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
It 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, errata, and other technical resources available publicly online.
Best used for:
- Recently updated specifications or documentation
- Vendor documentation that may have changed
- Looking up unfamiliar components or interfaces
- Finding implementation references
- Verifying technical details against current sources
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.
This is particularly useful for locating datasheets, technical papers, architecture descriptions, application notes, and similar engineering material.
Best used for:
- Finding similar implementations
- Architecture references
- Datasheets and technical documentation
- Research papers
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. This can reduce development effort and help take advantage of implementations already optimized for Xilinx FPGA families.
Best used for:
- PCIe, Ethernet, DDR, and other complex interfaces
- High-performance arithmetic blocks
- Designs where timing or resource efficiency is important
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.
This is especially valuable for large specifications where all requirements cannot reasonably be included in a single prompt.
Best used for:
- RTL generated from a formal specification
- Large interface documents
- Internal architecture documents
- Product requirements
- Datasheets supplied by your team
- Projects with many design constraints
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 to confirm that the design behaves as expected. If any test fails, the platform analyzes the issue, refines the RTL, and runs the tests again. This loop continues until the module passes the full sanity-check suite. The tradeoff is that, because it prioritizes speed and lightweight testing, it is not intended to uncover every possible 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” by automatically building a complete verification strategy around the generated design. The platform derives the expected behavior from the specification and uses it to systematically test the RTL implementation.
The process begins by analyzing the prompt and identifying potential corner cases, which are used to create a 12-scenario verification plan. It then generates a golden reference model that defines the expected behavior during simulation. For each scenario, the platform builds a constrained-random verification environment and executes the test multiple times with different randomized inputs and conditions.
The generated RTL is then simulated automatically to detect functional bugs, protocol violations, and unexpected behavior. If an issue is found, the platform analyzes the failure, reasons about its root cause, and provides the findings back to the generation model so the RTL can be refined.
This generate → simulate → analyze → refine feedback loop continues automatically until the module successfully passes the complete verification suite.
Use Exhaustive Verification when correctness and comprehensive testing matter more than generation speed. It performs significantly deeper testing than Auto-Verify, but this additional coverage comes at the cost of a longer generation and verification time.
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 generated design, looks for potential problems, and can revise the implementation before presenting the final result.
Reflection is useful for complex RTL, unfamiliar architectures, highly parameterized modules, or designs where subtle corner cases are likely. It may take longer because the model performs additional reasoning and revision passes.
The review can look for issues such as:
- Incorrect interpretation of requirements
- Handshake bugs
- Width and signedness mistakes
- Reset behavior
- FSM corner cases
- Combinational loops
- Latch inference
- Clock-domain issues
- Incorrect parameterization
- Protocol violations
- Unnecessary registers or logic
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.