Improving Verification of Battery Cell Monitoring Chips

Batteries, especially for electric vehicles, are very much in the news these days. This technology is vital for many aspects of our modern lives, but people often worry about things like range limitations and the possibility of overheating. The industry is responding with electronic solutions for improving battery operation. One leading company is Dukosi, whose Cell Monitoring System is revolutionizing the performance, safety, and sustainability of high power batteries used in many applications. I learned that they are a user of AMIQ EDA’s products, so I had a nice chat with Anders Convery, their Senior Principal Verification Engineer.

Thanks for joining me today, Anders. Can you tell me more about your role and your projects?

Happy to be here and thank you for the invitation. I’m the verification lead for the digital portions of the chips in our next-generation battery cell monitoring system. Our solution is actually a two chip solution consisting of a Cell Monitor IC and a System Hub IC. One Cell Monitor chip is installed on each cell in the battery pack, It provides highly accurate voltage and temperature measurements, stores that information on the chip, and sends the data to the System Hub chip using C-SynQ®, our proprietary communication protocol and near field RF. All the Cell Monitors send the cell measurement data synchronously and with deterministic latency to the System Hub chip, which sits on the same board as the battery management system (BMS) host processor and manages the bi-directional communication between the network of Cell Monitors and the BMS host. We also provide software that runs on this processor, as well as evaluation kits to try our solutions and for development purposes.

How is your system different than traditional approaches?

Our near field contactless system as I’ve just shared is very different than traditional wired and even far field wireless battery designs. Traditional battery systems are limited by their wired modular designs as well as economic factors, The result is that traditional approaches usually only measure temperature at one or two points in each module, with typically 12-24 cells per module in an EV battery. Our per-cell on-cell monitoring architecture provides much faster and higher data granularity for more reliable identification of issues that might compromise performance or safety. Our contactless communication and architecture eliminate the cabling and fault prone connectors found in traditional solutions, and our unique communication protocol enables robust, proactive battery management.

It seems as if your chips must have a mix of analog and digital content.

Indeed they do. The analog portions, which include functions such as sensors and RF transceivers, take up about the same amount of silicon real estate as the digital. However, the digital portions are very complex, including multiple processor cores, sophisticated power management, and fault protection logic with many corner cases. All this means that my verification team has a tough and complex job.

What are some of your challenges?

Many of the applications using our chips have high reliability and safety requirements, especially for automotive. For example, we must satisfy the Automotive SPICE (ASPICE) maturity model and Automotive Safety Integrity Level D (ASIL D) as defined by the ISO 26262 functional safety standard. We need to be really sure that our designs have no lingering design bugs. Meeting these quality standards is not just an engineering requirement, it’s embedded in our quality process and product roadmap. So, my team is constantly on the lookout for tools and techniques that help us perform more efficient and more thorough functional verification to meet our high quality standards.

What role do the tools from AMIQ EDA play?

When it comes to writing and editing verification code, DVT IDE is essential. I’ve been using it for seven or eight years now, including for the first generation of Dukosi chips, and I can’t imagine coding SystemVerilog and Universal Verification Methodology (UVM) without it. For the current project, we added Verissimo SystemVerilog Linter to the mix, and it’s proven very helpful. We’ve also started using Specador Documentation Generator, although I wouldn’t say that’s fully adopted yet.

Did you do an evaluation or consider any alternative linting solutions?

Honestly, no. We had a brief look at alternatives but didn’t see anything that looked as good as Verissimo.  Given that our experience using DVT IDE and working with AMIQ EDA was so positive, Verissimo was the natural choice for improving our testbench quality and confidence.

How have you integrated it into your verification flow?

Everyone on my team runs Verissimo as they write or edit code. It’s much more efficient for the person who knows the block to find coding errors right when they happen and fix them immediately. In the past, bugs that slipped through to simulation caused test failures that took hours to debug. By the time the verification team found the cause, notified the correct engineer, and received a fix, it often took a full day. A few minutes to find and fix a bug is a lot better than a day spent debugging.

Do you use Verissimo to gate your repository check-ins?

We do run Verissimo on all check-ins. We don’t require a clean run, so it’s not a hard gate. Sometimes engineers check in code that is still in development for test builds and other purposes. However, if someone checks in code that has new linting errors, he or she must make a conscious decision to do so and have a good reason. At this point, I would say that Verissimo is completely integrated within our continuous integration/continuous deployment (CI/CD) flow.

Do you also do manual verification code reviews?

Yes, our manual verification code reviews consist of three verification engineers—the coder and two reviewers who must fully understand each block. As verification lead, I often review the code as well. There is no doubt that Verissimo makes code reviews much more efficient than in the past. We used to find lots of typos and misuse of constructs. Now, these are fixed as soon as they are written, before code review, check-in, or simulation.

Do you have SystemVerilog and UVM coding guidelines?

Yes we do, and enforcing them manually was challenging. Especially when we brought in contractors during peak development times, it was hard to keep everyone on the same page. We worked with the AMIQ EDA team to configure the Verissimo rule set to capture nearly all our coding guidelines and adhere to Dukosi’s development processes, which are in full alignment with ASPICE PAM 4.0 and ISO 26262. Since everyone runs the tool, now everyone follows the rules. A consistent coding style, even for something as basic as white space formatting, also helps make code reviews faster and easier.

Can you provide some examples of issues found by Verissimo?

It’s quite a wide variety, but a few things stand out. Eliminating duplicated code makes simulation more efficient and updates easier. Verissimo is much better than humans at spotting this issue. It’s also great at identifying dead code, which usually occurs when engineers make changes and don’t fully clean up after themselves. One specific example is outdated coverage groups that are no longer applicable. If they’re not deleted, they become coverage holes and lower our metrics. They require extra work to remove them so that we can achieve our coverage goals. Two other common errors we’ve seen in the past are not checking returns of functions and tasks or ensuring successful casting. Verissimo finds a lot of issues that we used to have to find in manual reviews or when simulations failed.

How has your experience working with AMIQ EDA been?

Great. We have found their tools high quality and very effective for our verification team. We’ve also been happy with their support, and with the resources they provide. If I’m wondering how to do something I haven’t done before, I can almost always find a short video on their website showing me exactly the right steps.

How do you plan to improve or increase your usage of AMIQ EDA tools going forward?

We have some ideas for new Verissimo rules and we need to find the time to document these so that AMIQ EDA can consider adding them. We’ve already suggested an enhancement in rule waiving, so we’re looking forward to that.  We have turned on some rules related to simulation performance, but we need to spend more effort looking at what’s available. We have not looked at AI Assistant yet, so that’s on our list to investigate as well. We also need to spend more time working with Specador to ensure that the documentation it generates has all the information we need and meets our quality standards. Finally, the design team hasn’t fully adopted Verissimo yet and we’re encouraging them to use it more.

Anything else you’d like to add?

Verissimo, just like DVT IDE, has become a mandatory part of our verification flow. Without it, my efficiency would slow down fourfold. So I’m glad to talk with you to spread the word and encourage more engineers to share in the benefits we’ve seen.

Thank you so much for your time.

You’re most welcome!

CONTACT AMIQEDA

Also Read:

Giving AI Agents Access to a Compiled Design and Verification Database

2026 Outlook with Cristian Amitroaie, Founder and CEO of AMIQ EDA

Runtime Elaboration of UVM Verification Code