A cost-effective and highly productive Framework for IP Integration in SoC using pre-defined language sensitive Editors (LSE) templates and effectively using System Verilog Interfaces

By Ashish Kumar Gupta, Broadcom Limited

ABSTRACT

This paper presents a cost-effective and efficient framework for IP Integration in SoC using pre-defined language sensitive Editors (LSE) like EMACS templates and effectively using System Verilog Interfaces. SoC integration approach of each company differs significantly in the way input is read by the tool, format understood by the tool for the IP and connectivity information, property of connection, algorithm to generate connections, renaming partitioning etc. The Paper presents an approach that is independent of automation tool and don’t need complex infrastructure to integrate IP in SoC. The approach presented, mentions various feature of Automated Integration tool and explains how it can be achieved making reusable templates understood by LSE editors like EMACS.

INTRODUCTION

Now a day’s most of the SoC Design companies are moving towards automation to do SoC integration but the infrastructure cost to maintain the automation is huge and is time consuming. Also extra time is spent to verify the sanity of the automated flow. Also the Automation tools consume huge time to generate Final RTL. With the enhancements made in various editors and introduction of language sensitive Editors (LSE) doing SoC integration in the hierarchical manner has become easy and efficient without much cost overhead. Features such as source navigator helps further during integration of various IP’s into SoC’s. Also with the growing use of System Verilog in design and usage of features like interfaces LSE’s make integration more effective and fast.

Most of the integration tools available use standard views of RTL files for example industry standard IP-XACT format and CSV files as input to integration tool this also makes database heavy as more and more files are needed to be added in database to provide inputs to automation tool. SoC Integration tools contain a rules-based assembly engine that enables rapid and robust interface and port-level connectivity to ensure that the chip integration can happen sooner and more predictably.

We can also use set of rules and create auto-templates to enable reusable, faster and robust integration using LSE’s such as EMACS. These rules can also be used to add prefix and postfix for the wire names, renaming wires and interfaces names to make integration easy etc. Auto-templates can be reused across IP’s to do similar connections. We can also invoke compiler through EMACS to check the sanity of generated RTL.

PURPOSE OF AUTOMATION TOOL IN IP INTEGRATION

Major usage of Automation for Integration involves:-

1. Reading required files from all directories. (mostly involved some kind of searching script to search based on directory structure)

2. Automatic instantiation of IP’s (modules).

3. Doing Interface based connections.

4. Doing point-to-point connectivity between IP’s (modules)

5. Wire renaming, adding prefix or postfix (mainly to identify source and destination module).

6. Doing automatic clock / reset connectivity.

7. Auto-insertion of clock gating cell.

8. Bus connections for all memory mapped peripherals.

9. Doing automatic Interrupt, DMA connectivity.

10. Automatic tie high/low of undriven ports.

11. Automatic generation of pin muxing logic.

12. Flattening of Hierarchical design

13. Moving IP’s from one hierarchy to other.

14. Automatic creation of glue logic and moving it to correct hierarchy.

15. Generating report of un-driven and Multi-Driven inputs, Unused outputs.

16. Generating files that can be used as input for Verification. (Specially Formal Verification). Example- DMA, Interrupt, Padring, Pin muxing verification.

Proposed framework for IP Integration

This paper covers all these points one by one and tries to explain how each point can be covered in proposed framework.

Reading required files from all directories.

Emacs provide features to look up in list of directories when looking for files for /*AUTOINST*/. The directory may be relative to the current file, or absolute. Environment variables are also expanded in the directory names. `defines can also be read (Defines must be simple text substitutions, one on a line, starting at the beginning of the line. Any ifdefs or multiline comments around the define are ignored.)

Automatic instantiation of IP’s (modules).

Emacs capture port list of necessary modules to do module instantiation.

It reads all module that is instantiated in the design be searching in the library directories and extension information. Below is the example of how to instantiate various IP’ in SoC or Sub-system.

Emacs create input, output, inout ports and also create the instantiation based on port names. By default the wire name is same as the name of input/output or inout port. More details on this along with renaming will be done in further sections.

Doing Interface based connections.

There can be two types of interface based connections. In Automation environment we need to provide the information regarding this connectivity in some sheet. In Emacs we can provide this information in the templates.

1. where System Verilog interface is used to group set of signals.

Example AHB_MASTER, AHB_SLAVE interface are created and files are created in system Verilog which connects MASTER interface with SLAVE interface by simple mapping.

In Automation environment we need to provide the information regarding this connectivity in some sheet. In Emacs we can provide this information in the templates.

1. Where separate ports are there but we group them based on functionality or prefix.

   In Automation tool we can define interface by group set of signals using port, protocol and function information but that is not possible in EMACS. In EMACS we can do this type of connectivity either by using prefix or doing point to point connection.

Doing point-to-point connectivity between IP’s (modules)

In automation tool this needs to be done by having connectivity information in CSV where as in EMACS this can be done using template. One entry per connection is required in automation tool whereas 1 or 2 entries per connection need to be provided in EMACS.

In the example above connection between out port of module A is done with in port of module B. Here we want to provide information of source and destination so we need to add 1 line in Module A template and 1 line in Module B template. (so two line needs to be added)

Clk port of both modules are to be connected to top level clk_in port so only 1 line per connection is needed.

Automation tools can also tie the undriven inputs (to default value) and hence we don’t need to tie all inputs that are unused by hand. (these tools can also tie the values to 0 or 1 based on some rules for example it looks for keywords rst, reset etc and tie the input to ‘0’ and in case _b or _n is in port name it will tie it to ‘1’ assuming reset or other signal to be active low). In emacs we need to tie ports by searching some prefix, also we can tie all remaining ports that are not defined in template to default value but this needs all other required ports to be connected manually.

While using automation tool if the design is hierarchical only those ports will be created which are crossing the hierarchical boundaries. For example:- module A is instantiated inside module A_top and module B inside B_top to when integration Is done by automation tool only those ports get created that is needed to connect A with B. other ports if unused , undriven will not create port at A_top and B_top level.

In Emacs all ports that are not used inside hierarchy will get created in A_top and B_top.

To avoid creation of unnecessary ports we need to provide input to emacs not to create port for such unused port.

Another issue in EMACS because of which we need to use auto-input-ignore is when we use glue logic inside A_top and assign glue logic output to input port of module A:-

For example:-

In this case even if en is assigned inside the same A_top module emacs will create input port names as “en” so we need to add en in list for verilog-auto-output-ignore-regexp.

Wire renaming, adding prefix or postfix.

In CSV based automation flow we can insert rule based prefix and postfix or insert that port wise.

Unused and tied prefix is usually added for unused outputs and tied inputs. This will also help further in doing review of tied and unused signals.

In Emacs this is done using TEMPLATE. By default wire with port name will be created. In example below port names are changed to have some meaningful wire names.

Bus connections for all memory mapped peripherals.

Bus connection using automation tool provides flexibility that it can be used across languages. Integration using EMACS can be effectively done when system Verilog interfaces are created in the design. This may require change in top level IP module to sv and creating interfaces for all such bus based connectivity. If Verilog, VHDL is used or system Verilog with interface is used either point to point connectivity needs to be done or some ports can be connected using rule based AUTOTEMPLATE. But this restricts us that other ports in the IP don’t have the names.

Usually CSV based automation tools do connectivity based in port, protocol and function.

For example we can list down all the ports in the IP for a particular protocol and group them. When two IP’s needs to be connected using protocol based connectivity all ports that have same function and protocol will get connected even if the port name is different.

For example:-

If ports of APB protocol are named as PSEL, PADDR, PWDATA, PRDATA in the bus matrix and named as apb_sel, apb_addr, apb_wdata, apb_rdata in the IP. As both belong to same protocol i.e APB connectivity will be done based on function of each port. Example function of apb_sel and SEL is same, apb_addr and PADDR is same. Only thing we need to maintain is the table that contains the information regarding PROTOCOL, FUNCTION and the list of all port names that are used in the IP’s. This sheet can be reused in any other SOC just by adding new port names if any new port name is used for specific protocol and function.

It’s not always easy to have some rule based connectivity in EMACS as IP owner can use any name. But usually there are RTL coding guidelines and if the IP is designed following coding guidelines it will be straight forward to do such connections using templates.

Doing Interrupt, DMA connectivity.

Usually all SoC’s maintain the list of DMA channel mapping and interrupt mapping along with the indexes in which IP’s dma request/acknowledge or interrupt needs to be connected. We can use same sheet to do automation around interrupt and dma connectivity. In EMACS also we can generate some template based on the interrupt sheet or DMA sheet.

Auto-insertion of clock gating cell. Doing automatic clock / reset connectivity.

Automation tools provide the facility of auto-insertion of clock gating cells and doing connectivity automatically. The only thing needs is to provide the input to the tool the clock that needs to be added, controls to the gate and type of clock gating cell to be used.

Also if the clock domain is known automatic reset synchronization logic is inserted and connectivity can be done. Usually all SoC’s maintain the list of clocks to IP’s and controls used to do clock gating and we can use same information as input to the tool to minimize the effort for integration. Although lot of scripting effort is needed for such features. EMACS don’t support such auto-insertion or connectivity and this needs to be done manually but keeping in mind complexity required to create such scripts in automation tool the extra effort in instantiating clock gating cells reset synchronization logic manually should be acceptable. Usually the template once defined can be used in other similar products.

Automatic generation of pin muxing logic.

Usually most of the companies uses in-house scripts to generate pin muxing logic or IOMUX logic.

Flattening of Hierarchical design

Automation tool can generate the connectivity information internally and it can flatten the hierarchical design and do the connection module to module based on the information collected. Although not straight forward we can do so by copying all AUTOINST module in one file and generating RTL again. Minor modification in template is needed as clock and reset name of each partition can be different.

Moving IP’s from one hierarchy to other.

As is mentioned earlier all connectivity information is captured by Automation tool and it stores connectivity based on module to module connectivity and hence is we move IP from one hierarchy to other it can redo connections based of the connectivity information stored. Using template in EMACS also we can cut and paste the IP instance from one file to other and generate RTL again to do such movement. Minor modification in template is needed as clock and reset name of each partition can be different.

Automatic tie high/low of undriven ports.

Automation tool can drive all the undriven ports to ‘0’ or ‘1’. We can do the tieing off based on some rules. In EMACS also we can do the tying off of undriven signals by searching for undriven inputs. But this will tie all ports that are not specified in auto-template. So all ports that are to be connected needs to be specified in the auto-template.

Similarly we can append some keyword to specify unused outputs (eg. *_unconn) in the design provided all outputs that needs to be connected are specified in auto-template.

Automatic creation of glue logic and moving it to correct hierarchy.

This cannot be done in EMACS and we need to create instance for all glue logic manually.

Generating report of un-driven and Multi-Driven inputs, Unused outputs.

As automation tool captures the information of connectivity of each IP port wise if the input port is connected from two different IP’s by mistake it will flag the error. Also it will report all ports that are not driven or unused. This is not possible in case of xemacs.

In xemacs we can grep the RTL to search for keyword that we appended for unused outputs (eg. *_unconn) to find the list of unconnected ports but its manual process.

Generating files that can be used as input for Verification. (Specially Formal Verification). Example- DMA, Interrupt, Padring, Pin muxing verification.

This cannot be done in EMACS. But usually we can directly use sheets from Architecture document to generate the assertions for Formal verification.

Summary

After going through features that are implemented in any standard automation tool and how similar thing can be done using EMACS it is clear that most of the work of automation tool can be done in EMACS. Although there are some limitations of EMACS over automation tool but keeping in mind the complexity effort and cost associated with developing a reliable automation tool we can conclude that EMACS can be effectively used as a tool to do IP integration in SoC. Also there is no need to generate specific views understood by the Automation tools. Listed below are the advantages and disadvantages of EMACS for quick reference.

Advantages:-

• SoC integration Cost reduced to great extend as no automation tool or framework is required.
• Run time to integrate IP in SoC is very less as compared to Automation tools.
• Size of frontend integration database reduces a lot as no additional files/views are required.
• No need to read complete database again for change in few RTL files.
• No need to read complete database again for change in few RTL files.
• Additional data required for integration is minimal.
• No Additional cost of Integration tools or creating automation environment.
• Time taken to generate SoC RTL is very less compared to automation tool.

Limitations of using EMACS for Integration:-

• No report generated for undriven, unused, multiple driven ports. (Need to run LINT after generating RTL)
• No additional files get generated that can be used for Verification for example- when CSV’s are used we can generate Memory maps, connectivity details of interrupts, dma, padring etc. on the fly.
• Clocks (Automatic clock gating insertion not possible), resets, memory connectivity etc. to be done manually.
• Different persons can do connectivity in parallel. (updating CSV’s in parallel)

References

http://standards.ieee.org/

http://www.veripool.org/wiki/verilog-mode/Verilog-mode-Help

http://www.veripool.org/wiki/verilog-mode/Verilog-mode_veritedium

https://www.doulos.com

If you wish to download a copy of this white paper, click here