asynchronous reset signal in sensitive list

[bravoegg]

signal ab is an synchronous signal, can it be used in a sensitive list to reset signal c immediately?
Does this style violate any rules?

I took part in a training program and the teacher says it's ok, as long as the signal ab is not combinational logic, and preferably the signal ab be a signal register bit.

always@(posedge clk)begin
    ab <= b;
end

always@(posedge clk or negedge ab)begin
    if(~ab)
         c <= 0;
    else
         c <= 1'b1;
end

 

[vGoodtimes]

As a concept, it is odd to intentionally create an async reset that is actually a sync reset. It should be ok, but you should see glitches in simulations. clk has to update ab, and then ab has to update c.

 

[TrickyDicky]

As a concept, it is odd to intentionally create an async reset that is actually a sync reset. It should be ok, but you should see glitches in simulations. clk has to update ab, and then ab has to update c.

Its not that odd. Most altera devices have no sync resets on their flops, so sync resets have to be emulated with logic. All flops have async reset though - their design guides says async resets should be asynchronously asserted and synchronously de-asserted.

 

[FvM]

As a concept, it is odd to intentionally create an async reset that is actually a sync reset.

The Verilog always construct describes an asynchronous reset. You might say that it's odd in some way that an asynchronous input is described by a negedge event. The synthesis template for a edge triggered register with asynchronous reset is more convention than straightforward language in my view, just take it as granted.

 

[ads-ee]

The Verilog always construct describes an asynchronous reset. You might say that it's odd in some way that an asynchronous input is described by a negedge event. The synthesis template for a edge triggered register with asynchronous reset is more convention than straightforward language in my view, just take it as granted.

Well it is perfectly legal to write the following code:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
always @(posedge clk, rstn) begin
  if (rstn) begin
    q <= 1'b0;
  end else begin
    q <= d;
  end
end

---

Though synthesis tools might not balk at coding the reset this way, you may end up with a simulation/synthesis mismatch if you rely on the rising edge of rstn causing the q <= d update during simulation. Another issue with this is that simulation will enter the always block when the value of rst changes either H, L, X, or Z so it will have a slight impact on simulation performance.

Using negedge rstn only enters the always block when the reset begins (asynchronously) not when it exits, which makes sense if you think about it.

 

[FvM]

Well it is perfectly legal to write the following code

Yes, it's legal Verilog code but usually not accepted by synthesis tools that rely on the well known register with asynchronous reset template.

Altera Quartus e.g gives

Error (10122): Verilog HDL Event Control error at xxx: mixed single- and double-edge expressions are not supported

for both variants

always @(posedge clk, reset)

and

always @(posedge clk or reset)

I have no problems to somehow read sense into posedge reset, but as previously mentioned, it's just convention, doesn't really matter if with good reasons or not.

I usually bring in IEEE 1364.1 Standard for Verilog Register Transfer Level Synthesis when discussing about synthesizable register modeling templates, but don't want to repeat things again and again. There are quite a lot previous threads about the topic at Edaboard.