cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
3,403 Views
Registered: ‎04-22-2017

inout port input constraint problem

Jump to solution

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.

 data read problem.JPG

 

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

0 Kudos
Reply
1 Solution

Accepted Solutions
Professor
Professor
5,717 Views
Registered: ‎08-14-2007

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":

 

-- Gabor

View solution in original post

counter_out delayed.png
2 Replies
Professor
Professor
5,718 Views
Registered: ‎08-14-2007

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":

 

-- Gabor

View solution in original post

counter_out delayed.png
3,286 Views
Registered: ‎04-22-2017

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!

0 Kudos
Reply