Can one force ModelSim to flag signals missing signals in sensitivity list?

In VHDL we often use processes not trigerred by clock e.g next state process for FSM. In this case, there may be a long list of signals that must be put into the sensitivity list.

I have noticed that if a signal is missing in sensitivity list, the code may still work when synthesized but will not work in simuation. This often leads to confusion and wasted time.

Is there a way to detect signals that must be present in VHDL process sensitivity list but are missing when using ModelSim? It does not seem to flag up such things by default.

If you use VHDL 2008 you can just use "all" in the sensitivity list .

matrixofdynamism said:

In VHDL we often use processes not trigerred by clock e.g next state process for FSM. In this case, there may be a long list of signals that must be put into the sensitivity list.

I have noticed that if a signal is missing in sensitivity list, the code may still work when synthesized but will not work in simuation. This often leads to confusion and wasted time.

Is there a way to detect signals that must be present in VHDL process sensitivity list but are missing when using ModelSim? It does not seem to flag up such things by default.

Click to expand...

Yes you can.
the vcom command has a -check_synthesis switch :

Modelsim Command Reference Manual said:

-check_synthesis
(optional) Turns on limited synthesis rule compliance checking. Specifically, it checks to
see that signals read by a process are in the sensitivity list. The checks understand only
combinational logic, not clocked logic. Edit the CheckSynthesis variable in the modelsim.ini
file to set a permanent default.

Click to expand...

I never use a "next state" combinatorial process. I write state machines as one clocked process.
With the tools we have today, I don't see any reason to use 2 processes for one state machine.

std_match said:

I never use a "next state" combinatorial process. I write state machines as one clocked process.
With the tools we have today, I don't see any reason to use 2 processes for one state machine.

Click to expand...

I agree. I never understood that whole separate "next state" nonsense.

barry said:

I agree. I never understood that whole separate "next state" nonsense.

Click to expand...

From my understanding, it comes from several places:

1. Synthesis tools use to require separate processes for logic and registers.
2. Some engineers (usually old timers) seem to understand separated logic/register processes better. These people also often also like using schematics.
3. Because of 1/2, text books and tutorials taught separated logic/register styles.
4. There are some that argue, that with a single process, it becomes "harder" to write unregistered outputs, as you then have to use the state machine directly in the combinatorial logic.

Using a single process style, it can be easy to write a monster of a process (and I have been guity of it in the past) that becomes harder for others to follow, where separate processes would be better. But that is true of any style, though I think with single process style, it is easier to do.

In the compile menu in modelsim, select "compile options". Under VHDL tab, under "Check for" enable the checkbox "synthesize". When you run the command "vcom" for vhdl files, you will find few warnings like missing signals from the sensitivity list.

barry said:

I agree. I never understood that whole separate "next state" nonsense.

Click to expand...

debugging is much much much easier. I am not talking about functional debugging, I am talking about timing issues. When you have to optimise that one critical path that is killing your entire performance, it becomes much easier if you can do it separately.

These answers are helpful. I learnt that the process to generate next state is combinatorial and thus should have its own process. It is a "good practice".

matrixofdynamism said:

These answers are helpful. I learnt that the process to generate next state is combinatorial and thus should have its own process. It is a "good practice".

Click to expand...

I, and many others, would disagree that splitting the FSM into separate processes is "good practice". (An equal number would probably take the opposite view.) When you use a separate combinatorial process there is the danger of inadvertently creating latches. Furthermore, I, personally, wouldn't find debugging "much much easier" using separate processes. In fact, that complicates debugging as you now have to look in TWO processes for the problem rather than one.

In the end, if you write your code properly either method should yield identical results and it comes down to a matter of preference and style.

Another thing: I tend to make all of my outputs registers, so everything fits happily into my clocked process. You've got thousands and thousands of registers, you might as well use them.

matrixofdynamism said:

These answers are helpful. I learnt that the process to generate next state is combinatorial and thus should have its own process. It is a "good practice".

Click to expand...

I dont know. I would recommend 1 process, as would many others.
"Good Practice" is good code that works well and is useable and readible by others. Ive seen "good practice" code that is terrible, and "bad practice" code that is good.

I learnt that the process to generate next state is combinatorial and thus should have its own process. It is a "good practice"

Click to expand...

As pointed by many others it was a "good practice", but maybe 10 yrs ago. In the university when I was learning VHDL, I was writing state machines as two clocked process and had used Modelsim 6b or something like that.
The modern "good practice" is a 1 clocked process, in my opinion and I have never run into problems.

There are some white papers analyzing both practices and discussing their pros and cons. You can search, download and read them.
In the end it is a matter of perspective.

In either case, you should be able to read/write either. You should also know the fundamental differences and common pitfalls of each.

In many cases, a one-process FSM is fine from a design perspective. The exception is any time next_state is used for output logic that cannot tolerate the extra one cycle of delay. This can occur when interacting with another module. The one I see most frequently is the use of empty to generate a registered read signal. However it could happen in other situations.

There are actually some interesting variations on the one/two process designs that mitigate a lot of the problems of either. One process has the issue that new devs still want to define logic as it occurs within a state vs as it occurs on transitions. two process has a lot of verbosity. There are language features that can solve these problems, especially in VHDL. I don't think anyone will use them, but they exist.