I ?? to create an AI digital IC engineer (1/n)

Link to AIVRAL paper on arxiv: https://arxiv.org/pdf/2409.11411

At this moment I am using those AI for various purposes:

• Microsoft CoPilot.
• xAI Grok 2 beta.
• Perplexity.
• Claude.

(My own subjective aversion of openAI prevents me from evaluating it as well, which is a character flaw that might or might not impact my progress.)

Anyway. I'm not going to describe the creation of an AI based digital IC engineer, it is more an incomplete write-down of what we need to consider and think about when creating such system.

AI HDL generation today

Yesterday is totally different from today so to speak. Go back one to two months and I tried to generate simple HDL code to more advanced HDL code like an APB Bus Functional Model to see what it would produce. It is an interesting thought process that reveals things both about you and the AI. Let's just follow a random example.

Prompts, tokens, words, instructions, whatever you want to call it is the key to unlocking AI potential. Me, a human by birth, I think about something and then talk loudly about it. Ask a question or tell a story, whatever. But I often forget the context I have in my head is not known outside your own mind. So, I could be mentioning "Yeah, he got seriously cooked" and nobody would know what I am talking about. You could be talking about someone in the room or you might have been thinking about someone but forgot to mention who "he" is. Context matters. Hence the prompt "generate me a systemverilog BFM of an APB slave" contains a lot of information but also requires more information. The AI is usually implemented such that it takes the information it has and does something with it. It could ask thousands of questions to get every detail ironed out too, but that would create a lot of friction for those impatient bio-bots called humans. So, the prompt generates systemverilog code that has:

• An incomplete port list because there are several AMBA/APB protocol versions with slight differences between the ports and even the number of ports.
• Code that drives the initial values of the outputs but with a comment and a TODO to implement.
• Code that does not implement the actual behavior based on the various input values.

Over time,the generated code got more complicated and it wasn't always exactly the same prompt.

Prompt: "can you show me an APB v3 systemverilog slave BFM implementation?"

// Grok v2 beta

module apb_slave_bfm (
  // APB Interface signals
  input logic pclk,
  input logic presetn,
  input logic [31:0] paddr,
  input logic psel,
  input logic penable,
  input logic pwrite,
  input logic [31:0] pwdata,
  output logic [31:0] prdata,
  output logic pready,
  output logic pslverr
);

  // Memory to simulate the slave's response
  logic [31:0] memory [0:1023]; // Assuming a small memory for example
  logic [31:0] data;
  
  // State for the APB transaction
  typedef enum logic [1:0] {
    IDLE    = 2'b00,
    SETUP   = 2'b01,
    ACCESS  = 2'b10
  } apb_state_t;

  apb_state_t state, next_state;

  // Sequential logic for state machine
  always_ff @(posedge pclk or negedge presetn) begin
    if (!presetn)
      state <= IDLE;
    else
      state <= next_state;
  end

  // Combinational logic for state transitions and outputs
  always_comb begin
    next_state = state;
    pready = 1'b0; // Default values
    pslverr = 1'b0;
    unique case (state)
      IDLE: begin
        if (psel && !penable) 
          next_state = SETUP;
      end
      
      SETUP: begin
        if (psel && penable) 
          next_state = ACCESS;
        else 
          next_state = IDLE; // If psel goes low, go back to IDLE
      end

      ACCESS: begin
        pready = 1'b1; // Signal that the slave is ready this cycle
        if (!psel) 
          next_state = IDLE;
        else if (pwrite) begin
          // Write operation
          memory[paddr[11:2]] = pwdata; // Assuming word addressable, adjust if byte addressable
        end else begin
          // Read operation
          data = memory[paddr[11:2]];
        end
        
        // Here you could add logic for pslverr if the address is invalid or operation not supported
      end
    endcase

    // Read data output
    if (state == ACCESS && !pwrite) begin
      prdata = data; // Output data on read
    end else begin
      prdata = 'z; // High impedance when not reading
    end
  end

  // Initialization of memory (optional for simulation)
  initial begin
    for(int i=0; i<1024; i++) memory[i] = i; // Just for example, fill with address value
  end

endmodule        

So, here you see more code, correct or not, I don't care so much at first. I like to see what choices were made and then add this to the prompt:

• For example, this stores data in memory, but we could also use tasks to return data for a read task and to write data via a write task. Or we could opt to have the info printed on stdout. Or a combo.
• In RTL you don't want 'z' but in a model, it could be used. Could also be 'x' so adjust accordingly. Even just hand edit the code.
• The slave error response is a bit of a weird thing, because you could return a slave error if a read only address was written to, and out of range address was used, ... Again, it is your choice, but you have to specify it for the code to be generated.

Hence, it is clear there are quite a few challenges to writing the prompts for HDL code generation:

• What is the purpose/type of code: behavioral code, synthesizable code, ...
• What should the code focus on? For example RTL code that is the fastest, smallest or best performance per Watt? For example for behavioral code, the fastest execution, the least memory space required (you would be surprised how many don't know the implications of creating huge environments that clog up the servers memory), ...
• What is the complexity of the code, how to divide the goal into various subparts of the code? An adder can be generated as such, but a matrix multiplier with an APB based configuration and status register map is not one prompt (right now).
• Reusability and parameterization of the code. Add it yourself?
• Documentation that describes the design, the requirements and the choice of implementation. In what format (doc itself and diagrams)? Text-only for version control friendliness? Diagrams in text only as well?
• Verification code that goes automatically with the RTL, BFM or whatever you designed. Which in itself brings up the question: exhaustive, random, basic, .. and how to measure? Also, using open source tools the AI could actually run it itself to validate the code and the verification. Inevitably also the verification plan, coverage reporting, regression, ... That is sim based verification, what about proving mathematically the code works?
• Is the RTL code synthesis, STA and DFT clean? If behavioral, how does it deal with values that are not '0' or '1', like 'z' and 'x'?
• Code quality, linting and formatting? Coding guidelines that need to be followed (RAG?).
• ...

Probably many more things to bring up. But major point today is also, the code the AI is trained on is a bunch of github repo's that is littered with:

• Lab exercises in various states of completion, with or without errors, who knows.
• Trials of designs started but never finished.
• Designs that are finished but haven't been fully verified, have been written exclusively for FPGA (resets!), ...
• Incomplete or no verification environments.
• Never synthesized (latches, tri-states, ...).

Hence the labelling for verilog/systemverilog is never done, the syntax is all systemverilog but some code is behavioral, rtl, tech dependent, tool dependent, bad coding style, ... so the AI itself has no clean and extensively labelled dataset to be trained on. And if we put all the good code together, it is gonna be negligible in size versus python for example. Hence I naturally tend to favor Python as a verification environment over HDL languages. But there the issue is that there is a steep learning curve, several different implementations are available, different python version compatibility, abandoned extensions/plugins/libraries, ...

Conclusion

I want to continue this discussion with myself and others. Still, it will take a lot of time to come up with a smart enough AI that can handle the design and verification of a low complexity IP block. Maybe not, maybe there are smarties out there that could do it or have it already, who knows? At this moment, it has become usable in a "primitive" Q&A way. Maybe the road of the AI is not design and verification but maybe it is in the direction of open source software. Take all the tools and repo's, unify them in one language like Python, compatible with one python3 version and "pip install -r requirements.txt" will get you all tools for the front-end (with a choice of multiple tools if there exist multiple ones). And then the AI could self-verify the code for syntax errors and evaluate different RTL implementations based on requirements. Today, the open source repo's have all either different languages, different build tools, different dependencies, different level of documentation, different size of the user base, ... And I see regularly people inventing new HDL-ish languages to "solve" things and they never pick up steam. And the effort and community build-up fizzles out. Why?