Browse > Home / 信息中心 / SNUG / 2011论文集 / Lynx在龙芯2H项目管理中的使用

Lynx在龙芯2H项目管理中的使用


肖 斌xiaobin01@ict.ac.cn

中国科学院计算技术研究所微处理器中心

摘要

随着集成电路工艺进步和设计复杂度的增加,层次化设计方法成为性能优化的主要选择,同时带来了设计数据交互和项目管理上 的难度,特别是在一个拥有不同层次设计经验的物理设计团队。本文将介绍在龙芯2H中使用新思科技的Lynx设计系统作为物理设 计项目管理软件的相关工作,龙芯2H是一款基于ST065工艺的复杂SOC设计,它的物理设计流程主要包括一套标准化子模块设计 流程,两级的层次化Signoff时序分析流程和第三方工具在Lynx中的集成方法。

Abstract

As design complexity and gate counts increase, the hierarchical design method has become a good choice for performance optimization, but it brings difficulties in design data exchange and project management, especially for a large ASIC team with more or less experience. This paper will summarize the work we have done in the project management of Godson2H, which use Synopsys Lynx Design System. Godson2H is a complicated SOC design fabricated in ST065 technology,the whole physical design flow includes three main parts: a basic design flow for sub-modules, a two-level hierarchical signoff timing analysis flow, and a flow for the third-party tools integration in Lynx Design System.

1. Introductiont

As design complexity and gate counts increase, hierarchical design method has become a good choice for performance optimization, but it brings difficulties in design data exchange and project management, especially in a large ASIC design team.
Before the advent of Lynx, in hierarchical design each module designer has its own tool scripts for synthesis, place and route. The project manager must check out each designer’s library versions , tool settings , logs and design flows carefully, even after this work some errors cannot be easily found. When designs become more and more complex, it is harder to do this work. Lynx Design System gives an easy platform for data management and flow control for a big project.
This paper describes the Synopsys Lynx Design flow used in Godson2H, which is a complicated SOC design fabricated in ST065 technology. To complete hierarchical design method, we need a basic submodule Lynx flow and a hierarchical STA flow for the whole chip’s timing check.
● Chapter 2 describes the architecture of Godson2H.
● Chapter 3 gives an introduction to the Synopsys Lynx Design System.
● Chapter 4 describes the hierarchical Lynx Design flow used in Godson2H.
● Chapter 5 gives some results of Lynx Design System.

2. Architecture of Godson2H

Godson2H is a single chip computer system, which not only integrate godson cpu ip, scache ip, but also integrate a graphic process unit, ddr controller, hyper transport controller, pcie controller, media unit, and south bridge function unit. Its architecture is shown in Figure 1.

Figure 1 Architecture of Godson2H

The south bridge module includes usual low speed interface, such as usb, sata, gmac, lpc, spi and and so on. This single chip is enough to construct a computer system without peripheral chips. It’s chip size is 11.6*10.0mm2, including about 6.4 million instances with more than 40 clock domains. It would be taped out with ST micro’s 65nm technology
with mixed GP and LP process. The Node including cpu and scache would run at 1.05GHz, the L2 XBAR would run at 400MHz. To complete so complex a SOC design, we construct a team with about ten engineers, most of these engineers are less experienced engineers, so how to manage the design data and control design flows in such a big project becomes a problem.

3. Synopsys Lynx Design System

Because of the complexity of the whole chip, half of the design’s submodules were implemented using the Synopsys Lynx Design System. Synopsys Lynx Design System is a complete RTL-GDS implementation flow which combines GUI-based runtime automation, metrics capture and reporting, and automates the library setup of the foundry data. Lynx takes advantage of the Synopsys Galaxy Implementation Platform and allows integration of third party tools as well.
It is easy to control library consistency and common settings between different design blocks in hierarchical flow in Lynx design system, and to avoid common mistakes made by less experienced engineers.

Figure 2 Lynx Design System

The Synopsys Lynx Design System incorporates a basic implementation flow as shown in Figure 3. The entire flow starts from some basic inputs such as RTL, constraints files,and then the Lynx Runtime Manager would automatically handles all the relevant tasks for the flow.
Lynx’s Flow Architecture Step & Task View

Figure 3 Lynx Design Flows

4. Hierarchical Design Implementation in Lynx System

In Godson2H, we use hierarchical design flow, which means that we divide the whole chip into some submodules, and each engineer is in charge of a basic module design flow from synthesis to place & route, only when the submodule has satisfied its timing constraint, it can be submitted to the top designer, then the top designer combines sumodules to a whole chip and complete the whole chip’s timing check.
To complete the whole chip’s implementation work, we should build a basic design flow as a standard flow for submodules in the chip with Lynx flow tools and a hierarchical STA flow for the whole chip’s timing check. For ST065 technology the submodule flow and hierarchical STA flow have been done for other projects, so what we have to do is to migrate those to Lynx Design System.

4.1 FRS Preparation

Foundry Ready System is an important part of Lynx Design System, but unfortunately when this project started, ST065 FRS was not ready. Lynx provides an easy GUI-based way to prepare FRS, or you can use text way to edit the library config files, including library name, library data base path, clock tree cells, don’t use cells, technology files, design scenarios and so on.
In our previous projects, the project leader creates the project setup and configuration files and other engineers copy those files to their own directory and make some modification. In this project, we have some less experienced engineers engaged in the implementation of sub modules. From previous experience, they start their flow from former scripts of other engineers which would have some implicit problems. For example former scripts may use an old version of tluplus files. The newer cannot notice these details usually, which leads to the difference between his timing result and top’s timing results. And usually it’ll spend much time to debug if error happens.
Lynx provide an uniform project setup and configuration interface in Runtime Manager GUI. The project leader makes the common setup for the whole project and other designers inherit the default common setup and make their block specific modifications if necessary. All these setup are done in clear GUI interface and the non-default values will be highlighted. It can make sure that each designer use the same library version and library relative settings. Even some designer modifies some library options, you can easily find differences from the lynx GUI.

Figure 4 Lynx Config Interface

4.2 Submodule Flow

A basic submodule flow includes three steps: the first is the module’s synthesis step, the second is the module’s place & route step, the third is the module’s signoff flow. For ST065 process, we have mature flows, but it is not exactly the same with the basic flows provided by lynx design system. For syn, dp and pnr steps, submodule flow is more simplified, in these steps, we would delete those tasks which we don’t need in original lynx design flow. The steps charts of syn, dp, and pnr steps are shown separately in Figure 4, 5, and 6.

Figure 5 SYN Step Figure 6 DP Step

Figure 7 PNR Step

The basic flow is similar as default design flow in lynx. In lynx design system, for most task scripts, it would execute a pre and post script in the main script of this task, so you can easily write you own design specific operations, and keep the original scripts not modified for easily tool version updating.
Another important function of lynx design system is design exploration flow, which mean that you can run the same task with different task properties. Different task properties refer to different tool command option, different input data like constraints or rtl files. It is usefull when you cannot decide which kind of macro placement is better, you can run some experiments parallel in the dp step and choose a best result, which can save a lot of time for you. It is shown in Figure 7. The results can be compared using a html report which show QoR related details such as WNS, TNS, Wirelength, congestion etc. As shown in Figure 7, the exploration flow consists of multiple invocations of the icc_dp_explore task with different arguments and settings. To create the flow, we create several icc_dp_explore task replications and connect them as shown. Then these replication tasks can run parallel as we expected. For each replication, we set different arguments in task property GUI to get different results. The whole process is fast and convenient.

Figure 8 Floorplan Exploration Flow

Compared with the default design flow in Lynx, the most different step is the finish step. In this step, several operations are performed in our flow, including RC extraction, static timing analysis, formal check, design rule check and layout versus schematic check. The task chart is shown in Figure 8.

Figure 9 FINISH Step

For ST065 design’s static timing analysis, ST Micro provides a complete suite of shell scripts, what we need to do is to integrate these into lynx design system. To reserve ST065 signoff flow’s integrity, we use tcl as the basic tool and use “exec” command to execute STA tasks. To observe design data in lynx design system, we come out a solution to print log files after you execute STA tasks. So the run time manager can check the STA logs almost the same as the default flow scripts. In drc and lvs tasks, we use a third-party tool as check tool. But the challenge is that the environment configuration for the third-party tool is very complex and it is quite different from synopsys drc/lvs tools. At the beginning we would suspect if Lynx can handle such problem but fortunately we find Lynx has flexible and open mechanism to integrate almost all 3rd part tools. In our case, we use tcl to complete the environment configuration and invoke the 3rd party tool, use the pre_script and post_script to help us put setting commands in appropriate location. We do this integration in one project and can migrate to others projects. From the end user perspective, the 3rd party flow is as simple and seamless to as synopsys drc/lvs flow.

4.3 Hierarchical STA Flow

To accelerate the whole chip’s timing analysis flow, we use hierarchical STA flow to get feedback as fast. The basic method of hierarchical STA flow is to extract module RC parasitic, generate SPEF files and read these files in the whole chip timing analysis flow.
Before lynx design system was introduced to the project,for hierarchical STA flow we use different console to do the extraction of one module, we must submit a task for each submodule which includes five sub extraction jobs, and when the extraction for each submodule has been done then a top STA flow which includes at least 7 corner’s STA jobs starts. The lynx design system provide a GUI runtime manager, it will auto generate the topology of each jobs and you can have visual feelings about how you work is running. When some submodule is not updated and extraction does not need to do again, you can just remove the dependency between the submodule and top STA step.
The hierarchical STA flow implemented in lynx design system uses the hierarchical character of STEP and TASK in lynx design system. The top flow chart is shown in Figure 8.

Figure 10 Tow Level Hierarchical STA Flow

For each Step in the top STA flow, it has a similar step flow chart as the submodule’s finish step. The submodule extraction is done parallel. After all the RC parasitic files of each module have been generated, the static timing analysis task in top starts, which mainly complete the whole chip’s timing closure. If it shows some boundary timing problem, submodules need to fix this problem, then a new timing analysis cycle starts.

4.4 Project Aacceleration

In Godson2H, the submodule flow is used in 4 modules of total 8 modules. The reason is Lynx design system was introduced after the project had started for a while. Compared to the 4 submodule without Lynx, the modules using Lynx benefit much from the data management mechanism in Lynx.

Figure 11 Release and Restore Mechanism

The release/restore mechanism is flexible and robust way for data handoff. Module designer release their design data to top designer in a central RELEASE repository. Top designer restore all these data back to implement top design. In the progress User only need to specify a design and provide a specific name. All other actions are done automatically without human interference. This is the most impressive part in acceleration but not the only one. In Table 1, we list a comparison of user work before and after Lynx is used. We can find that Lynx design system help engineers to focus more on designs themselves and cost less time on flows and other repetitive work.

Table 1 Work before and after lynx is used

5. Conclusions

With the development of VLSI technology, more and more function units can be integrated in a single chip, which result in an increase of design complexity. Hierarchical design method is chosen but brings problems in data management and flow control. Lynx Design System provides a complete RTL-GDS implementation flow, also it is a good data and flow management solution to physical design team, which utilize Synopsys Galaxy Implementation Platform and reserve interface for the third-party tools. It is easy to custom your own design flow in lynx GUI-based design system.
For data and flow management, lynx can help you to avoid some common mistakes like library version, tools common settings and so on, that can save your time for some design checks especially for those engineers with less experience and it gives a more kind work ways which makes all work done in GUI.
In next project which may use 28nm technology, we will use lynx design system for the whole chip design and can get more benefit on runtime.

6. Acknowledgements

I would like to thank my colleagues for their continued support during the course of this paper. I would also like to thank my SYNOPSYS reviewers for their valuable feedback.

7. References

[1] Synopsys tool documentation on Solvenet.