Ken Hornstein wrote:
> 
> So, if anyone happens to remember, I was that wacko who had a Sparc
> 2 with a VMEbus (a FORCE embedded SPARC board, actually).  I asked
> about getting the VMEbus working on it, and wiser heads than I
> said, "Well, geez, that's pretty weird ... you'll need to get the
> FORCE documentation".
> 
> So, I finally got the FORCE documentation, and as far as I can
> tell, it seems to contain what I need ..... but perhaps I don't
> quite understand the issues involved.
> 
> When I last brought this up, someone (forgive me, I don't remember
> exactly who) 

Me.

>said that the main issue was dealing with 16/32 bit
> memory access.  The sun4 class machines had extra bits in the PTE
> to signify which kind of memory space it was (which I found in the
> documentation for the FORCE 1C board, which is _not_ the board I
> have), and the sun4m machines have extra instructions, 

Right, because the sun4m architecture accounted for VME spaces-

Physical Address bits 35-32 had VME encodings of:

		0xA: User, 16 Bit Data
		0xB: User, 32 Bit Data
		0xC: Supervisor, 16 Bit Data
		0xD: Supervisor, 32 Bit Data

but this isn't across the SBus- in fact there are terrible
deadlock race conditions in the S-to-M and the M-to-V chips
on some sun4m implementations (think about it: SBus is a synchronous
20-25Mhz clocked bus- VME is asynchronous. Let's wedge up
the *entire* data path from an SBus master to a VME slave - whilst
some dopey PAL equation on a VME board ponders its fate, left
in the backwaters of forgotten technology, resentful, pensive,...
but I digress...)


>and the
> sun4c machines have nothing ... which is the problem.
> 
> Now, after reading the FORCE 2CE manual, it seems that it has
> exactly nothing for dealing with data size issues on the VMEbus.
> As I read this documentation, if you want a 16-bit access, you
> write using a 16-bit instruction, and the same for 32-bit access.
> Does this make sense?  I'll confess being mostly ignorant to the
> details of VME.  If there _is_ other issues, then could someone
> please explain them to me and I'll try R'ing the FM.
>

I've forgotten nearly all of this stuff- it's been close to
a decade, so forgive me if I miss many of the fine points- I
could dig up my spec manual- it's someplace behind a 6 foot pile
of Alpha architecture and chipset manuals...

Right- here's the deal- there isn't just 8, 16, or 32 bits
of address and/or data with each cycle- there's also 5 bits
of Address Modifier- which tells the system arbiter and
addressed slaves what your permissions are and how you
want to get or put data. It's a slightly strange concept-
but not unusual except that it exposes to a higher level
details usually wired architecturally or buried as  a side
effect of early initialization or what have you.

The AM bits specify widths, but also whether you have supervisor
or user privileges (this stuff was originally specified for
primary memory being a target- so this fits in nicely with some
(err, umm, can you say "MC68851"?) mmu units. It also had a *very*
interesting effect in that 8, 16, 24 and 32 bit address spaces do
*not* overlap. That is, you can have a 16 bit space board and
a 32 bit space board at the same actual address- the AM bits
act as the selectors. They aren't *quite* an extra 5 bits of
address, but close to it.

So- the take home lesson here is that each VME master in addition
to floating out an address during address phase has to float out
Addess Modifier bits. Yon FORCE board clearly has to have some
place you get it to latch up AM bits for all cycles- or it has to
infer, somehow, on a cycle by cycle basis what it is supposed to
pair up with addresses being emitted thru the MMU.

There are further complications in that SPARC references
have to be aligned - whereas VME assumes auto bus sizing
by the master- I'm a little hazy about what issues this
brought up- I believe that on sun4 they used the limited
type bits available (basically 32 or 16 quantities) to
overload a16d16 and a32d32 and a24d32 accesss- Gee- I'm
sorry, my memory really fails me here.

The net issue here is that there has to be *some* info
that tells you what Address Modifiers this card will
assert based on *some* condition that is either set
automatically or you program.

Hope this helps.