Home

antti kamppi library management implementation on kactus2 ip

Contents

1. a spirit file 2 lt spipit defaultFileEmilder gt lt spirit fileType gt vhdlSource lt spirit fileType gt spirit command vcom spirit command spirit flags quiet check synthesis work hibi mem dma lt spirit flags gt spirit replaceDefaultFlags falsec spirit replaceDefaultFlags z spirj efaultFileBuilder gt lt spirit fileSet gt Figure 2 4 The component editor and the saved XML data for a single VHDL file The part marked with number 1 contains information for the path and options of a single file The path is a relative path from the XML file to the source file The part marked with number 2 contains the compile commands and options for different file types The more detailed and strict the metadata package of an IP block the more precise are the search results and statistics of the library When the packaged data is correct and up 9 to date it is possible to perform different types of data mining operations on the library For example one could generate a weekly report of the library reporting not only the number of IP blocks but also their maturity levels complexity and dependencies 2 3 2 Elements of a component Each IP block will add at least one component document to the library Components can be used to describe processors peripherals such as DMA controllers and buses like the HIBI bus Component contains several elements used to describe different types of informa
2. layout GGricl aout hide Attributes void compactLayout QGHBoxLayout setAttributes prodHier FroductHierarchy firmness Firmness J void E setlmplementation implementation Implementation void VLN Displayer parent Gyvidget vinv LAM const compact bool false J xgetPraductHierarchy ProductHierarchyiguery i VLN Displayer parent CYidget vinv gt YL canst compact bool talse J getFirmness Firmnessigueryi VLN Displayer parent Gyvidget KactusAttributeEditorf parent cv vidaet YLMYDisplayeri scontentChangedi void 3etYLINYT vinv SENS const compact bool talse 1 void zpraductHierarchy hanged void zetPath path String consta J void Figure 8 12 The structure of general editor GeneralEditor is a container class which owns the VLNVDisplayer KactusAttributeEditor DescEditor and ComponentPreviewBox VLNVDisplayer displays the component s VLNV identifier to the user along with the file path of the component s XML file These settings are not editable and if the user wants to change the VLNV then component must be saved as new component with different VLNV KactusAttributeEditor is used to display and edit the Kactus2 attributes of the component which are depicted in Chapter 2 3 3 2 The implementation attribute can t be edited but product hierarchy and firmness are editable Changes in the editor emit contentChanged signal which is connected to general editor
3. FileBuildersEditori is validi booliquery refresh void FolshAL errorMessaget msg G String const amp J void ESIGNAL naticeMezssage msg S String const amp 1 void ESIGMNAL contentChangedo0 void 115 APPENDIX 3 FILE SETS EDITOR FileSetsDelegate MAME COLUMN int eanst OireadOnky 0ESC COLUMN int const 1ireadonly i int const 2ireadOnly LIST EDITOR MIN HEIGHT int const 100 readonl USER DISPLAY ROLE int const Gt UserRoleireadOnlky USER EDIT ROLE int const Gt UserRole 1ireaddnl File SetsDelegater parent GCOohject J FilesetsDelegater createEditori parent eit dget option astyleoptionviewltem const amp index GilWadeallndex const amp Sttvidget query i zetEditorData editor Gu idget index SModellndex const2 J voidiquery sefModelDatac editor slvidget model GAbstracttemModel index aladellndex const amp voldiquers SLOT commitAndoioseEdftorr void FileSetsModel COLUMM COUNT int eanst Siread amp Onky i USER DISPLAY ROLE int const Gt UserRolefread nl USER EDIT ROLE int const Gt UserRole 1iread ni Component QSharedPointer Component E E fileSets GlistecSharedPointer lt FileSet 8 EditableTableView FileSetsModell component asharedPointerzcComponent parent 2Object File SetsModelr rowecaount parent GModellndex const amp cModellndex0C j intigquery
4. zmouseDoubleClickEvent event aldouseEvent J void Library TreevVidgett mousePressEventl event aldouseEvent 1 void sBelectitem viny SEN eonst amp void amp mouseloveEvent event GWouseEvent 3 void ESIGNAL naticeMessadge msg Gistring eonst amp J void EmouseReleaseEventi event GhaouseEvent J void ESIGNAL errorMessage meq EIString const amp J void fcontexthlenuEventi event GContextklenuEvent 3 void ESIGNAL temSelected vinv s LN eanst amp 3 void amp etup Actions void amp etupConnections dataModel LibraryTreeMadel void Figure 7 6 The VLNV tree view classes 1 LibraryTreeModel The tree structure shown to the user is contained in the LibraryTreeModel which is the model class explained in Chapter 7 1 LibraryTreeFilter is connected to VLNVDialer to receive the filtering settings used to select which objects are shown in the view LibraryTreeView is the view class which is visible to the user 62 7 4 VLNV dialer VLNV dialer Figure 7 9 contains the implementations to set filtering and search options which specify the objects to show in the library views hame string level Level childltemz GL isteLibraryltem parentltem Librarvltem ln LNY Librarykemi name Gstring const amp parent GObject J Libraryltem viny v Lh const level Level parent Libraryttem J LibrarsItem createChildi vInv VLA const l
5. FolshAL content changed void SLOT onFileTypeschanged void Figure 8 17 The structure of file general tab FileNameEditor contains a line edit widget which 1s used to set the relative file path to the file Line edit re implements the mouse press event to open a dialog to select a file in the file system FileTypeEditor inherits ListManager which is depicted in Chapter 88 8 1 3 The sub class is used to provide a list of suggestions for pre defined file types listed in the IP XACT standard 6 FileGeneralEditor contains several editors to set e g the description of the file FileBuildCommand contains line editors to set the file specific build command for the file Figure 8 18 shows the GUI classes of file general tab General settings External dependencies and defines Fie name andpath EileNameLineEdit Name vhd fifo vhd File lypeEditor vhdlSource Only used as default File contains external dedarations FileGeneralEditor FileBuildCommand Command vcom Flags check synthesis quiet work work Replace default flags Target file Figure 8 18 The GUI classes of file general tab 8 5 Address space editor Address space editor Figure 8 19 1s used to edit the details of a single address space It also contains a class to visualize the address space and segments it contains to the user Chapter 6 6 1 explains the user interface and the purpose of each element SegmentsModel S
6. EditableListView is the view class displaying the items to the user and providing the graphical user interface The two classes are connected together via Qt s signals and slots mechanism List manager provides interface to set and retrieve list of strings stored in the model Figure 8 9 displays the user interface of the list manager where user is editing a list of group identifiers for a file set sourceFiles documentation projectFiles Add new Remove Figure 6 9 The list manager user interface 81 8 1 4 Name group editor Name group editor Figure 8 10 1s used to edit the NameGroup struct which contains name display name and description fields It is used e g in the file set editor This editor is never used alone but as a member of a parent editor For example file set editor forwards the file set model s nameGroup struct to this editor This way the same editor can be used in several places thus providing a consistent GUI appearance for users amp CrTSucts HameGroup name string displayWame string dezcription QString Namecraupr NameGroupl node apomMade amp Mamecroup name string coanst Namecroupr other NamecGroup const amp J operator other NamecGroup canst amp HamecGroup s HameGroupEditor namecGraup Mamecroup amp nameEdit LineEdit displayMameEdit SLineEdit descriptionEdit CPlainTextEdit NamecroupEditor nameGroup
7. coalumncount parent SModellndex const amp GhWModellndex J intiguers data index ahadellndex canst amp rale int2at DisplayRole J a sariantiquers headerDatal section int orientation Orientation role int 0t DisplayRole J Swarlantiguery i 3 zelbatar index Ghlodelndex const amp value i ariant const amp role int t EditRole 1 bool Tlagsi index Gahodellndex const amp 1 kemFlagsiguery riz alid baoltquers i SLOT on ddftemc index aladellndex const amp J void SLOT onRemoveltem index SModellndex constE 1 void amp NAL contentchangedr void ESIGNAL fileSetAddedr index int J void KomEdit ESIGMAL fileSetRemovedi index int J void em EOIor NAME COLUMN WIDTH int const 2001reacconly DESC COLUMN WIDTH int const 500iread amp Onky i view Editable Tableview model FilezetsModel proxy GSortFiterProxybModel FileSetsEdtorl component asharedPointerzcomponentz FileSetsEditorl Tis Vvalid boolioguesry makechangest void refresh void 116 APPENDIX 4 FILES EDITOR FilesModel USER DISPLAY ROLE int const at LiserRalejreadonl LISER EDIT ROLE int const Gt UserRole 1ireadonkyi handler Librarylnterface component GSharedPointersComponent gt fileSet QSharedPointer FileSet files aList asharedPointersFile 3 Fileskiodelf handler Librarylnterface component QSharedPointer Compon
8. handler Librarylnterface absDef aSharedPointerzA amp bstractionDefinitionr interfaceMode InterfaceMode PortMapstodeli proxy GSortFiterProxyModel busif Buslnterface component asharedPointersComponentsz handler LibraryInterface parent QObject Paorthdapshodel rovyCountl parent amp iadellndex const amp ihodellndex intiquery i column amp ountr parent Sikodellndex const amp OModellndexf J intiauers datai index GModellndex const amp role int2ct DisplayRole j G s ariantiquersy i headerData section int orientation Orientation role int 0t DisglayRole j G v ariantiguery i setDatal index ahladellndex const amp value Gs ariant const amp role int2Gt EditRole 1 bool flagst index GModellndex const amp 3 temFlagsigueryj is valid bool query logicalPorts GiStringListicuery physicalPorts G StringListiguery i canCreateMapl physicalPort GString const amp lagicalPort GString const amp 3 bookiouesryj SLOT onRemoveltemsi index ahodellndex const amp J void TSLOT createMapi physicalPort string canst amp logicalPort astring const amp 1 void 5LOT onRestoreltemi index ahodellndex canst amp 3 void SLOT set amp bsTypei virv YLM Tonst amp mode IntertaceMode j void OSortFilterProxyModel RSIGMHAL contentChangedi void ESIGNAL noticeMessagel msg astring const amp 3 voidiguers ESIGNAL logi
9. isValid is used to know if the items in the model are in valid state The three slots of model are used to add remove and relocate items stored in the model The signal contentChanged is used to inform component editor that the underlying 78 data structure has changed and in order for changes to take effect editor should save the changes Other two signals are used to print errors and notifications to the message console of Kactus2 1f needed QSortFilterProxyModel acts between the model and view classes Its purpose is the sorting of items displayed in the view By using this class sorting of items can be performed without modifying the original data structure This class can be sub classed to provide custom implementation of the sorting The original model class can also be connected directly to the view to leave the intermediate sorter class out The delegate classes inherit QStyledItemDelegate and use the default implementation to render the data Sub classes re implement the following functions to provide data specific editors 1 createEditor constructs the correct editor and returns pointer to it For example strings are often edited with a simple line editor but if the possible options are limited to an enumerated list a combo box can be used 2 setEditorData retrieves the current data from the model and sets it to the editor 3 setModelData retrieves the data set in the editor and saves it to the model The com
10. role int 2it EditRale 1 kool is validi baal query S5LOT an amp dadltem index iahadelndex const amp 1 void 4 SLOT onRemoveltem index OSModellndex const amp void amp SIGNAL contentChanged void SIGNAL memoryhMapAdded index int 1 void ESISNAL memoryh pRemovedi index int void 1 OSortFikerProxyModel Korn Editor ak MemoryMapsEditor view EditableTable View proxy GSofFikterFroxyhbModel model MemoryMapsModel MemaorylapsEditar component asharedPointerscomponentz parent cvvidaet 2r lemoryMapsEdtorl 2 alid boolfquery refresh void 121 APPENDIX 9 MEMORY MAP EDITOR MemoryMapDelegate MemoryMapDelegatel parent GObject MemoryhapDeleqater createEditor parent GuVidget option SStyleOptionviewwtem const amp index Ghodellndex const amp J Widget query setEditorData editor Gvidaet index Giodeallndex const amp J voidiguery i setodelbata editor Gvvidaet model GAbstractkemModel index GModellndex const amp J voidiguery SLOT commitAndi loseEditorr void 1 MemoryMapModel auses memaryMap SSharedFointers lt Memoryhlap kems aListeasharecdPointerzMemoryhapltemz 5 MemoryMapklodell memoryMap asharedPointerzMemaryMapz parent Gobject Eum Wlemoryktapilodelr USAGE COLUMN rowcount parent iiodellndex const amp eaodellndex
11. setModelData editor Ctvidget model CSbstracttemModel index SModellndex const amp J voididquery SLOT commit amp ndcCloseEdritori void eenurmseratioan Column MAME COLUMN OFFSET COLUMN SIZE COLUMM OK COLUMN DESC COLUMN VOLATILE COLUMN ACCESS COLUMN RESET WALUE COLUMN RESET MASK COLUMN COLUMN _ COUNT AddressBlockModel addressBlock GSharedPointer lt AddressBlock tems aListeasharedPointerzRedgisteradelzz x AddressBlockModell address6lock S SharedFointer lt Address6lock parent 2Object AddressBlackModell rowcCount parent GModellndex conste QModellndexC J intiguery i column amp ounti parent tadellndex canst amp aGhodelndext J intiquery flags index QModellndex const amp kemFlagsiguery headerData section int orientation Orientation role int Gt DisplayRole SYariantidgusry data index todallndex const amp role int2Gt DisplayRole Gs ariantiguersy setData index GModellndex const2 value Sariant const amp role int t EditRole J bool is valid baaliquery SLOT onAdaltem index Ghlodellndex const amp J void SLOT onRemoveltem index QModellndex const J void ESIGNAL contentchanged void ESIGNAL tem amp ddedi index int J void ESIGNAL temRemoved index int J void Kom Editor ui AddressEBlockEditor view EditableTable svieve proxy gt GSortFiterProxyModel madel Ad
12. Figure 7 12 depicts the different phases when the user wants to search the disk for new IP X ACT objects EE Bio Eee LibraryHandler LibraryData OSettings 1 Search for objects l LL searchForlPXactFilest 1 l l I I l I 3 parselikraryi 4 value library locationis 5 StringList N loop I 6 parseDirectory directoryPath l T parsefFileifilePath I l loop I 13 ig Valid I j K Aa REESE I 15 getDependentyLMWsi 18 OList Ki E Sa SS s i lobis 17 getDependentFilesi I i 18 cotringList N o D pe er E 19 Figure 7 12 Searching for IP XACT objects on the disk 1 The user clicks to search for new objects in the Main Window user interface MainWindow forwards the request to LibraryHandler 3 LibraryHandler forwards the request to LibraryData which manages the library paths 4 LibraryData uses QSettings to read the saved library paths from a settings file A OSettings returns the library paths in a string list 6 LibraryData calls for its own parseDirectory function to parse the directory structure recursively Phases 6 10 are repeated for each library path and their subdirectories The files in the directory are checked to see if they are XML files 8 Each XML file is parsed to check if it is an IP XACT object 66 12 13 14 15 16 17 18 19 When an IP XACT obj
13. intiguery i calumnCount parent GhWadellndex const amp GMadellndex intjquery flaget index Gladelndex canst amp temFlagsiguery headerCatai section int orientation Orientation role int Ct DisplayRole StYariantiouery i E data index GhWodellndex const amp role int Git DisplayRole 3 G ariantiquery DESCRIPTION COLUMN setData index GModellndex const amp value G seariant const amp role int Gt EditRole 1 kool ACCESS COLUMN tis alid booliuersy VOLATILE COLUMN SLOT onAddltem index Ghdodellndex const amp void COLUMM COUNT SLOT onRemoveltemi index GModellndex const amp void ESIGNAL contentchanaged void ESIGNAL tem amp ddedi index int 1 void ESIGNAL itemRemoved index int void Hem Editor J I U MemoryMapEditor view gt EditableTableVview proxy gt GSofFikerFroxybodel model MemoryMaphodel MemoryMapEdtorr component G sharedFointersComponent memorykiap S SharedPointersMemorybaps parent cWidaet MWemoryMapEditor Tis valid booliogusryj refrezh void 122 APPENDIX 10 ADDRESS BLOCK EDITOR AddressBlockDelegate AddressBlockDelegate parent Gobject AddressBlockDelegater createEditor parent CvYidget option styleoptionsieveItem const amp index altadellndex const amp J EMMidget ouery setEditorData editor vidaet index GModellndex const amp J voididuery
14. pde x p Figure 2 1 A System on Chip containing 4 IP blocks a bus and 5 external interfaces Figure 2 1 contains a large light blue rectangle which is the HIBI bus connecting the other IP blocks On the right side there are blocks performing different functionalities 4 such as PCI Express adapter memory controller and a DMA controller On the edges of the Figure the external interfaces of the chip are shown e g the reset interface The SoCs today may be very complicated containing several different clock regions and dozens or hundreds of IP blocks 4 An example of modern SoC is the Texas Instruments OMAP platform for mobile applications 5 The OMAP platform contains e g two ARM Cortex A9 CPUS vast scale of I O peripherals a DSP processor and a eraphics accelerator This level of complexity sets great demands on testing and verification processes Reuse of IP blocks can greatly ease this workload when one can use the same blocks and subsystems that have already been tested previously In addition to the large number of IP blocks also different configurations of the same system set challenges for the developer For example in the example SoC the PCle adapter could be replaced by an Ethernet interface while the rest of the system remains the same When developing a new system it is not wise to always start all over from scratch but making use of the old systems saves a lot of time and effort One way to upgrade the system
15. vopd arm rin i TUT soc vopd idct m e de2 samos soc vopd inv scan vopd iguan d TUT soc o e mjpeg de2 soc vopd pad a TUT chip vopd run len dec vopd stripe mem davicon dm9000 eth ctrl 1 0 vopd timer vopd up samp a TUT chip vopd vid F push buttons 1 0 TUT chip M SDRAM 8MB 1 0 vopd vop mem vopd vop rec COPECO RC ECR CEC RCE E82 E ip hwp accelerator dct absDef E det busdef TUT chip hibi PP spam 512KB 1 0 m aan N c A TUT board E E rt_binker E 4 ocio 2 sig gen ip hwp communication ju TUT board E ip hwp cpu c e PC design 1 0 x86 1 0 TUT ip hwp cpu T n PP 86 10 ed ip hwp interface l ip hwp misc A TUT board ip hwp storage 8 LA xilinx spartan 3e 1 0 ip swp api ip swp driver e TUT product E ip swp stack samos 2012 pc dct acc mjpeg design 1 0 mcapi nios ai Altera ip hwp cpu 1 0 e nios ii sdram 1 0 E mcapi ublaze Koski gait Altera ip hwp cpu product S e nios ii sram 1 0 samos 2012 TUT ip application on h 263_encoder_main 1 0 TUT ip hwp accelerator dct to hibi 1 0 ax TUT ip hwp cpu soc altera de II demo basic tester hibi example 3 de2 samos soc 10 Figure 5 1 The hierarchical view and the VLNV tree view The hierarchical tree view on the left displays the dependencies between different objects Each component on the tree contains the designs it refers to and the designs contain the compone
16. 2 0 Interface mode slave v Slave Memory map Bridges Master bus interface Opaque hibi pl VI hibi p2 VI General Number of bits in least addressable unit 8 Endianness litte Bit steering Enable F Connection required Parameters Name Value Description busif param value Figure 6 23 The user interface of bus interface editor Bus definition and abstraction definition contain VLNV references to the IP XACT documents associated with this interface Those documents define the qualities this interface must meet e g the abstraction definition defines the logical signals that belong to the bus These logical signals are used to define how the physical ports of the component are connected in the bus This 1s explained in Chapter 6 9 1 1 49 Interface mode selects the interface mode of the bus interface e g slave Below the combo box are the interface mode specific fields used to edit options of the currently selected interface mode With slave these include memory map and bridge info In the general group the addressable unit size defines how many bits are included in the least addressable unit of the bus The default setting is byte addressable 8 bits The endianness indicates whether the interface is big endian or little endian The bit steering can be set to on or off The bit steering on implies that the interface is able to align data on different byte channels in case of addressable interfaces The de
17. File set editor sets the details of a single file set and adds and removes files File sets basically group files together so they can be easily referenced by other sections of a component Figure 6 4 displays the user interface of the file set editor 34 Names Name hdlSources Display Name Description Files File name File path File types Description hibiv2 pkg vhd vhd hibiv2 pkg vhd vhdlSource Hibi segment vhd vhd Hibi segment vhd vhdlSource addr data demuxes vhd vhd addr data demuxes vhd vhdlSource indi Default file build commands File type Command Flags Replace default flags vhdlSource vcom quiet check synthesis work hibi mem dma false Double click to add a new item Group identifiers Dependent directories Figure 6 4 The user interface of file set editor The file path of each file 1s the relative path from the component s XML file File types column displays the file types defined for the file and the description contains the textual description of a single file The file types and description columns are editable but the file name and file path are not The Add Files button opens a dialog used to select files on the disk to add to the file set If a file 1s in invalid state e g missing a mandatory file type then the file 1s displayed in red color The order of files is maintained and can be changed by dragging rows If the compilation order of files is important then the f
18. Ghladellndex 1 intiguery virtual columniCount parent Ghodellndex J intiquery irtual datat index SModellndex role temRole J G arianti query Virtual headerData section int orientation Orientation rale temRole J SYarlantiguery virtual flags index ataodellnndex J temFlagsiguery virtua setCatar index SModellndex value Gwariant rale temRole J bool isvalid boolkiguery t SLOT onA amp daltem index ahModellndex J void SLOT onRemoveltemi index ataodelndex J void SLOT onkoveltemi originalPos aModellndex nevwPos GModellndex J void GNMAL contentChanged auer s i SIGNAL erroarMessage msg QString Wauers i SIGNAL noticeMessagel msg QString MNauery gt _ SortFilterProxyModel EditableTableView QStyleditemDelegate MINIMUM TABLE HEIGHT int const 100 readOnly deflmportExportPath SString pressedFoint Point Delegate virtual createEditor woidiguery addAction GAction removeAction_ Action coo HMM copy Action Action virtual zetEditorData void query i 1 virtual settdodelDatar voidioguery Er oheen SLOT commit amp ndCloseEditar void import amp ction Action exportAction GAction itemsDraggable bool EditableTable siewi parent cvidaet EditableTablevieset SLOT setkemsDCraggabler draggable bool void SLOT oncS vExpart filePath G String const amp cIStringr void SLOT onts Imp
19. IP block is almost useless for third party developers who do not know the detailed implementation of the block In addition to the user manual the documentation files may include class block and seguence diagrams which explain how the IP block functions For hardware IP blocks the datasheets must explain how to configure and boot the IP The documentation material should reveal how to connect the block with the rest of the system and what kind of reguirements it sets for the connections The interfaces of the IP block must be documented clearly For example in software IPs the class interfaces must be defined and for hardware IPs the ports and their timing diagrams must be included 2 2 2 Testing and verification files A test plan should reveal how the testing of the IP block is planned what test cases are planned and how the block is expected to behave in those test cases The test report should explain what tests were executed and how the IP actually behaved in those tests Especially all deviations between the expected behavior and the actual behavior must be reported clearly Test coverage analysis can be used to estimate the quality of the testing and how reliable the IP block is Test log can be used by third parties to repeat the tests and verify the block behavior with the given test cases themselves The types of the test logs may vary from simulation log files to screenshot videos recorded during graphical user interface testing A
20. NamecGroup amp parent GvVidget title astring const amp istring i Names tamecroupEditar getMame SStringiguery i getDisplay Nameg GStringiquery i getbescription SString query SLOT refreshi void ESIGNAL contentchanaed void SLOT onNameChangedi newhame Gstring const amp J void SLOT enDisplayMamechanged neveMame String const J void SLOT onDescrigtionChangedf void Figure 8 10 The structure of name group editor The underlying IP XACT model is edited through a reference this way the editor does not need to know to which element the struct belongs to allowing very generic usage of the editor Name group editor provides functions to retrieve the data set for the editor text fields through getter functions The isValid function can be used to check if the editor is in valid state and refresh slot can be used to update the contents of the editor to match the data stored in the associated model The three private slots listed last on the class are handlers for changes in the editor when the user edits one of the editor fields Figure 8 11 displays the user interface of the name group editor Names Name vhdlSources Display Name HDL sources Description VHDL sources of the component Figure 8 11 The name group editor user interface 82 8 2 General Editor General Editor Figure 8 12 is used to edit the general settings of a component which do not belong to any of the sub e
21. TAMPERE UNIVERSITY OF TECHNOLOGY ANTTI KAMPPI LIBRARY MANAGEMENT IMPLEMENTATION ON KACTUS2 IP XACT TOOL Master s thesis Examiner Prof Timo D H m l inen Dr Erno Salminen Examiner and topic approved by the Faculty Council of the Faculty of Computing and Electrical Engineering on 7 November 2012 TIIVISTELM TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan koulutusohjelma ANTTI KAMPPI Kirjastonhallinnan toteutus Kactus2 IP XACT ty kalussa Diplomity 112 sivua 18 liitesivua Joulukuu 2012 P aine Sulautetut j rjestelm t Tarkastajat Prof Timo D H m l inen ja TkT Erno Salminen Avainsanat J rjestelm piiri IP lohko kirjastonhallinta metadata IP XACT Sulautettujen j rjestelmien koko ja monimutkaisuus ovat viime vuosina kasvaneet kiihtyv ll tahdilla Siksi suunnittelun tuottavuutta t ytyy tehostaa johon on pyritty mm k ytt m ll uudelleenk ytett vi logiikkakomponentteja Uudelleenk yt n tehostaminen vaatii uusia suunnitteluty kaluja ja metodeja IP XACT on XML pohjainen metadata standardi jolla kuvataan uudelleenk ytett vi logiikkakomponentteja eli IP lohkoja ty kalu toteutus ja toimittajaneutraalilla tavalla Ongelmana IP XACT in yleistymisess on ollut ty kalujen tuki Saatavilla ei ole aiemmin ollut vapaan l hdekoodin suunnitteluty kaluja ja kaupalliset vaihtoehdot ovat kalliita mik rajoittaa pienten ja keskisuurten yritysten mahdollisuuksia ottaa IP XACT k ytt
22. TIP DIOCK TOTIMAaTIOM CODIS DES seed E ERE DIEI a aes 4 222b 3Doc tnentattorrTHle 9c xoit n exo abeat hoat snt dotum tett kosti 5 2 252 Testing and yertTicattom Iles ono iet cd amen m ss asen 5 2 2 3 Source files of the implementation oooooon aa een 6 2 2 4 Files to help the initialization of the IP block 6 Deo AP AACTS and ard satasen nona A tabe Nub IUS 6 2 3 1 IP XACT based IP block integration ooooon neen 7 2 92 ElSMSIISOT a componen uictis sue pem us cus ioa dom SHAR du teme e CHE 9 2 99 Extensions to the sandid e s ordo Eco A 10 2 5 9 1 sNewIP XACT 0DJe6ts uii ei a i rg le in Cdi cbe 11 2 3 3 2 Kactus2 attributes for IP block 13 3 uiu 14 A OSIN ON INACUIS2 E 16 4 1 Kactus2implementation lt iussosaasma san cvs tee ero rte ea taco Fede dae aa a AL ANVIAN 19 olli SISRAISO SIOIS ue S an ONT t sae venam is D Ken Sata sa PS kana aaah 19 3 JiManasement otr te BDEAE eiie ntn tind Warten ecstatic aes skies samaa atit 2 Deli Fome ORAL oto nte e MEAM NIME Lee LU Peu IE Mat is 23 5 1 1 Search for new items on the disk eeeeeesreeeeeeeees 24 SLZ Checkins library tite DUIEV mivat aavan s n eta ode tud 24 5 1 3 Parsing item dependencies ccccccccccessseeeeeeceeeeeeeaaeeeseeeceeeeeaaas 25 SIMI IDRIICHRD IMMER T 25 S TENSION MOD u
23. int j void SLOT anlntearationchanged state int J void SLOT ancConfigurationchandged state int J void x globalBox acCheckBox productBox checkbox boardBox acheckBox chipBox QCheckBox soacBox acheckBox 1 aicheckbaox HierarchyOptions HierarchyGroup parent Ctfidget Hierarchy Groupe ESIGNAL options Changed options Hierarchy options const amp 1 void SLOT onGloballhangel state int J void SLOT onProductChanger state int J void SLOT onBoardChange state int void SLOT anChipChange state int void 1 SLOT onSocChangec state int 1 void e e Struct SLOT onlpChangel state int j void FirmnessOptions E templates bool r mutable bool parameterizakle bool aC Structs fixed kool HierarchyOptions FirmnessOptionsi Hierarchy options Figure 7 10 The class diagram of filter widget FilterWidget see Chapter 5 3 2 contains four different group boxes with each of them handling the options for corresponding type TypeGroup s settings are based on the IP XACT object types mplementationGroup FirmnessGroup and HierarchyGroup base their filtering settings to the Kactus2 attributes depicted in Chapter 2 3 3 2 64 7 5 Use cases as sequence diagrams This Section contains 4 sequence diagrams to demonstrate the communication between classes in some of the use cases presented earlier in Chapter 5 75 1 Open hierarchical component in an
24. quinth4 GRectiguery i AddressSpaceEditor addrSpace asharedPointerz amp ddressSpaces 1 nameEditor MamecroupEditor _ AddresssSpaceceneralEditor i SegmentEditor parameterEditor ParametertsroupBox visualizer AddressSpacevisualizer HameGroupEditor 1 Rem Editor AddressSpacecEditorf component E SharedFointer lt Componentz addrspace E SharedPointer lt AddressSpacez parent Widget 0 AddressSpaceEditor ParameterGroupBox ig validi bookigueryj refreshi void 1 Figure 8 19 The structure of address space editor 90 Address space editor is a container for several editors of which 2 are generic editors 1 NameGroupEditor sets the name and description of address space and is explained in Chapter 8 1 4 2 ParameterGroupBox Table 8 1 edits the parameters of the address space SegmentEditor is an editor to add remove and edit the segments inside an address space It follows the presented model view architecture with some modifications SegmentEditor uses the EditableTableView as view class and SegmentsModel provides the model functionality The difference is the SegmentProxy which acts as the proxy model between view and the original model to provide specific sorting functionality by implementing lessthan function AddressSpaceGeneralEditor sets addressable unit size range and width of the address space These gualities are also edited in address spaces editor Table 8 1 AddressSpaceV
25. 000 The purpose of these modules is to enable users to create IP XACT metadata packages for IP blocks and manage the IP library in an efficient way The most important features of the library management are the parsing and writing of the IP XACT metadata integrity checks of the library objects and the dependency management between the library objects For the component editor module the most important elements in the packaging process are the files and interfaces of an IP block These enable the integration of the IP block to larger Systems This Thesis explained the IP XACT elements supported by Kactus2 as well as the hardware related extensions to the standard These extensions enable extending the scope of the IP XACT standard from IP and SoC level to product management and facilitate the packaging of hardware related software such as drivers to the IP blocks The different use cases of the library management were introduced and explained as well as the IP packaging process The implementation details contained the UML class diagrams of the modules and some example sequence diagrams of the library management use cases The possible improvements or changes in the future for the library management module could be the support for databases and library overview report The current file based implementation requires the use of network drives or version control systems if the IP XACT libraries are used by several people The database approach could
26. 111 HDL Designer Mentor Graphics Corporation Wilsonville OR USA WWW accessed on 28 10 2012 Available at http www mentor com products fpga hdl design hdl designer series SOPC Builder Altera Corporation San Jose CA USA WWW accessed on 28 10 2012 Available at http www altera com support software system sopc sof sopc builder html QSys System Integration Tool Altera Corporation San Jose CA USA WWW accessed on 28 10 2012 Available at http www altera com support software system gsys sof gsys index html CoreLink AMBA Designer ARM Holdings Cambridge United Kingdom WWW accessed on 28 10 2012 Available at http www arm com products system ip amba design tools amba designer php CoreBuilder Synopsys Inc Mountain View California United States WWW accessed on 28 10 2012 Available at http www synopsys com dw ipdir php ds core builder CoreAssembler Synopsys Inc Mountain View California United States WWW accessed on 28 10 2012 Available at http www synopsys com dw ipdir php ds core assembler Socrates Weaver Duolog Technologies Dublin Ireland WWW accessed on 28 10 2012 Available at http www duolog com products socrates weaver Magillem IP XACT Packager Magillem Design Services Paris France WWW accessed on 28 10 2012 Available at http www magillem com eda manage your ip portfolio metadata in a fully automated and scriptable way magillem ip xact packager m
27. Appendix o Pile Sets editOE ie o oh statute HE Mee aamen i UEM PN dU 115 Appendix 4 Files C CU Ol iit itedi de pb ote mett s i eq at o sewn RM me cedi dat dunftut 116 Appendix 5 Model parameter editor oiii detenido piso mota id ead uelut rdi oa pesa eg tns 117 Appendix 0 Parameters edio renees a a Seela aim dime a E Tietaa tenes 118 Appendix 7 Address spaces dIEOTE eeu oet da t EU mek Fm eiat 119 Appendix 8 memory maps editor eeseeeeeesseeeeeeseeee enne eene nennen eene 120 Appendix 9 Memory map edlO uires orones tpi Epi earned TN ponente Roda rente e 121 Appendix LOSAGGreSS block edlfOI ue cou enar aea kou d apa eau c TON Etre tesa dee ud 122 AJAppendix EIReegrstet editOE di be ES Oen aod pe UMOR MUS ecd m nM ad Ed E UAE 123 Appendix 12 Views editor oiii MiTo eO Mab t dbi a NT eate dab t bd euet 124 Appendix 13 Environment identifier editor eeeeeeessssssseeeeeeeeeeeeeeeeeennns 125 Appendix 1 POrts eutlOE sssusa sas a o E E a e a 126 Appendix 15 Bus Interface S CdltOtusis ee ioi eite Dedi uo tees Obat DO TANI aus ks eesko 127 Appendix I6 Channels ed1tOTuicu iecit taba kassavaa eua ded eur achat utu v d duree CREE SA 128 Append 7 C PUS EUITOE riui ueste Tuomaan dope vuotenaan kata Poste ni dope Ried sae E DERE 129 APpendik 18 Other clock drivers edltOE suoi oet ose teim pao ar Ub PE eoe neato 130 LIST OF SYMBOLS AND ABBREVIATIONS FPGA IP block IP XACT SoC Metadata Verilog VHDL
28. EIString const amp J voididguery ESIGNAL helpOriReguested url QString const amp J void ESIGNAL child amp ddedi index int void ESIGNAL childRemoved index int void ESIGNAL childWoved source int target int void amp component GSharedPointer Component query i Figure 6 4 The ItemEditor base class The pure virtual functions isValid and refresh must be implemented in base classes to perform the editor specific validation and refreshing of the editor s elements The contentChanged signal is used to inform that the user has edited the component s data structure somehow and the component must be saved in order for the changes to take effect Signals errorMessage and noticeMessage can be used to print notifications to the user in the message console of Kactus2 Signal helpUrlReguested is associated with the context sensitive help system to open a correct help page for the editor when it is shown to the user The childAdded Removed and Moved signals are used to inform the navigation tree that it should add remove or relocate its children under the selected branch 8 1 2 Model view architecture in Kactus2 The model view controller design pattern is commonly used to separate the user interface from the actual data being presented This allows showing the same data in multiple ways e g with a table or a bar chart In Qt the view and controller objects are combined into same class to simplify the
29. InterfaceModestacki busif asharedPointersBuzlnterface component sharedPointer Component handler LibraryInterface parent BuslfiGeneralTab InterfaceModestack refreshfr void SLOT setModef mode InterfaceMode j void SIGNAL contentihangedi void BusfGeneralDetails busif GSharedPointer lt Buslnterface gt connReguired aocheckBox bitslnLau esSpinBax endianness ComboBox bitSteering GicomboBox SST laa ParameterGroupBox HameGroupEditor VLHYEditor Buslfiseneralbetails busit S SharedPointer lt 6Guslnterface gt parent GVyvidget BuslfGeneralbetails 1 1 2 is validi bool query refresht void SIGNAL contentihangedi void ESIGMNAL errorMessaget msg GString const amp 1 voididguery ESIGNAL noticellessaget msg EString const amp J voididuery SLOT onAddressableBnitohangedc new alue int J void SLOT onEndiannesschangedi void SLOT onE6fitSteeringChangedi void SLOT ontonnectionReguiredohangedr void 1 d 1 1 1 BuslfGeneralTab busif GSharedPointer lt Buslnterface gt nameEditor MameiroupEditor busType YLM Editor absType vLN v Editor modeSelector_ InterfaceModeSelector modeStack_ InterfaceModeStack details_ BuslfiseneralDetails parameterz ParameterGroupBox libHandler Librarylnterface BuslfGeneralTab libHandler LibrarsyInterface busit GSharedPointer Businterface component GsharecdPointerzcomponentz p
30. VLNV XML Field programmable gate array Intellectual property block XML based metadata format for automated configuration and integration of electronic systems System on Chip A general term for descriptive data Hardware description language for modeling digital circuits Very High Speed Integrated Circuit Hardware Description Language Vendor Library Name Version eXtensible Markup Language 1 INT RODUCTION This master s thesis is related to FPGA based embedded system design and presents development work for an open source design tool called Kactus2 1 A typical embedded system product consists of a hardware platform and software being executed on one or more programmable cores Hardware platforms consist of system on chips SoC which consist of reusable intellectual property blocks IP blocks An IP block is a reusable unit of logic that is owned by one party 2 Figure 1 1 depicts an example case of a system hierarchy One platform may contain several different implementations and on the other hand same implementation may be ported on several different platforms IP Documentation Testing files Interface defintions Figure 1 1 System hierarchy Today digital systems are getting larger and more complicated at an increasing pace The integration of IP blocks into larger systems and porting of these systems to different platforms has become a complex task Traditionally the solution for these problems has
31. a v ariantidguersy zetbata index atadellndex canst amp value SYarlant const amp rale int lt t EditRole bool Tlagsr index atadellndex const amp 1 temFlagsiguery i izvalid baaltquervy t SLOT enRemoveRowve row int 1 void SLOT onAddRow gt aid SLOT onAdaltem index ahodellndex canst amp J void SLOT onRemoveltem index xGhWodellndex canst amp void ESIGNAL content Cchanged void ESIGNAL error essage meq String const amp 1 voidigquers ESIGNAL noticeWMessage msg string const amp J voidiguery Ronm Editor A view EditableTablevievw model OtherClockDriversModel proxy GSortFikerProxyhbodel OtherClockDriversEditor component C SharedPointercComponentz parent CMYidget O OtherClockDriversEditorf izvalid booliguery refresh void
32. ahadelndex canst amp rale int2Gt DisplayRole J EYarlantiguery i zetbata index aModellndex const amp value SYtarlant const amp rale int 6t EditRole J bool isValid booligueryi SLOT onAdditemt index aModellndex const amp 1 void SLOT onRemoveltemi index Ghladellndex const amp 1 void ESIGNAL contentchanged void ESIGNAL fieldAddedr index int 1 void ESIGNAL fieldRemovedi index int J void Kam Editor a RegisterEditor view EditableTable sview proxy G amp SortFilterPraxvhWodel model RegisterTablekdodel RegisterEditar reg CSsharedPointer lt Registers component G SharedFointersComponent gt parent GMYYidget 0 RegisterEditor r isValid booliguery t refresh void 124 APPENDIX 12 VIEWS EDITOR LineEditDelegate Hilt EDITOR HEIGHT int const 20jreadOnky LineEditDelegate parent GObject 3 LineEditDelegater createEditor parent Gidget option astyleoptionViewveItem canst amp index GModellndex const 1 Midget guer zetEditorData editor cvvidaet index aodellhndex const amp 1 void query zetodelData editor iv vidaet model GAbstractkemModel index alodellndex const amp 1 voidiquery SLOT commitAndoloseEdiktorr void View sModel component GSharedFointer lt Component Views gt taListzasharedPointerz svievw S Viewshiodell component GsharedPointer Component g
33. also defines the transfer type used in the interface and the direction of the communication Of course as mentioned before the hardware component doesn t implement the communication abstraction and therefore the COM interface refers to a software component s which provide the implementation This way e g a DCT accelerator can be used through an MCAPI endpoint 11 in a software application even though the hardware accelerator was not designed to support MCAPI The basic IP XACT standard would require the software drivers to be packaged within the hardware component s file sets The COM extension allows the drivers to be packaged in their own software component which defines its own software interfaces to be used in an application This way the hardware component still contains reference to its drivers but the drivers can also be re used to build other custom software stacks 1f 13 needed Also the API provided by the drivers is explicitly defined in the library and could be used e g to help the software hardware co design 2 3 3 2 Kactus2 attributes for IP block Other extensions are new attributes to describe the hierarchy level implementation type and firmness of the IP block 10 These attributes are used for categorization of the blocks and have no effect how the blocks behave in the tool Making use of these attributes allows library handler to filter the objects shown to the user and also to display the object type to user with
34. amp 3 void i i ComponentEditor libHandler Librarylnterface component GSharedPointer lt Component navigationSplitter_ Splitter editor vigualizerSpliter_ Splitter navigationMadel ComponentEditorTreeodel n vigationvieves ComponentTreevieve editorSlot ComponentEditorGroupSlot visualizerSlot ComponentEditorGroupslat sebidaet widget cvwyidaet 1 void ComponentEditor libHandler LibrarsyInterface component sharedPointerzcomponentz parent Gyvidget ComponentEditor getldentifying LME SVENSIIuersy getDocumentYLMYGO YLNVigueryj isHvvImplementation bookigusry refresh void SLOT validate errorList GStringlist amp 1 bool 5LOT on VvhdlGenerate bool S5LOT saves bool SLOT save bool SLOT onbadelsimcGenerate bool SLOT setProtection lacked bool void SLOT ontemActivated index ihladelndex const amp void SLOT onftem amp hangedi void ESIGNAL opencSourcef filename GString const amp component asharedPointerzcomponent 1 void Figure 8 2 The structure of the component editor 74 The graphical user interface of ComponentEditor can be divided into three parts navigation tree editor area and visualization area On the left side of the GUI is the navigation tree which is implemented by ComponentTreeView acting as the view class and ComponentEditorTreeModel acting as the model class This follows the model vi
35. automatically when the component instances and their connections have been defined like in the example SoC on page 3 2 3 3 Extensions to the standard Kactus2 uses some extensions to the original IP XACT standard These extensions are designed to improve the usability and efficiency of the tool The largest extensions are related to the software design process which is itself out of the scope of this work Figure 2 5 depicts the used extensions and their relation to the original IP XACT standard Implementation Comm abstraction System HW SW d Template _ l Product i Hierarchy Mutable Original scope I Physical Fixed A m a am a a am om i a parts Kactus2 Extensions Firmness process Figure 2 5 The extensions to the scope of IP XACT standard 10 11 2 5 31 New IP XACT objects Figure 2 6 displays the extensions on the implementation axis formulated as a stack These extensions are implemented by new IP XACT object types and interfaces to both new and standard components a SW component b SW design c API SW definition d COM definition e System design SW architecture mapped to HW The new interfaces are API for software components and COM for both HW and SW components COM interface communication abstraction 7 SW component application API interface 77 4 API SW platform interface definition SW com
36. been to develop IP libraries in several different implementation languages such as VHDL Verilog and C programming language This kind of approach results in having systems which contain IP blocks implemented in several different implementation languages radically expanding the range of possible configurations The used design tools also reguire additional information on the systems which increases the configuration count even further This creates demand for tools which efficiently manage the different configurations and variations of products on the market IP XACT metadata provides a possibility to package the IP block s essential information in a tool implementation and vendor neutral way The purpose of this 2 Thesis is to develop a tool which understands IP XACT and is able to manage the IP library based on IP XACT Kactus2 is designed to help the management and integration of reusable intellectual property blocks The Thesis is organized as follows The next Chapter introduces the concepts of IP block and System on Chip It also explains the basics of IP XACT a metadata standard for configuration and integration of IP blocks The third Chapter lists related tools on the market Chapter four introduces the Kactus2 tool which is the main focus of this Thesis The fifth Chapter lists the use cases of library management and sixth Chapter the different phases of IP packaging Chapters seven and eight explain the implementation details o
37. driver Open XML File Hw Design S Design Hw Component Export Delete Item Figure 5 6 Adding a new item to the library The context menu allows the user to select what type of object 1s to be created After selecting the correct action a dialog 1s opened where the user can input the VLNV for the new object The VLNV of the selected object is automatically set to the dialog as default for usability reasons 5 2 2 Open item for viewing or editing Library handler displays the objects in the library in two different views as explained earlier Both views enable the user to open the object in an editor for more detailed viewing Figure 5 7 displays the context menu used to open the editor EI TUT E board EF altera de2 board BPC Open Hw Design EF xilinx spartz E chip Open Component HF clock oscillal E cyclone TI Mew EF davicon dm H push buttor pen XML File Fi SDRAM SME Export E 5MSC LANSI H SRAM 512K Delete Item xilinx spartan xc k Figure 5 7 Open object for editing Different object types have their own editors on Kactus2 Components are edited by the component editor which is explained in this thesis Other editors are not addressed on the thesis but the library handler selects the correct editor automatically based on the object type When opening an object the library handler reads the XML formatted IP XACT file saved on the disk and parses its contents into a data structure A
38. ease the use of libraries over network However the use of version control systems has its advantages allowing the tracking of the changes to the documents The use of databases would probably scale better to very large libraries The reporting feature for the library management module could be used to get an overview of the current library Since the scope of IP XACT has been extended from IP and SoC level to products it might be useful to get statistical analysis of the library or products The reports could include for example 1 The component count and type HW SW System The number of hardware bus definitions or software APIs How many component instances hierarchical components contain on average How many files a component contains on average ae Je How many different products boards or chips the library supports 109 This information could be used to measure the maturity and complexity of the products and the whole library For example it would be possible to save the statistics daily to generate a graph depicting the progress of a product development The component editor module could be improved by adding a packaging wizard to guide through the start of the packaging process This wizard could contain a parser to extract the data of the component s interfaces from the top level VHDL or verilog file This way the component s ports and model parameters could be automatically added to the IP XACT metadata The same parser co
39. editor Figure 7 11 depicts the different phases when the user selects a hierarchical component in the hierarchical library view to be opened in the design editor E tn eme design 2 ondOpenDesianrindex const QModelindexd index 3 onGpenDesign vinv coanst VLNVE in ndeltvinv const vLNv vn 13 z E GsharecPointer T EE TA amp OStringList i gd openDesigncconst VLNV amp vinv const Gistring amp view Mame Figure 7 11 Open hierarchical component to an editor 1 The user selects the desired component through the hierarchical library view 2 The view forwards the request to the model class HierarchyModel 3 HierarchyModel identifies the selected component based on the model index and forwards the VLNV identifier to LibraryHandler 4 LibraryHandler calls LibraryData to parse the component XML file on the disk to Component data structure 5 LibraryData reads the data on the disk and parses the XML into data structure 6 LibraryData returns pointer to the parsed data to LibraryHandler which takes ownership of the class 7 Component is asked for a list of its hierarchical views 8 A list of strings 1s returned which contains the hierarchical view names 9 LibraryHandler forwards the VLNV identifier of the component and the hierarchical view name to MainWindow which manages the editors 65 7 5 2 Search for objects on the disk
40. eroe lab E eap chateau 4 O NIC W SUTDITD IE oxic ys sess sanana Uca vu sir eode Ce Bera acer Di uec vol uon de one ees 42 Ol YR 1 8 neers sas re mu nS nu ICD D d au dS R18 42 OS POMS CCIM dior eto date REM EMEEIMLLMI EM 44 6 9 Busdilterface Summary eria Co ere MM ped itae ie ob ptite Ad Du SDN 46 691 Dus InterTaCe COI OF cuoio dead ideae tec dino piss ado ta id iod dedu ta Ud 48 OO POTMA D oeer a at ses aa mie e RO t 49 0 10 Gio nS sno MR REN 51 OLI PUSS CIO 259i n ae a rs par Rae ESA At amma eo dus usa rome Fbuv uud 52 O12 Other clock drivers COLOR ere R RT 52 Library management Module sereen A T ahte osa Us 53 Jub Data SULLO Scio rebns a Sake M Saska ima Hau Co Ss T s CU aika 55 A2 Merac hy NICW ecean Tote ON bu Pa Toten Matias 50 MER PE Sa VC r M 61 k NEN ARa EET T M T 62 PAM PEEN EO scat Sees Seine e Debo adi SUA Une cii od Ded RUM 63 7 9 Use cases as sequence CIA SAIS uc eser ron rto Eee bo enean ed ees nea Santanan 64 7 5 1 Open hierarchical component in an editor 64 T 9 2 Search for objects n tlie XHSK 2o e eS detta e eto ut aiit 65 42 9 EXPONE d COm DODGE ied rero samas bul be uti MEHR eMe 67 Tou Jeletns a component 6 ore Ree s m em n e anim 68 Coniponmcn editor TOA UG tossa Ta t s S 70 8 1 Common editors and classes oooooonno ae aan nnne 75 Sd Mempeditor interlace tlas eran
41. framework 28 This model view architecture is used in Kactus2 to display and edit lists tables and tree structures Especially the summary tables in component editor module use this architecture to display lists of objects and their attributes Also the library management module uses model view 76 architecture to display the library items to the user Figure 8 5 depicts the model view architecture used in Ot Data XACT O O mA O 5 O Figure 8 5 The Ot model view architecture In case of component editor the source of data is the underlying IP XACT model parsed from the XML file The model class accesses the data to read information and write the changes made by the user Views retrieve data from the model class and show it to the user The sort proxy between model and view classes is optional option a in the Figure and can be used to provide custom sorting operations If the proxy class is missing then the model is connected directly to view option b Custom delegate classes can be used to render the data in a specific way to be shown in the view When the data is edited the delegate communicates with the model to provide appropriate editors and to save the data back to the model The model view architecture is implemented by sub classing Ot s default implementations Figure 8 6 depicts the basic structure of the table editors within component editor module TI QAbstractTableModel virtual row Counti parent
42. parent GtYidget O BuszlnterfaceEditor is valid bool query refresh void SLOT anTabChanger index int 1 void Figure 8 26 The structure of bus interface editor The elements of a bus interface are divided into 2 categories BuslfGeneralTab contains editors to set the general settings of a bus interface and reference the used bus and abstraction definition This editor 1s explained in Chapter 8 8 1 95 2 BuslfPortmapTab is used to specify which ports are connected to the logical signals defined in the abstraction definition assigned in the generals tab This editor is explained in Chapter 8 8 2 8 8 1 Bus interface general settings Bus interface general tab Figure 8 27 provides functionality to set general settings such as name type master slave etc and VLNV references of a single bus interface AddressSpaceSelector BridgesEditor MemoryMap5Selector InterfaceModeSelector 1 1 1 1 1 1 1 1 1 BuslfinterfaceSystem BuslfinterfaceMaster BuslfinterfaceSlave BuslfinterfaceMSlave BuslfinterfaceMonitor 2 2 1 1 1 1 7 1 1 1 InterfaceModeStack kusif GSharedPointer lt Buslnterface gt parent BuslfieneralTab mode InterfaceMade master BuslflnterfaceMaster slave BuslfiInterfaceslave system Buslilnterfacesystem mirroredMaster BuslflnterfacehMaster mirroredSlave BuslflnterfaceM slave mirroredsystem_ BuslflnterfaceSystem monitor BuslflnterfaceMonitor
43. s onAttributesChange slot to set the changes to the model DescEditor provides a text field to view and edit the free textual description of the component When description is edited general editor s onDescriptionChange slot saves the changes to component 83 ComponentPreviewBox displays to the user how the component appears when it is instantiated in a design It shows the different interfaces and possible ad hoc ports Figure 8 13 depicts the GUI classes of general editor endor TUT Library ip hwp interface VLNV Displayer Mame simple udp flood example Version 1 0 Path D SVNwork Funbase IP library trunk TUT ip hwp interface udp Firmness Mutable Implementation HW KactusAttributeEditor Connect to LIDP IP controller Creates TX operations as quickly as possible Destination and packet size are configurable by using generics DescEditor udp i udp ip tx npo antPreview Box F Figure 8 13 The GUI classes of general editor 84 8 3 File set editor File set editor is used to edit a single file set of a component It displays the detailed settings of a file set and provides an editor to add and remove files contained in the file set Figure 8 14 displays the class diagram of file set editor 3roupManager component l Components parent GMvYIdoget 0 component GSharedPointer Component dPointer FileSet parent GuMidget Figure 8 14 The structure of file set edito
44. tests need to be run often When there are several developers writing the code simultaneously and committing the changes very frequently as seen in the Figure 9 3 it is impossible to test and verify all changes manually One way to improve the testing process for Kactus2 could be to implement automated tests for the most basic elements of the software that are no longer subject to rapid changes For example the interface of the library management module has been stable for many releases This way the routine tests could be automated but the testing of new features could be left for exploratory testing thus easing the burden of maintaining the automated tests As the software evolves and matures the amount of automated tests can be increased The modular structure of the software eases the testing especially unit testing The sub editors in the component editor module can be tested as separate pieces which reduces the complexity of the tests Also the underlying IP XACT data structures are modular and it would be very simple to write automated tests for them The library management module could be tested by writing a script which produces an example library After this the library management module could be initialized to a known state through its programmatic interface and certain queries and operations could be performed to the library and their results be verified This way the unit testing for the modules is quite simple to implement The mos
45. the VLSI Journal September 2004 Vol 37 Iss 4 pp 223 252 Texas Instruments OMAP 4 mobile applications platform WWW accessed on 23 10 2012 Available at http www ti com lit ml swpt034b swpt034b pdf IEEE Std 1685 2009 IEEE Standard for IP XACT Standard Structure for Packaging Integrating and Reusing IP within Tool Flows New York 2010 IEEE 360 p Kruijtzer W van der Wolf P de Kock E Stuyt J Ecker W Mayer A Hustin S Amerijckx C de Paoli S Vaumorin E Industrial IP integration flows based on IP XACT standards Design Automation and Test in Europe 2008 DATE 08 pp 32 37 10 14 March 2008 Matilainen M IP lohkojen jaottelu ja nime minen Bachelor s Thesis Tampere 2011 Tampere University of Technology Department of Computer Systems 23 p Kamppi A Matilainen L M tt J Salminen E H m l inen T D H nnik inen M Kactus2 Environment for Embedded Product Development Using IP XACT and MCAPI Digital System Design August 31 September 2 2011 Oulu Finland 2011 pp 262 265 Matilainen M Kamppi A M tt J M H m l inen T D 2011 Kactus2 IP XACT IEEEI685 Compatible Design Environment For Embedded Multiprocessor System on Chip products Technical report 47 p Matilainen L Salminen E H m l inen T D MCAPI abstraction on FPGA based SoC design FPGA World 2012 6 p 12 13 14 15 16 17 18 19 20 21 22 23
46. the information of a single VHDL file and what compile options are set for it hibi segment small 2 0 Component EI External dependencies and defines General General settings 4 File sets N N 4 hdiSources CONtains the build settings for files File name and path Default file builders Mame vhd tx ctrl vhd Elle vhd hibiv2 pkg vhd vhd Hibi segment vhd vhd addr data demuxes vhd vhd addr data muxes vhd vhd addr_decoder vhd vhd cfg init pkg vhd vhd cfg mem vhd vhd copy of multidk fifo vhd vhd double fifo demux wr vhd vhd double fifo mux rd vhd vhd dyn arb vhd vhd fifo vhd vhd fifo muxes vhd vhd hibi wrapper r1 vhd vhd hibi wrapper r3 vhd General aptions hd hibi wrapper r4 vhd a N Logical name hibi 7 Only used as default Specified file types vhdlSource vhd receiver vhd E File is include file E File contains external declarations vhdjrx ctrl vhd dh vhd transmitter vhd Description of the file vhd tx ctrl vhd Model Files contained in this IP block Parameters spirit file edbirit name vhd tr ctrl vhdc spirit name spirit fileType vhdlSource c spirit fileType spirit isIncludeFile spirit externalDeclarations false false spirit isIncludeFile spirit logicalName spirit default false gt hibi lt spirit logicalName gt spirit buildCommand spirit replaceDefaultFlags gt false lt spirit replaceDefaultFlags gt lt spirit ins
47. their dependencies and compilation options could be considered as metadata This kind of metadata is not standardized and the project files are not interoperable between different tools and sometimes not even with different versions of the same tool The closest tool neutral standard for software packaging might be the Linux packet management system 22 but it is meant for higher level packets used to ease the installation of software for personal computers 16 4 OVERVIEW OF KACTUS2 Kactus2 is a metadata based design tool for embedded products It aims to ease the reuse of IP blocks with the help of a graphical user interface The goal 1s to provide a tool implementation and vendor independent method for IP integration using IP XACT metadata The presented Kactus2 version is 2 0 Kactus2 can be used for the following tasks a b c d e g h J Package existing IPs to create electronic datasheets Manage IP XACT library by importing libraries from other vendors checking library integrity and exporting IP library Create quick draft blueprints for IP System on Chip printed circuit board PCB and product all stored in IP XACT format Create system designs used to map SW to HW Create SW architecture using higher level communication abstractions Configure designs to increase reusability of IPs Generate structural top level VHDL code for HW designs Generate code templates including VHDL ent
48. to create IP XACT metadata packages for a component 16 The tool is similar to the component editor module presented in this thesis CoreBuilder supports both the Synopsys coreKits and also IP XACT components It asks the user to input the details of the IP block and then creates the desired package to be used in an integration phase CoreAssembler 1s the integration tool for assembly and configuration of an IP based subsystem 17 Duolog provides an integration tool called Socrates Weaver 18 It supports importing and exporting of IP XACT to integrate IP blocks into larger systems and then creating the metadata package for the entire system 15 Magillem has IP packaging tool called Magillem IP XACT Packager 19 It enables user to Import existing source files such as VHDL to create an IP XACT description which can be used to build the IP library Magillem Platform Assembly is the design and integration tool which uses the IP blocks created with the packager to create larger systems 20 OpenTLM environment provides tools for the development and verification of SystemC TLM IP models The OpenTLM IDE integrates an IP XACT editor which can be used to create edit IP XACT metadata packages 21 The tool is open source and can be downloaded in the project s SourceForge page There are not many tools for packaging software blocks Of course the different project files of development platforms which contain the files needed by the project
49. 0x40000 IM 32 Random access memory read write false Double click to add a new item Figure 6 10 The user interface of memory map editor 38 Usage specifies the type of the address block The possible values are a Memory specifies the entire address block as memory b Register specifies the entire block to contain registers and nothing else c Reserved specifies the entire block as reserved for unknown usage The only type that may contain registers 1s the usage type of register Base address specifies the starting address for the address block It 1s expressed in addressing units from the containing memory map Range of the address block is also expressed in addressing units and specifies how many units the block contains Width is the bit width of a row in the address block The access column is used to specify the accessibility of the block The possible values are a Read write b Read only c Write only d Read writeOnce e writeOnce Value true in volatile column indicates that the stored value may change without assigning a write operation For example a register may change its value in case of an interrupt 6 5 1 1 Address block editor This editor is used to define registers to the address block Each row in the editor specifies a single register Figure 6 11 Registers summary T Offset Size Dimension Description olatil Access Reset value Reset mask INTERRUPT O0 32 0 Interrupt vectors false read writ
50. 3 false read write true unConstrained ADON A D on bit 0 1 true write only oneToSet true unConstrained Double click to add a new item Figure 6 12 The user interface of the register editor Offset describes the starting bit of the field within the containing register Width specifies how many bits are included in the field Volatile indicates that there is no guarantee what a read operation will return because the register may change its value without write operations e g as a result of an interrupt Access column specifies the accessibility of the field the possible values are listed in Chapter 6 5 1 The modified write value describes how the data in the field is manipulated on a write operation For example bits can be set cleared toggled or the value written is stored to the field as such Read action specifies the action that happens after a read operation the possible values are a Empty setting indicates that field is not modified after a read operation b Clear indicates that all bits in the field are cleared after a read operation c Set indicates that all bits in the field are set after a read operation d Modify indicates that the bits in the field are modified in some way after a read operation Testable specifies if the field is testable by an automated register test Test constraint specifies the constraints for the automated tests for the field the possible values are a UnConstrained indicates that there are no co
51. 562 NU ay 60 502 8 0 096 2 60512 i a C 18 416 27 493 59 996 13 541 s9450 3 n 1 117 D 0 096 1 1118 DL 04 NSIS 295 28 8 796 55 yalo o o Jos Pr cm 6B D 0 0 20 ss Lo 00 Make E1 11 15 3 12 aL 00 KEN sre script 7 1 12 5 1 g 00 DOS batch script 5 D 0 0 D 5 09 Totals 185 541 57 128 35 539 258 208 As mentioned before the C code is actually the headers of the C classes which explains the large ratio of comments to code lines in the C code section The makefiles and scripts shown in the table are related to the Linux release versions of Kactus2 102 Figure 9 3 displays the commit count to the SVN repository since the first release of Kactus2 The average commit count per month is about 40 commits Commits per Month Zoom lyr ZU TZ T a po a Tmmmm m ln LUE Taal Apr 12 Jul 12 Ort Figure 9 3 Total commits per month 9 1 Maintainability The maintainability is an important factor and should be considered already in the design process of the software This has been considered in the presented modules as well as the whole Kactus2 by trying to make the software as modular as possible The inheritance mechanism is used to encapsulate the common interfaces and services of the classes For example the library management module has an abstract class Librarylnterface as an interface class If the implementation of the library management should be changed it is possible to simply wr
52. Addressable unit size 8 Width of address block 16 Range of address block 512M Segments Ed itor slot Name Offset 0x0 64M 0x4000000 128M omponentEditorlte 0xC000000 32M 0x16000000 126M Visualization slot Name value Description ComponentTreeView Figure 8 3 The GUI classes of component editor module 75 8 1 Common editors and classes Component editor uses some common classes within several editors whenever possible to make the code easier to maintain For example name and description are fields contained in several different elements making it logical to use the same generic editor for them Also some classes can be used as base classes and only the editor specific functionality is Implemented in sub classes Below is listed the common classes so their detailed descriptions can be omitted from editor specific chapters 8 1 1 Item editor interface class Item editor Figure 8 4 is the base class for all editors used in the component editor It declares the interface which is used to connect the different editors to the component editor s skeleton a Kom Editor Component GSharedPointer Component ItemEditori component iasharedPointerzcomponentz parent Gvvidaet n temEditor islada booligueng confirmEditorChanger bool refesh void ez NAL content hanged void ESIGNAL errorMessage msg Gistring const amp J voidiauers ESIGNAL naticeMessage msg
53. Box advancedBox acheckBox options lmplementation amp ptions options TypeoOptions Implementationtsroupi parent Syyvidget Typeisroupi parent Etv idget J Implementationtsroupi TypEGrOuRi ESIGNAL options Changed options Implementation ptiong const amp 1 void ESIGNAL optionsChanged options TypeOoptions const amp 1 void SLOT onAvvichanged state int 1 void SLOT onComponentChangel state int 1 void SLOT oS hanged state int void SLOT onBuschangel state int J void SLOT onSystem amp Changedi state int J void SLOT onAdvancedlhangel state int J void 1 1 x 4 FilterWidget firmness FirmnessGroup implementation lmplementationtsroujp Ivpe Typecroup hierarchy HierarchyGroup Filkeni dgeti parent Gyvidget Filtervidaeti ESIGMNAL firmnesschanged options Firmnessoptions canst amp J void ESIGMNAL implementation changed options lmplementationOoptions const amp 1 void ESIGNAL typechanged options TypeOptions const amp 1 void ESIGNAL hierarchy Changed options Hierarchy options canst amp J void x x 1 1 lemplateBox acCheckBox mutableBox acheckBox paramseterizableBox acheckBox fixedBox acheckBox options FirmnessOoptions Firmness iroup parent Gividget J Firmnesssroupi ESIGNAL optionsChangedi options FirmnessOptions const amp J void SLOT onTemplatechanged state int 1 void SLOT onBlackChanged state
54. GActian FirmnessOptionsf 7 1 bool i bool components bool buses bool bool i bool parameterizable bhool advanced bool system bool ip bool createMevwComponentAction GAction 7 CreatelewwDesig n amp ction GAction an createWew SADesignAction S6otion HierarchyOptions CreateWeweSystemDesian amp ction SAction 1 delete amp ction G amp ction export amp ction a amp ction showErrorg amp ction G amp ction penBusAction aAction createBusAction_ SAtion addSianals amp ction G amp ction penComDefAction 4ction CreateComDef amp ction CAction LibraryInterface penApiDefAction G amp ction laler YLMYDialer createApiDetAction_ SAction firmness FirmnessOptions penSystemAction action implementation Implementation ptions openXmlAction G amp ction type TypeoOptians Ee i Libraryinterface filter LibraryTreeFilter parent GCMvidget 0 Mob e skitor Library TreeView li j E j ESIGMAL openDesiant index alodellndex const amp void m ata cose ESIGNAL openSvyDesign index GModellndex const amp 3 void versionwalidator QRegexp validator ESIGNAL opensystemDesignt index GModellndex const amp J void QString ESIGNAL openComponent index OModellndex consta void i GString ESIGNAL createWewwComponentc index itadellndex const amp void E OS
55. Ghodellndex intiguerv data index tadellndex caensts amp role int 0ct DisplayRole J Givarianticuers i headerData section int orientation Orientation rale int 1st DisplayRole 7 Gi ariantiguers i 3etCata index SModellndex const amp value G ariant const amp role int 6t EditRole j bool flage index Ghadellndex const amp J temFlagsiguery Tis Valid booljquery i SLOT on amp dditem index QModelindex const amp void S5LOT onRemoveltemi index SModellndex const amp J void EE SIGNAL cantentchanaedi SIGNAL errorklessaget meq string const amp J SIGMAL naticeMessage meg OGString const amp ParameterGroupBox view _ Editable Tabler iew model Parametersklodel proxy GSortFiterProxyModel ParameterGroupGox parameters iListeasharedPointerzParameterz 2 5S parent Ci yidget J ParameterGroupBoxrt 1 Tis validi booljquery i refreshi void ESIGNAL contentChangedi void ESIGNAL errorkessaget meq string consts J voildiguery i ESIGNAL noticeMessagel msg SString const amp J voidiguersy 114 APPENDIX 2 FILE BUILDERS EDITOR FileBuildersDelegate FileBuildersDelegatel parent CObject File6uildersCelegater createEditor parent widget option astyleoptionsievwwltem const amp index OModellndex const amp J Gvyidaet query zetEditorDatar editor Gidget index ataedelndex const amp voidigqu
56. IGNAL busifs amp dded index int J void ESIGNAL busifRemovedi index int void Kom Editor J NAME COLUMN WIDTH int const 100jreadonly i 605 COLUMN WIDTH int const 200jreadonly 465 COLUMN WIDTH int congt 2004readonly i IF MODE COLUMN VADTH int const 100jreadinky view Editable Table jew proxy GsSaortFiltrerProxyMadel madel BuslnterfacesModel BuszlnterfacesEditor handler Librarvlnterface component G SharedPointer lt Component parent Gyyvidget 0 BuszlnterfacesEditar sis valid booljquery refreshf void 128 APPENDIX 16 CHANNELS EDITOR ChannelsDelegate LI5T EDITOR MIN HEIGHT int const 100jread amp onkyi component GSharedPointercComponent ChannelsDelegate component G SharedFointer lt Component parent GiObject ChannelsCelegater createEditor parent Stvidget option SStylkeOoptionvievetem const amp index SModellndex const amp Sitiidget igueryi setEditorData editor StYidget index SModellndex const amp J voidiguery i setModelDatac editor Cividget model GAbstracttemModel index atWodellndex canst amp voididuers i SLOT commit amp ndcloseEditor void sue ChannelsModel z Enumeration es channels GListeGSharedFointer lt Channel USE component azharedPointerzcComponentz lusER DISPLAY ROLE ChannelsMadel component S SharedPointer lt Componen
57. IGNAL cpuddedi index int 1 void 1 PSIGMAL cpuRemovedi index int 1 void Editable Table View 1 Hom Editor A CpusEditor vies Editable Taben iew proxy asartFilterPraxyMaodel madel Cpuskiodel OSortFikerProxyModel CpusEditar component asharedPointerzcompaonentz parent Gvvidaet zn CpusEditorr is valid booliguery refreshf void 130 APPENDIX 18 OTHER CLOCK DRIVERS EDITOR ClockDriversDelegate ClockDriversDelegatel parent object ClockCriversCelegater createEditor parent widget option GstyleOption vievetem const amp index GModellndex const2 j Cividget query i setEditorDatac editor Cddget index Gkodellndex const amp J voididguery setModelDatar editor CWidget model a amp bstractieemhWodel index SModellndex const amp 1 voidzguers SLOT commit amp ndcloseEditor void OtherClockDriver sModel compaonent GSharedPointer lt Component table aListeasharedPointer zotherclockDriverz amp OtherClockDriversModelt component GsharedPointerscomponentz parent Gobject OfherClockDriversModelr rowcount parent aladellndex cansts Ghaodellndex intiquery i caolumncount parent ahodellndex consts aoGhodellndex intiguersy data index atadellndex canst amp rale int 3t DisplayRole J SYarlantiguery i headerDbata section int orientation Orientation role int 0t DisplayRole
58. Libraries OSListeLibrarykem iguery getNames GListeLibrarykem gt iguery T getversions GSiListeLibrarykem iguery LibraryTreeModel dataSource LibraryData rootltem GSharedPointer Libraryttem handler Librarvlnterface LibraryTreeModeli handler Librarvlnterface sourceModel LibraryData parent QObject 0 LibraryTreeModelr headerDatac section int orientation Orientation role int Ct DisplayRole SYarlantiguery i columncount parent GiModellndex const amp chModellndex 1 intiguery i roweitount parent amp tadellndex canst amp uodelndex intiguers index row int column int parent iiuadellndex const amp ihodelndex eWadelncdexidquery parenti child Ghodellndex const amp Ghodellndex query i data index GhWadelndex const amp role int 6t DisplayRole G arianti cuers thasChildrent parent iWadellndex const amp iadelndex boaaltaquers flags index itladellndex const amp 3 temFlagsigusry getRoot0 Libraryltem query index tem Libraryltem Qhlodellndex SIGNAL errordlessage message GiString eonst amp J void SIGNAL noticeMessagel message aString const amp J void SIGNAL openDesian vlnv YLIN const amp 1 void ESIGNAL opensvybesian vlnv YLM const J void SIGNAL opensystemDesignt vlnv YLMW const amp 1 void SIGNAL editkemi vinv VLA const amp void SIGNAL createBusc vIn
59. NISUS vinvToSearch VNV consid mijosenn geil Alidre nt fist gt QLS LAN E vine Tasearch LN conshe Intiaueng geile sign lily fierarchyReft VENE conste J ENT getillesianr hierarchyRer gt VENE conste J gt OSharedgPointerzDesiqnm Svala vine FLA cen sie Y boo SL 07 ORCheckLIDrandntesrba void SL07 opSelectionChabged vine VEM consi Y vola SL OF onClesrSelecton void SL OF onEdittem vin LAY oon st amp J vol SL OF on Opendesignt vine gt VEN consi J void SL OF onCresteNewtemp vine VEA conste void SL OF onCresteDesloanj vibe VEA V conshe volg SL 07 remove Opec vin VA canst J void SL07 remove Opiecisj vinetisi Qristelr NS conste J void SL OF begihSave void SL OF endeave void ESIGNAL errorMessage message QString const j void ExGNAL noticeMessagel message GString const amp J void ESIGNAL openDesigni vInv YLM Y const viewhame SString const amp J void ESIGNAL openBusc busDefyL NY sv NI const absDefYL MM VLA const disableBusDef bool void ESIKGGMNAL opentomponenti waw s NS eonsts amp 1 void ESIGNAL createBusr vin LN eanst amp directory string const amp J void ESIGNAL createcomponentt vin sENSIeanst amp directory Grstring const amp J void SIGNAL create AbsDeti busDefvLNV VENIT eanst amp directory G String const amp disableBusDef bool J void E
60. RefWidget 1s used 1n hierarchical views to set the hierarchy reference to a design or design configuration containing the hierarchical description of the component It only contains one instance of VLNVEditor and its class diagram is therefore omitted Figure 8 24 shows the GUI classes of view editor Display Name Description The flat view containing the component source files NameGroupEditor Environment identifiers Language Tool Vendor specific vhdl Kactus2 EnvIdentifierEditor Double click to add a new item hdlSources FlatViewGenerallab Default file build commands File type Command Flags place default fla vhdlSource vcom check synthesis quiet false FileBuildersEditor Parameters Name Value Description view param value ParameterGroupBox Figure 8 24 The GUI classes of view editor Flat view general tab Figure 8 25 1s used to edit the details of a single non hierarchical View 94 ListManager LA FileSetRefEditor component_ GSharedPointer Component FilesetRefEditor component S SharedPointer lt Component title GC String const trr List parent Gvvidget 0 File SetRefEditorr inftializer tems GStringlist const amp cStringlisti void 1 L1 FlatViewGeneralTab Component QsharedPointer Component vlevw gt GSharedPointer Vievw gt language GLineEdit Janguadgestrict acheckBox madella
61. SKISNAL refreshbialer void ESIGNAL itemselected vInv YLM const J void ESIGNAL openSystemDesigne vInv sv EN consta 3 void ESIKGGMNAL openPlattormComponenti vin sv ER eonst amp J void LibraryHandler 1 1 1 Libraryllata mainvvind_ gt Glhvdain ndowe libraryitems_ GMap VLAY GString handler LibraryHandler 1 LibraryData parent LibraryHandler mainYynd Ghdlainvvindosw 1 LibraryDatal HierarchyModel getPatht viny YLMW const amp string const addYLMYE viny YLM Y const path GString const amp J bool f contains vInv SERI eonsts J kool getltemsi aListevLE Ns iguersy t getType vin v LN canst amp J IPXactTypeiquery parseLibrary showwProgress bool true J void getkdodeli viny VLAN eanst amp 1 GSharedFointer lt LibraryComponent checkLibrarylntearity showProgress bool true J void SIGNAL errorMessage message IString const amp J void ESIGNAL noticeMessager message Gstring const amp J void ESIGNAL remove CONYE vins gt YLI consta J void ESIGNAL add NT vine YLM consta void ESIGNAL resetMadel void SLOT onRemoveYL Yi vin gt SENS const J void SLOT rezetLibrary void getDirectorvy list GStringList 2 J void parseDirectorv directoryPath OSString const amp 1 void parseFile filePath CString const amp 1 void Hierarchyltem Figure 7 3 The data classes used in library manage
62. T an amp ddrllnitcChanged nevetalue int J void SLOT anvWidthichangecd newWdth int 1 void SLOT anRangechanged newRange astring const amp J void AddressSpace yisualizer parent Gividget 2ddressSpacevisualizerf setsegmentsi addrSpace GC SharedPointer lt AddressSpace gt void S5LOT setByteSize bitCount int void SLOT setRowvvidth bitCount int 1 void SLOT setRange byteCount quinte4 void S5LOT zetRange range string const amp J void SLOT addSegment segment S SharedPointer lt Segment void SLOT removesegment zeamentMame astrinq const amp J void SLOT renameSegment aldMame string const amp newMame arSstring const amp J void SLOT updateSegment segment SharedPointer lt Segment gt void amp paintEvent event aPaintEvent J void draweCenteredTextt painter Painter amp text aistring canst amp textCenterPoint GPoint const amp J void drawHeaders painter Painter amp GRect drawHaorizontalLimiter painter aPainter amp bounds GRect const amp legend GString const amp J void draw Gridi painter Painter amp bounds ERect const amp J void draw Segments painter Painter amp bounds GRect const amp columnCount quinte rovetount quint amp 4 J void segmentSreat bounds akect const amp start amp ddress quint amp 4 end amp ddress quint amp 4 calumnicaount quint amp d row Count
63. The icons for different object types 19 4 1 Kactus2 implementation Kactus2 was implemented in C language using cross platform Ot application and UI framework 23 The version used in this work is Ot 4 8 3 There were several reasons for selecting Ot as the development framework Kactus2 is an open source project so a framework which is released with an open source license was desired One of the major reasons was also the ability for cross platform development which enabled the release of Kactus2 for several different operating systems such as Linux Windows and Mac OS X 1n the future Python language was also considered when selecting the framework It has large number of GUI frameworks available and some of the features of Kactus2 such as XML parsing and VHDL code generation would have been easier to implement using Python However this would have made the installation package for Kactus2 more complex because also installation of Python interpreter would have been needed Use of Python was therefore rejected Java would have also been an option but the visual outlook of Java GUI frameworks such as Swing was not satisfactory to the development team The graphical user interface of Kactus2 consists of widgets which display information interact with the user and act as containers for other widgets 24 The used development environment is Microsoft Visual Studio 2008 25 with Ot s Visual Studio add in installed which enables Ot developm
64. a correct icon in the library views Table 2 2 lists the Kactus2 attributes their possible values and their explanations Table 2 2 The different Kactus2 attributes Attribute scope Attribute value Global Does not fit into any other category Represents a final product sours a a Product Hierarchy Board platform e g a circuit board P Represents a single IP block Implementation Contains information about the software component mapping to the underlying hardware platform A model that can be used as a base when creating new components to the library but can t be used Template as such rarameterzble to configure t but carre be modifed further Parameterizable to configure it but it can t be modified further EB naa Fixed is frozen to its final state 14 3 RELATED TOOLS The system design tools on the market can be divided into two different categories There are tools used to compose systems from higher abstraction level models e g by generating executable program code from UML models On the other group are the tools that manage completed IP blocks and integrate them into larger entities The Kactus2 software described in this Thesis belongs to the second group Typically the tools in the second group require that the blocks contain some kind of metadata to ease the integration and configuration of the sub blocks Mentor Graphics provides a tool called HDL Designer which contains a graphical user interf
65. accessed on 28 10 2012 Available at http gt project org doc gt 4 8 model view programming html The Ohloh code indexing project Black Duck Software Inc Burlington MA USA WWW accessed on 7 11 2012 Available at http www ohloh net p kactus2 Doxygen documentation system WWW accessed on 28 10 2012 Available at http www stack nl dimitri doxygen index html Exploratory Testing Explained Bach J WWW accessed on 28 10 2012 Available at http people eecs ku edu saiedian Teaching Fa07 814 Resources exploratory testing pdf 113 APPENDIX 1 PARAMETER GROUP BOX LingEditDelegate MINIMUM EDITOR HEIGHT int canst 20jread amp n LineEditDeledgate parent aiobject LineEditDelegater createEdiftorr parent Stvidget option astyleoptiansvievwItem const amp index SModellndex const amp avwvidaet iaguerv setEditorData editor cvvidaet index SModellndex const amp 1 voildiguery se8tModelData editor c vidaet model GAbstracttemModel index xGtadellndex const amp void query SLOT commit amp ndicloseEditor void ParametersModel alisteisSharedPointers lt Parameters amp parameters ParametersModelf parameters GLjsteisharedPointersParameter2 2 5 parent GOhject ParameterzsMaodel Editable T ableView rowecount parent ahadellndex const amp ahWodellndext int guersy columnicount parent ahodeallndex const amp a
66. ace to instantiate and connect sub blocks by drawing lines between the ports of the blocks HDL Designer supports IP XACT standard but also enables functional descriptions such as state machines 12 Altera provides a tool called SOPC Builder as a part of their Quartus IT development software 13 In this tool the IP blocks are packaged as library components and are connected to each other by using a graphical tool When the connections are made SOPC Builder generates the needed connection logic automatically between the blocks The metadata format used by the tool is not standardized and it is completely tool specific and the connection network is always Avalon bus developed by Altera Altera also provides a tool called OSys which is the newer version of SOPC but the basic principle of the tool is similar 14 ARM has developed a tool called CoreLink AMBA Designer 15 The tool supports IP XACT versions 1 2 and 1 4 which are older than the current IEEE standard 1685 2009 which Kactus2 uses Version 1 4 is guite similar to the latest version but contains differences e g in the register elements The AMBA Designer uses the ARM Fabric IPs and allows the integration and configuration of those IP blocks into larger systems The tool outputs a top level Verilog file which connects the different IPs together and also the top level IP XACT description which can be used in the next level of integration Synopsys has a CoreBuilder tool which can be used
67. ain issue for the testability of Kactus2 as well as the presented modules is the lack of test plans and test documentation The unit testing for the software has been performed by the developers but no documentation of the tests has been written The 106 same problem applies for the integration and system level testing of the software The system testing has been performed using the exploratory testing approach which doesn t use predefined test cases 31 However some kind of documentation on tests that have been executed would help locating the bugs and evaluating the maturity of the software Although the tests were not documented the bug reports of the found defects were saved and documented in a data base As mentioned previously in Chapter 4 1 the development process was very agile and the requirements changed during the implementation phase This caused a lot of re testing of the modules because one minor change in the code especially in the library management module affected several parts of the software Using the exploratory approach demands a lot for the tester when re testing the same module because the temptation to skip certain features which tester believes were not affected is great The use of automated tests could greatly ease the burden of the testing process Of course the writing and especially maintaining of the automated tests causes much work but when using agile development methods it can be justified because same
68. alse m Version 1 0 Parameters Name Value Description view param value Figure 6 18 The view type specific elements The view type is used to select between non hierarchical and hierarchical views The left side of the Figure 6 18 displays the elements for non hierarchical and the right side for hierarchical views Language specifies the HDL for the view e g this may be VHDL or verilog Model name is language specific and therefore depends on the implementation language of the view For VHDL this may be a configuration name or the entity architecture name File set references contain a list of file set names within the component used by this view Default file build commands contain a list of build commands and flags for the files contained in the file sets 44 The hierarchy reference contains a VLNV reference to a design configuration or design document These documents list the sub components instantiated in the hierarchical design and their configurations The design objects can be edited by a design editor omitted from this Thesis The reference to a top level implementation view is a Kactus2 specific extension used to refer to a non hierarchical view containing the rtl implementation of the component Usually a component contains a non hierarchical view which contains the top level structural VHDL This extension refers to the view to include the source codes e g when generating a compilation script for simulation or s
69. amp void ESIGMAL additem index GModellndex const amp J void ESIGNAL removeltem index GModellndex consta void ESIGNAL moveltemi ariginalPas GlWodellndex const amp newPos GlWadellndex const amp void EmouseldoveEventi e QMouseEvent 3 void EkeyPressEventi event GOkeyEvent void EmouseDoukbleClickEvent event GMouseEvent J void EmouseFressEventi event altnuseEvent J void EmouseReleaseEventi event atauseEvent void amp contextMenuEvent event aiContextWenuEvent void amp currentChanged current Cklodellndex const amp previous iaWwWadellndex canst amp 1 void SLOT onddActionr void SLOT onRemoveActioni void ListManager model_ ListhanagerhModcel view _ EditableListview ListManagert title CString const tr List parent G tdget ListManager initialize items EStringList const amp ts StringList void items CStringlist const amp igueryj setltems items stringList eonst amp J void size int query ESIGNAL cantent Changed void Figure 8 8 The class structure of list manager List manager follows the previously mentioned model view architecture with the exception that is uses the default delegate implementation for lists List manager contains two classes to contain the data and display it in the user interface ListManagerModel is the model class managing the item list to be displayed
70. an tell which other objects a component needs but also which components need the specified object This way it 1s possible to check the dependencies in both directions of the hierarchy This functionality can be used e g when opening a component in the component editor If the component is instantiated in one or more designs the user is informed which components are affected Figure 5 5 shows a dialog where the user is asked if he is sure he wants to edit the component which is a sub component in a hierarchical component named de2 sdram example WW Kactus Are you sure you want to unlock the document A Changes to the document can affect 1 other documents If you choose yes this will not be asked next time for this document Yes The component has been instantiated in the following 1 componentis TUT soc de sdram example 1 0 Figure 5 5 A warning informing about the implications of editing the component 5 2 Item management The following use cases are directed specifically to the selected item These use cases are available through the context menu in the library views 5 2 1 Create new item Library handler allows a user to create new items to the library through the context menus in library views See Figure 5 6 for an example 26 TUT El ip hwp cemmunicatian EF hibi orbus H hibi segmenl Open Component H hibi wrapper H hibi wrapper H ip hwp interFace ip swp
71. ap specifies the addressable area seen through a slave bus interface e g the registers that other components can access status control Figure 6 8 displays the user interface of the memory maps editor 37 Memory maps summary Memory map Address unit na bits Description memoryMap 8 The memory map for slave interface data in Double click to add a new item Figure 6 8 The user interface of memory maps editor The address unit bits column is used to define the number of data bits each address increment of the memory map contains The default setting for a memory map is byte addressable 8 bits 6 5 1 Memory map editor Memory map editor is used to set the details of a single memory map by defining address blocks The memory maps use 4 editors each of them extending to different level of detail Address blocks may either define registers or a contiguous block of memory but not both at the same time Figure 6 9 depicts the different levels of memory map Address block Usage register Field Address block Usage memory Contains a contiguous block of memory Figure 6 9 The hierarchy of memory map Figure 6 10 displays the user interface of the memory map editor Address blocks summary b Usage koisen Base address Range Width Description Access Volatile register registers 0x0 512 32 Status and control registers read write true memory ROM 0x200 256k 32 Read only memory read only false memory RAM
72. arent Gvvidaet lm BuslfiseneralTabr 1 isvalidi Baal t query refresh void getEusTypel vLENSTquersy t 3etAbsTypel VEMM Tquersy t ESIGMNA amp L contentohangedi void ESIGNAL errorMessadet msg SString const amp J voidiguery i SIGNAL noticeMessage msg GString const amp 1 voididuery i SLOT onBusTypeChangedr void SLOT an amp bsTypechangedr void SLOT onModecChangedi mode InterfaceMode J void Figure 8 27 The structure of bus interface s general editor 96 BusIfGeneralTab contains 6 different editor types Two instances of VLNVEditor are used to specify a VLNV reference to a bus definition and abstraction definition objects in the library These objects define the gualities of a bus which this interface promises to fulfill NameGroupEditor depicted in Chapter 8 1 4 is used to edit the name and description of the bus interface ParameterGroupBox listed in Table 8 1 is used to set the interface specific parameters BusIfGeneralDetails contains a group of editors for the general settings InterfaceModeStack contains five editors to edit the interface mode specific details of a bus Only one of these editors is visible at a time nterfaceModeSelector is used to select the interface mode and it is connected to the onModeChanged slot in BusIfGeneralTab thus changing the visible editor on nterfaceModeStack The possible modes and their respective editors are shown in Table 8 2 Some edit
73. ble is the total code count which differs from the total count in Table 9 1 The graph contains the total code count including also other languages not related to the implementation and 101 therefore not included in the table Figure 9 2 displays the LOC development by language LOC by Language Zoom lyr 100k October 2012 C 85 070 XML 60 502 C 18 416 HTML 1 117 295 50k 2012 I m mum l oen Jan 12 Apr 12 Jul 12 Oct k Figure 9 2 Lines of code by language The Ohloh tool 29 used to draw the graph interprets the code header files h as C code which results in large amount of C code The code is actually C so by combining the C and C codes the total code count matches with the amount reported on Table 9 1 The XML code comes from the example library of the project as well as the documentation which is mostly UML graphs saved in XML format Also a minor part of the XML is contributed by the project files used HTML is used in the context sensitive help system in Kactus2 The help pages displayed are written in HTML to provide better ability to modify the outlook of the pages compared to basic text files HTML also enables the use of pictures Table 9 2 shows detailed statistics of the used languages Table 9 2 Statistics of the used languages Language Breakdown Language Code Lines Comment Lines Comment Ratio Blank Lines Total Lines Total Percentage 3 Bd 85 070 29 585 25 896 21907 135
74. brary Root oi il j ip hwp ac Versioni not visible Vendorz2 Version2 Figure 7 6 Items in the VLNV tree 7 2 Hierarchy view Hierarchy view displays the library hierarchy in a tree structure Hierarchy view follows the model view architecture see Chapter 8 1 2 for details HierarchyWidget is the container class which owns the view and filter classes and sets the layout for the hierarchy view Figure 7 7 displays the class diagram containing the 3 classes related to hierarchy view 60 handler LibraryInterface filler HierarchyFilter startPos Point draglndex SModellndex openDesignAction_ GAction openSvwyDesign ction gt GSAotion OpentompAetion GAction createMewiomponent amp ction iG amp ction createMewrDesign amp ction GAction CreateWeweSYDesignAction iGi amp ction createNewSystemDesignAction_ Gi amp ction export amp ction G amp ction showvErrore amp ction GAction openBuzAction GAction addSignals amp ction GAction createBus amp ction GAction opencomDefAction GAction createcomDefAction GAction openApibetAction_ GAction createApiDef amp ction GAction OpenSystem otion GIAction openPlatform amp ction ESAeotion openApplicatianAction_ GAction apenEndpoint ction CYAction openxml amp ction a amp ction Hierarchy View parent Widget handler LibrarylInter
75. calkemovedi lagical lame GString const amp voididuers SIGNAL physicalkemovedi physicalName GString const amp 1 voildiousryj SIGNAL errorkiessaget msg G String const amp J vaidiguers Wu PhysListModel component_ SSharedPointer Component PhysListView EE 9 wQ 9 PhysList iew parent Ghvidget Physlistwiew RdropEventi event EDropEvent J void BusifPortmapTab mode ConnectianlWade Porti ist Wodef alist GStringlist amp portMapstodel Portkdapskiodel portapshodel Portktapskiode PortMapsView PortListModell porthlapsMadel PartilapshWadeal parent Gobject 1 PortListkodeli roveCount parent GModellndex const amp GModellndexr intiguery data index GModellndex const amp role int 6t DisplayRole Grvariantiquery i A reesi void removePortsi portList GStringList const amp void removePorti part string const amp 3 void SLOT addPort portName OString const amp void S5LOT removeltemi index alodellndex canst amp J void Ji ZmE m 5L OT removeltemsi indexes SModellndexList const amp 1 void ae wn 5LOT onMoveltemst portMames istringList const amp targetIndex ahadellndex const amp void ee Em e ESIGNAL contentchanged void ESIGNAL error Messager msg GString const amp 1 voldiguery ESIGNAL noticeessage msg EString const amp J voidigquers i PortListView
76. can be to develop a new software implementation which runs on the old hardware platform until a new hardware implementation reaches the market On the other hand old software may be run on a new hardware platform or both of them can be upgraded simultaneously In each case it must be explicit which configurations have been tested and verified 1n each product 2 2 IP block information contents As an example Figure 2 2 depicts the directory structure of the HIBI bus showing the different versions 2 0 and 3 0 the documentation files directory doc implementation files directory vhd and the test benches directory tb Library on the disk Directory vhd Directory doc Mame Mame wt svn VL svn a ey addr data demux read vhd ij Datasheet E E Tmi ey addr data mux write vhd LA clock distribution readme txt O svn lej addr decoder vhd ME hibi v2 to v3 pptx EN ase meshi lej cfa init pkg shd E hibi v3 datasheet 2011 11 15 pdf ED avalon to hibi leg cfg mem vhd m basic tester lei double Fifo demux wr vhd en fh M lej double fifo mux rd vhd 5 Fh mesh 2d ej dyn arb vhd N vA FiFa demux wr vhd fh rin El hibi i lej Fio mux rd vhd A svn les hibi bridge v2 vhd EI m 2 0 lej hibi orbus small vhd hibi segment small vhd m lei hibi segment v3 vhd x sad lei hibi wrapper r1 vhd Z vhd hibi wrapper r3 v hd m 30 Jeg hibi wrapper r4 vhd amp n lei hibiv3 pkg h
77. ces Bus interface groups ports together to form interfaces that e g fulfill requirements of a bus protocol Bus interfaces Bus Abstraction Interface om Definition definition mode Ta sin clk in TUT ip hwp interface clock busdef 1 0 TUT ip hwp interface clock absDef 1 0 slave ddr2 ctrl p TUT ip hwp communication hibi ip r3 busdef 2 0 TUT ip hwp communication hibi ip r3 absdef 2 0 mirroredMaster hibi pl TUT ip hwp communication hibi ip r4 busdef 2 0 TUT ip hwp communication hibi ip r4 absdef 2 0 mirroredMaster hibi p2 TUT ip hwp communication hibi ip rd busdef 2 0 TUT ip hwp communication hibi ip rd4 absdef 2 0 mirroredMaster rst n TUT ip hwp interface reset busdef 1 0 TUT ip hwp interface reset absDef 1 0 slave Double click to add a new item Figure 6 22 The user interface of bus interfaces editor The bus and abstraction definition columns are not editable and they display the VLNV identifiers of the IP XACT documents defining qualities of the hardware bus that the interface fulfills The next two subsections explain how they are edited The interface column is used to select the interface mode of a bus interface There are 7 different interface modes a Master indicates that this interface initiates transactions b Slave responds to transactions c System is something that does not fit into the master or slave category d Mirrored slave is the mirrored version of slave interface and may pro
78. ch the different IP XACT elements in the standard Each item is a sub class of ComponentEditorItem which 72 contains the basic functionality for a tree item On the right side are the different editors for each tree item When a tree item is clicked in the navigation tree the matching editor is displayed to the user All editors are sub classes of ItemEditor which defines the interface for all sub editors ComponentEditorRootltem is the root of the navigation tree and it 1s not displayed to the user Therefore it doesn t have an editor assigned for it 73 zlibHandler LibrarvyInterface component azharedPointerzcomponent model_ ComponentEditor TreeMadel zchildltems iL ist asharedPointerscomponentEditorltemz parent ComponentEditorltem ComponentEditorltem model ComponentEdtorTreeModel libHandler LibraryInterface component SSharedPointer Component parent CompanentEditorltem ComponentEditorltem libHandler Librarylnterface component amp isharedPointerzcomponentz parent ComponentEditor TreeMadal ComponentEditortemi rovw intiquery getlndexOfr child ComponentEditorkem const intiquery rowecCount intiguers j hazcChildren bookiousry childi index int const GSharedPointer lt ComponentEditorkem parent CamponentEditorltem movechild sourcelndex int const targetlndex int void getFont GFontigueryj setLocked lacked k
79. childList Lists vL NYy 7 8 owner YLRM const amp 1 void SLOT onResetMadel void S5LOT onOpenDesignt index ahadallndex const amp void SLOT onOpenseyDesignet index GlWadelndex canst amp J void S5LOT anopensystemDesign index aMadellndex const amp j void SLOT onOpenComponent index GModellndex const amp 1 void SLOT oncreateMewCompanent index GModellndex const amp void S5LOT ancreateMewveDezign index SModellndex const amp void S5LOT ancreateMewvswyDesian index alWadellndex canst amp J void SLOT onCreateNewsystemDesign index GModellndex const amp void SLOT onCreateNew Bus index atWodellndex const amp 1 void S5LOT onCreateNewAbsDet index Ghodellndex const 3 void S5LOT onCreateNewComDeft index aMadallndex const amp void S5LOT onCreateNewApibef index GhMadellndex const amp j void SLOT onExpartitem index itvadellndex const amp 1 void SLOT onShoweErrorsi index atadellndex const amp 1 void S5LOT onRemoveYL NY viny SENS eonst amp 3 void S5LOT ancomponentsaved viny vLNVyeanst amp J void FolSNAL errorMessage meq GString const amp J void ESIGNAL naticeMessage msg GString const amp 1 void ESIGNAL openDesig nt vInv YLR Mconst amp viewName EIString const amp 1 void ESIGNAL opensitDesigno vln v LNS canst amp viesyName GString const amp 1 void FoISNAL opensystemDesignt vine YLMconst vievMam
80. cket_len_g integer nontyped 1000 source_ip_port_g integer nontyped 6000 target MAC addr g std logic vector 47 downto0 nontyped x ACDCABBACD01 target ip addr g std logic vector 31 downto0 nontyped x 0A000001 target ip port g integer nontyped 5000 Double click to add a new item Figure 6 6 The user interface of model parameters editor Each model parameter has a name and a type which is language specific The usage type can be either typed or nontyped Typed parameters appear in object oriented languages e g in C Non typed parameters are found in all languages e g in VHDL all types are non typed Value contains the default value of the model parameter if it isn t assigned in the design upon instantiation 6 4 Parameters editor Parameters editor is used to add remove and modify parameters of a component Figure 6 7 shows the user interface of the parameters editor Some sub elements within the component also contain parameters but the scope of parameters is always restricted to the containing element e g parameters of a view can only be used within that view Component s parameters have the scope of the entire component Value contains the default value of the parameter Parameters Name Value Description parameterl valuel parameter2 value2 Double click to add a new item Figure 6 7 The user interface of parameters editor 6 5 Memory map summary Memory map summary is used to add and remove memory maps Memory m
81. cture depicted in Chapter 8 1 2 and the model classes for the views and filters are HierarchyModel and LibraryTreeModel Figure 7 2 shows which classes are visible in the graphical user interface of library management module IP XACT Library FilterVVidget Library x a w Item T TypeGroup a v Bus API COM Advanced v Component I BuslAPI COM Advanced Implementation Imbfermentation Group Hw M sw I System Product Hierarchy HierarchyGroup I Global W Product v Board vw IP M SoC Item Type Iv Component Implementation v Hw vM zw v System Product Hierarchy Iw Global W Product Iw Board v chip v Soc v IP Firmness i Template W Mutable I Parameterizable w Fixed IFTE FirmnessGroup i Template lv Mutable v Parameterizable w Fixed endor TLIT Library Mame Library pone S DislerWieget ay lt x E Hierarchy VLMV Tree Hierarchy VLA Tree Library items Hierarchy View Instance count Ni items Library TreeView n FM TUT ip Aw communication hibi ip r4 busdef 3 0 global communication ip application ip hp accelerator det absDef Sy 1 0 dck busdef F dct to hibi a 10 S m TUT ip hwp communication hibi orbus 3 am TUT ip hwp communicatian T hibi_segment 3 0 TUT ip Awe communication hibi segment design 3 0 Bali isi da X Libraryltem nication ase meshi topi M TLIT ip hw
82. d EN doc Jeg hibiv3 r4 vhd ED io xat lej lFsr hd En tb lej receiver vhd ED lei rx control vhd A structure txt A transmitter vhd irj Ex control vhd m hibi pe dma n nzhz ET packet codec Figure 2 2 The directory structure and files of HIBI bus 5 The owner of an IP block may use the block in one s own systems or it can be licensed to another party Typically IP block implements a clearly defined functionality and can be used in many systems The block may also be configurable to improve its reusability in different systems By using the same block more than once the cost of development can be spread among several parties The configurability of IP blocks may vary greatly Configurability of a transistor level design is minor but respectively one can estimate for example the performance and timing limitations very well In contrast an IP block which consists of source codes written in VHDL language may be very well configurable but the estimates for its performance are very rough One IP block contains much more than just the source codes the file count may easily increase to dozens or even hundreds of files The better the IP block 1s documented the easier it is to reuse it in another system In addition to the source and documentation files the IP may contain files for testing and verification 2 2 1 Documentation files A user manual is the most important subsidiary deliverable Without the user manual the
83. d a new item Figure 6 16 The user interface of views editor The view type is not editable and is used to inform the user if the view is hierarchical or not A hierarchical view contains a reference to a design or configuration which instantiates sub components A non hierarchical view references the file sets within the containing component Views that are currently in an invalid state will be displayed in red 6 7 1 View editor View editor sets the details of a single view There are 2 types of views hierarchical and non hierarchical as depicted in Chapter 2 3 2 Some elements are common for both view types Figure 6 17 but some change according to the type Figure 6 18 The view type can be changed thus changing the outlook of the editor 43 Name rt Display Name Description The flat view containing the component source files Environment identifiers Language Tool Vendor specific vhdl Kactus2 Double click to add a new item Figure 6 17 The common elements of the view editor The name and description are common for all views as well as the environment identifiers specifying information about the tool environment of the view Language VHDL Strict Fie set references hdlSources View type hierarchical Hierarchy reference Default file build commands lt gt brary soc File type Command Flags place default fla N vhdlsource vcom check synthesis quiet f
84. dressBlockModel AddressBlockEditori address6lock CSharedPointer lt AddressBGlock component sharedPointerzComponentz parent CMvidget N ddress6lockEditorr isvalidt booliouery i refreshf void 123 APPENDIX 11 REGISTER EDITOR RegisterDelegate ReqgisterDelegatel parent Gobject RedisterDelegater createEditor parent Widget option asStyleoptioniewItem const amp index CeModellndex const amp J Mt doget iguery zetEditorData editor etvidget index Ghklodellndex const amp J voidiauersy zetModelbata editor Guidget model ai amp bstractiEemhodel index ialiadelndex const amp J voidiguery i SLOT commitAndoloseEditorr void enumeration Column MAME cuo EI DESC COLUMN OFFSET COL0MRI WIDTH COLUMP VOLATILE _COLUMM ACCESS COLUMN MOD WRITE COLUMN READ ACTION COLUMN TESTABLE COLUMN TEST_CONSTR_COLUMM COLUMN COUNT Register TableModel teg GSharedPointer lt Register fields GListeGSharedPointer lt Field Reuister TableMadel reg SCSharedFointer lt Register parent GObject RegisterTableMaodelri rowcoaount parent SModellndex const amp GModellndext J intigquerv i columncount parent aWMadellndex consts GhMadellndex J intiguerv flage index QModellndex const2 jJ kemFlagsigusry headerData section int orientation Orientation role int 6t DisplayRole J EYarlantiguery data index
85. e QString coanst J void FSIGNAL edtkemi vine SEIN eonst amp J void ESIGNAL createBusDeft vinv YLM const amp 1 void SIGNAL createComponenti wlaw SEN const J void ESIGNAL ereateBus vinv YLAY const amp J void FoISNAL createSbsDetl busDefvLN VENS eansts void FSISGNAL createDesign vine WLAW const 1 void ESIGNAL createsyDesig nt vlnv s Lh consta 1 void FolsNAL createSystemDesign vInv SENS eonst amp 3 void ESIGNAL ereatecombeft vinv ENS eonst amp 3 void FolSNAL createApiDefi vInv SENS eonst amp 1 void SIGNAL exporttemi vin YLNY const J void SIGNAL showErrarst vlnv VLAN eonst amp 1 void SIGNAL invalidateFilter void enumeration ObjectType ROOT COMPONENT BLISDEFIMITIOM ABSDEFIMITIOP COMDEF INITIOM APIDEFIMITIOPM Hv DESIGN Sw DESIGN SYS DESIGN Figure 7 4 The class diagram of hierarchy tree model HierarchyModel provides the hierarchical data structure which can be seen in the library management user interface It constructs a tree structure which represents the object dependencies in the library For example a hierarchical component contains its design objects under it in the tree such as ibi segment in Figure 7 2 Hierarchyltem represents one item in the tree All instances of Hierarchyltem identify a single object in the library HierarchyModel owns only one instance of Hierarchyltem which is the tree root not shown to the user The roo
86. e 0x0 STATUS 020 32 0 Status register true read only 0x80001000 OxFFFFF000 CONTROL 0x40 32 0 Control register false write only 0x0 Double click to add a new item Figure 6 11 The user interface of address block editor Each register has a name and a textual description Offset specifies the location of the register from the start of the containing address block expressed as the number of addressing units Size defines the number of bits the register contains Dimension assigns an unbounded dimension to the register Volatile indicates if the register value may change without a write operation to it e g by an interrupt event Access specifies the accessibility of the register the possible values are listed in the Chapter 6 5 1 The user can set the value that register gets on reset Reset mask defines the bits of the register that have a known reset value Bit value of 1 means that the corresponding bit has a known reset value 0 means that the value is unknown e g the 20 top most bits of STATUS are set 39 6 5 1 2 Register editor Register sets the details of a single register by assigning bit fields to it A bit field may contain just one bit the whole register or something in between Figure 6 12 displays the user interface of the register editor Fields summary Description Offset Width Volatile Access essel lead Testable mn ADCS A D conversion clock select 6 2 false read write true unConstrained CHS Channel select bits 3
87. e implementation and will result in problems during the integration phase Figure 5 1 displays the library views where one object 1s displayed in red meaning that the object 1s not valid The objects can be opened to an editor for closer inspection and errors can be corrected During the integrity check the library handler also provides an error report which is printed to the message console in Kactus2 user interface displayed in Figure 4 1 Each erroneous object is listed and beneath it the errors it contains Finally a summary of different error types found in the library is printed Figure 5 4 displays an example of an error report and the summary of integrity check 25 Processing item Vendor TUT Library soc Name udp flood example dm9000a Version 1 0 Error File vhd udp flood example dm9000a vhd was not found in the file system Processing item Vendor TUT Library system Mame image manipulator swmapping picture manip 1 design Version 1 0 Library integrity check complete found 12 errors within 8 item s Structural errors within item s 5 Invalid VLNV references 4 Invalid file references 3 Figure 5 4 The summary of integrity check and an example of an error 5 1 3 Parsing item dependencies The hierarchical view visualizes both the direct and indirect dependencies of the components The library handler also provides interface for other modules to get a list of dependencies of the library object The handler c
88. e returned in a list LibraryHandler adds the file paths to the dialog The dialog now contains both the VLNV identifiers and the file references Dialog is executed and the user is prompted to confirm the objects to remove LibraryHandler checks if the user accepted the dialog LibraryHandler requests the objects that the user selected to be removed The list of objects is returned to LibraryHandler The list is processed In case of file paths the file is removed from the disk and in case of VLNV reference the XML file of the identified object is removed Finally the directories which were left empty after the delete operations are removed from the disk If some directories still contain other files they are left intact 70 8 COMPONENT EDITOR MODULE Component editor module is used to create the IP XACT metadata package for an IP block It operates on a data structure which is parsed from component IP XACT document type The different elements of component are explained briefly in Chapter 2 3 2 Each element has its own sub editor class and some elements are even divided into several editors due to their complicated structure Figure 8 1 displays the class diagram that contains the basic structure of component editor module and the relations between navigation tree and 21 sub editors 71 ComponentEditorTreeModel TabDocsmenrt ComponentTIreeView ComponentEditor GroupsSliot 1 T 1 2 1 1 141 ComponentEditor ComponentEditorkor K
89. eModel field GSharedPointer Field enum ales GList ttSharedPointer lt Enumerated alues 8 seNUumerations Column EnumeratedYaluehodelr field asharedPointerzField parent object ses NAME COLLIMIP Enumerated valueMocdel ALUE COLUM roweCount parent atlodellndex const amp aGhModellndex intiguery USAGE COLUMN calumncount parent GModellndex const eModellndex intiquery M flags index Gklodellndex const amp 1 IEemFlagsiguery i headerData section int orientation Orientation role int amp t DisplayRole J SYarantigueryj datac index atadellndex const amp role int t DisplayRole 1 EeYarlantiguery zetData index ahoadellndex const amp value a ariant const amp role int 0ct EditRole 1 bool EditableTableView x COLUMN COUNT isvYalidt booliguery t SLOT onAdditemt index GModellndex const amp J void 1 SLOT onRemoveltemi index ahadellndex caenst amp 1 void ESIGNAL contentchanged void ESIGNAL enum amp ddedi index int 1 void ESIGNAL enumRemovedi index int 1 void 1 1 OSortFikerProxyModel am Editor P FieldEditor enum view EditableTable vieuv 1 enumPraxwy GsortFiterProxyModel enumbhiodel Enumerated alueModel E veritetonstr Writer aleconstraintEditor FieldEditor field aSharedPointersField component iaSharedPointerzcomponentz parent Cy vidget 0 E FieldEditor 1 is va
90. ect L ineEditDelegater createEditor parent EvMidoget option GistyleOptionviewltem const amp index GModellndex conste J QVvidget query setEditorDatal editor Guvidget index SModellndex const amp voidigusty i setModelDatai editor v Widaet model GAbstracttemModel index ahadellndex consts J voidigquery SLOT cammit amp ndicloseEditar void Parameter zModel List isharedPointerzParameter amp parameters _ ParametersModelf parameters GListeasharedPointerzParameterz amp parent Qobject J ParameterzMadel rowcaunt parent Glladellndex const amp iaodellndex intigueryj x columncount parent Gllodellndex const amp ieadellndex J intiquersy i data index ahadelndex const amp role int 6t DisplayRole EYarantiguery theaderDatal section int orientation Orientation rale int 0t DisplayRole EYarlantiguery setDatal index Giaodellndex const amp value a ariant const amp rale int 6t EditRole J bool flage index SModellndex const amp J temFlagsigusryi izValid baaliquery SLOT onAddltemi index SkModellndex const amp J void SLOT onRemaoveltemt index atwadellndex canst amp J void TSIGNAL contentChangedf SartFilterProxyModel SIGNAL errorMessaget msg GString const amp SIGMAL noticeMessagec msg SString const amp J O Homi Editor ParametersEditor _ EditableTable szieww _ Paramet
91. ect is found its VLNV searched 10 11 The VLNV of the object is saved along with the file path to the object When all files and folders have been scanned the integrity of the found IP XACT objects is checked The objects are parsed into data structures which contain the information of the XML files First the internal integrity of the object is checked The information on the integrity is returned along with the possible error reports The object dependencies are reguested A list of VLNV identifiers 1s returned which contains the dependencies of the object If one of these refers to an object not found in the library the object is not valid The file references are reguested from the object A list of relative file paths is returned If one of these files is not found in the disk then the object is not valid The possible error reports of the object are printed to the message console for the user to read 67 7 5 3 Exporting a component Figure 7 13 displays a seguence diagram showing the different phases when selecting a component to be exported to a new location on the disk 1 Export i em index caonst oodelndes index 3 an EM const VLNYR vin 4 targetPath 5 String E copyFiles target vInvz handledFiles vesToAll noTo4ll 7 getModel vinv const YLNY vin Figure 7 13 Exporting a component to a new location 1 The user selects a component to be exported to a new loca
92. ed enumerated values are the only legal values that can be written d Set minimum and maximum limits indicating that the user may set the minimum and maximum limits for the values written to the field 41 6 6 Address space summary Address space summary is used to add and remove address spaces The summary enables the user to set the general information of an address space see Figure 6 14 for the user interface AaGaress spaces summary Addressable Name pys unit size Width Range Description instr mem 8 32 2G Double click to add a new item Figure 6 14 The user interface of address spaces editor Addressable unit size specifies the number of bits each address increment contains The default is 8 which means byte addressable Width means the width of a row in the address space in bits The range of an address space is expressed as addressable units e g in this case the address space is 2G 8b 2GB 6 6 1 Address space editor Address space editor is used to set the details of a single address space Address space defines a logical address space used by a CPU Figure 6 15 shows the user interface of the address space editor Names Name instr mem Displa General Addressable unit size 8 Width of address block 32 S H Range Description Range of address block 2G Double click to add a new item Parameters Value Description Figure 6 15 The user interface of address space ed
93. egmentProxy segments GList QSharedPointer lt Segment 3 SegmentProxyi parent GObject SeqmentsModell addrSpace GSharedPointer lt AddressSpaces parent aObject SegmentProxyl SegmentsModelf rowllountl parent GModellndex const amp GModellndex0 intiquery columncountl parent GModellndex const amp GiModellndexf intiguery datai index SModelindex const rale int ct DisplayRole SsYarlantiguery headerDatal Section int orientation Orientation role int Cat DisplayRole G arianticuersy amp etbataf index GModellndex const amp value a s ariant const amp rale int ct EditRole kool 1 flags index GModellndex const amp 1 temFlagsioguery i FEditableTableView is validi baaliquery SLOT en amp ddltem index atadellndex canst amp void 1 1 SLOT anRemoveltem index QModellndex const 3 void SIGNAL eontentChanged void ESIGNAL errordessage msg GString const amp voidiguery i SIGNAL noticeMessagel msg GString const amp J voididguery 1 ESIGNAL zegmentdded segment QSharedPointersSeqment gt J void ESlGNAL segmentkemoved seamentMame Gztring const amp void ESlGN amp L segmentRenamedi aldMame string const amp newMame Gxstring const amp J void 1 ESIGNAL segmentChanged segment sharedPointeresegmentz void SegmentEditor view Editable Table iew proxy SeqgmentPraxy 1 model SegmentsModel E a
94. ement The design and implementation of the library management and IP packaging classes and the user interfaces are described The implementation language was C and the used development framework was the open source version 4 8 3 of Qt The development environment was Microsoft Visual Studio 2008 with the Qt add in installed Qt enables cross platform development which facilitated the release of Kactus2 for both Windows and Linux operating systems The sizes of the presented modules in code lines are 7 500 for library management and 21 000 for IP packaging The corresponding class counts are 26 and 156 The code line count for whole Kactus2 tool is 103 000 lines Library management contains two views of the library structure and a segment to define search options Packaging module contains 28 editors for different elements of the metadata The graphical user interface was designed to be easy to use enabling users to adopt new design methods Also the tool contains a context based help system which reacts to user s actions giving advice related to the task on hand The total download count for different Kactus2 versions is over 1 700 TABLE OF CONTENTS BREAST EE RR NU NTC ne REN ii ADSI P ii Litol symbols and abDEG VIO sien oo boe hd Potete aa vii TatrodtettOm sanasota suossa alakaa sit bte ate ur tom dude ied acit aoi l 2 P O E T E NN 3 DA SV SUSIE On C DID ena a a avaat 3 2 2
95. en instantiated in a design The preview displays the bus interfaces of the component 33 and also the ports that are marked to be seen as ad hoc ports In this case there are 5 bus interfaces 6 2 File set summary The files of a component are grouped together by file sets The grouping can be based on e g the file types sources documentation simulation etc There are 3 different editors for the file packaging the file set summary file set specific editor and file editor File set summary is seen in Figure 6 3 File sets summary Name Description Group identifiers hdlSources Contains the source files for the component sourceFiles documentation Contains the documentation files for the component documentation simulation Contains the simulation files for the component simulation Double click to add a new item Figure 6 3 The user interface of file sets editor Group identifiers can be used to describe the function or purpose of the file set with a single word All columns can be modified in the editor to set the general information of the different file sets If a file set 1s 1n invalid state then the editor displays the associated row in red Group identifiers can contain several identifiers and the possible options are not limited However the editor suggests the following options for the group identifiers a Diagnostics b Documentation c ProjectFiles d Simulation e SourceFiles 6 2 1 File set editor
96. en opastusj rjestelm joka reagoi k ytt j n tekemisiin Kokonaisuudessaan Kactus2 n eri versioita on ladattu yli 1 700 kertaa ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Master s Degree Programme in Information Technology ANTTI KAMPPI Library management implementation on Kactus2 IP KACT tool Master of Science Thesis 112 pages 18 appendices December 2012 Major Embedded Systems Examiners Prof Timo D H m l inen and Dr Erno Salminen Keywords System on Chip IP block library management metadata IP XACT The size and complexity of embedded systems have grown at an accelerating pace over the last years This causes demand to improve the productivity of the design process e g by enhancing the reusability of logic components also called IP blocks Improving reusability requires use of new design tools and methods IP XACT is a XML based metadata standard which describes IP blocks in a tool implementation and vendor neutral way Previously there hasn t been open source design tools supporting IP XACT and the commercial tools are expensive thus limiting the ability of small and middle sized companies to use IP XACT This thesis presents an open source IP XACT design tool called Kactus2 The scope of the thesis is the library management and IP packaging modules which enable automated management of IP blocks The thesis presents a few extensions to the standard which expand the original scope of IP XACT towards product manag
97. ent fileSet G SharedFointersFileSet parent CObject FilesModel troy lount parent SModellndex const OModellndex intiguers columnCount parent aladellndex const amp Gthodellndex J intiquery flagst index ikdlodellndex const amp 3 kemFlagsiogueryj headerData section int orientation Orientation role int at DisplayRole 1 G s ariantiguers i data index atadellndex canst amp role intzit DisplayRale SYariantiguery i setbata index SModellndex const amp value i s ariant const amp role int2Gt EditRole j bool SLOT onAdditemt index Ghadellndex const amp filePath string const amp void S5LOT onRemoveltem index itladellndex canst amp J void SLOT onMoveltem originalPos GModellndes const amp nevePos Gtadelndex const amp J void ESIGNAL cantentChanged void ESIGNAL file amp dded index int J void ESIGNAL fleRemovedi index int 1 void ESIGNAL fileMaved source int target int void FilesDelegate USER DISPLAY ROLE int const Gt UserRoleiread n USER EDIT ROLE int const it UserRole TireadOnly LIST EDITOR MIN HEIGHT int sonst 100 readionl FilesDelegate parent GObject FilesDelegatei createEditor parent Gidget option eStyleOptionvievetem const index ekilodellndex const amp j Midget igueryj setEditorData editor cvidaet index SModellndex const amp J voidigu
98. ent on Visual Studio Although the development and testing has been mostly done on computers running on Windows operating systems other platforms have been considered and platform dependent code has been avoided Kactus2 has been tested to run on at least Linux s Ubuntu and Debian distributions as well as Windows XP and 7 in both 32 and 64 bit versions Agile software development methods have been used in the development process There have been several different parties submitting demands for the tools and the demands have changed several times during the development Therefore the traditional waterfall method wouldn t have suited for this type of development because of the rapid changes in system requirements The Kactus2 development team contained two key coders which performed the unit testing of modules and also part of the system testing For system testing there has been several parties which have used the tool in both the development and the release environment The extremely agile nature of the development has forced re writing of some of the codes due to major changes in system requirements 4 1 1 Signals amp slots The use of signals and slots mechanism of Qt enables the use of very modular code 26 Signals and slots are an alternative for the traditional callback mechanism which is commonly used in GUI programming The use of signals and slots enables the communication between two classes which do not know of each other It is eno
99. eonst amp J void FSIGNAL errordiessage meq string const amp J void SIGNAL naticeMessage msg Gstring const amp 31 void SIGNAL componentSelectedi vinv YLW const 1 void setupConnections datamodel HierarchybModel 3 void Figure 7 7 The hierarchy view classes HierarchyModel contains the actual tree data structure displayed to the user explained in Chapter 7 1 HierarchyFilter acts as an intermediate class between the model and view and filters the items to display based on settings received from VLNVDialer HierarchyView is the tree view class which is shown in the GUI 61 7 3 VLNV tree view VLNV tree view displays the library objects based on their VLNV identifiers It follows the model view architecture depicted in Chapter 8 1 2 LibraryTreeWidget is the container class which owns the view and filter classes and sets the layout for the VLNV tree view Figure 7 8 displays the class diagram containing the classes related to the VLNV tree view LibraryTreeView el Structs C Struct C Struct C Struct handler_ Librarylriterface FirmnessOptions TypeOptions HierarchyOptions ImplementationOptions lobal bool product bool board bool filler LibraryTreeFilter startPos aPoint dragindex GModellndex openDesign amp ction G amp ctian s fixed bool chip bool pent DesignAction_ aAction Typeoptions z c bool Implementation Options OpenComp amp ction
100. ershMadel i tasartFilterPraxyhadal ParametersEditori component GasharedPointer component parent Gvvidaet an E ParametersEditor 1 refresh void tis Valid booliojuery 119 APPENDIX 7 ADDRESS SPACES EDITOR 120 APPENDIX 8 MEMORY MAPS EDITOR MemoryMapsDelegate MemoryMapsDelegater parent GObject J WlemoryhlapsDelegater createEditor parent Ghltidget option GStyleOptionviewveytem const amp index iiadellndex const amp Gidget i query i 4 zetEditorData editor cvvidaet index aladelndexz canst amp J vaididquery setiodelDbata editor eidget model SAbstracttemModel index ahadellndex canst amp 1 voildiguery i SLOT commit amp ndcloseEditar void component GSharedFointer lt Component memmMaps GListzisharedPaointerzMemoryhMapz 5 MemoryhlapsModell component GsharedPointers Component parent Guobject WAME COLUMN MemoryMapsklodelr AUB COLUMN roweCount parent sModellndex const amp tikodellndexr intigquerv DESC COLUM column Count parent GModellndex const GModellndext J intiquery COLUMN COUNT flags index atadelndex canst amp temFlagsiguery headerbata section int orientation Orientation role int Cat DisplayRole J SvYarlantiguery data index OModellndex const rale int2Gt DisplayRole J SvYariantidguery i zetbatar index SModelindex conste value variant const amp
101. erv zetodelbata editor widget model GAbstracttemMadel index Ghlodellndex const amp J voididguery i SLOT commitAndoloseEditor void FileBuildersModel fileBuilders aListeasharedPointerzFileBuilderz amp FileBuildersModelt ESSI GListeasharedPointer FileBuilderz amp parent p abject j EditableTableview FileBuildersMadel rowveCount parent Gtadellndex canst amp iGhadellndex intiguery columnicount parent iladellindex const amp ahodellndex intiguery i datal index GhWodelindex canst amp rale intzGt DisplayRole j amp sv arianticuery headerData section int orientation Orientation role int 6t DisplayRole J a sariantiguerv reo model zetData index Ghacdelndex const amp value a ariant const amp role int2ct EditRale J kool Tlagsc index GModellndex const J ItemFlagstauery is validi baalt query SLOT anAdaditem index SModellndex const amp void SLOT anRemoveltem index Ghodellndex const amp J void ESIGGMNAL cantent changed void FolshAL errorMessagei msg GString const amp J voidiguery i SIGNAL naticeMessage msg SString const amp voildiguery FileBuildersEditor EditableTable View FileEuilderskiodel i aisartFilterPraxyhWModel FileBuildersEditar fileBullders GList taSharedPointer FileBuilder amp parent GvMidget title String canst amp tri Default file build commands
102. ery i setModelbata editor Citidget model GtAbstracttemModel index itladellndex canst amp J voidiguery SLOT commit amp ndcloseEditor void Editable Tableview handler LibraryInterface component GSharedPointer Component FilesVieve handler LibraryInterface component asharedPointerzcamponentz parent Gyyvidget FilezView ESIGMAL additeml index QModellndex const filePath EString const amp 1 void emouseDoubleClickEvent event GhMouseEvent 1 void SLOT on amp dd amp ction void handler LibraryInterface component GSharedPointersComponent gt fileSet CGSharedPointer lt FileSet files aList asharedPointersFile s vjgwe Filesvievy model Filesktodel addFilesButton SPush6utton ESISNAL filekdovedi source int target int void SLOT onAddfFilesi void 117 APPENDIX 5 MODEL PARAMETER EDITOR UsageDelegate Usagecolumn int UsageDelegatel usagecolumn int parent GOhject O0 J LsageDelegater createEditor parent Gidget option GStyleOptionvYiesvytem const amp index OSModellndex const amp EMYidget tguery i zetEditorData editor Gvidaet index alvadelindex const amp 1 void query i setModelDatac editor ividaet model isbstractitemMWadel index iladelndex const amp J voidiauers SLOT commit sndclozeEditar void ModelParameter Model table ListzasharedPaointerzMadelParame
103. es the automated generation of software documentation such as method descriptions at any time Of course this reguires the comments in the code lines to be up to date and precise but this would be a reasonable reguirement in a software project anyway The use of Doxygen notation doesn t fully solve the need for other documentation such as UML diagrams but this eases the burden of maintaining the documentation in an agile software process 104 9 2 Usability The graphical outlook of Kactus2 is guite unigue when compared to the other design tools in the same category This can be an opportunity but also a disadvantage The fresh design aspect gives possibilities to explore new ways to do things but they must be intuitive enough for users to feel comfortable with them If the learning effort is too high to start using the software users will not adapt to the new methods For this reason one of the goals in designing Kactus2 has been to keep the learning effort as low as possible while still preserving the ability for users to do complicated things In the library management module the library objects have icons which identify the object type This way it 1s easier for the user to understand the library structure and find the desired objects Also the different library views help The user can choose which view to use in each situation The filter functionality was added because in certain situations it is not necessary to view e g software compo
104. et index aladelndex const amp 1 voildidguery setModelDatac editor i vidaet model isbstractlEemMadel index sModellndex const amp void query SLOT commit amp ndclozseEditar void EnuldentifiersModel vies GiSharedPointer View table GStrinaL ist amp EnvidentifiersModell views GSharedPointerzsiew parent xobject En ldentifier sodali roweCount parent Glladellndex const amp iehodellndex 1 intiquery calumncount parent atadellndex canst amp ohadellndex J intiquery data index atadellndex const amp role int 0t DisplayRole G ariantiguery header Datat section int orientation Orientation role int t DisplayRole EYarlantiguery zetbata index atadelndex const amp value a ariant consts rale int Gt EditRole bool flags index SModellndex const amp j temFlaqgs query i izvalid baalauery i SLOT onA amp daditem index ataodellndex const amp J void SLOT onRemoveltemc index xGtWodelndex const amp void a NAL content hanged void ESIGNAL errorMezsage msg string const amp voidiguery i ESIGNAL naticeMessage msg String const amp J voidiquery EnuldentrifierEditor _ EditableTable iewe Envldentifierzhadal GSofFilterProxyhkodel EnvIdentifierEditar view GiSharedPainterz Viewz parent Gvvidaet title string canst 2istrina Environment identifiers refresh vo
105. evel Level void parent Librarytem query yethamel QString query j getLeveli Leveliquery childi index int Librarykem iguery i rowwv int aetNumberotfcChildren intiouery aetv MY SENS TOuery aetindexof item Librarykem J int getRowr int hasChildrenc baaltauers i getv LNY ai vinvList iLbistevE NUR 3 void removeChildc childltem Librarykem J void findHighestUniquerl childltem Libraryttem 0 3 Librarykem findHighestUniguei vInv YLM const 1 Libraryltem findltemc vinv YLAY const amp 1 Libraryitem setvinvi vinv LMS 1 void clear void getvendorsi validator SRegExpvalidator const amp 1 GListeLibrarykem iguery i getv endors SList Librarytem query i getLibrariesi validator CRegExpvalidator const amp 1 GList Libraryttem query i getLibraries GListeLibrarykem igueryj gethames aListeLibraryltem 10u8ry yetVersions ListeLibraryltem 194u6ery DialerWidget vendorBox SComboBox library6Box acomboBox nameBox GicomboBox versionBox acombobox root Librarykem const ireadOnhyj vendors GListeLibrarvltem libraries GListeLibrarykem names GListeLibrarykem versions GListeLibrarykem Dialetiidgetr parent Cividget Djalettvidgeti setRootltem rootitem Librarytem const J void SSIGMA AL vendorCchangedi vendarText GString co
106. evels 7 Each document creates a single object in the library The different objects can be uniquely identified by a VLNV identifier The identifier consists of tuple vendor library name and version All references between the documents are made using the VLNV identifier The library can be better managed when the dependencies between IP blocks are documented and in a format that can be read by computers This way it 1s possible to clearly display to users the dependencies between the components and how a single component consists of sub components This also facilitates the management of third party libraries because the developers are not needed to explain to integrators what components depend on each other and what kind of requirements they set for their interfaces By agreeing on the naming policies of the VLNV identifiers it is also possible to manage the dependencies across library bounds because the dependencies are seen in references from one object to another 8 2 3 1 IP XACT based IP block integration Figure 2 3 depicts the different phases to add a new IP block to the library Design phase Artifacts IP blocks Source IPblos Source 1 Packetize l Specify new Component metadata 2 Assemble together Tool DN i metadata 3 Configure Design metadata 7 4 Generate executables Executable Figure 2 3 Adding a new IP block to the library and compos
107. ew architecture explained in Chapter 8 1 2 The tree model contains only one instance of ComponentEditorRootItem which is the tree root All other tree items are located either directly or indirectly under the root item ComponentEditorItem is the base class for all tree items and contains all functionality for managing the tree structure The defined abstract functions that must be implemented in sub classes contain element and editor specific functionality such as checking the validity of the item ComponentEditorGroupSlot is a placeholder for widgets in the component editor s layout When the user selects a tree item ComponentEditor asks it for the matching editor and places the editor inside editorSlot instance of the group slot The visualizerSlot within ComponentEditor is reserved for items that have a visualization widget to help the user to see the effects of editing the element On the current version of Kactus2 the visualization 1s used only on address spaces but this functionality will be extended to other elements in future versions If the selected tree item does not contain a visualizer widget then the slot is hidden and will not take up space on user s screen Figure 8 3 depicts the different classes in the user interface of component editor General File sets E a F structural vhdlSource addrspace Jvhd hibi segment vhd DS e Model parameters Parameters Description Memory maps 4 pis na S CEET General
108. f hardware dependent 12 software driver is needed Figure 2 7 depicts how the communication abstractions are handled in Kactus2 COM definition for MCAPI VEM Reference to communication e communication I methods and lo properties e Transfer types definition prop P LL a in mcm Message 7 Scalar Packet m a VLNV Reference to driver s me EE Muy software which define their API sd defines the I functions and Toss he 1 MCAPI iis POTITUS i endpoints communication Risain ee i interface J a t d a m f The software Y p x I components are I I Thelowlevel I connected to each driverfor DCT l other through API block whichis interfaces hin aus um a e md unm d IP specific I Aim mum ass m d Figure 2 7 Higher level communication interfaces in hardware components Kactus2 uses extensions called COM definition and COM interface to support higher level communication COM definition is an IP XACT like XML document which describes the transfer types and communication properties used in the communication method COM interface is similar to the bus interfaces in standard IP XACT which lift the connection abstraction from port level to bus level COM interfaces are included in the hardware component and they contain a reference to the COM definition which 1s implemented by the interface The COM Interface
109. f library management and IP packaging module The ninth Chapter contains evaluation of the presented modules and finally Chapter ten contains the conclusions of the topics discussed on this Thesis 2 IP INTEGRATION This Chapter explains the basic principles of IP blocks and System on Chips SoC what they are and what they can be used for The basics about IP XACT a standard used to package IP blocks for easier reuse are also explained Finally the different phases to add new IP blocks to the library and the extensions made to the original standard are depicted 2 1 System on Chip A System on Chip consists of several IP blocks and contains almost all different parts of the system on a single VLSI chip 2 While testing and verification of a single IP block focuses on making sure the block functions correctly the main focus on SoCs is checking the cooperation of IP blocks instantiated on the chip In case of large designs the workload can be divided into smaller portions by dividing the system hierarchy into smaller subsystems This way each level has fewer components to test therefore making the testing and verification process simpler Figure 2 1 shows an example of a small SoC where several IP blocks are connected together via HIBI bus 3 hibi segment small 1 hibi mem dma 1 E rst n rst n ddr2 ctrl p hibi p alt ddr2 p a2 ddr2 dimm 1GB 1 lt Jalt ddr2 pl phy dk out ddr2 p dk in soft rst n hibi p2 hibi p1 gt
110. face filter HierarchyFilter Hierarchy sev setSelectedindexes indexes itodelndexList const amp void 5L OT onopenDesign void SLOT ondpenStYDesigno void S5LOT ondpenSystemDesig nr void S5LOT ondpenComponenti aid SLOT oncreateComponent void SLOT onCreateDesign void S5L OT oncreatesSvyDesigni void SLOT oncreateSystemDeszian void SLOT onExpart amp ction void 5L OT setCurrentindex index itodelndex const amp J void SLOT onopenBust void S5L OT on amp ddsignals void S5L OT oncreateBus void 5L OT anopencombDef void SLOT ancreatecomDef void S5L OT onopenpiDef void SLOT oncreateApiDef void SLOT onopenXml void SLOT onShowErrors void SIGNAL openDesign index i tadelndex const amp J void ESIGNAL opensvyDesignt index QModellndex const J void ESIGNAL openSystemDesignt index GModellndex const amp J void FSIGNAL apencomponent index itadeallndex const amp void SIGNAL createNewComponenti index GModellndex const amp void ESIGNAL createNew Bust index Ghodellndex const amp J void ESIGNAL createNewAbsDefi index GModellndex const amp J void FSIGNAL createNewComDeff index atiadallndex const amp J void SIGNAL createNewApibet index eModellndes const amp void ESIGNAL createMeveDesigni index etMadellhdex const amp J void SIGNAL createNewSDesignt index GModellndex c
111. fault setting when the bit steering is not set is off When checked the connection required indicates that when instantiated in a design this interface must be connected to some other interface 6 9 1 1 Port maps The port maps tab Figure 6 24 of a bus interface editor groups the physical ports of the containing component to the logical signals listed in the associated abstraction definition General Port maps 20 1 1to many 4 Cleanup 9 Connect Logical ports Physical ports ADDRESS data in WRITE ENABLE addr in valid out Logical Logical Logical Physical Physical Physical left right name name left right 0 0 COMM comm out 0 0 6 o REDENAME reout 0 0 3 0 DATA data out 7 4 Figure 6 24 The user interface of port maps editor The top left corner contains a list of the logical signals that were defined in the abstraction definition assigned in the general tab The top right corner contains a list of the physical ports of the component The bottom table displays the mappings between logical signals and physical ports A mapping can be created by dragging an item from one of the top lists to the another or by selecting an item in the both lists and pressing enter or clicking the connect button After this the selected items disappear from the top lists and appear as mapped on the port map table If the user selects several items on both lists and connects them then mappings between the ports are made in the
112. fter this the library handler selects the correct editor for the object type and forwards the data structure to it Figure 5 7 displays two options to open a hierarchical component The selected option on top Open HW Design opens the hierarchical view of the component which displays the contents of the design and the components instantiated 1n the design The operations of opening a hierarchical design are explained in Chapter 7 5 1 The lower Open Component opens the component editor which is explained in detail in Chapter 6 27 5 2 3 Open the metadata to XML editor Sometimes the user may need to open the selected document in an XML editor instead of the IP XACT editors in Kactus2 see Figure 5 8 for example This option opens the file in operating system s default XML editor However usage of Kactus2 editors is recommended because they provide support for error checking and help the user when creating references between objects TUT Cl ip hwp communication El hibi orbus H hibi segment Open Component W hibi wrapper EP hibi wrapper ip hwp interFace H ip swp driver Mew b Open XML File Export Delete Item Figure 5 6 Open document in XML editor 5 2 4 Save item As mentioned before each object type has its own editor that handles the modification of the data structures However the library handler takes care of the saving process itself When the user wants to save the modified object
113. full out 8 out agent full out 7 out agent msg addr in 17 agent msg addr out 17 agent msg comm in 17 agent msg comm out 17 agent msg data in 17 agent msg data out 17 S So o cce amp 2 cle 4 agent msg empty out 17 Es ES E E ES E EST EST oa Import CSV file amp Export CSV file 7 Amis VHDL code agent addr in 17 in std logic vector 31 downto 0 agent comm in 17 in std logic vector 2 downto 0 agent data in 17 in std logic vector 31 downto 0 agent msg addr in 17 in std logic vector 31 downto 0 agent msg comm in 17 in std logic vector 2 downto 0 agent msg data in 17 in std logic vector 31 downto O agent msg re in 17 in std logic Figure 6 20 The user interface of ports editor and an example of VHDL code declaring the ports Port name identifies each port and must match the name of the port in the implementation language For example in case of VHDL the ports listed in the entity declaration are to be listed here The direction column specifies the direction of the port and has 4 options a In for input ports b Out for output ports c Inout for bidirectional and tri state ports d Phantom for ports that exist on the IP XACT component but not on the implementation The left and right bound define the width of the port in case of vectored ports The width of the port is left bound right bound 1 In case of scalar ports left bound right bound The por
114. functionality in the VLNV fields Only objects that match search criteria are displayed in the library views Figure 5 11 shows how the search looks like in the user interface Vendor Libr Name Version rur v i hibi v v Hierarchy VLNY Tree E TUT E ip hwp communication hibi bus absdef hibi bus busdef hibi ip r1 absdef hibi ip r1 busdef hibi ip r3 absdef hibi ip r3 busdef hibi ip r4 absdef hibi ip r4 busdef hibi orbus 9 30 E hibi segment 0 3 0 hibi wrapper r3 hibi wrapper r4 ip hwp interface E hibi clocks Eh 1 0 hibi clocks absDef E ip swp driver Z hibi pe dma 1 0 hibi pe dma apiDef 0880888808 Figure 5 11 Only items that match the search criteria are shown in the search results 30 Only objects that s VLNV identifiers contain the given keywords are shown The search results contain all object types such as hibi segment component and hibi clocks bus definition The user may also use wildcards and to replace characters in search terms 5 3 2 Filteritem types In addition to the search functionality the library handler provides option to filter objects based on the object types This can be used together with the search terms e g in order to search for mutable hardware components containing name hibi Filtering uses the Kactus2 attributes Chapter 2 3 3 2 and allows the user to select which attribute options are to be shown in the library views Figure 5 12 di
115. ght is context sensitive and changes when user selects different elements on the component editor Figure 4 2 shows another screenshot of Kactus2 with the design editor 18 0 x H i E G M o m E 7 dat D d oW a N of GC x 2 DO Save As Save All Print ie r Q Add Column a z Unlocked Refresh Settings Help About Fie N N NR RN WR RR n IP XACT Library Bx Design Configuration Details N Vendor Library Name Version Add new configuration Hierarchy VLNV Tree Current configuration structural Library items x x i TUT hibi orbus 0 hibi wrapper r4 2 Instance name Active view a ip hwp communication a slave 0 save 2 bus mslave PIN a lu hibit us abs def hibi wrapper r4 3 rtl LM 3 0 hibi wrapper r4 2 rtl K mt v bus_mMaster ip mSlave ip mMaster clocks BD rst n hibi bus busdef ir ahedef Component Instance Details Context Bus type YLIN communicat TIC 3 0 Sp cific TU ip hwp compunicat hibi bus absdef 3 0 New HW Component Creates a Plut nor vett aha a HA component Cactus Attributes Product Hier aechn hibi wrapper r4 3 o bus master Interface mode slave 3 E ta T BD rst n WP debug in T ug out HW design editor g 45 new a Object dialog Desc
116. ibrarylnterface JEN GHBoxLayn ni rootltem GSharedPointer lt ComponentEditorRootkem gt currentividget Cl idget ComponentEditorTreelodeli libHandler LibraryInterface parent Gobject P MEE MUI 9 P J CompaonentEditorGroupslaot parent Stidget setComponent component SharedPointer Component 1 void ComponentEdftorisroup sloti rowecCount parent Gklodellndex const amp GModellndexi intidguery hasChildrenc parent Siklodellndex const amp cModellndex bookiguery columncountl parent SModellndex const amp GWlodellndex0 intiguery i data index itadellndex canst amp rale intzit DisplayRole J G rariantiguery flagst index OModellndex consta kemFlagsigueryj index row int column int parent aladellndex const amp GhModelndex GModellndexigusryi indexi item CompanentEditarltem Gladelndexidquers i parent index Gklodellndex const amp J Gklodellndesiogueryj 5LOT oncontentChangedi tem ComponentEditarltem void SLOT addftemi parentitem ComponentEditorltem childindex int 1 void SLOT removeltemi parenttem ComponentEditorkem childlndex int 1 void 1 5LOT moveltem parenttem ComponentEditortem child source int childtarget int 1 void SLOT setlockedi locked bool void 1 ESIGNAL opentSourcet filename Gstring const amp component asSharedPointerzicompaonentz void SIGNAL helpUrlRequested url string const
117. id EnvldentifierEditori Y alidi Baal query i ESIGNAL contentchanged void SIGNAL errardessage msg string const amp voldiguery ESIGNAL naticeMessage meq astrinq const amp J voildiguery 126 APPENDIX 14 PORTS EDITOR PortsDelegate adhocGroupModity bool adhocGroupstate_ CheckState PortsDelegate parent aobject PortsDelegatel createEditor parent lt tAidoget option CSStyleoptionvievytem const amp index GModellndex const 3 evyidget rquers setEditarData editor Gvvidaet index GModellndex const amp J voldidguery i setModelbata editor avvidaet model Q4bstracttemModel index tadellndex const amp voidigueryr paint painter GPainter option QStvleOptionViewitem const index GModellndex conste J voidiquery EeditorEvent event GEvent model QAhstracttemModel option SStyleOoptionviewytem const amp index QhModellndex const bool SLOT commit amp ndiloaseEditar void enumeration PortEditorColumn PORT COL NAME PORT COL DIRECTION mE amp uses PORT COL VYIDTH PORT COL LEFT EditableTableView PORT COL RIGHT PORT COL TYPENAME PORT COL TYPEDEF ISE PORT COL DEFAULT sa PORT COL DESC PORT COL ADHOC VISIBILITY PORT COL COLIMT Q 5ortFilterProxyModel PortsModel table aList asharedPointerzPort amp component iisharedPointer cComponentz PortsModelf c
118. idator versionvalidator CRegExpvalidator vendor String library QString name String version GString HierarchyFilter dialer WLAN Dialer parent Guobject HierarchyFilteri 5L OT onvendorChangedc vendorText GString const amp J void SLOT enLibrary Changed library Text GString const amp void 5LOT onhamechanged nameText astring const amp 1 void 5LOT on ersion changed versionText Gstring const amp 3 void SLOT onFirmnessChangedi options Firmnessoptions const amp 1 void SLOT onlmplementationthangedi options Implementation options const amp 3 void S5LOT onl ypeChangedl options Typeoptions const amp void 5L OT onHierarchyChangedi options Hierarchy Options canst amp J void zfiller amp cceptsRovv source row int source parent QModellndex const bookiguery i checkFirmness component GSharedPointer Component baaliguers checklmplementation component E SharedPointersComponent J bool query i checkHierarchy component SharedPointer Component gt 3 booliguery i Check LNY st list iste sv LNS eonst amp 3 booliguery i 1 1 YLHY Dialer HierarchyModel HierarchyWidget filler HierarchyFilter view gt Hierarchy iew model HierarchyModel Hierarchsitidgiett dialer s LH aDialer parent Stidt dget handler LibraryInterface dataModel HierarchyMadel 3 HierarchyMWidaet selectktemsi vinv VLA
119. ies DirListManager sourceFiles Figure 8 15 The GUI classes of file set editor 8 4 File editor File editor is used to edit the details of a single file Figure 8 16 shows the class diagram of the file editor handler Librarylnterface compnonent CSharedPointersComponent DirListklanagerr title CString const handler LibraryInterface component sharedPointer Component parent GYidget O DirListklanageri initializet items S StringList const amp cStringListi void 1 FileExtraTab dependencies DirListManager exportedWames ListManager imagelypes lListmManager file GSharedPointersFile gt FileExtraTab handler Librarylnterface component SharedPointer Component file GSharedPointersFile parent Ctldget FileExtraTabr refresh void is validi bool quer i ESIGNAL contentohangedi void SLOT onDependenciesChangel void SLOT onExportsChanger void SLOT onlmageTypesthanger void SLOT anDefinechandae void Korn Editor FileGeneralTab T i labs GSTaktvidoet generalTab FileGeneralTab extraTab FileExtraTab file aSharedPointersFilez FileEditar handler Librarylnterface component iisharedPointerscempanentz file GSharedPointer lt File parent Ctviidget 0 FileEditorr iz validi bool quer i refresh void Figure 8 16 The structure of file editor 86 The graphica
120. iles should be listed in the order needed by the compilation The default build command applies to all files of the specified type For example all VHDL files in this file set are compiled with Modelsim s vcom and the given flags Replacing default flags means that flags defined in higher level will be replaced by the flags defined in this file set For example the flags may be defined in the views of component If files are not replaced then they are appended to the default flags Group identifiers are used to describe the purpose of the file set and they are same as in Chapter 6 2 Dependent directories can be used to describe a list of paths to directories containing files on which the file set depends such as third party libraries 35 6 2 1 1 File editor File editor sets the details of a single file within a file set This allows a more detailed description of the file and its dependencies Figure 6 5 displays the user interface of a file editor General settings External dependencies and defines File name and path Mame vhd fifa vhd Specified file types vhdlSource Double click to add new item General options Logical name hibi E Only used as default E File is include file File contains external dedarations Description of the file Build command Command vcom Flags check synthesis quiet work work Replace default flags Target file Figure 6 5 The user interface of file editor The top pa
121. ing of new blocks 9 The left side of the Figure displays the different phases of the design process and the right side the documents being handled in each phase When adding a new IP block to the library it must be packaged with IP XACT metadata This makes it possible to automatically manage the IP library when the data is 1n computer readable format The user can search for a single component from the hundreds or thousands of components in the library by defining search criteria and filters to display only the desired types of components In phase 2 a new hierarchical component is created by creating a design description which lists the components instantiated with their mutual connections The created hierarchical component is also displayed in the library among the other components and it can be instantiated itself in some other hierarchical component to create deeper hierarchies of sub systems 8 To create a final product phases 3 and 4 are used Phase 3 sets the used configurations and settings for each component instance Phase 4 generates the needed files for example the structural level VHDL code for the top level component Finally the source codes can be e g synthesized using the tools provided by an FPGA vendor Figure 2 4 displays a screenshot of the component editor in Kactus2 used to create a metadata package for a component The bottom of the figure displays a part of the saved metadata for HIBI bus The metadata displays
122. interzcomponentz parent Qobject CpusDelegater createEditor parent Cttidget option Gistyleoptian vievvltem const amp index Glwadellndex canst amp cyvwyidaet reuerv 1 zetEditorData editor cvvidaet index waedelndex const amp J voididuery setModelDatal editor cvvidget model CSbstracttemModel index ladelindex const amp J voidiguery i SLOT commit amp ndoloseEdftor void CpusModel Component GS SharedFointer lt Component gt lt enumeration Cpus al isteasharedPointerscpus amp Role Cpuskodell component SharedPointer Component gt parent GObject USER DISPLAY ROLE Cpusktodelf USER EDIT ROLE roweCount parent SModellndex const amp CModellndex intiguery i columncCount parent Ghadellndex canst amp iehadellndex J intiguery Tlagsc index GModellndex const amp temFlagsigusry headerDatar section int orientation Orientation role int 6t DisplayRole 1 G s ariantigquery i datar index GModellndex consts role int 0ct DisplayRole G cariantiguery MAME COLLIMPMN zetbata index SModellndex const amp value a s ariant const amp rale int lt t EditRole j bool DISPLAY MAME COLUMN isvYalidt booliguery ADDRSPACE COLUMN S5L OT onddltemf index ahadellndex const amp 1 void DESCRIPTION COLUMN SLOT onRemoveltem index atadellndex const amp J void COLUMN COUNT ESIGNAL contentchanged void ES
123. ip Magillem Platform Assembly Magillem Design Services Paris France WWW accessed on 28 10 2012 Available at http www magillem com eda assemble configure and manage systems hierarchy in a graphical front end magillem platform assembly mpa OpenTLM IDE OpenTLM Project WWW accessed on 28 10 2012 Available at http opentlm minalogic net comp tools ip xact editor Lan Yu Oing Extraction Methods on Linux Package Dependency Relations Information Engineering and Computer Science 19 20 12 2009 Beijing China 2009 pp 1 5 Ot Cross platform application and UI framework Nokia Norge AS Norway WWW accessed on 28 10 2012 Available at http gt nokia com 112 24 25 26 27 28 29 30 31 Widgets and Layouts Ot Reference Documentation WWW accessed on 7 11 2012 Available at http doc qt digia com qt widgets and layouts html Microsoft Visual Studio Microsoft Corporation Redmond WA USA WWW accessed on 28 10 2012 Available at http www microsoft com visualstudio eng whats new Ot signals amp slots Ot Reference Documentation WWW accessed on 28 10 2012 Available at http doc gt digia com gt signalsandslots html Salminen E H m l inen T D H nnik inen M Applying IP XACT in Product Data Management International Symposium on System on Chip October 31 November 2 2011 Tampere Finland pp 86 91 Model View Programming Ot Developer Network WWW
124. is way it is possible to control the documentation source codes and configurations of an entire product and get the product data management in a machine readable format When the library contains information on what configurations and platforms a product uses it could be possible for example to build a matching test environment automatically 27 Figure 5 2 displays the 11 use cases of the library management module which are explained in the following Chapters m Get dependencies 1 of an item m ui Search new items on disk Checklibrary integrity Create new item 4 i Open kmlfile User n i Saye item Export item N Filter item types S Searchfor item in library Figure 5 2 Use cases of library management 5 1 Entire library Some operations are directed to the entire library instead of single items For example searching for new items on the hard drive will cause all items to be re parsed 24 5 1 1 Search for new items on the disk The Library section in the ribbon menu on top of Kactus2 contains icon to set the directory paths for the libraries Figure 5 3 shows the icon in the user interface of Kactus2 Ry ie Configure Library a Figure 5 3 Set library paths for Kactus2 The user can define library paths that are used as base when starting to search for new library items When Kactus2 is started it takes these paths and starts to search f
125. isplay and edit a list of strings such as file types within the editors It is used as such or as a base class when a more specific functionality is needed items_ StringList ListklanagerModeli parent 2Object 0 items S StringList const amp c stringlist ListhfanagerModell rowCount parent GModellndex const amp OModellndext 1 intigueryi data index atadelindex canst amp rale intet DisplayRole earlantiguery headerDatal section int orientation Orientation role int Gt DisplayRole CYariantiouery selDatat index Glvodelindex const amp value G variantconst amp rale intzit EditRale J bool fladqst index GModellndex const amp temFlagsiouery tems GiStringListcanst amp query setltems items GistringList const amp J void appenditemi tem string const void appendltemsi items GstringList eonst amp void replacer index atdadellndex amp newText EString const J void SLOT removet index Ghlodellndex const amp J void SLOT addftemi index alWadellndex const amp void SLOT moveltem originalPos ihadellndex censt amp newPos GModellndex coanst void ESIGNAL contentChangedf void ListManagerModel EditableListView pressedPoint GPoint addAction GAction removeAction action EditableListview parent Glvsidaet EditableList View ESIGNAL selectionthangedi index alWodellndex const
126. isualizer draws the address space on the screen for the user to view it It contains Area structs which define the bounds of each segment Visualizer is connected to the general editor and segment editor to get updates of changes in them so the visualization can also be updated simultaneously Figure 8 20 shows the GUI classes of address space editor NameGroupEditor TA ddressSpaceGeneralEditor Addressable unit size 8 N Width of address block 32 a Range of address block 2G TI orents SeomentEditor Name Offset Range Description segmenti 0x0 128M segment2 0x8000000 512M segment3 0x28000000 1G Double click to add a new item Name Value Description ParameterGroupBox AddressSpaceVisualize Figure 8 20 The GUI classes of address space editor 91 8 6 Field editor Field editor 1s used to edit the details of a single bit field within a register Figure 8 21 displays the structure of the editor EnumeratedValueDelegate Enumerated y alueDelegatel parent 2Object J Enumerated alusDelegater createEditorC parent Gl vidaget option SStyleOptionvievwtem const amp index GModellndex const amp evWidaet query zetEditorData editor Qvvidget index Ghklodellndex const amp voidigusry setModelDatai editor Ssvidget model G AbstracttemModel index GtmodellIndex const amp J voidiauersy i SLOT cammit amp ndcloseEditor void 1 gue EnumeratedValu
127. ite another class which implements the interface and replace the current LibraryHandler class In the component editor module the same principle is used ComponentEditor 1s a sub class of TabDocument which 1s the base class for all editors in Kactus2 as explained in Chapter 8 The basic structure of the component editor allows a developer to add a new element to be edited very easily The tree items in the navigation tree handle the tree operations and all the developer needs to do is to write the element specific functionalities In Kactus2 the basic structure of the component editor has been used in other editors as well and only the visible tree structure has been re written The use of signals and slots in Kactus2 improves the modularity of the software thus improving maintainability Two modules can be connected to each other without either of them being aware of this As long as the parameters of the signal and slot don t change it is possible to change either module Although the modules presented in this thesis have clear interfaces which they use to communicate with the rest of the software when looking inside the modules there is chance for improvement As mentioned in Chapter 4 1 the development process has been very agile and the reguirements have changed several times during the implementation This has caused some ad hoc style code fixes to be written which make maintenance harder The component editor is currently in a fairl
128. ities ports and C headers for new IPs based on their IP XACT descriptions Generate synthesis and simulation scripts for designs Generate combined documentation for whole systems through all hierarchy levels of a product Figure 4 1 displays a screenshot of Kactus2 user interface with the IP packaging module open ICT MN IBrx d v b ml ki k Mis a C x 2 O Li General File sets structural vhdlSource Teil Model parameters Parameters Memory maps Address spaces Views Software views System views v Board v IP able iv Fixed management Component editor J Channels D pus Other clock drivers COM interfaces Software properties Figure 4 1 Screenshot of Kactus2 with component editor On the left side of the screenshot is the library management module which is presented in Chapter 5 The item in the middle is the component editor which is the module used to create the IP XACT packages for components explained in Chapter 6 These two modules are presented in this Thesis in detail but the other parts of the software are introduced only briefly The component preview is used to display a preview what the currently selected component looks like in the integration phase This helps user to find the correct component in the library because it shows the interfaces of the component visually The message console is used to print notifications and possible errors to user The help on the ri
129. itor The example shows a 2GB address space which is divided into 3 segments 42 On the left side are the editor fields that can be used to set the details of an address space The right side has a visualization displaying the address space in its current state The general group contains the same settings that can be set through the address spaces summary presented in Chapter 6 6 Each address space can be divided into segments The user can specify the starting offset for the segment and define how many addressable units the segment has range The visualization on the right side reacts on the changes in both the general settings and segment changes to display how the segments are situated in the address space The width of the address space sets the maximum transfer length of a single transaction Address space can have parameters They are set similarly as 1n Chapter 6 4 but their scope is limited to the containing address space 6 7 View summary View summary Figure 6 16 is used to add and remove views The views are used to provide different configurations of the component For example the component may contain one view for simulation and one for synthesis purposes Views summary Name View type Description rti non hierarchical The flat view containing the component source files structural hierarchical Hierarchical view of the design acc only hierarchical Hierarchical view without general purpose processors Double click to ad
130. l user interface of file editor displays two tabs and they are also seen in the class diagram FileGeneralTab for general settings of a file and FileExtraTab for external dependencies FileGeneralTab is explained in Chapter 8 4 1 FileExtraTab is container class which owns three editors DirListManager inherits ListManager which is depicted in Chapter 8 1 3 ExportedNames and imageTypes are direct instances of ListManager 87 8 4 1 File general tab File general tab Figure 8 17 is used to edit the most often used elements of a single file FileBuildCommand build Command Builldcommand command GLineEdit flags GlineEdit replaceDefault GcheckBox target TargetameEdit layout acGridl ayout FileBuildlommand parent EetlMdoget handler LibraryInterface component G SharedPointer lt Component file CGSharedFointer lt File FileBuldCommandi refresh void ESIGMAL contentohangedi void SLOT oncommandChangedr void SLOT onfFlagsChangedi void SLOT onTargetChangedf void setuplommand void amp etupFlags void setupTargeti void FileHameL ineE dirt handler Librarylnterface component asharedPainterzcomponernt file aSharedPointerzFile FileMameLineEditi parent GvMidget handler LibraryInterface component GSharedPointer Component file S SharedPointer lt File is validi bool query FileMameLineEcdit refresht void ESIGNAL conte
131. lements It displays the VLNV identifier of the component as well as the Kactus2 attributes ComponentPreviewBox DescEditor Ih Librarylnterface p Riri component GSharedPointer Component m descEdit Plain TextEdit SCENE EGraphicsScene DescEditort parent ci idget 0 ComponentPreviewEox DescEditor setComponent component GC SharedFointer lt Component J void zetDescription desc string const amp J void updatePreview void getDescription Gitring query a temsBoundingRect GiRectFigquery SSLOT contentChanged void B aitor ComponentPreviewBoxt Ih LibraryInterface setComponent vinv s LhNSIeonst amp J void Yny Displayer YLMYDisplayer attributeEditor KactusAttriputeEditar dezscEditor DescEditor previewBox gt ComponentPreviewBox GeneralEditar libHandler LibraryInterface component G SharedFointercComponent parent Sividget 0 GeneralEditori issalid bool query t refresh void SLOT onAttributesChangel void SLOT onDescriptionchanger void 1 VLHVDisplayer KactusAttributeEditor vendorLabel GL abel prodHierLabel GLabel libraryLabel iL abel prodHierCombo ixcomboBox nameLabel Label firmnezsLabel aL abel versionLabel_ aL abel firmneszscombo acomboBox vendor ilL abel implementationLabel aL abel library SLakel implementation alue SLabel name GLabel
132. lest 13 GStringList 17 result N 15 getltemsToRemove j 19 GList Remove files from file system and tell the models to remove the objects from their data structures l l l 16 exec l l l Figure 7 14 Deleting a component from the library 1 The user selects the component to be removed in the VLNV tree view 2 LibraryTreeView forwards the request to the model class 3 LibraryTreeModel identifies the tree item and requests the VLNV identifiers of the objects the item represents in the tree 4 The VLNV identifiers are returned in a list 5 LibraryTreeModel forwards the VLNV identifiers to LibraryHandler 6 LibraryHandler constructs an instance of ObjectRemoveDialog which implements the dialog to select which objects and files are to be removed 7 LibraryHandler adds the VLNV of the selected object to the dialog 8 Now the dialog contains the VLNV of the selected object 10 11 12 15 14 15 16 17 18 19 20 69 LibraryHandler requests LibraryData to parse the selected object Note If the object is already parsed 1n the memory then parsing 1s not necessary LibraryData parses the object to a data structure A pointer to the parsed data structure is returned LibraryHandler requests the object for its file references The file paths ar
133. lid bool query refresh void WriteValueconstraintEditor write constraint sSharedPointers lt Yrtevalueconstraint noConstrButton GRadioButtan veriteAsRkeadEutton GRadiabuttan UseEnumB6utton GRadiaButtan minhTaxButton akadioButtan minBox aspinBax maxBox GSpinBox yritevalueconstraintEditor verteConstraint GSharedPointer vrite valueConstraint title String canst amp parent Guvidget Tre aluecaonstraintEditor 1 ESIGNAL contentchanged void SLOT anMacCaonstr checked bool void SLOT onvriteAskead checked bool void SLOT anLlseEnum checked bool void SLOT onMinMaxc checked bool void SLOT onMinChangedi newValue int void SLOT onMaxChangedi neweslalue int void Figure 8 21 The structure of field editor FieldEditor is the container class which owns the other classes and sets the layout for the editor It contains two different parts one to set enumerated values for the bit field and one to set constraints for write values Editor for enumerated values follows the model view architecture depicted in Chapter 8 1 2 where EnumeratedValueModel implements the model class and EnumeratedValueDelegate provides the delegate functionality 92 Write ValueConstraintEditor provides functionality to set write constraints e g by using the listed enumerated values or setting minimum and maximum values The editor contains a handler
134. llndex const amp J void S5LOT onOpenApibef index OSkModellndex const amp void S5LOT onCreateBust index GModellndex const amp 1 void S5LOT oncreateZbsDefr index kModellndex const amp J void 5LOT onCreatecombDef index Ghodelndex const amp 3 void S5LOT onCreate4pibet index aModellndex const amp J void S5LOT onRemoveYLlktvine SEPIS eonst amp J void S5LOT ongda CME win gt VLA const J void SLOT onResetModelf void removelibrarykemi toRemove Librarykem emitSignals bool void Figure 7 5 The class diagram of vlnv tree model 59 LibraryTreeModel provides the VLNV tree structure seen in the user interface of library management module It uses the VLNV identifiers of the library objects to construct a tree which holds 4 levels one for each VLNV field Libraryltem is the class to represent one item in the tree LibraryTreeModel owns one instance of Libraryltem which is the tree root The root item owns the items in vendor level and so on Only the leaf items which display the version fields can identify a single object in the library All other higher level items represent a group of objects Figure 7 6 depicts how the items form the VLNV tree m N This item identifies a single object l 9p me ee ee EGS W mn p o I This item identifies a NI Version group of objects E NETS TUN dct to hibi Version2 Vendor Li
135. me LineEdit file amp etRefz FillesetRefEditor Flat iew ieneralTab component asharedPointerzcomponentz view GsharedPointeressievez parent Gvvidaet FlatviewveGeneralTabi isvalidi book quer i refresh void FolsHAL errordessage msg GString const amp 1 void ESIGNAL naticeMessadge msg GString const amp J void ESKGNAL contentChangedri void SLOT anLanguagechanget void SLOT onModelflameChangec neveMame QString const void SLOT onFileSetRetChangel void Figure 8 25 The structure of flat view general tab FlatViewGeneralTab is the container class which contains editors to set the language and model name elements of a view It also contains an instance of FileSetRefEditor which is used to refer to the file sets of the component FileSetRefEditor 1s a sub class of ListManager which is depicted in Chapter 8 1 3 but it re implements the initialize function to provide a combo box to select among existing file sets 8 8 Bus interface editor Bus interface editor Figure 8 26 contains two tabs to edit the details of a single bus interface BusfGeneralT ab KomEditor BuslfPortmapTab BuslnterfaceEditor busif EGSharedPointer lt Buslnterface gt tabs eaTabvvidaet general BuslfiseneralTab portmaps BuslfPortmapTab BuslnterfaceEditor libHandler LibraryInterface component GS SharedFointer lt Component busif asharedPointerzBuslnterfacez
136. ment module As mentioned before LibraryData searches for IP XACT files on the disk and saves the VLNV identifiers and file paths of the found objects to its ibraryitems_ map structure After the files are searched the found VLNVs are forwarded to LibraryTreeModel and HierarchyModel These classes use the VLNV identifiers to build their own data structures to provide the library views seen in the GUI of library management module see Figure 7 2 When LibraryHandler needs an object to be parsed from a file it calls 57 for LibraryData which has the file path in its map structure and reads the file Figure 7 4 displays the class diagram for the HierarchyModel and Hierarchyltem Hierarchyltem Component S SharedPointers lt Component busDef CSharedPointer lt BusDefinftion i GSharedPointerzA amp bstractionDefinitianz GSharedPainterzCamDeftinitionz aisharedPointer zA amp piDefinition i GSharedPointer lt Design LibraryInterface childltems GListeHierarchyltem parentltem Hierarchyltem jgvalid bool isbuplicate bool Ivpe ObjectType instancecount ahapz VEN int viewhlame string Hierarchyltemi handler LibraryInterface parent Hierarchyltem vinw SENS eonst amp Hierarchyltem handler LibrarylInterface parent aoObject createchild Ins S LNSeanst amp J void Hierarchyltemi parenti Hierarchyltem raquerv i get v ENVIO SENSITQuervt child i
137. mitAndCloseEditor slot is used to commit the data from the sending editor and to close the editor Editable table view 1s a general purpose view which can be connected to model classes implementing the QAbstractTableModel abstract class This view is used in all editors within component editor where information is presented to the user in a table form such as ports summary The class contains different actions that are displayed to the user 1n the context menu of the view The table view contains handler for triggered signal of each action see Figure 8 7 for an example of the editable table view with the context menu Name Data type Usage type data width g Datarea nontyped 16 diable apod Add row Shift Return ved n Remove row hontvped 1000 packet len g source ip port Clear Del nontyped 6000 target MAC adi Copy Ctrl C nontyped x ACDCABBACDOL target ip addr Paste Ctrl V nontyped x 0A000001 target ip port c Import csv file ontyped 5000 Export csv file Figure 8 7 An example screenshot of the table editor The setltemsDraggable function can be used to enable or disable dragging of rows in the view Adding removing and moving of a row 1s informed to the connected model by emitting one of the associated signals Table 8 1 lists the tables used in component editor module and the classes that implement the previously mentioned roles in each case EditableTableView is used as a 79 view class i
138. mp lessThanf lett SModellndex const amp right SModellndex const amp 1 bool query SegmentEditorr addrSpace GSharedPointer lt AddressSpaces parent GMvYidget SegmentEditorf a0 5Struots is valid bkooliguery i refresh void Area SIGNAL contentCchanged void name Getring ESIGNAL errorWessagen msg GString const amp J void offSet guint d SIGNAL naticeMezsage mag Gstring const amp void rande quinte4 FolSHAL segmentAdded segment sharedPointerssSegmentz void ESIGNAL segmentkemovedi segmentkame Gstring const amp 1 void ESIGNAL segmentRenamedi oldName string const amp neveMame string const amp J void FolSHAL segmentchanged segment asharedPointersSegmentz void AddrezssSpaceGeneralEditor i ta amp haredPointerzA amp ddressSpace it aepinBax GispinBox HumberLineEdit Areal name Gstring const amp offset quinth4 range guint amp 4 Area other Area const amp operator other amp rea const amp j Area s operator lt other amp rea const amp 1 kooliguesry AddresssSpaceceneralEditor addrspace asharedPointerz amp ddresssSpacez parent Civvidget J 2ddressspaceGeneralEditor e validi kookiguery refreshi void ESIGNAL contentlhanged void ESIGNAL addressableUntsChangedt units int J void ESIGNAL veioththangedr width int 1 void ESIGNAL rangechanged range string const amp J void SLO
139. n T ss diplomity ss esitell n avoimen l hdekoodin Kactus2 ty kalu IP XACT pohjaiseen suunnitteluun Ty n aiheena on ty kalun kirjastonhallinta ja IP paketointimoduulit joiden avulla IP lohkoille voidaan luoda metadata kuvaukset ja hallinnoida lohkoja automatisoidusti Diplomity ss esitell n muutamia lis yksi jotka laajentavat alkuper ist standardia my s tuotetiedon hallintaan Ty ss sek suunniteltiin ett toteutettiin kirjastonhallinnan ja paketoinnin vaatimat luokat ja k ytt liittym n kym t Toteutuksessa k ytettiin C ohjelmointikielt ja ohjelmistokehyksen k ytettiin Ot n avoimen l hdekoodin versiota 4 8 3 Kehitysymp rist n toimi Microsoftin Visual Studio 2008 johon oli asennettu Ot lis osa Ot mahdollistaa j rjestelm riippumattoman koodin Kirjoittamisen joten Kactus2 on julkaistu sek Windows ett Linux k ytt j rjestelmille Esiteltyjen moduulien koot koodirivein ovat 7 500 kirjastonhallinta ja 21 000 IP paketointimoduulille Vastaavat luokkien m r t ovat 26 ja 156 Koko Kactus2 n koodirivim r on 103 000 rivi Kirjastonhallinta sis lt kaksi eri n kym kirjaston rakenteesta sek oman osan kirjaston hakuehtojen m ritt miseen Paketointimoduuli sis lt 28 eri editoria K ytt liittym st on pyritty tekem n selke ja helppok ytt inen jotta k ytt jien olisi helppo omaksua uusia toimintatapoja Lis ksi ty kaluun on lis tty kontekstipohjain
140. n all cases except in FilesEditor where FilesView provides a custom add functionality to choose a file in the file system The class diagrams of the editors are found in the appendices listed in the table Table 8 1 The table editors in IP packaging Editor Model class Delegate class Class diagram ParametersModel LineEditDelegate Appendix 1 box File builders editor FileBuildersModel FileBuildersDelegate Appendix 2 FileSetsModel FileSetsDelegate Appendix 3 FilesModel FilesDelegate Appendix 4 Model parameter ModelParameterModel UsageDelegate Appendix 5 editor ParametersModel LineEditDelegate Appendix 6 Address spaces AddressSpacesModel AddressSpaces Delegate Appendix 7 cue a Memory maps MemoryMapsModel MemoryMapsDelegate Appendix 8 PN p fn Memory map MemoryMapModel MemoryMapDelegate Appendix 9 PLN NN AddressBlockModel Appendix 10 editor RegisterTableModel RegisterDelegate Appendix 11 ViewsModel LineEditDelegate Appendix 12 Environment EnvidentifiersModel EnvidentifiersDelegate Appendix 13 identifier editor PortsModel PortsDelegate Appendix 14 Bus interfaces BusInterfacesModel BusInterfacesDele gate Appendix 15 editor Channels editor ChannelsModel Channels Delegate Appendix 16 CPUs editor CpusModel CpusDelegate Appendix 17 Other clock drivers OtherClockDrivers OtherClockDrivers Appendix 18 editor Model Delegate 80 8 1 3 List manager List manager Figure 8 8 is the common editor used to d
141. name name left right 3 0 3 0 DATA data in Figure 6 26 Connecting only a part of a vectored port in port map 6 10 Channels editor Channels editor provides a summary of the channels in the component A Channel is used within a bus component to describe which bus interfaces are connected via bus Only mirrored interfaces can be connected via channel Figure 6 27 shows the user interface of the channels editor Channels Mame Display name mis Description references HIBIchannel hibi pl hibi p2 ddr ctrl p Double click to add a new item Figure 6 27 The user interface of channels editor Interface references contain the names of the mirrored bus interfaces that are grouped to a same channel Figure 6 28 illustrates the connections between mirrored bus interfaces Mirrored bus interface 3 Mirrored bus interface 1 Mirrored bus interface 4 Mirrored bus interface 2 Figure 6 28 A channel connecting bus interfaces within a component 52 6 11 Cpus editor The cpus editor Figure 6 29 displays the programmable cores the component contains CPUs Address space ES Name Display name Tram sm Description x86 instr mem Process supporting the x86 instruction set Double click to add a new item Figure 6 29 The user interface of cpus editor Address space references contain the address spaces specifying the logical address space of the CPU The master interfaces of a component may refer to the same add
142. ndex int Hierarchyltem quers Fo int getWumkerOCfChildrenc intiouery getindexof item Hierarchyltem J int hasChildrenf bool query isvalidi bookiouery t setValidity valid bool void containst vInv ENS const amp J kooligueryi component G SharedPointer lt Component guery cleanllpi void referenceCount vinv VLA const amp intidgueryj getOvners list Liste vL NYv amp vinvToSearch SENS eanst amp 3 intiquery removeltemsi vInv SENS eonst amp J int findltemsi viny SL NS censt amp 1 GiListsHierarchyltem updateltems viny VEN canst amp 3 void hasParent vlr VLAN eanst amp bool parentlsRoot baali query isRoot bool query i isDuplicate bool query setDuplicatei isDuplicate kool void getv LN s SLlisteyLMYsiouery t clear void isHierarchical bool query getlmplementation Implementation query type OhbjectTypeiguery i getChildren childList abiste v LNY ez s owner ENS consta J void 3etChilditemsi itemList Lists LNW g J void instancecount ntiguery getvievehlamer SStringigueryj SIGNAL noticeMessagel msg astring const amp J void ESIGNAL errorkiessagen msg CString const amp j void amp countlnstances component LMY YLiksisonst J int has amp hildi vlny YLMconst amp 1 bool parseComponent vinv YLM const amp 1 void parseBusDefiniti
143. nents when integrating a hardware platform This way the user is not strained with excessive information which helps focusing on the work at hand When agreeing on the naming policies of the library it 1s possible to use the search functionality to limit the items to display very efficiently In any case the search helps users to find correct objects in a large library In the component editor module there are several aspects which are considered to make the packaging tool easy to use The navigation tree 1s designed to support the intuitive way of starting at the top and moving downwards The objects which do not contain references to other elements are aligned to the top of the tree and when moving down the tree the objects on the top can be referred to Figure 9 4 depicts the packaging order in the tree General Hle sets F structural vhdlSource J vhdjhibi segment vhd Model parameters Parameters H Memory maps Address spaces addrspace Views structural structural vhd Software views System views Ports Bus interfaces ip mSlave 1 ip mMaster 1 clocks 1 ip mSlave 0 ip mMaster O rst n clocks O clocks 3 clocks 2 ip mSlave 3 ip mSlave 2 ip mMaster 3 ip mMaster 2 Channels Cpus Other clock drivers COM interfaces Software properties Packaging order m Mm Figure 9 4 The packaging order in component editor Of course the tool does not force this order to be used and navigation back and forth between elements is p
144. nst amp void Hitter AcceptsRowl sourceRow int saurceParent GModellndex const amp 3 booligueryi SIGNAL draginitiated index GModellndex const amp J void checkFirmnezs component GSharedPointer lt Component kookiguery ESIGNAL itemselected vlnw VLNY const void checklmplementation component i sharedPointerz Component booliguery ESIGMAL errorMessage message cstring const amp void checkHierarchy component S SharedFointersComponent kbooliouery ESIGNAL naticeMessage message astring canst amp 1 void check LNYsf list Liste vL NV const amp baol query SLOT onOpenDesign void SLOT anOpenSVWbesign void SLOT anOpensystemDesigni void SLOT anOpenComponent void SLOT onCreateComponent void S5L OT onCreateDesignf void SLOT onCreatesyDesign void SLOT onCreatesystemDesian void SLOT anDeleteActian void SLOT onExport amp ction void SLOT anOpenBust void SLOT anOpenCombDefi void S5L OT onOpen amp piDef void SLOT onCreateBust void SLOT onCreateComDef void SLOT oncreate ApiDef void i Library Tree View SLOT onddSgnalsr void iler Library TreeFitter SLOT setCurrentindex index GModellndex const amp void Hatabiodel LibraryTreeModel SLOT onOpenxml void B SLOT onShowErrors void LibraryTreevvidgeti dialer YLIVOialer handler LibraryInterface dataldodel Library TreeModel
145. nst amp J void ESIGNAL library Changed libraryText sString const amp J void ESIGNAL namechanged nameText astring const amp J void ESIGMNAL version changed versionText Gstring canst amp 1 void SLOT refreshvendors void SLOT onvendorChangedr vendorText GString const amp 1 void SLOT onLikrarythangedr library Text s String const amp J void SLOT onhMamechangedi nameText astring canst amp J void SLOT onversionChangedi versionText GString const amp J void disconnectBoxesf void connectBoxes void Filterwidget VLHYDialer firmness Firmnessiroup implementation lmplementationtsroup type TypeGroup hierarchy Hierarchy troup FiltervVidaet parent ievvidaget Fitervvidgetl ESIGNAL tirmnessChanged options FirmnessOptions const J void ESIGNAL implementation changed options Implementationoptioans const amp void ESIGNAL typeChangedr options Typeoptiongz const amp 1 void ESIGNAL hierarchy Cchanged options Hierarchy Optians canst amp 1 void fillerz Fitervidget dialer Dialervidaet hideButton aPushButtan hidden bool YLMYDialerC parent evvidaet xL NS Dialer zetknotltem roottem Librarykem const J void ESIGNAL vendorchanged vendorText astring const amp J void SIGNAL library changed library Text Gstring const amp 1 void E IGNAIL namechanged nameText GString const amp 1 void FSISNAL version changed ve
146. nstraints for the written or read data This 1s the default setting b Restore indicates that the field s value must be restored to its original value before accessing another register c WriteAsRead indicates that the data written to a field must be same that was read previously from the field d ReadOnly indicates that the field can only be read 40 6 5 1 3 Field editor The field editor sets the details of a register field For example it defines enumerated values as the legal bit patterns Figure 6 13 shows an example Enumerated values Enumeration name Value Usage FOSC 2 00 read write FOSC 8 01 read write FOSC 32 10 read write Derived from internal oscillator 11 read write Double click to add a new item Write value constraints No constraints Write as read Use enumerated values Set minimum and maximum limits Minimum Maximum Figure 6 13 The user interface of field editor The table defines the bit patterns which 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 The write value constraints define the legal values the user may write to a field The Options are a No constraints indicating that there are no constraints for values to be written b Write as read indicating that only legal values to be written are the same that were previously read from the field c Use enumerated values indicating that the defin
147. nt changed void zmousePressEvent e GhouseEvent 1 void FileHameEditor N nameEdit FileMameLineEdit file GsharedPointer lt File FileMameEditor parent evidaet handler LibraryInterface component GsharedPointer lt Component file G SharedPointers lt File FileMameEditor 2 validi baolt query refresh void SIGNAL content changed void ListManager FileGeneralEditor a file GSharedPointer lt File lodgicalMame GLineEdit File TypeEditor logicalDefault aGcheckBox file GSharedPointer File ME eneckEox externalDec Gi heckBox FileTypeEditort parent Stvidoet file GSharedPointer File description GPlainTextEdit FileTypeEditor initialize tems GStringList const amp GStringListl void sur ae CUTE DN MR Massone ile M uu refresh void MET redi fm SIGNAL contentChanged void i CUER SLOT onLogicallameChanged void SLOT onlncludeFileChangedri void SLOT onExternalDecChangedi void SLOT onDescriptionchanged void 1 1 1 FileGeneralTab file CSharedPointer lt File nameEditor FileMameEditor generalEditor FiletseneralEditor fileTvpeEditor FileTypeEditor build command FileBuildCommand FileGeneralTabr handler LibraryInterface component i sharedPointer zcomponentz file SharedPointer File gt parent cvvidaet J 1 FileGeneralTab refresh void isYalido bookiouery
148. nt editor module as well as the navigation tree are dependent on the data structures This hasn t been an issue so far since no new versions of IP XACT standard have been released during 2 years of development and there hasn t been need to support the old versions Also if support for several different versions is needed simultaneously then it wouldn t be reasonable to have their own editor modules but to use the same editor for all standard versions The solution to this problem could be the separation of the data structures from the parsing and writing code This way Kactus2 would use its internal data structures no matter how or in what format it would be written on the disk This would also enable the use of a data base as the library storage instead of the disk Each different metadata version would have its own parsing and writing code which would convert the data from the internal data structures to the appropriate form Now the user could use the same editors to manipulate the metadata and simply select the format for the data to save Parsers could also be added as plug ins to allow use of other metadata types For example an Altera OSys project could be imported to Kactus2 and then be saved as an IP XACT file A common problem when developing the software is to keep the documentation up to date with the implementation code To ease this problem the comments in the Kactus2 code have been written using the Doxygen notation 30 This enabl
149. nts instantiated in them The non hierarchical flat components such as SRAM 512KB obviously do not contain any children because they lack the design reference On the view user can see the entire structure of an example product samos 2012 which is the topmost object on the tree The product contains a board level component which contains a chip and so on until the hierarchy reaches the IP blocks written in VHDL language on the bottom of the hierarchy The VLNV tree on the right side is constructed from the VLNVs of the objects The appearance of this view can be greatly influenced by naming policies The tree is constructed by taking one of the VLNV fields on each level to create a four level deep tree structure For example the full VLNV of the object on the top of the view 1s TUT board altera_de2_board 1 0 23 Component de2 samos soc is marked with red on both views This means that the component is not in valid state and contains some errors The error could be a missing file or invalid reference to an object that does not exist in the library User can explicitly ask the library handler to do error checking on the objects of the library and view the error reports to fix the objects into valid state The error reporting is explained in more detail on Chapter 5 1 2 Kactus2 attributes extend the scope of IP XACT as depicted in Chapter 2 3 3 2 allowing users to document e g the structure of the development board to the IP XACT metadata Th
150. of the Figure 6 1 is the navigation tree of the editor which corresponds to the IP XACT elements in Table 2 1 This tree can be used to browse between different elements of the component When clicking an item in the tree the corresponding editor for that element is opened to the editor area in the middle On the right side is the area reserved for element visualizations Currently only address spaces contain a visualization widget but more will be implemented in future versions of Kactus2 When the user adds new elements to the component e g a new file set they are added to the tree The implementation of the component editor is explained in Chapter 8 The following Chapters will explain the 23 different element editors and their purposes in more detail Each Chapter contains a screen shot of the editor interface and an explanation of the different fields The editors edit the IP XACT metadata of their 32 corresponding elements within a component and more detailed description of the different fields can be found in the IP XACT standard 6 There are two types of editors Summaries contain a table displaying the settings of the items Some elements such as parameters only contain a summary editor because all element fields can be accessed in the table Some more complicated elements such as files reguire several editors to handle different levels of detail All elements contain a name field used to identify the element and a textual desc
151. om the library 11 slots to perform actions to the library and 12 signals to pass information from the library to other modules LibraryHandler is the class that implements the functions declared in Librarylnterface Some of the services it provides itself and some it forwards to one of its member classes LibraryData is the main data class for the library management module It does the parsing and searching of IP XACT files on the disk as well as checks the library integrity Figure 7 3 displays the class diagram of the data classes within library management the connections with the GUI classes are omitted from this Figure ibraryInterface LLL TaelModgel vipy LAL consi J Oo AaredPolnters ibrani Componente g etMode read Only vie PLN consi OSharedPoibterzLibra Component const containsj vinv LAL eonstk boo aetPathi viny VEA consi J OSiring const jquery nie ode Tonner path QStrina consi model QShbaredPoibteraLIbran Components printErrors bool true boo writelloderroFier model QSharedPolnterzLIbrany Component print amp rrors bool true boo searchForxactFesr void getNeededglild Nl sr vim VEN cobs Wst Oristel E Ni J c vole deilependenc iesi viny PLN consi dst OSirnalisi amp J void det reeRooi Libran tem const quer taelliocument per vine LN consi IPXsct pe reference Count vinv Vr NI consie latpjosen detlwnersi Hst Liste
152. omponent asharedPointerscomponentz parent GObject ParteMadel rav Counti parent GModellndex const amp cModellndex j intiquery columnCcount parent atodellndex canst amp GhMadellndex intiguersy i datar index SModellndex const amp rale int 6ft DisplayRole SYariantiouery headerData section int orientation Orientation role int 0t DisplayRale SYarlantidguery setDatal index GMadellndex const amp value G variant canst amp rale intzit EditRale 1 bool flage index alodellndex const amp J ItemFlags query Tig Valid bookiousry SLOT anRemoveRovwt rove int void SLOT onAddRowr void SLOT onA amp dadltemt index SModellndex const amp void SLOT onRemoveltemi index QModellndex const amp J void ESIGMAL contentChangedi void ESIGNAL errorMessagel msg EString const amp J vaidiguery ESIGMAL naticeMessage msg Sstring coanst amp voididuetyj Kom Editor o Pdo MEE oos 1 1L iPushButton exportButtan aPushBbuttan view Editable Tableview model PortsModel proxy GSortFikerProxykodel handler Librarylnterface PortsEditor component S SharedFointercComponent handler Librarylnterface parent GuVidget 0 PartsEditar isvalid baaliauersy refresh void EshowEventi event ashovwEvent J void 12 APPENDIX 15 BUS INTERFACES EDITOR BuslnterfacesDelegate BuslnterfacesDelegate
153. on files of the component ther clock Describes clock signals within a component that are not directly drivers associated with an external port of the component For example generated clock signals can be listed here Parameters Describes parameters that can be used to configure the component Description Contains the textual description of the component This can be used to document a human readable description of the component 10 The components in the library can be divided into two categories by their internal structure Non hierarchical components do not contain any kind of metadata documentation of their internal subcomponents They are not dependent of other components through VLNV references and contain all source codes and documentation they need in their own metadata package The metadata package of these components refers directly to the files in its file sets The only VLNV references are bus and abstraction definitions 1f any Hierarchical components consist of other IP XACT sub components These sub components can be non hierarchical or hierarchical to form deeper hierarchies of system design A Hierarchical component contains VLNV reference to design which instantiates the sub components It does not contain the files of the sub components because they are contained in the sub component descriptions The hierarchical component may contain structural level source codes The structural level code can also be generated
154. on vlnw EN eanst amp J void parseAbsDefinition vinv v LN eanst amp J void parsecombDefinitiont vlnw sLNVeanst amp 1 void parseApiDefinition winy sLNs canst amp 3 void parseDesign vinv vEN canst amp implementation Implementation vievMame GString const amp J void HierarchyModel dataModel LibraryData raotitem GSharedPainter Hierarchytem handler Librarylnterface HierarchyModell sourceModel LibraryData handler LibraryInterface parent Giobject HierarchyMacdel headerDatal section int orientation Orientation role int Gt DisplayRole J G v ariantiquery columnCount parent GModellndex const GmModellndexO intiquery rowwit nunt parent GlWodellndex const amp etModellndex J intiquery index row int column int parent Gldadellndex censt amp aGtaodellndex 1 1 amp tMadelndexigquers parent child Glvadellndex canst amp 3 aMadellndexidquers data index atadellndex canst amp role int Gt DisplayRole a sariantiquers hasChildrenc parent aodellndex const amp aWadelndex J kooligusryi flags index GModellndex const amp 1 kemFlagsioguery i index tem Hierarchyltem 3 alYodellndexiguervt referenceCount vinv SEINS const amp J intiquers getovenersi list QListe v LNS R vinvToSearch VLNS const amp 3 intigueryj findindexes vin YLM Y const J GModellndexList getChildren
155. onst amp J void FSIGNAL createNeySystemDesignt index GModellndex const amp J void SIGNAL exportitem index SModellndex const amp 3 void SIGNAL showtErrorst index Ghlodellndex const J void SIGNAL componentSelectedi vinv v LNS eanst amp J void ESIGNAL draalnitistedi index aladaellndex const amp 1 void SIGNAL errorMessage message arstring const amp void SIGNAL naticeMessage message EString const amp 1 void zcontexthienuEvent event aicantextMenuEvent void zmouseDpoaubleclickEvent event GttouseEvent 3 void mousePressEventl event GtouseEvent void amp mouseMoveEventi event GkouseEvent 1 void amouzeRsleaseEvent event tWouseEvent J void setupActionsi void templates bool mutable bool parameterizable bool fixed bool chip bool TypeOptionst 800 bool Firmnezzoptions in ip bool Hierarchy Options il eC Structs al Structs eC Structs al Structs Firmness ptions TypeOptions Hierarchy ptions H pions components bool buses bool aloka bool product bool board bool advanced bool ImplementationOptionsi 1 x HierarchyFilter dialer LR aDialer firmnesz FirmnessOptions implementation Implementation options Ivpe Typeoptioans hierarchy Hierarchy Options vendorvalidator GegExps alidator library validator GRegExpvalidator namevalidator GRegExp al
156. ool implementation and vendor neutral format to describe the essential information of an IP block Metadata is a general term for descriptive data In this case its purpose is to list for example the interfaces and file sets of an IP block The reusability of the block can be increased by making it easier to port it from one development environment to another Therefore a tool neutral approach is very beneficial The implementation neutral approach means that the metadata does not limit the language the block is implemented in This way there will be no unnecessary dependencies in the IP library between implementation languages and different configurations can be managed easily 7 The standard defines 7 different types of IP XACT documents 6 Component describes a single component in the library For example the interfaces and files for the component are listed here 2 Design contains a hierarchical design which consists of the components instantiated in this design It is a kind of textual block diagram of the system 3 Design configuration defines the configurations used in a hierarchical design 4 Bus definition contains the general information of a hardware bus 5 Abstraction definition defines the logical signals and attributes of a hardware bus 6 Generator chain defines a group of scripts that can be used e g for automatic configuration of a component 7 Abstractor 1s used to combine designs from different abstraction l
157. ool J void createchild index int 1 void removeChildi index int void Get roolin OStradg jquery iexi OSting quer is validi bool query editori hemEaditor editori temEditorconst Tosen visualizer temwisualizer refreshEdftor void canBeopened bool query hasBuittinEdittarl bookiguery SLOT openltemi builtinEditar bool 1 void FolShNAL helplriRequested url SString const amp J void ESIGNAL contentChangedr tem ComponentEditortem J void ESIGNAL createChildc tem ComponentEditarltem childlndex int 1 void SIGNAL removeChildi tem ComponentEditorltem childindex int void ESIGNAL movechild tem cCompanentEditarltem sourcelndex int targetlndex int 1 void ESIGNAL opentSourcef filename GString const amp component GsharedPointer Component void SLOT onEditorChangedi void SLOT onAddChildi index int 1 void SLOT onRemoveChildi index int void SLOT anMovechild source int target int 1 void JA ComponentEditorRootltem 1 ee ComponentEditorRootlitemi libHandler Lipraryinterface component GsharedPointer Component parent ComponentEditorTreeModel ComponentEditorRoottemi getTooltip String query HextO Gdtring query t isvalidi booliguery editorr ItemEditar editor temEditar canst query ComponentEditorTreeModel ComponentEditorGroupSlot libHandler_ L
158. or Editor 4 K E ComponentEditorRootltem g ComponentEditor Generalltem EE GeneralEditor ComponentEditorFileSetskem g FileSetsEditor ComponentEditorFileSetkem D FileSetEditor EE ComponentEditorFileltem NEN ComponentEditorModelParamsltem NEN ComponentEditorParametersltem EE Parameter sEditor ComponentEditorMemMapsltem MemoryMapsEditor ComponentEditor MemMapltem MemoryMapEditor il ModelParameterEditor A ComponentEditorAddrBlocktem ii AddressBlockEditor ComponentEditorRegisterltem Ya RegisterEditor ComponentEditorFielditem i FieldEditor ComponentEditor AddrS5pacesltem EE AddressspacesEditor t 1 CompoaonentEditorAddrS5paceltem D AddressSpaceEditor ComponentEditorViewsltem D ViewsEditor x ComponentEditorViewltem D ViewEditor a n a amma Hummes 1 lt ComponentEditor Cpusitem EE CpusEditor W ComponentEditor therClocksltem Other ClockDriversEditor 1 1 1 Figure 8 1 The class diagram of component editor and its navigation tree The top part of the Figure shows classes that form the basic structure of the editor TabDocument is the base class for all editors of Kactus2 and defines the interface to be implemented in its sub classes Figure 8 2 displays the basic structure in more detail The bottom part of the Figure 8 1 shows the items that form the navigation tree in the component editor On the left are the tree items which mat
159. or IP XACT objects in those directories and their subdirectories The found objects are displayed to the user in library views described earlier IP XACT objects are searched by seeking for IP XACT related tags in all files with XML suffix User may start the library search at any time when Kactus2 is running Together with the search an integrity check is done to the library objects to find possible errors in the library Integrity check is explained in more detail in Chapter 5 1 2 The different phases when searching for objects on the disk are explained in Chapter 7 5 2 5 1 2 Checking library integrity Most of the library objects contain references to other objects via VLNV identifiers All hierarchical components require these references to design and configuration files but also non hierarchical components may contain bus interfaces that refer to a bus definition Components also contain references to files saved on the disk in form of relative file paths Third category is references within a document For example bus interface groups ports together to form a bus by listing port names that belong to the interface If any of these refers to an item that does not exist the object 1s no longer in valid state and it might not work correctly A source file may be missing or renamed thus breaking the IP block On the other hand a bus interface may refer to a port that does not exist which causes a conflict between metadata and the actual sourc
160. order which the items were listed If a mapping from one port to many is desired then the user may toggle the 1 to many button and select a single item on either list and connect it to all selected ports on the other list The user can remove the mappings from the bottom table by selecting the row and pressing delete or selecting Remove mapping from the context menu When a mapping is removed the 50 associated ports return to the top lists Pressing the clean up button will remove any duplicate ports from the lists Figure 6 25 depicts how the physical ports between two component instances are connected through their bus interfaces Port map of a single component Busintertace Suman with interface Boss i ignal mode master Logical TESS mode slave i defined in an Physical ports of abstraction Physical ports of J acomponentA E definition W acomponentB comm out COMM I REN eam WA aan oma on WRITE_ENABLE irr eR PENNE y l CREME ee a Figure 6 25 The association between physical ports and logical signals On the left side is a list of physical ports found on the component A The right side lists the physical ports found on a component B The lines between the physical ports and the logical signals represent the created port mappings in the bus interfaces For example component A has mapped it
161. ors are used to edit both the normal and mirrored versions of interface modes Table 8 2 Interface modes and their editors Interface mode Used editor MASTER BusIfInterfaceMaster SLAVE BusIfInterfaceSlave SYSTEM BusIfInterfaceSystem Figure 8 28 shows the GUI classes of bus interface general settings 977 General Portmaps NameGroupEditor Bus definition Abstraction definition Vendor TUT Vendor TUT Library ip hwp commu L N V E ditor w conmunicaton Name hibi ip r3 busdef Name hibi ip r3 absdef Version 2 0 Version 2 0 Interface mode slave Interface ModeSelector l n RM Bridges Master bus interface Opaque hibi pl hibi p2 v V InterfaceModeStack General Number of bits in least addressable unit amp nau BusIfGeneralDetails Bit steering v E Enable 7 Connection required Name Value Description busif param value ParameterGroupBox Figure 8 28 The GUI classes of bus interface general settings 8 8 2 Businterface port map settings Bus interface port map tab Figure 8 29 provides functionality to set the port maps of a bus interface It follows the model view architecture with the exception that it contains several different views and models 98 PortMapsModel busif Buslnterface portMaps GListeisharedPointerePorthtapz 7 amp proxy_ gt GSortFitterProxyModel component_ SSharedPointer Component
162. orti filePath string cansts amp aGcstrina J void S5LOT setDefaultimportExportPath path G Stringq const amp void SIGNAL additem index EeModellndex const amp void SIGNAL removeltem index SModellndex const amp J void ESIGNAL moveltemi originalPos Ckdlodellndex const amp newPos Giklodellndex const amp J void emouseMoveEvent e GMouseEvent J void RkeyPressEvento event GkeyEvent J void EmouseDoubleCickEvento event SMouseEvent void EmousePressEvento event GhlouseEvent J void EmouseReleaseEvento event GldouseEvent void econtextMenuEventi event acontextWenuEvent 1 void SLOT onAddAction void SLOT onRemo veAction void SLOT oncopy Action void SLOT onPasteAction void SLOT onclear amp ction void setupActions void Figure 8 6 The implementation of table editors The model classes inherit QAbstractTableModel which provides the default implementation to provide model indexes to views The following 7 functions are implemented in sub classes 1 rowCount obtains the number of rows to display in the table columnCount obtains the number of columns to display in the table data obtains the data for an item identified by a model index headerData obtains the headers for the different columns of the table flags 1s used by view to know how the data of an item can be handled setData saves data of an item back to the model 5 2 ceo 5
163. ossible and likely However e g setting the files first helps the user to get started with the basic settings and then advancing to the elements which describe the component in a more detailed way 105 Many of the sub editors within component editor use the table editor interface This is a powerful way to manage large guantities of data in a single view For example the port editor is likely to contain dozens of ports so displaying the data in an efficient way is crucial Also in elements which reguire a more detailed editor the table is used to set the general settings of the elements so the user can perform the packaging in a sort of top down method advancing to the detailed editors after the general settings Currently the address space editor is the only editor which provides a visualization of the element being edited The component editor has a specific space reserved for visualization widgets in the GUI explained in Chapter 8 but they have yet to be implemented for the other element types These visualizations could be used to help users to understand the current state of the component when editing as well as the effects of their actions in an intuitive way Also a visualization tool could be used to package e g the dependencies between files of the component The most important factor for usability in the component editor module is the connection to the context sensitive help When the user navigates through the different sub edi
164. p communicatian 2 hibi wrapper r4 3 0 TUT ip Awe communication Figure 7 2 The GUI classes of library management module The hierarchical view is on the left and VLNV tree on the right VLNVDialer is the container class for the search and filtering options in the GUI FilterWidget implements the filtering options for different groups of attributes DialerWidget implements the search widget enabling searching for text in different VLNV fields VENVDialer is connected to both filter classes to update changes in search conditions One of the most important services in the programmatic interface of library handler is the parsing of IP XACT XML files into data structures LibraryComponent is the base class for all IP XACT data structures such as components and designs and libraryHandler keeps a cache of these classes to provide faster parsing of library items 55 7 1 Data structures Library management module contains several different data structures to enable different views to the library and to allow navigating the library structure and dependencies LibraryInterface is the interface class which all other modules use to access the library management services It is an abstract class and doesn t contain any implementation code which makes it easy to change the implementation of the library services if necessary e g changing the library management to use data bases The interface contains 17 functions to retrieve data or information fr
165. parent GObject BuslnterfacesDelegatet createEditor parent Gvvidaet option GiStyleoptionvieveltem const index GModellndex const GuVidget query setEditorData editor Cu vidget index alaodellndex canst amp 1 void query i setModelDatar editor cvidaet model GAbstracttemModel index attodelindex const amp J voidiquery SLOT commitAndoloseEditor 1 void NAME COLUMN BUSDEF COLUMN ABSDEF COLLIMN IF MODE COLUMN DESCRIPTION COLUMN COLUMN COUNT libHandler Librarylnterface component azharedPointerzcompanentz busifs aL ist asharedPointer Buslnterfaces2 amp EuslnterfacesModelf libHandler LibraryInterface component SSharedPointer Component parent GObject BuslnterfacesModelf i rowlountl parent GModellndex const amp GcModellndex0 intiquery i columnCountr parent Gladellndex caensts atodelndex intigueryj flags index GModellndex const amp J ItemFlagsiaquery headerDatar section int orientation Orientation role int2at DisplayRole EYarlantiouery data index atodellndex const amp rale int Gt DisplayRale StYarlantiguery setData index Gladellndex const amp value a variantcanst amp role intzGit EditRale 1 bool A bool query i SL OT onZddltemf index Qhodellndex const amp void SLOT anRemoveltem index atadelndex const amp J void SIGNAL contentChanged void ES
166. ponent SW platform F COM interface communication abstraction Standard HW component HW platform Bus interface 77 s BUS ABS ae oe oe Hardware abstraction layer HW interconnections definition definition Figure 2 6 New IP XACT object and interface types API interfaces are used to connect SW components to each other For example the API provided by a driver is documented in API definition which lists e g the functions of the API The driver SW component contains an API interface which refers to the API definition thus promising to implement the interface reguirements The application SW component also contains an API interface which means that the application uses the API in some way When the two API interfaces are connected together this means the application uses the API provided by the driver component The communication between IP blocks can be abstracted to a higher abstraction level by using software stacks which implement a higher level communication mechanism An example of this kind of higher level communication abstraction is the Multicore Association Communications API MCAPI 11 Usually the communication in higher abstraction levels is implemented by software run on a processor The software implements the logical communication channels but the underlying hardware components do not know of these logical connections For these logical communication channels to be functional some kind o
167. ports PortListView and PortListModel act as base classes and provide most of the functionality needed to present a list of items PortMapsView is connected to the PortMapsModel which provides the port maps of the interface When the user creates a new port map it is added to the model and displayed to the user 100 9 EVALUATION OF THE WORK Kactus2 is released as open source software under GPL2 license The open source version of the Ot framework was used to provide a cross platform design tool for embedded MP SoC Table 9 1 lists the line and class counts of the presented modules the two topmost rows and the whole project Table 9 1 The code statistics of Kactus2 v2 0 Component editor 21 108 156 eraasi Library handler PAZI 26 Library management module o o IP XACT data structures 25 271 Design editor software flow etc 49544 omitted from this thesis 103350 The IP XACT data structures which are used to read and modify the IP XACT XML metadata are shown to give an example of the library complexity Figure 9 1 displays the development of the entire Kactus2 software since its first release in October 2011 ode Comments and Blank Lines 300k October 2012 Code 165 541 Comments 57 126 Blanks 35 539 Figure 9 1 Total code development The graph is drawn since the start of the first release and therefore doesn t start at O LOC The development of the Kactus2 begun in June 2010 Also noticea
168. r File set editor Figure 8 15 is a container which has 5 editors to edit different elements NameGroupEditor is used to edit the name and description of file set Editor is explained in Chapter 8 1 4 2 FileBuildersEditor Table 8 1 is used to assign build commands for different file types 3 FilesEditor Table 8 1 is used to add and remove files contained in the file set 4 GroupManager is used to edit the group identifiers of the file set The editor inherits ListManager depicted in Chapter 8 1 3 The sub class uses the base class functionality otherwise but provides suggestions for possible group identifier names for the user to select e g sourceFiles or documentation 5 DirListManager is used to edit a list of directories on which the file set depends The editor inherits ListManager which is depicted in Chapter 8 1 3 85 NameGroupEditor hdlSources FilesEditor File name File path File types Description hibiv2 pkg vhd vhd hibiv2 pkg vhd vhdlSource Hibi segment vhd vhd Hibi segment vhd vhdlSource addr data demuxes vhd vhd addr data demuxes vhd vhdlSource addr data muxes vhd vhd addr data muxes vhd vhdlSource Is 4 Default file build commands Fil eBuil d ersE dit or File type Command Flags Replace default flags 1 SBE vhdlSource vcom quiet check synthesis work hibi mem dma Double click to add a new item roup identifiers GroupManager ependent director
169. ress spaces to create a link between programmable core and interface 6 12 Other clock drivers editor Other clock drivers editor Figure 6 30 shows the clocks within the component which are not directly associated with a top level port These kinds of clocks could be e g virtual clocks or generated clocks Other clock drivers Clock Clock Clock Period Pulse Offset Pulse Pulse Duration name source period unit offset unit value duration unit virtClock 5 ns 0 ns 1 3 5 ns genClock i clkGen clkl 20 ps 4 ps 0 5 ps Double click to add a new item Figure 6 30 The user interface of other clock drivers editor The clock source specifies the physical path and name of the clock generation cell The rest of the columns are used to describe the waveform of the clock signal The time units are either ps picoseconds or ns nanoseconds Figure 6 31 depicts the association of the different columns to the waveform of a clock pulse Clock period Clock pulse offset Clock pulse duration i ml m Clock pulse value Figure 6 31 The waveform of a clock pulse The clock period defines the length of one cycle of clock pulse Pulse offset describes the time delay from start of the pulse to the first transition Pulse value defines the logic value which the transition 1s made to Pulse duration specifies how long the value defined in pulse value 1s held 53 7 LIBRARY MANAGEMENT MODULE LibraryHandler implements
170. ription piss Port map Logical name Physical name AV 0 0 bus av 2 in 0 0 API Deter Figure 4 2 Screenshot of Kactus2 with HW design editor Figure 4 2 displays a design editor in the middle containing three components instantiated The design editor is used in the integration phase of the development to instantiate components created with the component editor The left side of the Figure displays a new object dialog where the user can select the type of object to create On the right there are several different context specific editors which are used e g to edit the details of the component instances Whenever user selects an item in the design editor an editor for the item is presented For example the user has selected a bus interface and the details of the interface are shown on the right Kactus2 uses different icons to display the object type to the user in the library views as depicted in Figure 4 3 The VLNV identifying the object is seen on the right side of the icon ehdo kn API definition E E TUTiexampies Bus definition akkaa UE Abstraction definition E ibn COM d efi nition kt HW Component c ial ara _hier_component HW Desi gn hdr iR HW Component 9 HA iconsisw desin SW Component 3 aan RE SW Desi en TUnexemptes SW Component icons SW component I odeur am System Component TUT examples System Design icons sysdesign system Figure 4 3
171. ription explaining the purpose of the element in guestion The mandatory fields of each editor are marked with yellow color If some information is invalid such as reference to a missing element or mandatory fields are empty the element is displayed in red color 6 1 General Editor General Editor is the first editor shown to the user when he opens the component editor It contains the general information of a component such as description Figure 6 2 shows the user interface of the general editor Vendor TUT Library ip hwp communication Mame hibi segment small Version 2 0 Path D TP library funbase ip library trunk TUT ip hwp communication hibi hibi segment small 2 0 hibi segment small 2 0 xml Kactus Attributes Product Hierarchy IP Firmness Parameterizable Implementation HW Description HIBI segment block induding two r4_wrapper and one r3_wrapper interfaces hibi segment small dk in ddr2 ctrl p lt gt lt hibi pl Figure 6 2 The user interface of general editor VLNV identifier and the path to the XML file are shown on the top of the editor These fields can t be modified and if the user wants to change the VLNV then the component must be saved as a new component Kactus2 attributes contain the hierarchy firmness and implementation of which the implementation can t be modified see Chapter 2 22 The component preview box on the bottom displays how the component will look like wh
172. rsionText GString const amp J void ESIGNAL firmnessChangedi options FirmnessOptions const amp J void FolsShAL implementation changed options mplementation options const amp 1 void FSISHAL typechanged options Typeoptions const amp J void ESIGNAL hierarchyChangedc options Hierarchy options canst amp void 5LOT refreshLibrary void SLOT onHideshowclick void Figure 7 9 The class diagram of VLNV dialer VLNVDialer is a container which sets the layout for two classes FilterWidget contains the check boxes to select which object types hierarchy levels etc to show in the views DialerWidget contains the implementation for the text search within VLNV identifiers see Chapter 5 3 1 It contains four combo boxes each matching one of the fields in the VLNV identifier It is connected to the root item of the VLNV tree view to allow navigation through the VLNV data structure 63 7 4 1 Filter widget Filter widget Figure 7 10 provides functionality to select different filtering options to hide show certain types of library objects from the user eC Structs C Struct Implementationoptions TypeOptions components bool buses kool h gt bool 5w bool system bool advanced bool ImplementationOptions Typeoptionst 1 px ImplementationGroup TypeGroup hwBox acheckbBox componentBox GheckBox swBox acheckbBax busApicomBox acheckbox system6ox acheck
173. rt of the editor contains the same information as the previous editor The logical name of a file can be used e g to specify a VHDL library for a VHDL file If the only used as default check box is checked then the logical name can be overridden by another process For example in case of VHDL the library where component is compiled to could change by changing the compilation flags The is include file and contains external declarations check boxes can be used to specify the file is an include file and that the file contains external declarations and is needed by other files in this file set The description and the build command can be defined also file by file Replacing the default flags means that only these flags are used to build the file Otherwise the flags are appended to the flags received e g from the file set The target name specifies a path to the file that is derived from this file when the build process is run It is not needed with VHDL but is useful e g with C 36 6 3 Model parameters editor Model parameters editor is used to add remove and modify the model parameters of a component Model parameters are often used in HDL languages to pass information to the model to configure it e g generics in VHDL Figure 6 6 displays the user interface of a model parameters editor Model parameters Name Data type Usage type Value Description data width g integer nontyped 16 disable arp g integer nontyped 0 pa
174. s port comm_out to the logical signal COMM Because the component B has mapped its port comm_in to the same logical signal this means that the ports are connected together if the user connects these interfaces together in a design Of course if no connection is made between the component instances in the design then no ports are 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 6 25 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 Figure 6 26 depicts how a part of the physical port can be connected 51 Port map of component A Logical Logical Logical Physical Physical Physical left right name name left right 3 0 DATA data out 7 4 76543210 krm ll Port data out on component A 3 210 Logical signal DATA 76543210 LITLI BER Port data in on component B Port map of component B Logical Logical Logical Physical Physical Physical left right
175. sed odd REA LEM 25 5 2 2 Open item for viewing or editing eeseeeeeeeeeeeeeee 26 5 2 3 Open the metadata to XML editor eeeeeeeeeeeeeeee 21 Ds cee MEME SUR er a kua aE eat EaEa 21 2 ESPOO Nams mcd vuoka Ta deo RO dco ona ioe 27 2342 0 REMOVE TC yas etie tud er FI kN ava KAA km Didaco xe per Paste edu 28 V ME ic e 20 Sb Search for Term in Ne HDEAE muasssa annoimme naos Pusa ooa deo See 20 229 2 Ferena DES iie ponen mis eerie cen eet Sn ic ee 30 6 Packaging of an IP block with component editor eeeeeeeeeeeeeeeeeeee 3l OE Gom RAL PATTON used arts tied boda aute A d anite etes oda 32 02 FICSEESUIMA T DO D 33 6 2 1 Fe Set edltOf ueste Sea PUE ase ocio ud ie Eo e Iu SE eet dani 33 G2 deb PISseU IE OR ioni a na ee beds edel ebd osamalli 35 0 3 Model parameters edltOr iupra Deeds eet t pd ee rab oe dedu en rane beue 36 0 4 Parameters editOE uiuis cp io rod e AE ua tao oa o pda UD 36 63 Memory Map SUMA y asiaa Season Ra aa Ede TANE saut TS SEAT J S S TN Saue on 36 6 521 Memon map editOE isi erbe eee eed ace ae nee 37 0 9 11 Address DIOCK editt uoo ite eet oo MET emo tab tendon 38 0 0 12 IROSISIGE COMMON 3o tuia uo eei Ecos euo basa oU UU ME aio adis 39 Oo PIER OAIOP omaissa Kaanon a d dulieteboditond Ud ePi ene 40 0 0 gt Address SDICO SUMMARY Laos ei drei Eoo edid de Cod ei et cool opa Id PEU 4 6 0 1 Address Space editor ane
176. sie oer ut iet reti etie Sees 75 8 1 2 Model view architecture in Kactus2 eeeeeereeeeeeeee 75 Duo A eA Ree E a R 80 Sda Name PIOUD CONOR sanra imusta sto ni m t das Edu cote 81 5 2 General Edit ouest eie ame d heb aaa I Loan ceca 82 S MEM uii CAO ea 84 Oc UNC CCIE O is gots etree tates talea ciant tota eta LI opes Fc CC am auda 85 SAk Filegeneral taD n 87 So Address spacc dilokasi ere minst ee Mop aan Tute mistaa 88 OO Tel SAKO vot sn ast vai ee ek se ace ee irda ok ener iae d Ceca Seah 91 Sd NEON Mes TREE 92 8 9 B usinierface CCIE saumaan Sussa am TOKA Saanaa pet rau Nv uu KSNK pe tuo etras eges 94 8 8 1 Bus interface general settings cccccccccccccsssseseseeceeeeeeaeeeesseeeeees 95 8 8 2 Bus interface port map Settings cuoi eo mas Ree ese EORR Er eG read pc 97 9 Er luation ok the Woi massassa cate tee pE m DRE ed M er e NE DN vakat 100 OA NIamtamaDIlity Jota Me i babeat did oa Mate ean edu dedo MH 102 Dede SADU c Sy sR ntjeiten 104 OCCA DIMOY ooo hee e dado eee end dU E EU EU eU LUE 105 07 SCODCTUSIODS o5 oec testen hs ORT o pns Owen bom opns OMiNM Eo Pd Dod ea ttUh 108 Relerer6eSusecuitoo itis Tosta uctahs pedi etum oto Maece ub sen S secus te Dod usse cbctpr d vaeletmeetees 110 Appendix LI Parameter orou p DOX oe en upi ie e p ieu ee ete born rive nes Predator n ru Rs 113 Append 2 File D tlders COMO ie 2522 iode chased vestej si veiston 114
177. slot for each GUI element such as onUseEnum Figure 8 22 displays the GUI classes of field editor l read write read write read write Double click to add a new item EditablelableView Write value constraints WriteValueConstraintE ditor O Write as read 8 Use enumerated values Set minimum and maximum limits Minimum Maximum Figure 8 22 The GUI classes of field editor 8 7 View editor View editor Figure 8 23 provides functionality to edit the details of a single view It contains elements for both hierarchic and non hierarchic views but changes its visual appearance according to the view type Libraryinterface parent Ci Vidget D MULUS Figure 8 23 The structure of view editor ViewEditor is the container class which owns the other classes and sets their layout in the editor It contains a combo box viewTypeSelector to select between hierarchical and non hierarchical views and adjusts the layout accordingly The editor contains 6 editors NameGroupEditor edits the name and description of the view and is depicted in Chapter 8 1 4 93 ParameterGroupBox Table 8 1 edits the parameters of the view 3 FileBuilderEditor Table 8 1 defines file build commands for files referenced in the view 4 EnvldentifierEditor Table 8 1 sets up environment identifiers for the view 5 FlatViewGeneralTab modifies settings that are only included in non hierarchical Views 6 Hierarchy
178. splays the menu for selecting the filtering conditions Item Type v Component I BusjAPI COM Advanced Implementation IV Hw Sw v System Product Hierarchy Iv Global v Product v Board v Chip Iv Soc lv IP Firmness v Template JY Mutable IV Parameterizable v Fixed Figure 5 12 Selecting the filtering conditions 31 6 PACKAGING OF AN IP BLOCK WITH COMPONENTI EDITOR The component editor module is used to package IP XACT components It provides help and advice but also reports errors in the metadata to help the packaging process The visual user interface is much more user friendly than the traditional XML editing tools This editor is used in the phase 1 of the Figure on page 7 When the essential information of an IP block is packaged in the component metadata it is easier to manage and reuse the block Figure 6 1 displays the user interface of the component editor General File sets Model parameters Parameters Memory maps Address spaces QE RR 3d irspace adi LLLA Views Software views System views Ports Addressable unit size Bus interfaces Editor area ange of address Dloci 12M f m fOr different alan N erts Description segment nail segment Ox4000000 128M Area for element visualization 2M Cpus Other clock drivers COM interfaces Software properties Figure 6 1 The user interface of the component editor On the left side
179. startPos Point PortListvievel parent Cttidget PortList iew getSelectedPortst remove bool 1 GtringList FSIGNAL removeltemi index Ghodelindex canst amp voidiguery i FSIGNAL removeltemsi indexes GModellndexList const amp 1 voidiquery ESIGNAL moveltemsi portames G StringList const amp targetlndex itwadelndex const amp 1 voidiquery Ex FSIGNAL makeconnection physicals CStringList const amp logicals C StringList const amp J voidiquery zdradgEnterEvent event aDragEnterEvent 1 void zdragMoveEvent e GDragMoveEvent J void LogicalListvievet parent Ctvidget imouseMoveEvent event GllouseEvent void Lagicallistiew gmousePressEvent event aldouseEvent 3 void amp dropEventi event GIDropEvent 1 void performDrag void portMap GSharedFointer lt PortMap busif Buslnterface component GSharedPointerzicomponent libHandler Librarylnterface mapProxy GSortFitterProxyModel 1 model Portklapskiodel View _ Porthdaps view logicalviesw _ Logicallistwiesw 1 logicaltdodel LogicalListmodel physicalview PhysListVview physhodel cleanButton PhysListMadel 1 aiPushButtan connectButton aPushButton onezi neButton iPushButton one2ManyButton SPushButton xBuslfPortmapTabr libHandler Librarylnterface component GSharedPointersComponent busif Buslnterface parent Giy
180. t parent Gobject USER EDIT ROLE ChannelsModelf i rowecount parent Oklodellndex const amp taModellndex intiguery i coalumncount parent Ghlodelndex const amp aGhadelndex intiguery i flagst index atadellndex const amp temFlagsiguesry i Col headerDbata section int orientation Orientation role int 4t DisplayRole 3 SYarlantiguery i meee datal index GModellndex const amp role int Gt DisplayRole G ariant query i MAME _ COLUMN setDatar index GModellndex const amp value G arlant const amp role int 0t EditRole bool DISPLAY MAME COLUMN isvYalido booliguery i INTERFACE COLUMN SLOT onAddltemi index QModellndex const amp J void DESCRIPTION COLUMN S5LOT onRemoveltem index Sklodellndex const amp J void COLUMN COUNT ESIGNAL contentChangedi void FSMSMAL channelA ddedr index int J void 1 ESIGNAL channelkemovedi index int 1 void EditableTableView Kom Editor 1 a enumeration OSortFilterProxyModel ChannelsEditor view Editable Table yiev proxy GSortFiterProxyModel i model channelshMadel ChannelsEditor component sharedPointerzcompaonerntz parent C Yidget 0 ChannelsEditorf isValid bool query retreshty void 129 APPENDIX 17 CPUS EDITOR CpusDelegate LIST EDITOR MIN HEIGHT int const 100iread amp n component azharedPointerzicomponentz CpusDelegatel component GsharedPo
181. t parent Guobject TMiewshMadeal rowecpount parent maedelindex const amp ahodellndex 7 intioguery columncaunt parent tadelindex consts aGhaodellndex J int quers flagzt index Gahadellndex canst amp J temflagsigueryi headerbata section int orientation Orientation rale int 4t DisplayFole j SYarlantiguery data index Ghltadellndex const amp rale int at DisplayRale StYarlantidguery i zetbatar index SModellndex const amp value a variant canst amp rale int 0t EditRole kool Tis valid booliguery S5LOT an amp daltem index atadelndex const amp J void S5LOT onRemo eltem index Galadellndex const amp J void ESIGNAL contentlhanged void ESIGNAL view Added index int 1 void az MAL vieveRemovedi index int void Enumeration Column We Sohn ae I DESCRIPTION COLLIMN COLUMN COUNT A ViewsEdrtor view _ Editable Table iev proxy GSSortFiterFroxyModel model View shlodel vlewesEditori component iharedPointerzcomponentz parent Guvidget T SslewsEdtor tie validi baaliaquery xrefresh void 125 APPENDIX 13 ENVIRONMENT IDENTIFIER EDITOR Enuldentifier sDelegate EnvIdentifiersDelegate parent aobject EnvldentifiersDelegater createEditor parent cvvidaet option E StyleOptiontvieveytem const amp index aWodellndex const amp J Gvwidaet rquersyr setEditorDatar editor Gvvidag
182. t complex tests for the library management would probably be related to the dependencies between the library objects The more difficult parts are the integration and system testing The integration testing can be done partly in code level but especially the system testing requires GUI tests which are much harder to automate When there 1s no documentation on the desired results of operations performed in the user interface it 1s under the tester s intuition to decide which results are correct and which defects So far the Kactus2 has been developed and tested within the same development team and communication between team members has been easy and fluent so this hasn t caused any problems However because the presented software has been released under open source license it is 107 possible to have outside contributors to the project in the future In this case it would be reasonable to start documenting the correct behavior in different use cases Also the use of automated tests would help verifying the commits from third party contributors 108 10 CONCLUSIONS This thesis presented the IP packaging and library management modules for the open source Kactus2 IP XACT design tool Kactus2 was developed in C language using the open source version of Ot cross platform framework The development has so far taken 2 years for the entire software The library management module consists about 7 500 lines of code and the component editor module 21
183. t item then owns the other items which are visible Hierarchyltem provides several functions to manipulate the tree e g in case of delete operation Figure 7 5 displays the class diagram of the VLNV tree model which is the other library view in the GUI 58 name QString level Level childitems_ GListeLibraryltem parentitem Librarsltem inv_ gt LAK Libraryltem name 2String const amp parent ixobject LibraryItem vin gt S LPSIeonst amp level Level parent Libraryltem Librarytem createChildr vinv VLA const level Level void parent Librarytem query getNamel Gstring query getLlevelf Leveliquery childf index int Libraryltem query troy int xaetlumberofchildren inticusers get MW WLM query getindexOft tem Libraryltem J int xaetkow int hasChildrenc bkooligueryj xaetvLNSsvinvList aListewL MYW 8 3 void xremovechild childltem Libraryltem J void findHighestUniguer childkem LibraryItem 0 1 LibraryItem findHighestUniquer wins WLY const 1 Libraryltem finditeme vinv WLAW conat 3 Libraryltem xset vInvi vinv gt YLIT 3 void clear void T getvendors validator SRegExpYalidator const amp GLlisteLibrarykem iguery get Yendors OSListeLibrarykem igueryi getlibrariesi validator OSCRegExpYalidator const amp GList Librarytem query get
184. t type specifies the type of the port in the implementation language In case of VHDL the typical values for scalar and vectored ports are std logic and std logic vector The type definition 1s a language specific reference to where the type is defined For the previous example the type definition is EEE std logic 1164 all In case of SystemC the type definition is the include file name e g systemc h The default value is used to assign a value for an unconnected port This is used for example when generating a structural VHDL for the top level hierarchical component to assign values to input ports that are not connected to any other port within the design The ad hoc column is a Kactus2 specific extension which is used in the graphical user interface of a hierarchical design Figure 6 21 displays an example of a component instance that has ports set as ad hoc ports 46 led packet codec clk From_hibi pkt_codec led outi Figure 6 21 The ad hoc ports on a component instance In this case the instance has 5 bus interfaces clk led rst n from hibi and pkt codec Normally this is all that the user sees of the interfaces of a component but if the user selects ports to be ad hoc then they are also shown Figure 6 21 displays two ad hoc ports rx av in and led out the directions of the ports can also be seen by the port icon 6 9 Businterface summary The bus interface summary Figure 6 22 is used to add and remove bus interfa
185. tems are removed from the library and disk If the user wants to save some of the items they can be unchecked in the dialog and they will not be removed Figure 5 10 displays the dialog asking if the user is sure he wants to remove a hierarchical component altera de Il demo and its configuration and design Also the files contained in the component are listed Type TUT socaltera de II derno 1 0 VLNV object TUT socaltera de II demo designcfg l 0 VLNV object TUT socaltera de I demo design 1 0 VLNV object D IP library funbase ip library trunk TUT soc altera de I demo 1 0 vhd altera de I dem File D TP library funbase ip library trunk TUT soc altera de I demo 1 0 quartus atom netlists File D IP library funbase ip library trunk TUT soc altera de I demo 1 0 doc Altera DE 2 dem File D IP library funbase ip library trunk TUT soc altera de I demo 1 0 sim create makefile File D TP library funbase ip library trunk TUT soc altera de II demo 1 0 sim sim do File Select deselect all Figure 5 10 The confirmation dialog for the user to select which items to remove 5 3 Viewing The following use cases affect how the library looks like They do not change the library structure but only the visual outlook of the library views 5 3 1 Search for item in the library The number of objects in the library may become very large making it hard to locate a specific object in the library This is why the library handler provides a search
186. terz 5 hodelParameterMoadel component G SharedFointer lt Componentz parent QObject EditableTableView hodelParameterModell x ow Counti parent GModellndex const amp GModellndex intiquery i columncount parent atadellndex canst amp aGhadellndex int quers data index GhWadellndex canst amp rale int 0t DisplayRole j Gi s arianticuery headerData section int orientation Orientation role int Gt DisplayFRole j ESeYariantioguery flagsr index atodellndex const amp 3 temFlagsidguery setDatal index Ghadellndex consts value a variantconst amp role int it EditRole 1 bool EMEND isvalido baalzauers awl 5LOT onRemoveRowr row int 3 void T SLOT on ddRovv void SLOT on ddftemc index atadellndex const amp 1 void S5LOT onRemoveltemi index SModellndex const amp J void E MAIL contentlhanged void ESIGNAL errorMessaget msg EString const amp voidiguersy j ESIGNAL naticeMessage msg OGString const amp J voidigueryi Kom Editor view EditableTablewievw model ModelParameterkodel proxy GSsortFikerProxyhModel ModelParameterEditorl component s SharedFointersComponent parent S Yidget 0 WlodelFarameterEditorf isvalido baaltauery i refresh void 118 APPENDIX 6 PARAMETERS EDITOR LineEditDelegate hMINIMUM EDITOR HEIGHT int const 20iread amp On LineEditDelegate parent CObj
187. test bench can be used to automate the testing of the IP block The test bench should include the automatic checking of the test results For hardware blocks the test bench may be a VHDL entity which instantiates the design under test For software there are several software frameworks especially for unit testing which can be used to write automated tests that check the results of the tests against the expected outputs 6 2 2 3 Source files of the implementation The most essential part of the IP block is the implementation files If there are other IP blocks that are needed for the main block to function then also the source codes of those blocks must be included An example of this could be a third party library used by the IP For hardware IP blocks there may also exist some software components such as drivers 2 2 4 Files to help the initialization of the IP block The initialization of the IP block is much easier if the block includes an example use case where the block is instantiated and used A makefile will help compiling the IP and lists its internal dependencies Synthesis scripts are similar auxiliary files for hardware IPs 2 3 IP XACT standard IP XACT is an XML format standard developed originally by SPIRIT Consortium for configuration and integration of electronic components and designs 6 The current version 1 5 that Kactus2 supports is also approved as IEEE 1685 2009 standard The purpose of the standard is to provide t
188. the interface for library management module providing services for other modules in Kactus2 It contains both a graphical user interface for the user to interact with library objects and also a programmatic interface for other program modules Figure 7 1 shows the class structure of the library management module elt otruct el Structs amp CrT5SIructs amp CrT5SIructs TypeOptions FirmnessOptions Implementation ptions HierarchyOptions 1 1 1 1 x x j x 1 1 1 1 1 1 1 1 17 t LibraryData FilterWidget DialerWidget 1 1 1 1 J VLHVDialer LibraryTreeModel 1 HierarchyModel 1 x LibraryTreeFilter 1 LibraryTreeView LibraryTreeWidget HierarchyView LibraryComponent HierarchyAVidget 1 LibraryHandler Figure 7 1 The structure of library management module The eraphical user interface of the library management is explained in Chapter 5 The main class is LibraryHandler on the bottom of the Figure It consists of 3 data classes LibraryData HierarchyModel and LibrarylreeModel which contain the data 54 structures It also contains two widgets HierarchyWidget and LibraryTreeWidget which contain the library views shown to user The two library views presented in Chapter 5 are implemented by HierarchyView and LibraryTreeView which are connected to corresponding filter classes to enable the use of the search and filtering options The library views follow the model view archite
189. the library handler takes the modified data structure and writes it to the disk If the object is new and is not yet in the library the user is asked to select a path to which the XML file is written into If the object was already in the library the handler knows the location and overwrites the previous file Because the files are overwritten it is recommended to use some version control system such as SVN or Git to help restore previous versions of the objects 5 2 5 Export item The user may wish to hand over a single IP block or part of the library for a third party without disclosing the whole library To make this easier the library handler contains an export function that can be selected in the context menu as in Figure 5 9 Kactus2 prompts the user to select a destination directory to export the selected object to The target may be another directory on the same disk a directory on network disk or e g a USB memory After this the library management module copies the selected object and all its dependencies to the new location Both direct dependencies of the object and indirect dependencies through other objects are copied to maintain the objects in a valid state This way all needed IP XACT objects and files are copied with a single click and files are not lost accidentally 28 Eb TUT El ip hwp communicatian Eb hibi_orbus a EIT hibi segment pen Component H hibi wrapper E hibi
190. tion HierarchyView forwards the reguest to the model class 3 HierarchyModel identifies the object and forwards its VLNV identifier to LibraryHandler 4 LibraryHandler asks the user to input a target directory to export the object to 5 Theuser selects the target directory 6 LibraryHandler calls for its own copyFiles function to copy all dependencies of an object to a new location 7 LibraryHandler asks LibraryData to parse the object from the disk Note if the object is already parsed in the memory then parsing is not necessary 8 LibraryData parses the object to a data structure Pointer to the parsed data structure is returned to LibraryHandler 10 LibraryHandler asks the object for its file dependencies 11 The object returns the file paths in a list 12 LibraryHandler asks the object for dependencies to other IP X ACT objects 13 The VLNV identifiers of the references are returned in a list 14 AII files are copied to a new location 68 7 5 4 Deleting a component Figure 7 14 depicts the different phases of selecting a component to be removed from the library and the disk 1 Delete item 2 onDeletellemiindex const GhModellndex amp index 3X getvLNvsr 5 onRemovevLNV vIfm gs Liste vL Nf E gt ObjectRemoveDialog T createtem yviny g gethtodeltyinv const VLAAMS vins l l l l T 110 11 GSharadPnointer 12 getFi
191. tion Not all elements are required for a single component and different types of components will use different elements Table 2 1 describes some of the elements of a component supported by Kactus2 6 Table 2 1 Different elements of a component IP XACT Description Po NEN VLNV An unambiguous identifier used to identify the component in the Bus interfaces Describes all external interfaces of a component Bus interface DET gemens Channels Describes interconnections between interfaces inside of the component This element can be used to describe a bus connecting interfaces together Address spaces Describes the addressable space seen from bus interfaces with interface mode of master This can be used to describe the address space seen by a CPU through bus interface Memory maps Describes the addressable area seen through bus interfaces with interface mode of slave Ports Describes a list of ports for the component These are used to EE describe the external connections of the component Model Describes the parameters needed to configure the model parameters implementation specified in a view Views Describes the different views of a component Component may have different views For example one view for the RTL implementation and one for the written documentation of the component File sets Describes groups of files that can be e g grouped by their function One file set may contain the source files and other the documentati
192. tors the help window reacts to this by changing the help view to match the active editor This way the user can understand the purpose of the different editor fields even without knowing the details of the IP X ACT standard The use of Qt framework enables the graphical user interface to adapt to the visual style of the different operating systems This way Kactus2 provides a native outlook in each operating system it supports Figure 9 5 displays an example of the new object dialog in Windows Vista and Windows XP The same release version without any OS specific code is being run in both screenshots W New ves New 2 x 3 New HW Component m New HW Component Creates a flat non hierarchical HW component Creates a flat non hierarchical HW component HW Component Kactus Attributes HW Component Kactus Attributes NS Product Hierarchy Global zj N Product Hierarchy soc v 9 Firmness Template P rees Mtae E HW Design HW Design VLNV VLNY Vendor vendor Library global Library soc SW Component Name SW Component Name Version Version W o o u g Ei f A m uw E 3 3 Directory D Programs Kactus2 Library un 9 i o g i LE 5 Directory D user kamppia SVNwork DACI IP libraryftrunk Ln x p fag E COM Definition COM Definition is API Definition Figure 9 5 The visual outlook in Vista and XP operating systems 9 3 Testability The m
193. tring ESIGMAL createMewDesign index GModellndex const amp J void ion string ESIGNAL createNewSvyDesign index GModellndex const amp 1 void ESIGNAL createNewSsystemDesign index GhWadellndex canst amp J void LibraryTreeFilter handler LibraryInterface dialer vLN Dialer sourceModel Q4bstracthemModel ESIGNAL deleteltem index ahoaedellndex const amp void LikraryTreefilterij ESIGNAL exportltem index atdodellndex const amp 3 void on endorChanged vendorText GString const amp j void ESI MAL showkErrorsrt index atodelndex const amp 1 void onLibrary Changed libraryText GString const amp J void ESIGNAL openBust index SModellndex const amp void xanMamecChanged nameText CString const amp void ESI MAL opencomDeft index GModellndex const amp 3 void on versianChanged versionText String const amp void ESIGMAL openA amp pibef index ctadellndex const amp void onFirmnessChanged options FirmnessOptions const amp J void ESIGNAL createBust index alWodellndex const amp 1 void onlmplementationChangedi options Implementation ptions const amp 1 void ESIGNAL create amp bsDefi index aModellndex const amp 3 void onTypeChanged options TypeCptions const amp 1 void ESIGNAL createcomDef index altodellndex const amp 1 void onHierarchyChangedi options HierarchyOptions censt amp void ESIGNAL createApiDef index SModellndex co
194. ugh that some code module makes the connection from the signal to the slot Figure 4 4 depicts the signals and slots communication mechanism 20 Class View Signal add Signal changed Class Model Signal remove Class Owner lt Constructor of Owner ae Connect View add Model onAdd e I Connect View remove Model onRemove Slot refresh Figure 4 4 The signals and slots communication mechanism The implemented modules and the whole Kactus2 use signals and slots to improve the modularity of the software For example the message console has two slots one for error messages and one for notifications None of the other modules are aware of the message console but when they emit a notification signal it 1s forwarded to the message console which then prints the message for user to see The message console prints notification and error signals with different outlook to provide a clear distinction between the message types 21 5 MANAGEMENT OF THE LIBRARY The library management module allows user to navigate through the object hierarchy and view dependencies between components The user can search for objects by their VLNV identifiers or object attributes which makes finding the correct object easier The module also checks the validity of the objects and reports if there are objects with invalid or missing data LibraryHandler is the class which implements the interface for librar
195. uld be used to determine the dependencies between the component s files This kind of automation would facilitate packaging of large quantities of legacy IPs to IP XACT format Also the previously mentioned visualizations could be extended to several different elements for example a File dependencies could be visualized to the user in the file set editor b Memory maps and their registers could be visualized to make the editing more intuitive c Channels between bus interfaces within component could show the connections in hardware buses d The bus interface summary could display which ports are mapped to which interfaces Some of these improvements have already been considered and designed to be implemented in the future versions of Kactus2 110 REFERENCES 1 2 3 4 5 6 7 5 9 10 11 Kactus2 Tampere University of Technology Department of Computer Systems WWW accessed on 28 10 2012 Available at http funbase cs tut fi index php Kactus2 Bergamaschi R A Cohn J The A to Z of SoCs IEEE ACM International Conference on Computer Aided Design 10 14 Nov 2002 pp 791 798 Salminen E On Design and Comparison of On Chip Networks Dissertation Tampere 2010 Tampere University of Technology Department of Computer Systems Publication 87 230 p F R Wagner et al Strategies for the integration of hardware and software IP components in embedded systems on chip Integration
196. v VLA const J void SIGNAL createibsDefC vinv YLMN consti J void SIGNAL createcomponent vlnw v EhNSeonst amp 1 void SIGNAL createbesian i vinv LAY const amp J void SIGNAL createsvyDesianti vinv VLAN const amp J void SIGNAL createSystemDesignc vinv SEINS eonst amp J void SIGNAL createcombef vInv YLMAconst J void SIGNAL create amp pibefi vinv sLhNSIeonst amp 3 void SIGNAL removewvLNN vinvs GEistes LS J void SIGNAL exporttemst list Listes LN s const 1 void SIGNAL showeErrarz vin v ENSIeonst amp J void SIGNAL invalidateFilter void SIGNAL refreshDialer void S5LOT onOpenDesiant index amp hacdellndex caonst amp J void S5LOT onOpensSwvyDesignt index atmadellndex const amp 1 void S5LOT onOpensystemDesign index ietadelndex const amp void 5LOT onopenComponenti index Ghtodellndex consts 1 void SLOT onCreateNewComponent index GModellndex canst amp J void 5LOT onCreateNewDesignt index GhModellndex canst amp J void S5LOT onCreateMewvswvyDesignt index Gtadellndex const amp J void S5LOT onCreateNewSystemDesignt index twadellndex const amp J void SLOT onDbeleteltem index ihaodellndex const amp void 5LOT onExpartitem index Ghtadellndex const amp void SLOT onShowkErrarst index ihWadellndex const amp J void S5LOT onOpenBust index GiModellndex const amp 1 void S5LOT onopenComDefl index GMode
197. vide address offsets to the connected slave interfaces e Mirrored master is the mirrored version of master interface f Mirrored system is the mirrored version of system interface g Monitor is an interface that can be used for verification process This interface type gathers data from other interfaces The mirrored interfaces have the same ports as the normal interfaces but the directions of the ports are inverted Table 6 1 depicts the connectivity of different interface modes 47 Table 6 1 The connectivity of interface modes Interface Master Slave System Mirrored Mirrored Mirrored Monitor mode Slave master system Master Mirrored slave Mirrored Yes No No No No mer mmm mi Mirrored No No Yes No No No mm 1 Ro The direct master slave connection can be enabled or disabled in the interfaces bus definition Each monitor interface defines itself what interface modes it can be connected to 48 6 9 1 Bus interface editor The bus interface editor Figure 6 23 contains two tabs the general tab to set the general settings of the interface and the port maps tab which groups ports to the interface General Portmaps Name and description Name ddr2 ctrl p Display Name Description Bus definition Abstraction definition Vendor TUT Vendor TUT Library ip hwp communication Library ip hwp communication Name hibi ip r3 busdef Name hibi ip r3 absdef Version 2 0 Version
198. vidget 3 BuslfPortmapT abt isvalidi booligusryi refresh void setAbsTypel vinv YLMW const amp mode Interfacelode 1 void S5LOT onRemovel void fkeyPressEventi event GkKevEvent 3 void gzhowEventi event GShowEvent 1 void ESIGMAL contentchangedt void ESIGNAL errorMessage msg GString const amp j voidiodusryj ESIGNAL noticeMessage msg OString const amp voidiquery SLOT onRefreshr void SLOT onConnect void SLOT onConnectionkiodeChanger void SLOT onMakeConnectionsi physicals GStringList const amp logicals G StringList const amp 1 void setupLa yout void Figure 6 29 The structure of port map editor BusIfPortmapTab contains three different view model pairs Figure 8 30 displays the different view classes 1n the graphical user interface of the editor 99 General Port maps 1tomany 4 amp Clean up 39 Connect ADDRESS WRITE ENABLE valid out LogicalListView ff PhysListView Logical Logical Logical Physical Physical Physical left right name name left right COMM comm out O 0 READ ENABLE re out 0 0 data out 7 ATA ortMapsView Figure 8 30 The views in port maps editor LogicalListView is connected to the LogicalListModel that provides the logical signals listed in the referenced abstraction definition PhysListView is connected to the PhysListModel which provides the ports listed in the component metadata which correspond to HDL
199. wrapper Mew F Hip hep interface ip swp driver Open XML File Export Delete Item Figure 5 9 Export item The exporting of files to a new location is only possible when the file references within components are made with relative file paths This is why component editor always selects relative paths when adding files to the component metadata 5 2 6 Remove item The VLNV tree view allows the user to remove objects from the library When the object is selected to be removed the handler checks the library if there are other objects in the library that are tightly associated with it and should also be removed This check is done to keep the library as clean as possible and to avoid accidentally leaving unnecessary objects to the library Also when removing a component its files might need to be removed from the disk Tightly associated objects are e In case of hardware buses bus definition and abstraction definition If the other is removed it 1s often unnecessary to preserve the other This is why the tool suggests removing both objects e Hierarchical components contain a design configuration and a design A hierarchical component may contain several different configurations and designs and when removed also all of these are suggested to be removed Before anything is removed the user is presented a dialog to select which library objects and files to remove After clicking Ok these i
200. y good state 103 because some reguirements forced re writing of the editor almost completely When writing the new implementation the new and old reguirements were taken into account to design a better architecture for the editor However in the library management module there are several inter dependencies which make the code hard to maintain and understand The main reason for this has been the introduction of several new object types and their categorization The Kactus2 attributes are not part of the original IP XACT standard 6 and were therefore not planned in the original design of the library management module Also the data to be shown in the library views has changed and one separate search view was rejected after implementation of the library search functionality The code has been restructured during the project to keep the situation under control but at some point it may become necessary to re design the library management module at least the library views part which is shown to the user This would also allow development of some new features to the library management module One issue in the maintainability of the component editor module in the future is the possible new versions of IP XACT Currently the data structures used to view and edit the IP XACT metadata follow the IP XACT 1685 XML structure very tightly If the data structures change this reguires much work also on the component editor All sub editors of the compone
201. y management module of Kactus2 software It does not only manage the components and their designs but also the interface definitions of hardware buses and software objects Chapter 7 depicts the implementation of the library management module The different objects are identified by using the previously mentioned VLNV identifier By creating naming policies for VLNV fields it is possible to unify and clarify the library structure thus keeping the IP blocks easier to manage 8 Moreover our extensions of Chapter 2 3 3 also aid in management Figure 5 1 shows a screen shot of the two library views of library management module 22 Hierarchy VLNV Tree Hierarchy YLNY Tree E TUT aA TUT product a E samos 2012 1 0 TUT product samos 2012 2xnios mjpeg design 1 0 gal TUT product G P samos_2012 design 1 0 i A TUT board 3 altera de2 board 1 0 wae TUT board P altera de2 board design 1 0 TUT chip clock oscillator 1 0 NN PA TUT chip T Vaa cyclone II 1 0 gill TUT chip i cyclone II design 1 0 amp board EF altera de2 board 1 0 g PC H xilinx spartan 3e ra clock oscillator cyclone II davicon dm9000 eth ctrl push buttons E SDRAM 8MB SMSC LAN91C111 SRAM 512KB xilinx spartan xc35500e lobal communication mcapi 1 0 ip application h 263 encoder dct h 263 encoder main A TUT soc 1 0 Wa de2 samos soc 1 0 vopd acdc pred
202. ynthesis Figure 6 19 depicts the reference to other views l mu mmu mmmu mu mu mu mu mu mu Hierarchical view which holds the reference to I the design tw mm B amp mu mm mu Si View structural hierarchy ref a View rtl language VHDL e model name entityName rtl Build commands 9 m view containing the rtl implementation v of the component The design object which instantiates the sub components i s Design object File set I containing the i l top level vhdl I 4 source file l O m mn mm mu mu mu mu Figure 6 19 The references between views and other objects 6 8 Ports editor Ports editor provides a table containing all the ports of a component This editor is used to add remove and edit the ports Figure 6 20 shows the user interface and an example of the matching VHDL code 45 Ports Left Right Mame Direction Width higher lower Type LN Description bound bound l agent full out 6 out std logic IEEE std logic 1164 all std logic IEEE std logic 1164 all std logic IEEE std logic 1164 all std logic vector IEEE std logic 1164 all std logic vector IEEE std logic 1164 all std logic vector IEEE std logic 1164 all std logic vector IEEE std logic 1164 all std logic vector IEEE std logic 1164 all std logic vector IEEE std logic 1164 all std logic IEEE std logic 1164 all agent

Download Pdf Manuals

Related Search

Related Contents

MANUAL DE INSTRUCCIONES  CentreCOM GS900M V2-4PS リリースノート  PROGRAMMABLE CROSSTRAINER USER`S MANUAL  T'nB TABREGBK7  Informe de Progreso Técnico y Financiero Donaciones para la  MANUEL DE L`UTILISATEUR  KitchenAid KEMI300 User's Manual  FX0N-232ADP Installation Manual  catalogo_2015_ita  KJT1680 User`s Manual  

Copyright © All rights reserved. Failed to retrieve file