Denny Esterline wrote:

>
>>You still need SOME buffer memory to get break-free continuous sampling.
>>If you have to do the buffer anyway, you might as well make it big.

> That would depend on several things, mostly the parts chosen. If the
> interface is anything similar to the FT245 FIFO arrangement, you might be
> able to get away from the memory altogether.

NO, you need SOME memory to buffer the data into packets, and
to bridge the gap caused by bus negotiation and other overheads.

> A system with a buffer needs several more things to make it effective.
> First you add address generation,

Yes.

> than a variable sample rate clock,

Not necessarily. Just variable rate writing to RAM.
Throw away unneeded samples by inhibiting the write strobe.

  of
> course you also need a trigger. 

Only if you're not shipping everything to the PC at full rate.

? Then the trigger gets complicated because
> you've got lots of different channels to trigger on (or combinations of all
> of them),

If you're talking l/a trigging, the design for that is well known.
LATCH, XOR and AND into wired or. You have one latch for level
and one for don't care.

Since you have an A/D you do your triggering in the digital domain
looking at the conversion result. That way you get 1 LSB resolution
for slope.

> then there's multistage triggering. 

A function of the FPGA design.

> Of course then you (or I)
> want to add pre and post triggering. Just the triggering alone becomes a
> nontrivial exercise in digital logic,

It IS trivial. You just need to memorize the address of the trigger,
and manipulate your display accordingly.

> and forget about a PIC for that - if

Of course.

> I can't toggle a single pin faster than a couple MHz, I certainly can't do
> any of this for a 10 to 100 Msps system.

All the PIC has to do is control the bus controller, and interpret
commands and load FPGA registers. It does NOTHING at sample rates.

> A system with a sample rate capable datapipe gets rid of all those parts,

Yes. But you then need a damn fast PC on the far end to keep up,
even if only buffering to PC RAM. Winblows is notorious for locking
out interrupts and causing dropped data. That's why anything streaming
needs DMA.

> you can replicate them in software at the PC end. Yes, there's limitations
> of the harddrive speed, but that only becomes an issue if you want to store
> 100's of meg of data. If all you'll need is a few meg (still larger than
> any likely hardware buffer) the software just discards the data until the
> trigger condition is met (might be a little more involved with a circular
> buffer for pretrigger)

Not at all. Just fix the MSBs of the address to get a binary sized
circular buffer of whatever size you like. The address generator
wraps the lower bits, until trigger, which increments the upper
bits to put the 'post trigger' data into a new buffer.

> then captures for a specified depth. Just because
> the PC receives the data doesn't mean it needs to save it all :-)

True.

>>I'm hoping Bob uses standard DDR RAM and connectors, and reads the
>>SID (serial ID) that tells the FPGA what timing to use on the RAM.
>>Then you can use your cast-off RAM (from when you upgraded your PC).
>>If physical size is an issue, we could look at SDRAM for laptops,
>>with a top speed penalty. RAM is relatively cheap, so there
>>is no reason to skimp on it.
> 
> I don't think PC RAM is a likely contender. Since it's dynamic, the refresh
> generation would add significantly to the hardware complication factor.

Not at all, as long as the minimum allowed sample rate is greater
than the minimum refresh rate (2 milli sec these days?) Today's
RAM autorefreshes on read/write so you just have to keep rereading
a small part of it if you're not actually using it.
And it's actually easier to address DRAM because of the address
multiplexing. Fewer pins needed for same size in Static.

>>That does push a fair load onto the PC, so no using old laptops.
>>That also gets around the aliasing problem since the LPF
>>can be done in the PC.
> 
> Granted, But I guess that means we have to decide what is considered an
> "old PC". We're definitely out of the realm of a 386 with a monochrome
> screen. I would guess (and I invite discussion on this point) that we'd be
> looking at maybe a PII @ 500+MHz, 128+Mb ram, win9x (or your favorite
> flavor of Linux - just not win2k or XP)?

As long as it has USB/ethernet, it should be able to do what is needed,
IF the data is fully buffered on the MA unit. The difference will
be screen refresh rate.

>>And you get a box to put the rest of the guts in.
>>
> With a P/S! (though I'm sure it'd need more regulation to work with high
> end analog...)

Of course.

Robert
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist