Async and sync resets

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

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.

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.

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

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

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

One that comes in on a device pin.

I agree.

-- Mike Treseler

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

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 '0'); elsif rising_edge(clk) then if sync_reset = '1' then -- where needed dout '0'); else dout

That's the one...

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

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

Hamish

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

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