For several years now, I’ve been meeting with AMIQ EDA co-founder Cristian Amitroaie every few months to discuss the state of the industry, key trends in design and verification, and the ways that they help facilitate and accelerate chip development. I noticed an interesting new feature mentioned in their latest press release, so I asked Cristian for more information. This led to a lively and interesting discussion.
Most designers and verification engineers write their code in SystemVerilog these days, but there are exceptions. Some take advantage of high-level synthesis (HLS) tools to design in SystemC or other languages a bit more abstract than SystemVerilog. Others write in their own languages and use custom tools to generate the SystemVerilog files used for simulation, formal verification, synthesis, and other steps in the development process.
Cristian said that they occasionally see a middle ground in which engineers write code that is primarily SystemVerilog but also contains “preprocessor” statements in established languages such as Perl and Python’s Jinja2 library, or in proprietary languages. They use scripts to process these files and generate the pure SystemVerilog files for the rest of the flow. I asked Cristian how the use of preprocessors changes the way that engineers use an integrated development environment (IDE).
I learned that users of the AMIQ EDA Design and Verification Tools (DVT) IDE family want to have access to all their favorite features even when editing files with preprocessor code. The AMIQ EDA team developed clever heuristics to enable full IDE capabilities when editing such files, just as they do with pure SystemVerilog. These features include navigational hyperlinks, autocomplete, on-the-fly error detection, quick fixes, refactoring, and all the advanced functionality DVT IDE users are addicted to.
This was intriguing to me. We are talking about “understanding” mixed-language files, not really something any compiler can easily digest. To make sure I get it right and that this is for real, Cristian invited Zeljko Zurzic, the team lead who coordinated the development of this capability, to explain how it works. He said that all users need do is to inform DVT IDE about the mapping between the files containing preprocessor statements (“p file”) and the generated files (“g file”).
This is done using dedicated compiler directives that support various use cases. For example, there is a way to tell the DVT IDE compiler “go figure out the corresponding p file from the g file header comment.” Once this is done, users just edit their p files as if there is nothing special about them. On-the-fly incremental compilation will flag any SystemVerilog errors as they type, hyperlinks take them around the code, autocomplete and refactoring work just fine, they can request various diagrams, etc.
The sections that contain preprocessor code are marked distinctively so that users know they will be transformed into SystemVerilog code. In DVT Eclipse IDE they can see how code is generated by using the Inspect View; in DVT IDE for VS Code they can “peek” the transformations. DVT IDE can be configured to automatically run the preprocessing script whenever the preprocessor code is changed. Users can easily compare a p file with the corresponding g file if desired.
Zeljko provided three screenshots that show this new capability in action. The first one below shows a file in DVT Eclipse IDE that includes a Jinja2 preprocessor statement. Despite the presence of this non-SystemVerilog code, the user is able to take advantage of the powerful “Show Writers” feature to quickly understand how a variable is driven. Compilation errors and warnings are indicated in the leftmost column of the display.
The screenshot below displays the same file in DVT IDE for VS Code, showing the compiler issues in the left column and enabling the use of autocomplete. This demonstrates how even the most advanced DVT functions are available in code with preprocessor statements.
Zeljko stressed that the IDE checks the generated SystemVerilog code, important because there could be an error in a preprocessor statement or a bug in the preprocessing script. The screenshot below shows just such an example. The generated SystemVerilog code contains a variable that was not defined in the source file. DVT IDE displays the compilation error, the p file, and the generated code in the g file.
Viewing the g files can be helpful in debug, but the bottom line is that users work directly with the p files, analyzing and editing them using a powerful IDE. The g files are tagged as “read only” and users will be warned if they are modified. I was glad to hear this; we all know that it’s a really bad idea to make manual changes to any file that will be overwritten by a code generation process.
Finally, Cristian stressed that the whole point of this new feature is that users can edit code with preprocessor statements just as if it were pure SystemVerilog. Making this possible has been a significant effort driven by a few key customers who rely on preprocessor-based flows. I thanked Zeljko and Cristian for their explanations and their time.
If you’d like to learn more about using preprocessor files or any aspect of the AMIQ EDA solutions, you can visit them in Booth 107 at the Design and Verification Conference and Exhibition (DVCon) United States in San Jose, Calif. on March 5 and March 6.
Also Read:
2024 Outlook with Cristian Amitroaie, Founder and CEO of AMIQ EDA
Using Linting to Write Error-Free Testbench Code
AMIQ: Celebrating 20 Years in Consulting and EDA
Share this post via:
- SEO Powered Content & PR Distribution. Get Amplified Today.
- PlatoData.Network Vertical Generative Ai. Empower Yourself. Access Here.
- PlatoAiStream. Web3 Intelligence. Knowledge Amplified. Access Here.
- PlatoESG. Carbon, CleanTech, Energy, Environment, Solar, Waste Management. Access Here.
- PlatoHealth. Biotech and Clinical Trials Intelligence. Access Here.
- Source: https://semiwiki.com/eda/amiq-eda/342053-handling-preprocessed-files-in-a-hardware-ide/
