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?
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.
... Verilog is easier to write, but VHDL is (seems) more typesafe and is easier to debug.
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
The heat from below can burn your eyes out
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.
Some men spend their entire lives trying to kill themselves for having been born. --Ross MacDonald
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
Have you compiled your kernel today??
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.
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.
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).
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.
...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.
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.