The two contributions that received best-paper awards at the recent Design and Verification Conference & Exhibition Europe (DVCon Europe) underlined two of the issues that now face chip-implementation teams: efficient flows and reliability.
The conference organisers said attendance rose again, in the event’s tenth year: up to 115 in 2022 to 181 this past November. The conference included presentations and discussions on AI, high performance compute, and chiplets among a larger number of presented papers. The 2023 event saw the addition of a research track, in which the winning paper focused on the implications of aging on clock trees for design and verification.
Professor Freddy Gabbay of the Ruppin Academic Center in Israel, together with Technion researchers Firas Ramadan and Maja Ganaiem, looked at the effects of a longstanding issue in chip aging and reliability, bias-temperature instability (BTI). However, they focused on the effects on clock trees, using a general-purpose graphics processing unit (GPGPU) as their target, on the basis that asymmetric transistor aging could have a dramatic effect.
Image Proposed aging-aware timing analysis flow
Earlier work had looked at the effects when gated clocks are used. This extended the analysis to other timing aspects, such as the changing impact of useful skew and the disparity between net and cell delays. Whereas cells can suffer the effects of BTI-related aging, the nets that connect them will not. The accumulation of these changes over time can lead to timing setup and hold violations. The team proposed extensions to the design flow to take account of likely changes in timing relationships as the devices ages, adding additional timing margin to setup and hold paths that show marginal and negative slack estimates.
Open the flow
For their paper in the engineering category, Peter Birch of VyperCore, PQShield’s Ben Marshall looked beyond the typical role of EDA tools in delivering silicon and asked whether the design and verification community should borrow some ideas from the software world, particularly when it comes to open source. The current approach they argued has led to a fragile and difficult-to-maintain build environment for chips based on ad hoc assemblies of shell, makefile, Perl, and Python scripts.
“We recognise building hardware is as much a problem of data management as it is of microarchitectural design or verification, and our tools should recognise it too,” they wrote.
The authors argued that the flow needs three key elements: traceability; modularity; and reproducibility. Traceability means being able to tie the input of each step to a particular asset or input, each with its own unique version identifier. And it needs to be an identifier or tag that is more robust than a filename convention. Modularity calls for the steps to be composable in a way that is less ad hoc than the scripts often used today. But the scripts remain a necessity because design information such as coverage waivers need to be altered for each specific tool that ingests them. Reproducibility is needed to ensure that the output of the same steps and inputs produces the same output: something that might be needed months or years later when the source of a bug in a production device needs to be identified.
The two engineers have taken the approach of modeling the design flow as a graph between steps, each of which transforms part of the overall design in some way, often into tool outputs such as lists of errors and warnings, log files, entries in a functional coverage database, or the design itself, such as its final GD-II output.
The paper acknowledged the contribution that some open-source projects have made in this direction, such as FuseSoC and Edalize and introduced one called Blockwork the authors proposed as a potential design flow, using containerisation of the kind used for cloud applications to improve the consistency of communication between the different steps in the flow. Each tool is bound into a container with the specific helper software it needs.
In the paper, the authors also called on EDA vendors to relax the non-disclosure agreement (NDA) provisions in their contracts to make to easier to share information about command line flags and other aspects of tool use to improve communication across the industry.