FPGA : Async FIFO, Programmable full

Reply to
Peter Alfke
Loading thread data ...

What I want to avoid is the gray-to-binary conversion necessary to calculate population counts and flags afterwards.

The design only introduces a simple handshake and replaces the gray resync registers by copy (hold) registers to create a safe false path for data between clock domains. IMO, this is simpler than having to decode gray counters before computing differences.

Yes, that approach does sacrifice five extra FFs and some in-to-out latency for the handshaking in each direction (that could be reduced by using some async SR FFs) but it is a straight register-to-register design that enables direct pointer arithmetic on both sides. With gray counters, you end up needing a decoder for both local and remote counters on each side before doing arithmetic in each clock domain.

As I said, designers are free to pick their poison.

For most applications I have in mind (mostly DMA-like), I can afford to trade some latency and a few FFs for the ability to stick with a simple, plain binary register-to-register and decoder-less design.

BTW, unless the gray decoders are fully absorbed by the arithmetic at no performance cost (doesn't gray code kill the carry cha> Daniel, why do you want to avoid the Gray register? Your design is at

Reply to
Daniel S.

Reply to
Peter Alfke

Yes, one can do "ptrA == ptrB" directly in gray... but if I want to do "ptrA - ptrB" to know how much headroom I have, it does not work quite as nicely, this does require G2B conversion.

For a gray implementation, it is probably preferable to generate a straight gray counter and convert that to linear binary for local use to avoid combinational paths and routing between the counter's registers and the other domain's resync registers since it increases the risk transcoding glitches (path delays + non-existing phase relation + ...) getting through. With a binary counter, the gray conversion must be registered on the local clock before resyncing to the other clock.

Reply to
Daniel S.

Reply to
Peter Alfke

To agree, there would need to be an argument to agree on in the first place. Since I was only proposing an alternative way of going about pointer data domain crossing, the only thing possibly worth arguing over is whether or not the approach is valid... and since I have used this approach in an ASIC project, I have reasonable proof that it is.

Is it the best implementation? That answer is application-specific.

The wheel has been patented a few times as well, there are way too many duplicate, obvious and useless patents out there, it makes finding truly relevant stuff an extremely tedious task.

From what I have seen in FIFO patents, they suffer from the same redundancy and irrelevance as other patents: they reinvent multi-bits signal domain crossing, not FIFOs themselves. All claims beyond that are frivolous at best - once the cross-over is done, everything beyond that is easily 20+ years old common knowledge.

I am very much surprised to see that some async FIFO patents are under

10 years old... the gray code and DP-SRAM or register file FIFO combo is much older than that AFAIK.
Reply to
Daniel S.

agree, there would need to be an argument to agree on in the first

has been patented a few times as well, there are way too many

Reply to
Peter Alfke

I wonder if I should be jealous... on one hand, you got to do one-man IC designs while on the other hand, the function alone is useless. All I will ever see on the ASIC side is my functions representing only a fraction of some 10M+ gates design.

Well, I suppose you probably envy younger designers for hav> For what it is worth:

agree, there would need to be an argument to agree on in the first

Reply to
Daniel S.

The big difference, for better or worse, is that, in the olden days, you could, and you had to, understand everything down to the minutest details. Whether it was building vacuum tube radios in the 'fifties, leading a small group to design data processing equipment, and re-invent germanium-transistor circuitry, core-memory drivers and ultra-slow mag-tape radback in the 'sixties. Even as late as 1988, I had the "pleasure" of completely taking apart and re-writing the Xilinx data book. Pain and agony, but also the joy of tangible achievement. Nowadays, the jobs are usually so complex that nobody can understand, let alone create, the whole system. There is no way I could re-write our product documentation. Too many words, too many specialties, and too many fiefdoms. On the other hand, the tools are now so incredibly more powerful that jobs which almost killed us then, have now become trivial. Who remembers looking for once-a-minute transient events on an analog scope? Darken the room, and glue you face, pupils wide open, to the Tektronix screen...

It's not a questi> I wonder if I should be jealous... on one hand, you got to do one-man IC

agree, there would need to be an argument to agree on in the first

Reply to
Peter Alfke

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.