ISE Webpack 14.4 ISim - what am i doing wrong?

[Kremmen]

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: [Select]

BEGIN
 
-- Instantiate the Unit Under Test (UUT)
   uut: sincoslookup PORT MAP (
          clk => clk,
          addr => addr,
          value => value
        );

   -- Clock process definitions
   clk_process :process
   begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
   end process;
 

   -- Stimulus process
   stim_proc: process
   begin
      -- hold reset state for 100 ns.
addr <= "00000000";
      wait for 100 ns;


      -- insert stimulus here
if (clk'event and clk = '0') then
addr <= std_logic_vector( unsigned(addr) +1);
end if;

   end process;

END;


[jahonen]

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: [Select]

BEGIN
 
-- Instantiate the Unit Under Test (UUT)
   uut: sincoslookup PORT MAP (
          clk => clk,
          addr => addr,
          value => value
        );

   -- Clock process definitions
   clk_process :process
   begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
   end process;
 

   -- Stimulus process
   stim_proc: process
   begin
      -- hold reset state for 100 ns.
addr <= "00000000";
      wait for 100 ns;


      -- insert stimulus here
        loop
    if (clk'event and clk = '0') then
    addr <= std_logic_vector( unsigned(addr) +1);
    end if;
    end loop;

   end process;

END;

regards,
Janne

[Kremmen]

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.

[jahonen]

Well, maybe like this then:

Code: [Select]

      -- insert stimulus here
        loop
          wait 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

[Kremmen]

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.

[jahonen]

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

[Kremmen]

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.

[nctnico]

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.

[jahonen]

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.

If 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

[Kremmen]

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  .

[jahonen]

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

[jahonen]

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.

Defining 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 

[nctnico]

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.

Weird. 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?

[jahonen]

This worked fine also (more like it how I would have done it), does this work with ISim?

Code: [Select]

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity tb_test_2 is
end entity;

architecture tb of tb_test_2 is

signal addr : std_logic_vector(7 downto 0) := (others => '0');
signal clk : std_logic := '0';
signal reset : std_logic := '1';

BEGIN

  -- Clock process definitions
  clk_process: process(clk)
    constant clk_period : time := 10 ns;
  begin
    clk <= not clk after clk_period/2;
  end process;

  reset <= '1', '0' after 100 ns;

  -- Stimulus process
  stim_proc: process(clk, reset)
  begin
    if reset = '1' then
      addr <= (others => '0');
    elsif rising_edge(clk) then
      addr <= std_logic_vector( unsigned(addr) +1);
    end if;
  end process;

END;

[Kremmen]

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

[Kremmen]

[...]
Weird. I have been using addr <= addr +1; for more than 10 years and ISE never complained. Maybe because of the included libraries.
[...]

I 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.