How to solve red lines in modelsim when timing simulation with VHDL?

Hi Albert,

It's been 10 years since I've used it, so I'm only going off memory.

You need to initialize all input signals - I cannot recall if that's only from a file, or if you can optionally also do it from the graphical interface. If you do not have clock or reset signals then you cannot set them of course. However, regardless of design (combinational or clocked) you need to have some starting value for the inputs. If you're still stuck, you might want to consult the documentation. If that doesn't help, consult old Xilinx ISE documentation, because I think they used a cut-down version of Modelsim.

Thaks for your answer,I think I have already initialize all input signlas when defining input/output signals.But it gives out 'U',and red lines in the middle of timing simulation,actually,the delay seems abnormal(about more than 10ns),as shown in the figure blow:

AND is it convenient for you to help me check the files attached at your spare time,or anybody else?

Anyway,thanks you very much!

--Here is the design block:8-bit phase multiplier
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity mult_nbits is
      generic(n:integer:=8);
      port(multiplicand,multiplier:in std_logic_vector(n downto 1);
            multiplication:out std_logic_vector(2*n downto 1));
end mult_nbits;

architecture  behave of mult_nbits is
signal sig:std_logic_vector(2*n downto 1);
begin
     sig<=conv_std_logic_vector(0,n) & multiplicand;
      process(sig,multiplier)
      variable var:std_logic_vector(2*n downto 1);
      begin
            var := (others => '0');
            for i in 1 to n loop
                 if (multiplier(i) = '1') then
                      var:=var+to_stdlogicvector(to_bitvector(sig) sll (i-1));
                 end if;
            end loop;
            multiplication<=var;
      end process;
end behave;

Then it's testbench(maybe the cause of red lines problems)

LIBRARY ieee;                                               
USE ieee.std_logic_1164.all;
                                
ENTITY mult_nbits_vhd_tst IS
END mult_nbits_vhd_tst;

ARCHITECTURE mult_nbits_arch OF mult_nbits_vhd_tst IS 
SIGNAL multiplicand : STD_LOGIC_VECTOR(8 DOWNTO 1):=x"00";
SIGNAL multiplication : STD_LOGIC_VECTOR(16 DOWNTO 1):=x"0000";
SIGNAL multiplier : STD_LOGIC_VECTOR(8 DOWNTO 1):=x"00";
COMPONENT mult_nbits
      PORT (
            multiplicand : IN STD_LOGIC_VECTOR(8 DOWNTO 1);
            multiplication : BUFFER STD_LOGIC_VECTOR(16 DOWNTO 1);
            multiplier : IN STD_LOGIC_VECTOR(8 DOWNTO 1)
            );
END COMPONENT;

BEGIN
      i1 : mult_nbits
      PORT MAP (
                 multiplicand => multiplicand,     
                 multiplication => multiplication,     
                 multiplier => multiplier     
                 );
     
init : PROCESS                                                                                 
BEGIN
      wait for 50 ns;

      multiplier<="00001111";
      multiplicand<="00001111";
      assert(multiplication/="0000000011100000")
      report "error"
      severity error;
      wait for 50 ns;

      multiplier<="11111111";
      multiplicand<="11111111";
      assert(multiplication/="1111111000000001")
      report "error"
      severity error;
      wait for 50 ns;

      multiplier<="10101010";
      multiplicand<="01010101";  
      assert(multiplication/="0011100001110010")
      report "error"
      severity error;
                                                      
WAIT;                                                       
END PROCESS;
END mult_nbits_arch;

First point - you are using

1. use ieee.std_logic_arith.all; 
2. use ieee.std_logic_unsigned.all; 

Don't !!!

Use IEEE.NUMERIC_STD.all;

Look it up on the web to find out why.

Because you are using a generally deprecated non standard library it's even harder for me to understand you code than otherwise.

The simulator looks as if its going through your process many times with an assumed 1ns delay and the first time something is unitialised- I don't think that's what you want. It may be a quirk of the simulator - for loops can make cascades of logic and the simulator will process them in order.

Your code is very hard to read, like really really hard !

Spaces are free: so put spaces between things write a <= b rather than a<=b

Use indentation, it helps with understanding.

And use comments !

I have never (as far as I can remember) looked at code I wrote a few years ago and thought "Pity I wasted time on all these comments", but I have often thought some comments made at the time would have saved me hours later !

Finally - I can't work out what the for loop is doing and I'm not sure that the simulator can: (some comments would help me, they won't bother the simulator).

what is varvar (line 21) and why are some things red, some blue and some black ?

Try showing some more data (like var) in the simulation plot.

MK

Thanks for your kindness ! It's very useful for me . I have learned a lot from your answer .

As for the problems in the code :

1 . It's an error in line 21 , the varvar should be var .

2 .There maybe something wrong with the website , I can't re-edit the line 21 , "varvar" seems can't be corrected .

Anyway , I would correct the style of coding , use indentation and comments .

Rion

God information, but you missed the most important point from Micheal's post.

More data is required to get closer to a solution.

Please re-run the simulation and show 'var' in the timing plot. Asll single bits of the signals would be helpful too, not just the 16-bit signal vector.

Also, please zoom in, where 'multiplication' changes from green to red at ~4 ns.

Thanks.

- W.

To be honest , I have almost quit the design . It's really annoying . I can't find where to upload the files in this website(maybe it's more convenient) .

Whether sloved or not , thank you very much !

Rion

I poked your code into my simulator (Aldec HDL) and once I'd fixed varvar it  compiled OK.

Same basic results as Modelsim, but none of the funny business when the data changes.

My test bench is basically yours but with the Aldec generated wrapper:

library ieee;
use ieee.STD_LOGIC_UNSIGNED.all;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;

    -- Add your library and packages declaration here ...

entity mult_nbits_tb is
    -- Generic declarations of the tested unit
        generic(
        n : INTEGER := 8 );
end mult_nbits_tb;

architecture TB_ARCHITECTURE of mult_nbits_tb is
    -- Component declaration of the tested unit
    component mult_nbits
        generic(
        n : INTEGER := 8 );
    port(
        multiplicand : in STD_LOGIC_VECTOR(n downto 1);
        multiplier : in STD_LOGIC_VECTOR(n downto 1);
        multiplication : out STD_LOGIC_VECTOR(2*n downto 1) );
    end component;

    -- Stimulus signals - signals mapped to the input and inout ports of tested entity
    signal multiplicand : STD_LOGIC_VECTOR(n downto 1);
    signal multiplier : STD_LOGIC_VECTOR(n downto 1);
    -- Observed signals - signals mapped to the output ports of tested entity
    signal multiplication : STD_LOGIC_VECTOR(2*n downto 1);

    -- Add your code here ...

begin

    -- Unit Under Test port map
    UUT : mult_nbits
        generic map (
            n => n
        )

        port map (
            multiplicand => multiplicand,
            multiplier => multiplier,
            multiplication => multiplication
        );

    -- Add your stimulus here ...  
init : PROCESS                                                                                   
BEGIN  

wait for 50 ns;  

multiplier<="00001111";  
multiplicand<="00001111";  
assert(multiplication/="0000000011100000")  
report "error"  
severity error;  
wait for 50 ns;  

multiplier<="11111111";  
multiplicand<="11111111";  
assert(multiplication/="1111111000000001")  
report "error"  
severity error;  
wait for 50 ns;  

multiplier<="10101010";  
multiplicand<="01010101";    
assert(multiplication/="0011100001110010")  
report "error"  
severity error;  
                                                    
WAIT;                                                         
END PROCESS;  

end TB_ARCHITECTURE;

configuration TESTBENCH_FOR_mult_nbits of mult_nbits_tb is
    for TB_ARCHITECTURE
        for UUT : mult_nbits
            use entity work.mult_nbits(behave);
        end for;
    end for;
end TESTBENCH_FOR_mult_nbits;

   library ieee;  
    use ieee.std_logic_1164.all;  
    use ieee.std_logic_arith.all;  
    use ieee.std_logic_unsigned.all;  


entity mult_nbits is  
      generic(n:integer:=8);  
      port(multiplicand,multiplier:in std_logic_vector(n downto 1);  
            multiplication:out std_logic_vector(2*n downto 1));  
end mult_nbits;  

--}} End of automatically maintained section


      
      
architecture  behave of mult_nbits is  
signal sig:std_logic_vector(2*n downto 1);  
begin  
     sig<=conv_std_logic_vector(0,n) & multiplicand;  
      process(sig,multiplier)  
      variable var:std_logic_vector(2*n downto 1);  
      begin  
            var := (others => '0');  
            for i in 1 to n loop  
                 if (multiplier(i) = '1') then  
                      var:=var+to_stdlogicvector(to_bitvector(sig) sll (i-1));  
                 end if;  
            end loop;  
            multiplication<=var;  
      end process;  
end behave; 

Not sure if this helps you much.

MK

Hello Rion,

Don't give up and thanks for sending the detailed timings.

It seems that the variables var and sig are missing the initial values and are undifined, which is represented by the red lines. They are only updated at the 1st wait statement.

Try in the architecture for mult_nbits:

signal sig:std_logic_vector(2*n downto 1) := (others => '0'); 

variable var:std_logic_vector(2*n downto 1) := (others => '0'); 

Micheal,

your result looks quasi identical, the simulator behaviour seems to be different, processing all combinational logic statements are processed at once without a minimal time step.

Good luck,

- Wolfgang.

wolfgangfriedrich  wrote:

 

your result looks quasi identical, the simulator behaviour seems to be different, processing all combinational logic statements are processed at once without a minimal time step.

 

I've never used ModelSim much but I thought that the whole idea of a 'for' loop in VHDL is that the content within it was combinatorial and processed simultaneously - I'll have to check now if such behavior is optional or an Aldec interpretation.

MK

michaelkellett, yes the for loop generates multiple combinatorial statements in parallel. This must be behavioural differences in the simulator architecture. I would guess again that Modelsim might have a setting with a minimal time step even between instructions, exploding the simulation time when set to a very small value, from the plot is seems to be ~100psec.

Reults are the same, so reality wins again.

- W.