If we are writing fresh code, an LLM can be used to get a skeleton or complete code by supplying specifications to it. We could also use an LLM to understand specifications, extract core specifications from manuals, or find the root cause of an unfamiliar error. Usually, in a team, we have scripts that control workflows, e.g., scripts that create a project with the required configuration, perform simulation and regression testing, check constraints, perform synthesis and implementation, and generate a bitstream. These flow steps are well defined, so the sequence in which they should be executed is already known. Hence, there is no need to ask the LLM about the execution sequence. The substeps within each step are already defined in the scripts, so asking the LLM to define them is unnecessary. Instead, we could run the scripts, generate summaries from the logs, and send compact logs to the LLM for feedback. This avoids sharing large amounts of context and file information with the LLM when the steps are already known. For example, assume we are creating a Vivado project using a predefined Tcl script that creates the project with the required configuration. Once project creation is complete, our script scans the console logs and sends a log summary to the LLM to assess whether project generation was successful. A CLI agent may send the entire log to the LLM for analysis, while a custom script written by us can send only what is relevant. So, CLI agents can be effective in unfamiliar territory, i.e., when we are debugging difficult issues, finding the root cause when things are not working as expected, generating code skeletons, or creating specifications or verification test cases. However, the execution of steps in EDA tools must be predictable. We must also control what should be edited and what should not be touched. This can be handled more efficiently by using custom agents that call our scripts instead of deciding every action on their own. We are happy to announce the launch of the Building Custom Agent tutorial, specifically for FPGA developers who wish to adopt agents in their workflows. This course will serve as a foundation for upcoming courses on agents, namely CLI agents and AMD ROSS agents. We will be building Tcl scripts to control design steps and then converting them into individual tools that can be called by the agent. A Python controller will sit between the LLM agent and our tools to decide the next step. At the end of the course, we will be able to give a task to the agent in plain text, and it will autonomously try to achieve the goal using our predefined steps. We will also cover MCP so that our custom tools can later be added to specialized EDA agents like AMD ROSS.
If we are writing fresh code, an LLM can be used to get a skeleton or complete code by supplying specifications to it. We could also use an LLM to understand specifications, extract core specifications from manuals, or find the root cause of an unfamiliar error. Usually, in a team, we have scripts that control workflows, e.g., scripts that create a project with the required configuration, perform simulation and regression testing, check constraints, perform synthesis and implementation, and generate a bitstream. These flow steps are well defined, so the sequence in which they should be executed is already known. Hence, there is no need to ask the LLM about the execution sequence. The substeps within each step are already defined in the scripts, so asking the LLM to define them is unnecessary. Instead, we could run the scripts, generate summaries from the logs, and send compact logs to the LLM for feedback. This avoids sharing large amounts of context and file information with the LLM when the steps are already known. For example, assume we are creating a Vivado project using a predefined Tcl script that creates the project with the required configuration. Once project creation is complete, our script scans the console logs and sends a log summary to the LLM to assess whether project generation was successful. A CLI agent may send the entire log to the LLM for analysis, while a custom script written by us can send only what is relevant. So, CLI agents can be effective in unfamiliar territory, i.e., when we are debugging difficult issues, finding the root cause when things are not working as expected, generating code skeletons, or creating specifications or verification test cases. However, the execution of steps in EDA tools must be predictable. We must also control what should be edited and what should not be touched. This can be handled more efficiently by using custom agents that call our scripts instead of deciding every action on their own. We are happy to announce the launch of the Building Custom Agent tutorial, specifically for FPGA developers who wish to adopt agents in their workflows. This course will serve as a foundation for upcoming courses on agents, namely CLI agents and AMD ROSS agents. We will be building Tcl scripts to control design steps and then converting them into individual tools that can be called by the agent. A Python controller will sit between the LLM agent and our tools to decide the next step. At the end of the course, we will be able to give a task to the agent in plain text, and it will autonomously try to achieve the goal using our predefined steps. We will also cover MCP so that our custom tools can later be added to specialized EDA agents like AMD ROSS.
Founder, Namaste FPGA · Mumbai, India
15 years of production silicon — from high-frequency trading on Xilinx Alveo, to India's indigenous MRI machine, to training engineers at Mumbai University. Top 1K instructor on Udemy. Every course here comes from work he's actually shipped.
No reviews yet
Be the first to review this course.