Occam TIMERs - was Dynamic Priority

["Roger Peel" <R.Peel@xxxxxxxxxxxxxxx>]

Forwarded message:
> Subject: Dynamic Priority
> To: occam-com@xxxxxxxxx
> Date: Wed, 28 Apr 1999 11:21:22 +0100 (BST)
> From: Adrian Lawrence <adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> 
> 1) SAT
> ~~~~~~
> 
> Vague as yet, but a way to qualify statements(processes?) taking a list of
> predicates. Perhaps something along the lines
> 
> PAR SAT (DELAY(c) < clock(5))
> 
> where c is a CHANnel and clock is a TIMER: no event on channel c
> will be delayed by more than 4 ticks of clock.
> 
> This seems a little futuristic, but we may be able to identify a small set
> of predicates current compiler technology can handle. 

Adrian rips open another can of worms here!

The occam TIMER mechanism is implemented rather restrictively at
present.  In particular, occam programs are not portable because the
timer tick rate varies from one implementation to another, with or
without PRI PAR (!), and with various sizes of INTs holding the time
value both within the clock hardware and at the other end of each TIMER
channel.

Barry and I have been discussing alternative schemes that are more
suitable for hardware compilation.   We don't have all of the answers
yet, but Adrian's clock(5), above, hints at some of them.

Consider the generation of fast waveforms from a piece of
occam-specified hardware - for instance the waveforms necessary to
control reading, writing and refreshing dynamic memories.  The time
taken to execute a conventional

    TIMER tchan :
    INT start :
    SEQ
      tchan ? start
      addrbus ! addr.hi
      write ! 1
      oe ! 0
      RAS ! 0
      tchan ? AFTER (start PLUS 2)
      addrbus ! addr.hi
      CAS ! 0
      tchan ? AFTER (start PLUS 4)
      databus ? data
      ... and so on 

is likely to suffer all sorts of jitter and potentially creates huge
adder hardware or operand routing buses to a central adder.  This code
also embeds several constants that may need to be changed when the
clock frequency of the target FPGA is discovered at the end of the
synthesis process.

Our thoughts are also turning to a relative TIMER mechanism, that can
be primed at the beginning of an operation and then used to trigger
events at short intervals thereafter.  This allows the size of the
adder (in the timer itself - there is no need for a 'start PLUS n' now)
to be constrained - the compiler could reason about about constant
numbers of constant intervals and would have to be told about the
maximum relative value in other cases.

In hardware, there is no reason why several clocks of different
frequencies may not be provided.  These may all communicate along
channels with other processes without further complication, except for
the usual metastability precautions.  Some form of protocol on TIMER
channels, to identify groups of channels connected to timers that are
running at different frequencies, therefore looks convenient.  It may
turn out that such identification is not necessary - the compiler might
be able to trace each use of a timer back to a specific clock - but the
protocol annotation might be the best place to declare the frequency in
the first place.

Roger.


Dr. Roger M.A. Peel
School of Electronic Engineering, Information Technology and Mathematics 
University of Surrey                   
Guildford                              Phone: +44 1483 259284 (01483 within UK)
Surrey  GU2 5XH                          Fax: +44 1483 534139
United Kingdom                         Email: R.Peel@xxxxxxxxxxxxxxx