![]() ![]() ![]() You start with the software and debug it using the standard software debug tools. Improve Debug Visibility AND Run Fasterĭebug is a process of detection and elimination as we know. The ability to efficiently debug hardware problems on your FPGA platform is a huge shift and a time saver for FPGA prototyping as a hardware verification platform. Modern FPGA prototyping platforms such as the Synopsys HAPS®-100 prototyping system change all that with high debug productivity capabilities. The whole process can take days or weeks and is often unsuccessful. This can be a difficult and lengthy process using binary chops to narrow down to a testcase that is small enough to replay on your emulation or simulation platform. Historically, when hardware bugs are encountered while running system software validation payloads on the FPGA prototyping platform, much effort is expended to reproduce the failures on a more debug-capable platform. It’s central to success in your quest to find those deeply hidden, hard-to-reach bugs. This trade-off between slower technologies like simulation and emulation, offering excellent visibility and ultra-fast FPGA prototyping, is where innovation helps achieve new levels of performance and debug productivity. This leaves behind a class of bugs that, without scaled-out FPGA prototyping, are likely to only be found in actual silicon. You’ve already wrung out most of the hardware bugs with simulation and emulation. Your testing payloads are not falling over due to endless and frequent RTL bugs. Additional challenges exist around the provision of sufficient visibility into the internal workings of the design for debugging purposes.Īs Joe and Bryan point out in “Deep Cycles,” you are likely running system software-based validation payloads on a scaled-out FPGA prototyping farm, and you are doing this because it is the closest approximation to actual silicon in terms of cycle throughput. So, the challenge is to make your debug turnaround cycle fast and easy to manage, as this is often the aspect of deploying FPGA prototyping in a hardware verification flow which makes it less attractive compared to, say, emulation. What happens when hardware bugs occur? You need to be able to observe bugs when they happen and to be able to debug them efficiently when using an FPGA-based prototyping system. Of course, it’s not just about achieving cycle targets or debugging software. This makes finding those unexpected interactions between the hardware and the software possible at fast enough performance and early enough in the design process to avoid bug disasters post-silicon. Deep FPGA prototyping allows you to scale out validation by depth and volume (deep cycles). In their article, “ Deep Cycles (Approximating Silicon with FPGA Prototyping), ” Joe Convey and Bryan Dickman talk about the challenge of getting enough performance to run real-life software pre-silicon, at speeds approximating those available in silicon. A long time-to-failure presents many challenges in repeatability and debuggability, requiring significant or even impractical amounts of time and effort. Detecting these hard-to-reach bugs often requires extremely long and time-consuming test payloads. They tend to manifest themselves in non-deterministic ways based on complex and unpredictable interactions between hardware and software. The problem is that bugs in highly complex chip designs are often buried deep in your system and they will not be found by simulation and emulation alone. Great! Unfortunately, your job as a verification lead is not complete. By Rob Parris, Engineering Director, Synopsys Verification Group Debug Matters!īy the time you have exhausted your bug questing by exploiting the full potential offered by simulation and emulation, the “easier-to-find-bugs” have been revealed and neutralized and your RTL is pretty stable.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |