fastest FPGA

Moving pointers would require an addressable load and an addressable read - what's available with dual-ports. A fixed entry with single addressable output mux gives everything needed for an addressable serial-in shift register without the need for extra bits. Maintaining the in pointer and calculating the out pointer from the "I want the 5th bit" control to the output mux is a sincere amount of logic above and beyond the normal LUT structure. The SRL's output MUX is the same as used for providing the LUT output in normal operation requiring no additional logic beyond the shift through the 16 memory cells.

There are many applications where a FIFO structure is best handled with separate in/out pointers, particularly when changing between time domains. The SRLs ar restricted to the same time domain for the input and output but don't need the extra pointers. As a FIFO, the SRLs have a slightly more complicated single pointer (adds and subtracts for write and read, respectively) but ends up more compact in the end.

I gave this a bit more thought and realized that there is already a lot of circuitry in the LUT. It has the output mux (read decode) and the write address decode and the LUT RAM bits are already in a shift register for loading configuration data. So the SRL is essentialy free. To use a moving pointer two 4 bit counters would have to be added, so I am sure they would not want to do it this way.

Can you use the SRL as a FIFO? I was not aware that you could change the length. I thought that was a configuration setting. If they are doing that the only extra for the moving pointers would be the 4 bit write address counter.

Not really, there is a common loading mechanism, but that has to serve the whole chip. The "prior to V5" SRL16 uses the age-old trick of differentiating the clock and putting a low-pass filter between the latches. Like we used to do in the 'fifties and 'sixties, when transistors were expensive. Since this does not scale well at 65 nm and below, V5 went back to the "proper 2-latches per bit, master/slave" method.

You use a fixed insertion point for writing into the SRL16, but move the read location by changing the mux address forwards, backwards or not at all. Takes a moment to understand... Peter Alfke

The SRLs are absolutely useable as FIFOs with the only caveat that they're in the same time domain. The output value is a combinatorial result from the 16 values in the memory and the LUT address: the standard F1-F4 or G1-G4 lines. If the data gets shifted in right when you're trying to read, no amount of coordination with the output mux select will give you a static value. So... used in a synchronous fashion, these are *great* for variable length FIFOs rather than just static delay lines. The pointer comes down to something like:

always @(posedge clk) SRLsel[3:0]

YOu sure can. I think a synchronous fifo was the very first macro I wrote for the SRL16, before I could even get a part with them in it.

To use it as a FIFO, you use an SRL16 (or several in parallel for multi-bit) plus an up-down counter. Push activates the SRL16's write enable and increments the count. Pop just decrements the count. The count addresses the SRL16 read port. If you make the counter 5 bits and preload it with "11111" then you get an empty indication from the counter's msb for almost free.

Up-down count doesn't have to take two levels of logic, it can be done with one level, but it has to be specified carefully to keep the synthesis from making it into two levels. Reset works fine too:

signa cnt, cnt_dec: unsigned(4 downto 0); signal cnt_inc: integer range 0 to 1;

cnt_dec '0'); cnt_inc

I guess it has been too long since I have used the SRL. I had forgotten that the read port was addressable, but that only makes sense. For a fixed delay shift register these inputs are just hard connected which is the way I have always used the SRLs.

I have not used them in many years. I guess they are mostly useful for signal processing which I don't seem to do much anymore. Otherwise I don't have many apps where delays are a good thing.

The SRL16's are actually one of the most versatile blocks on the FPGA. You can use them for:

reprogrammable LUTs --poor man's reconfiguration dual port memory --serial write port, parallel read synchronous FIFO --smallest FIFO implementation data reordering --this is really cool for sorting and other apps counters state machines variable delays fixed delays

The only one of these that is inferred by synthesis tools is the fixed delay, and that is also the least interesting out of all these. I've probably used them for other things as well, but these are the ones that pop out at me. It is a shame that Xilinx doesn't promote the usefulness of the SRL16 more than they do, as I suspect most users don't have a clue how powerful these little buggers are.

How can you use SRLs for these? I guess a shift register can be used for a simple FSM like a Johnson ring counter.

Inference works for SynplifyPro and Verilog without trouble for quite some time. The simplest implementation is to shift into the SRL register vector bit[0] and index the vector with your MUX. Variable length FIFOs infer nicely.

The counter-type use I liked *so* much was started by Antti who showed how to get a 2^27 divider into 6 LUTs (or similarly tiny number). I extended that to an NCO and was real happy with the results. The key to counters in this sense is bit serial arithmatic. Fun! The only caveat for the NCO which recirculates the phase value in a looped SRL is to make sure the clock is stable before letting the system shift!

How do you make an LFSR if you can't access any intermediate taps? The two forms require that you either insert XOR gates into the shift path or that you tap the intermediate outputs to XOR a value that is shifted into the shift register. If you have to use multiple SRLs, then you are just using them as fixed length shift registers.

You have to be judicious on your choice of taps. One SRL16 and the accompanying flip-flop gives you access to two adjacent taps, which works for a fair number of small LFSR lengths.

You can also use the SRL16 as a Johnson counter by adding only an inverter. For short counts, you can use the shift register as a shift count, which I use frequently in state machines.

I've also used the SRL addressing a LUT that controls the read address as a state machine a while back in a Spartan50 design that was pretty close to 100% utilized (customer didn't want to go to a larger device).

Yes, a lot of the uses simply use the SRL as a shift register, but the point is by being conscious of the SRL as a design option you can often design the logic in a way that uses the SRL to realize a smaller implementation than a straightforward approach migh provide. This is particularly true with small counters where only a terminal count output is needed, or in state machines.

Several years ago I managed to get Synplify 6.3 to infer SRL16s for a variable delay. Frankly I was amazed it worked :) I can dig up the code if anyone is interested.

cheers, aaron

Synplicity infers it as long as there are enough taps in the delay. It won't, for instance, infer an SRL16 for a variable delay with only 1,2,3 or 4 clocks delay, instead it infers flip-flops with a mux. Same template works fine with 9 taps.

While it's nice to have synthesis take care of all cases without concern, if you know you want to target an SRL (so you leave the reset out) why not make it longer so there's no problem inferring it "properly?" There's not a big loss in readability and the implementation is still clean.

I personally think Synplify synthesis tools do an excellent job in the first 23 miles of the marathon but that last mile is where things trip up a bit. Very decent results all around but there are particular nuisances that - in my opinion - should be handled better. The overall quality is still better than other tools I've known.

Because the design needed a selection between 1 and 4 taps. It turned out to be considerably less work to just instantiate the SRL16 and be done with it rather than dealing with the pushing on a rope trying to get the tools to do what I wanted...at the cost of "portability" and an increase in simulation time. Instantiation of things like this gives the confidence that the tools get it right when you already have a specific design approach in mind.

Nice list. Care to elaborate on the "data reordering" use case? I can't think of any good examples.

Thanks, Tommy

OK, an example: A small FFT requires the input data in bit reversed order, however the circuit presents data in natural order:

the data goes into the SRL16 in natural order, and then we permute the address for read so that it reads out in the bit reversed order

input: 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F output: 0 8 C 2 A 6 E 1 9 5 D 3 B 7 F address=delay-2 A 3 0 B 4 9 2 x 9 E 7 y B x 9 x=10h y=12h

This case requires two cascaded SRL16's to get all the delays needed for the sequence. The address can be produced from an ordinary counter by passing the 4 bit count through a 4 input x4 bit LUT.

Reversing the order of data in a set of 8 numbers (a left-right mirror) is similar, using just an SRL16 per bit and a 3 bit counter: input: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 output: 7 6 5 4 3 2 1 0 address=delay-2 0 2 4 6 8 A C E