{"id":7723,"date":"2015-02-27T16:52:32","date_gmt":"2015-02-27T16:52:32","guid":{"rendered":"https:\/\/www.techdesignforums.com\/practice\/?p=7723"},"modified":"2019-03-31T17:14:59","modified_gmt":"2019-03-31T17:14:59","slug":"ip-based-fpga-design-synplify","status":"publish","type":"post","link":"https:\/\/www.techdesignforums.com\/practice\/technique\/ip-based-fpga-design-synplify\/","title":{"rendered":"Getting the most out of IP based FPGA design with Synplify"},"content":{"rendered":"<p>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\u2019t undermine the advantages of using IP in FPGA-based designs.<\/p>\n<h2>Simple approaches to IP creation<\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>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\u2019 Synplify can ingest all the IP files created by an IP vendor\u2019s generator tool and use them as input to its integration process.<\/p>\n<h2>IP management concepts<\/h2>\n<p>The flow you use to manage your IP will depend on a number of factors:<\/p>\n<ul>\n<li>how the IP is packaged<\/li>\n<li>the content type: RTL, netlist or synthesis models<\/li>\n<li>user requirements, such as QoR, visibility, and stability<\/li>\n<\/ul>\n<p>IP is packaged in a number of ways, depending on three key parameters (see Figure 1):<\/p>\n<ul>\n<li>packaging format<\/li>\n<li>encryption type<\/li>\n<li>content type<\/li>\n<\/ul>\n<em>No URL for image<\/em>\n<p>IP is delivered in three forms:<\/p>\n<ul>\n<li>RTL, which is incorporated into the rest of the RTL and then synthesised<\/li>\n<li>Gate-level netlist, which can be incorporated into the rest of the design as it is, or re-optimized for better results<\/li>\n<li>Synthesis models, also known as &#8216;white box\u2019 or \u2018grey box\u2019 models, which provide timing and area information, but are untouched by synthesis and are incorporated into the design by place and route.<br \/>\nSome considerations about working with each type follow in Figure 2.<\/li>\n<\/ul>\n<em>No URL for image<\/em>\n<h2>Choosing an IP integration methodology<\/h2>\n<p>Your IP integration strategy depends on a number of factors:<\/p>\n<ul>\n<li>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<\/li>\n<li>The importance you place on having constraints information available for synthesis<\/li>\n<li>How the IP is delivered, eg as plaintext, or encrypted using IEEE P1735<\/li>\n<\/ul>\n<h2>Strategies for IP optimization<\/h2>\n<p>There are various ways in which IP can be incorporated in a design: by being absorbed into the design\u2019s RTL, or incorporated as a white box, grey box or black box model.<\/p>\n<p>In an <em>Absorb<\/em> 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.<\/p>\n<p>In a <em>white-box<\/em> 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\u2019t include the IP logic, which is added during place and route.<\/p>\n<p>In a <em>black-box<\/em> 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\u2019t include the IP logic, which is added during place-and-route.<\/p>\n<p>Altera offers a <em>\u2018grey-box<\/em>\u2019 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\u2019t include the IP logic, which is added during place-and-route.<\/p>\n<p>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.<\/p>\n<h2>Using Xilinx Vivado IP<\/h2>\n<p>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.<\/p>\n<em>No URL for image<\/em>\n<p>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.<\/p>\n<p>Some best practices:<\/p>\n<ul>\n<li>Compile your design with black boxes before IP import. Remove the stub files, used for black-boxing, after the IP is imported.<\/li>\n<li>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.<\/li>\n<li>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.<\/li>\n<\/ul>\n<h2>Using Altera IP<\/h2>\n<p>Synplify FGPA tools provide direct support for Altera IP. Megafunctions can be inferred and are modeled using \u2018clear-box\u2019 and grey-box models. Instances of LPMs (library of parameterized modules) can be merged into the design as a netlist.<\/p>\n<em>No URL for image<\/em>\n<p>Some recommendations<\/p>\n<ul>\n<li>When incorporating third-party IP available as RTL, use that RTL as the source.<\/li>\n<li>When working with Xilinx Vivado IP, use the netlist as the source.<\/li>\n<li>When working with Altera IP, use the grey-box netlist as source.<\/li>\n<li>When timing-critical paths originate or end inside an IP block, use the netlist Absorb strategy.<\/li>\n<li>If you want a flow that is easy to debug, use the white-box approach on Vivado IP.<\/li>\n<\/ul>\n<h2>Working with third-party IP<\/h2>\n<p>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&#8217;s plaintext or has been delivered with embedded encryption keys that Synplify can unlock.<\/p>\n<p>IP delivered in netlist format has already been synthesized in Synplify, which should mean better performance.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<em>No URL for image<\/em>\n<h2>Packaging and protecting IP for re-use<\/h2>\n<p>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.<\/p>\n<p>Depending on how you expect the IP you are packaging to be used, you may want to encrypt it.<\/p>\n<p>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 \u2018digital envelopes\u2019 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.<\/p>\n<p>The steps to created an IP block encrypted with P1735 are as follows:<\/p>\n<ul>\n<li>create the IP\u2019s RTL<\/li>\n<li>create a list of all the RTL source files to be encrypted<\/li>\n<li>encrypt RTL files to the P1735 standard (Synplify includes this facility)<\/li>\n<li>ship the Synplify project file along with IP files, so the IP can be incorporated as a sub-project in the target design<\/li>\n<\/ul>\n<p>Figure 6 shows how the encryption process works. Your unencrypted source is encrypted with a session key, creating an encrypted data block.<\/p>\n<p>The session key is created using asymmetric encryption, using the software vendor\u2019s 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\u2019s key block exists in the encrypted file.<\/p>\n<em>No URL for image<\/em>\n<p>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.<\/p>\n<em>No URL for image<\/em>\n<p>Synplify includes an encryption script, and a public key.<\/p>\n<h2>Other Synplify features<\/h2>\n<p>Synplify supports a special design flow for the Xilinx Zynq-7000 all-programmable SoC.<\/p>\n<p>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.<\/p>\n<h2><b>Further information<\/b><\/h2>\n<p>Virtual prototyping<\/p>\n<p><a href=\"http:\/\/www.synopsys.com\/Systems\/VirtualPrototyping\/Pages\/default.aspx\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/www.synopsys.com\/Systems\/VirtualPrototyping\/Pages\/default.aspx<\/a><\/p>\n<p>Hybrid prototyping<\/p>\n<p><a href=\"http:\/\/www.synopsys.com\/Systems\/FPGABasedPrototyping\/Pages\/hybrid-prototyping.aspx\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/www.synopsys.com\/Systems\/FPGABasedPrototyping\/Pages\/hybrid-prototyping.aspx<\/a><\/p>\n<p>Synplify synthesis<\/p>\n<p><a href=\"http:\/\/www.synopsys.com\/Tools\/Implementation\/FPGAImplementation\/Pages\/default.aspx\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/www.synopsys.com\/Tools\/Implementation\/FPGAImplementation\/Pages\/default.aspx<\/a><\/p>\n<p>Webinar: Getting the most out of IP-based FPGA design with Synplify &#8211; <a href=\"https:\/\/event.on24.com\/eventRegistration\/prereg\/register.jsp?eventid=907380&amp;sessionid=1&amp;key=5EA292D9A805767495ABEAFA515AB763&amp;partnerref=web&amp;cmp=WEBR-fpga100400-HPE\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/event.on24.com\/eventRegistration\/prereg\/register.jsp?eventid=907380&amp;sessionid=1&amp;key=5EA292D9A805767495ABEAFA515AB763&amp;partnerref=web&amp;cmp=WEBR-fpga100400-HPE<\/a><\/p>\n<h2><b>Author<\/b><\/h2>\n<p>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,\u00a0leading SOC design team that created System Designer tool. He holds a BE in electronics from Thapar University, Patiala India.<\/p>\n<h2><b>Company info<\/b><\/h2>\n<address><i>Synopsys Corporate Headquarters<\/i><\/address>\n<address><i> 690 East Middlefield Road<\/i><\/address>\n<address><i>Mountain View, CA 94043<\/i><\/address>\n<address><i>(650) 584-5000<\/i><\/address>\n<address><i>(800) 541-7737<\/i><\/address>\n<address><i>\u00a0<\/i><i><a href=\"http:\/\/www.synopsys.com\">www.synopsys.com<\/a><\/i><\/address>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>How Synplify makes it easier to use IP in FPGA-based designs, and package your own IP for secure reuse, on Altera and Xilinx devices <\/p>\n","protected":false},"author":329,"featured_media":7738,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1386,160],"tags":[1814,1571,922,1684,1145,1812],"coauthors":[996],"class_list":["post-7723","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assembly-integration","category-design-management","tag-altera","tag-ip-encryption","tag-ip-integration","tag-reuse","tag-vivado","tag-xilinx","workflow-technique","workflow-up-to-date","organization-synopsys"],"_links":{"self":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/7723","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/users\/329"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/comments?post=7723"}],"version-history":[{"count":0,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/7723\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media\/7738"}],"wp:attachment":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media?parent=7723"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/categories?post=7723"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/tags?post=7723"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/coauthors?post=7723"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}