Simple explaination I hope

[Altera_Forum]

I have seen some VHDL code written like this: 

  SIGNAL slv : STD_LOGIC; SIGNAL usg_counter : UNSIGNED(7 DOWNTO 0); --code to make usg_counter count up 1 count etc. every 1uS here proc_ConfusedDotCom : PROCESS(usg_counter) BEGIN slv <= '0'; IF usg_counter = b"0010_0110" THEN slv <= '1'; END IF; END PROCESS proc_ConfusedDotCom;   Can some clever bod explain exactly what is happening to the signal 'slv' here please? Is there a better way of writing this?  I know what is does, I would like to know why. :)  Cheers,  Andy

[Altera_Forum]

--- Quote Start ---  I have seen some VHDL code written like this:   SIGNAL slv : STD_LOGIC; SIGNAL usg_counter : UNSIGNED(7 DOWNTO 0); --code to make usg_counter count up 1 count etc. every 1uS here proc_ConfusedDotCom : PROCESS(usg_counter) BEGIN slv <= '0'; IF usg_counter = b"0010_0110" THEN slv <= '1'; END IF; END PROCESS proc_ConfusedDotCom;   Can some clever bod explain exactly what is happening to the signal 'slv' here please? Is there a better way of writing this?  I know what is does, I would like to know why. :)  Cheers,  Andy  --- Quote End ---    it is equivalent to   IF usg_counter = b"0010_0110" THEN slv <= '1'; else slv <= '0'; END IF;   or just: slv <= '1' when usg_counter = b"0010_0110" else '0';  In your code the '0' is assigned as default and the next conditional statement updates it.

[Altera_Forum]

Cool! 

 Your equivalent 'else' answer is what I thought too, but thought (like many things) there may be deeper VHDL 'nastiness' to consider too.  Thanks,  Andy

[Altera_Forum]

The default approach is convenient alternative if the target signal is to be assigned same value in many following statements in the sequence.

[Altera_Forum]

The most common usage is in state machines where output signals are usually the default, but assigned something different in specific states.

[Altera_Forum]

Gotcha. 

 OK, another question leading on from this then if I may:  As you can see, the above process is processed upon a change to usg_counter  Now say I combined the activity of slv into the clocked process that deals with updating the counter, i.e. something like this:   proc_Counters : PROCESS(IN_CLK, IN_RESETn) BEGIN IF IN_RESETn = '0' THEN usg_Counter <= (OTHERS => '0'); slv <= '0'; ELSIF RISING_EDGE(IN_CLK) THEN IF usg_Counter = b"0010_1111" THEN usg_Counter <= (OTHERS => '0'); ELSE usg_Counter <= usg_Counter + 1; END IF; --Put it here instead... IF usg_Counter = b"0010_0110" THEN slv <= '1'; ELSE slv <= '0'; END IF; END IF; END PROCESS proc_Counters;   Would that do the same thing?  Andy

[Altera_Forum]

yes, but it has a 1 clock cycle delay compared to the unregistered code.

[Altera_Forum]

REALLY! 

 Hmmmmmmmmm!  Hold on, which has a 1 clock cycle delay. The combined one or the separate process one. The latter I guess.  Cheeers,  Andy

[Altera_Forum]

the get the same behaviour, you need to make the counter a variable, check the variable rather than the signal.

[Altera_Forum]

the combined one has the extra clock cycle delay, as you make slv synchronous. The seperated one has no interaction with the clock.

[Altera_Forum]

I see! 

 Effective change within a process only implemented after the process is done.  Thank you yet again!

[Altera_Forum]

no, this is to do with the way signals vs. variables work. 

signals are updated only when the process they are assigned in suspends. So a signal assignment actually schedules the update to occur in the next delta cycle, or in x ns if you use the after assignments:  x <= '1' after 10 ns;  varaibles are updated immediatly, hence why making the counter a variable instead of a signal would remove a clock delay from the process. It wouldnt exactly recreate the same hardware, as the two versions would alter the position of the output register - with separate processes the register is on the counter with the slv signal just a gated version of this register output. In the combined version, the slv is a gated version of the +1 output, with the register placed after this.   Hence why you really need to understand the underlying hardware before writing the VHDL.