cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
spajas
Visitor
Visitor
1,017 Views
Registered: ‎08-20-2018

[VHDL] Reset at top or bottom of process

At our company we are use the following way of implementing resets:

 

process(CLK)
begin
    if rising_edge(CLK) then
        if RST = '1' then
        ....
        else
        ....< Here all logic would have a (shared) Clock Enable (CE) signal >
        end if;
    end if;
end process;

This works fine but there are some discussions about the location of the 'RST' in the process. Partially because it seems inefficient - all logic in the 'else'-clause have a clock enable; we use 512-bits (100G MAC) data-busses and all might have a CE-signal -, partially because it becomes more inreadable due to the extra indentation. There is also a blog-post about this: http://olofkindgren.blogspot.com/2017/11/resetting-reset-handling.html

 

So we tried it and rewrote our IP with the 'RST' at the bottom of the process:

process(CLK)
begin
    if rising_edge(CLK) then
        ....
        ....
        if RST = '1' then
        ....
        end if;
    end if;
end process;

We compared both implementations and observed the following (compared to the RST at the top of process):

* The number of control-sets went up a bit which is explainable

* CE FF went down a lot (explainable)

* Power usage went up from 12.x to 13.x watt (around 1 watt; which is explainable)

* CLB LUTs went up a bit (which is explainable)

* CLB Registers went down a bit

 

So for us, in the current situation, it is 'give and take'. We don't see any (big) gains to go to the 'RST at bottom' but also no real downsides.

So what I would like to know: What is the best way? What do you recommend and why? What would be recommended for future development?

Note: We use an UltraScale+ (VUP13+).

 

Thanks in advance!

0 Kudos
Reply
6 Replies
drjohnsmith
Teacher
Teacher
1,003 Views
Registered: ‎07-09-2009

Ah resets in FPGA's

yet another twist on the topic.

Re your imediate question, in FPGAs , control sets are a limiting factor of the packing into CLB's.

    so IMHO, anyhting that worsens that, is not a good stratergy for FPGAs.

 

On the note of resets in general. 

   Again in FPGAs the need for ereset is a lot less than in ASICs, 

         The more you have reseting, the more terms are needed, the more power and less chance of meeting timming,

            In FPGAs at start up, all registers and BRAMs are in a (user) defined state, unlike ASICS. 

               So again , IMHO, anything that adds to power and complexity is not a good thing,  so minimise resets.

         typiclay you could save 25 % of your design by doign so...

https://www.xilinx.com/support/documentation/white_papers/wp275.pdf

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply
richardhead
Scholar
Scholar
984 Views
Registered: ‎08-01-2012

@spajas 

Your assertion is incorrect that in the first code all logic has a shared clock enable. Logic only has a clock enable IF it is not reset - the reset will be connected to the clock enable instead of reset.

There is an issue with this - you are now creating a timing relationship between two flip-flops you may not have intended. Eg:

process(clk)
begin
  if rising_edge(clk) then
    if rst then
      a <= '0';
    else
      a <= ip1;
      b <= ip2;
    end if;
end process;

Here, both flops have a connection to reset - flop A has the reset connected to the srst input, while flop B has rst connected to clk enable. This is not neccessarily obvious from the code and maintains a timing relationship between rst and B. If you use the following code, only flop A has a connection to reset:

process(clk)
begin
  if rising_edge(clk) then
    b <= ip2;
    a <= ip1;

    if rst then
      a <= '0';
    end if;
  end if;
end process;

B no longer has a connection to rst, and no timing relationship exists, reducing routing usage, and lowering the fanout on rst, but potentially increasing control sets.

While A is the style most engineers use, it is very easy to unintentionally connect the rst to CE pins on flops when engineers add code in the else branch but forget to add a reset. Usually, connecting a reset to a CE pin would be a design error.

You can find these by running a timing report:

report_timing -from rst -to */CE

Xilinx recommend only resetting flops if absolutely neccessary - data path registers usually dont need a reset. This reduces routing and large fanouts, which is usually more of a problem than control sets.

If you insist on sticking with the first style, then you either have to regularly check your code for accidental connections to CE, or have separate processes for flops with reset and flops without.

The second style is the one I use, after we have had lots of rst -> CE connections creep in over the years.

apetley
Xilinx Employee
Xilinx Employee
949 Views
Registered: ‎06-14-2018

To add,

More no of control sets will affect placement leaving slice flops partially empty. Tool can reduce that by moving control signals onto D path (using attributes) however that will add LUT. If LUT exists it will increase its size. So in short unless needed more control sets are not very good idea.

Thanks,

Ajay

richardhead
Scholar
Scholar
923 Views
Registered: ‎08-01-2012

@apetley 

While this may be true, in our current design we have several thousand control sets, but its actually routing that is being starved. (currently about 80-90% lut and ram usage)

While its old, Xilinx always recommended not using reset unless neccessary:

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

Are you saying that control sets or routing are more critical?

@spajas 

Note there is also the EXTRACT_RESET synthesis attribute that allows you to force a reset into the LUT logic rather than the srst of the flop, basically giving you an emulated srst and reducing control sets.

0 Kudos
Reply
apetley
Xilinx Employee
Xilinx Employee
889 Views
Registered: ‎06-14-2018

Hi @richardhead ,

You are right with control set being more in design along with placement, routing too gets affected.

Even now Ultrascale CLB guide recommends to have lesser unique control sets.

UG 574:

Control inputs are shared across multiple resources in a CLB. Minimize the number of
unique control inputs required for a design. Control inputs include clock, clock enable,
set/reset, and write enable

Thanks,

Ajay 

0 Kudos
Reply
spajas
Visitor
Visitor
783 Views
Registered: ‎08-20-2018

Thanks all! After internal discussion, we decided to keep the reset at the top, reducing control sets (and saves the hassle/risk of moving them to the bottom).

This topic can be closed.