How to write best prompts for best RTL

A reusable hardware specification template, a stronger multiplier prompt, and the edge cases worth spelling out before generation.

A structured hardware specification with clock, interface, and timing requirements

The best RTL prompt is a compact engineering specification. It tells the model which circuit to build and leaves as little accidental interpretation as possible. Adding “be an expert hardware engineer” cannot compensate for an unspecified reset or an ambiguous handshake. A useful prompt also makes the eventual review fairer: two implementations can be compared against the same observable behavior rather than two different guesses about your intent.

Start with behavior, not adjectives

“Write an efficient FIFO” leaves most of the design unresolved. Efficient in which technology? Synchronous or asynchronous? What depth and width? Is the first word visible immediately or only after a read? What happens when reading empty? Can a simultaneous read and write proceed when full? A model must invent answers unless the specification supplies them, and two models may invent incompatible interfaces.

A better request describes transactions, storage, and boundary cases. Separate required behavior from preferences. For example, “depth is exactly 16” is a contract, while “prefer readable control logic” is a style preference. Do not demand the lowest possible area or a guaranteed frequency without a target library and constraints. HDL Arena’s generic synthesis results cannot establish either claim.

A reusable specification template

Purpose:
  What block is needed, and what must it do?
Language and packaging:
  Select the same HDL in the arena; name one top module.
  Keep required submodules self-contained in the source.
Ports:
  Name, direction, width, signedness, and meaning of each.
Clock and reset:
  Clock edge; reset polarity; sync/async; reset values.
Transactions:
  Exact acceptance rule, valid/ready meaning, stall behavior.
Timing:
  Latency in cycles; throughput; output behavior when invalid.
Arithmetic and storage:
  Widths, binary point, rounding, saturation or wraparound.
Boundary cases:
  Overflow, underflow, simultaneous operations, illegal inputs.
Implementation constraints:
  Portable synthesizable subset; target assumptions if known.
Acceptance examples:
  Short cycle traces and expected outputs.
Deliverable:
  RTL plus a concise explanation of assumptions.

Not every field applies to every design. A combinational decoder does not need a reset. A single-clock counter does not need a ready/valid interface unless the system requires one. State explicitly that a field is inapplicable rather than adding unnecessary machinery. The template is a checklist for eliminating ambiguity, not a reason to overcomplicate a small block.

Weak request versus improved request

Weak: “Make a fast signed multiplier with valid signals in Verilog.” This says little about input widths, output width, pipeline depth, reset, or whether the result may be stalled. “Fast” might prompt a combinational multiplier, a deeply pipelined circuit, or an unsupported device primitive. All could look reasonable while fitting different surrounding systems.

Generate self-contained Verilog-2005 with top module mul8.
Inputs: clk, rst_n, in_valid, signed [7:0] a and b.
Outputs: out_valid, signed [15:0] product.
Use the rising clock edge and synchronous active-low reset.
Reset sets product and out_valid to zero.
On each non-reset edge, out_valid captures in_valid.
If in_valid is high, product captures a*b from that edge.
Otherwise product holds its previous value.
There is no backpressure; accept one input on every valid edge.
Use the full signed 16-bit product without saturation.
Use one output register stage, no vendor primitives or includes.
Example: a=-3, b=7, in_valid=1 before an edge yields
product=-21 and out_valid=1 after that edge.
Explain the sampled-input/output timing and invalid-cycle behavior.

Notice that the example defines the edge relationship explicitly instead of relying only on the phrase “one-cycle latency.” It also gives output behavior during invalid cycles, which matters when a testbench checks data as well as valid. You can add a second example for reset asserted during a valid input and a third for back-to-back valid samples. Small traces often expose contradictions before any model is called.

Make tool expectations realistic

Choose the output language once for the entire battle. Supported Verilog/SystemVerilog designs receive bounded compilation and generic synthesis checks, while VHDL is unsupported by that checker. SystemVerilog support in synthesis is limited. For portable comparisons, avoid advanced language features unless they are genuinely necessary and you can validate them in your own tools. An accepted language selector is not a guarantee that every construct will synthesize.

Use a unique ordinary top module and include the required submodules. The current checker does not support external includes, general preprocessor macros, conditional compilation, memory-file loading, or external calls. If a design requires a ROM, discuss a self-contained representation rather than assuming the worker can access an initialization file. Do not ask the model to bypass these limits.

Ask for evidence you can evaluate

Request an explanation of state transitions, numeric ranges, and expected cycle behavior, but do not treat generated explanations as proof. In the blind comparison, inspect whether each implementation satisfies the prompt. After voting, review the independent tool results and AI assessment as separate sources of information. An enthusiastic AI review cannot override a clear mismatch in reset behavior or a missing acceptance rule.

After the reveal, the product supports manually saving and rechecking a separate revision. That is not automatic repair: you are responsible for the change and its verification. Original generation, original checks, and the vote remain distinct from your revision. Use a local testbench and assertions for functionality, then a target-specific flow for implementation quality.

Protect information before you submit

  • Use invented or public interfaces rather than confidential workplace specifications or proprietary RTL.
  • Follow your employer’s data policy: prompts and code are processed by AI providers, not guaranteed confidential by the arena.
  • Include concrete edge cases, but remove customer names, internal addresses, secrets, and sensitive architecture details.
  • Keep a reusable sanitized prompt and evaluate every generated implementation against the same contract.