Timing Analysis

[johnathan_smith]

This is a problem carried over from another thread of mine.

https://forums.xilinx.com/t5/Timing-Analysis/inout-port-OFFSET-IN-constraint-problem/td-p/761764/highlight/false/page/2

I have a design like this (check the attachments for full code, UCF & test bench)..

data_in <= data when (readwrite = '0' and reset = '0') else (others =>'0');

process(clk,reset)

.

.

if(reset = '1') then
.
.
elsif(clk'event and clk = '1') then
.

    if(readwrite = '0') then

        counter <= data_in;

    end if;
.
counter_out <= counter;
end if;

"data" is an inout port & it's value is fed into "counter" if the flag "readwrite" is 0, i.e. in read mode. In this mode, I have a constraint that the "data" port's value must be registered only after 9ns from the rising clock edge, which is done through this line in the UCF.

NET "data[*]" TNM = "DATA_GROUP";
TIMEGRP "DATA_GROUP" OFFSET = OUT 12.5 ns AFTER "clk" RISING;

TIMEGRP "DATA_GROUP" OFFSET = IN 11 ns VALID 20 ns BEFORE "clk" RISING;

When I simulate my design via a test bench, I can see that the input is actually being registered before the 9 ns mark.

 

Now, as you can see from the post-P&R timing diagram, at the 9 ns mark as pointed to by the 2nd cursor, the value of "data" is 10101010 but at the end of that clock cycle/start of the next clock cycle, you can see that the value of "counter_out" is 01010101 which is the value before the 9 ns mark.

If the data port was read at the 9ns mark as specified by the constraint,
TIMEGRP "DATA_GROUP" OFFSET = IN 11 ns VALID 20 ns BEFORE "clk" RISING;

shouldn't the value at the end of that clock cycle be 10101010?

Thanks,

John

interface.vhd ‏3 KB

interface.ucf ‏2 KB

inout_test_tb.vhd ‏4 KB

[gszakacs · Accepted solution]

The issue is that you have a two-stage pipeline due to the following line being inside the clocked process:

counter_out <= counter;

When I ran behavioral simulation I saw the same issue, so it's not a timing issue.  It's the way you defined the logic.  "counter" updates to the correct value at the clock edge, but "counter_out" only follows "counter" on the following clock edge.  You probably wanted the above line to be outside the process.  Here's a snap from behavioral simulation showing both "counter" and "counter_out":

[gszakacs · Accepted solution]

The issue is that you have a two-stage pipeline due to the following line being inside the clocked process:

counter_out <= counter;

When I ran behavioral simulation I saw the same issue, so it's not a timing issue.  It's the way you defined the logic.  "counter" updates to the correct value at the clock edge, but "counter_out" only follows "counter" on the following clock edge.  You probably wanted the above line to be outside the process.  Here's a snap from behavioral simulation showing both "counter" and "counter_out":

[johnathan_smith]

Thank you!

I did the required changes based on what you pointed out & carried them over to my main project as well. Both worked as expected.

Thanks again for all your help!