Reset Sync style

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

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.

See my synthesis benchmarks of 3 templates in the reference design here:
http://home.comcast.net/~mike_treseler/

-- 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

Rick North

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

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.

> Usually my main
> would be the largest part of my code with processed and instances. This
> way tips it all upside down. Real nice!

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) ?

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

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) ?

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" <> 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.
>

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

--

TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

Martin Thompson

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...

jpdullius@gmail.com

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%)

Rick North

Thanks to Martin and Rick for the synthesis benchmarks.
I'll update the comments with these results.

-- Mike Treseler

Mike Treseler