The typical development methodology can be summed up in the phrase the device model is the inverse of the driver. In short, it works as follows: Starting with a skeleton model, boot up the driver in Simics and use the inspection facilities to see what device registers it accesses first. Model those, and if necessary the subsystem behind them, using the hardware documentation for reference. With the additions in place, run the driver again to find the next part of the device that needs modeling. This is repeated until no more unaccounted-for references are found, at which time the device is declared finished.
The skeleton model needs to be detailed enough to allow logging of the activities of the driver with respect to the device. For example, all interface registers may be modeled, but their semantics may be left unimplemented.
Running the software will also help the developer understand what modes of functioning will or will not be used in the device model, such as commands or setup options that are never used.
If the hardware documentation is not available, it is often possible to use a well documented open source device driver for reference when implementing the semantics of the device.
See section 8 for more on how to test device models during development.