Re: high level languages for synthesis
- From: fpga_toys@xxxxxxxxx
- Date: 25 Aug 2006 11:23:24 -0700
Jan Panteltje wrote:
There are many many cases where ASM on a micro controller is to be preferred.
Not only for code-size, but also for speed, and _because of_ simplicity.
For example PIC asm (Microchip) is so simple, and universal, and
there is so much library stuff available, that it is, at least
for me the _only_ choice for simple embedded projects.
No way 'C'.
Yes hardware engineers add sometimes great functionality with a few lines of
ASM or maybe Verilog, cool!
Hi Jan, .... one size certainly doesn't fit all, especially where the
tools are poor or lacking.
Having written Asm since mid 1960's in a grand scale on over 30
architectures, I'm certainly not asm adverse when needed. I have
however strongly advocated C since first writing device drivers for
UNIX machines starting in 1975. Learning to write low level "symbolic
asm" in a C compiler is a needed skill for anyone doing machine level
coding optimization. Debugging compilers on new architectures is also
painful, and requires solid skills in machine languages. As does doing
cross architecture operating systems porting, as bringing up both new
hardware and new software tools (asm, linker, compilers, libraries) is
more an exercise in debugging at the machine level than it is high
level design. I made my living do hardware/software at that level for
over 30 years, and still do today.
One the other hand, I've watched to asm bigots fall one by one over the
last 30 years, as entire industries switch from asm coding as the
defacto standard to HLL's. All of your arguments are the same they
made. In the end, the HLL tools mature, reach nearly hand coding
levels, and a slow migration occurs from 100% asm, to 20%, asm after
the first C recode, to 10%, to 5%, to under a small fraction of 1%.
There are minimum machine thresholds where HLL's are viable, and that
isn't an embedded micro with 64 bytes of r/w registers/memory and a few
Kbytes/bits of program rom. On the other hand, the price difference
between a highly capable micro with resources to easily support 99% HLL
coding and a bare bones chip is getting pretty small, and frequently
when you factor devevelopment costs and life cycle maintainence costs
into the cost of the product, the difference is actually negative ....
IE the tiny chip is MUCH MUCH more expensive in both real costs and
time to market costs as compared to a large micro using HLL development
tools, well trained HLL development engineers, and clean
readable/maintainable well structured C/HLL (such as Forth).
I helped Ron Cain with UNIX resources and design ideas back in the late
1970's to do "Small C' for the micro's of that day ... not pretty asm,
but functional. I've also worked with tiny embedded micro's running
Forth, that knocked off applications in weeks that would have taken
years to debug in asm, if you could get it to fit. I've also done
hardware design for more than 30 years, including more than my share of
PLD work using early PAL's and PALASM level tools. There is a good
reason VHDL/Verilog exist .... and as many good reasons they should not
be the mainstay development tools at the current low level they provide
in two decades from now ... especially for FPGA's.
It's with more than a weekend warriors experience, that I see C on
FPGAs making a huge difference for both hardware design, and
reconfigurable computing.
I guess it is a matter of learning, I started programming micros with
switches and 0010 1000 etc, watch the clock cycles.. you know.
Teaches you not to make any mistakes, as re-programming an EPROM took
15 to 20 minutes erase time first...
Being _on_ the hardware (registers) omits the question of 'what did that
compiler do', in many cases gives you more flexibility.
C already puts some barrier, special versions of C for each micro
support special functions in these micros....
I started programming on 4K 1401 card machines, with at most 5-10 test
runs a week. Desk checking was everything ... and having a full work
day between runs pretty much insured it. Program complexity is however
far past what even a good coder can get running in one or two test
cycles these days. So ... been there, done that, and it sucks rocks. As
does large scale bit level design today.
In spite of what I just wrote .. anyways why wants everybody all of the
sudden Linux in FPGA? So they can then write in C?
Have it slower then in a cheap mobo ?
Dunno ... didn't advocate that, especially not for LUT level FPGA work,
as there are not enough LUT's on the planet to implement linux as a
netlist.
Ok, OTOH I appreciate the efforts for a higher level programming, as long
as the one who uses it also knows the lower level.
That sort of defuses your argument that 'engineers need less training' or
something like that, the thing will have to interface to the outside world
too, C or not.
First I don't exactly make that arguement, but I do make the arguement
that fewer numbers of engineers need that level of training ...
something that greatly separates the newbie's from the experienced.
Organizationally that makes a huge difference in costs, time to market,
maintainability, and survivability in a global market.
It also means that you don't let experienced designers create job
security by coding at a level only they can maintain, except where
critically necessary and there exists other staff available in house,
or as consultants, to carry the torch long term.
.
- References:
- high level languages for synthesis
- From: Sanka Piyaratna
- Re: high level languages for synthesis
- From: Antti
- Re: high level languages for synthesis
- From: fpga_toys
- Re: high level languages for synthesis
- From: Jan Panteltje
- high level languages for synthesis
- Prev by Date: Re: UltraController II + SystemAce
- Next by Date: Re: high level languages for synthesis
- Previous by thread: Re: high level languages for synthesis
- Next by thread: Re: high level languages for synthesis
- Index(es):
Relevant Pages
|
