FSM in illegal state

Let me get back to the fundamental problem: We distribute a (p)reset signal all over the chip. The problem is not the activating edge of this signal, it's the release of (p)reset. No matter how we distribute and phase it (unless there is only a single user clock of relatively low frequency) the trailing edge will not appear at every flip-flop in the same clock period. Whether the (p)reset is asynchronous or synchronous does not matter. I do not see a way to solve this dilemma on the chip-hardware-design level. I suppose the software could be made smart enought to handle this, same as smart designers can design around this. Especially with an elegant construct like SRL16. Peter Alfke

I don't design huge devices. I also normally need to conserve gates. So I typically am working close to the hardware. This selective reset (as you call it) is just SOP for me. I don't use test vectors (can't you provide don't cares?) and the chaos is only if you don't use it correctly.

But all of this is only to save gates and/or improve speed. Trying to route a chip wide sync reset can end up running into the same timing issues as the async reset if the fanout is too large. I once worked on an Altera design where we had CEs with large fanouts at 80 MHz. The timing analysis software did not work correctly for these signals and we had a he77 of a time getting the chip to actually work on the bench when the software said all was well. Being 80% full didn't help much either. But my point is that chip wide, large fanout signals can be problematic. So I make sure I understand what my chip needs to startup correctly and deal with that. Of course ASIC design requires a whole different level of confidence, but the method is not any different for an ASIC. You just have to make sure you did your homework, just like when you design your FSM in the first place. A small mistake in the FSM can work great in simulation and even on the test bench, but end up failing in the field and lock up the whole thing. I can vouch for that.

Yes, more details, but each one is separate. If you have startup dependancies between your FSMs, that has to be managed even if you have a global sync reset. This does not change that.

Speed is just what it is about. If you have to add another input to every FF on the chip (some of which don't have a lut if they are just delay registers) I can assure you that many of them will end up adding a layer of logic and therefore another increment of delay. If your design is not timing critical, then this is not an issue.

That depends on the target and tools. Many HDL packages will detect the async reset and connect it to the GSR, similar to the way they detect clock signals and use the global clock buffers. Some may still require instantiation of an internal async reset signal source. Check with your tool/chip vendor.

The above style is what I learned to use before anyone was providing any automatic support. You used to need to instantiate the driver for this signal or even provide it at a schematic level at the top of the design. As far as I know all vendors support this, but check with the tool vendor to be sure. Don't they have style guides?

I don't know which app note would be good, but Xilinx has lots of them. Do a doc search on their web site on the line of chips you are using and the word "startup" or "configuration".

Forgive me if I've someone's mentioned it already, but I understand that, in Virtex and later devices, synthesis tools do NOT infer the use of the GSR from the VHDL Reset signal. Instead the user's Reset is routed using general routing resources. (So, timing constraints can be applied to it.) There is of course still an issue if the external signal is truly asynchronous to the clock.

The effect of the GSR on the design's flip-flops is inferred from the behavior of the Reset signal.You can change this using UCF INIT constraints (care!)

The GSR is still used - at configuration time. It is an internal signal driven from the STARTUP block. You can't get rid of it (nor would you want to!) You can connect an external reset to the STARTUP block and hence drive the GSR if you want - you do this by instancing a STARTBUF component. You can also connect an internal signal to the STARTUP block to drive the GSR. If you do neither of these, the GSR is only used at configuration.

I recommend Xilinx's "Simulation and Verification Guide", which discusses all this. It is available with ISE or from:

Mike Smith, Doulos Ltd. snipped-for-privacy@myemployer.com

I am puzzled by how that would work. In normal use, the reset would be driven by an internal ROC (in VHDL), or be driven only by the testbench (in Verilog). So what would be the source of the reset signal in the cases you mention? Or are you referring to an asynchronous reset driven from a pin?

Hi,

An other technique can be use in ASIC design too. Because ASIC have commonly multi-clock domains, some of them can be powered down when not required. Clock gating logic are used to do it, and you have an enable input for this logic; you can design this input to be active only after reset and clocks input stability.

That give you a similar behavior than the FPGA proposal.

JaI

Jim Lewis wrote:

a cpu "just" needs: * known good value in the pc * address translation and caches disabled

thats a very small amount of state that needs to be right. the rest can be initiated to a known good state by software.