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