It will be about using models of not the most simple devices, such as, for example, SoC (System on Chip) or printed circuit boards with many integrated devices on board. In the development of these devices themselves, two stages can be distinguished. The hardware is developed first. This is a slow process – it can take a year or more.
After the first revision of the physical device appears and basic checks are carried out, the device is transferred to the software developers. From this moment, the second phase begins – the development of software for the device. These can be firmware, BIOS, BSP / CSP (Board and CPU Support Package) for various operating systems, as well as drivers.
By the way, in the development of chips, which are often called “silicon”, these phases are called “pre-silicon” and “post-silicon” or simply “silicone”.
In theory, software development is possible before a physical device appears. However, in practice, so few do. Development without the possibility of intermediate launches and debugging, and this is exactly what a device is required for, is a very thankless job, I have met few such masochists. Everyone is waiting for “hardware”, but it, as I wrote above, will appear only in a year.
Besides, there is another problem with the hardware. The first revision is released in a limited edition and handed out one piece at a time. Simply put, there are not enough boards and chips for everyone. There are queues, conflicts, it comes to assault. And if you accidentally burned a device, which is very easy, then all development stops until another device is found. Often it is not found, it is necessary to produce a new one, and then wait for delivery. This greatly slows down the process.
And then simulators come to the aid of software developers!
The creation of a virtual device model begins simultaneously with the design of the physical device. But since the creation and release of a model is much easier, the first releases of such models appear conventionally not in a year, but much earlier. Using such models, software developers can immediately start their tasks without waiting for “hardware”.
Yes, there will not be all the functionality, but programmers at the first stages do not need all of it. Until the device is made, teams of hardware architects, modelers, and software developers must have clear and consistent plans that reflect what specific functionality should be done at what stage. At each iteration and with each stage, the virtual model grows with additional functionality, which, in turn, is used by software developers to write a driver or create firmware for this particular functionality.
In this approach, model and software developers use common specifications. By running software on a model, they are essentially checking each other’s work.
An additional plus is the validation of the “hardware” despite the fact that the hardware itself is not even there yet. It sounds surprising at first glance, but we are talking about architectural errors in the design of the device, some of which can be detected when running software on a model. And this is very cool, as it is possible to fix these bugs in the hardware before it is released. Otherwise, these errors would lead to the need to re-release the next revisions, and this is quite an expensive pleasure.
We had a case when 10 blocks for processing the incoming data stream were implemented in a complex device, and the control and management registers allowed us to work with only half of them. This was implemented in the previous version of the device, and the architects simply forgot to expand this part. When we created the model and the other team wrote and ran the driver, it quickly turned out that all the advanced functionality was not available. The architecture and specifications were corrected in time before the physical prototype of the device was created.
Large device companies can support an entire ecosystem built around their products. This ecosystem includes many other companies, including those that produce software for this equipment. For example, these can be BIOS manufacturers, the so-called IBV (Independent BIOS Vendors), the most famous of which are AMI, Insyde, Phoenix. Such companies also receive models from the hardware manufacturer and begin development before the physical device appears. For example, for Intel platforms, the Simics simulator is used, which can be read in more detail in the article Ecosystem Partners Shift Left with Intel for Faster Time-to-Market…
It is obvious that creating models requires additional costs. The amount of costs, of course, depends on the type of models (functional, per-cycle, etc.), but in general, the cost of creating a model can be assumed to be approximately equal to the cost of writing software for the device. Not all companies are willing to pay this price for an earlier release, which is why this approach is common in large corporations. They have sufficient budgets for this, and an earlier launch of a product on the market significantly increases their income. Although recently, there has been a tendency for more widespread use of simulators for software development in small companies.
Often, to reduce costs, the model does not implement all possible functionality, but only the minimum necessary for certain scenarios of using the device. For example, if a network device is not planned to be used in VLANs, but only to update the firmware and download via tftp, then it is not necessary to implement the logic with VLAN tags, but the functionality for scenarios of device boot over the network and firmware updates must be fully implemented volume.
What is the end result?
If we assume that the development time of hardware and software are approximately equal to each other (see the picture above), then the use of models can significantly, almost 2 times, reduce the time to market a product (so-called TTM – Time To Market) , since the development of “hardware” and software is carried out in parallel, and not sequentially. For this, the term Shift Left is often used, which came from the field of testing, where it meant testing as early as possible. The same term applies to software development, which seems to shift to the left in the timeline when it is executed on the simulator.
By the time the first revision of the equipment appears, all that remains is to check the functionality of the software on real hardware. Ideally, errors and fixes should not be significant and this stage does not introduce large delays, since the code has already been written and debugged on the model.
This approach is not “free”, it requires an additional budget and a team of programmers, so you need to clearly understand how much these costs will pay off in one case or another.
This is not the only use case for simulators. I will talk about architectural research and creating complex environments in the following articles. Don’t switch.