Anyone Using JHDL for Programmable Logic?

gte910h asks: "I am an embedded developer who is learning how to program programmable logic devices (CPLD's and FPGA's). I have looked at VHDL and other Hardware Description Languages, but they seem so obtuse compared to C or Java. Has anyone tried any of the tools based off of general purpose programming languages, like JHDL. Do they work as well as VHDL and other HDL's? These would make things this type of development acessable to more people if they work well enough." Are packages similar to JHDL available for other languages?

Comments

VHDLs are good for you!

[Victor Danilchenko]

They are a heckuva lot better than the Low Density Lipoproteins...

JHDL, now -- let me guess: Just-right Height Density Lipoproteins? Sure sounds good to me...

;)

HDL 'programming'

[motorsabbath]

One of the hardest things we all need to learn when starting out with HDL is that we're not programming - we're building hardware and arrays of gates. Having done a *lot* of C and applications programming before I started on VHDL and Verilog I can tell you it took a while to shake off the programmer in me and become a hardware developer. Applying general-purpose programming tactics to HDL too often makes too many gates and highly inefficient chip and logic layouts.

Both VHDL and Verilog have their strengths - you'll get used to them. Especially if you have to sit down and hand-tewak the resultant logic aftewards ... Verilog is easier to write, but VHDL is (seems) more typesafe and is easier to debug.

Re:HDL 'programming'

[anonymous loser]

Applying general-purpose programming tactics to HDL too often makes too many gates and highly inefficient chip and logic layouts.

Inefficient logic is the least of your worries. "Programmers" that are new to HDL's have a tendency to think linearly, which is a Bad Thing(tm). You end up linear dependencies (i.e. X must happen before Y), and sometimes even *loops* which are the worst thing you could possibly do in HDL. Since almost everything is happening in parallel in most code snippets, the code simply doesn't work properly in hardware. Some gates will initialize properly, others will be zero, and most everything else will be in a random state.

My microprocessor design professor used to mock CS students ("see...you have this *object*...) because of the poor code they produced. Don't be one of those people, but instead "think hardware" when you're writing HDL.

Re:HDL 'programming'

[jcorgan]

The 'conceptual model' that is embodied in high-level languages such as C/Java or Verilog/VHDL couldn't be more different:

• With C and Java, a developer is presented with an abstract "machine" that has one or more "flows of execution". The developer creates a sequence of data/variable manipulations and flow control constructs which guide execution based on the results of logical tests. This is a view of the world as a "stream of instructions."
• With Verilog and VHDL, the developer is "sequencing" a "state machine" (with or without a synchronizing clock) by routing massively parallel binary state between logic elements that update that state. This is a view of the world as a "lot of things happening at once, connected by the rules that govern them."

It's not surprising that people (such as the poster of this story and the students you mention) have trouble shifting between them.

Re:HDL 'programming'

[Snoochie Bootchie]

Here, here.... It is VERY easy to write syntactically correct, but difficult to synthesize HDL code. The synthesis tool you'll be using is going to try to infer the logic it believes you're describing. Keep it simple. Write synthesis-friendly HDL code. Make sure you understand blocking vs. non-blocking statements (it'll haunt you during simulations). Always keep in mind that this high level description is going to be translated into logic gates. In your design flow, logic synthesis should not be the longest time sink (except for trivial designs).

Re:HDL 'programming'

[prator]

It just takes a little practice. I've learned most of my Verilog on the job, and recently I had to explain it to one of our co-ops.

The non-procedural Verilog vs. procedural C did confuse her for a little while, but she caught on pretty quickly just like I did.

You just have to take a little time to explain what "=" is versus "<=".

-prator

Re:HDL 'programming'

[DrCode]

Yes. And keep in mind that VHDL was first a 'description' language (the 'D' in the name), then a simulation language, and was only later used for creating circuits (synthesis). We software types tend to expect a compiler, like gcc, to be able to handle anything in a language that's syntactically and semantically legal. But VHDL synthesis tools usually only handle a subset of the language, and different tools handle different subsets.

Re:HDL 'programming'

[taniwha]

Yup - the having to think about time is hard for people when they are starting out. I've spent the past decade or so building stuff out of verilog, before that I was a unix kernel hacker - coming from that environment where time and synchronisation did mean something helped - having to explicitly spec out my state machines seemed like like such a chore.

I actually like to sometimes use a verilog coding style that's more close to co-routining where the synthesis tool creates a hidden state variable for you however you have to check with your tools to see if they'll accept it [synopsys does] - old time verilog hacks throw up their hands when they see this stuff. Event when I'm not using this style and making my state machines by hand I still tend to write verilog that looks much more like traditional programming (fewer larger always statements that
do lots of things together) - my experience has been that this makes me much more productive (I can turn out >100k aggressively timed, DV'd gates per year of relatively random logic).

Recently I made the move back to doing more software - I've found my kernel driver coding skills are greatly enhanced by my time writing gates - stuff that might have been hard to find in the past is instantly obvious today because I've spent all that time designing stuff that cared implicitly with time

VHDL, Verilog and "those other languages"

[Entrope]

I'm surprised you didn't mention Verilog -- it's an HDL that is (outside of military contracting) much more popular than VHDL. The "obtuse" syntax in VHDL you mention is based on Ada's syntax -- both were designed essentially by committee. Verilog, in contrast, is based on C's syntax (with some Pascal thrown in).

VHDL has a much richer syntactic set than Verilog; however, it's easy to lose track of some of the features, and most synthesis tools need to convert to Verilog for gate-level representation of the code eventually. Some companies (such as Altera, with AHDL) have created hybrid languages that add some of the features to VHDL to Verilog; Verilog 2000 (which does the same, but isn't as widely proven yet) is another option. Still, if you want a simpler HDL than VHDL, I'd recommend Verilog.

The languages derived more directly from C and Java (SystemC, for example) are even less tested; it's hard to tell what bugs or other shortcomings exist in the tools. C and Java were designed without concurrent structures, and this makes me suspect HDLs derived from them will actually be more awkward than VHDL or Verilog.

Re:VHDL, Verilog and "those other languages"

[csbell]

I don't think 'obtuse' applies to VHDL for the single reason that there are not many ways to do a single thing. Unlike perl where there are almost an infinite ways to get results, VHDL forces you to code for a specific hardware. I've had to learn this the hard way, along with accepting the fact that *simpler* VHDL code produces better results.

Re:VHDL, Verilog and "those other languages"

[bluebomber]

I'm surprised you didn't mention Verilog

I thought the same thing. I'm also an embedded programmer. And while I don't design PLDs and probably won't write a line of Verilog during my career, I have had cause to peek at the code and I've found Verilog to be very readable. (After, of course, a quick 5-minute-or-less introduction to the language by one of the EEs.)

Re:VHDL, Verilog and "those other languages"

[cyberlync]

You really need to make sure of your facts when spouting them as doctrine. Ada was in fact not designed by committee, Ada was design by a single individual with support from a group of very smart people to give suggestions. Ada95 was designed by Tucker Taft, I forget the designer of Ada83, I am pretty sure that he would not be real happy with you calling him a committee. As a side note, Ada is one of the easiest and most productive languages I have every worked with (these include in order of use Java, C++, C, Perl, tcl, Ocaml). The syntax is very Pascal like and many C/C++ programmers don't like that, but it does lend itself to readability. Its threading model is very intuitive, its use of generic is well thought out, memory management is very simple even though there is no garbage collector. In any case, look into something before you make snap judgments.

Re:VHDL, Verilog and "those other languages"

[KarmaPolice]

I'm surprised you didn't mention Verilog -- it's an HDL that is (outside of military contracting) much more popular than VHDL.
[SNIP]
The reason for mentioning VHDL as opposed to Verlog is probably that he's a european HW designer. European designers use VHDL and everyone else uses Verilog.

BTW: I'm studying electrical engineering at Technical University of Denmark and I've never written a single line of Verilog - none of the professors teach it since it would be hard to get a job in europe.

Re:VHDL, Verilog and "those other languages"

[martinde]

Actually, while Verilog is more popular in the US, VHDL is more popular in Europe. It's pretty hard to say overall which is more popular.

Re:VHDL, Verilog and "those other languages"

[Anonymous Coward]

It has been my experience that VHDL is used much more widely for FPGA design where Verilog is used mostly by ASIC designers. Also, VHDL is used a lot by companies that do a lot of government work. VHDL - VHSIC Hardware Description Language was actual developed by the government as a way for people working on government contracts to describe their designs.

But I think more importantly, you have to look at the tools available - any language is not very useful if you don't have a way to target your technology. In the EDA world Verilog seems to be the most popular because all of the EDA vendors release tools that work with Verilog first, VHDL is usually an add-on to the tool, or released later. I've never heard of JHDL, but if there is only one source for a tool to target your technology, then it sounds like a bad move to me.

Re:VHDL, Verilog and "those other languages"

[Entrope]

Thank you for your comments, but the Ada FAQ (see section 2.6), a timeline of the language's history, and a writeup for a UMich course suggest otherwise. While S. Tucker Taft may have led the Ada 95 revision team and Jean Ichbiah led the Cii Honeywell Bull team designing the submission to the DoD (which became Ada 83), the design of the language is clearly not the work of a small number of people.

Rather, it was designed to meet a specification from a DoD working group and received feedback from hundreds of reports (and dozens of individuals or other groups).

While Robert Dewar's answer to "Was Ada designed by a committee?" is certainly witty, a rose by any other name would smell the same. Taft's answer lists -- for just Ada 95 -- not only the core "Design Team," but five other full- or nearly-full-time teams ("Language Precision Team", "Requirements Team", and three "user/implementor" teams) and the large group of "Distinguished Reviewers."

Given all that, I will retract my description of Ada as being designed by a committee -- it was in fact designed by a beauracracy!

(As for VHDL, I cannot find as detailed information on the web about its history, and don't have my VHDL books with me right now. However, the timeline at the University of Erlangen-Nürnberg's VHDL-online -- with discussions and defining requirements taking up most of a decade -- suggests that it suffered from too many cooks at times.)

While I agree that Ada and VHDL are very expressive and powerful, it's not good to get rose-colored glasses about their history or (especially in VHDL's case) drawbacks.

Re:VHDL, Verilog and "those other languages"

[twalk]

2 guys were involved in the actual VHDL '87 writeup, Paul Menchini and I can't remember the name of the other. Paul did about the whole '93 version himself. He told me that he felt that many of the problems with the '87 version were directly attributable to merging the work from two people instead of having one person's "whole concept" (something like that). (Of course that might just be his ego talking...)

HEH

[keepper]

This just reminds me of the differences in thought between EE and CS...

HDL's in java or C? HEH... What's next? x86 assembler implemented in java? ( pun :-P )

Maybe you should take a look here http://philip.greenspun.com/humor/eecs-difference- explained

Damn CS's :-P

Re:HEH

[Anonymous Coward]

Damn straight ...

Re:HEH

[free779]

Almost already been done. Not exactly x86, but Jasmin will convert jasmin 'assembly' code in Java byte code.

Another Java assembler is the Java Bytecode Assembler

To make it even better, there is a Jasmin backend to GCC, so any language that GCC supports can be compiled into Java bytecode!!

Slow down Cowboy

[Uttles]

The very reason languages like VHDL are "obtuse" is because hardware isn't the most intuitive thing out there. In order to make good chips, you have to thoroughly think things through, not just whip out some POS java script. VHDL is a good tool and I think taking C++ or Java code and making a chip out of it would only produce an extremely inefficient piece of hardware.

VHDL tends to the standard

[nesneros]

In my experience, things tend to work better when you go with the standard, which I would say is VHDL.

Last year, I was in a FPGA-based hardware design class, and during the early course of our group's project, we thought that maybe we'd be better served by switching to something easier to use. Long story short, we wasted three weeks trying to learn the "simpler" method which nobody at our school used, while the other groups plowed through VHDL, which everyone at the the school used, and they ended up with a better result.

I'm not saying "Because its the most popular it must be the best," but user base realy is a major decision when trying to go a particular route.

Re:VHDL tends to the standard

[Flick]

>> In my experience, things tend to work
>> better when you go with the standard,
>> which I would say is VHDL.

A standard for what? Verilog is a standard. 85% percent of the chips designed today are described in Verilog.

Verilog is to C as VHDL is to C++. You can easily hang yourself in C just as you can in Verilog. VHDL is heavily typed and object oriented, so you have to write more code but the compiler will pervent you from doing bad things.

The answer to the question of Verilog vs VHDL for FPGAs is what tools do you have. You can describe the design in C using SystemC or C-Level. But it comes down to what code your FPGA tool can swallow. Remember, you have to map your design to the logic found in the FPGA so you need library support for the FPGA with any language you select.

If you have the budget, look at VisualHDL (Innoveda). It let's you graphically capture your design and it produces Verilog or VHDL as it output.

"I'm tryin' to think, but nothin's happenin'!"
-- Curly

Re:VHDL tends to the standard

[Anonymous Coward]

VHDL and Verilog are both standards for development and modeling. Verilog simulators are faster than their VHDL counterparts however. Synthesis tools convert VHDL and Verilog to gates equally well.

Re:VHDL tends to the standard

[Anonymous Coward]

VHDL is more popular in Europe. Verilog is more popular in the U.S. Remember, VHDL was brought to you by those same fine folks that brought us ADA.

Having switched between both from project to project and company to company over the last 5 years, I find that I definitely prefer VHDL. People whine about it being easier to make mistakes in Verilog, but these are probably the same people that don't truly understand the concept of Validation either (as most CS people don't really). If you do proper validation you're going to the same amount of validation work no matter which language you use, and you'll find the same RTL bugs, but I find it much faster to write the code in Verilog. (Not to mention, much easier to read). Universities tend towards VHDL from what I can tell (since it's a government/committee based standard), although the University I attended taught Verilog exclusively.

Intel tends to use VHDL and their own proprietary language, but a few groups in Intel do use Verilog.

Companies like Toshiba and Via use Verilog exclusively.

Celoxica DK1

[Anonymous Coward]

is a C-based HDL. We've been reviewing it, and its pretty impressive. Not really C, but fairly similar. One of our engineers managed to port a complete GSM codec (originally in C for some 16 bit DSP) from scratch in about 3 weeks, so its easy to use. Check out their site.

Re:Celoxica DK1

[Anonymous Coward]

This is also known as Handel-C btw.. Pretty nice to work with.. It lets you write in a c-like language and also do things like declare blocks of serial code so that the compiler can arrange blocks to operate in parallel. The downsides are (a) not many tools for Handel-C (though they can translate to other intermediate gate level languages) (b) universities have to sign screwy contracts.. We gave up on Handel-C because it looked like anything we designed at our university would become their IP. Granted, its not like we were curing aids and it is a cheap tool for universities..but still..

Re:Celoxica DK1

[Anonymous Coward]

I've used DK1 for a number of large scale FPGA projects.

In terms of productivity and time to market, JHDL/VHDL/Verilog/SystemC are dead in the water.

BTW...

[keepper]

I did not mean C-like syntax..

I am aware of verilog and other hdl's with "c-like" syntax...

but the way he worded that question seemed to imply something very different

The real difference...

[paulwomack]

...is between gates and serial processors. The coding languages reflect this difference.

BugBear

You are so right

[Uttles]

"I don't care if it runs fast, programming it is EASY"

Damn CS majors...

Re:You are so right

[Anonymous Coward]

No shit. You see that way too often here.

Toto - This doesn't loook like C (part deux)

[stevew]

Let's try that again.

There is a reason that it looks "obtuse" to you. The language is built to describe parallel things, i.e. stuff occuring at the same time, and at a VERY low level. As others have mentioned, it's built for EE work not CS work.

If you want something that is more C like, then look at verilog. I picked up verilog in 4 days and was producing useful hardware descriptions. I maybe have one advantage over you though. I'd been using pal programming languages like ABEL for 10 years before I ever saw Verilog. You might say my head was already in the right space.

If you want a free verilog compiler that covers 95% of the languages capability check out www.icarus.com

Write Java and get gates?

[Anonymous Coward]

Xilinx (FPGA semiconductor ompany) has a tool in early beta which let's you write Java, in a normal software way, which is then translated to Verilog. It looks pretty cool, and is free to use at this point (beta). Check out: this link.

They seem to have gotten some fairly decent speed/area results.

Re:Write Java and get gates?

[Anonymous Coward]

This tool that is in "early beta" is actually a company they sucked up formerly called LavaLogic that was a spinoff of something called TCI Telsys or something like that that developed this using DARPA moneys. This was all done back in the mid-late 90's and was bought by Xilinx sometime around 97 or 98 I think. In any event - this is hardly early beta - more in the realm of vaporware.
Be wary of the High-Level language to chip approach - makes great demoware, just bad chips. The problem isn't in the languages, it is in the algorithms. You have to (for other than the most basic demo applications) alter the algorithm for it to be effective in hardware. If you have to completely rewrite the algorithm anyway, than you really can't re-use your software code written in the high level language. So, might as well grab a tool like Verilog or VHDL that is suited to the problem of creating hardware.

Re:Write Java and get gates?

[ddavis21042]

As one of the developers of Forge, I can assure you it is not vaporware. If you don't believe me, go to: http://www.xilinx.com/ise/advanced/forge.htm and download a copy. Our "vaporware" runs on both Windows and Solaris :-)

As far as making bad chips, again I invite you to try it out before you make such blanket statements. "Those who say it can't be done should stay out of the way of those who are doing it!" (or something like that...)

ya i remember...

[acdc_rules]

... using ladder logic for programming programmable logic controllers. now that was something.... oh sorry, you said programmable logic devices, never mind.

gte910h, you have a long road ahead of you

[Anonymous Coward]

"but they seem so obtuse compared to C or Java."

French seems pretty obtuse compaired to English, but then again I ONLY SPEAK ENGLISH! Maybe what you question should be is "I'm too fucking lazy to actually learn anything, and I'm afraid of things I don't understand. I don't want to learn anything new or difficult, just something similar to what I already know."

With a shitty attitude like yours, it's no wonder the world is heading to the crapper. The fast & easy way is the best way - bullshit! But a little work into something and learn something that seems "obtuse." You might surprise yourself. But more likely, you'll give up because you're a shiftless piece of shit and you'll leave the difficult innovations up to other people.

You make me sick.

JHDL is supposedly good, but lacks in synth dept.

[borum]

I haven't used it myself, but some friends at university are using it for modelling both simple and complex logic. They seem happy about it - the learning curve is not as steep as 'real' HDL languages, so its ideal for teaching as well.
The problem, i understand, is synthesis (the process of making hardware out of your source files). JHDL seem to lack those, but things might have changed...

So remember to check out the synthesis tools before you commit to JHDL....

SystemC vs. HDL Languages

[Boone^]

Well, there's SystemC, which gives you a C-like syntax to describe logic at a stratospheric level. I tried playing around with it a little bit and it seems like it would be great if you had to crank out very small blocks, running at very slow speeds, multiple times a day.

But, if you're doing any kind of sizable project (like designing parts of supercomputers, for instance) then you'll just have to bite the bullet and learn how to design logic. VHDL is a little screwy, but Verilog is a breeze to learn and use. Just like you can't fake being a programmer, you can't fake being a logic designer. Just learn the background, there's no way around it.

When in Rome...

Re:SystemC vs. HDL Languages

[Hal-9001]

When in Rome...

...speak Roman? ;-)

Re:SystemC vs. HDL Languages

[Anonymous Coward]

No, Latin! Or failing that, Italian. Sheesh.

compiler pile-up

[tangent1900]

it's like using C/C++ instead of writing in assembly: it's more intuitive and a hell of a lot easier, as long as you have some extra horsepower to make up for the compiler inefficiencies. depends on the budget and/or time constraints.

JHDL

[pauldy]

I can't belive I haven't seen this before but if we need any evidence that java is being used for way to much crap this is it.

Also the only reason you would have problems in VHDL is if you didn't understand how it works. When I got started in it I found I had to forget all the programming I learned and move into describing my circuts instead of trying to program their behavior. You'll find this type of mindset works well with VHDL/ABEL/Verilog.

OMG

[Anonymous Coward]

See what happens when we start to consider assembly language (and EE/digital logic) as archaic subjects, and de-emphasize it in compsci curriculums? We get wet-behind-the-ears kids wanting to design hardware - WITH JAVA. cause "VHDL is too haaaaaarrrd". lol.

hey TM5K...

[cyb0rq_m0nk3y]

have you seen me around? I need to talk to myself at some point. If you see me, tell me that I was looking for me.

Embedded Developer

[The Famous Brett Wat]

"What the...? Who the blazes are you, sir, and what are you doing inside my electrical appliance?"

"I'm an embedded developer."

As a Comp Sci Student.

[akula1]

I actually enjoy VHDL. I found it extremely easy to use once I realized that I wasn't actually programming I was just drawing with words.

Granted I was doing fairly simple things, (junior level Computer Organization class), but VHDL didn't seem obtuse at all to me.

Hardware is not Software!

[Anonymous Coward]

I'm an ASIC designer and the team I'm on just wrapped up another chip. We used Verilog, which in my experience, is simpler than VHDL for *synthesizable* code (more on that later).

For the whole chip we used nothing but if-else, case, the usual boolean operators (and, or, xor etc.) and shifters. That's pretty much all you need. Loops, multi-dimensional arrays etc. aren't needed AND the synthesis tools will often either reject them flat out or construct very strange logic from them.

In order to "get" VHDL, you need to pretty much abandon all your software habits. Think in terms of parallel operations, not serial ones. Also, draw timing diagrams! They can be a real life saver.

Our company bought a soft IP core from a third party about a year ago. We got the VHDL source and everything. We tried to synthesize it and the tools eventually did it...but it took 14 hours. So, a few of us took a look at the code. What we saw horrified us. It was written in VHDL, but it was written in an extremely "software" like manner. A week later, we had re-written most of the offending blocks. The result was that the design synthesized in 4 hours and was 20% smaller.

Hmmm...I had a point in there somewhere, but it seems to have turned into a long rambling story.

Remember, coding hardware in an HDL is, and will probably never be, the same as writing software!

Re:Hardware is not Software!

[Anonymous Coward]

What a load of crap - i hope that you are not the only person on your team...
Loops, multidim. arrays ARE sometimes needed for testbenches.
And yes, VHDL does give you the ability to write designs that are hard to synthesize - but so do verilog (if-else and case are considered poor design by some).... Its a question of restraining yourselves from using the easy-but-not-synthesizable features.

The guy asking the question was just trying to learn something about programmable logic. Most of the posts come from people that thinks that JHDL is exactly the same as writing servlets (it is not - its usually about tying objects together).

-angry_guy

Re:Hardware is not Software!

[Anonymous Coward]

I was referring to synthesizable code, not testbenches. Yes, loops etc. have their place in testbenches. No argument there.

if-else is usually a poor choice since it implies priority. This does not usually generate a mux. Every synthesis tool I have worked with interprets "case" statemtents as muxes, so I don't really see a problem with that. What is an alternative to using a "case" statement? ( other than the X = (Y) ? A : B; format)

I suppose you could code entire chips using just and/or etc., but it would be more difficult to read the code (from a human perspective)

My main point was that most of the common structures that are used in software, will not produce sythesizable HDL code. Since the guy is doing PLDs, than I assume that he acutally wants to have his code synthesize.

Parallelism and J[ava]HDL

[Proud Geek]

While they never say it explicitly, the J in JHDL is for Java. Read the papers on their website and you will see! Probably either legal issues with Sun or the obvious embarassment of mentioning Java in hardware design circles prevents it.

The difficulty is that Java is a serial language for designing software to execute on a serial processor. HDL's target devices that are inherently parallel, and have the extra complexity and difficulty that comes with that. There is currently *no* compiler that can get good performance out of serial HDL's. It's a different programming paradigm; you might as well ask for LISP that looks and feels like C. Even if you match the syntax, you still have to change paradigms to get any useful work done.

The area this targets (I believe) is unified design, where hardware and software (such as it is) for embedded devices is specified in the same language. They want to go for reconfigurable computing, you know, the one where you can perform parallel 1-bit additions twenty thousand times faster than a P4. Thing is, targetting hardware, which is inherently parallel, you need a language that supports that parallelism. J[ava]HDL just won't work, period.

Re:Parallelism and J[ava]HDL

[Izmunuti]

Looking at some of their examples, it seems that they are striving to use a very high-level language to build a netlist. Whoopie.

They are using Java objects to instantiate gates , flops, and wires. There's hierarchy so an object can be a collection of other objects which is ultimately made up of gates, flops, and wires. In other words C = A + B looks like:

VHDL: C = A + B
Verilog: C = A + B
JHDL: adder(A,B,C) where adder , in turn is a glob of discrete gates.

Frankly, I don't see the point. I could make netlists in any number of languages. I don't have a burning need for a new one. It's not adding anything new and in some ways is a step back. For example, to do a multiplexer, it seems that I would have to instantiate one:

multiplexer(A,B,S,C)

While in Verilog or VHDL I could use a nice case or if-then-else.

if (S == 1'b0)
C = A;
else
C = B;

And instantiating a mux is better/easier/clearer how?

We must obey the synthesizers

[fireboy1919]

For very large designs, it is incredibly important to have a very good synthesizer, because FPGAs just aren't that big, and because hardware bugs are harder to catch (not only are there software bugs in hardware, but you can have bugs based upon physical problems) and more catastrophic.

However, there are really only two companies that make very high quality synthesizers: Cadence and Synopsis. Having used both of their products, I have to say that they only design for two languages: VHDL and Verilog.

And I must say, I don't blame them. Trying to extend Java to create hardware is crazy; they have to do a workaround in order to create multiple inheritance, as well as justifying the use of functions to specify IO properties of certian wires.

Syntax is sort of irrelevant, both VHDL and Verilog don't make this blunder. A function should not determine the properties of a signal - it makes a lot more sense that the only thing that functions can do is change the value of said signal.

Also, someone might try to use Java primitives that simply confuse the issue. VHDL has very basic support for primitives, which is very tied to bit manipulation (as well it should be, since each bit represents a single wire). Java isn't nearly as good without adding some non-inuitive (in Java) functions to the mix.

VHDL is not very close to ADA, despite a few slight syntactic elements. Verilog is not C, despite the same. They are HDLs, well suited to their tasks.
One final point: those languages (Ada and C) make good starting points for other languages. ADA provides the necessary strictness to ensure hardware design is not sloppy - a necessity since sloppiness results in errors and most hardware errors are impossible to detect during runtime. C was designed to be a low-level language, and to interface well with low-level operations, making it particularly well suited to the design of low-level systems. What other language makes a better starting place for a new languages design than these two based upon these lingual goals?

Re:We must obey the synthesizers

[Anonymous Coward]

hold on man... FPGAs can be quite large and rival small asics for complexity. even for my smallest fpga designs i use verilog and another high quality synthesis tool you've apparently never heard of: synplify. it's awesome for fpgas, damn fast too.

vhdl is way too complicated. i've never met anyone who uses it, outside of school. i have to believe the verilog is twice as popular.

Re:We must obey the synthesizers

[fireboy1919]

Why should we compare FPGAs to ASICs? That's not what Java (which has been adapted to a HDL) has been used for. I know they're "large" compared to ASICs. But ASICs are, by definition, small compared to conventional desktop systems. They're custom made to be that way.

Synplify is made by Synopsis, dude. Synopsis is a company, not a tool.

And for this argument, it doesn't matter how VHDL compares to Verilog. I was comparing both of them to JHDL, and basically stating that the only real choices for HDLs are Verilog and VHDL.

Also, I tend to believe you're wrong about the "verilog is more popular" argument. I use VHDL because more companies have VHDL packages than Verilog packages for the work that I've done, so that I can test my designs in VHDL before synthesis. Also, I've been able to find a lot more information about VHDL. Perhaps Verilog is more popular with the people you've worked with.
(On a side note, I think Verilog is way too simple - it makes you work at the lowest levels when you don't have to do so. You don't have to because components are already available that can do a very good job).

Re:We must obey the synthesizers

[Anonymous Coward]

Synplify is not made by Synopsis. It's made by Synplicity.

Learn VHDL

[aqu4fiend]

I think verilog has been mentioned already so I'll skip that (it's just VHDL lite IMHO). VHDL is around for a reason - it's about the maximum level of abstraction that's reasonable. High level (>=C) are great, but they work because microprocessors are designed to work with abstact structures. Hardware is just designed to work (usually). Think about it this way - if you want to program in C, program a *computer*, if you want to design hardware, keep in mind that you're designing hardware and *not* programming a computer.

If I'm totally off-base, and you were actually complaining about VHDL's crappy syntax (ON CLOCK'EVENT et al),just learn it - it's not bad at all once you get down to it, and it does make sense after you've used it for a while. (I hated it too when I first started).

Some thoughts from a JHDL developer

[omnirealm]

I worked in the BYU Configurable Computer Lab (the lab that developed JHDL) for about a year and a half. I built the JHDLOutput and the Design Rule Checker (DRC) components of the system.

One semester, the EE department decided to use JHDL as the HDL for the logic design class (then it was EE320), and I was the teaching assistant that "specialized" in the actual tool (JHDL). Basically, JHDL was used as an introductory HDL for the students. The results were interesting.

In short, most of the class succeeded in building an LC2 processor entirely in JHDL, interfacing it with memory, and programming it (netlist, run through Xilinx backend tools, transfer bitstream) onto a Spartan chip. Most of the issues arose in the students struggling with object-oriented programming (creating a "Wire object" and a "2:1 Multiplexor object") and in the subtle details of how to interface circuit components with one another. A lot of students would get sections of their circuits ripped out by the Xilinx tools for failing to simply attach one component to another. The schematic viewer, waveform viewer, and other debugging tools proved effective in helping with the actual design.

Automated and dynamic simulation is easily performed in the simulator GUI and in testbenches. There is a Finite State Machine generator. There is parameratizable Floating Point arithmetic unit (its size depends on the number of wires you pass to it when you instantiate it; there are many more modules like this). Parameters can be assigned to the circuits in JHDL to, for example, instruct the Xilinx tools how to assign pins to top-level wires. Multiclock functionality exists. My DRC subsystem can dynamically instantiate circuits and run user-specified (and user-defined) checks on those circuits through a GUI. JHDL is fairly sophisticated, and it is an impressive tool given that it is mostly a student-developed application.

Before I left the lab (I had a very heavy classload), we were kicking around the idea of making JHDL Open Source. There are many legal issues we had to deal with... I'm not sure how it's looking now.

Re:Some thoughts from a JHDL developer

[Anonymous Coward]

From what I heard at HPEC at MIT Lincoln Labs last November, the JHDL tool from BYU was to be open sourced the second quarter of this year. I'm looking forward to that. I was part of building a SmallTalk based synthesis tool that used Petri net inputs during my master's work. It was totally awesome to be able to hack on new features to a tool as they were needed.

my experiences with VHDL

[Jucius Maximus]

Having worked with VHDL for programming Xilinx FPGA's in digital systems class, I can tell you that the language, although somewhat obtuse to learn at first, is highly worth it.

And keep in mind that there are various levels of abstraction that you can use for VHDL. If you're going do to the gate level it's going to take you some good time to learn it but your chips will save money because they are smaller/faster/more efficient. Even if you don't learn the most abstract parts of the lanugage, you can still program the gate logic using C-like logical operators (which saves you huge amounts of time compared to cad tools where you have to connect the gates manually.)

The moral of the story: Spending the time to learn VHDL will pay for itself. The big chip manufacturers like Xilinx control large market portions, and their tools are VHDL-centric.

it might work

[Anonymous Coward]

it might work if you aren't interested in having particularly fast or small logic(i.e. spending more to get a bigger than necessary FPGA) and you can get it to work with the FPGA tool flow.... if your interested in implimenting large and fast circuits for computation you really need to understand all that obtuse stuff... alot of FPGA vendors add hardware structures like embedded aray blocks that can really improve your performance, but you need to know how to get the tools to use them.

the real limitation is what your tools support. and just about everybody supports VHDL and (to a little lesser extent) verilog. if you go off and use joe shmoe HDL your kinda locked into a very limited choice of tools...
and if you plan to be working with FPGA's for a while you really ought to learn VHDL and/or verilog... it's like the C of hardware design, love it or hate it its the standard that just about every professional in the field uses to communicate.

VHDL is good

[loo_hoo_ser]

Hello,

I am a programmer and digital hardware designer with 10 years experience in both areas.

I find that VHDL, while obtuse, is a terrific modeling language. There is a steep learning curve associated with it. Once you get the hang of it, it can do many things for behavioral modeling and RTL design of FPGA's and ASIC's.

It has been said that once you pick up VHDL, Verilog is easy to pick up afterwards.

It really depends on what you are trying to do. Are you trying to realize a design into an FPGA? For example, VHDL code is written differently when modeling behavior. When you're using VHDL to implement a real design for an FPGA, the coding style is different and many techniques you've learned in CS do not apply here. Good coding practice still applies such as well definied variable/signal names, proper data typing, generous use of white space, and verbose comments. However, that is where the similarities between C coding and VHDL coding end.

The real issue here with VHDL design to an FPGA are the tools. How well the tool that you've chosen (i.e. Synopsis Design Compiler or Synplicity's Synplify) reads in your VHDL, parse it, and create a gate level design using the low level building blocks available for a given FPGA/ASIC family.

Because of this, the code needs to be written in a specific way. To implement a counter, you would need to write a specific construct that the synthesizer recognizes.

But, that is just the beginning of your problems, there is no real good way to have a synthesizer infer that you want a ripple counter, compact counter, balanced, and so on. The only way to get exactly what you want is to define it gate by gate, what connections are connected to what. This provides for zero ambiguity how the design is to be implemented in an FPGA and you gain something such as performance or decreased utilization (there is a trade-off somewhere). In my experience, I find that synthesis tools try to find a happy middle.

The problem as I see it with the JHDL and other languages that try to supplant VHDL/Verilog is that they haven't matured. You will be hard pressed to find adequate tool support for those languages. Synopsis provides support for System C (if I recall correctly) but Synopsis products are horrendously expensive ($60K a year MAINTENANCE fee alone). Recently, EETimes reported that EDA companies are generally not happy with System C right now as its touted benefits don't seem to be happening.

Should you choose something other than VHDL/Verilog, your choice of platforms may be limited as well, such as using Solaris which are not cheap. It depends on your outfit, can they afford the cost and be on the bleeding edge or is it a shoestring outfit scraping to get by where it can (i.e. affordable FPGA tools on affordable platforms)?

There is the long term to consider. If you were to successfully develop a FPGA design utilizing JHDL for the first generation. What happens if support for JHDL disappears when the time comes to do a 2nd or 3rd generation of your design? The long term outlook for languages other than VHDL and Verilog are unclear.

Hope this adds some insight to your questions.

It looks interesting...

[drhpbaldy]

...but I think it will be quite a long time before you see people like Intel, IBM, Motorola, Nvidia, TI, et. al. using this. Spinning hardware is *expensive* and you have to absolutely know your design is correct. AFAIK that usually means a tool that has been tested, inspected and ripped apart many times over. So perhaps five to seven years down the pipe, we'll be designing hardware in Java. But...

...people are making good points that hardware is not software. Everything is happening at the same time and if you are thinking in a one stream of execution state of mind you are not thinking in the correct problem space. The virtual machine that is presented by most operating systems is simply nothing like hardware. Not to say its bad, its just different.

Re:It looks interesting...

[Anonymous Coward]

Wow...I guess people don't realise how much HDL's are used. While they will NEVER be used in high-end CPU design, they are used all the time for CPU core logic chipsets. I am an ASIC engineer for Compaq (working on Alpha, not x86) and we have used Verilog to design chipsets for the EV6 and EV7 CPUs.

Of coruse, for the high end clock forwarding circuits, we built them by hand with schematics.

No support

[joncraft]

I agree, the currently available hardward description languages out there (nearly nothing but VHDL & Verilog) are sorely behind the curve. Unfortunately, you're not going to get the support of the big EDA vendors (Synopsys,Cadence,etc.) if you go with an academically developed language like the one you mentioned. There are new languages coming down the pipe, however. A new Verilog standard was approved last year, which makes a few steps in the right direction. Also, there has been a good bit of momentum behind some newer languages, such as Superlog from Co-Design Automation, which is still under NDA, but looks like it has promise. HDLs develop very slowly. Companies invest millions of dollars in EDA software that only support the big two languages, and nobody is willing to budge unless everybody moves at once (sounds familiar!)

Re:No support

[Anonymous Coward]

And don't forget support from the technology vendors (LSI, TI, Lucent, IBM, etc) themselves. Each has their own flow for taking a design from HDL to silicon. These flows are based on accepting netlists in either Verilog or VHDL (seems mostly Verilog now days). I work for a company that does DFT (design for test) services and we have millions of dollars invested in software to support these two languages. It doesn't matter that they are mediocre - the cost of changing to another language would be enormous. You would need the ASIC designers, the service companies, the tool companies (Cadence, Synopsys, etc), the technology vendors, the people who make the testers, and others to all agree to support this new language. Agreed, something new is needed, but given the dollars spent on the current infrastructure don't expect change soon. This would be a tremendous effort. Perhaps we could try a smaller project as a warm-up exercise. Let's rewrite the GNU tool suite in COBOL.

Two other optoins

[Anonymous Coward]

The very esoteric language Haskell in the page Libraries and tools for Haskell has two links, one to Hawk and other to Lava. While the former is not of much interest for main questioner (Hawk is aimed only to verification of microprocessor's design) the latter has more wide goal. Here is the excerpt from Lava homepage:

Currently, there are two versions of Lava in use. One, Chalmers-Lava, developed at Chalmers University of Technology in Sweden, is mainly aimed at interfacing to automatic formal hardware verification tools. The other, Xilinx-Lava, developed at Xilinx Inc., is aimed at generating configurations for Xilinx' FPGAs. We hope to merge these two version soon.

Of course, they both are research projects.

HDLs have their place

[davros74]

I am an electrical engineer who does ASIC/FPGA design and DFT, and if there is one thing I can't emphasize enough, is that when using HDLs, think about the hardware implications and don't just write straight code like you would in a functional program.

I have seen numerous designs done by primarily FPGA designers which use the languages (esp VHDL) very liberally, which usually works fine for programmable devices where the compilers can make your code work as long as it fits and meets timing, but when you want to put that code into an ASIC, it's a nightmare (non-synchronous design, no thought about DFT). Just like when doing OO programming, you need to THINK about your design or objects first, then code it up in C++ or VHDL _last_. It's a "description" language. HDLs should be used to describe designs that have already been designed in your head or on paper. The synthesis tools can do very funny things with code that is even functionally correct but just syntactically awkward. Sometimes, you just have to write the HDL in a manner that gets you what you want from the synthesis tools. Sometimes, good code in = garbage out! Writing code in high level languages puts another layer of complexity into the problem.

We are currently investigating some of the new tools that are starting to pop up out there for high level hardware design. It appears to me that using high level languages makes the most sense when you want to do functional type designs, for instance, DSP chips. There it makes PERFECT sense: you describe your DSP functions and algorithms in C just like you would if implementing it purely in a software application, and the tools can translate that into a decent HDL description for a signal processing core. Other things which are more structural than functional, are better done in one of the HDL languages. But we'll see. Doing circuit design in high level languages like C and Java is a New Thing(tm) and so the performance of these tools yet on really large and complicated designs isn't well known yet.

But if you want to learn HDLs, I would recommend starting with Verilog. It's based on C and is syntactically much less complicated than VHDL. Verilog is also faster than VHDL when doing large simulations. And remember that Verilog/VHDL code always executes in PARALLEL, since you're describing blocks of hardware.

Clarification

[gte910h]

I asked about JHDL because it is based off Java. I wasn't aware that Verilog was based off C, or I might have looked there (C is my first choice in Programming Languages when given the option). The JHDL people claim that people learn it much faster than VHDL, so I was asking you guys for verification of its applicability and ease of use. I would like to actually get something working, which is a lot easier in something halfway familiar to me than something completely alien. English is much closer to German than it is to Chinese, and similarly that much easier to learn

A tutorial on Verilog is made available from a CMU professor. I think that Verilog will be more than sufficiently C-like to ease me into the PLD world.

I am aware of the huge difference of what kinds of behavior you are programming when you are using programmable logic devices vs. microcontrollers. But just because I am looking at a different paradigm doesn't mean it wouldn't be nice if some of my skills would transfer. I want to gain proficiency in PLD's because of the fact they can implement functionality otherwise requiring complex circuits. This is useful and I can't currently use it in my designs without another engineer to do the PLD.

I was really curious about the accessibility of the language. Java-like syntax would make it easier to entice more people to try to learn this skill, as Java is familiar to many people in the environments in which I work. I would bet Verilog has gained many adopters b/c of its similarity to C, who would otherwise use schematic entry to program PLD's, or avoid the parts altogether

To function well in the climate and level of embedded development today, you have to be able to do both sides of the equation if you want to be at all independent. I have seen horrific program design choices by people formally trained in EE, and I have seen atrocious, laughable circuits from those formally trained in CS.

A software guy sees a fault in a product and says it is a hardware problem.A hardware guy sees a fault in a product and says it is a software problem. The real engineer fixes the damn problem and tells the other two to grow up and pull their heads' out of their asses.

Re:Clarification

[bill]

"The JHDL people claim that people learn it much faster than VHDL, so I was asking you guys for verification of its applicability and ease of use."

Perhaps its easier to learn, but as any programmable logic designer will tell you - it's also about synthesis and what comes after. I'll present to you the normal process flow of a programmable logic part (in this case, an FGPA):

1. VHDL or Verilog design

2. Synthesis through software tool (ie Synplicity, Leonardo, etc).

3. Synthesis results in a netlist

4. Place and Route, usually through vendor-specific tool (Xilinx, Aldec, Altera)

5. Place and route results in a device programming file (usually vendor specific, could be JEDEC format)

Of course, in between these steps are any number of required simulations. You will conduct many re-iterations of functional simulation and post-layout simulation of the design. As you will soon see, and has been mentioned previously, timing is one of the most essential things about a programmable logic design. If your timing is screwed up or your propogation delays too great, then your part is not going to work, and you're going to spend a lot of money in schedule slips and re-designs.

As has been said, there is a WHOLE LOT of details here that are not addressed by simply pointing to this JHDL tool and running with it. I've seen some of the main driving factors in FPGA and CPLD design are the tool--part interoperability and availability. JHDL is all nice and good - until you get to the point for synthesize and place and route (or fit for CPLDs) and discover you're SOL.

I recommend you first define your requirements (in detail), and develop a system level spec. At that point, if a programmable logic component fits the bill (FPGA or CPLD), then pick a language with good industry support (VHDL or Verilog) and move from there. In other words - reinforce success: both VHDL and Verilog have proven track records in the industry, and designers have had many successes using them.

Re:Clarification

[mozumder]

Dude, just learn VHDL (or Verilog). No one is going to hire you because you know JHDL. They WILL hire you because you know VHDL, because that is what people actually use to build chips. You need to be learning stuff that's applicable to solve real-problems. JHDL will not do that, since your company will not be using a PLD or an ASIC synthesis tool that has support for JHDL.

I actually work for one of the large EDA vendors that sells a high-end ASIC synthesis and everything else solution. To me it appears that VHDL and Verilog will both stick around forever. I don't see anything else displacing them as HDL anytime within the next decade, since JHDL and SystemC has no advantage over VHDL or Verilog.

VHDL isn't the hardest thing to learn, either. The process is similiar to making a schematic- start with a library of pre-defined stuff, specify the external interface signals, define your internal state signals, form some groups of logic, and start to build the logic. Look, here's a 64 bit adder that adds every clock cycle:

LIBRARY ieee;
USE ieee.std_logic_1164.all ;
USE ieee.std_logic_unsigned.all ;

ENTITY adder IS PORT (
A : IN std_logic_vector(63 downto 0);
B : IN std_logic_vector(63 downto 0);
SUM : OUT std_logic_vector(63 downto 0);
clk : IN std_logic );
END adder ;

ARCHITECTURE rtl OF adder IS

SIGNAL OPERAND_A : std_logic_vector(63 downto 0);
SIGNAL OPERAND_B : std_logic_vector(63 downto 0);

BEGIN

ADDER_LOGIC : PROCESS (clk) BEGIN
IF (clk'event AND clk = '1') THEN
OPERAND_A <= A ;
OPERAND_B <= B ;
SUM <= OPERAND_A + OPERAND_B ;
END IF ;
END PROCESS ;
END rtl ;

You can build anything you want by sticking with the above framework. Don't worry about what kind of adder you have to build (CLA? CSUM?) Advanced synthesis tools decide that for you once you specify the clock frequency. The more advanced synthesis tools let you design even more complex logic (FIR filters, for example) quite easily as well.

Analogous to VB

[Anonymous Coward]

Using something like JHDL is analogous (in my opinion, at least), to designing and app in VisualBasic. It's fast, you can pick up the language in a few days, but when it goes through the compiler (or in this case synthesis), you're not going to get something nearly a concise as if you took the time and wrote it in a lower-level language, where all the work wasn't done for you.

OT: Re:VHDL, Verilog and "those other languages"

[Anonymous Coward]

Yes, this is very true.

Very often when people are discussing some new cool feature, they've found in some obscure language, a similar feature often exist in Ada. Tasking, exceptions, generics, welldefined libraries etc.

Also, the GNAT branch of GCC is now merged into the main GCC branch.

calm down bozo

[Anonymous Coward]

In fact, all human progress is driven by the requirement to make things easier. Otherwise brainboxes like you would still be doing your coding on punch cards. This poster has asked a fair question, and in fact his attitude makes a lot more sense than yours. jackasses like you are the reason the world is going down the pipe.

Re:calm down bozo

[Anonymous Coward]

Horeshit. His question is "I'm too lazy to learn something hard, what can I learn that is easy." This isn't about human progress - HARD WORK, dedication, and drive advances society. The lazy ass loser, which he (and apparently yourself) is, reap the benefits, while slouching through life never and accomplishing anything. If everyone backed off from anything that looked hard or obtuse, we wouldn't even have punchcards we'd be eating raw meat in a cave. Lazy fuckers like you make me sick - Goddamned societal leeches.

Re:calm down bozo

[Anonymous Coward]

and what have you developed in verilog, vhdl, or abel?

Yeah, I thought so.

Sad...

[nullset]

I'm surprised to see a fellow georgia tech CS student asking such stupid questions.

As a cmpe student at georgia tech, i encourage gte910h (name withheld) to take some REAL cmpe classes, ie more than ECE2030 which is probably where he was exposed to VHDL.

Take ECE2031, and while you're at it, maybe ECE2025. After that, you can take classes that really show off what VHDL can do, such as ECE3055 (Computer Architecture and Operating Systems)

some of these will be electives for you, but you might not get any credit at all for 3055.....it's still a fun class though.

My true advice: don't be such a wuss....if you want to be cmpe, switch to cmpe. we rock! join the dark side! (not only do we rock, we make more money too....)

--buddy

Re:Sad...

[gte910h]

I don't want a Computer Engineering Degree. I make devices that use electronic components. Rarely do I wish to make my own components. The Computer Engineering degree at Georgia Tech is an Electrical Engineering degree where you have to specialize IC/microprocessor design. I don't need or want that much training in those skills.

A EE degree to complement my CS degree might be a useful certification for industry, as well as provide additional training. There are many ways MaTech could have crossbred the CS and EE curriculum to make another major, but I don't really think a Computer Engineering degree is that useful, at least for any of my needs.

Re:Sad...

[nullset]

Well, if you want to make hardware, make hardware. if you want to make software, make software. maybe you would be interested in hardware software codesign.... www.codesign.ece.gatech.edu

anyway, if you want to design hardware components, use a hardware description language that is standard in industry. the same goes for software

you don't see me writing programs in befunge, so why would you do hardware in something nonstandard? :)

if you don't want to make your own components, stay away from HDL.

--buddy
(btw, i'm just playing devils advocate mostly here..... so don't take it personally and look up gte160h..errr nevermind....)

Re:Sad...

[tjb]

Hardware design skills are good for a programmer to have, especially if this guy wants to work on embedded stuff as a career.

I program a custom DSP, and let me tell you, the most useful classes I took in college (not GT)were my digital design classes. Programming comes pretty natural to me (as it does, I'm sure, for a lot of CS majors), but taking those classes widened my skillset quite a bit.

If I'm getting weird ass behavior out of my programs, I can grab the chip design and figure out WTF is going on (not HDL of any sort, our chip is schematically laid out in an ancient tool). If I need a new instruction in next chip, I have some idea of what is and isn't possible and can suggest ways of making it work. If I need to change the behavior on my dev board, I can grab the VHDL for the FPGA and change it. Very, very useful, allows me to get my programming done rather than waiting for other, extremely busy people to help me out.

So really, there's no reason for him to convert to the darkside. A CS with a decent digital hardware background is a good fit in the embedded world.

Tim

SystemC/JHDL vs. VHDL/Verilog

[Snoochie Bootchie]

I think something is being forgotten here. The reason SystemC came into existance is to provide a higher level of abstraction for system design. The ideal is to unify software and hardware design such that making trade-offs between the two is very easy. Should I implement this FFT in an FPGA or just keep it in C code and use an off-the-shelf DSP? How much does my throughput increase if I were to implement this accelerator in hardware?

The short term reality is that the current toolset will probably take SystemC code and generated VHDL or Verilog for synthesis. Why? Because RTL synthesis tools are mature and VHDL and Verilog are mature. You are much better off learning VHDL and/or Verilog and developing the RTL in one of those. Just as in any other area of engineering, having a good foundation of knowledge is always better then learning a specific language/skill. (I'll call this the principle of first principles) If you're trying to hide a fundamental lack of knowledge of programmable logic and logic gates in general, you'll dig a hole for yourself. While not direct logic equations, VHDL or Verilog will keep you closer to the hardware.

As for SystemC vs. JHDL, my current opinion would be to go with something based on C. Why? Because it is far more likely that you'd write C code for the low-level software required by your system than Java. Also, I think JHDL as currently defined is meant as a straight-up replacement of VHDL/Verilog. I, personally, don't see a compelling advantage to use JHDL over VHDL or Verilog for standard RTL flows.

It appears JHDL is being positioned as a better solution for describing reconfigurable systems. It may offer advantages for that niche. However, I'd agrue that any higher level language (e.g. SystemC) would offer an advantage given a good JHDL/SystemC synthesis tool that understood reconfigurable devices. The synthesis tool should be able to implement reconfigurable logic based on your higher level description.

Easy to write vs easy to debug

[dpilot]

>Verilog is easier to write, but VHDL is (seems) more typesafe and is easier to debug.

About a year back I began doing some work in Verilog, because it was common in the area. Next chance I got, I switched to VHDL. Both languages were learned from scratch. The C vs Pascal comparison for Verilog vs VHDL is rather apt. I found that mistakes in my Verilog design would lurk much later into the build process, whereas most mistakes in my VHDL design would show up much sooner. With conventional programming, the difference may not be that great, because compilation isn't that 'thick' a process. With hardware design its much worse, with several stages of synthesis, timing, and only after that do you get into place and route. Some of my Verilog mistakes didn't show up until place an route, where I never had a VHDL mistake make it past synthesis. These are even mistakes that make it through simulation. HDL can be subtle indeed, especially for a newbie.

To some extent this comes back to the old C vs Pascal debate. Unfortunately Pacal was crippled by the limited library and other factors of its definition, so the debate could never be truly intelligently done. There's a tremendous amount of "Real Programmers..." macho crap in the debate too, further reducing the intelligence level. (training wheels references, and all that.)

Today we gripe over and over about buffer overflows, and wonder why they keep happening. It comes down to this: The C language is perfectly happy to let it happen, so preventing buffer overflows is completely up to programmer diligence. While you can probably come up with a buffer overflow in Pascal descendents (Gotta include that 'descendents', since pure Pascal is *practically* useless, I agree.) it almost takes work. No doubt there would have been no end of griping about that max_length on the strings, but then that's pretty much what needs to be done by hand for C.

Ada currently carries the Pascal-descendent banner, and is still alive with a reasonably vital community. Oddly enough, the US DOD has largely abandoned it, thinking C/C++ leads to cheaper development. Much of the new Ada community appears to be European, by the way.

The insiders' view appears to be, "Yes, it's more of a pain to develop the code, and that takes longer. But you buy all that back and more when it comes to debug and maintenance."

Re:Easy to write vs easy to debug

[kiatoa]

Try verilog in conjunction with a rule based formal verification language for bug free code instead of using a draconian approach like VHDL to enforce correctness.

VHDL has so much overhead and is cumbersome to write in in my opinion. Verilog also seems to generally simulate faster. Also the free (GPLed) icarus verilog simulator is better than any free VHDL simulator I've been able to find :).

Also when it comes to writing behavoural testbenches I could never live without fork/join.

Lastly many of the deficiencies in verilog have been corrected in the Verilog 2000 spec.

Chip design != Programming

[Theovon]

If you're still quibbling about which HDL language to use, you need a few more years of experience learning how to design chips. The language is 1% of what you have to learn. Two years ago, I, a software engineer, was asked to design a chip for my employer, not because I knew anything about chip design, but because I was the only one who knew what was needed in the design. You should see some of the crap I wrote back when I first started. It's taken me two years to unlearn programming and learn chip design. They're nothing alike. I know Verilog syntax and semantics better than the senior ASIC designer we hired a year ago. His code is messier than mine, and he avoids certain features of the language, but his code synthesizes more easily to meet constraints. He's a better designer. Many programmers love abstraction. I do. Design a C++ class that performs some library of tasks and then forget about the internals of the class and just use it at a higher level in a bigger system. LISP is a WONDERFUL language for writing code at a very high level. Depending on your needs and your personality, there is a plethora of programming languages that provide different levels of abstractibility (is that a word?) and power. You must forget about all of that in chip design. If you try to abstract yourself too far from the hardware, the synthesizer is going to give you garbage. Some tools like Synopsys Module Compiler do a lot of the work for you and you don't know EXACTLY how it's going to pipeline your design, but you know, for the most part, what kind of hardware you're going to get. If you don't, then you're in trouble. When I was in highschool and was learning C, one thing I did was compile lots of little things to assembler and look at the results. I wanted to know what I was getting from my code. Given what I learned, I was able to optimize my C code much better. Likewise, when I started learning Verilog, I synthesized lots of small designs and looked at the gate-level results to see what I was getting. There were a number of things I tried to synthesize that I knew the synthesizer would choke on (because I knew that the design was counter-intuitive from a hardware perspective), and I got lousy results, as expected. One interesting rule of thumb in software development is that smaller code is faster. Although it's not true all of the time, statistically, if I write a function to perform a task and my code is significantly smaller than my co-worker's verion, my code will run faster. Exactly the opposite is true with chip design. The more explicit you are about the hardware you want, the better the synthesizer will understand what you want and be able to give you a good result. Remember that you are smarter than the synthesizer. Of course, telling the synthesizer that you want an adder is a bit of an abstraction over telling what gates you want for an adder, but nevertheless, when you say "a I'm sure some more experienced chip designers will see inexperience in what I'm saying, but from some of the other comments I have read, I think many generally agree with me. The bottom line is that although some languages may be better for chip design than others, good chip design comes from a chip-design way of thinking, which is completely unlike software engineering. One tip comes to mine, BTW. Many chips are embedded in systems with a CPU that will be controlling it. Don't try to put too much into the hardware. A little software can save a lot of hardware without any loss of performance or functionality.

Re:Chip design != Programming

[Anonymous Coward]

so, what happened with the chip you started
2 years ago? did your chip work the
first time?

Re:Chip design != Programming

[Theovon]

Well... it took some work to get it to meet timing which required a few of the oldest modules to be rewritten. I now look at the architecture of some of my earlier work and cringe at how sloppy it is, but it works.

I spent a lot of time doing synthesis and re-synthesis of modules and rewriting critical paths to meet constraints. Apparently, that's par for the course.

Before going to fabrication, we did extensive testing in simulation, and worked out almost all of the bugs then. When we got the first real chips, we ran through more testing and found three bugs, all of which we have software or hardware work-arounds for.

People are happy.

They're embedding THOSE now?

[Anonymous Coward]

I am an embedded developer...
Gee, I guess they'll embed anything. Imagine a Beowulf cluster of, er, him!

Think about your resume too...

[owlmeat]

Telling people that you've designed chips with Java is about as useful as describing your Quickbasic programming skills. Learn VHDL and you've made yourself a much more valuable employee.

Extremely Interesting Solution-Star Bridge Systems

[DaveWood]

http://www.starbridgesystems.com/cont-tech.html

I'm surprised I didn't see this at the top of the responses. These guys have, if their claims are accurrate (they are shipping hardware, supposedly to the likes of Nasa, so...), revolutionized both the FPGA development process and computer hardware architecture.

Their ideas seem to be based on the idea that a big array of FPGAs, which are reconfigured on the fly to suit a specific application at the gate level, is significantly (they claim orders of magnitude) faster than a conventional general purpose Von Neuman CPU or CPUs (even modern Athlons, etc). The frightening thing is that intuitively it makes sense to me, and if it really does work, it could change everything.

Obviously to make this work, they've developed a high-level language which compiles down to the FPGA level... They call it IIADL and/or Viva...

Looks fascinating.

-David

RISC CPU in JHDL

[Jan]

In June '01, Mike Butts published an independent reimplementation of the xr16 instruction set architecture, written in JHDL.

See:
http://www.easystreet.com/~mbutts/xr16vx_jhdl.ht ml
http://www.fpgacpu.org/log/jul01.html#010731
http://groups.yahoo.com/group/fpga-cpu/message/4 88

And Canadians learn both...

[Jennifer E. Elaan]

My prof in intro digital design taught VHDL. My prof in VLSI design is teaching Verilog.

If you've wired logic by hand with 7400-series TTL (like I have), HDL's come quite naturally. They're NOTHING like a computer programming language.

Grab a copy of klogic or something similar and play with digital design before you learn an HDL. You'll do much better design as a result.

You're thinking EE and SE

[Heretic2]

At my school, both Software Engineering is indeed part of the Electrical Engineering department; those are who you are really comparing.

Computer Science is different. Computer Science is more like: compilers, OSes, the Halting Problem, P and NP, etc. We look at asymptotic bounds, amortized algorithmic performance, etc.

We look at a different class of problems.

Various high-level modelling languages

[Anonymous Coward]

I assume that you are really asking what other options, aside from Verilog, which has most of its user base in the US, and VHDL, which is more popular in Europe, you have for building ASICS.

Apart from several non-standarized beasties based on C, Pascal and other stuff (Take sequential language, add parallellism, see what happens), people have been trying to use things like SDL.

SDL is a sort-of-parallell method of describing telecommunications procedures and protocols. Everything is based on process or thread concepts with relatively good state machine descriptions, and datatypes are what you would expect in a high-level language. There is both a graphical and a text-based input method. It is well standarized.

It is also cumbersome to use for digital logic. The datatypes are too complex for low-level logic (which everyone needs to do once in a while), and you are removed too far from what really happens. If a bug appears in your netlist, you will usually have hell finding your way in the VHDL code typically output from the SDL compiler, and you don't want to know about the netlist. There are no paradigms for describing clocks, resets or other stuff. Software people would write massive amounts of code, simulating it in SDL, and then call upon the hardware people to "make it work". This would often mean a total rewrite, in which case you have used SDL as a simulation tool, not as a synthesizable language.

In short, people have tried, but I have never heard of a successful project using something like this.

Jean Ichbiah...

[Modular]

was the designed of Ada (83). Ada (83) was an object based language, but not truly object oriented. Ada (95) is object oriented. It really is a nice language whereas Ada (83) isn't. It's too bad that when they finally fixed it that the US government abandonned it.

stick with Verilog and VHDL

[spatula]

Verilog and VHDL are both excellent hardware description languages. The syntax may seem obtuse at first because you are expecting them to be like programming languages. In a programming language, you describe a set of mostly sequential operations. In a hardware description language, you describe several blocks of hardware all operating in parallel. Obviously the syntax of an HDL is going to need to be a little different from your average programming language.

If you use either VHDL or Verilog, you will have plenty of choices for compilers, simulators, and synthesis tools. There are many books available that will help you learn these two languages. You will have access to excellent usenet communities at comp.lang.verilog and comp.lang.vhdl. If you only learn JHDL, you simply won't have so many choices.

I recommend learning one of the big two first. I think you will find that both Verilog and VHDL will meet your needs. I can't tell you which to choose, since I don't want to start a VHDL vs Verilog flame war here. I recommend checking out some of the VHDL and Verilog models at http://www.opencores.org and deciding for yourself which syntax you prefer.

Re:stick with Verilog and VHDL

[silentmusic]

And don't forget tools for test/testbench generation and formal verification which you'll want if you ever start designing ASICs.

Regarding the Verilog versus VHDL war - I work in Silicon Valley and we tend to be very biased towards Verilog out here.

What kind of developer are you...

[Anonymous Coward]

"I am an embedded developer..."

Funny, I can get up and move around my office any time I want...

Language Choice depends on the Designer

[spamcan]

The "right" system design language is currently a heated discussion in the chip design community. A design language based on a mainstream software language (like JHDL on Java, or SystemC on C++) means that each of us already has the compiler installed to run a simulation. Proposals made on proprietary syntaxes (like SpecC, Rosetta , Superlog , Esterel, ECL ) mean that you have to set up a new environment off the beaten path.
On the other hand, in chip design a language is used to express a model. In a proprietary language, the compiler errors will related directly to that model (like 'port not connected'), while with a mainstream software language you will see C++ or Java errors that might have nothing to do with a modeling error. So the answer to your question would be: if you are a hardware newbie, stick to an environment that supports you: VHDL, Verilog, or one of the new ones. If you like software engineering, go for C++ or Java.

AHDL seems like a very good choice

[akad0nric0]

Granted, you have to be using all the Altera stuff, but I understand that AHDL offers a lot of abstraction that is not possible with VHDL, and was recommended by all of my engineering professors in college (recent CPE grad), FWIW. This isn't my field of work, but everything I've read seems to indicate it's a fine PLC/FPGA language.

Re:AHDL seems like a very good choice

[Anonymous Coward]

I have experience with both. You have it 100% backwards -- AHDL offers much LESS abstraction than VHDL.

VHDL is obstuse looking cause its ADA....

[gte910h]

ADA looks obtuse too. Verilog looks pretty nice. That's what I want. Thanks for the input.

Re:VHDL is obstuse looking cause its ADA....

[Anonymous Coward]

Since you think Ada is obtuse, do you also believe that Ferarri makes campers?

Verilog

[Anonymous Coward]

try verilog, it's also supported from the official Xilinx et.al. tools.
verilog is near to c, while vhdl is near to ada

Re:HDL 'programming' - JHDL can help!

[aeromatic]

It is true that building hardware and coding software are different thought processes - to a point. Hardware is inherently parallel, and thus you must think in terms of everything happening simultaneously/in parallel.

JHDL has advantages that you attribute to both VHDL and Verilog. Because it is based on Java, it is much easier to debug than a C-based HDL. Java is also much easier syntactically than VHDL OR Verilog.

JHDL is structural. In JHDL, you describe your circuit using java classes to represent circuit components - for me very intuitive. If you want an AND gate, you instance a new AND gate.
Also, it is very easy to write parametric circuits in JHDL - i.e., an arbitrary-width adder.

JHDL currently does not have a "finished" synthesis tool, but it is currently being worked on. So in the future you will get the best of both worlds - a powerful structural description and synthesis capabilities...

[Tangent] FPGA/PLD/etc starter kits?

[Pope Slackman]

Does anyone out there know if any of the PLD companies (Xilinx, Altera, etc) offer inexpensive (<$500) dev kits for personal/noncommercial use?

I've been wanting to try using PLDs in some of my projects for pretty much as long as I've known such things existed,
but the cost of the tools I've seen is prohibitive to most anyone without corporate or university backing.

C-X C-S

Re:[Tangent] FPGA/PLD/etc starter kits?

[aeromatic]

Check out Xilinx's WebPACK software - it's free w/ registration, and it supports their xc9500 and coolrunner series cplds

According to their web page, it supports schematic entry, ABEL/HDLs.

http://www.xilinx.com/xlnx/xil_prodcat_landingpa ge .jsp?title=ISE+WebPack

Re:[Tangent] FPGA/PLD/etc starter kits?

[pacc]

From my experience most chips only need power and a simple parallell port programming adapter, so a dev-kit shouldn't have to be more than a few leds and a socket for something else.

The problem might be that the chips is developing rapidly so you might have to look a few years back in time to find something suitable to solder yourself compared to the new surface-mounted packages.

There are tools available for free, but it can be hard to grasp what you are getting and what you don't until you have worked with them.

Re:[Tangent] FPGA/PLD/etc starter kits?

[Anonymous Coward]

Yes, see http://www.xess.com -- they sell student edition versions of the Xilinx tools and other low cost FPGA dev boards

Re:[Tangent] FPGA/PLD/etc starter kits?

[KillboyPHD]

Try asking on comp.arch.fpga.

But just from a quick search on Xilinx's store, a JTAG connector and Prototype board runs about $550. The chips themselves can be pretty cheap (between $5 and $50), and they have stripped down toolkits available online.

Re:[Tangent] FPGA/PLD/etc starter kits?

[Anonymous Coward]

Try this path to Avnet, the are a electronics distributor and sell cheap eval boards.

http://www.avnet.com/em/en/evk/home/0,1729,SID%3 D0 %26NAT%3DUS%26LID%3D1%26CTP%3DEVK%26CID%3DINDEX%26 RID%3D0,00.html

Re:[Tangent] FPGA/PLD/etc starter kits?

[Eric Smith]

Spartan-2 eval board (XC2S200, the biggest Spartan-2, with over 5000 logic elements) for about US $150 from BurchED. I've been using it for months, and it's great. They also offer a lot of plug-on modules with switches, LEDs, SRAM, keyboard and display interfaces, etc.

You can use Xilinx Webpack tools, available free from Xilinx. Supports both VHDL and Verilog. (I wish they had a native Linux version.)

With the XC2S200, you can fit a 32-bit RISC CPU, a bunch of peripherals, and a little memory all into the FPGA.

Re:HDL 'programming' - JHDL can help!

[Izmunuti]

JHDL may be syntactically simpler that VHDL/Verilog but that's largely due to it being limited to structure (effectively a netlist). If one limited themselves to structural in VHDL or Verilog, one would also throw out most of the syntax.

Yes, it's good to be able to instantiate an AND gate when you need it, it's more productive to move beyond schematic capture when you don't really need to instantiate gates.

VHDL has the generate statement and generics so it supports parametric circuits quite well, and easily enough. Verilog can do it too but it's a kludgey mess compared to VHDL. One can do it with the help of macro preprocessors and parameters.

Nothing against JHDL. I guess I just don't see what it brings to the table that ain't already there.

Thoughts From A Professional FPGA Developer

[Light's Shadow]

I worked in the Virginia Tech Configurable Computing Lab for many years. I hold a Ph.D. in electrical engineering from VT. Currently, I work for Annapolis Micro Systems, Inc. http://www.annapmicro.com, the world's leading FPGA-based computing solution provider. I have developed several small applications using JHDL that were used as case studies in my dissertation. I've developed large scale high-performance applications using VHDL as part of my job. I have also used a tool that, I helped pioneer, called CoreFire(tm). I can offer the following point of view about the merits of the various options.

First, VHDL was developed as a simulation language. Later, when industry discovered that what it really wanted was an automated tool that converted an HDL to a hardware design, VHDL was adopted as an input language for that process. Large portions of the VHDL language cannot, in fact, be used when the goal is to synthesize the resulting code into hardware. So, hardware development with VHDL is actually done with a subset of VHDL, typically referred to as synthesizable VHDL.

VHDL does indeed provide a higher-level approach to developing hardware. Some relatively simple language constructs can lead to a complex hardware implementation. It is, for instance, very easy to describe a state machine in VHDL and have the synthesis tool translate that state machine into gates and flip flops.

Since VHDL was not designed as a synthesis language, the translation of a VHDL construct into a hardware construct is not well defined. Each company that markets a VHDL synthesis tools approaches the problem differently. So, a given construct synthesized by one tool might lead to a well-optimized piece of hardware, while it leads to an ugly mess when synthesized by a different tool. To get reliable results, engineers that use synthesis tools must become experts in the particular synthesis tool they use.

Another disadvantage of VHDL is that it is very difficult to produce reusable code. It provides some mechanisms that seem useful for this purpose at first, but which, with experience, turn out to fall short. As a professional FPGA application developer, I've abandoned VHDL. I typically spend much too much time fighting with the language or the synthesis translation process.

So, what to use if not VHDL? The first thing that needs to be understood about JHDL is that it does not allow you to write your application in Java and then synthesize it into hardware. JHDL provides a mechanism for doing structural hardware design. So, you're not, for instance, writing a while loop in Java and having that translated into gates. What you would have to do is describe, in terms of the interconnection of the available hardware primitives and macros, the detailed hardware structure of your while loop. JHDL does not raise the accessibility of FPGA design. You still need to be a hardware engineer. You still need to understand the low-level nature of the hardware that you're building. What JHDL does is make it easier to do those things. JDHL is a Java-based library that allows you to build hardware structures using a real computing language.

Re:Thoughts From A Professional FPGA Developer

[gte910h]

I did not realize JHDL was not synthesizeable. The history is a wonderful explaination of why VHDL is what it is.

What do you currently use?? Verilog? CoreFire?

Re:Thoughts From A Professional FPGA Developer

[Light's Shadow]

After facing years of low productivity using conventional HDL design, we conducted a serious study of the sorts of things that would really increase our productivity and that led to the development of CoreFire(tm). In my opinion, it's the best tool for my job.

Re:Thoughts From A Professional FPGA Developer

[hoquaim]

And how does CoreFire differ from HDLs like VHDL and Verilog?

Re:Thoughts From A Professional FPGA Developer

[Light's Shadow]

CoreFire(tm) is a graphical language whose primary purpose is to allow both hardware engineers and non-hardwarwe engineers to develop FPGA applications quickly.

While typical HDL's are designed to describe a fundamentally parallel process using procedural structures, CoreFire(tm) represents parallel structures as parallel structures using a data flow paradigm.

CoreFire(tm) provides a large body of ready-to-use cores that are optimized for speed on FPGA's. You don't need to understand anything about how to implement an FFT on an FPGA, all you need to do is route the data from wherever it is coming from to the core.

Where CoreFire(tm) truly shines, however, is in it's ability to create distributed control structures that are correct by construction. My experience with the development of FPGA applications is that building the computations is really the easy part. The hard part is getting the data into the system from the outside world, managing the data as it gets routed between various computations, and then getting it back out into the outside world. Typical HDL's encourage centralized control structures that have to be designed when you've got your computations all ready to go. With CoreFire(tm) you just draw out your computation as a dataflow graph and CoreFire(tm) produces the control that you need automatically.

JHDL + clock gating = quick, large, low power

[petdetective]

If you intend to use a high level hardware definition language, be prepared to have an implementation (netlist) that is not optimized for area (gate/register count) or power consumption. I beleive the only way to gain a smaller area is to be as explicit as possible in your JHDL code. However, if you can be smart about defining clock-gating (limiting the gates and registers that see clock transitions when not in use), you can solve the power consumption problem.

Conservatism is good for you

[Anonymous Coward]

After spending the last 5 years working on u-arch design and implementation as well as different MGate ASICs I consider myself an intermediate, half senior ASIC designer.

My experience so far have made me into an old-schooler. Design is done simple and conservative. Things like:

(1) Whiteboards are good design tools. Use colors for datapath, control, exception/IRQ/flags, clocks etc.

(2) Design on whiteboard && paper == Simple code. As others have stated, a good thought out design doesn't require advanced language features. This in turn means less tool problems, faster toolruns etc.

(3) Learn the features of the language and their HW equivalents. Build test designs for different language constructs, guess the HW (including routing, registers and gates). Learn to see the HW when you write the code.

(4) Emacs + language mode == high productivity. Ignore managers that believe that Visual HDL, Renoir etc == good designs. (They don't).
Tools that give you the block hierarchy and possibly block interfaces with wires are very useful. But the actual contents should be written.

(5) Stick with Verilog. Ah! A language war you say. But there it really isn't. It's culture. EDA tools are just about always developed in the US. Americanos generally use Verilog, knows Verilog and are more comfortable with Verilog. This means that (A) The tools are developed for Verilog first and (B) generally have fewer bugs in the Verilog versions.

Superlog is a super language and I would love to use it - when it's at least as supported by the EDA vendors as VHDL. SystemC and other C-things? Look at the comments by colleguages in the ESNUG maillists. I wouldn't bet my design methodology on those languages and tools.

Platforms? NT was hailed as the new EDA platform, it went away. Linux is doing hefty inroads, they are everywhere at least as workstations for design entry, block simulation and synthesis jobs. Quite a few of the new tools are being developed on Linux and ported to Solaris (and HP-UX - the next OS to go in EDA?).

I have used VHDL and Verilog extensively. The ability to describe the HW is roughly the same in each of them. It's much more important to do a good arhitecture, partitioning and models. Learn that, pick up the language of choice and do lots of testruns. Good luck!

Re:Conservatism is good for you

[Anonymous Coward]

If I could finally get my "Monitor Reach-Through" technology to work, I would use it to kiss you, whoever you are. :)

Re:HDL 'programming' - JHDL can help!

[Anonymous Coward]

"I guess I just don't see what it brings to the table that ain't already there."

The same thing Java brings to every problem domain: Inferior solutions to solved problems; but its COOL, man.

My expierence of learning HDL

[Anonymous Coward]

As some one that has just learnt VHDL (+ a little Verilog) at uni and got a job designing FPGA's. My recommendations for learning an HDL language are: -

1) Start at the basics i.e. What an and gate is made from, how a mux works, Bullion logic ect...
2) Get a good book. I couldn't find a good tutorial on the web. (Maybe I didn't look to well)
3) To begin with live by three rules. (When you get experience you can bend/brake them)
I) never gate the clock
ii) Clock everything.
iii) Give everything an Asynchronies reset.
4) Remember at all times your not writing software. Your describing hardware!

Other thing to note are.
HDL's is not much good for home projects. Even small projects will need quad flat pack or BGA devices and if you can mount them on a PCB at home I'm impressed or one!
As for the VHDL/Verilog argument. Like all these arguments it's six of one half a dozen of the other.

JHDL systemC ect. Will be great when they mature.

Make an alarm clock. Ever HDL course I've been on makes an alarm clock ;-)

Using C++ to Simulate Designs

[mssymrvn]

It's funny that there's a lot of talk about which HDL to use. The company that I just started working for is now using C++ to simulate and design ASICs. And we're talking about 8 Million+ gate designs (it's a volume rendering chip). Verilog and VHDL simulate like dogs on any platform. Here, they've written their own tools and use a very strained version of C++ (which compiles nicely using g++ on any platform) and spits out waveform files to be used with viewers like VirSim and SignalScan.

The gist of this is that the HDL world might be moving more towards C++ and away from Verilog due to the increase in simulation performance. The CRTL that we code is more like RTL (register transfer language) rather than abstracted/software-only C++, but it simulates 4-5 times faster on a 2GHz P4 (under Linux, hurrah) than Verilog. Plus, Verilog simulators that any reputable semiconductor-house will signoff with cost US$20k per license (or more).

Of course, the down side is that for now, we still have to run Perl scripts that translate the C++ to Verilog which is then synthesized using Synopsys (and simulated using VCS for sanity). But as things move forward, don't be surprised to see companies like Synopsys and groups like the IEEE moving to coming up with some way of writing RTL in C++ and synthesizing directly.

Re:Using C++ to Simulate Designs

[Anonymous Coward]

So you work for Merl?

I've found that the best way to improve simulation/verification performance is to prototype in Xilinx Virtex parts. We were able to run our chip at speed, perform software development, and do customer demos and field tests before tapeout. And we had the chip running in the lab the same day that it was mounted on a board.

Unfortunately your design sounds just "a little" too large for that, and since you probably have a hell of a lot of interconnect that would make paritioning the chip into multiple FPGAs difficult to impossible.

Do you guys have any way to do formal verification of C++ versus Verilog versus gate level? It sounds like RTL level Verilog simulation is still a bottleneck for you. (I'm guessing that you use Verplex for Verilog RTL versus gates verification.)

I assume that you're using VCS for Verilog simulation and have tried all of the different settings. It's worth wasting an hour or two to figure out how to maximize it's performance. (You're getting a good deal if you're only paying $20k a copy for VCS.)

Re:Using C++ to Simulate Designs

[mssymrvn]

So you work for Merl?

Or C-Port/Motorola.

Prototyping sounds like a handy thing to do. There's a Quickturn spinoff that does something like that by putting some FPGA boards in a Sun workstation. But their entry price is something like US$700k as I recall. I can't remember the name of the company though.

As for the other environment issues - since I've just started there I can't give you specifics since I'm still learning the C++ RTL, let alone the big picture of the formal verification.

As for $20k for VCS, I'm not sure what our licencing terms are for it. But you're right, I'm sure it's quite a bit more than $20k now that I think about it. Given that Design Compiler is $100k a license why would VCS be much cheaper.

It's actually funny because three or four years ago I worked for a company that was being cheap so they bought one or two VCS licenses and six or so VCSi licenses. The difference: VCSi would put random wait delays of varying length in the simulation that merely slowed things down. And slow sims down it did. I used to see 45 minute delays in the middle of the sim. Rather annoying when it's 9:00pm at night and you want to go home but can't until the sim results come out. And for that we paid somewhere around $15-$20k. Such a deal!

Check out BYU, Celoxica, Frontier Design

[Anonymous Coward]

I've reviewed several of these tools, some of which are not yet publicly available.

JHDL was developed at BYU, so that's the best place to look for information.

Celoxica makes a product called DK1 that uses their variant of C called Handle-C. It has significant differences from C, but is closer than VHDL or even Verilog in my opinion. Synthesis usually took twice the space and gave me about half the clock as hand written VHDL, but you could probably improve that a little if you really dug into it. The thing I liked about this one was a lot of control over parallelization.

Another one to check out is Frontier Designs, now Adelante Tech. They have a suite of products with the A|RT surname. Testing their builder, I had a little less control over hardware usage, but got size and speed almost as good as hand written VHDL.

Note that these tools, like most HDL stuff, are kinda pricey. But they could be useful as long as you're not pushing the limits on your FPGA to much.

Re:HDL 'programming' - JHDL can help!

[svirre]

While VHDL might seem cumbersome syntactically, you will soon realize that it brings a significant readability advantage over the c-like syntax usedinverilog and to some extent java.

As for structure. All HDL's will have some method for describing structure. VHDL uses the entity as the most common hierarchial component. A entity has a well defined interface, and may use generic parameters. In addition you can use blocs for describing smaller subcomponents and configurations for describing the overall system. (One very useful propery of VHDL is that you can have multiple implementations (architectures) of an entity. A configuration is used for selecting the apropriate one)

Genericity along with generate statements make it very easy to describe very general structures. Good for reuse.

From what I gather of JHDL is that it tries to be a behavioral description language rather than an HDL. This poses a problem at synthesis as behavioral synthesis is a lot tougher and more error prone process than rtl synthesis (though improvements are beeing made)

I don't really see at first glance what this particular language might offer (though it might find a slot in dynamically reconfigurable circuits, (which is rather margial IMO)).

View from an FPGA application engineer at Xilinx

[Xilinx_guy]

This discussion on JHDL is good, since it highlights the huge difference between writing code for a serial processor and parallel hardware. JHDL seems to be a Java based methodology for creating structural circuits which also happen to be simulatable using the Java environment. Bravo! But there are serious complications for people who want to get the most performance out of the FPGA silicon. FPGA design has evolved from the early days where a schematic was your only choice, but frankly, we still have a LONG way to go before we get as far as the convenience and power of the latest software IDE's for Wintel development. It's coming, I tell you! (having seen the inside stuff on future tools)

I have a few words to say about the various methods.

Schematics: OK for 1000 gate designs, but it scales very poorly to million gate devices.

Verilog: Easy to learn, simulates fast, can be scaled to very large designs, but it lacks OOP features, as well as hooks for attributes to easily implement EDIF properties that are so important for low level FPGA floorplanning. Some tools have pragmas that will let you floorplan, but it's pretty crude, since pragmas don't have any language hooks for doing loops or anything. You pretty much have to extend Verilog with a macro processor like VPP before it becomes practical for million gate high level ASIC design.

VHDL: Complex language, takes a while to learn, has some good OOP features, as well as the all important attribute which permits structural design equivalent to schematic level implementation. VHDL is slow to simulate and VHDL also suffers from crappy parsers, since most synthesis vendors don't support the full language (Mentor comes closest). I can synthesize sin(x) and cos(x) with only a single tool (Leonardo) at this point, since it is the only tool which really supports floating point calculation during elaboration. Even then, I have to convert the float (type Real) into integers to realize actual hardware. Because of the poor language support, many designers are looking for System-C, Handel-C, or JHDL to give them the higher level synthesis support. Most new internal IP development at Xilinx these days is being done with VHDL, since Verilog is such a bitch to parameterize and floorplan. Believe it or don't, but a lot of IP cores in our Coregen tool are done in Java. (The Java code creates a structural netlist, with optional floorplanning.) This seems to be more difficult that VHDL, so it's losing popularity lately. SystemC, Handel-C, JHDL can sort of be lumped together as high level simulatable structural methods that all share one feature. They don't have the hooks for low level FPGA design (like attributes), so fancy stuff is pretty tough.

Bottom Line: All design methods will be tossed in the meat grinder of the marketplace and the best will survive. Come back in 5 years to see what happened.

VHDL

[nil_null]

I had trouble my first attempt at VHDL, but at some point in the semester, it just "clicked" and I suddenly understood it... and loved it ever since. This is something I want to get further into during grad school. Its interesting hearing from all of you who are out there doing this stuff.

Re:Extremely Interesting Solution-Star Bridge Syst

[Anonymous Coward]

Unfortunately it's very easy to link numerous FPGAs together in a systen which is theoretically extremely powerful. However the main challenge is how to program these complex systems. Starbridge have been around for years now, and have shown no concrete signs that they've made any significant breakthrough in reducing design complexity. As a result their systems are almost useless.

JHDL

[thayn]

Having used JHDL somewhat extensively I wouldn't recommend it for anything but the learning environment. It's really the equivalent to a netlisting language, jave (OO) style. For the learning environment it is excellent because its so tedious but basic. You have to instantiate everything! Every wire, every pin, but it is a good way to learn what's going on inside. I learned JHDL before VHDL and found it very useful because when I got to VHDL, one, I could appreciate its niceties and two, I knew better what VHDL was doing in the background that I couldn't see, thus allowing me to write more efficient code. This is because a certain task that takes 10 lines of code in VHDL might take 300 in JHDL. If you are interested in learning VHDL but don't have the money to dump into expensive software try the free stuff you can get online. You usually can get pretty decent free software from the big FPGA companies since they want companies to buy their chips, and the software they give only works on their stuff.

Intuitive? Ada?

[shaldannon]

I had the pleasure^h^h^h^h^h^h^h^hmisfortune of having to take most of my programming courses at Auburn University in the CSE department. For four years I learned about linked lists, trees, etc. using Ada. I will give you that it is a very verbose language, but I would not call it intuitive. It's certainly not as intuitive to read in a float, munge it into text, and then print it all out. Consider that it would take me more lines of code to print "Your order is $29.95" in Ada than it would in Perl, C, C++, or (maybe) Java. It would certainly require more hoop-jumping than Perl, but I'm not biased.

They tell me that the running wage for good Ada programmers is well over $100k/year. Some get 2-4 times that. Perl programmers don't generally get that much, but I'd rather do Perl than Ada because it is so anal-retentive. If you want to make sure your airplane doesn't crash due to software failure, use Ada. For anything else, find another language.

Ada may be stable, but anal-retentive verbosity does not intuitivity define.