2018年高级逻辑综合：大数据与人工智能驱动的创新

2018

需积分: 9 86 浏览量更新于2024-07-18 收藏 6.76MB PDF 举报

《高级逻辑综合2018》是一本由André Inácio Reis和Rolf Drechsler合编的专业书籍，关注于逻辑综合领域的最新发展。逻辑合成作为一项关键的计算机科学技术，随着大数据时代和人工智能的崛起，正朝着更深层次的研究方向迈进。书中特别强调了利用数据中心的强大计算能力，这使得处理大规模数据和应用认知功能成为可能。在2018年的这一版本中，作者探讨了如何将人工智能的最新进展，如深度学习和图形数据结构的并行处理技术，融入逻辑综合的设计流程中。这不仅包括了算法的优化，还涵盖了硬件与软件的协同工作，以及在云计算环境下的系统设计，如cyber-physical systems（CPS）的构建。书中详细介绍了逻辑综合的高级方法论和技术，如基于门级设计、高阶综合、静态时序分析以及针对复杂电路的优化策略。编辑们可能还讨论了如何通过集成自动化工具和人工智能技术来简化设计过程，提升效率，减少设计时间和成本。此外，本书可能会包含关于硬件描述语言（HDL）的最新进展，以及如何将它们与机器学习算法相结合，以实现自适应和自优化的设计。对于那些对逻辑设计感兴趣的工程师、研究人员和研究生来说，这本著作提供了一个深入了解当前前沿技术和未来趋势的平台。值得注意的是，版权方面，《高级逻辑综合2018》受到Springer International Publishing AG的保护，所有权利均保留，未经许可，不得进行任何形式的复制、转印、广播或电子传播，除非符合版权法的例外规定。对于想要在逻辑综合领域深化研究或教学的人来说，查阅此书需确保遵守版权条款。读者可以通过ISBN 978-3-319-67294-6（纸质版）或978-3-319-67295-3（电子版）获取，或者访问DOI: <https://doi.org/10.1007/978-3-319-67295-3> 获取在线资源。《高级逻辑综合2018》是一本不容错过的资料，它反映了逻辑综合领域在2018年的重要突破，以及人工智能和云计算如何推动这一领域向更高效、智能的方向发展。

1 EDA3.0: Implications to Logic Synthesis 7

22nm Micro

Scratch

User

Analysis

Phys Design

Verification

Logic

Fig. 1.2 Design data for a 10 C B transistor 22 nm chip

It is not uncommon for design teams to write 1–2 millions of lines of Skill

or Python scripts to create library cells and IP blocks. A complete design and

veriﬁcation ﬂow can quickly add up to 1–2 million lines of TCL to control the

tools and deal with the setup and environment in which IP and models are stored.

And once the design ﬂow is up and running, a large number of Python and Perl

scripts are written to extract the key information from the terabytes of reports and

design data. It is often difﬁcult to know how many of these scripts exist in a design

environment since they are often owned by individual designers. In addition to all

the conﬁguration and control ﬁles a large amount of data gets generated and stored.

Let us look at the amount of data produced by a design team designing a 10BC

transistor processor in 22 nm technology as shown in Fig. 1.2. It takes about 12 Tb to

store the entire golden data (including incremental revisions). Logic and veriﬁcation

setup takes about 2 Tb, the physical design data about 8–9 Tb and another 1–2 Tb

for analysis reports. In addition, individual users keep another 6 Tb of local copies in

user and scratch spaces. For functional veriﬁcation, approximate 1.5 Tb of coverage

data is collected daily. This data is very transient and about 2 weeks worth of data

(21 Tb) is kept in a typical veriﬁcation process.

After the design is ﬁnished, the physical data get compressed and streamed out

to about 3Gb of OASIS. The product engineering team blows this up to around 1 Tb

during mask preparation operations. Finally, another 5 Tb of test and diagnostics

data gets generated in the post-silicon process.

This looks like a signiﬁcant amount of data but it tops out at 50 Tb for a multi-

year design and manufacturing project. Recently a study [17] was published that

produced the table in Fig. 1.3. It seems to project the 22 nm chip storage needs

1 EDA3.0: Implications to Logic Synthesis 9

How does this compare to the design data? Comparing the 50 Tb/design versus

the 20 Pb of the fully annotated Google maps, the design data is only 1/400th the

size. A large chip has 5 km of wire compared to the 5 million miles of road to

accumulate street view images. Of course, the scale of intersections on the chips are

in nm’s and the road crossings are in kilometers. It would be interesting to compare

the number of road intersections in the world with the number of vias on a chip.

Typically, the street view data annotated with each street is signiﬁcantly larger than

the physical design data needed to be associated with each stretch of wire.

One major difference is that the core EDA design data is certainly more dynamic

than the more static base map of roads in an application like Google maps. EDA

tools can much more quickly reroute wires than physical roads can be built. But let

us look at another data point to illustrate the velocity of data in a cloud application

like YouTube. Each minute 300 h of video is uploaded to YouTube [19]. This is

indexed, categorized, and made available. While we have no accurate data on how

much of the design data changes each day, since it tops out at 50 Tb after a multi-

year project, it is safe to assume that only a small fraction of it changes daily.

Based on these examples we conclude that many of the cluster-level program-

ming models will be able to handle the typical data sizes in EDA projects. Let

us look at the traversal speed of some of these models as well. Graph databases

have become one of the fastest growing segments in the database industry. Graph

databases not only perform well in a distributed environment but can also take

advantage of accelerators such as GPUs. Blazegraph set up an experiment to run a

Parallel Breadth First search on a cluster of GPUs. Using such a cluster, Blazegraph

demonstrated a throughput of 32 Billion Traversed Edges Per Second (32 GTEPS),

traversing a scale-free graph of 4.3 billion directed edges in 0.15 s [20]. This is a

few orders of magnitudes more than a static timing analysis tool which traverses

about 10 M edges per second on a single machine. An example of a matrix

programming model is shown in Quadratic Programming Solver for Non-negative

Matrix Factorization with Spark [21].

Despite the applicability of many of these programming models to EDA rela-

tively little attention has been paid to them. This is caused by the fact that most

of the public discussion has been overshadowed by other “cloud” aspects and

speciﬁcally the element of data security [22, 23]. Indeed, only when sufﬁcient

security guarantees are given will designers put their entire IP portfolio on a public

cloud. However, EDA applications can run in private (or hybrid) clouds and take full

advantage of the massively distributed warehouse-scale computing infrastructure

without the security issues.

Unfortunately, this heavy focus on the security aspect has overshadowed the

discussion around the opportunities of warehouse-scale computing to the EDA

design ﬂows and applications. This is also the reason I am using the term

“warehouse scale computing” instead of cloud to not distract from its underlying

potential. In the next section, we will describe how EDA tools can take advantage

of the warehouse-scale software infrastructure. We will describe how we can make

a design ﬂow a lot more productive and designer-friendly.

10 L. Stok

4 EDA Applications

What does a designer (the EDA tool client) really want? She wants to get to the

design DATA from anywhere and any place. She wants the DATA to be there without

her waiting for it. She wants to analyze the DATA with whatever tools she can lay

her hands on to learn how to improve her design. She wants to know how to get

from A to B through the design process and wants design data, design navigation,

and a design ﬂow to act like Google maps. For example, wouldn’t it be great if

understanding timing and congestion problems in your design is no more difﬁcult

than turning on trafﬁc congestion information in Google maps? Wouldn’t it be great

if we could annotate key manufacturing data from inline inspection tools just as easy

as Street Views to our design data? This has certainly become easier to accomplish

using key elements from cluster level programming models.

This type of rapid analysis and optimization can only be accomplished if the

entire design data is in a (set of) live database(s) distributed among many machines

in the warehouse-scale compute center. When design changes are made, the live

data needs to be incrementally communicated and updated. We know how to do

this for timing analysis integrated within a place and route ﬂow. However, this

incrementality needs to be extended to all analysis. Analysis engines can run on

many parts of the design simultaneously and can be folded together in the live

model. The analysis tools will produce the appropriate abstractions that are needed

by the higher levels of hierarchy in the design.

Instead of thinking about synthesis, place, route, and timing algorithms, this

DATA-centric EDA3.0 paradigm will start from the data, map it to the compute

infrastructure using the right cluster-level infrastructure, and put the applications

(e.g., placement, routing, timing analysis) on top of that using well-deﬁned cluster-

level APIs as services.

Clearly there are some technical challenges here. EDA data is more connected

than many of the social networking applications. However, in many applications

we have seen that EDA data viewed the right way is inherently more parallel than

initially thought. The fact that tens or hundreds designers can work simultaneously

and productively on a design makes it clear that the parallelism exists in the design

process, albeit sometimes not in a single optimization run.

While EDA data is certainly more volatile during the optimization part of the

process, the increased re-use of IP and increased use of hierarchy with appropriate

abstractions has resulted in a much larger portion of the design data to be stable in

the iterations of modern hierarchical designs. Furthermore, only a small portion of

the chip and logic design gets (re-)done each day. With advanced version control

fully integrated in the data itself, the knowledge of what actually changed can lead

to a whole new class of optimization algorithms.

Large service providers such as Google and Facebook provide their own platform

and cluster-level infrastructure based on special versions of open source code. Many

smaller companies will build on standardized platforms such as CloudFoundry [24]

and Bluemix [25]. The EDA industry needs to ask itself the question: what can we

1 EDA3.0: Implications to Logic Synthesis 11

do to customize several of the cluster-level programming models to allow EDA tools

to be written like services that interface with live design data through well-deﬁned

APIs?

5 EDA Applications: Analysis

As described in Sect. 2 we can leverage many of the existing cluster-level infras-

tructure programming models for EDA applications. This is particularly true for

the EDA applications that perform analysis and reporting. DRC, LVS, and timing

analysis applications are well geared to the distributed infrastructure.

As an example, we deployed Neo4j [26] for timing analysis. Using Neo4j we now

have an unprecedented capability to store detailed timing information in a highly

efﬁcient format, enabling very powerful query analysis. Our current benchmarking

efforts have established the feasibility of storing a complete top-level chip timing

graph from EinsTimer consisting of nearly 100 million nodes and associated timing

properties in Neo4j. Using an IBM Power8 Linux server, we are able to import data

within 11 minutes. The resulting graph database is indexed on several key query

parameters, such instance names and slack values, within a matter of a few minutes.

Once indexed, we have demonstrated the ability to perform lookups, for example

iterating through all timing end points in the top-level chip run, and returning the

worst N sorted by slack within 2 seconds. Given the underlying graph schema

consisting of both properties and labels, we have the ability to support multiple

levels of hierarchy within a single graph instance, which then enables efﬁcient

cross-hierarchy analysis within a single instance of Neo4J. For example, we have

demonstrated the ability to compare in vs. out of context timing for approximately

1000 primary inputs on given macro within its top-level environment within 5

seconds. Previously, such cross-hierarchy analysis would require complex code to

parse timing reports and resolve the names throughout the hierarchy. Such powerful

analytics can often be achieved in a single line of Neo4J Cypher, illustrating the

power of graph databases in analyzing complex EDA data sets.

The other advantage of using a graph database as a timing data server is that it

can provide the data as an always on web service. We are fully leveraging Neo4j as

a web-server which subsequently allows for a rich variety of applications to be built

on top of the underlying graph database service, allowing us to package numerous

queries as REST end points - as well as visualize results using custom built web-

applications which allow for a clean visual representation of key timing metrics.

From the standpoint of a chip designer, the above framework provides “any time

anywhere” access to critical EDA timing results for use in triage, as well as trend

analysis over time.

We use a similar framework for noise analysis. In Fig. 1.4 we show an example

of a Noise inspection tool that we developed on top of an analytics framework. The

cause of noise problems is often not very easy to determine. Noise can be caused by

a combination of weak drivers, low tolerance for noise on sink gates, large aggressor

剩余235页未读，继续阅读

Pamela_ouyang

粉丝: 13
资源: 40

2018年高级逻辑综合：大数据与人工智能驱动的创新

Advanced Logic Synthesis 无水印pdf

Advanced-Logic-Synthesis_logic_vhdl_usualqhx_

Advanced Synthesis Cookbook

tangoblues-ADVANCED ASIC CHIP SYNTHESIS

Advanced.ASIC.Chip.Synthesis.2nd.Edition.part2

PLD Based Design with VHDL: RTL Design, Synthesis and Implementation

Xilinx_Advanced_Code.7z

Truth Tables and Logic Synthesis: The Bridge from Truth Tables to Real Circuits (An Authoritative ...

【Advanced Tips】: Avoiding Mode Collapse: Advanced Solutions in GAN Training

【Advanced】GAN Adversarial Network Simulation for Generating Gaussian Distribution in Matlab

最新资源