cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
nadaumtimuj
Explorer
Explorer
1,420 Views
Registered: ‎01-29-2021

Can we implement 32-bit LFSR using BRAM?

Hi,

I have the following code to implement a 32-bit LFSR. Is there any way to implement an LFSR using BRAM? If yes, is BRAM implementation more efficient than FF?

 

module LFSR ( clk, out);

input clk;
output reg [31:0]out;
wire feedback;

parameter seed = 32'b0;

initial out = seed; 

assign feedback = !(out[31]^out[21]^out[1]^out[0]);

always @(clk )
out <= {out[30:0],feedback};

endmodule

 

 

0 Kudos
18 Replies
hongh
Moderator
Moderator
1,390 Views
Registered: ‎11-04-2010

The directive AreaMapLargeShiftRegToBRAM of synth_design can help to detects large shift registers and implements them using dedicated block RAM.

Mapping small ShiftReg into BRAM is not beneficial for the design.

Mapping large ShiftReg into BRAM can help to reduce the utilization and raise the routability.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
nadaumtimuj
Explorer
Explorer
1,376 Views
Registered: ‎01-29-2021

Thanks, how about a situation where I need 32-bit LFSR but I need many of them? Say for example 5000 instances in a neural network. Also could you please tell me why I have that AreaMapLargeShiftRegToBRAM  directive missing in my project settings? 

nadaumtimuj_0-1626341509945.png

 

0 Kudos
dgisselq
Scholar
Scholar
1,320 Views
Registered: ‎05-21-2015

@nadaumtimuj ,

Be very aware of your always @(clk) statement.  It's not synthesizable in general, and it will often lead you to simulation/synthesis mismatch.  I think you meant always @(posedge clk).

Dan

hongh
Moderator
Moderator
1,309 Views
Registered: ‎11-04-2010

Too many SRL instances cannot be mapped into BRAMs, because BRAMs don't have enough ports.

AreaMapLargeShiftRegToBRAM is directive of synth_design, instead of strategy

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
synth_dir.png
drjohnsmith
Teacher
Teacher
1,289 Views
Registered: ‎07-09-2009

Have you seen these 

https://www.xilinx.com/support/documentation/application_notes/xapp210.pdf

https://www.xilinx.com/support/documentation/application_notes/xapp211.pdf

Golden oldies but still relevant

  FPGA is stuffed with thousands of SRL's.

   BRAM are not the way to go .

BUT 

what do you want to do with thousands of LFSR ?

   to generate gaussian noise, you only need 16 or so max

        if your making a "random" number generator, 

          then the more you gate together the less random it becomes,  

so struggling a bit here,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
nadaumtimuj
Explorer
Explorer
1,246 Views
Registered: ‎01-29-2021

@dgisselq yes, you are right. I meant posedge. Thanks.

@hongh @drjohnsmith Thank you. I am using LFSR for RNG. I know they are correlated but I cannot afford 64-bit LFSR or Xoshiro LFSR since I have already resource limitation. With the 32-bit LFSR, I synthesized by Vivado defaults without doing any smart tweak. I hope it is using the SRL itself. I will then avoid using BRAM unless it saves me anything. Thank you guys.

0 Kudos
drjohnsmith
Teacher
Teacher
1,238 Views
Registered: ‎07-09-2009

All the options you state are predictable, 

    not random, 

do not use them for anything crypto , 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
nadaumtimuj
Explorer
Explorer
1,180 Views
Registered: ‎01-29-2021

@hongh I used that directive  in a design that has only five 32-bit LFSRs. Nothing changed after synthesis. Same LUT, same FF, and only 1 BRAM used as before. Probably it isn't seen to be large by Vivado.

nadaumtimuj
Explorer
Explorer
1,134 Views
Registered: ‎01-29-2021

@drjohnsmith One more thing, I see that in my design all the LFSRs are being implemented using FF, instead of SRL. Is that ok? Or is there an way to force SRL? Which one is better? The following link suggests that SRL is some kind of alternative to Altera ALTSHIFT_TAPS. Thanks.

Solved: Xilinx ALTSHIFT_TAPS equivalent? - Community Forums

0 Kudos
drjohnsmith
Teacher
Teacher
1,077 Views
Registered: ‎07-09-2009

We dont mention the alternative FPGA compnies here,

   ( Xilinx patented the SRL , I think by  @kenchapman  ,then others have "copied" , patent wars )

any way,

things that can stop SRL being used,

   a reset in your code, SRL don't have a reset,

          as an FPGA loads to a known state at boot, then a reset is not needed, 

  minimum SRL length I think is 3 registers,

     any less than that the tools know the routing is better with two individual FF.

Modern FPGA are so dammed big that SRL inference has become less important, and so less supported, but its still there,

just follow the template here

https://www.xilinx.com/support/documentation/application_notes/xapp465.pdf

( but use rising _edge(clk ) if your using Vhdl please ) 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
seamusbleu
Voyager
Voyager
949 Views
Registered: ‎08-12-2008

Adding to @drjohnsmith 's reply, the LFSR can only use SRL between taps.

<== If this was helpful, please feel free to give Kudos, and accept as Solution if it answers your question ==>
maps-mpls
Mentor
Mentor
833 Views
Registered: ‎06-20-2017

>things that can stop SRL being used,

>a reset in your code, SRL don't have a reset --@drjohnsmith 

 

You can still get SRLs with synchronous resets--try it sometime.  What you wrote was once true, but synthesizers are not tightly specified by standards bodies, and they change as EDA tool designers come up with new tricks.  In general, rules of thumb one day become obsolete another day. 

>Modern FPGA are so dammed big that SRL inference has become less important, and so less supported, but its still there, - @drjohnsmith 

SRL inference is still important even with large FPGAs.  They reduce congestion, and can mean all the difference between meeting timing or not meeting timing on a challenging design, as reduced congestion benefits other aspects of large designs--not just the shift register itself.

*** Destination: Rapid design and development cycles *** Please remember to give internet points to those who help you here. ***
seamusbleu
Voyager
Voyager
810 Views
Registered: ‎08-12-2008

@maps-mpls- please illustrate how you can have a sync reset with an SRL.  I tried it (with a kintex-7 part if it matters), and as I suspected, without the reset lines it's an SRL, with them, it gets implemented as a series of FF's.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity test_srl is port (
   Clk            : in  std_logic;
   Rst            : in  std_logic;
   Dummyi         : in  std_logic;
   Dummyo         : out std_logic);
end test_srl;

architecture Rtl of test_srl is
   signal srl_q    : std_logic_vector(15 downto 0) := (others => '0');

begin
   reg_p : process (Clk)
   begin --  reg_p
      if (RISING_EDGE(Clk)) then
         srl_q <= srl_q(srl_q'HIGH-1 downto 0) & Dummyi;
         --
--       if (Rst = '1') then
--          srl_q <= (others => '0');
--       end if;
      end if;
   end process reg_p;
   --
   Dummyo <= srl_q(srl_q'HIGH);
end Rtl;

 

<== If this was helpful, please feel free to give Kudos, and accept as Solution if it answers your question ==>
markcurry
Scholar
Scholar
798 Views
Registered: ‎09-16-2009

@maps-mpls

> You can still get SRLs with synchronous resets--try it sometime. What you wrote was once true, but synthesizers are not tightly specified by standards bodies, and they change as EDA tool designers come up with new tricks. In general, rules of thumb one day become obsolete another day. 

(Double-checking my various Xilinx library Primitives guides... i.e. UG574 - to make sure things haven't changed...)

I think you're misremembering.  SRLs physically have no Reset on the cell primitive - doesn't matter what the EDA tools do - they can't change hardware this way.  If you code a reset, you'll get LUT FFs instead or SRLs.

Regards,

Mark

maps-mpls
Mentor
Mentor
748 Views
Registered: ‎06-20-2017

>I think you're misremembering. -- @markcurry 

also @seamusbleu 

Possibly misremembering.  But I seem to recall the synthesizer doing something clever to get the same behavior (e.g., use a register with reset for first and/or last register in SR, use SRL for intermediate).  I don't have time to check right now, but I recall the synthesizer "breaking" some code where I had a synchronous reset to prevent SRL inference, but an SRL got inferred anyway.  Seems the reset would have to be some number of clocks for this to work.  But I might be misremembering.

 

But you are right about SRLs not having reset.  

*** Destination: Rapid design and development cycles *** Please remember to give internet points to those who help you here. ***
0 Kudos
drjohnsmith
Teacher
Teacher
722 Views
Registered: ‎07-09-2009

@maps-mpls 

You are rigth, 

   tools progress,

     Also you are wrong,

The SRL, as others have tried and shown,

    does not have a reset.

if you code a shift register with a reset, then you will not get a SRL.

 

There is in the tools, the ability to as you say, add a start register, that is able to  be reset,

     and then if the reset is long enough, and the SRL is enabled, then the reset gets shifted through,

Does not work if the output of the SRL is part of a LFSR, due to the feedback to the begining,

     it never took off as an idea, as there are just so many exceptoins to make it work, 

       

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
maps-mpls
Mentor
Mentor
696 Views
Registered: ‎06-20-2017

> Also you are wrong, The SRL, as others have tried and shown, does not have a reset. - @drjohnsmith 

What I responded to is that I have seen shift registers with synchronous resets described mapped to DFF/SRL/DFF or SRL/DFF or DFF/SRL, i.e., if you code a reset, it is no longer a guarantee that you won't get an SRL. 

I may have misremembered (TBD, but probably misremembered), but--side comment--your ability to accurately characterize statements makes me wonder about your academic credentials.

I just did a quick search, and I cannot find the project where a SR with a synchronous reset was converted to a DFF/SRL/DFF.  Probably because I stopped gratuitously coding resets after reading and pondering WP272.  Reconstructing, maybe I removed a reset from a SR (used to make timing across a die), it got coding as an SRL, and then I had to add an srl_style to prevent SRL inference.  This seems likely in light of other's trying and failing to reproduce my snipe hunt (apologies to @markcurry  and @seamusbleu 

*** Destination: Rapid design and development cycles *** Please remember to give internet points to those who help you here. ***
0 Kudos
seamusbleu
Voyager
Voyager
693 Views
Registered: ‎08-12-2008

@maps-mpls- I was careful not to call you wrong in case it was me that was misremembering something, or, that I might learn something I didn't know.

<== If this was helpful, please feel free to give Kudos, and accept as Solution if it answers your question ==>
0 Kudos