111–120 of 125 posts
About @diamondman's Adapt Framework (github.com/diamondman/adapt) Adapt is an open, modular framework which offers a streamlined approach for JTAG controllers to speak to target devices (currently CPLDs and soon fpgas). Adapt is built to be extensible and currently includes open/reversed drivers for the following Controllers and target devices: - Digilent & Xilinx PC1 (JTag Controllers) & XC2C-256 (CPLD)* *Note: Map…
Earlier quoted context omitted.
> Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. Could you provide further details?
http://www.xilinx.com/support/documentation/data_sheets/3000... is the data sheet. I used to have the programming and layout specs doc they gave out.
About @diamondman's Adapt Framework (github.com/diamondman/adapt) Adapt is an open, modular framework which offers a streamlined approach for JTAG controllers to speak to target devices (currently CPLDs and soon fpgas). Adapt is built to be extensible and currently includes open/reversed drivers for the following Controllers and target devices: - Digilent & Xilinx PC1 (JTag Controllers) & XC2C-256 (CPLD)* *Note: Map…
So why aren't these targets for OpenOCD instead of a new system?
"I actually want to hook OpenOCD into my Daemon to bring some sanity to how it manages devices. Several of my IRC friends prefer using closed source tools to open OCD calling open Obsessive Compulsive Disorder, frustrated the license is so strict (mine will be LGPL), and annoyed that everything has to be exhaustively specified in TCL files for it to do ANYTHING."
The TL;DR is OpenOCD's driver model itself is fixed/limited/standardized to a degree which prevented him from, in many cases, optimizing underlying controllers (or getting them to work at all -- e.g. OpenJTag, I believe). Also, see licensing disagreements above + unreasonable configuration requirements outlined in @diamondman's answer above.
Earlier quoted context omitted.
When you say 'good, efficient software' i wonder if you are talking about Xilinx ISE/Vivado, or any of the tools from their competitors. I can not imagine you are.
Have you noticed anybody else with better software and chips ? no ? maybe because it's extremely hard to to get to the level of ISE and the competitors ?
Earlier quoted context omitted.
But in how far didn't it do well for Xilinx?
Well the guy I know who used to be in charge of strategic marketing for Xilinx shared that it had not met sales projections and support costs were higher (which cut into margin) when people were trying to program the things with their own tools. So sharing all that stuff about the chip alienated some big customers, reduced profit margins, and didn't help volumes. That pretty much defines 'fail' in the chip business.
Earlier quoted context omitted.
>> They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass produced to under cut them. So how does having a closed tool chain achieve that? Aren't the FPGAs programmed either on the line, or from ROM at power up? Either way, board producers should be able to replicate the product. How does being closed help?
> So how does having a closed tool chain achieve that? It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though…
Earlier quoted context omitted.
> So how does having a closed tool chain achieve that? It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though…
This feels like circular logic to me. We do not want the hardware companies spending time 'open sourcing' their docs because they need to spend that time and money 'making more features' which they wouldn't have to do alone if it was open, but we can't have it open because spending the time and money 'open sourcing' their docs...... I think there is a big difference between 'users wanting tools to be closed source' a…
Well, that's an assumption. User base is very small, and potential contributors base is even smaller. So that would be a big bet hoping that someone would contribute to make it worthwhile.
However, your statement is true when it comes to more mainstream technologies like ruby or javascript.
Having done my graduate studies in FPGA architecture and software, I can definitely see where the author is coming from. In fact, it seems like the entire hardware development industry has to face the issue of most tools being closed-source. Although I don’t have a solution for the technology specific phases (Place and Route, Bit Stream Generation, etc.), I am actually part of a company that is trying to help solve t…
Earlier quoted context omitted.
If there's so much value there, how are these companies stopping internal espionage? If a company wanted to see what their competitors were doing to gain a large advantage, they could certainly field a candidate to work as an agent for their competitor. It sounds like how Nikon doesn't document the NEF format and pretends their binaries are the only way to decode such files. Except obviously the secrets these hardwar…
From what I've read of internal leaks, the leakers get caught and charged and dealt with, which discourages other leakers perhaps. But there isn't anything stopping an employee from selling or stealing company secrets. That hasn't changed. But during the 70's and 80's a lot of manufacturers stopped printing schematics in response to clones appearing which used a circuit that was close (but not exactly like) theirs an…
Earlier quoted context omitted.
This feels like circular logic to me. We do not want the hardware companies spending time 'open sourcing' their docs because they need to spend that time and money 'making more features' which they wouldn't have to do alone if it was open, but we can't have it open because spending the time and money 'open sourcing' their docs...... I think there is a big difference between 'users wanting tools to be closed source' a…
>>> which they wouldn't have to do alone if it was open Well, that's an assumption. User base is very small, and potential contributors base is even smaller. So that would be a big bet hoping that someone would contribute to make it worthwhile. However, your statement is true when it comes to more mainstream technologies like ruby or javascript.