Is this legal?

[Jan Decaluwe]

Valentin Tihomirov wrote:

May be "stop bit" expression is misleadind, simulator stops in different
place.

if SampleCnt = 7 then
BitPos <= BitPos + 1; -- ModelSim stops here
if BitPos = 10 then -- STOP condition (UART stop bit)
BitPos <= 0;
.. -- check stop bit is '1'


I'm writing here just because when Sample = 7 and BitPos = 10 ModelSim shows
me message "Value 11 is out of range 0 to 10" and does not proceed. I
understand which signals I have at which cycles. There is no condition where
BitPos = 11; my logic prevents this. Please, tell me where is my (0..10)
constraint violated? I expect simulator to warn me only when things go wrong
due to inconsistency or a hole in my logic. I don't not want it to stall
when everithing is going as planed.

Interesting ... when I went through the exercise of implementing my Python-based
MyHDL simulator (loosely modeled after VHDL) I encountered the same issues. Here's
my reasoning.

When checking signal bounds, there are 2 options:

1. checking bounds at the actual update, when all processes have stalled.
This is "obviously" the correct thing to do.
2. checking bounds at each signal assignment. This may be pessimistic,
as the example shows.

Initially, I implemented (1), of course. However, later I reverted to (2).
Why? Because (1) didn't behave as a practical run-time check to my taste.
At update time, execution has moved far beyond the offending line, and the
context has changed. I just got a traceback from the simulation kernel about
a signal bound error - but without any direct clue, such as the offending
line, about what caused it.

In contrast, with (2), simulation stops exactly at the line that
(potentially) causes the problem, with the exact context to examine.
99% of the time, the problem will be real, and in the other case,
the code is probably confusing and the workaround will make it clearer.
In this case, I would prefer to put the counter increment in the else
case. I love default assignments, but in this case I don't think they
made the code clearer.

So I think this is a case where "practicality beats purity" as we say
in the Python community.

Regards, Jan

--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html