Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
One of the most common questions asked about virtual platforms is:
Who creates the models?
There are many sources of models and there are people who can make additional models (like Cadence), but obtaining some experience in model creation and virtual platform construction is a great skill to have if you are a software engineer, a hardware designer, or a verification engineer.
Most companies providing commercial virtual platform tools have tools to create models. Cadence has a model creation tool which generates models from register descriptions called tlmgen. Refer to Creating SystemC TLM-2.0 Peripheral Models to understand the flow.
The most important step in the model creation flow is to add the functional behavior for a new model. This was not really covered in the above article. Generally, there are two ways to extend the generated model and implement behavior:
For new model design, I start from the first point to determine what needs to be added to implement the model behavior. Designing models is different than designing hardware in Verilog or VHDL because the actions are much more abstract, and the goal is usually to provide the needed functionality with high performance. This means there is less thinking about state machine design and clocks, and more thinking about the register interface and what is supposed to happen when registers are accessed.
Recently, I found an old piece of scratch paper in my backpack that I had used to create a new model. It was one of those cases where a project needed a model quickly and there was no time for fancy design diagrams.
The picture is a little hard to see, but what I did was draw some pictures of the key registers and fields and map out what kind of actions were needed on reads and writes to those registers, and what kind of side effects (such as changes to other registers) were needed. This helps when the field names are things like MSI, RLSI, TBEI, and RBFI. Without such a planning sheet I find the alphabet soup hard to remember. Each person has their own ways of reading through specs and understanding and capturing key ideas needed for model creation. Feel free to share ways you create models or other design software you use to track and summarize model implementation.
Besides adding functionality, a model developer should think about what he wants to communicate to model users. Good models quietly provide needed functionality, and if things go well users don't even notice the models are there at all; they just work. Sometimes it's important to communicate important information to model users, and there are many ways to do it. Obviously, print statements are common. SystemC also provides a verbosity level and message reporting functions to help control which messages users see. Developers need to decide how to use the SystemC verbosity control and decide what is important and what is not all that important. Personally, I think all of the flexibility provided to model developers is sometimes more of a hindrance than a help.
For example, the default SystemC verbosity level is SC_MEDIUM or 200. What kind of information is "medium"? Then there is SC_DEBUG or 500 which is assumed to provide more information about a model. Consider the debug message below from a model when the verbosity level is set to SC_DEBUG using:
ncsim> scverbosity -set 500
There is also instance specific verbosity, which is normally discovered after you realize you are overrun with messages. This allows users to set the verbosity on a specific instance in the design or even a part of the design using the -recursive option. When developing models ask yourself which software engineer trying to run his code on a Virtual Platform knows that when it doesn't work he should use the instance specific verbosity control to try to get more information from a model? Some might think to do it, but most probably will not.
Virtual Platform tools also provide features such as logging events, messages, and other interesting activity to a log or database for efficient recording. The Cadence Virtual System Platform provides something called the "VSP Log Viewer" which is a database of useful information containing model and software activity. Tools also provide GUI toolkits or parameter displays for models to use to communicate the status of a model or model actions, such as removing the SD card model.
Good models give just enough information to trigger a user's brain to recognize possible problems without overwhelming them with too much information. Tools can help capture, filter, identify, sift, and sort data, but nothing replaces the skills of a good model developer. I bet there are some experienced model developers reading, so please share techniques you use to decide what to share with model users or share stories about past experiences. Maybe there was a situation when you wish you would have shared more or less model information, or a time when you shared just the right information to quickly identify a problem.
While working with students I’ve seen often that it is very difficult for trained hardware engineers to reach the state of programming SystemC in a efficient manner.
On the other hand software engineers don’t get the odd concurrent statements SystemC needs to simulate proper hardware.
So the most important part of teaching somebody to design abstract hardware models in SystemC is to make them understand to let it go, and accept a completely different approach to write a similar thing as usual in a different manner.
So in my opinion develop good SystemC models start with a lot of looking in other models and reaching the right state of mind to be able mix hardware and software paradigms right.
Facing an issue into a Virtual Platform's execution you cannot immediately ensure where the problem is : into the executed SW, the model, boths ... the only effective way (I practiced) to verify and dbug is through a pair section : the SW guy sharing his knowledge and implementation and the VP guy doing the same ...