Which HDL?

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

-snip-

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

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

C+Occam; interesting, and probably the only realistic choice outside VHDL/Verilog

SystemC

C++ class library; big in system-level design and architecture exploration, not good for low-level design

SpecC

Extensions to C Confluence a functional programming language JHDL Java-based 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

Verilog

that

still

to

and

(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-