I have many years of experience with hardware design, software design & implementation etc (i.e. I'm comfortable with C++, soldering or anything in between)
I'm using FPGA"s more and more.
So far, I've used schematic capture exclusively. I use Altera's Megawizard, so I know someone wrote some parameterizable VHDL behind this, but I still think in hardware terms.
I never learned VHDL, and wonder if it's worth it.
My take has been that I am designing hardware - configuring the LE's and interconnects and not writing algorithms. This seems to me to be mind-set that best fits what I'm doing.
I notice that a lot of people here refer to "code" - suggesting they have an algorithmic mind-set
What am I missing ? What would be some examples of something better done in VHDL ? Are there examples of stuff that cannot be done in schematic ?
Well, when doing VHDL, you'd better be thinking hardware as well. VHDL is a language to describe the hardware you want built.
When you code in VHDL, you don't think "algorithm", you think register, combinatorial logic and you describe that in VHDL.
Note the exception about that is when you code testbench and "code generation". The first is just a behovioral description of the test environment and stimulus and don't need to be synthetizable. The latter is when you write "generic" VHDL code that needs to adapt somewhat to static option at synthesis time (not unlike the C preprocessor).
The main advantage I see about HDL over schematic capture would be : - Vendor independent : I don't think the schematics are interoperable but I may be mistaken - Text edition : To write the vhdl, you can do it every where where you have a text editor, no need to have the vendor tools - Genericity : When you have a complex block that needs different fine tuning for different application, you can use parameters to change details.
I too used schematic entry exclusively until the company ran into a larger project, and we got sent off on VHDL course. Now it's exclusively VHDL, not because there's any functional difference in my mind, but because I'm lazy. True, I too refer to the file as 'code', but it's only 'code' or 'behavioural description' until it's been through the synthesis tool, just as 'schematic' is only a 'drawing of funny looking boxes' until the synthesis tool breaks it down. Algorithmic mindset, no. For me that somehow implies sequential execution, and hardware isn't. I'm a C programmer too, and I tried reading VHDL from a sequential-execution mindset. It didn't work.
As an example (because I've done this both in schematic and VHDL), consider a shift/count register typically used for a reciprocal frequency counter. In schematic I constructed a symbol with a FF that would either count or shift, and made a schematic with 28 of those symbols. Draw wires, think it over, did I do it right, okay. If I want to expand the register, I need to draw more. When writing VHDL my mindset is still "I need a register, when not gated open it should be a shift register, when gated open it should be a synchronous counter. It should be clocked from refclock."
if rising_edge(refclk) then if (gate='1') then fcount
As many writers have commented you need to know hardware before you code VHDL -- as certain syntax & grammar of VHDL will infer logic ... Your extensive background in gate-level design will serve you well in VHDL.
Everything that you do in schematics you can do in VHDL i.e. as complete set of instantiated components wired as you want. But that is a terrible waste. Where you really win is something like a state machine where you can describe fairly complex behaviour in a relatively small number of lines. I have designed state machines up to 32 thousand states. Yes I did say 32 thousand and that took me about 2 weeks to enter and debug - mostly typing. Try doing that in schematic and not making a mistake or even fixing mistakes.
There are lots of other examples where description is quicker and more reliable than schematic. You are also not ruled from using schematics to view the design, or even to do critical bits in schematic, or even doing vhdl netlist form. If you are comfortable with C++ then you will find a lot similarities in VHDL. VHDL can be written as very abstract code or very simple staying with a small number of constructs like if/elsif, case etc. Personally I prefer the simple approach to VHDL but each to their own as the saying goes.
John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board.
Schematic entry has always been a transitional addition to Programmable Logic tools, representing a merging of the old and the new. Comparing Schematic entry to VHDL is like comparing Hotmetal, Frontpage or some other WYSIWYG website design utility to HTML/XML etc. It is a tool, enjoy.
If you are considering learning VHDL (or Verilog), my advice is a resounding YES; Do it, learn it.
FPGA's will soon exceed present physical production limitations and we will have budget giga, tera and even peta gate FPGAs. VHDL makes designing complex and/or large hardware very easy compared to schematic entry; however visual descriptions are always easier on the eye.
Now the contentions stuff:
IMHO, IMHO, IMHO: (flame on!)
It is all code. VHDL and Verilog are Hardware Description Languages. Various 3rd Generation Languages (3GLs) like Pascal, C, Basic etc are Functional description languages. ALL LANGUAGES are behavioral in concept; they are supposed to define and/or describe a "system's" behavior.
In development circles the words "code" and "coding" are abbreviations borrowed from the words "encode" and "encoding". They describe the process (coding) and results (code) of translating a behavioral design from the mental landscape into a textual format; At these levels "it is all code".
Now let us be really outspoken:
Synthesis is not Compilation, although compilation is a form of synthesis. When comparing the two, people generally consider the outputs: compilation results in further code, now translated into binary form. However, compilation is more like synthesis than translation.
Does not the binary result of synthesis define how an FPGA/CPLD/PLD should react to stimuli. Doesn't a compiled program do the same for a microprocessor? GIGO, Input, Process, Output. Who cares!! The argument is a philosophical one and thus one of opinion anyway.
Here is a passing thought: If ADA never existed, what format would VHDL have. VHDL's designers WERE influenced. If C never existed, what form would Verilog or SystemC have. Their designers are influenced. If chicken never existed, what would everything else taste like!?!
Nme. God Bless.
P.S.
IMHO: We will always have Schematic entry, humans like pictures, CAD, CAM, UML, SSADM, websites; we love diagrams and images, easier to digest.
Hi Gary, Quartus II 4.1 and newer versions have a graphical tool called the RTL viewer. This tool will be great for you if you want to see how the VHDL/Verilog/Schematic you write translates into logic. Our customers and our own developers and support folks use it extensively to debug their circuits if they run into a problem, or to understand how logic gets implemented. There is also a state machine viewer built into the RTL viewer which will show you the bubble diagram for your state machines written in HDL.
The RTL viewer can be used to see the output after the synthesis step is complete, but prior to Technology mapping into LUT's. There is another tool called the Technology Map viewer which shows you the result after Technology Mapping. Both Tools are available under the Tools menu and you can bring them up after compiling your design. As you are already using Quartus they are already on your desktop and one button click away.
Quartus has been available on Linux for the past two years. Red Hat Version 7.3, 8.0 and Red Hat Enterprise 3.0 are supported with Quartus II
5.0. We will be dropping 7.3 in the next release. These have been tested with both Opteron and Xeon CPU's. Based on comments from some of the power Linux users they have had it working on other Linux distributions. This product will require the purchase of a Linux subscription. You will need to contact your distributor or the Altera Telsesales group depending on your location. Check
I also like schematics for "random" logic, such as a bus controller/decoder.
But, there's some stuff that is just so much more concise in VHDL. One example is a Gray-binary or binary-Gray code converter. In schematic, it is a string of FFs and XORs. In VHDL, it is a parameterizable one-line statement, with the parameter being the # of bits. (I may be exaggerating the concise-ness just a little, but both of these functions were completely coded in 4-6 lines.) These were 48-bit converters for time codes.
I also did an experiment just to stretch my VHDL writing skills and coded up a do-nothing box that (pseudo)randomly changed bits in a 10 x 10 array, and simultaneously refreshed a 10 x 10 grid of LEDs, like a raster scan. Each of those bits was a VHDL function, and each raster line looped through 10 bits, then the line looped through 10 iterations. I compared (mentally) what this would look like in the most concise hierarchical schematic, and the superiority of the HDL was pretty convincing.
You wrote: "But, there's some stuff that is just so much more concise in VHDL. One example is a Gray-binary or binary-Gray code converter. In schematic, it is a string of FFs and XORs. In VHDL, it is a parameterizable one-line statement, with the parameter being the # of bits."
This is correct, but: I have seen people converting a binary counter output to Gray code, believing that this would allow glitchless decoding. Of course it does not: The delay differences on the binary side go straight through to the Gray side. If you are a Schemtosaurus, you easily see a solution: Re-synchronize the Gray output. And if you are clever, you drive the conversion not from the binary counter's Q outputs but from its D inputs. That keeps the two counters in step. I doubt that you would get this "picosecond" insight from VHDL code. Peter Alfke
I have never used a HDL, but I have an opinion anyway, this is usenet.
I have a hardware and firmware (C and asm) background and recently picked up an existing schematic based fpga design for modification. My first fpga.
What I miss most is the ability to compare the file I am looking at to last weeks version, or the version that Joe modified. I have not found a way to do that with schematics. I have gotten very used to this for firmware.
If there are any software types looking for a project, I would pay for a tool to do this.
1) Print out the two schematics onto the thinnest (lightest) paper you can.
2) Place one page on top of the other, and align carefully.
3) Hold up to the light.
4) You owe me $0.02
I like it! It's simple and elegant. You can also try the screen-based version of this method. Bring up the two schematics in two windows or buffers. View both at the same zoom level and position on your screen. Then quickly switch back and forth between the two views and look for something "flashing". I do this to compare graphics and sometimes text files as well.
You should change your software programming style to using flowcharts for inputs instead. That way you can always have a graphical representation of your processes which are self-documenting. Plus, if you can get that method to catch on wil more developers, the client base for graphical revision control will increase and the dream of comparing schematic versions easily might be realized.
If you prefer programming with text, look at Verilog (c-like in syntax to some degree) or VHDL (more complete in its rigorous approach).
A tool is only as capable as the person using it. For the same "function", some can easily create schematics as fast as anyone can code in HDL, if that schematic person knows what they are doing. The key is symbol libraries, and better yet, tested libraries (thank you Philip ;-)...which allows hierarchical, basically, drag and drop, schematics. This can be done with datapaths, as well as state machines, functions etc. It's as good (or as poor) as you want it to be, depending on how much work you put into your libraries.
Of course, it takes time to build up a good library, but not *that* much time, and the time it saves in the long run can be huge. People seem to like to draw gates...why I don't know. My schematics are like block diagrams, and alleviate the "need" that people have to turn HDL code into block diagrams to understand what it does.
I won't contend that if starting from scratch, HDLs will typically have an edge on time to completion, and the tools today are far better than a decade ago, but that does not diminish my point. IF someone had come out with a library that was publicly available, schematics would have been quite a bit more popular.
This capability (having a large library of pre-built schematic modules) was a huge advantage I had for many years being an independant contractor. I was able to do designs that met performance goals of speed and resource utilization, as well as do them very quickly and cost effectively. But, basically, schematics for FPGAs, at least Xilinx FPGAs, are dead today, IMO.
But, without schematics, I could not have done the designs I did in the earlier Xilinx series parts (2k, 3k & 4k), as the synthesis tools were rather poor back then, and required far more work to get the results to come close to the speeds (and densities) achievable with schematics. Using an HDL simply as a netlister is not a very good use of the tool IMO...but now, that is the only way to get every Hz out, is to instantiate what you need to using HDL. Sigh.
There is not a thing wrong with schematics compared to HDLs, and schematics even have many advantages, but today, they just aren't popular. HDLs are. It has not a wit to do with schematics lack of ease or capabilities.
I agree with that. BTW: Altera / Quartus has still a very good schematic editor. The only problem (surprise): It is not vendor-independend. If you have a large schematic design, it would be a huge effort to transfer this to e.g. Xilinx.
Many people explained correctly that you have to think "hardware" when you are writing VHDL. Therefore I think, graphic design is even a "higher level language" then VHDL because the schematics are better human readable in many cases. For e.g. state-machines and simulation, things are different, of course.
So a mix of VHDL and schematic design (top-level: schematic, with sub-modules that may also be in VHDL) would be perfect. Is there any good tool out there that can convert such a graphic/VHDL-mixture into a vendor-independent VHDL-design?
Well, kind of...ViewDraw is capable of doing exactly that, but it is currently not supported by Xilinx. You simply set the schematic symbol to point to, well, pretty much any HDL, even Abel. Not sure how this flow works with the new tools though...file formats have changed since I've done this.
On the issue of vendor independance, my libraries ARE vendor independant. Only the lowest level elements are vendor depeandant. Of course, some elements aren't available in some technologies...so no matter what, you are still vendor dependant in most designs. But, I've also never ever ever in the many dozens of dozens of designs I've done had to convert from one FPGA vendor to another. I have converted say, a 4k design to a Spartan (big deal, their the same ;-), or 2k to 3k...
There have been many tools in the past. I would guess that 5-10 years ago, quite a few true schematic programs allowed this. I used one of them for a number of years. It would output VHDL code and also xnf files, so that I would simulate in Modelsim and then incorporate the various bits and pieces during ngdbuild. Another kind of tool was the HDL graphic tools, which were good for the block diagrams you talk about, along with generally providing graphical state diagram creation. I also used one of these in the past.
I prefer the schematic/graphic input tools. I generally find that they are easier to look back at and figure out what is going on. They are generally quick and easy to use, especially as mentioned once a library has been developed.
But I have completely abandoned all the graphical tools for the tedious process of coding in VHDL directly. In general, industry expects HDLs. I had a reviewer for a customer complement a design, and then make an offhand comment about it being done schematically, in a tone that conveyed his surprise at that.
But really the main reason was that I have seen far too many schematic/graphical tools come and go. In a previous employment incarnation, we had to keep around an old Windows 3.1 machine gathering dust in a corner, just to support the schematics from an old but still active project. And the schematic package mentioned above that I used for mixed schematic VHDL designs is now also obsolete, and I am once again keeping an old schematic program around to support old designs.
Well no more! ;) That is a problem that is far less likely to happen with HDLs. And while I still consider VHDL tedious, I have come to appreciate the strengths of doing designs this way. Not least of which are the many very simple methods available for doing source control.
Well yes and no. Schematic design and data entry pre-date HDLs. The place and purpose of schematics is well known. They will always exist.
I do however believe you are flawed in thinking that the time taken to type multi-layer package/module replications is longer compared with cut/load/insert and paste, then linking the wires manually. But hey, I use the Altera MAX/Quartus schematic entry tools; there are better tools available.
Again, I think you are comparing HDL starting from scratch with schematic libraries. You can also have VHDL libraries.
This is the key area were schematic entry beats HDL entry hands down, schematic entry is automatically self documenting. However, there are tools to do this.
Developers I have met can visualise the schematic just from reading the HDL.
k....
today, IMO.
You prefered schematics, others have HDLs. Like I said to Gary who started the thread: Diagramatic description, design and management will always have a place with humanity, we prefer pictures. New methods and new tools have their place, but they don't always make old methods and old tools redundant.
I am reminded of a comedian who told a story of a visit to the Opticians. After putting on his new varifocals he found it very difficult press lift buttons, walk off/on street edges, judge the distance from cars etc. Eventually he got to a phone booth and called his wife at home. He describing the disturbing events, his fear and desperation and begged her to pick him up. Down the phone she snapped: "Stupid! Take off your new glasses and come home!"
FPGA/CPLD/PLDs will always implement binary constructions to provide the desired application function(s).
IMHO: HDLs will become hidden within purely diagramatic design tools, much the same way software development is about module reuse and UML/SSADM diagramatic tools now. Not the case back when I started.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.