[time-nuts] Sound Cards for locking to GPSDO 10 MHz references

Magnus Danielson magnus at rubidium.dyndns.org
Tue Jun 2 20:06:23 UTC 2009


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



More information about the time-nuts mailing list