sequential vs combinatorial logic (Verilog and VHDL)

Question

Is this true to say that the following Code-1 and Code-2 are equivalent in Verilog:

Code 1

always@(posedge Clock or B or C) 
 begin
   if (B)
    A <= 0;
   else if (C)
    A <= 1; 
 end 

Code 2

 always@(posedge Clock or B or C) 
 begin
   if (B)
    A <= 0;
   else if (C)
    A <= 1; 
   else
    A <= A;
 end 

Is the same thing also true in VHDL?

Code-3

process (clk, preset, reset) 
 begin  
  if (preset = ‘1’) then 
   ff <= ‘1’; 
  elsif (reset = ‘1’) then 
   ff <= ‘0’; 
  elsif (clk=’1’ and clk’event) then 
   ff <= ff_d; 
 endif; 
end process

Code-4

process (clk, preset, reset) 
 begin  
  if (preset = ‘1’) then 
   ff <= ‘1’; 
  elsif (reset = ‘1’) then 
   ff <= ‘0’; 
  elsif (clk=’1’ and clk’event) then 
   ff <= ff_d;
  else
   ff <= ff; 
 endif; 
end process

Could we also say Code-3 and Code-4 are the same?

How about the same thing about a combinatorial logic ? Can we say the followings are equivalent (Verilog example)?

code-5

  always @ ( * ) begin
    if ( Trigger ) begin
      A = Pass ;
    end
  end

code-6

  always @ ( * ) begin
    if ( Trigger ) begin
      A = Pass ;
    end
    else begin 
     A = A;
    end
  end

Could we also say Code-5 and Code-6 are the same? f

Answer 1

1. Code-1 and Code-2 are the same, but messy.
2. Brian Drummond has answered that Code-3 and Code-4 are the same.
3. Code-5 and Code-6 are the same, and both contain the same mistake.

Code-1 and Code-2 update based Gregs comments
The use of always@(posedge Clock or B or C) is messy because it combines edge triggered and level triggered.

You may want a combinatorial block always @*, the * gives you an automatically compiled sensitivity list (less bugs, easier refactoring). While learning there is sometimes the idea of purposefully giving an incomplete sensitivity list to get the simulation behaviour you want, Do not do this for RTL. When synthesised you will get the behaviour of always @*.

To imply sequential or flip-flop use edge triggered ie

// Flip-flop sync or no reset
always @(posedge clk) begin 

//Flip-flop with async active-low reset.
always @(posedge clk or negedge rst_n) begin

//Flip-flop with asyn active-low reset and async set
always @(posedge clk or negedge rst_n or posedge set) begin

As Greg has also noted from at least 2001 comma , separated lists can be used instead of or.

Code-5 and Code-6 imply combinatorial blocks, which maintain state this implies a latch.

Latches are not inherently bad but require a touch of caution therefore accidental ones are often cause for concern and many bugs.

A flip-flop is two latches one after the other with a clock inversion. This means that only 1 of the 2 latches is open at a given point. A single latch when enabled is transparent.

If a latch is open and closes on near the updating data (posedge of a clock), timing uncertainties mean that you may latch the old data or the new data.

A typical way to control this is to have open the latch on the first half of the clock and close it for the second half. This ensures the Latch hold the Output value at the time when the input is to be updated. Often using a full cycle enable to operate a clock gate to generate the enable signal for the latch.

Answer 2

The basic answer to your question is true of both VHDL and Verilog. If you trace every possible path through your 'process' (and everything essentially decomposes to a 'process', in both VHDL and Verilog), and a 'signal' is not assigned to in one or more paths, then that signal holds its value in those paths. It has to, because you haven't assigned to it. It doesn't make any difference if you explicitly add an assignment which says 'assign the signal to itself', because this is the same as not assigning to the signal at all (assuming that your code isn't sensitive to delta-delays, you haven't done anything fancy with manually-specified delays, and so on). It doesn't make any difference if the process is interpreted as being clocked or combinatorial.

One of the comments refers to an SO thread where someone suggests that a form which an explicit assignment may synthesise to a gated-clock rather than a gated-data implementation. I don't buy this, and I'd like to see an example.

Having said all that, you need to stick with conventional synthesis templates to get something that you know will synthesise as intended, rather than just simulating correctly. Note also that your snippets #1 and #2 are useless, and are not equivalent to #3/#4 - there's no data input. and there's nothing wrong with latches, as long as your tool flow can cope with them (ie. do timing analysis on them). And you don't need al lthe brackets in the VHDL, use rising_edge, etc.