Getting the most out of IP based FPGA design with Synplify

The combination of FPGAs and IP blocks enables teams to develop and try out complex designs quickly. Optimised approaches to managing and using third-party IP, and packaging your own IP for reuse, can help ensure that methodology issues don’t undermine the advantages of using IP in FPGA-based designs.

Simple approaches to IP creation

In the simplest IP creation process, a team develops an IP block, compresses the file and sends it to the design team, which unpacks it and integrates the RTL into the top level of its design, which is then synthesized and implemented as a whole.

A slightly more complex approach sees the creation team including constraints with the RTL, which are then used to inform the place and route process.

More complex distribution strategies are necessary if creators are distributing configurable IP, targeting specific implementation technologies, or for licensing reasons. An IP packaging tool is necessary so that end users can generate the specific version of the IP they need, target it to their choice of FPGA, and get a licensed file for integration. Tools such as Synopsys’ Synplify can ingest all the IP files created by an IP vendor’s generator tool and use them as input to its integration process.

IP management concepts

The flow you use to manage your IP will depend on a number of factors:

• how the IP is packaged
• the content type: RTL, netlist or synthesis models
• user requirements, such as QoR, visibility, and stability

IP is packaged in a number of ways, depending on three key parameters (see Figure 1):

• packaging format
• encryption type
• content type

IP is delivered in three forms:

• RTL, which is incorporated into the rest of the RTL and then synthesised
• Gate-level netlist, which can be incorporated into the rest of the design as it is, or re-optimized for better results
• Synthesis models, also known as ‘white box’ or ‘grey box’ models, which provide timing and area information, but are untouched by synthesis and are incorporated into the design by place and route.
  Some considerations about working with each type follow in Figure 2.

Choosing an IP integration methodology

Your IP integration strategy depends on a number of factors:

• Whether or not you want to optimise the contents of an IP block, and/or use the contents to develop good timing and resource estimates
• The importance you place on having constraints information available for synthesis
• How the IP is delivered, eg as plaintext, or encrypted using IEEE P1735

Strategies for IP optimization

There are various ways in which IP can be incorporated in a design: by being absorbed into the design’s RTL, or incorporated as a white box, grey box or black box model.

In an Absorb methodology, the IP logic can be optimized as part of the larger design during synthesis. The netlist output by synthesis includes the IP logic, so there is no need to provide the IP separately to the place and route process.

In a white-box methodology for gate-level IP, the IP netlist is added as a read-only model. Synthesis does not change the IP, whose netlist is used for timing and resource estimation. The netlist output by synthesis doesn’t include the IP logic, which is added during place and route.

In a black-box methodology for gate-level IP, a stub for the IP is included in the design RTL. Synthesis has no visibility of IP timing or resources, unless special attributes are added to the stub. The netlist output by synthesis doesn’t include the IP logic, which is added during place-and-route.

Altera offers a ‘grey-box’ flow, in which Altera tools generate a read-only netlist, which cannot be re-optimized, for the Synopsys Synplify tool. The IP netlist is used for timing and resource estimation. The netlist output by synthesis doesn’t include the IP logic, which is added during place-and-route.

The difference between a grey-box and white-box netlist in this context is that a white-box netlist can also be used in Absorb mode.

Using Xilinx Vivado IP

The Xilinx Vivado IP Catalog tool generates Xilinx IP in two forms: plaintext RTL, and encrypted RTL. Plaintext IP can be absorbed during synthesis as part of the top-level design. Encrypted RTL is only readable by simulators. Vivado produces a gate-level netlist for Synplify to read.

During the import process, Synplify automatically translates Vivado XDC constraints into Synplify FDC format constraints. The tool can import both RTL and netlist IP, and can handle single blocks or all the blocks in an IP directory at once.

Some best practices:

• Compile your design with black boxes before IP import. Remove the stub files, used for black-boxing, after the IP is imported.
• Let the Synplify IP import features set the best defaults. Point to an IP directory and Synplify will do the rest. Alternatively you can point to a directory full of IP, or a list file with XCI or DCP files, and Synplify will add all IP or a list of IP.
• When Vivado is not available or installed, generate an IP netlist and XDC file once. Then import that netlist and XDC using -verilog and -xdc options.

Using Altera IP

Synplify FGPA tools provide direct support for Altera IP. Megafunctions can be inferred and are modeled using ‘clear-box’ and grey-box models. Instances of LPMs (library of parameterized modules) can be merged into the design as a netlist.

Some recommendations

• When incorporating third-party IP available as RTL, use that RTL as the source.
• When working with Xilinx Vivado IP, use the netlist as the source.
• When working with Altera IP, use the grey-box netlist as source.
• When timing-critical paths originate or end inside an IP block, use the netlist Absorb strategy.
• If you want a flow that is easy to debug, use the white-box approach on Vivado IP.

Working with third-party IP

Companies such as Synopsys, ARM and others also offer IP for use in FPGAs. Their IP blocks are shipped with Synplify project files, which can be added to a user design project as a sub-project. The RTL is accessible for synthesis, because it’s plaintext or has been delivered with embedded encryption keys that Synplify can unlock.

IP delivered in netlist format has already been synthesized in Synplify, which should mean better performance.

ASIC designs can be synthesized into an FPGA using Synplify, without having to replace any of the Synopsys DesignWare components. Synplify recognises DesignWare models that have been instantiated in the ASIC RTL and handles them automatically.

DesignWare Cores can also be used directly in FPGA designs. Synopsys has two tools, coreConsultant and coreAssembler, which can be used to configure DesignWare components and then generate the necessary RTL, constraints and scripts to be passed into Synplify as a project file, to be combined with the rest of your design.

Packaging and protecting IP for re-use

A typical IP package will contain a metadata file or a Synplify project file, RTL or netlist files, constraint files, and a configuration tool if the IP is configurable. The Synplify-import process adds a Synplify project file (PRJ), translated IP constraints (FDVC, and a constraints file for place and route if supplied.

Depending on how you expect the IP you are packaging to be used, you may want to encrypt it.

The IEEE is in the process of adopting the P1735 standard for encrypting IP, with support from Aldec, Altera, Cadence Design Systems, Mentor Graphics, Synopsys and Xilinx. The standard uses strong encryption to create ‘digital envelopes’ that enable multiple tools to read encrypted designs securely. It is up to the IP vendor to decide which EDA tools can read the IP.

The steps to created an IP block encrypted with P1735 are as follows:

• create the IP’s RTL
• create a list of all the RTL source files to be encrypted
• encrypt RTL files to the P1735 standard (Synplify includes this facility)
• ship the Synplify project file along with IP files, so the IP can be incorporated as a sub-project in the target design

Figure 6 shows how the encryption process works. Your unencrypted source is encrypted with a session key, creating an encrypted data block.

The session key is created using asymmetric encryption, using the software vendor’s public key, to create the key block. The encrypted data block and key block are then bundled together to create a digital envelope. Each tool vendor gets a separate key block, based on their public key, and users can see which vendor’s key block exists in the encrypted file.

The decryption process in Synplify starts with the decryption envelope. The tool uses its own key block to decrypt the session key using a private key. The extracted session key is then used to decrypt the data block. This decryption process never writes the decrypted data on the disc. The design is synthesized and re-encrypted before it is written out in a file.

Synplify includes an encryption script, and a public key.

Other Synplify features

Synplify supports a special design flow for the Xilinx Zynq-7000 all-programmable SoC.

It also supports the use of software IP models for prototype systems, for example to validate IP in a real-world environment. The solution is to use UMRbus and AMBA-based transactors to connect the virtual CPU subsystems to FPGA-based prototyping hardware.

Further information

Virtual prototyping

http://www.synopsys.com/Systems/VirtualPrototyping/Pages/default.aspx

Hybrid prototyping

http://www.synopsys.com/Systems/FPGABasedPrototyping/Pages/hybrid-prototyping.aspx

Synplify synthesis

http://www.synopsys.com/Tools/Implementation/FPGAImplementation/Pages/default.aspx

Webinar: Getting the most out of IP-based FPGA design with Synplify – https://event.on24.com/eventRegistration/prereg/register.jsp?eventid=907380&sessionid=1&key=5EA292D9A805767495ABEAFA515AB763&partnerref=web&cmp=WEBR-fpga100400-HPE

Author

Parminder Gill is engineering project leader, FPGA implementation at Synopsys. He has 17 years of experience in FPGA implementation tools, RTL design, verification, and prototyping. Before joining Synopsys he was a senior manager at Synplicity, leading SOC design team that created System Designer tool. He holds a BE in electronics from Thapar University, Patiala India.

Company info