In Part 1 (TVP: Rethinking Virtual Platform Development With Agentic AI), we walked you through the industry problem of virtual platform modeling being a production bottleneck and how TVP, an agentic AI platform built by Vayavya Labs, can help address it. 

This is the second blog in the series that talks about the TVP from an engineering point of view – how a hardware spec becomes a verified SystemC model.

A few one-line primers you need to know before reading further:

• SystemC / TLM-2.0: a C++ library and transaction-level modeling standard used to build high-speed virtual prototypes of Systems-on-Chip (SoCs).
• RAG (Retrieval-Augmented Generation): lets an LLM answer using your ingested documents instead of guessing from memory.
• MCP (Model Context Protocol): a standard way for agents to call external tools and data sources.

TVP: The Architecture

Image Copyrights Reserved @vayavyalabs

TVP is organized as a set of cooperating agents wired to perform certain functions in a simulation environment. It consists of:

• Orchestrator Agents (Design, Code): the controllers. They drive the workflow from reading a specification through generating code, deciding what happens next at each stage.
• Task Agents: the workers. They execute predefined tasks (extract features, declare ports, implement a register callback, run tests).
• MCP Client + MCP Server & Tools: the agents reach external capabilities through MCP. The server exposes tooling and a RAG database for semantic search over ingested specs, plus CSML for code generation.
• Simulation Environment: the generated model is compiled and exercised against SystemC libraries, so verification is real, not hypothetical.
• Human in the Loop: approval gates sit between stages. The engineer steers and signs off; the agents do the heavy lifting.

The result is a system that is context-aware and workflow-aware with an embedded knowledge of how to model IPs.

The Four-Stage Workflow

Every IP moves through four interaction modes. We’ll follow a real example from our demo: an HMAC cryptographic accelerator (SHA-2 256/384/512, HMAC mode, configurable key up to 1024 bits, a 32 × 32-bit message FIFO, and context switching across message streams).

0. Pre-Processor: “X to Markdown”

Our LLMs work on text. IP information arrives as PDF datasheets, technical reference manuals, IP-XACT XML, and spreadsheets with text, tables, and diagrams. The pre-processor ingests all of it and produces clean Markdown.

1. Design: Plan and Define

The Design Orchestrator builds the model’s blueprint. In the demo screenshots above, a sub-agent reads the HMAC manual and classifies features into what must be modeled in TLM versus what to exclude, separating software-visible behavior (operational modes, key configuration, message processing, interrupts, FIFO management) from RTL-level timing and implementation details. From there, it produces a feature list, breaks features into functionalities, plans test cases for each, and generates design documentation. Crucially, it pauses for human approval. The engineer steers it to model cryptographic operations using a third-party library, then approves the rest.

2. Stub: Initial Code Base

Now the model gets scaffolded. This stage uses CSML or customer-specific libraries to generate the skeleton: register declarations, register callbacks, port declarations, and testbench initialization with port bindings. A task agent first queries the knowledge base, generates a register-map CSV, and then runs CSML to emit the stub. For the HMAC, this produced a clean TLM interface- a tlm_target_socket register bus plus interrupt and clock/reset ports.

3. Code: Implement and Verify

The Code Orchestrator implements the functionality, writes its test cases, runs them, analyzes logs on failure, and fixes them. The produced register callbacks have genuine hardware semantics. Each functionality runs a loop of implement → test → analyze → fix → approve before moving to the next.

CSML: The Reusable Asset 

CSML is Vayavya’s permissively licensed C++11 modeling library built on SystemC, TLM, and CCI. It fills gaps SystemC leaves open for real peripheral models, likely registers, interrupts, timers, logging, and stays vendor-neutral. It’s why generated models look consistent regardless of who supervised them.

Conclusion:

Your virtual platform modeling doesn’t have to be gated by how many SystemC experts you can hire. TVP reframes the work as a supervised, agentic workflow-  a spec goes in, orchestrator and task agents plan, scaffold, code, and verify against a real simulation environment, and an engineer approves the decisions that matter. The structure is what separates it from prompt-driven code generation. The output is consistent, traceable, and ready to grow toward the self-debugging and fully autonomous flows on the roadmap.

The honest next step is to see it run on an IP that matters to your team. Contact Vayavya Labs to request a live demo and a technical consultation. Bring your own spec, and we’ll walk through how TVP would model it. Write to us at: sales@vayavyalabs.com or drop your query here.