Is FPGA code called firmware?

Not at all. Programmers juggle instruction/statement flow all the time to reach timing closure in C and asm for device drivers and embedded applications in many fields .... such as software driven stepper motor controls. Such low level programmers also have training in understanding bit level device interfaces, and related timing. They frequently do not have board level hardware training or experience, to deal with power, board level signal integrity, and related issues.

The reason for C based HDL/HLL's is to expand the field to include related sytems and embedded programming talent to be able to effectively, and comfortably, write "programs" for HDL/HLL FPGA based designs which effectively instantiate the same hardware that VHDL/Verilog would with similar syntax statements. We do this by preserving sequential semantics with parallel statement execution of standards based C. Also removing fine grained access to creating multiple fine grained clocking sematics that are standard for pure HLLs. For those that are doing device level or machine level interfaces, writing C FSMs to netlists is substantially the same as coding asm or C for similar low level hardware interfaces. Remarkably the same task and skill set as writing drivers or embedded hardware controls.

Programs are FSM's and data paths.

Reply to
fpga_toys
Loading thread data ...

Looking at the problem a little more this afternoon, the C based 66mhz PCI core is looking much more viable. The combinatorial length was actually from unnecessarily including the main references to the pci bus signals in the else side of the reset conditional. Breaking that dependency changed the base FSM speed from 63mhz to better than 73mhz, making it likely the other setup and hold times can be met as well. I suspect the remaining code to be written will not change this, and I can refine what is there a bit better, possibly improving this so my other board with -6 parts can be used at 66mhz as well. Probably by hacking the ucf file some more to optimize placement for the bus interface slices to use the local IOB to CLB routing, and get rid of the longer general routing paths ISE is using, since routing delays appear to be better than 60% of the timing budget.

Timing summary:

---------------

Timing errors: 0 Score: 0

Constraints cover 1569 paths, 0 nets, and 1215 connections

Design statistics: Minimum period: 13.556ns (Maximum frequency: 73.768MHz) Maximum path delay from/to any node: 13.556ns

Reply to
fpga_toys

But you're not just juggling lines of code about so the order of execution is different (ie to make sure things are picked up quickly enough in an ISR or whatever).

I still think this is an accurate observation...

"You've had to understand the target architecture and what's causing your timing constraint to fail, then re-jig your HDL to reduce the number of levels of logic to achieve timing closure."

Nial.

Reply to
Nial Stewart

First, your cut an paste of several different points and answers isn't accurate. My answer above is to this part that that it directly followed:

||> I thought that one of the arguments for using a C based HDL was you can avoid ||> this level of design implementaion detail?

My point was and is that low level programmers have to understand the underlying hardware in significant detail to program it properly ... that has never changed in 35 years. It really doesn't mater if we are talking about clock latency and scheduling for multiple pipelines, or the physics and dynamics of a motion control system. I really does matter if the system measurement units are hours, seconds, microseconds or picoseconds. Or that the units are core access and cycle times, pipeline latencies, clock cycles, gate delays or routing segment latencies.

Certainly. So what's your point?

Certainly. But the second part and real point in your question remains, and that I addressed in detail I still have issues with:

|| > I thought that one of the arguments for using a C based HDL was you can avoid ||> this level of design implementaion detail?

and the answer remains, not at all.

Reply to
fpga_toys

"Stiffware" I love it!!

Reply to
ritchiew

The FPGA manufacturers call it the "configuration", but I don't think firmware is very wrong when talking to less-technical folks.

Jon

Reply to
Jon Elson

I think "configuration" would be equivalent to the machine code that is pro duced by a standard compiler for CPUs. The OP is asking what to call the s ource code. In PCs and other typical computers it is "software". In embed ded applications it is "firmware", mainly because it is loaded into a write only memory (or write mostly). So what name to use for programming that i s for configuring hardware?

I think I'm in favor of "hardware"... oh, what, that's already used... lol

Firmware is as good as any term. I'm ok with calling it software.

--
  Rick C. 

  - Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

"Firmware" is one of those terms that has a very specific meaning in a very specific context. And means exactly what it is intended to mean. But as soon as the context changes... So does the definition.

Which makes the term practically useless as a general use technical description. Sure for the general public, (or anything above a level 2 manager), "Firmware" might as well mean "The magic smoke which makes my device do things when I turn it on". Usually one thinks of it as applying to "embedded" electronic devices - which is another fuzzy definition in itself. Here, "Embedded" usually means any device that's not a personal computer sitting on one's desk. But even that's up for argument...

Regards, Mark

Reply to
gtwrek

So what is that very specific meaning of "firmware"??? I've not come across it. Every source I check has a different wording and meaning.

Wikipedia - In computing, firmware[a] is a specific class of computer software that provides the low-level control for the device's specific hardware.

Google - permanent software programmed into a read-only memory.

techterms.com - Firmware is a software program or set of instructions programmed on a hardware device. It provides the necessary instructions for how the device communicates with the other computer hardware.

lifewire.com - Firmware is software that's embedded in a piece of hardware

So each one is different enough that the included classes vary hugely!

What is yours?

--
  Rick C. 

  + Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

I'm uncomfortable with the use of 'firmware', because FPGAs frequently have some kind of processors on them, either soft cores or hard cores like the ARM on a Zynq. Those cores run a software stack - either bare metal, some RTOS or maybe Linux. There's quite a difference between the software running on these cores and the hardware design programmed into the FPGA. Typically when one refers to an embedded product 'firmware' is referring to software for a processor. If you advertise for FPGA firmware engineers you might expect software people to apply for the job, for instance.

Another term used for the hardware is 'bitstream' - not very descriptive, although it does imply the hardware-blockbox overtones to it.

If you're talking in general terms about the lump of data loaded from flash on boot, used to make the product usable, without any distinction of whether it's hardware or software, then maybe firmware works slightly better.

Theo

Reply to
Theo

e:

M.

ve

e

to

ou

sh

her

I guess my interest is in a label for the program as written in the languag e, the HDL. I don't call that a bitstream. The bitstream is what gets loa ded into the FPGA. I write software or firmware. I've never gotten used t o the term "gateware" but it would be fine if that is what ends up being ac cepted ultimately.

Rather than to say, this term means this and that term means that, I would ask what the purpose of using those terms would be? What distinction is be ing made?

--
  Rick C. 

  -- Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

Interesting question. You write a hardware description language so what you produce must be the "Hardware description"...

I personally am quite happy to call the HDL source code an "Program" or an "hdl program".

A "program" really is just a list of instructions. Just as "g-code" is a programming language used to control a 3-d printer or milling. machine, VHDL is a programming language that is used to "program" a "logic synthesisers" which generates the bitstream.

Generally we use the term "firmware" to refer to code that is in some way an intrinsic part of the hardware, without which it won't function.

Dave

Reply to
David Wade

flash

hether

guage, the HDL. I don't call that a bitstream. The bitstream is what gets loaded into the FPGA. I write software or firmware. I've never gotten us ed to the term "gateware" but it would be fine if that is what ends up bein g accepted ultimately.

The source code is indeed a hardware description.

uld ask what the purpose of using those terms would be? What distinction i s being made?

My PC won't function without software. So what is really different? Origi nally it had to do with the fact that firmware resided in ROM or EPROM whic h could only be programmed by means other than just loading it into RAM.

Now with Flash memory being rewritable in the system, there is much less di stinction and in many systems the Flash acts more like a hard drive with th e program being executed from RAM. Raspberry Pi devices are like that. Ev erything about developing code for a rPi is like developing code for a PC, but in the end it is an embedded system.

So what would be the purpose of calling this firmware... or any other devic e?

--
  Rick C. 

  -+ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

That's my point. My definition entirely depends on context. So much so that as a general term "firmware" is next to useless in a general technical forum...

Regards,

Mark

Reply to
gtwrek

Not trying to dig or start a flame here... But when I hear someone describe Verilog or VHDL as a "program", I'm almost certain to (prejudge) that such individual is a newbie, or inexperienced at FPGA design. Thinking of traditional "programs" or "list of instructions" when designing an FPGA is certainly the wrong mindset.

FPGA vendors would love to think that there new wonderful C like "High level languages" are just super programs that make things run fast on an FPGA. But they're nothing of the sort. One "designs" with an HDL akin to how one designs with a schematic.

Comparing to instruction based CPU's just doesn't fit, which is (in my mind) what "programs" traditionally do.

My 2cents.

Regards, Mark

Reply to
gtwrek

2
y
s

ross it. Every source I check has a different wording and meaning.

ftware that provides the low-level control for the device's specific hardwa re.

ogrammed on a hardware device. It provides the necessary instructions for h ow the device communicates with the other computer hardware.

re

Yeah, I think I misread your other post. I agree. It's like Humpty Dumpty said,

?When I use a word,? Humpty Dumpty said, in rather a scornf ul tone, ?it means just what I choose it to mean?neither mo re nor less.?

--
  Rick C. 

  +- Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

correct.

Thats what typical modern programs do. But that is a very narrow use of the word "program" Those of us who are old enough to have programmed an analog computer may recall that we did so by physically wiring analog adders, integrators, comparators and other components together.

In fact using a very similar process to that we use to configure an FPGA.

Going back to Eniac that was also "programmed" with wires and plug boards.

so whilst many folks assume a "program" is restricted to digitl languages, historially it was applied to other processes..

Dave

Reply to
David Wade

It's no longer the canonical definition in my opinion. When I hear a question on some FPGA group asking about some details on "my verilog program" it's inevitably a newbie with a software background.

While I've never touch an Eniac - nor seen one outside a musuem - I've debugged a few wire-wrapped systems in my career early days. Don't care to go back to that...

Regards, Mark

Reply to
gtwrek

So what do experienced folks say? Simply "My VHDL" or "my verilog" I guess?

Perhaps the issue is with the training materials. Most of the VHDL tutorials I can find refer to VHDL programming and I don't see how you can have programming without a program.

I must admit I it took me a while to get my head round the non-sequential behaviour of VHDL and wondered how the tools that claim to let you program FPGAs in "C" work in practice.

Well most Tuesday I get to demonstrate the replica Manchester Baby/SSEM, a valve/tube computer but thats really just like a modern machine to the programmer. Inside it has some tweaks to cut down on valves/tubes.

But I also own an EAI TR-10 analoge computer which is definitely programmed with wires... (This one isn't mine)

formatting link

Dave

Dave

Reply to
David Wade

t
r
a
,

hen

n

While I tend to think in terms of the logic involved and write my HDL to de scribe the logic I have in mind, not everyone works that way (many call thi s RTL coding).

Once I was interviewing for a job and when asked I described this method of designing. The lead engineer of a Japanese team disagreed saying they did n't have time to optimize the code so they wrote to describe the behavior i nstead (many call this behavioral coding). I was trying to point out that the two do not need to be in conflict, that an RTL coding style can be used to describe behavior with little or no additional effort. The lead engine er disagreed and we discussed it a little. When I was in touch with the re cruiter he asked me about the "confrontation"! I didn't realize there was a confrontation. lol Obviously there was not a good match of cultures.

.

Yes, I wish there were better terms to describe programs written to run on sequential processors to distinguish them from programs written to describe hardware. The emphasis these days is to try to merge the two so the entir e application can be written in one language and different layers can be im plemented in either domain as best suits the particulars of the system bein g designed.

Just some thoughts...

--
  Rick C. 

  ++ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

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.