UET discussion-1       (11/26/96)

>	The purpose of this note is to describe what appears to be feasable (on
>paper) for an Event Timer system which incorporates a PC32 card and some
>special hardware for I/O.  This is a "low level" description, users won't
>interact with this directly but should have some understanding of what the
>limitations are.
>
  Mike,

  Here are some comments on your status report for the new UET. I decided
  to write them and am also placing them in file MISC106.TXT in directory
  \DSS3\ on the W: disc so we can look them up later if useful. There is
  another note (MISC105.TXT) in the same directory that also relates to
  the UET.

>	The Event Timer system can write to and read from a 32 bit register
>connected to the outside world.  16 of the read bits are dedicated to
>independent lines similar to the inputs of the UET now.  These bits are checked
>once every microsecond (usually, see caveats below) and if any changes from
>a previous state are detected, the clock time is logged along with the event.
>This data is stored internally on the PC32 card.  If no event has occured, the
>routine attempts to transfer any previously collected data to the host computer.
>This loop repeats forever.  (Event + Time data = 64 bits per event logged)
>

  This seems OK, except that we may also want to encode some additional
  information like "memory overflow" or other error conditions. We probably
  don't need to store 64 bits per event time, but it's OK to transfer 64
  to the host computer and let it do any data compression. If there is an
  easy way to reduce the number of bits in the PC-32 then it may ease the
  amount of data sent to the host computer, but I don't see this as a problem.

  You statement above that "..if no event has occurred (in one microsec) then
  the PC32 will attempt to transfer previously collected data to the 
  host computer.." may be slightly inconsistent with the "dump data" routine
  described below which you think should be executed only during slack times.
  More on this below.

  It's not explicitely stated above, but I assume the UET will capture
  events on two or more channels if they happen simultaneously (i.e. within
  one microsec) ? If two events happen at time X, will the UET log these
  as two data words of X each ? or as one data word with two bits set to
  indicate the two channels ?

  BTW, I assume there are _two_ 32 bit registers, one for input only and
  one for output only ? 16 of the bits on the input side are for timing
  spikes that come from the animal. What are we doing with the remaining
  16 bits on the input side ?

>	In addition, there is an output control system.  This consists of a
>"program" which the PC32 executes when no input event has occured.  The 
>structure of this progam includes a 32 bit relative time and a 32 bit command.
>The relative time is the amount of delay to wait before advancing to the next
>step in the output program.  Commands include "output raw" which just sends
>data directly to the 32 bit output port, "start loop" which pushes the start
>location and loop count on an internal stack, "end loop" which decrements
>the loop counter and branches to the top of the loop if not zero, or pops
>the loop stack if count = zero, "goto" which just goes to a fixed point
>in the program, "event-goto" which sets up a vector for one of the 16 bit
>input events to goto some fixed point in the program, "clock reset" which
>zeros the internal timer, and "dump data" which transfers large blocks of
>data to the host.
>
  Where does the PC32 get these "time+command" words from ? Are they 
  loaded at the start before the UET is started ? In a typical behaviour
  expt. the (host computer) program may wish to set a level on the output
  port (e.g. turn on an LED) at some indeterminate time while the UET
  is in the process of timing. Is this possible ? Can we issue new
  commands to the UET while it's timing ?

  How is the timing loop started ? In some cases it may be started by
  a command from the host (e.g. user presses some key), at other times
  it should be started when some external event happens (e.g. DSS turns ON).
  This latter is the most common way in which we presently use the UET
  (i.e. DSS starts UET). Is there a catch-22 here if we are also using the
  UET as a timing subsystem for the DSS ?

  Same considerations also apply to how the UET timing loop is stopped.

  In most cases the DSS and UET start simultaneously, but there are 
  important exceptions where one or the other starts before the other.
  In some cases the DSS may be used without the UET, or the UET used without
  the DSS.

>	All the instructions except "dump data" execute within the 1
>microsecond time limit.  The "dump data" command should only be executed when
>dead times of more than 10 milliseconds or more are available and no events are
>required to be logged.  The program size is limited to 1024 steps and no
>more than 16 levels of nested looping are allowed.
>

  This is a bit troubling. The present UET does continue timing while
  data transfer to the host is in progress (there is a 4000 word FIFO).
  This is actually used in many real situations. The most common is
  the case of searching for a unit (with program SER). The DSS is started
  with an FM signal which stays running for a long time (~several minutes).
  Every so often (~once per second) the program gathers event times
  upto that point and updates a graph on the screen. There are similar
  other cases where a long stimulus is presented, but you don't want to
  wait for a slack time (stimulus over) before gathering the event time
  data.

  It possibly isn't necessary for the host computer to be interrupted for
  every event that comes in, but it may be important to get the event
  times moved every so often even while the timing loop is in progress.
  Could we do something with the DMA capability of the PC32 ?

>	The "event-goto" program step works in conjunction with any of the 16
>input bits.  Each event automaticly vectors to a command (set to "nop"
>initially) which has 1/3 microsecond available.  These commands can be loaded
>for each experiment to be different, but this requires a touch of effort to
>re-link the DSP code.  Once set up, these routines won't need to be changed.
>The system is flexable so each experiment won't necessarily be able to use
>the same code (i.e. BE CAREFUL!).  
>
  This is potentially useful, and something not possible at present.
  If an "event-goto" is executed, how much will it interfere with the
  event timing loop ? What sort of things are possible with the event-goto ?

>	Commands from the host are also monitored, but they have the lowest
>priority and will blow the 1 microsecond timing if sent.  A command vector 
>table exists, but none of the commands have been coded.  As the entire DSS3
>evolves, I'll get a better feel for what these commands should do.
>
  The sort of commands I can forsee coming from the host are:

     (1) (program) Start
     (2) (program) Stop
     (3) Arm for (external) start/stop
     (4) Start/stop UET without affecting DSS.
     (5) Start/stop DSS without affecting UET. 
     (6) Send data from FIFO. (to host computer).
     (7) Set some output bit (e.g. turn on some LED)

  For some of these it doesn't matter what happens to the 1 usec timimg,
  but others (e.g. 5,6,7) may need to be executed without affecting the
  timing loop accuracy.

>      	While simple, this Event Timer system can be a very powerful 
>controller for logging events, controlling devices and responding to changing
>conditions.  Some of the data transfer will go to the PC44 card to control
>signal generation.  The rest can be used by individual experiments.
>
>Mike Rosing

  In some cases it may be desirable to use a time base larger than 1 usec
  (e.g. 5 or 10 usecs).

  What is the FIFO size on the PC32 ?  Is this shared memory that the
  UET and host computer could access at the same time ?

  Hope these are not too many questions for one message :)

  Thanks,

  Ravi
  11/26/96