CASE STUDY – vxWorks BSP For Deep Packet Inspection System
A vendor of Deep Packet Inspection Systems used by several major Telecom / ISP operators had a problem. The network processor chip that was the key component of their multi-card system was going end of life. Without a replacement, they would be unable to meet their commitments to ship systems.
The solution was to re-design the packet processing cards in the system to use a new, untested, network processor chip that had some similarity to the one in the current version of the system.
Initial BSP Analysis Work
Once that decision was made, Lextel was asked to develop the Board Support Package (BSP) for the new card. The objective being to enable the new card to operate seamlessly in the existing deep packet inspection system.
The first step was to determine the basic plan of action. The vendor of the new packet processing chip already had a Linux bsp and a demo card. However, the deep packet inspection system used vxWorks, and obviously was a different piece of hardware. Adding to the difficulty, the version of vxWorks in use on the DPI system was 5 years out of date, and did not have native support for the ARM11 core in the new packet processing chip or any of the non-core portions of the chip.
Lextel weighed all the options and recommended that the BSP for the new card be based on the version of vxWorks currently in use in the DPI system, and that Lextel would alter the vxWorks Kernel/OS itself as part of the BSP development so that it would run on the new ARM11 Core.
At first this seemed like a problematic choice, but Lextel suggested that the other options, either upgrading to a newer version of vxWorks, or running Linux on the new packet processing chip, would prove to be even more difficult and time consuming to accomplish, given the large base of existing software in the DPI system, which amounted to several million lines of code. The customer agreed with this analysis.
This is an example of a typical problem faced – new projects are not always starting with a clean slate, and it is important to consider several options and the cost / benefit relationship among the options.
BSP Development on Demo Card
Lextel developed the needed BSP. In this case, the software included the ‘standard’ BSP items such as boot code, operating system startup, serial and ethernet drivers, flash memory drivers, etc. In addition, we needed to modify the operating system memory management, cache control, real time process control, exception handling, and other functions to work with the as yet unsupported ARM11 Core. In this instance, the ‘BSP’ also included many other system specific pieces of code that run in ‘kernel’ mode, such as temperature monitoring, firmware update code, version reporting, device drivers for pcie switches, network chip, internal processor atomic hardware operations, qdr, and other items.
Since actual hardware was not available, we used the vendor’s demo card to the greatest extent possible for testing. This enabled many months of test and debug to proceed prior to having the real system hardware. Compile time constants were used to build the code for either the vendor demo card or the customer’s hardware. This also allowed the demo cards to be used by other developers even after the real customer hardware was available but in short supply.
Significant complications developed on this project because the packet processing chip was brand new. During the debug process, various chip defects were diagnosed. Lextel was able to identify, isolate, and come up with workarounds for many of the identified problems. We worked closely with the IC vendor engineers to help isolate and identify problems and workarounds. Persistence and creativity enabled us to get the software running on the new card.
In the end, the engineering manager(s) concluded that Lextel saved the company 100’s of thousands of dollars on the cost of this project as compared to the cost quoted by the Operating System Vendor’s technical services group to develop a BSP for the chip vendor’s demo card. In addition, the OS Vendor would not have developed the BSP for the client’s actual hardware, which would entail significant additional effort.
BSP Tasks Completed
- Initial Analysis
- Recommendation of development options
- Development Proposal including Schedule, Risk Factors, Steps
- Development of software
- Add support for new processor core to Operating System
- Add support for new packet processing chip hardware
- Provide seamless integration with existing software base
- Debug and Validation
- Identify, Diagnose, Workaround IC Defects
- Deliver project on projected schedule
- Provide cost effective solution
Background Information on this project
Please let us know how we can help you!