Simulation and Verification

[alperucar]

Post-route simulation as well as the actual design on my Virtex-5 FPGA (verified by chipscope) does not delay a desired signal by half clock cycle. Here is my code:

module half_delay (
            write_en, // incoming signal
            reset_n,
            clk,
            read_en // needs to be delayed by half clock cycle
        );       
output reg read_en;
input write_en, clk, reset_n;

always @(negedge clk)
begin
    if (!reset_n)   read_en <= 1'b0;
    else              read_en <= write_en;
end
endmodule

and my UCF file:

NET "clk" TNM_NET = "clk";
TIMESPEC TS_clk = PERIOD "clk" 16 ns HIGH 50 %;
NET "clk" SLEW = FAST;
NET "write_en" SLEW = FAST;

I've tried to use AREA_GROUP constraint in the UCF file.. No difference..

Bizzarely, when the process starts with always @(negedge clk), the actual dealy is 1 full clock cycle. When the process uses always @(posedge clk),  the actual dealy is 1 and a half clock cycle:

Also, regardless of the statement always @(negedge clk) / always @(posedge clk), XILINX tools seem to synthezise the very same circuit:

Am I missing something here?

Many Thanks,

Alper

[graces]

With negedge, the synthsized result would look the same except that at the FF's clk pin, there's an inverter symbol. That means the input clock will be inverted before connecting to the FF.

Regarding the post-PAR simulation result, remember it takes delay into account. The 'read_en" you observed is an output port signal. It's driven by the FF's output. So there's delay between them. Please refer to the following figure.

The signals below "read_en_FF" divider are the ones for the always statement.

"I" is sourced from "write_en" and "CLK" is inverted "clk". "O" is the "read_en" which drives output port.

[alperucar]

graces, many thanks for your reply. At my end, the delay between the external clock (@62.5 MHz) and the output of the clock buffer (clk_bufgp) is 2.5 ns, the delay between the external input and buffered input (write_en_ibuf_35) is 880 ps, and the delay between FF output (s_read_en_off_off1) and buffered output (read_en) is 2.5 ns. Even when you take the output of the buffered clock (clk_bufgp) as reference, the delay between the falling edge of that and the FF output (s_read_en_off_off1) is almost 2.2 ns!

 

With these relatively large delays, it is impossible to implement a stable system working at 62.5 MHz, which shouldn't be the case for an FPGA built in 65nm process. The workround is to change the design according to the delays indicated in the post-route simulation, but how reliable is that?

Many Thanks

Alper