My First CPU but.. one problem

F

flz47655

Guest
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: http://imageshack.us/photo/my-images/824/modelsimproblem.png

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: http://www.atomwave.com/FPGA/LCPU.zip
 
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.
 
Jon wrote:
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.
Click to expand...
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
 
On 10/13/2012 4:26 PM, Frank Buss wrote:
Jon wrote:
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.

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?

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

BobH
 
Frank Buss <fb@frank-buss.de> wrote:
Jon wrote:
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.

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?
Click to expand...
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
 
On 10/13/2012 11:09 PM, glen herrmannsfeldt wrote:
Frank Buss <fb@frank-buss.de> wrote:
Jon wrote:
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.

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?

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

They won't generate any logic if more than one process drives the
Click to expand...
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
 
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
 
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 <= '1';
addr <= data(5 downto 0);
state <= sstore;
-- ...
end case;
when sstore =>
-- write to memory, data is ready next clock
data <= reg;
state <= sfetch;
when others => null;
end case;

I just moved:

data <= reg;

In the state sstore.

So using high impedance Z signals in design is a worst practice?

Thank you
 
On Monday, October 15, 2012 9:42:17 AM UTC-5, flz47655 wrote:
So using high impedance Z signals in design is a worst practice?
Click to expand...
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 to happen, and perhaps why a more explicit approach is not preferable.

A fuzzy area is called "pushing tri-states" (through registers). We often need 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 really hold a 'Z', but the synthesis tool recognizes this, inserts a tri-state buf after the register AND inserts a register for the (implied) tri-state buf enable signal. Note that if you reset a register to 'Z', then the real reset on the real data register is not truly defined. The RTL code still determines 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 register 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 registers 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 (otherwise it would not have worked for a real tri-state bus), which reduces the 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 least the AND gating of an explicilty coded AND-OR tree.

Also, an INOUT tristate port on an internalal bus/module is automatically implemented as three signals (an output & enable to the mux, and an input from the mux). Whether that is more readable/writeable/maintainable than a more explicit description with two ports and an external mux is dependent upon the application and the design team/customer. (YMMV) If the application allows, I tend to favor higher levels of abstraction over more explicit descriptions of hardware.

Andy
 
flz47655 wrote:

So using high impedance Z signals in design is a worst practice?
Click to expand...
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
 
On 10/15/2012 10:12 AM, jonesandy@comcast.net wrote:
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
Click to expand...
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
 
On 10/15/2012 10:12 AM, jonesandy@comcast.net wrote:
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

On the other hand if one process is assigning 'Z', then he shouldn't
Click to expand...
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
 
jonesandy@comcast.net wrote:
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
Click to expand...
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
 
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
 
On 14 Okt., 01:26, Frank Buss <f...@frank-buss.de> wrote:
Jon wrote:
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.

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?
Click to expand...
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
 
On 13 Okt., 18:48, Jon <j...@beniston.com> wrote:
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.
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top