As you may recall, I started blogging about my journey into the chaos that is the world of FPGAs back in May of 2012. My original intention had been to learn about, and blog about, both Verilog and VHDL. As things turned out, however, that was a little more of a task than I was up to at the time, so I ended up settling on Verilog.
Now, working with Verilog has certainly been both instructive and fun. On the other hand, since the hardware design language (HDL) world is largely split between Verilog and VHDL, I’ve effectively eliminated half of my potential sources of help. Not knowing VHDL makes it much more difficult to translate help given by non-Verilog users, so I've decided it’s time to go back in time and see what I can do with VHDL.
There are a lot of divided technology camps in the world: Mac vs. PC, Canon vs. Nikon, AMD vs. Intel, Coke vs. Pepsi, etc. People defending a position in one or the other of those sets tend to get very emotional about their point of view. To be honest, I was expecting something similar in the case of Verilog vs. VHDL, but I'm happy to report that I really haven’t seen much evidence of this here on All Programmable Planet. There are some stated pro/cons, but the arguments tend to be more matter-of-fact than emotional. That’s refreshing; however, it doesn’t really make the choice any easier.
Regardless, I’m going back to my Blinky LED in VHDL and -- hopefully -- now that I have a better idea what I'm doing, I’ll be able to progress faster than I did in Verilog. Certainly, I am much less likely to get sucked down the black hole of comparisons with software, as I did with my Verilog work. In the FPGA world, a software mindset is about as effective as stumbling unarmed into Shelob’s lair.
I created a 4-bit counter for my August 6, 2012 blog: Driving a 7-Segment Display. Rather than going completely back to zero, my first VHDL “blinky” will be a version of the four-bit counter I used to drive the 7-segment display. Fortunately, the UCF is the same between VHDL and Verilog, so there’s one less thing I have to re-invent.
Step one is to open the ISE and create a new project: from the ISE file menu, select the very first choice “New Project...” Give your project the name “VHDLcounter” in the “Create New Project” dialog and click “Next.” The “Project Settings” dialog should be set as in the image below. The key is to set your “Preferred Language” to VHDL (click here to see a larger, more detailed version of this image):
Once that’s done, you’ll need to create your VHDL source file, which you do by means of the “Project -> New Source” menu (or just click the "New Source" icon). Select “VHDL Module” from the “Select Source Type” dialog and name it “VHDLcounter.” Following this, you will define the I/O as shown in the image below (click here to see a larger, more detailed version of this image):
Finally, you need to create a “New Source” again, but this time, choose “Implementation Constraints File” and name it “VHDLcounter.” This creates a blank UCF (user constraints file), into which you need to add the following contents (click here to see a larger, more detailed version of this image):
Once you have performed these steps, you will have your UCF and an empty VHDL framework. The Xilinx ISE generated the framework, as you can see in the image below (click here to see a larger, more detailed version of this image):
For comparison, here’s the same framework generated by the ISE in Verilog:
Now, there are a number of new features in the VHDL representation that don’t seem to have a Verilog equivalent. For example, “Library IEEE;” and “use IEEE.STD_LOGIC_1164.ALL;”. So, we use libraries in VHDL. My brain says “libraries = software," but... don’t... go... there (see also the recent VHDL Libraries column that was written by my co-blogger Adam Taylor).
According to the book I have in hand at the moment, Design Recipes for FPGAs by Peter Wilson, VHDL, without library extensions, is quite limited in terms of data types and models; hence, libraries. What we see in lines 20 and 21 of the VHDL code is the name of the library “IEEE” and the element package within that library (“IEEE.STD_LOGIC_1164.ALL”) that we will be loading in this VHDL configuration. The book also notes that the library isn’t specific to VHDL, but is for HDL languages in general. I don’t yet understand the implications of this fact, but I’ll take it without question for the moment.
In my next column, after a bunch more reading, I’ll start putting code into the framework. As best as I can, I’ll compare what I do in VHDL to what I did in Verilog. In the meantime, do any of you seasoned VHDL folks have any advice for a Verilog rookie who is poised to dive headfirst into VHDL?
But seriously, there are a number of things I dislike about VHDL, but I've had real problems accomplishing certain things in Verilog (though I didn't try in VHDL). Guess I should!
QSYS might be OK for real quick prototyping, but it definitely promotes vendor lock in, which in the long run, is never a good thing.
the interfaces is also far from intuititve. it also requires a separate generate step in the design flow if changes are made (if I remember correctly).
most things done in qsys can be done directly in HDL I believe.
josyb: Once you have all the building blocks in place you can go real quick tying it all together in a graphical manner.
And this is somehow better than instantiating entities in VHDL in the usual way?
How does this graphical part get put into the source-code respository? Can it be diffed?
With any reasonable editor (emacs, of course, and Sigasi), instantiating entities is easy and immediate. Emacs: put cursor in the entity's port list. From the menu, choose VHDL->Port->Copy. Switch to buffer containing source in which to instantiate entity. Put cursor somewhere useful. From the menu choose VHDL->Port->Paste As Instance. Congratuatlons, entity now instantiated. Oh, yeah, the signals: VHDL->Port->Paste As Signals. Now all signals used in that entity instantiation have declarations. Edit as necessary.
I know that it takes me less time to instantiate an entity in code using emacs than it does to add an entity to a module done in Actel's SmartDesign. Add entity, add bus interface, instantiate, wire it up by clicking and mousing two or three dozen times, regenerate, etc etc.
And while I'm sure that a lot of people say, "Well, the graphical interface gives me a schematic, and it's easier to understand a schematic," every such interface makes a mess of the schematics so there's no benefit.
devel: Xilinx was founded the year I started college. I didn't know about programmable logic until my first job after graduation. And that was with 22V10s and later Altera CPLDs.
I started off with MMI's PALs and remember the first LCA presentation by Xilinx, around 1984 or so The manual Routing tool was US$ 10,000,-! You understand that a small firm just couldn't afford that.
So, I don't get it ... what advantage does a proprietary scheme for packaging and interconnecting in-house logic have over just putting the code into a source-code repository, external-ing (in the svn parlance) it into a design and wiring it all up in the usual way?
Once you have all the building blocks in place you can go real quick tying it all together in a graphical manner. When you press generate the tool adds the necesarry interconnect fabric. You should read a bit about Qsys to understand this better. Qsys comes with Quartus, unlike Xilinx' EDK. You still need to buy a NIOS II license, but I don't use NIOS II (yet, probably will look for another smaller softcore processor when that need arises)
I was talking with one of the guys here earlier today about Xilinx' scheme for doing that. And again, it came up: why package your code using a vendor-proprietary scheme that is likely to change with every revision of the tools?
Altera have a reasonably good track record of not breaking things (that often). And as I said before my interconnect scheme works well with Qsys. (it would also work well with the EDK scheme). And I don't have plans to switch vendors - but never say never.
josyb: You see, I never went to university and got spared from Xilinx and other academic stuff :)
Xilinx was founded the year I started college. I didn't know about programmable logic until my first job after graduation. And that was with 22V10s and later Altera CPLDs.
But use Qsys to interconnect in-house generated IP, connecting e.g. image sensors to camera link outputs.
So, I don't get it ... what advantage does a proprietary scheme for packaging and interconnecting in-house logic have over just putting the code into a source-code repository, external-ing (in the svn parlance) it into a design and wiring it all up in the usual way?
I was talking with one of the guys here earlier today about Xilinx' scheme for doing that. And again, it came up: why package your code using a vendor-proprietary scheme that is likely to change with every revision of the tools?
@devel: "I'd rather not wait. Not if something has to get out the door."
Like I said I rarely simulate a top level system, maybe twice a year. And I have told my colleagues before: faster tools only lead to faster errors.
That's all in the Altera world; I live in Xilinx and Actel. And honestly, we don't do designs that would benefit from Qsys, such as using canned IP and a system integration tool.
And yes, we've done the Xilinx EDK thing and found it to be a disaster."
You see, I never went to university and got spared from Xilinx and other academic stuff :)
Actually we use very little of Altera's 'canned IP'. But use Qsys to interconnect in-house generated IP, connecting e.g. image sensors to camera link outputs. It may look that Qsys is also centered around Altera's soft-core NIOS II CPU, but you can perfectly build systems without that NIOS II. I had devised my own 'module connection fabric' and connected those blocks within a top-file, lot's of typing and now and then a wrong connection ... Turned out that the Avalon ST-fabric is a superset of what I had, so I had an easy transition. Again I won't go back ...
josyb: But I rarely simulate full FPGA designs, and if I have to I just wait ...
I'd rather not wait. Not if something has to get out the door.
Nowadays we build systems with Qsys. Once the sub-modules have been thoroughly tested you connect them up in Qsys and things tend to run fine. I built a few 'peeking' modules for in-system-debugging and statistics and that usually show where something goes wrong. If that doesn't help enough we dig out the Signaltap ... as you mentioned, the external hardware sometimes behaves differently than expected / simulated
That's all in the Altera world; I live in Xilinx and Actel. And honestly, we don't do designs that would benefit from Qsys, such as using canned IP and a system integration tool.
And yes, we've done the Xilinx EDK thing and found it to be a disaster.
@devel: "Sigasi do a comparison to Emacs-VHDL mode.
I've seen that, but it's not clear whether everything in that list applies to the paid-for or the free version."
The list applies for the paid-for (of course) and for the starter version too, until you hit the 200 statements limit, and even then it will be at least as good (Jan's claim).
But don't hold back, ask them for an evaluation license, they are happy to give one :)
@devel: "I presume the starter that comes with the Altera tools is similarly crippled."
Yes, it is. But I rarely simulate full FPGA designs, and if I have to I just wait ... Nowadays we build systems with Qsys. Once the sub-modules have been thoroughly tested you connect them up in Qsys and things tend to run fine. I built a few 'peeking' modules for in-system-debugging and statistics and that usually show where something goes wrong. If that doesn't help enough we dig out the Signaltap ... as you mentioned, the external hardware sometimes behaves differently than expected / simulated
You can also use Sigasi in 'single file' mode. But than you can not use all features, such as a project wide search or rename refactoring. The 'workspace' is the mechanism to manage this project information.
Duane Benson has his SPI interface working. At some point, he'll want to rewrite the Verilog code, but first he wants to get the I2C interface up and running.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
