(RK)(10/9/97)
                                                         (rev. 10/27/97)

     The following are some notes on the new UET design (PC-32 based)
  that reflect the topics discussed at a meeting on the UET on 10/9/97
  attended by Bill, Mike, Jane and Ravi. Some questions remain, and 
  anyone reading this should comment on any related issue that
  concerns the new UET.

     Background: The new Unit Event Timer (UET) is based on a PC-32 board
  from Innovative Integration. This is an ISA board that includes a
  64 Mhz TMS320C32 DSP processor made by Texas Instruments. The board
  also has 128 Kword SRAM, and 1 Kword shared dual-port memory. The
  dual-port memory is apparently available to both the PC32 and the
  host PC, as long as both do not try to write to it simultaneously.
  The dual-port memory is also the sole means of data transfer between
  the PC32 and the host PC.

     The basic design of the UET has been described earlier by Mike. It
  is available at http://www.neurophys.wisc.edu/comp/docs/dss/etimer.html
  Essentially, the PC32 board serves a dual purpose - as a UET and as a
  timer subsystem for the DSS. It may also in due course act as a controller
  for the (external) rate generators and for the "remote panel". The basic 
  timing loop to do this currently takes about 1.5 microsecs, though Mike
  is hopeful (?) that this may be brought down to 1 microsec. A 1 usec
  resolution would equal what is possible with the current UET. The added
  benefits of the new UET include (a) a 32-bit time (b) 32 input channels
  and (c) 32 bits of digital output (for controlling lights etc.)

     The main focus of today's discussion is the interaction between the
  new UET and the host PC.

     It is generally agreed that it is very desirable for the host to be
  able to fetch spike (event) times from the UET while data collection is
  in progress (i.e. before all the repetitions of the stimulus are 
  finished). The present (old) UET has a fifo of size 4K to 32K (depending
  on model), which can be read by the host microVAX at anytime without
  impacting the UET. This appears tricky to implement in the new design
  without some loss of timing accuracy. This is because the PC32 stores
  each event time as it comes in into it's internal 128 kword static ram
  buffer. The host PC cannot directly access this buffer, it only has
  access to the 1 kword dual-port RAM. The dual-port RAM is both smaller
  and slower than the internal SRAM buffer. To require the UET to 
  frequently move data from the internal SRAM buffer to the dual-port
  could impact timing accuracy. The following consensus emerged from 
  today's meeting:

     Mike thinks it is possible to use DMA capability to move data between
  the internal SRAM buffer and the dual-port RAM. This would greatly reduce
  the data transfer demands on the PC32. One possible scenario is as
  follows:

         (a) Host sets up PC32 with initial parameters, issues "arm"
             command (for external start of UET). PC32 "waits".

         (b) Host sends command to PC32 to start the timers (duration
             and rep. time etc.). This triggers the DSS to start, and also
             the UET to start timing.

         (c) UET starts reading incoming events in a tight (1 usec) loop.
             As an event is received, it is stored as two 32-bit words in
             internal SRAM buffer. In each 1 usec loop, the UET checks
             whether a command word has been received from the host PC.

         (d) If a command is received from the host PC, the UET branches
             according to the command word. For example, if the command
             word is "STOP", the UET terminates the timers etc.

         (e) If the command word is "SEND DATA", the UET triggers the
             transfer of any event times in the internal buffer to the
             dual-port RAM, using the DMA controller. The number of
             event times moved with each request should be the lesser
             of (1) the actual number in internal memory or (2) a number
             pre-specified during setup in step (a) above, subject to a
             max of 512 event times (which is all that the dual-port can
             hold).
             [Notes added 10/27/97: The PC32 requires the host PC to send
              it one request for each event time, (actually two requests
              since UET is storing each event in two 32-bit words, and they
              count as two words for transfer). PC32 transfers one 32-bit
              word to dual-port memory for each request from host PC).

         (f) The UET (or the DMA controller) will also have to set a flag
             when the transfer to dual-port is done, so the host can proceed
             to move that data to main host memory. How will this be done ?
             Also, the UET will have to record the number of events actually
             transferred.
             [Note added 10/27/97: Probably not relevant now since the
              UET is only moving one word per request, see above]

         (g) As soon as (?) the UET has started the DMS transfer (step (e))
             it should return to the timing loop (step (c)). The host could
             proceed to move data out of dual-port RAM without apparently
             disturbing this loop in any way.

     The above is a very basic description of how the I/O could work. Mike
  would need to fill in the gaps and define the command words and locations.

     Some other considerations were also brought up:

     (a) Could the UET automatically move data from internal SRAM to dual-port
         at pre-determined intervals, or when specific events happen (such
         as the end of a repetition time) ?

         The mechanics of this are not completely clear at this time.
         Something along these lines may be needed when certain
         events happen, such as the end of the stimulus, or an error
         condition. The UET would need to be sure that the host PC was
         done with reading any previous buffer.

     (b) There is a need to independently verify how tight the timing loop
         really is, and what impact the data transfer would have on it.

     (c) The setup commands to the UET should include one channel (bit)
         number that is analogous to the present "repetition time".
         Whenever this bit goes high (start of a new repetition), the
         UET timer should be zeroed. This bit should be programmable
         (typically so that either DSS-1 or DSS-2 could zero the timer).

     (d) It would be nice to know if the PC32 has any way of sending
         an interrupt to the host PC. The data transfer scheme outlined
         above uses programmed I/O, but using an interrupt has many
         benefits, such as relieving the host from having to check the
         UET frequently. In some cases it may be necessary to alert the
         host that some special event has happened, such as "monkey presses
         bar". Programmed I/O may be too slow for this situation.
         [Mike says there is one interrupt that the PC32 can use, implications
          yet to be explored].

     The data format of each event time also needs some thought. In the
  design as it stands, two 32-bit words would be recorded for each event
  time, 32-bits for the time and 32-bits to record the "channel #" on which
  the event happened. Each bit of the second word would record a 1 or a 0
  to indicate whether an event happened on one particular channel.

     This format, though inefficient for storage, is necessary to save
  time within the tight timing loop of the UET. The host PC could compress
  the data for storage on disc etc.

     A necessary addition to this format is the addition of error bits.
  The old UET has two bits assigned for flagging errors, one to indicate
  buffer overflow, and the other for timer overflow. Timer overflow is
  very unlikely with the new system (32-bits = 4,000,000,000 usecs
   = 4000 secs = 1.11 hour (approx)). Should we assume that timer overflow
  can be ignored ? In the rare event that the timer does overflow, what
  should happen. The best thing might be to roll over the time to 
  zero and keep going.

     Buffer overflow cannot be ignored. One way to flag it is to reserve one
  of the channel bits (still leaving upto 31 channels) as an error bit.
  Another possibility is to signal an overflow by setting all the channel
  bits to zero (should this be used to signal something else ?)

     What should the UET do when a buffer overflow occurs ? It could stop
  timing and wait for a command from the host PC. Or, it could start
  ignoring events and then resume automatically when buffer space becomes
  available. Could this choice be made at run time via a host command ?

     One question at this time is, given the above scheme for data transfer,
  how many events per second can the (Windows/NT based) host keep up with
  on a sustained basis ? This can only be resolved by some testing on
  a prototype.

     It would be desirable to have more than one timing loop. A slower
  version (running at 5 usecs e.g.) could include other features such
  as monitoring the input channels (monkey presses bar) and taking
  action (turning on lights) without missing any events or without need
  to notify the host CPU. 

     Another topic for further discussion is the synchrony of the various
  devices involved. In the current (old) DSS, the host PC sends a software
  command to the DSS. The start of the duration timer (in the DSS) is
  signaled by a level going high. This level is hardwired to both the
  UET and the A/D rate generators. Thus both the UET and the A/D are
  started at precisely the same instant (within 1 usec) as the DSS. In some
  cases the initial start command may come from some source external to
  the host PC.

     Here are some possible plans for triggering the devices in the new DSS
  (once the devices have been "armed"):

    Host Command       PC32. The PC32 in turn starts the timers, which
         or        ->  are made available via an external cable, which is
    External level     connected to the start ports of the rate generators
                       and the UET. This would be closest in some ways
                       to (old) DSS-II.

    Host Command       PC32. The PC32 starts timers, which trigger the
        or         ->  rate generators that trigger the DSS output.
    External level     However, the start of UET timing is triggered
                       by some other event or bit, and the start of
                       the A/D rate generators by yet another bit or
                       event. This would allow for pre-stimulus
                       sampling. (In DSS-II this is achieved by use
                       of the master delay option). To be most flexible,
                       triggering of the DSS rate, UET sampling and A/D rate
                       should be done without external cabling.

     The topic of how the rate generators should be triggered and started
  and stopped also requires further discussion.

  [Notes added 10/27/97: 
    It has become apparent that in the present design, the UET would
    in fact end up storing each spike time as two separate events, one
    for the upward going edge and another for downward edge. This is because
    the present design is more of a "level detector" than an "edge detector".
    This could be handled in software after event times have been moved
    to the PC, but would result in doubling of the amount of data 
    transferred. This is considered undesirable, and Mike is looking at
    ways to avoid this, perhaps by using additional hardware before the
    UET inputs.]

Back to Top