Accelerating process migration in advanced ASIC design at Bull
How the HPC company used Synopsys’ Lynx Design System to standardise its flow and simplify migration to the next node.
Bull develops both open and secure high-performance computing systems. An ASIC team of more than 70 engineers, covering logical and physical design, and verification, creates the critical chips for these systems. Using processes down to 28nm, the team develops chips that may instantiate more than 200Mbyte of SRAM, include SERDES interfaces running at 25Gbit/s, and run at system clocks of up to 1GHz. Die size can be up to 20 x 30mm.
Tech Design Forum spoke with Cyrille Thomas, ASIC physical design team leader, Bull, about how the company has used Lynx in its design flow:
Challenges
A few years ago our whole design team was based on one site and worked on one project at a time, targeting a single process node. We now run three projects at once and the physical design team is spread across multiple sites, in France and the UK. We’re doing 40nm and 28nm projects at the same time, our schedules have become much more challenging, and we need to monitor increasing amounts of design data to keep our projects on track. The new challenges that advanced nodes bring are also making our schedules more difficult to predict, something that we need to control in order to serve our customers in the rest of the business.
Why use Lynx?
Why did we decide to implement Synopsys’ Lynx Design System at Bull? To improve productivity, flexibility and predictability, we wanted to develop a single design flow that would work across multiple sites, projects and technology nodes. We also wanted to make it easier for new team members to become productive. Lynx also helps us track progress and manage our schedules across all our projects.
Synopsys already provides reference design methodology scripts through SolvNet for users who have their own approaches to design management. Lynx, however, includes a full, production-ready RTL2GDSII flow, integrating all the necessary Synopsys tools. We used the 28nm version of this reference flow as our baseline, to which we added our own design-dependent customisations.
This means that when we upgrade to the latest version of Lynx we automatically update the flow and can use its new features and those of the latest version of the Synopsys Galaxy implementation toolset. For example, we were able to move from using Hercules for sign-off verification to IC Validator, the new tool for 28nm and below, very easily.
Our customisations have included adding third-party tools to the flow, and handling very technology-specific issues, such as top-critical-dimension cell insertion. We were also able to migrate a script, which optimises the choice of high, normal and low VT standard cells to meet timing goals in a 40nm process, to the 28nm design environment in weeks.
Lynx in practice
Our ASIC design files are managed by a revision control tool with several directories, organised to match the expectations of the Lynx tool, so that a master RTL2GDS2 directory holds sub-directories for global scripts and blocks. The global scripts directory includes all the plug-ins for specific nodes, and all the directories for each major place and route step, such as synthesis, placement, chip finishing and so on. The revision control tool also has directories for each project, with symlinks back to each of the directories used in the ‘golden’ flow. If we need to be more specific for a given project, we create project-specific scripts. Each project’s ‘blocks’ directory holds all the blocks it will use.
Figure 1 How Bull implements a generalised reference flow and project-specific flows (Source: Bull)
This makes it easier to substitute project-specific scripts into the golden flow, by breaking the symlink to the generic script. It also helps the flow-management team to track the flow for each project. In practice, perhaps only 10 files out of 200 for a 28nm project differ from the norm.
Customising our flow
What sort of customisations do we allow to our golden flow? Lynx includes all the steps in the place and route task, driven by a main script. We can use pre-scripts and post-scripts to vary the way these main scripts work. This makes it easier to track the way in which a design flow is varying from the template.
One example is in the pre-route task, where we added two post-scripts. One creates a bounded area around each input and output port into which the tool is meant to put the port’s related register, to improve the slack on the nets between them. The second post-script attempts to do the same for registers relating to memory blocks.
Metrics
One of the key reasons for using Lynx is that it can provide useful metrics both on the way a design is evolving, and on the way in which the design is being done, all held in an SQL database that we can access using a management dashboard and interpret using charting software.
For example, we can access design measures such as how much memory has been implemented, the amount of slack on particular nets and a standard-cell count. We can also access design-process metrics, such as the licence use per tool or the way in which the slack in a particular block is evolving as the design progresses.
Figure 2 One example of a trend analysis report (Source: Bull)
This trend analysis report is very useful for tracking our projects and making design decisions as we go.
An execution profile analysis shows how long each step in the place and route process takes, which can guide decisions about the practicality of merging two blocks.
Figure 3 This report helps keep track of the most time-consuming parts of the design process (Source: Bull)
Another dashboard report lists each of the key blocks in rows in a table, and shows the slack for that block, the number of DRC errors, and related information such as the use of low VT cells (which has to be carefully managed to meet foundry rules).
Figure 4 Lynx includes the ability to set up dashboard reports (Source: Bull)
The dashboard is also very practical in terms of data management. We have done 25,000 runs over 18 months and it has only generated 1.4Gbyte of reports.
Conclusions
Lynx can look complex at first: there are a lot of Synopsys variables and a lot of task-environment variables to master. But it is quite easy to learn and use, with the option of a command-line interface for those who prefer.
Its advantages include the fact that it enables us to track deviations from the global recommended flow and settings, and to understand design development trends and status, so we can identify project bottlenecks.
Our next steps with the tool will include using it in the data preparation phase, going from the GDS2 and LEF provided by the IP providers to the CEL and FRAM formats used by the physical designers. We want to include these steps in Lynx so that we can implement some quality assurance on IP blocks, as well as ensuring that we deliver good data for physical implementation.
Further information
Author
Cyrille is ASIC Physical Design Team Leader at Bull, and has acquired experience over the last 10 years in logical design, synthesis, design for test, static timing analysis and complete RTL2GDS implementation. He won the SNUG Europe (Synopsys Users Group) Best Technical Paper Award in 2008 for his document Design For Test insertion on a very complex VLSI using Synopsys Galaxy Flow. He also recently patented a way to optimize block interconnection within a chip using genetic algorithms.
