6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 02, 2024 7:30 am

All times are UTC




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Jan 31, 2006 11:28 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
As you know, I've been hammering out the details of an expansion bus for my next-generation Kestrel design. Drafts 1 and 2 were internal documents that I eventually grew to be unhappy with. Enclosed here-in is the third draft, which I'm sufficiently happy with to reveal to the outside world. Please let me know what you think! Thanks.

Code:
|/ E S T R E L      Copyright (c) 2006 Samuel A. Falvo II
|\    2 P 1         Preliminary Material -- All Rights Currently Reserved

===================================================
Kestrel Bus Architecture Specification Revision 1p1
===================================================
                            I D E A   D R A F T   3

Features:
* Microprocessor Independent Bus
* Supports a flat 24-bit address space
* Supports partial address decoding for true plug-n-play support
* Fully asynchronous design
  * Minimal logic required for synchronously clocked bus masters
  * Use combinatorial or monostable multivibrator logic for
    acknowledgement generation
* 8-bit data bus for economy of implementation

Minimum Implementation
======================

            as      as
Pin:        Slave   Master
------------------------------------------------------------
_reset      I*      I*          Kestrel Hardware Reset
_irq        O*      O*          CPU Interrupt Request

a(0..23)    I       O           Address Bus (16Mi sub-space)
_we         I       O           Asserted when sending data to slave
_ss16       I       O           Asserted when addressing slot space
_start      I       O           Asserted to start a transfer
_end        O+      I+          Asserted to acknowledge a transfer
d(0..7)     I/O     I/O         Data Bus

_br         O       O           Bus Request signal
_bg         I       I           Bus Granted signal
------------------------------------------------------------
LEGEND:
    I   Input
    O   Output
    *   Open-collector; may be driven by bus master, bus slave, or
        backplane circuitry.
    +   Three-state.  Driven only by addressed bus slave.
    I/O Three-state input and/or output signal.  Direction depends on
        _we.
------------------------------------------------------------

Bus Slave Operation
~~~~~~~~~~~~~~~~~~~

The d() signals are used to carry data from or to the master, depending
on the state of _we.  When _we is high, the flow of data is from the
slave to the master.  Otherwise, the flow of data is from the master to
the slave.  d() is considered invalid unless both _start and _end are
asserted, as part of a fully-interlocked handshake.  See below.

The a() signals provide addressing information.  24 address lines
provides 16,777,216 bytes of address space.  How this address space is
mapped into a computer's memory space is not specified officially, but it
is intended to be directly mapped into the CPU's address space to make
maximum use of its bus mastering capabilities.  Others may prefer to
provide a small, 256-byte window, with a register to 'bank switch' the
I/O space accordingly.  Still others will provide a smaller window via a
special 16-bit pointer register, and maybe a data register that, upon
access, optionally causes the 16-bit pointer to post-increment.  Note,
however, that these latter two approaches compromise the utility for
supporting multiple bus masters.

The _ss16 signal is asserted when the current bus master is attempting to
reach a specific slave's dedicated I/O space in the 24-bit address space.
With A(20..23) being set to an implementation-defined value addressing a
1MiB window of dedicated I/O space for all slots, and bits A(16..A19)
indicating the slot number, this leaves only A(0..15) for addressing
peripheral chip data.  Therefore, when _ss16 is asserted, use only the
lowest 16 address bits for further address decoding.  For example, the a
computer may place its I/O space at $F00000-$FFFFFF, so that
$F00000-$F0FFFF is slot 0, $F10000-$F1FFFF is slot 1, etc.

If _ss16 is negated during a bus cycle, but the current address is
referring to a peripheral that exists on the card (e.g., an address which
is set via a programmable base address register, for example), the
peripheral may still respond, as the address bus is assumed to be fully
decoded.

NOTE:   The bus makes no attempt to avoid bus contention when used in
        this mode, and therefore it is assumed that all base address
        registers are programmed in accordance with address space
        allocation policies determined by the computer's operating
        system.  The operating system is ultimately responsible for
        properly allocating unmapped device address space.

        To do their part, peripherals must fully decode all pertinent
        address bits, starting with A(23) and on down.  They must also
        communicate the address range requirements to any host operating
        system as well.  This must be done via the card's dedicated I/O
        space.

_start is asserted after the address, control, and optionally, data buses
have become stable.  This officially begins the bus transaction.

_end is asserted by the peripheral in response to the assertion of
_start.  It is the addressed slave's responsibility to make sure enough
time elapses between the falling edge of _start and the falling edge of
_end.  For example, 70ns RAM should have 70ns of delay from the falling
edge of _start to the falling edge of _end.  It is also the slave's
responsibility for keeping _end asserted for any recovery time of the
addressed peripheral as well.

Read/Write Timing
-----------------

            ______ _________________________________ ___
_we/a()     ______X_________________________________X___
            ___________                              ___
_ss16       ___________\____________________________/___
            ____________________                      __
_start                          \____________________/
            ______ ...............         _________ ___
d(r)        ______X...............>-------<_________X___
            ______ ............... _________________ ___
d(w)        ______X...............X_________________X___
            __________________________________         _
_end                                          \_______/

Bus Master Operation
~~~~~~~~~~~~~~~~~~~~

_br is asserted by the device whenever it desires access to the bus.
_br may be asserted asynchronously.  This signal may also be negated at
any time, indicating that the device no longer needs access to the bus.

_bg is asserted or negated by the bus arbitration unit on the backplane
or motherboard in response to the assertion of _br.  The bus
specification provides no guarantees on response times of any kind -- it
depends on the algorithm of the arbiter, along with what other
peripherals currently are using the bus at the time.

When asserted, _bg indicates that the device will become the master at
the end of the CURRENT bus cycle if one is in progress.  Likewise, when
negated, it indicates the device will cease to be the bus master at the
end of the current cycle.  Note that the bus arbiter is free to implement
any bus fairness algorithm it chooses -- peripherals MUST expect the
condition where _bg may be negated at any time, even if _br is still
asserted.

If the bus master negates its _br signal, but the _bg signal remains
asserted for longer than expected, the master MUST continue to assume it
owns the bus for as long as _bg remains asserted.  Dummy, idempotent bus
cycles are recommended to prevent bus lines from floating for an
excessive period of time.

Bus Request Timing
------------------
            ________
_br                 \___________________________________________________
            ________________________
_bg                                 \___________________________________
                                                  ______________________
_start      _____________________________________/
            __________________                           _______________
_end        __________________\_________________________/
                                                             ___________
own         ________________________________________________/

            The bus request unit of a bus master first waits for _bg,
            then waits for the current bus transaction to come to a
            completion before officially accepting ownership of the bus.
            _own is a signal local to the bus master to indicate that it
            officially has the bus.

If the bus arbiter decides to rescind the bus grant prior to the device
becoming the bus master, then the device cannot assume ownership of the
bus until the _bg signal is re-asserted.

                        _______________________________________________
_bg         ___________/
                                    ___________________________________
_start      _______________________/
            _____                          ____________________________
_end        _____\________________________/
            ___________________________________
own                                            \_______________________

            Note that the condition of _br is immaterial for releasing
            the bus.  If the bus arbiter rescinds ownership of the bus to
            a peripheral, that peripheral MUST tri-state its bus
            transceivers at the completion of whatever bus cycle is
            currently in progress.

Interfacing the 6502 to the Kestrel Bus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are no plans to officially support the 6502 processor architecture
at this time.  The 6502 lacks the ability to wait on write (use of FIFOs
for rate-matching writes was encouraged back when it was designed), thus
compromising the asynchronous bus protocol detailed above.  Furthermore,
it lacks sufficient addressing space, thus requiring external banking
registers.  This, in turn, results in the inability to effectively use
bus mastering technology.

Interfacing the 65816 to the Kestrel Bus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The 65816 is quickly and easily interfaced to the Kestrel Bus.  Below is
an ASCII-art schematic for the interface circuit:

    + indicates OR gate
    -1 indicates inverter
    * indicates AND gate


              +---+        (E)
    vpa >-----|   |       +----+
              | + |---*---| -1 |o--------------> _br
    vda >-----|   |   |   +----+
              +---+   |
               (A)    |   +---+
                      +---|   |
   phi2 >-----------------| * |o----+
    rdy <-------------*---|   |     |
                      |   +---+     o
                      |    (B)   +-----+
                      |          |  s  |
                      |          |    Q|o--*---> _start
                    +-----+      |  r  |   |
                (D) |  *  |      +-----+   |
                    +-----+    (C)  o      |
                     | | |          |      |
                     | | |          |      |
                     | +------------*----------< _end
                     |   |                 |
                     +---------------------+
                         |
                         +---------------------< own


NOTE:   Implemented in a PAL or PLA chip, this logic should not incur
        excessive propegation delays, thus allowing the CPU to be driven
        at or near its rated speed without incurring wait-states.

OR gate A is used to detect when the 65816 is attempting to perform a
legitimate bus access.  Its output will go high when this happens; the
inverter E will condition the signal to be used as the _br signal on the
bus.  Note that asserting _br does NOT guarantee the 65816 will actually
get ownership of the bus!

NAND gate B is used to detect the start of a new bus cycle.  This occurs
when phi2 goes high AND RDY is asserted from the previous bus cycle AND a
legitimate bus cycle is being requested.  If these conditions are all
true, it will set the flip-flop C, which brings _start low to assert it.
The immediate feedback from _start to the AND gate D will cause RDY to
negate only a few nanoseconds later, thus guaranteeing the 65816 will see
a wait-state condition if the peripheral doesn't respond in time.

It should be pointed out at this time that the 65816 can only drive the
_start line when it owns the bus.  Therefore, the _start signal above is
an internal signal that must be tri-stated when it doesn't own the bus,
just like other addressing signals.

At this point, the CPU just waits for _end to be asserted by the
peripheral.  When it does, it will cause the flipflop to reset, bringing
_start high.  Note that AND gate D will still have its output negated at
this point -- thus ensuring a premature bus cycle completion doesn't
happen.  To complete the bus cycle, both _start must be high AND _end
must be high.  Once the peripheral negates its _end driver, AND gate D
will ensure that RDY goes high, thus terminating the 65816 bus cycle.

This circuit assumes that the 'own' signal is locally generated once
proper bus ownership has been detected.  See the section above on bus
request timing.

If the 65816 lacks ownership of the bus, then the _end signal can be
delayed as required, thus ensuring bogus data isn't read or written,
until the bus ownership can be re-established.



Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 01, 2006 3:56 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8535
Location: Southern California
Sounds interesting. What application do you have in mind? 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=39

What kind of bus speeds do you expect with fastish logic?

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 6502 lacks the ability to wait on write

That was true of older 6502's, but WDC's '02 data sheet says, "A low input logic level on the Ready (RDY) will halt the microprocessor in its current state. Returning RDY to the high state allows the microprocessor to continue operation following the next PHI2 negative transition. This bidirectional signal allows the user to single -cycle the microprocessor on all cycles including write cycles." Although the whole address range would be less practical to implement with the '02, I wouldn't totally rule it out. Even with older ones, you can still stretch the clock pulses from the clock source, such that the '02 basically doesn't know it's giving extra time when needed.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 01, 2006 5:29 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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=39


The 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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 05, 2006 5:47 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
Taken on the basis of no real updates to this thread, I'm going to assume that everyone here is hunky-dory with the concept and architecture of the bus. Therefore, my next step is to now define the physical connectors used to interconnect the bus.

The goal is to be easy for a homebrew hacker to deal with, and to make it just as trivial for wire-wrappers as PCB etchers to make an expansion peripheral for the Kestrel, especially since this computer isn't going to be a volume production system. Therefore, I'd like a system which allows one to create quick one-off circuits that otherwise won't justify the cost of a real, mass-production-grade expansion system. To this end, I've decided on the same 96-position connectors as those used by VMEbus (3 x 32 pins, all spaced 100 mil apart).

I am now looking for some constructive feedback from anyone experienced either with bus design, or with designing peripherals for existing buses. Thanks.

Code:
    A       B       C
+-------+-------+-------+
|  gnd  |       |  Vcc  |   1
+-------+-------+-------+
|  gnd  |       |  Vcc  |   2
+-------+-------+-------+
|  a0   |       |  a1   |   3
+-------+-------+-------+
|  a2   |       |  a3   |   4
+-------+-------+-------+
|  a4   |       |  a5   |   5
+-------+-------+-------+
|  gnd  |       |  gnd  |   6
+-------+-------+-------+
|  a6   |       |  a7   |   7
+-------+-------+-------+
|  a8   |       |  a9   |   8
+-------+-------+-------+
|  a10  |       |  a11  |   9
+-------+-------+-------+
|  gnd  |       |  gnd  |   10
+-------+-------+-------+
|  a12  |       |  a13  |   11
+-------+-------+-------+
|  a14  |       |  a15  |   12
+-------+-------+-------+
|  a16  |       |  a17  |   13
+-------+-------+-------+
|  gnd  |       |  gnd  |   14
+-------+-------+-------+
|  a18  |       |  a19  |   15
+-------+-------+-------+
|  a20  |       |  a21  |   16
+-------+-------+-------+
|  a22  |       |  a23  |   17
+-------+-------+-------+
|  gnd  |       |  gnd  |   18
+-------+-------+-------+
|  d0   |       |  d1   |   19
+-------+-------+-------+
|  d2   |       |  d3   |   20
+-------+-------+-------+
|  d4   |       |  d5   |   21
+-------+-------+-------+
|  gnd  |       |  gnd  |   22
+-------+-------+-------+
|  d6   |       |  d7   |   23
+-------+-------+-------+
| _strt |       | _end  |   24
+-------+-------+-------+
|  _we  |       | _ss16 |   25
+-------+-------+-------+
|  gnd  |       |  gnd  |   26
+-------+-------+-------+
| _res  |       |  _irq |   27
+-------+-------+-------+
|  _br  |       |  _bg  |   28
+-------+-------+-------+
|       |       |       |   29
+-------+-------+-------+
|  gnd  |       |  gnd  |   30
+-------+-------+-------+
|  Vcc  |       |  gnd  |   31
+-------+-------+-------+
|  Vcc  |       |  gnd  |   32
+-------+-------+-------+


Vcc is +5V, so this will be a 5V bus.

Thanks.

[/code]


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 05, 2006 9:42 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8535
Location: Southern California
I've labored over this kind of thing (connector pinouts) before, and after all my pain, I'm never sure if I came up with the best, or if the exact details of the pinout even really mattered that much. Still, it's always great to have someone to bouce ideas off of.

You have 2.5 times as many grounds as VME's J1 does. If you really want the 3-row (3x32) connector instead of the dual-row, and want (almost) that many ground pins, you could reduce the maximum distance from any non-ground pin to the nearest ground pin by grounding every other pin in row 2, and not grounding any row-1 or 3 pins. Then no pin would be more than .141" (center to center) from a ground pin. I really doubt that you need them that close, or if their impedance requires that many of them. If that means you could reclaim a half-dozen pins for other uses and even go to the dual-row headers and sockets, those would be a lot less expensive. (You'll still have 8 more contacts than STD-80 had.) Then staggering the grounds would reduce the maximum distance to a ground pin. The dual-row connectors will yield shorter non-transmission-line distances for signals to travel anyway. By that I mean the hop between where the signal leaves a trace against the plug-in board's ground plane and where it gets into a trace against the backplane's ground plane, if that kind of board is even used.

That will leave you with some uncommitted pins; but I'm going to suggest a use for at least two of them: ±12V. These are good for LCD bias, op amps (like for data converters), cheaper RS-232, a speaker or headphone amp, etc.. Their implementation would be optional, and the exact voltages may vary or not be terribly critical, depending on what you're doing. When I'm programming PIC microcontrollers with my workbench computer, the +12V actually needs to be +13.0 for some of them, so I set the power supply accordingly.

Are you thinking of using the 100x160mm Eurocard? They're nice because you can get ready-made prototyping breadboards in that form factor.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 05, 2006 6:01 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
GARTHWILSON wrote:
You have 2.5 times as many grounds as VME's J1 does. If you really want the 3-row (3x32) connector instead of the dual-row, and want (almost) that many ground pins, you could reduce the maximum distance from any non-ground pin to the nearest ground pin by grounding every other pin in row 2, and not grounding any row-1 or 3 pins.


I was thinking about that actually. But in those moments where you second-guess yourself, they tell you to never do that, because your gut instinctual reaction is usually the correct one. So I decided to just proceed as I was with the post.

Quote:
Then no pin would be more than .141" (center to center) from a ground pin. I really doubt that you need them that close, or if their impedance requires that many of them.


I was not considering impedance -- I was going on the dictum that more grounds equals good, less grounds equals bad. Frankly, I have no idea what the circuit impedance is of each line. In fact, I don't think that impedance would be easily calculable, since each trace may full well take a completely different path (and hence, have a completely different length) through the circuit. Especially since it's being wire-wrapped to start with. :)

In your opinion, should I reduce the number of grounds that are made available?

Quote:
If that means you could reclaim a half-dozen pins for other uses and even go to the dual-row headers and sockets, those would be a lot less expensive.


No it wouldn't, actually. The average cost for 3-row headers is $5. The average cost for 2-row headers is, according to DigiKey, $5. Note that I'm talking averages -- you can find each for $3.50 each if you know which part number to look for precisely.

Quote:
The dual-row connectors will yield shorter non-transmission-line distances for signals to travel anyway. By that I mean the hop between where the signal leaves a trace against the plug-in board's ground plane and where it gets into a trace against the backplane's ground plane, if that kind of board is even used.


From what I can see, I don't see how this logic applies, as the pin heights are the same for both the 3-row and 2-row plugs. It looks as though the 3-row and 2-row connectors are the same physical size as well. Am I missing something?

Quote:
That will leave you with some uncommitted pins; but I'm going to suggest a use for at least two of them: ±12V.


The problem is that the Kestrel 2 is likely to be driven off of a 9V source. I don't want any kind of extraneous signals on the bus because that ultimately adds complexity to the bus, and increases the cost of conformance.

I would much rather each card have its own power supply connector if required, kind of like how hard drives in PCs have their own power connectors. While it's not as clean as everyone would like, I really cannot see any other solution to this.

Quote:
Are you thinking of using the 100x160mm Eurocard? They're nice because you can get ready-made prototyping breadboards in that form factor.


Not really -- I was thinking more about people who are going to wire-wrap stuff together, because I cannot foresee a large enough market for Kestrel peripheral cards to warrant printed circuit boards. My convictions are confirmed when doing a search for this stuff on Digikey.com and mouser.com. $14 for a prototyping board is outrageous, and is twice the cost of a *worst-case* price for a 3-row male and female DIN connector for home-brewed equipment and PCB.

I have no defined form-factor for the Kestrel's bus interface at this time. 160mm*100mm is a commonly cited standard, and I can use that as a foundation (that comes out to be approximately 6" x 4" if my head-only math is correct). I'll probably define a full-sized Kestrel card as being 320mm*100mm (same as a 6U VMEbus card).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 06, 2006 6:12 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8535
Location: Southern California
Quote:
In your opinion, should I reduce the number of grounds that are made available?

It's not that reducing in itself is better, but that the benefit of spreading them out more evenly will outweigh any loss from having fewer. If you run into speed limits as parts get faster, you'll want to minimize the distance from any given pin to the nearest ground return pin.

Quote:
No it wouldn't, actually. The average cost for 3-row headers is $5

The standard PC-mount ones aren't too bad, but if you've found wire-wrap ones for $5, please tell me where. The ones I'm thinking of, Digi-Key's cat. no. V1250-ND in the bottom right corner of their catalog T061 page 1550 (viewable at http://dkc3.digikey.com/PDF/T061/1550.pdf ) are $19.20 each below qty 10. These are the right-angle females that go on the board. The wire-wrap straight males that go on the backplane (Digi-Key cat. no. V1238-ND) are $13.20 each.

Quote:
From what I can see, I don't see how this logic applies, as the pin heights are the same for both the 3-row and 2-row plugs. It looks as though the 3-row and 2-row connectors are the same physical size as well. Am I missing something?

Just measuring some I have here, the "flying" distance for the row C pins of the 96-pin DIN pair is over an inch, whereas it's under 3/4" with the dual-row pair-- about a .300" difference. If it's going to be wire-wrapped anyway then the difference hardly matters.

Quote:
The problem is that the Kestrel 2 is likely to be driven off of a 9V source. I don't want any kind of extraneous signals on the bus because that ultimately adds complexity to the bus, and increases the cost of conformance.

I would much rather each card have its own power supply connector if required, kind of like how hard drives in PCs have their own power connectors. While it's not as clean as everyone would like, I really cannot see any other solution to this.

I suppose there's no need to require implementation of ±12V, but I think it would be a bit short-sighted not to at least reserve pins for them. If you stay with the 96-pin DINs, you certainly have room for them.

Quote:
$14 for a prototyping board is outrageous,

I agree, but if someone can afford it, it might be worth it to them just to make sure they don't have slight errors in cutting their own boards that would mean a card that's slid into the card cage won't mate quite right with the connector in the back because of something like a height discrepancy. A single 96-pin DIN connector per board normally goes with 3U VME chasis, with the card guides spaced vertically for 100mm-wide boards. It might be nice for anyone putting together your system to be able to pick up such a card cage at an electronics swap meet or surplus store. It doesn't force you to do it that way, but leaves that option open. 6U VME boards are usually the same length (160mm) and sometimes 220mm. Their height is 233mm. I have a nice little half-rack-width 3U VME cage here I got from an electronics swap meet for $10 and then put a carrying handle and hinged covers on it.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 06, 2006 5:54 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
GARTHWILSON wrote:
It's not that reducing in itself is better, but that the benefit of spreading them out more evenly will outweigh any loss from having fewer. If you run into speed limits as parts get faster, you'll want to minimize the distance from any given pin to the nearest ground return pin.


I see what you're getting at. I will come up with another connector layout soon. In the mean time, though, isn't there a point of diminishing returns with this though? That is, the connector could be the best representation of a transmission line there is for these things, but on the backplane and on the card, the signals have to "flatten" -- doesn't that compromise the efforts a bit?

Quote:
The standard PC-mount ones aren't too bad, but if you've found wire-wrap ones for $5, please tell me where.


I was looking at using the standard PC-mount parts and jury-rigging them to a protoboard somehow. If you can find an alternative solution, I'd like to hear it. :)

The SS-50 bus relies on SIP connectors, which is an interesting alternative, but not very stable mechanically, AND, they result in a very long connector, which might be a significant disadvantage for smaller cards.

Quote:
I suppose there's no need to require implementation of ±12V, but I think it would be a bit short-sighted not to at least reserve pins for them. If you stay with the 96-pin DINs, you certainly have room for them.


Though, again, where would I get these voltages from? I'd need DC-to-DC converters for at least the negative supply, if not for both +12V (which would almost certainly be truely 12V and not 13.8V like what your project required) and -12V, on the backplane.

Quote:
$14 for a prototyping board is outrageous,

I agree, but if someone can afford it, it might be worth it to them just to make sure they don't have slight errors in cutting their own boards that would mean a card that's slid into the card cage won't mate quite right with the connector in the back because of something like a height discrepancy. A single 96-pin DIN connector per board normally goes with 3U VME chasis, with the card guides spaced vertically for 100mm-wide boards. It might be nice for anyone putting together your system to be able to pick up such a card cage at an electronics swap meet or surplus store. It doesn't force you to do it that way, but leaves that option open. 6U VME boards are usually the same length (160mm) and sometimes 220mm. Their height is 233mm. I have a nice little half-rack-width 3U VME cage here I got from an electronics swap meet for $10 and then put a carrying handle and hinged covers on it.[/quote]

You have to be careful with VME backplanes though, because not all pins are bussed together. The DMA daisy-chain and interrupt daisy-chain signals for example. Quite simply, it means that those pins are automatically no-connects from now until forever.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 06, 2006 11:27 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8535
Location: Southern California
Quote:
isn't there a point of diminishing returns with this though? That is, the connector could be the best representation of a transmission line there is for these things, but on the backplane and on the card, the signals have to "flatten" -- doesn't that compromise the efforts a bit?

Because of the higher and higher frequencies and data rates and the wider and wider buses, the electronics industry actually has a magazine dedicated to just connectors. My field of work doesn't make it worth subscribing (even though it's paid for by the advertisers and is free to those in the industry who qualify), but I thought it was almost comical that they could have a dedicated connector magazine.

I'm not sure what you mean by "flatten", but I'm looking at unwanted things like RF noise radiation, coupling of digital signal edges from one line into another, and slowing and ringing of edges.

I have not worked in high-speed digital but I got a feel for what goes on up there when I worked in VHF and UHF power transistor applications engineering in the mid-1980's. That experience helps me get a better grasp when I read articles and ap notes on digital circuit board layout.

Quote:
I was looking at using the standard PC-mount parts and jury-rigging them to a protoboard somehow.

The 96-pin DIN connectors have screw holes at the ends to give mechanical strength, so you probably don't need to worry about getting that strength from the pins themselves like you would with other connector types. That means you wouldn't need the more expensive proto boards with plated-thru holes to solder to. You just have to solder the wires to the connector pins, which is not as convenient as WW but I've done it many times.

Quote:
The SS-50 bus relies on SIP connectors, which is an interesting alternative, but not very stable mechanically, AND, they result in a very long connector, which might be a significant disadvantage for smaller cards.

I don't recall seeing SS-50 information. But even if you don't use a card cage, I would still plan on using some kind of card guides, even if it's the open-frame idea where they just stick up off the backplane, fastened to it with screws.

Quote:
Though, again, where would I get these voltages from? I'd need DC-to-DC converters for at least the negative supply, if not for both +12V (which would almost certainly be truely 12V and not 13.8V like what your project required) and -12V, on the backplane.

It could be as simple as a pair of 9V batteries, up to an open-frame power supply like Jameco's 230535CB ($27), to a desktop supply like Jameco's 190959CB ($33), to an adjustable tripple-output workbench power supply.

Quote:
You have to be careful with VME backplanes though, because not all pins are bussed together. The DMA daisy-chain and interrupt daisy-chain signals for example. Quite simply, it means that those pins are automatically no-connects from now until forever.

I should have clarified. It didn't meet the VME electrical connection spec when I got it. 2/3 of the pins didn't go to anything. Using WW 96-pin DINs, I made my own backplane to replace the one it came with. I've had it for a few years now, but still have not put it into service. My grand ideas for it have been modified again by further experience with my existing workbench computer.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 20, 2006 3:36 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
Well, I've decided to not include an asynchronous backplane for the Kestrel. Instead, I'm going to follow through with a synchronous backplane interface instead. There are several reasons:

First, the logic to implement the asynchronous logic interface on both sides of the connector is only about $1.50 of logic. Although fiscally cheap, it won't be adding a whole lot of value. You have to spend the time to wire the logic up, and 99% of the time, it will not really solve any real problem.

Second, with the construction techniques available to most homebrewers, you'll be lucky if you can push the interface to 33MHz and have it be robust. Therefore, I'm confident that few, if any, will ever want to exceed 16MHz. Going beyond that requires *very* fast logic, which you likely won't see in most home-brew designs anyway (you'd need CPLDs and FPGAs for that).

Third, it obviously will support the RDY signal, so you can still use monostable multivibrators or other delay techniques to generate the RDY signal if required.

Finally, due to the cost of the connectors, you're probably not going to want to have more than two or three slots anyway. But you'll likely want to add a lot more than just three peripherals. Therefore, these slots should be reserved for peripherals that need the bus bandwidth the most: Ethernet or other networking adapters, video cards, data acquisition, etc. For most everything else, there is GPIB or similar interface standards.

Making this decision was not easy for me, because I'm not happy accepting limitations. But, I have to keep telling myself, "There is a reason why it's called Kestrel 2, and not The Kestrel." If in doubt, I can always make a Kestrel 3. :)

Thanks for putting up with me.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Feb 24, 2006 8:51 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
This is the latest incarnation of the Kestrel's Local Bus. Maybe this can be useful as a backplane as well, I don't know. But as usual, I'm interested in constructive criticism over its design.

Thanks!!

Code:
===============================
Kestrel Local Bus Specification
===============================
        I D E A   D R A F T   2

Goals:

* Semi-synchronous design to simplify interfacing logic.
* One byte per bus clock cycle maximum throughput.
* Demultiplexed address bus for easy access by peripheral circuitry.
* 8-bit data bus for homebrewing simplicity.
* RDY support for wait-state generation if required.
* Full bus mastering capability.

Mission Statement
=================

The mission of the KLB is to help facilitate homebrew electrical
engineering for the Kestrel series of computers in particular, and for
65816-based and Terbium-based platforms in general.  Because the Kestrel
itself is a homebrew computer, it is important that the bus architecture
not impose an extensive amount of financial burden on the builder.
Additionally, should the builder decide to create new peripherals that
require the KLB's high bandwidth, it should be easy and inexpensive for
someone to do so.  Dedicated bus bridges or specialized interface chips
should not be a requirement for someone to build a KLB peripheral --
standard 74HC(T) or 74AC(T) CMOS logic must suffice.

NOTE: The KLB is NOT a replacement for the alternative forms of
interconnects such as SS-22!  Whenever possible one should try to use
those.  The KLB is best used when adding more peripherals that need to be
accessed by the microprocessor or for those peripherals that draw or
deposit directly to/from system RAM.

The KLB is designed to present as close an interface to a 65816 as is
reasonable.  Therefore, we will not be repeating much of the 65816's bus
cycle description here, as it is already documented in readily available
materials from Western Design Center, Inc.

Note that the full KLB implementation uses two inline 2x20 pin female
headers on the motherboard for each slot.  J1 is the slave-only
interface, which a peripheral may use if it does not desire access to the
full address bus and has no bus mastering capability of its own.

More sophisticated expansion peripherals, it will make use of both J1 and
J2, the latter of which defines the remainder of the bus signals that are
of most use to a bus master, or a slave which requires access to the full
address bus (e.g., a RAM expansion card).

Pin-out: J1 (Slave-only Interface)
==================================

A01 : _VP       B01 : _RESET
A02 : RDY       B02 : VDA
A03 : SLOT0     B03 : n.c.
A04 : _IRQ      B04 : BUSCLK
A05 : SLOT1     B05 : _SLOTSEL
A06 : SLOT2     B06 : SLOT3
A07 : VPA       B07 : R_W
A08 : A0        B08 : D0
A09 : A1        B09 : D1
A10 : +Vdd      B10 : D2
A11 : GND       B11 : D3
A12 : A2        B12 : D4
A13 : A3        B13 : D5
A14 : A4        B14 : D6
A15 : A5        B15 : D7
A16 : A6        B16 : A15
A17 : A7        B17 : A14
A18 : A8        B18 : A13
A19 : A9        B19 : A12
A20 : A10       B20 : A11

The slave-only J1 header mimics a DIP 6502 microprocessor's pinout
closely.  There are some differences, however.

* +Vdd and GND are adjacent, to make decoupling easier for higher-speed
  operation.

* Many signals that would only be of interest to a bus master are moved
  to the J2 connector.  In their place are four pins to identify which
  slot the peripheral is plugged into, and a _SLOTSEL which is asserted
  whenever another bus master is accessing this peripherals local 64K I/O
  space ($Fs0000-$FsFFFF, where s is the slot number indicated by
  SLOT(0:3)).

* There is no NMI interrupt; peripherals only have access to an IRQ pin.
  The IRQ pin is always affirmatively driven by the peripheral -- it is
  NOT open-drain.

Although the peripheral lacks direct access to A16-A23, it can deduce the
state of those address lines whenever _SLOTSEL is asserted.  By
definition of the Kestrel Local Bus specification, all slot space
occupies memory between $F00000-$FFFFFF, where the 2nd most-significant
nybble indicates the specific slot in question (e.g., slot 0 is at
$F00000-$F0FFFF, slot 1 at $F10000-$F1FFFF, etc).  In case a peripheral
needs to know its base address for any reason, the SLOT(0:3) signals are
provided to deliver this information.

Pins marked "n.c." are expressly reserved for future definition.

Pinout: J2 (Full Bus Extensions)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

C01 : A16       D01 : n.c.
C02 : A17       D02 : n.c.
C03 : A18       D03 : n.c.
C04 : A19       D04 : n.c.
C05 : A20       D05 : n.c.
C06 : A21       D06 : n.c.
C07 : A22       D07 : n.c.
C08 : A23       D08 : n.c.
C09 : _ML       D09 : n.c.
C10 : +Vdd      D10 : n.c.
C11 : GND       D11 : n.c.
C12 : _ABORT    D12 : n.c.
C13 : _BR       D13 : n.c.
C14 : _BG       D14 : n.c.
C15 : n.c.      D15 : n.c.
C16 : n.c.      D16 : n.c.
C17 : n.c.      D17 : n.c.
C18 : n.c.      D18 : n.c.
C19 : n.c.      D19 : n.c.
C20 : n.c.      D20 : n.c.

This header defines the remainder of the address bus, as well as some CPU
status signals that would be of use to a potential bus master.  In
addition, the slot-local bus arbitration handshaking signals _BR (bus
request) and _BG (bus grant) are defined here as well.

Of particular interest is the _ABORT pin.  This is often used for
implementing external MMU functionality.  It is not possible to implement
a complete, address-translating MMU with the current KLB specification.
However, it is possible to add memory *protection* as a separate adapter
card.


NOTE: _ABORT is positively driven, just like _IRQ is.  It is NOT an
      open-drain output.

Pins marked "n.c." are expressly reserved for future definition.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 26, 2006 1:21 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8535
Location: Southern California
What kind of board are you planning then? I take it you decided to abandon the 100x160mm Eurocard, since both connectors won't fit along its back edge, let alone with room around them for IDCs in case someone wanted to just connect two or three together with ribbon cables instead of a backplane. Those connectors are definitely inexpensive though.

How 'bout more grounds? (You kind of went from one extreme to the other.)

Is it intended that only one board will be able to drive the IRQ line, since it's not a wire-OR line?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 26, 2006 3:11 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
GARTHWILSON wrote:
What kind of board are you planning then?


I do not understand this question.

Quote:
I take it you decided to abandon the 100x160mm Eurocard, since both connectors won't fit along its back edge


Are you sure about this? Since I'm using 2x20 headers (non-IDC), it seems to be that it should be able to fit, since worst-case it will be 4" long (100mm).

Quote:
How 'bout more grounds? (You kind of went from one extreme to the other.)


I could not find any reasonable way to arrange them. No matter what I did, I would end up with a gigantic connector, and it would always require all 80 pins to be connected. It is a possibility, but since both the DIP and the PLCC 6502 can (theoretically) handle 16MHz, I figured the pinout I chose for J1 would as well.

How would you arrange the signals above? I have to admit, I have zero experience in this area, probably as evidenced by the two extremes. :-)

Quote:
Is it intended that only one board will be able to drive the IRQ line, since it's not a wire-OR line?


No. The motherboard would have AND gates for RDY, IRQ, and ABORT. In fact, I forgot to include the feedback from RDY's AND gate to the connector, because without it, circuitry would not be able to properly generate RDY itself (since it wouldn't see when *other* cards negate RDY, it would not know where one cycle ends and a new one begins).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 26, 2006 6:33 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8535
Location: Southern California
100mm is just a hair under 4", but you can't really run the connector all the way to the edge because then it would hit the card guides when you try to insert the board into the cage. (Even if the pins didn't hit, the insulation strip would.)

I like your idea of having the AND gates on the backplane. That also explains the reason for not planning to allow a three-board system to be connected together with ribbon cable too (although I assume a two-board system with a single master could still be). Then I guess you would also make the backplane circuitry able to know which slot is the current bus master, since that slot's RDY, ABORT, and IRQ will be inputs, while the other slots' will be outputs.

On number of ground pins-- Even STD-80 bus, which is limited to something like 4MHz IIRC, has a ground at each end of the 56-contact connector, and an auxiliary ground at each end as well. The AUX GND is not used by all boards. I think it would be better to bring STD's ground contacts in from the corners a bit to reduce the maximum distance from any given contact to a ground contact. Unless one could build up the system several different ways and test them (which is highy impractical in your case), this kind of thing kind of gets into that nebulous area called "good engineering practice," where we know that something will make it better but we don't have an answer when someone asks exactly how much better. I'm uncomfortable with leaving the whole connector depending on a single ground pin. With so many uncommitted pins on J2, were you planning on possibly another whole parallel auxiliary bus of some type? Could at least a couple of those serve as extra ground pins, even if you have to divide the two connectors up a little differently instead of 40/40?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Feb 26, 2006 4:10 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
GARTHWILSON wrote:
I like your idea of having the AND gates on the backplane. That also explains the reason for not planning to allow a three-board system to be connected together with ribbon cable too (although I assume a two-board system with a single master could still be). Then I guess you would also make the backplane circuitry able to know which slot is the current bus master, since that slot's RDY, ABORT, and IRQ will be inputs, while the other slots' will be outputs.


I will not make these pins bidirectional -- that's excessively complex and it would waste most of the buffers in a 74AC245 chip.

I was planning on having the ABORT and IRQ just feed directly to the 65816; they really do not have any reasonable meaning on non-CPU bus masters. Moreover, when supporting multiple CPU systems, now you run into the issue of *routing* these interrupts to the appropriate processor.

As such, there really is no need for one card to know when another card asserts IRQ or ABORT. It can guess this anyway by monitoring the _VP line.

The RDY pins are different, however. The RDY_I (pin 2 on J1) signal is unidirectional from card to motherboard, for all slots, no matter what. The output of the AND gate then feeds not only the CPU, but another RDY_O pin, also on J1 (I'll probably end up using B03). That way, cards which are interested can detect when the end of the previous bus cycle occurs, thus arming the monostable multivibrator (or whatever) for the next bus cycle.

Quote:
With so many uncommitted pins on J2, were you planning on possibly another whole parallel auxiliary bus of some type?


Room for expansion for when I get my hands on a Terbium processor.

Quote:
Could at least a couple of those serve as extra ground pins, even if you have to divide the two connectors up a little differently instead of 40/40?


I was hoping that I could get away with a clean division between master and slave interfaces, so as to make slave-only devices cheaper.

How would something like this seem?

Code:
A00 : SLOT0     B00 : SLOT1
A01 : SLOT2     B01 : SLOT3
A02 : _RESET    B02 : _SLOTSEL
A03 : _VP       B03 : _IRQ
A04 : GND       B04 : GND
A05 : RDY_I     B05 : RDY_O
A06 : VPA       B06 : VDA
A07 : R_W       B07 : n.c.
A08 : _ML       B08 : BUSCLK
A09 : GND       B09 : GND
A10 : A0        B10 : A1
A11 : A2        B11 : A3
A12 : A4        B12 : A5
A13 : A6        B13 : A7
A14 : GND       B14 : GND
A15 : A8        B15 : A9
A16 : A10       B16 : A11
A17 : A12       B17 : A13
A18 : A14       B18 : A15
A19 : GND       B19 : GND
A20 : A16       B20 : A17
A21 : A18       B21 : A19
A22 : A20       B22 : A21
A23 : A22       B23 : A23
A24 : GND       B24 : GND
A25 : D0        B25 : D1
A26 : D2        B26 : D3
A27 : D4        B27 : D5
A28 : D6        B28 : D7
A29 : GND       B29 : GND
A30 : _ML       B30 : _ABORT
A31 : _BR       B31 : _BG
A32 : n.c.      B32 : n.c.
A33 : n.c.      B33 : n.c.
A34 : GND       B34 : GND
A35 : n.c.      B35 : n.c.
A36 : n.c.      B36 : n.c.
A37 : +5V       B37 : +5V
A38 : +5V       B38 : +5V
A39 : GND       B39 : GND


The only problem with this is that now there is no room for expansion for the Terbium. I can fit the 16-bit data bus in, but no bus lane selects (if it even has them), and certainly no room for A24-A31.

And, of course, tacking on another 2x20 to support the Terbium, while it would be visually impressive, is probably starting to become unweildly from a practicality standpoint. :-)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: