On 10/22/05, Sebastien & Cathy <[EMAIL PROTECTED]> wrote: > Hello, > > Thanks everybody for welcoming me. > > Tim: > > > There is some architecture done, but it doesn't apply to the PCI core. > I can give you a general idea of what I'm going for, but what I've > been trying to do lately is formally define the architecture of the > Lattice portion of OGD and diagram it out in detail. We just haven't > yet chosen a tool for representing it. > > I've read your article in kerneltrap. Regarding the PCI-X core. Why are you > using a 32-bit interface? A 64-bit PCI-X card fits in a 32-bit connector. I > think, we can design the interface able to switch from 64 to 32 bit if > required.
I've done that before, and it's pain. I had to deal with three different sets of states: (1) 64-bit transaction on 64-bit bus, (2) 32-bit transaction on 64-bit bus, and (3) 32-bit transaction on 32-bit bus. Instead of hard-coding the state numbers and output signals, I had to register them for whichever mode I was in. (When on a 32-bit bus, it's very important to drive the 64-bit extension to constant levels so as to prevent oscillation of an input buffer not connected to anything, and the spec does not allow for external pull-downs.) > Are you using some verilog code from www.opencores.org? I think they have a > fully functionnal PCI core and some other interesting IPs... I. Hate. Wishbone. Wishbone is not designed for speed or throughput. When you implement a wishbone device, either you end up with a lot of asynchronous logic, limiting your clock rate, or you have to transfer data every other clock. I decided that since I had designed a PCI controller before, I would be better off starting over than trying to spend all the time necessary to rewrite their core. Their PCI core isn't designed for high clock rates. Another reason I started on my own design was because I had planned to merge the PCI and AGP state machines (because they would share pins). Since then, people have suggested that I skip AGP and go directly to PCI-Express. The jury is still out on that, but in the mean time, I want to finish the PCI core. It's really just a PCI/66 core that I figured I would hack later to make it deal with 133 and possibly even 266MHz. > If you could help with that part, it would be great. We can review > its present design and go over the needs. After diagramming it out, > we could even split the work. At the very least, if you can help me > architect it, I can code it more efficiently. > > > Ok. I'm ready to help but I don't know where to get the info from. As I > said, I have some experience in PCI but I may be helpful in any other > digital part of the project. > What do you want me to review? There are discussions on the list, but they might be hard to find in the archives. I figured we'd just discuss it on the list and diagram it as we go. > > > > 2. There is not much verilog in the database. Does that represent the > current status of the project? > > > > Of OGD, yes. OGA has the GPU defined in detail, but it's not in Verilog. > > Anything you can show me about the GPU? in which language is it written? > Do you have a schematic of the board? Andy's working on the schematic. I haven't checked on his status in a while. As for the GPU, what we have is a model of it in C++. That just represents the math, pipeline, and register set. There is an old version of it that is copyrighted by Tech Source, which is in the repository. Traversal needs one where the copyright is held by Traversal, so I had Andy, who had never before seen the original model, develop a new one from scratch. I just need to finish the licensing stuff and check it in. > > > 3. Is there an #IRC channel? > > Yeah. Freenode.net, #opengraphics, IIRC. > > Do you connect often? Not in a while. > > > A plus tard. > > A bien tot. :) > > (I forget what that means. I hope it means something good.) > > Means the same. Good shot. > > > Thank you for joining us. > > > > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
