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

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

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
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?=20

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

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

flz47655 wrote:

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

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