Let's clarify this whole fpga / vhdl / and all that

[A-sic Enginerd]

So Dave made a comment in his HW vs. SW blog that got me thinking. (Don't worry Dave, this isn't a 'let's bag on Dave session', you just got me thinking was all).
I'm tossing this out there to maybe clear some of the mud for the newbies that are asking questions about what's what and how to get started, etc. I'd like to de-mystify at least this small corner of the world.

I've seen and heard multiple references from some of the EE's present here, that their view of what FPGA design is all about, what is it to write VHDL, and what not.

In one aspect, there's the need to understand the electrical interface to an FPGA so one can design a proper circuit around it, do a proper PCB, etc. However, the inner workings of the FPGA itself is a different realm. It's actually not VHDL design or even Verilog design, it's digital design. Now before anyone starts bagging on us poor digital pukes, let me mention for the newbies there's actually a whole lot more to digital design than just tossing down a few AND and OR gates with some flops in between. Is it any easier or harder than what an analog EE deals with? Neither. It's just different. Depends on the complexity of the problem at hand. Don't believe me it can get ugly? Pick up a book on DSP (digital signal processing) and prepare to dust off every math book you can lay your hands on. And yes there's a whole range in between.

So where does this VHDL or Verilog fit in? It's just a tool. This is where much of the confusion lies. Writing VHDL (shudder) or Verilog, or even System Verilog is not writing software. It may look a lot like software in syntax, but in terms of what becomes actual logic (the term is "synthesized") it's really digital design and the language is just the means to the implementation. Now if a team truly has software engineers that are not experienced digital designers, I cringe at the outcome of what that design will look like. What makes things even more muddled is when you start getting into the verification realm, then yes it does or can quickly become software design. Most of today's top notch ASIC verification engineers actually have their roots in software engineering. They generate the virtual testbenches and stimulus to wring out the RTL design before it's put to actual hardware.

One last comment for the newbies - the tools and skills used for FPGA design are largely the same for doing chip design. The backend tools get specialized (tools for place and route, floorplanning, etc) and will be different for FPGA vs. chip design, but all the same front end tools and methods are the same.

So if you managed to actually read through all that, I'm curious to hear from the analog EE's in the house.

[EEVblog]

In one aspect, there's the need to understand the electrical interface to an FPGA so one can design a proper circuit around it, do a proper PCB, etc. However, the inner workings of the FPGA itself is a different realm. It's actually not VHDL design or even Verilog design, it's digital design.

Correct. I was (and am) usually very liberal with my term "software" when referring to VHDL and other Hardware Description Languages (HDL's).

As for physical/electrical implementation of the FGPA, usually you also need a fairly intimate knowledge of how the part is going to be used in the "soft" realm as well. As FPGA's are in practice not the ideal "universal" "sea of gates".
Feed your clock into the wrong quadrant for example and oops, better re-spin that board!

And then when you start talking FPGA's with "hard" processor cores, the whole game shifts again.
The same can be said of microcontrollers too, and there are many people who consider microcontroller firmware as part of "digital design". At least at the lower interface levels.

For most hardware people, FPGA design in traditional schematic form is pretty easy and natural, but HDL is a different ballgame going from a very visual form to a coded form, and it usually takes some getting used to.

Now before anyone starts bagging on us poor digital pukes, let me mention for the newbies there's actually a whole lot more to digital design than just tossing down a few AND and OR gates with some flops in between. Is it any easier or harder than what an analog EE deals with? Neither. It's just different. Depends on the complexity of the problem at hand.

True.
And digital is essentially just analog with hysteresis levels

Don't believe me it can get ugly? Pick up a book on DSP (digital signal processing) and prepare to dust off every math book you can lay your hands on. And yes there's a whole range in between.

DSP gets ugly because now you really are talking all about software algorithms and math.
Personally I'd put regular micro firmware in the "digital design" camp before I'd put DSP, but the point is pretty moot!

So where does this VHDL or Verilog fit in? It's just a tool. This is where much of the confusion lies. Writing VHDL (shudder) or Verilog, or even System Verilog is not writing software. It may look a lot like software in syntax, but in terms of what becomes actual logic (the term is "synthesized") it's really digital design and the language is just the means to the implementation. Now if a team truly has software engineers that are not experienced digital designers, I cringe at the outcome of what that design will look like. What makes things even more muddled is when you start getting into the verification realm, then yes it does or can quickly become software design. Most of today's top notch ASIC verification engineers actually have their roots in software engineering. They generate the virtual testbenches and stimulus to wring out the RTL design before it's put to actual hardware.

Yep. By "FPGA software guys" I almost always mean hardware people who have a knack for the "soft side" of VHDL/Verilog.
It would be really hard for a pure software geek with no hardware experience to be any good at HDL's.

Dave.

[DJPhil]

As a newb hobbyist myself I spent a bit of time recently looking rather broadly at different ways to attack a problem requiring a digital solution. In the end I decided to ground myself much more firmly in the analog world before diving into digital design. It was easy to see how fast things could get complicated (for me) if I strayed away from the most basic microcontroller projects into real microcontroller projects, discrete logic, or programmable array logic. I'm sure I'll build up to it, and it'll be fun for me, but the experience left me with a deep respect for those people who are gifted with an intuitive and/or trained understanding of logic as a concept. I'm still forming my impressions of the different aspects of the electronic world, and my brief peek at the realm of programmable logic left me with the impression that it's difficulty level (for me at least) is very high.

There are many aspects of analog design that I find just as challenging, but in a different way. The feeling in my head when contemplating the function of an analog circuit is one of flow, I tend to visualize electricity as fluid (often air, as in a pneumatic system, or occasionally water). It can be hard to keep track of a lot at once, and some schematics make my head want to pop when I look at them (buck/boost converters for example, or just about anything with an inductor). Digital circuitry is difficult for me to imagine like this (square waves with air, ouch), so I expect to have to retread my instincts before being able to understand digital circuitry more complex logic. I try to keep shifting my methods of visualization to avoid forming bad mental habits. It sounds weird but it's how my head works best.

Speaking to software vs. analog hardware vs. digital hardware vs. etc . . .
In my case it's probably best I never do any of the above professionally (see above weirdness). My advice would be to follow your passion, even if it leads you in a completely different direction altogether. I share Dave's opinion on the philosophy: specialize in your passion, have a working understanding and curiosity about other things. If at all possible avoid making a decision based on the job market or potential income, but if you're forced to do so then stay up to date on your passion and be ready when the opportunity comes. Also, respect passionate dedication in other people, they will be among the most valuable and enjoyable people to know.

. . . tools for place and route, floorplanning, etc . . .

The bit about floorplanning reminded me of a picture I saw once, and sent me trying to track it down. I found it in Art of Electronics 2nd Ed. on page 851.

I'm not sure what floorplanning means in the context of chip design, but I thought this was awesome nevertheless.

[A-sic Enginerd]

It would be really hard for a pure software geek with no hardware experience to be any good at HDL's.

Dave.

Thank you thank you thank you!
Can't tell you how many times I just about collapse to the floor and roll my eyes when I'll be talking to a fellow engineer that doesn't understand HDLs and they say something like, "well it's just like writing software."

It's also the reason there have been lots of tools that have come and gone in the market with the intent to autogenerate a bunch of synthesizable RTL based on some other whiz bang input like a high level block diagramming tool or some other sort of functional level input. Good idea, but they had the wrong people writing the code for the part of the product that spits out the actual HDL. The tools usually don't last long before the company dries up. Stuff Dave would definitely cry out "Absolute heap of shit!!!"

[jahonen]

I think too that there is no way you can say that HDL is just another form of software, no way.

For example, average sequentially thinking software guy becomes very confused when he reads for example following VHDL code snippet which increments count if a is not '1' (although, doing this is not very wise because it is confusing):


if rising_edge(clk) then
  count <= count + 1;
  if a = '1' then
    count <= count;
  end if;
end if;


If you translate this blindly to C, the if statement would seem to be pretty useless. If you don't know how the FPGA (or VHDL signal rules work), efficient coding is pretty much difficult. I personally tend not to think about gates in FPGA, but LUTs followed by DFF:s (and lots of routing channels in between), which they essentially are, more or less.

And for me, digital signals are just non-linear wideband analog signals up to GHz range for harmonics content. It just makes sense.

Regards,
Janne

[A-sic Enginerd]

The bit about floorplanning reminded me of a picture I saw once, and sent me trying to track it down. I found it in Art of Electronics 2nd Ed. on page 851.

I'm not sure what floorplanning means in the context of chip design, but I thought this was awesome nevertheless.

Hehe, hadn't noticed that picture before. I guess back when a chip had few enough gates on it you could hardcopy the plot and see what's actually going on. Now days the ratio of geometry size to gate / transistor count is just too extreme. The plot would probably have to be the size of a small country to be legible.

Anyway, floorplanning in chip design is to take the individual larger sub-blocks of the design and determine their shape and where best to drop them down on the die. Definition of a "sub-block" is somewhat arbitrary and is determined by a number of factors, but usually we try to break them down by functionality: CPU, ethernet controller, RAM controller, etc.

The floorplanning tools for an FPGA have to understand the FPGA architecture and the notion of a LUT and all that, hence why they diverge from a specific chip vendors tools.

[wd5gnr]

Great picture. When I used to work for Motorola we had the engineering printers that could do those and used to wander around 68000 layouts like that.

I do find people who dismiss HDL as software, but I also find that a lot of hardware guys (well, ok, me too) when they get started with FPGAs (or before they get started) say "Oh I don't need no stinkin' HDL! I'll just draw schematics because that's what EEs do!"

Well the quickest way to dispel that is to ask them to draw a schematic of a 4 bit BCD to 7 segment decoder. Sure, we can all do that, but what a pain. Sit quietly while they sketch all the and gates. Then wait until they are almost done. Make a big show of picking up your pen and write:

Code: [Select]

module SevenSegDecoder(output reg [6:0] ssOut, input [3:0] num);
  // ssOut format {g, f, e, d, c, b, a}

  always @(num)
    case (num)
      4'h0: ssOut = 7'b0111111;
      4'h1: ssOut = 7'b0000110;
      4'h2: ssOut = 7'b1011011;
      4'h3: ssOut = 7'b1001111;
      4'h4: ssOut = 7'b1100110;
      4'h5: ssOut = 7'b1101101;
      4'h6: ssOut = 7'b1111101;
      4'h7: ssOut = 7'b0000111;
      4'h8: ssOut = 7'b1111111;
      4'h9: ssOut = 7'b1100111;
      4'hA: ssOut = 7'b1110111;
      4'hB: ssOut = 7'b1111100;
      4'hC: ssOut = 7'b0111001;
      4'hD: ssOut = 7'b1011110;
      4'hE: ssOut = 7'b1111001;
      4'hF: ssOut = 7'b1110001;
    endcase
endmodule

That's usually enough to cure anyone of wanting to do their CPU design on 625 schematic pages.

[EEVblog]

Well the quickest way to dispel that is to ask them to draw a schematic of a 4 bit BCD to 7 segment decoder. Sure, we can all do that, but what a pain. Sit quietly while they sketch all the and gates. Then wait until they are almost done. Make a big show of picking up your pen and write:

Code: [Select]

module SevenSegDecoder(output reg [6:0] ssOut, input [3:0] num);
  // ssOut format {g, f, e, d, c, b, a}

  always @(num)
    case (num)
      4'h0: ssOut = 7'b0111111;
      4'h1: ssOut = 7'b0000110;
      4'h2: ssOut = 7'b1011011;
      4'h3: ssOut = 7'b1001111;
      4'h4: ssOut = 7'b1100110;
      4'h5: ssOut = 7'b1101101;
      4'h6: ssOut = 7'b1111101;
      4'h7: ssOut = 7'b0000111;
      4'h8: ssOut = 7'b1111111;
      4'h9: ssOut = 7'b1100111;
      4'hA: ssOut = 7'b1110111;
      4'hB: ssOut = 7'b1111100;
      4'hC: ssOut = 7'b0111001;
      4'hD: ssOut = 7'b1011110;
      4'hE: ssOut = 7'b1111001;
      4'hF: ssOut = 7'b1110001;
    endcase
endmodule


Ick!
Times have changed, it's a bit more high level than that now, you can just drop in a 4 bit BCD to 7 segment decoder symbol on the schematic 

Dave.

[A-sic Enginerd]

Well the quickest way to dispel that is to ask them to draw a schematic of a 4 bit BCD to 7 segment decoder. Sure, we can all do that, but what a pain. Sit quietly while they sketch all the and gates. Then wait until they are almost done. Make a big show of picking up your pen and write:

Code: [Select]

module SevenSegDecoder(output reg [6:0] ssOut, input [3:0] num);
  // ssOut format {g, f, e, d, c, b, a}

  always @(num)
    case (num)
      4'h0: ssOut = 7'b0111111;
      4'h1: ssOut = 7'b0000110;
      4'h2: ssOut = 7'b1011011;
      4'h3: ssOut = 7'b1001111;
      4'h4: ssOut = 7'b1100110;
      4'h5: ssOut = 7'b1101101;
      4'h6: ssOut = 7'b1111101;
      4'h7: ssOut = 7'b0000111;
      4'h8: ssOut = 7'b1111111;
      4'h9: ssOut = 7'b1100111;
      4'hA: ssOut = 7'b1110111;
      4'hB: ssOut = 7'b1111100;
      4'hC: ssOut = 7'b0111001;
      4'hD: ssOut = 7'b1011110;
      4'hE: ssOut = 7'b1111001;
      4'hF: ssOut = 7'b1110001;
    endcase
endmodule


Ick!
Times have changed, it's a bit more high level than that now, you can just drop in a 4 bit BCD to 7 segment decoder symbol on the schematic 

Dave.

Yeah, but I think his example is a good illustration of what's going on. Imagine doing an FSM. I have FSM designs that even when looking at them in Verilog I have to get really mentally focused to find the change or bug fix I need to make. The idea of attempting that change if it were all done via K-maps and schematic capture!? ugh.....

It would be impossible, yes I will dare say impossible, to design the chips today that are as large and as complex as they are without an HDL. Doing it by hand it would just be too friggin complex and too many things to track and would be constantly riddled with bugs. By the time you got a design clean enough for tapeout, it would no longer be needed / out of date. And get this one - contrary to software compilers, the synthesis tools of today are pretty damned smart. They have very advanced algorithms and are able to optimize things in ways that would be a pretty far stretch for joe average engr. That's what makes ECO's so fun. (Engineering Change Orders). You spend 90% of the time figuring out what the synth tool did with your code, then the remaining 10% of the time working up the fix and verifying it. Nothing like making hand edits and wading through netlists!!! oooomph...

[wd5gnr]

Ick!
Times have changed, it's a bit more high level than that now, you can just drop in a 4 bit BCD to 7 segment decoder symbol on the schematic 

Dave.

Yeah yeah, but that's not my point. My point is, you can describe what you want in HDL much more succinctly than drawing out logic and the tools can do a better job of optimizing it.

Granted, for something that simple they will have some drop in module that I can instantiate in a schematic OR in HDL. But my point was to demonstrate why schematic drawing is a dying art at this level.

[GeoffS]

Great picture. When I used to work for Motorola we had the engineering printers that could do those and used to wander around 68000 layouts like that.

But when's the last time you saw engineers wearing ties? 

[armandas]

But when's the last time you saw engineers wearing ties? 

That's exactly what I thought. I was wondering whether they dressed up for the photo shoot

[Neilm]

Next time you want to annoy a software engineer remember - "Software is all about 1's and 0's. Any idiot can get is half right."

[A-sic Enginerd]

Next time you want to annoy a software engineer remember - "Software is all about 1's and 0's. Any idiot can get is half right."

Yeah, I tell people I wonder why they made me take all that math in college. I mean come on, I've been doing this job for a number of years now and not once have I had to count higher than 1.

[wd5gnr]

I had a stuffed shirt prof when I was working on my masters who kept saying "maximize the boolean variable" -- I had to think about it for awhile before I realized he meant "set the bit to 1" -- man. Some people are apparently pretty insecure.

[charliex]

So there's some notes on RAD tools sucking, that doesn't apply just to hdl/fpga and so on, its pretty much the same anywhere you can find a RAD tool. they're just enough. I saw VB recently referred to as the "no programmer left behind" language.

I hear a lot of the same discussions in the software world too, its just like hardware theres really no difference. Each has a set of rules, you follow them or you deal with the consequences. Its rare there are magic bullets, and not all programmer/languages are equal.  You can get by with a lot of the off the shelf stuff, and that covers a suprising amount of work.

Often i'll see something like, well X language/hw lets you do this which is stupid, so in my mind that basically is solved with, don't do stupid things,  not lets blame the toolset for letting us do it. I'd like to see how well that attitude goes down in a machine shop !

FPGA's etc are definitely tricky to get your head around, but not more tricky than say writing a physics engine, you just have to understand it. there are loads of gotchas and that often just comes down to experience, and sometimes just talent. Pick something hard, and then say 'that is hard', i guess i just don't understand that POV.

Sure comparing VHDL to C is going to be silly, but why would you do that ? Is there anyone dumb enough out there who really believes that because it looks similar , its the same ? Especially after they've had a go at it ? Sure internet banter and all that.

I know i struggled with VHDL and initially didn't understand the difference between simulation and synthesizing, which is a very odd concept to me as a developer.


cheers