Error (10028): Can't resolve multiple constant drivers for net… VHDL ERROR

Question

I\'m trying to write a code that will detect a rising edge on din signal and will raise dout for 5 clock cycles after that happens. I keep on getting different errors while

Answer 1

You have dout and count assigned in both processes. Neither are resolved signals.

From IEEE Std 1076-1993:

12.6.1 Drivers

Every signal assignment statement in a process statement defines a set of drivers for certain scalar signals. There is a single driver for a given scalar signal S in a process statement, provided that there is at least one signal assignment statement in that process statement and that the longest static prefix of the target signal of that signal assignment statement denotes S or denotes a composite signal of which S is a subelement. Each such signal assignment statement is said to be associated with that driver. Execution of a signal assignment statement affects only the associated driver(s).

This essentially means you are duplicating both count and dout.

There are many ways to model the behavior of dout and count you desire. Bifurcating their operation across two processes based on starting and ending events isn't one of them. That would require three processes, one for the making event, one for the breaking event and one for the clocked storage. You'd likely need separate events for operating count.

Answer 2

As you seem new to VHDL, keep this rule in mind:

You can only drive a signal from one process.

You need to rearrange your logic so that a given signal is only driven from one process. Don't try to get around this. Use the std_ulogic type and the compiler will tell you when you get it wrong very early on.

So in your case, you need to move the 'resetting' part which drive count into the process which does the incrementing of count.

---

Now, when you've built up some experience, you'll find there are times when you need to have multiple drivers on a single signal. This is used when modelling the outside of chips (I2C buses, tristate memory buses and the like). But not for 'inside the chip' code.