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...
@Max: Now that is what I like, explaining it the way that an old timer can understand.
Have I got this right "The designer of the TTL circuit boards was in fact the top level HDL block you show?".
I must admit it was mind blowing to see the schematic layout when i synthesized my first switches and leds VHDL, it really rammed home the fact that these chips are blocks of logic waiting to be connected. I think what you have just proved to me is that the logic of the FPGA lends itself to parallel manipulation of multiple bits of data on the same clock cycle.
I think like a lot of beginners coming from the 8 bit micro world will, like me, have difficulty in knowing whats best done by a micro or an FPGA. This will be the real test and some possible cause of lost hair.
I presently have an 8 bit micro project, for a cooks kitchen timer with OLED display and rotary switch input, on the go. So I was thinking that this would be a good thing to try and convert to an all FPGA design?
Jacek Hanke 8/10/2012 7:19:13 AM User Rank Blogger
Re: Do you still see a need for standalone MCUs?
I agree with Paul, cause in the end the choice is always yours. In some projects standalone MCU seems to be fifth wheel, but still in many, many, many projects standalone MCU rulez :)
Paul Clarke 8/10/2012 3:17:41 AM User Rank Blogger
Re: Do you still see a need for standalone MCUs?
There is a very hard and defiant YES from me on that one.
I work in a world with no FPGAs and only small MCUs. I use 8bit and 16bit MCU or PICs in all our products. They are very low cost, very low power and do everything we need them to do. They are also very small, one is in a 6 pin package.
The point is that we need both MCUs and FPGAs as they have very different skill sets. My industry is about controls but is still very slow in MCU terms so our chips running on 500kHz clock are more than fast enough, in fact I still have delay loops in the code.
You have seen my posts on the PicoBlaze, its not just about putting a MCU in a FPGA it's about why and when to use them. The lines are getting harder to see with MCUs having CPLD hardware on them and FPGAs with hard MCUs in them. However as the saying goes "The Choice Is Yours!".
Do you still see a need for standalone MCUs? (Yes, with all of their boring little, sequential op codes :-) Especially given that FPGAs now have integrated soft/hard cores... Just curious.
Immediate thoughts on standalone MCU advantages that come to mind are reuse, cost and power consumption. Any others?
Their is another big difference that I can't quite nail down....
For me the big difference is that there is no thread of execution, Jumps do not exist, loops do not exists, only parallel conditional evaluation of expressions and atomic assigment of all variables at once.
This is very hard to explain to software guys, But here is an analogy that works.
The hardware you design with VHDL is like a spreadsheet, with each row being you state at a given clock cycle, each formulas are ONLY able to reference constants and cells in the row immediately prior, and the formula for each cell MUST BE exactly the same for all cells in a column.
Each Input variable is also a column, and as it is an input you can put values in it as you go. So if you wanted to average a list of numbers you will need to list the numbers all in column 'A'.
When put in that context, ask a software guy how to calculate the average they will come to a result surprisingly close to the HDL solution of the same problem:
* column A contains the data set, changing over time
* column b <= previous value for column b + previous value in column a
* column c <= previous value for column c + 1;
* column d <= previous value for column b / previous value for column c, and is the running average delayed by one cycle.
You then have the issue of what to do with the discontinuties on the top row. You can then introduce the concept of a reset signal...
* column A contains the data set, changing over time
* column b is the reset signal (0 or 1)
* column c <= IF(previous column b = 0, 0, previous value for column c + prevoius value in column a)
* column d <= IF(previous columm b = 0, 0, previous value for column d + 1)
* column e <= if(previous column d > 0, previous value for column c / previous value for column d, 0)
Once this is done the "#REF" errors that happen when you copy your formulas to row 1 disapper when reset is asserted.
If anybody was going to start with a HDL this would most probably be the most useful excersise to try, then do exacty the same in HDL...
This should solve all the misconceptions between software and hardware programming. Looking back at myself, I thought all programming languages work similarly (newbie thinking) and that I could write something similar in another programming language. How wrong I was. I kinda feel a bit guilty for writing a software-like IP module for a well known FPGA company (shouldn't expose too much details :))
The appellation "primary colors" refers to a small collection of colors that can be combined to form a range of additional colors, but which "small collection of colors" should we use as our primaries?
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
