--- Quote Start ---
t1 is not register. It is y2 and y4 that are registered.
--- Quote End ---
I think the opposite view is more appropriate. Viewn from the outside of the clock sensitive code, t1 behaves as a register because it's assigned under clock control.
The view of variable assignments as "combinational code" inside a clocked process isn't completely true. The behaviour is only combinational for succeeding references to the variable inside the clock sensitive code. It's registered for preceeding references and those not controlled by the same clock edge.
This can lead to hardly readable behaviour in some cases. In so far I understand why people want to separate combinational and registered processes and consider multiple clock sensitive events in a process as sacrileg.
But if you want to write compact code that keeps functionally related actions close together, these "mixed" processes can serve a purpose.
Assigning a variable in the clocked code and reading it in the combinational code, as done in the previous example, is probably not the best idea, because it's "avoidable confusing".
The latest integer variable example has implications of synthesis to simulation mismatch, but they are not primarly specific to variables, I think.
Exceeding the range of 0 to 99 in simulation causes an exception. To keep the code simulation compatible, the range must be increased (or the code changed).
Honored Contributor
