Large projects like the SKA have an intrinsic complexity due to their scale. In this context, the application of a management design system becomes fundamental. For this purpose the SysML language, a UML customization for engineering applications, has been applied. As far as our work is concerned, we focused on the SKA Low Telescope - Tile Processing Module, designing diagrams at different detail levels. We designed a conceptual model of the TPM, primarily focusing on the main interfaces and the major data flows between product items. Functionalities are derived from use cases and allocated to hardware modules in order to guarantee the project's internal consistency and features. This model has been used both as internal documentation and as job specification, to commit part of the design to external entities

BELLI, Carolina

COMORETTO, Giovanni

OA@INAF - Istituto Nazionale di Astrofisica

2017Publication Year2020-11-12T12:06:19ZAcceptance in OA@INAFSystem Modeling of a large FPGA project: the SKA Tile Processing ModuleTitleBELLI, Carolina; COMORETTO, GiovanniAuthorshttp://hdl.handle.net/20.500.12386/28293HandleMEMORIE DELLA SOCIETA ASTRONOMICA ITALIANAJournal88NumberMem. S.A.It. Vol. 88, 141c© SAIt 2017 Memorie dellaSystem Modeling of a large FPGA project: theSKA Tile Processing ModuleC. Belli and G. ComorettoIstituto Nazionale di Astrofosica – Osservatorio Astrofisico di Arcetri, Largo Enrico Fermi 5,I-50125 Firenze, Italy, e-mail: belli@arcetri.astro.itAbstract. Large projects like the SKA have an intrinsic complexity due to their scale. Inthis context, the application of a management design system becomes fundamental. For thispurpose the SysML language, a UML customization for engineering applications, has been ap-plied. As far as our work is concerned, we focused on the SKA Low Telescope - Tile ProcessingModule, designing diagrams at different detail levels. We designed a conceptual model of theTPM, primarily focusing on the main interfaces and the major data flows between productitems. Functionalities are derived from use cases and allocated to hardware modules in orderto guarantee the project’s internal consistency and features. This model has been used bothas internal documentation and as job specification, to commit part of the design to externalentities.Key words. SKA – Square Kilometre Array – SysML – Systems Modeling Language – TPM– Tile Processing Module – FPGA – Field Programmable Gate Array – SKA Low telescope –LFAA – Low Frequency Aperture Array1. IntroductionThe Square Kilometre Array (SKA) is an in-ternational project to build a radio telescopetens of times more sensitive and hundreds oftimes faster at mapping the sky than todaysbest radio astronomy facilities. It will be builtin part in Australia and in part in South Africa.The SKA is mainly divided into three tele-scopes, Low Telescope, Mid Telescope andSurvey Telescope, according to the frequencyband in which they operate. The constructionof the Survey Telescope is currently deferred(Dewdney et al. 2015).The Low Telescope, or Low FrequencyAperture Array (LFAA) covers the frequencyband from 50 MHz to 350 MHz. LFAA is madeup of 217 stationary antennas with no movingparts. Signals from these antennas are groupedinto 512 stations of 35 m each, which are elec-tronically steered using digital signal process-ing techniques.SKA management requires the applicationof a committed design system to avoid incon-sistencies as much as possible and to iden-tify scientific needs and the main project func-tionalities from the very beginning of the de-velopment cycle. We contributed to and stillworking on the design by applying a SystemsModeling Language, SysML. The tool we usedfor the design is No Magic Cameo SystemsModeler. In particular, we focused on the de-sign of the Tile Processing Module, TPM, ofthe Low Telescope, specifically, we concen-trated on the TPM firmware. A detailed de-scription of TPM is presented in Chap.3.142 Belli: SysML of a large FPGA project: SKA TPMIt is important to note that the main scopeof the application of a System ModellingLanguage is not the direct writing of the VHDLcode, but to provide the programmer of theVHDL code with a description as accurate aspossible of the main functionalities that the al-gorithm to be developed should have.2. System Modeling LanguageThe SysML modeling language has been de-veloped starting from the Unified ModelingLanguage (UML). UML is mainly used forsoftware applications, while SysML gives tothe designer the possibility to apply it to anysystem from an engineering point of view(INCOSE 2006).One of the main advantages in applyingthe SysML is its interdisciplinary approach(Delligatti 2013), it can be applied indiscrim-inately from very small devices to extremelylarge and complex systems, like SKA. Otheradvantages are connected to the project de-velopment cycle: customer requirements andmain project functionalities are identified fromits very beginning; technical and economicalaspects are considered in parallel during thewhole design phase and at different scale level;they can therefore be controlled more effi-ciently.SysML allows the design of several kind ofdiagrams. Each diagram highlights only someparticular aspects of the project (Friedenthal etal. 2011). The model behind the SysML de-scribes the elements and relations in the projectconsistently. Therefore a change in one of thediagrams causes a change in all the connectedones.Considering the model we developed forthe TPM firmware, we used four diagramtypes:– USE CASE DIAGRAM: answers the ques-tion ”how is the system used?”, identifiesthe main actors and how they interact withthe system.– ACTIVITY DIAGRAM: shows what hap-pens when one of the use cases is imple-mented. It can also show alternatives andparallel actions in the work-flow.– BLOCK DEFINITION DIAGRAM: de-scribes the system’s architecture and showsthe hierarchy in terms of blocks and sub-blocks.– INTERNAL BLOCK DIAGRAM: showsthe internal structure and the connectionsbetween blocks in terms of properties andlinks between them.2.1. SysML application to LFAAFig. 1 shows the structural breakdown of SKATelescope. The level of details goes down tothe main components of the tile processingmodule, highlighting the TPM Firmware forwhich we design some of the diagrams. Weconcentrated on those we consider more inter-esting.This design system is modular since all thesmall parts developed by the various consor-tia, related to the part they are working on, canbe combined to form the global SKA SysMLmodel.The Low Telescope model is made up ofseveral diagrams that can go into the level ofdetail desired. Through different types of dia-grams it is possible to highlight different pointsof view of the same aspect and the relationsamong different aspects, in order to better anal-yse them.2.2. SysML Model definitionThe application of SysML to SKA starts fromthe identification of the main requirements.From the scientific point of view, the importantquestions it has to answer are ”What should thesystem do” and ”How should the system oper-ate”. Some of the items considered during thedevelopment cycle are:– the system should operate in the real world:it will encounter problems connected to itsmanagement by people.– the technology used during the designphase: existent technology can be used,which therefore could become outdated atthe end of the construction phase or, onthe contrary, developing technology canBelli: SysML of a large FPGA project: SKA TPM 143Fig. 1. Structural decomposition of SKAbe used whose real potentiality is not atpresent known.– the system should operate within a legisla-tive context and respect the environment.– the design process is iterative since dur-ing the design itself, new requirements andconstraints will arise and should be inte-grated in the overall design of the system.The process in Fig.2 shows the main stepsthat lead to the definition of a SysML model.The starting point for the development of theSysML model is the identification of the mainrequirements that the system should provide.Considering these requirements, the ”USECASE” diagrams have been developed, whichbecomes the starting point for identifying theconstituent elements of the system and the ac-tions that each of these elements is able to per-form. Furthermore, the main characteristics ofthe elements have been defined, consideringthe data they are constituted by and the inter-faces between those data.3. Tile Processing ModuleThe TPM structure is described in Fig.3. TheLow Telescope is made up of an extremelylarge number of LFAA stations, each stationconsists of 256 antennas, divided in 16 tile of16 antennas each (Comoretto 2015).Each Tile is composed of a tile process-ing module (for data processing) which digi-talizes the signal coming from the 16 antennasand processes it (Comoretto 2016). The signalcoming from the 16 antennas, with two polari-sations, is converted to digital by 16 ADC withtwo channels each.Every TPM is made up of two FPGA, in-terconnected between them, each processes thesignal coming from 8 antennas. An externalmemory is connected to each FPGA and eachTPM has an internal control system which in-teracts with both the FPGAs. An Ethernet in-terface is also connected to each FPGA, to ex-change data between boards and to send theprocessed data to the correlator.3.1. Firmware DiagramsFollowing the process described in Chap.2, wepresent the diagrams that have been used. Asanticipated, four different kinds of diagramshave been designed to describe the firmware,the first one is the Use case Diagram, fol-lowed by Actvity Diagrams, Block DefinitionDiagrams and an Internal Block Diagrams.3.1.1. Use Case DiagramThis diagram describes the high level function-alities and their relations to external actors. Theobjective of the diagram in Fig.4 is the produc-tion of a Station Beam for each station, which144 Belli: SysML of a large FPGA project: SKA TPMFig. 2. SysML approach to system designFig. 3. Tile Processing Module Structurerepresents the signal coming from a specificsky region.For the production of the beam it is nec-essary to collect the data from the antennas,correlate these data through a correlator, andcontrol the process through a monitoring andcontrol station.Furthermore, the diagram shows that theaction ”Produce Station Beam” to be per-formed necessitates the implementation of allthe actions indicated in the lower part of thediagram.3.1.2. Activity diagramTo analyse the functionalities in detail, we usedthe activity diagram in Fig.5. The ”ProduceStation Beam” activity is central in the UseCase Diagram in Fig.4. The columns representthe blocks, i.e. the physical objects which willimplement the actions that they were assigned.The rectangles represent the actions, whilethe arrows symbolize the passage of informa-tion, i.e. the activities sequence to be followed.These sequences can be more or less compli-cated, in Fig.5 it is possible to note that theupper left part is more linear, while the lowerright part presents a more convoluted sequenceof actions.3.1.3. Block Definition DiagramThe blocks defined in the activity diagram inFig.5, are summarized and presented in a morehierarchical way in the block definition dia-gram in Fig.6, in the form of blocks and sub-blocks.Belli: SysML of a large FPGA project: SKA TPM 145Fig. 4. Firmware - Use Case DiagramFig. 5. Firmware - Activity DiagramThe “parts” included at the bottom side ofeach block are the related sub-blocks that as-semble the block they are contained in. The di-agram indicates also multiplicity informationand may contain other kinds of relations, suchas use of external blocks.3.1.4. Internal Block DiagramFig.7 shows how the blocks are physically con-nected between them. The diagram highlightsthe relations among blocks, defining the inter-faces they are characterized by, i.e. the rela-tions between blocks. The interfaces in the di-146 Belli: SysML of a large FPGA project: SKA TPMFig. 6. Firmware - Block Definition DiagramFig. 7. Firmware - Internal Block Diagramagram are represented by blocks; however theycan also be described by specific objects.3.2. Station Beamformer DiagramsAll the process described in Par.3.1 canbe repeated in greater detail. The StationBeamformer activity, represented by an ele-ment in Fig.6, is described in Fig.8. This ac-tivity diagram depicts a more convoluted pro-cess: various parts interact with each other, ex-changing information; alternative solutions canbe undertaken depending on the element of theseries of data that is going to be processed.Furthermore, there are also interconnectionswith other diagrams, with information comingfrom, or going to blocks belonging to other di-agrams.The described activity is related to the for-mation of a Station Beam, i.e. the combinedsignal of 256 antennas. The activities in the di-agram in Fig.8 have combined together 16 an-tennas in a tile beam and stored it in a mem-ory. Net interfaces receive information relatedto the pack of data processed and sum it tothe archived data. There is a series of data thatBelli: SysML of a large FPGA project: SKA TPM 147Fig. 8. Station Beamformer - Activity DiagramFig. 9. Station Beamformer - Internal Block Diagramgoes backwards and forwards between mem-ories and net interfaces. The Internal BlockDiagram in Fig.9 shows the interfaces and theconnections between blocks identified in the148 Belli: SysML of a large FPGA project: SKA TPMactivity diagram of Fig.8; in this case we canalso note bi-directional connections. It is possi-ble to go down to even greater detail, analysingthe composition of the blocks identified in thislatest level, defining the interfaces that charac-terise them. At this latest level of detail, all theinformation necessary for the composition ofthe VHDL code is available.The code can also include information oncosts and consumption of each single module;in this way, when the codes of all the modulesare ready, it is possible to have information onthe overall cost and consumption of the system.4. ConclusionsConsidering the complexity of the SKAproject, a designing management system isimportant and necessary for its development.There are various computer applications ableto produce SysML diagrams; in this case weused No Magic Cameo Systems Modeler.We developed a system of diagrams for thedescription of the functionalities and behaviourof the TPM Firmware. We started from the def-inition of the Use Case Diagram; we identifiedthe actions to be undertaken that are part ofthe system, the blocks that will perform theseactions and their behaviour. The diagrams pre-sented in the current paper represent a selectionof those developed to describe the project. Thediagram system developed includes the mainactors and the activities which are part of andact in the project. The detail level until whichthe iterative process of designing diagrams hasbeen carried out is the one that allows a pro-grammer, even from an external company andtherefore with a restricted knowledge of theproject, to write the VHDL code of the singlemodules.As highlighted before, the objective of thedevelopment of a SysML model is not the di-rect production of the code from the diagramsdesigned, but provides all the necessary infor-mation and detailed description of the func-tionality that the VHDL code shall supply.Acknowledgements. This work is supported by theItalian participation to the SKA project.ReferencesComoretto, G. 2015, LFAA Tile Beamformerstructure, INAF - Osservatorio Astrofisico diArcetri, Internal Report n. 2/2015Comoretto, G. 2017, MmSAI, 88, 154Delligatti, L. 2013, SysML Distilled: A BriefGuide to the Systems Modeling Language(Pearson Education, New Jersey)Dewdney, P., et al. 2015, SKA1System Baseline V2 Description,https://www.skatelescope.org/wp-content/uploads/2014/03/SKA-TEL-SKO-0000308SKA1 System Baseline v2DescriptionRev01-part-1-signed.pdfFriedenthal, S., et al. 2011, A PracticalGuide to SysML: The Systems ModelingLanguage (Morgan Kaufmann, Amsterdam)INCOSE 2006, Systems EngineeringHandbook

System Modeling of a large FPGA project: the SKA Tile Processing Module

https://openaccess.inaf.it/bitstream/20.500.12386/28293/1/2017MmSAI..88..141B.pdf

System Modeling of a large FPGA project: the SKA Tile Processing Module

Abstract

Similar works

Full text

Available Versions

OA@INAF - Istituto Nazionale di Astrofisica