Slashdot Mirror
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?
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.
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.
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....
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...
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!
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?
Mod me down and I will become more powerful than you can possibly imagine!
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.
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!)
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.
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).
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
>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."
The living have better things to do than to continue hating the dead.
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.
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...
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