Async and sync resets

Hi all,

Just over two years ago, Allan Herriman posted about having synchronous AND asynchronous resets in Xilinx FPGAs.

formatting link

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

Reply to
Hamish Moffatt
Loading thread data ...

formatting link

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

Reply to
Mike Treseler

formatting link

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
 Click to see the full signature
Reply to
rickman

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

Reply to
Brian Davis

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

Reply to
Hamish Moffatt

formatting link

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
 Click to see the full signature
Reply to
Hamish Moffatt

One that comes in on a device pin.

I agree.

-- Mike Treseler

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

Reply to
Hamish Moffatt

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

Reply to
mike_treseler

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

Reply to
Brian Davis

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
 Click to see the full signature
Reply to
Hamish Moffatt

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

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

Reply to
Hamish Moffatt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.