That'll be great. There's not a lot left for me to do before just the PCI part can be tested.
On 10/31/05, Sebastien & Cathy <[EMAIL PROTECTED]> wrote: > Hello Tim, > > I'll have a look to the mail archives. > As far as the PCI is concerned, I think I can help you with the > testbenches. Once I know more about the project, I can develop R/W > tasks,... I'll keep you updated with ideas about the testbench. > > > Sebastien > > Timothy Miller wrote: > > >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. > >> > >> > >> > >> > >> > >> > > > > > > > > > > -- > --Seb > http://tetsuo3.free.fr/ > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
