

&&

!./2'//

!./2'//

!./1'//

 -


 

 ()&\*

of the controller function and the control output have to be completed within one period of T\_Control in order to fulfill the real-time execution restriction for the discrete-time controller

Since the platform-independent model abstracts from the DAQ and output behaviour, from the model-based design point of view, the beginning of the T\_Control interval has to be regarded as the point in time, when the state of the plant has been captured and the controller simulation/computation is initiated. For the platform-specific controller model the question arises, how to regard the hardware execution of the controller and its delay in relation to the

In this section first a hardware implementable model is directly derived from a T\_Control-cycle oriented model to analyze its hardware execution semantics. Afterwards a model with advanced clocking and trigger structures necessary to ensure consistent hardware execution are introduced. Along with the required modifications to the model structure and the simulation semantics the advantages and disadvantages of each modelling and

When applying the HDL Workflow Advisor directly to the model shown in Figure 8 a valid HDL entity of the controller model including the referenced HDL component for the black box will be generated. The data paths from the inputs through the internal arithmetic functions of

 

 Fig. 9. Execution cycle of a real-time control system in reality and simulation.

 -

!./1'//

  !.5'4

!.33'// !./2'//


!./4'//

!.45'42

! 

6 

 -

Fig. 8. Structurally HDL compatible controller model.

 -

real-time interval and how to model it.

implementation variant are discussed.

**4.1 Control cycle oriented design**




!.34'//

!


'   

design (Caspi & Maler (2005)).


 !

! &

!./0'//

!.43'42

!.43'42

!./0'//

 ! &

> 

!.34'//

!./2'//

! "-

+&,

\$ % &'

!.34'//

!./5'42

!.32'//

this entity will be transformed into *combinational logic*. The unit delays in the feedback path, see Figure 8, and in the integrator block, see Figure 5 storing the control cycle state will be realized as *registers*. The update of these registers will be triggered by a rising edge of the clock signal connected to this entity.

At this level of abstraction, although the Kalman filter subsystem is still simulated as an abstract black box, the integration of the underlying HDL component in the logic path has to be prepared. This includes the connection to a 120 MHz clock source, which is best designed at chip level. Therefore, the according clock port CLK\_120MHz is linked to the controller component's interface to the top level. Furthermore, the Kalman filter component has to be triggered at a point in time defined by outside prerequisites, which requires the connection of the Trigger port to an outside source. Both modifications are shown in Figure 10.

Fig. 10. Model of the controller with an externally clocked Kalman filter component.

Prototyping the implementation with the HDL Coder Workflow Advisor and using the back-annotation feature allows to examine the computational delays of the combinational path of the resulting hardware implementation of the controller. For the example design this value is 45*ns*. Regarding the 1.8*μs* execution delay of the Kalman filter, which on the FPGA is computed in parallel, it is certain, that the computation is completed well within the T\_Control = 100*μs* real-time interval.

During code generation the HDL Coder will generate an entity, that, aside from the ports defined in the Simulink model, declares the port clk to connect to an on-chip clock source. As the simulation model computed one step per sample interval T\_Control, the controller implementation will conduct one computation step, if the clk port is driven by a clock source with the period of the simulation base sample time, i.e. clock frequency *f* = 1/*T*\_*Control*.

But it has to be noted, that the only safe assertion, that can be made for hardware design derived from this model, is that at each rising clock edge the output and integrator values are stored in the respective registers. Due to the combinational logic, the design is sensitive to the *input/output behaviour* of the surrounding hardware design. All value changes of the signals


 " ! 3 

