Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Avoid Bad Architecture Decisions
In their latest article from “The Quest for Bugs” series, entitled “Correct by Design,” Joe Convey and Bryan Dickman explore how using virtual prototyping to design and simulate product architectures can eliminate costly architectural design bugs before committing to register-transfer level (RTL). In other words, get the design architecture right first, then write the RTL! Joe and Bryan characterize bad architecture decisions as “architecture design bugs.” They examine this problem through the lens of ASIC design and verification and ask how such bugs can be found and eliminated in the architecture design phase. Not finding these bugs can have costly impacts downstream for power, performance, and security of the end product. Further, they point out that design viability can be compromised by poor architectural design decisions, leading to designs that struggle to meet timing or are difficult to place and route due to wire congestion, for example.
As Joe and Bryan mention, historically, architectural analysis was carried out using spreadsheets, an entirely static approach. This method is very limited, with a high degree of guess work as you speculate on what the dynamic activity will look like for the target system. It’s very easy to make a miscalculation when doing this. The trouble is, you may not realize your mistake until you reach the system validation stage, when you finally have functional RTL and functional software running together. This pre-silicon system validation stage is essential for wringing out hardware and software bugs, including performance and power issues. It is supported by performance-leading hardware acceleration platforms featuring best-in-class debug capabilities, such as ZeBu® Server 4, ZeBu EP1, ZeBu Empower, or the HAPS®-100 prototyping system from Synopsys.
So, bad product architecture decisions can lead to late RTL rework costs. Worse still, you might have successfully built the wrong product: functionally correct, but missing the mark in performance and power, for example. Adopting a more simulation-oriented architectural exploration approach enables a far more extensive and measurable analysis of design choices, achieved through the execution of realistic traffic profiles and critical software sequences. You wouldn’t dream of skipping the RTL or software validation stages, so why leave the critical architecture design stage to guess work?
As Joe and Bryan discuss in “Correct by Design,” we need to simulate architecture design because dynamic effects will arise from workloads that change over time, or from multiple applications sharing the same resources. Modern many-core systems with dynamic scheduling will lead to multiple initiators, giving rise to arbitration on shared interconnects and dynamic memory access latency due to caches and DDR memories. Dynamic effects make it difficult to predict performance with static analysis.
In the same way, dynamic residency of workloads on resources leads to dynamic power consumption, making it difficult to estimate average and realistic peak power. Dynamic power management (DVFS) creates a closed control loop where the application workload drives resource utilization, which is influenced by power management. This makes prediction of power and performance even more difficult, as the elements of the loop become interdependent.
The Architects’ Platform
When talking about virtual prototyping systems, we usually think of the software development shift-left use case. Fast, functionally accurate virtual prototype models remove the dependency on fully functional RTL models for software development. However, there is another important shift-left: product architecture analysis and optimization. Virtual prototype models can be used to deliver a simulation platform suitable for system architecture design, exploration, analysis, optimization, and validation. Synopsys Platform Architect™ provides architects and system designers with SystemC TLM-based tools and efficient methods for early analysis and optimization of multicore SoC architectures for performance and power. Stimulus can be generated from task- and trace-driven traffic generators initially and from critical software running on fast processor models later. Analysis is the key word here. Platform Architect delivers debug visualization capabilities that allow you to root-cause performance and power bugs by correlating power profiles, bus throughput, DDR utilization, task traces, address traces, software traces, and more, enabling you to answer complex architecture design questions.
Get AI-Enabled Chip Designs Right
As Joe and Bryan mention, the emergence of AI-enabled ASIC designs presents some unique challenges in hardware, software, and algorithm exploration. AI acceleration is fast becoming one of the most important technology trends for many applications, but especially in advanced automotive where AI is central to so many systems, from driver assistance through to level 4/5 autonomous driving. These design challenges can be met using Platform Architect coupled with the broadest portfolio of transaction-level models (TLMs), especially a large library of Synopsys and third-party architecture design models. This also includes support for SystemC TLM-2.0 models of Synopsys DesignWare® Interface IP and DesignWare ARC® EV Processors, which are fully programmable and configurable IP cores that are optimized for embedded vision applications, combining the flexibility of software solutions with the low cost and low power consumption of hardware. For fast, accurate execution of convolutional neural networks (CNNs) or recurrent neural networks (RNNs), the EV Processors integrate an optional high-performance deep neural network (DNN) accelerator.
For systems that incorporate AI capabilities, you must figure out the optimal solution in terms of the AI algorithm and the SoC architecture. Highly parallel compute drives memory bandwidths, so it’s important to select the optimal memory system architecture for the application. Systematic parameter sweeping allows you to figure out the sweet spot in, for example, DNN inference latency, system energy, and system power consumption.
Summary
In the past, a spreadsheet approach to architecture design was practical and reasonable. This is no longer sufficient, because of ASIC design complexity and the need to achieve optimal solutions that meet the performance and power requirements of modern technology applications. Accurately predicting the behaviors and power and performance characteristics of your chosen design is impossible without an architecture design modelling approach. You need to stimulate your model with realistic traffic and by running critical software in order to visualize and correlate key performance attributes, then iterate quickly towards the correct design solution. Guesswork no longer cuts it!