0
\$\begingroup\$

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.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Regarding your VHDL sensitivity list, general verilog simulation isn't deterministic, VHDL simulation is: insights.sigasi.com/opinion/jan/vhdls-crown-jewel.html \$\endgroup\$
    – DonFusili
    Jul 15, 2019 at 13:03
  • \$\begingroup\$ 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. \$\endgroup\$
    – Bort
    Jul 15, 2019 at 13:49
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – DonFusili
    Jul 15, 2019 at 13:57
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Dave Tweed
    Jul 15, 2019 at 14:05

1 Answer 1

2
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ 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? \$\endgroup\$
    – Bort
    Jul 15, 2019 at 17:35
  • \$\begingroup\$ @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. \$\endgroup\$ Jul 15, 2019 at 17:39
  • \$\begingroup\$ @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. \$\endgroup\$
    – Bort
    Jul 15, 2019 at 18:12
  • \$\begingroup\$ 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. \$\endgroup\$
    – Dave Tweed
    Jul 15, 2019 at 18:21
  • \$\begingroup\$ 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. \$\endgroup\$
    – Bort
    Jul 15, 2019 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.