More VHDL issues..

^^^ now??

the

same

It sounds like Modelsim is confused. Is it actually an error, or just a warning? Having a signal read that is not in the sensitivity list is not an error. Can you disable Modelsim's synthesis checks?

If it's a warning, just ignore it.

If it's an error, it sounds like a bug.

regards

Alan

p.s. I know it's nothing to do with this error, but I'd check for negative values before assigning, just because I am paranoid (!). In particular I wonder what happens if you assign a negative time value to a variable of type time? e.g.

assert ( (ARM_command.RelTime - (now - CurrentTime)) >= 0 ns ) report "negative time value";

waittime := ...

p.p.s. Reading the LRM shows I really am being paranoid, as type TIME is guaranteed to include the range -2**9+1 to 2^9-1, so negative time values in variables of type TIME are ok.

Yes, now, not "not".

The possibility of being negative was why I was using a variable instead of just sticking it in the wait statement. I thought it would be better to calculate it once and then test it and set to zero if negative. So now I have to do the calculation twice.

I am getting the same error from a different assignment now. The common point is that a signal is on the right hand side of the assignment and a variable is on the left. I am using the variable assignment operator, ":=". This is reported as an error, not a warning.

Last_Bus_Action := Bus_Command.Bus_Action;

In both cases, part of the right hand expression is an element in a record. The error reports the record "Bus_Command" as missing from the sensitivity list, not the element! Could the VITAL process have a bug in regards to dealing with record elements? This doesn't sound likely to me. But then I don't even know what the VITAL process is.

Maybe I need to contact Mentor about ModelSim.

That should have been -2**31+1 to 2**31-1, sorry.

instead

better

So

OK, sounds sensible.

common

and a

operator,

the

bug

likely

That is weird. I thought that VITAL was a label you'd used in your code, e.g.

vital: process...

But if it's not?

If it's vital as in "VITAL - VHDL Initiative Toward Asic Libraries" then I'd only expect to see it referred to if you were doing back-annotated gate level simulation?

Sounds like a good idea.

regards

Alan

If that's the case, then assigning the record field to an intermediate signal would probably "fix" it. Not nice, but as an expedient to (a) keep moving and (b) home in on the real problem, maybe worth trying.

-- parallel signal assignment tempAction

I already have a work around and have sent the problem to Xilinx (Mentor does not support the Starter Edition). But thanks.