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?
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.
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.
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.
- 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.
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.
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.
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?