Alberto di Bene skrev:
Magnus Danielson wrote:
No need to switch on the soldering iron...
Never do in hardware what can be done in software.... :-)
Respectfully I disagree. There are tasks which is better managed by
software and tasks which is better managed by hardware. In the world
of FPGAs, it is also worth mentioning that some tasks is best done there.
The big trick is to find a balance between various methods, available
resources, partitioning of the problem, doing it on time and achieving
the needed performance.
Of course you are right, the best solution must be decided case by case.
But the biggest plus of the software is that it can be changed on the fly,
without an expensive reworking station, and the manual ability to correctly
use it. And a side effect is speed : you can test many variants of a
solution
in a time frame of a few minutes. Not so easily doable with hardware
changes.
This is why we do alot of things in FPGAs today, and in the FPGAs we
often put dedicated DSPs of various complexity, often adapted to their
task. Keeping quick turn-around is on our mind, but in general, the
shorter turn-around, the poorer testing usually happends, and the
sloopier design is often found, and the longer it takes to get the job done.
In general, a CPU is suitable for doing non-common tasks. More dedicated
designs like firmware and hardware is suitable to do things which is
essentially the same but happends over and over and over and often at a
high speed. Such monotonic tasks just waste energy, space and
complexity when done in CPUs. The problem with a generic CPU is that it
is generic, so it can do all kinds of tasks, which makes timing-critical
bulk-processing tasks problematic to combine with sporadic and possibly
high-dynamic processing. Splice the bulk off to some dedicated
processing, which can be done in another CPU, and better performance is
yielded. There are loads of designs where a few well thought 8-bit
processors work together and shine over a more modern fancy design.
One such example is found in the SR-620 which has a Zilog Z-8000
processor as main CPU and a Z-80 co-processor which only does the X-Y
vector display. The Z-80 has so small program that it is loaded into
SRAM from the Z-8000 as it boots.
The HP 5334A has actually 3 different 3870 processor, one for overall
control, one for measurements and one for GPIB.
Hmm, do you get a feeling that I am actually object very much to just
toss it into the processor. I think you are right. :)
Nothing wrong with software, but use it wisely. Build the test-benches
as if you where doing a ASIC or full-custom design and thus also think
about each compile costing you milions of dollars and a pipe-line depth
of many months (6-9).
I guess I am becomming more conservative by the day. From my own and
others mistakes and succsesses.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
