I’m having some trouble finding the best way to structure the Verilog code for this CPU. In particular, I’ve encountered one small headache and one larger one.

The small headache relates to the best way to describe complex combinatorial logic that doesn’t involve any registers. Consider some hypothetical logic that determines the value of the incrementPC and loadA control signals, based on the current state. One way to do this would be:

    wire incrementPC, loadA;
    assign incrementPC = (state == s1) || (state == s3) || (state == s4);
    assign loadA = (state == s0) || (state == s2) || (state == s4);


That works fine, and it’s pretty clear what it does. But for more complex designs, it’s clearer to use procedural assignment and a case statement, grouping all of the control signals for each state together:

    reg incrementPC, loadA;
 
    always @* begin
        case (state)
            s0:
                incrementPC = 1'b0;
                loadA = 1'b1;
                // other control signals...
            s1:
                incrementPC = 1'b1;
                loadA = 1'b0;
 
                // other control signals...
            s2:
                incrementPC = 1'b0;
                loadA = 1'b1;
                // other control signals...
            s3:
                incrementPC = 1'b1;
                loadA = 1'b0;
                // other control signals...
 
            s4:
                incrementPC = 1'b1;
                loadA = 1'b1;
                // other control signals...
        endcase
    end

The problem with this approach is visible in the first line: incrementPC and loadA must be declared as type “reg”, even though they are not registers. During synthesis, no register will be created as long as your code is correct, but Verilog demands that the target of a procedural assignment like this always be type “reg”. So reg does not always mean that something is a register. I find this very confusing and misleading, because it means you can’t just look at the Verilog code to see which signals are registers and which are purely combinatorial.

My bigger problem is more subtle, and is about good HDL design practices rather than any quirk of the Verilog standard. I’m unsure how explicit I should be in defining the structure of the virtual hardware described by the Verilog code. At one extreme, I could write a high-level functional description of *what* the CPU does, ignoring *how* it does it, and leave the Synthesis software to figure it out. Or at the other extreme, I could work out a block diagram of the CPU consisting of familiar real-world elements like registers, arithmetic unit, muxes, and busses, and then write Verilog code to describe these elements and how they’re all connected.

To help make this distinction clearer, here’s an example based on section 6.2.4 of the book FPGA Prototyping by Verilog Examples. Imagine a state-driven system that can add two input registers, and store the output in a third register. One way to describe this would be high-level, functional:

    always @(posedge clk) begin
        case (state)
            s0:
                d0 <= a + b;               s1:                 d1 <= b + c;             s2:                 d2 <= a + c;         endcase     end     
Great, that's compact and clear. But what does the datapath of this hardware look like? Is there one adder unit, or three? Who knows? It's a black box, relying entirely on the synthesis software to do the right thing.

A second approach would be to explicitly define a single adder unit:

    assign mout = in1 + in2;
    
    always @* begin
        // default: maintain same values
        d0_next = d0;
        d1_next = d1;
        d2_next = d2;
        
 
        case (state)
            s0:
                begin
                    in1 = a;
                    in2 = b;
                    d0_next = mout;
                end
            s1:
                begin
 
                    in1 = b;
                    in2 = c;
                    d1_next = mout;
                end
            s2:
                begin
                    in1 = a;
                    in2 = c;
                    d2_next = mout;
 
                end
        endcase
    end
    
    always @(posedge clk) begin
        d0 <= d0_next;         d1 <= d1_next;         d2 <= d2_next;       end     
That makes the hardware design clearer, so it's unambiguous that there's only one adder. Is this second approach better than the first, then? Mabye, maybe not. If you're optimizing for space, and don't trust the synthesis software to be as smart as you are, then the second example is probably better. But if you're optimizing for speed, having three separate adders (or at least the possibility of three) may actually be better.

Even this second design is somewhat ambiguous. Presumably there are some muxes at the input to the adder, and a mux or load enable at the input to each D register too. But the Verilog code leaves this all implied and unspecified. Here's a third example that spells everything out in full detail:

    wire [1:0] in1Select, in2Select;
 
    assign in1 = (in1Select == 2'b00) ? a :
        (in1Select == 2'b01) ? b :
        (in1Select == 2'b10) ? c :
        d;
    assign in2 = (in2Select == 2'b00) ? a :
        (in2Select == 2'b01) ? b :
        (in2Select == 2'b10) ? c :
        d;
    
 
    assign mout = in1 + in2;
    
    wire loadEnableD0;
    wire loadEnableD1;
    wire loadEnableD2;
    
    always @* begin
        // default: disable all loads
        loadEnableD0 = 1'b0;
        loadEnableD1 = 1'b0;
 
        loadEnableD2 = 1'b0;
        case (state)
            s0:
                begin
                    in1Select = 2'b00;
                    in2Select = 2'b01;
                    loadEnableD0 = 1'b1;
                end
            s1:
 
                begin
                    in1Select = 2'b01;
                    in2Select = 2'b10;
                    loadEnableD1 = 1'b1;
                end
            s2:
                begin
                    in1Select = 2'b00;
                    in2Select = 2'b10;
 
                    loadEnableD1 = 1'b1;
                end
        endcase
    end
    
    always @(posedge clk) begin
        if (loadEnableD0)
            d0 <= mout;         if (loadEnableD1)               d1 <= mout;         if (loadEnableD2)             d2 <= mout;     end     
This approach makes it very clear what's happening in terms of the hardware, and you could build an equivalent physical circuit from 7400 parts. Is this better or worse than the other two approaches? I find it better in terms of understanding what will be synthesized, but it's worse in terms of length. I also suspect that by specifying all the details in this way, it may be over-constraining the synthesis software, preventing it from using some clever optimizations to pack the same amount of logic into less space.

I find myself going around in circles with variations of these three approaches, unable to really get started with the actual CPU design work.