My First CPU but.. one problem

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:

formatting link

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

VHDL code:

formatting link

Reply to
flz47655
Loading thread data ...

A red signal means you have an X - an unknown value. Probably something not being reset, or you have multiple drivers, driving different values to the same signal.

Reply to
Jon

Is it possible to synthesize multiple drivers? When I try this in VHDL, it is an error and it doesn't synthesize the design. Maybe with some "inout" or "buffer" ports?

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

That has been my experience with Xilinx tools as well. It's possible that he is simulating RTL and not the post-synthesis data though.

BobH

Reply to
BobH

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.

-- glen

Reply to
glen herrmannsfeldt

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.

-- Gabor

Reply to
Gabor

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.

Andy

Reply to
jonesandy

Thank you to all, Thank you very much for your valuable informations.

I've adjusted code and removed red warning in Modelsim with:

case state is -- ... when sexec => -- Read data case data(7 downto 6) is -- ... -- Store when "01" => we

Reply to
flz47655

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.

Andy

Reply to
jonesandy

You need it, if you want to implement an open collector output, e.g. for implementing I2C. I've never needed it inside a FPGA.

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

and it's not an inout port of each driver.

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.

Like someone said earlier, FPGAs no longer have tristate buffers in them. If this is an external pin, then a 'Z' can be driven, but I'm still not sure it will synthesize with multiple drivers.

Rick

Reply to
rickman

and it's not an inout port of each driver.

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.

-- Gabor

Reply to
Gabor

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.

Andy

Reply to
jonesandy

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.

-- Gabor

Reply to
Gabor

General spoken it is possible (and in rare cases intended) , as long as you use std_logic instead of std_ulogic. Wheter the technology or synthesis tool supports multiple drivers is another question.

bye Thomas

Reply to
Thomas Stanka

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.

bye Thomas

Reply to
Thomas Stanka

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.