Since semiconductor designs now increasingly depend on software and firmware, hardware verification is not sufficient to ensure a chip ready for successful deployment. Teams require assurance about correct interactions between the firmware, drivers, and applications and the hardware. Shift left verification will move these activities to occur earlier in the development process so that real-world use cases can be validated before any silicon is available.<\/p>\n
Traditionally, development required the software and firmware teams to wait for prototypes and first silicon to start interacting with the hardware. However, this could lead to delays when any issues were identified later in the development process.<\/p>\n
Having a pre-silicon verification environment means having an early chance to spot hardware-software interactions that may be problematic. Teams can simulate or emulate the relevant hardware behavior and carry out bring-up of software and firmware before the chips become physically available.<\/p>\n
For the shift left verification process to work, the team needs an environment that resembles the intended hardware closely enough. Hardware visibility and speed are different from simulation, emulation, and virtualization.<\/p>\n
The ideal test facility should allow software developers to test the vital parts of the interface, peripheral devices, memory, and control units. The goal here isn’t necessarily to duplicate every physical feature of the chip, but rather to achieve enough behavioral accuracy for validation of crucial software\/firmware procedures.<\/p>\n
It is crucial to test the individual components, but there are some cases where the workload will consist of the interaction between various hardware and software components. For instance, there may be the need for initialization of peripherals, memory management, interrupt processing and communication with external devices during one workload scenario.<\/p>\n
These use cases can help discover some problems in the context of pre-silicon environment that can be overlooked in individual block-level testing. These use cases can be created based on customer workflows and system requirements.<\/p>\n
The bring-up phase of the firmware development typically consists of such activities as boot sequence testing, device initialization, driver interaction and power management. Finding some problems in these flows after silicon arrival can cause some delays and extra debugging cycles.<\/p>\n
With shift-left verification, firmware teams have an opportunity to do that earlier, and investigate some problems that are related to register configuration or interface of the hardware component.<\/p>\n
To implement an effective shift-left methodology, collaboration is required among hardware teams, verification, firmware, and software. The hardware assumptions need to be clear for software, and the requirements and loads for software need to help plan the verification.<\/p>\n
Test cases and debug data in common will allow determining the source of the problem \u2014 either hardware design, firmware, or interaction of both.<\/p>\n
The purpose of shift-left verification is not to stop post-silicon validation. Actual silicon is still needed to validate certain things that are impossible to validate pre-silicon. Pre-silicon verification helps to reduce the number of fundamental problems with software and firmware at the first-silicon stage.<\/p>\n
Shift-left verification brings software and firmware bring-up into the hardware development flow. Thus, the teams have a chance to validate critical real-life use cases before silicon is available. Combining the pre-silicon environment with the representative workload and cross-functionality helps to find the HW\/SW interaction problems earlier.<\/p>\n\t\t\t\t\t\t\t