Slashdot Log In
Anyone Using JHDL for Programmable Logic?
Posted by
Cliff
on Thu Jan 17, 2002 09:07 AM
from the describing-hardware-using-coffee-derivatives dept.
from the describing-hardware-using-coffee-derivatives dept.
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?
This discussion has been archived.
No new comments can be posted.
Anyone Using JHDL for Programmable Logic?
|
Log In/Create an Account
| Top
| 153 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
VHDLs are good for you! (Score:1, Offtopic)
JHDL, now -- let me guess: Just-right Height Density Lipoproteins? Sure sounds good to me...
;)
HDL 'programming' (Score:5, Insightful)
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
VHDL, Verilog and "those other languages" (Score:4, Informative)
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" (Score:4, Informative)
HEH (Score:4, Funny)
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
Maybe you should take a look here http://philip.greenspun.com/humor/eecs-difference
Damn CS's
Slow down Cowboy (Score:2)
VHDL tends to the standard (Score:3, Insightful)
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.
Celoxica DK1 (Score:1, Interesting)
The real difference... (Score:1)
BugBear
Toto - This doesn't loook like C (part deux) (Score:3, Insightful)
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? (Score:4, Informative)
They seem to have gotten some fairly decent speed/area results.
ya i remember... (Score:1)
JHDL is supposedly good, but lacks in synth dept. (Score:2, Informative)
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 (Score:3, Informative)
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...
compiler pile-up (Score:1)
JHDL (Score:2, Insightful)
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 (Score:1, Funny)
Embedded Developer (Score:1)
"I'm an embedded developer."
As a Comp Sci Student. (Score:2, Insightful)
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! (Score:4, Informative)
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!
Parallelism and J[ava]HDL (Score:3)
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.
We must obey the synthesizers (Score:3, Informative)
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?
Learn VHDL (Score:2, Insightful)
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 (Score:5, Interesting)
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.
my experiences with VHDL (Score:2, Informative)
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.
VHDL is good (Score:3, Insightful)
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... (Score:2, Insightful)
...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.
No support (Score:2, Informative)
HDLs have their place (Score:2, Informative)
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 (Score:3, Interesting)
A tutorial on Verilog [cmu.edu] 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.
Sad... (Score:1)
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
SystemC/JHDL vs. VHDL/Verilog (Score:1)
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.
Chip design != Programming (Score:5, Informative)
Think about your resume too... (Score:1)
Extremely Interesting Solution-Star Bridge Systems (Score:2)
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 (Score:2, Interesting)
See:
http://www.easystreet.com/~mbutts/xr16vx_jhdl.h
http://www.fpgacpu.org/log/jul01.html#010731
http://groups.yahoo.com/group/fpga-cpu/message/
Language Choice depends on the Designer (Score:1)
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 (Score:1)
VHDL is obstuse looking cause its ADA.... (Score:1)
[Tangent] FPGA/PLD/etc starter kits? (Score:2)
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
Thoughts From A Professional FPGA Developer (Score:2, Interesting)
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.
JHDL + clock gating = quick, large, low power (Score:1)
Conservatism is good for you (Score:1)
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 [deepchip.com] 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!
Using C++ to Simulate Designs (Score:1)
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.
View from an FPGA application engineer at Xilinx (Score:1)
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.
JHDL (Score:1)
Re:stick with Verilog and VHDL (Score:1)
Regarding the Verilog versus VHDL war - I work in Silicon Valley and we tend to be very biased towards Verilog out here.