Xilinx Best Source for Reset

Up to now, I have been doing much of my work with ModelSim and a BMP file reader and writer. Most of my VHDL designs have clk and reset. I know where to attach the clk but what do I use for reset. An external pin? The Done pin? Or a DCM lock signal?

Brad Smallridge b r a d @ a i v i s i o n . c o m

Reply to
Brad Smallridge
Loading thread data ...

I drive reset from a cpu running on the fpga clock. Pulse it after the binary image is loaded. This is vendor independent and synchronous.

-- Mike Treseler

Reply to
Mike Treseler

Is this an asynchronous (power-on) reset you are talking about? In that case, for Xilinx parts, instantiate a ROC component:

component roc port ( O : out std_logic ); end component;

begin

-- model of the Xilinx POR roc_e: roc port map( O => RESET );

The model for the ROC is in the Xilinx unisim library. The Xilinx tools know to assign the RESET net to the internal POR structure. You don't need to connect it to any pins.

Reply to
Duane Clark

Brad,

There are two types of reset. One, hardware reset, is typically sourced by an external pin. Two, software reset, is typically sourced by a bit written by CPU & any other host controller. It all depends on what you are up to.

Sometimes, you might want to reset parts of the design upon some synchronization reached or something like this.

Vladislav

Reply to
Vladislav Muravin

Mike,

Do you then code that reset signal using the normal asynchronous reset at the start of a clocked process model, or do you code it as a synchronous reset?

Or do you treat it on a case by case basis?

Nial.

Reply to
Nial Stewart

I use the asynchronous reset template. As others have noted, this saves gates.

Here is a benchmark of three templates on the same design:

formatting link

-- Mike Treseler

Reply to
Mike Treseler

Wow, that's an interesting use of procedures to automatically restructure a program.

I brought the question of async vs. sync reset to the group awhile ago, and someone told me (they should harp in here to get credit), that with an async reset you may have metastable issues when your reset goes inactive, which sort of defeats the purpose of having a reset. So this sold me on sync resets, end of story.

When does a CPU know when to reset the FPGA? PowerUp timing delay? I am using a Cypress USB chip which has some interesting PowerUp ennumeration and renumeration issues if anyone has any experience with this sort of thing.

Brad

Reply to
Brad Smallridge

Actually this is a false compromise. There is a perfectly safe way of synchronizing the reset to your local c*ck(s) so that there is no chance of metastability regardless of the reset release time. This way you can continue to use async resets.

Reply to
m

If you generate a synchronous reset signal then connect that to the asynch reset input of the registers in your design, can you be sure that the tools include this path in the timing analysis?

It be a reasonable assumption of those designing the timing analysis tools that anything going to an asynchronous input doesn't need to be included.

Could you be caught out doing this?

BTW, I'm playing devil's advocate here as I've been using this technique myself for a while, I'm just checking it's as bulletproof as I assumed it was.

Nial.

Reply to
Nial Stewart

nooooo, you really don't want to do that at all. Jolly painful.

See the recent thread "Bulletproofing CPLD Design" on comp.lang.vhdl for further suggestions from me and others on this issue.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
 Click to see the full signature
Reply to
Jonathan Bromley

Jonathan, I hope you're not being rude ;-)

To recap, Jonathan suggests.....

- Datapaths, configuration registers etc have simple asynch reset.

- Sequence-control state machines have asynch reset, but also have synchronous reset signal that holds them in their idle state.

- Arrange one small dedicated piece of logic that is reset by asynch reset, and holds the synch reset signal active for two clocks after asynch reset has been released.

Now, your sequence controllers will remain in their idle state for two clocks after the end of asynch reset. While they are in the idle state, no other activity will run in the other parts of the design. Consequently, it doesn't matter what happens to the other flip-flops immediately after the end of asynch reset. But the synchronous reset is applied only to a small part of the design (the sequence control FSMs) so it consumes very little extra logic.

Which is similar to the approach I take, except often the synchronous reset can also be triggered by an SBC/CPU or whatever to get the FPGA to a known state.

The question still remains...

"If you drive flip-flop asynchronous reset inputs from a synchronous source, are the tools intelligent enough to include these paths and the flip-flop reset mechanism in the timing analysis"?

If so then the extra synchronous reset logic could also be dispensed with.

Anybody from Altera/Xilinx want to comment?

Nial.

Reply to
Nial Stewart

Hmm. I have to admit that I didn't think of this. So you can register your reset at the IO pin and then have that synced output drive the internal global reset? Is that right?

Reply to
Brad Smallridge

I like to play with templates. For production code, I just pick one and use it.

Unless the inactive edge is synchronized.

That will work fine.

In our system, the cpu runs the show. The FPGA is just one of many chips that is initialized during boot up.

-- Mike Treseler

Reply to
Mike Treseler

The Reset to Clock path of a flop is very similar to Input to Clock path and in all libraries I have used it is a timing check which is included in the flop description. The release time of the reset is checked against the clock pulse. By supplying a registered reset, you are allowing to STA tool to do a better job because now it has an availabitlity number for reset with respect to clock which can be checked. Of course this assumes that your cell library has the reset to clock timing checks.

Reply to
m

In a way yes and it's safe to do. You don't register the reset signal though. Assume you have an active low reset. You connect input of a flop to 1 and connect its async reset input to the reset io pin, a second flop takes the output of the first as input and it's also async reset by the io pin. These are clock by your local clock (of course you have to make sure that for every clock domain in your design, you repeat this process).

So now when reset io is on, both flops are reset which also resets your design. When reset io goes high, the first flop can get upset if it's close to the clock edge but the second flop is perfectly happy as its input doesn't change at the same clock. On the next clock it sees the high value on its input (as the first flop is not being reset anymore) and propagates it to its output (as it's not being reset either).

This works very nicely if the library has the reset to clk path characterized and timed.

Reply to
m

OK. Are you doing this with Unisim components? Or can the XST infer all this through VHDL? And then does the synched reset from the second flop then connect to some global reset? And then how do you check that the synthesizer is correctly inferring to use the synched reset signal?

Brad

Reply to
Brad Smallridge

Try something like this:

Process(clk,resetin) begin if resetin = '1' then reset1

Reply to
Phil Hays

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.