Ask an AI assistant for a Verilog module and you will get one in seconds. It will have sensible names, tidy formatting and a confident explanation. The real question for an engineer is different: will it simulate correctly, will it synthesize into what you intended, and will it survive a design review?<\/p>\n
This article looks honestly at AI for RTL design<\/strong><\/a>.<\/a> You will see what generative AI does well, where it fails, a few sample prompts and code, and a validation workflow you can use on any AI-generated RTL.<\/p>\n The industry is moving in this direction too. In 2026, major EDA vendors announced agent-style tools that take a specification, produce RTL, run simulations and iterate. Availability and maturity differ between products, so check the vendor for current status.<\/p>\n The quality of generated RTL depends heavily on the prompt. Vague requests produce vague hardware. A strong prompt states the interface, the behaviour, the reset style and the coding rules.<\/p>\n Write a Verilog counter.<\/p>\n Write synthesizable SystemVerilog for a parameterized up\/down counter.<\/p>\n – Parameter WIDTH, default 4<\/p>\n – Inputs: clk, rst_n (active-low asynchronous reset), en, up<\/p>\n – Output: count [WIDTH-1:0]<\/p>\n – When en is high, count increments if up is 1, decrements if 0<\/p>\n – When en is low, count holds its value<\/p>\n – Use always_ff and non-blocking assignments<\/p>\n – No latches, no initial blocks, no delays<\/p>\n – Add a short comment above each block<\/p>\n The second prompt removes the guesswork. It also gives you a checklist to review the answer against.<\/p>\n module updown_counter #(<\/p>\n parameter int WIDTH = 4<\/p>\n )(<\/p>\n input\u00a0 logic\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 clk,<\/p>\n input\u00a0 logic\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 rst_n,<\/p>\n input\u00a0 logic\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 en,<\/p>\n input\u00a0 logic\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 up,<\/p>\n output logic [WIDTH-1:0] count<\/p>\n );<\/p>\n <\/p>\n \/\/ Sequential logic with asynchronous active-low reset<\/p>\n always_ff @(posedge clk or negedge rst_n) begin<\/p>\n if (!rst_n)<\/p>\n count <= ‘0;<\/p>\n else if (en)<\/p>\n count <= up ? count + 1’b1 : count – 1’b1;<\/p>\n end<\/p>\n <\/p>\n endmodule<\/p>\n This is a straightforward case and a capable model will usually get it right. Notice that you still must check the reset style, the hold behaviour and the wrap-around at the maximum and minimum values.<\/p>\n A model may write combinational logic that does not assign an output in every branch, which creates a latch.<\/p>\n \/\/ Risky: y holds its old value when sel is 0, so a latch is inferred<\/p>\n always @(*) begin<\/p>\n if (sel) y = a;<\/p>\n end<\/p>\n <\/p>\n \/\/ Safer: assign a default first<\/p>\n always_comb begin<\/p>\n y = ‘0;<\/p>\n if (sel) y = a;<\/p>\n end<\/p>\n Using blocking assignments in sequential logic, or non-blocking in combinational logic, can create simulation and synthesis mismatches.<\/p>\n AI often ignores reset recovery, asynchronous reset release and signals that cross clock domains, because a short prompt rarely mentions them.<\/p>\n Delays, certain initial-block uses and some testbench-style constructs may appear in code that was supposed to be synthesizable.<\/p>\n If the specification is ambiguous, the model silently picks an interpretation. That may differ from what the architect intended, and nothing will warn you.<\/p>\n Models sometimes refer to signals, libraries or tool commands that do not exist. Always run the code instead of trusting the explanation.<\/p>\n For the counter above, a simple assertion could check increment behaviour:<\/p>\n assert property (@(posedge clk) disable iff (!rst_n)<\/p>\n (en && up && count != ‘1) |=> count == $past(count) + 1);<\/p>\n An independent check like this is valuable because it does not depend on the generated code being correct.<\/p>\n A beginner who uses AI to avoid learning will struggle, because they cannot tell good RTL from bad. A beginner who first learns the fundamentals and then uses AI as an assistant will move faster than before. The difference is the ability to judge.<\/p>\nWhat Generative AI Can Do for RTL<\/h2>\n
\n
Writing a Good Prompt<\/h2>\n
Weak prompt<\/h3>\n
Stronger prompt<\/h3>\n
What the Output Might Look Like<\/h2>\n
Where AI-Generated RTL Goes Wrong<\/h2>\n
Accidental latches<\/h3>\n
Mixed or incorrect assignments<\/h3>\n
Weak reset and clock-domain handling<\/h3>\n
Non-synthesizable constructs<\/h3>\n
Misread specifications<\/h3>\n
Invented details<\/h3>\n
A Workflow to Validate AI-Generated RTL<\/h2>\n
\n
Good Uses and Poor Uses<\/h2>\n
\n\n
\n Good uses<\/strong><\/td>\n Poor uses<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n First drafts of small, well-specified blocks<\/td>\n Unreviewed code for a critical block<\/td>\n<\/tr>\n \n Refactoring and style conversion<\/td>\n Clock-domain crossing or reset architecture without expert review<\/td>\n<\/tr>\n \n Explaining legacy code<\/td>\n Learning Verilog by only copying output<\/td>\n<\/tr>\n \n Generating test ideas and documentation<\/td>\n Replacing simulation and synthesis checks<\/td>\n<\/tr>\n \n Speeding up repetitive scripts<\/td>\n Pasting confidential design data into public tools<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n What This Means for Learners<\/h2>\n