Assisted Creation and Refinement of Transactional Level Specifications Based on IP-XACT

High abstraction levels, design automation and reuse are currently the three main axes to solve the productivity gap issue. The new Spirit consortium’s IP-XACT v1.4 standard provides normalized file formats to describe transactional and RTL (Register Transfer Level) components. Since information on connecting and configuring designs is given, the combination of reuse and ESL is now enabled. This paper describes a high level platform prototype based on IP-XACT. It supports SystemC models and simulations; and also provides a set of tools for fast design generation and simple user experience. The platform has been successfully implemented and used to generate a system including a processor in an FPGA.

1. Introduction

In electronic design, the pressure of Moore’s law and time-to-market challenge has lead to a great need of productivity in the system-on-chip industry. The difference between the increase of chip complexity and the growth of productity is often referred as the productivity gap. Because of it, the design cost of system on chips is constantly increasing. To solve that issue, several responses have emerged.

First, Electronic System Level (ESL) [1] focuses on high levels of abstraction. A model of the system can be simulated in the early stages of the design flow, even before hardware-software partitioning. That approach has several advantages. First, it helps to create executable functional specification. Then fast architecture exploration can be done, including hardware/software partitioning. Finally, high-level models can be also used for verification of RTL components [2, 3].

Secondly, productivity can be increased thanks to component reuse, which avoids reinventing the wheel for every system, using reliable modules.

Most reuse efforts focus on standard interface definitions. At high levels, OSCI (Open SytemC Initiative) TLM-2.0 (Transaction Level Modeling) defines a SystemC standard for transactional modeling. At low-level, wrapper libraries (for instance OCP — Open Core Protocol [4]) allow the user to create bus interface neutral cores, which can be connected to buses using adapters. With those standards one can create components once for all, using adapters when necessary. However, managing large libraries of components inevitably needs to support multiple types of interfaces. Therefore, a standard format that documents component interfaces is necessary. That is precisely one of the goals of Spirit consortium’s IP-XACT [5]. It supports ESL components, including transactional ports since its latest 1.4 version.

Finally, it is essential to provide tools that help architecture engineers to modify and refine their system simply and rapidly. Indeed, modifying a design inevitably includes a part of tedious work. Automating that work wherever it is possible would improve usability of high-level modeling, fostering its adoption.

This paper proposes principles and an implementation of a platform that combines those three features. It manages a library of high-level components, which can be used to build the first model. Then at each refinement step, library components are replaced by more accurate modules, down to a physical implementation. At every level, the user has access to tools to edit the model in a very simple manner, without worrying about implementation details.

High abstractions levels are enabled by supporting functional descriptions and transactional ports, as SystemC [6] does. IP-XACT files store information on how to parameter and connect components. More precisely, we use four of the seven XML (Exetensible Markup Language) file types defined by the standard:

• A bus definition contains general information on an interface type, such as whether it is addressable or direct (in this case, direct master-slave connections are allowed).

• Abstraction definitions describe the ports used to implement a bus interface at a given abstraction level.

• A component has bus interfaces, ports and parameters. Bus interfaces on a component are defined by their abstraction definition and the interface type (e.g. master or slave).

• A design describes a set of instances of components. Values are given to their parameters, and connections are defined, whether they connect simple ports (ad hoc connections) or whole bus interfaces (interconnections).

Without excluding other technologies, the program benefits from Space platform [7]. Indeed, it provides all the features required by this application. A library of SystemC modules at various abstraction levels is available. Modules at the lowest levels can be mapped to hardware cores. Additionally, Space supports software implementation of application modules.

This paper has the following structure: Section 2 presents how and why IP-XACT needs to be extended to create the platform. Then, Section 3 gives an overview of the most important helper tools, and examples of such extensions. Section 4 details which information is needed to generate implementations on Field Programmable Gate Array (FPGA) boards, and finally Section 5 shows an example of use of the platform. Section 6 presents the conclusion.

2. IP-XACT as basis

2.1. Vendor extensions

Tools we developed all need some specific information which is missing in common IP-XACT files. Fortunately, the standard defines special sections of files called vendor extensions. While the rest of documents must respect a strict syntax specified by an XML schema, vendor extensions can contain any information.

To be able to validate input files, we have defined an XML schema for extensions we added. Other IPXACT compliant programs will simply ignore them, so interoperability is not reduced. Reciprocally, our extensions are not mandatory, so any IP-XACT valid file can be processed by our platform. However, some tools will not work if their extensions are missing.

Sections 3 and 4 show the main vendor extensions used by the platform.

2.2. Generators

Some components may need to be managed in a particular manner. For instance, a component may need to import the value of a parameter from an other component; the files used to build software must be generated depending on the processor type; etc. To support those special cases, components may refer to generators. They are executable programs called by the design environment, able to interact with the current design.

IP-XACT defines a communication interface between the design environment and generators: the Tight Generator Interface (TGI). It is a set of functions implemented by the design environment and called by generators. The communication is made according to the SOAP standard [8]. The latter, mostly known in the context of web services, defines XML-based message passing used for remote procedure calls in heterogeneous environments. Since the interface is completely neutral, generators using the TGI do not depend on design environment implementation. As well as the description file format, the TGI may appear insufficient in some situations, so it has also been extended.

Since the platform is implemented in Java, it can invoke Java methods of generators, giving reference to objects it uses. Therefore, they have a broad access to the platform’s inner behavior. Such generators are located in JAR files in the component library, keeping them in the outside of the platform. The major drawback is that independence of generators with design environment is lost. That is why that type of generator should be used only when the TGI cannot realize the required functionality. There are two types of such situations:

1) Some generators require access to special, nonstandard information. In particular, processor generators are responsible for creating files to compile its software (detailed in Section 3.2). And they must also generate appropriate connections to implement point-to-point links (detailed in Section 3.3) involving components it executes.

2) The need to define several roles for generators, such that of them is called at a specific moment. Five types have been defined: User component generators create IP-XACT descriptions of user components, with possibly source file stubs. Postinstantiation generators are called just after an instance of a component has been added to a design. They are mostly used to operate dynamic changes, using the listener design pattern to obtain instant reaction to user operations. Pre-transformation generators are able to select which type of component must replace a component in a refinement process, whereas post-transformation generators are called just after a refinement. They can modify the new design model from characteristics of the original one (cf. Section 3.4). At last, normal generators are called during the generation step, as defined in the IP-XACT standard. This is the default type. Standard IP-XACT generators (using the TGI) are run at this moment.

Just like vendor extensions, non-standard generators are simply ignored by third party design environments, so the component description remains usable. The difference is that the additional component features will not be enabled.

3. Necessary features

3.1. Adapter generation

As explained by Gajski and Kai [9], TLM should be implemented focusing on a separation between communication and computation concerns. Thus, adapters are needed between processing elements and communication channels, leading to a layered model (Figure 1), as described by [10, 11]. It is important to note that those adapters are just the glue to make the simulation work; designers should make abstraction of such components.


Figure 1. Layered communication model

To generate adapters in a design, the platform needs to split components in three categories: channels, adapters and functional component. The type of a component is defined in its vendor extensions, and the default is functional.

When the user asks for a connection between a functional component and a channel, the platform first checks if those components have compatible interfaces. If not, a chain of adapters from the library is built between the components. In most cases, one or two adapters are sufficient.

For instance, the need of two adapters has been encountered in the following situation: 1) using the Space environment, a module adapter converts the Space convenience interface into a common bus interface; 2) a second layer of adapters connects it to a bus model (such as OPB). A third adapter may be necessary to simulate an RTL module in a TLM environment [12].

The principles of the method are shown in Algorithm 1. Adapters have two sides: the first one has interfaces which can be connected to functional components (in IP-XACT: mirrored interfaces); and the second one can be connected to channels (direct interfaces). A chain of two adapters is connected when a mirror interface of one of them one can be connected to a direct interface of the other one.



The algorithm is based on a forest representation of potential solutions, in which nodes are adapters. Node C is a child of parent P if a mirrored interface of C can be connected to a direct interface of P. Root nodes are adapters connectable to the functional components. The goal is to find nodes which can be connected to the channel. Therefore, the path from that node to the root represents the adapter chain.

Line 2 initializes the first layer of adapters. If one of those leaves can be connected to the final component, it is returned (line 7). Otherwise, for every leaf in the tree, we look for adapters that can be connected to the one stored in it. Those adapters become the leaf’s children.

The actual implementation prunes the tree when no adapter is found on line 9 to simplify the following iterations. As we saw, this algorithm allows to connect a component to an other one. But with a few changes, on lines 2 and 9, they can be used to generate interface-to-interface and component-to-interface connections.

3.2. Hardware Software partitioning exploration

In an ESL design flow, hardware-software partitioning is the step in which application elements are mapped to hardware or software implementation. To explore possible partitions, component instances need to be modeled either as hardware modules or as software tasks, run by one or more processor. It is a different point of view than the IP-XACT one, in which partitioning is considered to be fully defined: the standard let only describe which executable image is run by a processor, as well as how to build it (source files, compiler and linker). Using extensions, it is possible to introduce our representation of software in description files.

First, the processor’s component file specifies which type of components it can execute. They should be base components of application modules. Second, on the design file, each processor instance lists the software component instances it executes in its vendor extensions. The syntax of their description is the standard one, normally used for hardware instances. Therefore, it is very easy to bring them back to a hardware model. The executable model run by the processor is built by its generators.

3.3. Point-to-point communication

Functional modules could require to be connected directly, for performance purposes. Point-to-point connections or FIFO (First In, First Out) connections are examples of dedicated communications links. This is particularly useful in data flow applications, in which buses can be bottlenecks. Therefore, we define a dedicated communication link as a subtype of a channel. The tool looks for such links to directly connect two components. If none are found, Algorithm 1 is used to insert the proper adapters in order to make the connection possible. Direct links can also be useful for defining hardware accelerators or coprocessors. For instance, Xilinx MicroBlaze softcore processor supports Fast Simplex Links, which are FIFOs for which control is hooked in the processor’s pipeline. Through IP-XACT generators, our methodology supports creating a link between a piece of software running on a MicroBlaze and a hardware accelerator. However, using different processors would lead to different implementations of the generators.

3.4. Refinement

In an ESL based design flow, refinement steps are part of the important milestones. To reach the goal of implementing a user-friendly environment, assistance must be provided for that operation. Basically, the principle is to replace functional components and channels by equivalent more precise models. The generated architecture is similar, and some parameter values are imported.

It is clear that a mechanism to find equivalent components is necessary. The chosen solution is adding an inheritance relationship between component classes, just like in object-oriented programming. Thus, it is possible to group components of the same type, and to define which components are equivalent. Any component can declare its base component. Parameters and bus interfaces on the base component should be present on the derived one, to let the refinement method properly import parameters and connections.

The main steps are presented in Algorithm 2. When the set of components to use has been selected, components are instantiated in the new design, parameters are imported from the original one and connections are made, possibly using adapters.




4. Toward FPGA implementation

Creating an implementation of the design on an FPGA-based board is more than a simple refinement. Indeed, several additional constraints must be considered to select appropriate equivalent components. The major ones are the availability of devices on the board and Intellectual Property (IP) cores for its FPGA.

4.1. Board description

Let us consider a board including one FPGA, and several external devices like memories, clocks, serial interfaces, etc. The goal is to generate the logic on FPGA with possible interaction with board devices. Thus, the platform needs to have information on the devices and how they are connected to the FPGA. The chosen solution is to view the board as a hierarchical component (Figure 2), in which subcomponents are devices. Hierarchical components requires two files: the component itself and its inner design. The component file describes interfaces and ports of the board. The FPGA pinout is defined in special extensions on board ports. The design file details device instances and their connections to supercomponent interfaces via hierarchical connections.

4.2. IP cores

The specific aspect of IP management is that for some of them, only compiled netlists for certain types of FPGA might be available. In this case, the list of supported FPGAs is added to the component definition file. When selecting appropriate equivalent components, the refinement algorithm will exclude incompatible components (line 2 of Algorithm 2).


Figure 2. Board representation


5. Application to a real case

5.1. Implementation technologies

For high-level modeling, the implementation is based on SystemC [6] as the system level design language. That means that components use SystemC and the platform generates SystemC files to simulate the design. As mentioned in the introduction, modules come from the library of the Space platform.

FPGA refinement generates a Xilinx Platform Studio [13] project. It uses IP cores provided by Xilinx, as well as Space components. Since Xilinx has it own description format (MPD for cores and XBD for boards), external tools have been created to build IPXACT file stubs from those files, making integration of new cores less tedious.

5.2. Design example

The platform has been tested using the case study of a land rover guiding system [7]. The purpose of this section is both validating its functionality and giving an overview of the user interface. We have followed a top-down approach, starting from an untimed model down to an FPGA implementation. All user actions are made through a console with simple commands, hiding the internal complexity.

The first step is the creation of the application processing elements, represented as user components:

That command creates the IP-XACT file corresponding to the new component, as well as SystemC file stubs. To achieve this, the design environment collaborates with the generator of the base component. The same action is repeated for every application module, then the user implements the functionality in the generated files.

After that, an empty design is created, specifying the name of the abstraction level (here Elix, a timed/untimed communication level [7]). Components can now be instantiated in it.

Automatic operations are transparently performed here. For instance, the user components have parameters corresponding to the clock period, as specified in their vendor extensions. Therefore, a new clock instance is automatically generated, and the parameter values are imported from the clock. If the clock period is changed, dependent parameters are automatically updated.

Then the connections are made. For instance:

As seen in Section 3.1, adapters are automatically added to the design and connected to the functional components and the channel. Of course, adapters instantiated in this way can benefit from the same mechanisms as in manual instantiation.

The generation of files builds source files and a makefile to be used to compile a simulation of the system. The IP-XACT file describing the current design is also created.

The refinement to the lower level (here Simtek, a cycle accurate computation model [9]) can now be executed:

By calling that command, user components—which are allowed at every transactional level—are simply copied to the new design. On the other hand, since untimed channels are not allowed in Simtek configuration, the platform looks for equivalent allowed components. The OPB bus satisfies those requirements, so it is instantiated to replace the untimed channel. Connections to the components are generated again (cf. Section 3.4); this time two layers of adapters are necessary.

Simtek is the level in the Space technology where hardware-software partitioning can be done, thus it is possible to add a MicroBlaze simulator in the design. The MicroBlaze is available in the library as a hierarchical component containing the processor itself, and other peripherals like an interrupt controller, a timer, etc. All of them are instantiated together. Since the MicroBlaze description specifies that it can execute application modules, the user components we created can be moved in the software domain. That operation is done in a single line. For instance:

Files generated for that configuration include the same than the previous one, plus files created by the MicroBlaze’s generator, to build the executable it runs.

Finally, the design is exported to an XPS project, for an FPGA implementation (Section 4). The board identifiers are given in the command line:

Components of the previous design become either by IP cores or board devices. A Digital Clock Manager (DCM) is added to generate a clock signal with the period specified in the original configuration from one provided by the board. Location of the software’s memory sections can be selected, and the linker script is generated accordingly. For this design, we chose to store instruction and data sections in an external RAM chip. Memory controllers are also automatically instantiated and connected to on-chip buses. The only manual task is implementing hardware application components in VHDL file stubs. All other files files required in a Xilinx Platform Studio project are generated, so when XPS is launched, it is ready for synthesis of the FPGA bitstream.

The system has been successfully synthesized and tested on the Xilinx multimedia development board. It uses 3763 slices (34%) of the board’s Virtex II FPGA, and it can run at a maximum frequency of 61.909MHz.

6. Conclusion

Version 1.4 of IP-XACT is a strong basis for IP description exchange, in high and low abstraction levels. However, to build a powerful and easy to use design platform, tools must be created, and those tools need additional information. Thanks to the vendor extensions mechanism, that data can be added in description files, while keeping our platform compatible with IP-XACT, whether it be for importing or exporting description files.

From that format, we have successfully developed the core of a design platform able to quickly create FPGA-based systems, following a top-down methodology. To build a complete design environment, a graphical user interface may be developed upon it.

Acknowledgments

The authors would like to acknowledge the SpaceCodesign team, in particular Benoit Pilote for his deep explanations of SpaceStudio requirements. They also want to thank NSERC for their monetary support and CMC Microsystems for their technical support.

References

[1] B. Bailey, G. E. Martin, and A. Piziali. ESL Design and Verification: A Prescription for Electronic System-Level. The Morgan Kaufmann series in systems on silicon. Morgan Kaufmann, Amsterdam, Netherlands, 2007.

[2] F. Ghenassia and A. Clouard. TLM: An overview and brief history. In F. Ghenassia, editor, Transaction Level Modeling with SystemC: TLM Concepts and Applications for Embedded Systems, chapter 1, pages 1–22. Springer, 2005.

[3] S. Abdi and D. Gajski. Model validation for mapping specification behaviors to processing elements. High-Level Design Validation and Test Workshop, 2004. Ninth IEEE International, pages 101–106, Nov. 2004.

[4] OCP International Partnership. Open Core Protocol specification version 2.2, 2006. http://www.ocpip.org/.

[5] The SPIRIT consortium. IP-XACT v1.4: A specification for XML meta-data and tool interfaces, Mar. 2008. http://www.spiritconsortium.org/tech/docs/.

[6] Open SystemC Initiative. SystemC. http://www.systemc.org/.

[7] L. Filion, M.-A. Cantin, L. Moss, E. M. Aboulhamid, and G. Bois. Space codesign: A SystemC framework for fast exploration of hardware/software systems. In Design & Verification Conference and Exhibition (DVCON’07), San Jose, CA, 2007.

[8] W3C. SOAP Version 1.2 specification, Apr. 2007. http://www.w3.org/TR/soap12.

[9] L. Cai and D. Gajski. Transaction level modeling: an overview. In CODES+ISSS ’03: Proceedings of the 1st IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis, pages 19–24, New York, NY, USA, 2003. ACM.

[10] L. Maillet-Contoz and J.-P. Strassen. TLM modeling techniques. In F. Ghenassia, editor, Transaction Level Modeling with SystemC: TLM Concepts and Applications for Embedded Systems, chapter 3, pages 57–94. Springer, 2005.

[11] A. Rose, S. Swan, J. Pierce, and J.-M. Fernandez. Transaction Level Modeling in SystemC. http://www.systemc.org/.

[12] L. Moss, M.-A. Cantin, G. Bois, and E. M. Aboulhamid. Automation of communication refinement and hardware synthesis within a system-level design methodology. Rapid System Prototyping, 2008. RSP ’08. The 19th IEEE/IFIP International Symposium on, pages 75–81, June 2008.

[13] Xilinx. Platform studio. http://www.xilinx.com/ise/embedded_design_prod/platform_studio.htm.