The current SoC prototyping flow produces system faults that arise with the integration of hardware and software. Mapping a SoC design onto a multi-FPGA prototype board that requires some arbitrary design partitions such that it can fit into the FPGAs can create problems. Eliminating problems that are not associated with the original SoC RTL design and ensuring that the design under test (DUT) in the FPGA prototype is functionally the same as the original RTL should be the first challenge of a prototyping project, collectively called "bring-up."
The next challenge in the FPGA prototype methodology is addressing system issues that require software engineers to assist identifying whether it is a software issue or RTL design issue. Software engineers can control the flow by reading registers and memory map information of the design to analyze the hardware behavior but have little understanding as to why a problem is caused. A typical hardware/software integration process may take a few months to debug such that it has stable hardware for application software development and a demo of the system. Today, software (ICE) and hardware (ELA) debugging tools are generally disjointed. The panacea in this process is controlling and synchronizing them such that a true HW/SW debug solution can be realized.
The last and most difficult challenge in this debug process is the limited visibility resulting in frequent FPGA P&R iterations when using FPGA-based prototypes. The limited visibility in FPGA-based prototyping is a well known problem, but it compounds itself when using multiple FPGA prototype systems. Having limited system visibility (which today is one FPGA at a time) really causes a lot pain when debugging issues that transcend over multiple FPGA prototypes. Using tools with limited visibility assures more trial and error iterations, with long FPGA P&R compile times. The diagram below illustrates today’s typical debug flow:
The next challenge in the FPGA prototype methodology is addressing system issues that require software engineers to assist identifying whether it is a software issue or RTL design issue. Software engineers can control the flow by reading registers and memory map information of the design to analyze the hardware behavior but have little understanding as to why a problem is caused. A typical hardware/software integration process may take a few months to debug such that it has stable hardware for application software development and a demo of the system. Today, software (ICE) and hardware (ELA) debugging tools are generally disjointed. The panacea in this process is controlling and synchronizing them such that a true HW/SW debug solution can be realized.
The last and most difficult challenge in this debug process is the limited visibility resulting in frequent FPGA P&R iterations when using FPGA-based prototypes. The limited visibility in FPGA-based prototyping is a well known problem, but it compounds itself when using multiple FPGA prototype systems. Having limited system visibility (which today is one FPGA at a time) really causes a lot pain when debugging issues that transcend over multiple FPGA prototypes. Using tools with limited visibility assures more trial and error iterations, with long FPGA P&R compile times. The diagram below illustrates today’s typical debug flow: