Accelerating ‘time to prototype’ with ProtoCompiler
A look at a tool and a flow that makes it easier to put designs on to a HAPS physical prototyping system for verification, debug and software development purposes
Physical prototyping is becoming increasingly important to the consumer, wireless communications, industrial, and computation/storage markets, as well as to sectors such as wired communications, automotive, medical and mil-aero.
Why is this? As the amount of software on SoCs rises, and their interaction with their environment grows, it becomes increasingly important to be able run a design in its target context, in as close to real time as possible.
This means that prototyping systems need to offer good performance, to run enough software to give worthwhile verification results, as well as to test real-time response. Prototyping systems also need the capacity to handle large designs, and the ability to drive established interfaces such as USB 2.0 and Ethernet, and external memories, such as Flash, and SRAM.
Challenges of physical prototyping
There are a number of challenges involved in moving a design that is targeted for an ASIC/SoC implementation to an FPGA-based prototyping system. These include:
- migrating the ASIC RTL and constraints on to one or several FPGAs
- representing complex ASIC clocking strategies within the limitations of the FPGA hardware
- supporting large ASIC memory blocks on FPGAs with limited capacity
- achieving the right level of debug visibility for the mapped design
- achieving a useful level of performance for the mapped design
- minimising the time it takes to migrate to the prototyping system and to debug it once there
Synopsys’ ProtoCompiler software provides a design environment for the company’s HAPS FPGA-based prototyping system, which, in its largest configuration, can handle nearly 300 million ASIC gates. ProtoCompiler enables designers to plan how their ASIC designs will be partitioned across multiple FPGAs, taking into account their capacity and the constraints imposed by having to route key signals among multiple devices. ProtoCompiler also handles system debug and bring-up, as well as enabling transaction-based validation.
The combination of ProtoCompiler software and HAPS hardware enables designers to start prototyping their work more quickly, and to achieve prototype clock speeds of up to tens of megahertz, which enables validation of the increasing amount of software used in SoCs.
ProtoCompiler
The ProtoCompiler Design-In environment takes in design files including the RTL, any related IP (such as DesignWare IP), SDC and UPF files, as the basis for the migration. The runtime environment handles configuration and debug, and a link to a host PC enables virtual prototypes to run alongside the FPGA-based prototype.
Figure 1 ProtoCompiler overview (Source: Synopsys)
A graphical shell runs on top of a TCL scripting console to enable designers to automate and track the migration process, visualize the RTL and IP design hierarchy and interconnect, and view the design database as it evolves.
FPGA logic synthesis for HAPS
One of the challenges of FPGA-based prototyping is to synthesise an ASIC RTL design for an FPGA target without changing the original design too much. To help with this process, ProtoCompiler can automatically convert multiple clock domains and gated clock trees, often used in modern SoC designs to reduce power consumption, into a form that can be prototyped successfully on an FPGA. ProtoCompiler can also synthesise all of the 180 building blocks of Synopsys’ DesignWare IP library into an FPGA-compatible format, including any digital cores configured by CoreTools.
Multiprocessing support in the synthesis, partitioning, placement and routing process means that an ASIC design targeting four FPGAs can be migrated four times as quickly on a four-threaded processor as on a single-threaded version.
System planning
The system-planning process in ProtoCompiler addresses one of the key tasks in FPGA-based prototyping: mapping between the original ASIC or SoC architecture, and a physical prototype made up of a number of FPGAs with a limited number of gates and I/O pins each, interconnected on a PCB or across a number of PCBs.
ProtoCompiler offers a set of constraints that designers can use to manage this partitioning process.
A Target System Specification defines the initial target FPGA resources and the specifications of the prototyping hardware.
Port Bin declarations define the external I/O for each FPGA.
Global Clock Sources define clock signals that reach all of the FPGAs.
Trace Patterns are used to define the topology of the interconnect between the FPGAs, eg full interconnect, diagonal, chain, loop or star schemes.
Logic Partition constraints define the number of I/Os each FPGA has available for interfacing to the external world, and the channels or links between the FPGAs.
ProtoCompiler works in multiple stages: a pre-instrumentation process; compilation; pre-mapping and pre-partitioning; partitioning; and post-partitioning. This segmented approach, combined with a segmented data model, means that there are more places in this process where the design can be iterated, allowing for tight feedback loops. Several of these processes, such as compilation, pre-mapping and pre-partitioning, and post-partitioning, can also be accelerated using parallel processing.
Automatic synchronous source mapping
One of the toughest problems in migrating a large ASIC design on to a large FPGA prototyping system is that of distributing signals between the physical devices without reducing the overall clock rate of the prototyped design too much. The Xilinx Virtex-7 FPGAs used in the HAPS system include fast SERDES transceivers, on to which ProtoCompiler can automatically multiplex multiple logic signals so that they can distributed between devices as quickly as possible.
Figure 2 ProtoCompiler can automatically multiplex logical signals onto the SERDES resources of the Xilinx FPGAs used by HAPS (Source: Synopsys)
In one example of this strategy at work, designers set out to distribute 1800 signals between four FPGAs, connected in a ring, using fewer than 200 physical I/Os. On a HAPS-70 S48 (a 48 million AISC gate prototyping system), this was achieved using 200 I/Os on four connectors, to create 96 differential signal pairs – a multiplexing ratio of 24:1. The resulting system frequency was 17MHz, and this could have been boosted to 24MHz if additional I/O resources had been used to enable a multiplexing ratio of 8:1.
The following diagram shows the ProtoCompiler flow, including the additional steps necessary to migrate an ASIC design to a multi-FPGA prototyping system.
Figure 3 The ProtoCompiler flow gives SoC designers the opportunity to think about how they would prototype their designs (Source: Synopsys)
Note the short iteration loops, for example in the initial check of the RTL or the later check of the constraints files, enabled by the new data model. It is also worth noting, as annotated in the diagram, that the ProtoCompiler flow enables designers to think about how they will partition a design for FPGA-based prototyping at the same time as they develop the source ASIC/SoC architecture.
Debug and bring-up
One reason for building an FPGA-based prototype is to monitor key signals that would be unreachable in a finished chip. The flow above includes an optional instrumentation phase that helps designers ensure that they can instrument pre-partitioned RTL. This diagram (figure 4) shows more detail of the instrumentation flow.
Figure 4 The instrumentation flow can automatically invoke the routing necessary to reach debug logic defined before partitioning (Source: Synopsys)
Because the debug logic has been defined before partitioning, ProtoCompiler can automatically synthesise the routing resource necessary to reach that logic. It is also possible to add instrumentation at the netlist level, before FPGA place and route.
The result is to give the RTL debugger seamless access to key signals and watchpoints across all the FPGAs in the prototyping system.
It is also possible to add a companion board to the HAPS-70 system to expand the debug sample memory to 8Gbyte, without using any of its HapsTrak 3 expansion slots.
The hardware instrumentation of a design is matched with software that helps designers know which signals they should be considering. The Synopsys Siloti visibility automation system can be used to analyze the source RTL to show which signals should be recorded. An RTL debugger can then generate the fault stimulus to test those signals, and the results can be extracted for use in the Verdi debugger.
Validation
Mapping a design that has been targeted for an ASIC to a set of FPGAs for prototyping purposes involves a number of adjustments to, and translations of the original RTL to make it fit the hardware resources of the FPGAs. In order to check that the prototype matches the original design intent, Synopsys offers Formality, an equivalence checker. This tool can be used to check that the logic that comes out of the mapping process matches the intent of the original RTL.
Synopsys also offers the ability to split a design which is being prototyped between an FPGA implementation and a virtual implementation in software. Transaction models of the AMBA bus interface can be used as a boundary on which to split a design between an FPGA prototype running on a HAPS system and a virtual prototype running under Virtualizer. The AMBA transactors exist as code to be included in a software virtual prototype, and as RTL to be included in a design being prototyped with HAPS.
Figure 5 AMBA transactor models make a convenient boundary on which to split a prototype between hardware and software prototyping strategies (Source: Synopsys)
Conclusions
It is increasingly important to prototype ASIC and SoC designs so that the software intended to run on them can be validated early in the design cycle (the so-called ‘shift left’) and to check that they will work in the final context as expected.
Mapping a large design targeted to the rich routing and logic-cell resources of a modern SoC process to the more tightly constrained resources of an FPGA is complex. The process becomes more so when a design has to be portioned across multiple FPGAs so that key signals may have to run across PCB traces. A carefully thought out partitioning strategy can cluster interrelated signals within each FPGA, to minimise the impact of board crossing on every system clock speeds.
With ProtoCompiler, Synopsys has introduced an environment that helps designers migrate designs to HAPS FPGA-based prototyping systems and instrument the designs for the debug process. Given that SoCs increasingly need prototyping, ProtoCompiler can also help designers think about architecting their designs not just to achieve their specified function, but to be prototyped effectively.
More information
Find out more about ProtoCompiler here
Author
Troy Scott, a product marketing manager, is responsible for FPGA-based prototyping software tools at Synopsys. He has 20 years of experience in the EDA and semiconductor industries. His background includes HDL synthesis and simulation, SoC prototyping, and IP evaluation and marketing.
