|
In recent years the impact of “bad RTL” has grown as designs have become more complex and code reuse has become commonplace in the mainstream design flow. There are many contributing factors, such as lack of adequate testing and frequent design changes within sufficient re-validation. Legacy code has also contributed to the development and propagation of bad RTL. As a result, designers face increasing challenges in the effort to effectively and consistently detect design and debug issues resulting from bad RTL coding, before handoff to the physical implementation team. While significant effort goes into verifying functionality and timing during front-end design, the tools and methodologies used tend to miss complex design flaws that can ultimately cause critical schedule delays and potential design re-spins. This purely simulation- and timing-centric approach to RTL code debugging is clearly inadequate. It causes many uncertainties in design schedules and greatly complicates program management in RTL development cycles. As a result, managers are required to make judgment calls on design development schedules without detailed knowledge of RTL quality. Actual product delivery dates inevitably stretch out beyond original projections. More aggressive geometries have only complicated matters. Smaller feature sizes present an exponentially increasing verification challenge even as design schedules are held constant (at best) or shrink. As a result, quality control exclusively through brute-force simulation is becoming impractical. Rather, new techniques are required to complement traditional QC methods. This is particularly true for designs containing ‘pre-verified’ IP. To extensively re-simulate the IP in the design would negate much of the value of using the IP in the first place. However, experience shows that no IP is so well validated that it can be re-used in any context without some level of re-validation, at least at the interface level. Additionally, verification is very costly in engineers’ time, often requiring inordinate engineering hours to set up before providing necessary feedback to the designer. It is not surprising that frustrated RTL developers often miss or do not anticipate key quality issues. Commonly, back-end and front-end engineers are at odds with each other regarding such quality flaws. Such deficiencies are either discovered late in the design cycle, resulting in product shipment delays or, worse yet, slip through to production, necessitating a re-spin, or in some cases a recall. Click here for your copy of the white paper
|
|
|||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
