Is ' wen_dly <= #TCQ 1'b0;' synthesisable?

[Robert Willy]

Hi,

I am very curious about whether the below code is synthesis-able?
From the translate_on switch, it does look like OK.


BTW, this code is for a Xilinx FPGA. From what I knew in the past,
a code having absolute delay number cannot be synthesized.

Can you explain it to me?


Thanks,



//synthesis translate_on

// model the delays for ram write latency

wire wen_int;
wire [12:0] waddr_int;
wire [71:0] wdata_int;

generate if (RAM_WRITE_LATENCY == 1) begin : wr_lat_2
reg wen_dly;
reg [12:0] waddr_dly;
reg [71:0] wdata_dly;

always @(posedge user_clk_i) begin
if (reset_i) begin
wen_dly &lt;= #TCQ 1'b0;
waddr_dly &lt;= #TCQ 13'b0;
wdata_dly &lt;= #TCQ 72'b0;
end else begin
wen_dly &lt;= #TCQ wen;
waddr_dly &lt;= #TCQ waddr;
wdata_dly &lt;= #TCQ wdata;
end
end

assign wen_int = wen_dly;
assign waddr_int = waddr_dly;
assign wdata_int = wdata_dly;
end

 

[Allan Herriman]

On Fri, 29 Dec 2017 16:23:52 -0800, Robert Willy wrote:

Hi,

I am very curious about whether the below code is synthesis-able? From
the translate_on switch, it does look like OK.


BTW, this code is for a Xilinx FPGA. From what I knew in the past,
a code having absolute delay number cannot be synthesized.

Can you explain it to me?

Absolute delays like that are synthesisable in the sense that the
synthesis tool will ignore the delay, i.e. treat it as if the delay was 0.

Delays are often done like that in Verilog (and VHDL for that matter) to
model an anticipated physical delay during RTL simulation, perhaps in a
clock domain crossing circuit such as a FIFO where the exact delay might
affect functionality.

Sometimes delays are added to HDL source to work around simulation races
caused by improper choice of blocking / non-blocking assignments.

Regards,
Allan

 

[Gabor]

On Friday, 12/29/2017 8:09 PM, Allan Herriman wrote:

On Fri, 29 Dec 2017 16:23:52 -0800, Robert Willy wrote:

Hi,

I am very curious about whether the below code is synthesis-able? From
the translate_on switch, it does look like OK.


BTW, this code is for a Xilinx FPGA. From what I knew in the past,
a code having absolute delay number cannot be synthesized.

Can you explain it to me?


Absolute delays like that are synthesisable in the sense that the
synthesis tool will ignore the delay, i.e. treat it as if the delay was 0.

Delays are often done like that in Verilog (and VHDL for that matter) to
model an anticipated physical delay during RTL simulation, perhaps in a
clock domain crossing circuit such as a FIFO where the exact delay might
affect functionality.

Sometimes delays are added to HDL source to work around simulation races
caused by improper choice of blocking / non-blocking assignments.

Regards,
Allan

In Xilinx land, delays after a clock are often necessary to deal
with simulation models for Xilinx primitives that have internal
buffer delays on their clocks. Newer models typically don't have
this issue, but I've been bitten in the past by dual-port memory
models whose internal clock delay made them behave like they
didn't have a register delay when reading, at least in behavioral
simulation. Adding even a tiny delay helped fix this bug in the
model.

One thing I've used such delays for is to make causality a bit
clearer when looking at waveforms in behavioral simulation.

--
Gabor

 

[Allan Herriman]

On Fri, 29 Dec 2017 21:03:07 -0500, Gabor wrote:

On Friday, 12/29/2017 8:09 PM, Allan Herriman wrote:
On Fri, 29 Dec 2017 16:23:52 -0800, Robert Willy wrote:

Hi,

I am very curious about whether the below code is synthesis-able? From
the translate_on switch, it does look like OK.


BTW, this code is for a Xilinx FPGA. From what I knew in the past,
a code having absolute delay number cannot be synthesized.

Can you explain it to me?


Absolute delays like that are synthesisable in the sense that the
synthesis tool will ignore the delay, i.e. treat it as if the delay was
0.

Delays are often done like that in Verilog (and VHDL for that matter)
to model an anticipated physical delay during RTL simulation, perhaps
in a clock domain crossing circuit such as a FIFO where the exact delay
might affect functionality.

Sometimes delays are added to HDL source to work around simulation
races caused by improper choice of blocking / non-blocking assignments.

Regards,
Allan


In Xilinx land, delays after a clock are often necessary to deal with
simulation models for Xilinx primitives that have internal buffer delays
on their clocks. Newer models typically don't have this issue, but I've
been bitten in the past by dual-port memory models whose internal clock
delay made them behave like they didn't have a register delay when
reading, at least in behavioral simulation. Adding even a tiny delay
helped fix this bug in the model.

I've been bitten by that too, but not for several years. These days I
don't use any unisim libraries earlier than ISE 14.7.

The names of the signals in the OP's example (all relating to RAM inputs)
should have hinted to me what was really going on. At least you picked
it up; I must be getting old or something.

Allan

 

[Kevin Neilson]

In Xilinx land, delays after a clock are often necessary to deal
with simulation models for Xilinx primitives that have internal
buffer delays on their clocks. Newer models typically don't have
this issue, but I've been bitten in the past by dual-port memory
models whose internal clock delay made them behave like they
didn't have a register delay when reading, at least in behavioral
simulation. Adding even a tiny delay helped fix this bug in the
model.

One thing I've used such delays for is to make causality a bit
clearer when looking at waveforms in behavioral simulation.

--
Gabor

I had the same issue using the BRAM unisims and had to put delays in the HDL to get the model to operate properly. What a pain.