Qsys and clock crossings

[Rob Gaddi]

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.

 

[Mark Curry]

In article <20131112124339.7deb9d9a@rg.highlandtechnology.com>,
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

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?

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

 

[Rob Gaddi]

On Tue, 12 Nov 2013 12:43:39 -0800
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

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.

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.

 

[Theo Markettos]

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

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?

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

 

[Rob Gaddi]

On 13 Nov 2013 09:53:53 +0000 (GMT)
Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
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?

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

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.