Shift_registers With Mlab Memory

[Altera_Forum]

Hello everyone! 

 I am working with a Stratix III EP3SE260F1152C3 FPGA doing my PFC (final career project)  I need to generate a shift register using MLAB memory but Quartus II MegaWizard Plug-in Manager only allows to use 8LUT.   How can I obtain my aim?:confused:   Thank you very much!

[Altera_Forum]

I'm not sure it's possible to do a shift register with MLAB. Why do you want to do that?

[Altera_Forum]

The reason why I want that aim is that I need a component like Xilinx SRL16. It is a reconfigurable LUT that I can use like a 16 shift register.:( 

 That is why I want to use Altera shift register implemented with MLAB memory instead of 8 LUTs.  Thank you very much for your help!

[Altera_Forum]

What's wrong with LUTs? Are you low on resources?

[Altera_Forum]

Yes, of course. I have scanty resources because i am doing CFD processing and I can´t allow use so many LUTs

[Altera_Forum]

Quartus synthesis will automatically infer large shift-registers into memories. You can also manually create altshift_taps megafunctions. Note that this is not the same thing as the SRL16. Most importantly, it can't dynamically change the tap length, so if you use the SRL16 with dynamically change shift lengths, it's not equivalent. The altshift_taps is literally a memory with a continuously running read and write pointers(the pointers are made out of logic). So if you're doing a small, narrow shift register, then logic is better. But as soon as they get wide and/or somewhat deep, altshift_taps works better.

[Altera_Forum]

Thank you very much, Rysc! 

 I have tested altshift_taps but this option consumes greater memory (one lut but a lot of memory and registers) than synthesizing a shift register with several stages of pipeline.  I need to use a LUT like a 16 shift register like Xilinx SRL16 does.  Any solution?

[Altera_Forum]

What width/depth of shift register are you building? What device? For wider/deeper(say 8 bits wide, 8 bits deep), the altshift_taps consumes less resources than Xilinx. Cyclone devices may not be as much of an advantage since they don't have small memories. But really, you're storing a lot of data, so registers or memories are the two ways to get this done. I just want to make sure your analysis is correct, since I've seen designs being converted from X where they complain about this, but when it's all done it works out.

[Altera_Forum]

Estimated Rysc, 

 I need a shift register with an input bus of 32 bits of data and 70 pipeline stages. I am using a Stratix III device.  Thank you.

[Altera_Forum]

Forget my comment about 8x8 being the approximate size where altshift_taps is better. Still, for that size, the number altshift_taps is definitely what you want. I think it's still going to be bigger than an SRL16 implementation, but hopefully not too bad(and significantly smaller than making it out of registers).

[Altera_Forum]

--- Quote Start ---  Thank you very much, Rysc!  I have tested altshift_taps but this option consumes greater memory (one lut but a lot of memory and registers) than synthesizing a shift register with several stages of pipeline.  I need to use a LUT like a 16 shift register like Xilinx SRL16 does.  Any solution?  --- Quote End ---    There is none.  I'm doing the same thing. For example, making a 16-bit shift register out of MLAB's consumes more resources than just using 16 flip-flops. Altshift_Taps is somewhat of a solution. The problem with Alt****_Taps is that it must be clocked by 3x you regular clock. That is, if you want a shift register clocked at 100 MHz then AltShift_Taps must be clocked at 300 MHz to get the correct results. That introduces another high frequency clock domain which may be undesirable for one's application.  Seems Altera did not do a good job as to how a MLAB could be used. Further, it appears that every signal entering the MLAB is registered whether you like it or not. If I use MegaWizard to get memory there's an option to register the READ address or not. If you select NO, Quartus 13.0 goes wild and comes back saying out of memory. Generally, you have to reset your PC. A real pain.

[Altera_Forum]

it can be a bit of a pain, but you can get an MLAB to have 0 read latency

[Altera_Forum]

--- Quote Start ---  The problem with Alt****_Taps is that it must be clocked by 3x you regular clock  --- Quote End ---   I have mistakes using alt_***_taps,  why do they have to be clocked by 3x ? I don't find this information elsewhere.

[Altera_Forum]

I think it's a kind of misunderstanding. Some posters wanted a shift register with variable tap position and granularity of one. As altshift_taps is restricted to tap distances >= 3, using a threefold clock is an option to implement the function with altshift_taps though. A way of putting the cart before the horse. 

 Instead you'd ask, what's a suitable FPGA hardware the function can be mapped to, how can it be effectively coded? altshift_taps apparently isn't in this case.

[Altera_Forum]

99% of altshift_taps are used as a single shift-register with only one tap point. I would also say 90-95% of altshift_taps are just inferred by synthesis, i.e. if you create a shift-register in your code you'll see altshift_taps inferred if you look through the synthesis reports(actually, the best place is the Fitter Report -> Resource Utilization -> RAM Summary, copy all the names to a text file and search on "altshift").

[Altera_Forum]

Thanks for answer. You saved my time. 

In fact my problem was in the clock enable. Now it works as expected. I use this as a single shift register like 99% ;-)  I have to use the megawizard and instantiate this altshift_taps.  Quartus synthesis doesn't recognize my VHDL piece of code as a shift register : 21 * (256 sample * 24 bit wide), even if I forget the asynchronous clear, registerd my inpout and ouput signals, force Quartus to enable "logic to ram" and RAM associated options. In this case, Quartus takes half an hour to synthesis and takes many many many DFF.