Вы находитесь на странице: 1из 11

Main

Kactus2

Woke

Tutorials

Examples

About

Contact

Kactus2 makes system, software and hardware


teams speak the same language
Intuitive system specification helps communication with SW and HW designers as well as customers and
subcontractors. Kactus2 helps to explain managers and sales department the product architecture and
contribute to requirements. All have the freedom to propose new blocks and try out different architectures,
while all data is formalized and manual copying of data eliminated. Time and effort is saved and quality
improved.

Kactus2 fits to your product design flow. There's no need to change specification, synthesis, verification or
other critical tools. You can start gradually using the unifying metadata and Kactus2 as the user interface
to it. Productivity is improved as re-use becomes real.

You don't lock-in with Kactus2, because you own data and can freely access it at any time. Kactus2 is
based on IEEE1685/IP-XACT metadata with our free and open extensions. Kactus2 comes with a core for
managing components and designs plus plugins for automation. Our ambition is the best usability among
EDA/ESL tools.
To whom
Small and mid-size vendor and integrator companies that now have only the traditional toolset: office
tools (doc, xls, ppt) for specification/documentation and Verilog/VHDL, C/C++, FPGA tools for designs.
Kactus2 helps taking a step to metadata based design that keeps products much better manageable
while still using also the familiar tools.

Universities and research laboratories that implement new content (IP bocks, SW modules). Kactus2
helps packetizing the content in a standard way for (re)using it much easier by others, specifically when
the original contributor leave after e.g. a PhD project.

Bigger companies and tool providers that already have modern design tool flows and resources for
developing higher abstraction methods. Kactus2 offers a great R&D environment for trying new
methodology ideas and user interface innovations. Kactus2 leads the way among metadata-based tools.

What you can do with Kactus2


Draft & Specify from scratch

Quickly draft block diagram blueprints for product boards (PCB), chips, system-on-chip, IPs and get
them stored in IP-XACT format
Draft communication channel abstraction endpoint design for all processors and fixed IPs in a
product
For new IP-blocks generate code templates (VHDL entities, headers) from IP-XACT components
defined in Kactus2
Packetize IP for reuse and exchange

Create "electronic datasheets" of your existing IPs for library as templates and blocks ready for
integration
Import, export and integrity check IP libraries from any standard compatible IP vendor

Analyze file dependencies between IP's source files and easily see changes in any file
Create MP-SoC products

Create HW designs with hierarchy across PCB, Chip, SoC, IP-blocks


Define memory areas and registers for the components
Configure base addresses
Create system designs that map SW to HW
Create SW architecture with communication abstraction as channels (MCAPI, Socket and others)
Configure all designs
Generate everything ready for HDL synthesis and SW build for all processors

What you can't do with Kactus2


Create IP functionality. You should use HDL editors and SW IDEs. Kactus2 can create stub code for
interfaces. For HW components you may use e.g. TCE-tools to create "C to VHDL" so you can
create the copmponent source without knowing much of HDLs.
Generate binaries/executables. You should use HDL synthesis and SW compilation tools, but there
is clear path from Kactus2 to other tools. IP-XACT generators are the standard way to build
automation between tools.
Press money. But you save a lot of time and effort.

What is Metadata?
Kactus2 follows the general platform based design paradigm with extensive use of metadata. Product is
created by assembling application components on platforms, and all are packetized to a library with
metadata. Metadata makes sure unambiguous interoperability between partners and tools and makes
design automation possible.

Metadata for a component is formal, vendor and technology independent description of the component.
It includes references to source files and other related information. Components are in practice HW blocks
and SW codes in different abstraction and granularity levels.

Metadata for a design is a formal structural description. It includes references to component metadata,
tools, configurations and other design related information.

In brief, metadata is like an electronic datasheet + product + project documentation.Read more on our
white paper or presentation on MeCoES'12 workshop.

What is metadata based design flow?


First, components are encapsulated and separated from their source, e.g. HDL source code is embedded
via links to the source file in the metadata file. IP metadata is used to assemble compopnents in a design.
IPs as well as the design itself may have generic parameters, which are configured using generators that
are typically scripts. The final configured design can be seen as "instructions" on how to create the final
executables.

Metadata benefits
Metadata-based design flow makes selling, buying, integrating and reusing IPs and complete
designs much less error prone
Saves time and effort when managing several configurations and variants of the products
Machine readable documentation also for the tools, languages and environments for backup and
maintenance
Increased design automation and standard compatibility

Kactus2 extensions to IP-XACT


Implementation
We handle also SW components as IP-XACT objects. This allows building dependencies and reusing SW
easier. IP-XACT parameters and vendor extensions are utilized.
Firmness
We add attributes to help managing the design process from re-usable components and designs to fixed
product releases. IP-XACT parameters and vendor extensions are utilized.
Product hierarchy

Embedded system products consists of HW and SW design data and plenty of process and other auxiliary
information. We consider the product as a hierarchy of its physical realization. Environments refer to the
context in which products are specified, verified, tested and finally used. Each product level include
associated information like documentation, source codes, tools, configurations and production data.

Our product hierarchy model consists of boards containing chips that are fixed-function or they can
accommodate a system-on-chip (SoC), which are built up from IP-blocks. All levels include both HW and
SW related information.

The scope of IEEE1685/IP-XACT is on the IP and SoC levels, but we apply the standard also to other
levels, aiming at product level information management (PDM, product data management).

Roadmap and Kactus2 releases


More about Kactus2

Archived Funbase-project site