Which Group Should Create System Models?

One of the factors affecting adoption of a system-level flow is identifying who will do the work to create the system model. For most organizations it’s not something they have allocated to a specific group.

Generally when an ESL flow is deployed, the software developers, architects and hardware designers will all benefit from the investment, so it would be reasonable that they all contribute. A complication is that these groups will benefit in different ways. While the requirements of the different groups may not be exactly the same, there is generally enough similarity that one model can be created as a basis to satisfy all of the needs. Some evolution or enhancement of the model will naturally occur to match the specific needs, but an appropriately abstract model generally will be flexible enough to be valuable to all.

At DAC earlier this month I saw a very good presentation from Chris Daniels of Oracle, describing his company’s implementation of an ESL flow. An interesting aspect of their experience was that the ESL design was created by the hardware verification team. In their case the verification team had the responsibility to satisfy their software developers, verify the architectural decisions and create the predictor for their UVM flow. In their organization the verification team essentially was responsible for satisfying most of the requirements for the other groups that could be satisfied with an ESL model, so it made sense for them to make the investment in creating the model.

Chris is a customer I’ve worked with, and in watching his description of their experience I started wondering if the verification team was always the right group to drive creation of the system-level model. Thinking about some of the other organizations I’ve worked with I realized that ESL success is not really related to the specific group implementing the model, but more dependent on the mindset of the engineers doing the work.

To be effective at creating an ESL model you need to be able to think about the design at the right level of abstraction. Hardware designers often run into problems in trying to be too close to the RTL implementation. The hardware engineer needs to be able to eliminate clocks and signals from their thinking in favor of transactions or messages. Software engineers generally have no trouble thinking in terms of message passing, but often get hung up on the concurrency and structure required to create a model good for more than functional verification. Performance modeling and use in a verification flow requires a model that reflects the architecture of the design. And systems engineers generally have no problem with the previous issues, but sometimes they are not as comfortable with the coding required to create the models, or stumble over the need for enough register accuracy to be appropriate for software execution.

I have worked with engineers from all of these areas who have been very effective at creating ESL models, but I’ve also seen quite a few engineers struggle to get an appropriate mindset. From what I’ve experienced, the ideal engineer to create the system-level model can come from any of the discipline areas. They generally share a few common attributes. They’re comfortable with C/C++. They have a solid understanding of the system architecture, both the data flow and the control flow through the system. And they have the ability to think about the communication as messages without needing to drop down to a clocked signal level and the ability to think about the function as a response to a message rather than a clocked sequence of steps. The key is for the engineer to go into the process with the right mindset and an understanding that an ESL model is not the same as any of the other models being created. With an effective model we can gain many benefits and often, as Chris found, there will be as many unexpected as expected benefits from investing in an ESL flow.