kc5tja wrote:
Quote:
SDIO is part of the Secure Digital standard. Apparently the SD Association has finally realized that people hate paying for standards, so they are posting "simplified" versions of it. The SD interface is a 9-pin bus that you can either talk to it via SPI, a 1-bit mode or a 4-bit mode.
I've looked at the SDIO standard (at least what I could find of it) briefly before screaming into work, and, . . . I don't really think that I would call it "simple." Yeah, the hardware seems simple (I still don't see how the hardware can automatically detect SPI, 1-bit, or 4-bit modes though), but then there's all sorts of other hidden gotchas in the standard. There are multiple address spaces you need to be aware of, and so forth. And the command list makes PCI's command list pale in comparison.
That implies that the SDIO device would require local intelligence, which pretty much means I might as well just use something like an IEEE-488 bus or something.
My goal is to make a capable, future-proof, yet minimal bus system that people can readily hack without requiring post-doctorates to design even the simplest of parallel port interfaces. I do not want it tied to any one special interest group (try downloading the PCI 3.0 specs from the PCI SIG -- won't happen unless you are a member, paid in full). Ideally, the bus interface would be licensed LGPL.
Ah, see, software doesn't faze me, but hardware does.
The standard is based on the MMC standard. So the "missing piece" is the SD standard, which they don't seem to have put a "simple" version that doesn't have DRM info that they don't want to talk about.
Maybe I should just say, "Hey, put a SPI bus on the Kestrel, even if you don't use it as the main bus." Because, as long as somebody writes a driver, you can hang AVR microcontrollers, MMC cards, SD cards, and SDIO peripherals off of it.
Or maybe I'm compensating for a decided lack of experience building electronics with my decided wealth of software building experience.
kc5tja wrote:
Quote:
asynchronous and can be clocked at any speed under 25 MHz. The only quirk is that it's a 3.3v standard.
To nitpick: anything that depends on a clock, regardless of its speed, is synchronous by definition.
SDIO is quite synchronous in this nature. It just happens to be rather flexible in what speeds it runs at.
Hah! Yeah, I bungled that.
kc5tja wrote:
Quote:
Remember, my views are colored by what I think would be useful. What I have in mind as my personal project is very different from the Kestrel, the main things in common being that I want it to be useful and use the 65816.
I want a bus interface that can satisfy the needs of a large number of hackers. I don't want to spend all my time hacking and re-hacking the Kestrel to support something new that I or someone else wants to support.
Make the bus best suited to the Kestrel and then make a PCI mezanine interface?
kc5tja wrote:
Quote:
One mental picture I had was to treat each side of the bus as an addressable bidirectional latch, with an 8 bit wide bus. Thus, you could have a pseudo-burst mode just by changing only the lowest word of the address latch and the data latch and still make it possible to do a peripheral without too much work. And the "I can't be bothered to think about timings" version of a peripheral would be a row of latches, a comparator for decoding, and a counter to make all accesses happen at 1 MHz.
This really doesn't make any sense to me. Can you elaborate a bit?
It could make no sense in general, for all I know. Remember, I software dude who dabbles in hardware. I connect power to ground and ground to power and let the magic smoke out.
So, we've got 8 bidirectional data lines. We have 3 bits on the side for the "latch address", the write transaction line, the read transaction line, the transaction complete line, plus whatever other extra signaling and contention lines are needed.
So the transaction goes as follows.
Write : Latches 0-3 are the address latches. So we set the "latch address" to 0, put the first byte on the latch and repeat until all 32 bits of the address are entered into the latch. We write the lower 8 bits of the address bus to latch 7. (latches 4,5,6 are left for future expansion). Then, once all 5 bytes are latched, signal that the transaction is complete on the write line. We can stream-ahead and wait until we've got another transaction pending, or we can just halt the processor until the device signals for transaction complete.
Burst write: We're only going up by one. So we only change the value in latch 0 and latch 7, then signal the write line again.
Read: We latch the address into latches 0-3, signal on the read line. Halt the processor until the transaction complete line kicks in and we can latch the read buffer.
Burst read: We only change the value in latch 0 and then signal the read line, synch as before.
So, at burst mode, you have 1 bye transfered every other clock cycle. Sure, you could have a transfer every cycle, but then you have to use a counter or an adder, not a latch. Latches are available in all kinds of fast low-voltage CMOS 74xx parts and counters aren't.
The highlight here is that the simple device without bus mastering is pretty simple. With 6 tri-state latches, a 3to8 decoder, and some misc logic, you have everything you need for a simple peripheral. (Yes, I'll call that a "few" pieces of 74xx logic. But then again, my definition of the words "Couple" and "Few" seem to match nobody's
) You end up with a local address bus, a local data bus, and a write and read strobe. Add some driver logic that just delays, by default, the transaction complete logic, everything down to 1 MHz, you have something that just about anybody who understands the basics of electronics and is lazy can do something with because all of the hard stuff is in whatever's driving the bus. And it's even not too hard to do a vaugely inefficent driver that always does all 4 address lines.
Mostly it's just a weird variant on your "bus command" thing. And for all I know, it's a really really dumb idea and I'll be forever known as He Who Can't Design A Bus Worth A Crap.
kc5tja wrote:
Yes, that was part of the original I/O bus concept (32K of I/O space, supporting 8 "slots" of 4K space each, but I'm probably going to shrink that down to 256 bytes each). Even so, I do want the ability to handle a greater address space than that (e.g., adding more RAM to the system -- potentially megabytes).
Make the protocol such that you have 8 "slots" of 4k up high in the address space (Assuming that you get the top 8 bits) and then dictate that if you want more than 4k, you hafta do the decoding yourself.
kc5tja wrote:
As we do know that the Tb will be a 65xx processor, I'd like it to at least design a new motherboard around the Tb without having to redesign all my expansion peripherals.
The problem is they could do a 65xx processor with a bus interface more suited to ASIC / embedded usages....