Black, white and even grey box testing techniques from the world of hardware and software integration are finding a place in semiconductor IP subsystems.
Much has been said about the need to incorporate software into chip and board level hardware design. Cadence’s EDA360 vision is but one example of the realization that silicon and software must be co-developed to achieve the optimal system design.
Integrating the disciplines of hardware (chip) and software design is not an easy task. It requires a systems engineering approach throughout the entire development life cycle, but particularly during the design and integration phase. While hardware and software engineers are experts in their respective “white box” domains, System Engineers have experience integrating the resulting “black box” subsystems.
Let’s be clear on terminology. “White box” refers to a method of testing where the internal workings of electronic components or software code are known. This is where hardware or software domain-specific experience and knowledge are needed.
Black box testing refers to functional tests where the internal workings of the hardware or software subsystems are unknown. In Black Box testing, only the input and output parameters of the subsystem are known. This is the realm of Systems Engineering.
To successfully integrate hardware and software subsystems, a Systems Engineer must have a working knowledge of both domains. He or she must be able to communicate effectively with both the hardware and software engineers during the white-box testing that precedes full system integration during the black-box testing phase.
Further, in the shrinking time-to-market (TTM) windows of today’s electronic systems, software development must start before hardware is fully available. This need has resulted in a co-design methodology between hardware and software which in turn affects traditional white- and black-box testing. The Systems Engineer must be involved in both co-design and co-testing to ensure validation and verification of system level requirements.
What does all of this mean to the world of semiconductor IP design? One of the problems with integration of large blocks of third party IP – think ARM cores – is that signals may cross different clocking domains. By design, semiconductor IP cores – logic, cell or chip layout – are black boxes for the SoC integration team. How does a System Engineer ensure successful integration in a purely black box environment? One way is to have access one or two relevant white-box parameters, resulting in what has been dubbed grey-box testing.
Grey-box testing is black-box testing with some knowledge of internal data structures and algorithms. It can be thought of as selective white box testing but without full access to the software’s source code. Black box models provide input and output signals, but nothing else. In IP integration, a grey-box model may provide a single level of register logic to enable inter-block analysis. This additional knowledge should provide greater test cover that result in fewer end-product failures. One example of the grey-box approach was provided by Blue Pearl’s recent partnership with Xilinx – announced during DAC 2012 – to develop grey-box testing for ARM core based System-on-Chips (SoCs).)
White-, black- and grey-box testing strategies are but one of many issues faced in SoC IP integration (see, Experts at the Table: IP Subsystems” ) Yet all of these issues are but a subset of challenges encountered in the integration of larger hardware and software systems – e.g., at the board, module and top system level. The goal is that successful approaches are applied throughout all level of the system hierarchy.
If you’d like to explore these and other hardware-software integration issues, then you might enjoy attending this online course which starts on June 25, 2012.