1. Home
  2. Field-Programmable Gate Arrays
  3. question about verilog language constructs

question about verilog language constructs

  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.

  1. 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.

  1. 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

Reply to
Fei Liu
Loading thread data ...

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.

  1. 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.

  2. 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.
Reply to
Dwayne Dilbeck

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.

Reply to
Fei Liu

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

Reply to
lm317t

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.