Async and sync resets

Hi all,

Just over two years ago, Allan Herriman posted about having synchronous 
AND asynchronous resets in Xilinx FPGAs.
http://groups.google.com/groups?hl=en&lr=&threadm=3dc210cc.14049401%40netnews.agilent.com&rnum=11&prev=/groups%3Fq%3Dsynchronous%2Breset%2Bstartup%2Bgroup:comp.arch.fpga%26hl%3Den%26lr%3D%26start%3D10%26sa%3DN

This should be possible if you use the STARTUP block, because that 
provides the async reset, leaving each flop's reset input free for the 
synchronous reset. The following code should work (+ STARTUP block);

     p: process (gsr, clk)
     begin
         if gsr = '1' then
             dout <= (others => '0');
         elsif rising_edge(clk) then
             if sync_reset = '1' then
                 dout <= (others => '0');
             else
                 dout <= din;
             end if;
         end if;
     end process;

However, it doesn't do the right thing in Synplify (7.7 etc). The 
resulting netlist has FD components, which don't use the reset input at 
all. It should generate FDR components instead. Judging by the RTL and 
technology views, the compiler has already moved the sync reset to the D 
input, so the mapper has no chance once it realises the reset input is 
free. In the 2002 thread, Ken McElvain said it should work but 
unfortunately, it still doesn't.

So, has anyone found any new workarounds since then?

I'm also open to others ideas. I don't actually need to async reset most 
of the design, but it's handy for simulation. I'm aware of Ken Chapman's 
techXclusives article about this; however it's a big change in 
methodology and I'm not the only designer working on this code.

Some other experiments I tried:

1. Instantiate an ROC component to provide the correct simulation 
behaviour, and hope that Synplify realises what it does, removes the 
reset net but preserves the initial values (which may not all be zero). 
Unfortunately, it doesn't realise that ROC is anything but a blackbox; 
Xilinx MAP will rip it out, but I still won't have FDRs.

2. Don't connect the async reset during synth (translate_on/off etc). 
This doesn't preserve the initial values though. In one case, we saw 
Synplify generate an illegal value for a one-hot encoded enumerated 
type, meaning an FSM would start in an illegal state (ouch!).

One known solution for synth is instantiating the FDRs manually, but 
then you don't get async resets in simulation. Also this is ugly.

thanks,
Hamish
-- 
Hamish Moffatt
R&D Engineer
Data Networks Division
Agilent Technologies

Hamish Moffatt wrote:

> Just over two years ago, Allan Herriman posted about having synchronous 
> AND asynchronous resets in Xilinx FPGAs.
> http://groups.google.com/groups?hl=en&lr=&threadm=3dc210cc.14049401%40netnews.agilent.com&rnum=11&prev=/groups%3Fq%3Dsynchronous%2Breset%2Bstartup%2Bgroup:comp.arch.fpga%26hl%3Den%26lr%3D%26start%3D10%26sa%3DN 

> 
> So, has anyone found any new workarounds since then?

I still like Alan Fitch's recomendation in the thread above.
Don't use the gsr.

A real reset signal allows for clean, portable code
for synthesis and simulation.

        -- Mike Treseler

Mike Treseler wrote:
> 
> Hamish Moffatt wrote:
> 
> > Just over two years ago, Allan Herriman posted about having synchronous
> > AND asynchronous resets in Xilinx FPGAs.
> > http://groups.google.com/groups?hl=en&lr=&threadm=3dc210cc.14049401%40netnews.agilent.com&rnum=11&prev=/groups%3Fq%3Dsynchronous%2Breset%2Bstartup%2Bgroup:comp.arch.fpga%26hl%3Den%26lr%3D%26start%3D10%26sa%3DN
> 
> >
> > So, has anyone found any new workarounds since then?
> 
> I still like Alan Fitch's recomendation in the thread above.
> Don't use the gsr.
> 
> A real reset signal allows for clean, portable code
> for synthesis and simulation.

What exactly is a "real" reset signal?  There are times when you *need*
an async reset, such as handling a failed clock situation or making sure
a circuit is put into a known good state with a minimum delay (for
safety or to prevent damage to equipment) when you are running with a
slow clock.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Hamish Moffatt wrote:
> 
> So, has anyone found any new workarounds since then?
> 
 I helped someone chase down that same problem with the
then-current Synplify (7.x???) about a year ago; IIRC,
the closest thing to a workaround was to delete the async
portion of the "IF" and use an initialized signal instead. 

 This generated more compact hardware that synthesizes and
simulates identically, but lacks an explicit async reset
signal to tug during sim.

 I don't have Synplify at hand to confirm this, so my recall
may be a bit fuzzy. BTW, XST also supports using initialized
signals to specify post-config register states.

>
>One known solution for synth is instantiating the FDRs
>manually, but then you don't get async resets in simulation.
>
 That hardcoded internal-to-the-model-with-no-outside-control
initialization in the UNISIM library has always baffled me;
occasionally enough so to hack up the primitive models that
I'm using to add a proper GSR input instead.

 ( Also, if you look closely at the Synplify RTL viewer for
the version of your code with the STARTUP block, I believe
you'll see that Synplify uses its' own special post-synth
simulation models of the FFs which include a GSR input )

Brian

Brian Davis wrote:
> Hamish Moffatt wrote:
>>So, has anyone found any new workarounds since then?
>  I helped someone chase down that same problem with the
> then-current Synplify (7.x???) about a year ago; IIRC,
> the closest thing to a workaround was to delete the async
> portion of the "IF" and use an initialized signal instead. 
> 
>  This generated more compact hardware that synthesizes and
> simulates identically, but lacks an explicit async reset
> signal to tug during sim.
> 
>  I don't have Synplify at hand to confirm this, so my recall
> may be a bit fuzzy. BTW, XST also supports using initialized
> signals to specify post-config register states.

Do you mean initialised as in

signal x: std_logic_vector(7 downto 0) := (others => '1');

or

attribute INIT of x: signal is "00000000";

I tried the former and couldn't see any sign of Synplify using the 
initial value.

     signal sa_int: std_logic_vector(7 downto 0) := (others => '1');

     p2a: process (clk)
     begin
         if rising_edge(clk) then
             sa_int <= din;
         end if;
     end process;


So I've found that leaving the async reset input disconnected at synth 
time (except to the STARTUP block) definitely helps with sync resets, 
but for anything without sync resets, initial values are lost.

You could argue that anything that depends on a preset value should have 
sync resets anyway, but that's not something I can change quickly in a 
few hundred thousand lines of code...


thanks
Hamish
-- 
Hamish Moffatt
R&D Engineer
Data Networks Division
Agilent Technologies
+61 3 9210 5782 (T210 5782) Tel

Mike Treseler wrote:
> Hamish Moffatt wrote:
> 
>> Just over two years ago, Allan Herriman posted about having 
>> synchronous AND asynchronous resets in Xilinx FPGAs.
>> http://groups.google.com/groups?hl=en&lr=&threadm=3dc210cc.14049401%40netnews.agilent.com&rnum=11&prev=/groups%3Fq%3Dsynchronous%2Breset%2Bstartup%2Bgroup:comp.arch.fpga%26hl%3Den%26lr%3D%26start%3D10%26sa%3DN 
> 
> 
> 
>>
>> So, has anyone found any new workarounds since then?
> 
> 
> I still like Alan Fitch's recomendation in the thread above.
> Don't use the gsr.
> 
> A real reset signal allows for clean, portable code
> for synthesis and simulation.

True, but that isn't an easy thing to change when you have a huge 
library of existing code. I'm only asking for the synthesis tool to 
produce an optimal and correct result!

Hamish
-- 
Hamish Moffatt
R&D Engineer
Data Networks Division
Agilent Technologies
+61 3 9210 5782 (T210 5782) Tel

rickman wrote:

> What exactly is a "real" reset signal? 

One that comes in on a device pin.

> There are times when you *need*
> an async reset, such as handling a failed clock situation or making sure
> a circuit is put into a known good state with a minimum delay (for
> safety or to prevent damage to equipment) when you are running with a
> slow clock.  

I agree.

       -- Mike Treseler

Mike Treseler wrote:
> rickman wrote:
> 
>> What exactly is a "real" reset signal? 
> 
> 
> One that comes in on a device pin.

I have a reset signal on a device pin. I connected it to the startup 
block. That's as far as I care about asynchronous resets. I want my 
logic to use the free reset inputs on the flip-flops for synchronous 
sets or resets. Synplify 7.7.1 won't do it. XST won't do it.

I tried removing my async reset today. Synth time dropped by 50%. 
Resource usage dropped by ~5%. It looked like it would've routed much 
better. (I didn't bother because the result was actually wrong - the 
initial values weren't preserved.) I want this benefit, but it seems 
that nobody is doing it.


Hamish

Hamish Moffatt wrote:

> I have a reset signal on a device pin. 
> I connected it to the startup block.

What happens if you ignore the startup block
and just modify the process template to
use that reset signal like this

    p: process (reset, clk)
     begin
         if reset = '1' then
             dout <= (others => '0');
         elsif rising_edge(clk) then
             if sync_reset = '1' then  -- where needed
                 dout <= (others => '0');
             else
                 dout <= din;
             end if;
         end if;
     end process;

That ought to synth and route fine and even
sim the same as before.

       -- Mike Treseler

Hamish Moffatt wrote:
>
> Do you mean initialised as in
>   signal x: std_logic_vector(7 downto 0) := (others => '1');
> 
 That's the one...

> 
> I tried the former and couldn't see any sign of Synplify
> using the initial value.
>
 I'll rummage around and see if I can find/recreate a test case
from the last time I worked on this in Synplify.

 I've definitely coded initialized registers that way using XST,
which builds the desired single FF implementation, having say
both an INIT1 and a sync clear as seen in fpga_editor.

Brian