Development, debugging and test of embedded systems get more and more complex due to increasing size and complexity of implementations. To dominate this complexity, nowadays designs are often based on models. However, while the design is on model level, the monitoring and debugging are still either on signal or on code level. This paper presents a continuous concept that allows monitoring and realtime recording of executions on recon gurable hardware at model level. Besides developed hardware debugger modules, a development environment has been integrated. It allows on model level generation of the implementation, control of the recording and monitoring at runtime and visualization of the execution. An algorithm, running in the background, maps acquired data from the hardware to the model and commands from the model-based development environment to the hardware. The method is demonstrated using the example of statechart diagram monitoring.
In software and hardware development costs, time-to-market and quality are
often contradicting to each other, which increase with the complexity of the
system. The complexity arises mainly by the increasing demands in terms of
functionality, energy e ciency and the ongoing integration on hardware. This
a ects especially the possibilities to monitor embedded systems at runtime. To
dominate the increasing complexity, more and more abstract approaches for
the development of embedded systems come up. One option is model-based
development using graphical languages, for example Uni ed Modeling Language
(UML)[
To preserve the bene ts of exible development and simultaneously achieve high performance, recon gurable hardware devices (e.g. Field Programmable Gate Arrays - FPGAs) are deployed. These o er the possibilities to implement algorithms in hardware and parallel execution, to gain more computing power. However, developing recon gurable systems is more complex, especially in the area of debugging and testing with regard to real-time conditions.
The challenge is to combine these domains into a continuous model-based
development process that allows debugging and monitoring on model level [
In the FPGA development process simulation[
For debugging FPGAs [
All discussed debuggers work and get controlled during runtime on signal or code level, i.e. breakpoints or trigger conditions for recording are set with respect to the signals in the design. This it is not suitable for a model-based design process, because the developer designs the system on model level and does not know about signals or source code, as this is mostly automatically generated according to the developed model. 2.3
Debugging on model level for embedded systems is possible, but not widely used.
The commercial software Matlab[
A general approach for model-based debugging on embedded systems has
been presented in [
Model-based Design Flow for Debugging The development of recon gurable systems is heading towards a model-based design ow. Hence also monitoring, debugging and control of the debugging needs to take place on model level. A continuous concept for debugging on model level is depicted in Figure 1.
The ow shows on the left side the design and transformation, in the middle bottom the execution and on the right side the mapping and debugging. In the middle, a direct connection for model-based control is added. In the beginning, the user designs his system using di erent models. In this context, the models
VHDL-Code ARCHISTIEGCNTAULREisf_Csma_r_SFdoHDmL:OtFypCear__isdo_Cmianr_atdoedm;IS
SIGNAL PedFinished : std_logic; BEGINSIGNAL is_Car_dom_next : type_is_Car_dom; initialize_Car_dom : PROCESS (clk, reset) BEGIN is_Lights <= IN_NO_ACTIVE_CHILD;
IF reset = '1' THEN
y1_reg <= to_unsigned(0, 3); ELSIF clk'EVENT AND clk = '1' THEN y1_reg <= ‘1’; Code generation
Source Code Implementation
Control
Monitoring /
Debugging
ow for model-based monitoring and control [
During the whole process, the user is working on model level, the intermediate steps are performed by algorithms. Therefore, developing, debugging and control of the debugging take place on the same abstraction level. The automatic interpretation and mapping of signals to the model cannot be regarded as reverse engineering, since information from the left branch of the process is needed. It is rather a reversal of the transformation from model to hardware. 4
The modular architecture of the debugger modules is depicted in Figure 2. First the recorded signals of the designs under test are bu ered in a FIFO. This rst FIFO can also run in a ring bu er mode, which allows recording signals before a trigger is released. This mode allows easier identi cation of the reason of an error, because the history of events can be recorded and parts of the system state reconstructed. After the FIFO, the data can be processed by di erent … Design Signals …
Coding and / or Compression Bypass-Switch
Interface FPGA
PC
JTAG,
RS232,
Ethernet
compression or coding algorithms to get a reduction of the data. This processing
is optional, but allows to use on-chip memory more e ciently and record a longer
period of time. The second FIFO stores the data into on-chip memory, before
it is transmitted to a PC using a communication interface. This architecture is
described in more detail in [
Besides recording, a direct monitoring of the design signals is also possible, since the transmission is independent of the recording. In this mode compression is bypassed and the FIFOs are directly read out. However, a restriction is the bandwidth, which depends on the speed of the interface to the PC and the processing in the model-based development environment. Therefore, real-time monitoring is only possible within small systems with few signal changes.
The debugger is managed by the controller, which is a small microprocessor. It monitors the status, controls recording and the design under test as well as communicates with the PC. To control the design under test, its clock enable and reset signal can be changed, which allows to stop and reset the design independent of the debugger modules. As inputs, trigger modules monitor signals of the design under test on the occurrence of certain conditions to start or stop the recording. The modules can trigger on edges or conditions of signals as well as compare signals to other signals or with xed values. The trigger module can be repeatedly instantiated to allow complex chained comparisons. Additionally, the trigger conditions can be modi ed at runtime, switching integrated multiplexers or changing memory cells. The controller also communicates with the PC, receiving commands for control and transmitting recorded data. The design has been extended by a timer module to enable time-based recordings.
For model-based generation of the platform, visualization of the execution and
control of the debugging at runtime a model-based developing environment
has been implemented. The environment is build on Eclipse[
With regard to statecharts in the rst step, a meta model has been developed
(Figure 3). As we use Eclipse the meta model is based on the Ecore meta meta
model. The meta model relies on the design of statecharts in Matlab State ow
to get the opportunity to convert Matlab les into the developed IDE. It is
similar to the UML statechart meta model [
According to the meta model, three models are created in the GMF-framework concerning the graphical editor on model level. The rst model describes the palette in the editor, i.e. the tools that are available to modify the model. In the example, there are tools to draw simple states, xor-states, and-states and junctions as well as transitions between states. The second model, the gmfgraph model, describes the graphical representation of the elements in the model, i.e. their shape, color etc. The last model layouts a mapping between the three models, it creates a connection between elements in meta model, tools and graphical representations. After creation of these models a model-based IDE can be generated by the framework. The result is depicted in Figure 4 (middle and left part). In the middle, is the modeling area with the tool palette and on the left side is the project management. The windows on the bottom and on the right are additionally implemented and explained in the next paragraph.
The window on the right allows displaying all recorded data with regard to the model. It displays in addition to the active states, which are shown in the model, the monitored values of internal variables, inputs and outputs. The view in the middle below can be used to visualize executions that have already been recorded and saved to a le. The window on the right below is the controller for on-chip recording and monitoring. It integrates a connection to the on-chip debugger to send commands and receive data during runtime.
The controller window allows controlling the reset and clock enable signal of the design under test. To control the recording start- and stop-conditions can be speci ed. The recording can start on the trigger, with the start of the design or manually. However, in this context, a manual start does not ful ll real-time conditions, because the time between the click and the actual start of the recording in the system cannot be exactly determined. The recording can stop either on a second trigger, on a timer or when the recording memory is full. Using the timer the recording time can be speci ed with regard to the number of clock cycles. Also the pretrigger time can be speci ed the same way.
Additionally, the trigger conditions are speci ed in the controller window. These are described with regard to the model, for example the string in(Go) and in(SwitchActive) would specify the trigger to release when state Go and SwitchActive are active at the same time. The trigger can be speci ed according to states, inputs, outputs and internal variables. The complexity have to match the implemented number of trigger modules, i.e. if the trigger condition is compound from three statements also minimal three trigger modules have to be present in the hardware implementation. In the next step, the design under test can be started, i.e. the clock enable signal is released and/or a reset performed. When recording is nished the data is transferred and stored in a XML le, which can be directly visualized to perform a postmortem analysis4. This enables model-based real-time debugging, but as the parameters have to be setup before recording, some knowledge according to the error needs to be present.
In another option, the controller can directly monitor the execution on-chip. The status of all recorded signals are polled every 100ms and the transmitted data is directly interpreted and visualized. The clock in the design under test can run continuously or controlled step by step to enable slow execution. No real-time debugging is possible using direct monitoring, because it only allows either slow execution (step by step) or slow monitoring (every 100ms). 6
Mapping of Model and Hardware Implementation In a model-based development process the design of the system is on model level and the source code for programming is mostly automatically generated from the model. If there is an error in the system, the user wants to monitor and debug his system on model level - the same level it has been designed. However, the data on a FPGA relies on signal level, therefore a mapping between model and hardware is needed. In addition, in a FPGA internal signals representing model elements are not directly accessible, therefore during generation of the system an adapted debugging interface needs to be integrated.
The design ow for generation of the platform and mapping of model and hardware system is depicted in Figure 5. In the example Matlab State ow is 4 Analysis that is performed after an expected event (e.g. an error / a system crash) Model-based development environment EIS xSSSIIIGGGNNNtAAALLL eiPises_d_CFCaianrnr_i_dsdohomemd_dn:e:xttyspteed:__ilso_gdCiacr;_dom+; ARCHITECTURE fsm_SFHDL OF Car_dominated type_is_Car_dom; Dinietialibze_Caur_dom g:PROgCES e(clk,r BEGIN resetB)EGINIF reisse_tLi=gh't1s'<T=HEN IN_NO_ACTEVILVSEI_FyC1H_cHIrlLekDg';E<V=EDNTto_AuNnDsLicglnked=('01,'3); THEN 5.
synth Design under Test 4.
generate IS SSIIGGNNAALL XPiesd_FCiaMnri_sdhoemd::Ltyspted__-ilso_gCiacr;_dom; ARCHITECTURE fsm_SFHDL OF Car_dominated SIGNAL is_Car_dom_next : type_is_Car_dom; BEGMINinitiaalize_pCar_dopm: PiROnCES(gclk, resetB)EGINIF reisse_tLi=gh't1s'<T=HEN IN_NO_ACTEILVSEI_FyFC1H_cIrlLekDg';Ei<V=ElNTtoe_AuNnDsicglnked=('01,'3); THEN esis Inputs clk reset Internal
Signals Outputs 3. specify monitored elements 6. control & debugging
User 6. mapping signaland model-level 6. control commands 6.
trace
data Interface Debug
ger IS SSIIGGMNNAALLiPse_daCFairn_idstohmedl::tayspted__ilbso_gCiacr;_dom; ARCHITECTURE fsm_SFHDL OF Car_dominated SIGNAL is_Car_dom_next : type_is_Car_dom; HBrEeGsIeDBiNtEn)GiItNiIaFLlirzeiess_e_CtL-air=g_hCd'to1sm'<T=:HoEPNROCESd(clek,r IN_NO_ACTEVILVSEI_FyC1H_cHIrlLekDg';E<V=EDNTto_AuNnDsLicglnked=('01,'3); THEN 1.
generate 2. load 2. load for platform generation and mapping of mo del and hardware 4 29.04u.2se01d0 to desigTn. Stchhewasltba-tFeFcNhaMrotdedllieazgurma mTesatennd the Matlab HDL-Co der to gene©raItnestitut für the VHDL co de, which represents the functionality of the statechart. If the mo del is designed and the VHDL co de generated, b oth is load into the describ ed development environment (see Section 5). The Matlab le is converted to an EMF mo del le which is based on the meta mo del shown in Figure 3. For e cient use of the FPGA resources in the next step the user can sp ecify in the mo del the monitored elements.
According to the sp eci cations in the mo del, the (by Matlab) generated VHDL co de is extended to enable monitoring of inner states and variables. Transitions cannot b e monitored directly, but as they form connections b etween states, according to changes from one state to the next, the used transition can b e determined. The monitored signals are group ed together into two vectors, one for recording and a second for the trigger, and integrated as outputs in the VHDL co de. The debugger mo dules are connected to the statechart mo dule by a generated interface le. The interface is a top level VHDL structural description and connects signals from outside to signals in the design and sp eci es signals b etween the debugger mo dules and the statechart mo dule. As all names of the signals are known or read from the Matlab le, the interface le can b e directly generated.
Technik der Inform ationsve
To get the mapping between signals and types in the VHDL le and elements in the model, an algorithm has been developed. This algorithm uses the fact, that in the VHDL code all signals and types have the same name as in the model and that all states in a composite state are grouped together. Therefore, as the model and VHDL always follow the same principles the mapping can be identi ed. This mapping is stored in a XML le, because it is needed later during debugging. The le contains the name, position, size and the function of the signals in the vectors with regard to the elements in the model. The le also contains general information concerning the model, which later allows later an easier identi cation.
The generated VDHL code is in the next step synthesized by FPGA speci c tools to generate a bitstream, which is integrated on the hardware. When the design is executed the debugger modules record the speci ed signals. The debugger modules are independent of the model and all signals, as described, are forwarded to the debugger in a vector. Therefore, during debugging additional information is needed for visualization of the execution on model level and control of the debugging (e.g. setting the trigger conditions). This information is contained in the XML le generated in the previous step. Therefore, the user can debug the system on model level and control the debugging according to the model notation. The back annotation of the recorded signals to the model and generation of control commands is performed by algorithms in the background using the mapping information.
In general, the back annotation from hardware to the model follows the
same principles as the back annotation in a general software debugger [
Di erent tests have been carried out to evaluate the functionality and integrity
of the depicted method and platform. The tests are mainly performed using a
development board, including a Xilinx Virtex II Pro FPGA [
Di erent designs were evaluated from small models used with minimal debugger modules up to large systems recording 128 signals. A common example is described in more detail. It is based on a model, which describes the tra c light system at a crosswalk and includes 14 states, 1 input, 2 outputs and 2 internal variables. The model is designed in Matlab State ow and according VHDL code generated. Both is load in the model-based development environment (see model in Figure 4). In the example every element in the model is selected for recording. After speci cation the according VHDL and XML les are generated. The VHDL design is integrated on the FPGA using the Xilinx ISE design suite, some additional adjustments are carried out according to the FPGA, the clock signal and external connections. The debugger modules record altogether 32 signals at 100MHz with a depth of 1024 clock cycles. Therefore, the recording data rate is 3.2Gbit/s. After recording or during monitoring the data is transferred to the PC using a RS232 interface. In the example the debugger modules use approximately 4% of the FPGA resources. The debugger does not include coding or compression, which would signi cantly increase FPGA resources.
During debugging the development environment connects to the debugger modules on the FPGA using the integrated RS232 interface. The XML le provides a mapping between the hardware implementation and the model and allows the user to control the debugging according to the crosswalk model. Further, the XML le is used to visualize the internal execution of the system in the model, highlighting active states and displaying the value of inputs, outputs and internal variables. Besides the real-time recording and postmortem analysis the system could be directly monitored during runtime. The transmission, interpretation and visualization of the status of 32 signals in the design every 100ms are performed without any timing problems. However, this is only a data rate of 320bit/s, therefore there is no real-time monitoring possible. In another design with 128 signals - the transmitting interval even needed to be reduced to 250ms to process the data before the next is transmitted, the most of that time thereby is consumed by the graphical visualization. 8
A method for model-based real-time recording and monitoring on recon gurable hardware has been presented. Therefore, the possibilities of an abstract and complex functional and algorithmic inspection of recon gurable system have been increased. In comparison with present techniques, the user does not only develop on model level, but can also debug and monitor as well as control the debugging on the same level. All intermediate steps from the model to hardware implementation and vice versa are carried out automatically by algorithms.
The underlying hardware modules are capable of monitoring and real-time recording as well as independent of the reviewed model. The debugger provides high modularity and adjustability during runtime, allowing several ways to identify causes of errors without re-synthesizing the design. The integrated development environment allows automatic integration of the debugger using a generated interface, control of the debugging during runtime and visualization of the execution - all on model level. The algorithms in the background convert the received data from hardware to model level and convert the commands from model level to hardware.
In future, there will still be many developed modules on code level, therefore the concept could be extended to allow mixed debugging on model, code and signal level. According to the software, the integration of breakpoints on model level could be added allowing more speci c debugging scenarios. Also the con guration of the debugger in terms of the compression and complexity of the trigger condition, which is at the moment performed in the VHDL code, could be integrated into software. In addition, the IDE will be extended to allow complete code generation of statechart diagrams to get independent of Matlab.