Linked by Thom Holwerda on Thu 2nd Mar 2006 12:24 UTC, submitted by Timothy Miller
Permalink for comment 101117
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
More News »
Sponsored Links



Member since:
2006-03-02
I have considered making the PCI core GPL rather than LGPL. This way, if you use it under GPL, you have to open source your entire design. If you don't want that, you can buy a commercial license. I'm pondering it, and I have mentioned it on OGML.
I did a PCI 64/66 design on an ASIC back in 2000. This ASIC was slower than the FPGA we're using here. On top of that, I've gotten better as a chip designer. I think 133MHz is probably doable. If not, it'll make it just fine in the ASIC, where that speed is important for the PCIe-to-PCIX bridge.
It's important to minimize your internal combinatorial delays. Often a harder problem is keeping your external I/O's fast. If it all possible, always use the register in the I/O buffer. The Opencores PCI design separates the PCI target and master logic and then multiplexes that together at the I/O buffers (it looks like to me from the diagrams). I've decided to merge the master and target state machines so that they implicitly share the I/O's, so we can always use the registers in the I/O buffers for output. I've played other tricks to ensure that inputs are handled well also.