Reply by Patrick Dubois●January 17, 20082008-01-17
On 16 jan, 22:31, "Vladimir Vassilevsky" <antispam_bo...@hotmail.com>
wrote:
> Sounds like a custom board with BlackFin-537 CPU. One week to do the
> hardware, one month to do the software.
I'd really like to see such a board done in one week. Schematics alone
would take more than that (especially if you're using new parts). I'm
not too familar with DSPs but for FPGAs, documentation is several
hundred pages long and you would be foolish to design a board without
reading it all, it's full of tricky gotchas. Now add the layout time
to that and you are WELL over one week. Maybe one week if you've
designed tens of similar boards but not too many people are in this
situation.
> >These requirements are quite low-end in terms of throughput but we
> >also have a project where we do data processing at 320 Mbytes/s.
>
> It depends. What exactly are you doing at 320M/s?
Real-time data processing for a Fourier transform imaging
spectrometer, but that's not the point. This is probably always going
to be custom boards.
> > I'm
> >not hoping for an architecture that can do both but I just wanted to
> >point out that we're not only doing 150 Hz data processing ;)
>
> Then what is your point?
My point is that we span a large spectrum of data processing
requirements, so idealy the chosen solution would be flexible. Like
cPCI for example might work. There is a large variety of boards
available, including beasts with multiple FPGAs and DSPs. We would
like to have that option later on.
> >One last thing is that we would like the whole system to be as plug-
> >and-play as possible (software-wise). We would like to focus on our
> >application instead of wasting time making all the boards talk to each
> >other.
>
> Is the socket programming too much work?
It depends, our inexperience is the problem. Say we want to create our
own custom board for our chosen modular architecture (which will
likely happen), I'd like the integration to be as easy as possible on
the software side. The easiest would be memory mapped IO in a DSP for
example, and the hardest (for me anyway) would be writing the
necessary driver in Linux or Windows if we go the embedded-PC way.
> My experience is that the universal solutions don't work, and the modular
> approach doesn't work too. If the goal is the particular application or the
> range of applications, then the best way is to be application specific.
The goal is to save time and money. Maybe COTS is not the option but
we are willing to give it a shot. I believe that the key will be to
find the _right_ modular approach and even more importantly, the right
vendor with good support.
Thanks for sharing your experience!
Patrick
Reply by Habib Bouaziz-Viallet●January 17, 20082008-01-17
Le Wed, 16 Jan 2008 21:31:44 -0600, Vladimir Vassilevsky a écrit:
> "Patrick Dubois" <prdubois@gmail.com> wrote in message
> news:2dc7c9a1-f245-4c5f-9e02-85ae7f2ff105@d70g2000hsb.googlegroups.com...
> Hello,
>
>>The company I work for is used to making its own custom boards (mainly
>>FPGA-centric) but this is time consuming and expensive,
>
> ????
>
>> so we're
>> cooking at moving more and more to COTS.
>
> My experience is the opposite; the universal solutions are expensive and
> overcomplicated; you are adding the problems of somebody else to your own
> problems.
>
>
>>Ideally, we would like to use a standard interconnect bus so that we
>>can mix and match cards from different manufacturers to assemble a
>>complete system, and possibly build our own expansion cards if
>>necessary. There seems to be lots of competing standards: PC104,
>>PC104+, Compact PCI, VME, PMC, PXI, etc. The problem I see with this
>>approach is that it seems that all these systems are CPU-centric,
>>requiring a central CPU running some OS. Since we are embedded guys,
>>this may be a problem, as we are more used to program
>>microcontrollers, DSP and FPGAs than Linux drivers.
>
>>The other option is to go with a single signal processing company and
>>their propriatary bus (i.e. Nallatech and DIME modules, Sundance Local
>>Bus, Traquair micro-line family, Hunt Engineering HERON, etc). This
>>option seems more natural to us but unfortunately we couldn't mix
>>boards from different vendors, so the choice would be much more
>>limited.
>
> The real question is what goals are you trying to accomplish.
>
>
>>Just to give a little more information, I'll list our current
>>requirements for one particular project (although we would like the
>>chosen architecture/bus to be as flexible as possible for future
>>projects):
>>- 1x DSP processor (speed is not too important right now, but the
>>higher the better to be future-proof)
>>- 2x ±10V ADC input (very low frequency, 150 Hz)
>>- 2x ±10V DAC output (very low frequency, 150 Hz)
>>- Several GPIOs, say 16
>>- 8x RS-232 ports
>>- 16 analog inputs multiplexed to one ADC (could also be one ADC with
>>4 GPIO to control an external mux).
>>- 1x Ethernet port (nice-to-have but not absolutely necessary)
>
> Sounds like a custom board with BlackFin-537 CPU. One week to do the
> hardware, one month to do the software.
Hey Vladimir you're late. Purchase the hardware and 1 month minus a week
to do the software.
>>These requirements are quite low-end in terms of throughput but we also
>>have a project where we do data processing at 320 Mbytes/s.
>
> It depends. What exactly are you doing at 320M/s?
>
>> I'm
>>not hoping for an architecture that can do both but I just wanted to
>>point out that we're not only doing 150 Hz data processing ;)
>
> Then what is your point?
>
>>One last thing is that we would like the whole system to be as plug-
>>and-play as possible (software-wise). We would like to focus on our
>>application instead of wasting time making all the boards talk to each
>>other.
>
> Is the socket programming too much work?
>
>>Can anyone share their experience or give any advice about which way we
>>should go?
>
> My experience is that the universal solutions don't work, and the
> modular approach doesn't work too. If the goal is the particular
> application or the range of applications, then the best way is to be
> application specific.
>
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Consultant
> www.abvolt.com
--
HBV
Reply by Vladimir Vassilevsky●January 16, 20082008-01-16
"Patrick Dubois" <prdubois@gmail.com> wrote in message
news:2dc7c9a1-f245-4c5f-9e02-85ae7f2ff105@d70g2000hsb.googlegroups.com...
Hello,
>The company I work for is used to making its own custom boards (mainly
>FPGA-centric) but this is time consuming and expensive,
????
> so we're
> cooking at moving more and more to COTS.
My experience is the opposite; the universal solutions are expensive and
overcomplicated; you are adding the problems of somebody else to your own
problems.
>Ideally, we would like to use a standard interconnect bus so that we
>can mix and match cards from different manufacturers to assemble a
>complete system, and possibly build our own expansion cards if
>necessary. There seems to be lots of competing standards: PC104,
>PC104+, Compact PCI, VME, PMC, PXI, etc. The problem I see with this
>approach is that it seems that all these systems are CPU-centric,
>requiring a central CPU running some OS. Since we are embedded guys,
>this may be a problem, as we are more used to program
>microcontrollers, DSP and FPGAs than Linux drivers.
>The other option is to go with a single signal processing company and
>their propriatary bus (i.e. Nallatech and DIME modules, Sundance Local
>Bus, Traquair micro-line family, Hunt Engineering HERON, etc). This
>option seems more natural to us but unfortunately we couldn't mix
>boards from different vendors, so the choice would be much more
>limited.
The real question is what goals are you trying to accomplish.
>Just to give a little more information, I'll list our current
>requirements for one particular project (although we would like the
>chosen architecture/bus to be as flexible as possible for future
>projects):
>- 1x DSP processor (speed is not too important right now, but the
>higher the better to be future-proof)
>- 2x �10V ADC input (very low frequency, 150 Hz)
>- 2x �10V DAC output (very low frequency, 150 Hz)
>- Several GPIOs, say 16
>- 8x RS-232 ports
>- 16 analog inputs multiplexed to one ADC (could also be one ADC with
>4 GPIO to control an external mux).
>- 1x Ethernet port (nice-to-have but not absolutely necessary)
Sounds like a custom board with BlackFin-537 CPU. One week to do the
hardware, one month to do the software.
>These requirements are quite low-end in terms of throughput but we
>also have a project where we do data processing at 320 Mbytes/s.
It depends. What exactly are you doing at 320M/s?
> I'm
>not hoping for an architecture that can do both but I just wanted to
>point out that we're not only doing 150 Hz data processing ;)
Then what is your point?
>One last thing is that we would like the whole system to be as plug-
>and-play as possible (software-wise). We would like to focus on our
>application instead of wasting time making all the boards talk to each
>other.
Is the socket programming too much work?
>Can anyone share their experience or give any advice about which way
>we should go?
My experience is that the universal solutions don't work, and the modular
approach doesn't work too. If the goal is the particular application or the
range of applications, then the best way is to be application specific.
Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com
Reply by Patrick Dubois●January 16, 20082008-01-16
Hello,
The company I work for is used to making its own custom boards (mainly
FPGA-centric) but this is time consuming and expensive, so we're
looking at moving more and more to COTS.
Ideally, we would like to use a standard interconnect bus so that we
can mix and match cards from different manufacturers to assemble a
complete system, and possibly build our own expansion cards if
necessary. There seems to be lots of competing standards: PC104,
PC104+, Compact PCI, VME, PMC, PXI, etc. The problem I see with this
approach is that it seems that all these systems are CPU-centric,
requiring a central CPU running some OS. Since we are embedded guys,
this may be a problem, as we are more used to program
microcontrollers, DSP and FPGAs than Linux drivers.
The other option is to go with a single signal processing company and
their propriatary bus (i.e. Nallatech and DIME modules, Sundance Local
Bus, Traquair micro-line family, Hunt Engineering HERON, etc). This
option seems more natural to us but unfortunately we couldn't mix
boards from different vendors, so the choice would be much more
limited.
Just to give a little more information, I'll list our current
requirements for one particular project (although we would like the
chosen architecture/bus to be as flexible as possible for future
projects):
- 1x DSP processor (speed is not too important right now, but the
higher the better to be future-proof)
- 2x =B110V ADC input (very low frequency, 150 Hz)
- 2x =B110V DAC output (very low frequency, 150 Hz)
- Several GPIOs, say 16
- 8x RS-232 ports
- 16 analog inputs multiplexed to one ADC (could also be one ADC with
4 GPIO to control an external mux).
- 1x Ethernet port (nice-to-have but not absolutely necessary)
These requirements are quite low-end in terms of throughput but we
also have a project where we do data processing at 320 Mbytes/s. I'm
not hoping for an architecture that can do both but I just wanted to
point out that we're not only doing 150 Hz data processing ;)
One last thing is that we would like the whole system to be as plug-
and-play as possible (software-wise). We would like to focus on our
application instead of wasting time making all the boards talk to each
other.
Can anyone share their experience or give any advice about which way
we should go?
Sorry for the long post and thanks in advance!
Patrick