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