|
$projectname $projectnumber
$projectbrief
|
$projectbrief
|
$searchbox | |
| $searchbox | |||
If you are not redirected automatically, click here.
================================================ FILE: Administrative/releaseFiles/DefaultSettingsWin.ini ================================================ [Platform] PluginsPath=Plugins HelpPath=Help [Library] Locations=Library DefaultLocation=Library [FilterWidget] Hidden=false [Policies] InstanceNames=$ComponentName$_$InstanceNumber$ HWViewNames=hierarchical, structural SWViewNames=software SysViewNames=system [Editor] IndentWidth=4 IndentStyle=1 Font=@Variant(\0\0\0@\0\0\0\x16\0\x43\0o\0u\0r\0i\0\x65\0r\0 \0N\0\x65\0w@$\0\0\0\0\0\0\xff\xff\xff\xff\x5\x1\0\x32\x10) Highlight\Keywords=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\0\0\xff\xff\0\0\0\0) Highlight\Preprocessor=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\0\0\xff\xff\0\0\0\0) Highlight\Strings=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\xa3\xa3\0\0\0\0\0\0\0\0) Highlight\SinglelineComments=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\xaa\xaa\0\0\0\0\0\0) Highlight\MultilineComments=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\xaa\xaa\0\0\0\0\0\0) Highlight\APITypes=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\0\0\xff\xff\0\0\0\0) Highlight\APIFunc=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\xaa\xaa\0\0\x7f\x7f\0\0\x1\0) [Workspaces] Default\WindowState=@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x4\0\0\0\0\0\0\x1H\0\0\x4\x33\xfc\x2\0\0\0\x2\xfb\0\0\0\xe\0L\0i\0\x62\0r\0\x61\0r\0y\x1\0\0\0g\0\0\x3Y\0\0\x1\\\0\xff\xff\xff\xfb\0\0\0 \0\x43\0o\0m\0p\0o\0n\0\x65\0n\0t\0P\0r\0\x65\0v\0i\0\x65\0w\x1\0\0\x3\xc4\0\0\0\xd6\0\0\0\x8e\0\xff\xff\xff\0\0\0\x1\0\0\x1&\0\0\x4\x33\xfc\x2\0\0\0\x6\xfb\0\0\0\x1e\0I\0n\0s\0t\0\x61\0n\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\0g\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\"\0\x41\0\x64\0-\0h\0o\0\x63\0 \0V\0i\0s\0i\0\x62\0i\0l\0i\0t\0y\0\0\0\0\x7f\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0(\0\x43\0o\0n\0\x66\0i\0g\0u\0r\0\x61\0t\0i\0o\0n\0 \0\x65\0\x64\0i\0t\0o\0r\0\0\0\0\x97\0\0\x2\xd0\0\0\0\xc5\0\xff\xff\xff\xfb\0\0\0\x32\0H\0W\0 \0M\0\x61\0p\0p\0i\0n\0g\0 \0\x44\0\x65\0t\0\x61\0i\0l\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x3k\0\0\0\xff\0\0\0\xff\0\xff\xff\xff\xfb\0\0\0 \0I\0n\0t\0\x65\0r\0\x66\0\x61\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x4n\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\"\0\x43\0o\0n\0n\0\x65\0\x63\0t\0i\0o\0n\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x4\x86\0\0\0\x14\0\0\0\x14\0\0\0\x14\0\0\0\x2\0\0\x6@\0\0\0\x63\xfc\x1\0\0\0\x1\xfb\0\0\0\b\0M\0\x65\0n\0u\x1\0\0\0\0\0\0\x6@\0\0\0\0\0\xff\xff\xff\0\0\0\x3\0\0\x4\xf4\0\0\0\xd6\xfc\x1\0\0\0\x3\xfb\0\0\0\f\0O\0u\0t\0p\0u\0t\x1\0\0\x1L\0\0\x3\x82\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x18\0\x43\0o\0n\0t\0\x65\0x\0t\0 \0H\0\x65\0l\0p\x1\0\0\x4\xd2\0\0\x1n\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x1c\0\x41\0\x64\0\x64\0r\0\x65\0s\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\x1*\0\xff\xff\xff\0\0\x4\xf4\0\0\x3Y\0\0\0\x4\0\0\0\x4\0\0\0\x1\0\0\0\x2\xfc\0\0\0\0) Default\Geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x1\0\0\xff\xff\xff\xf8\xff\xff\xff\xf8\0\0\x6G\0\0\x4\xb7\0\0\x1 \0\0\0\xe3\0\0\x5\x1f\0\0\x3\xe2\0\0\0\0\x2\0) Default\WindowPosition=@Point(-8 -8) Default\ConfigurationVisibility=true Default\SystemDetailsVisibility=true Default\ConnectionVisibility=true Default\InstanceVisibility=true Default\AdHocVisibility=true Default\AddressVisibility=false Default\InterfaceVisibility=true Default\LibraryVisibility=true Default\OutputVisibility=true Default\ContextHelpVisibility=true Default\PreviewVisibility=true Design\WindowState=@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x4\0\0\0\0\0\0\x1H\0\0\x4\x33\xfc\x2\0\0\0\x2\xfb\0\0\0\xe\0L\0i\0\x62\0r\0\x61\0r\0y\x1\0\0\0g\0\0\x3Y\0\0\x1\\\0\xff\xff\xff\xfb\0\0\0 \0\x43\0o\0m\0p\0o\0n\0\x65\0n\0t\0P\0r\0\x65\0v\0i\0\x65\0w\x1\0\0\x3\xc4\0\0\0\xd6\0\0\0\x8e\0\xff\xff\xff\0\0\0\x1\0\0\x1&\0\0\x4\x33\xfc\x2\0\0\0\x6\xfb\0\0\0(\0\x43\0o\0n\0\x66\0i\0g\0u\0r\0\x61\0t\0i\0o\0n\0 \0\x65\0\x64\0i\0t\0o\0r\0\0\0\0g\0\0\x1\xb5\0\0\0\xc5\0\xff\xff\xff\xfb\0\0\0\x1e\0I\0n\0s\0t\0\x61\0n\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2 \0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0 \0I\0n\0t\0\x65\0r\0\x66\0\x61\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2\x38\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\"\0\x43\0o\0n\0n\0\x65\0\x63\0t\0i\0o\0n\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2P\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\x32\0H\0W\0 \0M\0\x61\0p\0p\0i\0n\0g\0 \0\x44\0\x65\0t\0\x61\0i\0l\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2h\0\0\x2\x32\0\0\0\xff\0\xff\xff\xff\xfb\0\0\0\"\0\x41\0\x64\0-\0h\0o\0\x63\0 \0V\0i\0s\0i\0\x62\0i\0l\0i\0t\0y\0\0\0\x2\xe3\0\0\x1\x87\0\0\0\x14\0\0\0\x14\0\0\0\x2\0\0\x6@\0\0\0\x63\xfc\x1\0\0\0\x1\xfb\0\0\0\b\0M\0\x65\0n\0u\x1\0\0\0\0\0\0\x6@\0\0\0\0\0\xff\xff\xff\0\0\0\x3\0\0\x4\xf4\0\0\0\xd6\xfc\x1\0\0\0\x3\xfb\0\0\0\f\0O\0u\0t\0p\0u\0t\x1\0\0\x1L\0\0\x3&\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x18\0\x43\0o\0n\0t\0\x65\0x\0t\0 \0H\0\x65\0l\0p\x1\0\0\x4v\0\0\x1\xca\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x1c\0\x41\0\x64\0\x64\0r\0\x65\0s\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\x1*\0\xff\xff\xff\0\0\x4\xf4\0\0\x3Y\0\0\0\x4\0\0\0\x4\0\0\0\x1\0\0\0\x2\xfc\0\0\0\0) Design\Geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x1\0\0\xff\xff\xff\xf8\xff\xff\xff\xf8\0\0\x6G\0\0\x4\xb7\0\0\x1 \0\0\0\xe3\0\0\x5\x1f\0\0\x3\xe2\0\0\0\0\x2\0) Design\WindowPosition=@Point(-8 -8) Design\ConfigurationVisibility=true Design\SystemDetailsVisibility=true Design\ConnectionVisibility=true Design\InstanceVisibility=true Design\AdHocVisibility=false Design\AddressVisibility=false Design\InterfaceVisibility=true Design\LibraryVisibility=true Design\OutputVisibility=true Design\ContextHelpVisibility=true Design\PreviewVisibility=true CurrentWorkspace=Default ================================================ FILE: Administrative/releaseFiles/Kactus2.ini ================================================ [Platform] PluginsPath=/usr/share/kactus2/plugins HelpPath=/usr/share/kactus2/help [Library] Locations=/usr/share/kactus2/library [FilterWidget] Hidden=false [Policies] InstanceNames=$ComponentName$_$InstanceNumber$ HWViewNames=hierarchical, structural SWViewNames=software SysViewNames=system [Editor] IndentWidth=4 IndentStyle=1 Font=@Variant(\0\0\0@\0\0\0\x16\0\x43\0o\0u\0r\0i\0\x65\0r\0 \0N\0\x65\0w@$\0\0\0\0\0\0\xff\xff\xff\xff\x5\x1\0\x32\x10) Highlight\Keywords=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\0\0\xff\xff\0\0\0\0) Highlight\Preprocessor=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\0\0\xff\xff\0\0\0\0) Highlight\Strings=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\xa3\xa3\0\0\0\0\0\0\0\0) Highlight\SinglelineComments=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\xaa\xaa\0\0\0\0\0\0) Highlight\MultilineComments=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\xaa\xaa\0\0\0\0\0\0) Highlight\APITypes=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\0\0\0\0\xff\xff\0\0\0\0) Highlight\APIFunc=@Variant(\0\0\0\x7f\0\0\0\x13HighlightStyleDesc\0\x1\xff\xff\xaa\xaa\0\0\x7f\x7f\0\0\x1\0) [Workspaces] Default\WindowState=@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x4\0\0\0\0\0\0\x1H\0\0\x4\x33\xfc\x2\0\0\0\x2\xfb\0\0\0\xe\0L\0i\0\x62\0r\0\x61\0r\0y\x1\0\0\0g\0\0\x3Y\0\0\x1\\\0\xff\xff\xff\xfb\0\0\0 \0\x43\0o\0m\0p\0o\0n\0\x65\0n\0t\0P\0r\0\x65\0v\0i\0\x65\0w\x1\0\0\x3\xc4\0\0\0\xd6\0\0\0\x8e\0\xff\xff\xff\0\0\0\x1\0\0\x1&\0\0\x4\x33\xfc\x2\0\0\0\x6\xfb\0\0\0\x1e\0I\0n\0s\0t\0\x61\0n\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\0g\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\"\0\x41\0\x64\0-\0h\0o\0\x63\0 \0V\0i\0s\0i\0\x62\0i\0l\0i\0t\0y\0\0\0\0\x7f\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0(\0\x43\0o\0n\0\x66\0i\0g\0u\0r\0\x61\0t\0i\0o\0n\0 \0\x65\0\x64\0i\0t\0o\0r\0\0\0\0\x97\0\0\x2\xd0\0\0\0\xc5\0\xff\xff\xff\xfb\0\0\0\x32\0H\0W\0 \0M\0\x61\0p\0p\0i\0n\0g\0 \0\x44\0\x65\0t\0\x61\0i\0l\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x3k\0\0\0\xff\0\0\0\xff\0\xff\xff\xff\xfb\0\0\0 \0I\0n\0t\0\x65\0r\0\x66\0\x61\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x4n\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\"\0\x43\0o\0n\0n\0\x65\0\x63\0t\0i\0o\0n\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x4\x86\0\0\0\x14\0\0\0\x14\0\0\0\x14\0\0\0\x2\0\0\x6@\0\0\0\x63\xfc\x1\0\0\0\x1\xfb\0\0\0\b\0M\0\x65\0n\0u\x1\0\0\0\0\0\0\x6@\0\0\0\0\0\xff\xff\xff\0\0\0\x3\0\0\x4\xf4\0\0\0\xd6\xfc\x1\0\0\0\x3\xfb\0\0\0\f\0O\0u\0t\0p\0u\0t\x1\0\0\x1L\0\0\x3\x82\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x18\0\x43\0o\0n\0t\0\x65\0x\0t\0 \0H\0\x65\0l\0p\x1\0\0\x4\xd2\0\0\x1n\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x1c\0\x41\0\x64\0\x64\0r\0\x65\0s\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\x1*\0\xff\xff\xff\0\0\x4\xf4\0\0\x3Y\0\0\0\x4\0\0\0\x4\0\0\0\x1\0\0\0\x2\xfc\0\0\0\0) Default\Geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x1\0\0\xff\xff\xff\xf8\xff\xff\xff\xf8\0\0\x6G\0\0\x4\xb7\0\0\x1 \0\0\0\xe3\0\0\x5\x1f\0\0\x3\xe2\0\0\0\0\x2\0) Default\WindowPosition=@Point(-8 -8) Default\ConfigurationVisibility=true Default\SystemDetailsVisibility=true Default\ConnectionVisibility=true Default\InstanceVisibility=true Default\AdHocVisibility=true Default\AddressVisibility=false Default\InterfaceVisibility=true Default\LibraryVisibility=true Default\OutputVisibility=true Default\ContextHelpVisibility=true Default\PreviewVisibility=true Design\WindowState=@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x4\0\0\0\0\0\0\x1H\0\0\x4\x33\xfc\x2\0\0\0\x2\xfb\0\0\0\xe\0L\0i\0\x62\0r\0\x61\0r\0y\x1\0\0\0g\0\0\x3Y\0\0\x1\\\0\xff\xff\xff\xfb\0\0\0 \0\x43\0o\0m\0p\0o\0n\0\x65\0n\0t\0P\0r\0\x65\0v\0i\0\x65\0w\x1\0\0\x3\xc4\0\0\0\xd6\0\0\0\x8e\0\xff\xff\xff\0\0\0\x1\0\0\x1&\0\0\x4\x33\xfc\x2\0\0\0\x6\xfb\0\0\0(\0\x43\0o\0n\0\x66\0i\0g\0u\0r\0\x61\0t\0i\0o\0n\0 \0\x65\0\x64\0i\0t\0o\0r\0\0\0\0g\0\0\x1\xb5\0\0\0\xc5\0\xff\xff\xff\xfb\0\0\0\x1e\0I\0n\0s\0t\0\x61\0n\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2 \0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0 \0I\0n\0t\0\x65\0r\0\x66\0\x61\0\x63\0\x65\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2\x38\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\"\0\x43\0o\0n\0n\0\x65\0\x63\0t\0i\0o\0n\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2P\0\0\0\x14\0\0\0\x14\0\0\0\x14\xfb\0\0\0\x32\0H\0W\0 \0M\0\x61\0p\0p\0i\0n\0g\0 \0\x44\0\x65\0t\0\x61\0i\0l\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\x2h\0\0\x2\x32\0\0\0\xff\0\xff\xff\xff\xfb\0\0\0\"\0\x41\0\x64\0-\0h\0o\0\x63\0 \0V\0i\0s\0i\0\x62\0i\0l\0i\0t\0y\0\0\0\x2\xe3\0\0\x1\x87\0\0\0\x14\0\0\0\x14\0\0\0\x2\0\0\x6@\0\0\0\x63\xfc\x1\0\0\0\x1\xfb\0\0\0\b\0M\0\x65\0n\0u\x1\0\0\0\0\0\0\x6@\0\0\0\0\0\xff\xff\xff\0\0\0\x3\0\0\x4\xf4\0\0\0\xd6\xfc\x1\0\0\0\x3\xfb\0\0\0\f\0O\0u\0t\0p\0u\0t\x1\0\0\x1L\0\0\x3&\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x18\0\x43\0o\0n\0t\0\x65\0x\0t\0 \0H\0\x65\0l\0p\x1\0\0\x4v\0\0\x1\xca\0\0\0P\0\xff\xff\xff\xfb\0\0\0\x1c\0\x41\0\x64\0\x64\0r\0\x65\0s\0s\0 \0\x45\0\x64\0i\0t\0o\0r\0\0\0\0\0\xff\xff\xff\xff\0\0\x1*\0\xff\xff\xff\0\0\x4\xf4\0\0\x3Y\0\0\0\x4\0\0\0\x4\0\0\0\x1\0\0\0\x2\xfc\0\0\0\0) Design\Geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x1\0\0\xff\xff\xff\xf8\xff\xff\xff\xf8\0\0\x6G\0\0\x4\xb7\0\0\x1 \0\0\0\xe3\0\0\x5\x1f\0\0\x3\xe2\0\0\0\0\x2\0) Design\WindowPosition=@Point(-8 -8) Design\ConfigurationVisibility=true Design\SystemDetailsVisibility=true Design\ConnectionVisibility=true Design\InstanceVisibility=true Design\AdHocVisibility=false Design\AddressVisibility=false Design\InterfaceVisibility=true Design\LibraryVisibility=true Design\OutputVisibility=true Design\ContextHelpVisibility=true Design\PreviewVisibility=true CurrentWorkspace=Default ================================================ FILE: Administrative/releaseFiles/Library/tut.fi/global.communication/iptlm/1.1/TLMW.1.1.xml ================================================Community Guidelines
Issues should be reported at Kactus2 project Github https://github.com/kactus2/kactus2dev
Otherwise support is provided by email: kactus2@tuni.fi
When contributing to Kactus2, you should see the wiki at the project management site. It will guide on essentials like building with Visual Studio and plugin development. Contributions to Kactus2 core, the IP-XACTmodels library, and the plugins provided by Tampere University will not make to a release unless we accept them and you agree to transfer the copyrights of the changes to Tampere University.
When creating a plugin, you may keep it closed or open source, and the copyright stays with you.
================================================ FILE: Help/componenteditor/addressblock.html ================================================ Address block editor
Address block editor is used to edit the details of an address block and the registers contained within it.
Name is a mandatory identifier for the address block. The name must be unique within all the address blocks of the containing memory map.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the address block.
Base address is mandatory and specifies the starting address for the address block in address unit bits.
Range is mandatory and specifies the size of the block in address units bits.
Width is mandatory and defines the data width of a row in the address block. The width value is given in bits.
Is present is optional and allows enabling/disabling of a address block presence in a memory map. Value 1 indicates that the address block is present in the memory map whereas value 0 marks the address block to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Usage is a mandatory value to specify the usage of the address block and may have one of the following values:
- Memory The address block is ROM, RAM or write-only memory as defined by access. Registers and register files within will be considered virtual.
- Register The address block range may contain registers.
- Reserved The address block is reserved for other usage and shall not contain registers or register files.
Access is optional and specifies the accessability of the address block. The possible values are:
- read-write. Both read and write transactions may have an effect on this address block.
- read-only. Only read transactions are allowed in this address block.
- write-only. Only write transactions are allowed in this address block.
- read-writeOnce. Read actions and the first write action may have an effect on this address block.
- writeOnce. Only the first write action affects the contents of this address block.
Volatile is optional and indicates whether the stored value may change without the master's write operation or not.
Registers table
The register table enables the user to define registers for the address block, with each row representing a single register. Each register must also contain at least one bit field.
Name is a mandatory identifier for the register.
Offset is mandatory and specifies the location of the register from the start of the containing address block expressed as number of addressing units. The actual address of the register is the sum of address block's base address and the register offset. E.g. if the base address is 'h100 and the register offset is 'h4, the register's address is 'h104. Offset can be given as a SystemVerilog expression.
Size is mandatory and defines the number of data bits the register contains. Size must be less than or equal to the width of the containing address block.
Dimension is optional and assigns an array dimension to the register. The register will be repeated in the address block as many times as indicated by the dimension value. By default, the dimension is presumed to be 0. Dimension 0 means that the register is not an array and will appear exactly once.
Volatile is optional and indicates whether the register value may change without a write operation to it, i.e. by an interrupt event, or not.
Access is optional and specifies the accessibility of the register. The possible values are:
- read-write. Both read and write transactions may have an effect on this register.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Both read and write transactions may have an effect on this register. Only the first write transaction, after an event that caused the reset value of the register to be loaded, may affet the contents of the register, and read transactions return a value related to the values in the register.
- writeOnce. Only the first write transaction affects the contents of the register.
Is present is optional and allows enabling/disabling of a register presence in an address block. Value 1 indicates that the register is present in the address block whereas value 0 marks the register to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the register.
Register files table
The register files table enables the user to define register files for the address block where each row represents a single register file. Register files are used to group together registers.
Name is a mandatory identifier for the register file.
Offset is mandatory and specifies the location of the register file from the start of the containing address block expressed as number of addressing units. Offset can be given as a SystemVerilog expression.
Range is mandatory and specifies the size of the register file in address unit bits.
Dimension is optional and assigns an array dimension to the register file. The register file will be repeated in the address block as many times as indicated by the dimension value. By default, the dimension is presumed to be 0. Dimension 0 means that the register file is not an array and will appear exactly once.
Is present is optional and allows enabling/disabling of a register file presence in an address block. Value 1 indicates that the register file is present in the address block whereas value 0 marks the register to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the register file.
================================================ FILE: Help/componenteditor/addressblock2022.html ================================================ Address block editor
Address block editor is used to edit the details of an address block and the registers contained within it.
Name is a mandatory identifier for the address block. The name must be unique within all the address blocks of the containing memory map.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the address block.
Description is an optional field for textual description of the address block.
Base address is mandatory and specifies the starting address for the address block in address unit bits.
Range is mandatory and specifies the size of the block in address units bits.
Width is mandatory and defines the data width of a row in the address block. The width value is given in bits.
Usage is a mandatory value to specify the usage of the address block and may have one of the following values:
- Memory The address block is ROM, RAM or write-only memory as defined by access policies. Registers and register files within will be considered virtual.
- Register The address block range may contain registers.
- Reserved The address block is reserved for other usage and shall not contain registers or register files.
Volatile is optional and indicates whether the stored value may change without the master's write operation or not.
Access policies are optional and specify the accessability of the address block data for different operating modes, specified by mode references. If no mode reference is present, then the access policy applies to all modes not already referenced by other access policies (i.e. only one access policy without mode references may exist). The possible access values for an access policy are:
- read-write. Both read and write transactions may have an effect on this address block.
- read-only. Only read transactions are allowed in this address block.
- write-only. Only write transactions are allowed in this address block.
- read-writeOnce. Read actions and the first write action may have an effect on this address block.
- writeOnce. Only the first write action affects the contents of this address block.
Registers table
The register table enables the user to define registers for the address block, with each row representing a single register. Each register must also contain at least one bit field.
Name is a mandatory identifier for the register.
Offset is mandatory and specifies the location of the register from the start of the containing address block expressed as number of addressing units. The actual address of the register is the sum of address block's base address and the register offset. E.g. if the base address is 'h100 and the register offset is 'h4, the register's address is 'h104. Offset can be given as a SystemVerilog expression.
Size is mandatory and defines the number of data bits the register contains. Size must be less than or equal to the width of the containing address block.
Dimension is optional and assigns an array dimension to the register. The register will be repeated in the address block as many times as indicated by the dimension value. If empty (default) or 1, the register will appear exactly once.
Volatile is optional and indicates whether the register value may change without a write operation to it, i.e. by an interrupt event, or not.
Access is optional and specifies the accessibility of the register by modifying the first access policy of the register. If multiple access policies exist, then the access value cannot be edited here and must be edited for each access policy separately in the register editor. If no access policy exists, then one will be created for the register when the access is edited here. The possible access values are:
- read-write. Both read and write transactions may have an effect on this register.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Both read and write transactions may have an effect on this register. Only the first write transaction, after an event that caused the reset value of the register to be loaded, may affet the contents of the register, and read transactions return a value related to the values in the register.
- writeOnce. Only the first write transaction affects the contents of the register.
Description is an optional field for textual description of the register.
Register files table
The register files table enables the user to define register files for the address block where each row represents a single register file. Register files are used to group together registers.
Name is a mandatory identifier for the register file.
Offset is mandatory and specifies the location of the register file from the start of the containing address block expressed as number of addressing units. Offset can be given as a SystemVerilog expression.
Range is mandatory and specifies the size of the register file in address unit bits.
Dimension is optional and assigns an array dimension to the register file. The register file will be repeated in the address block as many times as indicated by the dimension value. If empty (default) or 1, the register file will appear exactly once.
Description is an optional field for textual description of the register file.
================================================ FILE: Help/componenteditor/addressspace.html ================================================ Address space editor
Address space editor can be used to edit the details of an address space within component. Address space defines a logical address space seen by a master bus interface. It can be split into smaller sgements.
On the left side are the editor fields that can be used to set the details of an address space. The right side contains a visualization displaying the address space in its current state and automatically updates on changes. It displays how the segments are positioned within the address space. Mismatches, e.g. sum of segment ranges being greater than address block range, can be easily spotted from the visualization.
Name is a mandatory identifier for the address space.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the address space.
Addressable unit bits (AUB) specifies the number of bits each address increment contains, e.g. 8 bits or 32 bits. The AUB is mandatory if the address space contains a local memory map.
Range is the size of the address space expressed as addressable units, i.e. the number of separate addresses.
Width is the data width of a row in bits. It defines the maximum size for a single transfer.
Is present is optional and allows enabling/disabling of a address space presence in a component. Value 1 indicates that the address space is present in the component whereas value 0 marks the address space to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Master interface binding shows the master bus interfaces bound to the address space. The binding can be set in the bus interface editor.
Segments
Segments editor can be used to describe sections of the address space, i.e. split it into smaller segments.
Name is a mandatory identifier for the segment.
Offset is mandatory and defines the starting address of the segment in address unit bits.
Range is mandatory and defines the size of the segment in address unit bits.
Is present is optional and allows enabling/disabling of a segment presence in an address space. Value 1 indicates that the segment is present in the address space whereas value 0 marks the segment to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the segment.
Local memory map
Local memory map is optional but some processors require specifying a memory map that is local to the component. It consists of address blocks similarly to the memory map of a slave bus interface. Hence, the address blocks can contain either memory or registers, and registers can contain bit fields.
Local memory map is useful for storing the programmer's view to interrupts registers, timers, and other local things. The overall address space of a component is a concatenation of local memory map (e.g. timers) and the memory maps of other units (e.g. registers of accelerator A, registers of accelerator B etc.)
================================================ FILE: Help/componenteditor/addressspace2022.html ================================================ Address space editor
Address space editor can be used to edit the details of an address space within component. Address space defines a logical address space seen by a initiator bus interface. It can be split into smaller sgements.
On the left side are the editor fields that can be used to set the details of an address space. The right side contains a visualization displaying the address space in its current state and automatically updates on changes. It displays how the segments are positioned within the address space. Mismatches, e.g. sum of segment ranges being greater than address block range, can be easily spotted from the visualization.
Name is a mandatory identifier for the address space.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for a short, textual description of the address space.
Description is an optional field for textual description of the address space.
Addressable unit bits (AUB) specifies the number of bits each address increment contains, e.g. 8 bits or 32 bits. The AUB is mandatory if the address space contains a local memory map.
Range is the size of the address space expressed as addressable units, i.e. the number of separate addresses.
Width is the data width of a row in bits. It defines the maximum size for a single transfer.
Initiator interface binding shows the initiator bus interfaces bound to the address space. The binding can be set in the bus interface editor.
Segments
Segments editor can be used to describe sections of the address space, i.e. split it into smaller segments.
Name is a mandatory identifier for the segment.
Offset is mandatory and defines the starting address of the segment in address unit bits.
Range is mandatory and defines the size of the segment in address unit bits.
Description is an optional field for textual description of the segment.
Local memory map
Local memory map is optional but some processors require specifying a memory map that is local to the component. It consists of address blocks similarly to the memory map of a target bus interface. Hence, the address blocks can contain either memory or registers, and registers can contain bit fields.
Local memory map is useful for storing the programmer's view to interrupts registers, timers, and other local things. The overall address space of a component is a concatenation of local memory map (e.g. timers) and the memory maps of other units (e.g. registers of accelerator A, registers of accelerator B etc.)
================================================ FILE: Help/componenteditor/addressspaces.html ================================================ Address spaces editor
Address spaces editor contains the summary of the address spaces of the component. This editor can be used to add and remove address spaces to the containing component.
Address space defines the addressable memory space that can be accessed through
a master bus interface. It is the programmer's view to the rest of the system.
Note: Address spaces are actually instance-specific concepts (what other units are
there and what are their addresses) rather than component-specific. Nevertheless, IP-XACT standard
defines address space inside a component, although it is seldom a reusable element.
Name is a mandatory identifier for the address space.
Addressable unit bits specifies the number of bits each address increment contains, e.g. 8 bits or 32 bits. The AUB is mandatory if the address space contains a local memory map. AUB is 8 by default.
Range is mandatory and defines the size of the address space in addressable units. In other words, it is the number of separate addresses in the address space.
Width is mandatory and defines the data width of a row in bits thus defining the maximum size for a single transfer.
Master interface binding shows the master bus interfaces bound to the address space. The binding can be set in the bus interface editor.
Is present is optional and allows enabling/disabling of a address space presence in a component. Value 1 indicates that the address space is present in the component whereas value 0 marks the address space to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the address space.
Address spaces editor contains a context menu (right mouse button) providing following options:
- Add new address space (Add row)
- Remove address space (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE. The address space AS0 defines the available address space of the whole system
when accessed through bus interface MainIF. This is what the component CPU0 requires
of the system, but the components connected to MainIF may be different.
Address spaces editor
Address spaces editor contains the summary of the address spaces of the component. This editor can be used to add and remove address spaces to the containing component.
Address space defines the addressable memory space that can be accessed through
a master bus interface. It is the programmer's view to the rest of the system.
Note: Address spaces are actually instance-specific concepts (what other units are
there and what are their addresses) rather than component-specific. Nevertheless, IP-XACT standard
defines address space inside a component, although it is seldom a reusable element.
Name is a mandatory identifier for the address space.
Addressable unit bits specifies the number of bits each address increment contains, e.g. 8 bits or 32 bits. The AUB is mandatory if the address space contains a local memory map. AUB is 8 by default.
Range is mandatory and defines the size of the address space in addressable units. In other words, it is the number of separate addresses in the address space.
Width is mandatory and defines the data width of a row in bits thus defining the maximum size for a single transfer.
Initiator interface binding shows the initiator bus interfaces bound to the address space. The binding can be set in the bus interface editor.
Description is an optional field for textual description of the address space.
Address spaces editor contains a context menu (right mouse button) providing following options:
- Add new address space (Add row)
- Remove address space (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE. The address space AS0 defines the available address space of the whole system
when accessed through bus interface MainIF. This is what the component CPU0 requires
of the system, but the components connected to MainIF may be different.
API interface editor
This is Kactus2 extension 
Each API interface has a
mandatory name. Display name is optional and
typically a few words providing a more detailed and/or
user-friendly name for display. Optional description
contains a textual description of the interface.
Optional API definition is an XML document that captures the interface properties. It lists all the function calls, their parameters, and return values. You can type the VLNV or drag-drop an API definition from the library.
Details section includes dependency which is either 'provider' or 'requester'. A provider means that this SW components implements the API and other SW components call its functions. Requester means that this SW components calls functions defined in the API and some other SW component must implement (provide) them.
================================================ FILE: Help/componenteditor/apiinterfaces.html ================================================API interfaces editor
This is Kactus2 extension
API interface
(application programming interface) means the protocol that SW
components use to communicate, in practice it is set of function
calls. Purpose is to increase portability by abstacting the
details of underlying HW. These are a lower level concept than
COM interfaces and cannot appear in HW components. API
interfaces make rather tight coupling between SW components, and
often both the sender and receiver are mapped on the same CPU.
COM interfaces are meant for communication between application
modules, whereas API interfaces are mainly between application
and platform (OS, drivers) and inside the platform.
For example, a SW component could have API interfaces 'lower'
and 'upper'. It requests the 'lower' one, DMA driver,
i.e. calls its functions. At the same, this component 'provides'
the 'upper' interface, MCAPI, i.e. other SW components can call
its functions.
Bus interface editor
Bus interface editor is used to edit the details of a single bus interface. A bus interface is used to group ports together to form an interface that fulfills the requirements for a bus protocol. The editor has two tabs: the general tab which is used to set the details of the bus interface, and the port maps tab which is used to group the ports to the bus interface.
Name is a mandatory identifier for the bus interface.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the bus interface.
General settings
Interface mode is mandatory and has 7 possible choices:
- Master for initiating transactions.
- Slave for responding to transactions.
- System for defining interfaces not belonging to either master or slave interface modes. They are categorized by a system group instead.
- MirroredMaster is the mirrored version of a master interface.
- MirroredSlave is the mirrored version of a slave interface.
- MirroredSystem is the mirrored version of a system interface.
- Monitor for verification.
Settings below the general section are mode-specific and change when the mode changes. The different modes are detailed in their respective sections below.
Addressable unit size defines how many bits are included in the least addressable unit of the bus interface. The default setting is byte addressable (8 bits).
Bit steering='on' implies that the interface is able to dynamically align data on different byte channels in case of addressable interfaces. The default setting when the bit steering is not set is off. Bit steering is not allowed in mirrored-master, system or mirrored-system interface modes.
Endianness indicates whether the interface is 'big-endian' or 'little-endian' (default).
Connection required indicates that when instantiated in a design, this interface must be connected to some other interface and cannot be left unconnected.
Master
Address space defines the address space available for transactions on the bus interface. Address space is optional, but, if defined, base address becomes mandatory as well.
Base address is defines the starting address of the address space. Typically base address is 0.
Mirrored master
Mirrored master has no mode-specific options.
Slave
A slave bus interface may have access to a memory map or a master bus interface. Access to a master bus interface is called a transparent bridge. Access is optional, but mutually exclusive i.e. a slave bus interface may only access a memory map, a transparent bridge or neither.
Memory map is optional and defines the memory map accessible through the bus interface. If a memory map has been defined, transparent bridge cannot be defined.
Transparent bridge(s) are optional and define the master bus interface(s) that all transactions to this bus interface are directed out of. If transparent bridges have been defined, memory map cannot be defined.
File set references define the associated file sets for the slave bus interface. For example, the file set could contain the interface implementation or a software driver.
Mirrored slave
Remap address defines an address offset for the slave bus interface conneted to this interface. Remap addressis optional, but, if defined, range becomes mandatory as well.
Range defines the address range available for the connected slave bus interface.
System and mirrored system
System group defines the group this bus interface is part of. The available system groups are defined in the referenced bus definition (see below).
Monitor
Interface mode is mandatory and defines the interface mode the monitor can be connected to.
Group defines the group this bus interface is part of when system or mirrored system interface mode is selected. For other modes group has no effect.
Bus definition
Bus definition is mandatory and contains a VLNV-reference to the bus definition document that defines the qualities that the bus interface must meet.
Abstraction definition
Abstraction definition contains an optional VLNV-reference to the abstraction definition document that defines the logical signals on the bus. If multiple abstraction definitions are defined, view references specify which view(s) the abstraction is applied to. All views are considered, if the view reference is empty.
Port maps on the other tab define how the logical signals in the abstraction definition are connected to the physical ports on the component.
Parameters
Parameters are optional and can specify any parameter data value(s) specific for this bus interface. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/businterfacegeneral2022.html ================================================ Bus interface editor
Bus interface editor is used to edit the details of a single bus interface. A bus interface is used to group ports together to form an interface that fulfills the requirements for a bus protocol. The editor has two tabs: the general tab which is used to set the details of the bus interface, and the port maps tab which is used to group the ports to the bus interface.
Name is a mandatory identifier for the bus interface.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the bus interface.
Description is an optional field for textual description of the bus interface.
General settings
Interface mode is mandatory and has 7 possible choices:
- Initiator for initiating transactions.
- Target for responding to transactions.
- System for defining interfaces not belonging to either initiator or target interface modes. They are categorized by a system group instead.
- MirroredInitiator is the mirrored version of an initiator interface.
- MirroredTarget is the mirrored version of a target interface.
- MirroredSystem is the mirrored version of a system interface.
- Monitor for verification.
Settings below the general section are mode-specific and change when the mode changes. The different modes are detailed in their respective sections below.
Addressable unit size defines how many bits are included in the least addressable unit of the bus interface. The default setting is byte addressable (8 bits).
Bit steering evaluating to value '1' implies that the interface is able to dynamically align data on different byte channels in case of addressable interfaces. The default setting when the bit steering is not set is 0. Bit steering is not allowed in mirrored-initiator, system or mirrored-system interface modes.
Endianness indicates whether the interface is 'big-endian' or 'little-endian' (default).
Connection required indicates that when instantiated in a design, this interface must be connected to some other interface and cannot be left unconnected.
Initiator
Address space defines the address space available for transactions on the bus interface. Address space is optional, but, if defined, base address becomes mandatory as well.
Base address is defines the starting address of the address space. Typically base address is 0.
Mirrored initiator
Mirrored initiator has no mode-specific options.
Target
A target bus interface may have access to a memory map or an initiator bus interface. Access to a initiator bus interface is called a transparent bridge. Access is optional, but mutually exclusive i.e. a target bus interface may only access a memory map, a transparent bridge or neither.
Memory map is optional and defines the memory map accessible through the bus interface. If a memory map has been defined, transparent bridge cannot be defined.
Transparent bridge(s) are optional and define the initiator bus interface(s) that all transactions to this bus interface are directed out of. If transparent bridges have been defined, memory map cannot be defined.
File set references define the associated file sets for the target bus interface. For example, the file set could contain the interface implementation or a software driver.
Mirrored target
Remap address defines an address offset for the target bus interface conneted to this interface. Remap addressis optional, but, if defined, range becomes mandatory as well.
Range defines the address range available for the connected target bus interface.
System and mirrored system
System group defines the group this bus interface is part of. The available system groups are defined in the referenced bus definition (see below).
Monitor
Interface mode is mandatory and defines the interface mode the monitor can be connected to.
Group defines the group this bus interface is part of when system or mirrored system interface mode is selected. For other modes group has no effect.
Bus definition
Bus definition is mandatory and contains a VLNV-reference to the bus definition document that defines the qualities that the bus interface must meet.
Abstraction definition
Abstraction definition contains an optional VLNV-reference to the abstraction definition document that defines the logical signals on the bus. If multiple abstraction definitions are defined, view references specify which view(s) the abstraction is applied to. All views are considered, if the view reference is empty.
Port maps on the other tab define how the logical signals in the abstraction definition are connected to the physical ports on the component.
Parameters
Parameters are optional and can specify any parameter data value(s) specific for this bus interface. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/businterfaces.html ================================================ Bus interfaces editor
The bus interfaces editor displays a summary of the bus
interfaces of a component. A bus interface groups
ports together to form an interface that fulfills
requirements for a bus protocol. Connecting two matching
interfaces means connecting multiple ports (up to tens or even
hundreds of bits) together very easily. This editor is used to
add and remove bus interfaces in a component
Bus interface has a mandatory name and optional textual description.
Bus definition and abstraction definition columns display the VLNV-identifiers of the IP-XACT documents that define qualities of the interface. These fields must be set in the bus interface-specific editor.
Interface mode has 7 different choices (3 modes and 2 flavors of each, plus 1 extra):
- 1. Master initiates transactions, e.g. a write or read. A master may have an address space which captures the programmer's view of the system.
- 2. Slave responds to transactions, e.g. accepts the written value or provides the read value. A slave may have a memory map which captures information about the accessible registers inside this component.
- 3. System can be used for some interfaces that do not fit into the master or slave category.
- 4-6. Mirrored master, mirrored slave, mirrored system are the mirrored versions of the above modes. They have similar ports as normal interfaces, but the directions of the ports are reversed. For example, if a master interface has data output, then a mirrored master has data as input. It is not allowed to connect to mirrored interfaces together. The main usage of mirrored interfaces is at bus interconnects, such as AMBA AHB/APB or HIBI, since they allow constructing a memory map of the whole system, whereas regular IP components mainly utilize direct interfaces.
- 7. Monitor is an interface that can be used for verification process. It gathers data from other interfaces, i.e. non-intrusive observation and hence all logical port are inputs
IP-XACT allows three kinds of connections
- Direct master to slave: Point-to-point connection. Complex cases require using bus interconnect component containing bridge(s), such as multillayer AHB bus.
- Direct-mirrored: master to mirrored master, mirrored slave to slave, system to mirrored system. Point-to-point connection. Complex cases require using bus interconnect component containing channel(s)
- Monitor: any type except monitor to monitor. Many monitors can be connected to single interface
EXAMPLE. Component Sender writes data through its master interface MIF to
mirrored master interface MMIF in interconnect. On the receiving side,
interconnect's mirrored slave interface MSIF writes the data to
Receiver's slave interface SIF.
Bus interfaces editor
The bus interfaces editor displays a summary of the bus
interfaces of a component. A bus interface groups
ports together to form an interface that fulfills
requirements for a bus protocol. Connecting two matching
interfaces means connecting multiple ports (up to tens or even
hundreds of bits) together very easily. This editor is used to
add and remove bus interfaces in a component
Bus interface has a mandatory name and optional textual description.
Bus definition and abstraction definition columns display the VLNV-identifiers of the IP-XACT documents that define qualities of the interface. These fields must be set in the bus interface-specific editor.
Interface mode has 7 different choices (3 modes and 2 flavors of each, plus 1 extra):
- 1. Initiator initiates transactions, e.g. a write or read. An initiator may have an address space which captures the programmer's view of the system.
- 2. Target responds to transactions, e.g. accepts the written value or provides the read value. A target may have a memory map which captures information about the accessible registers inside this component.
- 3. System can be used for some interfaces that do not fit into the initiator or target category.
- 4-6. Mirrored initiator, mirrored target, mirrored system are the mirrored versions of the above modes. They have similar ports as normal interfaces, but the directions of the ports are reversed. For example, if an initiator interface has data output, then a mirrored initiator has data as input. It is not allowed to connect to mirrored interfaces together. The main usage of mirrored interfaces is at bus interconnects, such as AMBA AHB/APB or HIBI, since they allow constructing a memory map of the whole system, whereas regular IP components mainly utilize direct interfaces.
- 7. Monitor is an interface that can be used for verification process. It gathers data from other interfaces, i.e. non-intrusive observation and hence all logical port are inputs
IP-XACT allows three kinds of connections
- Direct initiator to target: Point-to-point connection. Complex cases require using bus interconnect component containing bridge(s), such as multillayer AHB bus.
- Direct-mirrored: initiator to mirrored initiator, mirrored target to target, system to mirrored system. Point-to-point connection. Complex cases require using bus interconnect component containing channel(s)
- Monitor: any type except monitor to monitor. Many monitors can be connected to single interface
EXAMPLE. Component Sender writes data through its initiator interface IIF to
mirrored initiator interface MIIF in interconnect. On the receiving side,
interconnect's mirrored target interface MTIF writes the data to
Receiver's target interface TIF.
Channels editor
Channels editor provides a summary of the channels contained in the bus component. Channel is used within a bus component to describe which bus interfaces are connected together. This editor can be used to add, edit and remove channels.
Name is a mandatory identifier for the channel.
Display name is an optional and used for a more user-friendly identifier.
Interface references contain the names of the mirrored bus interfaces that are grouped to the same channel. All the bus interfaces in the group are interconnected.
Description is an optional field for textual description of the channel.
The figure below illustrates the connections between mirrored bus interfaces. All four
mirrored bus interfaces are included in the same channel.
Channels editor
Channels editor provides a summary of the channels contained in the bus component. Channel is used within a bus component to describe which bus interfaces are connected together. This editor can be used to add, edit and remove channels.
Name is a mandatory identifier for the channel.
Display name is an optional and used for a more user-friendly identifier.
Interface references contain the names of the mirrored bus interfaces that are grouped to the same channel. All the bus interfaces in the group are interconnected.
Short description is an optional field for compact description of the channel.
Description is an optional field for textual description of the channel.
The figure below illustrates the connections between mirrored bus interfaces. All four
mirrored bus interfaces are included in the same channel.
Choices editor
The choices editor lists the configuration elements of the component. A choice provides a set of possible values for parameters, module parameters and other configurable elements within the containing component.
Choices are identified by a mandatory name in the Choice list.
Each choice must have at least one enumeration defined. An enumeration has a mandatory value, an optional text to display instead of the value and an optional description. When the value of e.g. a parameter refers to the choice, the possible model parameter value is selected from the set of enumerations in that choice.
EXAMPLE. The choice is used to limit the possible parameter values to 8, 16 or 32 (bits).
COM interface editor
This is Kactus2 extension
Each interface has a mandatory
name. Display name is optional and typically a few
words providing a more detailed and/or user-friendly name for
display. Optional description contains a textual
description of the interface.
Optional COM definition is a XML document that captures the interface properties, similarly to bus interfaces in regular HW components. You can type the VLNV or drag-drop a COM definition from the library.
Details are settings that are specific to selected COM definition. Optional transfer type denotes what kind of data is transmitted through the interface. The allowed values depend on the selected COM definition, e.g. in MCAPI they are 'message', 'packet', and 'scalar'. At least MCAPI has also a Direction (in, out, inout).
Property values define values for the parameters as name-value pairs. For example in MCAPI, each endpoint must have a 'port_id'.
================================================ FILE: Help/componenteditor/cominterfaces.html ================================================COM interfaces editor
This is Kactus2 extension
COM interface means
that component supports an optional "high-level" communication
mechanism, such as MCAPI. Purpose is to increase portability by
abstacting the details of communication. COM interfaces are
connected together in system view of the Kactus. Usually,
these interfaces a part of a SW component, but some HW
components can support them also. COM interfaces makes only
loose coupling between SW components, and consequently the
receiver can be mapped on different CPU than sender. COM
interfaces are meant for communication between application
modules, whereas API interfaces are mainly between application
and platform (OS, drivers) and inside the platform.
Each interface has a mandatory name and direction (in, out, inout). Optional COM definition is an XML document that captures the interface properties, similarly to bus interfaces in regular HW components. Note that this information is just shown here and can be edited on interface editor. Optional transfer type denotes what kind of data is transmitted through the interface. The allowed values depend on the selected COM definition.
For example, a SW component could have an input COM interface
'data_in' and output called 'result_out'. Then depending of how
the channels are conencted in system design, the imput data can
come from, say, UART or CPU. Similarly, the result can be
directed to, say, memory or VGA. Here both interfaces correspond
to MCAPI endpoints and transmit 'MCAPI messages'.
Component instantiation editor
Component instantiation defines how a specific component instance is associated with a view. This editor can be used to edit the details of a component instantiation.
Name is a mandatory identifier for the component instantiation.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the component instantiation.
Implementation details
Language specifies the HDL used for a specific instantiation, for example, verilog or vhdl. Strict determines if the language shall be strictly enforced.
Library specifies the library name in which the model should be compiled.
Package describes the VHDL package containing the interface of the model. Defaults to the component VLNV name concatenated with the postfix _cmp_pkg, which stands for component package.
Module name describes the Verilog, SystemVerilog or SystemC module name or the VHDL entity name. Defaults to the component VLNV name.
Architecture describes the VHDL architecture name. Defaults to rtl.
Configuration describes the Verilog, SystemVerilog or VHDL configuration name. Defaults to the design configuration VLNV name of the design configuration referenced in the view, or to the component VLNV name concatenated with the postfix _rtl_cfg.
File set references
File set references is an optional list of file set names that are associated with the component instance. For example, the file set containing the RTL implementation file(s) of the module detailed in Implementation details could be referenced.
Default file build commands
Default file build commands is a list of build options for the file sets referenced in the containing view.
File type defines which files are build by the given command.
Build command defines how to build the files within the file set by e.g. running 'gcc' for C files or 'vcom' for VHDL.
Flags define the command line options for the command e.g. '-Wall'.
Replace default flags selects whether the given flags override the flags defined in the target file or are they appended to them. Replace default flags can be given as an expression, but it must evaluate to 1 or 0.
The defult file build commands contains a context menu, with the following functionalities:
- Add new build command (Add row)
- Remove build command (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Module parameters
Module parameters editor can be used to add, remove and modify module parameters. Module parameters are often used in HDL to configure component instances. They represent e.g VHDL generics and Verilog parameters.
All columns of the editor are editable. Double-clicking an empty space adds a new row.
Name column is mandatory. Display name provides a more user-friendly name for the module parameter. Description is free text for further details.
Legal data type depends on the language of the model. For example in VHDL this could be 'integer' or 'std_logic', whereas in C-language int or 'char*' could be used.
Type is an optional constraint for the type to which the module parameter value resolves. Possible types are:
- bit indicates that the value shall resolve to a System Verilog bit, which by default is resolved to a 1-bit value, unless a vector size has been specified.
- byte indicates that the value shall resolve to a System Verilog byte, which is resolved to an 8-bit integer value.
- shortint indicates that the value shall resolve to a System Verilog shortint, which is resolved to a 16-bit integer value.
- int indicates that the value shall resolve to a System Verilog int, which is resolved to a 32-bit integer value.
- longint indicates that the value shall resolve to a System Verilog longint, which is resolved to a 64-bit integer value.
- shortreal indicates that the value shall resolve to a System Verilog shorint, which is resolved to a 32-bit floating point value. Both standard and scientific format (e.g 0.002 and 2e-3) are supported. This type applies also to minimum value and maximum value.
- real indicates that the value shall resolve to a System Verilog shortreal, which is resolved to a 64-bit floating point value. Both standard and scientific format (e.g. 0.002 and 2e-3) are supported. This type applies also to minimum value and maximum value.
- string indicates that the value shall contain text.
Value contains the mandatory default value of the module parameter. This value can be overridden in a design that instantiates this component. The value is given in SystemVerilog format and may be given as an expression. Any other text must be enclosed within quotes e.g. "Any text".
By selecting a choice, the user can restrict the allowed module parameter values to a set of predefined values. Possible values are defined in the choices of the containing component.
Minimum value and maximum value define the lower and upper boundary for the module parameter value. If the selected type is bit or string, these fields have no effect.
OO usage specifies how this model parameter is used. Default is 'non-typed' since such parameters are found in all languages, i.e. all VHDL types are non-typed. 'Typed' parameters appear in object-oriented languages, i.e. in C++.
Resolve specifies the configuration of the model parameter. Possible resolve values are:
- immediate indicates that the the value is defined within the containing component. The value cannot be overridden by the user or a generator in design configuration. This is the default value
- user indicates that the user can override the default value in design configuration. Generators are not allowed to change the value.
- generated indicates that the a generator can override the default value in design configuration.
Bit vector left and bit vector right define the left and right bounds of the bit vector. These are valid only for a bit type parameter. A valid bit vector requires both the left and the right bit vector values.
Array left and Array right specify the left and right sides of array dimension for the parameter in an output language e.g. Verilog. Both of these are vendor attributes. The values can be given as an expression, but they must resolve into a decimal number. In order to get a valid array, both array left and array right values must be given.
Usage count displays the number of references made to this module parameter. Selecting the usage count of a module parameter displays a reference analysis for it. The usage count can not be changed manually.
Module parameters editor contains a context menu (rigth mouse button) that has the following options:
- Add new module parameter (Add row)
- Remove module parameter (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Parameters
Parameters are optional and can specify any parameter data value(s) specific for this component instantiation. These parameters do not have direct connection to HDL, but may be used to configure IP-XACT elements, including the module parameters. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/componentInstantiation2022.html ================================================
Component instantiation editor
Component instantiation defines how a specific component instance is associated with a view. This editor can be used to edit the details of a component instantiation.
Name is a mandatory identifier for the component instantiation.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for a short description of the component instantiation.
Description is an optional field for textual description of the component instantiation.
Implementation details
Language specifies the HDL used for a specific instantiation, for example, verilog or vhdl. Strict determines if the language shall be strictly enforced.
Library specifies the library name in which the model should be compiled.
Package describes the VHDL package containing the interface of the model. Defaults to the component VLNV name concatenated with the postfix _cmp_pkg, which stands for component package.
Module name describes the Verilog, SystemVerilog or SystemC module name or the VHDL entity name. Defaults to the component VLNV name.
Architecture describes the VHDL architecture name. Defaults to rtl.
Configuration describes the Verilog, SystemVerilog or VHDL configuration name. Defaults to the design configuration VLNV name of the design configuration referenced in the view, or to the component VLNV name concatenated with the postfix _rtl_cfg.
File set references
File set references is an optional list of file set names that are associated with the component instance. For example, the file set containing the RTL implementation file(s) of the module detailed in Implementation details could be referenced.
Default file build commands
Default file build commands is a list of build options for the file sets referenced in the containing view.
File type defines which files are build by the given command.
Build command defines how to build the files within the file set by e.g. running 'gcc' for C files or 'vcom' for VHDL.
Flags define the command line options for the command e.g. '-Wall'.
Replace default flags selects whether the given flags override the flags defined in the target file or are they appended to them. Replace default flags can be given as an expression, but it must evaluate to 1 or 0.
The defult file build commands contains a context menu, with the following functionalities:
- Add new build command (Add row)
- Remove build command (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Module parameters
Module parameters editor can be used to add, remove and modify module parameters. Module parameters are often used in HDL to configure component instances. They represent e.g VHDL generics and Verilog parameters.
All columns of the editor are editable. Double-clicking an empty space adds a new row.
Name column is mandatory. Display name provides a more user-friendly name for the module parameter. Description is free text for further details.
Legal data type depends on the language of the model. For example in VHDL this could be 'integer' or 'std_logic', whereas in C-language int or 'char*' could be used.
Type is an optional constraint for the type to which the module parameter value resolves. Possible types are:
- bit indicates that the value shall resolve to a System Verilog bit, which by default is resolved to a 1-bit value, unless a vector size has been specified.
- byte indicates that the value shall resolve to a System Verilog byte, which is resolved to an 8-bit integer value.
- shortint indicates that the value shall resolve to a System Verilog shortint, which is resolved to a 16-bit integer value.
- int indicates that the value shall resolve to a System Verilog int, which is resolved to a 32-bit integer value.
- longint indicates that the value shall resolve to a System Verilog longint, which is resolved to a 64-bit integer value.
- shortreal indicates that the value shall resolve to a System Verilog shorint, which is resolved to a 32-bit floating point value. Both standard and scientific format (e.g 0.002 and 2e-3) are supported. This type applies also to minimum value and maximum value.
- real indicates that the value shall resolve to a System Verilog shortreal, which is resolved to a 64-bit floating point value. Both standard and scientific format (e.g. 0.002 and 2e-3) are supported. This type applies also to minimum value and maximum value.
- string indicates that the value shall contain text.
Value contains the mandatory default value of the module parameter. This value can be overridden in a design that instantiates this component. The value is given in SystemVerilog format and may be given as an expression. Any other text must be enclosed within quotes e.g. "Any text".
By selecting a choice, the user can restrict the allowed module parameter values to a set of predefined values. Possible values are defined in the choices of the containing component.
Minimum value and maximum value define the lower and upper boundary for the module parameter value. If the selected type is bit or string, these fields have no effect.
OO usage specifies how this model parameter is used. Default is 'non-typed' since such parameters are found in all languages, i.e. all VHDL types are non-typed. 'Typed' parameters appear in object-oriented languages, i.e. in C++. 'Runtime' parameters are parameters, whose value is set at run-time.
Resolve specifies the configuration of the model parameter. Possible resolve values are:
- immediate indicates that the the value is defined within the containing component. The value cannot be overridden by the user or a generator in design configuration. This is the default value
- user indicates that the user can override the default value in design configuration. Generators are not allowed to change the value.
- generated indicates that the a generator can override the default value in design configuration.
Bit vector left and bit vector right define the left and right bounds of the bit vector. These are valid only for a bit type parameter. A valid bit vector requires both the left and the right bit vector values.
Array left and Array right specify the left and right sides of array dimension for the parameter in an output language e.g. Verilog. Both of these are vendor attributes. The values can be given as an expression, but they must resolve into a decimal number. In order to get a valid array, both array left and array right values must be given.
Usage count displays the number of references made to this module parameter. Selecting the usage count of a module parameter displays a reference analysis for it. The usage count can not be changed manually.
Module parameters editor contains a context menu (rigth mouse button) that has the following options:
- Add new module parameter (Add row)
- Remove module parameter (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Parameters
Parameters are optional and can specify any parameter data value(s) specific for this component instantiation. These parameters do not have direct connection to HDL, but may be used to configure IP-XACT elements, including the module parameters. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/componentInstantiations.html ================================================
Component instantiations editor
Component instantiations define how a specific component instance is associated with a view. This editor can be used to add and remove component instantiations.
Each component instantiation contains a mandatory, unique name, a display name and a textual description to identify the component instantiations.
Language specifies the HDL used for a specific instantiation, for example, verilog or vhdl.
Component instantiations editor contains a context menu (right mouse button) providing following options:
- Add new instantiation (Add row)
- Remove instantiation (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Component
An IP-XACT component describes data of any component, both flat and hierarchical, hardware and software. Most importantly it describes components external interface, such as ports and parameters, but also internal features, such as remap state and memory maps. On the other hand, many properties are parametrizable, and thus tied to the external interface.
A component may also refer to non-IP-XACT files, such as HDL source files and documentation. Thus components are vital for integration with non-IP-XACT tools and formats.
================================================ FILE: Help/componenteditor/cpu.html ================================================ CPU editor
The cpu editor can be used to edit the details of a cpu within a component.
Name is a mandatory identifier for the cpu.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the cpu.
General settings
Is present is optional and allows the enabling/disabling of a cpu presence in the component. Value 1 indicates that the cpu is present in the component whereas value 0 marks the cpu to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Address spaces specify the logical address space(s) of the cpu. When a master bus interface of a component references the same address spaces, there's a link link between the programmable core and the interface. This information helps in generating a board support package (BSP) and picking appropriate programmable components into system design. CPU definition should not be repeated on a higher level component (one that instantiates a CPU).
================================================ FILE: Help/componenteditor/cpu2022.html ================================================ CPU editor
The cpu editor can be used to edit the details of a cpu within a component.
Name is a mandatory identifier for the cpu.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the cpu.
Description is an optional field for textual description of the cpu.
General settings
Memory map is mandatory and maps the address space defined by range and width to a memory map in the component.
Range is mandatory and defines the address range in the memory map accessible by the cpu.
Width is mandatory and defines the bit width of a row in the memory map for the cpu.
Address unit bits (AUB) is an optinal field that defines the number of data bits each address increment in the address space contains. The default setting for a cpu address space is byte addressable (8 bits).
Regions
Regions editor can be used to describe sections of the address space available for the cpu by splitting it into smaller regions.
Name is a mandatory identifier for the region.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the region.
Offset is mandatory and defines the starting address of the region in address unit bits.
Range is mandatory and defines the size of the region in address unit bits.
Description is an optional field for textual description of the region.
Regions editor provides a context menu (right mouse button) with the following options:
- Add new region (Add row)
- Remove region (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Copy selected element to clipboard (Copy elements)
- Paste the element from the clipboard (Paste elements)
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
CPUs editor
The cpus editor lists the programmable cores the component contains. This way the tools can recognize them and distinguish from hardwired components. One component can have multiple cores.
Name is a mandatory identifier for the cpu.
Display name is an optional and used for a more user-friendly identifier.
Address space references specify the logical address space of the cpu. When a master bus interface of a component references the same address spaces, there's a link link between the programmable core and the interface. This information helps in generating a board support package (BSP) and picking appropriate programmable components into system design. CPU definition should not be repeated on a higher level component (one that instantiates a CPU).
Description is an optional field for textual description of the cpu.
Cpus editor provides a context menu (right mouse button) with the following options:
- Add new cpu (Add row)
- Remove cpu (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE.
Example SoC has two CPUs and both refer to an address space.
The first CPU is bound to a master bus interface through address space
AS0 whereas the second has only a local memory map in AS1.
Consequently, cpuA has access to the global address space of
the master bus interface and cpuB does not.
CPUs editor
The cpus editor lists the programmable cores the component contains. This way the tools can recognize them and distinguish from hardwired components. One component can have multiple cores.
Name is a mandatory identifier for the cpu.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the cpu.
Memory map reference is mandatory and maps the address space defined by range and width to a memory map in the component.
Range is mandatory and defines the address range in the memory map accessible by the cpu.
Width is mandatory and defines the bit width of a row in the memory map for the cpu.
Address unit bits (AUB) is an optinal field that defines the number of data bits each address increment in the address space contains. The default setting for a cpu address space is byte addressable (8 bits).
Description is an optional field for textual description of the cpu.
Cpus editor provides a context menu (right mouse button) with the following options:
- Add new cpu (Add row)
- Remove cpu (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE.
Example SoC has two CPUs and both refer to a memory map.
The first memory map is bound to an initiator bus interface using
a subspace map whereas the second has only a memory map with registers.
Consequently, cpuA has access to the global address space of the
initiator bus interface and cpuB does not.
Design configuration instantiation editor
Design configuration instantiations detail how a specific design configuration instance is associated with a view. This editor can be used to edit the details of a single design configuration instantiation.
Name is a mandatory identifier for the design configuration instantiation.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the design configuration instantiation.
Design configuration reference specifies the used design configuration.
Configurable element values are instance-specific configuration options. It shows all the design configuration parameters. The value can be set to override the default value in the design configuration. The value is editable only, if the parameter resolve-property is set to 'user' or 'generated' within the design configuration. By default parameters that cannot be edited are filtered out, but will be shown when Show immediate values is selected.
Parameters are optional and can specify any parameter data value(s) specific for this design configuration instantiation. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/designConfigurationInstantiation2022.html ================================================ Design configuration instantiation editor
Design configuration instantiations detail how a specific design configuration instance is associated with a view. This editor can be used to edit the details of a single design configuration instantiation.
Name is a mandatory identifier for the design configuration instantiation.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the design configuration instantiation.
Description is an optional field for textual description of the design configuration instantiation.
Design configuration reference specifies the used design configuration.
Configurable element values are instance-specific configuration options. It shows all the design configuration parameters. The value can be set to override the default value in the design configuration. The value is editable only, if the parameter resolve-property is set to 'user' or 'generated' within the design configuration. By default parameters that cannot be edited are filtered out, but will be shown when Show immediate values is selected.
Parameters are optional and can specify any parameter data value(s) specific for this design configuration instantiation. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/designConfigurationInstantiations.html ================================================ Design configuration instantiations editor
Design configuration instantiations detail how a specific design configuration instance is associated with a view. This editor can be used to add and remove design configuration instantiations.
Each design configuration instantiation contains a mandatory, unique name, a display name and a textual description to identify the design configuration instantiations.
Design configuration reference specifies the used design configuration.
Design configuration instantiations editor contains a context menu (right mouse button) providing following options:
- Add new instantiation (Add row)
- Remove instantiation (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Design instantiation editor
Design instantiations specify how a specific design instance is associated with a view. This editor can be used to edit the details of a single design instantiation.
Name is a mandatory identifier for the design instantiation.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the design instantiation.
Design reference details the design description and configuration values applied to it.
Configurable element values are instance-specific configuration options. It shows all the design parameters. The value can be set to override the default value in the design. The value is editable only, if the parameter resolve-property is set to 'user' or 'generated' within the design. By default parameters that cannot be edited are filtered out, but will be shown when Show immediate values is selected.
================================================ FILE: Help/componenteditor/designInstantiation2022.html ================================================ Design instantiation editor
Design instantiations specify how a specific design instance is associated with a view. This editor can be used to edit the details of a single design instantiation.
Name is a mandatory identifier for the design instantiation.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the design instantiation.
Description is an optional field for textual description of the design instantiation.
Design reference details the design description and configuration values applied to it.
Configurable element values are instance-specific configuration options. It shows all the design parameters. The value can be set to override the default value in the design. The value is editable only, if the parameter resolve-property is set to 'user' or 'generated' within the design. By default parameters that cannot be edited are filtered out, but will be shown when Show immediate values is selected.
================================================ FILE: Help/componenteditor/designInstantiations.html ================================================ Design instantiations editor
Design instantiations specify how a specific design instance is associated with a view. This editor can be used to add and remove design instantiations.
Each design instantiation contains a mandatory, unique name, a display name and a textual description to identify the design instantiations.
Design reference details the design description and configuration values applied to it.
Design instantiations editor contains a context menu (right mouse button) providing following options:
- Add new instantiation (Add row)
- Remove instantiation (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Field editor
The field editor is used to edit the details of a field. For example user may define enumerated values that define the legal bit patterns of the field.
Name is a mandatory identifier for the field. The name must be unique within all the fields of the containing register.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the field.
Field definition
Offset is mandatory and describes the starting bit of the field within the containing register.
Width is mandatory and speficies how many bits are included in the field.
Is present is optional and enables/disables a field presence in a register. Value 1 indicates that the field is present in the register whereas value 0 marks the field to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Field ID is optional identifier for the field. Fields can be referenced in indirect interfaces using this identifier.
Field constraints
Volatile is optional and indicates that the field may change its value without write operations.
Access is optional and specifies the accessability of the field. The possible values are:
- read-write. Both read and write transactions may have an effect on this field. Write transactions may affect the contents of the field, and read transactions return a value related to the field.
- read-only. A read transaction to this field returns a value related to the value in the field. A write transaction to this field has undefined results.
- write-only. A write transaction to this address affects the contents of the field. A read transaction to this field has undefined results.
- read-writeOnce. Both read and write transactions may have an effect on this field. Only the first write transaction may affect the contents of the field, and read transactions return a value related to the values in the field.
- writeOnce. Only the first write transaction affects the contents of this field.
Modified write value is optional and describes how the data in the field is manipulated on a write operation. The basic operation without any setting is to store the written value 'as is'. Moreover, both bitwise and field-wise set/clear/toggle is also possible. The possible values are:
- oneToClear. Each written '1' bit will assign the corresponding bit to '0'.
- oneToSet. Each written '1' bit will assign the corresponding bit to '1'.
- oneToToggle. Each written '1' bit will toggle the corresponding bit.
- zeroToClear, zeroToSet, zeroToToggle. Similar to previous ones, except that written '0' bit triggers the action.
- clear. Each write operation will clear all bits in the field to '0'.
- set. Each write operation will set all bits in the field to '1'.
- modify. Indicates that after a write operation, all bits in the field can be modified.
- ' ' (empty setting). Indicates that the value written to a field is the value stored in the field. This is the default value.
Read action is optional and specifies if some action happens to the field after a read operation. By default the field is unmodified. The possible values are:
- clear. All bits in the field are cleared to '0' after a read operation.
- set. All bits in the field are set to '1' after a read operation.
- modify. Indicates that the bits of the field are modified in some way after a read operation.
- ' ' (empty setting). Indicates that the field is not modified after a read operation. This is the default.
Testable is optional and specifies if the field is testable by an automated register test.
Test constraint is optional and specifies the constaints for the automated tests for the field. The possible values are:
- unConstrained. There are no constraints for the written or read data. This is the default setting.
- Restore. The field value must be restored to its original value before accessing another register.
- WriteAsRead. The data written to a field must be same that was read previously from the field
- ReadOnly. Indicates that the field can only be read.
The write value constraints are used to define what are the legal values user may write to a field. The possible values are:
- No constraints. Indicates that there are no constraints to values to be written.
- Write as read. Inidcates that only legal values to be written are the same that were previously read from the field.
- Use enumerated values. Indicates that the defined enumerated values are the only legal values that can be written.
- Set minimum and maximum limits. Indicates that the minimum and maximum limits can be set for the value written to the field.
Resets
Resets describe the reset values of the field. Each reset has the following subelements:
- Reset type reference. Identifies the defined reset. This should correspond to a user-defined reset type element. Default value is HARD, and only one reset can be defined as that.
- Reset value is mandatory and defines the actual reset value on reset. Reset value uses SystemVerilog syntax for binary values. The number of bits must be equal to the field size.
- Reset mask is optional and defines the bits that have a known reset value. Bit value of 1 means that the corresponding bit has a known reset value whereas 0 means that the value is unknown. Reset mask uses SystemVerilog syntax for binary values e.g. 'b1011, 4'b1011, and 4'b10_11 are all valid values. The number of bits must be equal to the field size.
Enumerations table
The enumerated values table enables the defining of bit patterns that can be identified by a name. This can be used to define the legal bit patterns for a field or to define some default settings to help configuration of the field.
Each enumeration contains a unique name of the enumeration (mandatory), an optional display name and description.
Value defines the value to assign to the specified name (mandatory).
Usage defines the software access condition under which this name value pair is valid. Possible values are: read, write and read-write.
================================================ FILE: Help/componenteditor/field2022.html ================================================ Field editor
The field editor is used to edit the details of a field. For example user may define enumerated values that define the legal bit patterns of the field.
Name is a mandatory identifier for the field. The name must be unique within all the fields of the containing register.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the field.
Description is an optional field for textual description of the field.
Field definition
Offset is mandatory and describes the starting bit of the field within the containing register.
Width is mandatory and speficies how many bits are included in the field.
Volatile is optional and indicates that the field may change its value without write operations.
Resets
Resets describe the reset values of the field. Each reset has the following subelements:
- Reset type reference. Identifies the defined reset. This should correspond to a user-defined reset type element. Default value is HARD, and only one reset can be defined as that.
- Reset value is mandatory and defines the actual reset value on reset. Reset value uses SystemVerilog syntax for binary values. The number of bits must be equal to the field size.
- Reset mask is optional and defines the bits that have a known reset value. Bit value of 1 means that the corresponding bit has a known reset value whereas 0 means that the value is unknown. Reset mask uses SystemVerilog syntax for binary values e.g. 'b1011, 4'b1011, and 4'b10_11 are all valid values. The number of bits must be equal to the field size.
Enumerations table
The enumerated values table enables the defining of bit patterns that can be identified by a name. This can be used to define the legal bit patterns for a field or to define some default settings to help configuration of the field.
Each enumeration contains a unique name of the enumeration (mandatory), an optional display name and description.
Value defines the value to assign to the specified name (mandatory).
Usage defines the software access condition under which this name value pair is valid. Possible values are: read, write and read-write.
Field access policies table
Field access policies define field access properties for different operating modes.
Mode(s) contains references to component modes. It is optional, and defines for which component modes the field access policy is active. If a field access policy contains no mode references, it is active for all component modes not already referenced by other field access policies (i.e. only one field access policy without mode references may exist). A field access policy is active, if it references an active mode and has the highest priority (i.e. the lowest priority value) among the field access policies of the field.
Access is optional and specifies the accessability of the field when that field access policy is active. The possible values are:
- read-write. Both read and write transactions may have an effect on this field. Write transactions may affect the contents of the field, and read transactions return a value related to the field.
- read-only. A read transaction to this field returns a value related to the value in the field. A write transaction to this field has undefined results.
- write-only. A write transaction to this address affects the contents of the field. A read transaction to this field has undefined results.
- read-writeOnce. Both read and write transactions may have an effect on this field. Only the first write transaction may affect the contents of the field, and read transactions return a value related to the values in the field.
- writeOnce. Only the first write transaction affects the contents of this field.
Read action is optional and specifies if some action happens to the field after a read operation. By default the field is unmodified. The possible values are:
- clear. All bits in the field are cleared to '0' after a read operation.
- set. All bits in the field are set to '1' after a read operation.
- modify. Indicates that the bits of the field are modified in some way after a read operation.
- ' ' (empty setting). Indicates that the field is not modified after a read operation. This is the default.
Read response is optional and describes the expected read value of the field in a certain mode. If not present, then the reset value is expected to be read.
Testable is optional and specifies if the field is testable by an automated register test.
Test constraint is optional and specifies the constaints for the automated tests for the field. Can be set only when testable is set to true. The possible values are:
- unConstrained. There are no constraints for the written or read data. This is the default setting.
- Restore. The field value must be restored to its original value before accessing another register.
- WriteAsRead. The data written to a field must be same that was read previously from the field
- ReadOnly. Indicates that the field can only be read.
Reserved is optional and indicates if the field is reserved for other use.
Modified write value is optional and describes how the data in the field is manipulated on a write operation. The basic operation without any setting is to store the written value 'as is'. Moreover, both bitwise and field-wise set/clear/toggle is also possible. The possible values are:
- oneToClear. Each written '1' bit will assign the corresponding bit to '0'.
- oneToSet. Each written '1' bit will assign the corresponding bit to '1'.
- oneToToggle. Each written '1' bit will toggle the corresponding bit.
- zeroToClear, zeroToSet, zeroToToggle. Similar to previous ones, except that written '0' bit triggers the action.
- clear. Each write operation will clear all bits in the field to '0'.
- set. Each write operation will set all bits in the field to '1'.
- modify. Indicates that after a write operation, all bits in the field can be modified.
- ' ' (empty setting). Indicates that the value written to a field is the value stored in the field. This is the default value.
The write value constraints are used to define what are the legal values user may write to a field. The possible values are:
- No constraints. Indicates that there are no constraints to values to be written.
- Write as read. Inidcates that only legal values to be written are the same that were previously read from the field.
- Use enumerated values. Indicates that the defined enumerated values are the only legal values that can be written.
- Set minimum and maximum limits. Indicates that the minimum and maximum limits can be set for the value written to the field.
File editor
File editor can be used to edit the details of a single file within a file set.
Name field contains the relative file path from the containing component XML-file to this file. The name can be changed in the file set editor.
Description shows a used given description regarding the currently active file.
File types list specifies the type of the file. File type can be used i.e. when specifying build commands for a group of files. A file can have multiple file types.
General options
Logical name specifies e.g. a VHDL library where the VHDL-file will be compiled to.
Generators can override logical name defines if the logical name can be
overridden by another process.
File is structural RTL indicates if the file contains only a structural Register Transfer Level (RTL) description i.e. no behavioral code.
File is include file indicates if the file is an include file e.g. C-header file.
File contains external declarations can be used to indicate that the file contains external declarations and is needed by other files in this file set.
Build command
Target file specifies a path to the file that is derived from this file when build process is run. A new file path can be entered or an existing file can be searched with "Browse...".
Build command can be used to define a build command and flags specific to this file. For example, a C-source file could have a build command 'gcc' with flags '-O2'.
Flags can either replace default flags (e.g. those specified for this file type) in the build script or be appended to them. The value can be given as an expression, but must evaluate to 1 or 0.
External dependencies and defines
Exported names contains a list names defined within the file that can be referenced externally.
Image types contains a list of the current files relations to executable image types in the design.
Dependent directories contains a list of directory paths containing (include) files on which the file depends.
================================================ FILE: Help/componenteditor/fileset.html ================================================ File set editor
File set editor can be used to edit the details of a single file set. These file sets can be used to group files together to be referenced by other sections of a component.
Name is a mandatory identifier for the file set.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the file set.
Group identifier can be used to describe the function or purpose of the file set with a single unbounded word. Group identifiers can contain several identifiers and the number of possible identifiers is not limited. However, the editor suggests the following options:
- diagnostics
- documentation
- projectFiles
- simulation
- sourceFiles
Files
Files editor lists the files contained within the file set.
Each file has a file name identifying the file. The name is mandatory and it is determined automatically from the file path.
File path is mandatory and defined as relative to the component XML-file, as an absolute path or as an external URI. If an URI is used, the schema must be explicitly defined (e.g. http://...).
File type is mandatory and helps categorize the file and links files to their build command (see below). A file can have more than one type.
Description is a freely formatted text describing a single file.
New files can be added by creating new rows, browsing the files using the context menu option described below or by drag-dropping the files onto the editor. If the order of files is important for e.g. compilation then the files should be listed in the required order. The order of the files can be changed by dragging the rows.
The files box also contains a context menu (right mouse button) that has the following options:
- Add new files to the file set by browsing the file system (Add file(s)...)
- Add new file to the file set (Add row)
- Remove file from file set (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
Default build commands
Default build command defines how to build the files within the file set by e.g. running gcc for C files or vcom for VHDL.
File type defines which files are build by the given command.
Flags define the command line options for the command e.g. -Wall.
The defined command can either replace default flags defined in the target file or be appended to it. The value can be given as an expression, but must evaluate to 1 or 0.
Dependent directories
Dependent directories can specify a freetext list of paths to directories on which this file set depends, e.g. directories of include files.
================================================ FILE: Help/componenteditor/fileset2022.html ================================================ File set editor
File set editor can be used to edit the details of a single file set. These file sets can be used to group files together to be referenced by other sections of a component.
Name is a mandatory identifier for the file set.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the file set.
Description is an optional field for textual description of the file set.
Group identifier can be used to describe the function or purpose of the file set with a single unbounded word. Group identifiers can contain several identifiers and the number of possible identifiers is not limited. However, the editor suggests the following options:
- diagnostics
- documentation
- projectFiles
- simulation
- sourceFiles
Files
Files editor lists the files contained within the file set.
Each file has a file name identifying the file. The name is mandatory and it is determined automatically from the file path.
File path is mandatory and defined as relative to the component XML-file, as an absolute path or as an external URI. If an URI is used, the schema must be explicitly defined (e.g. http://...).
File type is mandatory and helps categorize the file and links files to their build command (see below). A file can have more than one type.
Description is a freely formatted text describing a single file.
New files can be added by creating new rows, browsing the files using the context menu option described below or by drag-dropping the files onto the editor. If the order of files is important for e.g. compilation then the files should be listed in the required order. The order of the files can be changed by dragging the rows.
The files box also contains a context menu (right mouse button) that has the following options:
- Add new files to the file set by browsing the file system (Add file(s)...)
- Add new file to the file set (Add row)
- Remove file from file set (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
Default build commands
Default build command defines how to build the files within the file set by e.g. running gcc for C files or vcom for VHDL.
File type defines which files are build by the given command.
Flags define the command line options for the command e.g. -Wall.
The defined command can either replace default flags defined in the target file or be appended to it. The value can be given as an expression, but must evaluate to 1 or 0.
Dependent directories
Dependent directories can specify a freetext list of paths to directories on which this file set depends, e.g. directories of include files.
================================================ FILE: Help/componenteditor/filesets.html ================================================ File sets editor
File sets editor contains a summary table regarding each file set within the component. This table can be used to add and remove file sets.
Name is a mandatory identifier for the file set.
Group identifiers are optional and can be used to describe the function or purpose of the file with a single word. Group identifiers can contain multiple identifiers and the possible words are not limited. However, the editor suggests the following options:
- diagnostics
- documentation
- projectFiles
- simulation
- sourceFiles
Description is optional field for detailed description of the file set.
Right clicking an item in the editor provides a context menu that can be used to:
- Add a new file set to the component (Add row)
- Remove a file set (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
File dependencies
Below the file sets editor is a dependency table to display the dependencies between the files within all the file sets. File dependencies are typically introduced by include directives (e.g. in C) or instantiation of other modules (e.g. sub-modules in Verilog). Kactus2 uses plugins to automatically analyse dependencies based on the file types.
Status shows if the file has changed since the last dependency analysis.
Path identifies the file.
Filesets shows the fileset(s) containing the file.
# column is used create custom dependencies. The first left-click on the mouse starts the dependency from the file on the clicked line and the second click ends the dependency to the file on the line. The first file is now dependent on the second file.
Dependencies show the dependencies for the file. A file dependent on another has a round end point of the arrow on the line whereas the required file has an arrow head on the line. Automatically created dependencies are denoted in black and user created dependencies in magenta. A file can have arbitrary number of depenedencies. Clicking on the arrow shows additional information about the dependency in the Dependency Information below.
File set source directories
Kactus2 will search the directories defined here for files to be automatically added into the component file sets.
Dependency information
Description displays the description of the file dependency.
Bidirectional indicates that both of the files are dependent on each other.
Locked can be set to protect the depencendy from being changed without explicitly re-opening the lock.
Reverse Direction changes the dependent and prerequisite file relation to the opposite of the current state.
EXAMPLE. The names of filesets do not need to be same as directories
(vhdlSource vs. vhd/) but they can be (e.g. syn).
General editor
General editor contains the general information of a component.
VLNV-identifier and the file path to the xml-file are shown on top. These fields cannot be modified after creation. Changes require that the component must be saved as new component with new VLNV.
Compatibility shows the component IP-XACT revision compatibility.
Description text box can store a textual description of the component.
Kactus attributes
Kactus attributes help to classify and categorize one's
IPs. They are Kactus2-specific extension to the IP-XACT standard
and describe the level (single IP vs. system), implementation
style, and whether modification is allowed. Only the
implementation style applies for SW components.
| Attribute name | Attribute value | Value description |
|---|---|---|
| Product hierarchy | Product | Whole product, which may contain multiple boards and computers. |
| Board | Represents circuit board, e.g. develoment- or final hardware platform. | |
| Chip | Represents a physical chip i.e. some specific FPGA-chip. | |
| SoC | A system on chip, set of intercconected IPs. | |
| IP | A single IP-block (which might be hierarchical) | |
| Flat | Does not fit into any other category. | |
| Firmness | Template | Used as a base for creating new components, but must not be used as such. It should be copied and then saved with new VLNV. |
| Mutable | Component is fully modifiable. | |
| Fixed | Component cannot be configured in any way and it is frozen to it's final state. | |
| Implementation (cannot be modified after creation) | HW | Hardware implementation, such as VHDL or Verilog |
| SW | Software implementation, such as C | |
| SYS | Contains information about the SW component mapping to the underlying HW platform. |
Tags is an optional set of user-defined categorizations for the component. Each tag has a name and a color. Tags can be used to filter items in the IP-XACT library view.
Copyright information
Author is an optional field for the author of the component.
License is an optional field for identifying the license applicable to the component.
XML header
XML header shows and allows editing the comment lines in the beginning of XML file, i.e. those inside tags <!-- and -->.
Component preview
Component preview box on the right of the editor displays how the component will look like when instantiated in a design. The preview displays the bus interfaces of the component and also the ports that are marked as ad-hoc.
================================================ FILE: Help/componenteditor/general2022.html ================================================ General editor
General editor contains the general information of a component.
VLNV-identifier and the file path to the xml-file are shown on top. These fields cannot be modified after creation. Changes require that the component must be saved as new component with new VLNV.
Compatibility shows the component IP-XACT revision compatibility.
Display name is an optional field and used for a more user-friendly identifier.
Short description is an optional field for compact description of the component.
Description text box can store a textual description of the component.
Kactus attributes
Kactus attributes help to classify and categorize one's
IPs. They are Kactus2-specific extension to the IP-XACT standard
and describe the level (single IP vs. system), implementation
style, and whether modification is allowed. Only the
implementation style applies for SW components.
| Attribute name | Attribute value | Value description |
|---|---|---|
| Product hierarchy | Product | Whole product, which may contain multiple boards and computers. |
| Board | Represents circuit board, e.g. develoment- or final hardware platform. | |
| Chip | Represents a physical chip i.e. some specific FPGA-chip. | |
| SoC | A system on chip, set of intercconected IPs. | |
| IP | A single IP-block (which might be hierarchical) | |
| Flat | Does not fit into any other category. | |
| Firmness | Template | Used as a base for creating new components, but must not be used as such. It should be copied and then saved with new VLNV. |
| Mutable | Component is fully modifiable. | |
| Fixed | Component cannot be configured in any way and it is frozen to it's final state. | |
| Implementation (cannot be modified after creation) | HW | Hardware implementation, such as VHDL or Verilog |
| SW | Software implementation, such as C | |
| SYS | Contains information about the SW component mapping to the underlying HW platform. |
Tags is an optional set of user-defined categorizations for the component. Each tag has a name and a color. Tags can be used to filter items in the IP-XACT library view.
Copyright information
Author is an optional field for the author of the component.
License is an optional field for identifying the license applicable to the component.
XML header
XML header shows and allows editing the comment lines in the beginning of XML file, i.e. those inside tags <!-- and -->.
Validation
Component preview
Component preview box on the right of the editor displays how the component will look like when instantiated in a design. The preview displays the bus interfaces of the component and also the ports that are marked as ad-hoc.
================================================ FILE: Help/componenteditor/indirectInterface.html ================================================ Indirect interface editor
Indirect interface editor is used to edit the details of a single indirect interface. An indirect interface defines access to memory maps that are not directly accessible through a standard bus interface. The indirect memory map is either a memory map within the containing component or accessed through a master bus interface of this component using a transparent bridge.
Name is a mandatory identifier for the indirect interface. The name must be unique within all the indirect interface of the containing component.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the indirect interface.
General
Indirect address field is mandatory and defines the bit field used for addressing in the indirect interface.
Indirect data field is mandatory and defines the bit field used for data in read/write operations in the indirect interface.
Bits in Lau is optional and defines the number of bits addressable by the least significant address bit.
Endianness is optional and indicates whether the interface is 'big-endian' or 'little-endian' (default).
Indirect access target
Memory map defines the indirectly accessible memory map for the indirect interface. If a memory map has been defined, transparent bridges must be left empty.
Transparent bridge(s) define the master bus interface(s) that all transactions through this indirect interface are directed out of. If transparent bridges have been defined, memory map must be left empty.
Parameters
Parameters are optional and can specify any parameter data value(s) specific for this indirect interface. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/indirectInterface2022.html ================================================ Indirect interface editor
Indirect interface editor is used to edit the details of a single indirect interface. An indirect interface defines access to memory maps that are not directly accessible through a standard bus interface. The indirect memory map is either a memory map within the containing component or accessed through a master bus interface of this component using a transparent bridge.
Name is a mandatory identifier for the indirect interface. The name must be unique within all the indirect interface of the containing component.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the indirect interface.
Description is an optional field for textual description of the indirect interface.
General
Indirect address field is mandatory and defines the bit field used for addressing in the indirect interface.
Indirect data field is mandatory and defines the bit field used for data in read/write operations in the indirect interface.
Bits in Lau is optional and defines the number of bits addressable by the least significant address bit.
Endianness is optional and indicates whether the interface is 'big-endian' or 'little-endian' (default).
Indirect access target
Memory map defines the indirectly accessible memory map for the indirect interface. If a memory map has been defined, transparent bridges must be left empty.
Transparent bridge(s) define the master bus interface(s) that all transactions through this indirect interface are directed out of. If transparent bridges have been defined, memory map must be left empty.
Parameters
Parameters are optional and can specify any parameter data value(s) specific for this indirect interface. For more information on parameters, see the component parameter editor.
================================================ FILE: Help/componenteditor/indirectInterfaces.html ================================================ Indirect interfaces editor
Indirect interfaces editor contains the summary of the indirect interfaces of the component. An indirect interface is used to define access to memory maps that are not directly accessible through a bus interface. This editor can be used to add and remove indirect interfaces to the containing component.
Name is a mandatory identifier for the indirect interface. The name must be unique within all the indirect interface of the containing component.
Display name is an optional and used for a more user-friendly identifier.
Indirect address field is mandatory and defines the bit field used for addressing in the indirect interface. A field ID must be defined for the field to be considered a valid option here.
Indirect data field is mandatory and defines the bit field used for data in read/write operations in the indirect interface. A field ID must be defined for the field to be considered a valid option here.
Memory map defines the indirectly accessible memory map for the indirect interface. If a memory map has been defined, transparent bridges must be left empty.
Transparent bridges define the master bus interface(s) that all transactions through this indirect interface are directed out of. If transparent bridges have been defined, memory map must be left empty. Transparent bridges are shown here, but must be edited in the editor of the respective indirect interface.
Description is an optional field for textual description of the indirect interface.
EXAMPLE 1. The memory map MM0 is accessible through slave bus interface accessIF.
Indirect interface II0 identifies bitfields data and address in registers r0 and
r1 which are used to access memory map MM1. The access to memory map
MM1 occurs at the memory location defined by the content of the address field and
the content of the field data is either written into register r6 in a write operation
or read from r6 into field data in a read operation.
EXAMPLE 2. The memory map MM0 is accessible through slave bus interface accessIF.
Indirect interface II0 identifies bitfields data and address in registers r0 and
r1 which are used to access other components through master bus interface outIF.
Instantiations editor
Instantiations editor provides a summary of the different instantiations of the component. Instantiations are used in views to represent different aspects of the view. Instantiations contain a mandatory, unique name, a display name and a textual description to identify the instantiations. This editor can be used to add and remove instantiations.
A component instantiation describes the details of instantiating the component in a hardware description language, for example, verilog or vhdl. This editor can be used to add and remove component instantiations.
A design configuration instantiation details how a specific design configuration instance is
associated with a view. This editor can be used to add and remove design configuration
instantiations.
Design configuration reference specifies the used design configuration.
A design instantiation specifies how a specific design instance is associated with a view. This
editor can be used to add and remove design instantiations.
Design reference details the design description and configuration values applied to it.
The editor contains a context menu that contains following options:
- Add a new instantiation (Add row)
- Remove an instantiation (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
================================================ FILE: Help/componenteditor/memorymap.html ================================================
Memory map editor
Memory map editor can be used to edit the details of a memory map.
Memory maps visualization is shown on the right of the editor. The visualization
can be expandped and minimized by clicking the expand arrow
and the minimize arrow
. Selecting any part
of the visualization will open the editor set for that item. The visualization can
be resized by dragging the border between the editor and the visualization. Holding
Ctrl-key while scrolling with the mouse wheel increases/decreases the width of the
items.
Name is a mandatory identifier for the memory map.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the memory map.
Address unit bits (AUB) defines the number of data bits each address increment of the memory map contains, e.g. 8b or 32b. The default setting for a memory map is byte addressable (8 bits). E.g. if AUB=8, then 32-bit registers are at addresses 0x0, 0x4, 0x8... If AUB=32, they are in addresses 0x0, 0x1, 0x2... AUB is the unit for base addresses and ranges within the address map.
Is present is optional and allows enabling/disabling of a memory map presence in a component. Value 1 indicates that the memory map is present in the component whereas value 0 marks the memory map to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Remap state identifies the name of the remap state for which the optional memory map elements are active. Memory maps are labeled with a default remap state, while memory remaps must be given a remap state. For more information on the remap states, see the remap states editor.
Slave interface binding shows which slave bus interfaces are used to access the memory map. The binding can only be set in the bus interface editor, but is shown here for convenience.
Address blocks table
Address block specifies a single contiguous block, either a set of registers or a block of memory. Registers within the address block are further divided into bit fields. (IP-XACT allows bank or subspaceMap elements within the address block, but they are not yet supported by Kactus2 (v3.3, December 2016)).
Name is a mandatory identifier for the address block.
Base address is mandatory and specifies the starting address for the address block. It is expressed as address unit bits as defined in the containing memory map, e.g. 8 or 32 bits.
Range is mandatory and specifies the size of the block in address unit bits.
Width is mandatory and specifies the data width in bits of a row in the address block. It sets the maximum allowed size of a single transfer and also defines the maximum size of a single register. Register can be smaller but not wider than the value.
Usage is optional and is used to categorize the usage of the address block. The possible values are:
- Memory specifies the address block as memory. A memory address block cannot contain registers.
- Register specifies the entire address block to contain registers.
- Reserved specifies the entire address block as reserved for usage that is unknown to IP-XACT. A reserved address block cannot include registers.
Access is optional and is used to specify the accessibility of the address block. The possible values are:
- read-write. Both read and write transactions may have an effect on this address block.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Read actions are allowed and the first write action may have an effect on this address block.
- writeOnce. Only the first write action affects the contents of this address block.
Volatile is optional and indicates that the stored value may change without master's write operation. For example, the timer value gets updated automatically and master must always issue a read to get the latest value.
Is present is optional and allows enabling/disabling of a address block presence in a memory map. Value 1 indicates that the address block is present in the memory map whereas value 0 marks the memory map to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the address block.
Subspace maps table
Name is a mandatory identifier for the subspace map.
Base address is mandatory and specifies the starting address for the subspace map in address unit bits. The range is equal to the referenced address space or segment.
Master interface is a mandatory identifier for the bridged master bus interface that is accessed by the subspace map.
Segment is an optional reference to a segment within the referenced master bus interface. If a segment is defined, the access is limited to the specified segment instead of the whole address space.
Is present is optional and allows enabling/disabling of a subspace map presence in a memory map. Value 1 indicates that the subspace map is present in the memory map whereas value 0 marks the subspace map to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
EXAMPLE 1. A simple IP could have 1 memory map, 1 address block inside it, and three
32-bit registers: ctrl, data_in, and data_out. Ctrl allows both read and write accesses,
data_in is write-only, and data_out is read-only. The lower part of ctrl register
is divided into two 8-bit fields and designer can describe how they are used. The
upper bits are not used. Data registers do not have field definitions.
Number of Addresss unit bits(AUB) of the memory map is set to 8 bits. There are
3 registers with identical size (32b), Hence, range = 12 = 3 * 32/AUB = 3 * 32/8
= 3 * 4. Let's assume base address=0x100. Since address block has 12 Bytes in total,
it reserves the (byte) addresses 0x100-0x10B. It is good to set the width of the
address block 32 b so that full register can be accessed at once. Smaller accesses
(e.g. 1 byte at a time) are also allowed.
EXAMPLE 2. An opaque bridge provides access from a slave interface
to a master interface through a specific memory region i.e. a subspace map.
The address space and any memory maps connected to the master interface
remain obscured (opaque) behind the subspace map.
The slave bus interface accessIF provides access to memory map MM0 which contains
an address block ab0 and a subspace map ssm0. The subspace map refers master bus
interface outIF indicating that any access to memory locations within ssm0 are redirected
out of bus interface outIF. The subspace map size will match the address space AS0 range
(or segment range, if segment is specified) referenced in master interface outIF.
Any interface connected to accessIF will have visibility only to ab0 and ssm0 within the
memory map MM0 and no visibility to AS0 while still being able to transfer data to
components connected to outIF.
Memory map editor
Memory map editor can be used to edit the details of a memory map.
Memory maps visualization is shown on the right of the editor. The visualization
can be expandped and minimized by clicking the expand arrow
and the minimize arrow
. Selecting any part
of the visualization will open the editor set for that item. The visualization can
be resized by dragging the border between the editor and the visualization. Holding
Ctrl-key while scrolling with the mouse wheel increases/decreases the width of the
items.
Name is a mandatory identifier for the memory map.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the memory map.
Description is an optional field for textual description of the memory map.
Address unit bits (AUB) defines the number of data bits each address increment of the memory map contains, e.g. 8b or 32b. The default setting for a memory map is byte addressable (8 bits). E.g. if AUB=8, then 32-bit registers are at addresses 0x0, 0x4, 0x8... If AUB=32, they are in addresses 0x0, 0x1, 0x2... AUB is the unit for base addresses and ranges within the address map.
Target interface binding shows which target bus interfaces are used to access the memory map. The binding can only be set in the bus interface editor, but is shown here for convenience.
Mode references identify operating modes for which a memory remap is active. Memory maps do not contain mode references, while memory remaps must be given at least one mode reference paired with a priority value. Each mode reference value must be unique within the containing memory map, while priorities do not have such limitations.
Address blocks table
Address block specifies a single contiguous block, either a set of registers or a block of memory. Registers within the address block are further divided into bit fields.
Name is a mandatory identifier for the address block.
Base address is mandatory and specifies the starting address for the address block. It is expressed as address unit bits as defined in the containing memory map, e.g. 8 or 32 bits.
Range is mandatory and specifies the size of the block in address unit bits.
Width is mandatory and specifies the data width in bits of a row in the address block. It sets the maximum allowed size of a single transfer and also defines the maximum size of a single register. Register can be smaller but not wider than the value.
Usage is optional and is used to categorize the usage of the address block. The possible values are:
- Memory specifies the address block as memory. A memory address block cannot contain registers.
- Register specifies the entire address block to contain registers.
- Reserved specifies the entire address block as reserved for usage that is unknown to IP-XACT. A reserved address block cannot include registers.
Access is optional and specifies the accessibility of the address block by modifying the first access policy of the address block. If multiple access policies exist, then the access value cannot be edited here and must be edited for each access policy separately in the address block editor. If no access policy exists, then one will be created for the address block when the access value is edited here. The possible access values are:
- read-write. Both read and write transactions may have an effect on this address block.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Read actions are allowed and the first write action may have an effect on this address block.
- writeOnce. Only the first write action affects the contents of this address block.
Volatile is optional and indicates that the stored value may change without initiator's write operation. For example, the timer value gets updated automatically and initiator must always issue a read to get the latest value.
Description is an optional field for textual description of the address block.
Subspace maps table
Name is a mandatory identifier for the subspace map.
Base address is mandatory and specifies the starting address for the subspace map in address unit bits. The range is equal to the referenced address space or segment.
Initiator interface is a mandatory identifier for the bridged initiator bus interface that is accessed by the subspace map.
Segment is an optional reference to a segment within the referenced initiator bus interface. If a segment is defined, the access is limited to the specified segment instead of the whole address space.
Description is an optional field for textual description of the subspace map.
EXAMPLE 1. A simple IP could have 1 memory map, 1 address block inside it, and three
32-bit registers: ctrl, data_in, and data_out. Ctrl allows both read and write accesses,
data_in is write-only, and data_out is read-only. The lower part of ctrl register
is divided into two 8-bit fields and designer can describe how they are used. The
upper bits are not used. Data registers do not have field definitions.
Number of Addresss unit bits(AUB) of the memory map is set to 8 bits. There are
3 registers with identical size (32b), Hence, range = 12 = 3 * 32/AUB = 3 * 32/8
= 3 * 4. Let's assume base address=0x100. Since address block has 12 Bytes in total,
it reserves the (byte) addresses 0x100-0x10B. It is good to set the width of the
address block 32 b so that full register can be accessed at once. Smaller accesses
(e.g. 1 byte at a time) are also allowed.
EXAMPLE 2. An opaque bridge provides access from a target interface
to an initiator interface through a specific memory region i.e. a subspace map.
The address space and any memory maps connected to the initiator interface
remain obscured (opaque) behind the subspace map.
The target bus interface accessIF provides access to memory map MM0 which contains
an address block ab0 and a subspace map ssm0. The subspace map refers initiator bus
interface outIF indicating that any access to memory locations within ssm0 are redirected
out of bus interface outIF. The subspace map size will match the address space AS0 range
(or segment range, if segment is specified) referenced in initiator interface outIF.
Any interface connected to accessIF will have visibility only to ab0 and ssm0 within the
memory map MM0 and no visibility to AS0 while still being able to transfer data to
components connected to outIF.
Memory maps editor
Memory maps editor contains the summary of the memory maps and memory remaps contained in the component and can be used to add, remove and edit them.
Memory maps visualization is shown on the right of the editor. The visualization can be expandped
and minimized by clicking the expand arrow
and the minimize arrow . Selecting any part
of the visualization will open the editor set for that item. The visualization can be resized by dragging
the border between the editor and the visualization.
Holding Ctrl-key while scrolling with the mouse wheel increases/decreases the width of the items.
Memory map specifies the addressable area seen through a slave bus interface, e.g. the data and control register.
Memory remap describes additional memory map items that are mapped on the referencing slave bus interface in a specific remap state. If multiple memory remaps or remap state attributes are active, then the first memory remap listed shall be selected.
Memory map
Name is a mandatory identifier for the memory map.
Remap state is always 'default' for memory maps and cannot be changed. It applies only to memory remaps.
Address unit bits (AUB) defines the number of data bits each address increment of the memory map contains, e.g. 8b or 32b. The default setting for a memory maps is byte addressable (8 bits). E.g. if AUB=8, then 32-bit registers are at addresses 0x0, 0x4, 0x8... If AUB=32, they are in addresses 0x0, 0x1, 0x2... AUB is the unit for base addresses and ranges within the address map.
Slave interface binding shows which slave bus interfaces are used to access the memory map. The binding can only be set in the bus interface editor, but is shown here for convenience.
Is present is optional and allows enabling/disabling of a memory map presence in a component. Value 1 indicates that the memory map is present in the component whereas value 0 marks the memory map to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the memory map.
Memory remap
Name is a mandatory identifier for the memory remap.
Memory remaps use the address unit bits and interface binding of the parent memory map.
Remap state identifies the name of the remap state for which the optional memory remap elements are active. See remap states for further information on remap states. Description is an optional field for textual description of the memory remap.
Context menu
Memory maps editor contains a context menu (right mouse button) providing following options:
- Add new memory map (Add memory map)
- Add a new memory remap to the selected memory map (Add memory remap)
- Remove memory map (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Copy selected element to clipboard (Copy elements)
- Paste the element from the clipboard along with its sub-elements (Paste elements)
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE. Component AccelA has two memory maps MM0 and MM1 that are accessible through bus interface RegsIF. MM0 defines the hardware registers for read/write operations and MM1 provides a random-access memory block.
Memory maps editor
Memory maps editor contains the summary of the memory maps and memory remaps contained in the component and can be used to add, remove and edit them.
Memory maps visualization is shown on the right of the editor. The visualization can be expandped
and minimized by clicking the expand arrow
and the minimize arrow . Selecting any part
of the visualization will open the editor set for that item. The visualization can be resized by dragging
the border between the editor and the visualization.
Holding Ctrl-key while scrolling with the mouse wheel increases/decreases the width of the items.
Memory map specifies the addressable area seen through a target bus interface, e.g. the data and control register.
Memory remap describes additional memory map items that are mapped on the referencing target bus interface in a specific mode. If multiple memory remaps or mode attributes are active, then the first memory remap listed shall be selected.
Memory map
Name is a mandatory identifier for the memory map.
Mode reference applies only to memory remaps and can be edited in the memory remap editor.
Address unit bits (AUB) defines the number of data bits each address increment of the memory map contains, e.g. 8b or 32b. The default setting for a memory maps is byte addressable (8 bits). E.g. if AUB=8, then 32-bit registers are at addresses 0x0, 0x4, 0x8... If AUB=32, they are in addresses 0x0, 0x1, 0x2... AUB is the unit for base addresses and ranges within the address map.
Target interface binding shows which target bus interfaces are used to access the memory map. The binding can only be set in the bus interface editor, but is shown here for convenience.
Description is an optional field for textual description of the memory map.
Memory remap
Name is a mandatory identifier for the memory remap.
Memory remaps use the address unit bits and interface binding of the parent memory map.
Mode reference identifies the name of the mode reference for which the optional memory remap element is active. Displays the mode reference value, if only one exists, otherwise the displayed value is either '[multiple]' or 'None'. The mode references can be edited in the memory remap editor.
Description is an optional field for textual description of the memory remap.
Context menu
Memory maps editor contains a context menu (right mouse button) providing following options:
- Add new memory map (Add memory map)
- Add a new memory remap to the selected memory map (Add memory remap)
- Remove memory map (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Copy selected element to clipboard (Copy elements)
- Paste the element from the clipboard along with its sub-elements (Paste elements)
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE. Component AccelA has two memory maps MM0 and MM1 that are accessible through bus interface RegsIF. MM0 defines the hardware registers for read/write operations and MM1 provides a random-access memory block.
Mode editor
The mode editor can be used to edit the details of a component mode.
Name is a mandatory identifier for the mode.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the mode.
Description is an optional field for textual description of the mode.
Condition
The condition defines when the mode is active. If the condition expression evaluates to true, the component is operating in the defined mode. The condition may depend on run-time value of a port, register field and other modes. The expression accepts the following special functions:
- $ipxact_port_value( [port slice name] )
- $ipxact_field_value( [field slice name] )
- $ipxact_mode_condition( [mode name] )
Condition ports
The condition ports can be referenced in the condition to check for their value in the mode.
Name is a mandatory identifier for the port reference.
Physical port is a mandatory and identifies the port in the component whose value may be checked in the condition.
Left and right bounds are optional for selecting a range of bits in the port. If no indices are defined, the whole port is selected.
Description is an optional field for textual description of the port.
Condition fields
The condition fields can be referenced in the condition to check for their bit pattern in the mode.
Name is a mandatory identifier for the field reference.
Field is a mandatory and identifies the field in the component whose bit pattern may be checked in the condition.
Leftmost bit and rightmost bit are optional for selecting a range of bits in the field. If no indices are defined, the whole field is selected.
Description is an optional field for textual description of the port.
EXAMPLE. The mode named reset is active when the value of the bit 0 in the physical port
button_in i.e. button_in[0:0] is equal to 1.
Modes editor
The modes editor lists the operating modes of the component.
Name is a mandatory identifier for the mode.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the mode.
Description is an optional field for textual description of the cpu.
Modes editor provides a context menu (right mouse button) with the following options:
- Add new mode (Add row)
- Remove mode (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
Other clock drivers editor
Other clock drivers-editor shows the clocks within the component that are not directly associated with a top-level port. This kind of clocks could be i.e. virtual clocks or generated clocks.
The mandatory clock name identifies the other clock driver.
Clock source is optional and defines the physical path and name of the clock generation cell. E.g. a component instantiated in VHDL and its output, like 'i_clkGen/clk1'. The waveform of the clock signal has 4 parameters. Time units are either ps (picosecond) or ns (nanosecond).
Clock period defines the length of one cycle of clock pulse, e.g. 10 ns.
Pulse offset describes the time delay from start of the cycle to the first transition.
Pulse value defines the logic value which the first transition is made to, either 0 or 1.
Pulse duration specifies how long the value defined in pulse value is held, e.g. 5 ns.
Other clock drivers editor provides a context menu (right mouse button) with the following options:
- Add new clock (Add row)
- Remove clock (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE. Component Foo has a regular clock input port ClkIn and two additional clock sources clk0 and clk1 generated by instantiation clk_gen.
Parameters editor
Parameters editor can be used to add, remove and modify parameters of a component. Parameters are name-value pairs to configure or hold information related to the containing component. Note that these are not equivalent of VHDL generics or Verilog parameters. In the columns, f(x) means that the value can be given as an expression.
Each parameter contains a mandatory name and an optional display name for more user-friendly identifier. Description is free text for further details.
Type is an optional constraint for the type to which the parameter value resolves. Possible types are:
- bit indicates that the value shall resolve to a System Verilog bit, which by default is resolved to a 1-bit value, unless a vector size has been specified.
- byte indicates that the value shall resolve to a System Verilog byte, which is resolved to an 8-bit integer value.
- shortint indicates that the value shall resolve to a System Verilog shortint, which is resolved to a 16-bit integer value.
- int indicates that the value shall resolve to a System Verilog int, which is resolved to a 32-bit integer value.
- longint indicates that the value shall resolve to a System Verilog longint, which is resolved to a 64-bit integer value.
- shortreal indicates that the value shall resolve to a System Verilog shortint, which is resolved to a 32-bit floating point value. Both standard and scientific format (e.g 0.002 and 2e-3) are supported. This type applies also to minimum value and maximum value.
- real indicates that the value shall resolve to a System Verilog real, which is resolved to a 64-bit floating point value. Both standard and scientific format (e.g. 0.002 and 2e-3) are supported. This type applies also to minimum value and maximum value.
- string indicates that the value shall contain any text.
Value contains the mandatory default value of the parameter. This value can be overridden in a design that instantiates this component. The value is given in SystemVerilog format and may be given as an expression. Any other text must be enclosed within quotes e.g. "Any text".
By selecting a choice, the user can restrict the allowed parameter values to a set of predefined values. Possible values are defined in the choices of the containing component.
Minimum value and maximum value define the lower and upper boundary for the parameter value. If the selected type is bit or string, these fields have no effect.
Resolve specifies the configuration of the parameter. Possible resolve values are:
- immediate indicates that the the value is defined within the containing component. The value cannot be overridden by the user or a generator in design configuration. This is the default value, when no resolve has been set.
- user indicates that the user can override the default value in design configuration. Generators are not allowed to change the value.
- generated indicates that a generator can override the default value in a design configuration.
Bit vector left and bit vector right define the boundaries of a bit vector. These values can only be set to bit type parameters.
Array left and Array right specify the left and right sides of array dimension for the parameter in an output language e.g. Verilog. Both of these are vendor attributes. The values can be given as an expression, but must resolve to a decimal number. In order to get a valid array, both Array left and Array right must be given.
Usage count displays the number of references made to this parameter. Selecting the usage count opens a reference analysis of the parameter. The usage count is automatically updated to display the number of references made to the parameter.
Parameters editor contains a context menu (right mouse button) that provides following options:
- Add new parameter (Add row)
- Remove parameter (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
Port maps editor
User can map the logical signals of a bus interface to the physical ports of the component. The physical ports are located in the top table, while the logical signals and port maps are located in the bottom table.
Creating a port map
- Drag & Drop. A physical port can be dragged over a logical signal to create a port map connecting the selected physical port to the selected logical signal. Multiple physical ports can be dragged simultaneously to the selected logical signal to create multiple port maps.
- Selecting a port. A physical port can be selected for the logical signal from the physical port column. This creates a port map connecting the selected physical port to the logical signal.
- Context menu. Right clicking on a logical port opens a context menu, through which it is possible to create a new port map. This port map can then be filled with the desired data.
- Auto connect. Creates a single port map for each logical signal that does not have a port map. A suitable physical port is selected by matching the direction, type, size and the name of the logical signal to physical ports. If Physical port prefix has been set, physical ports starting with the given string will be prioritized in the connections. For example using prefix "master" will connect logical port 'CLK' to physical port 'master_clk' over ports 'clk', 'slave_clk' etc.
Removing a port map
-
Context menu. A port map can be removed throught the context menu. Right click on the
selected port map to open the menu. From there, select remove port map.
Opening the context menu on a logical signal allows the removing of all the port maps connected to the logical signal. - Remove all. Clicking the Remove all button removes all the port maps from this bus interface.
Physical port filters
- Name allows regular expressions to filter ports not matching the given expression.
- Type selects whether to display wire ports or transactional ports.
- Direction allows the selection of a port direction and filtering all the other ports with different directions.
- Connected ports can also be hidden through option Hide connected. By default, this filter is on, but can be changed.
Port maps
The port maps table consists of both the logical signals and the port maps referencing
logical signals. The table is constructed as a tree, where the port maps are child items of a logical
signal. Values for columns with an f(x) symbol can be given as expressions.
If a logical signal has been referenced only once in the port maps of the bus interface, information
of the port map is displayed on the same row as the logical signal.
If a single physical port is referenced in all the port maps referencing the logical signal, the
physical port name is displayed on the same row as the logical signal. If multiple port maps referencing
the same logical signal contain different physical ports, the name is displayed as [multiple].
The logical signal of a port map can be changed from the logical port column. This moves the
selected port map from its current position to the selected logical signal.
The physical port can be changed from the physical port column.
A port map can be defined by giving ranges for the logical and physical sides. These ranges determine how many and which bits are connected between the port and signal. These can be defined in the columns for the logical left, logical right, physical left and physical right.
Requirement informs the user of the port map requirement of the logical signal. The requirement is set in the abstraction definition of a bus definition, and cannot be edited here. The possible values are:
- Illegal. Logical signal may not be refereneced in a port map.
- Required. Logical signal must be referenced in a port map.
- Optional. The default value. Port maps can be created referencing the logical signal.
Tie off displays the possible logical tie off of the port map. A port map must contain either a reference to a physical port, or a logical tie off. The logical tie off indicates thate the physical connection for this logical port is the specified value.
Informative specifies that the portMap is used only for information purposes.
Invert specifies that connections to the physical port are logically inverted.
Port maps context menu (right mouse button)
- Add port map (logical signal / port map). Add a port map to the selected logical signal.
- Remove port map (port map). Remove the selected port map.
- Remove all port maps (logical signal). Remove all the port maps referencing the selected logical signal.
- Auto connect (port map). Automatically tries to connect the selected port by locating a suitable physical port matching the direction, type, size and the name of the logical signal to physical ports.
- Expand all. Show the port maps connected to each logical signal.
- Collapse all. Hide the port maps connected to each logical signal.
Details
The port maps tab of a bus interface editor is used to group the physical ports of the containing component to the logical signals listed in the associated abstraction definition.
The lower table contains the logical signals that were defined in the associated abstraction definition. The upper table contains a list of the physical ports in the component. The bottom table displays the mappings between logical signals and physical ports. The mapped physical ports are removed from the physical ports table unless Hide connected ports is unchecked.
The port directions are shown using the following icons:
in
out
inout
phantom
Picture below depicts how the physical ports between two component instances are connected through their
bus interfaces.
The physical ports of the component
A are on the left and those of component B on the right. Logical signals are in the middle and the lines
denote port mappings. For example component A has mapped its port 'comm_out' to the logical signal 'COMM'
and component B has mapped its port comm_in to it. When user connects these interfaces together in a
design, the physical ports get connected.
All ports of the component do not need to be mapped in the interface nor do all the logical signals of the
abstraction definition need to be associated with a physical port. Abstraction definition defines the
directions of the signals in different interface modes thus making it possible to validate connections so
that two output ports are not accidentally connected to each other. In the figure above the abstraction
definition could have defined the DATA signal to have direction out in master interfaces and in at slave
interfaces.
A vectored physical port can be sliced to connect only part of it by assigning left and right bounds in the
mapping table. Picture below depicts how a part of the physical port can be connected.
Port maps editor
User can map the logical signals of a bus interface to the physical ports of the component. The physical ports are located in the top table, while the logical signals and port maps are located in the bottom table.
Creating a port map
- Drag & Drop. A physical port can be dragged over a logical signal to create a port map connecting the selected physical port to the selected logical signal. Multiple physical ports can be dragged simultaneously to the selected logical signal to create multiple port maps.
- Selecting a port. A physical port can be selected for the logical signal from the physical port column. This creates a port map connecting the selected physical port to the logical signal.
- Context menu. Right clicking on a logical port opens a context menu, through which it is possible to create a new port map. This port map can then be filled with the desired data.
- Auto connect. Creates a single port map for each logical signal that does not have a port map. A suitable physical port is selected by matching the direction, type, size and the name of the logical signal to physical ports. If Physical port prefix has been set, physical ports starting with the given string will be prioritized in the connections. For example using prefix "initiator" will connect logical port 'CLK' to physical port 'initiator_clk' over ports 'clk', 'target_clk' etc.
Removing a port map
-
Context menu. A port map can be removed throught the context menu. Right click on the
selected port map to open the menu. From there, select remove port map.
Opening the context menu on a logical signal allows the removing of all the port maps connected to the logical signal. - Remove all. Clicking the Remove all button removes all the port maps from this bus interface.
Physical port filters
- Name allows regular expressions to filter ports not matching the given expression.
- Type selects whether to display wire ports or transactional ports.
- Direction allows the selection of a port direction and filtering all the other ports with different directions.
- Connected ports can also be hidden through option Hide connected. By default, this filter is on, but can be changed.
Port maps
The port maps table consists of both the logical signals and the port maps referencing
logical signals. The table is constructed as a tree, where the port maps are child items of a logical
signal. Values for columns with an f(x) symbol can be given as expressions.
If a logical signal has been referenced only once in the port maps of the bus interface, information
of the port map is displayed on the same row as the logical signal.
If a single physical port is referenced in all the port maps referencing the logical signal, the
physical port name is displayed on the same row as the logical signal. If multiple port maps referencing
the same logical signal contain different physical ports, the name is displayed as [multiple].
The logical signal of a port map can be changed from the logical port column. This moves the
selected port map from its current position to the selected logical signal.
The physical port can be changed from the physical port column.
A port map can be defined by giving ranges for the logical and physical sides. These ranges determine how many and which bits are connected between the port and signal. These can be defined in the columns for the logical left, logical right, physical left and physical right.
Requirement informs the user of the port map requirement of the logical signal. The requirement is set in the abstraction definition of a bus definition, and cannot be edited here. The possible values are:
- Illegal. Logical signal may not be refereneced in a port map.
- Required. Logical signal must be referenced in a port map.
- Optional. The default value. Port maps can be created referencing the logical signal.
Tie off displays the possible logical tie off of the port map. A port map must contain either a reference to a physical port, or a logical tie off. The logical tie off indicates thate the physical connection for this logical port is the specified value.
Informative specifies that the portMap is used only for information purposes.
Invert specifies that connections to the physical port are logically inverted.
Port maps context menu (right mouse button)
- Add port map (logical signal / port map). Add a port map to the selected logical signal.
- Remove port map (port map). Remove the selected port map.
- Remove all port maps (logical signal). Remove all the port maps referencing the selected logical signal.
- Auto connect (port map). Automatically tries to connect the selected port by locating a suitable physical port matching the direction, type, size and the name of the logical signal to physical ports.
- Expand all. Show the port maps connected to each logical signal.
- Collapse all. Hide the port maps connected to each logical signal.
Details
The port maps tab of a bus interface editor is used to group the physical ports of the containing component to the logical signals listed in the associated abstraction definition.
The lower table contains the logical signals that were defined in the associated abstraction definition. The upper table contains a list of the physical ports in the component. The bottom table displays the mappings between logical signals and physical ports. The mapped physical ports are removed from the physical ports table unless Hide connected ports is unchecked.
The port directions are shown using the following icons:
- in
- out
- inout
- phantom
Picture below depicts how the physical ports between two component instances are connected through their
bus interfaces (note: in this picture the interface mode names used are of the old 2014 standard).
The physical ports of the component A are on the left and those of component B on the right. Logical signals are in the middle and the lines
denote port mappings. For example component A has mapped its port 'comm_out' to the logical signal 'COMM'
and component B has mapped its port comm_in to it. When user connects these interfaces together in a
design, the physical ports get connected.
All ports of the component do not need to be mapped in the interface nor do all the logical signals of the
abstraction definition need to be associated with a physical port. Abstraction definition defines the
directions of the signals in different interface modes thus making it possible to validate connections so
that two output ports are not accidentally connected to each other. In the figure above the abstraction
definition could have defined the DATA signal to have direction out in initiator interfaces and in at target
interfaces.
A vectored physical port can be sliced to connect only part of it by assigning left and right bounds in the
mapping table. Picture below depicts how a part of the physical port can be connected.
Ports editor
Ports editor provides a table containing all the ports of a component. This editor is used to view, add, remove and edit the ports. The port details can be edited in the Wires and Transactionals section.
Port name is a unique identifier and must match the name of the port in the implementation language.
Type shows the kind of the port. The type is set when the port is created and cannot be changed here.
- wire port carries binary value(s) and are used in RTL.
- transactional port is used for all other kind of ports, especially in TLM.
Port tags column displays the optional tags for a port. These can be used to group ports together
to, for example, create bus interfaces.
Ad-hoc column is a Kactus2-specific extension which is used in the graphical user interface of a
hierarchical design. Ad-hoc determines whether the port is shown as an ad-hoc port when the component is
instantiated in a design.
Description is an optional free text for further details.
Ports editor provides a context menu (right mouse button) that contains following options:
- Add new wire port (Add wire)
- Add new transactional port (Add transactional)
- Remove port (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
Power domains editor
The power domains editor lists the applicable power domains of the component.
Name is a mandatory identifier for the power domain.
Display name is an optional and used for a more user-friendly identifier.
Always on is optional and determines if the power domain is always powered on (value 1) or not (value 0). Always on can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Subdomain of is optional and defines this power domain as a part of another power domain.
Short description is an optional field for compact description of the power domain.
Description is an optional field for textual description of the power domain.
Power domains editor provides a context menu (right mouse button) with the following options:
- Add new power domain (Add row)
- Remove power domain (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
Register editor
Register editor is used to edit the details of a single register and the possible bit fields within the register. A bit field may contain just one bit, the whole register or something in between.
Name is a mandatory identifier for the register. The name must be unique within all the registers of the containing address block.
Display name is an optional field and used for a more user-friendly identifier.
Description is an optional field for textual description of the register.
Offset is a mandatory value to specify the location of the register from the start of the containing address block expressed as address units.
Size is mandatory and defines the number of data bits the register contains. Size must be less or equal to the width of the containing address block.
Dimension is optional and assigns an array dimension to the register. The register will be repeated in the address block as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register is not an array and will appear exactly once.
Is present is optional and allows the enabling/disabling of a register presence in an address block. Value 1 indicates that the register is present in the address block whereas value 0 marks the register to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Volatile is optional and indicates whether the register value may change without a write operation to it.
Access is optional and specifies the accessability of the register. The possible values are:
- read-write. Both read and write transactions may have an effect on this register.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Both read and write transactions may have an effect on this register. Only the first write transaction, after an event that caused the reset value of the register to be loaded, may affet the contents of the register, and read transactions return a value related to the values in the register.
- writeOnce. Only the first write transaction affects the contents of the register.
Fields table
The fields table enables the user to define the register bit fields. A register must contain at least one field.
Name is a mandatory identifier for the field.
Offset is a mandatory value to specify the starting bit of the field within the register.
Width is a mandatory value to specify how many bits are included in the field.
Resets defines the reset values of the field. The reset values must be edited in the field editor. If a field only has one reset value, it is displayed here. If a field contains multiple reset values, they are displayed with a [multiple] tag. A tooltip provides basic information on the resets, displaying the reset type and value.
Access is optional and specifies the accessibility of the field. The possible values are:
- read-write. Both read and write transactions may have an effect on this field. Write transactions may affect the contents of the field, and read transactions return a value related to the field.
- read-only. A read transaction to this field returns a value related to the value in the field. A write transaction to this field has undefined results.
- write-only. A write transaction to this address affects the contents of the field. A read transaction to this field has undefined results.
- read-writeOnce. Both read and write transactions may have an effect on this field. Only the first write transaction may affect the contents of the field, and read transactions return a value related to the values in the field.
- writeOnce. Only the first write transaction affects the contents of this field.
Modified write value is optional anddescribes how the data in the field is manipulated on a write operation. The basic operation without any setting is to store the written value 'as is'. Moreover, both bitwise and field-wise set/clear/toggle is also possbile. The possible values are:
- oneToClear. Each written '1' bit will assign the corresponding bit to '0'.
- oneToSet. Each written '1' bit will assign the corresponding bit to '1'.
- oneToToggle. Each written '1' bit will toggle the corresponding bit.
- zeroToClear, zeroToSet, zeroToToggle. Similar to previous ones, except that written '0' bit triggers the action.
- clear. Each write operation will clear all bits in the field to '0'.
- set. Each write operation will set all bits in the field to '1'.
- modify. Indicates that after a write operation all bits in the field can be modified.
- ' ' (empty setting). Indicates that the value written to a field is the value stored in the field. This is the default.
Read action specifies if some action happens to the field after a read operation. By default the register is unmodified. The possible values are:
- clear. All bits in the field are cleared to '0' after a read operation.
- set. All bits in the field are set to '1' after a read operation.
- modify. Indicates that the bits in the field are modified in some way after a read operation.
- ' ' (empty setting). Indicates that field is not modified after a read operation. This is the default.
Testable is optional and specifies if the field is testable by an automated register test.
Test constraint is optional and specifies the constraints for the automated tests for the field. The possible constraint values are:
- unConstrained. There are no constrains for the written or read data. This is the default setting.
- restore. The field value must be restored to its original value before accessing another register.
- writeAsRead. The data written to a field must be the same that was read previously from the field.
- readOnly. Indicates that the field can only be read.
Is present is optional and enables/disables a field's presence in a register. Value 1 indicates that the field is present in the register whereas value 0 marks the field to be treated as if it did not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the field. ================================================ FILE: Help/componenteditor/register2022.html ================================================
Register editor
Register editor is used to edit the details of a single register and the possible bit fields within the register. A bit field may contain just one bit, the whole register or something in between.
Name is a mandatory identifier for the register. The name must be unique within all the registers of the containing address block.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the register.
Description is an optional field for textual description of the register.
Offset is a mandatory value to specify the location of the register from the start of the containing address block expressed as address units.
Size is mandatory and defines the number of data bits the register contains. Size must be less or equal to the width of the containing address block.
Dimension is optional and assigns an array dimension to the register. The register will be repeated in the address block as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register is not an array and will appear exactly once.
Volatile is optional and indicates whether the register value may change without a write operation to it.
Access policies are optional and specify the accessability of the register data for different operating modes, specified by mode references. If no mode reference is present, then the access policy applies to all modes not already referenced by other access policies (i.e. only one access policy without mode references may exist). The possible access values for an access policy are:
- read-write. Both read and write transactions may have an effect on this register.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Both read and write transactions may have an effect on this register. Only the first write transaction, after an event that caused the reset value of the register to be loaded, may affect the contents of the register, and read transactions return a value related to the values in the register.
- writeOnce. Only the first write transaction affects the contents of the register.
Fields table
The fields table enables the user to define the register bit fields. A register must contain at least one field.
Name is a mandatory identifier for the field.
Offset is a mandatory value to specify the starting bit of the field within the register.
Width is a mandatory value to specify how many bits are included in the field.
Resets defines the reset values of the field. The reset values must be edited in the field editor. If a field only has one reset value, it is displayed here. If a field contains multiple reset values, they are displayed with a [multiple] tag. A tooltip provides basic information on the resets, displaying the reset type and value.
Volatile is optional and indicates whether the field value may change without a write operation to it.
Access modifies the first field access policy of the field. If multiple field access policy exists, then the access cannot be edited here and must be edited for each field access policy separately in the field editor. If no field access policy exists, then one will be created for the field when the access is edited here. The possible access values are:
- read-write. Both read and write transactions may have an effect on this field. Write transactions may affect the contents of the field, and read transactions return a value related to the field.
- read-only. A read transaction to this field returns a value related to the value in the field. A write transaction to this field has undefined results.
- write-only. A write transaction to this address affects the contents of the field. A read transaction to this field has undefined results.
- read-writeOnce. Both read and write transactions may have an effect on this field. Only the first write transaction may affect the contents of the field, and read transactions return a value related to the values in the field.
- writeOnce. Only the first write transaction affects the contents of this field.
Description is an optional field for textual description of the field.
================================================ FILE: Help/componenteditor/registerFile.html ================================================ Register file editor
Register file editor is used to edit the details of a single register file and the registers and register files within the register file.
Name is a mandatory identifier for the register file. The name must be unique within all the registers or register files of the containing address block or register file.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the register file.
Offset is a mandatory value to specify the location of the register file from the start of the containing address block or register file expressed as address units.
Range is mandatory and specifies the size of the register file in address units bits.
Dimension is optional and assigns an array dimension to the register file. The register file will be repeated in the containing address block or register file as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register file is not an array and will appear exactly once.
Is present is optional and allows the enabling/disabling of a register file presence in a containing address block or register file. Value 1 indicates that the register file is present in the containing element whereas value 0 marks the register file to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Access is optional and specifies the accessability of the register file. The possible values are:
- read-write. Both read and write transactions may have an effect on this register file.
- read-only. Only read transactions are allowed in this register file.
- write-only. Only write transactions are allowed in this register file.
- read-writeOnce. Both read and write transactions may have an effect on this register file. Only the first write transaction, after an event that caused the reset value of the register file to be loaded, may affet the contents of the register file, and read transactions return a value related to the values in the register file.
- writeOnce. Only the first write transaction affects the contents of the register file.
Registers table
The registers table enables the user to define and edit registers of the register file.
Name is a mandatory identifier for the register.
Offset is a mandatory value to specify the location of the register within the register file expressed as address units.
Size is mandatory and defines the number of data bits the register contains. Size must be less or equal to the width of the containing address block.
Dimension is optional and assigns an array dimension to the register. The register will be repeated in the containing register file as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register is not an array and will appear exactly once.
Volatile is optional and indicates whether the register value may change without a write operation to it.
Access is optional and specifies the accessability of the register. The possible values are:
- read-write. Both read and write transactions may have an effect on this register.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Both read and write transactions may have an effect on this register. Only the first write transaction, after an event that caused the reset value of the register to be loaded, may affet the contents of the register, and read transactions return a value related to the values in the register.
- writeOnce. Only the first write transaction affects the contents of the register.
Is present is optional and enables/disables a register's presence in the register file. Value 1 indicates that the register is present in the register file whereas value 0 marks the register to be treated as if it did not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the register.
Register files table
The register files table enables the user to define and edit register files within the register file.
Name is a mandatory identifier for the register file.
Offset is a mandatory value to specify the location of the register file within the containing register file expressed as address units.
Range is mandatory and specifies the size of the register file in address units bits.
Dimension is optional and assigns an array dimension to the register file. The register file will be repeated in the containing register file as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register file is not an array and will appear exactly once.
Is present is optional and enables/disables a register's presence in the register file. Value 1 indicates that the register is present in the register file whereas value 0 marks the register to be treated as if it did not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
Description is an optional field for textual description of the register.
================================================ FILE: Help/componenteditor/registerFile2022.html ================================================ Register file editor
Register file editor is used to edit the details of a single register file and the registers and register files within the register file.
Name is a mandatory identifier for the register file. The name must be unique within all the registers or register files of the containing address block or register file.
Display name is an optional and used for a more user-friendly identifier.
Short description is a compact description of the register file.
Description is an optional field for textual description of the register file.
Offset is a mandatory value to specify the location of the register file from the start of the containing address block or register file expressed as address units.
Range is mandatory and specifies the size of the register file in address units bits.
Dimension is optional and assigns an array dimension to the register file. The register file will be repeated in the containing address block or register file as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register file is not an array and will appear exactly once.
Access policies are optional and specify the accessability of the register file data for different operating modes, specified by mode references. If no mode reference is present, then the access policy applies to all modes not already referenced by other access policies (i.e. only one access policy without mode references may exist). The possible access values for an access policy are:
- read-write. Both read and write transactions may have an effect on this register file.
- read-only. Only read transactions are allowed in this register file.
- write-only. Only write transactions are allowed in this register file.
- read-writeOnce. Both read and write transactions may have an effect on this register file. Only the first write transaction, after an event that caused the reset value of the register file to be loaded, may affect the contents of the register file, and read transactions return a value related to the values in the register file.
- writeOnce. Only the first write transaction affects the contents of the register file.
Registers table
The registers table enables the user to define and edit registers of the register file.
Name is a mandatory identifier for the register.
Offset is a mandatory value to specify the location of the register within the register file expressed as address units.
Size is mandatory and defines the number of data bits the register contains. Size must be less or equal to the width of the containing address block.
Dimension is optional and assigns an array dimension to the register. The register will be repeated in the containing register file as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register is not an array and will appear exactly once.
Volatile is optional and indicates whether the register value may change without a write operation to it.
Access is optional and specifies the accessibility of the register by modifying the first access policy of the register. If multiple access policies exist, then the access value cannot be edited here and must be edited for each access policy separately in the register editor. If no access policy exists, then one will be created for the register when the access is edited here. The possible access values are:
- read-write. Both read and write transactions may have an effect on this register.
- read-only. Only read transactions are allowed in this register.
- write-only. Only write transactions are allowed in this register.
- read-writeOnce. Both read and write transactions may have an effect on this register. Only the first write transaction, after an event that caused the reset value of the register to be loaded, may affet the contents of the register, and read transactions return a value related to the values in the register.
- writeOnce. Only the first write transaction affects the contents of the register.
Description is an optional field for textual description of the register.
Register files table
The register files table enables the user to define and edit register files within the register file.
Name is a mandatory identifier for the register file.
Offset is a mandatory value to specify the location of the register file within the containing register file expressed as address units.
Range is mandatory and specifies the size of the register file in address units bits.
Dimension is optional and assigns an array dimension to the register file. The register file will be repeated in the containing register file as many times as indicated by the dimension value. An empty dimension (default) or a dimension with value 1 means that the register file is not an array and will appear exactly once.
Description is an optional field for textual description of the register.
================================================ FILE: Help/componenteditor/remapStates.html ================================================ Remap states editor
The Remap states editor displays a summary of the remap states of a component.
Name is a mandatory identifier for the remap state.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the remap state.
Right clicking an item in the editor provides a context menu that can be used to:
- Add a new remap state to the component (Add row).
- Remove a remap state from the component (Remove row).
- Clear the selected cells (Clear).
- Copy the contents of the selected cells to clipboard (Copy).
- Paste the contents of the clipboard to the selected cells (Paste).
Reset types editor
The Reset types editor is used to edit the details of a reset type. The reset types describe any user-defined reset types referenced within field reset elements. The default reset type for a field is HARD, and should be treated as pre-defined.
Name is a mandatory identifier for the reset type. The name must be unique, and can not be the pre-defined default value HARD.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the reset type.
================================================ FILE: Help/componenteditor/resetTypes2022.html ================================================Reset types editor
The Reset types editor is used to edit the details of a reset type. The reset types describe any user-defined reset types referenced within field reset elements. The default reset type for a field is HARD, and should be treated as pre-defined.
Name is a mandatory identifier for the reset type. The name must be unique, and can not be the pre-defined default value HARD.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the reset type.
Description is an optional field for textual description of the reset type.
================================================ FILE: Help/componenteditor/singleRemapState.html ================================================ Single remap state editor
Remap state editor is used to edit the details of a single remap state. A remap state defines a conditional state which is conditioned by a remap port. A remap state element does not specify the remapping addresses. Instead, they are defined by the memory remap element (in a memory map element), and its state attribute refers the remap state by name.
Name is a mandatory identifier for the remap state.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the remap state.
Remap State Condition
In addition to the name group, a remap state contains a remap state condition, which is specified with the remap port elements. These elements make up the condition for this remap state. All elements must be true for the remap state to be enabled.
Port contains the names of the selected remap ports. These remap ports are selected among the components ports. No port can be selected twice.
Left bound shows the left bound value of the selected port. This value cannot be given, as it is read using the selected port. Together with the value of the right bound column, this value is used to calculate the width of the port.
Right bound shows the right bound value of the selected port. This value cannot be given, as it is read using the selected port. Together with the value of the left bound column, this value is used to calculate the width of the port.
Value contains the value necessary so the specified port activates the remap state. Depending on the width of the port, the remap condition value may be given as a single expression for the whole port, or as separate expressions for each bit of the port. A port with a width of 1 is only allowed to receive a single expression.
================================================ FILE: Help/componenteditor/subspacemap.html ================================================ Subspace map editor
Subspace map editor is used to edit the details of a subspace map. Subspaces are used for opaque bridges to define access from a memory map to an address space of a master interface.
Name is a mandatory identifier for the subspace map.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the subspace map.
Base address is mandatory and specifies the starting address for the subspace map in address unit bits. The range is equal to the referenced address space or segment.
MasterRef is a mandatory identifier for the bridged master bus interface that is accessed by the subspace map.
SegmentRef is an optional reference to a segment within the referenced master bus interface. If a segment is defined, the access is limited to the specified segment instead of the whole address space.
Is present is optional and allows enabling/disabling of a subspace map presence in a memory map. Value 1 indicates that the subspace map is present in the memory map whereas value 0 marks the subspace map to be treated as if it does not exist. Is present can be given as a SystemVerilog expression, but it must evaluate to 1 or 0.
================================================ FILE: Help/componenteditor/subspacemap2022.html ================================================ Subspace map editor
Subspace map editor is used to edit the details of a subspace map. Subspaces are used for opaque bridges to define access from a memory map to an address space of a initiator interface.
Name is a mandatory identifier for the subspace map.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the subspace map.
Description is an optional field for textual description of the subspace map.
Base address is mandatory and specifies the starting address for the subspace map in address unit bits. The range is equal to the referenced address space or segment.
Initiator reference is a mandatory identifier for the bridged initiator bus interface that is accessed by the subspace map.
SegmentRef is an optional reference to a segment within the referenced initiator bus interface. If a segment is defined, the access is limited to the specified segment instead of the whole address space.
================================================ FILE: Help/componenteditor/swproperties.html ================================================Software properties editor
This is Kactus2 extension
These allow defining
parameters for software. The usage is similar to model
parameters, first define the available parameters and then
give them actual values upon component instantiation. However,
these are separated, since other tools do not have such concept
and that might lead confusion which are HW parameters and and
which are SW parameters.
Each SW property has mandatory name and type (string, integer, IP address). Moreover, sometimes the value definition is required on each instance. Optional default value is used, if instance does not specify the value. Textual desciption is also optional.
For example, MCAPI nodes necessiate that user sets the 'node_id' which is done through SW property. Similarly, some SW may need the IP address of itself or other device and it can be also set here.
================================================ FILE: Help/componenteditor/systemview.html ================================================System view editor
This is Kactus2 extension
Each system view has a mandatory name. Display
name is optional and typically a few words providing a more
detailed and/or user-friendly name for display. Optional
description contains a textual description of the
interface.
Hierarchy reference is the VLNV of system design which also a Kactus-extension. It captures the mapping informationand is saved in its own XML file. You can type the VLNV or drag-drop a SW design from the library. Note that a system view is always hierarchical, unlike regular view.
================================================ FILE: Help/componenteditor/systemviews.html ================================================ System views editor
This is Kactus2 extension
System view is a
usually associated with a component including multiple CPUs. It
is hierarchical reference to system design which is also
a Kactus-extension and defines the mapping of SW onto HW
resources. One component, such as multiprocessor SoC (MPSoC),
can have multiple system views, i.e. multiple stored mappings,
and hence it is easy to switch between them. System design
defines how SW is mapped onto CPUs and it shows all HW
components that include a CPU definition. Mapping is
necessary if there are multiple CPUs or HW accelerators that
support the optional COM interfaces.
Each system view has mandatory name and hierarchy reference. Note that the latter cannot be edited here, but in view's own editor. Note also that a system view is always hierarchical, unlike regular view.Display name is optional and typically a few words providing a more detailed and/or user-friendly name for display. Optional description contains a textual description of the interface.
EXAMPLE. A product includes two programmable CPUS: Nios on FPGA
and a regular PC. One system design performs the application
mapping so that discrete cosine transfrom (dct) is executed on PC
whereas the main function H.263 video encoder is on
Nios. Communication between these is done using MCAPI endpoints
and channels. Therefore Nios also includes the MCAPI SW component.
We notice that interface symbols are different in COM interfaces
(main - dct) and API interfaces (main - mcapi). Note also that
system design shows CPUs together although they appear on
different levels of product's hiearchy. 
Transactional ports editor
Transactional ports editor provides a table containing all the transactional ports of a component. This editor is used to add, remove and edit the transactional ports.
Port name is a unique identifier and must match the name of the port in the implementation language. For example, the ports listed in the VHDL entity declaration are listed here.
Width specifies the data width in bits. Can be given as an expression.
Initiative defines the type of access. Initiative has four options:
- requires defines an initiative requirement of the port.
- provides defines a provider port for initiative.
- both defines the type of access as both requires and provides.
- phantom for ports that exist on the IP-XACT component but not on the implementation.
Kind defines the ports type. Kind has four options, in addition to a custom type.
- tlm_port should only be used for TLM1 notation
- tlm_socket
- simple_socket
- multi_socket
Protocol characterizes the information transportation method of the port. Currently not supported in Kactus2.
The port type is optional together with a type definition that an optional language specific reference to where the type is defined, e.g. package or header file. In SystemC, the type definition is the include file name, e.g. 'systemc.h'. The type definition has no effect if type is not set. The type can be applied to specific view(s) or all views.
Array left and array right are optional and define the indices of an array port. The values can be given as an equation, but it must resolve into a decimal number. If either left or right value is given, the port is considered to be of an array type.
Port tags column displays the optional tags for a port. These can be used to group ports together
to, for example, create bus interfaces.
Max connections and Min connections define the number of legal connections that can be made to this port. Max connceionts indicates the maximum number of supported connections, while Min connections indicates the minimum number of supported connections. These values can be given as expressions.
Ad-hoc column is a Kactus2-specific extension which is used in the graphical user interface of a
hierarchical design. Ad-hoc determines whether the port is shown as an ad-hoc port when the component is
instantiated in a design.
Description is an optional free text for further details.
Transactional ports editor provides a context menu (right mouse button) that contains following options:
- Add new port (Add row)
- Remove port (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- New Bus Interface creates a new bus interface in the component using the currently selected ports
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
View editor
View specifies a representation level of a component, e.g. there might be different views for simulation and synthesis. This editor is used to edit the details of single view.
Name is a mandatory identifier for the view.
Display name is an optional and used for a more user-friendly identifier.
Description is an optional field for textual description of the view.
Environment identifiers
Environment identifiers is optional textual information about how this view is deployed in different tool environments.
Language indicates this view may be compatible with a particular tool, but only if that language is supported in that tool, e.g., different versions of some simulators may support two or more languages.
Tool indicates that this view contains tool-information, e.g., HDL models that use simulator-specific extensions. This should contain tool name and company name, separated by dots e.g. 'designcompiler.designcompany.com'. Alternatively, the tool can have a generic value such as '*Simulation' or '*Synthesis'.
VendorSpecific can further qualify tool and language compatibility, e.g. if some appropriate simulator mode must be enabled.
Instantiations
Component instantiation is optional and specifies the component instantiation containing all the implementation details for the component with this view. For convenience, details of the component instantiation are shown in the view editor if a component instantiation has been selected. For more information on the component instantiation, see the component instantiation editor.
Design configuration instantiation is optional and specifies the referenced design configuration instantiation. For convenience, the referenced design configuration is shown in the view editor if a design configuration instantiation has been selected. When this view is active, this design configuration should be used to configure the component structure. For more information on the design configuration instantiation, see the design configuration instantiation editor.
Design instantiation is optional and specifies the referenced design instantiation. For convenience, the referenced design is shown in the view editor if a design instantiation has been selected. When this view is active, this design should be used to describe the component structure. For more information on the design instantiation, see the design instantiation editor.
================================================ FILE: Help/componenteditor/view2022.html ================================================ View editor
View specifies a representation level of a component, e.g. there might be different views for simulation and synthesis. This editor is used to edit the details of single view.
Name is a mandatory identifier for the view.
Display name is an optional and used for a more user-friendly identifier.
Short description is an optional field for compact description of the view.
Description is an optional field for textual description of the view.
Environment identifiers
Environment identifiers is optional textual information about how this view is deployed in different tool environments.
Language indicates this view may be compatible with a particular tool, but only if that language is supported in that tool, e.g., different versions of some simulators may support two or more languages.
Tool indicates that this view contains tool-information, e.g., HDL models that use simulator-specific extensions. This should contain tool name and company name, separated by dots e.g. 'designcompiler.designcompany.com'. Alternatively, the tool can have a generic value such as '*Simulation' or '*Synthesis'.
VendorSpecific can further qualify tool and language compatibility, e.g. if some appropriate simulator mode must be enabled.
Instantiations
Component instantiation is optional and specifies the component instantiation containing all the implementation details for the component with this view. For convenience, details of the component instantiation are shown in the view editor if a component instantiation has been selected. For more information on the component instantiation, see the component instantiation editor.
Design configuration instantiation is optional and specifies the referenced design configuration instantiation. For convenience, the referenced design configuration is shown in the view editor if a design configuration instantiation has been selected. When this view is active, this design configuration should be used to configure the component structure. For more information on the design configuration instantiation, see the design configuration instantiation editor.
Design instantiation is optional and specifies the referenced design instantiation. For convenience, the referenced design is shown in the view editor if a design instantiation has been selected. When this view is active, this design should be used to describe the component structure. For more information on the design instantiation, see the design instantiation editor.
================================================ FILE: Help/componenteditor/views.html ================================================ Views editor
Views editor provides a summary of the views of the component. The editor can be used to add and remove views.
A view specifies a representation level of a component, e.g. there might be different views for simulation and synthesis. A component can have multiple views and one of them is selected as active when component is instantiated in a design.
Name is a mandatory identifier for the view.
View type is automatically determined by the view definition. A non-hierarchical view defines an independent one-level representation of the component. A hierarchical view implies there is a design describing the sub-components that together compose this component.
Description is an optional field for textual description of the view.
The editor contains a context menu that contains following options:
- Add new view (Add row)
- Remove view (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
A view specifies the instantiations composing the representation of the
component. Implementation specific details such as filesets and module
parameters are defined in a component instantiation whereas
design instantiation and design configuration instantiation
are used to identify the design describing the internal structure of
the component. A view can define any combination of the three
different instantiations.
Wire ports editor
Wire ports editor provides a table containing all the wire ports of a component. This editor is used to add, remove and edit the wire ports.
Port name is a unique identifier and must match the name of the port in the implementation language. For example, the ports listed in the VHDL entity declaration are listed here.
Direction has four options:
- in for input ports.
- out for output ports.
- inout for bidirectional and tri-state ports.
- phantom for ports that exist on the IP-XACT component but not on the implementation.
Left and right bounds define the indices of a vectored port. The width of the port is higher bound - lower bound + 1, e.g. 3 downto 0 requires 4 bits. For scalar ports left bound = right bound. If either left bound or right bound is an expression, width cannot be set manually.
The port type is optional together with a type definition that an optional language specific reference to where the type is defined, e.g. package or header file. Typical values in VHDL are 'std_logic' for scalar ports (i.e. 1 bit) and 'std_logic_vector' for vectored ports (multibit). In VHDL, 'std_logic' types are defined in 'IEEE.std_logic_1164.all' ('all' means that the whole package is included). In SystemC, the type definition is the include file name, e.g. 'systemc.h'. The type definition has no effect if type is not set. The type can be applied to specific view(s) or all views.
Default value is optional and can be used to assign a value for an unconnected (input) port. This is used, for example, when generating a structural top-level VHDL for the hierarchical component where some input ports are not connected to any other port in the design.
Array left and array right are optional and define the indices of an array port. The values can be given as an equation, but must resolve into a decimal number. If either left or right value is given, the port is considered to be of an array type.
Port tags column displays the optional tags for a port. These can be used to group ports together
to, for example, create bus interfaces.
Ad-hoc column is a Kactus2-specific extension which is used in the graphical user interface of a
hierarchical design. Ad-hoc determines whether the port is shown as an ad-hoc port when the component is
instantiated in a design.
EXAMPLE: The component instances are drawn as rectangles and their external interfaces are drawn to the
edges of the rectangle. There are different symbols for different directions. The example instance in
figure has 5 bus interfaces: clk, led, rst_n, from_hibi and pkt_codec. Each interface includes 1 or
multiple ports, and the interface definition has its own VLNV. Moreover, user can select that some ports
are shown as Ad-hoc, e.g. if they are not necessarily associated in any bus interface. Example
figure displays 2 ad-hoc ports: rx_av_in and led_out.
Description is an optional free text for further details.
Wire ports editor provides a context menu (right mouse button) that contains following options:
- Add new port (Add row)
- Remove port (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- New Bus Interface creates a new bus interface in the component using the currently selected ports
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
EXAMPLE. The figure shows the relation between VHDL source code and the port editor. The names, directions,
and bounds are obvious. Width is derived from the bounds, if given, but otherwise set to 1 to denote a
scalar port. The type of the ports is std_logic for clk and rst_n, and std_logic_vector for data_in and
data_out. For data_out, the type is defined only for view flat. In other ports no view is defined so the
same type is applied for all views (not shown in the figure below). The type definition is
IEEE.std_logic_1164.all for each port.
Abstraction Definition
An abstraction definition can also be linked with a bus definition to provide additional validation for bus connections. Abstraction definition defines what logical signals must be present in the bus interface in order for the bus connection with such abstraction definition to be valid. A logical signal can be either a wire signal or a transactional signal.
Logical signal editor contains a context menu (right mouse button) that provides following options:
- Add master signal interface mode
- Add slave signal interface mode
- Add system signal interface mode
- Add all unconnected system signals from the bus definition system group
- Reset extended ports to reload the signals that have been extended from the extended abstraction definition
- Add new logical signal (Add row)
- Remove logical signal (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
Extended abstraction definition
Allows the creation of a family of interconnectable abstraction definitions. The extending abstraction definition must have a bus type that extends the bus type of the extended abstraction definition. The logical signals of the extended abstraction definition can be used and the following elements can be edited:
- Presence
- Width
- Default value
- Driver
- System group
Logical signal properties
Name is a mandatory unique identifier for the logical signal.
Mode defines for which interface mode the settings apply.
- master defines constraints for this signal when present in a master bus interface.
- slave defines constraints for this signal when present in a slave bus interface.
- system defines constraints for this signal when present in a system bus interface with a matching group name.
Presence is an optional restriction for the logical signal presence in a bus interface. It can have one of the following three values:
- required indicates that the logical signal must appear in the connected bus interface.
- illegal indicates that the logical signal must not appear in the connected bus interface.
- optional does not apply any restrictions. This is the default value.
Qualifier is an optional indicator for what kind of information the the signal carries. It can have one of the following five values:
- address indicates that the signal carries address information.
- data indicates that the signal carries data.
- empty indicates that the signal may carry any information.
System group helps identify the system interface the signal belongs to. System group is mandatory for system mode and illegal for other modes.
Description is an optional free text for further details.
Wire properties
Direction is an optional restriction for the logical signal direction in the connected bus interface. Direction can have one of the following values:
- in
- out
- inout
Width is an optional definition of the number of bits in the logical signal. If not specified, the number of bits in the connected physical port is used.
Default value is an optional value that is applied when the logical signal is not connected in a connected bus interface.
Driver is an optional setting for defining what kind of a driver the logical signal requires in a complete design. The possible values are the following:
- any indicates that any logical signal or value is valid for driving the signal. This is the default value.
- clock indicates that a repeating waveform is required.
- singleshot indicates that a non-repeating waveform is required.
- none indicates that no driver is required.
Wire ports have additional values for Qualifier:
- address indicates that the signal carries address information.
- data indicates that the signal carries data.
- clock indicates that the signal is a repeating clock signal for the bus interface.
- reset indicates that the signal is a reset signal for the bus interface and is used to set the interface into a know valid state.
Transactional properties
Initiative optional definition of the access type. Initiative can have any of the folowing values:
- requires
- provides
- requires/provides
Kind specifies the type of the transactional port. It can be one of the following values, though tlm_port should be used for TLM1 notation, while others whould be used for TLM2:
- tlm_port
- tlm_socket
- simple_socket
- multi_socket
- custom name
Bus width specifies the data width in bits.
Protocol type characterizes the communication protocol. Type can be one of these values:
- tlm
- custom
Protocol can contain a payload specifying the way information is transported. Payload has the following sub elements:
- Name, specifying the payload's name.
-
Type mandatory specification of typing. Can have either of the two values:
- generic
- specific
- Extension determines an extension for the payload.
Abstraction Definition
An abstraction definition can also be linked with a bus definition to provide additional validation for bus connections. Abstraction definition defines what logical signals must be present in the bus interface in order for the bus connection with such abstraction definition to be valid. A logical signal can be either a wire signal or a transactional signal.
Logical signal editor contains a context menu (right mouse button) that provides following options:
- Add initiator signal interface mode
- Add target signal interface mode
- Add system signal interface mode
- Add all unconnected system signals from the bus definition system group
- Reset extended ports to reload the signals that have been extended from the extended abstraction definition
- Add new logical signal (Add row)
- Remove logical signal (Remove row)
- Clear the selected cells
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Import a csv-file to the editor
- Export the contents of the editor to a csv-file
Extended abstraction definition
Allows the creation of a family of interconnectable abstraction definitions. The extending abstraction definition must have a bus type that extends the bus type of the extended abstraction definition. The logical signals of the extended abstraction definition can be used and the following elements can be edited:
- Presence
- Width
- Default value
- Driver
- System group
Logical signal properties
Name is a mandatory unique identifier for the logical signal.
Mode defines for which interface mode the settings apply.
- initiator defines constraints for this signal when present in an initiator bus interface.
- target defines constraints for this signal when present in a target bus interface.
- system defines constraints for this signal when present in a system bus interface with a matching group name.
Presence is an optional restriction for the logical signal presence in a bus interface. It can have one of the following three values:
- required indicates that the logical signal must appear in the connected bus interface.
- illegal indicates that the logical signal must not appear in the connected bus interface.
- optional does not apply any restrictions. This is the default value.
Qualifier is an optional indicator for what kind of information the the signal carries. It can have any combination of the following values:
- address indicates that the signal carries address information.
- data indicates that the signal carries data.
- clock indicates that the signal carries clock information.
- reset indicates that the signal is a reset signal for the bus interface and is used to set the interface into a know valid state. The reset level can also be specified either as low or high or undefined.
- valid indicates that the data on the interface is currently valid.
- interrupt indicates that the signal carries reset interrupt information.
- clock enable indicates that the signal carries clock enable information. Clock enable level can be set in a similar manner as reset level.
- power enable indicates that the signal carries power enable information. Power enable level can be set in a similar manner as reset level.
- opcode indicates that the signal carries opcode information.
- protection indicates that the signal carries protection or security information.
- flow control indicates that the signal carries flow control information. Additionally, the flow type can be specified.
- user indicates that the signal carries user-defined information.
- request indicates that the signal carries request information.
- response indicates that the signal carries response information.
Port match specifies that the ports on both sides of the connection need to be present if set to true.
System group helps identify the system interface the signal belongs to. System group is mandatory for system mode and illegal for other modes.
Description is an optional free text for further details.
Wire properties
Direction is an optional restriction for the logical signal direction in the connected bus interface. Direction can have one of the following values:
- in
- out
- inout
Width is an optional definition of the number of bits in the logical signal. If not specified, the number of bits in the connected physical port is used.
Default value is an optional value that is applied when the logical signal is not connected in a connected bus interface.
Driver is an optional setting for defining what kind of a driver the logical signal requires in a complete design. The possible values are the following:
- any indicates that any logical signal or value is valid for driving the signal. This is the default value.
- clock indicates that a repeating waveform is required.
- singleshot indicates that a non-repeating waveform is required.
- none indicates that no driver is required.
Transactional properties
Initiative optional definition of the access type. Initiative can have any of the folowing values:
- requires
- provides
- requires/provides
Kind specifies the type of the transactional port. It can be one of the following values, though tlm_port should be used for TLM1 notation, while others whould be used for TLM2:
- tlm_port
- tlm_socket
- simple_socket
- multi_socket
- custom name
Bus width specifies the data width in bits.
Protocol type characterizes the communication protocol. Type can be one of these values:
- tlm
- custom
Protocol can contain a payload specifying the way information is transported. Payload has the following sub elements:
- Name, specifying the payload's name.
-
Type mandatory specification of typing. Can have either of the two values:
- generic
- specific
- Extension determines an extension for the payload.
API Definition
API definitions are used to define API dependencies between SW components in more detail. API definition wraps an SW library or other API to offer more thorough validation for or both software and system designs and to provide context-sensitive content assistance in the code editor. API definition consists of three types of information:
COM definition reference can be used to reference a COM definition in order to use its transfer types and properties in the function definitions so that the content assist in the code editor can give more detailed assistance.
Data types define all data types the API makes available for use in the code.
Functions list is filled with all functions that the API contains. For each function, all its parameters are defined in detail, including any restrictions that depend on the referenced COM definition.
================================================ FILE: Help/definitions/busdefinition.html ================================================Bus Definition
Bus definitions are used to define bus connections in HW designs. Each bus interface of a component must refer to a bus definition and connected bus interfaces must refer to the same bus definition.
Allow direct connections defines if a bus interface can be directly connected to a non-mirrored bus interface. If unselected, a bus interface can be connected only to a mirrored bus interface of the same type e.g. master to mirrored-master and system to mirrored-system.
Support broadcast defines if a bus interface can be directly connected to more than one opposing interface i.e. supports one-to-many connections. Notice that bridges and mirrored connections are possible even when broadcasts are not supported.
Addressable bus defines if the bus has addressing information and a memory map can be traced through a bus interface.
Max masters on bus defines the maximum number of master bus interfaces connected to the bus. If unspecified, the number of masters is unbound.
Max slaves on bus defines the maximum number of slaves bus interfaces connected to the bus. If unspecified, the number of slaves is unbound.
System group names defines the group names available for signals with the system mode. In bus interface the selected system group limits the logical signals to those with the matching system group name.
Description is a text that describes further details, such as the purpose of the bus and link to the specification.
Extended bus definition allows the creation of a family of interconnectable bus definitions. The following values of the bus interface are set to match the extended bus interface:
- Allow non-mirrored connections
- Support broadcast
- Addressable bus
- System group names are modified to include the names given in the extended bus interface. These cannot be removed or renamed in the bus definition.
- In addition, a placeholder for the description is given from the extended bus definition.
Bus Definition
Bus definitions are used to define bus connections in HW designs. Each bus interface of a component must refer to a bus definition and connected bus interfaces must refer to the same bus definition.
Display name is a short descriptive text for the bus definition. Can be used as an identifier in GUI applications, for instance.
Short description is a compact description of the bus definition.
Description is a text that describes further details, such as the purpose of the bus and link to the specification.
Allow direct connections defines if a bus interface can be directly connected to a non-mirrored bus interface. If unselected, a bus interface can be connected only to a mirrored bus interface of the same type e.g. initiator to mirrored-initiator and system to mirrored-system.
Support broadcast defines if a bus interface can be directly connected to more than one opposing interface i.e. supports one-to-many connections. Notice that bridges and mirrored connections are possible even when broadcasts are not supported.
Addressable bus defines if the bus has addressing information and a memory map can be traced through a bus interface.
Max initiators on bus defines the maximum number of initiator bus interfaces connected to the bus. If unspecified, the number of initiators is unbound.
Max targets on bus defines the maximum number of target bus interfaces connected to the bus. If unspecified, the number of targets is unbound.
System group names defines the group names available for signals with the system mode. In bus interface the selected system group limits the logical signals to those with the matching system group name.
Extended bus definition allows the creation of a family of interconnectable bus definitions. The following values of the bus interface are set to match the extended bus interface:
- Allow non-mirrored connections
- Support broadcast
- Addressable bus
- System group names are modified to include the names given in the extended bus interface. These cannot be removed or renamed in the bus definition.
- In addition, a placeholder for the description is given from the extended bus definition.
Catalog
Catalogs are used to group together IP-XACT documents that are somehow related. For example, a catalog could list all the IP-XACT documents i.e. components, designs and design configurations required in composing a specific product. Catalogs can also include other catalogs.
Description is an optional field for textual description of the catalog.
Catalog files
Catalog files lists the IP-XACT document files contained within catalog. All the files are categorized according to the document type i.e. Components and Designs are listed in separate sections. Items can be added by drag-dropping from the IP-XACT library or creating new rows from the context menu (right mouse button).
Vendor, Library, Name and Version together identify the IP-XACT document in the catalog.
Path is mandatory and defines the path to the IP-XACT document XML file. Path must be defined as relative to the catalog XML-file, as an absolute path or as an external URI. If an URI is used, the schema must be explicitly defined (e.g. http://...).
The Catalog files editor also contains a context menu (right mouse button) that has the following options:
- Opens the selected item (Catalog, Component or Bus) in separate editor. (Open)
- Add new file to the catalog (Add row)
- Remove file from catalog (Remove row)
- Cut the selected cell content to clipboard(Cut)
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Clear the selected cells
- Expand all categories to show all files (Expand all)
- Collapse all categories to hide all files (Collapse all)
Catalog
Catalogs are used to group together IP-XACT documents that are somehow related. For example, a catalog could list all the IP-XACT documents i.e. components, designs and design configurations required in composing a specific product. Catalogs can also include other catalogs.
Display name is a short descriptive text for the catalog. Can be used as an identifier in GUI applications, for instance.
Short description is a compact description of the catalog.
Description is an optional field for textual description of the catalog.
Catalog files
Catalog files lists the IP-XACT document files contained within catalog. All the files are categorized according to the document type i.e. Components and Designs are listed in separate sections. Items can be added by drag-dropping from the IP-XACT library or creating new rows from the context menu (right mouse button).
Vendor, Library, Name and Version together identify the IP-XACT document in the catalog.
Path is mandatory and defines the path to the IP-XACT document XML file. Path must be defined as relative to the catalog XML-file, as an absolute path or as an external URI. If an URI is used, the schema must be explicitly defined (e.g. http://...).
The Catalog files editor also contains a context menu (right mouse button) that has the following options:
- Opens the selected item (Catalog, Component or Bus) in separate editor. (Open)
- Add new file to the catalog (Add row)
- Remove file from catalog (Remove row)
- Cut the selected cell content to clipboard(Cut)
- Copy the contents of the selected cells to clipboard
- Paste the contents of the clipboard to the selected cells
- Clear the selected cells
- Expand all categories to show all files (Expand all)
- Collapse all categories to hide all files (Collapse all)
COM Definition
COM definitions are used to define more strictly the connections that relate to higher-level communication between HW/SW components in a system design. COM definition consists of two types of information: transfer types and properties.
Transfer types is an enumeration of possible data types that define what kind of data can be communicated between components via connections that are based on this COM definition. The used transfer type for each COM interface in a component is selected in the component editor.
Properties offer a way to define certain variables whose value must be set for each COM interface. Properties can be either required or optional. COM definition defines the data type and default value for each of the properties.
================================================ FILE: Help/general/colors.html ================================================ Colors
In Kactus2, elements that are currently in an invalid state are displayed in red. Mandatory fields have lemon chiffon background. Disabled fields have light grey background.
Likewise, in console error messages are displayed in red and regular messages are displayed in blue.
================================================ FILE: Help/general/defaultApplication.html ================================================ Default Application
You may select the default application for each file type within Kactus2. For instance, this could be the default text editor for makefiles.
- Open settings.
- Select Environment variables.
- Double click to create a new row, set the name for the new variable, and set field value as the path to the program.
- Open settings.
- Select File Types.
- Go to the row of the desired file type. Set field Executed with as the variable in format $(VARIABLE_NAME).
- You may also opt to edit the file type within the built-in text editor of Kactus2, although this should be considered mostly as a fall-back.
================================================
FILE: Help/general/expressions.html
================================================
Expressions
Many fields within Kactus2 accept expresions as their input value for easy and fast configuration. The function sign f(x) is used to identify these fields. The input should conform to the SystemVerilog syntax to be acceptable.
Constant values
Constant numeric values can be given as decimal values (e.g. 15) or by explicitly defining the base (e.g. 'h0F for 15 in hexadecimal). The possible bases are 'b (binary), 'o (octal), 'd (decimal) and 'h (hexadecimal). Also fractional numbers (e.g. 0.25) can be used where applicable. Other numeric formats, e.g. 0x000F and 0b0010, will not be accepted.
String values must be given within double quotes e.g. "This is a string value".
Boolean true and false are accepted and will be interpret as 1 and 0, respectively.
Operations
Kactus2 supports the following operations:
| Operator(s) | Description | Example |
|---|---|---|
| +,-,*,/ | Basic arithmetic operations | 2*4 (8) |
| &&,|| | Basic logical operations: AND,OR | 1 || 0 (true) |
| &,|,^,~ | Bitwise logical operations: AND,OR,XOR,NOT | 4'b0011 & 4'b0110 (2) |
| <<,>> | Shift operations | 4'b0011 << 1 (6) |
| ** | Power operation | 2**4 (16) |
| <,>,<=,>=,==,!= | Comparison of two values | 4 >= 2 (true) |
| ==,!= | Comparison of string values | "abc" != "bcd" (true) |
| $clog2() | Ceiling of logarithm of base 2 | $clog(9) (4) |
| $exp() | Exponential function | $exp(2) (0.135335) |
| $pow() | Power function | $pow(2, 4) (16) |
| $sqrt() | Square root | $sqrt(9) (3) |
| ?: | Conditional (ternary) operator | 1?2:0 (2) |
Library Navigation
How to access IP-XACT documents and open them for editors.
VLNV Tree
Documents are sorted to VLNV tree based on the VLNV tuple of a document.
- Select VLNV tree.
- Browse to the desired document, double click to open.
- Right click for context menu. The additional options include opening and creating designs.
- The external interfaces and ad-hoc ports are illustrated in the preview.
Hierarchy Navigation
Documents are sorted to hierarchy display based on their position in designs and sub designs.
- Select hierarchy.
- Hierarchical components are expandable, displaying the associated designs and the components that have instances in the design.
- Hierarchical navigation is recursive, so that a design within a design is also expandable.
- This column displays how many instances in the design use the component.
Library Filters
You may limit the number of displayed IP-XACT documents using filters:
- Hide/show filters
- Only documents which type is checked are displayed. Advanced stands for designs and design configurations.
- Hide documents that do not match the implementation. For instance, unchecking HW hides all hardware components and buses.
- Hide components that do not match any checked hierarchy level.
- Hide components that do not match any checked firmness level.
- Hide documents that have no errors or do have errors.
- Hide documents that do not have the tags listed here.
================================================
FILE: Help/general/shortcuts.html
================================================
Kactus2 shortcuts
Kactus2 uses the following shortcuts.
| Key sequence | Description |
|---|---|
| CTRL + L | Lock/Unlock document. |
| CTRL + {Z, X, C, V, A} | Usual shortcuts for editing |
| F2 | Edit item. |
| CTRL + TAB | Move to the next tab. |
| CTRL + SHIFT + Tab | Move to the previous tab. |
| SHIFT + RETURN | Add a row to table. |
| SHIFT + DEL | Remove selected row(s) from table. |
Toolbars and views
Toolbars
The Kactus2 main window contains a toolbar at the top and sidebars on both sides. The toolbar contains actions for performing common actions within the Kactus2.
The toolbar adapts to the size of the window. If the window gets too small for the toolbar, two buttons for scrolling left and right will be made visible. Scrolling can also be done by using the mouse wheel.
The toolbar hides actions that are not available in the current environment. For example, generators are not show when no component or design has been selected.
UI views can be docked to a sidebar. Multiple views can be docked to the same sidebar and the active view can be hidden by clicking its icon in the sidebar, or changed by clicking the icon of another view.
The toolbar groups
The File group contains functions for controlling the files of the component.
-
New. Creates a new component, design, system, bus, COM definition or API definition.
-
Save. Saves the active document with its current name and location. Activates when a document has been edited. -
Save As. Saves the document with a new name and location. -
Save all. Saves all open documents. -
Print. Prints the currently open design. -
Export image. Export an image of the currently open design document. Possible image formats are SVG, JPG and PNG. -
Import File to Component. Imports elements from a source file e.g. VHDL or verilog to the active component.
The Library group contains functions for maintaining the IP-XACT libraries used by the Kactus2.
-
Configure libraries. Select the libraries used in Kactus2. The libraries can be set as default and active. -
Refresh libraries. Refresh the currently active libraries. -
View Library Integrity Report. Shows a report of errors within all library items. This operation may take a long time with large libraries.
The Protection group shows the current documents editability. The lock status can be changed with this button.
-
Locked. While locked, no changes can be made to the document. -
Unlocked. While unlocked, the documents can be edited and saved.
The Generation group shows all the available generator plugins underneath Run generator:
-
Run generator Runs a chosen generator for the active component. If the active document is a design, all component instances are included in documentation generation.
The Diagram Tools group consist of tools related to the design editors of Kactus2. This group is only visible to the HW, SW and system design editors.
-
Add Column. Creates a new column to the design. In HW design, the type of the possible items in the new column can be customized. -
Select Tool. Allows the selection of items within the HW design. Information regarding the selected item is show on the different editors of the des. -
Interconnection Tool. Allows the creation of interconnections between the interfaces of component instances. After selecting the starting point, the possible ending points for the connection are highlighted in the design. An interconnection cannot be dragged from the starting point to the ending point. Both points must be selected separately. -
Interface Tool. Draft interfaces can be to the component containing the currently opening design. These interfaces must be placed within columns allowing interface items. -
Drafting Tool. Allows the creation of draft component instances and interfaces. The drafted component instances must be placed in columns allowing component instances. Interfaces can be placed either into the component containing the design, or any of the drafted component instances. -
Toggle Off-Page Tool. Changes the selected connections from regular to off-page, and from off-page to regular. Off-page connections are displayed as squares near an interface, and the connected point is displayed when an off-page point is selected. -
Sticky Note Tool. Create notes regarding the currently open design. Notes can be associated with an item contained within the design. This can be achieved through the button located at the top right corner of the note.
The Filtering Tools group has actions for filtering and adjusting the visualization of the memory layout for current component hierarchy. Available only in the Memory Designer.
-
Filter Segments. Show/hide the segments within the address spaces. -
Filter Address Blocks. Show/hide the address blocks within the memory maps. -
Filter Registers. Show/hide the registers within the address blocks. -
Filter Fields. Show/hide the bit fields within the registers. -
Address Space Filter. Show/hide the address space items on the path from the furthest address space to the connected memory maps. -
Unconnected items filter Show/hide unconnected memory items. -
Compress Memory Items. Minimize the vertical space taken by the memory items. When disabled, the item height is relative to the contained address range. -
Compress Field Items. Minimize the horizontal space taken by the bit field items. -
Extend Field Items. Extend the horizontal space taken by the bit field items. This ensures the full name is visible for every item.
The View group has actions for defining the view of the current design. Visible Windows -button is always available.
-
Zoom In. Enlarge the display of the active design. -
Zoom Out. Reduce the display of the active design. -
Original 1:1 Zoom. Return the display to original size. -
Fit Document to View. Fit the currently active document to the available view. -
Visible Windows. Allows changing the visibilities of the available windows. -
Visibilities. Change the visibilities of design items.
The Configuration group contains actions related to configuring the currently open document.
-
View Configuration. Configure the views used in the currently open document. The items are constructed recursively, so that the contained items within a component with a hierarchical view are displayed below said item. This allows the display of all the items contained within the currently active document. -
Open Memory Designer. Opens a view of the memory layout of the underlying component hierarchy. Available only in Hardware Design view.
The Workspace group shows the currently selected workspace.
-
Workspace. Select, delete or create other workspaces. Only non-active, non-default workspaces can be deleted.
The System group contains actions related to the whole system.
-
Settings. Displays the available settings for Kactus2. -
Help. Opens the Kactus2 manual. -
About. Shows information about Kactus2. -
Exit. Exit Kactus2.
Views
Views are used to present additional data regarding the currently open document.
Common
Views that can be displayed regardless of the currently open document:
- Context Help displays help of the currently open document or editor.
- IP-XACT Library shows the used libraries of Kactus2. See library navigation.
- Output displays data of the actions performed by Kactus2.
Vendor Extensions
Vendor Extensions are used to edit the user defined extensions. Depending on the currently active editor, either the extensions of the current document or the active element are displayed.
Design
Views that are related to design documents, both HW and system.
- Connection Editor displays data of the currently active interconnection. See interconnection, ad-hoc connection, api connection or com connection.
- Component Instance Details displays details of the active component instance. See component instance, HW mapping instance, SW component instance.
- Design Configuration Details allows the editing of the design details. The current design configuration can be changed, and the view configuration allows the editing of the active views for the contained component instances.
-
Interface Editor displays data related to the currently active interface:
- Bus interface contains data of the bus type, abstraction type, the interface mode and the contained port maps.
- API interface displays the API type of the interface and its dependency direction.
- COM interface details the COM type, transfer type and direction of the interface, as well as allowing editing of its property values.
HW design
Views for displaying details only related to a HW design.
- Ad hoc port editor allows the editing of ad hoc ports. The port names and directions are displayed, and port visibility can be enabled or disabled.
- Design parameters displays the parameters of the parameters associated with the current design. See parameters.
System design
Views for displaying details related only to a system design.
- HW Mapping Details allows the editing of the referenced HW component and selecting the referenced active view. Additional functions for handling the SW are also provided.
Workspaces
Workspaces allow you to customize the sizes, locations, and visibilities of widgets for specific situations.
- Click workspace button on the top ribbon for workspace menu.
- You may select an existing workspace here.
- Creating new ones and deleting existing ones are supported.
- Insert the name for the new workspace on creation.
You may also customize what is seen in the component editor, while using a workspace:
- Open settings.
- Select Component Editor Visibilities.
- Choose the workspace which you wish to customize.
- Unchecking/checking items hides/shows the component editor section on the row in the hierarchy level of the given column. For instance, you may decide that product level components do not need to show sections for external interfaces.
- By clicking a row or a column header, the whole row or column is checked/unchecked. As another example, you may decide that since this workspace is reserved for software work, it does not need other clock drivers.
You may also customize design editors by dragging and closing the side widgets. For instance, in the image below, the design configuration details widget has been detached to a floating window. You may reopen closed widgets with the visible windows menu highlighted in the image.
================================================
FILE: Help/gettingStarted/accessingDocuments.html
================================================
Step 2: Accessing Documents
- Select VLNV tree.
- Browse to the desired document, double click to open.
- Right click for context menu. The additional options include opening and creating designs.
- The external interfaces and ad-hoc ports are illustrated in preview.
- You need to open protection (ctrl + L) to modify the document. It is protected again with the same button or hotkey, or when protection of another document is opened.
The next step is creating documents.
The previous step was configuring a library.
Step 1: Configuring Library
Kactus2 library settings determine, which folders are scanned for components and other IP-XACT documents.
- Click the configure library button on the top ribbon.
- Click the plus button to add new location by browsing the file system.
- Select the root folder of the documents as the library path.
- Make sure it is both active and default.
- Click OK.
- If any readable IP-XACT documents were found, they will show up under Library items.
Any new documents will be placed under the default location.
The existing documents are scanned from all active locations.
The next step is accessing documents.
================================================
FILE: Help/gettingStarted/creatingDocuments.html
================================================
Step 3: Creating Documents
A new document is required for new IP as well as for IP lacking IP-XACT packaging.
- Click the new button on the top ribbon.
- Select a document type. Detailed descriptions are in their corresponding sections in the manual.
- Bus Definition determines constraints for bus connections.
- Catalog groups IP-XACT documents.
- HW Component describes a hardware IP with behavioral functionality.
- HW Design describes an IP that instantiates and connects other hardware IPs.
- SW Component is used to group software source files and set their build rules.
- SW Design describes an IP that instantiates and connects other software IPs.
- System describes an IP that instantiates and connects software IPs and maps them to hardware IPs.
- API definition describes external functions provided by software components.
- COM Definition determines constraints for interprocess connections.
- In case of HW component or HW design, you may select hierarchy level and firmness. See more details in the component section of the manual.
- Type VLNV tuple for the document:
- Vendor identifies the owner. To ensure uniqueness, it should be their internet domain name in left-to-right order (e.g., tut.fi not fi.tut).
- Library is used to group documents, and thus should reflect the type of the IP-XACT document. This field is auto-filled with the selected hierarchy level, but you may replace it with something more accurate.
- The name should be self-explanatory.
- Technically, another version means another document.
- Select a directory for the new document. Default location is constructed from the VLNV. It is based on the location of the default library, which was chosen in step 1.
- Click OK. If you are creating a component, this will open the component creation wizard. If you are not importing any existing IP, close it by clicking Finish.
The previous step was accessing documents.
================================================
FILE: Help/hwdesign/adhocconnection.html
================================================
Ad-hoc Connection
Ad-hoc connections define the ad-hoc connections for the component instances in the design. They are only used to connect individual physical ports whereas interconnections connect multiple ports grouped in the bus interfaces.
Connection Editor
The Connection Editor shows the properties of the selected connection.
A connection has a mandatory name and an optional description. By default, the connection is named by the connected instances and ports. The name also forms the basis for signal naming in the generated HDL.
The connected ports are shown at the bottom. Left Bound and Right Bound can be used to select the port bits in the connection. For example, a 2-bit port 'chip_select' could be connected to two different instances where the first is connected to the lower bit of 'chip_select' (chip_select[0:0]) and the second to the higher bit of 'chip_select' (chip_select[1:1]).
================================================ FILE: Help/hwdesign/adhocinterface.html ================================================Ad-hoc Interface
See Ad hoc Port.
================================================ FILE: Help/hwdesign/adhocport.html ================================================Ad-hoc Port
Ad hoc Port Details shows the selected port name, direction and bounds as defined in the containing component.
Tied value can be set to connect a port to a constant value e.g. 0 for unsed input. The value can be given as an expression, but it must resolve into a bit value compatible with the port width. Tied value is valid only for in/inout ports of a component instance and out/inout ports of the top-level component.
Ad-hoc ports can be re-positioned by drag-dropping.
================================================ FILE: Help/hwdesign/businterface.html ================================================Bus Interface
See Bus Interface.
================================================ FILE: Help/hwdesign/busport.html ================================================Bus Interface
Bus Interfaces provide the connection points for the components. The access details are defined within the containing component, but the connections are defined in the design. Only compatible bus interfaces can be connected. The bus interface mode is indicated using the following colors:
Bus interfaces can be re-positioned by drag-dropping.
Interface Editor
The Interface Editor shows the selected bus interface bus definition, abstraction definition, name, interface mode and description as defined in the containing component. They are only editable if the bus interface is a draft. Otherwise all changes must be made in the containing component.
Port maps shows the mapping of logical ports on the bus to the physical ports in the containing component.
Exclude can be set to exclude the logical port from the port maps of the bus interface within this design.
================================================ FILE: Help/hwdesign/busport2022.html ================================================Bus Interface
Bus Interfaces provide the connection points for the components. The access details are defined within the containing component, but the connections are defined in the design. Only compatible bus interfaces can be connected. The bus interface mode is indicated using the following colors:
Bus interfaces can be re-positioned by drag-dropping.
Interface Editor
The Interface Editor shows the selected bus interface bus definition, abstraction definition, name, interface mode and description as defined in the containing component. They are only editable if the bus interface is a draft. Otherwise all changes must be made in the containing component.
Port maps shows the mapping of logical ports on the bus to the physical ports in the containing component.
Exclude can be set to exclude the logical port from the port maps of the bus interface within this design.
================================================ FILE: Help/hwdesign/connection.html ================================================Interconnection
Interconnections define the connections for the component instances in the design.
Connection Editor
The Connection Editor shows the properties of the selected connection.
Bus type VLNV and Abstraction type VLNV show the Bus Definition and the Abstraction Definition that define the communication protocol on the bus.
A connection has a mandatory name and an optional description. By default, the connection is named by the connected instances and interfaces. The name also forms the basis for signal naming in the generated HDL.
Connected physical ports shows the physical ports as they are connected in the port maps of the connected bus interfaces and to which port(s) they are connected on the opposing end through the connection.
================================================ FILE: Help/hwdesign/hwdesign.html ================================================Hardware Design
A design describes the structure of a hardware component by instantiating other components from the library and connecting them.
The design area in the center is divided into typed columns to create cleaner layouts. There are four column types: 'Components', 'IO', 'Buses', and 'Custom'. Only items with matching types can be placed on a column. New columns can be created using the Add Column button in the toolbar. The column and its allowed types can edited by double-clicking the column header. The column order can be changed by drag-dropping the columns by the header.
New component instances can be added by by drag-dropping components from
the library into the design area. If dropped on an existing instance, the component will
replace the exisiting instance. Similarly, two existing instances can be swapped by holding the ALT-key
while drag-dropping one on the other.
A hierarchy icon is shown on the top right corner of the instance,
if it has a design of its own. Double-clicking the instance opens the design. If the component
does not have a design, the Component Editor is opened instead. Both options are also available
by right-clicking the instance. All the bus interfaces in the component will be
shown on the component instance and can be connected to other instances by creating an
interconnection with the Interconnection Tool.
Instances can be copy-pasted within the design or into other designs.
Selecting an item in the design shows more details in the windows on the right.
Design Parameters
The Design is configurable through a set of parameters. Parameters are name-value pairs that can be referenced in e.g. configurable element values of the component instances to propagate the same value to every instance. For detailed information on parameters, see the parameters-section in the Component Editor.
Ad-hoc Visibility
The Ad-hoc Visibility window is always visible in the design. It lists all the physical ports on the selected component instance. If no instance is selected, the ports of the top-level component are listed instead. Setting the ad-hoc option for a port shows the individual port on the component instance symbol or in the IO column, if it is a top-level port.
Design Configuration Details
The Design Configuration Details window is always visible in the design. A design configuration contains additional information about an IP-XACT design. Each design can have multiple configurations. Design configuration defines what are the active views of the component instances in the design. While not explicitly mandatory, each component instance used in the design should have an active view defined. Connecting hierarchical draft bus interfaces to component instance bus interfaces require that an active view is defined for that component instance.
Toolbar
Generation group has the tools for automatic generation of e.g. VHDL, Verilog, synthesis and simulation scripts, and HTML documentation.
Diagram tools has all the design-specific actions including adding columns, connections and IO pads. Individual connections can be changed to off-page for cleaner diagrams with Toggle Off-Page Tool. Preliminary components can be designed with the Drafting Tool.
View has the tools for zooming in and out in the design. Zooming is also possible by holding the Ctrl-key while scrolling with the mouse wheel. Visible Windows controls what information is shown i.e. IP-XACT library, component preview, context help and design specific windows on the right. Visibility control allows selection whether design details, such as 'sticky notes', are shown or not.
Workspaces store the window layout and visibilty settings. It is handy for quickly changing the layout depending on purpose, e.g. design editing vs. component packetization.
================================================ FILE: Help/hwdesign/hwinstance.html ================================================Component Instance
Component Instance Details
Component Instance Details window shows the properties of the selected HW component.
Component VLNV shows the component identifier and cannot be changed.
Name is mandatory and used to identify the component instance. The name is also be used in the generated HDL.
Display name is an optional means of providing a user-friendly name for the instance. If defined, it is shown on the component instead of the name.
Description is an optional field for providing design specific details about the component instance.
Parameters are instance-specific configuration options and shows all the component parameters. The value can be set to override the default value in the component. The value is editable only, if the parameter resolve-property is set to 'user' or 'generated' within the component. By default parameters that cannot be edited are filtered out, but will be shown when Show immediate values is selected.
Module parameters are language-specific configuration options (equivalent of VHDL generics or Verilog parameters) similar to parameters. The element value can be set to override the default value in the component.
Ad-hoc Visibility
The Ad-hoc visibility window shows all the physical ports on the selected component. Component symbols show all the bus interfaces by default, but individual ports will be shown only, if they are marked as ad-hoc.
Design configuration
The design configuration is additional information about an IP-XACT design. Each design can have multiple configurations. Design configuration defines what is the active view of a component instance within the design.
================================================ FILE: Help/hwdesign/hwinstance2022.html ================================================Component Instance
Component Instance Details
Component Instance Details window shows the properties of the selected HW component.
Component VLNV shows the component identifier and cannot be changed.
Name is mandatory and used to identify the component instance. The name is also be used in the generated HDL.
Display name is an optional means of providing a user-friendly name for the instance. If defined, it is shown on the component instead of the name.
Description is an optional field for providing design specific details about the component instance.
Power domains editor is used to create and edit references to external power domains of the design component and internal power domains of the component instance component.
Parameters are instance-specific configuration options and shows all the component parameters. The value can be set to override the default value in the component. The value is editable only, if the parameter resolve-property is set to 'user' or 'generated' within the component. By default parameters that cannot be edited are filtered out, but will be shown when Show immediate values is selected.
Module parameters are language-specific configuration options (equivalent of VHDL generics or Verilog parameters) similar to parameters. The element value can be set to override the default value in the component.
Ad-hoc Visibility
The Ad-hoc visibility window shows all the physical ports on the selected component. Component symbols show all the bus interfaces by default, but individual ports will be shown only, if they are marked as ad-hoc.
Design configuration
The design configuration is additional information about an IP-XACT design. Each design can have multiple configurations. Design configuration defines what is the active view of a component instance within the design.
================================================ FILE: Help/hwdesign/interconnectgenerator.html ================================================Interconnect generator
Kactus2 features a generator for generating interconnect components to connect IP blocks in a given design. To launch the generator, press the button
in the configuration tools section, while a design is open:
Overview
The interconnect generator can create IP-XACT models for interconnect components using either transparent bridges or channels for addressing. RTL code generation (verilog) is supported for selected abstraction definitions and interconnect types. The RTL code relies on PULP open source libraries for the functional RTL.
Generator dialog
Interconnect component VLNV editor
VLNV editor is used to define the VLNV for the interconnect component. The generated IP-XACT document will be placed in the default library with a path derived from the VLNV.
Interconnect Component Configuration
The interconnect component requires that an abstraction definition is selected for the bus interfaces that are generated. The abstraction definition should generally match the wanted interconnect type, such as AXI4 or OBI. The listed abstraction definition options are abstraction definitions in use by the bus interfaces of the component instances in the design.
Generate RTL (experimental)
Apart from IP-XACT component description, a verilog RTL file can be automatically generated for supported configurations. RTL file generation is still experimental and requires that interconnect uses a compatible abstraction definition. Currently supported abstraction definitions are TUNI authored AXI4(LITE) and OBI abstractions. RTL generation is recommended for channel-type interconnect components, but bridges are also supported with limited address mapping capabilities. RTL generation also requires that the Verilog generator plugin is enabled. Generated RTL code needs bit width information for address and data widths. This information can be automatically extracted from selected abstraction definition, more information in the Interconnect component parameters section below.
The RTL file is generated to the interconnect component IP-XACT model location and the generated RTL can also be added to a file set by checking the "Add to fileset" checkbox and providing a name for the fileset.
Interconnect component parameters
It is possible to define parameters for the interconnect component. Some parameters are automatically created for RTL generation. These are the address and data bit widths. To automatically extract widths, they must be parameterized in the selected abstraction definition. The disabled fields (grey background) in the screenshot above are automatically extracted width parameters. If no width parameters are found, then they are automatically created with default names ADDR_WIDTH and DATA_WIDTH. Whether the parameters were extracted or created, they cannot be removed during interconnect generation and only the value field can be edited.
Address ports in abstraction definition should use the address width parameter as the port width, and have address qualifier set. The same applies to data ports and data widths. As an example, below is a screenshot from TUNI AXI4LITE abstraction definition:
Interconnect mode
Interconnect modes select which type of component is created: one using transparent bridges as the internal mapping, or one that uses a channel. Address mapping is currently only available for channel-based interconnect components.
Instances to connect
The Instances to connect section consists of a list where component instances found in the design can be selected to be connected to the interconnect component. Instance interfaces to connect can be selected with the round checkboxes.
For both bridge mode and channel mode, at least one initiator/master-adjacent and one target/slave-adjacent interface must be selected. Here, initiator-adjacent refers to an interface, which can be connected to a mirrored initiator/master interface of the interconnect component if channel mode is selected, or a target/slave interface if bridge mode is selected. Target-adjacent refers to an interface that can be connected to a mirrored target/slave interface if channel mode is selected, or an initiator/master interface if bridge mode is selected.
If channel mode is selected, it is possible to address-map the selected interfaces using the Start and Range editors. These editors accept IP-XACT expressions and parameters defined in the parameter editor (see above).
================================================ FILE: Help/index.html ================================================Kactus2 Manual
To access the manual topics, see the contents window (Right click on the menu bar).
Summary
Kactus2 is a toolset for designing embedded products, especially FPGA-based MP-SoCs. The aim is easier IP reusabilility and integration for both hardware and software. The tool is based on IEEE 1685-2014 "IP-XACT" standard.
What you can do with Kactus2
See this page.
Examples
Example IPs are available in GitHub at https://github.com/kactus2/ipxactexamplelib.
Tutorials
Video tutorials are available in Youtube at https://www.youtube.com/channel/UCsilC6PiJ8tH5ltGxL5M8VA.
================================================ FILE: Help/kactus2help.qhcp ================================================Memory Design
Memory design displays all the address spaces and memory maps from the associated HW design. These are
constructed from the component instances and their contained components. Connections made between the bus
interfaces in the HW design are displayed here as connections between the address space referenced by the
connected master bus interface and the memory map referenced by the connected slave interface.
Initially the memory design is shown at the most simple level, all the items and connections are condensed
and both the sub memory items and bridge connections are hidden. These can all be expanded and shown
through the buttons on the Filtering Tools group in the tool bar.
Address spaces are displayed in green on the left side of the view. The address spaces are constructed using the address spaces of the instanced components in the associated HW design. The address spaces can contain address segments.
Memory maps are displayed in blue on the right side of the view. The memory maps are constructed using the memory maps of the instanced components in the associated HW design. The memory maps can contain address blocks, registers and register fields.
The memory items are displayed as rectangular items containing information regarding the memory item.
- Name displays the name of the memory item. If the item has a display name, it is shown instead of the real name.
- Instance name displays the name of the component instance containing the memory item. The instance name is displayed only for the address spaces and memory maps.
- Base address displays the modified base address of the memory item. Displayed at the top corner of the item.
- Last address displays the modified last address of the memory item. Displayed at the bottom corner of the item.
Connections are featured as lines between the connected items, with the connection range displayed on both sides of the connection. Connections and the connected memory items are arrayd so that the ranges of the memory items and their sub memory items match.
Connections are divided into different classes:
- Regular connections. These are regular connections between an address space and a memory map.
- Bridge connections. Bridges are displayed as a connection between a master bus interface and another, bridged master bus interface. These connections are displayed in green, with a modified connection line.
- Local memory map connections. Local memory maps are displayed as connections between an address space and its local memory map. These are displayed in blue, with a modified connection line.
Overlapping connections are displayed in red. with the overlapping range areas displayed next to the connections.
All the sub memory items can be enabled or disabled through the use of buttons in the tool bar. This allows
the user to display only the required information. Additionally, field items can be extended to display
their full name. This can be achieved by pressing the button for extending the field items, or by pressing
ALT together with using the mouse wheel.
The bridged connections are initially hidden, but they can be viewed through the use of Address Space
Filter button.
As the memory items are initially displayed as compressed, it is possible to display them in full. This
can be achieved through the Compress Memory Items button.
API Connection
This is Kactus2 extension
API connections define tight coupling of software component instances
in the design. API interfaces are connected mainly between application and the platform (OS, drivers)
in contrast to COM connections that are used for communication between application modules.
Connection Editor
The Connection Editor shows the properties of the selected API connection.
API type VLNV shows the API Definition that defines the communication protocol through the API.
An API connection has a mandatory name and an optional description. By default, the connection is named by the connected instances and interfaces.
================================================ FILE: Help/swsysdesign/comconnection.html ================================================COM Connection
This is Kactus2 extension
COM connections define the loose coupling of software component instances
in the design. COM connections are mainly used for communication between application modules,
in contrast to API interfaces that are used between application and the platform (OS, drivers).
Connection Editor
The Connection Editor shows the properties of the selected COM connection.
COM type VLNV shows the COM Definition that defines the communication protocol.
A COM connection has a mandatory name and an optional description. By default, the connection is named by the connected instances and interfaces.
================================================ FILE: Help/swsysdesign/hwmappinginstance.html ================================================HW Mapping Instance
This is Kactus2 extension
This instance represents a HW component instance that can be used as a platform
for running software i.e. it has at least one CPU element defined. HW mapping instances are
automatically searched within the selected HW design hierarchy and shown in system design.
Software components can be mapped on the platform by drag-dropping.
Component Instance Details
Component Instance Details window shows the properties of the selected HW mapping instance.
Component VLNV shows the component identifier and cannot be changed.
Name is mandatory and used to identify the instance.
Display name is an optional means of providing a user-friendly name for the instance. If defined, it is shown on the component instead of the name.
Description is an optional field for providing design specific details about the instance.
Property values allow specifying parameters as name-value pairs.
================================================ FILE: Help/swsysdesign/swdesign.html ================================================SW Design
This is Kactus2 extension
User can describe the structure of SW
similarly ot HW design. All SW instantiated in one SW
design will be executes on a single CPU. The mapping of SW
design onto CPU HW is done in a system design.
Select SW components from the library and connect
them.
Instead of interfaces and ports, SW
components have API interfaces. There are two modes, a SW
component can request an API (i.e. make calls to API
functions) or provide it (i.e. implement the API
functions). Connections are allowed only when interfaces match
or if either interface is 'UNSET' (no API VLNV associated with
it).
SW Component Instance
This is Kactus2 extension
Reusable piece of SW that is instantiated as a part of SW
design. Each instance has a mandatory name, and
optionally a display name and textual description.
File set reference refers to a file set of the top component of the design that is to be used in conjunction with the instance.
Property values allow specifying parameters as name-value pairs.
================================================ FILE: Help/swsysdesign/systemdesign.html ================================================System Design
This is Kactus2 extension
A system design describes the software mapping on hardware resources.
Software components can be mapped on hardware accelerators and
CPUs, and connected using COM and API connections.
The design area in the center is divided into typed columns to create cleaner layouts. New columns can be created using the Add Column button in the toolbar. The column name can edited by double-clicking the column header. The column order can be changed by drag-dropping the columns by the header.
New software component instances can be added by by drag-dropping
components from the library into the design area. Hardware components
cannot be added directly, they must be defined in the underlying hardware design.
Double-clicking the instance opens the design.
Selecting an item in the design shows more details in the windows on the right.
Design Configuration Details
The Design Configuration Details window is always visible in the design. A design configuration contains additional information about an the design. Each design can have multiple configurations. Design configuration defines what are the active views of the component instances in the design.
HW Mapping Details
The HW Mapping Details window is always visible in the system design. An HW component reference defines the top level hardware component for which the system design applies. HW component view defines the view containing the hardware design that is used as a platform for the system. Changes to the component reference and view must be confirmed by selecting Apply. Revert can be used to change back to the previous component configuration.
================================================ FILE: Help/swsysdesign/undefinedconnection.html ================================================Undefined Connection
This connection has no defined type yet. Setting the connection endpoint to COM or API interface will automatically change the connection to the corresponding connection type.
================================================ FILE: Help/welcome.html ================================================Welcome to Kactus2
This window will give context-sensitive guidance during your use of Kactus2.
Getting started section will guide you through the basic setup for configuring your IP-XACT library and accessing documents in the library.
The help content can be browsed at any time
by clicking the Help button in the toolbar.
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
================================================
FILE: IPXACTmodels/AbstractionDefinition/AbstractionDefinition.cpp
================================================
//-----------------------------------------------------------------------------
// File: AbstractionDefinition.cpp
//-----------------------------------------------------------------------------
// Project: Kactus 2
// Author: Esko Pekkarinen
// Date: 10.08.2015
//
// Description:
// Implementation for ipxact:busDefinition element.
//-----------------------------------------------------------------------------
#include "AbstractionDefinition.h"
#include