#9cbb e90 error counter 1 code#

Else, you will get unknown resulting values, represented in red by Modelsim, as you saw. When one of your driving processes drives a strong value ('0' or '1'), all the others must drive a weak value ('Z' for high impedance). There is no compiler error any more, no seatbelt.

#9cbb e90 error counter 1 code#

If you can find the source code of ieee.std_logic_1164 you will see the declaration of the unresolved, 9-valued std_ulogic type ( u for unresolved), the resolution function, and the declaration of the resolved subtype std_logic (see? no u).Д«ut when using resolved types you must yourself take care of not creating short-circuits. This function can be used to define the resolved subtype of a unresolved parent type. Sometimes, rarely, it is useful to drive a signal from more than one process (high impedance shared bus, bi-directional RAM data bus.) So VHDL allows to define a resolution function that computes the resulting value of several drivers. You can try this and see the errors by replacing your unsigned (resolved) counter by a natural (unresolved) one: signal counter_reg,counter_next : natural 0 to 2**16 - 1 ДЄdapt the rest of your code, and see what happens when compiling. And this is a very nice feature because such accidental short circuits can have serious consequences. This means that, if you try to drive a signal of this type from more than one process you will get an error at compilation or elaboration time that basically says 'I cannot decide what value to assign if your processes disagree, this is forbidden'. Solution: drive your counter from one single process.ДЄ bit more about this: if this is bad, why didn't you get an error when compiling or when launching your simulation? Because most people do not know or care about unresolved/resolved types in VHDL.

It is usually undesirable, just like any short circuit, because when the two processes disagree about the value to assign things are getting very bad. This is what we call a 'multiple drive' situation. Your counter_reg signal is assigned in two different processes. The moment channel_prev rises, both counter_reg and counter_next become X (error) and turn red. If (channel = '1') and (channel_prev = '0') thenДЄs shown below, counter_reg and counter_next start off with a value of 0 until I try to add 1 to counter_next. If (shifter = '1') and (shifter_prev = '0') then Signal counter_reg,counter_next : UNSIGNED (15 downto 0) Signal arm_prev,shifter_prev,channel_prev : STD_LOGIC Signal state_reg,state_next : state_type Type array_type is array (1 downto 0) of UNSIGNED (15 downto 0) Is there anything I'm doing wrong with the counter? library IEEE ДЄrchitecture fsm_arch of photon_counter is I am not sure what is wrong with counter_reg. I have included the IEEE.NUMERIC_STD.ALL, so I should be able to do unsigned addition.

The code and picture of what happens to the signal are provided below. For some reason, whenever I try to add 1 to counter_reg, or try to assign any number at all to it, the signal becomes red with an X in ModelSim. I've simplified my design to include two states, one and two, where counting is done. I'm building a counter that counts rising edges from an input channel.