Is it possible to perform gate level simulation on a design without a reset?

Hi,

If an Altera design does not have a reset, then what happens to the registers during gate level simulation? I assume that the Q outputs are initilaised to 0, but what happens with the D inputs, I guess they would be assigned U at time 0 , so when the registers clock changes the U will appear on Q, which would then propagate throught the fpga? How are designs tested without resets?

Thanks Andy

Reply to
aclegg1986
Loading thread data ...

Reply to
Peter Alfke

Only if the clock was scheduled before any of the other logic at time zero would the assumption of undefined Ds with defined Qs be a problem.

The issue with most simulation is the assumption of undefined Qs independent of the fact that FPGAs configure to a very well defined state. Depending on the manufacturer, device, or even development software revision, the assumption that all Qs start off 0 may or may not be valid.

Some FPGAs have global resets available that mimic the power-on reset, at least for registers. Memory elements might not be affected by the GSR.

It's because of the simulation/synthesis mismatch that I've very dutifully added those pitifully unnecessary async resets throughout my recent designs except for the logic that I *know* will perform better (where performance is needed) without the constraints of an async reset.

I don't have enough recent experience with Altera devices to tell you what

*will* take care of your simulation initialization problems. Until I get my synthesizer to properly deal with initial states in my source code, I'll keep adding the insanely unneeded async resets.

- John_H

Reply to
John_H

Not following why you would do this and just what simulation/synthesis mismatch you're talking about. A flip flop that doesn't *need* to be reset will be an unknown so if the simulation says that some output is an 'X', but the design functionally performs what you want it to do in simulation even with the 'X', then there is no mismatch that needs to be resolved...and certainly not by adding an otherwise unneeded reset.

One such situation would be an output interface that has say a data bus and an output data qualifier. If the data bus is 'X' but the output data qualifier is false then there should be no compelling reason to put resets on the data bus outputs. I realize there a bunch of other scenarios, but there is generally no requirement for all storage elements in a design to get into a known particular state at 'reset'. If the simulation model for the system works as intended and passes all testbench tests then you've properly initialized all of the storage elements that are required. This is true whether doing a sim based on the original source code or the post-route sim (assuming that you've also passed static timing analysis).

KJ

Reply to
KJ

If one designs with programmable logic, the simulation will not provide adequate results with all Xs.

The flops that don't need reset that we're talking about are the ones that configure to known states and those known states are necessary for a starting point for synthesis to begin from. A count incrementing from X to X doesn't provide the simulation results needed.

It's not "all storage elements" that I want to have brought to a known state for simulation, it's the registers that have known power-up states that the simulation is unaware of.

The discussion is about adding async reset to establish unequivocally what the power up state is for both simulation and synthesis.

I'm looking forward to the day when I can assign my registers, SRLs, and simple ROMs and RAMs initial values by declaring my vectors with initial states. My synthesis tool *still* doesn't support "reg [3:0] myFour =

4'h4;" style syntax, ignoring the construct. XST has supported the construct but didn't do a great job with SRLs a while back, breaking the SRL at each binary 1 in the initialization. Initial blocks and declaration initial statements would make life *so* much easier for me. Assuming, that is, that the synthesizer doesn't implement gratuitous "optimizations" that are inefficient in the end.

I just ask too much of my tools, sometimes.

- John_H

Reply to
John_H

OK, then we're talking about synthesis support (or lack thereof) for initial values in either (or both) the physical part and the post-route simulation model (duh...it was the name of the post)....I agree, that can be spotty in which case you open a service request to the supplier for producing a sim model that doesn't mimic the correct power up/end of configuration condition. They really won't have much of a leg to stand on for why they don't correctly model the specified behaviour. When enough people grumble about it, it could get fixed, if nobody grumbles they definitely will not fix it. Of course, in the mean time you design in the resets that you were talking about so you can get your job done.

As do we all....sigh.

KJ

Reply to
KJ

Hi,

Out of curiosity I decided to list the signals applicable to one of the back-annotated registers, as shown below:

ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd clk_ipd 0 +0 0 U U U U U U U U 0 +1 X U 1 1 X U U U U 0 +2 X U 1 1 X U 1

1 X 0 +7 X X 1 1 X U 1 1 X 0 +8 X X 1 1 X X 1 1 X 3900 +2 X X 1 1 0 X 1 1 X 3900 +3 X X 1 1 0 X 1 1 0

I had the idea to force all inputs except the d's and q's to an inactive state and the output was given below (note clock force was removed at approx 40000):

ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd clk_ipd

0 +0 0 U 1 1 0 U 1 1 0 0 +7 0 X 1 1 0 U 1 1 0 0 +8 0 X 1 1 0 X 1 1 0 400000 +3 0 X 1 1 1 X 1 1 0 400000 +4 0 X 1 1 1 X 1 1 1 400400 +4 x X 1 1 1 X 1 1 1

The q still went to X on the rising edge of the clk_ipd, obviously due to the d input being at x, but not sure why the D input remained at x? Then I noticed that all the registers had their CLRN inputs connected to the VCC net, I forced this signal low for 10ns and removed the force. The design then sprang into life, I was curious to know if this is legitimate? I also still do not understand why all the registers Q outputs go to X unless I hard code an async reset, which I can not do at present (manager is happy with design as appears to work on the board, although wants it back-annotated, the original designer has left) or use the hack listed above?

Reply to
aclegg1986

The Xilinx simulation models have a GSR signal that can be included in simulation which globally resets all non-memory synchronous elements. The Altera simulation probably has a similar reset.

For the Altera simulation folks here, what can be done to initialize the Altera part?

If you're doing RTL simulation rather than post-placement back-annotated simulation, the situation is much simpler. In Verilog, use "initial" blocks to initialize all your register values. No forces required.

Are you Verilog or VHDL?

- John_H

Reply to
John_H

Hi, I am using a VHDL Altera generated netlist for back anno + VHDL for RTL, at present in RTL I am setting the vhdl signals to the required values in the signal declaration area.

Thanks

Andy

Reply to
aclegg1986

Unless you also take steps to deal with the asynchronous transition from configuration to operation (e.g. the first clock edge), relying on initial values from the object declaration will not guarantee reliable results in hardware.

There are methods of dealing with the clock side of this timing relationship (e.g. delaying the clocks until "well after" end of configuration), but otherwise, most methods look an awful lot like a synchronous reset or clock enable anyway, and are often much harder to review/audit.

Andy

Reply to
Andy

I agree. Part of designing a robust system with or without resets is making structures that come out of async reset conditions without confusion where an async reset caught by different flops on different sides of the clock edge work cleanly. A synchronous (deassertion of) reset covered by timing constraints provides the best assurance of clean startup with no startup issues.

It is certainly difficult to review/audit both systems without reset or with deassertions of asynchronous resets.

- John_H

Reply to
John_H

There are some situations where you don't care about the starting state, but it has to be a valid state for the state machine to work (i.e. not 'X's). For example, if I have a counter that generates an enable pulse every 4th clock and all I need is that 4 clock enable with no need to know the phase of it relative to anything else. That can be done with a simple counter with no reset and will work just fine in hardware because it starts off in some valid state, you just don't know which one. If I tried to simulate that however, it will start off with all bits set to 'U' which makes the next state all 'X's and it will never get into the operational sequence without some form of initialization. In Xilinx, this can be taken care of using the ROC primitive to provide a simulation reset. ROC gets taken out by the mapper, so there is nothing in the hardware (well, it does set the configuration bits for the initial value of the connected registers but no user hardware is used).

The situation I see most for this is a simple toggle flip-flop used in clock domain crossings. An event toggles a flip-flop in the sending clock domain. The output of the toggle FF is sent across the domain boundary, resynchronized to the receiving clock and then synchronously edge detected to produce a one clock wide pulse response to each time the toggle FF changes state. I don't care what state the toggle FF is in, all I care about is when it transitions. The hardware doesn't care, because it will always be either a 1 or 0 so it just flips state. Simulation does care because it can't invert an unknown state.

Reply to
Ray Andraka

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.