The survey conducted by Rocketblog and the FPGA Journal produced some eye opening results, particularly among the segment of the survey population doing complex FPGA design. On average, the number of iterations required to bring up a working FPGA is more than 100, a situation unheard of in previous eras of FPGA use, and one that is threatening the biggest FPGAs to being with – faster time to market and/or rapid prototyping.
The survey revealed that the number one issue causing lengthy debug times is tracking down errors in RTL code. This can be a result of designer error, or, increasingly, because of issues related to other design tools such as synthesis and place and route, or IP cores. Regardless of the source, these types of errors are tougher and tougher to find using traditional FPGA debug and verification techniques.
In fact, the survey results show that debugging a complex FPGA can now represent to 92 days of the overall development cycle!
For more detail, see
The survey conducted by Rocketblog and the FPGA Journal produced some eye opening results, particularly among the segment of the survey population doing complex FPGA design. On average, the number of iterations required to bring up a working FPGA is more than 100, a situation unheard of in previous eras of FPGA use, and one that is threatening the biggest FPGAs to being with – faster time to market and/or rapid prototyping.
The survey revealed that the number one issue causing lengthy debug times is tracking down errors in RTL code. This can be a result of designer error, or, increasingly, because of issues related to other design tools such as synthesis and place and route, or IP cores. Regardless of the source, these types of errors are tougher and tougher to find using traditional FPGA debug and verification techniques.
In fact, the survey results show that debugging a complex FPGA can now represent to 92 days of the overall development cycle!
For more detail, see
No comments:
Post a Comment