05-27-2017 02:43 AM
This is a problem carried over from another thread of mine.
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
05-28-2017 01:51 PM
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":
05-28-2017 01:51 PM
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":
05-31-2017 01:17 AM
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!