asynchronous bus transfers

Jason: It would be nice to have more specifics on your problem.

Inherently ther is no difference between an FPGA (which one) and anything else.

Which kid of metastability? Which kid of microcontroller? Do you use the same clock, and derive one from another ? (I guess no). Here having somewhat synchronous clocks simplify the problem, but async transfers are ok... as long as you do not violate any timing requirement (mostly cpu/memory). I would suggest to derive one clock from another if you could. The somewhat brute force way to resolve this issue would be to use of FIFO's between busses but you probably can do better. There is no way you can avoid a proper assessment of timing closure!

-- All the luck.

Jas> Hello all,

Does the FPGA not have DualPort RAM blocks ?

-jg

Jason,

If seems you have to either use speed buffer with FIFO or you have to do handshake between two clock domains. Hope somebody else can suggest other approaches.

If you know the relationship between 2 clock domains, you may simplify your circuit a little.

Ch>Jason:

...or a PLL to generate both clocks?

-- Mike Tresleler

One technique is to have an N-to-1 Mux with the output selected by address lines, and a decode of a tristate output enable off of appropriate signals. Key is that this is all done without a clock ... which is okay since it sounds like the read is not doing anything like advancing internal address pointers ... as in a FIFO.

-- Regards, John Retta Owner and Designer Retta Technical Consulting Inc.

email : snipped-for-privacy@rtc-inc.com web :

metastability

incurring

then

have

how

an

I designed something similar and found it was not a big problem. You don't have to worry about metastability on the read as long as you are not doing anything else with the strobe internally. Even though the read enable or address may be changing on a clock edge, that first cycle will be ignored by the CPU and 10 ns later the second clock cycle will read valid data from the RAM in the FPGA.

On the write you should use a register to hold the data when the write strobe is asserted. The stabilized (and delayed) write strobe can write the data into your RAM. If your data is not stable on the leading edge of the write strobe, you can use one of the delayed strobes to as your data register enable. That will help you meet both setup and hold.

Rick,

That sounds like the approach that I was considering, as the reads seem to be okay, it's the writes that become unstable, however if I am delaying the write strobe, then I must also delay the data lines, and the address lines, otherwise the micro has moved on to the next cycle without the data being written correctly. It would seem to me that I must pipeline the write transfer to eliminate the instability.

Thanks for the help.

Jas> >

bus

metastability

through

question

incurring

then

have

and

how

an

the

Ultimately in the design I start with one 10 MHz TCXO and use PLL chips to generate a 40 MHz clock (micro) and another 100 MHz clock (FPGA). Since there are no handshaking lines between the chips for data transfers I cannot use. I have not checked the relationship between the two clocks, as I wanted just assume they were completely asynchronous for the design, thus allowing this design to work in any situation.

Thanks for the help.

Jason

FIFO's

bus

data

the

Jim,

Yes it does (XC2S200), but I have no access to the 40 MHz clock from the micro, otherwise I would have implemented a synchronous transfer or used the dual port RAM. I figured that without access to the 40 MHz clock the dual port RAM would be out of the question since I would need a clock one the second port which I do not have.

Thanks

Jas> > Hello all,

bus

metastability

through

question

incurring

then

have

and

how

an

the

You only need one level of registers or latches for the write data and either address or decoded address. You are guaranteed two rising edges of the 100 MHz clock in each period of the 40 MHz clock. So you just need to delay the write strobe by one clock cycle and the write strobe will be settled. So use that second clock edge to register the non-timing info (data address...).

just make or just miss clock edge or even was metastable V write -----------_________________________---- clock -----_____-----_____-----_____-----_____ data,etc ==========xx=======================xx=== ^ ^ register data,etc here | or here |

You can see, either way the data and address are grabbed correctly.

On my design, I took advantage of the delay to predecode the addresses into separate control strobes removing one level of delay in the subsequent logic.

USE data,etc here | or here |

I'm not sure I was awake when I wrote this. You don't actually need to register the data,etc since they are stable long before and after your enabled clock edge. Just use them before they go away which is guaranteed to be a half clock cycle after the enabled clock edge.

Having the clock would not do you a lot of good anyway unless the micro specs the transfers relative to the clock, which is rare except for SSRAM or SDRAM interfaces.

But you can use the rising edge of the write pulse as the clock to the BRAM. As long as it is a one way interface, you can provide your own clock to the read side on the other port. The micro won't be able to read what it has written though since you need a clock to read as well.

But my other suggestion only requires that you delay the write/read strobes.