Features
Every option you can switch on before a run, explained in full; what each one retrieves, how deeply it checks the result, and when it is worth the extra time.
Web Search
Live results from the open web
Web Search allows the RTL generator to retrieve up-to-date public information. It is useful when the request depends on information that may not already be available in the model's built-in knowledge, such as current vendor documentation, protocol updates, implementation notes, reference designs and errata. Reach for it when a specification may have changed, when a component is unfamiliar, or when a detail needs checking against a current source.
Example
If you ask for an RTL interface to a recently released FPGA device, Web Search can retrieve the latest documentation before generating the module.
Exa Search
Semantic search over datasheets & papers
Exa Search is a more technical, meaning-based retrieval mode. Instead of primarily searching by keywords like web search, it is intended to find documents that are conceptually relevant to the engineering problem being solved. That makes it particularly useful for locating datasheets, technical papers, architecture descriptions, application notes and similar engineering material, and for surfacing similar implementations when your prompt and the source use different terminology.
Example
For a high-throughput packet scheduler, Exa Search may retrieve papers describing scheduling architectures even when they use terminology different from your prompt.
Web Search vs. Exa Search:
Think of Web Search as broad live information retrieval, while Exa Search is better suited to finding technically relevant documents by meaning.
IP Core Library
Reuse verified cores from the vendor IP catalog
IP Core Library allows the generator to consider existing “Xilinx” IP cores rather than implementing every function from scratch in RTL. When a suitable verified core exists, the platform can recommend or integrate that IP into the generated architecture, taking advantage of implementations already optimized for Xilinx FPGA families. It pays off most on complex interfaces such as PCIe, Ethernet and DDR, on high-performance arithmetic blocks, and wherever timing or resource efficiency matters.
generated architecture
Example
Instead of generating a large asynchronous FIFO entirely from RTL, the design may use the FPGA vendor's dedicated FIFO implementation when appropriate.
Knowledge Base
RAG over your uploaded specs & PDFs
Knowledge Base grounds the RTL generator in your own documentation. When enabled, the platform retrieves relevant sections from uploaded specifications, interface documents, architecture descriptions, datasheets, PDFs and other project material, and provides that context to the RTL agent during generation. It is especially valuable when RTL must follow a formal specification, when the interface or architecture documents are large, or when a project carries more requirements than fit in a single prompt.
Example
You can upload a large hardware specification and ask:
“Implement the DMA descriptor fetch engine.”
The generator can retrieve the sections related to descriptor format, AXI behavior, reset requirements, interrupts, and error handling rather than relying only on the prompt.
Important distinction:
Knowledge Base searches your documents, while Web Search and Exa Search retrieve information from external sources.
Auto verify
Sanity check
Auto-Verify provides a lightweight sanity check for the generated RTL. It creates 5–6 direct test cases covering the module’s core functionality and runs them automatically. If a test fails, the platform analyzes the issue, refines the RTL and runs the tests again, until the module passes the full suite. Because it prioritizes speed, it will not uncover every corner case.
core functionality, checked fast
Example
You want to generate a simple module that doesn’t have a complex behavior, and a simple sanity check on its functionality gets the job done.
Exhaustive Verification
Test plan · golden model · coverage
Exhaustive Verification extends the workflow beyond basic “Auto-Verify”, deriving a 12-scenario plan of corner cases from the prompt, generating a golden reference model, and running each scenario in a constrained-random environment to detect functional bugs and protocol violations; failures are fed back so the RTL is refined until it passes the complete suite. Use it when correctness matters more than speed.
12-scenario plan
Example
Your module includes a complex interface and may experience rare corner cases.
Reflection
Model critiques & iterates its output
Reflection adds an additional engineering review pass after the initial solution is produced. Rather than immediately returning the first generated RTL, a 2nd model examines the design and can revise it before presenting the final result, looking for issues such as misread requirements, handshake bugs, width and signedness mistakes, reset behavior, FSM corner cases, combinational loops and latch inference. It is useful for complex RTL, unfamiliar architectures and highly parameterized modules, and may take longer.
revised before delivery
if (s_axis_tvalid && s_axis_tready)Example
The first implementation of an AXI module might accidentally update internal state when TVALID=1 but TREADY=0.
During Reflection, the model can recognize that AXI state should only advance on a successful handshake if (s_axis_tvalid && s_axis_tready) and revise the implementation before returning it.
Describe your first module today
Start on the free tier. Bring your own models. Ship verified RTL.