Model-Based Design for Embedded Systems- P21 pps

Modeling Embedded Systems and SoCs—Concurrency and Time in Models of Computation.. Responsible frameworks for heterogeneous modeling and design of embedded systems.. 586 18.1.2 Design Re

576 Model-Based Design for Embedded Systems

g at tn−1+ 0.5hn and tn−1+ 0.75hn, we must fire but not postfire these actors.

Postfiring the actors would erroneously commit them to state updates before

we know whether the step size hn is valid Thus, in effect, the solver mustprovide them with tentative inputs at each tag (one tag for each of thesetime values), as shown in Equations 17.5 and 17.6, and find a fixed point atthat tag But it must not commit the actors to any state changes until it is

sure of the step size Avoiding invocation of the postfire method successfully

avoids these state changes, as long as all actors conform to the actor abstractsemantics This mechanism is similar to that used in Simulink, where the

model_updatemethod is not invoked until a simulation step is concluded

We can now see that CT operates similar to DE models, with the onlyreal difference being that in addition to using an event queue to determinethe advancement of time, we must also consult an ODE solver The same

fireAtmechanism that we used in DE would be adequate, but for efficiency

we have chosen to use a different mechanism that polls relevant actors fortheir constraints on the advancement of time and aggregates the results In ourimplementation, any actor can assert that it wishes to exert some influence on

the passage of time by implementing a ContinuousStepSizeController interface All such actors will be consulted before time is advanced The Integrator

actors implement this interface and serve as proxies for the solver But giventhis general mechanism, there are other useful actors that also implement

this interface For example, the LevelCrossingDetector actor implements this

interface Given a CT input signal, it looks for tags at which the value of thesignal crosses some threshold given as a parameter If a step size results in acrossing of the threshold, the actor will exert control over the step size, reducing

it until the time of the crossing is identified to some specified precision.Since the CT director only assumes that component actors conform to theactor abstract semantics, these actors can be opaque composite actors thatinternally contain SR or DE models Moreover, a CT model can now form anopaque composite actor that exports the actor abstract semantics, and hence

CT models can be included within SR or DE models and vice versa (subjectagain to the constraint that if SR is at the top level, then it must be explicitabout time)

A simple example is shown in Figure 17.8 The top-level model is DE resenting a sequence of discrete jobs with increasing service requirements.For each job, a random (exponential) service rate is generated The insidemodel uses a single integrator to model the (continuous) servicing of the joband a level-crossing detector to detect completion of the job

rep-17.8 Software Implementation

A prototype of the techniques described here in Ptolemy II is available in an

Nicolescu/Model-Based Design for Embedded Systems 67842_C017 Finals Page 577 2009-10-2

Mixed Continuous and Discrete Systems 577

Falling 0.0 TimedPlotter

TimedPlotter

Continuous director

ZeroOrderHold

AddSubtract +

–

LevelCrossingDetector2

JobDone Job

Rate ZeroOrderHold3 Integrator2

Trigger Lambda

FIGURE 17.8

CT opaque composite actor within a DE model

the SRDirector created by Whitaker [48], which was based on an SR

direc-tor in Ptolemy classic created by Edwards and Lee [17] We then used this

director as a base class for a new ContinuousDirector Unlike the predecessor

CTDirectorcreated by Liu [37], this new director realizes a fixed point tics at each discrete time point The discrete time points are selected from the

seman-time continuum, as explained above, in response to actors that invoke fireAt and actors that implement ContinuousStepSizeController The latter include

integrator actors, which use an underlying ODE solver with variable stepsize control

We modified SRDirector and implemented ContinuousDirector so that

both now rigorously export the actor abstract semantics That is, when the

firemethod of either director is invoked, the director does not commit to any

state changes, and it does not invoke postfire on any actors contained in its

composite Thus, if those actors conform to the actor abstract semantics, then

so does the opaque composite actor containing the director

578 Model-Based Design for Embedded Systems

These improvements led to significant improvements in simplicity and

usability Before we had a menagerie of distinct versions of CTDirector, but

now we only need one Previously, in order to compose CT models withother MoCs (such as DE for mixed signal models and FSM for modal modelsand hybrid systems), we needed to implement specialized cross-hierarchyoperations to coordinate the speculative execution of the ODE solver withthe environment This resulted in distinct directors for use inside opaquecomposite actors and inside modal models

We also acquired the ability to put SR inside CT models This is extremelyconvenient, because SR can be used to efficiently specify numeric compu-tations and complex decision logic, where the continuous dynamics of CT

is irrelevant and distracting Note that it would be much more difficult touse dataflow models, such as SDF [31] inside CT models This is because indataflow models, communication between actors is queued In order to sup-port the speculative executions that an ODE solver performs, we would have

to be able to backtrack the state of the queues This would add considerablecomplexity SR has no such difficulty

Since the CT MoC is a generalization of the SR, in principle, SR becomesunnecessary However, SR is much simpler, not requiring the baggage ofsupport for ODE solvers, and hence is more amenable to formal analysis,optimization, and code generation

17.9 Conclusions

In this chapter, we explain an operational semantics that supports mixtures

of SR, DE, and CT MoC, and outline a corresponding denotational semantics.Dialects of DE and CT are developed that generalize SR, but provide com-plementary modeling and design capabilities We show that the three MoCscan be combined hierarchically in arbitrary order

Cen-Nicolescu/Model-Based Design for Embedded Systems 67842_C017 Finals Page 579 2009-10-2

Mixed Continuous and Discrete Systems 579

awards #0720882 (CSR-EHS: PRET), #0647591 (CSR-SGER), and #0720841(CSR-CPS)), the U S Army Research Office (ARO #W911NF-07-2-0019), the

U S Air Force Office of Scientific Research (MURI #FA9550-06-0312 and TRUST #FA9550-06-1-0244), the Air Force Research Lab (AFRL), the State

AF-of California Micro Program, and the following companies: Agilent, Bosch,HSBC, Lockheed-Martin, National Instruments, and Toyota

References

1 G A Agha, I A Mason, S F Smith, and C L Talcott A foundation for

actor computation Journal of Functional Programming, 7(1):1–72, 1997.

2 R Alur, T Dang, J Esposito, Y Hur, F Ivancic, V Kumar, I Lee,

P Mishra, G J Pappas, and O Sokolsky Hierarchical modeling andanalysis of embedded systems Proceedings of the IEEE, 91(1):11–28,2003

3 A Basu, M Bozga, and J Sifakis Modeling heterogeneous real-time

components in BIP In International Conference on Software Engineering

and Formal Methods (SEFM), pp 3–12, Pune, India, September 11–15,2006

4 A Benveniste and G Berry The synchronous approach to reactive and

real-time systems Proceedings of the IEEE, 79(9):1270–1282, 1991.

5 A Benveniste, L Carloni, P Caspi, and A Sangiovanni-Vincentelli.Heterogeneous reactive systems modeling and correct-by-construction

deployment In EMSOFT, Philadelphia, PA, 2003, Springer.

6 G Berry The Constructive Semantics of Pure Esterel Book Draft, 1996.

http://www-sop.inria.fr/meije/esterel/doc/main-papers.html

7 G Berry The effectiveness of synchronous languages for the ment of safety-critical systems White paper, Esterel Technologies, 2003

develop-8 G Berry and G Gonthier The Esterel synchronous programming

lan-guage: Design, semantics, implementation Science of Computer

Program-ming, 19(2):87–152, 1992

9 R Boute Integrating formal methods by unifying abstractions In

E Boiten, J Derrick, and G Smith (editors,) Fourth International

Confer-ence on Integrated Formal Methods (IFM), 2999: Canterbury, Kent, U.K.,

April 4–7, 2004, LNCS, pp 441–460, Springer-Verlag.

10 C Brooks, A Cataldo, C Hylands, E A Lee, J Liu, X Liu, S fer, and H Zheng HyVisual: A hybrid system visual modeler Technical

Neuendorf-580 Model-Based Design for Embedded Systems

report UCB/ERL M03/30, University of California, Berkeley, CA, July

17, 2003

11 J T Buck, S Ha, E A Lee, and D G Messerschmitt Ptolemy: A

frame-work for simulating and prototyping heterogeneous systems

Interna-tional Journal of Computer Simulation , Special issue on “Simulation Software

Development,”4:155–182, 1994

12 L P Carloni, M D DiBenedetto, A Pinto, and A Vincentelli Modeling techniques, programming languages, and designtoolsets for hybrid systems Technical Report IST-2001-38314 WPHS,Columbus Project, June 2004

Sangiovanni-13 C G Cassandras Discrete Event Systems, Modeling and Performance

Anal-ysis Irwin, Boston, MA, 1993

14 A Cataldo, E A Lee, X Liu, E Matsikoudis, and H Zheng A tive fixed-point theorem and the feedback semantics of timed systems In

construc-Workshop on Discrete Event Systems (WODES), Ann Arbor, MI, July 10–12,2006

15 A Deshpande, A Gollu, and P Varaiya The Shift programming

lan-guage for dynamic networks of hybrid automata IEEE Transactions on

Automatic Control, 43(4):584–587, 1998

16 R Djenidi, C Lavarenne, R Nikoukhah, Y Sorel, and S Steer From

hybrid simulation to real-time implementation In 11th European

Simula-tion Symposium and ExhibiSimula-tion (ESS99), pp 74–78, Erlangen-Nuremberg,Germany, October 1999

17 S A Edwards and E A Lee The semantics and execution of a chronous block-diagram language Science of Computer Programming,48(1):21–42, 2003

syn-18 J Eker, J W Janneck, E A Lee, J Liu, X Liu, J Ludvig, S Neuendorffer,

S Sachs, and Y Xiong Taming heterogeneity—The Ptolemy approach

Proceedings of the IEEE, 91(2):127–144, 2003

19 G S Fishman Discrete-Event Simulation: Modeling, Programming, and

Analysis Springer-Verlag, New York, 2001

20 P Fritzson Principles of Object-Oriented Modeling and Simulation with

Mod-elica 2.1 Wiley, New York, 2003

21 A Girault, B Lee, and E A Lee Hierarchical finite state machines

with multiple concurrency models IEEE Transactions On Computer-Aided

Design of Integrated Circuits and Systems, 18(6):742–760, 1999

Nicolescu/Model-Based Design for Embedded Systems 67842_C017 Finals Page 581 2009-10-2

Mixed Continuous and Discrete Systems 581

22 G Goessler and A Sangiovanni-Vincentelli Compositional modeling

in Metropolis In Second International Workshop on Embedded Software

(EMSOFT), Grenoble, France, October 7–9, 2002, Springer-Verlag

23 G Goessler and J Sifakis Composition for component-based modeling

Science of Computer Programming, 55:161–183, 2005

24 P L Guernic, T Gauthier, M L Borgne, and C L Maire Programming

real-time applications with SIGNAL Proceedings of the IEEE, 79(9):1321–

1336, 1991

25 N Halbwachs, P Caspi, P Raymond, and D Pilaud The synchronousdata flow programming language LUSTRE Proceedings of the IEEE,79(9):1305–1319, 1991

26 F Herrera and E Villar A framework for embedded system specification

under different models of computation in SystemC In Design Automation

Conference (DAC), San Francisco, CA, July 2006 ACM

27 C Hewitt Viewing control structures as patterns of passing messages

Journal of Artifical Intelligence, 8(3):323–363, 1977

28 A Jantsch Modeling Embedded Systems and SoCs—Concurrency and Time

in Models of Computation Morgan Kaufmann, San Francisco, CA, 2003

29 E A Lee Modeling concurrent real-time processes using discrete events

Annals of Software Engineering, 7:25–45, 1999

30 E A Lee Embedded software In M Zelkowitz (editor), Advances in

Computers, vol 56 Academic Press, London, U.K., 2002

31 E A Lee and D G Messerschmitt Synchronous data flow Proceedings

of the IEEE, 75(9):1235–1245, 1987

32 E A Lee and S Neuendorffer MoML—A modeling markup language inXML Technical report UCB/ERL M00/12, UC Berkeley, Berkeley, CA,March 14, 2000

33 E A Lee, S Neuendorffer, and M J Wirthlin Actor-oriented design of

embedded hardware and software systems Journal of Circuits, Systems,

and Computers, 12(3):231–260, 2003

34 E A Lee and A Sangiovanni-Vincentelli A framework for comparing

models of computation IEEE Transactions on Computer-Aided Design of

Circuits and Systems, 17(12):1217–1229, 1998

35 E A Lee and H Zheng Operational semantics of hybrid systems In

M Morari and L Thiele (editors), Hybrid Systems: Computation and Control

582 Model-Based Design for Embedded Systems

(HSCC) , Zurich, Switzerland, March 9–11, 2005 LNCS, 3414: pp.25–53,

Springer-Verlag

36 E A Lee, H Zheng, and Y Zhou Causality interfaces and compositional

causality analysis In Foundations of Interface Technologies (FIT), Satellite to

CONCUR, San Francisco, CA, August 21, 2005

37 J Liu Responsible frameworks for heterogeneous modeling and design

of embedded systems PhD thesis Technical Memorandum UCB/ERLM01/41, December 20, 2001

38 X Liu and E A Lee CPO semantics of timed interactive actor works Technical report EECS-2006-67, UC Berkeley, Berkeley, CA, May

net-18, 2006

39 X Liu, E Matsikoudis, and E A Lee Modeling timed concurrent

sys-tems In CONCUR 2006—Concurrency Theory, Bonn, Germany, August 27–30, 2006 LNCS, 4137: Springer.

40 Z Manna and A Pnueli Verifying hybrid systems Hybrid Systems,

43 W H Press, S Teukolsky, W T Vetterling, and B P Flannery Numerical

Recipes in C: The Art of Scientific Computing Cambridge University Press,Cambridge, MA, 1992

44 I Sander and A Jantsch System modeling and transformational design

refinement in forsyde IEEE Transactions on Computer-Aided Design of

Cir-cuits and Systems, 23(1):17–32, 2004

45 S Swan An introduction to system level modeling in SystemC 2.0 nical report, Open SystemC Initiative, May 2001

Tech-46 M M Tiller Introduction to Physical Modeling with Modelica Kluwer

Aca-demic Publishers, Norwell, MA, 2001

47 F D Torrisi, A Bemporad, G Bertini, P Hertach, D Jost, and D none Hysdel 2.0.5—User manual Technical report, ETH, 2002

Mig-Nicolescu/Model-Based Design for Embedded Systems 67842_C017 Finals Page 583 2009-10-2

Mixed Continuous and Discrete Systems 583

48 P Whitaker The simulation of synchronous reactive systems inPtolemy II Master’s Report Memorandum UCB/ERL M01/20, Electron-ics Research Laboratory, University of California, California, CA, May2001

49 B P Zeigler, H Praehofer, and T G Kim Theory of Modeling and

Simula-tion 2nd edition, Academic Press, Orlando, FL, 2000

Design Refinement of Embedded

Mixed-Signal Systems

Jan Haase, Markus Damm, and Christoph Grimm

CONTENTS

18.1 Introduction 585

18.1.1 Previous Work 586

18.1.2 Design Refinement of E-AMS Systems with OSCI AMS Extensions 587

18.2 OSCI SystemC-AMS Extensions 588

18.3 Design Refinement of Embedded Analog/Digital Systems 591

18.3.1 Use Cases of SystemC AMS Extensions 591

18.3.2 Design Refinement Methodology 592

18.3.3 Methodology-Specific Support in SystemC AMS Extensions 595

18.3.4 Specific Support in a Methodology-Specific Library 596

18.4 Simple Example for a Refinement Step Using Converter Channels 597

18.5 Conclusion and Outlook 600

References 601

18.1 Introduction

There is a growing trend for closer interaction between embedded hard-ware/software (HW/SW) systems and their analog physical environment This leads to systems in which digital HW/SW is functionally interwoven with analog and mixed-signal blocks such as radio-frequency (RF) inter-faces, power electronics, and sensors and actuators, as shown, for example,

by the communication system in Figure 18.1 We call such systems “embed-ded analog/mixed-signal (E-AMS) systems.” Examples of E-AMS systems are cognitive radios, sensor networks, and systems for image sensing A chal-lenge for the development of E-AMS systems is to understand and consider the interaction between HW/SW and the analog and mixed-signal subsys-tems at architecture level

Complexity of modern systems often requires methodologies that hide complexity and allow designers an incremental, interactive approach that

585

586 Model-Based Design for Embedded Systems

Radio transceiver

Wakeup radio

Low-level packet handling

Energy supply management

Node power management

SoC/SiP

Sensor interfaces

MAC layer(s)

Oscillators wakeup timers

Microcontroller

Upper layer protocols

Security functions

FIGURE 18.1

A node of a sensor network serving as an example of an E-AMS architecture

step-by-step leads to an implementation In this approach, it is crucial toobtain very early feedback on the impact of nonideal properties onto overallsystem performance, which requires considering interaction of HW/SW andAMS subsystems

In the SW engineering community, extreme programming [17] uses astepwise approach that starts with code fragments that are successively

“refined” by SW engineers Refinement of SW systems has been known for

a long time (e.g., [15]) However, the SW-oriented approaches are restricted

to pure SW systems and do not deal with specific problems in the design ofE-AMS systems In the realm of formal “property refinement” of embeddedsystems, a (formal) property that is present and proved in a system spec-ification is maintained by proved design steps (e.g., [16]) In this chapter,

we describe a design refinement approach for E-AMS systems Similar toextreme programming, and in the same vein of “property refinement,” it is

an incremental approach Compared to extreme programming, however, it

is more specifically tailored to E-AMS system design, whereas compared toproperty refinement we do not intend to provide a formal proof

18.1.1 Previous Work

SystemC [1] supports the refinement of HW/SW systems down to RTL

by providing a discrete-event (DE) simulation framework Design

refine-Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 587 2009-10-1

Design Refinement of Embedded Mixed-Signal Systems 587

is successively augmented with timing information, power consumption,and more accurate modeling of communication and simulation of poten-tial HW/SW architectures However, the properties of E-AMS systems aremuch more diverse than only timing, performance, and power consump-tion A key issue is the accuracy that is determined by noise, sampling fre-quencies, quantization, and very complex, nonlinear dependencies betweensubsystems: Often, accuracy of the AMS part is improved by digital signalprocessing (DSP) software in the HW/SW part SystemC offers neither anappropriate methodology for refinement of E-AMS nor support for the mod-eling and simulation of analog, continuous-time systems

Support for modeling and simulation of E-AMS systems is offered

by tools such as Simulink R [3] and Ptolemy II [4] While their supportfor system-level design also facilitates capturing continuous-time behavior,these tools lack appropriate support for the design of HW/SW (sub)systems

at the architecture level in a manner that, for example, SystemC does

Hardware description languages (HDLs) dedicated to the design of AMSsystems such as VHDL-AMS [5] and Verilog-AMS [6] target the design ofmixed-signal subsystems close to implementation level such as analog/dig-ital (A/D) converters, but modeling HW/SW systems based on HDLs iscumbersome To support HW/SW system design, cosimulation solutionframeworks mix SystemC and Verilog/VHDL-AMS However, although theresulting heterogeneous framework allows designers the modeling of mixedHW/SW and AMS architectures, it does not support interactive evaluation

of different potential architectures in a seamless design refinement flow

18.1.2 Design Refinement of E-AMS Systems with OSCI

AMS Extensions

An earlier work by the open SystemC initiative (OSCI) [12] presented anAMS extension that augments SystemC with the ability to model and sim-ulate AMS subsystems at functional and architectural level [7,8] Further-more, this work specifically intends to support design refinement of E-AMS.Design refinement of E-AMS starts with a functional description that is used

as an “executable specification.” In “architecture exploration,” properties ofdifferent subsystems such as

• Noise, distortions, and limitation effects

• Quantization and sampling frequencies

• Partitioning of (A/D/SW)

are added to the functional specification The impact of these properties onthe overall system performance (accuracy, power consumption, etc.) is deter-mined by modeling and simulation

In this chapter, we assume that the reader is familiar with SystemC 2.0

We first present a brief overview of the SystemC AMS extensions A moredetailed overview of the AMS extensions is provided in [9,12] Then, we

588 Model-Based Design for Embedded Systems

describe typical use cases of SystemC AMS extensions to focus on ture exploration and to classify different levels of refinement and refinementactivities

architec-18.2 OSCI SystemC-AMS Extensions

The SystemC AMS extensions provide support for signal flow, data flow, andelectrical networks, as shown in Figure 18.2 Electrical networks and signal-flow models use a linear differential and algebraic equation (DAE) solver thatsolves the equation system and that is synchronized with the SystemC ker-nel The use of a linear DAE solver restricts networks and signal-flow com-ponents to linear models in order to provide high simulation performance.Data-flow simulation is accelerated using a static schedule that is computedbefore simulation starts This schedule is activated in discrete time steps,where synchronization with the SystemC kernel introduces timed semantics

It is therefore called “timed” data flow (TDF)

The SystemC AMS extensions define new language constructs identified

by the prefixsca_ They are declared in dedicated namespacessca_tdf(TDF), sca_eln (electrical linear networks (ELN)), and sca_lsf (linearsignal flow (LSF)) according to the underlying semantics By using names-paces, similar primitives as in SystemC are defined to denote ports, inter-faces, signals, and modules For example, a TDF input port is an object ofclasssca_tdf::sca_in<type>.

LSF and linear electrical networks (LEN) are specified by instantiatingcomponents of the AMS extensions library such as resistors, capacitors, and

AMS methodology-specific elements elements for AMS design refinement, etc–

Linear signal flow (LSF) modules ports signals

Electrical linear networks (ELN) modules terminals nodes

Linear DAE solver

Synchronization layer

SystemC language and C/C++ language

User-defined AMS extensions modules, ports signals (e_g_aditional solvers/

simulators)

Timed data flow (TDF) modules ports signals

Scheduler

etc_

FIGURE 18.2

Nicolescu/Model-Based Design for Embedded Systems 67842_C018 Finals Page 589 2009-10-1

Design Refinement of Embedded Mixed-Signal Systems 589

(controlled) current sources for LEN or integrators and adders for LSF TDFrequires some new syntactic elements and is crucial for understanding theSystemC AMS extensions In the following, we will concentrate on TDFmodels

TDF models consist of TDF modules that are connected via TDF signalsusing TDF ports Connected TDF modules form a contiguous graph structurecalled TDF cluster Clusters must not have cycles without delays, and eachTDF signal must have one source A cluster is activated in discrete time steps.The behavior of a TDF module is specified by overloading the predefinedmethodsset_attributes(),initialize(), andprocessing():

• The methodset_attributes()is used to specify attributes such asrates, delays, and time steps of TDF ports and modules

• The methodinitialize()is used to specify initial conditions It isexecuted once before the simulation starts

• The methodprocessing()describes time–domain behavior of themodule It is executed with each activation of the TDF module duringthe simulation

It is expected that there is at least one definition of the time step value and,

in the case of cycles, one definition of a delay value per cycle TDF ports aresingle-rate by default It is the task of the elaboration phase to compute andpropagate consistent values for the time steps to all TDF ports and modules.Before simulation, the scheduler determines a schedule that defines the order

of activation of the TDF modules, taking into account the rates, delays, andtime steps During simulation, the processing()methods are executed

at discrete time steps Example 18.1 shows the TDF model of a mixer The

SCA_TDF_MODULE(mixer) // TDF primitive module definition{

sc_out or sca_tdf::sc_in) can establish a connection to a SystemC DE channel, for instance, sc_signal<T>, to read or write values during the first

590 Model-Based Design for Embedded Systems

delta cycle of the current SystemC time step Example 18.2 illustrates the use of such a converter port in a TDF module modeling a simple A/D converter with an output port to which a SystemC DE channel can be bound This A/D converter also scales the input values based on a given input range to fit the range of the output data type, while clipping the inputs out of range.

SCA_TDF_MODULE(ad_converter) // simple AD converter

{

double val;

if(in_tdf.read() > in_range_max) val = pow(2,12)-1;

// clip ifelse if(in_tdf.read() < in_range_min) val = 0;

// necessaryelse val = (in_tdf.read() - in_range_min) * scaleFactor;

// scale otherwiseout_de.write( static_cast<sc_dt::sc_uint<12> >(val) );{

ad_converter(sc_module_name n, double _in_range_min,

double _in_range_max){

Example 18.2 TDF model of a simple A/D converter using a converter port The

SystemC AMS simulation kernel uses its own simulation time t TDF that usually differs from the SystemC simulation time t DE If a pure TDF model is used in a simulation, the SystemC AMS simulation kernel blocks the DE kernel, and so the DE simulation time does not proceed at all That is, in general we have t TDF ≥ tDE In a mixed TDF-DE model, interconnected by converter ports, there is of course the need for synchronization If there is an access to a converter port within the processing() method

of a TDF module, the SystemC AMS simulation kernel interrupts the execution of the static schedule of TDF modules and yields control to the SystemC DE simulation kernel, such that the DE part of the model can now execute, effectively proceeding t DE