SPIRIT-based IP Assembly and SDC promotion for a 65nm System-on-Chip using coreassembler

Transcription

1 SPIRIT-based IP Assembly and SDC promotion for a 65nm System-on-Chip using coreassembler Olivier Florent Philip Cuney Cyril Vartanian STMicroelectronics STMicroelectronics STMicroelectronics Grenoble, France Grenoble, France Grenoble, France olivier.florent@st.com philip.cuney@st.com cyril.vartanian@st.com Stéphane Maulet Emanuele Irrera Sal Tiralongo Synopsys Professional Services Synopsys Professional Services Synopsys Professional Services Grenoble, France Milan, Italy Milan, Italy smaulet@synopsys.com eirrera@synopsys.com stiralo@synopsys.com ABSTRACT To cope with the huge time-to-market pressure, every designer is looking at a plug-andplay solution to build complex System-on-Chips. One of the current challenges of such designs is to assemble quickly and consistently a high numbers of IPs around one or more on-chip-bus. Thanks to SPIRIT, Synopsys coretools & ST Microelectronics design data structures, this process can be made much more efficient. SPIRIT consortium is providing a standard way of describing IP for integration purpose and this is now supported by various CAD tools. The coreassembler tool is used to automate and speed up the Front-End design capture of a 65nm System-on-Chip. Each IP is described using SPIRIT metadata which are built automatically from standard ST Microelectronics design data structures. The automatic protocol based connection capability of the tool is then used to perform a correct by construction assembly suitable for chip verification as well as chip implementation. The ability to extend coreassembler by writing custom plug-in is demonstrated by showing how the IP-based design capture flow is linked with pad ring design, and how it interfaces with ST design data structures. Moreover, this paper will outline the features and usage of a complex plug-in, specifically developed to promote and consolidate IP timing constraints into one unique chip level SDC. Overall, this SPIRIT-based IP assembly methodology is showing a significant productivity increase, helping to enter quickly and earlier physical design and chip verification, and enabling quick reacts to specification changes.

2 1 Introduction Chip companies that compete in the consumer market are facing two conflicting trends regarding their product development: the complexity is increasing while the time to market is reducing. This is exactly the situation of STMicroelectronics Home Entertainment Group: every new generation of System-On-Chip includes more features, uses more innovative leading-edge technologies, while the competition and the market are asking for faster design cycle. Furthermore most of the customers are no more looking for only silicon, but for a complete solution including software, meaning that software development should start as soon as possible, before silicon is available. Ultimately, the targeted products often have late and unexpected specification changes driven by the market quick evolution. From a designer perspective, solutions are to accelerate and secure the System-on-Chip design assembly as well as to provide one unique design database that can be used for design implementation, design verification and software development. This can be achieved using a SPIRIT based approach and SPIRIT compliant tools. Chapter 2 will give a SPIRIT overview and show the added value brought to the SoC product development. It will also outline the SPIRIT features inside coreassembler a Synopsys tool. Chapter 3 will describe in depth the SPIRIT-based IP assembly flow deployed on ST STM nm set-top-box System-on-Chip. Besides the standard way of using coreassembler on a SPIRIT database, this chapter will outline how this tool can be extended through plug-ins to be better integrated into STMicroelectronics design environment. Moreover the methodology used to promote timing constraints information from IP level to SoC level during the assembly will be described and illustrated with examples and results. Downstream usage of the assembled design database for verification and physical implementation will be discussed in the last part. 2 Using a SPIRIT approach to System-On-Chip assembly STMicroelectronics Set-Top-Box chips are System-on-Chips (SoC): they are made of several IPs and CPUs connected together through a proprietary on-chip-bus. Each IP contains one or more standards bus interfaces, and a set of registers that are possibly accessed through the bus by the others IPs. One of the challenges of such designs is to assemble quickly and consistently all these IP together to eventually start the implementation process, and to enable quick assembly replay in case of system specification updates. One solution is to have a coherent database of all the needed IPs, as well as tools able to work efficiently on this database. Moreover this database should embed different abstraction levels to address other areas like design verification and software development in a consistent manner. Such a database is part of what SPIRIT is addressing. 2.1 What is SPIRIT?

3 SPIRIT stands for Structure for Packaging, Integrating and Reusing IP within Tool Flow. It is a consortium [1] founded by three types of companies: IP integrators like Philips or STMicroelectronics, IP providers like ARM, and CAD vendors like Cadence, Synopsys and Mentor-Graphics. They teamed up together to facilitate the integration of various IP coming from different sources into a System-on-Chip. One important aspect of SPIRIT is that CAD automation is part of the goals. Moreover any SPIRIT feature is supposed to have been proved on a real design by the consortium members. As of today SPIRIT 1.1 specification is available, and is gaining adoption in the semiconductor companies [2]. SPIRIT proposes a metadata structure to describe each and every component of a system. This structure enables to import a component into a design while taking into account the component integrations constraints. SPIRIT metadata can be used to describe a design resulting of an assembly of several components. SPIRIT also defines a set of API functions, to access and transform any SPIRIT metadata. These API are used to provide configurable IP through configurable metadata, but also enable to package any needed point tool as a standard SPIRIT generator that can be called from any SPIRIT compliant SoC design tool. Figure 1 : SPIRIT metadata and SPIRIT generators in a SPIRIT compliant design tool The two next sections will further describe the content of SPIRIT metadata and the scope of the SPIRIT generators SPIRIT metadata A SPIRIT metadata is an XML file that should comply with the SPIRIT XML schema. It is meant to describe objects like bus definitions, components or even a full design.

4 A bus definition is the XML description of a set of signals constituting a bus interface that exists among two or more components. This can cover on-chip-bus like Amba or STBus, standard interfaces like USB or SATA, but also internal ad-hoc IP interfaces like the DFT bus. This bus definition contains information such as the mandatory and optional signals that are part of the bus, their direction and associated default values when the full interface is either a slave or a master one, or even their timing constraints. A component is the XML description of a given level of hierarchy as a black-box. This can be one IP or an abstracted level of a set of connected IPs. It contains information such as: Hardware model signals: the list of the i/o ports of the component, possibly including timing constraints; Bus interfaces: instances of available bus definition covering all known interfaces of the component. Each instance is mapped to the port list and configured according to the bus definition properties (for instance master/slave behavior, optional/mandatory signals and possibly values different from the default for bus definition parameters); Memory map: The description of any internal registers that can be accessed through the component slave interfaces, including addresses and read/write properties; Address space: The description of the programmer view as seen from the component master interfaces. It also describes address translation scheme when the described component embeds itself a piece of the on-chip-bus; Model views : Catalog of available views (RTL, TLM, hierarchical views ) and their location. A design is the XML description of a set of components connected together through bus interfaces and simple ad-hoc wires. By combining a component XML with its own design XML description it is then possible to describe a full hierarchical system SPIRIT Generators Using the standard API, the SPIRIT metadata of a component can embed a mechanism to make it configurable. This object is called a SPIRIT generator as it will then generate transparently a new configured component metadata from the generic description. Moreover the use of the standard API ensures that any SPIRIT compliant tool will be able to support natively this SPIRIT generator. This can be applied for instance to the on-chip-bus which is usually a configurable component as its content depends on the number of IP to be connected together. Point tools that either perform checks on the SPIRIT database or extract data from the SPIRIT database can also be packaged as SPIRIT generators thanks to the API. 2.2 What does SPIRIT metadata enable?

5 Having all the components of a System-On-Chip described as SPIRIT metadata has several advantages: IP can be safely configured in the way planned by the provider as this is coded in the XML generator; metadata such as bus interfaces are carrying integration constraints that can be used and verified during IP integration; moreover those metadata can be used to derive useful data. As an example, let us see what can be done with bus definition instantiated on a component and with memory map and address space description Usage of bus definition and bus interface metadata The first usage of bus interfaces on a component is to automate and simplify as much as possible the connection between two or more components. If one component has a master instance of one bus definition and another component has a slave instance of the same bus definition, a correct by construction automatic connection can be safely made between the two. Even if those two instances are not using the exact same set of mandatory and optional signals, the bus definition information will allow tying up or tying down automatically and correctly the unused signals. This automatic protocol based connection can significantly speedup and secure the design assembly. The bus interface information can also be used to derive consistent useful data from the component. For instance it is possible to generate a TLM skeleton model of the component reflecting the behavior of its interfaces, and that can be used in system level simulation. On the other hand it is also easy to generate automatically a bit accurate test bench aimed at testing the behavior of the interfaces. This test bench can then be applied to the IP RTL model. Finally this bus interface can be promoted to the next hierarchical level at the end of the assembly. This is the case when the bus interface is exported, i.e. connected to the top-level of the design. The information will then be available for the next level of assembly Usage of memory map and address space metadata The registers description present in the component XML can be used to enrich the TLM skeleton model described above with the register behavior as seen from the interface. It can also be used to enrich the component test bench to test the register behavior. Both the TLM models and the test bench will greatly help the process of building system verification tests and IP integration tests. Another usage of the register information is to generate C header files needed for software driver development. This will help early software development, while ensuring coherency with the design. The register information can also be consolidated during the design assembly for the registers embedded in the IP that need to be visible to the next level. Moreover the address space information attached to bus components is then used to compute the new address of each register in the context of the system. This makes available the full register map of the system

6 from where can be derived either a full header file for system software development, or a C code to be executed on the system processor to check system level register access. Another useful derived data is the full datasheet of the system which can be generated within a minute Conclusion By using a SPIRIT based approach it is possible to enhance significantly many part of the design process: the design assembly can be secured and speed-up; IP verification tests can be automatically generated, as well as IP integration tests at system level; finally significant data can be generated to ease system verification and early software development. 2.3 Synopsys coreassembler: a SPIRIT compliant tool The coreassembler tool simplifies the process of assembling a subsystem or system of components by automating the configuration and interconnection steps, providing an automated path to implementation for the entire platform, and providing a starting point for verification. The solution addresses a platform based design approach that employs standard on-chip integration architecture and a robust design reuse methodology. This is an excellent way to ensure that system components can be integrated into a subsystem in a reasonable timeframe. The basic idea is to allow the designer to rapidly generate and assemble the generic based IP s as well as ready to use IPs by using coreassembler. On top of its proprietary corekit format, coreassembler supports the SPIRIT IP packaging standard and a path to implementation in silicon for SPIRIT-compliant IP in addition to system-level integration and verification. By providing production support for SPIRIT, coreassembler now enables designers to more rapidly integrate the broad portfolio of any kind of IPs compliant with the SPIRIT standard. coreassembler is proven to reduce SoC design time by automating much of the work needed to integrate IP blocks into a SoC. It also reduces design risk by ensuring that the IP is correctly connected and configured. Using coreassembler, designers can more rapidly and reliably integrate configurable IP subsystems, platforms and system-on-chip (SoC) designs. The following SPIRIT-related features are supported in coreassembler: Import SPIRIT components into coreassembler. SPIRIT components are installed and connected using the same process as packaged components. Generate static hierarchical SPIRIT components from coreassembler. Create a hierarchical component modeling the subsystem. This provides a crude netlist (connections at interface level only) and indicates exported pins. Also generates a

7 SPIRIT component as a separate file for each of the component in the subsystem to accompany the hierarchical component description. Generate a static SPIRIT design from coreassembler. Create design element showing instantiated components and their connections. Import a SPIRIT design into coreassembler. Translate a SPIRIT design element into the corresponding coreassembler subsystem. Instantiate all components, make defined interface connections, and preserve any unused data for future export. Import synthesis constraints from the component description, and also write them out to any component description when writing SPIRIT components. Run generators explicitly within coreassembler. These are typically system level generators used in the validation process but can do almost anything. Currently loaded generators are available via the Generators menu. In addition to enhancing coreassembler, Synopsys has also added SPIRIT support to its corebuilder IP packaging tool. corebuilder enables designers to package IP and then automatically generate the SPIRIT XML that describes the IP for use with IP integration tools like coreassembler [3]. 3 Design and SDC assembly flow for the STM nm Set-Top-Box chip STMicroelectronics STM7200 System-on-Chip is targeting the high-end set top box market. This 65nm chip features dual HD MPEG4 decode, audio decoding, HDD and DDR2 interfaces as well as an extensive set of communication channels (Sata, Ethernet ). It is composed of complex functional subsystems that communicate through an on-chip-bus, the STBus. Each subsystem is made of several IPs and DSPs, for a total of more than 70 components including 30 custom RTL blocks. The pad ring is done upfront and includes several interfaces. The estimated synthesized gate count is 24 million, and the circuit embeds 6 Mbits of static RAM spread into various memory cuts. A functional diagram of the STM7200 is shown below.

8 HDMI Out HD Digital HD Analog SD Analog Video Out Video Out Video Out DDR2 SDRAM (x2) SD Digital Video Input Dual MPEG4 decoder Digital / Analog Video out PCM S/PDIF Out x2 Audio In PCM Out Analog Out x2 Audio decoder Peripherals Flash SFlash MPX LMI 32 bit STbus InterConnect Transport Application processor Communication block TP In (x2) TP In/1394 Out Ethernet I/F Peripherals SATA1 I/F USB2 I/F Figure 2 : STMicroelectronics STM700 SoC overview The number and complexity of IPs to be connected together through the STBus on this chip makes it a good candidate for the SPIRIT based assembly flow described earlier in this paper. Unfortunately SPIRIT metadata not being available for the STM7200 IPs, so the first step is to generate such views from standard ST IP package. The coreassembler tool is then used to assemble IPs, Subsystems and Bus to build a complete SPIRIT database of the chip. Although the standard out of the box coreassembler SPIRIT flow is used for the assembly itself, new features have been added thanks to custom plug-ins to integrate better in ST flow and to promote SDC from IP level to chip level. Finally the full design SPIRIT database is used to perform several tasks in the implementation, verification and software area. All these steps will be detailed out in the next sections. 3.1 Building SPIRIT metadata from standard ST IP Package There has been a lot of work in ST in the past years to define a common data structure for every internally delivered IP. However this Front-End package is not including any SPIRIT metadata yet. Consequently a set of tools has been written to extract most of the information from it.

9 The first tool extracts the signal map and the bus interface part of the SPIRIT metadata from the RTL entity of the component. Using some regular expressions, one can associate a given bus definition to a set of port. The direction and the size of each signal are compared to the XML bus definition, and the tool checks that at least all the mandatory signals of this interface are present. Once successful, the bus interface instance is created in the XML component. Full RTL views and available TLM model can also be added to the XML component. Using another tool, the memory map and the address space information is translated from the FrameMaker document holding the IP specification and written back to the XML component. The bus interfaces can also be read from the specification document, allowing getting a usable black-box XML component even before any RTL is available. Additionally those tools have been automated and integrated into the design datamanagement environment to help doing quick updates in case of specification changes or RTL changes. 3.2 Design assembly with Synopsys coreassembler Once all the components to be assembled together are available, the standard SPIRIT coreassembler platform assembly flow can be used. In the case of STM7200 a two step assembly has been done: first IPs are assembled into subsystem, and then subsystems and bus are assembled into the core. The assembly can be completely driven through the GUI or executed via TCL scripts, and is a succession of interdependent activities that must be fully completed before proceeding with the next one Setting up coreassembler search path for available SPIRIT views Each component is known to the system thanks to its SPIRIT metadata. Bus definition SPIRIT metadata must also be known. In the first step all the search paths containing installed corekits, SPIRIT component files and directories containing SPIRIT bus definitions are specified

10 Figure 3 : coreassembler search path window Adding subsystem components Each SPIRIT component or installed corekit is chosen from the list of available component and instantiated. The dialog shows available components and version numbers. Each component is found via the search paths initialized via the previous dialog. Multiple components can be added at one time and the default instance name is calculated automatically and is user controllable. coreassembler ensures all required interfaces are connected, runs any subsystem validation hooks, and generates subsystem report. SPIRIT design instantiation can be possibly done through read_spirit_design command or GUI menu. Figure 4 : Adding subsystem components in coreassembler Connecting together Bus Interfaces

11 The tool connects in one shot all members of a bus interface and enables correct by construction connections, ensuring that all non-ambiguous interfaces automatically connect as components are instantiated, while ambiguous connections are resolved by posting dialog query user. Some interfaces, such as the ones routinely connected outside the subsystem, can be exported automatically. coreassembler also connect easily broadcasted interface (i.e. clock, reset) thanks to a Synopsys SPIRIT patch (but that should be standard in next SPIRIT revision) Configuring and verifying components In this activity it is possible to configure the components if this is relevant and planned by the IP providers, to verify that the integration is OK using component SPIRIT metadata, to update data model, to complete pin to pin connections based on connected interfaces, and finally to complete pin to top-level port connections based on exported interfaces. Figure 5 : Configuring components in coreassembler Completing remaining connections In this activity pins that are not part of any interface must be processed. All pins must be connected, explicitly tied off (inputs), or explicitly marked open (outputs); connections can be direct or inverted; core integrators can filter out pins with default connection defined to hide the pins that will be processed automatically; they can select sources and/or loads and

12 then press the appropriate connection button; partial connections (bit sub-range) are also supported; At the end an activity report documents all automatic and manual connections. Figure 6 : Completing connections in coreassembler Generating Subsystem RTL views Here the tool generates consistent data resulting of the assembly: documented RTL code (VHDL and/or Verilog) including a customizable header SPIRIT Design XML view SPIRIT Component XML view to be used for the next level assembly Parameter files (C, VHDL, Verilog) Sample instances (VHDL, Verilog) Propagated synthesis constraints HTML documentation The number and accuracy of generated data obviously depends on what is available in each component CoreKit of SPIRIT XML.

13 Figure 7 : Subsystem report and generated files Using TCL scripting to enable quick updates Everything, previously described via the GUI, can be replayed through TCL scripts in either an interactive or batch mode. This has two advantages: first the scripts can be documented accurately and shortly; then the assembly can be quickly modified and replayed in batch mode. Next figure shows a typical coreassembler script covering all the steps described earlier. ## Setting up Search Path for Components and bus definition set_activity_parameter AddSubsystemComponents SearchPath "\ ${::env(iplib)}/ip1/spirit_db/v4_0/\ ${::env(iplib)}/ip2/spirit_db/v3_0/\ " set_activity_parameter AddSubsystemComponents BusDefnSearchPath \ "$::env(busdeflib)/xml/busdef/st/" ## Adding Subsystems Components instantiate_component ip1 -name inst_ip1 instantiate_component ip2 -name inst_ip2 ## Connecting Bus Interfaces export_interface -name TOPINTERFACE \ -component inst_ip2 \ -interface INTERFACE1 connect_interface -from_component inst_ip1 \ -from_interface INTERFACE1 \

14 -to_component inst_ip2 \ -to_interface INTERFACE2 autocomplete_activity AddSubsystemComponents ## Configuring and verifying Components set_configuration_parameter -component inst_ip2 \ packagename ip2_pack autocomplete_activity ConfigureComponents ## Completing Remaining Connections export_pin -port tst_reset_mux inst_ip2/tst_reset_mux create_connection {inst_ip2/my_output \ inst_ip1/my_input} create_connection -constant open inst_ip2/status autocomplete_activity CompleteConnections ## Generating Subsystem RTL and SPIRIT Views set_activity_parameter GenerateSubsystemRTL LanguageChoice VHDL autocomplete_activity GenerateSubsystemRTL write_spirit_component -file "subsys_component.xml" write_spirit_design -file "subsys_design.xml" Figure 8 : Standard coreassembler script to assemble IPs 3.3 Extending coreassembler using plug-ins coreassembler is highly customizable and can be extended using plug-ins to either perform additional tasks or modify the tool behavior. This has been used to handle a frozen core entity coming from the pad ring design tool, to add SDC promotion capabilities to coreassembler, and to dump out results according to standard ST data structures Top down frozen entity support The top-level of the 7200 chip is composed of two parts: the pad ring and the core. This toplevel is not designed using coreassembler but is automatically generated by the ST pad ring design tool. This tool is producing an empty Verilog module of the core, and the bottom-up assembly of the design must match this core entity. This ensures that the pad ring design and the core design are in sync. The goal of the frozen entity plug-in is to mix a top-down definition of the I/O ports with the usual bottom-up coreassembler design assembly approach. Depending if there are bus interfaces to be exported at chip-level or not, the plug-in can either parse the empty Verilog module of the core or a derived SPIRIT XML component containing in addition the bus interfaces. All the I/O ports are then created during a specific activity which has to be completed before all the standard coreassembler activities. If the XML has been used, the plug-in is able to group together all the ports that are part of the same interface to create an unconnected exported interface. Therefore all the exported

15 interfaces are visible when entering the Add Subsystems Components activity. Exported interfaces have then to be connected to the right component interface. Later on, during the Complete Connections activity, remaining unconnected ports need to be connected to the right component port. If only the empty Verilog module has been used to create the ports upfront, then all the ports have to be connected during this activity. Thanks to this plug-in the entity of the core generated by coreassembler matches by construction the one generated from the pad ring tool Bottom-up SDC promotion Another enhancement added to the standard flow, via a plugin, is the process of SDC promotion that up till now was done manually at the different level of hierarchy, from the botto all the way to the top-level. This process is error prone, including mistakes such as missing clock definitions or input/output delays not defined relatively to the right clock domain, etc. As a result the SDC qualification process is taking several weeks, sometimes months. Taking benefit from IP platform assembly flow within coreassembler, SDC promotion is much less error prone in the sense that physical clock sources, relationship between ports and clock domains for input/output delays definitions, are now coming directly from connectivity information. This process speeds up the constraints promotion, but also ensures a first level of quality SDC and reduces the qualification process effort. However, because connectivity data may lead to inconsistent information, there is a need to give some extra inputs to perform automatic SDC promotion. A typical example is a connection at top-level between two IPs clocks ports having different frequencies. All decisions in such case of conflicting information should remain under designer s responsibility. That is why skeleton SDC and mapping files entries have been added to the flow. The content of those files will be described later in this paper Plug in overview The SDC promotion plug-in developed for coreassembler allows automatically generate the SDC file of a subsystem by promoting the SDC information of every instantiated component. Promotion is performed by completing two custom activities in coreassembler: ReadSubsystemSDC and GenerateSubsystemSDC. Moreover, this plug-in has a special feature allowing constraints propagation from the core level to the top level including the pad ring instance: this special propagation is performed using information provided through a file generated by the ST pad ring tool, describing how the core I/Os are connected to the pad ring ReadSubsystemSDC activity

16 During this activity the designer has to specify a directory containing all the SDC files of the components instantiated in the subsystem. A preliminary syntax checking is executed in order to legalize the SDC files; then the SDC files are read into coreassembler data model. Figure 9 : ReadSubsystemSDC plug-in activity At this point all clocks are elaborated and propagated. The propagation is performed using the available connectivity information inside the subsystem since the Complete Connections activity has been performed before. The clocks are grouped in the following categories depending on their related physical driver: Clocks propagated at the top of the subsystem Clocks propagated inside the subsystem (generated clocks) Clocks defined on bit of a bus Clocks feedthrough inside the subsystem This information is then used by the next activity of the plug-in GenerateSubsystemSDC activity During this activity the plug-in propagates the constraints loaded during the ReadSubsystemSDC step. However, in order to allow the integrator to specify constraints that cannot be automatically propagated through a bottom-up approach, additional information are read from two additional files: Skeleton SDC file: this is an SDC file in which the integrator specifies intended clock definition at subsystem, and timing exceptions between two or more clocks. Actually only the core integrator is aware of the functionality of the subsystem and can take appropriate decisions; for instance about the frequency of clocks connected to several IPs having originally different period and/or waveform, or about conflicting timing exceptions between different clocks domains. Through this approach, the core integrator has still full control over clock naming and definition. However, the plug-in

17 also performs a check to ensure that there is not any missing clock definition, reducing the integrator risk of error. Mapping file: it helps the mapping of IP virtual clocks to assembly virtual clocks in cases the plug-in is not able to guess this information. Additionally this file can provide internal connectivity information if the IPs are described as black-box. The promotion can also be run without any extra information. In this case clock information will sometimes be arbitrarily chosen by the tool. It can be a good starting point for understanding the subsystem, but still it is recommended, and in some cases mandatory, to write a dedicated skeleton file. The result of the promotion will be one SDC file for the entire assembly (subsystem or core) Core to Top SDC promotion As described earlier, the pad ring is generated by a specific ST tool, and not by coreassembler, however the SDC promotion plug-in via an optional feature allows the constraints promotion to the top level of the chip. When this feature is activated, the plug-in will generate at the same time a full core SDC, and the top level SDC of the chip. To make the plug-in properly working a pad ring mapping file has to be provided on top of the skeleton and mapping file. This new file is provided by the ST pad ring tool and will show, for any pad cell, the connectivity pin-to-pin for the pad pins connected to the core, and the pad pins representing pad terminals towards the outside world. Core and pad ring instance name have also to be provided to the plug in, as well as default values for input transition and load capacitance to be applied on pad terminals. The next figure is showing the GenerateSubsystemSDC window including the optional entries for core SDC to top SDC promotion.

18 Figure 10 : GenerateSubsystemSDC plug-in activity SDC promotion example As an example of what the plug-in is able to do, the next figure shows a simple subsystem made of two IPs. Subsyste datain in1 IP1 out1 in2 IP2 ckto cki in out ckou ck ck out2 dataout ckdiv Figure 11 : A simple subsystem with 2 IPs

19 IP1 receives data through in1 on its main clock ckin, and emits data through out1 from one internally divided clock derived from ckin. This divided clock is also available through the ckout port. The content of IP1.sdc is shown below. For the sake of simplicity clock latencies, clock waveforms, clock transitions and clock uncertainties have been omitted in all SDC examples, as well as driving cells and external loads. ## main clock on ckin and it associated virtual clock create_clock -name "ckin_name" -period 6 [get_ports ckin] create_clock -name "ckin_name_io" -period 6 ## internal clock and it associated virtual clock create_generated_clock -name "ckout_name" -source [get_ports ckin] \ -divide_by 2 [get_pins {ckdiv/out}] create_clock -name "ckout_name_io" -period 12 ## i/o delays vs virtual clocks for in1 and out1 set_input_delay clock ckin_name_io 3 [get_ports in1] set_output_delay clock ckout_name_io 3 [get_ports out1] ## timing exceptions to an internal register set_false_path from [get_clocks ckin_name] to myinst/d Figure 12 : IP1.sdc IP2 receives data through in1 on its main clock ck1, and emits data through out2 from another main clock ck2. The content of IP2.sdc is shown below. ## first clock and its associated virtual clock create_clock -name "ck1_name" -period 12 [get_ports ck1] create_clock -name "ck1_name_io" -period 12 ## second clock and its associated virtual clock create_clock -name "ck2_name" -period 5 [get_ports ck2] create_clock -name "ck2_name_io" -period 5 ## i/o delays vs virtual clocks for in2 and out2 set_input_delay clock clkin1_name_io 5 [get_ports in2] set_output_delay clock clkin2_name_io 4 [get_ports out2] Figure 13 : IP2.sdc At the subsystem level, there will be two clocks: a main one attached to the subsystem cktop port, but still the clock generated within IP1 will be present. By using the skeleton file it is mandatory to create the clocks, defining their name and characteristics. In the example below cktop period is set to 6 while it drives the ckin port of IP1 where the clock period is originally 6, but also the ck2 port of IP2 where the clock period is originally 5. The skeleton file is shown below. ## main clock and it associated virtual clock create_clock -name "cktop_name" -period 6 [get_ports {cktop}] create_clock -name "cktop_name_io" -period 6

20 ## internal clock and it associated virtual clock create_generated_clock -name "ckgen_name" -source [get_ports {cktop}] \ -divide_by 2 [get_pins {IP1/ckdiv/out}] create_clock -name "ckgen_name_io" period 12 Figure 14 : skeleton.sdc Skeleton information is also used to check that clock information is complete. For instance, by looking at the subsystem connectivity the plug-in knows that there should be a clock defined on cktop as this port is driving IP ports where a clock is defined according to their original SDCs. For internally generated clocks, since coreassembler in this methodology is only dealing with black-box views of the IPs, skeleton information is not sufficient. For instance it is needed to tell the plug-in that there is a direct connection between the internal ckdiv/out pin of IP1 and its ckout port. Without this information the plug-in will ask for a clock to be created on ckout port of IP1 when propagating the ck1 clock of IP2. This information will be carried in the mapping file as shown below. ## Inform about connection between block1/clk and clkout in IP1 IP1 ckdiv/out ckout con Figure 15 : mapping file Through the mapping file it is also possible to map IP virtual clock name with subsystem virtual clocks. However if the association between a real clock and its virtual clock is respecting some naming conventions (like here a _IO suffix) then the plug-in will guess the new virtual clock name automatically. Starting from all these information and looking at the connectivity, the plug-in will be able to promote accurately the constraints, taking care of clock name changes in every exceptions and promoted I/O delays. The resulting subsystem.sdc is shown below. ## main clock and it associated virtual clock create_clock -name "cktop_name" -period 6 [get_ports {cktop}] create_clock -name "cktop_name_io" -period 6 ## internal clock and it associated virtual clock create_generated_clock -name "ckgen_name" -source [get_ports {cktop}] \ -divide_by 2 [get_pins {IP1/ckdiv/out}] create_clock -name "ckgen_name_io" period 12 ## i/o delays on datain and dataout, inherited from IP1/in1 and IP2/in2 set_input_delay clock cktop_name_io 3 [get_ports datain] set_output_delay clock cktop_name_io 4 [get_ports dataout] ## timing exceptions to an IP1 internal register set_false_path from [get_clocks cktop_name] to IP1/myinst/D Figure 16 : subsystem.sdc

21 SDC promotion applied to STM7200 Every STM7200 subsystem is composed of 5 to 20 IPs, for an average of about 11 IPs per subsystem. IP SDC files size range from 50Kb to 12MB, for an average of about 1Mb per IP. The promotion has been successfully completed for all subsystems, with an average run-time of half an hour per subsystem. Resulting SDC files sizes range from 200Kb to 20.5Mb for the biggest one. At core level the SDC promotion plug-in has been run taking as input the SDC files generated during the subsystem level promotion. The full generated SDC file for core level and top level were generated together with a run-time of 16h and have both a size of 27Mb. This plug-in has brought major productivity improvement in building the full chip level SDC file, thus getting quicker to physical design and timing verification Building ST data structure out of the assembly To integrate smoothly coreassembler generated data in the design flow, it is important to organize it following the standard ST Front-end package as is the way of delivering a soft or a firm IP inside ST. When it is describing a subsystem, a Front-end package should contain at least RTL code of the assembly, SDC constraints, and the generated SPIRIT data. Thanks to Synopsys Professional Services, a plug-in has then been developed with two goals: generate the files of the Front-end package which are not natively created by coreassembler organize all the data to conform with the Front-end package data structure Moreover the plug-in is able to perform some level of verification on the generated data to ensure package quality. For instance, in addition to the creation of the Front-end package structure, the plug-in also runs Formality in order to verify that the VHDL and Verilog files contained in the Front-end package are equivalent. Although coreassembler has a sufficient knowledge to create a complete Front-end package, it is sometimes simpler to provide it with additional information. Therefore, when the content of some files cannot be easily generated by the plug-in, the choice has been made to use some activity parameters to pass additional information to the plug-in. These activity parameters are shown on the snapshot below.

22 Figure 17 : Front-End package plug-in parameters Here is an overview of the files collected or generated by the plug-in: <subsystem_name>.implementation.sdc: This file contains the SDC constraints of the subsystem. This is the SDC file generated by the SDC plug-in. <subsystem_name>_ent.vhd and <subsystem_name>_arch.vhd: Those files contain the VHDL entity and the VHDL architecture of the subsystem and are natively generated by coreassembler. <subsystem_name>_arch_dummy.vhd: This is a dummy VHDL architecture to be used for simulation purposes. In this dummy architecture, all outputs are tied to their default values. By default, the default value is assumed to be zero but a parameter of the plug-in allows to specify the list of outputs with a default value at one. Moreover, on specific signals like clocks or resets, it is possible (thanks to some other parameters of the plug-in) to apply a square waveform or a pulse instead of tying them to a constant value. This file is totally created by the plug-in. <subsystem_name>_arch_empty.vhd: This is an empty VHDL architecture. It is created by the plug-in from the <subsystem_name>_arch.vhd file.

23 <subsystem_name>_pack.vhd: This is a VHDL package with the declaration of the subsystem component. This is a copy of a file generated by coreassembler. <subsystem_name>.v: The Verilog netlist of the subsystem. This is not a direct copy of the Verilog file generated by coreassembler because this latter contains 'assign' statements which have to be removed. To achieve that the plug-in runs DesignCompiler to read the original Verilog file and write it back without those unwanted statements. This operation is completely transparent to the designer and occurs at the generation of the Verilog netlist by coreassembler. sc_<subsystem_name>.tcl and sc_<subsystem_name>_searchpath.tcl: These are the coreassembler batch scripts that allow to replay the assembly. Depending on a parameter of the plug-in, they are either created by coreassembler during the execution of the plug-in or copied from the designer own scripts. <subsystem_name>.xml and <subsystem_name>_design.xml: These are the SPIRIT XML component and SPIRIT XML design of the subsystem. They are natively created by coreassembler Other files like ReleaseNote and dependencies information are also generated by the plug-in. After this plug-in is completed, the generated Front-End package can be released and used in the design flow as any other component coreassembler flow improvement More work continues taking place in order to further improve the flow. In the upcoming releases among all the other improvements will be added: Support for SPIRIT version 1.2, 1.3 & 2.0 Full support for reading hierarchical components Automatic generation of SPIRIT directory o Written automatically after Generate Subsystem RTL full hierarchical output including source code references o Hierarchy represented in SPIRIT component files and via directory structure of generated files Specifying workspace type (either implementation or verification ) Improved hierarchy support Improved SDC built-in promotion features Ability to define memory map as part of corebuilder packaging process and export it automatically to SPIRIT component to be used for future verification work Synthesis Replay Log to simplify test case creation process Automatic creation of script to recreate a netlist, completely independent of coretools environment, as it is today Glue logic insertion

24 3.4 Using generated database in chip verification and physical design Thanks to the Front-End package organization, all the coreassembler generated data including the SPIRIT views and the assembly scripts are available in the STM7200 design database. Apart from all the SPIRIT tasks described earlier, the following tasks can then be performed: Full RTL simulation using RTL code for the IP and coreassembler generated VHDL for all the subsystems and the core ; A full gate netlist for physical design is available by concatenating all the IP netlist and the coreassembler generated Verilog for all the subsystem and the core. In case of IP change or chip specifications changes, the full assembly can be replayed within a week. 4 Conclusion Usage of SPIRIT for SoC assembly has many advantages in the system-level design by enabling quick system prototyping from system specification. Moreover SPIRIT metadata are helping in the automation of IP verification. STM7200 experience has also shown that it is efficient for the design capture. With SPIRIT, all these areas are addressed from the same database, hence helping to prevent misalignments. Finally, as it is a standard, several commercial tools can be used, and internally developed scripts and tools can be reused. Synopsys coreassembler has proven its efficiency in supporting SPIRIT standard, but also by integrating innovative techniques like the automatic SDC promotion. Now that a database of SPIRIT IPs is available inside STMicroelectronics, most of the effort done for the STM7200 flow can be reused for upcoming chips. Furthermore, many internal and external IP providers will now deliver SPIRIT views natively, reducing the effort of producing the view in the design team. 5 Acknowledgements Achievement of the results described in this paper has been possible due to the fruitful cooperation between the STMicroelectronics team and Synopsys Professional Services division. References [1] SPIRIT Consortium, SPIRIT 1.1 Specification, June 2005 [2] Industrially Proving the SPIRIT Consortium Specifications for Design Chain Integration, DATE 2006 Special Session paper, March 2006 [3] Synopsys' coreassembler Reduces Time and IP Integration Risk for Spirit-Compliant IP, [4] coreassembler user guide

25