Reset Sync style

R

Rick North

Guest
Hi all,

For a FPGA design, I have been told that the way to stay away from harm
is to implement the reset synchronously. In this way the reset signal
will be taken in consideration for timing analysis.

I have seen two ways of obtaining a synchron reset 1) and 2) below. The
argument for 2) is that it will take less resource than 1). The only
way I 'think' it will be true is for variables, which will result in
combatorial nets. The nets would get a reset net as well but since it
normally is placed between FF1-comb-FF2 the comb output is determined
by FF1.

Did some initial test Synth-P&R but did not see any big difference
which was as I initially thought.

What does your expertise say about 1) and 2) template? Is there a
benefit of using 2) over 1)? This might be a "should I use Altera or
Xilinx" question but I will stick my neck out anyway.

Cheers,
/Rick

-----------------------------------------------------------------------
1)
P_Foo: process (clk) is
begin -- process P_Foo
if clk'event and clk = '1' then -- rising clock edge
if reset = '1' then -- synchronous reset
(active high)
-- reset variable, signal
else
-- set signals and assign variables
end if;
end if;
end process P_Foo;

2)
P_Foo: process (clk) is
begin -- process P_Foo
if clk'event and clk = '1' then -- rising clock edge
-- set signals and assign variables
if reset = '1' then -- synchronous reset
(active high)
-- reset variable, signal
end if;
end if;
end process P_Foo;
 
Rick North wrote:

For a FPGA design, I have been told that the way to stay away from harm
is to implement the reset synchronously. In this way the reset signal
will be taken in consideration for timing analysis.
Click to expand...
See my synthesis benchmarks of 3 templates in the reference design here:
http://home.comcast.net/~mike_treseler/

-- Mike Treseler
 
Odd style, but refreshing to read. Haven't seen any similar piece of
code to your UART example. I think I need to test this. Usually my main
would be the largest part of my code with processed and instances. This
way tips it all upside down. Real nice!

But, you have two asynchron reset example and the synchron example is
the same as template 1) in my post. Do you have any opinion on the two
template 1) and 2) ?

/rick
 
Odd style, but refreshing to read. Haven't seen any similar piece of
code to your UART example. I think I need to test this. Usually my main
would be the largest part of my code with processed and instances. This
way tips it all upside down. Real nice!

But, you have two asynchron reset example and the synchron example is
the same as template 1) in my post. Do you have any opinion on the two
template 1) and 2) ?

/rick
 
Rick North wrote:
Odd style, but refreshing to read. Haven't seen any similar piece of
code to your UART example. I think I need to test this.
Click to expand...
Please post the results.
test_uart has been verified using
modelsim and ncsim 05.10 or newer.

uart has been synthesized without error
for leonardo and quartus.
If anyone has access to precision, synplicity or synopsis,
please give it a quick spin.

Usually my main
would be the largest part of my code with processed and instances. This
way tips it all upside down. Real nice!
Click to expand...
Thanks.
Tradition prefers a netlist of many processes and signals.
I like a process of many variables and procedures,
with the "think-hardware" part covered by the template.
But, you have two asynchron reset example and the synchron example is
the same as template 1) in my post. Do you have any opinion on the two
template 1) and 2) ?
Click to expand...
You can read my comments at the end of the uart file.
For brand X and A FPGAs the s_rst template is much slower than the
other two. I now use the v_rst style for new designs.

-- Mike Treseler
 
But, you have two asynchron reset example and the synchron example is
the same as template 1) in my post. Do you have any opinion on the two
template 1) and 2) ?
Click to expand...
Sorry. I missed the difference in your templates.
On first reading it looks to me like
your template 2 is logically equivalent to 1
as long as the reset clause always happens last.
Template 2 wastes some simulation cycles during
reset since the non-reset code always executes.


-- Mike Treseler
 
"Mike Treseler" <mike_treseler@comcast.net> writes:

Rick North wrote:
Odd style, but refreshing to read. Haven't seen any similar piece of
code to your UART example. I think I need to test this.

Please post the results.
test_uart has been verified using
modelsim and ncsim 05.10 or newer.

uart has been synthesized without error
for leonardo and quartus.
If anyone has access to precision, synplicity or synopsis,
please give it a quick spin.
Click to expand...
OK, I did this, while waiting for something else to finish :) Seems
to go through Synplify 8.0 (Pro if it matters) fine - haven't taken it
on to PAR.

template 0,2:
94 LUTS, 216 MHz in a xc3s50tq144-4
template 2:
76 LUTS, 171MHz in a xc3s50tq144-4

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt
 
Well, from my hardware implementation experience, using Xilinx ISE
(always the updated version, now it is the 8.1i), at least Xilinx ISE
would do the following with your code:

1)

P_Foo: process (clk) is
begin -- process P_Foo
if clk'event and clk = '1' then -- rising clock edge
if reset = '1' then -- synchronous reset
(active high)
-- reset variable, signal
else
-- set signals and assign variables
end if;
end if;
end process P_Foo;

All the signals in " -- set signals and assign variables" would have
in their clock enable logic the "reset" signal. Even those signals are
not actually reseted would have the reset in their clock enable
logic... I don´t really like that. I prefer what it does in 2)



2)
P_Foo: process (clk) is
begin -- process P_Foo
if clk'event and clk = '1' then -- rising clock edge
-- set signals and assign variables
if reset = '1' then -- synchronous reset
(active high)
-- reset variable, signal
end if;
end if;
end process P_Foo;

In this approach, Xilinx ISE would use the "reset" signal on clock
enable or reset pins of only those signals that are reseted on " --
reset variable, signal".
Those signals that appears only on " -- set signals and assign
variables" and not "-- reset variable, signal" won´t have the "reset"
signal on their logic.
For me, it makes much more sense...
 
Ok... here is the result.

Synplify Pro 8.4
Fanout guide 10000
Pipelining
Retiming
Reasurce Sharing
¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
template_c : natural := 2; -- 0=a_rst, 1=s_rst, others=>v_rst

Requested Estimated Requested Estimated
Clock Clock
Starting Clock Frequency Frequency Period Period
Slack Type Group
------------------------------------------------------------------------------------------------------------------------
uart|clock 479.8 MHz 407.8 MHz 2.084 2.452
-0.368 inferred Autoconstr_clkgroup_0
=======================================================================================================================



Resource Usage Report for uart

Mapping to part: xc4vlx15sf363-12
Cell usage:
FDC 33 uses
FDCE 52 uses
FDP 6 uses
FDPE 2 uses
MUXF5 3 uses
MUXF6 1 use
LUT2 20 uses
LUT3 29 uses
LUT4 77 uses

I/O primitives: 22
IBUF 13 uses
OBUF 9 uses

BUFGP 1 use

I/O Register bits: 1
Register bits not including I/Os: 92 (0%)

Global Clock Buffers: 1 of 32 (3%)


Mapping Summary:
Total LUTs: 126 (1%)

¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
template_c : natural := 0; -- 0=a_rst, 1=s_rst, others=>v_rst

Worst slack in design: -0.368

Requested Estimated Requested Estimated
Clock Clock
Starting Clock Frequency Frequency Period Period
Slack Type Group
------------------------------------------------------------------------------------------------------------------------
uart|clock 479.8 MHz 407.8 MHz 2.084 2.452
-0.368 inferred Autoconstr_clkgroup_0
=======================================================================================================================
Mapping to part: xc4vlx15sf363-12
Cell usage:
FDC 33 uses
FDCE 52 uses
FDP 6 uses
FDPE 2 uses
MUXF5 3 uses
MUXF6 1 use
LUT2 20 uses
LUT3 29 uses
LUT4 77 uses

I/O primitives: 22
IBUF 13 uses
OBUF 9 uses

BUFGP 1 use

I/O Register bits: 1
Register bits not including I/Os: 92 (0%)

Global Clock Buffers: 1 of 32 (3%)


Mapping Summary:
Total LUTs: 126 (1%)

¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
template_c : natural := 1; -- 0=a_rst, 1=s_rst, others=>v_rst
Worst slack in design: -0.420

Requested Estimated Requested Estimated
Clock Clock
Starting Clock Frequency Frequency Period Period
Slack Type Group
------------------------------------------------------------------------------------------------------------------------
uart|clock 420.4 MHz 357.3 MHz 2.379 2.799
-0.420 inferred Autoconstr_clkgroup_0
=======================================================================================================================

Mapping to part: xc4vlx15sf363-12
Cell usage:
FD 1 use
FDR 63 uses
FDRE 45 uses
FDS 5 uses
FDSE 2 uses
MUXF5 2 uses
MUXF6 1 use
LUT1 1 use
LUT2 14 uses
LUT3 46 uses
LUT4 42 uses

I/O primitives: 22
IBUF 13 uses
OBUF 9 uses

BUFGP 1 use

I/O Register bits: 1
Register bits not including I/Os: 115 (0%)

Global Clock Buffers: 1 of 32 (3%)


Mapping Summary:
Total LUTs: 103 (0%)
 
Thanks to Martin and Rick for the synthesis benchmarks.
I'll update the comments with these results.

-- Mike Treseler
 
I like this reply. Is this ISE specific?

If I would have a async reset and omitts a reset value for a signal or
a variable Synplify will light up a warning which says "feedback mux
created for s_Foo". Should I not expect to see the same in the sync
reset case?

P_Foo: process (clk, reset) is
variable v_foo : std_logic;
begin -- process P_Foo
if reset = '1' then
s_Foo <= '1'; -- if omitted s_Foo would create a feedback mux.
v_Foo := '1';
elsif clk'event and clk = '1' then -- rising clock edge
v_Foo := s_a or s_b; -- s_a and s_b are port signals
s_Foo <= v_Foo and s_c; -- s_c is a port signal
end if;
end process P_Foo;

would it not create a feeback mux in this case`?
P_Foo: process (clk) is
variable v_foo : std_logic;
begin -- process P_Foo
if clk'event and clk = '1' then -- rising clock edge
v_Foo := s_a or s_b; -- s_a and s_b are port signals
s_Foo <= v_Foo and s_c; -- s_c is a port signal
if reset = '1' then
s_Foo <= '1'; -- s_Foo would it not create a feedback mux if
omitted.
v_Foo := '1';
end if;
end if;
end process P_Foo;

/Rick
 
Mike Treseler wrote:
Thanks to Martin and Rick for the synthesis benchmarks.
I'll update the comments with these results.
Click to expand...
Done. See end of testbench here:
http://home.comcast.net/~mike_treseler/

-- Mike Treseler

-------------------------------------------------------------------------------
-- Synthesis Performance for default constraints Thu Jan 26 15:52:21 2006
-------------------------------------------------------------------------------
-- template_a_rst;
-------------------------------------------------------------------------------
-- Quartus 5.1 356 MHz 52 FF 72 ALUT eps15sf484c3
-- Synplify Pro 8.4 408 MHz 93 FF 126 LUTS xc4vlx15sf363-12
by Rick North
-- Synplify Pro 8.0 216 MHz 94 LUTS xc3s50tq144-4
by Martin Thompson
-------------------------------------------------------------------------------
-- template_s_rst;
-------------------------------------------------------------------------------

-- Quartus 5.1 317 MHz 50 FF 80 ALUT eps15sf484c3
-- Synplify Pro 8.4 357 MHz 108 FF 126 LUTS xc4vlx15sf363-12
retime R.North
-- Synplify Pro 8.0 171 MHz 76 LUTS xc3s50tq144-4
by Martin Thompson
-------------------------------------------------------------------------------
-- template_v_rst;
-------------------------------------------------------------------------------

-- Quartus 5.1 356 MHz 52 FF 72 ALUT eps15sf484c3
-- Leo 2005b.24 est 194 MHz 48 FF 62 ALUT
-- Synplify Pro 8.4 408 MHz 93 FF 126 LUTS xc4vlx15sf363-12
retime R.North
-- Synplify Pro 8.0 216 MHz 94 LUTS xc3s50tq144-4
by Martin Thompson
-------------------------------------------------------------------------------
 
Mike Treseler wrote:

Thanks to Martin and Rick for the synthesis benchmarks.
I'll update the comments with these results.
Done. See end of testbench here:
Sorry, that's end of reference design source here:
Click to expand...

http://home.comcast.net/~mike_treseler/

-- Mike Treseler
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top