Close

Time to bust out the books...

A project log for rhombus

An open-source minimalist 68020 based single board computer

jason-westerveltJason Westervelt 01/12/2016 at 03:3029 Comments

In preparation for the next revision of my hardware, I'm looking at making use of a standardized bus. I have a VME chassis and backplane, so I might as well make use of it. There are a few issues that I am running into, but I am certain that I'll get them figured out with a little reading.

Basically what it boils down to is that A0 (address 0 line) is not presented on the VME bus. This leads one to believe that everything is 16bit data width or higher on the bus. There is an issue with that thought, specifically that 8bit cards and peripherals DO exist for VME systems.

The documentation that I have from Motorola shows that, because the 68020 and higher are capable of 32bit data operations, that a few things have to be addressed when interfacing these CPUs to a VME system. One such difference is that the 8-bit data bus is present on D24-D31... 16-bit on D16-D31. That's fine, a few transceivers and supporting logic should fix the byte presentation to the CPU... and in fact the documentation that I have proposes just that...


The problem is that the documentation shows D0-D7 on the VME bus going to D16-D23 on the CPU and VME D8-D15 going to CPU D24-D31 for a 16 bit operation, but for an 8-bit transfer, VME D0-D7 still end up going to D16-D23... not D24-D31 as I'd expect.

I find it hard to believe that the documentation would be so horribly flawed, but it wouldn't be the first time that I've run across a spectacular booboo in documentation. Perhaps it is possible that 8-bit devices on the VME bus are actually attached to the upper byte, and thus D8-D15 on the bus ends up getting placed on D24-D31 on the CPU.




Discussions

Jason Westervelt wrote 01/15/2016 at 08:55 point

Bah.  I'm not making sense of this mechanism.  I appreciate all the help you guys have provided, it has been quite useful thus far, but I am properly stumped at the moment.

The schematic that I posted is, unfortunately, the only example that I have found of a 68020 interface to the VME bus.  A brief summary of this circuit is that as long as a byte is being transferred, the center two buffers will be active and the other four will be disabled... the other logic will not change this outcome due to A0/A1/*BERR status. 

This means  DTB D0-D7 is placed on the CPU's D16-D23, and DTB D8-D15 is placed on the CPU's D24-D31.  This much I am certain.  Now for the assumptions, please correct me where I go astray.

Assuming an 8bit peripheral, such as a UART... who's card decodes on an even address, the UART's data lines should output to D0-D7 on the DTB.  The logic shown in the image would cause this data to be seen on D16-D23 on the CPU.

The 68020 documentation is showing me that, for an 8-bit port, the only lines read for a byte READ are D24-D31.  Incidentally, the schematic is fine for byte WRITEs because the byte is replicated on D0-D7, D8-D15, and D16-D23 since the port size is unknown.  I've been over the internal multiplexer documentation a dozen times, and I just don't see a single case mentioned where a single byte on an even address will be read across D16-D23.

In fact, the documentation states the following:  "Dynamic bus sizing requires that the portion of the data bus used for a transfer to or from a particular port size be fixed.  A 32-bit port must resize on D31-D0, a 16-bit port must reside on D32-D16 (typo lol), and an 8-bit port must reside on D31-D24.  This requirement minimizes the number of bus cycles needed to transfer data to 8- and 16-bit ports and ensures that the MC68020/EC020 correctly transfers valid data."

The only thing that I can assume is that either
1) the schematic is missing a transceiver which would route D0-D7 on the bus to D24-D31 on the CPU for byte operations when DSACK0/DSACK1 indicate an 8-bit port

 or 


2) 8-bit devices on a VME system are supposed to be attached to D8-D15 on the bus.  

  Are you sure? yes | no

Matt Bettcher wrote 01/12/2016 at 21:19 point

I went for a multiplexed bus for my expansion ports. I used two SN74CBT16233's as the mux and the timing will be controlled by a CPLD. I also have a SN74CBT16292 to mux the address lines for the DRAM. Using external mux ic's save a bunch of pins on the CPLD allowing me to use a much smaller one.

  Are you sure? yes | no

Jason Westervelt wrote 01/12/2016 at 21:59 point

Yeah, i'm thinking I'll just design this in such a way that I can fix any screwups by changing the code in the CPLD....

Interestingly enough, I did find a page where someone documented a 68020 VME system that they had built.  Unfortunately the documentation that I have indicates that certain timings on the VME bus are easily violated with a faster CPU... so the address strobe and synthesized data strobes in his design are likely to violate the VME spec since they are not being delayed via a flip flop...  

In a way, I suppose that this is good news because if his design works, it means that the specification might be more tolerant of timing issues than I am led to believe.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/12/2016 at 14:20 point

That picture...

I'll know who to blame for my next nightmare.

  Are you sure? yes | no

Jason Westervelt wrote 01/12/2016 at 18:14 point

Yeah I know... check out that flip-flop... Q vs _Q... Hmm... which is which, lol

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/12/2016 at 19:29 point

I don't think I want to know!

  Are you sure? yes | no

Jason Westervelt wrote 01/13/2016 at 20:56 point

Oh jeebus... i just realized that those are the inverting output transceivers... wut da hell?

Pretty sure those should be 74LS645s....  :/

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2016 at 21:05 point

Why not '245 ?

  Are you sure? yes | no

Jason Westervelt wrote 01/13/2016 at 21:13 point

I can't source the '245s locally.But certainly, these should not be inverting output, right?  I can't imagine that being the case unless every peripheral card on the bus is buffered in the same manner.  It seems... odd.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2016 at 21:19 point

What ? You can't get '245s ? Then how did you get the other parts ? :-)

Are you sure you're in the USA ? It's one of the most common digital parts... I just received more than 7K× TC74VHC245 from a US broker ($4+shipping) !

  Are you sure? yes | no

Jason Westervelt wrote 01/13/2016 at 22:04 point

Yeah, I'm in AZ.  We have one local vendor.  I can of course order stuff off the interwebs, but the I have to wait for shipping.  Sometimes, I just gotta have my parts ASAP and start tinkering.

That said, '245 and '645 are functionally equivalent, right?  I think the tolerances are a little different, but I cannot see it being an issue.  I know that the '645-1 parts can handle more current, but I'm not suspecting that it will be an issue in this case.

  Are you sure? yes | no

K.C. Lee wrote 01/13/2016 at 22:15 point

You might want to check with the VME specs on the drivers.

6.13  AS*, DS0*, DS1* needs IOL>64mA drivers.
6.4.2.2 Your loading for regular tristate lines (e.g. address, data) needs IOL >48mA drivers

regular LS245 are 24mA drivers and HC parts are probably 6-8mA.

specs here: https://www.mpp.mpg.de/~huber/vme/vmebus.pdf

I notice they use 74LS645 for the tristate lines and 74F573 for the strobes on my old VME cards.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2016 at 22:56 point

64mA ??? that's insane !

I believe that Jason will not use a full configuration, only a few boards, so such current is not necessary...

  Are you sure? yes | no

Jason Westervelt wrote 01/13/2016 at 23:12 point



@Yann Guidon / YGDES I might as well try to meet spec as much as possible.  I agree, 64mA is pretty retarded...  I am already starting to piece this together and I think I have a decent design.  I'll have a standalone SBC which will mate with the VME prototyping board which will include all the fun bits to glue it to the VME bus... DTB Arbiter/requester/master, bus transceivers, etc.  

Thanks @K.C. Lee It turns out I do have a spec sheet in my book, it says that I need high current 3-states for AS*, DS0*/DS1*, and high current totem-pole (3-state to keep things simple) for SYSCLK, BCLR...

So that's what, a single IC for the 5 high current lines.  The specs show a '244 part, but whoever decided that the alternating layout on those parts was a good idea needs to be put under ground.  ;) Looks like there is no such thing as a 74S244 either... :/  

Just found out that I have a single SN74F245N in my parts bin.  One side of that transceiver can handle 128mA IOL.  Looks like I have a part lined up for the high current stuff.  :D  Granted, the F classification is probably way overkill for this part.

As for the standard class signals... 48mA is still kinda steep.  :/  Looks like I'm going to just order more 74F245s and be done with it then.  Looks like I'll also need open collector on 18 signal lines (mumble mumble something about multiples of 8). I have all of two 74S38s... in my IC bin.  Going to need more if I start making cards, especially since they are used for bus allocation, interrupt, and response signals. 

  Are you sure? yes | no

K.C. Lee wrote 01/13/2016 at 23:26 point

That's the problem with first incident wave type of backplane (vs the reflected wave for PCI.)  The high currents are for the thevenin terminations.  I don't know if that's required for the fancy transfer modes or you can get away without or use weaker terminations for a short slot.

I am actually surprised that they spec the 48mA drivers, but recommends the regular LS parts in their own observation section.

There are some 18-bit wide (and 36-bit) parts for the newer 3.3V or below logic families.  Something about parity/ECC.

  Are you sure? yes | no

Jason Westervelt wrote 01/14/2016 at 06:31 point

Active termination! GO!

  Are you sure? yes | no

K.C. Lee wrote 01/14/2016 at 11:24 point

I guess I should have been more verbose instead of lumping things.  Here is a simplified version:
The driver impedance and the backplane impedance forms a voltage divider.  The amplitude of the initial wave front has to be high enough (or low enough) to clear the logic thresholds.  On a long bus with lots of slots, each of the connections aka stubs will add capacitive loads thus lowering the backplane impedance.  So to drive them, you'll need a driver with very low impedance i.e. a high current driver.

Now the problem is that all that energy from the wave front has to go somewhere or it get bounced back and forth on the length of the bus, hence you put in Mr. Terminator.  

The type of termination affects the amount of power consumption, but the driver impedance still have to be low enough for this to work.

Now if you have only a few slots, you could get by with a weaker driver.

http://electronicdesign.com/boards/sorting-out-backplane-driver-alphabet-soup

  Are you sure? yes | no

Jason Westervelt wrote 01/14/2016 at 19:48 point

Well luckily my backplane is only 10 slots, not the full 21 in the spec.  I don't think that I will have too much trouble with the parts that I have selected.  I can always throw my scope at it and look at the waveform.  I mean, c'mon, it's 5V at 16MHz... it's not like I'm driving a first-incident wave backplane at 1GHz with 1.1V logic.  ;) 

  Are you sure? yes | no

K.C. Lee wrote 01/12/2016 at 21:13 point

I thought you guys like your discrete logic.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/12/2016 at 21:20 point

discrete, not random ;-)

  Are you sure? yes | no

Jason Westervelt wrote 01/14/2016 at 19:50 point

discrete?  There's no discrete logic on my board.  :)  Everything has been tossed into a CPLD.  That is going to change when I have to add the bus transceivers though, I really don't think that the CPLD will have the oomph to drive the bus.

  Are you sure? yes | no

Jason Westervelt wrote 01/12/2016 at 10:29 point

Yeah, I'm learning that... but it appears that 8bit devices will present on D0-D7 if on odd address and D8-D15 if on an even address.  The schematic posted would lead me to believe that only the latter is supported in the design given.  It looks like DTB masters all need D08(EO) capability, and the schematic appears to only support D08(O)... unless I am missing something. :/

  Are you sure? yes | no

K.C. Lee wrote 01/12/2016 at 14:09 point

Might want to read Table 5-4. "Data Bus Requirements for Read Cycles" of the 68020 datasheet ("5.2.1 Dynamic Bus Sizing").  There is an internal mux that can access 8-bit transfer bytes on the each of the byte boundaries from the 32-bit data bus "Long-Word Port".

  Are you sure? yes | no

Jason Westervelt wrote 01/12/2016 at 18:13 point

I think I understand it now...

So the VME card would signify that it is a 16bit port as it drives DSACK0/DSACK1, and the internal multiplexer would then route the data internally based upon the value of A0...

Looks like I'll need to generate the necessary DS0/DS1 signals as well using DS/A0/SIZ0/SIZ1... fun times :)

  Are you sure? yes | no

K.C. Lee wrote 01/12/2016 at 18:55 point

My guess is that all these buffers are for steering a 32-bit data bus for 16-bit cards.  i.e. a card without P2 connector  If connected with a full 32-bit bus, the 020 is quite capable of steering internally.

Unless you really want to support actual VME cards, it is a bit too much overhead to use.  I would have gone for PCI.  :P

  Are you sure? yes | no

Jason Westervelt wrote 01/12/2016 at 20:11 point

PCI?  I thought that the multiplexing of Address and Data lines would be too much overhead...  Plus when I looked into it, I really didn't find any decent design examples that would point me in the right direction for ramming a 680x0 into the mix...

Luckily I started on this project to learn, so I have opportunities...:D

  Are you sure? yes | no

K.C. Lee wrote 01/12/2016 at 20:49 point

PCI relies on reflected wave, so it doesn't need extra high current driver like VME does.  So it boils down to big CPLD(s) for the mux, state machines to get the minimal PCI going.

Amiga to PCI  (68000 to PCI)  
http://krashan.ppa.pl/articles/prometheus/

PCI I/O card with discrete.
http://elm-chan.org/works/pci/report_e.html

oops.  It is Zorro III, so the data/address bus are muxed.

  Are you sure? yes | no

Jason Westervelt wrote 01/13/2016 at 20:59 point

PCI might be a good project for a later time.  I have to make sure I understand something simple before I jump into that fire.

  Are you sure? yes | no

Bharbour wrote 01/12/2016 at 03:45 point

Address A0 is not present on the VME bus because the DS1 and DS0 handle byte address stuff.

  Are you sure? yes | no