System Verilog simulation versus execution

Question

Much ado is made about SystemVerilog (SV) being used for both programming chips and simulating SV code. This economy of language constructs has caused a bit of confusion for me: Section 9.2.2 of the SV Reference states

"There are four forms of always procedures: always, always_comb, always_latch, and always_ff. All forms of always procedures repeat continuously throughout the duration of the simulation."

Certainly, though, these constructs also specify the creation of combinatorial and latched logic. So is the SV standard aimed mainly at simulation, leaving it up to the chip OEMs to advise customers which SV constructs will result in actual hardware, as Altera has done here ?

Altera makes CPLDs and FPGAs, some of which are not too expensive (hence my drive to learn SV). That subset of SV constructs blessed by Altera as synthesisable would compile in Quartus into a form suitable for downloading to a chip. Altera labels other constructs, such as many assertions (section 16 of the above reference), as "Supported. Ignored for synthesis." with concurrent assertions as an example.

So my conclusion, pending new information gained here, is that I may use, for instance, concurrent assertions for a test bench module only, but immediate assertions can be used anywhere.

Basically I am trying to get a picture of how SV works, and how I may best interpret the SV standard, quoted above. Thanks.

Answer 1

The Verilog languages are quite low level so when designing hardware for FPGA or ASIC we have combinatorial logic and sequential logic. Assertions in any tools are really for verification, the concept is to high level to be able to get the hardware you want.

SystemVerilog is not just for simulation, but using the correct subset for design will allow RTL and a post synthesis gates file to match in simulation. The way you write SystemVerilog design will determine what the synthesis tools generate. Flip-flops and latches will only be created if you have implied them. Different tools may optimise the combinatorial sections differently but if written using best practices then they should all be functionally equivalent.

Verilog in a day gives a guide on design. The SystemVerilog LRM does not split the spec between synthesisable components and verification but the unofficial guide to synthesising SystemVerilog is a good guide.

To the part of the question regarding usage of the different always blocks.

From Verilog we have:

always @*             // For combinatorial logic
always @(posedge clk) // For flip-flops (sequential) Logic

Implying a latch involved an incomplete if/else branch and was quite difficult tell if it was a accident or actually intended.

//Latch from bug or actually intended?
always @* begin
  if (enable) begin
    //..
  end
end

System verilog has kept the simple always for backwards compatibility with verilog code but added three types so the designer can be explicit in there design intent.

always_comb  //For Combinatorial logic
always_latch //For implying latches
always_ff    //For implying flip-flops (sequential logic)

always_comb has stricter rules than always @* for triggering in simulation to further minimise RTL to Gate level simulation mismatch.