Writing Better Code More Quickly with an IDE and Linting

As a technical marketing consultant, I always enjoy the chance to talk to hands-on users of my clients’ electronic design automation (EDA) tools to “see how the sausage is made” on actual projects. Cristian Amitroaie, CEO of AMIQ EDA, recently connected me with Verification and Infrastructure Manager Dan Cohen and Verification Engineers Xiyu Wang and Nick Sarkis from Lightmatter. I had the pleasure of speaking with them about their experiences using AMIQ EDA products.

Can you please tell us a bit about your company and your projects?
We specialize in developing advanced computing solutions using photonic technology. We have projects focusing on data transport and optical processors that leverage the unique properties of light to achieve high-performance computing with significantly lower power consumption.

So this involves designing some big chips?
That’s for sure! At the heart of our solution are huge chips with a great deal of both digital and analog content. They present an interesting verification challenge with some unique features, so using the best tools helps us move quickly with a fairly small team.

What led you to look to AMIQ EDA for help with your verification?
Lightmatter: Several members of our team used DVT Eclipse IDE and Verissimo SystemVerilog Linter at our previous companies, so we planned to use it here as well. Verissimo is the only tool that can effectively lint UVM code. We use the DVT editor extensively, and it’s tightly linked with the linter. All of our team now uses the DVT IDE for VS Code, although some of us were Eclipse based in the past.

How do DVT IDE and Verissimo fit into your process?
We encourage everyone to write their code in the IDE and to run lint periodically. In addition, we automatically run Verissimo whenever an engineer pushes new or changed code into our Git repository. We don’t accept code into the build of our verification environment until it passes the lint checks. We don’t ask for a manual code review until after a clean lint run. We don’t want to waste our time finding typos, style differences, or well-known language pitfalls when Verissimo can find these.

How have the engineers responded to this process?
Every member of the verification team (ten and growing!) has embraced the IDE and linter. Our observation is that engineers don’t mind having style rules enforced by a machine. Having a single set of rules that everyone must follow saves a lot of time and effort. This is especially true since we hire engineers from many different companies; the AMIQ tools help us quickly align them to a common coding style. This also keeps the humans focused on finding high level issues in the code, rather than focusing on style.

Do the hardware designers also use the tools?
Our more forward-thinking designers do, and we encourage them all to try the tools. Not linting parts of the RTL code is missing opportunities to catch design bugs early. Personally, I can’t imagine writing SystemVerilog with only the simple checks available in Vim/vi or Emacs.

Can you describe some of the benefits provided by the tools?
Verissimo has caught some tricky variable bit width issues where a macro hid that only the lowest order bit was being compared. Both DVT IDE  and Verissimo also save a lot of time. In the past, we found that when we wrote or edited code we spent too much time in a compile-debug-fix loop until it was clean. This happened hundreds, maybe thousands, of times on every project. With the ability to find and fix errors interactively within the IDE, that loop is significantly shorter. We get great team style alignment, with more efficient code reviews. So clearly we save many weeks of effort.

Are there any additional features you would like in the tools?
There are some specific things we’ve asked AMIQ to add, such as the ability to use relative path names in compiler waiver include statements. We’ve also asked them to increase their support for the Verilog-A language, which we use in the testbench for the analog and mixed signal (AMS) portions of our design. In addition, we’d like more flexibility in applying style rules and guidelines.

What are your plans going forward?
We’ve used DVT IDE and Verissimo on every project at Lightmatter, and that’s not going to change. We know that AMIQ constantly adds new lint rules, and we need to review these and decide which ones we want to enable. We have found that some rules, such as those for whitespace and length restrictions, are only marginally useful and take too much time to resolve. We also intend to investigate some new Verissimo auto-correct features and the Specador documentation generator when we have time.

How was your experience working with AMIQ EDA?
They’ve been great to work with. We push our EDA vendors hard, and the folks at AMIQ have been amazing, always responsive.

Is there anything else you’d like to add?
We are surprised that so many engineers in the industry are still using crusty old editors like Vim or Emacs when there is such a productivity gain from using a modern editor with DVT. It seems that some engineers are more likely to change their company, spouse, or country than their editor. We’re not about to give relationship advice, but it’s definitely time to revisit the editor you are using if you haven’t looked at DVT IDE. Verissimo goes hand in hand with the IDE by automating code reviews and allowing you to focus on the important issues.

Engineers join us because they are excited to work on new technology. We need a great working environment to keep them engaged. We have a state of the art setup with a lot of automation and the freedom to deploy the resources they need. If you’re an engineer looking to leave behind a fossilized environment and a team that still uses tools from the 90s, then please look at our job postings!

Thank you for your time and your insights.
Thank you for the opportunity to share a bit about our flows and company.

Also Read:

AMIQ EDA Integrated Development Environment #61DAC

AMIQ EDA at the 2024 Design Automation Conference

Handling Preprocessed Files in a Hardware IDE