Continue to Site

# Inconsistent Post-Route simulation (ISE)

Status
Not open for further replies.

#### HyperText

##### Junior Member level 2
Hi,

I created an 8bit Barrel Shifter and now I want to simulate it using Xilinx ISE tools, specifically I want to do a Post-Route simulation (the last step).

I do these steps:
1. Synthesize - XST
2. Implement Design
3. I check the "Synthesis Report" and find: "Minimum period: 3.281ns (Maximum Frequency: 304.785MHz)"

Now when I create a test bench and set the clock period to 10ns (100MHz) it works fine.
Then when I set the clock period to 4ns (250MHz) it doesn't work fine. Here it is a screenshot:

Why I get those red signals?
When I run the simulation with a >= 7ns clock period it all works fine... Is this a discrepancy in the Synthesis Report? Or should I consider other reports?

Last edited:

#### K-J

Hi,

I created an 8bit Barrel Shifter and now I want to simulate it using Xilinx ISE tools, specifically I want to do a Post-Route simulation (the last step).

I do these steps:
1. Synthesize - XST
2. Implement Design
3. I check the "Synthesis Report" and find: "Minimum period: 3.281ns (Maximum Frequency: 304.785MHz)"

Now when I create a test bench and set the clock period to 10ns (100MHz) it works fine.
Then when I set the clock period to 4ns (250MHz) it doesn't work fine. Here it is a screenshot:
View attachment 84543
Why I get those red signals?
I assume that 'shift' is an input. If so, the changing of 'shift' relative to the clock is likely an error ('enable' is also in error). Those signals appear to be changing at the same time as the rising edge of the clock which means that it will be violating a setup or hold time requirement. Also, it appears that the output actually starts changing prior to the clock edge which really means that it is actually changing long after the preceding rising edge of clock.
When I run the simulation with a >= 7ns clock period it all works fine... Is this a discrepancy in the Synthesis Report? Or I should consider other reports?
- First you must enter input and output delay constraints. I suspect you didn't do this since you're only looking at clock frequency in your posting.
- Re-run the timing analysis. I suspect you'll see that you really can't run at the speed you would like because of the I/O pin timing constraints
- Model your inputs so that they adhere to the input delays that you specified in the first step. Otherwise you're violating the timing requirements so you should expect the design to not work which is what the simulation will show you as well.

Kevin Jennings

HyperText

### HyperText

Points: 2

#### HyperText

##### Junior Member level 2
Shift, data_in, reset and enable are inputs. The only output is data_out.
However you are right, thanks for the answer.

I changed my test bench and now the inputs don't change at the same time of the rising edge of the clock.
This is a simulation running with a 4ns clock period:

It seems working fine, except the delay of the output... isn't it?

By the way this is the test bench code I tried:
Code:
      -- hold reset state for 100 ns.
wait for 100 ns;

wait for clk_in_period*10;

enable <= '1';
reset <= '0';

data_in <= "10110110";

wait for clk_in_period*2;

shift <= "000"; -- shift 0: 10110110
wait for clk_in_period;

shift <= "001"; -- shift 1: 01101101
wait for clk_in_period;

shift <= "010"; -- shift 2: 11011010
wait for clk_in_period;

shift <= "100"; -- shift 4: 01101011
wait for clk_in_period;

shift <= "111"; -- shift 7: 01011011

wait;

Is this correct?

#### barry

Your maximum synthesis frequency is one thing, your post-place-and-route max is totally different. What is the maximum frequency in THAT report? What is your constraint?

HyperText

### HyperText

Points: 2

#### TrickyDicky

well theres a problem. You're waiting for specified clock periods, rather than specific clock edges. You're probably assigning the inputs just before the rising edge of the clock, so things arnt timing corectly. to wait for specified numbers of clock edges, use a for loop:

Code:
for i in 1 to 10 loop --waits for 10 clocks
wait until rising_edge(clk);
end loop;

#### HyperText

##### Junior Member level 2
You are right.
I tried with a 20ns clock constraint and this is the Post-PAR Timing Report:
All constraints were met.

Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)

Clock to Setup on destination clock clk_in
---------------+---------+---------+---------+---------+
| Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
clk_in | 3.489| | | |
---------------+---------+---------+---------+---------+

Timing summary:
---------------

Timing errors: 0 Score: 0 (Setup/Max: 0, Hold: 0)

Constraints cover 64 paths, 0 nets, and 97 connections

Design statistics:
Minimum period: 3.489ns{1} (Maximum frequency: 286.615MHz)

Status
Not open for further replies.