An Engineer’s Journey to Finding Her Way to IP-XACT

 

A Brief History of a System’s Engineer Struggle for Synchronization of Data

I am a Systems Engineer in search for ways to make a complex System On a Chip (SoC) and embedded firmware work together.  The chip industry is making great strides in process technology – thus leading to more complex chips to put in the new silicon.  In roughly 18 month intervals, it has gone from 180nm to 130nm to 90nm to current 65nm process node and Intel is now is in its first production at 45 nanometer[1].  That’s a lot of RTL and embedded firmware to write and creates larger teams that need synchronized communication.  I’ve frequently been called a “bridge-person” because I am involved in all aspects of the design: Architecture of the ASIC, Architecture of the System Firmware, Verification Lead, and RDK/SDK bring up.  I am moved around from group to group depending on what state the chip is being developed or tested.  What I’ve wanted is a mechanical clone of me.  I think that IP-XACT is the answer to my problem – a system oriented “bridge”.

 

How to Represent SoC Information Common to Different Organizations Within a Company?

For years we struggled at Creative LABS, ATC for ways to share register information and memory maps amongst the groups that needed them.  We looked at defining the information in Perl, in C++, in HTML, CSV, and many other document types.  What we finally came up with was XML.  Why did we pick XML?   It is a perfect way to describe data.  It is easy to use, has many free editors, and has the capability of validating the data with schemas.  An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntax constraints imposed by XML itself. An XML schema provides a view of the document type at a relatively high level of abstraction[2].  An XML parser also provides a way of making sure the data is well-formed.  A well-formed document will have start node and stop node for each < /> pair.  It also allows for complex tree like structures.  Look how easy it is to describe a register (this doesn’t have a schema):

<CHIP>

<BLOCK>

<NAME>MEMORY</NAME>

                …

                                <MODULE>

                                                <NAME>DMA</NAME>

                                                <ADDRESS>0xFC00_0000</ADDRESS>

                                                ….

                                                <REGISTER>

                                                                <OFFSET>0x0</OFFSET>

                                                                <FIELD>

                                                                                <NAME>Reserved<NAME>

                                                                                <BITS>31:9</BITS>

                                                                                …..

                                                                </FIELD>

                                                                <FIELD>

                                                                                <NAME>MODE</NAME>

                                                                                <BITS>8:0</BITS>

                                                                </FIELD>

                                                </REGISTER>

                                </MODULE>

                </BLOCK>

</CHIP>

                                                               

                       

One Engineer’s Solution- Single Point Source

This section describes a tool that I created, Single Point Source Tool. This is a subset of what the consortium is creating (the entire chip).  I am describing it here because it’s been proven to work really well for my customers and I think it’s important for Spirit Consortium to see a proven path with XML.

 

 The SPS Tool uses a single point of definition and description of registers to be used within an ASIC/SoC and produces multiple output files which will be used in various ways, such as the creation of Register Transfer Language (RTL), embedded firmware, documentation, and validation software.  The purpose of having a Single Point Source file is to create an environment where one single input defines the registers in a system and multiple outputs are created.  This forces a system where the outputs dependant on a register change will be updated and synchronized appropriately.  The outputs created are for a range of customers within the company and reduces “out-of-date” errors and miscommunication across the entire product base of developers (ASIC team) and users (the software team, board engineers) of the ASIC. 

 

This document defines the Single Point Source XML tags that have been created for the definition of the ASIC hierarchy for defining registers.  The XML input file to the SPS tool is the only source that defines the registers/bit fields/ enums and descriptions. This is the ‘Single Point Source’.  The tool produces multiple outputs used to create products, document, etc.  These files are auto-generated by the tool and should not be modified by

Single Point Source Customers:

 

IP-XACT and SoC Development

Since I have already jumped on the XML to many outputs bandwagon, I decided to look at the Spirit Consortium’s definitions for creating a SoC. What I’ve found is really what I’ve been looking for the entire chip – not just the registers that SPS creates.  What the consortium has created is very easy to read set of schemas to define the whole chip.  With a little over 20 schemas, it’s not very hard to read and understand how to create the xml needed for a specific type of data.  They way the parts are divided, allows different users to change information related to what they are doing.  For instance, a System Architect could make a first draft only touching some of the XML modules at the top level (designConfig.xsd).  ASIC, Verification, and Embedded Software Engineers would go in and make the modifications that they need.  Simulation, code verification and co-simulation would be performed on the design produced from the xml. Modification would be made based on bugs, new features needed (for instance additional Interrupt Request –IRQ bit for a module).  These examples use schemas that are changing.  The consortium has not finalized the IP-XACT schemas yet – so these are subject to change.

Diagram 1 below shows this flow using IP-XACT:

 

In this case, the Board Engineers and the ASIC engineers might work on the chip_pins.xml using the ports.xsd schema file together for the chip pin outs.

For a given module (timer.xml), the ASIC engineer for the Timer Module will work using the using the signalDrivers.xsd XML file and ports.xsd schemas.  The software engineer might work on the programmable Registers using the memoryMap.xsd schema An ASIC Engineer, System Architect, and Sofware Engineer might work on the chip_memory_map.xml xsd XML file.  The Software Engineer designing the linker map would work on the file.xsd XML file.

 

Simple IP-XACT Example

This is a simple subset of a timer.  Usually the file is arranged in the following manner:

 

Sample XML

        <spirit:portMap>

                  <spirit:portName>

                              <spirit:componentPortName>psel</spirit:componentPortName>

                              <spirit:busPortName>PSELx</spirit:busPortName>

                  </spirit:portName>

 

                  <spirit:portName>

 <spirit:componentPortName>penable</spirit:componentPortName>

                              <spirit:busPortName>PENABLE</spirit:busPortName>

                  </spirit:portName>

                    <!—more ports -->

      </spirit:portMap>

 

 

The Impact IP-XACT Has on SoC Development

You are probably wondering: 1)”What impact does this have on me?” or 2)”Oh, Please another scripting language of the day.”  Well, think of it this way:  This will increase productivity because all groups involved in making a SoC product are in the architecture phase early on.  IP-XACT offers a level of abstraction that makes understanding the nature/flow of the ASIC and how to program it much easier.  XML is the best way of describing lot of information and validating that it well-formed.  It is very easy to read and change.  It also enforces a “discipline” of defining information in a meaningful manner that makes different XML writers have similar style.  This is one of the biggest headaches in engineering, when the hand written code (RTL, C, C++, etc) has different styles based on the engineer.  The biggest impact will be the money saved on chip turns and late schedules and that is what will drive companies to adopt IP-XACT.

 

This was written by Lisa K. Barbay, as System Architect/Verification/Embedded Engineer for 20 years at Seagate, Sierra Imaging, and Creative ATC.  She currently owns Barbay Consulting and sells Single Point Source, an XML register description tool (a subset of IP-XACT).  She is working on a more detailed article, Architecting Complex SoCs with IP-XACT.

 

 


[1] Gabe Morretti

[2] Wikipedia