Which HDL?

John wrote:
> I'd like to see a unified Verilog C language which looks like either &
> both but with most of the useless stuff thrown out, ie a cycle/event C
> with Verilogs expressiveness that is synthesizeable when using that
> syntax and not when using the C syntax.

So would I.  Do you have any examples of how that would look?

How about the Timogriffer-C model where all computation goes infinitely 
fast, but the program can wait for the next clock edge, eg. something 
like (thought experiments)

input int rst:1;
output int led:8;

counter()
{
    for (;;) {
       if (rst)
         led = 0;
       else
         ++led;
       WAIT;
    }
}


Another example, a FIFO

input wren:1, rden:1;
input wd;
output rd;
output full:1;

int fifo[32], rp:5, wp:5;

run_fifo()
{
    for (;;) {
      if (rst) {
         rp = 0; wp = 1;
      } else {
         par {
            if (rden) rd = fifo[rp++];
            if (wren) fifo[wp++] = wd;
         }
         full = wp == rp;
         empty = wp == rp+1;
     }
     WAIT;
   }
}

The par {} construct is inspired by Handel-C, but Handel-C has a very 
odd model where there's essentially an implicit WAIT after each 
statement, thus making it very hard and unnatural to describe 
non-trivial circuits that happens between two clock edges.

Of course this example doesn't make up of bit extract, concatenation, 
and replication, but there's no reason it couldn't be there.

Or did you have something else in mind?

Tommy

Hi Tommy

Well I'm working on a Transputer cpu (which originally ran Occam) as
well as the compiler for it. Occam later went to U.Oxford and turned
into HandelC since they recognised that Occam could be used to model SW
and HW processes.

My view as I stated often in the NGs is that while Occam is good for
Par message based programming, it wouldn't ever be my choice to
describe HW except in a very general way at the spec stage or as a co
HW-SW harness . I believe SystemC & other xxxCs also includes CSP
basics.

Also I realized that the Transputer process scheduler is a hop & skip
from an event wheel but with a much more limited set of semantics so it
never quite made it as a direct HW simulator but most Transputer
projects were essentialy HW like and usually DSPish.

I like the C syntax as a user, but as a compiler writer, the language
is a total dog as it is far harder to describe than Verilog or VHDL
although the Hanson-Fraser Lcc book helped me out on that.

Still I am combining Verilog with Occam & C as the main language for
the new Transputer. Generally C type seq programs would remain in C.
The Verilog syntax comes into play to describe very par HW objects
using the cycle model and later the event driven model. Occam comes
into play more at a system level for combining message passing seq (C)
/par (HDL) blocks. This is somewhat experimental and counters SystemC,
SystemVerilog or VHDL to some extant.

The parser essentially allows all constructs of Verilog, Occam & C to
be interwtined in sometimes meaningless ways, so a mixed Verilog-C
object would not be exportable to another Verilog or C tool, not sure
if that matters, its probably inevitable. But you could import modules
& functions.

None of this would make any sense outside the Transputer env, as it
pushes the idea that to some extent HW & SW form a continuum where
algorithms can slide between HW & SW as performance demands. Esp useful
to algorithms that naturally might fall into an FPGA as HW but might
also be described as HDL or Occam code and just run as SW for lower
cost but only possible if cpu supports processes, events, messages etc.
The reverse is that SW can be moved from C to C-Occam and perhaps on up
to HDL and synthesized into HW directly. Another alternative available
only in Transputer systems is to increase the cpu count and spread SW
process around to defer having to rewrite as HW. If you have a few 100
cpus, you might never want to rewrite as HW period. Now some might call
that a HW simulator, but I might just call it an application.

The alternative approach of trying to figure how to parallelize seq C
directly into HW or onto fancy superscaler cpus makes no sense to me as
it avoids using the par operator when it can be used in so many places.
even if only to express "seq order don't care".

Anyway I am in the middle of getting the compiler to emit asm for the
Transputer and also to continue development of the C-ISA simulator,
C-RTL simulator, and Verilog models. They are so intertwined that the
C-ISA simulator is potentially the runtime for  the compiler when
hosted on a PC.

It will be awhile before I can demonstrate the whole thing, but parts
will come out soon enough.

Looks like you are already convinced too, now another few more bods to
go.

regards

johnjakson at usa dot com

JJ wrote:

> Hi Tommy
> 
> Well I'm working on a Transputer cpu (which originally ran Occam) as
> well as the compiler for it. Occam later went to U.Oxford and turned
> into HandelC since they recognised that Occam could be used to model SW
> and HW processes.
-snip-
> 
> johnjakson at usa dot com
> 
Quote from a former co-worker, who had to maintain a legacy product that 
used transputers:

"Oakum is something you stuff into cracks in boats, not a programming 
language".

Not that I've ever actually _used_ Occam, it was just too good a quote 
to pass up.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Sun, 13 Mar 2005 16:06:53 +0100, "Piotr Wyderski"
<wyderskiREMOVE@ii.uni.wroc.pl> wrote:

>Hello,
>
>I would like to start a serious adventure in FPGA development,
>so which HDL would you recommend me? I can restrict myself
>to a single chip vendor (i.e. Altera, because their chips are quite
>cheap and very easy to obtain in small quantities in Poland),
>thus the spectrum of alternatives should be wider. The most
>important thing is good support of genericity, for instance:
>
>    generic type vector{N} where {const N : positive} is group of N bits
>    x : vector(32); -- x : std_logic_vector(31 downto 0)
>
>or even constants:
>
>    generic const square{N} : type of N where {const N} is N*N;
>    const nine : int is square{3};
>
>The languages I know about are:
>
>VHDL: very disappointing, the nicest part of Ada has ben removed.
>No support for anonymous types, stiff and annoying syntax, weak
>interface inference (needs explicit component specifications).
>
>Verilog: same as above + lack of generate statements, so how
>does one specify generic pipelines (very useful e.g. in parallel
>CORDIC specifications)?
>
>AHDL: I don't know much about it, because I can't find a good manual.
>
>    Best regards
>    Piotr Wyderski

If you're doing FPGA development, then you've only got 2 serious
choices; VHDL and Verilog. You can find any amount of VHDL vs. Verilog
debate on Google (mostly uninformed, plain incorrect, prejudiced, or
all 3). The bottom line, if you're already programming-literate (as
you clearly are), is that you'll find Verilog more frustrating than
VHDL. VHDL is at least based on Ada, so is consistent, and relatively
modern (for 1980).

Both languages were designed in the early 80's; VHDL by committee (it
shows), Verilog by one person (it shows). Unfortunately, Verilog's
design was exceptionally poor even then, and still is. The market for
these languages is small, and the major EDA vendors have always had a
vested interest in stability, and not progress; the end result is that
we have to put up with 25-year-old languages.

Verilog-2001 is much more usable than the 1995 version, but it's still
Verilog. SystemVerilog is not an option for you, since it's too new to
be supported. SystemVerilog is largely again a political creation, and
it may or may not catch on in the longer term, depending on how
gullible we all are (very, if history has anything to tell us).

If you want to write a preprocessor, you should generate Verilog-1995
output, not VHDL; it's better supported.

Other minority languages (for FPGA development, anyway):

Handel-C (http://www.celoxica.com/methodology/c2fpga.asp): C+Occam;
interesting, and probably the only realistic choice outside
VHDL/Verilog

SystemC (www.systemc.org): C++ class library; big in system-level
design and architecture exploration, not good for low-level design

SpecC (http://www.ics.uci.edu/~specc/): Extensions to C
Confluence (www.confluent.org): a functional programming language
JHDL (http://www.jhdl.org/): Java-based
RHDL (http://www.aracnet.com/~ptkwt/ruby_stuff/RHDL/) Ruby-based
AHDL: vendor-specific; forget it

I guess everyone has different experiences. I find Verilog less
frustrating after writing VHDL for about 3 yrs, but in reality I'm not
adverse to using either. I sure don't miss simulating 9-level SLVs when
less than 1/2 those states occur inside an FPGA design is a nice bonus.
I sure do miss VHDL's records for testbenching (but not the limitations
of driving fields from two directions!). Verilog can be ambiguous. VHDL
can be redundant.

I don't think languages designed by one person is a bad thing; I'm not
sure if I could live without Perl. My opinion on design-by-comittee is
summed up by, Where the heck is VHDL-200x? ("Fast Track", no less). I
used to sit in on SMPTE spec meetings where the group argued over
whether a word should be "shall" or "will" for 2 hrs. The point being
most of the time was spent innovating nothing. Having 'n' engineers in
a room, n>1, means a level of contention proportional to n, and
functionality is diluted in the process to keep everyone happy. I'm
sure the new VHDL will be awesome but I'm not holding my breath.

-- Pete

> If you're doing FPGA development, then you've only got 2 serious
> choices; VHDL and Verilog. You can find any amount of VHDL vs.
Verilog
> debate on Google (mostly uninformed, plain incorrect, prejudiced, or
> all 3). The bottom line, if you're already programming-literate (as
> you clearly are), is that you'll find Verilog more frustrating than
> VHDL. VHDL is at least based on Ada, so is consistent, and relatively
> modern (for 1980).
>
> Both languages were designed in the early 80's; VHDL by committee (it
> shows), Verilog by one person (it shows). Unfortunately, Verilog's
> design was exceptionally poor even then, and still is. The market for
> these languages is small, and the major EDA vendors have always had a
> vested interest in stability, and not progress; the end result is
that
> we have to put up with 25-year-old languages.
>
> Verilog-2001 is much more usable than the 1995 version, but it's
still
> Verilog. SystemVerilog is not an option for you, since it's too new
to
> be supported. SystemVerilog is largely again a political creation,
and
> it may or may not catch on in the longer term, depending on how
> gullible we all are (very, if history has anything to tell us).
>
> If you want to write a preprocessor, you should generate Verilog-1995
> output, not VHDL; it's better supported.
>
> Other minority languages (for FPGA development, anyway):
>
> Handel-C (http://www.celoxica.com/methodology/c2fpga.asp): C+Occam;
> interesting, and probably the only realistic choice outside
> VHDL/Verilog
>
> SystemC (www.systemc.org): C++ class library; big in system-level
> design and architecture exploration, not good for low-level design
>
> SpecC (http://www.ics.uci.edu/~specc/): Extensions to C
> Confluence (www.confluent.org): a functional programming language
> JHDL (http://www.jhdl.org/): Java-based
> RHDL (http://www.aracnet.com/~ptkwt/ruby_stuff/RHDL/) Ruby-based
> AHDL: vendor-specific; forget it

Piotr Wyderski wrote:

<...>

> or even constants:
>
>     generic const square{N} : type of N where {const N} is N*N;
>     const nine : int is square{3};

(Didn't see anybody else mention this -- or I missed it)

In VHDL this would be a function, like

      function square (integer N) returns integer;

declared in a package header and defined in a package body.  Or is it
that you want to have a single function "square" for a bunch of
different types ? In VHDL presumably your types are different lengths
of SLVs or UNSIGNEDs : VHDL function arguments can be unconstrained
types, ie

      function square (std_logic_vector N) returns std_logic_vector;
      -- length only determined when function is called.

However be very careful handling increasing and decreasing ranges, I
learnt how to do this by studying some of the standard packages.

As an aside, I also like to use VHDL records, which for the few
unfamiliar readers here are like a C struct.

Regards,
-rajeev-