In order to design a complete reference design for their SharcFIN™ ASIC based DSP boards that would enable host-to-board, and board-to-host communication, (including loading and running of programs, accessing memory and variables and performing board and DSP operations), low-level drivers for the BittWare boards were required. Additionally, the drivers had to support Windows 98, Me, NT, 2000 and Linux operating systems, with the option to port the drivers to Solaris and VxWorks.
Writing a device driver for each of the BittWare boards for each of the different operating systems would have entailed learning the internals of each OS, learning how to write a device driver for each OS, learning the relevant hardware protocol, developing and debugging in kernel mode, writing the kernel mode device driver which carries out the basic hardware input/output and repeating this process for each of the supported OSs.
Using WinDriver, the BittWare engineers were able to immediately access and control their boards’ resources (without writing a line of code), and then automatically generate skeletal driver code specific to their device. WinDriver enabled the BittWare developers to add functionality in user-mode.
In no time, BittWare engineers had created a driver based on WinDriver, with specific functionality for their DSP boards, which could in turn be integrated into their SDK.
WinDriver eliminated the need to write a kernel mode device driver, by providing a complete hardware access API in user-mode, which may be used in a development environment of the users choice – MSDEV, C Builder, or any other 32-bit development environment. The user-mode API calls the WinDriver Kernel Module (a kernel module generic driver), which then controls the hardware. (See the WinDriver architecture diagram to the right.)
WinDriver’s API is optimized for minimal performance overhead. For the drivers that require kernel mode performance, WinDriver offers “Kernel PlugIn,” which allows code to be created and debugged in user-mode, while running performance-critical parts of the code in kernel mode, thereby achieving kernel mode performance.
The BittWare engineers had identified certain features that were crucial to the success of the toolkit such as hardware auto-detect (so that a list of BittWare boards could be presented to the user), unique device numbers (so that users with multiple boards of the same kind could tell one board apart from the other), and the flexibility to make changes on-the-fly (like DMA buffer allocation).
Whereas other driver development kits presented the BittWare development team with solutions that had marked limitations, Jungo’s WinDriver was selected for multiple reasons. WinDriver could read PCI configuration registers that were behind a PCI-to-PCI bridge under Windows 98. There was no limitation on the number of devices on Windows 98, whereas the competing tool only allowed for a maximum of 10 devices. WinDriver did not require the user to restart the system for each of the installed boards, when multiple boards of the same type were being installed. WinDriver provided a graphical user interface, which automated driver code generation and produced skeletal driver code specific to the BittWare boards’ resources.
With one of the commercial driver tools initially used by the BittWare team, the BittWare team was required to reboot after setting the DMA buffer size in the Windows registry, before being identified to the driver. In addition, only one buffer was allowed per device. The amount of memory mapped for the device could not be changed, even if some was unused. This meant that only three of the BittWare boards could be installed in a system running Windows NT. Using WinDriver, BittWare was able to alter quantities of memory mapped for the particular DSP device and control an unlimited number of boards.
The commercial tool they used only supported Windows operating systems. However, BittWare, having identified growing market demand for driver support under UNIX platforms, was looking for a more flexible solution. The BittWare team started developing a Linux driver, however, shortly abandoned the project when they discovered WinDriver, a multi-platform and cross platform tool, that in addition to supporting various Windows operating systems, also supports Linux, Solaris and VxWorks.Drivers developed using WinDriver are portable between all supported operating systems without code modification.
“When we tried Jungo’s WinDriver, we were immediately pleased with what they had to offer,” said Dave Hedstrom a Senior Software Engineer at BittWare. “Using only the evaluation version, we found that none of the limitations of the competing tool that we were faced with, applied to Jungo’s WinDriver. After only three days of development, we had a working driver and a kernel plug in for interrupts.”
WinDriver features enhanced support for leading PCI chipset vendors (PLX, Altera, AMCC, Marvell and QuickLogic) who have partnered with Jungo to provide comprehensive hardware-software solutions. The enhanced support includes a special set of APIs customized for each of the partner’s PCI devices and accompanying diagnostic samples (source code included). The diagnostics samples enable unrestricted read/write access to all the device’s registers, host and local memory ranges and port I/O ranges. The BittWare Snaggletooth board uses a PLX PCI 9080 interface chip as an interface between the PCI bus and the DSPs and peripheral devices on the board. Thus the PCI 9080-specific diagnostics program and API provided by WinDriver further aided developers in jump-starting their driver development for this particular board, enabling interrupt handling, memory/IO access and performing of DMA functions.
The Host Interface Library (HIL) is the principal component of the BittWare DSP21k-SF Toolkit and is a library of C-callable functions that allow the user to download and start programs on the DSP board, read from and write to the DSP board’s memory, and control other board functions. The HIL provides a common set of functions for all of the supported boards and automatically performs the required interface operations. The HIL’s API (interface functions) are standard across all BittWare boards supported by the BittWare toolkit – programs that use the HIL can use functions to determine what BittWare devices exist in the system, where they are located and determine the types of devices that are present.
The BittWare Toolkit architecture diagram below illustrates how WinDriver forms the basis of the low-level operating system driver, and shows how all communication with the BittWare DSP boards is made via calls from the Host Interface Library to the driver.
The BittWare toolkit includes utilities that use the HIL to communicate with the board namely, DSP Host Library, Diag21k and DSP Bad.
Diag21k, a console application, is a diagnostic utility that allows developers to control, interrogate, and test the DSP board. Diag21k can download and run DSP programs, read from and write to the DSP memory (in multiple formats, including code disassembly), perform memory tests, and display program symbol information. DspHost is a tool for porting existing C applications to the DSP and for creating programs that run on a DSP board but still have access to the host machine’s resources. The DSP Board Automated Diagnostic is a utility operating via a command line, used to test the DSP board for proper operation. It verifies the ability to communicate with the DSP board from the PC, test the memory as well as other special features of the DSP board, and confirms the DSP processor’s ability to load and run a program. The BittWare Porting Kit
BittWare provides a Porting Kit to allow its customers the freedom to use the BittWare board under the operating system of their choice. The foundation of the BittWare Toolkit, meaning the HIL, provides an interface to the hardware that is consistent with all BittWare products. Certain parts of the HIL, however, contain operating system-specific functions that interface with the driver. The BittWare Porting Kit allows the developer to adapt those portions to fit the respective operating system. Once the operating-system-specific functions have been defined, the HIL can be compiled and linked with host programs, Diag21k, or the example programs, so that the developer can then start using the board under the operating system of choice.
The BittWare Porting Kit source code’s operating system-specific functions were developed using WinDriver. WinDriver provides the same API for all the operating systems supported, eliminating the need to write separate drives for each board.
WinDriver supports Windows 98/Me/NT/2000/CE, Solaris, VxWorks and Linux, i.e. the same source code will run on all supported platforms. Using both WinDriver and the BittWare Porting Kit, device drivers can be ported to all supported operating systems without altering the driver code, (given that the same operating system-specific code can be used for all operating systems supported by recompiling the Porting Kit.) Industry impact
The software development kit is an integral part of the value provided by BittWare to its DSP customers. Given that time-to-market is a crucial factor, the inclusion of WinDriver pushed forward the release date of the BittWare DSP 21K-SP toolkit enabling BittWare customers to release quality products rapidly and at lower cost to the market.