On Sunday night at DAC we heard from Gary Smith that traditional EDA companies need to grow into new market segments in order to stay relevant, and that a systems-level approach to multi-disciplinary engineering was called for. I almost jumped out of my seat and said, “Hey, what about Dassault? They are already doing that now.” Hopefully Gary is reading this blog, and will update his slides for DAC 2016 in Austin and at least mention the several systems-oriented companies that intersect with EDA.
Q: What is a trend that you see at DAC this year?
Well, one big thing at DAC is the discussion on requirements-driven verification (RDV) strategy. Design companies are understanding that you must tie requirements to EDA tool results.
Semiconductor companies have requirements that are unfortunately spread out in over a dozen different places, but in a functional verification flow a bug could be in your plan, the design or the testbench. RDV tracks the entire path from requirements to verification results. Anything that produces a report can be linked back to requirements.
Q: I remember hearing about a requirements tool called DOORS back in the 1990s. What’s new in this space?
Rational Software created a requirements management tool called DOORS, now owned by IBM. Reqtify is the Dassault tool for requirement traceability and impact analysis, but it links with all the other requirements tools and imports them into our system to create the traceability. If someone changes requirements, it tells the designers what the effect is, new requirements are in place, your old results are valid.
A graphical representation of requirements, test benches, design files and results are available with Reqtify. That tool answers questions like what has changed, what is out of date. If a requirement changes, we know all about.
The ad-hoc approach to requirements is now replaced with this structured flow.
Q: How does this requirements traceability process work with EDA tools?
All the outputs of EDA tools are now stored away and cataloged, and you have a dashboard across the flow, so that you can now look at historical trends and ask an important question – are we getting better?
- functional coverage
- timing closure
- DFT coverage
The dashboard is configurable by the user and new tools can be added for tracking.
Related – Managing Semiconductor IP
Q: Who would be using a requirements tool on a design team?
It could be any engineer, but mostly we see that it is a verification engineer.
Q: What is management concerned about on large system projects?
Management likes to work with project plans – using the notion of invisible governance, where you can actually track EDA tool data against your milestones so that status is auto-updated once you install the infrastructure. End-users can focus on each of their specialized design tasks, while reporting is automated for them.
We do find that there is a bit of a big-brother aspect, because your design tasks are being tracked and reported.
Engineering data can come from design engineers, product engineers, even manufacturing – because all can be included in the system.
Q: What is a decision support system and why is it useful?
A decision support system answers the primary questions of:
- Where am I in this process, are we really done designing yet?
- How well are we tracking against plan, with these engineering resources?
- Which design team is most effective in their projects?
With a decision support system I will know which resources will help me get to my goals. The more that you use the system, the better the prediction results are.
Q: How does this all work with other EDA vendor tools?
All of the big three EDA companies work well with Dassault, because each of their point tools work well within the Dassault environment.
Also ReadShare this post via: