[time-nuts] Software

[jimlux]

On 10/2/18 8:39 PM, Hal Murray wrote:
> 
> richard at karlquist.com said:
>> At least for me. I took 1 course in Fortran 50 years ago, and that was the
>> extent of my software education. During my whole career, I have too busy
>> being well paid to design hardware, to have any time left over to learn
>> software.  After Fortran was over, there was the Pascal fad, then the C fad,
>> etc, now I guess Python is the latest. Never got involved in any of that.
> 
> Interesting.
> 
> All the hardware people I've worked with have been reasonably happy working on
> software.  That may be more common in the digital world.
> 
> As an example, most people write PAL code as logic equations rather than
> schematics.
> 
> It would be interesting to compare the costs of hardware vs software for a big
> chip project over time.
> 
> 
> 
Like most things, "it depends" - here, I'm going to talk about embedded 
applications (as would be typical for a "time-nuts" widget of some sort)

 From a "first unit" cost standpoint, in general software is 
cheaper/easier than FPGA code. It might also be cheaper in hardware on 
recurring cost basis. Purpose designed processors tend to be faster and 
lower power, and cheaper than FPGA instantiated processors - ultimately, 
it takes less sand to make them.




There are orders of magnitude more C programmers available than FPGA 
folks. And there are more of both of them then folks who can design an ASIC.

The maturity of the development tools for "software" is far greater than 
for FPGA and they are cheaper. There are things like documentation 
generators, debuggers, code analyzers, integrated development 
environments, and on and on for software. There are multiple vendors for 
each.

In the FPGA world, we're just starting to get analysis capabilities that 
look for things like clock domain crossings that might cause trouble, 
decent library management tools.  I don't know that there are FPGA 
equivalents to static code analysis tools like Coverity, CodeSONAR, 
Semmle, etc.  There probably are, but I'm going to bet that they've only 
been out for a few years, and don't have decades of use behind them like 
most software tools do.

In terms of debugging - whether it's "printf() to the console" or 
embedded hardware debugger supports like the SPARC/GRMON combination - 
there's a lot more support for software debugging than in an FPGA.  Part 
of this is that FPGA designs tend to be timing critical - you can't just 
add a block of code that dumps a bunch of values to a device or file. 
Tools like ChipScope in the Xilinx family do let you look at some stuff 
(like having a oscilloscope or logic analyzer in your design) - but the 
scale and practicality is limited.

Just the time required to turn around a new design after fixing a bug is 
typically faster with software.  On the Xilinx Virtex 6 designs I'm 
working with, resynthesizing the bitstream takes on the order of 30-45 
minutes.  I haven't had a C compile take that long in years, except when 
I was compiling some package from source on a Beagle.  For most software 
applications, recompile is a matter of <1 minute (if you're not working 
in an interactive or JIT language where the time is zero).


Maturity of software libraries vs embedded components for FPGAs - for a 
given function, it is far more likely that there are multiple high 
quality software implementations than for a FPGA. Look at something like 
BLAS (for linear algebra) or FFTW - folks have been optimizing numerical 
libraries for decades - you want a Radix 17 FFT for some reason, and 
there's probably one out there: in 3 different languages, and either 
platform indpendent or with a well defined path to 
optimizing/configuring them for a given platform.

In FPGA land, there's some standard building blocks: FFTs, FIR 
filters,NCOs, various common interfaces (Ethernet, serial port) - but 
often, there's one or two instances, they're somewhat tied to a specific 
architecture, and tend to be straightforward implementations.  And 
they're not necessarily cross platform supported - I made the mistake a 
few years ago of thinking that I could move a digital down converter 
from Virtex 2 to Virtex 6, but discovered that the IP cores (from 
Xilinx) used were supported on Virtex 2 but not Virtex 6, and the new 
cores worked entirely differently. Over a span of a few years, we got 
virtually no code-reuse - for a very non-sophisticated, non-platform 
specific design - an oscillator, multiplier, CIC decimator and FIR filter.

I can still use the original 10-15 line FORTRAN Radix2 FFT from that 
IEEE transactions paper in the late 60s without much trouble.
An awful lot of people reuse a CRC calculation code for 8 bit 
microcontrollers that originated in a paper by Aram Perez "Byte-wise CRC 
Calculations" in IEEE Micro June 1983. It works, why change it.