Qsys and clock crossings

I'd love if someone could tell me if what I've found is as stupid as I think it is, or far cleverer than I am.

So I'm putting together a design using Qsys on Quartus 13.0. I used the Avalon-MM Clock Crossing bridge out of the Altera library, and have been having some wacky issues on reset. So I go spelunking.

The Avalon-MM Clock Crossing bridge wraps two of the Avalon-ST Dual Clock FIFO. Okay, I suppose that makes sense. Both these cores have two reset inputs, one for the master/write side clock and one for the slave/read side. Fine, sure, good.

In the ST FIFO that's at the core of all this, however, those two resets never meet up. So the write side reset asynchronously clears the write_ptr, and the read side reset async clears the read_ptr.

Well, now I know why I'm getting old junk transactions stuck in my clock crossing bridge after resetting one side. Does anyone have a reason why one might want to reset only one side or the other of the FIFO, or is this (undocumented, of course) behavior just silly?

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi
Loading thread data ...

Additional note on this. Because the Avalon-ST Dual Clock FIFO (a.k.a. altera_avalon_dc_fifo) is also what is automatically inserted into the Qsys design for a clock-domain crossing when you simply let Qsys "take care of it" and have the design set for FIFO crossings rather than Handshake, the same problem occurs. If you only reset one clock domain, then the read and write pointers get out of whack and the FIFO gets hosed.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

I'm with you Rob - sounds silly to me. I know nothing of that product, so can't offer much, but common fifo bugs are around initialization. You often need a bit of logic in your design to make sure that both sides of the fifo come out of reset into the proper states. Resetting just one side seems like asking for trouble.

--Mark

Reply to
Mark Curry

I'm not completely clear on why that happens. You need two inputs because each reset needs to be in the right clock domain, otherwise Excitement (TM) happens if you try and clock domain cross with the resets. Perhaps the model is that the resets only reset the parts in the domain that belongs to it, and propagating the resets is your problem.

How are you generating the clocks for the two parts? I think the standard Qsys clock input block will also synchronise a reset to a given clock

- perhaps you need one of those?

Theo

Reply to
Theo Markettos

And yet the entire point of the core is clock domain crossing, so they should have had the resets cross and resynchronize as well. A halfway-reset FIFO is a broken FIFO.

The clocks/resets for the two parts are entirely independent. One is the 125 MHz clock that comes out of the PCIe core (which at least on Arria II can't be PLL'd like a real clock). The other is my own free-running 125 MHz clock. My system is a multi-mastered bus in which PCIe is one of the possible masters. The main logic has to all run from the free-running clock since PCIe availability isn't required for operation of the rest of the world.

The solution I used was to tie both resets to both sides of the clock crossing bridge. This forces Qsys to generate reset adapters on both sides that OR the two resets and synchronize the deasserting edge to the respective clock. But if you just rely on Qsys to automatically add your clock crossings, it won't do that. Hence, if you do have two independent reset domains, it'll wreck the FIFO.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.