Despite this, there is a general consensus that success in hardware remains limited. The reality may be better than imagined, as certain trends in agility in hardware are not clearly marked.
For example, we are seeing increasing efforts to separate IP-level design and verification from SoC-level design and verification. In this case, different IP teams are running asynchronously from the SoC project “train model” and can select any version of IP when the SoC design is completed.
Although this approach is not labeled as agile, it does fit the agile philosophy.
The biggest drag on the development of agile design – arithmetic
The high cost of chip flow and the inability to change the design after the flow are often cited as key reasons why agile methods do not map well to hardware design. However, the inability to be agile after die flow does not necessarily mean that we cannot be more agile before die flow.
One of the biggest resistance to adopting agile design in hardware design is the complexity of hardware verification. Testing a software program requires only the calculations needed to execute that program, and of course the test will run at full speed.
Testing a hardware design requires a simulator program that simulates in software the behavior of the chip design as it is fabricated in hardware. The calculations for this simulator program are very expensive, but its execution is thousands of times slower than the real chip it is simulating.
Companies designing hardware are limited by their computing power when testing their designs. Several companies that support system design offer special emulation gas pedals that use dedicated processors or FPGAs designed for emulation acceleration. these systems simulate hundreds of times faster than simulations on general-purpose servers, and they are correspondingly more expensive. As a result, design teams find that they have similarly limited computing resources on these platforms.
Agile design requires continuous integration and testing, not only at the unit level, but also at the entire system level. If testing is limited by computational power, then agile design requires greater computational efficiency, especially at the system level. For example, a typical modern SoC requires up to five days of continuous computation on a server farm of thousands of machines to complete a basic set of complete chip tests.
How can design teams become more agile in chip design in such an extreme computing context?
Two approaches to solving agile computing challenges
There are two key approaches that can drive solutions to computational obstacles in agile hardware design: reducing design size through parametrization and through computational logistics (Thunderbird note, computational logistics involves the use of computation and advanced mathematics to plan and execute large and complex tasks. Computational logistics is applied in many areas, including the movement and storage of goods, services, and related information from origin to consumption.) Reducing test size.
First, parameterization. Replication is becoming increasingly common in SoC designs, whether at the IP level (e.g., multi-core CPUs) or at the architecture level (e.g., shader cores in GPUs or MAC nodes in AI gas pedals). By leveraging parameterization, the scope of replication can be significantly enhanced by blending more similar but different things together under some form of parameterization.
The more replication in a design, the greater the possibility of automatically generating reduced configurations of the design that are smaller but still meaningful for testing. The more complex the use of parameterization, the more flexible it is to minimize the size of the design used to test a specific function at the SoC level.
Mainstream hardware description languages (HDL) such as System Verilog already support replication and parameterization well, but they can be further enabled by adopting more advanced languages as HDL generators. Examples include SystemC, Matlab, Python, or Chisel. a similar trend towards adopting high-level languages for hardware design has emerged as well as the trend towards separating IP and SoC-level design.
As for computational logistics, if we continuously integrate and test under an agile design approach, then each integration and test is an increment to the previous one. For a given incremental design change, computational logic means automatically determining the best design configuration, test set, and test configuration to provide good verification quality at the lowest computational cost.
Think of this as a new class of EDA tools – one engine controlling all other engines in the complete verification flow.
We see great potential for improving the efficiency of verification computing through computational logistics, especially if one expects a heterogeneous, cloud-based future where unlimited usage capacity can be billed on a wide range of simulation and emulation platforms. Just as computational logistics has transformed package throughput for shipping companies like UPS and FedEx, it can transform verification throughput in hardware designs.
Hardware design has become more agile, but there is still plenty of room for improvement. A key barrier to such improvements compared to software verification is the huge computational cost of hardware verification.
By leveraging replication, parameterization, and high-level languages as HDL generators, we can minimize the size of the design in test. By employing computational logistics, we can minimize test effort and further optimize design size in test, especially in a cloud-enabled future, and based on the availability of using unconstrained verification computing.
The author of this article, Paul Cunningham, is senior vice president and general manager of the Systems and Verification Group at Cadence Design Systems.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/two-key-ways-to-make-chip-design-more-agile/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.