# Are Verilog always blocks synthesized so that the sensitivity list items are settled by the time the block behavior is carried out?

In other words, if signal goes high and triggers the always block, will the block be synthesized in a way that the behavior in the if (signal)... block is reliably performed (since signal is now high)? Or will this behavior only be reliably performed after a clk rising edge when signal is already high?

always @ (posedge clk, posedge signal)
begin
if (signal)
begin
// do stuff
end
end


I've simulated similar code in Active-HDL, showing that // do stuff is performed after a signal rising edge.

My prior experience with HDL makes me uneasy about this code, but I'm new to Verilog and wanted to clear up any misconceptions.

Related questions:

• Is synthesis of code like this vendor-specific?
• Are VHDL sensitivity lists handled in a markedly different way?

I am trying to implement something like a SPI slave peripheral, so the two important inputs are the chip select and the clock. Since the clock will only ever be used a relatively long time before and after the chip select changes state, I'm using them both in the sensitivity list with the chip select being essentially an asynchronous set, as you suggest. Ordinarily I'd bring signals in synched with a shift reg to sequence behavior, but I don't have access to a particularly fast clock, so I'm trying to understand better to create a safe way to sequence things.

• Regarding your VHDL sensitivity list, general verilog simulation isn't deterministic, VHDL simulation is: insights.sigasi.com/opinion/jan/vhdls-crown-jewel.html – DonFusili Jul 15 '19 at 13:03
• What about synthesis? Can I not expect consistent behavior of the code in the example from vendor to vendor? It seems crazy that consistent behavior of the same code would not be part of the spec. – schadjo Jul 15 '19 at 13:49
• It's not crazy, HDLs are just that: description languages. Tool vendors will work hard to deliver consistent synthesis and simulation results, and you can expect them as long as you don't stray too far from general coding idioms. Consistent is not necessarily the same as what you expect, though. – DonFusili Jul 15 '19 at 13:57
• You can't build hardware that depends on two separate clocks (i.e., edges on two different signals), except in the specific idiom in which one of them is used strictly as an asynchronous set/reset. Even then, the HDL does not capture all of the details about the hardware timing, such as setup/hold times and reset recovery times. That's why you also need static timing analysis. – Dave Tweed Jul 15 '19 at 14:05

Since the clock will only ever be used a relatively long time before and after the chip select changes state, I'm using them both in the sensitivity list with the chip select being essentially an asynchronous set...

Yes, that's fine. But there are no guarantees. If the SPI master violates the setup/hold timing of CS with respect to CLK, there's nothing you can do about it.

Is synthesis of code like this vendor-specific?

No, not normally.

Are VHDL sensitivity lists handled in a markedly different way?

The syntax is different, but in the end, they both represent the same hardware.

• Still, if a positive edge of signal triggers the always block, there is no way to know the state of signal without doing timing analysis? – schadjo Jul 15 '19 at 17:35
• @schadjo This strikes me as an odd question. You shouldn't be using an edge-trigger signal as part of combinational logic inside the same block. – Elliot Alderson Jul 15 '19 at 17:39
• @Elliot - I agree with you, but it's not clear why this is prohibited beyond thou-shalts and hand-waving. If signal will always be high when the block behavior occurs, always be low, or is not knowable, great, but which is it, and why? So far I have not seen a satisfactory answer in my reading and asking. – schadjo Jul 15 '19 at 18:12
• The only thing that a clocked always block guarantees (i.e., the "block behavior" in your terms) is that certain variables (FFs) will be updated when the clock edge occurs. Whether they get updated with valid values depends on the logic around those FFs, and whether that logic meets the timing constraints of the FFs. THAT's what static timing analysis tells you. It's starting to sound as if you've made your question so abstract that you yourself don't understand what it really means. Perhaps you should provide a more concrete example of what you're talking about. – Dave Tweed Jul 15 '19 at 18:21
• Haha, it is totally true I don't know what I'm talking about, but every pearl of wisdom helps. Let me put together a more informative edit. – schadjo Jul 15 '19 at 18:31