Document Sample
sinnott Powered By Docstoc
					Applying SDL for Real-Time
Systems Development: A Lip-
 Synchronisation Case Study
       Dr Richard Sinnott
         EPK Ericsson
     Overview of Presentation
• Intention of presentation to address issues in
  SDL usage for general modelling vs validation
  – not all (small sized) models can be validated!
• Outline of Lip-Synchronisation system
  – outline of algorithm
  – outline of modelling approaches for
    Producer/Consumer sides
• Conclusions on SDL usage
    Lip-Synchronisation Model
• Two producers wanting to send audio flow
  and video flow respectively to consumer
  – strict timing requirements for individual flows
     • within some jitter bounds
  – strict timing requirements between flows
     • avoid flows drifting apart
  – rates of production/consumption can vary
     • allow faster/slower rates of production/consumption
 Basic Timestamping Modelling
  Approach For Producer Side
• Producers use timestamping of frames with
  timestamps based on expiry of local timers
  – local timers set at controllable rates (durations)
  – rate of production dependent on rate variable
     • sendFaster/sendSlower -> lower/higher value for rate
       results in higher/lower productivity
     • producer can also ask consumer to consume faster/
       slower, e.g. if producer has too many/not enough
       buffered frames to send
   Producer                                               ready

 Timestamping                                        startFlow

   Approach                                         tnow:= NOW

                                                     length(fs)>0       False = stop flow



• Change rate (r) = change sending freq.
• Frames to send(fs) value below/above
some limit = consume slower/faster resp.             t1                                      tnow + r = NOW

                                                     FrameSend( (. first(fs)!d,tnow+r .) )


                                           fs:= substring(fs,2,length(fs)-1)
 Basic Timestamp Approach For
         Consumer Side
• Consumer receives two streams of arriving
  timestamped frames
  – Ensure both streams satisfy individual timing
     • ensure timestamps of arriving frames within
       consumption rate +/- jitter for individual flows
  – Ensure both streams satisfy joint time constraints
     • ensuring timestamps arriving frames within bounds
       compared to timestamped frames of other flows

   Consumer                                                          FrameSend(f)

 Timestamping                                                              f!d                                                      similar for video case


   Approach                                                            call
                                                                                                                                 Check timestamp of this frame
                                                                                                                                 vs time stamp of last video
                                                                                                                                 frame (or expected next video
                                                                                 True                                            frame if buffered audio =
                                     Check early
                                                                  f!ts < act + ar - aj                                           buffered video)
                                                                                                     False                       If False then increment error
                                                                                                                                 count: if error count > max then
                                                                      ae:= ae +1         f!ts > act + ar + aj                    resetClocks

•checks if audio/video frame (f!d)                                                                   True
                                                                                             al := al +1                         Check late
•checks value of frame timestamp (f!ts)
with last video/audio timestamp, if ok                         al > maxLateAudio OR
                                                                 ae > maxEarlyAudio
•compares with own local clock (act)                                                lab
                                                                                                                                           Frame time OK
                                                   setClock(aId, df!d := last(afs)!d;
and rate consumption (ar) +/-jitter (aj)           act + ar - f!ts)    df!l := f!l;
                                                                                                                ae:= 0, al:=0,
                                                                                                                 afs := afs //
                                                                     df!ts := f!ts;                              MkString(f)
•if ok, add to buffered frames, else
                                               ae := 0, al:= 0       afs := afs //
increment no. early/late (ae/al) frames,                             MkString(df)

add copy of data to buffered frames                      lab
                                                                    act := act + ar
•if ae/al exceed maximum value, set
producer clock with appropriate offset
 Problems Validating
  Using Timestamp                                                           ready



• Consider same approach using

  INTERVAL time extensions                                                   wait

• Problem of accessing/reading time
                                                                              true                 ac1<=11)

   – now does not explicitly change in
     FrameSend so consumer cannot check if                               length(fs)>0       False = stop flow

     early/late                                                                     True

       • actually value 0 sent but when try to access                    FrameSend( (. first(fs)!d,now .) )

         this causes “value out of range condition”                                                      NOW=?
            – hence consumer cannot check timing               fs:= substring(fs,2,length(fs)-1)

              information, e.g. frame early, late etc                                              resetclock(ac1)
       • if try to send value of ac1 would result in
         non-validatable system
            – due to current techniques for clock constraint
              representation (polyhedra) during validation
 Problems validating …continued
• Validation of following systems causes
  deadlock      set(now+9,t1)


                 t1             NOW>=8

                       -        X


• does not result in signal X being sent
  – if interactively simulate system, then X sent
     • e.g. NOW takes value of last timer that has fired
• Role played by specification important
     • interactive simulation vs
     • validation (via state space exploration)
• Often restrictions imposed which are not
  immediately apparent when specifying
• As well as language extensions and tool
  development Interval should (is!)
     • identify these restrictions
     • give guidelines how best to specify/verify such systems
        – don’t use time stamps accessing NOW
        – don’t use continuous signals based on NOW
        – … etc

Shared By: