UET discussion-2       (11/26/96)

  Mike,

  Thanks for clarifying many of the points. Some more questions are below.
  I'm sending the following to the DSS list in case others on the list
  (Bill, Jane, Dan) have questions or comments. Also saving it in
  the W:\DSS3\ directory as MISC107.TXT.

  Ravi
  11/26/96

>>
>>  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.
>
>
>I do have flag space set aside for things like that.  That's detail that's
>way below the user, other than we'll need to let them know about it if it
>does happen.
>
>>  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.
>
>Yep, that's why I'm warning you about it.  I think this is complex enough
>that I should draw up a picture and show how all these things inter-relate.
>
  OK, I think I understand now. See additional questions 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 ?
>
>Simultaneous events will be stored in one word.  Only the highest order bit
>will be acted on.  All 16 could change simultaneously and would be stored
>as a single "event".
>
>>  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 ?
>
>It's one physical address, but yes, there is a set of latches for input
>and another set for output, so it is independent.  The second set of
>16 bits on the input side is not yet defined.  I was thinking it might be
>used by the PC44 to PC32 as additional commands, or as higher order commands
>from the outside world (as opposed to bits).
>
>>  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 ?
>
>The program is loaded before the UET is started.  A possible command (which
>blows the 1 microsecond timing) could be to download a new program.  It does
>come from the host.  The host does not have access to the UET's outputs, it
>can not control the same things the UET does.  That's the point of the program.
>There's no such thing as indeterminate time, the program in the UET needs to
>be set up to emulate what ever it is you're thinking about.  The timing and
>output all occur simultaneously (on the 1 microsecond time scale).  If the
>program is set up properly, you won't need new commands, it will be able to
>respond correctly by branching to a different set of instructions.
>
  There will probably be situations where this may not be enough. It may
  be that we'll need to turn on LED's etc. using some other device that
  won't interfere with the UET timing. An example from current expts. is
  as follows : Cat looks at some point in space. When cat enters a certain
  "window" (say 4 degs. around that point), a reward is given. This is
  accomplished by the program continuously reading cat eye position and
  setting the reward bit. Can the PC44 set output bits similar to the
  PC32. Is that a possible way to turn on lights at arbitrary times under
  computer control ?

>>  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 ?
>>
>This is open.  You could use one of the input bits to do a "reset clock"
>followed by a "goto" which would start the system up.  You could send a host
>command.  We can use the 16 input bits that are still open and have the DSS
>or even a foot switch fire it up.  All are possible.  The DSS clocks are
>independent of the UET clocks.  However, it is physically possible to run
>a line from the DSS card to the UET card (PC44 -> PC32) and force the PC32
>clock to be derived from the PC44.  What ever you want, it's possible!
>
>>  Same considerations also apply to how the UET timing loop is stopped.
>
>Same answer, any way you like.  An input bit, a host command, a DSS command,
>or a program step.  In fact, I do have an external command on the upper 16 bits
>which executes a halt.  What I do when I "halt" remains to be determined tho.
>
>>  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.
>
>That's up to the host.  If you don't boot one of the cards, it won't run.

  Hopefully we can still use the PC32 to gate the DSS timers even though
  we didn't use it for event timing.

>>>	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 ?
>
>During normal operation, the PC32 will transfer an event to the host.  This
>is handshaked one 64 bit chunk at a time and polled between the two.  As long
>as the event rate is less than 100K/second you'll have all the data anyway
>and a "data dump" won't be necessary.  I included it as a secondary clean up
>command for situations that are known to be dead time.  The standard data
>transfer mechanism is polled, as long as the host pays attention and constantly
>looks for the data coming over, it shouldn't be a problem.
>
>The PC32 can't DMA to the host.  The host and PC32 can read the same dualport
>ram locations and that needs to be handshaked.  Again, that's at a very low
>level of operation, you'll have all the data you want if you call the low level
>routines often enough.  We can use multi-threaded operations to ensure this
>happens behind the scenes and take advantage of the NT OS.

  I guess this is something we can work out. I assume by "polled" you
  mean something like: PC32 puts new data in shared memory, sets a flag.
  Host checks flag, if set it reads new data into host memory, clears flag.
  If these flags and pointers are sitting in shared memory we'll need to do
  additional handshaking. Not clear if this has any impact on the timing
  loop. But you imply that it does not. Correct me if I am entirely wrong
  on how the PC32 pushes data to the host.

>>  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 ?
>
>As long as what ever happens uses 12 or fewer cycles it won't interfere
>with the 1 microsecond limit.  Halt, reset, restart, goto program location,
>output raw data, clear buffers (reset pointers anyway), change clock timing
>(go from 1 microsecond to 1 millisecond counts), etc.  We can do quite a
>bit in 12 instructions!  I'm sure people will want more than is possible, but
>the idea is that this is open to the demands of the experiment and we can
>work out the details on a case by case basis.
>
>>  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.
>>
>(6) happens all the time anyway, you don't need it unless it's a "dump data"
>situation where timing is of no concern.  Those are definitly things we can
>do.

  OK, (7) is left to do some other way, I imagine.

>>  In some cases it may be desirable to use a time base larger than 1 usec
>>  (e.g. 5 or 10 usecs).
>
>Yup, not a problem.  There's a 16 MHz base clock (or 12.5 if from the PC44)
>and up to 32 bits of divide down from there.  The counter is always 32 bits
>relative to that count rate (nominal count rate is 16 for a 1 MHz clock).
>
>>  What is the FIFO size on the PC32 ?  Is this shared memory that the
>>  UET and host computer could access at the same time ?
>
>32K X 64 bits.  The shared memory is only 1K X 32 bits, I've allocated that
>to be 256 X 64 bits for block transfer and the rest to be allocated for all
>other sorts of special data.
>
  Is "block transfer" the normal data transfer mode ? 

>>  Hope these are not too many questions for one message :)
>
>:-)  No problem!  I think this will do what people need, we may need to think
>hard about how we do things with this because it won't be the same as the
>previous system.  The advantage of this is that it's very flexable, the
>disadvantage is that we'll need to write more software at the lower level for
>each experimenter.  This is all on paper remember, we still need to try it out
>for real!

   Thanks.