UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
12,658 Views
Registered: ‎07-13-2014

Behavioral simulation is right, timing simulation is wrong

Jump to solution

Hello,

 

I have written some vhdl code for a circuit that monitors two categories of input signals. If any signal changes in one category, it outputs an index (0 or 1) to indicate in which category the changed signal works. When I run behavioral simulation everything runs fine. When I try timing simulation (after implementing the design), the outputs are wrong no matter how fast or slow the clock is. I have tried everything (even writing better vhdl code), but it does not work.

 

In the attched files, there is my circuit, the testbench I am using and the behavioral and timing simulation.

 

Please take a look at them,

thanks a lot

 

behavioral.jpg
timing.jpg
0 Kudos
1 Solution

Accepted Solutions
Professor
Professor
23,584 Views
Registered: ‎08-14-2007

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

OK, I just saw the problem.  Look at this process:

 

    process(clk)
    begin
        if low = '1' then
            temp <= '0';
        elsif high = '1' then
            temp <= '1';
        else
            temp <= temp;
        end if;
    end process;

 

The process only has a dependency on "clk" however there is no edge event.  So synthesis will ignore the sensitivity list and the process becomes combinatorial so in effect "temp" becomes a latch.  Latches of this type do not synthesize well in a Xilinx fabric.  I assume you meant this process to be synchronous to the clock like:

 

    process(clk)
    begin
      if rising_edge(clk) then
          if low = '1' then
              temp <= '0';
          elsif high = '1' then
              temp <= '1';
          else
              temp <= temp;
          end if;
      end if;
    end process;

 

-- Gabor

View solution in original post

0 Kudos
8 Replies
Professor
Professor
12,638 Views
Registered: ‎08-14-2007

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

I can see two issues right away:

 

1) Your code uses a single input register (buffB58 for instance) to both delay and synchronize the input to the clock.  If the input signal is not already synchronous to the clock, this won't work.  When you compare the input (e.g. async B58) to the register's output (e.g. buffB58) you need to meet setup time to the next flop.  This will not be possible if B58 was not already synchronous to the clock.

 

2) Your stumulus starts immediately at the beginning of simulation.  For timing simulation, you need to wait 100 nS for global set/reset (GSR) to de-assert before applying stimulus.  Library models will not respond to stimulus while GSR is active.

-- Gabor
0 Kudos
Adventurer
Adventurer
12,628 Views
Registered: ‎07-13-2014

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

Thank you @gszakacs for your answer.

 

It's true that my input signals are not synchronous to the clock. Could you please give me an example how to make them synchronous? B58 for example. What should I add to my code?

0 Kudos
Professor
Professor
12,624 Views
Registered: ‎08-14-2007

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

You can just add another signal which implements the input stage register like:

 

signal synB58 : std_logic;

 

Then in the first clocked process:

 

  process(clk)
  begin
    if (clk'event and clk = '1') then

      synB58 <= B58;

      buffB58 <= synB58;

 

and further down:

 

  changeB58 <= synB58 xor buffB58;

 

Note that this fix has nothing to do with metastability.  If you need high reliability, it would be better to add two input synchronization stages rather than just the one I show above.  The first stage could be considered "dirty" as it could become metastable (this happens very infrequently) which means it would take longer to settle to a known value after the clock edge.  The second stage would sample this "dirty" stage one cycle later so it would only have metastability issues if the first stage stayed dirty for most of a clock period.  It's also a good idea to add an async_reg attribute to your input registers.  For now, the code I posted above should help you get past timing simulation issues assuming you also fix the test bench to delay the start of stimulus by 100 ns.  For use in hardware, the second register stage and async_reg attributes will provide a more robust design.

-- Gabor
0 Kudos
Adventurer
Adventurer
12,594 Views
Registered: ‎07-13-2014

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

Hello @gszakacs

 

Thank you for your anwers. both of them were really helpful. I made my input synchronous to the clock and added a "wait for 100 ns" line into my testbench. I attached the improved code for reference. Now, timing simulation is close to correct, but it still faces an issue. The "index" waveform goes from 0 to 1 correctly but it goes down to 0 quickly (pulses are too narrow). Is that a metastability problem? Or a code problem?

 

Thanks in advance for your time.

beh_imprv.jpg
timing_imprv.jpg
0 Kudos
Professor
Professor
12,572 Views
Registered: ‎08-14-2007

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

Metastability is not modeled in simulation.  I would suggest adding the intermediate signals "low" and "high" to the waveform view to see if you can spot something wrong.  If I had to guess, one difference is that because your synXX and bufXX signals initialize to zero in post translate, and your index starts at "1001", you will detect a "change" in the index signals as soon as GSR is released causing a pulse on "low".  This pulse happens much later in post-translate simulation because of GSR.  You only posted a small clip of the simulation waveform.  Do the pre- and post-translate simulations start to match at later times?

-- Gabor
0 Kudos
Adventurer
Adventurer
12,568 Views
Registered: ‎07-13-2014

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

Hello @gszakacs,

 

I tried delaying the start of the simulation. I replaced the line "wait for 100 ns" with "wait for 1200 ns". As you can see, I get exactly the same behavior. The "low" pulse seems ok, and it indicates that "index" pulses could be wider. (Unfortunately I could not locate "high" pulse in Isim. Maybe it is renamed or something).

 

I really appreciate your help

del.jpg
0 Kudos
Professor
Professor
23,585 Views
Registered: ‎08-14-2007

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

OK, I just saw the problem.  Look at this process:

 

    process(clk)
    begin
        if low = '1' then
            temp <= '0';
        elsif high = '1' then
            temp <= '1';
        else
            temp <= temp;
        end if;
    end process;

 

The process only has a dependency on "clk" however there is no edge event.  So synthesis will ignore the sensitivity list and the process becomes combinatorial so in effect "temp" becomes a latch.  Latches of this type do not synthesize well in a Xilinx fabric.  I assume you meant this process to be synchronous to the clock like:

 

    process(clk)
    begin
      if rising_edge(clk) then
          if low = '1' then
              temp <= '0';
          elsif high = '1' then
              temp <= '1';
          else
              temp <= temp;
          end if;
      end if;
    end process;

 

-- Gabor

View solution in original post

0 Kudos
Adventurer
Adventurer
12,546 Views
Registered: ‎07-13-2014

Re: Behavioral simulation is right, timing simulation is wrong

Jump to solution

@gszakacs

 

Thank you so much for your help. Your answers were accurate and very detailed. I really appreciate it.

 

Thanks a lot.

0 Kudos