[time-nuts] IRIG B
jimlux at earthlink.net
Wed May 26 03:43:43 UTC 2010
Hal Murray wrote:
>> The IRIG-B decoder work I did was implemented on power systems relays &
>> disturbance recorders several years ago, then I left the company and in the
>> meantime, they changed over to an FPGA implementation and skipped the
>> processor altogether. Now I'm back with that same company (although
>> ownership has changed), but I haven't yet had a chat with the new FPGA
>> designer to find out how he did it :-)
> Interesting. I'd like to know why they switched to FPGA.
> I thought the consensus in the FPGA world was that if you could do it in
> software that was probably the better way to go. The main idea is that it's
> easier to hire programmers than FPGA designers.
> I'd expect silicon costs to be roughly equal. In a FPGA you are "wasting" a
> lot of silicon for routing. In a CPU, you are wasting it on instruction
> decoding. Both are high volume parts riding the crest of Moore's Law. Of
> course, algorithm details may push you one way or the other.
Maybe you have an all FPGA design otherwise, and just want to add IRIG
Maybe you've got both FPGA and CPU resources in the box, and the CPU is
used for non-real-time-critical stuff, and you want to do timing in
hardware (that's my situation).
Not all applications are high volume.. even a mid volume app might need
enough glue that one FPGA is a better choice than a uC and a FPGA.
More information about the time-nuts