FPGA Central

1. In verilog, for continuous assignment, the assignee must be scalar
or vector net; for procedure assignment, the assignee cannot be scalar
or vector net; then for procedure continuous assignment, the assignee
can only be scalar or vector of registers. This is very confusing. I
can't quite see the logic behind such language design.

2. multiple event triggered always block updating same register
causing race condition or undefined behavior. e.g.

always @(posedge clock)
a = 1'b1;
always @(reset)
a = 1'b0;
If both reset turns high and clock turns high at the same time, what's
the result? I see code like this in text books which confuses me.

3. my understanding is that always statements is similar to
initial
forever statements

other than the practical reason always is preferred for looping
statements, any catch I don't see?

Thanks a lot!

Fei

This question is better to ask on comp.lang.verilog.
1. Yep, very confusing. Thus why with System Verilog, you have new rules
that don't care about where and what is assigned. type "logic" can be
assigned in both flows.

2. That is the point of text book examples. It is supposed to be
confusing. It is an example of what not to do. there are better ways to code
this and know exactly what the result would be. In this case if reset
changed value at the same time that clock had a posedge the final result
would depend on the order that the TOOL executed the blocks. There is no
defined garantee of which value would be written.

3. Logically the initial forever and always blocks appear to be similar. But
you would be hard pressed to find a synthesis tool that will turn a initial
forever construct into logic gates. For emulation there are some synthesis
tools that can map an initial forever block to gates. Another gotcha is when
is the block evaluated. The simulator must schedule events to happen. Based
on the LRM and the tool nvendors interpretation of the LRM the order I which
the initial blocks are evaluated and the always blocks are evaluated will
change the behavior of the simulation.

"Fei Liu" <[email protected]> wrote in message
news:[email protected]...
> 1. In verilog, for continuous assignment, the assignee must be scalar
> or vector net; for procedure assignment, the assignee cannot be scalar
> or vector net; then for procedure continuous assignment, the assignee
> can only be scalar or vector of registers. This is very confusing. I
> can't quite see the logic behind such language design.
>
> 2. multiple event triggered always block updating same register
> causing race condition or undefined behavior. e.g.
>
> always @(posedge clock)
> a = 1'b1;
> always @(reset)
> a = 1'b0;
> If both reset turns high and clock turns high at the same time, what's
> the result? I see code like this in text books which confuses me.
>
> 3. my understanding is that always statements is similar to
> initial
> forever statements
>
> other than the practical reason always is preferred for looping
> statements, any catch I don't see?
>
> Thanks a lot!
>
> Fei

> 2. That is the point of text book examples. It is supposed to be
> confusing. It is an example of what not to do. there are better ways to code
> this and know exactly what the result would be. In this case if reset
> changed value at the same time that clock had a posedge the final result
> would depend on the order that the TOOL executed the blocks. There is no
> defined garantee of which value would be written.

Yeah, my point is text book authors should avoid having such kind of
code in examples here and there, except to illustrate this is a bad
coding practice. But what I see is that authors feel it's acceptable
to write code like this. It annoys me.

On Mar 5, 7:57 pm, Fei Liu <fei....@gmail.com> wrote:
> > 2. That is the point of text book examples. It is supposed to be
> > confusing. It is an example of what not to do. there are better ways to code
> > this and know exactly what the result would be. In this case if reset
> > changed value at the same time that clock had a posedge the final result
> > would depend on the order that the TOOL executed the blocks. There is no
> > defined garantee of which value would be written.
>
> Yeah, my point is text book authors should avoid having such kind of
> code in examples here and there, except to illustrate this is a bad
> coding practice. But what I see is that authors feel it's acceptable
> to write code like this. It annoys me.

Icarus verilog interprets the posedge as "higher priorty" than the
reset changing (always@reset implies change, not just high or low).

The real question is how does the design compiler interpret this? I
think that rather than writing ambiguous behavioral code for the
design compiler to interpret as the book suggests, write it the
"normal way" as you would want it to synthesize:
always @ (posedge clock or negedge reset)
if you want an active low asynchronous reset.

The academics just want you to understand all corners of the language
I guess.

here's my test code:
//test.v
module counter(out, clk, reset);

parameter WIDTH = 8;

output [WIDTH-1 : 0] out;
input clk, reset;

reg [WIDTH-1 : 0] out;
wire clk, reset;

always @reset
out = 0;

always @(posedge clk)
out = 1;


endmodule // counter

//test_test.v
module test;

/* Make a reset that pulses once. */
reg reset = 0;
initial begin
# 5 reset = 1;
# 10 reset = 0;
# 5 reset = 1;
# 5 reset = 0;
# 100 $finish;
end

/* Make a regular pulsing clock. */
reg clk = 0;
always #5 clk = !clk;

wire [7:0] value;
counter c1 (value, clk, reset);

initial
$monitor("At time %t, reset %h value = %h (%0d)",
$time, reset, value, value);
endmodule // test

and run:
iverilog test.v test_test.v -o test & ./test