Concurrent assignments to std_ulogic_vector slice is OK with ModelSim

[Nicolas Matringe]

Hello
I noticed that ModelSim doesn't give an error at compile time when
multiple concurrent assignments are made to a std_ulogic_vector slice.

Try this, for example:
....
signal vect : std_ulogic_vector(7 downto 0);
....
vect(3 downto 0) <= x"5";
vect(2) <= '1';
....

 

[Symon]

Hi Nico,
But the 'X' value you get on vect(2) is a big clue something is awry.
std_ulogic includes U,X,0,1,Z,W,L,H,- so ModelSim is correct in allowing
your code. A synthesis tool will (should) complain.
Cheers, Syms.

 

[Wallclimber]

The LRM says that checking for multiple concurrent assignments is only
performed during the elaboration phase.

Both Modelsim and ncelab complain during elabortion.

Tom Verbeure

 

[Nicolas Matringe]

Symon a écrit:

Hi Nico,
But the 'X' value you get on vect(2) is a big clue something is awry.
std_ulogic includes U,X,0,1,Z,W,L,H,- so ModelSim is correct in allowing
your code. A synthesis tool will (should) complain.

The reason I use std_ulogic (unresolved) instead of std_logic (resolved)
is precisely to avoid such unwanted multiple assignments. I've spent too
much time tracking 'X' values in simulation waveforms when using std_logic.
Besides, as Wallclimber said, I won't get an 'X' but an error message
during the elaboration phase. I won't have the opportunity to run the sim.

 

[Nicolas Matringe]

Wallclimber a écrit:

The LRM says that checking for multiple concurrent assignments is only
performed during the elaboration phase.

I must admit I've never read the LRM.
I thought the check took place during compilation (and when concurrently
assigning multiple values to std_ulogic or std_ulogic_vector the
compiler complains)

Both Modelsim and ncelab complain during elabortion.

I noticed the problem when routing some internal signals to testpoints
and I used ModelSim compilation as a syntax check, I didn't simulate the
design

 

[Michael Riepe]

Hi!

Wallclimber a écrit:



I must admit I've never read the LRM.
I thought the check took place during compilation (and when concurrently
assigning multiple values to std_ulogic or std_ulogic_vector the
compiler complains)

It can't. If the signals assigned to don't have locally static names, it
will be impossible to detect multiple sources before elaboration:

generic (index : integer := 1);
-- ...
signal sig : std_ulogic_vector(...);
-- ...
sig(0) <= '1'; -- locally static
sig(index) <= '0'; -- not locally static

During elaboration, `index' may or may not become 0.

It would be much nicer if such cases would at least produce a warning
message. Maybe also an error if the case is clear (that is, a locally
static signal name is assigned to several times, as in your example).

Just my 0.02 €,

 

[Wallclimber]

The LRM says that checking for multiple concurrent assignments is only

I must admit I've never read the LRM.

That's not a shame. It's not something you want to do to relax during
a vacation.

I thought the check took place during compilation (and when concurrently
assigning multiple values to std_ulogic or std_ulogic_vector the
compiler complains)

At first, I was surprised myself that this wasn't caught during the
compilation phase. It seems like an easy extra check that wouldn't
really hurt...

I noticed the problem when routing some internal signals to testpoints
and I used ModelSim compilation as a syntax check, I didn't simulate the
design

Sounds very familiar to the 'quick and trivial ECO fix that cannot be
wrong'.

Tom

 

[Mike Treseler]

I noticed the problem when routing some internal signals to testpoints
and I used ModelSim compilation as a syntax check, I didn't simulate the
design

Modelsim can elaborate the design without a testbench.
____________________________
analyze for syntax errors:

vcom -c my_module.vhd

load for elaboration errors:

vsim -c my_module
____________________________

But consider writing a simple testbench.
It's much quicker to debug code than
to debug place+route errors.

-- Mike Treseler

 

[Nicolas Matringe]

Mike Treseler a écrit:

But consider writing a simple testbench.
It's much quicker to debug code than
to debug place+route errors.

I have a testbench and the design had been simulated many times (I'm no
beginner ) but sometimes the simulation works and the real system doesn't.
I just wanted to watch some internal signals (I can't use SignalTap
since I use an Altera Flex)

 

[Mike Treseler]

I have a testbench and the design had been simulated many times (I'm no
beginner ) but sometimes the simulation works and the real system doesn't.
I just wanted to watch some internal signals (I can't use SignalTap
since I use an Altera Flex)

For troubleshooting, assign the signal to an unused pin.
Normally synthesis "just works".
When it doesn't consider the following.

1. Double check the static timing report and synthesis warnings.
2. Eliminate asynchronous processes and multiple clocks.
3. Double check all inputs for synchronization.
4. Break the design into pieces zoom in on the problem.

-- Mike Treseler