ISE Webpack 14.4 ISim - what am i doing wrong? - Page 1
Forum section: electronics / general

author: Kremmen
author_rank: Super Contributor
timestamp: March 24, 2013, 12:40:01 pm
content: I am running a testbed for a simple sin/cos lookup in ISim with no luck. The code appears to be OK, at least no errors/warnings. Simulation testbench however does not generate the stimulus the way i would assume.Below is the code for clock and stimulus processes. In the simulation trace i can see the clock cycling exactly as specified but the addr signal stays at 0 instead of incrementing.Is there something i am not seeing here?Code:BEGIN-- Instantiate the Unit Under Test (UUT)uut: sincoslookup PORT MAP (clk => clk,addr => addr,value => value);-- Clock process definitionsclk_process :processbeginclk <= '0';wait for clk_period/2;clk <= '1';wait for clk_period/2;end process;-- Stimulus processstim_proc: processbegin-- hold reset state for 100 ns.addr <= "00000000";wait for 100 ns;-- insert stimulus hereif (clk'event and clk = '0') thenaddr <= std_logic_vector( unsigned(addr) +1);end if;end process;END;

author: jahonen
author_rank: Super Contributor
timestamp: March 24, 2013, 01:01:42 pm
content: Problem is that the stimulus-generating process restarts on each iteration so addr will be always reset. Try adding a loop around the address increment:Code:BEGIN-- Instantiate the Unit Under Test (UUT)uut: sincoslookup PORT MAP (clk => clk,addr => addr,value => value);-- Clock process definitionsclk_process :processbeginclk <= '0';wait for clk_period/2;clk <= '1';wait for clk_period/2;end process;-- Stimulus processstim_proc: processbegin-- hold reset state for 100 ns.addr <= "00000000";wait for 100 ns;-- insert stimulus hereloopif (clk'event and clk = '0') thenaddr <= std_logic_vector( unsigned(addr) +1);end if;end loop;end process;END;regards,Janne

author: Kremmen
author_rank: Super Contributor
timestamp: March 24, 2013, 02:00:06 pm
content: Hmm, that is almost the one thing that never even crossed my mind. Thanks a lot - i will try that right away.Edit: tried that, but no cigar. The behavior is exactly the same. The addr signal stays at 0, never incrementing.

author: jahonen
author_rank: Super Contributor
timestamp: March 24, 2013, 03:09:12 pm
content: Well, maybe like this then:Code:-- insert stimulus hereloopwait until falling_edge(clk);addr <= std_logic_vector( unsigned(addr) +1);end loop;I must admit that I really haven't ever done it like I posted above. Hopefully this time it will work. Notice that std_logic_1164 package contains a nice edge function(s) which you can use instead of the longer and obscure clk'event and clk='0' form.Regards,Janne

author: Kremmen
author_rank: Super Contributor
timestamp: March 24, 2013, 04:16:45 pm
content: The falling_edge form is certainly nicer to type and read so i think that is the way i will go in the future.However, this did not solve the issue, although it did change the end result.Now ISim has turned all input signals to U, even the clock and further, it complains that the simulation object is not traceable because ISim does not support constant and generic multi-dimensional arrays. WTF? What use is it if it can't simulate even this trivial case? Or is there again some mysterious construct that i am missing?The (probably) offending element is the actual lookup table, a constant array of 256 elements, of type std_logic_vector(7 downto 0), initialized to values between "00000000" and "11111111". The synthesizer is happy with this declaration, but ISim croaks.

author: jahonen
author_rank: Super Contributor
timestamp: March 24, 2013, 04:51:39 pm
content: Sounds strange, I tried it with Altera ModelSim starter edition and it seemed to work just fine as expected. I guess that ISim has its quirks.If you give signals initial values, does it change anything? like this:signal addr : std_logic_vector(7 downto 0) := (others => '0');Regards,Janne

author: Kremmen
author_rank: Super Contributor
timestamp: March 24, 2013, 08:18:06 pm
content: Actually the addr signal was initialized just like you suggest.Suspecting things i rolled the clock change back an sure enough, now the simulator give U to all inputs even with the previous code, which it didn't do earlier.I have seen this before and it is extremely frustrating because there doesn't seem to be any logic why the damn thing behaves like this.

author: nctnico
author_rank: Super Contributor
timestamp: March 24, 2013, 10:31:04 pm
content: Why are the loop / end loop there? Those look suspicious. I suspect your reset doesn't work as expected.I'd make a seperate reset signal and use that to reset addr. Furthermore I always write addr <= addr +1. From the expression the types are obvious to the synthesizer.

author: jahonen
author_rank: Super Contributor
timestamp: March 25, 2013, 06:46:38 am
content: Quote from: nctnico on March 24, 2013, 10:31:04 pmIf this would be a code to be synthesized, I'd agree, but it is my understanding that this is "testbench"-type code, where one can use all structures allowed by VHDL syntax. At least the ModelSim Altera edition had no problems with it.Regards,Janne

author: Kremmen
author_rank: Super Contributor
timestamp: March 25, 2013, 10:26:06 am
content: Yes this is the code for the testbench so there is no need to be able to actually synthesize this one. All legal VHDL constructs are OK.On the other hand the expression addr = addr +1 does not work at all. ISE complains that it cannot resolve the '+' operator so the type is not obvious, or at least the expression does not resolve.Explicitly typecasting does work and as far as i understand, the end result is the same.Somehow these simple things get very contorted in VHDL but i guess that's where you end when the requirement is to synthesize a circuit based on the expressions. The lack of support for constant arrays was a big disappointment however. That doesn't seem so hard to do.----Late breaking news: Curiouser and curiouser. When i discarded the incrementing part altogether, just setting addr <= "00001111"; ISim didn't show the change. Addr still lies at 0, not reacting to the assignment at all. However, removing the clock from around the assignment allowed it to go through so the value was finally visible in ISim. And the lookup value correctly reflected the address. So the complaint regarding lack of support for constant arrays was some kind of bullshit, ISim supports this one at least no problem.Now to discover how to actually increment the f-ing addr %-B.Blood pressure decreasing at least marginally, however.

author: jahonen
author_rank: Super Contributor
timestamp: March 25, 2013, 10:49:16 am
content: Well, these kind of discoveries do not exactly make me any less reluctant to try out Xilinx stuff if even the simulator breaks on little things like these. I can vaguely remember that a Xilinx representative visited us and told how great their new simulator is (they had ditched ModelSim recently back then). It seems that they have some issues to work out.Regards,Janne

author: jahonen
author_rank: Super Contributor
timestamp: March 25, 2013, 10:52:53 am
content: Quote from: Kremmen on March 25, 2013, 10:26:06 amDefining addr signal as unsigned instead of std_logic_vector should work but then you must do the type conversion in uut instantiation port map.Regards,Janne

author: nctnico
author_rank: Super Contributor
timestamp: March 25, 2013, 05:10:01 pm
content: Quote from: Kremmen on March 25, 2013, 10:26:06 amWeird. I have been using addr <= addr +1; for more than 10 years and ISE never complained. Maybe because of the included libraries.Back to your problem: how about the process sensitivity list? Shouldn't clk be put in there?

author: jahonen
author_rank: Super Contributor
timestamp: March 25, 2013, 05:58:03 pm
content: This worked fine also (more like it how I would have done it), does this work with ISim?Code:library ieee;use ieee.std_logic_1164.all;use ieee.numeric_std.all;entity tb_test_2 isend entity;architecture tb of tb_test_2 issignal addr : std_logic_vector(7 downto 0) := (others => '0');signal clk : std_logic := '0';signal reset : std_logic := '1';BEGIN-- Clock process definitionsclk_process: process(clk)constant clk_period : time := 10 ns;beginclk <= not clk after clk_period/2;end process;reset <= '1', '0' after 100 ns;-- Stimulus processstim_proc: process(clk, reset)beginif reset = '1' thenaddr <= (others => '0');elsif rising_edge(clk) thenaddr <= std_logic_vector( unsigned(addr) +1);end if;end process;END;

author: Kremmen
author_rank: Super Contributor
timestamp: March 25, 2013, 07:30:08 pm
content: How blind can one be to the obvious. It was exactly the thing ntnico asked about: the clock. Of course the stimulus process should be sensitive to it, how else can the addr be clocked - duh.By the way, if addr is defined as integer then the simple addition should of course work, but i have insisted on keeping it std_logic_vector to ensure synthesis later.jahonen's stimulus initalization is considerably more elegant than mine and my only defense is that i never quite got that far before getting tangled in this no update issue. But now that this is more or less solved i am happy to stea^H^H^H^H re-use the better code in my workbenches.Thanks guys. You have been a real help in solving this and i am only embarrassed how trivial the real issue turned out to be. Oh well, life is.P.S. ISim too is much less broken when you feed it something that actually works

author: Kremmen
author_rank: Super Contributor
timestamp: March 28, 2013, 07:47:43 am
content: Quote from: nctnico on March 25, 2013, 05:10:01 pmI thought this weird as well and sure enough - i had omitted the ieee.std_logic.unsigned from the testbed. Silly me. Now it works as expected - finally.