Modelsim simulations and VHDL process senstivity List...Request for Advice.

[Mirzaaur]

Dear all,

I need you advice about a strange behavior of the Modelsim 6.5 SE for a VHDL based design.

question: if the sensitivity list of a process is not listed with all internally used signal why Modelsim doesn't let the process to trigger assuming that clock is in sensitivity list then it must trigger the process on next clock edge taking account of new value of the signal?

I did simulation for similar design using NC-Launch and it works fine but not in Modelsim 6.5 SE.

Please advise me if there is any specific settings in Modeslim so it should account for all signals in the process being in sensitivity list and trigger with clock?

I hope I am clear enough in my question!!

best regards,

Mirzaaur

 

[TrickyDicky]

If it is sensitive to clock, and you have followed the synchronous template properly, you dont need to have other signals in the sensitivity list, only the clock (and reset if you want an async reset).

Why dont you post the code you're having problems with?

 

[shnain]

Hello,

In synthesizable logic, there is 2 options :

Either your process is clocked, then in sensivity list you have only the asynchronous reset and the clock.
Or the process is combinational then you have to include all used signals in the sensivity list.

For behavioral code (Test Bench, models ...) you can use process with no sensivity list by using WAIT statement.

In all these cases, the simulator should work correctly.

Hope I was clear !

If you still have problems please provide your code, maybe you have a hidden issue ?

Yours.

 

[Mirzaaur]

Dear TrickyDicky and Shnain,
first of thanks a lot for you time to reply my question.

>>"If it is sensitive to clock, and you have followed the synchronous template properly, you dont need to have other signals in the sensitivity list, only the clock (and reset if you want an async reset)."

precisely this is what my understanding is and used topology in the design.

"Why dont you post the code you're having problems with?"

I wish I could but this design contains almost 50+ vhdl files and this malfuntion is observed only when simulating top level. same design simulated in NC Launch (NC sim) works perfectly fine.

I am trying to play around the optimization stuff dne by Modelsim. I will update as soon as I get a fix for it .

Dear Shanin,

"If it is sensitive to clock, and you have followed the synchronous template properly, you dont need to have other signals in the sensitivity list, only the clock (and reset if you want an async reset)."

I found in Modelsim 6.5SE , while doing functional simulation (RTL) code, if any signal is missing in sensitivity list at some stage a malfunction appears in simulation. netlist (after PnR) same design works fine since those process are already converted to edge sensitive FFs.

once again , I am grateful for you kind replies, I will update about it once I reached to a conclusion.

best regards,

Mirzaaur

 

[TrickyDicky]

This is the standard synchronous template, are you using it?

process(clk, reset)
begin
  if reset = '1' then
    --async reset
  elsif rising_edge(clk) then
    --do logic
  end if;
end process;

Also, are you doing funny things with your clocks in the design that cause extra delta delays, mening data wont actually do quite what you expect. Here is an example that would work fine when synthesised, but will cause errors in simulation:

library ieee;
use ieee.std_logic_1164.all;

entity play_tb is
 
end entity;
  
architecture rtl of play_tb is
  signal clk1, clk2 : std_logic := '0';
  signal data1, data2 : std_logic := '0';
  signal input : std_logic;
begin
  
  clk1 <= not clk1 after 10 ns;
  
  --clk1 is a system clock:
  
  input <= '0', '1' after 25 ns;
  
  clk2 <= clk1;
  
  process(clk1)
  begin
    if rising_edge(clk1) then
      data1           <= input;
    end if;
  end process;
  
  
  process(clk2)
  begin
    if rising_edge(clk2) then
      data2           <= data1;
    end if;
  end process;
  
end rtl;

In simulation it will appear that data2 is connected directly to input, but when synthesised it will be a registered version of data1. This is because of the extra delta delay you have applied to clk2, making the rising edge actually occur after the rising edge of clk1, so that when process2 sees a rising edge, data1 will have already changed.

The answer to this - dont re-assign your clocks inside a

 

[Mirzaaur]

Dear TrickyDicky,

thanks a lot for your prompt reply and response.

finally i figured out what the mess was going in the simulations:-

the test bench was reading a text file to inject a serial bit stream, this bit stream was supposed to feed into a fifo 32 bit to cross into a different clock domain. the data valid signal was getting in short sometimes due to different paths of the the state machine and result was occasional error in the simulation.

mystery that why it was always working in the NC Launch was due to a slightly different version of a package file which was defining the default delays used foe the state machine .......... ufffffffffffffffffffffffff

thanks once again ..... I will go to bed shortly .......!!!!

ciao ciao,

Mirzaaur

 

[shnain]

library ieee;
use ieee.std_logic_1164.all;

entity play_tb is
 
end entity;
  
architecture rtl of play_tb is
  signal clk1, clk2 : std_logic := '0';
  signal data1, data2 : std_logic := '0';
  signal input : std_logic;
begin
  
  clk1 <= not clk1 after 10 ns;
  
  --clk1 is a system clock:
  
  input <= '0', '1' after 25 ns;
  
  clk2 <= clk1;
  
  process(clk1)
  begin
    if rising_edge(clk1) then
      data1           <= input;
    end if;
  end process;
  
  
  process(clk2)
  begin
    if rising_edge(clk2) then
      data2           <= data1;
    end if;
  end process;
  
end rtl;

but when synthesised it

@TrickyDicky: are you sure this code is synthesisable ?! :shock:

 

[TrickyDicky]

No, sorry, but if you re-assign the clock internally and have 2 processes running off the two different clocks, the simulation would not match the synthesised version.

 

[Mirzaaur]

sorry for late reply, i was away an traveling.

you are right that "if you re-assign the clock internally and have 2 processes running off the two different clocks, the simulation would not match the synthesised version"

the problem was in when clk1 captures that data it uses a different configurable delay as compared the one in Modelsim so the simulation gets into error for the data blocks exceeding the buffering time.

thanks and best regards,
mirzaaur