Is it necessary to seperate combinational logic from sequential logic while coding in VHDL, while aiming for synthesis?

Question

I am working on projects which requires synthesis of my RTL codes specifically for ASIC development. Given the case, how much important is it, to separate sequential logic from differential logic while designing my RTLs ? And if it is important, then what should be my approach while designing, as if how should I differentiate my design for sequential and combinational logic?

Answer 1

I generally will separate sequential and combinational as much as possible until it results in too much code (which is usually rare, and possibly an indication of a poor design), or when something just makes more sense (which again is rare, but happens).

This segregation usually aids in initial design, brain->rtl->synthesis (what you think you're making is actually what is synthesized), CDC evaluation for multiclock designs, verification, and other things as well. It's hard for me to give a great example of something bad versus something I would call good, but here is a stab at it.

Say I have a counter that I want to reset on a certain value. I could do this (which I tend to see from people who have a strong software and/or FPGA background)

always @(posedge clk or posedge reset) begin
    if(reset) begin
        count <= 0;
    end else begin
        if((count == reset_count_val) || (~enable)) count <= 0;
        else                                        count <= count + 1;
    end
end

Or I would do this (which is what I would personally do):

//Combinational Path
assign count_in = enable ? ((count == reset_count_val) ? 4'd0 : count_in + 4'd1) : 4'd0;

//Sequential Path
always @(posedge clk or posedge reset) begin
    if(reset) count <= 4'd0;
    else      count <= count_in;
end

The above I would agree is more typing, and to some, more difficult to read. It does however split up the circuit in a way that allows me to easier see what happens on each clock edge. I know that "count_in" is being setup prior to the posedge of clk. I can easily see (as well as anyone else looking at the code) that I would expect a MUX for the reset or addition of count based on the reset_count_val, with a final MUX for gating the count based on the enable signal. Now you could see the same with the first bit of code, however IMO it's not as clear. When you look at a sim, you can see what count_in looks like prior to the rising edge of the clk. This could aid you if the conditional statement for the count_in was rather complex.

Let's say you sent this through synthesis and place and route and you get a timing violation between the Q of the count reg and the D of the count reg (since you have a loopback based on the addition). It would generally be easier to see which path is causing the issue with the 2nd batch of code. This depends on the tool (Primetime more than likely). CDC could also be easier because let's say that reset_count_val is coming from a static registers in another clock domain. The tool may try to synthesize/elaborate the OR in the 1st batch of code thinking the reset_count_val and enable are somewhat related giving you a weird looking CDC violation. Again, sometimes it's hard to come up with an example that exercises all of the "why you shouldn't do this" type of cases.

As an example about splitting combinational and sequential, I inherited a design where someone had a state machine that was written with the combiational and sequential in the same block (always @(posedge clk) where the if/else's would get deep and have next state logic in it). I'm no genius, but after days of staring at that thing and running sims, I could just not figure out what it was doing. It was quite large as well. I simply redid the design, keeping the same algorithm, but splitting up the logic in the format I described here. Even with me adding some features, the size went down ~15%. Other engineers who had the same problem of being lost with the other design, could now understand what was going on with it. This won't always be the case, but more than often it is.

TLDR; I try to be extremely descriptive when designing RTL that is to be used in an ASIC. The more abstract the code, the more likely it is to build something you don't want, or is more complex than needed. Verification is often much easier, particularly when you get to gate sims. While I am in the camp of "the less code the better" that is not always the case with verilog, especially on an ASIC.

Answer 2

In general, I would not hesitate to mix combinational with sequential logic. I come from an IC design background and have always mixed up combinational logic with sequential. I think that you are restricting yourself too much if you don't and are not fully using the power of your logic synthesiser.

For example, here is how I would design a simple, asynchronously-reset counter in VHDL:

  process (Clock, Reset)
  begin
    if Reset = '1' then
      Cnt <= (others => '0');
    elsif Rising_edge(Clock) then
      if Enable = '1' then
          Cnt <= Cnt + 1;
      end if;
    end if;
  end process;

This style of writing a counter in VHDL is ubiquitous. I personally can see no advantage to splitting the code up into two separate processes, one sequential the other combinational. I have just taught a room full of engineers to design a counter in exactly this way.

Here are some exceptions. I would split the combinational logic from the sequential logic if:

i) I were designing a state machine:

There is what I think is a really elegant way of coding a state machine, where you do split the combinational logic from the sequential:

  Registers: process (Clock, Reset)
  begin
    if Reset = '1' then
      State <= Idle;
    elsif Rising_edge(Clock) then
      State <= NextState;
    end if;
  end process Registers;

  Combinational: process (State, Inputs)
  begin
    NextState <= State;
    Output1 <= '0';
    Output2 <= '0';
    -- etc
    case State is
      when Idle =>
        if Inputs(1) = '1' then
          NextState <= State2;
        end if;
      when State2=>
        Output1 <= '1';
        if Inputs = "00" then
          NextState <= State3;
        end if;
      -- etc
    end case;
  end process Combinational;

The advantage of coding a state machine like this is that the combinational process looks very like the state diagram. It is less error prone to write, less error prone to modify and less error prone to read.

ii) The combinational logic were complex:

For really big block of combinational logic, I would separate. The exact definition of "really big" is a matter of judgement.

iii) The combinational logic were on the Q output of a flip-flop:

Any signal driven in a sequential process infers a flip-flop. Therefore, if you wish to implement combinational logic that drives an output of an entity* then this combinational logic must be in a separate process.

*often not a good idea - be careful.

Answer 3

I would post it as comment if I could, as I am not writing full answer, but giving you a source, and also I don't fully refere to the question (I don't know anything about ASICs). But there is great pdf about this problem in general here. Generally, you don't have to completely separate sequential logic from differential logic, but it is helpful to write more readable and maintainable code.