JJ wrote:
>  I do remember though before I
> became interested in FPGAs some 10 years ago several commercial ASIC
> HDL C and I recall that they all failed miserably in the market as
> "nobody wants this stuff". With FPGAs and systems guys, there is
> perhaps more room for using HDL C but it has to be a FREE language and
> preferably standardized.

10 years ago the price performance of FPGA's really was marginal. A
decade of Moore's Law, and we are just now finding the price
performance of FPGA's to be very competitive ... without the proper
tools.

I agree that open source FPGA tools are critical .... and something
that the big vendors haven't realized yet. I can still remember the
posturing and standards problems that plagued the software industry 30
years ago ... till UNIX leveled the playing ground, and create a
cooperative competitive environment the benifited all. Once
reconfigurable computing starts to take off, the large computer vendors
will mandate it. And leave those closed shops behind.

Standards really make the difference ... it's why a C HDL really needs
to be ANSI C, with as FEW changes as possible (IF any at all). It's
actually quite possible to design with ANSI C, and leave the changes in
the back end tools. Restricting bit field declarations to structures
isn't really a problem, and allows portability. A few pragma's are a
bit deal either. Everything else should be portable, standards based.
It's the problem I had with TMCC (the starting source code for FPGA),
and Handel-C.  It was a hard call not to start from scratch, rather
than use the subset TMCC. The evolution of TMCC to an ANSI C in the
FpgaC project has been slow, but steady progress. And even as a subset,
with so-so synthesis, is amazingly useful. A few more good
hardware/software people working on it, and it could be really "done"
in a few months.

The most disappointing part of the project, has been the kids that
arrive gungho, and discover it's  actually some difficult learning and
relatively challenging work as a programmer to do hardware tools. I'd
hoped a few more computer engineering students would find the project.

fpga_toys@yahoo.com wrote:
> JJ wrote:
> > Myself I vote for the one that begins with V.
> >
> > Now if the C language would pick up some major extensions the likes of
> > which we see in HDLs such as open ended bit sizes and the same notion
> > of concurrency and nested modules I could probably do most everthing in
> > a HDL C combined with regular C. If the compiler would spit out HDL for
> > regular synthesis and allow HDL code to be simulated at C speeds, that
> > would be neat.
>
> Most of the C based HDLs offer some means to assign arbitrary bit
> widths to objects, frequently in ways that break ANSI C compatability.
> Bit fields do however existing in the language, and in ways that are
> actually pretty useful for most applications. Still, one of my nits in
> doing FpgaC is to carry a proposal to the ANSI committee to allow bit
> fields that are larger than the native type, forcing the compiler to
> handle a 200 bit or 64 bit object the same on both an 8bit micro and a
> 128 bit super computer. In FpgaC, I'm not sure there is a limit on the
> width of an object, other than constants, which is something I'm
> already working toward fixing.
>

Exactly, least possible change to the language but to allow wires bits
fields to be truly arbitrarily large, Verilog allows 16M bit width if
needed. perhaps we should be using Fortran or APL as base languages.
Using C++ overloading operators and hence SystemC doesn't do it for me
either. A base language that can do huge math ops in a few symbols is
something we had 40 years ago. It is a pity N.Wirth didn't do more for
HDLs beside Lola.

> As for concurrency, that is something that hardware guys miss
> understand completely. Every compiler is free to shuffle/reschedule the
> code produced, as long as the results have the expected serial
> symantics. Out of order execution and multiple issue pipelines, ARE
> concurrency. As are threads, pipes, processes, and many other
> concurrent abstracts in what appears a sequential language.
>

By concurrency I refer to the CSP model and the occam language which
looks alot lke hardware design. Ofcourse HandelC evolved out of occam
from the U Oxford work a decade ago in synthesizing occam processes as
hardware. I don't know about the other xyzCs or FpgaC and will wait
till they have been around a while.  I do remember though before I
became interested in FPGAs some 10 years ago several commercial ASIC
HDL C and I recall that they all failed miserably in the market as
"nobody wants this stuff". With FPGAs and systems guys, there is
perhaps more room for using HDL C but it has to be a FREE language and
preferably standardized.

> In FpgaC everything in a statement group is completely concurrent.
> Other C based HDLs offer other concurrency rules, from statement level
> clock timing, to explict construction of parallelism using hardware HDL
> semantics.
>

Really wIll have to look into FpgaC some time esp if its gets more
traction and more references by others.

snipping

> While my interest in FpgaC is to build useful FPGA super computers in
> the future, it's a love of both hardware design, and software design,
> that enables that vision. That is not a reasonable vision, while the
> only tools to program fpga designs, and at the bit and clock edge
> level.  I suspect, that just as assembler, and even 'low level" C is no
> longer in favor for complex designs today ... there will be an
> evolution where high level HDL tools move away from detailed hardware
> description at the clock and signal level detail, and move up so that
> system level specification which includes the interface descriptions
> and leaves the internal hardware description clearly to the tools to

I think there needs to be a combination of Verilog (maybe VHDL) and a
subset of C++ so that processes can be described in a common language
that might run as conventional software on a single or massively
threaded cpu or might also be synthesized onto hardware. It should
still allow for bitwise low level hardware design if need be but should
also allow higher lever synthesis too. That should be a boon to those
Opteron systems with FPGA coprocessors .

> optimize and produce. I'm not the brighest tool designer on the planet
> ... actually just a wet eared newbie ... so if I can get FpgaC to do
> these things with a little magic, I'm certain the better guys on the
> planet that do this for a living will blow some socks off with system
> level C languages.  I'm actually looking foward to a SystemC tool based
> on C++ sematics that has really good synthesis ... maybe a few years
> from now?

I find myself moving further & further away from C++, leave as much of
it as possible out of the loop. Perhaps Lisp would or should be the
ticket.

Well I am not the worlds brightest spark either but what I can see is a
mess all around me where ever I look, most of it as a result of too
much idiotic complexity and too many parties. I yearn for the
simplicity of years past. I have 4 different computers around the
office house and every one of them is really crap, and some of it is
pretty new crap. This one won't run that OS, that OS or mobo don't like
that HD, those 2 HDs from same vendor can't be on same ribbon. Its
really endless list of incompatibles. Give me a system based on
something like SpaceWire links for everything and lots of throughput
processors and no Memory Wall!

FWIW I always say that Verilog is closer to Pascal than C, C only
supplies the arithmetic expression operators while Pascal supplies the
module structure. A parser for C is far more complex than for Verilog
even though on the surface C is supposed to be simpler.


John Jakson
transputer guy

Evan Lavelle wrote:
> Actually, you can make your VHDL or Verilog description much more
> abstract than this. I've recently been working with some very abstract
> VHDL code, some of which was untimed, and some of which used functions
> and procedures rather than explicit hierarchy. It was also very
> dependent on passing around large records, and letting the synthesiser
> get rid of the unused bits. The untimed code relied on register
> retiming in DC (which I think XST supports).
>
> Personally, I really hate this sort of code. It was synthesising to
> about 75 logic levels between clocks before I started hacking it.

Following the links in Mike's posting proved to be interesting, as it
references indirectly this great piece, which makes the same arguments
about why you don't want to let hardware designers avoid a high level
of design abstraction, as they will dig the same deep unmaintainable
hole that assembly language provides for programmers, and their
employers.

http://www.designabstraction.co.uk/Articles/Advanced%20Synthesis%20Techniques.htm

And clearly, the bottom line is well stated by this articles
introductory "Scope" section.

> It'll never happen; already been tried, failed. Hacking low-level
> hardware semantics into existing C++ semantics just gives you a
> verbose and complex mess, which is nowhere near as concise and clear
> as a VHDL or Verilog description. Great for modelling, non-starter for
> real-world synthesis.

Having to work with some horrible "concise and clear" VHDL, I have to
disagree. Job security by obscurity in a botched VHDL design that LACKS
reasonable high level abstraction is exactly why in my mind that TTL
designers should not be allowed to write TTL designs in VHDL/Verilog.
That those constructs need to be removed from a production language
that is general use, to specifically force mantainable coding
standards, that improve productivity and maintainability over the long
term.

Evan Lavelle wrote:

> It's a client's software, I'm afraid, so no can do. It's also worth
> more than I make in a year.

It *costs* more that a year's pay,
but its worth is open for discussion.

> 'map_to_entity' is a pragma that you enter in the source code,
> together with your behavioural function/procedure. All it says is
> that, during synthesis, the subprogram call should be replaced with an
> instantiation of the named entity (in other words, it's not something
> that you can try running with or without; you have to write the code).

Hmm. Do-it-yourself synthesis.

There was a Far Side cartoon that depicted one cave dweller holding a
single round stone in his hand with another cave dweller holding a 'tool
box' full of more of the same round stones.  The first guy holding the
single stone exclaims: "I asked for a hammer, A HAMMER!  This is a
crescent wrench...... Well, maybe it's a hammer.  DAMN these stone tools!"

         -- Mike Treseler

fpga_toys@yahoo.com wrote:

> Any mappings to Virtex-5 fat lut's yet?

No. Try it and let me know.
I'll add the stats to the table
at the end of the file.

> Best case hand design for comparison?

After looking at the Quartus RTL view
http://home.comcast.net/~mike_treseler/uart.pdf
I don't think I could make much less area.
Anyway, life's too short :)

          -- Mike Treseler

On Tue, 08 Aug 2006 10:05:10 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

>Evan Lavelle wrote:
>
>> Give it a go - try some abstract code on your favourite synthesiser.
>> DC has a 'map_to_entity' pragma which allows you to write a
>> behavioural function or procedure for simulation, and map it to an
>> entity for synthesis. I tried running some example code that uses this
>> pragma through Amplify recently, and it ignored the pragma, and
>> synthesised the behavioural code correctly. Synplify would probably do
>> exactly the same.
>
>I have some semi-abstract reference code below that has been
>synthesized successfully on everything except DC.
>I would appreciate it if you could give it a go on DC
>with and without map_to_entity.

It's a client's software, I'm afraid, so no can do. It's also worth
more than I make in a year.

'map_to_entity' is a pragma that you enter in the source code,
together with your behavioural function/procedure. All it says is
that, during synthesis, the subprogram call should be replaced with an
instantiation of the named entity (in other words, it's not something
that you can try running with or without; you have to write the code).

Evan 

Mike Treseler wrote:
> I have some semi-abstract reference code below that has been
> synthesized successfully on everything except DC.
> I would appreciate it if you could give it a go on DC
> with and without map_to_entity.

> http://home.comcast.net/~mike_treseler/uart.vhd

Thanks ... interesting reference point!

Any mappings to Virtex-5 fat lut's yet?
Best case hand design for comparison?

Evan Lavelle wrote:

> Give it a go - try some abstract code on your favourite synthesiser.
> DC has a 'map_to_entity' pragma which allows you to write a
> behavioural function or procedure for simulation, and map it to an
> entity for synthesis. I tried running some example code that uses this
> pragma through Amplify recently, and it ignored the pragma, and
> synthesised the behavioural code correctly. Synplify would probably do
> exactly the same.

I have some semi-abstract reference code below that has been
synthesized successfully on everything except DC.
I would appreciate it if you could give it a go on DC
with and without map_to_entity.

Thanks.

              -- Mike Treseler

http://home.comcast.net/~mike_treseler/uart.vhd

On Mon, 07 Aug 2006 17:53:50 +0200, Nicolas Matringe
<nicolas.matringe@fre.fre> wrote:

>I can't remember who in this newsgroup who knows both and, whichever 
>he's using at any given moment, always regrets he doesn't use the other 
>language.

I think that's Janick Bergeron's line originally, but it gets my vote!
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On 8 Aug 2006 09:24:56 -0700, fpga_toys@yahoo.com wrote:

>hmm ... so much for memory ... googling seems place it 
[C++]
>early 1980's too.

I had understood that Stroustrup was working on "C with Classes"
(using a preprocessor to map from CwC to pure C) from around 1978.
Methinks Evan was being whimsical about VHDL...
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.