DOOCS environment for FPGA-based cavity control system and
Contents
1. D matlab reg D float z nterface 7 Dumrmnlat Figure 8 Simplified UML scheme of D matlab reg class 6 2 LIBRARIES As a consequence of the modular approach to the developed DOOCS server a set of libraries has been created Some of them are exactly the same as in the Matlab version of the control software All libraries are directly loaded by the program This means that there is no need to copy these libraries into the directories accessible through LD LIBRARY PATH or to modify this environment variable The libraries are loaded from the current server directory Figure 9 presents dependencies between all used libraries libsimcon so libvme so Figure 9 Dependency of libraries used in SIMCON server Only two libraries are directly loaded by the server These libraries implement two main interfaces described in chapter 5 libsimcon so is a library created from the compiled Matlab code For the SIMCON software any Matlab 6 x version can be used to compile the M functions For the compilation the following option were used mee t L C W lib libsimcon T link lib fool foo2 foo3 where fool foo2 foo3 are the parameters As a product of this compilation a shared library is being created It contains all functions used in the algorithm but only a few of them are called by the DOOCS server libmatcore this library is the wrapper for libsimcon library It provides the main DOOCS MATLAB interfac2. In the first solution every Matlab routine can use inside its body functions to access the hardware Since the Matlab scripts cannot be run in the multithreaded way there is a guarantee that one Matlab script will not be interrupted by another script during the running of the procedure requiring multiple accesses to the device In the DOOCS solution there is an arbitrary unit through which all calls to the hardware should be done The compiled Matlab function which is put into the DOOCS server and contains direct calls to the device is not thread save It can be called by many clients at the same time so many instances of this function will be run at the same time and cause the controller algorithm to crash This points to the first requirement the Matlab routines cannot access the hardware inside the function body Any data should be exchange through the function input and output parameters cibis DOOCS server gt Workspace vu 1 pre ud VI np Ie x Matlab Matlab routine routine Figure 4 Matlab to hardware communication model versus DOOCS to hardware communication model An important issue 1s also the lack of the Matlab workspace inside the DOOCS server The compiled functions cannot use the global variables The requirements described above can cause some modification in the Matlab function source code however they have no influence on the algorithm itself 5 INTERFACES AND MODULES The DOOCS server is meant to be used as a
3. PES RAG Wr ore 1 LE INTRODUCTION wisscoscscevscucetnwsseisassatecsssscetuctasses sotessiuestarsducabensetsesseseceatveedes 3 2 ALGORITHMS DEVELOPMENT PROCESS e eeeeeeeeee 3 3 MATLAB BASED CONTROL ENVIRONMENT eere 4 4 DOOCS BASED CONTROL ENVIRONMENT cere 5 5 INTERFACES AND MODULES eerie osea appo eee aaa nano eoe eoe aaa Pr reae aee eere se 6 5 MATLAB DOOCS INTERFACE eere eene ee eere eerte noe 7 5 2 DOOCS HARDWARE INTERFACE ee eee e eere eene 9 06 DOOCS IMPLEMENTATIQN eiisvos Cora ee aeree een ea ao Ex ese eo ERE P Eo eia Yo Eee eee ae 9 S EM DA LS E Db PES mnt 9 0 2 LIBRARIES C 11 ABS MENU LSU Ol Lon N 12 7 APPLICATION SIMULATOR AND CONTROLLEXR 13 Sa SUMMARY zeeer 17 9 ACKNOWLEDGEMEN I teseeeeo oe tee eH YN e e Eau EE PES erra eo Ya ae Sn e eto ees esp p 18 IU REBRERENCES ue ori ERE REEREESE ee RE EET TRE Ir REN I ree E EU 18 1 INTRODUCTION The FPGA technology offers a possibility to build a control and automation hardware with the level of complexity flexibility and performance far exceeding standard solutions i e based on the DSP processors The manufacturers put more and more dedicated modules into the FPGA chips 1 e complete fixed point processors with a fully functional operation system This not only increases the usability of the hardware but also increases t
4. platform for operation and developing Therefore based on the conclusions drawn in the previous chapter a number of modules and interfaces have been defined in the server in order to adapt the existing libraries into the project as well as to provide necessary functionality for the compiled algorithms Figure 5 presents the overall scheme of the modules and interfaces designed for the SIMCON server Two main interfaces have been defined one for the communication between the compiled Matlab functions and the DOOCS and the second for communication between DOOCS and the hardware Matcore wrapper MATLAB DOOCS server Channel bridge library to EM Matcore library DOOCS hardware interface interface Figure 5 Main interfaces and modules used in SIMCON server 5 1 MATLAB DOOCS INTERFACE The compiled Matlab functions are available for the DOOCS as a shared library which was called the Matcore It is assumed that one library contains all functions required for the specific algorithm and only for that one algorithm For many algorithms separate libraries should be compiled According to the requirements defined in the previous chapter all connections to the hardware are performed through the DOOCS server core routines Therefore a special interface for all Matlab functions used by the DOOCS has been defined There are three types of functions which can be used by the DOOCS e Input Initialization function This function must be incl
5. 0 0 0 20000 20000 det04 det04 6e 04 Be 04 Be 4 Be 4 1e 05 1e 05 1 2e 05 1 2e 05 1 4e 05 1 4e 05 sil ie mus die 1000 1500 2000 2500 1000 1500 2000 2500 Res 16 ns 0 Cus Res 16 Be 0 us TEST DOOCS LOCRLHOST 8883 CONTROLLER CTRL DET de ses TEST DOOCS LOCALHOST_8889 CONTROLLER CTRL_DET_PH HV 1 5e 05 250 200 150 100 50 s 90 E 100 I 200 en 1 Be 05 300 0 2500 Res 1 Buf 0 us Res 1 Buf 0 Name TEST DOOCS LOCALHOST 8888 CONTROLLER CTRL DET Q Figure 13 I and Q component on the input of the controller 15 FFORWARD TEST DOOCS LOCALHOST_8889 CONTROLLER TEST DODCS LOCRLHOST S883 COMTR LLERAFF I E 0 TEST DDDOCSA LOCRLHOST S883 CONTR LLERZFF beth 3e d 2e d 10000 ue 10000 eg d ag d detid etid etig e d 8e 4 1000 1500 20 2000 500 1000 1500 2000 2500 Res 1 Bur 0 TEST JO0CSLOCALHOST_S38e9 CONTROLLER FF_LA degrees TEST D00CS LUCRLHOUST 8883 7 LONTR LLERAFF PH Bu BO 40 0 20 E 40 10000 amp 4 0 E 100 10000 SN 2e 04 Rs ooo Loo 1500 2000 1000 1500 eno E Figure 14 FeedForward tables simulator panel TEST DOOCS LOCALHOST _8889 SIMCON Predetuning Quality factor vector L L G i bb bebo Ss Cavity resonance 1300000000 TTT ETT TET TTT Characteristic Mechanical Frequency resonan
6. TESLA Report 2005 13 DOOCS environment for FPGA based cavity control system and control algorithms development Piotr Pucyk Waldemar Koprek Pawel Kaleta Jaros aw Szewinski Krzysztof T Pozniak Tomasz Czarski Ryszard S Romaniuk Warsaw ELHEP Group Institute of Electronic Systems ISE Warsaw University of Technology Nowowiejska 15 19 00 665 Warsaw Poland photonics g ise pw edu pl ABSTRACT The paper describes the concept and realization of the DOOCS control software for FPGA based TESLA cavity controller and simulator SIMCON It bases on universal software components created for laboratory purposes and used in MATLAB based control environment These modules have been recently adapted to the DOOCS environment to ensure a unified software to hardware communication model The presented solution can be also used as a general platform for control algorithms development The proposed interfaces between MATLAB and DOOCS modules allow to check the developed algorithm in the operation environment before implementation in the FPGA As the examples two systems have been presented Keywords Distributed Object Oriented Control System DOOCS cavity simulator cavity controller SIMCON Matlab FPGA VHDL LLRF control system control software environment DOOCS specifics for FPGA systems Corresponding author ppucyk ntmail desy de DOOCS environment for FPGA based cavity control system and control algorithms development CONTENTS
7. ansfer can represent basic numerical and char types in the network The server is a skeleton which should be filled by the appropriate routines This chapter describes specific data types used for the integration of the project with the DOOCS It also contains a detailed information concerning the modules and interfaces implementation presented in the previous chapter 6 1 DATA TYPES In the IID format IID there are three main data types BITS WORD and AREA According to these types the appropriate DOOCS equivalents have been created Every BITS WORD or AREA can be accessible through the network using the DOOCS D classes e D simcon bits is the DOOCS equivalent for BITS type in the II This class is derived from D int class e D simcon reg is the DOOCS equivalent for WORD type in the II This class is derived from D int class e D simcon area is the DOOCS equivalent for AREA component in the II It derives from D spectrum class e D simcon complexarea is a special class dedicated for constructing the amplitude and phase plots from separate I and Q components which are mostly D simcon area objects It derives from D spectrum class and uses two D simcon area object to calculate the amplitude or phase Every class gets in constructor the mnemonic name of the component from II and a pointer to the Xidd bridge object described further in this chapter which provides access to the hardware The methods value and set value have been re
8. ator and free electron laser Proceedings of SPIE Bellingham WA USA Vol 5484 2004 pp 88 98 T Czarski R S Romaniuk K T Pozniak S Simrock Cavity control system optimization methods for single cavity driving and envelope detection Proceedings of SPIE Bellingham WA USA Vol 5484 2004 pp 99 110 T Czarski R S Romaniuk K T Pozniak S Simrock TESLA cavity modeling and digital implementation with FPGA technology solution for control system development Proceedings of SPIE Bellingham WA USA Vol 5484 2004 pp 111 129 http www desy de http sun com 18
9. be the best choice for near future solutions It is much faster than commonly used DSP systems easier to configure and extend Also the software which controls such devices must be more flexible Thus the design emphasis and amount of effort goes from the hardware to the software The presented solution is an initial proposal for adapting the existing control system to a new generation of FPGA based hardware The DOOCS will for sure be used as the main software environment for operation and the Matlab environment will for sure be the main development platform It is essential to combine these two frameworks into one unified and flexible environment in order to follow the FPGA technology The described software uses the same components as in the Matlab control system It provides all needed data types taken from the IID in the DOOCS manner The presented software project is now in the extremely active testing stage The final version of the SIMCON is planned to be finished after detailed tests in the operation environment in the TTF and FNAL The future versions of presented solution will control 8 and more channel controller and simulator and will use newer version 7 x Matlab compiled functions Also a II DOOCS diagnostic module is being developed in order to provides additional features needed for Matlab and VHDL algorithms development 17 9 ACKNOWLEDGEMENT We acknowledge the support of the European Community Research Infrastructure Activi
10. ce resistance Loaded quality 1 3e 06 factor Cavity input LFI constans vector delau Cavity trigger delau Beam amplitude Beam ztart Beam stop Figure 15 DDD panel of SIMCON simulator server 16 1 TEST DOOCS LOCALHOST_8889 SIMCON CAV_MOD_1 1 TEST DOOCS LOCALHOST_8889 SIMCON CAY_MOD_2 1 TEST DODCS LOCRLHOST 8883 8 IMCON CRV MOD 3 0 8000 2000 2000 6000 4000 i 4000 2000 2000 6000 o 2000 E 8000 4000 4000 le 04 6000 6000 1 2e 04 8000 8000 1 4e 04 adus 1 2e 04 T ai 1 4e 04 1 8e 04 m 1 Be 04 1 2e 04 0 500 1000 1500 2000 2500 0 500 1000 1500 2000 2500 0 500 1000 1500 2000 2500 Res 1 Buf 0 1 Res 1 Buf 0 Res 1 Buf 0 1 TEST DOOCS LOCALHOST_8889 SIMCON CAV_MOD_1D 1 TEST DOOCS LOCALHOST_8889 SIMCON CAV_MOD_2D 1 TEST DOOCS LOCALHOST_8889 SIMCON CAY_MOD_3D 6000 1 5e 04 3 5e 04 4000 Q4 1 26404 xdi 2000 1e 04 2 5e 04 0 8000 2e 04 2000 Me 4000 1 5e 04 4000 2000 6000 0 1e 04 8000 2000 IE 4000 d SESH 6000 i 1 2e 04 8000 5000 1 4e 04 lew 1 2e 04 E 1e 04 es 1 4e 04 1 8e 04 1 Be 04 1 5e 04 0 500 1000 1500 2000 2500 0 500 1000 1500 2000 2500 0 500 1000 1500 2000 2500 Res 1 Buf 0 Res 1 Buf 0 Res 1 Buf 0 Figure 16 Plots of the cavity modes calculated inside SIMCON 8 SUMMARY The FPGA based electronics for the LLRF control system seems to
11. de and phase of the signal calculated from the I and Q components The current version of these plots 1s scaled in samples The final version will be scaled in MV In figures 15 and 16 one can see a control panel and the example readout from the SIMCON simulator server The simulator server is running in the continues mode That means every change of any input parameter is automatically applied in the server 14 m OUTPUT TEST DOOCS LOCALHOST 8889 CONTROLLER samples TEST DODCS LOCRLHOST S889 CONTROLLER CTRL I samples TEST DOUCS LOCALHOST amp ee3 CONTROLLER CTRL Q 1 6e 5 1 6e 05 1 2e 05 1 2e 05 Le 05 1e 5 Be d Bed be 4 Rerig detOd detid 20000 20000 Due ur 2000A 20000 detid detid be 4 be 4 Be d Be 4 EE 1e 05 sles 1 2e 05 zl a 1 6e 05 1000 1500 2000 2500 ie 1000 1500 2000 Res 1 2 Res 1 Buf 0 CMY TEST DO0CS LOCALHOST_S663 CONTROLLER CTRL_A degrees TEST DOOCSLOCALHOST_8889CONTROLLER CTRL_PH 1 6e 05 300 1 2e 05 1e 05 200 Bed 150 Be 4 100 dertid 20000 20 o 20000 4de 04 ett Be 04 ie 05 i 2e 05 i E nas 1000 1500 2000 1500 U Plot Viro mi Figure 12 I and Q signal on the output of the controller samples TEST DOOCS LOCALHOST_8889 CONTROLLER CTRL_DET_I samples TEST DOOCS LOCALHOST_8889 CONTROLLER CTRL_DET_Q 1 5e 05 1 6e 05 1 26 05 1 2e 05 1e 05 1e 05 8e 04 Be 04 5e 04 5e 04 4e 04 de 04 20000 2000
12. e described in chapter 5 1 It also provides a mechanism that allows to block the access to the object The DOOCS routines are blocking the access to the internal libmatcore tables and 11 structures to ensure the data integrity Different threads in the server could access the libmatcore tables in the same time This would cause the failure of the whole controller Libmatcore separates also the DOOCS environment from the Matlab environment In compiled Matlab functions a sophisticated interface for communication and data wrapping must be applied The DOOCS Matlab interface hides all Matlab specific data types so that the DOOCS core server source files and Makefile remain unchanged and can be compiled without access to the Matlab libraries libvme is a small library that provides direct access to the hardware It is based on the original DOOCS VME library but has different communication interface It reads the configuration file located in the current directory named vme conf This file contains three lines e VME based address written in hex mode This is the base address of the SIMCON memory space mapped in the VME e The size of the space mapped in the VME e The path to the VME device In this case we are using dev 24d32 which means that address has 24 bits and data are 32 bit The interface that libvme provides is very simple There are two functions one for reading and second one for writing a 32 bit word under the given address The importa
13. ed T BEL i oR iios te 7 5 channel va Au SIMCON board In the scheme presented above Matlab routines can write and read from the hardware specified registers bits and memory areas using read write functions and mnemonics names for elements identification Inside the toolbox there is a library responsible for translating mnemonics names to physical addresses of the elements in the FPGA using IID Internal Interface Description 4 5 After translation another library provides data exchange with the device through physical interface The important thing in this solution is that writing code in Matlab one does not need to care about the proper data addressing or handle the protocol of the physical interface between Matlab and hardware All is hidden inside toolbox Another important solution is the unified interface between II Engine and Channel library For II Engine library the real communication channel is not known All implementation issues are again hidden inside channel library Using unified channel interface one can implement many different communication channels like EPP VME Ethernet optical link USB etc Both libraries have been written in C using non platform specific functions so they can run on different architectures under different operation systems Matlab based control system created for laboratory purposes is used during the first stage of development Since the DOOCS environment is the logical consequent of the Ma
14. he extent of control of the device Even the most sophisticated hardware must be controlled by appropriate software which is flexible enough and can be changed after some time For example the simplicity of changing the FPGA configuration requires very flexible software solution for such a system The DOOCS Distributed Object Oriented Control System 1 used in the TESLA experiment for the remote control of the hardware was designed before the FPGA technology started to be used in the control systems It consists of a set of libraries and interfaces that allow to access hardware and create server and client applications for remote control of the device The general idea is to represent every device as a server seen in the S Ae network Such a server is communicating L ASA HARDWARE directly with the hardware and provides EN m EN real device properties which correspond to the hardware z device properties The client GUI application is in this case a virtual operation panel for this device One can run the client application on DOOCS client API virtual operator panel Device parameters are available through the network Server sets the real device parameters through physical bus i e VME Figure 1 Scheme of hardware control the local computer and remotely control through the DOOCS hardware placed in the linac The DOOCS was mainly designed to control the existing hardware Therefore its a
15. in the operation environment The SIMCON controller server DDD panel has been presented in figure 11 It was meant to have the same functionality as its Matlab equivalent Therefore the panel has the same input parameters The important thing 1s that this version of the server works in the step mode That means every change of any parameter should be confirm by pushing the INIT button which triggers the appropriate functions to calculate and reload the tables The RECON button is used to perform a single step of adaptive FeedForward algorithm controller TEST DOOCS LOCALHOST 8389 CONTROLLER CONTROLLER INPUT CONTROLLER OUTPUT SETPOINT FEEDFORWARD Text left Figure 11 The DDD panel for SIMCON controller server Two additional buttons intern mode and extern mode are used to set the controller in the two possible Stages e Internal mode controller drives cavity simulator inside the FPGA No external inputs are needed e External mode controller drives the real cavity All input signal including clock and trigger must be provided In practice during the operation of the SIMCON system the external mode is used Internal mode is used for debugging purposes On the DOOCS control panel there are 4 buttons which run windows with plots These plots have been presented in figures below Every type of signal is presented in 4 plots Two upper ones are I and Q components of the signal Two bottom plots represent amplitu
16. nly for reading Thus the internal functions use only Y parameter not Y and U The wrapper provides also the thread safety to the Matcore library During the calculations all the resources shared by functions are blocked till the running function returns 5 2 DOOCS HARDWARE INTERFACE The DOOCS server uses the same compiled versions of IID 5 and channel libraries which are used in the Matlab based control system The detailed description of these libraries can be found in 4 However there has been a special wrapper library used in order to adapt the non multithreaded libraries to the multithreaded DOOCS server 6 DOOCS IMPLEMENTATION The DOOCS server is in principle a skeleton of application which has to be filled by the programmer with appropriate routines and data structures It should ensure the proper communication with the hardware and provide the full functionality of the device to the user The DOOCS server for the SIMCON is an application in which different environments and technologies meet together From one side there are compiled Matlab functions to C language which use specific data types On the other side there 1s an engine for communication with the hardware which uses mnemonics names and several data types In addition the DOOCS itself contains specific data structures All these different environments must work together in a single application The DOOCS provides data structures which perform basic RPC network tr
17. nt thing about this library is that it is taken from the Matlab control software without any changes libxiid This library is also taken from the Matlab control environment This library translates the mnemonic names into the addresses in the VME space and performs all necessary read write operations using ibvme library This library provides interface to the operations which must be thread safe Therfore inside the server it is wrapped with a class which provides the interface for thread safety The library reads two configuration files e channel txt contains the path to the channel library In this case the channel is VME and the library is called ibvme e source txt contains the filenames of the IID files with description of the FPGA memory space 6 3 SERVER The detailed common DOOCS server structure has been described in DOOCS manual MANUAL The SIMCON server is only the extension of the template server used in many other server applications in the TTF This subchapter describes only the SIMCON related issues The main server class EqFct simconserver uses DummyMat class to generate all Matlab specific input parameters All these parameters are of type D matlab reg The server object during initialization calls INPUT INIT function from ibmatcore library It returns the structure whose fieldnames are the names of input parameters to the controller Based on that it automatically creates a list of properties for the server In addi
18. nted above unify the way the DOOCS communicates with the Matlab The communication sequence using the described interface has been presented in figure 6 During the initialization of the wrapper library the JVPUT INIT function is called It returns the structure needed for creating in the server a list of properties available in the network An instance of the matrix A is created in the wrapper The user can access its fields through the DOOCS Next the INIT function is called It uses A structure filled by the user to calculate the U Y and W parameters The first two variables are loaded into the FPGA W parameter is the local workspace for the compiled functions It is not accessible by the DOOCS server The internal algorithm functions use variable Y and structure W as the input and output parameters The wrapper routines take care of updating the temporary tables only when the functions are going to be called and download results of the calculation back to the FPGA immediately Matcore library Matcore wrapper DOOCS server INPUT INIT Download to FPGA Figure 6 The sequence of the library functions calls The wrapper library stores temporary tables shared by all functions The Y and U parameters correspond to appropriate parameters in the FPGA so they are fixed to the actual VHDL implementation of the controller In practice the Y is a set of control tables in the current SIMCON 12 tables from which 8 are read write tables and 4 are o
19. on testing operation MATLAB DOOCS server Figure 2 Algorithm development process e Algorithm inventing In this stage the MATLAB is used as a powerful tool for building mathematical formulas The mathematical propriety of the algorithm is being checked One can use the offline test signal or access the hardware using dedicated tools to simulate the flow of the algorithm e Testing stage is the place where the algorithms are put into the operation environment The Matlab functions are compiled into the C functions These ones are next loaded as a library into the server During this stage one can test the algorithms with a real signal and measure the influence of the latency of the DOOCS system on the performance of the algorithm Based on these tests one can decide which algorithm parts should be implemented in the FPGA and which can remain in the software The testing stage allows starting machine operation with algorithms running with a decreased speed This lets the developers to check step by step the algorithm and move time critical parts into the FPGA without any meaningful influence on the user interface e Operation stage is the stage of developing when all algorithms have been tested and the system is running with a desired performance In this stage one can perform further investigations on the possible algorithms improvement The presented scheme shows that the DOOCS server for the SIMCON should not only be the control softwa
20. rchitecture seems to be not sufficient for controlling advanced device like FPGA based cavity controller and simulator However using some external libraries it is possible to achieve full control of the device through the DOOCS This article describes the conception and realization of the DOOCS servers and clients for FPGA based cavity field controller and cavity simulator called further in this paper as the SIMCON SIMulator CONtroller board This particular software was prepared for a single channel SIMCON ver 2 0 and 2 1 but is flexible enough to be adapted efficiently for multi channel SIMCON operation available from the ver 3 0 2 ALGORITHMS DEVELOPMENT PROCESS The development scheme applied in the SIMCON differs from the methodology used in other projects which do not base on the on the FPGA technology One of the main problems during the algorithm development is the difficulty of implementing the mathematical routines in VHDL code The VHDL is not a programming language but the language used for defining hardware architecture Therefore there is no simple way to translate the algorithms created in the MATLAB to VHDL Every complex algorithm must be tested before the implementation The changes in VHDL and FPGA in most cases are more complicated than the changes in Matlab or other programming language Due to this the SIMCON and other FPGA based control board development process can be divided into three main stages fig 2 creati
21. re but also the environment dedicated to algorithms development Thus there exists a laboratory control system dedicated for creating and testing the algorithms Some of its modules have been used in the DOOCS control system The next paragraph describes the MATLAB based control software 3 MATLAB BASED CONTROL ENVIRONMENT SIMCON board is only one of the many FPGA based projects being realized by Warsaw ELHEP group 2 3 During hardware and software development process there is a strong need to have very flexible tool useful for testing new VHDL code applied in the chip and debugging whole board and its subsystems Such a tool should have easy and powerful interface through which one can generate testing data access hardware perform tests collect and process results The speed of the system is not critical in this case For this purpose a dedicated tool 4 for Matlab has been developed Matlab itself provides powerful mathematical language In addition a special toolbox has been created to ensure communication with the hardware The most important feature of that system is modular approach to software hardware communication problem The very simplified idea of the solution has been presented in the figure 3 Matlab routines Read write functions gt Matlab toolbox II Engine library Unified interface Channel library Figure 3 The scheme of MATLAB based control system Communication e Bev ent
22. tion the server contains a set of D simcon area and D simcon complexarea classes used for the plots A simplified diagram of the server classes is presented in figure 10 12 EqgF ct id bridge D matlab reg d 4 EqgFct_simconsenrer Dummnvyl at D zimcon area A T T A D zimcon caomplexarea D zimcon reg D zimcon bits Figure 10 Simplified UML diagram of additional non DOOCS classes used in the server In the current version of the server all updates of the input values are made in the step mode This means that after changing any input parameter this change must be confirmed by pressing a special button on the panel see next chapter This was made for the testing purposes of the current server and will be changed in the future To provide this feature a set of classes has been created based on D int class The integer property reacts to the change of its value and triggers the update procedure 7 APPLICATION SIMULATOR AND CONTROLLER The concept presented in the previous chapters has been used to create two server applications One is dedicated for simulator part of the SIMCON and the second one for controller part of the SIMCON It has to be mentioned that both serves are in the very development stage and the description presented below should be considered as an example of the implementation of the concept presented in the paper rather than complete application These applications are to be tested
23. tlab environment it has been decided to use in DOOCS the same low level communication model as in the Matlab system 4 DOOCS BASED CONTROL ENVIRONMENT The DOOCS system in the principle is the skeleton which should be filled by the programmer In case of the SIMCON server the main elements of the server are communication libraries and Matlab algorithms As it was mentioned in the previous chapter the idea was to move as much of the logic functions and modules form the Matlab environment as possible Some of these modules have been ported without any changes some of them required modifications especially Matlab code This chapter presents the main issues concerning the differences between these two environments Moving the algorithms from the Matlab environment into the DOOCS is not only the matter of compiling the Matlab code These two environments have different data types dataflow and the architecture The DOOCS server unlike the Matlab from the user s point of view is a multithreaded application This means that many clients can at the same time access the hardware Since there is only one physical bus for the hardware the communication server must contain an arbitrary unit for the FPGA access In addition since the most of logical operations in the FPGA need a sequence of hardware accesses there must be a mechanism for blocking the access to the device Figure 4 presents the model of hardware access used in the Matlab and DOOCS
24. ty under the FP6 Structuring the European Research Area program CARE contract number RII3 CT 2003 506395 NO B 10 11 10 REFERENCES http doocs desy de Krzysztof T Pozniak Tomasz Czarski Waldemar Koprek Ryszard S Romaniuk Institute of Electronic Systems Warsaw University of Technology ELHEP Group DSP Integrated Parameterized FPGA Based Cavity Simulator amp Controller for VUV FEL SC Cavity SIMCON version 2 1 re 1 02 2005 User s Manual TESLA Report 2005 02 Krzysztof T Pozniak Ryszard S Romaniuk Institute of Electronic Systems Warsaw University of Technology ELHEP Group Krzysztof Kierzkowski Institute of Experimental Physics Warsaw Modular amp Reconfigurable Common PCB Platform of FPGA Based LLRF Control System for TESLA Test Facility TESLA Report 2005 04 Waldemar Koprek Pawel Kaleta Jaroslaw Szewinski Krzysztof T Pozniak Tomasz Czarski Ryszard S Romaniuk Institute of Electronic Systems Warsaw University of Technology Software Layer for FPGA Based TESLA Cavity Control System Part I TESLA Report 2004 10 K T Pozniak M Bartoszek M Pietrusinski Internal interface for RPC muon trigger electronics at CMS experiment Proceedings of SPIE Bellingham WA USA Vol 5484 2004 pp 269 282 http www mathworks com T Czarski R S Romaniuk K T Pozniak S Simrock Cavity digital control testing system by Simulink step operation method for TESLA linear acceler
25. uded inside the Matcore library It is needed for initialization of all algorithm input parameters which should be available through the DOOCS A INPUT INIT It is necessary to name this function as IVPUT INIT The output parameter A is a Matlab structure with scalar fields and fieldnames corresponding to the names of input parameters used in the algorithm especially in Input function The DOOCS is using names of these fields to generate the appropriate data structures in the server called first order parameters e Input function This function is used to perform the algorithm calculations which are related only with the user input parameters The input parameter is the Matlab structure from the function mentioned above which contains input parameters for the algorithm As an output this function returns a vector of scalars U and a table Y These variables are so called second order parameters which are data ready to load into the FPGA W is the workspace a structure which can be used by the algorithm to store some temporary data described further in the text This structure is shared by all functions in the library and can be freely modified U Y W FOO A e Internal algorithm function is called by the server and operates on the real data red from the FPGA As an output the function returns table Y with data ready to load into the FPGA The function also has access to the workspace W Y W FOO Y W The interfaces prese
26. written so that they access the given FPGA memory component using Xiid bridge The general scheme of D simcon classes has been presented in the figure 7 D zimcon reg 4 D zimcon bits D simcan area D int iid bridge EM a spectrum D zimeaen ceomplexarea Figure 7 General UML scheme of D simcon classes used in SIMCON server D simcon reg and D simcon bits classes use a single command access to the hardware they are not thread safe To update its value table the D simcon area needs to perform the readout from the FPGA This requires a consistent set of operations on the FPGA bits and registers To ensure the thread safety the D simcon area locks the access to the hardware for the time needed to perform a complete readout procedure The current D simcon complexarea uses the actual data taken from two D simcon area objects It does not perform any independent readouts from the FPGA Therefore one must take care of updating the I and Q components of the signal in order to have the proper amplitude and phase plots This can be achieved for example by putting all 4 plots I Q amplitude and phase in the same windows In addition one more DOOCS data type has been created It is responsible for providing all algorithm input parameters first order parameters in the network D matlab reg derives from the DOOCS D float class Every field from the Maltab INIT structure is represented in the DOOCS as the D matlab reg class
Download Pdf Manuals
Related Search