There is a new post at my Wind River blog, about how the LDRA code coverage tools have been brought to work on Simics using a simulation-only “back door “.
The most interesting part of this is how a simulator can provide an easy way to get information out of target software, without all the software and driver overhead associated with doing the same on a real target. In this case, all that is needed is a single memory-mapped location that can written to be software – which can be put into user-mode-accessible locations if necessary.
Some hardware actually exposes something similar, with hardware trace ports that is part of the on-chip debug blocks like ARM’s CoreSight. However, in hardware, that still requires some form of hardware connection to the chip to be available to get the data to where it can be processed. A key advantage of a simulator is that in the most extreme cases, we could simulate a computer system put into an inaccessible location (like inside a aero engine) along with its physical environment (very hot gases and lots of hot moving parts) – and do code coverage on the software in a way that just could be done in hardware due to the total absence of communications path to the physical hardware.
It is also an interesting personal thing for me, as that simple device we used for this is the only piece of simulated hardware in the Simics distribution that I created. Everything else I do is bolted on to the outside as demos, and demos don’t typically ship as part of the product.
OK you did a marvelous system that functions perfectly. What is next?
A little reminder : there is a very good chance that the machinery you designed will function long time after you die. You can not really simulate this 🙂 .