[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mark IV Electronics Design



[Chris suggested using a PC parallel port like interface.]

Chris,

As outlined some time ago, this has long been done.  The problem was
to design an interface that was data push.  The receiving end has no 
control.  I did not want the read out from the chip to vary in speed as
would be the case with any computer interface.  i.e. from time to time
the computer wants the interface and holds things up.  So the design
is a straight byte parallel interface designed to go at up to a 20 MB or
so rate (for a short cable).  So it is not any standard interface.

Tom Droege

To: tass@wwa.com, "Griffing, Dan" <DAN.GRIFFING@kla-tencor.com>
From: Tom Droege <droege@wwa.com>
Subject: RE: Mark IV Electronics Design

[Dan et al suggested Ethernet or other fast data/control interfaces.]

Dan,

The basic problem is that I don't have a live in programmer, or
any way to muck with system functions.  When I run my computer
it from time to time goes off and does something.   This is the 
essence of multitasking systems. 

I want to unload the cameras in one continuous operation.  This
is because I have experience with systems where the computer
takes a few cycles here and there.  The result is a noise pattern in
the data because of the computer operations.  The way to avoid
this is to always read out the CCD with exactly the same spacing
between operations.  I have built big analog systems both ways.
This is a 16 bit system.  The only way I have found to make such
systems work to their potential is to make sure there is no 
asychronous stuff around.  

Believe me, I no longer build systems that interrupt.  I build systems
that poll.  If you poll you are always in control.  True, you may
find when you poll that you got somewhere too late.  But you
always know (if properly designed) that you did not get there in
time.  True, you can achieve the same thing with interrupts, but
it is harder.  

Now if I could just turn off all other system functions for 40 
seconds while I did a read, I might attempt some of the routes  that
yout describe.   But I don't know how, and if I did, the operating 
system would not like it.   At the minimum the system clock would
lose counts.  

While I am reading 32 Mbytes in 40 seconds with the current system,
there are ADC's around that would do it in 2 seconds or so.  So I want
to be able to transmit 32 Mbytes in 2 seconds over a 8 bit wide bus
without *any* variation in timing.  If you know how to do this let me
know.  

This is why I designed my own memory.  (Merle did it).  Now I can
run "data push" with no handshake.  My memory is always ready
since no one but me has access.  

Tom Droege