Important: Kactus2 3.0 is the most thorough revision since the project started. With about 80% of the code lines touched we introduced big architectural changes and a lot of new features to support the new IEEE-1685-2014 IP-XACT standard. All of this gives better IP and Design configurability and adopts the familiar SystemVerilog format for parameters and expressions. We offer a conversion tool upon request for the old IP-XACT XML documents created by previous versions of Kactus2.
All the information and any part thereof provided on this website are provided « AS IS » without warranty of any kind either expressed or implied including, without limitation, warranties of merchantability, fitness for a particular purpose or non infringement of intellectual property rights.
TUT makes no representations or warranties as to the accuracy or completeness of any materials and information incorporated thereto and contained on this website. TUT makes no representations or warranties that access to this website will be uninterrupted or error-free, that this website (the materials and/or any information incorporated thereto) will be secure and free of virus or other harmful components.
IP-XACT standardises the descriptions of IP-block and design as well as the design flow including integration and configuration information. The scope of IP-XACT covers the IP component library and HW design, and offers placeholders for settings, parameters, options and scripts needed in design automation. It does not specify any language to be used, but XML format to store the information. IP-XACT tools are used for editing and launching other tools for automated operation.
The IP-XACT Component is a central placeholder for all IP information. It defines the interface, parameters, registers/memory areas and some non-functional properties. All these apply to one or more Views that give the implementation of the IP by source code associated as FileSets. IP-XACT objects are referenced by a VLNV (Vendor,Library, Name,Version) identifier found in the XML file. For this reason the location of the IP-XACT XML file is not significant.
The IP-XACT Design is an assembly of IP-XACT component instances. The components are connected by Bus interfaces that use Bus Definitions. Each component may have parameters and default values, which can be overridden instance by instance.
IP-XACT supports infinite levels of hierarchy as depicted in the Figure below. A component is hierarchical when it includes a design, which includes instance(s) of other component(s). Any IP-XACT component should be independently re-usable at any level of design hierarchy, but it is still possible to propagate parameter values down in hierarchy.
IP-XACT helps describing many variations of the component. Parameters are used to define configurable things in many IP-XACT elements (the component itself). The component can have several implementations, each defined in Component Instantiations e.g. Verilog, VHDL and SystemC. Module parameters are implementation language specific parameters. Module and other parameters can refer to each other. A hierarchical component can have different designs defined in Design Instantiations or a design that has different configurations defined in Design Configuration Instantiations.
Views are collections of the Instantiations for some specific design purpose like high-level modeling, verification or releasing a product. We call them "mission configurations" to separate them from Instantiations that are "implementation configurations". A component can have all instantiation types, but Views tell what of them are used in each case.
IP-XACT designs can be configured in two principal ways: by different parameter values or by different Views for component instances. Each setup is stored in a Design Configuration, each of which refers to the same Design. Parameters can be propagated down in hierarchy as follows. The parameters and Module Parameters that are defined to be configurable in Component Instances are seen as Configurable Element Values (CEV) in the Design. The CEV can be set to a fixed value or to refer to other parameter e.g. at the upper hierarchy. Design Configurations are handy to define different sets of the CEVs
A simplified IP-XACT design flow is depicted in the Figure below. Generators produce top-level HDL code for synthesis and project files for collecting included HDL code from the components. Generators are often used to create HW dependent SW code, e.g. header files for the registers.
Kactus2 scope on IP-XACT
Kactus2 includes tools for all essential parts of the IP-XACT design flow. Import wizards are used to create IP-XACT models from legacy VHDL and Verilog code, and generators are used to create source code for simulation, synthesis and SW development.
Legacy HDL code import to IP-XACT (VHDL, Verilog)
Kactus2 import wizard searches for the VHDL entity and extracts the ports. Parameters are extracted from the generics, and constants found in packages. Kactus2 writes this information to the IP-XACT component XML file. The source files are referenced by the path and name in the XML file.
HDL code generation from IP-XACT (VHDL, Verilog)
Kactus2 VHDL generator creates the top entity for the IP-XACT Design that instantiates the component entities. The Component entities can also be (re)generated from the IP-XACT Component, especially if there is only the IP-XACT description without any imported HDL files.
Kactus2 is a graphical EDA toolset for designing embedded products, especially FPGA-based MP-SoCs. The toolset supports reuse, exchange, and integration of IPs, thus increasing productivity of hardware development, but potentially also assisting co-operation with software development.
You do not lock-in with Kactus2, because you own your data and can freely access it at any time. Kactus2 is based on IEEE 1685-2014 "IP-XACT" standard, which enables vendor independent integration between standard compatible tools.
Kactus2 can be fitted to current design flows. Basically there is no need to change tools for development, synthesis or verification, although the IPs will likely need changes when packing them to IP-XACT documents. The tool is able to import existing module headers from Verilog and VHDL IPs. Generators produce synthesisable code for the RTL flow.
What you can do with Kactus2
Package IPs for reuse and exchange
Import your existing IPs as IP-XACT components
Create new IP-XACT components and generate their HDL module headers
Reuse IP-XACT files from any standard compatible vendor
Reuse the IPs in your designs and connect them with wires and busses
Create HW designs with hierarchy
Create multilevel hierarchies, where a design has multiple sub-designs
Configure component instances in designs, including the sub-designs
Use generator plugins to create HDL with wiring and parameterization
Integrate HW and SW
Use memory designer to preview memory maps and address spaces in your hierarchy
Package software to IP-XACT components and map them to hardware
Generate makefiles that build executables with rules defined in IP-XACT components
What you cannot do with Kactus2
Behavioral logic: Neither Kactus2 nor IP-XACT handles module implementations
Synthesis or simulation: These require tools that are specificly created for the purpose
The bigger picture
IP-XACT enables vendor independent integration:
Exchange of data with other vendors and work groups
Integration with compatible synthesis and simulation tools
Re-use of the files in other IP-XACT tools
The source code is still usable in non-IP-XACT tools
Today we focus on improving the productivity of SoC and embedded system design. The means are language and tool agnostic metadata to support re-use and optimization of the design workflow. New ideas are brought into life in our tools that have superior usability as the first requirement.
We work on close collaboration with companies to get requirements for the research and feedback on our solutions. Please contact us if you are interested in a joint project.
Current members (Updated Apr 1 2016) are
Prof. Timo D. Hämäläinen,
Dr. Jarno Vanne,
Esko Pekkarinen, Sakari Lahti, Janne Virtanen, Panu Sjövall, Arto Oinonen. Alumni are Dr. Erno Salminen, Dr. Kimmo Kuusilinna, Dr. Pasi Kolinummi, Dr. Tero Kangas, Dr. Panu Hämäläinen, Dr. Vesa Lahtinen, Dr. Ari Kulmala, Dr. Tero Arpinen, Dr. Petri Kukkala, Dr. Marko Hännikäinen, Lauri Matilainen, Mikko Honkonen, Timo Korpela, Joni-Matti Määttä, Antti Kamppi, Juha Arvio, Juuso Järvinen, Jussi Nieminen, Tapio Koskinen, Mikko Setälä, Kalle Holma, Timo Alho, Antti Rasmus, Janne Muhonen, Pasi Liimatainen, Ville-Veikko Jokinen, Marjo Kari, Pasi Pulkkinen, Kimmo Tikkanen, Eero Ryytty, Antti Jore, Aki Launiainen, Timo Kaikumaa, Juha Särkijärvi, Miia Viitanen, Kaisa Haapala, Tomi Sokeila.
Lauri Matilainen, Lasse Lehtonen, Joni-Matti Määttä, Erno Salminen, Timo D. Hämäläinen, System-on-Chip deployment with MCAPI abstraction and IP-XACT metadata, International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS XI), Samos, Greece, July 2012, 8 pages
Erno Salminen, Timo D. Hämäläinen, Marko Hännikäinen, "Applying IP-XACT for product data management", International Symposium on System-on-Chip, Tampere, Finland, Oct 31 - Nov 2, 2011, pp. 86-91.
Antti Kamppi, Lauri Matilainen, Joni-Matti Määttä, Erno Salminen, Timo D. Hämäläinen, Marko Hännikäinen, "Kactus2: Environment for Embedded Product Development Using IP-XACT and MCAPI", The 14th Euromicro Conference on Digital System Design (DSD), Oulu, Finland, Aug 31 - Sep 2, 2011, pp. 262-265.
Lauri Matilainen, Erno Salminen, Timo D. Hämäläinen, Marko Hännikäinen, "Multicore Communications API (MCAPI) implementation on an FPGA multiprocessor", International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS XI), Samos, Greece, July 18-21, 2011, pp. 286 - 293.