Signal Resolution

When more than one input is connected to a signal, the simulator has to figure out what to do. If you send different signals in either input, something has to come out the other side, but what?

The process of deciding this is called resolution. A signal type that knows how to do this is called a resolved signal. In the std_logic library, the std_logic type is resolved, but std_ulogic isn't (but is otherwise identical). An unresolved signal doesn't know how to deal with this situation and the compiler or simulator will choke on it.

So far, there shouldn't be any surprises here--hook up a couple of entities' outputs to a single signal and some decisions have to be made. For more details, you can look at Chapter 8 of the Student's Guide to VHDL or chapter 6 in the VHDL Cookbook.

Resolution of processes

The tricky thing is when you have one entity with multiple processes. VHDL imagines each process as a separate circuit. So, if you have two different processes that each set the value of the signal T somewhere, the simulator is thinking of this situation:

a circuit with resolution problems

[Aside: This is one of those things you have to keep in the back of your mind: VHDL is for designing circuits; it ain't a programming language. This is the kind of thing that makes perfect sense if you remember that VHDL is trying to design a circuit. If you think of VHDL as a programming language, this makes no sense whatsoever.]

When this situtation comes up, it needs to do signal resolution. This can cause unexpected results. For example, this model has two processes that set the signal T, so we run into the resolution problem. The output is 'X' for most of the simulation.

Fixing it

This can be fixed most easily by combining the parts that set a particular signal into one process. This has been done for the example. This eliminates the whole multiple-input problem.

The other thing you can do is use the std_logic value 'Z'. It's job is really to be ignored in the resolution process. You can do this structurally with tri-state buffers or behaviourally with some clever fiddling with your process outputs.

Copyright © Greg Baker, last modified 2003-06-26.