4 ms·

I am OP You are correct some of the information required to build a computer for these chips are 'internal' details. However they already have strict patents o

I am OP You are correct some of the information required to build a computer for these chips are 'internal' details. However they already have strict patents on most of it, and knowing the configuration bits of a chip and the the delay of various paths is not going to give away their fabrication technique. They could potentially release just enough details to satisfy compiler writers instead of making us do it ourselves so we try to rip every details out of it.

bravo22 11y ago
Often times there are clever optimizations and work around that have to be implemented to work around internal limitations that they don't publish so as not to give their competitor marketing advantages. What we should be pushing for are cross platform tool. Being open-source isn't something that I necessarily would care about as an EE in this particular case. It doesn't get me anything I don't with vendor tools. The BIGGEST thing in FPGA/ASIC design is certainty. Error in the tool costs me time and money. You'll find it difficult to convince anyone to a tool that isn't supported by the vendor because errors and bugs, in the tool or the tool data, won't get resolved quickly. Most of the money in ASIC/FPGA is spent on "verification" either as pre-build/pre-tested cores or as tools that do verification, such as formal logic tools.
- diamondman 11y ago
  Hmm, that is a way I did not think about. Documenting hardware limitations for compilers gives competitors leverage for saying theirs is better because it does not suffer from X. I understand that open source is not particularly important to you, but I am a bit more skeptical about the verifiability of a product that is all secret sauce and promises than I am about something with open check-able code and test suites. Open source software very rarely tries to hide its flaws to prevent a PR issue and then lazily fixed in the future because it is 'low priority', instead they are fixed by whoever can, verified, etc. There are always counter examples, but I thing the verifiability of the tool is in the same world and of similar importance to the verifiability of the output. You do make a point in the catastrophic cost of a screw up when casting an ASIC though.
  - bravo22 11y ago
    FPGA/ASIC interchangeable for the purpose of verification. There are two types of verification: A) does the post synthesis gate match my RTL B) Does my RTL do what I want it to do, i.e. matches the spec. For B you have a whole host of third party IP, verification library, assertions, etc. that you can use For A there are formal verification tools. They mathematically match A to B. There is no need for that tool or anything in the chain to be open. Synthesis is complex and an optimized synthesis is very important. Timing closure is where a lot of this stuff comes to the forefront and that's the part that vendors won't release. That's their secret of what sucks in their chip, or what workarounds they have to use. You'll pry it from their dead cold hands. As an engineer I don't care about their secret. I care about making sure that I don't have to chase down a synthesis bug and that their compiler gives me the most optimized, fast design. Synplify used to be a third party product that did FPGA synthesis (Synopsys bought them). They discontinued it, even though though they had full specs/details from Xilinx/Altera. The main reason is Xilinx/Altera tools are excellent. They know their chips better than anyone and for marketing purposes it is in their interests to give you the tool that does the fastest design, or smallest design. Otherwise you would switch to their competitor. I love the idea of what OP is trying to do but it is a solution in search of a problem. There is a bigger problem that an open source tool could solve and that is Verilog simulation. Currently we have Icarus Verilog but someone should improve it and add SystemVerilog support. Simulation is much easier to solve, since there is a spec to design against, and has many more users. There aren't good, inexpensive simulation tools. Simulation is as important as compilers. Imagine a world where gcc didn't exist and you had to pay to get a good compiler. People will always stick to the big vendor for synthesis. I can't imagine a day that they wouldn't.
    - diamondman 11y ago
      OP here You are right that my particular project is not the biggest piece, but it is the part that pisses me off. I can deal with Xilinx's crappy compiler if I can program my chips with ease..... or maybe I should say UNTIL I can program my chips with ease. Then my focus will change hehe. Icarus works but it has been maintained by one 'eccentric' guy for quite a while and the code base is semi unapproachable. I believe this is why the Yosys guys started from scratch. You are also right that the place and route, as well as verification of the LAYOUT in the chip are super big problems. It is in fact what my friends toying with the compiler side are dreading dealing with because we have no idea the delays of individual traces in the chip. I disagree that people will stick with the vendors tools. Open compilers dominate most of the Intel CPU market besides on windows since Visual Studio is the only thing that deals with all the quirks reasonably well. But the windows case is more of a lack of interest. ARM compilers are more interesting to me because most people use Keil. Keil... works. But it feels crazy retro paying for a compiler. I believe the only reason that Keil is being used for most embedded ARM projects is there simply are not enough people with compiler knowledge using ARM regularly yet to pour enough work to make a better alternative. But it will come. And one day we will have synthesis tools for FPGAs that are comparable to the big guys or better.
goodcanadian 11y ago
You are not wrong, and I think the first company to support open tools would gain a competitive advantage . . . I know I would give them my business. They could release some details, but they won't. They perceive it to not be in their interest. They are probably wrong about that, but that is the way they perceive it.

bravo22 11y ago

Often times there are clever optimizations and work around that have to be implemented to work around internal limitations that they don't publish so as not to give their competitor marketing advantages. What we should be pushing for are cross platform tool. Being open-source isn't something that I necessarily would care about as an EE in this particular case. It doesn't get me anything I don't with vendor tools. The BIGGEST thing in FPGA/ASIC design is certainty. Error in the tool costs me time and money. You'll find it difficult to convince anyone to a tool that isn't supported by the vendor because errors and bugs, in the tool or the tool data, won't get resolved quickly. Most of the money in ASIC/FPGA is spent on "verification" either as pre-build/pre-tested cores or as tools that do verification, such as formal logic tools.

diamondman 11y ago
Hmm, that is a way I did not think about. Documenting hardware limitations for compilers gives competitors leverage for saying theirs is better because it does not suffer from X. I understand that open source is not particularly important to you, but I am a bit more skeptical about the verifiability of a product that is all secret sauce and promises than I am about something with open check-able code and test suites. Open source software very rarely tries to hide its flaws to prevent a PR issue and then lazily fixed in the future because it is 'low priority', instead they are fixed by whoever can, verified, etc. There are always counter examples, but I thing the verifiability of the tool is in the same world and of similar importance to the verifiability of the output. You do make a point in the catastrophic cost of a screw up when casting an ASIC though.
- bravo22 11y ago
  FPGA/ASIC interchangeable for the purpose of verification. There are two types of verification: A) does the post synthesis gate match my RTL B) Does my RTL do what I want it to do, i.e. matches the spec. For B you have a whole host of third party IP, verification library, assertions, etc. that you can use For A there are formal verification tools. They mathematically match A to B. There is no need for that tool or anything in the chain to be open. Synthesis is complex and an optimized synthesis is very important. Timing closure is where a lot of this stuff comes to the forefront and that's the part that vendors won't release. That's their secret of what sucks in their chip, or what workarounds they have to use. You'll pry it from their dead cold hands. As an engineer I don't care about their secret. I care about making sure that I don't have to chase down a synthesis bug and that their compiler gives me the most optimized, fast design. Synplify used to be a third party product that did FPGA synthesis (Synopsys bought them). They discontinued it, even though though they had full specs/details from Xilinx/Altera. The main reason is Xilinx/Altera tools are excellent. They know their chips better than anyone and for marketing purposes it is in their interests to give you the tool that does the fastest design, or smallest design. Otherwise you would switch to their competitor. I love the idea of what OP is trying to do but it is a solution in search of a problem. There is a bigger problem that an open source tool could solve and that is Verilog simulation. Currently we have Icarus Verilog but someone should improve it and add SystemVerilog support. Simulation is much easier to solve, since there is a spec to design against, and has many more users. There aren't good, inexpensive simulation tools. Simulation is as important as compilers. Imagine a world where gcc didn't exist and you had to pay to get a good compiler. People will always stick to the big vendor for synthesis. I can't imagine a day that they wouldn't.
  - diamondman 11y ago
    OP here You are right that my particular project is not the biggest piece, but it is the part that pisses me off. I can deal with Xilinx's crappy compiler if I can program my chips with ease..... or maybe I should say UNTIL I can program my chips with ease. Then my focus will change hehe. Icarus works but it has been maintained by one 'eccentric' guy for quite a while and the code base is semi unapproachable. I believe this is why the Yosys guys started from scratch. You are also right that the place and route, as well as verification of the LAYOUT in the chip are super big problems. It is in fact what my friends toying with the compiler side are dreading dealing with because we have no idea the delays of individual traces in the chip. I disagree that people will stick with the vendors tools. Open compilers dominate most of the Intel CPU market besides on windows since Visual Studio is the only thing that deals with all the quirks reasonably well. But the windows case is more of a lack of interest. ARM compilers are more interesting to me because most people use Keil. Keil... works. But it feels crazy retro paying for a compiler. I believe the only reason that Keil is being used for most embedded ARM projects is there simply are not enough people with compiler knowledge using ARM regularly yet to pour enough work to make a better alternative. But it will come. And one day we will have synthesis tools for FPGAs that are comparable to the big guys or better.

goodcanadian 11y ago

You are not wrong, and I think the first company to support open tools would gain a competitive advantage . . . I know I would give them my business. They could release some details, but they won't. They perceive it to not be in their interest. They are probably wrong about that, but that is the way they perceive it.