Get email delivery of the Cadence blog featured here
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 ...