As we've already seen in part 1 and part 2 of this mini-series, programming languages like C and C++ are very different in nature to hardware description languages (HDLs) like Verilog and VHDL. In this column we're going to explore these differences in a little more detail.
Now, before we plunge headfirst into the fray with gusto and abandon, let's first set the scene by noting that -- if we wished -- on the software side of things we could simply create a single, honking big program. By this I mean a single file containing line after line of code that may include loops and IF-THEN-ELSE type statements, but that doesn’t make any use of procedure or function calls.
A honking big program (left) and a honking big circuit (right).
Similarly, on the hardware side of the fence, we could use our HDL to describe a single, honking big circuit/design. In reality, of course, we tend not to do this sort of thing on either side of the fence, because it makes life difficult in so many ways.
Taking a walk on the software side
Just one more point before we start, which is that we are going to keep things as simple as possible. On this basis, we will consider only a single-threaded program running on a single processor core -- we are not going to worry about multi-core systems, threaded applications, operating systems time-sharing multiple programs, or any other weird and wonderful scenarios.
The term "subroutine" is used to refer to a small portion of code that performs a specific task and that is relatively independent of the main body of code. The main routine (program) calls the subroutine as and when it is required. These days, the term "subroutine" is now predominantly associated with assembly languages and languages like BASIC. In the case of languages like C and C++, it is more common to use the terms "procedure" and "function" (we don’t need to worry about the differences between these constructs here). Older programmers often think "subroutine" but say "procedure" and "function," while younger programmers typically view the world only in terms of procedures and functions. Having said this... these days, for a number of folks, even the terms "procedure" and "function" are going by the wayside, being replaced by "object," but we digress...
Consider a program that makes use of four procedures that we will call "pA," "pB," "pC," and "pD." A very simplistic way of viewing things (ignoring loops and suchlike) is that the "arrow of time" -- by which I mean the order of program execution -- points from top to bottom as illustrated below:
A software program in C/C++ boasting four procedures.
Once again, we're keeping things simple here. In reality, the main program may call procedures and functions multiple times from different parts of the program, passing in different values each time. Also, procedures and functions can call other procedures and functions (sometimes they even call themselves recursively), but we really don’t want to get sidetracked by any of these scenarios, because we have other fish to fry...
jandecaluwe 2/18/2013 3:57:05 AM User Rank Blogger
Re: What we need is a library of short examples.
@Jezmo "Jan, If you are going to tell people to use software design ideas in the realm of FPGA design at least explain to them the problems of converting untimed c/c++ constructs rather than just waving your arms about saying its all good"
Yes, let's change subjects quickly.
Please do listen carefully now.
I am an RTL guy. I think it's going to be the lingua franca of digital design in the coming decade. RTL gives me exactly the control I need over area, timing and power that I need for the designs I do for my customers.
My ambitions are modest. All I want is better RTL. RTL is not living up to its potential now. I want to save it from "experts" like you with their irrational response whenever someone mentions the word "software" or a simple concept like "variable".
So if you want a real design challenge, revisit my Thinking Software article. I can't really explain it much better than that. Here we have a well-known design problem, which is simple and small from all angles: a few lines of RTL, clear code that directly expresses an algorithm, and just 14 Altera LUTs and 9 FFs for the 8-bit version.
It's a great solution - yet no "conventional wisdom" expert like you would ever come up with it because you think variables are harmful, or optional, or a solution in search of a problem, or whatever else I have heard.
Try to do better. Post your reasoning and your code.
Let's stop the cheap talk and the half-baked philosophy - it's time for action.
Jan,
If you are going to tell people to use software design ideas in the realm of FPGA design at least explain to them the problems of converting untimed c/c++ constructs rather than just waving your arms about saying its all good
jandecaluwe 2/17/2013 12:34:13 PM User Rank Blogger
Re: What we need is a library of short examples.
@Jezmo "The problem with telling to people to treat HDL design as if its simply a variant of software design is you end up with designs which look like they have been written by software people, and then they have to be rewritten so that they work."
If you are still talking about my MyHDL example here, be careful with whom you are targetting. Look at the MyHDL code. It is almost identical to @hamster's original VHDL code. (That was also the intention, get it?)
(Except that I used some sophistication to generate the "Hello World" pattern. But this is just embedded scripting to set up the lookup table outside the actual hardware description.)
You don't want to accuse a hardware buddy of yours to think like a software engineer, do you?
jandecaluwe 2/17/2013 12:19:31 PM User Rank Blogger
Re: What we need is a library of short examples.
@Jezmo "Anyway I managed to fix the code produced by the method that jan champions, and it now runs at 300% of the original speed using 50 % of the logic, so ner ner ner ner :p~~~~~~~~~~"
What is this again? What do you think you are "fixing"?
The goal of this quick modeling experiment was simply to have something equivalent to @hamster's original VHDL code in MyHDL, to demonstrate what is possible. The goals was not timing or area optimization.
As I said clearly in the notes, I didn't even simulate it and so there may (will) be functional bugs. So if you want to do something meaningful, simulate it first and check if it does the same as @hamster's code. If not, I will fix it.
Then check whether there is a significant synthesis difference between the two. I don't expect that, but I may be wrong and then we can look into it.
The problem with telling to people to treat HDL design as if its simply a variant of software design is you end up with designs which look like they have been written by software people, and then they have to be rewritten so that they work
Anyway I managed to fix the code produced by the method that jan champions, and it now runs at 300% of the original speed using 50 % of the logic, so ner ner ner ner :p~~~~~~~~~~
Jan,
There is a problem with using signed or unsigned types at interfaces if you want to use something like viewlogic which will only let you use std_logic at the top level.
But that's another battle I've got to fight at work
It another reason I don't like schematic entry tools for FPGA design
jandecaluwe 8/16/2012 12:33:08 PM User Rank Blogger
Re: What we need is a library of short examples.
> I've switched it to IEEE.NUMERIC_STD. Don't know if I did it the right way by using lots of conversion functions, but it implements.
I feel guilty of causing all these conversion functions :-)
No, the trick to avoid conversion functions in VHDL is to go all the way and use the "right" types for signals/variables to start with. E.g. there is no problem with using signed/unsigned at interfaces.
> Cut and paste the lines into a text editor, and replace all the 0s with spaces. The mystery will be solved.... :-)
I had figured the message out, just didn't understand the logic behind the case choices. Now I understand that is how the message if positioned vertically.
I had some fun doing this in MyHDL, and you can find the draft version here:
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.