If every hardware engineer just understood that...
Updated: August 17, 2004
On This Page
Steve Dispensa: …the Windows kernel is an asynchronous programming environment.
It's not possible to wait for long periods at raised IRQL for things to happen, and it's inconvenient to require work-arounds like worker threads or driver-created threads. If only hardware engineers understood a little about the programming model and worked closely with a Windows driver developer during the design phase of the hardware, angst could be avoided. For example:
If hardware engineers understood that Windows is not a real-time operating system and it cannot put tight bounds on interrupt latencies, then they would not create hardware that has to be "touched" within a timeout period.
If hardware engineers understood the programming model, they'd realize that it's a bad idea to combine disparate pieces of technology onto a single card and expose it through a single hardware interface. Driver support may require the difficult programming solution of creating a WDM bus driver, rather than the more straight-forward solution of writing a function driver.
So, if hardware developers would read at least:
A few chapters of Programming the Windows Driver model by Walter Oney, especially Chapter 2, "How Drivers Work," and Chapter 14 sections on System Threads, Work Items, and Watchdog Timers
The WHDC Driver Fundamentals papers, especially the papers on "Scheduling, Threat Context, and IRL"
The Hardware <-> OS interface information in Dekker's and Newcomer's Developing Windows NT Device Drivers: A Programmer's Handbook
And if only hardware engineers would provide reasonable documentation so that driver writers don't have to spend time reverse-engineering cryptic documents (sometimes long after the hardware was originally designed). I don't care a bit about pin-outs, of which plenty of diagrams can be found, but I do care a lot about the programming interface and its semantics, which are often under-documented.
Bill McKenzie: …hardware specifications are both precise guides and not the last word, the world would be a better place.
If every hardware engineer just understood that hardware specifications are both precise guides and not the last word, the world would be a better place. While these two properties may seem at odds with one another (especially if you happen to work in hardware design), they are not. I wish I had a dollar for every hardware device I have seen that did not follow its associated bus specification. I would not be rich, but I could take a nice Caribbean vacation. While many electrical details in hardware specifications might leave room for play, register specifications typically do not. At the same time, just because a specification allows a certain feature in a hardware design does not mean that that feature should or even could be used.
The number of PCI devices which fail to follow the PCI multi-function specification is staggering. I do not know what it is about each function of a PCI device needing its own Base Address Registers (BARs) that so many hardware designers seem to not understand. The PCI specification seems fairly plain to me. Likewise, USB interfaces are numbered starting at zero not one. Of course, the USB specification is somewhat confusing here, as configurations are numbered starting at one. Obviously, a specification written by hardware engineers.
It is probably asking too much, but it might be useful for hardware designers to consider their audience when designing their wares. How many years now has Windows absolutely dominated the desktop computer market? Yet it is amazing how many hardware designs are launched for the desktop having neither been designed for or tested on Windows platforms. Consider the following: It might be a good idea to include a serial number string descriptor with your USB device. If this statement does not make sense to you, then you must be a typical hardware designer.
The most irksome hardware engineering missteps are those that do follow the specifications, but which are completely impractical. For instance, the USB specifications would seem to indicate that a USB device which supports multiple configurations is perfectly valid. However, this simple lack of understanding of the target platform can wreak havoc on your Windows hardware product's cost and schedule. Why? Try a Google search for "USB" and "configurations" on any of the Windows driver-related newsgroups and see if the answer becomes clear. A simple hardware design change can save weeks of software effort.
I believe it is absolutely critical for any professional to be familiar with technology at least one level deeper and one level higher than they work. For Windows driver developers this means knowing the platform (hardware access, assembly, operating system internals, etc.), and knowing the application layer (Win32, perhaps COM, etc.). For hardware engineers this means knowing some physics (parasitic capacitance, radio frequency radiation characteristics, etc.), and knowing the platform (Windows quirks, bus specification, Microsoft technology whitepapers, etc.). Study up, hardware engineer, and co-design with your software group. You will make your boss, customers, and colleagues in software a lot happier.
Lest I seem too harsh, I should say that I have worked with some top-notch hardware talent. I have rarely seen the types of mistakes outlined above come out of groups I have worked with.
Tim Roberts: …write-only registers make debugging almost impossible, our job would be a lot easier.
If every hardware engineer just understood that write-only registers make debugging almost impossible, our job would be a lot easier. Many products are designed with registers that can be written, but not read. This makes the hardware design easier, but it means there is no way to snapshot the current state of the hardware, or do a debug dump of the registers, or do read-modify-write operations. Now that virtually all hardware design is done in Verilog or VHDL, it takes only a tiny bit of additional effort to make the registers readable.
Another typical hardware trick is registers that automatically clear themselves when written. Although this is sometimes useful, it also makes debugging difficult when overused.
Stephan Wolf: ...interrupt registers should be stand-alone.
It is crucial that the design of a device allows for non-destructive access to its interrupt-related resources from any driver context.
Drivers use various synchronization techniques like spin locks to protect shared device or driver resources from simultaneous access. One critical resource is device registers related to interrupt processing, which usually every device has:
the interrupt source register
the interrupt mask register
When the device issues an interrupt request (IRQ), the system invokes the driver's interrupt service routine (ISR), which needs to perform the following actions very quickly:
Check if the IRQ is from the driver's device. And if it is then…
Mask (disable) all IRQs from the device.
If the ISR cannot read and write the interrupt source and mask registers on the device without causing race conditions with respect to other driver routines, the driver needs to synchronize access to these registers.
KeSynchronizeExecution() synchronizes execution with the ISR, but drivers can avoid this extra overhead, which costs a lot of CPU cycles and accepts the risk of preventing the system from running smoothly.
Hardware engineers should therefore:
Design stand-alone interrupt source and mask registers that contain only bits related to interrupt processing.
Leave out any destructive side-effects from interrupt-related registers like "auto-clear on read" if the driver cannot otherwise retrieve or restore the register's information afterwards.
Place interrupt-related registers in an address range that is always "visible" regardless of, for example, any register banks that can be switched.