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.
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!
>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.
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