Hello to all, I completed my first CPU in VHDL, an incredibly satisfying feeling! : D I simulated successfully but I did not understand what it means to a signal colored red in ModelSim:
I notice the signal that is in red has a change of more bits at the same time, it is perhaps hazard or something? How can I eliminate the problem in the case?
The register in question is an SRAM synthesized with normal flip-flop, the writing of a data element in memory involves a change of more bits and seems to require two clock pulses to stabilize the signal ..
Earlier Xilinx FPGAs had internal tristate buffers. As the chips got bigger, it became necessary to put buffers along the lines, and so internal tristates were removed. Even so, the tools usually will generate equivalent logic.
They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver. Synthesis is therefore an easy way to check for multi-source errors. I almost never simulate code intended for synthesis unless I have run it through synthesis first. You can spend a lot of time debugging stuff and then realize you need to start over because you used a non-synthesizable "feature" of the language.
On Sunday, October 14, 2012 1:55:03 PM UTC-5, Gabor wrote: They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver.
That's not correct. All you need is an OUT port, a resolved type, and conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it.
Not necessarily. Some work groups or organizations discourage it. If I use it (inside an FPGA, instead of on IO), I heavily comment what is supposed t o happen, and perhaps why a more explicit approach is not preferable.
A fuzzy area is called "pushing tri-states" (through registers). We often n eed registered, tri-stated IO, and an easy (to read and write) way to do it is to assign 'Z's to the output register. Of course registers cannot reall y hold a 'Z', but the synthesis tool recognizes this, inserts a tri-state b uf after the register AND inserts a register for the (implied) tri-state bu f enable signal. Note that if you reset a register to 'Z', then the real re set on the real data register is not truly defined. The RTL code still dete rmines what the first (non-Z) assignment after reset will be, so it really does not matter. I don't recall whether the synthesis tool left the data re gister reset off, or defaulted the reset value to '0'. I would imagine that if it affects pushing the registers et al into the IO block (e.g. if all r egisters in the IOB must have a common reset), the synthesis tool will "do the right thing".
Inside an FPGA, an interesting side-effect of tri-state to mux synthesis is that the tri-state enable signals are assumed to be mutually exclusive (ot herwise it would not have worked for a real tri-state bus), which reduces t he complexity of the mux. This may be an easier way to get the simpler mux than to explictly code the AND-OR tree. It also allows the mux control/code to be distributed amongst multiple modules. The same can be done with at l east the AND gating of an explicilty coded AND-OR tree.
Also, an INOUT tristate port on an internalal bus/module is automatically i mplemented as three signals (an output & enable to the mux, and an input fr om the mux). Whether that is more readable/writeable/maintainable than a mo re explicit description with two ports and an external mux is dependent upo n the application and the design team/customer. (YMMV) If the application a llows, I tend to favor higher levels of abstraction over more explicit desc riptions of hardware.
conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it.
On the other hand if one process is assigning 'Z', then he shouldn't get 'X' on the simulation. My point was that a normal signal can't generally be driven by more than one process for synthesis within the same entity or architecture. In Verilog this is certainly enforced for "reg" types, whether they are assigned 'Z' or not. None of this is an error for simulation, and unless you happen to notice the 'X' for the multiple-driven case, you could do a lot of design debug and then realize you need to do a lot of re-coding to get it to synthesize.
In vhdl, you can use unresolved data types to disallow multiple drivers. You can still drive 'Z' with std_ulogic or std_ulogic_vector, but you can only have one driver.
I seem to remember Modlesim showing waves in red if the trace included meta-values (W, Z, X, -, U), maybe if you had the radix set to something besides binary? If that is the case, it would not necessarily indicate contention between drivers.
can still drive 'Z' with std_ulogic or std_ulogic_vector, but you can only have one driver.
meta-values (W, Z, X, -, U), maybe if you had the radix set to something besides binary? If that is the case, it would not necessarily indicate contention between drivers.
Modelsim (in the default color scheme) shows Z in blue and most other meta-values in red. If any bits of a vector are not 0, 1 or Z, then the whole vector gets colored red unless you expand it to show individual bits. This has nothing to do with the display radix. You can see binary values like "01XX0XX0" in the waveform originally posted. Just under it you can see the individual bits as waves, and only those with "X" values show up in red. If you have a sufficient license (I don't think the vendor-bundled editions did this) you can double-click on the red lines to trace back to the driver(s).
And the multi-driver issue was a "side-thread" to this topic. There are many ways to end up with X or U in simulation.
being reset, or you have multiple drivers, driving different values to the same signal.
Red in modelsim for std_(u)logic and predefined setting means either U or X or W. U = uninitialised (signal not driven up to now, forgot reset?), X = Unknown (Eg two driver). W = weak unknown (if H and L drive the same signal, but no 1 or 0 driver). For vectors the vector will be red, if one bit is red.