> But is *is* like writing C per-ANSI, when every compiler had its own variant.pre-ANSI The churn in language revisions isn't helping either
Phrasing!
Started by ●November 19, 2016
Reply by ●December 1, 20162016-12-01
Reply by ●December 2, 20162016-12-02
On 26/11/16 05:57, rickman wrote:> On 11/25/2016 4:26 PM, Tim Wescott wrote: >> >> Reading this whole thread, I'm reminded of a gripe I have about the FPGA >> manufacturers, or at least Xilinx and Altera. >> >> If they -- or just any one of them -- would PUBLISH the details of how >> their bitfiles map to the workings of their FPGAs, then all of a sudden >> that company's stuff would be the subject of all the intensive university >> research on FPGA optimization that you might desire, and possibly even >> see an open-source tools ecology grow around its parts. >> >> It wouldn't immediately lead to nirvana, but it may at least lead to more >> and better optimization, and lots of people experimenting with different >> optimization approaches. > > Let's say I am Xilinx... I have a bazillion dollars of investment into > my products and the support software. I sell to large companies who > want reliable, consistent products. I open up my chip design and a > bunch of university idealists start creating tools for my devices. The > tools work to varying degrees and are used for a number of different > designs by a wide variety of groups. > > So what happens when some of these groups report problems "with the > chips"? Are these problems really with the chips or with the tools? If > any of these groups ask us to deal with these problems, how do we begin? > > In other words, how do we keep these tools from causing problems with > our reputation? >This is a point, although a weak one. The same should also happen to the microcontroller industry... but does not. They are quite happy selling chips that are being programmed by the open-sourced gcc toolchain. Pere
Reply by ●December 2, 20162016-12-02
On Friday, December 2, 2016 at 3:10:19 AM UTC-5, o pere o wrote:> > This is a point, although a weak one. The same should also happen to the > microcontroller industry... but does not. They are quite happy selling > chips that are being programmed by the open-sourced gcc toolchain. >Also consider that on the gcc side of things that they have a lot of people who know how to write software that are writing and developing the gcc software. There aren't nearly as many people who know how to write software working on software stuff for hardware like FPGAs. Witness that we don't have much of anything other than GHDL as a basic simulator. Development on that is up to the whims of one person who chooses to work on it (or not in which case everything stops...as it has of late). It wouldn't surprise me if FPGA companies probably consider that the open source community would take forever to develop anything. Kevin
Reply by ●December 2, 20162016-12-02
On 12/2/2016 3:10 AM, o pere o wrote:> On 26/11/16 05:57, rickman wrote: >> On 11/25/2016 4:26 PM, Tim Wescott wrote: >>> >>> Reading this whole thread, I'm reminded of a gripe I have about the FPGA >>> manufacturers, or at least Xilinx and Altera. >>> >>> If they -- or just any one of them -- would PUBLISH the details of how >>> their bitfiles map to the workings of their FPGAs, then all of a sudden >>> that company's stuff would be the subject of all the intensive >>> university >>> research on FPGA optimization that you might desire, and possibly even >>> see an open-source tools ecology grow around its parts. >>> >>> It wouldn't immediately lead to nirvana, but it may at least lead to >>> more >>> and better optimization, and lots of people experimenting with different >>> optimization approaches. >> >> Let's say I am Xilinx... I have a bazillion dollars of investment into >> my products and the support software. I sell to large companies who >> want reliable, consistent products. I open up my chip design and a >> bunch of university idealists start creating tools for my devices. The >> tools work to varying degrees and are used for a number of different >> designs by a wide variety of groups. >> >> So what happens when some of these groups report problems "with the >> chips"? Are these problems really with the chips or with the tools? If >> any of these groups ask us to deal with these problems, how do we begin? >> >> In other words, how do we keep these tools from causing problems with >> our reputation? >> > > This is a point, although a weak one. The same should also happen to the > microcontroller industry... but does not. They are quite happy selling > chips that are being programmed by the open-sourced gcc toolchain.I think this is apples and oranges. It is easy to look at the output of a compiler and see what it is doing. The details of the configuration file for an FPGA is not so easy to analyze. Also, the configuration bit stream isn't just a matter of telling the chip what to do, it can set up internal conflicts that can damage the chip. Even if the FPGA vendors release their technical info on the configuration bit stream, it is a very complex thing to deal with. -- Rick C
Reply by ●December 2, 20162016-12-02
o pere o <me@somewhere.net> wrote:> This is a point, although a weak one. The same should also happen to the > microcontroller industry... but does not. They are quite happy selling > chips that are being programmed by the open-sourced gcc toolchain.An ISA is an API. A lot of work goes on implementing the microarchitecture which implements the API, either in hardware or software (microcode). Another lot of work goes on proving that the implementation matches the API and is bug-free (and 'halt and catch fire' is definitely a bug). FPGA silicon doesn't have an API, you just have the raw transistors to control. The main safeguards to prevent them generating flame-inducing configurations (or more prosaically customer returns) are in the tools. You can put an API on top of an FPGA (eg as the 'FPGA virtualisation' folks do) but the performance and flexibility impact is substantial. As far as I'm aware of the current state of FPGA virtualisation (admittedly not that much), there's nothing there that would be usable in a product anytime soon. Theo
Reply by ●December 2, 20162016-12-02
On Friday, November 25, 2016 at 4:26:11 PM UTC-5, Tim Wescott wrote:> > If they -- or just any one of them -- would PUBLISH the details of how > their bitfiles map to the workings of their FPGAs, then all of a sudden > that company's stuff would be the subject of all the intensive university > research on FPGA optimization that you might desire, and possibly even > see an open-source tools ecology grow around its parts. >I kind of doubt that would happen. I don't think there are enough hardware knowledgeable folks who can write good software. If there were, we would all be simulating with some open source VHDL+Verilog simulator that puts Modelsim and Aldec to shame [1]. But instead most people I think are using Modelsim/Aldec or some lame simulator that comes bundled with the tools. Since there apparently aren't many folks diving in to develop something that would benefit many with a decent simulator, why would you think there would be enough to dive in and help develop something that benefits a subset of that market? Open source developers tend to use their tools in their day to day work as well. Those developers 'only' need to be good at developing software in order to develop open source stuff. When you talk about open source tools to be used for hardware development, you would want to have someone good at developing hardware and software so that the tools they develop they would then use day to day. If nothing else, there are fewer of those folks that have both skills and, based on the lack of developers for open source simulators, I think there just isn't the critical mass. Manufacturers keeping their details secret could be seen as nothing more than their seeing that there aren't enough people out there who could even develop what is needed in an open source scenario. So they pay people to develop what they need.> It wouldn't immediately lead to nirvana, but it may at least lead to more > and better optimization, and lots of people experimenting with different > optimization approaches. >I know you're not holding your breath waiting for that nirvana...but I'd wager that you will have taken your last breath long before such nirvana was reached. Kevin Jennings [1] Yes I know about GHDL and it is and appears to have always been a one man band. The original band member left the band and years later someone else picked it up. Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015, nothing new in about 12 months and counting. It is still not up to release 1.0 and there will be another revision to the VHDL standard in 2017. One person can only do so much...in addition to doing something that puts food on the table.
Reply by ●December 2, 20162016-12-02
On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote:> > [1] Yes I know about GHDL <snip> > Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015, > nothing new in about 12 months and counting. >Tristan moved the development to GitHub: https://github.com/tgingold/ghdl/releases -Brian
Reply by ●December 2, 20162016-12-02
On Friday, December 2, 2016 at 7:28:42 PM UTC-5, Brian Davis wrote:> On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote: > > > > [1] Yes I know about GHDL <snip> > > Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015, > > nothing new in about 12 months and counting. > > > Tristan moved the development to GitHub: > https://github.com/tgingold/ghdl/releasesThat's good to hear, now you need to let Google in on the secret. I do see there is mention of the move to Github on the summary page on SourceForge page, but maybe you should consider pulling all the old stuff down from SourceForge and put some more redirection links to the new home. Kevin Jennings
Reply by ●December 2, 20162016-12-02
> I kind of doubt that would happen. I don't think there are enough hardware knowledgeable folks who can write good software. If there were, we would all be simulating with some open source VHDL+Verilog simulator that puts Modelsim and Aldec to shame [1]. But instead most people I think are using Modelsim/Aldec or some lame simulator that comes bundled with the tools.I agree. It doesn't seem likely that there would be a lot of people versed in low-level silicon design and high-level software and who would also be willing to put in a lot of time for free. I don't suppose there is anything stopping somebody from making a synthesizer--you can just convert RTL into structural HDL containing primitives--but I don't see a lot of free synthesizers around.
Reply by ●December 3, 20162016-12-03
On Fri, 2 Dec 2016 03:32:16 -0800 (PST) KJ <kkjennings@sbcglobal.net> wrote:> Also consider that on the gcc side of things that they have a > lot of people who know how to write software that are writing > and developing the gcc software. There aren't nearly as many > people who know how to write software working on software > stuff for hardware like FPGAs. Witness that we don't have > much of anything other than GHDL as a basic simulator. > Development on that is up to the whims of one person who > chooses to work on it (or not in which case everything > stops...as it has of late).The MyHDL community is vibrant [1], and this fast[2] simulator exports Verilog and VHDL for synthesis.> It wouldn't surprise me if FPGA companies probably consider > that the open source community would take forever to develop > anything.I'm using open source tools [3]. As for community, there are many users, not sure about developers, maybe clues here [4]. Clifford did/does warn about frying chips, but the value of the project far exceeds the cost of a few sacrificial ICs. Jan Coombs -- [1] http://myhdl.org/ [2] http://myhdl.org/docs/performance.html [3] http://www.clifford.at/icestorm/ [4] https://www.reddit.com/r/yosys/comments/4ocilz/icestorm_adding_support_for_new_devices_part_1/
