1. A synchronous FIFO can only be used if both the read and write interface share the same clock.

Transcription

1 FIFO Answers

2 1. A synchronous FIFO can only be used if both the read and write interface share the same clock. 2. The depth of the FIFO is determined by the number of addressable locations in the memory core. For an n-bit address this would be 2 n. 3. Hmm. Well, the most obvious alternative I suppose would be a two-ported memory. In that case, the read side would need to know when additional data was written (and presumably how much) in order to read it out. With a FIFO, it starts reading when the empty flag is deasserted and keeps reading until it is asserted. Much simpler implementation of an elastic buffer between two domains potentially operating at different rates.

3 1. What is the best way to count the CCs it takes for transactions 2. How in-depth should we understand the Binary to Gray code and Gray code to Binary conversions? 3. Still a little confused on how augmented counters are used to set status flags cc for synchronization of signals that are crossing the abyss and then count the number of state transitions (or similar) required to be ready for the next exchange. Repeat for the other interface. Then take into account the potentially different clock periods to get an absolute time. 2. Hmm. You can assume that an appropriate module is available, e.g., G2B and B2G. 3. Augmented counters are used to differentiate between full and empty, since without an extra bit the write pointer would roll over or wrap around and would once again be equal to the read pointer when the FIFO is full.

4 1) Are there limitations for relative clock freq differences between write domain and read domain? 2) How to implement and follow depth/full of FIFOs that aren't a ^2 depth? 3) When should you use distributed RAM instead of BRAM (bulk size excluded)? 1. Not if the FIFO controllers are properly designed, as in the Cummings paper (and the FIFO memory is not implemented with dynamic memory!). 2. Hmm. I don t know that there is a clean way of implementing a FIFO with a depth that is not a power of two (nor would there seem to be a strong motivation!). I believe you would need additional logic in your pointers to jump from 2 n x back to zero as opposed to rolling over after reaching 2 n 1. Essentially the same as building a modulo-n counter. The problem is that for an asynchronous FIFO your pointers are no longer going to adhere to the single bitchange. 3. Aside from the size issue, I suspect that at some point the wiring between the distributed memory chunks might become a limiting factor. However, using the core wizard is always the best bet when targeting a specific technology.

5 1. You would have to read the rest of the Wikipedia entry. 2. Presumably. All things being equal, more or bigger pipes make things faster, assuming you can benefit from the increased throughput. Depends where your bottleneck is. 3. NMOS and PMOS transistors? How about static RAM cells for the memory core?

6 1. This is two questions! LFSRs have simpler next state logic, but can only be used with synchronous FIFOs because they do not satisfy the single bit-change requirement. I don t know of any way to implement an augmented LFSR, so you would need to use the status flag method, where setting of the flag was dependent upon both the pointer comparison and the operation being performed. 2. Yes, absolutely. Otherwise the read interface would read every clock cycle. 3. See the answer to question (1). 4. Sorry, you only get three questions. You can use the gray code pointers as addresses into memory. Whether you would want to probably depends upon how it affects area/speed. I m not sure there is a good reason to.

7 1. Not that I can think of. 2. I don t know about pipelining, but if you had a master and multiple slaves operating off of the same system clock, the master could distribute lengthy jobs to the slaves without having to worry about how long it took to complete. Just keep polling for a slave FIFO that wasn t full. 3. Not very easily. All of the data has to move in parallel if a word is read and inserting a word during a write has to bubble through the string until it encounters an occupied location. While it s easy to construct enough storage, the control logic is a bear.

8 (1) and (3) Our book probably says something about this. A FIFO is an efficient interface between two systems that are producing and consuming data at different rates, either because of differences in clock frequency or the processing times. (2) A synchronous FIFO is designed on the assumption that the read and write interfaces are operating from a common clock and thus all signals that pass between them are synchronous. This eliminates the need for the synchronizers and the single-bit change requirement for pointers, but the remaining logic is the same.

9

10 Is there an optimum FIFO size (W vs D) for a given problem that works in all environments? Does the environment have an affect on W vs D)? 1. Hmm. I would say that both are dependent upon the environments. In general, you want your FIFO wide enough so that each side can quickly access the FIFO. For example, if all of the write data becomes available in one clock cycle, then write all of it into one location. As for depth, that will depend on the relative rates of production and consumption. You want your FIFO deep enough that the producer never stalls for lack of space. 2. Hmm. I view the FIFO as simply an elastic buffer, or data conduit. It doesn t have any intelligence for searching. Now, if we want to investigate the Xilinx Content Addressable Memory core...

11 Binary pointers can not be passed between the two controllers in an asynchronous FIFO implementation, only pointers that satisfy the single-bit change between accesses. You are absolutely correct that if one side is super fast, then it will appear to the other side as if multiple bits change between counts, but that is simply because the slow side did not sample the intervening pointer values. The important point is that within the sampling window (setup + hold) of the receiver s clock, only one bit will be changing. It doesn t matter whether the first synchronizer FF resolves to the new value or returns to the previous value the receiver will always see a proper sequence of pointer values.

12 Note to self: Never offer to do this again. It takes forever!