01-15-2020 11:07 PM
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;
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!
01-15-2020 11:53 PM
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...
01-16-2020 01:06 AM - edited 01-16-2020 01:08 AM
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.
01-16-2020 03:30 AM
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.
01-16-2020 05:47 AM - edited 01-16-2020 05:52 AM
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:
Are you saying that control sets or routing are more critical?
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.
01-16-2020 09:28 AM
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.
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
01-23-2020 03:39 AM
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.