arrrrg!

K

Ken Cecka

Guest
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
 
On Feb 14, 12:01 am, Ken Cecka <cec...@alumni.washington.edu> wrote:
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
Click to expand...
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
 
On 14-02-2009 06:01, Ken Cecka wrote:
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
Click to expand...
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,
Click to expand...
I cannot. But then what do I know.
 
On 14-02-2009 08:29, Al Muliman wrote:
On 14-02-2009 06:01, Ken Cecka wrote:
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 ;-)
Click to expand...
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.
 
On 14-02-2009 08:53, Al Muliman wrote:
If this is an undocumented feature then I suppose it is just one more
reason to use ModelSim.
Click to expand...
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.
 
Al Muliman a écrit :
On 14-02-2009 08:53, Al Muliman wrote:
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.
Click to expand...
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
 
On Sat, 14 Feb 2009 09:14:45 +0100, Al Muliman <nospam@noway.no> wrote:

On 14-02-2009 08:53, Al Muliman wrote:
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.
Click to expand...
Can you create a simple example and submit a Webcase?

- Brian
 
On 14-02-2009 14:51, Nicolas Matringe wrote:
So what if the name contains both Z and X (or U)? Just curious... ;-)
Click to expand...
X and U beat Z ;-)

I suppose H, W and L also receive a special treatment.
Click to expand...
Not that I can tell.
 
On 14-02-2009 14:56, Brian Drummond wrote:

Can you create a simple example and submit a Webcase?
Click to expand...
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 :process
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;
 
Al Muliman wrote:

On 14-02-2009 14:56, Brian Drummond wrote:

Can you create a simple example and submit a Webcase?

Example created, webcase access pending. :)
Click to expand...
Thanks for the confirmation. I'll submit a webcase as well if you don't get a positive response to yours.

Ken

------------------------ 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 :process
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;
Click to expand...
 
In message <resll.181$Bl.138@nwrddc01.gnilink.net>
Ken Cecka <ceckak@alumni.washington.edu> wrote:

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?
Click to expand...
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
 
Dave Higton wrote:

In message <resll.181$Bl.138@nwrddc01.gnilink.net
Ken Cecka <ceckak@alumni.washington.edu> wrote:

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.
Click to expand...
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.
Click to expand...
Thus far, I've only worked with GHDL and isim, so I don't have a particularly high bar to measure against.

A new version is expected to be released around April.

Dave
Click to expand...
 
In message <DQFll.262$Bl.26@nwrddc01.gnilink.net>
Ken Cecka <ceckak@alumni.washington.edu> wrote:

Dave Higton wrote:

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
Click to expand...
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.
Click to expand...
That sounds like the same bug I'm seeing. Have you reported it?

Dave
 
Dave Higton wrote:

In message <DQFll.262$Bl.26@nwrddc01.gnilink.net
Ken Cecka <ceckak@alumni.washington.edu> wrote:

Dave Higton wrote:

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

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?
Click to expand...
Yes that makes sense.

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?
Click to expand...
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
 
On Sat, 14 Feb 2009 20:03:09 GMT, Ken Cecka <ceckak@alumni.washington.edu>
wrote:

Al Muliman wrote:

On 14-02-2009 14:56, Brian Drummond wrote:

Can you create a simple example and submit a Webcase?

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.
Click to expand...
Nice test case and thanks Al for submitting.

A positive response is a week or so of back-and-forth followed by a Change
Request.

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

- Brian
 
On Sat, 14 Feb 2009 20:29:23 GMT, Ken Cecka <ceckak@alumni.washington.edu>
wrote:

Dave Higton wrote:

In message <resll.181$Bl.138@nwrddc01.gnilink.net
Ken Cecka <ceckak@alumni.washington.edu> wrote:

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.

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...)
Click to expand...
My experience too - though either it's been improving or I'm learning where not
to tread (don't return access types from functions, use OUT parameters instead,
etc) ISIM is definitely a work in progress.

But before Xilinx's new hush-hush policy, one of its developers took part here,
and it sounded as if Xilinx actively want to make it work properly.

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.
There seem to be a whole raft of issues in this area.
There are - the horizontal scroll bar being another fine example.
Click to expand...
(Linux and Windows may be different in terms of the wave viewer)

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,
Click to expand...
I haven't had this. If I add signals, of course they aren't drawn in the
existing sim. However if I run the sim further, they are drawn from the point
where I added them.

However, I find it dramatically faster than ModelSim.
Click to expand...
Interesting; I'd say it's reasonably fast but haven't tried it against Modelsim
directly. Another poster rated it as (3-5x) slower, but I think he was factoring
in a long compilation process for a tiny simulation run; typically I run a sim
for much longer than it takes to compile.

It IS ...
cross-platform
cross-language (though with issues connecting std_logic to Verilog!)
Smart-model compliant

and in my experience it (the unlimited version) runs the PCIe examples perfectly
well, though this is not officially supported by Xilinx.

It is mainly held back from running EDK sims by a crippling ISE bug in handling
VHDL libraries. This currently takes a LOT of fiddling to work round (I have
used ISIM for one EDK PPC project), but that is slated for fix in ISE 11.

- Brian
 
On 14-02-2009 21:03, Ken Cecka wrote:
Al Muliman wrote:

On 14-02-2009 14:56, Brian Drummond wrote:

Can you create a simple example and submit a Webcase?
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.

Webcase submitted with the title 'Special colors for signal names with
Click to expand...
"X", "U", or "Z". '
 
On 15-02-2009 14:35, Brian Drummond wrote:
On Sat, 14 Feb 2009 20:03:09 GMT, Ken Cecka <ceckak@alumni.washington.edu
wrote:
Al Muliman wrote:
On 14-02-2009 14:56, Brian Drummond wrote:
Can you create a simple example and submit a Webcase?
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.
If you post the CR# we can take turns opening webcases every few months to check
on its status!
772064 :)
Click to expand...
 
Brian Drummond wrote:
On Sat, 14 Feb 2009 20:29:23 GMT, Ken Cecka <ceckak@alumni.washington.edu
wrote:

snip
Click to expand...
A pedant writes....

My experience too - though either it's been improving or I'm learning where not
to tread (don't return access types from functions, use OUT parameters instead,
etc) ISIM is definitely a work in progress.

procedures surely, not functions?
Click to expand...

Alan


--
Alan Fitch
Doulos
http://www.doulos.com
 
On Fri, 27 Feb 2009 11:15:45 +0000, Alan Fitch <alan.fitch@spamtrap.com> wrote:

Brian Drummond wrote:
On Sat, 14 Feb 2009 20:29:23 GMT, Ken Cecka <ceckak@alumni.washington.edu
wrote:

snip
A pedant writes....


My experience too - though either it's been improving or I'm learning where not
to tread (don't return access types from functions, use OUT parameters instead,
etc) ISIM is definitely a work in progress.

procedures surely, not functions?
Click to expand...
Almost...

Functions originally, returning Line (= access to string). Nothing fundamentally
wrong with that, worked for years in Modelsim, but ISIM raises SEGV (or Access
Violation on Windows).

Changed to procedures with OUT parameters, which doesn't crash the tool and is,
errr, functionally equivalent.

- Brian
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top