Advice? 10 kHz sampling on Intel pxa270 processor

I’m working on some instrumentation that must sample an A/D at 10 kHz and
simultaneously support a bare-bones Photon GUI and wired host interface
(RS232/USB 2.0/GPIB).

In the past our instruments have used QNX4 with fairly modest x86 processors
(200-233 mHz) and a custom FPGA to do the A/D sampling. In these designs the
FPGA samples and buffers the A/D data, stores min and max values, etc. and
the cpu reads data from the FPGA and does everything else. In this
configuration the cpu may burst up to 90% utilization.

We are embarking on development of a new instrument, and are wondering
whether todays processors have enough power to eliminate the FPGA. At this
time we are looking at QNX6 and the Intel PXA270 processor.

Is this pie-in-the-sky thinking, or might this just be possible? Anyone done
something similar?

Ken Schumm wrote:


Is this pie-in-the-sky thinking, or might this just be possible? Anyone done
something similar?

No. I have done 10Khz 16 bit with QNX4 on a 450Mhz processor with no
hardware assist. 10Khz was the absolute limit at that time. With a
dual core 2.4GHz Opteron, I am certain it would not even sweat doing this.

“Rennie Allen” <rnogspamallen@comcast.net> wrote in message
news:d4c0hq$lbu$1@inn.qnx.com

Ken Schumm wrote:


Is this pie-in-the-sky thinking, or might this just be possible? Anyone
done
something similar?

No. I have done 10Khz 16 bit with QNX4 on a 450Mhz processor with no
hardware assist. 10Khz was the absolute limit at that time. With a
dual core 2.4GHz Opteron, I am certain it would not even sweat doing this.

In our previous designs we’ve done 8 kHz with the 233 mhz x86 compatible
processors, but the FPGA was necessary to sample and buffer 3-deep to
overcome jitter caused by ISA bus video. It’s jitter that has me worried
most.

In article <d4g803$nhv$1@inn.qnx.com>, NOSPAM@qsolv.com says…

“Rennie Allen” <> rnogspamallen@comcast.net> > wrote in message
news:d4c0hq$lbu$> 1@inn.qnx.com> …
Ken Schumm wrote:


Is this pie-in-the-sky thinking, or might this just be possible? Anyone
done
something similar?

No. I have done 10Khz 16 bit with QNX4 on a 450Mhz processor with no
hardware assist. 10Khz was the absolute limit at that time. With a
dual core 2.4GHz Opteron, I am certain it would not even sweat doing this.

In our previous designs we’ve done 8 kHz with the 233 mhz x86 compatible
processors, but the FPGA was necessary to sample and buffer 3-deep to
overcome jitter caused by ISA bus video. It’s jitter that has me worried
most.

Hello Ken,

You would face the similar problem if you were using modern PC class
computer and making your A/D as a PCI extention board. Just because the
same reason: AGP video card or some other peripheral device may initiate
PCI burst and you have to provide some FIFO within A/D board to collect
samples till your board has a chance to initiate data transaction in
order to supply acquired data to CPU (system memory).

But you said you’re looking at PXA270 processor, that mean you probably
wouldn’t have such a bus like PCI/ISA at all. Since PXA270 doesn’t have
on-chip A/D convertor, probably you will have to connect the external
one to the synchronous serial port (SSP). SSP provides 16 samples deep
FIFO, 32 bits wide, so it looks like it’s much deeper than your old FPGA
design. It tends me to believe you should not worry about the h/w issue
in question. I do not have hands-on experience with QNX running on
PXA270, so I can’t comment any further details or software issues you
may meet. Any software may implement the internal-bus peripheral (IBP)
transaction handling so poorly that 16 samples deep FIFO wouldn’t help
:slight_smile:

P.S. I assume you have single A/D channel or multichannel conversion
with a total rate up to 10 000 samples per second, samples are up to 16
bits wide.

Cheers,
Eduard.

Ken Schumm wrote:

“Rennie Allen” <> rnogspamallen@comcast.net> > wrote in message
No. I have done 10Khz 16 bit with QNX4 on a 450Mhz processor with no
hardware assist. 10Khz was the absolute limit at that time. With a
dual core 2.4GHz Opteron, I am certain it would not even sweat doing this.


In our previous designs we’ve done 8 kHz with the 233 mhz x86 compatible
processors, but the FPGA was necessary to sample and buffer 3-deep to
overcome jitter caused by ISA bus video. It’s jitter that has me worried
most.

Have a read of the topic “Serious execution time jitter of thread” started on 2 April 2005.

While there is many hardware causes for jitter I feel it would be a badly configured ISA video card that would create that sort of interference since most were simple frame buffers that the CPU feed. It sounds more like you were dealing with some other hw problem or a multitasking issue.

Btw: 10 kHz interrupts is a breeze. In fact I don’t see any reason why a 486 couldn’t do the job.

Evan

Ken Schumm wrote:

I’m working on some instrumentation that must sample an A/D at 10 kHz and
simultaneously support a bare-bones Photon GUI and wired host interface
(RS232/USB 2.0/GPIB).

In the past our instruments have used QNX4 with fairly modest x86 processors
(200-233 mHz) and a custom FPGA to do the A/D sampling. In these designs the
FPGA samples and buffers the A/D data, stores min and max values, etc. and
the cpu reads data from the FPGA and does everything else. In this
configuration the cpu may burst up to 90% utilization.

We are embarking on development of a new instrument, and are wondering
whether todays processors have enough power to eliminate the FPGA. At this
time we are looking at QNX6 and the Intel PXA270 processor.

Is this pie-in-the-sky thinking, or might this just be possible? Anyone done
something similar?


Our lab has an application that runs on single processor 3.6 GHz Intel

x86 machines that samples 12 bit A/D at up to 2 giga samples per second
and supports a full featured GUI (menus, dialog boxes, and multiple data
display windows). We use PCI A/D boards (Measurement Computing and UEI)
that can DMA the data.The interrupt rate can be up to 4 KHz, resulting
in a jitter of 250 usec. One thing that we found to be critical is the
ability to specify the IRQ number of the slot containing the A/D board.

“JohnMcClurkin” <jwm@lsr.nei.nih.gov> wrote in message
news:d4imt9$i67$1@inn.qnx.com

Ken Schumm wrote:
I’m working on some instrumentation that must sample an A/D at 10 kHz and
simultaneously support a bare-bones Photon GUI and wired host interface
(RS232/USB 2.0/GPIB).

In the past our instruments have used QNX4 with fairly modest x86
processors
(200-233 mHz) and a custom FPGA to do the A/D sampling. In these designs
the
FPGA samples and buffers the A/D data, stores min and max values, etc.
and
the cpu reads data from the FPGA and does everything else. In this
configuration the cpu may burst up to 90% utilization.

We are embarking on development of a new instrument, and are wondering
whether todays processors have enough power to eliminate the FPGA. At
this
time we are looking at QNX6 and the Intel PXA270 processor.

Is this pie-in-the-sky thinking, or might this just be possible? Anyone
done
something similar?


Our lab has an application that runs on single processor 3.6 GHz Intel x86
machines that samples 12 bit A/D at up to 2 giga samples per second and
supports a full featured GUI (menus, dialog boxes, and multiple data
display windows).

2giga sample, huh? Since it’s 12 bit that amounts do 24giga bit per
seconds. Assuming 12 bit of A/D are packed, that’s 300M byte of data per
seconds. Ubviously there has to be some sort of buffering because PCI bus
can’t handle it (unless it 64 bit 66Mzh)

We use PCI A/D boards (Measurement Computing and UEI) that can DMA the
data.The interrupt rate can be up to 4 KHz, resulting in a jitter of 250
usec. One thing that we found to be critical is the ability to specify the
IRQ number of the slot containing the A/D board.

“JohnMcClurkin” <jwm@lsr.nei.nih.gov> wrote in message
news:d4imt9$i67$1@inn.qnx.com
[…]

Our lab has an application that runs on single processor 3.6 GHz Intel
x86 machines that samples 12 bit A/D at up to 2 giga samples per second
and supports a full featured GUI (menus, dialog boxes, and multiple data
display windows). We use PCI A/D boards (Measurement Computing and UEI)
that can DMA the data.The interrupt rate can be up to 4 KHz, resulting
in a jitter of 250 usec. One thing that we found to be critical is the
ability to specify the IRQ number of the slot containing the A/D board.

On our old instruments with ISA video we’re processing interrupts at 8 kHz
on a 486/133. The only reason the FPGA has a three deep fifo is because the
ISA video seizes the bus from time to time. Normally the ISR runs to
completion in less than 35us, but when the video kicks in it can add up to
80us of latency, thus the fifo requirement.

I’m not the least bit worried about the interrupt load, but am concerned
that without the FPGA the cpu must do a lot more work in the ISR. Basically,
it needs to maintain a 64 sample timestamped circular buffer looking for a
peak, then scan the fifo to extract the min/max values, do peak-base
subtraction, check for peak, base, and subtraction errors on each sample,
implement a trigger holdoff strategy, and probably some other stuff I can’t
think of right now. Actually as I think about it, it may not be that bad.

Thanks for your thoughtful response, Eduard.

The serial A/D tied to the serial port is interesting, but each sample must
be associated with a high resolution timestamp from another source so that
may not work.

In article <d4jc9a$47v$1@inn.qnx.com>, NOSPAM@qsolv.com says…

Thanks for your thoughtful response, Eduard.

The serial A/D tied to the serial port is interesting, but each sample must
be associated with a high resolution timestamp from another source so that
may not work.

I feel you’re experiencing some mess thinking about old ISA based design
and new one based on PXA270. I meant exactly SSP, it could work as SPI
(synchronous peripheral inrterface) supported by many ADC manufacturers
(Microchip, AD, Atmel, etc., datasheet for PXA 270 refers to it as
Motorola SPI). Also SSP may support TI SSP protocol, National
Semiconductor Microwire, or programmable serial protocol (PSP). Actually
just several ADC supply samples in parallel form, rest of them transmit
data by some serial interface. 10 kHz samples rate is nothing for up to
13 Mbps SSP of your PXA, but ADC chip needs just few pins for interface
(that’s why chip makers prefer serial interfaces). SSP is exactly
designated port to connect external device like ADC (or external MCU
with ADC on-chip with price tag about 6 bucks in single quantity :slight_smile:). Of
course, it supposes re-doing a lot of hardware stuff. If you’re thinking
of keeping old ISA design but without any FIFO (FPGA), I doubt PXA would
help you. It’s up to you (or your co-workers involved in hardware
design) to accomplish every sample with a timestamp. What PXA will have
to do is just clocking external device (“black box”, or “ADC”) and
receive data bit by bit from that “box”. It’s up to you to decide that
your black box supplies, says, 32 bits per sample, low 12 bits are
voltage value and 20 upper bits are timestamp (you see, this is again
small FPGA and ADC - I doubt there is an ADC with some timestamping
mechanism on market, maybe some ADC capable MCU can do the trick).

LCD controller is also built on chip, so there also will be concurrent
requests on IBP, but 16 levels of FIFO provided by SSP should eliminate
the problems. Although I think you may want to use higher end of ~600MHz
PXA270 CPU if you need extensive graphics. I have never seen QNX running
on PXA270, but on regular PC Photon is not fastest GUI available.

All that math you listed in different thread worth no computer power (if
we speak of i386 or better). Though, I wouldn’t do that in ISR, but in
interrupt handling thread.

Regards,
Eduard.

Ken Schumm wrote:

In our previous designs we’ve done 8 kHz with the 233 mhz x86 compatible
processors, but the FPGA was necessary to sample and buffer 3-deep to
overcome jitter caused by ISA bus video. It’s jitter that has me worried
most.

What kind of jitter can you tolerate ? 16Khz equates to a period of
0.0000625 sec, PCI latency timers are expressed in clocks. Let’s take a
66Mhz PCI bus for a clock period of 0.000000015 sec.

(.0000000015/0.0000625)*100 = 0.024% granularity of control

OK, let’s say the video cards latency timer is set to 10; then that
yields .24% (1/4 of a percent) jitter on a .0000625 sec sample period.

Rennie

Mario Charest wrote:

“JohnMcClurkin” <> jwm@lsr.nei.nih.gov> > wrote in message
news:d4imt9$i67$> 1@inn.qnx.com> …

Ken Schumm wrote:

I’m working on some instrumentation that must sample an A/D at 10 kHz and
simultaneously support a bare-bones Photon GUI and wired host interface
(RS232/USB 2.0/GPIB).

In the past our instruments have used QNX4 with fairly modest x86
processors
(200-233 mHz) and a custom FPGA to do the A/D sampling. In these designs
the
FPGA samples and buffers the A/D data, stores min and max values, etc.
and
the cpu reads data from the FPGA and does everything else. In this
configuration the cpu may burst up to 90% utilization.

We are embarking on development of a new instrument, and are wondering
whether todays processors have enough power to eliminate the FPGA. At
this
time we are looking at QNX6 and the Intel PXA270 processor.

Is this pie-in-the-sky thinking, or might this just be possible? Anyone
done
something similar?



Our lab has an application that runs on single processor 3.6 GHz Intel x86
machines that samples 12 bit A/D at up to 2 giga samples per second and
supports a full featured GUI (menus, dialog boxes, and multiple data
display windows).


2giga sample, huh? Since it’s 12 bit that amounts do 24giga bit per
seconds. Assuming 12 bit of A/D are packed, that’s 300M byte of data per
seconds. Ubviously there has to be some sort of buffering because PCI bus
can’t handle it (unless it 64 bit 66Mzh)

Oops. I meant 2 mega samples / sec. Sorry.



We use PCI A/D boards (Measurement Computing and UEI) that can DMA the
data.The interrupt rate can be up to 4 KHz, resulting in a jitter of 250
usec. One thing that we found to be critical is the ability to specify the
IRQ number of the slot containing the A/D board.

“Rennie Allen” <rnogspamallen@comcast.net> wrote in message
news:d4kerf$r04$1@inn.qnx.com

Ken Schumm wrote:


In our previous designs we’ve done 8 kHz with the 233 mhz x86 compatible
processors, but the FPGA was necessary to sample and buffer 3-deep to
overcome jitter caused by ISA bus video. It’s jitter that has me worried
most.

What kind of jitter can you tolerate ?

[…]

That’s something we’re trying to figure out now. It’s never been an issue
before since it’s always been done in hardware. Thanks a lot for your
numbers, it’s very helpful.

In article <d4kerf$r04$1@inn.qnx.com>, rnogspamallen@comcast.net says…

What kind of jitter can you tolerate ? 16Khz equates to a period of
0.0000625 sec, PCI latency timers are expressed in clocks. Let’s take a
66Mhz PCI bus for a clock period of 0.000000015 sec.

(.0000000015/0.0000625)*100 = 0.024% granularity of control

OK, let’s say the video cards latency timer is set to 10; then that
yields .24% (1/4 of a percent) jitter on a .0000625 sec sample period.

Rennie,

According to PCI local bus specification, paragraph 3.5, it’s not that
simple as you described. Although, I would agree 10 kHz samples rate is
a small bandwidth for even ISA, not saying about 33 MHz 32 bit PCI bus.
I don’t see any reason to have additional FIFO - except they need FPGA
for something else like timestamps, and why not to use some additional
features provided.

I just realized looking at your numbers, interrupt rate for 10 kHz ADC
would be very close to that that’s produced by serial UART working at
115200 baud without FIFO. It’s not a task for 386DX40 - in my serial
sniffer that runs on that ancient hardware I handle two UARTs with FIFO
disabled at up to 115200 baud without any problems (though without GUI
and QNX :slight_smile:)

Eduard.

ed1k wrote:

Rennie,

According to PCI local bus specification, paragraph 3.5, it’s not that
simple as you described.

Para 3.5 gives an example of high bandwidth (i.e. high latency)
application where the latency is 2.16 usec (.00000216 sec). For Ken’s
example even a system not optimized for low latency (I would assume Ken’s
systems would be optimized for low latency) would exhibit ~3% jitter on
a 16Khz sample rate.

I stand by the assertion that a .25% worst case jitter on a 16Khz (16bit)
sample rate is achievable for a system with just Ken’s PCI 2.2 compliant
custom card and a PCI 2.2 compliant video card on a 66Mhz PCI bus,
where the latency timers are adjusted appropriately.

Rennie

“Ken Schumm” <NOSPAM@qsolv.com> wrote in message
news:d4mdgh$c64$1@inn.qnx.com

“Rennie Allen” <> rnogspamallen@comcast.net> > wrote in message
news:d4kerf$r04$> 1@inn.qnx.com> …
Ken Schumm wrote:


In our previous designs we’ve done 8 kHz with the 233 mhz x86
compatible
processors, but the FPGA was necessary to sample and buffer 3-deep to
overcome jitter caused by ISA bus video. It’s jitter that has me
worried
most.

What kind of jitter can you tolerate ?

[…]

That’s something we’re trying to figure out now. It’s never been an issue
before since it’s always been done in hardware. Thanks a lot for your
numbers, it’s very helpful.

Ken, you mentioned the PXA270 XScale process, and I don’t beleive these
process have a PCI bus. How do you plan on interfacing your A/D device with
it.

Have you consider some flavor of embedded PowerPC which include A/D
converter that support DMA.

Bad communication. Although the laser pulses being measured arrive at a
maximum rate of 10 KHz, the pulse waveform is important. To sample the
waveform requires 2-20 Mega samples/second. We need to have a DSP or FPGA
front end to the processor. That being the case the customer is going to
reuse a lot of the code from another instrument. Unfortunately, that means
Nucleus. Blech.

In article <426FC413.5090703@csical.com>, rallen@csical.com says…

ed1k wrote:
Rennie,

According to PCI local bus specification, paragraph 3.5, it’s not that
simple as you described.

Para 3.5 gives an example of high bandwidth (i.e. high latency)
application where the latency is 2.16 usec (.00000216 sec). For Ken’s
example even a system not optimized for low latency (I would assume Ken’s
systems would be optimized for low latency) would exhibit ~3% jitter on
a 16Khz sample rate.

I stand by the assertion that a .25% worst case jitter on a 16Khz (16bit)
sample rate is achievable for a system with just Ken’s PCI 2.2 compliant
custom card and a PCI 2.2 compliant video card on a 66Mhz PCI bus,
where the latency timers are adjusted appropriately.

Rennie

Rennie,

I said I agree with you that jitter would be acceptable even for a PCI
2.1 (33MHz) compliant system not optimized for low latency.

I would name a time taken to transport a sample from ADC to system
memory as an acceptable propagation delay in a digital processing
system, and usually sample has to be read before the next sample is
ready. For 10 kHz sample rate this delay should be less than 0.1 ms.
This is quite a chunk of time even for ISA bus. Any good designed even
fast responding DSP system wouldn’t make a controlling decision
analizing just one sample ASAP - it could be just ADC glitch. What does
matter in any DSP system is a jitter of sampling rate, but it should be
high accuracy clock of ADC and it’s a way beyond of this discussion.

As a side note, every one can play the role of don Kihot, and actually
many people do (recently somewhere else someone asked how to achieve
microsecond accuracy for 3.5T timeout in the end of modbus packet).

Eduard.

In article <d4p8on$fkr$1@inn.qnx.com>, NOSPAM@qsolv.com says…

Bad communication. Although the laser pulses being measured arrive at a
maximum rate of 10 KHz, the pulse waveform is important. To sample the
waveform requires 2-20 Mega samples/second. We need to have a DSP or FPGA
front end to the processor. That being the case the customer is going to
reuse a lot of the code from another instrument. Unfortunately, that means
Nucleus. Blech.

Ah, that explains a lot :slight_smile:
Eduard.

ed1k wrote:

As a side note, every one can play the role of don Kihot, and actually
many people do (recently somewhere else someone asked how to achieve
microsecond accuracy for 3.5T timeout in the end of modbus packet).

Don Quixote and modbus ? Sorry, I don’t follow…

Rennie