I have a computer engineering degree, but I've spent most of my professional career writing software for embedded CPUs (with a bit of hardware designed on the side). So, I'm probably tainted in this respect.
I agree with your statement, Rick. A grumpy old FGPA engineer once told me that anyone who says they're "writing a program for an FPGA" doesn't know what they're doing. He says they typically end up with a design which is not synthesizable. He and I agree on this point.
You're describing how you're hooking up logic within the FPGA, virtually connecting the wires between logic gates. HDLs let you cheat a bit and say what you want to do, then they try to figure out what you meant. This elaboration process can be perilous, if one does not know the proper incantations. The older HDLs, such as PALASM and CUPL were so close to wiring gates together that it was painful, but they didn't infer much, if anything, about what you meant.
So, here's my nomenclature:
"Software" -> Stored program code, typically stored in offline memory and then loaded into RAM to run on a CPU. Also a generic term, even if applied to embedded systems.
"Firmware" -> Stored program code, residing in Flash/EPROM/EEPROM/etc. and ready for instant fetch/execute by a CPU.
"Program" -> Noun: Source code for Firmware or Software, Verb: The physical act of putting bits into some storage, usually Flash/EPROM/...
"RTL" or "Design" -> The embodiment of a Boolean logic design, typically in the form of a Hardware Design Language such as Verilog, VHDL, etc.
"Bitstream" or "Configuration" -> When the RTL/Design is fed into a design tool that compiles/elaborates/synthesizes the former, along with a description of the target hardware, into a series of bits or bytes in a file. This file, when loaded into the FPGA, configures the gates/LUTs/other-logic-elements into the hardware design described by the RTL/Design.
Anyway, if one stays away from the terms "Software" or "Firmware" for hardware design and remembers that FPGAs are just a sea of look-up tables and logic, one won't fall into the trap of thinking that stuff at the top of the HDL source file executes before the stuff at the bottom.
I started with electronic hardware when I was a young teenager with a hand wired kit/toy with bells, lights, switches and batteries. I call it "elect ronic" because I learned to gang SPST switches together to make DPDT switch es, my first logic exercise. lol From then on it was all a direct path.
So I'm probably "tainted" too.
That's always a great way to start a discussion even if you disagree. A f riend makes a point of telling me every time I see him, "You are not only r ight, you are absolutely correct". Lol... so far it hasn't completely take n, I tend to be a bit argumentative online.
Your friend was not only right, but absolutely correct... except for the pa rt about then not knowing what they are doing. I call it a program, but us ually add "code" as in "I'm working on the program code now". While proces sor code is written differently most of the time, they are both still actua lly not totally different. Just don't confuse a process sensitivity list f or a subroutine parameter list.
That would be true of instantiated logic which I typically use at the modul e level, but not true of the logic defined in the modules. Inside the modu les the logic is simply described in the assignment expressions. It is ent irely up to the synthesis tool to synthesize the logic and it's up to the b ack end tools to place and route. My code has nothing/little to do with th e P&R unless I add very detailed instructions which are vendor unique and v ery laborious.
Not so much "try to figure out" since logic is a well defined part of the l anguage. The synthesis tool tries to provide an optimal solution. In one, not unusual case I recall getting poor results because my code was not des cribing what I was seeing in my head like I thought it was. So instead of getting an optimized structure, I was duplicating the adder chain to get th e carry out. My coding style learned from that. Now I code the logic of s uch adders/counters outside the process so there will only ever be one adde r/carry chain and use the results of that adder in the process. I suppose if I were more organized, I could make the adder logic a library function r esulting in a single, simple, consistent line of code where used.
Not sure I'd call PALASM or CUPL HDLs. I suppose it is, but they're more l ike assemblers for logic than high level languages.
You are not only right, but absolutely correct! So what exactly is the dif ference between reading a program from a flash drive into ram for execution and loading a program from a flash chip into ram for execution? Does a Ra spberry Pi built into a box to control lighting in a house load software fr om it's SD card or load firmware? If the same job is being done by a TI MS P430 does it load software or firmware from the internal Flash on the chip? What if either of these devices are connected to a rotating disk for prog ram storage?
Or are you saying firmware has to be in Flash that can be directly addresse d and executed by the CPU?
This is what I mean by there not being much value in even distinguishing th e terms. To me it's more of a "who cares" about using one term or the othe r since the boundary is so subjective and not of much value. What does cal ling it software imply that firmware doesn't or vice versa?
What does it mean to you to say "Boolean logic" exactly? Don't most comput er programs utilize Boolean logic in one way or the other, the same as HDL.
A "Bitstream" or "Configuration" -> When the RTL/Design is fed into a
That's a very fundamental difference that has to be understood before doing any HDL work. I took a 1 week class in VHDL and they didn't do that. The instructor just followed a book that wasn't really so good and he seemed i ncapable of making that distinction of everything at the top level (concurr ent code) was running in parallel rather than sequential. He also failed t o explain that a process was not a subroutine in any way that helped. (Jus t saying they aren't the same doesn't really help) The biggest issue is th at the sensitivity list is not a parameter list. Then there is the fact th at outside a process the code is parallel, inside the code is sequential. Nope, no real explanation of that. The guy had no business teaching the st uff.
Anyway, I find it interesting to discuss experiences. I haven't done any c oding in a while.
--
Rick C.
--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209
They're definitely more limited, to be sure. But CUPL does have syntax for truth tables, state machines, etc.
Yes, this is what I'd consider the turning point for "firmware". Something that is instantly available for execution, without being first loaded by some other mechanism (ROM, 1st/2nd stage bootstrap, etc.)
You are correct. Perhaps the best thing is to delete "Boolean logic" out of that sentence and replace it with "hardware".
Well, one is a nonblocking assignment and one is a blocking assignment, but that's a bit off our topic. :-)
I know very little VHDL, other than my impression that it is more akin to the rigidness of Ada or Pascal, whereas Verilog is closer to anything-goes C.
Yes, nothing more than just direct logic of one output at a time is allowed . There isn't much in the way of optimization. No conditional constructs (the sort of stuff that makes sense to humans and not just totally geek eng ineers like me). No complexity of assignments. If you want an output to b e tristate, you don't assign a tristate value to the output, you manipulate the tristate control of the output. No targets other than simple devices.
Although I shouldn't say this about CUPL as I have not used it.
Ok, so at least you have your clear definition of "embedded". Others inclu de devices on external properties like the form factor or application. I g uess my point is everyone having their own definition of the term makes it hard to have discussions with this language.
Ok, but my point is that includes virtually every type of HDL program... er , design. Conventionally RTL is a coding style that directly specifies reg isters and the logic between them rather than a functional description that is more abstract in a way that allows the registers to be less obvious.
That isn't want I intended to be saying. The latter is how you write an as signment in C. I guess my point is that both types of language have simila r functionality in many ways... more similarities than differences.
Yes, they have relaxed some of the stricter issues such as allowing "IF sig nal_a THEN" rather than requiring "IF signal_a = '1' THEN". But type che cking is still pretty stiff. At one time a string constant (the way you sp ecify a vector) had to be type cast as the logic type you wanted because it can be more than one type. They did something to relax that a couple of r evisions ago. Still, strong typing can trip up a newbie. You quickly get used to it. Just think what you intend and if what you write can be interp reted more than one way. VHDL will not assume. That's the basis of its ri gor. No assumptions. Verilog has many default assumptions which you have to know about to not get it wrong by not specifying that you want something different. It's easy to make a mistake doing math that is hard to find.
--
Rick C.
--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209
I do FPGA design since 20+ years (MAX+PLUS II anyone?), but I came across the term "gateware" for the first time a few days ago in a job interview. So it is quite funny to find it again in this discussion here. But I think it is not really widely used...
BTW: Did anyone realize that this thread started in 2006?
To come back to the topic: In my company we just refer to it as "the FPGA design" which is a part of the firmware update file of a product. But I would not call a FPGA design (or configuration file) alone firmware.
I have seen gateware is used to differentiate HDL derived implementations f rom firmware.
The landscape has changed over time quite a bit. Nowadays we have a soft c ore processor running software.
At its core, all data processing systems (discrete systems) are doing two t hings; implementation of an algorithm, and running a state machine. When implemented in gateware, an algorithm is implemented as a combinatoria l circuit, and the state machine is implemented as a sequential circuit.
It is possible to design a complete data processing system as a single disc rete system with different frequencies attached to each seq circuit and del ays to the algorithms, analyze for throughput, and change the software/gate ware boundary at the time of implementation.
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.