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.
