Hi all, A couple of weeks ago, I was watching the talk of Wolf Clifford on his opensource fpga flow at ccc. (https://www.youtube.com/watch?v=SOn0g3k0FlE) At the end, he mentions designing an open-source fpga and the replies he got when he mentioned the idea to hardware-companies. Appart from the question about the usefullness or economic viability of the idea itself (1), it did get me thinking. Question, can I conclude from his remark that -if a hardware companie would start out with designing a fpga- that the problem is more the "software" side of things than the actual hardware design of the chip. Or is this conclussion a bit to easy? Cheerio! Kr. Bonne.
designing a fpga
Started by ●February 24, 2017
Reply by ●February 24, 20172017-02-24
On 2/24/2017 2:32 AM, kristoff wrote:> Hi all, > > A couple of weeks ago, I was watching the talk of Wolf Clifford on his > opensource fpga flow at ccc. > (https://www.youtube.com/watch?v=SOn0g3k0FlE) > > > At the end, he mentions designing an open-source fpga and the replies he > got when he mentioned the idea to hardware-companies. Appart from the > question about the usefullness or economic viability of the idea itself > (1), it did get me thinking. > > > Question, can I conclude from his remark that -if a hardware companie > would start out with designing a fpga- that the problem is more the > "software" side of things than the actual hardware design of the chip. > > > Or is this conclussion a bit to easy?Nearly two decades ago (well, 15 years anyway) folks from Xilinx said they spent more on software development than developing the chips. -- Rick C
Reply by ●February 24, 20172017-02-24
On 02/24/2017 08:32 AM, kristoff wrote:> Hi all, > > A couple of weeks ago, I was watching the talk of Wolf Clifford on his opensource fpga flow at ccc. > (https://www.youtube.com/watch?v=SOn0g3k0FlE) > > > At the end, he mentions designing an open-source fpga and the replies he got when he mentioned the idea to hardware-companies. Appart from the question about the usefullness or economic viability of the idea itself (1), it did get me thinking. > > > Question, can I conclude from his remark that -if a hardware companie would start out with designing a fpga- that the problem is more the "software" side of things than the actual hardware design of the chip. > > > Or is this conclussion a bit to easy? > > > > Cheerio! Kr. Bonne. > >Hodgin posted this link a while ago: https://www.youtube.com/watch?v=1oG-3XWLgog
Reply by ●February 24, 20172017-02-24
rickman wrote:> On 2/24/2017 2:32 AM, kristoff wrote: >> Hi all, >> >> A couple of weeks ago, I was watching the talk of Wolf Clifford on his >> opensource fpga flow at ccc. >> (https://www.youtube.com/watch?v=SOn0g3k0FlE) >> >> >> At the end, he mentions designing an open-source fpga and the replies he >> got when he mentioned the idea to hardware-companies. Appart from the >> question about the usefullness or economic viability of the idea itself >> (1), it did get me thinking. >> >> >> Question, can I conclude from his remark that -if a hardware companie >> would start out with designing a fpga- that the problem is more the >> "software" side of things than the actual hardware design of the chip. >> >> >> Or is this conclussion a bit to easy? > > Nearly two decades ago (well, 15 years anyway) folks from Xilinx said > they spent more on software development than developing the chips. >It is easy to believe this is true. The FPGA needs a fair bit of careful design and testing, but the structure is quite simple. You need to make sure the LUTs are glitchless and that you know the timings. That is about it. THEN, you get to the software side. You need to be able to take in all the suboptimal and blatantly bad HDL that users will throw at it, and at least give coherent error messages and not crash. There are probably so MANY ways to write bad HDL that has unintended side effects, races and logic hazards. While the FPGA is a massively repeated set of very simple identical cells, the software has to treat it as thousands of different components once the LUT patterns have been loaded. I'm GLAD somebody else is doing all this work! To make your own FPGA, probably the BIGGEST minefield is the patent arena. There must be thousands of current patents on FPGAs and FPGA-like devices and tons of old prior art that could make patenting anything you design problematic. Even if you had no intention of filing for a patent, you'd have to design very carefully so as not to step on one of the "big boys" patents. There is also lots of prtections files on software IP that you'd have to avoid. Jon
Reply by ●February 24, 20172017-02-24
In 2004 ST started the most serious Open FPGA project I am aware of: http://web.archive.org/web/20041208022906/http://www.gospl.org/fpl/static/aboutgospl.jsp Sadly they gave up in early 2005. -- Jecel
Reply by ●February 24, 20172017-02-24
On 2/24/2017 11:35 AM, Jon Elson wrote:> rickman wrote: > >> On 2/24/2017 2:32 AM, kristoff wrote: >>> Hi all, >>> >>> A couple of weeks ago, I was watching the talk of Wolf Clifford on his >>> opensource fpga flow at ccc. >>> (https://www.youtube.com/watch?v=SOn0g3k0FlE) >>> >>> >>> At the end, he mentions designing an open-source fpga and the replies he >>> got when he mentioned the idea to hardware-companies. Appart from the >>> question about the usefullness or economic viability of the idea itself >>> (1), it did get me thinking. >>> >>> >>> Question, can I conclude from his remark that -if a hardware companie >>> would start out with designing a fpga- that the problem is more the >>> "software" side of things than the actual hardware design of the chip. >>> >>> >>> Or is this conclussion a bit to easy? >> >> Nearly two decades ago (well, 15 years anyway) folks from Xilinx said >> they spent more on software development than developing the chips. >> > It is easy to believe this is true. The FPGA needs a fair bit of careful > design and testing, but the structure is quite simple. You need to make > sure the LUTs are glitchless and that you know the timings. That is about > it.I think you are oversimplifying the design of an FPGA by quite a large margin. I believe the most important part of FPGAs is the routing and overall architecture. I am sure they put tons of effort into optimizing every aspect of the logic as well as the routing for timing and power consumption, the two most important parameters of FPGAs. The design of all the various special functions take no small amount of effort too, the clock blocks are a good example. Then there are multipliers and memory, all of which must be optimized for the process. In fact, my understanding is that the FPGA vendors are a large contributor to the development of the processes used at the foundries.> THEN, you get to the software side. You need to be able to take in all the > suboptimal and blatantly bad HDL that users will throw at it, and at least > give coherent error messages and not crash. There are probably so MANY ways > to write bad HDL that has unintended side effects, races and logic hazards. > While the FPGA is a massively repeated set of very simple identical cells, > the software has to treat it as thousands of different components once the > LUT patterns have been loaded. I'm GLAD somebody else is doing all this > work!I don't think writing code to read text and not crash is actually all that hard. The tool vendors don't care about logic hazards, that is the domain of the designer.> To make your own FPGA, probably the BIGGEST minefield is the patent arena. > There must be thousands of current patents on FPGAs and FPGA-like devices > and tons of old prior art that could make patenting anything you design > problematic. Even if you had no intention of filing for a patent, you'd > have to design very carefully so as not to step on one of the "big boys" > patents. There is also lots of prtections files on software IP that you'd > have to avoid.Certainly if you wish to make a state of the art FPGA it would involve dodging a great many patents. But to design *a* FPGA would not be so hard. In fact expired patents would be your pool of resources to draw from. The basic LUT used as logic and memory are out of patent along with everything used in devices like the XC4000 series. If I were designing a chip and wanted to include FPGA fabric, I could do worse than to duplicate the functionality of that device. -- Rick C
Reply by ●February 25, 20172017-02-25
rickman wrote:> > I think you are oversimplifying the design of an FPGA by quite a large > margin. I believe the most important part of FPGAs is the routing and > overall architecture. I am sure they put tons of effort into optimizing > every aspect of the logic as well as the routing for timing and power > consumption, the two most important parameters of FPGAs. >OK, yes, I WAS oversimplifying. My point (badly stated) was that the FPGA designers hold all the cards, they fully specify the LUTs, the routing matrix, the IOBs, etc. The SOFTWARE, however, has to deal with all the pathological and just totally unexpected things people will try to do with an FPGA. How about designing your own ring oscillator?> The design of all the various special functions take no small amount of > effort too, the clock blocks are a good example. Then there are > multipliers and memory, all of which must be optimized for the process. > In fact, my understanding is that the FPGA vendors are a large > contributor to the development of the processes used at the foundries. >Yes, I can believe that, too. They really push the boundaries of what can be done in a process.>> > I don't think writing code to read text and not crash is actually all > that hard. The tool vendors don't care about logic hazards, that is the > domain of the designer. > >OK, maybe not "crash", but produce unintelligable error messages, or just totally screwy results, with NO error messages. Yes, now I must admit, some of my legacy designs that have been dragged along from 5V Spartan to Spartan 2E to Spartan 3A still have a bunch of crud left over from their old history and mediocre hacking. But, I've had a few situations where ISE didn't like what I'd given it, and had to just recompose some portion of the logic. I never understood what was wrong with my VHDL, but changing the way I'd written the equations just slightly made it work. Fortunately, I have had very few of these situations, and for the most part ISE works amazingly well, and I'm NOT complaining. I'm just aware that there are so many ways to structure HDLs, and so many things one can do with it, that it seems very complicated to make it all work. Jon
Reply by ●February 25, 20172017-02-25
On 2/24/2017 11:30 PM, Jon Elson wrote:> rickman wrote: > > >> >> I think you are oversimplifying the design of an FPGA by quite a large >> margin. I believe the most important part of FPGAs is the routing and >> overall architecture. I am sure they put tons of effort into optimizing >> every aspect of the logic as well as the routing for timing and power >> consumption, the two most important parameters of FPGAs. >> > OK, yes, I WAS oversimplifying. My point (badly stated) was that the FPGA > designers hold all the cards, they fully specify the LUTs, the routing > matrix, the IOBs, etc. The SOFTWARE, however, has to deal with all the > pathological and just totally unexpected things people will try to do with > an FPGA. How about designing your own ring oscillator?I'm not sure how to even do that in an HDL. I suppose you can have a second input to each inverter and set bits in a register to enable it. But it would still have an combinatorial feedback path which would flag an error in the timing analyzer unless you except that path. Where do you see the problem? The tools don't cope with a lot of crazy stuff. If the inputs are too wacky, they just give an error message.>> The design of all the various special functions take no small amount of >> effort too, the clock blocks are a good example. Then there are >> multipliers and memory, all of which must be optimized for the process. >> In fact, my understanding is that the FPGA vendors are a large >> contributor to the development of the processes used at the foundries. >> > Yes, I can believe that, too. They really push the boundaries of what can > be done in a process. >> > >> >> I don't think writing code to read text and not crash is actually all >> that hard. The tool vendors don't care about logic hazards, that is the >> domain of the designer. >> >> > OK, maybe not "crash", but produce unintelligable error messages, or just > totally screwy results, with NO error messages. Yes, now I must admit, some > of my legacy designs that have been dragged along from 5V Spartan to Spartan > 2E to Spartan 3A still have a bunch of crud left over from their old history > and mediocre hacking. But, I've had a few situations where ISE didn't like > what I'd given it, and had to just recompose some portion of the logic. I > never understood what was wrong with my VHDL, but changing the way I'd > written the equations just slightly made it work. Fortunately, I have had > very few of these situations, and for the most part ISE works amazingly > well, and I'm NOT complaining. I'm just aware that there are so many ways > to structure HDLs, and so many things one can do with it, that it seems very > complicated to make it all work.It's all rule based. As long as you follow the rules it will synthesize. I remember my first VHDL design. I used some of the features that seemed useful and no one told me not to (it was an Orcad tool believe it or not). It was so terrible we switched to the Xilinx tool (I don't recall the origin of that tool). I was using '-' for don't cares in comparisons. Then we had a tool update and Xilinx switched the synthesis engine on us. The don't cares didn't work anymore as well as many other issues. Back in those days I think the vendors tried to ignore some aspects of the VHDL standard and let you get away with some things and not others and of course, each vendor was different. So I wrote my code three times for that project. -- Rick C
Reply by ●February 25, 20172017-02-25
Hi Jecel, Rickman, Jon, Johann, ... all On 24-02-17 18:23, Jecel wrote:> In 2004 ST started the most serious Open FPGA project I am aware of: > http://web.archive.org/web/20041208022906/http://www.gospl.org/fpl/static/aboutgospl.jsp > Sadly they gave up in early 2005.Interesting. Now I do get the impression that open-source hardware (and related issues) is something that just now has started to become of age. (perhaps opensparc was also years to soon). Appart from the icestorm tool, I now found this project: Trollstigen https://www.youtube.com/watch?v=zMZqzXfjOko Also here: https://www.youtube.com/watch?v=04SWPT4d9Ls I think it's interesting in two ways: - it's really a open-source fpga design so it proves in principe that this can be done. - it seams to be based on a different flow: VTR (verilog to routing, https://verilogtorouting.org/) on which they added their own bitstream-generator Now, i am far being an expert in fpga expert (hence all my questions here :-) ) but from what I understand about it, this means there are two options on the table: - completely open-source: open-source fpga hardware + open-source tools - closed-source fpga hardware + open-source tools (except for the bitstream generator, which would then be closed source). I am correct, the actual knowledge of the internals of the FPGA is in the bitstream generator, so if a company does not want to expose that information, it would be enough to use a closed-source tool for that. Well free to correct me if I am wrong.> -- JecelCheerio! Kr. Bonne.
Reply by ●February 25, 20172017-02-25
On 2/25/2017 4:39 AM, kristoff wrote:> Hi Jecel, Rickman, Jon, Johann, ... all > > > > > On 24-02-17 18:23, Jecel wrote: >> In 2004 ST started the most serious Open FPGA project I am aware of: >> http://web.archive.org/web/20041208022906/http://www.gospl.org/fpl/static/aboutgospl.jsp >> >> Sadly they gave up in early 2005. > > Interesting. > > > Now I do get the impression that open-source hardware (and related > issues) is something that just now has started to become of age. > (perhaps opensparc was also years to soon). > > > Appart from the icestorm tool, I now found this project: Trollstigen > https://www.youtube.com/watch?v=zMZqzXfjOko > > Also here: > https://www.youtube.com/watch?v=04SWPT4d9Ls > > > I think it's interesting in two ways: > > - it's really a open-source fpga design so it proves in principe that > this can be done. > > - it seams to be based on a different flow: VTR (verilog to routing, > https://verilogtorouting.org/) on which they added their own > bitstream-generator > > Now, i am far being an expert in fpga expert (hence all my questions > here :-) ) but from what I understand about it, this means there are two > options on the table: > - completely open-source: open-source fpga hardware + open-source tools > - closed-source fpga hardware + open-source tools (except for the > bitstream generator, which would then be closed source). > > I am correct, the actual knowledge of the internals of the FPGA is in > the bitstream generator, so if a company does not want to expose that > information, it would be enough to use a closed-source tool for that. > > Well free to correct me if I am wrong.A company can *try* to keep their chip design info closed, but if a bunch of amateurs can reverse engineer one company's devices, it shouldn't be too hard to reverse engineer them all. It is a matter of time and the need. To date no commercial effort has needed to reverse engineer FPGA bitstreams. But a bunch of amateurs showed it could be done. The trouble with open source hardware is that having one made is not inexpensive. For board level items it is not terribly practical unless it is a niche item you just can't find elsewhere. For chip level devices personal manufacturing is prohibitively expensive. Even decades old technology is not cheap to have a minimum run made. Ask Green Arrays. -- Rick C
