×
What can it do:
Define your classes properties and connectivities (port, channel, interface) in a json file. then, use the tool below to generate a runnable SystemC/C++ framework, and to visualize the software architecture as UML diagrams.
Json source code rules | Auto-generated | |
---|---|---|
SystemC/C++ code | UML wsd | |
__common.h product.h person.h circle.h bike.h rider.h wheel.h dummy.h main.cpp Makefile Build environment: Docker Build command: make Note: rename "Makefile.txt" to "Makefile". | class_diagram.wsd component_diagram.wsd |
UML diagram
Rules to write the json file:
- Classes are defined as an array, each class corresponds to one element inside the array.
- Each class has the following properties: "type", "inheritance", "channels", "ports", "fields", "methods", and "lang".
- Only one class can have type of "main", which defines the top-level code structure.
- "__common" is reserved, don't use it for class type.
- "inheritance" specifies the parent classes to inherit from. Public inheritance is assumed.
- "Channels" and "ports" are arrays of SystemC channel and port. Each channel or port has the following properties: "interface", "type", "name", "handler", "to", "from", "next".
- A channel is defined as: interface<type> name; A channel can have initial value. If defined, the "write" method will be used to initialize channel with the given value.
- A port is defined as: sc_port< interface<type> > name;
- "handler" may be needed for incoming ports. It defines a function that will be triggered by the port.
- "to" and "from" defines how current port is connected to other ports/channels. Each port can have only one incoming connection, but multiple outgoing connections. Thus, "to" is an array.
- "next" may be defined for a port that has the "trigger" field. It means, when the trigger function is activated, within the function, the port/channel defined by "next" will be written.
- "to", "from", "next" shall specify the connections within the same class instance, or with ports/channels that are below the hierarchical level of current class.
- "interface", "type", "name" are mandatory fields; the others are optional.
- "Channels" and "ports" are always public in the auto-generated code.
- "fields" is an array which includes the properties of the class. Technically speaking, "channels" and "ports" are also fields, they are separated because of their importance in SystemC modeling. Each "field" has "access", "type", "name", "isClass", where
- "access" can be: public, protected, or private. If missing, public is assumed.
- "type" can be C++/SystemC built-in types or user-defined classes. It can also be a pointer that ends with "*".
- "isClass" can be true of false. If true, it tells the code generator current type is a user-defined type. The codegenerator will then step into the corresponding class definition.
- "methods" is an array which includes the member functions of the class, where
- "access" can be: public, protected, or private. If missing, public is assumed.
- "out" defines the return type. If missing, void is assumed.
- "in" defines the input parameters. If missing, no input is assumed for the function.
- "lang" specifies the language used for current class, can be "cpp" or "systemc". If missing, systemc is assumed. Use "cpp" avoids unnecessary inclusion of SystemC libraries and classes. If lang of cpp is specified for main class, then the whole program will be generated only in C++ language. Any SystemC channel/port will be ignored.
- For the class relationship, "inheritance", "dependency", "aggregation" shall be specified explicitly. "Aggregation" and "composition" are derived from the "fields" of the class.
Multiple examples are provided in above table, which can be used to better understand these rules.
Your data privacy:
- the auto-generation script runs 100% on the client side, your json contend stays locally, it is NOT uploaded to our server.
- The output SystemC code and text-based UML diagrams are temporary variables only visible locally. They don't exist anywhere in the internet. Nobody other than you can see those files.
- We use plantuml's server to generate the UML diagrams. Thus, if you choose to see the diagrams, the wsd files will be submitted to plantuml, and the figures are returned. If this is concerning to you, you can opt-out the diagram generation, and launch plantuml manually to convert the wsd files into diagrams.