GARTHWILSON wrote:
Sounds interesting. What application do you have in mind?
Video, audio, and networking. I need a bus that can approach if not exceed the native CPU bandwidth to memory for these applications.
Video. Video is intended to draw mainly from its internal RAM supply, much as video cards on modern-day PCs do. The high bandwidth bus allows the microprocessor enough raw address bits to properly address the full extent of the card's frame buffer in the best case, or to reduce bank-switching requirements significantly over a system that allows only 64KB, such as the $000A0000-$000BFFFF video window on PCs. Additionally, the bus-mastering capability is considered for DMA-based blitting operation, thus reducing the need for manual CPU blitting. This substantially improves graphics performance.
Audio. Audio also has its own internal memory, but it needn't be addressable like a video card -- it can be treated more like a FIFO. In this case, a huge chunk of audio data (say, up to 64KB worth) can be DMA'ed into internal audio RAM in one fell swoop, then doled out to the DACs at the audio sample rate desired. This, thus, interleaves audio fetches with normal CPU operations.
Networking. Many networking ICs have immense register sets and large amounts of backing RAM. It'd be nice to allow the host operating system or application to directly reference the internal RAM with a simple pointer instead of having to copy data, since most network packets
don't need to have their contents copied in order to be used properly. See the uIP stack, for example. Where copying is required, I'd like to have sufficient bus bandwidth to use the MVN or MVP instructions to grab frame data, or to rely on DMA provided on the networking card itself.
Experimentally, I'd also like to support
multiprocessing. I have 7 65816 CPUs. Wouldn't it be cool to be able to just add CPU boards at will to arrive at a 2 to 7 CPU system? Assuming we drive each CPU at 7MHz with a multithreading-aware operating system and applications, that's just like having a 49MHz machine (best-case) in terms of user-perceived performance. Operating systems like Plan-9 and Inferno are expressly designed to support precisely this kind of computer.
Quote:
It reminds me of the 5-page discussion we had under the topic, "Survey: A 65C02-based PC", at
http://www.6502.org/forum/viewtopic.php?t=39The Kestrel has always been intended to function in the capacity of a desktop home computer, but one which is at once easy for beginners to use, easy for programmers to develop for, and economical for homebrewers to design hardware for. It is an attempt to answer the question, "If engineers from Apple, Atari, and Commodore had gotten together to build the one last 8/16-bit home computer, knowing full well that there'd never be another 8-bit ever again, learning from the mistakes of the past, adopting features of their 16/32-bit and larger bretheren, and being 100% free of bean-counter influence while still being sensitive to production costs, what would the computer be like?" My hypothesis is it'd be much like the Kestrel 2.
Perhaps more importantly, it is an attempt to reduce my contribution to my household power bill.
If our $515 utility bill this month is any indication, we all (my roommates and I) need to cut power consumption substantially. Utilities have gone up substantially over the past few years, and shows no signs of stopping. I'm more than willing to sacrifice compute performance for power savings at this rate. Also, being able to be run off a 12V gel-cell or NMH battery is the power goal, with the gel being charged up during the daylight hours via a solar cell of some kind. Ultimately prefer to keep the Kestrel 100% off grid power if I can, including the household internal LAN equipment.
Quote:
What kind of bus speeds do you expect with fastish logic?
I haven't done any detailed analysis yet, as I'm still getting ideas for the overall architecture; however, with simple or complex PLDs implementing the semi- to a-synchronous bus translation and a relatively small number (4 or less) slots, I can easily see it handling up to 16MBps or 25MBps, even if the CPU itself can't handle those speeds. Considering the 8-bit bus width, this puts the bus just barely in the PCI-class of data movers.
With more slots comes longer lead lengths, which will slow the bus down accordingly. However, if VMEBus is any indication, it can handle 22 slots and still move data at immense speeds. Therefore, I am confident that this bus be competitive with VMEbus when moving 8-bits of data per memory access cycle.
Note that RAM speed on the current Kestrel 2 designs handles only 70ns access times; therefore, master access to the stock RAM will only allow approximately 12MBps throughput, taking cycle recovery times into consideration.
Exactly how I'm going to handle widening the bus for the Kestrel 3 when the Terbium comes out remains to be seen, however, and depends entirely on the Terbium's final bus interface. However, I expect double performance with the Terbium, based on my assumption of a 16-bit data bus.
Quote:
How big are you thinking of the whole thing? As parts shrink and memory gets more dense and speeds rise, putting things on separate boards suggests pretty small boards. The modularity helps the building project, breaking the job into manageable chunks.
The bus allows for 16 slots. The Kestrel will likely only have 4 though, as slot connectors are damn expensive, relatively speaking at least. I'm probably going to adopt the 96-pin DIN connectors for the expansion connectors, since they're *relatively* cheap, and are more wire-wrap friendly than the PCI slots are. Plus I have plenty of pins to expand for when the Terbium-based Kestrel-3 comes out.
Quote:
This bidirectional signal allows the user to single -cycle the microprocessor on all cycles including write cycles.
Hmmm, I don't recall reading that before. However, that's an excellent and, in my opinion, important bug fix. However, there still is the issue of address space. I'm not saying that the 6502
cannot be used with this bus; I'm just saying that I don't officially support it. My goal with the bus standard is to exploit the 65816's addressing range for ease of software development and hardware development alike. To this end, I can more economically support geographical addressing: 1/16th the address space is dedicated to I/O. A19-A16 selects the slot to address. This is predecoded using a pair of 74AC138s or a 74AC154 to drive the various _ss16 lines. This gives each slot its own 64K address space with which it can map both I/O chips, RAM, and even (e.g.) a driver ROM. In this way, I can provide plug-n-play capabilities essentially for free.