Does a VHDL programmed FPGA concern software or hardware?
As usual also this issue can be approached from different viewpoints. One viewpoint can be the realization process, Another viewpoint can be blackbox testing of the programmed FPGA device, whether or not 100 % coverage can be achieved. You will certainly be able to add your own viewpoints and your personal opinion to this question. Does a VHDL programmed FPGA concern software or hardware? Should software engineering methodologies be applied or is it more likely application of switching theory and logical design or ..... And what about design verification & validation? What do you think?
Thats because were are all pretty old and back when we were in school, I think we did our own homework rather than posting questions into the ether (arpanet was still in infancy).
Besides, badly asked obvious homework/essay questions are considered sport. On the comp arch parent NG, the sport is far more brutal. Professors should I hope monitor the relevant NGs to see who the class slackers are. I actually had some buffoon google me & ask to do his homework, only had to haggle the price.
Well composed serious and interesting questions do get some help though if the homework is admitted and some effort has been made.
Once upon a time (in a different NG) a bozo asked obvious homework questions for about a month straight. I (semi-jokingly) asked him to send me his prof's email, so I could save him the trouble of even having to email the answers in -- and being (apparently) a bit stupid along with lazy, he sent not only his prof's email, but also his own full identification (class number, student ID number and the whole bit). For some strange reason, after I emailed his prof, the guy just seems to have dropped out of sight.
I also know of at least one guy in Russia who makes a pretty decent living, almost entirely from doing homework for people in the US. I guess in this day and age, it's good training for managers though -- they'll have practical knowledge of outsourcing before they graduate...
This question is hard to answer. Depends on the criteria you use. My opinion is use the one of Hard, Soft & Firm that fits your needs best :). A good answer should include, that it is very design dependend. A programmed fuse based FPGA is hardware, a bitfile using reconfiguring during runtime is software.
Maybe you could allways consider the device as HW and the bitfile as SW. Of course this is a very easy point of view.
Why?
And what do you call SW without 100% BB-Testing? (Beside "commercial ready")
Software engineering methods are more often applied for developing HW than for developing SW.
The background for my question whether an FPGA is viewed as software or as hardware comes from the regulations for medical devices.
From the perspective of regulatory requirements it makes a difference whether an FPGA is viewed as software or as purely hardware because of regulatory requirements for medical devices are more comprehensive when software is involved.
Regulatory requirements for medical devices are focussed on safety and reliability of the finished medical device. If the resulting product cannot be tested in full - which is the case with software - then the regulations require to have controlled processes in place for (software) product development in order to minimize risks on hazardous situations.
Is anybody in this NG experienced in the field of applying FPGA's in medical devices and the view of regulatory bodies?
Looks like a duck, swims like a duck, quacks like a duck, it must be a duck???
In the end, if it looks like software (HDL or HLL), acts like software (loads from some read/write storage media such as eeprom, flash, disk, network), is readily updated/changed like software, there probably is very good reasons for regulators (or litigating lawyers) to suggest that design procedures would have avoided the loss of life or injury if the development had been held to the proper, and more rigourous standards of software. It's really hard to claim due diligence after the fact when you choose to take the easy way out by splitting hairs with definitions.
Reconfigurable computing and system-on-chip design strategies blur the line today, and will probably solidly move that line so that FPGA design is considered software tomarrow. And for good reason.
***HARD*** ware designs can not easily/cost effectively be changed in the field, and as such everyone puts more effort into getting it right first time for that reason. ***SOFT*** ware has a reputation of people taking shortcuts because it can be changed next release, and get better (or right, or perfect) over time. I'm almost certain someone can find a written memo from some company to ship a hardware design in FPGA with known critical flaws to meet contractual shipment obligations or sales quotas, with the expectation that it can be corrected with an updated FPGA image next week, month, year. One such memo, in litigation, clearly defines HARD and SOFT when it comes to product failures and field upgradability.
I'd call it firmware, the idea being that it's easier to change than hardware but harder to change than software. But it depends on who I'm talking to. If I wanted to be specific for somebody familiar with the gear we are discussing, I'd probably call it "the code for XXX" where XXX is the name of the particular FPGA.
I've worked on old microcoded machines that had some RAM for the microcode. It was rare, but a couple of good hacks compiled (micro) code on the fly and loaded it ...
I might call a simple ROM based state machine "firmware" because I'd probably write a program to generate the contents of the ROM. For anything but the simplest sort of state machine, it's easier to hack an existing microcode assembler to do what you want and then actually write the code in your new assembly language.
Ask your lawyer.
Do the regulations say anything interesting about simple software vs complicated software?
Are you doing anything complicated in your FPGA? Is it just glue logic, or do you have complicated state machines?
Software people in general (both coders and managers) have a reputation for shipping buggy crap. Hardware guys have a reputation for doing (much) better. From what I've seen, it'a a culture thing. Hardware projects tend to be expensive to fix so management tends to encourage doing it right. That message gets passed around to everybody working on a project.
I think it's possible to build good software. It doesn't happen very often. I've never worked on a safety critical project.
There is also the complexity issue. It's easier to build a tower of cards out of software. You can make it do something useful most of the time without paying any attention to the complicated corner cases.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Please read the very fr "Xilinx products are not intended for use in life support applications. Use of Xilinx products in such applications without the written consent of the appropriate Xilinx officer is prohibited."
This of course has to do with legal liabilities. So it is serious stuff. Peter Alfke, Xilinx Applications (from home)
But don't be too scared.. every single electronics company on the planet has the same disclosure statement. The best bet is look at aerospace everything is triplicate.. and there is hardware safety interlocks too. FPGA's like software are still subject to gamma and single bit events. Even if its one in a million.. you don't want to be that millionth. Just don't forget.. with medical applications you had better be bloody sure it works.. or it will be bloody for sure.
The problem is that the regs require similar levels of documented development processes for life support as they do for any supporting medical electronics, such as imaging products. The Xilinx and other disclaimers for life support, are just a small fraction of the equipment subject to these regs in many places. I spent some time working in an MRI shop 10 years ago, I was amazed at the regs.
I've seen my share of crap hardware designs go out the door in 35 years, pushed by managers with their feet held to the fire for shipment schedules, so it's just not a software problem. The problem with most large software projects, is that the logic complexity is two to four orders larger than a very large hardware design. Corner cases sneek thru in both hardware and software designs. In the old days you would see a board escape to production in a few revisions. Large ASIC projects burn a few more mask revs than people would like, but also fail the simulator pretty frequently for every mask rev .... and we see large ASIC projects with design errata that are never corrected too.
It's because the software complexity is so much higher, as well as part of the industry adopting low quality standards for both hardware and software, that it also makes sense to focus on documented development process for both, especially software .... not the quality of engineers working on it.
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.