|
||||||||||||
|
Why Our Customers Choose to Use MiM Top 3 reasons cited in case studies below
On this page
Case Study 1 Background
What was said about MiM
Features they like
Case Study 2 Background
What was said about MiM The consistency of models is a key feature. Decades ago, he thought that his expertise meant that he could move faster without learning a new tool, and write the exact code he wanted. Experience has shown him that even very experienced engineers make different choices every time they hand code models, and those inconsistencies can inhibit simulation debug and model re-use. Using a tool-based approach, all models are constructed in a consistent fashion, and if common content changes, rebuilding them to incorporate the new content is easy to script. MiM is such a tool, and MiM provides features to make regenerating all of the models with the new content easy. With MiM containers, it's easy to create common content. When he needs help with getting many models done, he can focus on training the modelers in the tool use, rather than what features are needed in every model. With the model vs schematic tests, he can trust that the model behavior matches the behavior of the circuit that will be taped out. MiM gives him the testbench for model vs. schematic comparison. If he's working on a model where the transistor level view is already available, he can immediately check that the model and the schematic are consistent, and trust the higher level simulation will match tape-out functionality. The spec-based approach of MiM allows many simple models to be created, tested vs schematics, a lot more quickly than hand coding. In MiM-2 it's easy to create SystemVerilog discrete electrical models without having to know much, or even anything, about SystemVerilog User Defined Types (UDTs). His modelers can focus their attention on just modeling voltage, currents, and resistance. And finally, being able to synchronize the pins in the symbol view with MiM is helpful. When asked about time savings He doesn't think in terms of time saved. MiM easily gives him capabilities that would take months for him to build into a flow. If starting without MiM, he would want to write a tool that generates models to create consistency (as he had a previous company). Developing his own at a start up would take too long and so he would have to do without. He would also have to do without model vs. schematic checking, which would otherwise prove too time consuming without an automated way of generating testbenches. This would undermine the validity of any top-level verification that involved analog blocks. Even if he had time to develop his own framework, as he had at his previous company, the home grown tool would be incomplete and difficult to maintain. And it's difficult to imagine that he'd have so much time that he could go beyond model generation to model vs. schematic checking. For day-to-day model writing, there is time savings, but the real value is having the entire flow in place immediately. When asked why MiM was chosen When he began at his current startup, he didn't want to have to build the modeling tooling infrastructure himself; he didn't want to struggle with model consistency; and he wanted a model vs schematic test capability. His perspective on modeling and verification is that you realize you need this kind of consistency at the worst possible time, right at tapeout, when there's a ton of work. If you don't have an automated framework like MiM, it's going to be weeks of grinding work with management breathing down your neck because they want to release the tape out database. He said that it took him "longer than the average bear to get smarter than the average bear" to realize this. It was this thinking that drove him to MiM. You need methodology to the madness. You need to write a bunch of models, and you need to get started before schematics are ready. You could write them by hand, but it just takes too long, and the testbenches would take even longer. Given that MiM was available, there was no reason to consider creating his own framework. Case Study 3 Background
What was said on generated models He likes that all models follow the same code structure. This makes them easy to read. The MiM specifications help a lot as one can see at a quick glimpse what is going on. Without MiM each engineer would follow their own style. Having a consistent style is critical for bringing up chip level simulations quickly. He likes that there is a well structured method for handling detected faults. He said that this is also critical to getting a chip-level simulation up and running. He mentioned that the utilities provided allow for quick launch of simulations. They provide easy management for the models and testbenches. And that the "av pop" command for netlisting allows one to see everything that's going on in the chip all in a local area. It is much easier to enter specifications instead of coding. MiM removes the redundant coding work such as writing assertions. He doesn't need to remember how to handle the many scenarios that arise when writing models, such as when to use continuous assigns vs. always blocks. He also doesn't have to worry about coding syntax errors. He can easily change behavioral equations in the specifications instead of editing the model itself, which takes much more time and is more error prone. What he said about the generated testbenches The generated testbench is also well structured. It covers many test cases out of the box. If we need to add tests manually using the user code feature, we can take advantage of the predefined tasks and instruments to make the focus of the code writing not on the details but on what we are trying to accomplish. MiM-2 adds capability to allow for the seamless re-use of test code so that it can be easily parameterized and shared between team members. What was said on entering specifications It is easy to enter assertions, especially with the options such as timeout and gating. It can handle concepts that without a generator would result in complex code with simple and readable words such as "smooth". It prevents many copy/paste mistakes compared to writing code. For example, when writing assertions by hand, they would rely on copy and pasting code, but then they would often forget to update parts of the code, such as the range, often making an assertion useless. What was said on model language neutrality For models with simple interfaces, the same spec can often be used to generate both Verilog-AMS and SystemVerilog models. The design engineers can read the specifications, but usually are not able to fully comprehend the models. They don't necessarily remember or know all of the details such as how to use UDTs (user defined types) in SystemVerilog to model voltage and current. What was said on teaching new engineers With minimal knowledge of Verilog-AMS and SystemVerilog, new analog/mixed-signal verification engineers can get started quickly. The MiM syntax is easy to read and well documented. The flow it provides also helps to get them up to speed quickly with all of the verification tasks, such as running model vs. schematic simulations. They can get quite far with what's provided out of the box. For example, instead of teaching someone how to write code to measure clock frequency, they can just specify that they want to measure the frequency of a signal in a MiM specification. Once they start, it is important that they eventually understand the code that MiM generates when working on more complex models that might require using the MiM user code feature. He has his new engineers start on blocks that don't require user code initially. Then as they learn from reading the code that is generated for those blocks, they get more experience and become used to the code. From there, they can move onto working on the blocks that require user code. Papers at DVCon 2024
Advantage for small and medium sized companies MiM provides an analog/mixed-signal verification environment. It was been our observation that many, if not most, big companies or big verification groups already have a MiM-like tool. We would characterize these as template (often a "Mad Libs" fill-in-the-blank approach) or partial model generators mostly focused on the generation of the pins and assertions. Our model solution is complete in that it covers both the assertions and behavior. In addition, their testbench capabilities are typically non-existent or very limited. There's only so much that a typically non-dedicated group with a limited set of internal customers can do in providing a general solution. Although not always the case, some of these home grown solution suffered from the fact that it was mainly developed by one or two individuals. Companies were often unable to maintain and update their solutions when these key employees left. We have two new customers, both of whom had been at large organizations with a set of capabilities, but at their new startup to medium sized companies they found that they had no such framework. They came to us so that rather than starting from behind where they would have been, they could get a jump start. |
|||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||
