arrrrg!

[Ken Cecka]

I just spent all afternoon trying to figure out why isimwave (the xilinx simluation waveform viewer) was drawing my state machine value in red for certain states.

I believe I've finally tracked it down: if my state name contains the letter 'X', xilinx draws it in red. For example, with the following states:

TYPE state_type IS ( STATE1, STATE2X );

Any time a signal has the value STATE1, it will be drawn in green. If it has the value STATE2X, it will be drawn in red.

Posting this partly to see if others can confirm this behavior and/or give a better explanation, and partly to get it documented somewhere for the next poor soul who wonders what's causing there state machine to go into an invalid state.

Also, I'm guessing this should be considered a bug in isimwave - is there anything in the language specification that says you can't use the letter X in your enumerated state names?

Ken

 

[kennheinrich]

I just spent all afternoon trying to figure out why isimwave (the xilinx simluation waveform viewer) was drawing my state machine value in red for certain states.

I believe I've finally tracked it down: if my state name contains the letter 'X', xilinx draws it in red.  For example, with the following states:

  TYPE state_type IS ( STATE1, STATE2X );

Any time a signal has the value STATE1, it will be drawn in green.  If it has the value STATE2X, it will be drawn in red.

Posting this partly to see if others can confirm this behavior and/or give a better explanation, and partly to get it documented somewhere for the next poor soul who wonders what's causing there state machine to go into an invalid state.

Also,   I'm guessing this should be considered a bug in isimwave - is there anything in the language specification that says you can't use the letter X in your enumerated state names?

Ken

There's nothing that says you can't use the letter "X" in your enums.
Perfect examples are in the language already: the simple character
'X' , as well as the names STX and ETX, are members of the CHARACTER
enum.

- Kenn

 

[Al Muliman]

Any time a signal has the value STATE1, it will be drawn in green.
> If it has the value STATE2X, it will be drawn in red.

Posting this partly to see if others can confirm this behavior

Running ISIM 10.1.03 WebPack on Windows Vista Home Basic, I can confirm.
But surely that is a feature rather than a bug ;-)

> and/or give a better explanation,

I cannot. But then what do I know.

 

[Al Muliman]

Running ISIM 10.1.03 WebPack on Windows Vista Home Basic, I can confirm.
But surely that is a feature rather than a bug ;-)

That feature also involves states named "FUNC". My state is in a shared
(to see it in Isim waveform viewer) variable.


When I rename the state to "FANC", it is green. When I rename to "UANC"
it is red again. The letter "U" seems to do the trick also. Renaming to
"XANC" also makes it red. So the position does not matter. Playing
around with the color coding reveals that it is considered an undefined
value in all cases.

If this is an undocumented feature then I suppose it is just one more
reason to use ModelSim.

 

[Al Muliman]

If this is an undocumented feature then I suppose it is just one more
reason to use ModelSim.

For the sake of completeness, states containing "Z" also receive special
treament. States containing "U" or "X" gets one color, and states
containing "Z" gets another.

 

[Nicolas Matringe]

Al Muliman a écrit :

For the sake of completeness, states containing "Z" also receive special
treament. States containing "U" or "X" gets one color, and states
containing "Z" gets another.

So what if the name contains both Z and X (or U)? Just curious... ;-)

I suppose H, W and L also receive a special treatment. This is a really
stupid bug.

Nicolas

 

[Al Muliman]

So what if the name contains both Z and X (or U)? Just curious... ;-)

X and U beat Z ;-)

I suppose H, W and L also receive a special treatment.

Not that I can tell.

 

[Al Muliman]

Can you create a simple example and submit a Webcase?

Example created, webcase access pending.

------------------------ Here's the example: ----------------------

library ieee;
use ieee.std_logic_1164.all;

entity colors is
port ( reset : in std_logic; clock : in std_logic );
end colors;

architecture behavioral of colors is
type state_type is (SZTATE1, STUATE2, SXTATE3, SZXTATE4, SZTUATE5,
SXTUATE6, STLATE7, STWATE8, STHATE9);
shared variable state : state_type;
begin
process(clock, reset)
begin
if (reset = '1') then
state := SZTATE1;
elsif rising_edge(clock) then
case (state) is
when SZTATE1 => state := STUATE2;
when STUATE2 => state := SXTATE3;
when SXTATE3 => state := SZXTATE4;
when SZXTATE4 => state := SZTUATE5;
when SZTUATE5 => state := SXTUATE6;
when SXTUATE6 => state := STLATE7;
when STLATE7 => state := STWATE8;
when STWATE8 => state := STHATE9;
when others => state := SZTATE1;
end case;
end if;
end process;
end behavioral;

---------------------- And the test bench: --------------------------

library ieee;
use ieee.std_logic_1164.all;

ENTITY colors_test_bench IS
END colors_test_bench;

ARCHITECTURE behavior OF colors_test_bench IS

-- Component Declaration for the Unit Under Test (UUT)

COMPONENT colors
PORT(
reset : IN std_logic;
clock : IN std_logic
);
END COMPONENT;


--Inputs
signal reset : std_logic := '1';
signal clock : std_logic := '0';

-- Clock period definitions
constant clock_period : time := 1us;

BEGIN

-- Instantiate the Unit Under Test (UUT)
uut: colors PORT MAP (
reset => reset,
clock => clock
);

-- Clock process definitions
clock_process rocess
begin
clock <= '0';
wait for clock_period/2;
clock <= '1';
wait for clock_period/2;
end process;


-- Stimulus process
stim_proc: process
begin
-- hold reset state for 100ms.
-- wait for 100ms;

wait for clock_period*2;

-- insert stimulus here
reset <= '0';

wait;
end process;

END;

 

[Ken Cecka]

Example created, webcase access pending.

Thanks for the confirmation. I'll submit a webcase as well if you don't get a positive response to yours.

Ken

 

[Dave Higton]

In message <[email protected]>

I just spent all afternoon trying to figure out why isimwave (the xilinx
simluation waveform viewer) was drawing my state machine value in red for
certain states.

I believe I've finally tracked it down: if my state name contains the
letter 'X', xilinx draws it in red. For example, with the following
states:

TYPE state_type IS ( STATE1, STATE2X );

Any time a signal has the value STATE1, it will be drawn in green. If it
has the value STATE2X, it will be drawn in red.

Posting this partly to see if others can confirm this behavior and/or give
a better explanation, and partly to get it documented somewhere for the
next poor soul who wonders what's causing there state machine to go into an
invalid state.

Also, I'm guessing this should be considered a bug in isimwave - is there
anything in the language specification that says you can't use the letter X
in your enumerated state names?

Widening the topic somewhat: isim is, by a country mile, the buggiest
software I use. I have a case in at the moment reporting two bugs (I
originally reported one, then another one came along...)

I find that, if I have a lot of signals in the simulation window, the
first simulation run after an edit of any of the source files causes
the simulation window to be only partly drawn. I have to close it and
re-run to get a fully drawn window. Also, infuriatingly, it will from
time to time randomly alter the order of signals in the simulation
window.

However, I find it dramatically faster than ModelSim.

A new version is expected to be released around April.

Dave

 

[Ken Cecka]

In message <[email protected]>


Widening the topic somewhat: isim is, by a country mile, the buggiest
software I use. I have a case in at the moment reporting two bugs (I
originally reported one, then another one came along...)

I find that, if I have a lot of signals in the simulation window, the
first simulation run after an edit of any of the source files causes
the simulation window to be only partly drawn. I have to close it and
re-run to get a fully drawn window. Also, infuriatingly, it will from
time to time randomly alter the order of signals in the simulation
window.

There seem to be a whole raft of issues in this area. It's become a compulsive behavior for me to kill the simulation and rerun it any time I look away from the screen, in case it went and did something funny when I wasn't keeping an eye on it.

More seriously, I couple of specific issues I've had repeatable problems with are: signals I add to the waveform view don't get drawn unless I restart the simulation, and for large projects, restarting the simulation sometimes results in partially drawn or completely incorrect waveforms, and can only be resolved by killing the simulation and rerunning.

However, I find it dramatically faster than ModelSim.

Thus far, I've only worked with GHDL and isim, so I don't have a particularly high bar to measure against.

 

[Dave Higton]

In message <[email protected]>

There seem to be a whole raft of issues in this area. It's become a
compulsive behavior for me to kill the simulation and rerun it any time I
look away from the screen, in case it went and did something funny when I
wasn't keeping an eye on it.

More seriously, I couple of specific issues I've had repeatable problems
with are: signals I add to the waveform view don't get drawn unless I
restart the simulation

I'm not sure this will turn out to be a bug. Added signals could
only be redrawn immediately if the previous simulation kept all
their values - and why would it, if the signal was not required
to be drawn?

and for large projects, restarting the simulation
sometimes results in partially drawn or completely incorrect waveforms, and
can only be resolved by killing the simulation and rerunning.

That sounds like the same bug I'm seeing. Have you reported it?

Dave

 

[Ken Cecka]

In message <[email protected]>


I'm not sure this will turn out to be a bug. Added signals could
only be redrawn immediately if the previous simulation kept all
their values - and why would it, if the signal was not required
to be drawn?

Yes that makes sense.

That sounds like the same bug I'm seeing. Have you reported it?

I haven't yet. I need to boil it down to a minimal test case if possible, and haven't taken them time to do that yet. I have a couple of other defects like that on my TODO list. There's another one with partial association that crashes the simulation (don't recall if it's fuse or the simulation executable), but when I made a simple test case it worked fine And my favorite is when coregen cores spontaneously become blackboxed/unbound components until I regenerate them. I suppose I should probably submit webcases for these even without a simple testcase, but I've been on the receiving end of bug reports like that.

Ken

 

[Al Muliman]

Thanks for the confirmation. I'll submit a webcase as well if you don't get a positive response to yours.

Webcase submitted with the title 'Special colors for signal names with
"X", "U", or "Z". '

 

[Al Muliman]

If you post the CR# we can take turns opening webcases every few months to check
on its status!

772064