Async and sync resets

mike_treseler wrote:
> 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.

Err.. That's functionally correct, but how does it help to get Synplify 
to use the reset inputs for synchronous reset?

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

Hamish Moffatt wrote:

> Err.. That's functionally correct, but how does it help to get Synplify 
> to use the reset inputs for synchronous reset?

It doesn't.

My point was to demonstrate a way to
integrate an external asynchronous reset
with your existing code in a vendor portable way.

Is this a question of a design not fitting
or unease about wasting gates?

       -- Mike Treseler

Mike Treseler wrote:
> Hamish Moffatt wrote:
> 
>> Err.. That's functionally correct, but how does it help to get 
>> Synplify to use the reset inputs for synchronous reset?
> 
> 
> It doesn't.
> 
> My point was to demonstrate a way to
> integrate an external asynchronous reset
> with your existing code in a vendor portable way.
> 
> Is this a question of a design not fitting
> or unease about wasting gates?

It's suspected wasted gates leading to (a) poor placement, and (b) more 
logic levels than necessary, and therefore difficulty meeting timing.

I'm running 200 MHz (+ jitter) in a 2V6000-6 so I don't have many 
picoseconds to waste. That along with a very wide data bus is making 
placement rather touchy.

Hamish