Removing set/reset logic for shift register (HDL ADVISOR )

Hi,
I'm getting an HDL ADVISOR message when I synthesize this code.
Basically, it is a big shift register that shift-in data on each
rising edge of mclk if srclkRise is high, and outputs its data on the
rising edge of mclk if lrclkRise is high. I don't quite understand the
advice here. Can anybody help?
Thanks,
David

--ADVICE
INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
signal <datain<8>> and currently occupies 9 logic cells (5 slices).
Removing the set/reset logic would take advantage of SRL16 (and
derived) primitives and reduce this to 1 logic cells (1 slices).
Evaluate if the set/reset can be removed for this simple shift
register. The majority of simple pipeline structures do not need to be
set/reset operationally.


--CODE
always @ (posedge mclk or negedge resetb)
begin
	if (~resetb) begin
		datain <= 0;
		leftdata <= 0;
		rightdata <= 0;
	end
	else begin 
		if (sclkRise == 1) begin
			datain[63:1] <= datain[62:0];
			datain[0] <= sdata;
		end
		if (lrclkRise == 1) begin
			leftdata <= datain[63:40];
			rightdata <= datain[31:8];
		end	
	end	
end

"David" <david.lamb@gmail.com> schreef in bericht
news:4b5ddf5.0410010758.cf16a3@posting.google.com...
> Hi,
> I'm getting an HDL ADVISOR message when I synthesize this code.
> Basically, it is a big shift register that shift-in data on each
> rising edge of mclk if srclkRise is high, and outputs its data on the
> rising edge of mclk if lrclkRise is high. I don't quite understand the
> advice here. Can anybody help?
> Thanks,
> David
>
> --ADVICE
> INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
> signal <datain<8>> and currently occupies 9 logic cells (5 slices).
> Removing the set/reset logic would take advantage of SRL16 (and
> derived) primitives and reduce this to 1 logic cells (1 slices).
> Evaluate if the set/reset can be removed for this simple shift
> register. The majority of simple pipeline structures do not need to be
> set/reset operationally.
>
>
> --CODE
> always @ (posedge mclk or negedge resetb)
> begin
> if (~resetb) begin
> datain <= 0;
> leftdata <= 0;
> rightdata <= 0;
> end
> else begin
> if (sclkRise == 1) begin
> datain[63:1] <= datain[62:0];
> datain[0] <= sdata;
> end
> if (lrclkRise == 1) begin
> leftdata <= datain[63:40];
> rightdata <= datain[31:8];
> end
> end
> end

I think it's the resetting code at the beginning that causes this. Resetting
all the registers is set/reset functionality. I don't know Verilog that
well, but it seems this is a synchronous reset; that means that for each
register a 2:1 mux is needed, one input to load a zero, and the other input
to load the data from the neighbouring register. Converting this to an
asychronous reset would remove all those muxes, and utilize the dedicated
preset/reset input on the flipflop.

Jeroen

The SRL16 does not have a reset pin on it...ie, you can't clear its
contents in one clock cycle.  Your code has a reset in it that clears the
whole shift register, which means it cannot be implemented using an SRL16
primitive (which costs only one LUT+FF instead of 9).  If you can
eliminate the reset on this shift register, then you get a more compact
implementation.  Your code would look like this:

always @ (posedge mclk or negedge resetb)
begin
                  if (sclkRise == 1) begin
                        datain[63:1] <= datain[62:0];
                        datain[0] <= sdata;
                end
                if (lrclkRise == 1) begin
                        leftdata <= datain[63:40];
                        rightdata <= datain[31:8];
                end

end

David wrote:

> Hi,
> I'm getting an HDL ADVISOR message when I synthesize this code.
> Basically, it is a big shift register that shift-in data on each
> rising edge of mclk if srclkRise is high, and outputs its data on the
> rising edge of mclk if lrclkRise is high. I don't quite understand the
> advice here. Can anybody help?
> Thanks,
> David
>
> --ADVICE
> INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
> signal <datain<8>> and currently occupies 9 logic cells (5 slices).
> Removing the set/reset logic would take advantage of SRL16 (and
> derived) primitives and reduce this to 1 logic cells (1 slices).
> Evaluate if the set/reset can be removed for this simple shift
> register. The majority of simple pipeline structures do not need to be
> set/reset operationally.
>
> --CODE
> always @ (posedge mclk or negedge resetb)
> begin
>         if (~resetb) begin
>                 datain <= 0;
>                 leftdata <= 0;
>                 rightdata <= 0;
>         end
>         else begin
>                 if (sclkRise == 1) begin
>                         datain[63:1] <= datain[62:0];
>                         datain[0] <= sdata;
>                 end
>                 if (lrclkRise == 1) begin
>                         leftdata <= datain[63:40];
>                         rightdata <= datain[31:8];
>                 end
>         end
> end

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Ok I understand...but isn't it better to have a reset for all our flip flop?
If something goes wrong - or when I press the reset button...- the
controller can always reset everything to zero before we start again...

Thanks,
David

"Ray Andraka" <ray@andraka.com> wrote in message
news:415DAEA4.AAFC9B99@andraka.com...
> The SRL16 does not have a reset pin on it...ie, you can't clear its
> contents in one clock cycle.  Your code has a reset in it that clears the
> whole shift register, which means it cannot be implemented using an SRL16
> primitive (which costs only one LUT+FF instead of 9).  If you can
> eliminate the reset on this shift register, then you get a more compact
> implementation.  Your code would look like this:
>
> always @ (posedge mclk or negedge resetb)
> begin
>                   if (sclkRise == 1) begin
>                         datain[63:1] <= datain[62:0];
>                         datain[0] <= sdata;
>                 end
>                 if (lrclkRise == 1) begin
>                         leftdata <= datain[63:40];
>                         rightdata <= datain[31:8];
>                 end
>
> end
>
> David wrote:
>
> > Hi,
> > I'm getting an HDL ADVISOR message when I synthesize this code.
> > Basically, it is a big shift register that shift-in data on each
> > rising edge of mclk if srclkRise is high, and outputs its data on the
> > rising edge of mclk if lrclkRise is high. I don't quite understand the
> > advice here. Can anybody help?
> > Thanks,
> > David
> >
> > --ADVICE
> > INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
> > signal <datain<8>> and currently occupies 9 logic cells (5 slices).
> > Removing the set/reset logic would take advantage of SRL16 (and
> > derived) primitives and reduce this to 1 logic cells (1 slices).
> > Evaluate if the set/reset can be removed for this simple shift
> > register. The majority of simple pipeline structures do not need to be
> > set/reset operationally.
> >
> > --CODE
> > always @ (posedge mclk or negedge resetb)
> > begin
> >         if (~resetb) begin
> >                 datain <= 0;
> >                 leftdata <= 0;
> >                 rightdata <= 0;
> >         end
> >         else begin
> >                 if (sclkRise == 1) begin
> >                         datain[63:1] <= datain[62:0];
> >                         datain[0] <= sdata;
> >                 end
> >                 if (lrclkRise == 1) begin
> >                         leftdata <= datain[63:40];
> >                         rightdata <= datain[31:8];
> >                 end
> >         end
> > end
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>

>Ok I understand...but isn't it better to have a reset for all our flip flop?
>If something goes wrong - or when I press the reset button...- the
>controller can always reset everything to zero before we start again...

"Better" is an interesting word.  Sure, it's cleaner.  How much
are you willing to pay for that?  If it's just data in a pipeline
things will get cleaned out after a few cycles.  (May not be true
if IIR filters are involved.)

Note for example that (most) RAMs don't have a reset pin to
clear out the whole array.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Depends on your design and what you are willing to settle for.  Technically
speaking, all you really need to do is provide a way of clearing stuff in your
design tht is inside hardware loops.  For example, a state machine or an IIR
filter have a 'loop' that needs to be broken in order to bring the hardware to a
known state.  In many cases, it is perfectly acceptable to clear only key points
in the design, and sometimes even require the reset be asserted for some minimum
number of clock cycles to achieve a known state.  Yes, the easy methodology is
to reset every flip-flop, but it is not necessary and can cost you dearly in
terms of both gates and reset signal fan out (and therefore delay).



Dave wrote:

> Ok I understand...but isn't it better to have a reset for all our flip flop?
> If something goes wrong - or when I press the reset button...- the
> controller can always reset everything to zero before we start again...
>
> Thanks,
> David
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:415DAEA4.AAFC9B99@andraka.com...
> > The SRL16 does not have a reset pin on it...ie, you can't clear its
> > contents in one clock cycle.  Your code has a reset in it that clears the
> > whole shift register, which means it cannot be implemented using an SRL16
> > primitive (which costs only one LUT+FF instead of 9).  If you can
> > eliminate the reset on this shift register, then you get a more compact
> > implementation.  Your code would look like this:
> >
> > always @ (posedge mclk or negedge resetb)
> > begin
> >                   if (sclkRise == 1) begin
> >                         datain[63:1] <= datain[62:0];
> >                         datain[0] <= sdata;
> >                 end
> >                 if (lrclkRise == 1) begin
> >                         leftdata <= datain[63:40];
> >                         rightdata <= datain[31:8];
> >                 end
> >
> > end
> >
> > David wrote:
> >
> > > Hi,
> > > I'm getting an HDL ADVISOR message when I synthesize this code.
> > > Basically, it is a big shift register that shift-in data on each
> > > rising edge of mclk if srclkRise is high, and outputs its data on the
> > > rising edge of mclk if lrclkRise is high. I don't quite understand the
> > > advice here. Can anybody help?
> > > Thanks,
> > > David
> > >
> > > --ADVICE
> > > INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for
> > > signal <datain<8>> and currently occupies 9 logic cells (5 slices).
> > > Removing the set/reset logic would take advantage of SRL16 (and
> > > derived) primitives and reduce this to 1 logic cells (1 slices).
> > > Evaluate if the set/reset can be removed for this simple shift
> > > register. The majority of simple pipeline structures do not need to be
> > > set/reset operationally.
> > >
> > > --CODE
> > > always @ (posedge mclk or negedge resetb)
> > > begin
> > >         if (~resetb) begin
> > >                 datain <= 0;
> > >                 leftdata <= 0;
> > >                 rightdata <= 0;
> > >         end
> > >         else begin
> > >                 if (sclkRise == 1) begin
> > >                         datain[63:1] <= datain[62:0];
> > >                         datain[0] <= sdata;
> > >                 end
> > >                 if (lrclkRise == 1) begin
> > >                         leftdata <= datain[63:40];
> > >                         rightdata <= datain[31:8];
> > >                 end
> > >         end
> > > end
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

"Dave" <gretzteam@hotmail.com> wrote in message
news:yt2dnW1FjtkfzsLcRVn-jg@comcast.com...
> Ok I understand...but isn't it better to have a reset for all our flip
flop?
> If something goes wrong - or when I press the reset button...- the
> controller can always reset everything to zero before we start again...
>
> Thanks,
> David

If something goes wrong - or when you press the reset button...- would you
be willing to wait for the FPGA to reprogram itself?  If you design the
system to boot the FPGA from a PROM or reprogram it from the processor, the
"clean" state would be guaranteed after the system reset and would allow
proper "initialization" or SRL and BlockRAM contents.  The async resets are
more a leftover from ASIC designs than a sincere need for FPGAs.

(In a discussion about reset and SRL16)

Ray Andraka wrote:

> Depends on your design and what you are willing to settle for.  Technically
> speaking, all you really need to do is provide a way of clearing stuff in your
> design tht is inside hardware loops.  For example, a state machine or an IIR
> filter have a 'loop' that needs to be broken in order to bring the hardware to a
> known state.  In many cases, it is perfectly acceptable to clear only key points
> in the design, and sometimes even require the reset be asserted for some minimum
> number of clock cycles to achieve a known state.  Yes, the easy methodology is
> to reset every flip-flop, but it is not necessary and can cost you dearly in
> terms of both gates and reset signal fan out (and therefore delay).

I believe it is important for testing purposes that a known state be
reached with a known combination of reset, clocks, and other signals.

It might be that a design would work perfectly well in any of the
possible reset states, but it wouldn't be testable.

Well, that is mostly for ASICs where test vectors need to be
supplied to the fab.  For FPGAs it might not be necessary,
though test vector sets are nice to have.

-- glen

But Glen, you can get the whole circuit to a known state by just using strategically
placed resets.  Take a simple example of a pipeline that has an accumulator in it.
All that needs to be reset is the registers at the pipeline input (these should be
held at a know value for some known number of clocks), and a reset on the accumulator,
which is needed to clear out the history stored in the accumulator (it won't self
clear regardless of the data coming in because of the feedback loop).  If your
pipeline is say 10 clocks long, then holding the reset to the input registers and
accumulator for 10 clock cycles will get the entire circuit to a known state without
having to reset every flip-flop.  You can take it a step further by also resetting the
output register and using some delays for the resets so that the operation as viewed
from outside is indistinguishable from a synchronous reset.  In that case, the input
register is cleared as long as reset is held.  The reset signal is delayed in a shift
register matching the length of the pipeline and tapped where needed to break loops,
and the reset for the output register is handled with a set-reset flip-flop that is
set by the reset input and reset by the delayed reset as the first valid input after
the reset is released reaches the pipeline output.

My point is that you do not have to reset every single flip-flop in the design to
reach a known state as long as you are willing to take a known number of clock cycles
to reach that state.



glen herrmannsfeldt wrote:

> (I believe it is important for testing purposes that a known state be
> reached with a known combination of reset, clocks, and other signals.
>
> It might be that a design would work perfectly well in any of the
> possible reset states, but it wouldn't be testable.
>
> Well, that is mostly for ASICs where test vectors need to be
> supplied to the fab.  For FPGAs it might not be necessary,
> though test vector sets are nice to have.
>
> -- glen

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Ray Andraka wrote:

> But Glen, you can get the whole circuit to a 
 > known state by just using strategically
> placed resets.  Take a simple example of a pipeline
 >  that has an accumulator in it.
> All that needs to be reset is the registers 
 > at the pipeline input (these should be
> held at a know value for some known number of 
 > clocks), and a reset on the accumulator,
> which is needed to clear out the history 
 > stored in the accumulator (it won't self
> clear regardless of the data coming in 
 > because of the feedback loop).

(snip)

> My point is that you do not have to reset 
 > every single flip-flop in the design to
> reach a known state as long as you are willing
 >  to take a known number of clock cycles
> to reach that state.

Yes.  That is included in what I wrote as a
known combination of reset and clocks.

It gets more complicated if you have memory
elements other than pipelines, such as registers
in a CPU.  While the processor might work just fine
with them in a random initial state, testing might
not.   All these things have to be considered at
design time.  It might be that they don't add much
logic, but they do add to the time it takes to
verify the design.


After I wrote:

>>(I believe it is important for testing purposes 
 >> that a known state be reached with a known combination
 > of reset, clocks, and other signals.

-- glen