high level languages for synthesis

Jan Panteltje <pNaonStpealmtje@yahoo.com> writes:

> On a sunny day (29 Aug 2006 11:42:00 +0100) it happened Martin Thompson
> <martin.j.thompson@trw.com> wrote in <uk64rzuvb.fsf@trw.com>:
> >
> >Neal Stephenson wrote "in the beginning was the command line"
> >http://www.cryptonomicon.com/beginning.html
> 
> I have just read part of that, he really gets out there.... :-)
> 

Yeah :-)

> For me, one thing the 'command line' interface does, is allow me to speak
> normal language to a computer.
> This is important in interfacing to computers with speech.
> 
> For example I have a script (Linux Bash) called 'show', and a PCI satellite
> card in the PC.
>  http://panteltje.com/panteltje/satellite/show
> When I _type_ 'show BBC2' at the command prompt, then it will steer the dish
> to one of the Astra satellites and start mplayer.
> 

Yep, get it done once and it's easy all the other times!

I've often thought that good engineers are fundamentally lazy - they
only want to do something once, do it well, then get on with the next
thing, having made the first thing so easy that they don't have to
think about it!  When I can make that less waffley (sp?), it might
become a .sig...

> And when I _say_ 'show bbc2' it will do the same, using perlbox voice.
> 

Neat- I shall have to play with that!

> The ability to make commands that are simply spelled as English words is
> perhaps the most powerful thing.
> 'Random access'.
> 
> You often _know_ what program or action you want the computer to do, and
> going via many menus to dig deeper and deeper is a barrier, takes time.
> 

It's OK the first time when you are exploring something new, the
guidance can be a boon. But when you have to do it every time, it gets
a bit annoying.

<snip>

> Same in FPGA, use makefiles, scripts.
> 

Ahh, back on topic :-)  Ditto for me.  I wouldn't be without python now!

> To pester MS windows users I say sometimes: 'My PC speaks English'.
> 

How do they respond to "goading" like that?

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

Martin Thompson wrote:
> I think that's also low-level though, LUTs and wiring?  I was thinking
> of something higher-level, where if you have an adder, you put a<=b+1
> in the VHDL and let the synth sort it out.

That might make sense for a lnaguage translator, but that isn't the
synthesis goal for FpgaC.

> Or are there benefits to optimising across the great sea of LUTs that
> a normal synth doesn't get to?

For TMCC (the starting point for FpgaC) the goal was just to get a
portable form, optimized for C. It wasn't particularly optimial, just
something that worked. The goal was a C language semantic HDL, as an
educational exercise.

The FpgaC project is targeting using FPGAs to provide a VERY fast
execution environment for ANSI C. As it matures it will do some things
in a very different way. One for starters, will be to keep all
expressions and variable assignments in "carry save" format right up to
the point they are committed to being saved in their final form as
DFF's. This may use a little more logic to gain performance, and avoids
unnecessary ripple carry resolution of intermediate terms. With LUT
term sharing and packing, it may actually use the same or less, by
foling several operations into a single lut.