FPGA Central

I have a general question: is it safe to have a continuous assign
statement in a clock line, or does this introduce a race condition?

A certain simulation (which has an assignment in a clock line) passes in
ModelSim, but fails in ncsim (only when delay_mode is set to unit, as I
found out later).

Below is some code that I created to reproduce the error. Whatever I try
though, q1, q2 and q3 correctly clock in the data from before the rising
clock edge, so I'm not quite sure whether the assign im the clock is a
prolem or not.

Paul.



module assign_in_clk;
reg clk;
wire clk_1;
wire clk_2;
reg d1;
reg q1;
reg q2;
reg q3;

// Clock generator
//
initial
begin
clk = 1'b0;
repeat (10) #50 clk = !clk;
end

// Flipflops on normal clock
//
always @(posedge clk)
begin
q1 <= d1;
q3 <= q2;
end

// Flipflop on renamed clock (via assign statement)
//
always @(posedge clk_2)
begin
q2 <= q1;
end

// Data generator
//
initial
begin
d1 = 1'b0;
wait(clk == 1'b0);
repeat (5) #100 d1 = !d1;
end

// Assignments in clock
//
assign clk_2 = clk_1;
assign clk_1 = clk;
endmodule

Paul Uiterlinden wrote:
> I have a general question: is it safe to have a continuous assign
> statement in a clock line, or does this introduce a race condition?

It can certainly introduce a race condition. Actually, to be correct,
the design contains a race condition, and putting a continuous assign
in a clock path may cause it to be exposed, i.e. produce a different
result by changing the order that changes occur. In general, putting
a continuous assignment in a clock path may delay the output to a later
point in the same time slice.

> A certain simulation (which has an assignment in a clock line) passes
in
> ModelSim, but fails in ncsim (only when delay_mode is set to unit, as
I
> found out later).

Different results in different simulators indicates either a bug in one
of them, or a race condition in your design.

> Below is some code that I created to reproduce the error. Whatever I
try
> though, q1, q2 and q3 correctly clock in the data from before the
rising
> clock edge, so I'm not quite sure whether the assign im the clock is
a
> prolem or not.

Since your sample code uses nonblocking assignments, which introduce a
delay into the data path that is guaranteed to be greater than any
number
of zero-delay continuous assignments in series, it should not have any
races between clock and data.

Presumably your actual design is different from this sample code in
some way.

I dont see why there should be any race condition with this code. it
should work perfectly as though there was only a single clock 'clk'
since you are using non-blocking statements in the procedural blocks.
-Neo

sharp & Neo,

Thanks for your replies. Indeed, I now understand there must be a
difference between my little example and the real design (a netlist from
Synplify) and/or my testbench. Apparently there is some path via
blocking statements from the clock to some output. I will dig into this.

Paul.

Paul Uiterlinden wrote:
> sharp & Neo,
>
> Thanks for your replies. Indeed, I now understand there must be a
> difference between my little example and the real design (a netlist
from
> Synplify) and/or my testbench. Apparently there is some path via
> blocking statements from the clock to some output. I will dig into
this.
>
> Paul.

Is it possible that the unit delay mode is introducing a delay
in the assign statements (which would delay clk_2 two "units" after
clk)?

[email protected] wrote:
>
> Is it possible that the unit delay mode is introducing a delay
> in the assign statements (which would delay clk_2 two "units" after
> clk)?

Good suggestion, but I don't think so. Because then my little example
code would behave incorrectly when I set delay_mode to unit. I already
checked that: it does not. That's also why I put two assign statements
in the clock, to make sure it will fail if the assign statements are
affected by delay_mode.

Paul.

[email protected] wrote:
>
> Is it possible that the unit delay mode is introducing a delay
> in the assign statements (which would delay clk_2 two "units" after
> clk)?

I believe that the "correct" behavior for unit delay mode (as
defined by the behavior of Verilog-XL) is that zero delays
remain zero. Only non-zero delays become unit delays. And
I believe that NC implements it correctly.

So while it was a good suggestion, I don't think that is what
is happening.