<dbj314>
How do you interface a ATF15xxAS chip to a PCI bus? The ATF1502AS(L) datasheet has a "PCI Compliance" section, where it claims that it can interface to a PCI bus if you "parallel outputs" (connect multiple pins together?). But then it doesn't state how many pins you need to connect together to make things work. I lack the knowledge necessary to
<dbj314>
figure this out from the datasheet. The "PCI Compliance" section gives "AC Characteristics" requirements in milliamps. The "Electrical Characteristics" section tells you a bunch of "AC Characteristics", but only gives units in nanoseconds and megahertz. I have no way of knowing how easy or hard this question is to answer, but I sure hope it is
<dbj314>
simply a matter of looking up notes that were already made in the process of reverse-engineering this chip family.
whitequark[cis] has joined #prjbureau
<whitequark[cis]>
I think there are entire careers dedicated to being PCI consultants
<whitequark[cis]>
and many books written on the topic
dbj314 has quit [Quit: Client closed]
dbj314 has joined #prjbureau
<dbj314>
You are talking to a random college student, who is considering a project that, except for a few key details, might actually be possible to fumble through with their near-nonexistent skills. (The basic idea is: if I can successfully drive and listen to the PCI bus, and handle a few things like parity generation and command decoding that are
<dbj314>
slightly too complicated, I can feed everything else into a RP2350 PIO block and handle things there). So yeah, my knowledge and ability to think things through are terrible (along with ettiquete too, probably. This is the second time I have ever used IRC for anything, and the first barely counted). So I mainly just want to know how much current
<dbj314>
the pins output when shifting, so I can compare it to the i/v curve PCI requires and find out how many pins I need to use at once. And I did hope that this is so trivial I don't need to pay people to find out (though I might be able to do that if its really needed? I have a PayPal account...)
<whitequark[cis]>
re IRC, you're fine (we also have a Matrix channel if you're up for something more modern but kind of worse)
<whitequark[cis]>
re PCI... PCI kind of scares me to be honest. I think I could probably get it working but, hm
<whitequark[cis]>
you know PCI Express?
<whitequark[cis]>
PCI Express is way, way faster, but despite that it's actually conceptually a lot simpler, even if the chips require a more complicated process to produce, and were harder to initially design
<whitequark[cis]>
PCI Express is a simple bus that uses like one or two complex blocks that you can copy&paste all over almost mindlessly. this is why basically every interface around is carcinizing into PCI Express (NVMe, SD Express, SATA Express, CF Express, XQD, the list goes on after that)
<whitequark[cis]>
PCI, however, is a much slower bus that is more complex. it is slower *because* it is more complex: in an effort to make it cheap, we pushed the envelope of the technology in many places, and you can really tell this by looking at any part of the system. some old FPGAs have dedicated hard logic for the sole purpose of supporting a single PCI feature, because you had to push everything that hard to get it to work
<whitequark[cis]>
and then we couldn't push it further because the amount of moving parts became unbearable and debugging it became intractable
<whitequark[cis]>
well, that's the short story, it's more complex than that
<whitequark[cis]>
because PCI is hopelessly obsolete I never actually looked into it deeper than to admire how complex it is and how thick the books written on it are
<whitequark[cis]>
maybe you'll get it to work in a month. maybe you'll spend four years doing it and not getting it to work. I have no idea!
<whitequark[cis]>
well, have fun
Wanda[cis] has joined #prjbureau
<Wanda[cis]>
I find it fascinating that basically every FPGA and CPLD of the era proudly boasts about its PCI support and the special whatever weirdness they had to do to get it work
<Wanda[cis]>
like the Lattice FPGAs that for some godforsaken reason support PCI only on one of the 4 edges of the device
<dbj314>
There would be no way I could do it if I had to deal with chips that were limited to the same clock speed as PCI. But The RP2350 runs over 4x faster than PCI, and can supposedly be overclocked to twice that. The main terrible feature (at least for working with RPi PIO blocks) is the byte enable lines. I might have to start out treating writes as a
<dbj314>
read, shove the data outside the RPi to whatever buffers there are (probably the inside of a ATF15xx), and then selectively overwrite them with the incoming bytes when needed.
<whitequark[cis]>
4x oversampling is probably fine
<dbj314>
But a whole bunch of stuff can just be ignored if you only let memory accesses be single-beat. That lets you collapse the 4 or so different kinds of memory space reads (and the same number of writes) down to one.
<whitequark[cis]>
yeah that actually sounds like a sound plan to me
<whitequark[cis]>
I imagine the CPLD would be clocked off PCI bus and then phase-shift it a bit to satisfy setup/hold times for Pico?
<dbj314>
The current idea is to exploit the high clock speed to turn the 32-bit PCI bus into a 16-bit bus for Pico, to let a single PIO block transfer data and manipulate control lines at the same time.
<whitequark[cis]>
oh, use the CPLD as a DDR multiplexer?
<dbj314>
(Control lines going to the ATF15xx of course. The PCI control lines still have to be driven by it)
<dbj314>
Yeah probably. I have way more awareness of software than hardware.
<whitequark[cis]>
so I think ATF15xx doesn't have selectable posedge/negedge flops, does it
<whitequark[cis]>
I think you'll need to allocate a product term for the clock
<dbj314>
I had spent several days wondering if there was a hidden "PCI mode" to put the pins into, before eventually realizing that it just wants you to connect several pins together.
<dbj314>
And then I spent a few more days trying to figure out how many pins to stick together.
<Wanda[cis]>
hm
<Wanda[cis]>
do the IOBs have the drive strength documented?
<dbj314>
The datasheet is really unhelpful in that regard.
<dbj314>
"Output Buffer and Pad Delay
<dbj314>
(Slow slew rate = OFF; V CC = 5.0V; C L = 35pF)" having a max of 2 nanoseconds could *maybe* communicate something about drive strength.
<whitequark[cis]>
well you could calculate how much current it takes to charge a 35 pF capacitor to 75% of 5 V, and then find out the driver Rds(on)
<whitequark[cis]>
you're an EECS student or something?
<Wanda[cis]>
oh dear gods it wants how many miliamps
<dbj314>
Nope! CS. I have an old computer hobby
<whitequark[cis]>
PCI is nuts, Wanda
<dbj314>
Yep, it thinks 195 mA is on the upper end of the acceptable side.
<Wanda[cis]>
oh this is the 5V variant we're talking about, too
<dbj314>
Yep
<dbj314>
So you can see why I am worried about either supplying nowhere near enough current, or way too much current.
<whitequark[cis]>
do you know that PCI uses reflected wave signaling?
<whitequark[cis]>
like the motherboard has wires on it and all, but spiritually, the PCI bus is closer to a collection of antennas
<whitequark[cis]>
really, really fucked up antennas
<dbj314>
Yep. Yet another reason I have no idea what I am supposed to do here.
<whitequark[cis]>
oh! I can explain that part
<whitequark[cis]>
in a practical way, it means that your 200 mA buffer doesn't need to (and cannot) swing the entire bus fully one end to another (0 to 5 or the other way around)
<whitequark[cis]>
it only does it halfway, which causes a wave to propagate towards the southbridge and towards the unterminated end. then the latter reflects and adds to the former, switching the input buffers in the process
<whitequark[cis]>
they did it in order to not require 400 mA buffers
<whitequark[cis]>
it also means that your buffers must be able to deal with ... what was it, -5 V to 8.5 V on them?
<whitequark[cis]>
this is a bonkers requirement for any modern tech. nobody does it anymore because it's ridiculous
<dbj314>
The ATF1502AS datasheet seems to think it can handle things if you connect enough pins together, and it has absolute maximum ratings of -2V to 7V.
<dbj314>
Do they need additional components to limit things? Are they just delusional? Or does the buffer only pull things down to 2.5 and the reflected wave brings things down the rest of the way?
<whitequark[cis]>
I think the difference is that the PCI bus is a dynamic environment
<whitequark[cis]>
like, applying static voltage of 8.5V might blow it, but transients within a very narrow envelope are fine... I think
<whitequark[cis]>
well, they're cheap at least
<dbj314>
Though I can definitely see why the PCI spec has there be a "turnaround cycle" when switching control of the bus. Don't want 200 mA buffers to fight.
<whitequark[cis]>
turnaround cycles are normal on ~any bidirectional bus