View 19889_709769.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

pcnet tm application examples application note advanced micro devices pcnet-isa to mc68000 pcnet-isa with a big endian processor
publication# 19889 rev. a amendment /0 issue date: june 1995 pcnet application examples application note mike keith & mike santoro advanced micro devices i. pcnet-isa controller in an embedded application interfacing to the motorola mc68000 microprocessor the design of an interface between the 68000 micro- processor and the pcnet-isa ethernet controller is presented. among the various design options available, and particularly whether the design effort is new or is an upgrade of an established lance-based design, one of two alternative design solutions may be optimal. a major consideration is whether established system software exists and must be preserved as is or whether the software can be revised and to what degree. new designs will obviously have greater freedom among design options; lance-based system upgrades may have very little. 19889a-1 802.3 mac core encoder/ decoder (pls) & aui port 10base-t mau isa bus interface unit aen iochrdy ior master memr memw sa0-19 sbhe sd0-15 dxcvr mausel/ ear xtal1 do+/- ci+/- di+/- rxd+/- txd+/- txp+/- bpcs led0-3 apcs tdo tms tdi tck jtag port control rcv fifo xmt fifo private bus control xtal2 ioam0,1 sleep te prdb0-7 fifo control isa config control buffer management unit dack irq drq iocs16 iow ref reset smemr la17-23 figure 1. pcnet ethernet controller (block diagram: bus master mode)
amd 2 pcnet application examples 19889a-2 802.3 mac core encoder/ decoder (pls) & aui port 10base-t mau isa bus interface unit aen iochrdy ior iow irq iocs16 memr memw reset sa0-9 sbhe sd0-15 dxcvr mausel/ ear xtal1 do+/- ci+/- di+/- rxd+/- txd+/- txp+/- bpcs led0-3 prab0-15 apcs tdo tms tdi tclk jtag port control rcv fifo xmt fifo private bus control xtal2 ioam0-1 sleep bpam smam sma te aboe prdb0-7 sroe srwe fifo control isa config control buffer management unit figure 2. pcnet ethernet controller (block diagram: shared memory mode) the pcnet-isa controller is a highly-integrated single- chip ethernet controller designed to interface directly with the pc/at industry standard architecture (isa) system bus. the pcnet-isa controller is 100 percent software compatible with the am7990 lance (local area network controller for ethernet). the simple and inexpensive hardware interface to the 68000 bus, the overwhelming advantage of preserving the investment in established system software for lance-based designs, and the device cost, power, performance, integration, and reliability benefits of the latest- genera- tion-technology make the pcnet-isa controller an ideal solution for advancing the state of the art in ethernet connectivity for the 68000. system architecture the hardware architectural design will affect system performance, material cost, real estate, software struc- ture, etc. there are several system architectural options to consider. block diagrams for the pcnet-isa in bus master mode and shared memory mode are shown in figures 1 and 2. bus-master architecture vs. shared-memory in the bus-master architecture, the pcnet-isa controller is allowed to arbitrate for and acquire control of the 68000 system bus. this provides the pcnet-isa controller with a dma path into system memory, through which data is exchanged with the 68000. in contrast, the shared-memory architecture requires additional dedicated memory coupled directly to the pcnet-isa controller for the exchange of information. this does save the 68000 from being preempted during the pcnet-isa controller data transfers, but carries the extra costs of: a) the additional memory components, b) the power they must be supplied, c) the increase in required real estate, and d) the reduction in system performance and cpu utilization associated with the need now to make an extra copy of all network data. a bus-master design is the architecture of choice; this will maintain software-compatibility with the lance (the lance does not support the shared-memory architecture). byte-swapping the 68000 is characterized as a big-endian machine; odd-addressed bytes reference data on the low-byte data lines d<0C7>, even-addressed bytes on the high-byte data lines d<8C15>. the pcnet-isa controller
amd 3 pcnet application examples is the opposite, a little-endian machine, where even- addressed bytes reference data on the low-byte data lines d<0C7> and odd-addressed bytes on the high-byte data lines d<8C15>. (unlike the lance, the pcnet-isa controller does not contain a byte-swapping mechanism which optionally config- ures it as a big-endian machine.) any byte-oriented data which both devices share access to, such as network packet data, will be inconsistently byte- ad- dressed between the two devices at the byte level. as an example, consider packet data being received and accepted by the pcnet-isa controller from the network and placed into system buffer memory. the first byte is placed into low-byte-memory at receive-buffer base-address-offset 0, the second byte at high-byte- memory offset-address 1. the 68000, however, will find the first byte at low-byte-memory address 1, the second byte at high-byte-memory address 0. the 68000 data is not in sequential order; it is not consistent with the pcnet-isa controllers representation of the data. this inconsistency occurs on all packet data, both transmit and receive. thus, it is seen that individual network data-bytes are addressed in memory by the pcnet-isa consistent with the construction of the network packet. the 68000 addressing is inconsistent with the network data. to link into a standard 802.3 network, some form of byte- swapping is required. (as an aside, it is interesting to note the implication of network systems with a 68000 and the pcnet-isa controller at each and every node. these systems could presumably communicate freely with one another without byte-swapping, even though the network data would not comply with the 802.3 specification. data would be reversed once when being transmitted onto the network, then reversed back again, to normal, at receptionthis would be transparent to the 68000 at each end. the difficulty with this scheme lies in the node addressing and automatic recognition by the pcnet-isa controller. if the address-field bytes are swapped, the node address must be compensated in order to recognize the targeted address; this may be simple to handle in a small dedicated network. the remainder of this discussion assumes full compliance with 802.3 networks.) consider now the distinction of word oriented (16-bit) data. while individual data bytes are not consistently addressed between the 68000 and the pcnet-isa controller, data words are. the bytes within the word are not addressed the same, but the word address is common to both devices. thus, for example, the most significant bit (msb) of the data at word-address 0 is the same bit for both devices and is transferred on d15. however, this bit is the msb of byte 0 for the 68000, byte 1 for the pcnet-isa controller. as a result, it is advantageous to have the non-network datathe descriptor ring, initialization block, and the pcnet-isa controller internal register dataorganized and accessed strictly as 16-bit words. this maintains consistent addressing between the two devices in this area which greatly reduces the complexity of the overall design, is quite easily implemented, and eliminates the need to byte-swap this data. it does require that all software accesses to this non-network data be coded as word accesses only. byte-swapping, therefore, is required only on the network data. there are at least three alternative byte-swapping solutions to consider: software swapthe 68000 can perform a byte-swap function in software. referring to network data, the first (byte #0, using byte addresses from the pcnet-isa controller point of reference) and all remaining even- addressed data-bytes are shifted down to the lower half of the data bus; the second (byte #1) and all remaining odd-addressed data-bytes are shifted up to the upper half of the data bus. this may be accomplished through series of move instructions or by an eight-position circular shift of data processed as 16-bit words. (note that there is a word-swap function in the 68000, but no byte-swap.) this will make the network-data byte- addresses consistent between the 68000 and the pcnet-isa controller. data must pass through this byte-swap filter on any transfer between the 68000 and any transmit or receive buffer. the overwhelming drawback of this approach is the significant reduction in system throughput and cpu performance associated with the inefficient and time consuming task of software-swapping each and every data byte which is transferred on the network. addition- ally, this option does not preserve lance software compatibility. while viable and possibly favorable under particular circumstances, this software-swap is rejected in lieu of more attractive alternatives. data-bus swapthe pcnet-isa controller data-bus can be hard-wired in reverse so as to provide the effect of a permanent byte-swap function. here, sd<0C7> is connected to high-byte memory, sd<8C15> is con- nected to low-byte memory. this scheme will maintain consistent addressing of all network data passing between the 68000 and the pcnet-isa controller. the major negative here is the impact on non-network data such as in accesses to the descriptor rings, the initialization block, or the pcnet-isa controller internal registers (as discussed above). now this data must be byte-swapped in order to negate the effects of the hard-wired swap. additionally, there is the confusion factor associated with keeping track of bit positions and data flows now that the data-bus is used in a non- standard mode. and, as before, lance-compatibility is no longer preserved.
amd 4 pcnet application examples the attraction to this option lies in the simplicity of the design. no special hardware is required to handle any byte-swapping. the byte-swapping on the non-network data may occur via: (i) a software filter, as discussed earlierthe system performance degradation associated with the software-swap of non-network data is small since these data transfers typically occur relatively infrequently and usually arent time critical. and the software function is fairly simple to implement. or, (ii) simply by redefining the bits in the non-network data registers and tablesthis is especially applicable to new software development efforts. if the definition of the bits in these registers/ tables are changed to reflect the effect of the data-bus swap, the software can then be designed to access this data properly and all is well and transparent to the overall system; the byte-swapping is accomplished in the system documentation. note that the danger of confusing bit positions or functions here is real and significant and must be cautiously considered. this data-bus swap design alternative is very attrac- tive, particularly to original design efforts. it is the basis for the first design example, detailed below. hardware-buffer swapthis alternative achieves full architectural and software compatibility with the lance. it consists of discrete hardware buffers to byte-swap network data while maintaining a standard and direct hardware and software interface to non- network data. the swapping occurs on the pcnet-isa controller data-bus. this isolates the swapping function from the remainder of the system. the obvious advantage here is backward compatibility with established lance system software. a lance-to- pcnet-isa controller system upgrade can be imple- mented entirely through hardware design. there is no need to revise software which may be mature and field-reliable. the only significant caveat here lies in the technique used to determine when to execute a swap. (recall that non-network data is not to be swapped.) there are no bus-cycle distinctions between the pcnet-isa con- troller accesses to network and non-network data. so how do you know when to make a swap? one possibility is to base the decision on the address used in the transfer: if the system memory map is partitioned into swap and no-swap areas, the swap decision can be made on a simple decode of the target address. this will obviously place restrictions on the locations available for network buffers (i.e., swap-memory only) and thus may impact lance backward-compatibility. this impact is expected to be minimal and easy to work around. alternatively, a different or more complex hardware-swap decision-mechanism may be able to match the existing software footprint and achieve the desired 100 percent compatibility. the costs of the hardware-buffer swap design are minimal and are detailed in the second design example, following. design examples the 68000-to-pcnet-isa controller data-bus swap and hardware-buffer swap design examples are illustrated in figures 3 through 11. the design options presented do not address the pcnet-isa controller interfaces to the network, the address prom, or the boot prom. these are inde- pendent interfaces which are not affected by the pcnet-isa controller system bus interface design. the one exception is the boot prom, a pc-specific function which will not typically apply to a 68000-based system. design notes the remainder of this document refers to figures 3 through 11: 1. description of diagrams: figure 3: block diagram figure 4: data-bus swap schematic, sheet 1 figure 5: data-bus swap schematic, sheet 2 figure 6: data-bus swap mach 110 design file figure 7: hardware-buffer swap schematic, sheet 1 figure 8: hardware-buffer swap schematic, sheet 2 figure 9: hardware-buffer swap mach 110 design file figure 10: address decode 16v8 design file figure 11: system memory map example 2. the following new signals are defined: pcncs_ pcnet-isa controller chip select memcs_ system memory chip select hmcs_ high-byte memory chip select lmcs_ low-byte memory chip select moe_ memory output enable mwe_ memory write enable iors_ i/o read strobe iows_ i/o write strobe s/r_ send/receive, transceiver direction control swap_ swap-transceiver enable noswap_ noswap-transceiver enable
amd 5 pcnet application examples 3. these designs meet worst-case timing with the parts indicated and with the 68000 running at its full speed of 16.67 mhz. 4. the system memory ics and the address decoding scheme are an example of minimal system resources only and are not necessarily recommendations for a specific implementation. 5. all 68000 accesses to the pcnet-isa controller and to non-network data should be coded as 16-bit accesses; the hardware is configured for operation as such. 6. pu pull-up and pd pull-down resistors are loosely recommended as 3.3k ohm resistors. these values must be carefully considered in an actual design which may differ considerably in specific areas. watch especially signal sa0 which is sure to have additional resources sharing its load. 7. the decision on whether or not to swap the data (via the transceivers) in the hardware-buffer swap design is made via address decoding per the discussion in the text. refer to figure 11. the system sram is fully shadowedall of the memory is accessible as either swapped or non-swapped data, as a function of a16. the example depicted is quite flexible and open to alternative schemes which may be tailored to an existing (i.e., lance-based system) software footprint. 8. the pcnet-isa controller bus-cycle control registers, msrda (in isacsr0) and mswra (in isacsr1), should be configured as follows: msrdaequal to 3 (minimum) for a 150 ns memr cycle minimum mswraequal to 1 (minimum) for a 50 ns memw cycle minimum 9. the mach110 design is partitioned into six major segments: bus master exchange, wait- state control, system memory control, hardware swap-buffer control, misc control, and misc. 10. the mach bus master exchange circuit: a. pcnet-isa controller output-signal master is not used. dack is its functional equiva- lent and is the indicator of the pcnet-isa controller bus-mastership when it is low. eliminating the use of master frees one mach pin. b. the two flip-flops used to generate ml1 and ml2 act as a synchronizing circuit to capture the asynchronous ( drq + dack_) term. this is to minimize metastable susceptibility in the generation of bgack . 11. the mach wait-state control circuit: a. a minimum of two 68000 wait-states are inserted on 68000-to-pcnet-isa controller accesses. b. dtack_ is a totem-pole-output wait-state control signal. to provide a wired-or capa- bility for other system resources to insert 68000 wait-states via dtack_ control, the open-drain and unused signal zdtack_ is availablesimply use zdtack_ (with a pull-up resistor, of course) instead of dtack_. as implemented, zdtack_ may insert an additional (i.e., three, minimum) wait-state if worst case timing occurs. if this cannot be tolerated, a faster mach device is needed. c. the iochrdy output from the pcnet-isa controller may or may not become active to insert additional 68000 wait-states in 68000-to-pcnet-isa controller accesses. iochrdy can be expected to insert addi- tional wait-states under two conditions: (a) rapid back-to-back pcnet-isa controller accesses, or (b) accesses to private and slow pcnet-isa controller resources such as the address prom. 12. the mach misc control circuit: 68000 interrupts are configured for the auto vector mode via fc and vpa_. 13. the two 74f32 or-gates are required so as to meet the pcnet-isa controller address hold time requirements. 14. the pld designs were compiled on amds palasm 4, version 1.5. 15. disclaimer! caution: this design has not been prototyped. no design verification of any physical circuitry has occurred at this time. references 1. ethernet/ieee 802.3 family 1994 world network data book/handbook, amd pid# 14287c. 2. am79c960 pcnet-isa controller technical manual, may 1992, amd pid# 16850b. 3. hilf, werner and nausch, anton, the 68000 family, volumes 1 and 2 (englewood cliffs: prentice hall, 1989). isbn# 0-13-541525-x. 4. mach family data book, high density ee cmos programmable logic, summer 1992, amd pid# 14051f. 5. mach technical briefs, 1991, amd pid# 15972a.
amd 6 pcnet application examples 6. m68000 family reference, 1990, motorola reference # m68000fr/ad. 7. 8-/16-/32-bit microprocessor users manual, eighth edition, motorola reference # m68000um/ad rev 7. 8. m68000 electrical specifications, motorola semiconductor technical data, motorola reference # m68000ec/d. 9. solari, edward, at bus design (san diego: annabooks, 1991). isbn# 0-929392-08-6. 19889a-3 68000 address decode system memory interface logic pcnet-isa 79c960 byte-swap (note) addr data mach110 data bus 16v8 addr bus addr data data addr standard 68000 system resources pcnet-isa specific resources note - either: 1. byte-swap buffers, or 2. hard-wired data-bus swap. dotted control line used in note 1, not in note 2. figure 3. pcnet-isa-to-68k interfaceblock diagram
amd 7 pcnet application examples mc68000p-16 25 24 23 6 13 11 12 10 28 27 26 21 7 8 9 15 pu pu pu 13 5 14 36 7 21 38 43 6 18 19 11 35 33 32 30 31 pu pu pu pu as br bg bgack dtack fc0 fc1 fc2 vpa uds lds r /w clk pcncs memcs hmcs lmcs iors iows drq dack iochrdy sbhe memr memw a0 moe mwe 25 28 10 3 16 20 17 9 1 2 3 4 5 6 49 50 47 42 44 54 13 40 39 pu pu pd pu pd pu pu nc nc nc nc pd sa0 74f32 74f32 "68k_isa_a" mach110-20jc ipl0 ipl1 ipl2 (ts) as br (tp) bg bgack dtack (ts) fc0 (ts) fc1 (ts) fc2 vpa (ts) uds (ts) lds (ts) r /w clk (ts) a(1?3) (ts) d(0?5) osc 16.67 mhz 8 27 4 to sheet 2 pu 53 45 48 51 57 58 sa(0?9) (ts) la(17?3) (ts) sd(0?5) (ts) master (oc) ioam1 ioam0 smemr ref iocs16 (od) aen memw (ts) memr (ts) sbhe (ts) iochrdy (od) dack drq (ts) iow ior irq (od) am79c960kc pcnet-isa 41 notes: (ts) denotes tri-state output (tp) denotes totem-pole output (od) denotes open-drain output (oc) denotes open-collector output 19889a-4 figure 4. pcnet-isa-to-68k interfacedata-bus swap (sheet 1)
amd 8 pcnet application examples 19889a-5 standard 68k system resources 1 2 3 4 5 6 7 8 9 11 12 13 14 15 16 17 18 19 a23 a22 a21 a20 a19 a18 a17 palce16v8h-25 address decode nc f0 f1 f2 f3 f4 f5 f6 f7 i0 i1 i2 i3 i4 i5 i6 i7 pcncs memcs nc nc nc nc nc nc nc nc i8 i9 a (1?3) sa (0?9) la (17?3) a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 10 9 8 7 6 5 4 3 25 24 a (17?3) a (1?5) sram 32kx8 low-byte memory ?d43256ac-85l 21 23 2 26 1 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a0 i/o1 i/o2 i/o3 i/o4 i/o5 i/o6 i/o7 i/o8 d1 d2 d3 d4 d5 d6 d7 d0 12 13 15 16 17 18 19 11 10 9 8 7 6 5 4 3 25 24 21 23 2 26 1 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a0 cs oe we i/o1 i/o2 i/o3 i/o4 i/o5 i/o6 i/o7 i/o8 cs oe we 20 22 27 lmcs moe mwe d9 d10 d11 d12 d13 d14 d15 d8 12 13 15 16 17 18 19 11 20 22 27 hmcs moe mwe sram 32kx8 high-byte memory ?d43256ac-85l a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 sa1 sa2 sa3 sa4 sa5 sa6 sa7 sa8 sa9 sa10 sa11 sa12 sa13 sa14 sa15 sa16 sa17 sa18 sa19 sa0 a20 a21 a22 a23 la20 la21 la22 la23 la17 la18 la19 nc nc nc pcnet-isa specific resources standard 68k system resources d (0?5) to sheet 1 to sheet 1 nc d9 d10 d11 d12 d13 d14 d15 d8 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd0 d1 d2 d3 d4 d5 d6 d7 d0 sd9 sd10 sd11 sd12 sd13 sd14 sd15 sd8 sd (0?5) figure 5. pcnet-isa-to-68k interfacedata-bus swap (sheet 2)
amd 9 pcnet application examples title 68k-to-pcnet-isa interface, with data-bus swap pattern revision 0 author mike keith, field applications engineer company advanced micro devices date 2/17/93 chip _68k_isa_a mach110 ; pin declarations pin 2 zdtack_ combinatorial ; output pin 8 a0 ; input pin 11 r_w_ ; input pin 13 as_ ; input pin 33 pcncs_ ; input pin 17 memr_ ; input pin 9 memw_ ; input pin 32 memcs_ ; input pin 18 uds_ ; input pin 19 lds_ ; input pin 20 sbhe_ ; input pin 4 mwe_ combinatorial ; output pin 27 moe_ combinatorial ; output pin 31 lmcs_ combinatorial ; output pin 30 hmcs_ combinatorial ; output pin 28 iows_ combinatorial ; output pin 25 iors_ combinatorial ; output pin 35 clk ; input pin 14 bg_ ; input pin 10 drq ; input pin 16 iochrdy ; input pin 21 fc0 ; input pin 38 fc1 ; input pin 43 fc2 ; input pin 6 vpa_ combinatorial ; output pin 7 dtack_ registered ; output node 8 q0 registered ; feedback node 28 brs_ registered ; feedback node 30 ml2_ registered ; feedback node 29 ml1_ registered ; feedback pin 3 dack_ combinatorial ; output pin 36 bgack_ combinatorial ; output pin 5 br_ combinatorial ; output figure 6. mach 110 design filedata-bus swap mach110 design file68000-to-pcnet-isa with data-bus swap
amd 10 pcnet application examples node 1 global equations ;- bus master exchange: dack_ = /(as_ * /(bg_ * bgack_) ) bgack_ = ( drq + dack_) + ml2_ ml1_ := drq + dack_ ml2_ := ml1_ brs_ := ml2_ br_ = /(brs_ * drq) ;- wait state control: q0 := as_ + pcncs_ + dtack _ dtack_ := q0 + as_ q0.rstf = iochrdy dtack_.rstf = iochrdy zdtack_ = gnd ;if needed: tri-state form of dtack_ zdtack_.trst = dtack _ ;if needed: tri-state form of dtack_ ;- system memory control: moe_ = memcs_ + (memr_ * (/r_w_ + dack _)) mwe_ = memcs_ + (memw_ * r_w_) hmcs_ = memcs_ + (uds_ * (sbhe_+ dack_)) lmcs_ = memcs_ + (lds_ * (a0 + dack_)) ;- misc control: vpa_ = /(fc0 * fc1 * fc2 * as _) ; 68k autovector interrupts iors_ = /r_w_ + pcncs_ + as_ iows_ = r_w_ + pcncs_ + as_ ;- misc: ml1_.clkf = clk ml2_.clkf = clk brs_.clkf = clk q0.clkf = clk dtack_.clkf = clk ml1_.rstf = gnd ml2_.rstf = gnd brs_.rstf = gnd global.setf = gnd 19889a-6 figure 6. data-bus swap mach 110 design file (continued) mach110 design file68000-to-pcnet-isa with data-bus swap
amd 11 pcnet application examples mc68000p-16 25 24 23 6 13 11 12 10 28 27 26 21 7 8 9 15 pu pu pu 13 5 14 36 7 21 38 43 6 18 19 11 35 33 32 30 31 pu pu pu pu as br bg bgack dtack fc0 fc1 fc2 vpa uds lds r /w clk pcncs memcs hmcs lmcs iors iows drq dack iochrdy sbhe memr memw a0 moe mwe 25 28 10 3 16 20 17 9 1 2 3 4 5 6 49 50 47 42 44 54 13 40 39 pu pu pd pu pu pu pu nc nc nc nc pd sa0 74f32 74f32 "68k_isa_b" mach110-20jc ipl0 ipl1 ipl2 (ts) as br (ts) bg bgack dtack (ts) fc0 (ts) fc1 (ts) fc2 vpa (ts) uds (ts) lds (ts) r /w clk (ts) a(1?3) (ts) d(0?5) osc 16.67 mhz 8 27 4 to sheet 2 pu 53 45 48 51 57 58 sa(0?9) (ts) la(17?3) (ts) sd(0?5) (ts) master (oc) ioam1 ioam0 smemr ref iocs16 (od) aen memw (ts) memr (ts) sbhe (ts) iochrdy (od) dack drq (ts) iow ior irq (od) am79c960kc pcnet-isa 29 37 24 s /r swap noswap 15 sa16 a16 41 notes: (ts) denotes tri-state output (tp) denotes totem-pole output (od) denotes open-drain output (oc) denotes open-collector output 19889a-7 figure 7. pcnet-isa-to-68k interfacehardware-buffer swap (sheet 1)
amd 12 pcnet application examples standard 68k system resources 1 2 3 4 5 6 7 8 9 11 12 13 14 15 16 17 18 19 a23 a22 a21 a20 a19 a18 a17 palce16v8h-25 address decode nc f0 f1 f2 f3 f4 f5 f6 f7 i0 i1 i2 i3 i4 i5 i6 i7 pcncs memcs nc nc nc nc nc nc nc nc i8 i9 a (1?3) sa (0?9) la (17?3) a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 10 9 8 7 6 5 4 3 25 24 a(17?3) a(1?5) sram 32kx8 low-byte memory ?d43256ac-85l 21 23 2 26 1 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a0 i/o1 i/o2 i/o3 i/o4 i/o5 i/o6 i/o7 i/o8 d1 d2 d3 d4 d5 d6 d7 d0 12 13 15 16 17 18 19 11 10 9 8 7 6 5 4 3 25 24 21 23 2 26 1 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a0 cs oe we i/o1 i/o2 i/o3 i/o4 i/o5 i/o6 i/o7 i/o8 cs oe we 20 22 27 lmcs moe mwe d9 d10 d11 d12 d13 d14 d15 d8 12 13 15 16 17 18 19 11 20 22 27 hmcs moe mwe sram 32kx8 high-byte memory ?d43256ac-85l a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 sa1 sa2 sa3 sa4 sa5 sa6 sa7 sa8 sa9 sa10 sa11 sa12 sa13 sa14 sa15 sa16 sa17 sa18 sa19 sa0 a20 a21 a22 a23 la20 la21 la22 la23 la17 la18 la19 nc nc nc pcnet-isa specific resources standard 68k system resources d (0?5) to sheet 1 74f245 b1 b2 b3 b4 b5 b6 b7 b8 a1 a2 a3 a4 a5 a6 a7 a8 g dir 2 3 4 5 6 7 8 9 19 1 18 17 16 15 14 13 12 11 d1 d2 d3 d4 d5 d6 d7 d0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd0 74f245 b1 b2 b3 b4 b5 b6 b7 b8 a1 a2 a3 a4 a5 a6 a7 a8 g dir 2 3 4 5 6 7 8 9 19 1 18 17 16 15 14 13 12 11 d1 d2 d3 d4 d5 d6 d7 d0 sd9 sd10 sd11 sd12 sd13 sd14 sd15 sd8 74f245 b1 b2 b3 b4 b5 b6 b7 b8 a1 a2 a3 a4 a5 a6 a7 a8 g dir 2 3 4 5 6 7 8 9 19 1 18 17 16 15 14 13 12 11 d9 d10 d11 d12 d13 d14 d15 d8 sd9 sd10 sd11 sd12 sd13 sd14 sd15 sd8 74f245 b1 b2 b3 b4 b5 b6 b7 b8 a1 a2 a3 a4 a5 a6 a7 a8 g dir 2 3 4 5 6 7 8 9 19 1 18 17 16 15 14 13 12 11 d9 d10 d11 d12 d13 d14 d15 d8 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd0 sd (0?5) s /r noswap swap to sheet 1 pcnet-isa specific resources byte-swap buffers nc noswap s /r swap s /r noswap s /r swap s /r 19889a-8 figure 8. pcnet-isa-to-68k interfacehardware-buffer swap (sheet 2)
amd 13 pcnet application examples title 68k-to-pcnet-isa interface, with hardware-buffer swap pattern revision 0 author mike keith, field applications engineer company advanced micro devices date 2/17/93 chip _68k_isa_b mach110 ; pin declarations pin 2 zdtack_ combinatorial ; output pin 8 a0 ; input pin 15 a16 ; input pin 11 r_w_ ; input pin 13 as_ ; input pin 33 pcncs_ ; input pin 17 memr_ ; input pin 9 memw_ ; input pin 32 memcs_ ; input pin 18 uds_ ; input pin 19 lds_ ; input pin 20 sbhe_ ; input pin 24 noswap_ combinatorial ; output pin 37 swap_ combinatorial ; output pin 29 s_r_ combinatorial ; output pin 4 mwe_ combinatorial ; output pin 27 moe_ combinatorial ; output pin 31 lmcs_ combinatorial ; output pin 30 hmcs_ combinatorial ; output pin 28 iows_ combinatorial ; output pin 25 iors_ combinatorial ; output pin 35 clk ; input pin 14 bg_ ; input pin 10 drq ; input pin 16 iochrdy ; input pin 21 fc0 ; input pin 38 fc1 ; input pin 43 fc2 ; input pin 6 vpa_ combinatorial ; output pin 7 dtack_ registered ; output node 8 q0 registered ; feedback node 28 brs_ registered ; feedback node 30 ml2_ registered ; feedback figure 9. mach110 design file68000-to-pcnet-isa with hardware-buffer swap
amd 14 pcnet application examples node 29 ml1_ registered ; feedback pin 3 dack_ combinatorial ; output pin 36 bgack_ combinatorial ; output pin 5 br_ combinatorial ; output node 1 global equations ;- bus master exchange: dack_ = /(as_ * /(bg_ * bgack_) ) bgack_ = (/drq + dack_) + ml2_ ml1_ := /drq + dack_ ml2_ := ml1_ brs_ := ml2_ br_ = /(brs_ * drq) ;- wait state control: q0 := as_ + pcncs_ + dtack _ dtack_ := q0 + as_ q0.rstf = iochrdy dtack_.rstf = iochrdy zdtack_ = gnd ;if needed: tri-state form of dtack_ zdtack_.trst = dtack _ ;if needed: tri-state form of dtack_ ;- system memory control: moe_ = memcs_ + (memr_ * (/r_w_ + dack _)) mwe_ = memcs_ + (memw_ * r_w_) hmcs_ = memcs_ + (uds_ * (a0 + a16 + dack_) * (sbhe_ + /a16 + dack_)) lmcs_ = memcs_ + (lds_ * (a0 + /a16 + dack_) * (sbhe_ + a16 + dack_)) ;- hardware swap-buffer control: noswap_ = ((pcncs_ + r _w_ + (uds_ * lds_)) ; 68k reads pcnet * (pcncs_ + r_w_) ; 68k writes pcnet * (memcs_ + dack_ + /a16 + memr_) ; pcnet reads noswap mem * (memcs_ + dack_ + /a16 + mwe_)) ; pcnet writes noswap mem swap_ = /noswap_ + ((memcs_ + dack_ + a16 + memr_) ; pcnet reads swap mem * (memcs_ + dack_ + a16 + mwe_)) ; pcnet writes swap mem s_r_ = (/pcncs_ * r_w_ * (/uds_ + /lds_) ) ; 68k reads pcnet + (/memcs_ * dack _ * memr_) ; pcnet writes mem ;- misc control: vpa_ = /(fc0 * fc1 * fc2 * /as_) ; 68k autovector interrupts iors_ = /r_w_ + pcncs_ + as_ iows_ = r_w_ + pcncs_ + as_ figure 9. mach110 design file68000-to-pcnet-isa with hardware-buffer swap (continued)
amd 15 pcnet application examples ;- misc: ml1_.clkf = clk ml2_.clkf = clk brs_.clkf = clk q0.clkf = clk dtack_.clkf = clk ml1_.rstf = gnd ml2_.rstf = gnd brs_.rstf = gnd global.setf = gnd 19889a-9 figure 9. mach110 design file68000-to-pcnet-isa with hardware-buffer swap (continued) title address decode68k-to-pcnet i/f pattern revision 0 author mike keith, field applications engineer company advanced micro devices date 2/17/93 chip _decode palce16v8 ; pin declarations pin 1 a23 ; input pin 2 a22 ; input pin 3 a21 ; input pin 4 a20 ; input pin 5 a19 ; input pin 6 a18 ; input pin 7 a17 ; input pin 13 pcncs_ combinatorial ; output pin 14 memcs_ combinatorial ; output equations memcs_ = /a17 + a23+a22+a21+a20+a19+a18 pcncs_ = a17 + a23+a22+a21+a20+a19+a18 19889a-10 figure 10. 16v8 design fileaddress decode
amd 16 pcnet application examples 19889a-11 a23 a22 a21 a20 a19 a18 a17 a16 a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0 000000 if a17 = 1: 1 = noswap 0 = swap; only pcnet-to-memory can be swapped if a17 = 0: don't care, noswap 1 = system memory: 0 = i/o (noswap): to system memory and i/o system memory noswap system memory swap i/o noswap i/o noswap 64k a16 = 1 non-network data goes here 64k a16 = 0 network data goes here 64k a16 = 1 64k a16 = 0 i/o shadowed here (64k block aliased) memory shadowed here (64k block aliased) a17 = 1 128k a17 = 0 128k memory map address bus a16 a17 chip select function pcncs memcs memcs pcncs figure 11. memory map example (applies to hardware-buffer swap only) 19889a-12 d d clk iochrdy q pcncs as q0 ar dtack zdtack q ar figure 12. wait state control unit
amd 17 pcnet application examples clk as ior dtack addr iochrdy=1 q0 data (out of pcnet) 0 30 60 90 120 150 180 210 240 270 300 330 360 s0 s1 s2 s3 s4 s5 s6 s7 s0 w1 w2 valid 90 300 valid 307 117 227 327 132 252 192 312 210 270 dtack latched by 68k data latched by 68k (16.67 mhz) 19889a-13 figure 13a. wait state control timing diagram (68k reads pcnet, iochrdy=1)
amd 18 pcnet application examples clk (16.67 mhz) as ior dtack addr iochrdy q0 data 0 30 60 90 120 150 180 210 240 270 300 330 360 390 410 440 470 500 s0 s1 s2 s3 s4 s5 s6 s7 s0 wwwwww w w valid 90 470 valid 477 117 287 497 152 277 132 312 422 372 482 390 440 C125C dtack latched by 68k data latched by 68k 19889a-14 figure 13b. wait state control timing diagram (68k reads pcnet with waits inserted via iochrdy)
amd 19 pcnet application examples 19889a-15 d d d as bg clk drq ff1 ff2 ff3 brs ml2 ml1 br bgack dack qqq cmk figure 14. bus master exchange circuit drq 68k pcnet 1 1 1 0 0 0 pcnet has acquired bus (3 x clk) 0 1 1 1 1 1 (2 x clk) br bg dack master bgack 0 1 1 1 1 1 68k has bus (default) 68k has bus pcnet tristates bus 68k tristates bus 19889a-16 figure 15. bus master exchange timing diagram
amd 20 pcnet application examples ii. using the pcnet-isa controller with a big endian processor the pcnet-isa controller (am79c960) is an excellent general purpose ethernet controller. one of its strong- est features is buffer management. its buffer manage- ment is very similar to the buffer management of the am7990 lance (local area network controller for ethernet) [and the new am79c90 c-lance (cmos version of the am7990 lance)], another industry standard ethernet controller chip from amd. unlike the lance, the pcnet-isa controller has separate transmit and receive fifos for ethernet packets. the transmit fifo is 136 bytes deep, and the receive fifo is 128 bytes deep. the pcnet-isa controller also has an onboard 10base-t transceiver as well as an onboard manchester encoder/decoder which can interface to a 10base-t, 10base2 or 10base5 maus (media attachment unit). other features of the pcnet-isa controller include: external address detect interface, dynamic transmit fcs generation on a packet by packet basis, power down modes and jtag support. the bus interface of the pcnet-isa controller was designed to be compatible to the isa pc bus. this bus architecture is very similar to the buses of iapx processors. the pcnet-isa controller has the capability to tune the read/write timing on its isa bus interface. this allows the pcnet-isa controller to interface to many clone pcs as well as provide interface flexibility to a wide range of processors. the pcnet-isa controller may tune its read/write pulse width between 50 and 750 ns, which gives the pcnet-isa controller a maxi- mum throughput rate of 150 ns/word (with 50 ns read/write pulse width). the pcnet-isa controller is very easy to interface to iapx processors. the pcnet-isa controller can also be interfaced to motorola 68000 class processors. the reader can reference the lance (am7990) technical manual (contained in the 1992 world network data book/handbook pid# 14287b ) for details of interfac- ing a 68000 to a lance. while the lance and the pcnet-isa controller do not have identical interfaces, they are somewhat similar, and this application note will give the user a feel for how to treat interface signals. (the user can also refer to the 1994 ethernet/ieee 802.3 family data book/handbook, pid# 14287c for a complete description of the am79c90 c-lance; cmos, pin-compatible version of the am7990 lance.) (note: the reader should also refer to the application note titled interfacing the motorola m68000 micropro- cessor to the pcnet-isa am79c960 ethernet control- ler by mike keith senior fae, for additional information on byte swapping techniques to those discussed in this application note.) there are issues relating to byte swapping high and low order bytes when interfacing the pcnet-isa controller to a 68000 class of processor, or any processor that is a big endian processor. the rest of this application note will propose several solutions to dealing with byte swapping. big endian versus little endian the pcnet-isa controller device is a little endian device and only supports that byte orientation, unlike the lance which supports both little and big endian. a big endian device associates lower order addresses with higher order bytes (reference figure 16b). a 68000 has a big endian format. a little endian device associ- ates lower order addresses with lower order bytes (reference figure 16a). iapx processors are little endian devices. note, some devices like the amd 29000 family can support either byte orientation. the relation of address bits for byte lane accessing is different for big versus little endian devices. for big endian devices: (lower addresses are associ- ated with higher order bytes, refer to figure 16b): a<4:0> = <00000>, accesses byte 0, bits<15:8> a<4:0> = <00001>, accesses byte 1, bits<7:0> for little endian devices (lower addresses are associ- ated with lower order bytes, refer to figure 16a): a<4:0> = <00000>, accesses byte 0, bits<7:0> a<4:0> = <00001>, accesses byte 1, bits<15:8> endian issues for the pcnet-isa controller the pcnet-isa controller is a little endian device. there is no byte orientation problem when using the pcnet- isa controller with a little endian processor. to under- stand the issues regarding mixing a the pcnet-isa controller with a big endian processor, it is necessary to examine the types of data transfers with which the pcnet-isa controller can be involved. the pcnet-isa controller deals with two classes of transfers (reference figure 17: basic system block diagram). 1) slave mode reads and writes. for these types of transfers, the pcnet-isa controller is a slave to the processor, reacting to the processors control signals. in these types of transfers, the processor is accessing the pcnet-isa controller internal registers for the purpose of configuring or reading the status of the pcnet-isa controller. 2) master mode reads and writes. for these types of accesses, the pcnet-isa controller is in control of its interface bus and is controlling
amd 21 pcnet application examples reads and writes to system memory. the pcnet-isa controller is performing dmas to and from memory during these transfers. there are two types of transfers within the master mode class: a) ring descriptor transfers: the pcnet-isa controller is dealing with descriptor ring data. in this case, the pcnet-isa controller is moving data between its internal registers and external memory. descriptor rings are data structures in memory which are associ- ated with the ethernet transmit and receive packets. they define the locations of trans- mit/receive buffers and contain status relat- ing to transmit/receive packets. the pcnet-isa controller and the processor both access the ring descriptors. b) transmit/receive fifo data transfers: the pcnet-isa controller is dealing with ethernet packet data. the pcnet-isa controller is either moving data to be transmitted (onto ethernet) from memory into its transmit fifo, or moving data received from the ethernet from its receive fifo to memory. the pcnet-isa controller and the processor both access the transmit/receive data buffer memory. for all types of transfers that involve the pcnet-isa controller internal registers, the endian-ness of the processor versus the pcnet-isa controller should not be an issue. (this would include slave mode read/writes and master mode descriptor ring transfers.) effectively, for all these types of transfers, the pcnet-isa controller does not care about byte ordering as implied by the endian-ness of a processor. the pcnet-isa controller only cares that the specification of its bit definitions for internal registers be met. for example, csr0 (control status register 0 [refer- ence figure 18a]) defines certain status bits of the pcnet-isa controller. notice that the definition of the register is on a per bit basis and this bit definition must be adhered to by the processor interfacing to the pcnet-isa controller. relating to descriptor rings, figure 18b shows the transmit descriptor ring 1 (tmd1). note that similar to the status registers, the descriptor rings have bit level definitions that a processor must adhered to. for both these examples, the processor must adhere to the definition of bits as required by the pcnet-isa controller to have the pcnet-isa controller operate correctly. therefore, the driver code dealing with the pcnet-isa controller must store constants, generate bit patterns, and output and input data accordingly. the one area remaining is master mode transfers that transfer transmit/receive data to and from the pcnet-isa controller internal fifos. proper byte orien- tation is imperative for these transfers. there is a relationship between which byte of a word is taken from the transmit fifo and sent onto the ethernet first. assuming the pcnet-isa controller performs an aligned word read access from memory (with a0 = 0), the data on data bits <7:0> will be loaded into location of the pcnet-isa controllers transmit fifo. bits<15:8> will be loaded into location n+1 of the fifo. fifo location n will be transmitted first. there will therefore be a problem when interfacing to a big endian processor because the serial data stream transmitted onto the ethernet will be out of order. similarly, receive data will be out of order. possible solutions the issues of interfacing the pcnet-isa controller to a big endian processor may be solved with either software or hardware, or a combination of hardware and software. as described above, master mode transmit and receive transfers care about endian-ness, whereas other transfer types dont care. three solutions will be proposed. solution #1 utilizes software only. solution #2 reverse wires the data buses between the pcnet-isa controller and the big endian processor. there is some software help required for this solution. solution #3, the most hardware intense, adds byte swap logic into the path between the pcnet-isa controller and the big endian processor. solution i. software only this solution proposes that the data in the pcnet-isa controller transmit and receive buffers (in external memory) is byte swapped by the processor. code must be added to byte swap the data in these buffers. for transmit buffers, the transmit data is usually moved from some application area to the pcnet-isa controller transmit buffer memory space, then transmitted onto the ethernet by the pcnet-isa controller. when this data movement is being performed bytes can be swapped as the data is being moved by the processor. this will position the bytes in the correct order for serialization onto the ethernet. for receive buffers, the received data is usually moved from the pcnet-isa controller receive buffers in memory to an application area of memory. at the time this data movement occurs bytes can then be swapped by the processor so that data is now byte ordered as the application expects. performance impact of solution 1: additional code to swap bytes need only be added in the driver code for the pcnet-isa controller. this change should not affect upper layer software which one might want to be portable to different systems. the addition of instruction(s) to perform the byte swap should not add much time to the transmit or receive code. some processors have single cycle byte swap instructions (for example, 68040). however, each design should consider the performance impact of this additional
amd 22 pcnet application examples code based on the specifics of their design (processor speed and time required to do byte swap). this solution does burden every 16 bit word that is transmitted or received with at least one additional line of code that needs to be executed. solution ii. hardware/software (reverse data bus wiring and software workarounds) another approach to the problem is to take care of the master mode data buffer transfers by cross wiring the busses between the pcnet-isa controller and the processor/memory (reference figure 19). the byte swapping required for the pcnet-isa controller master mode transmit/receive buffer accesses is now accom- plished by a hardwired swapping of high order and low order bytes. the processor will read and write bytes in memory in its natural way, big endian. the pcnet-isa controller will read and write bytes in memory in a swapped order from the processor which will make the positioning look like little endian for the pcnet-isa controller. now the problem of slave mode and master mode ring buffer accesses must be addressed. one approach to the problem is to perform a byte swap in software for the pcnet-isa controller slave and ring buffer accesses (performed by the processor). this method adds some software delay for the pcnet-isa controller register and ring buffer accesses. another approach could be to use software tools to get around the problem. the pcnet-isa controller does not care about byte ordering for slave or ring buffer accesses. it only requires that its bit definition be adhered to. by cross wiring the buses, we have tied bit 0 of the processor to bit 8 of the pcnet-isa controller, and software must take this into account. for this issue, one can use the facilitates of a high level language compiler or assembler to relate mnemonics to bit positions and make this transparent to the programmer. using software tools to make the bit swapping transparent should not increase software overhead when dealing with the pcnet-isa controller registers or the ring buffers. performance impact of solution 2: the performance impact of solution #2 will probably be less than the impact of the software only solution, solution #1. access to transmit/receive data buffers will be performed more often than the pcnet-isa controller resister and ring buffer accesses. byte swap code added to deal with transmit/receive data will be exe- cuted more often than byte swap code dealing with ring buffers/the pcnet-isa controller registers. beyond that, the transfer types that must be addressed in software with this solution (ring buffer accesses and internal registers) can be handled by software tools rather than performing byte swapping in software which adds cycles to code. solution iii. hardware only as stated previously, the only transfers that care about byte orientation are transmit/receive data buffer trans- fers dealing with the pcnet-isa controller controllers fifos. to address this situation in hardware, it is necessary to add byte swap logic between the pcnet- isa controller and memory. this byte swap logic is enabled only when the pcnet-isa controller is perform- ing master mode accesses to data memory (reference figure 20). all other types of transfers as previously discussed need not be byte swapped. (note: refer to previous section entitled interfacing the motorola m68000 microprocessor to the pcnet-isa am79c960 ethernet controller by mike keith.) figure 20 shows logically how the byte swapping hardware should work. referencing to figure 20; the address decoder determines when the pcnet-isa controller is accessing transmit/receive buffer memory. the address decode logic generates an enable to the byte swap logic. when enable is asserted, the byte swap logic will swap bytes to/from the pcnet-isa controller. the byte swap logic must also know the direction of transfer (read or write). figure 20 also shows logically, that when bytes are being swapped, that byte write enables must also be swapped to the memory banks, such that a pcnet-isa controller byte write modifies the proper memory bank. there is a system level implication in that the address decoder logic must know the address space of the pcnet-isa controllers transmit/receive buffers since this is the only time the byte swap logic should be enabled. there is some implication in that this address area for transmit/receive buffers must be fixed and remain fixed. some hardware implementation details relating to this solution are discussed in the following section entitled implementation discussion for solution #3. performance impact of solution 3: the byte swap hardware adds delay into the path between the pcnet-isa controller and the big endian processor, and the pcnet-isa controller and memory, for all types of the pcnet-isa controller accesses. as long as this addition delay does not add wait states when: 1) the processor is accessing the pcnet-isa controller registers, or 2) when the pcnet-isa controller is accessing memory, then this solution has no perform- ance impact. conclusions the pcnet-isa ethernet controller is a very flexible and powerful controller for ethernet. while it has an interface optimized for the isa bus, it can be easily used with iapx processors. the pcnet-isa controller can also be used with other processors such as motorola 68k class processors.
amd 23 pcnet application examples one consideration for interfacing to various processors is the question whether the processor is big or little endian. the pcnet-isa controller is a little endian device. when interfacing to a big endian processor, there are several solutions possible in both hardware and software. the software solutions are fairly reasonable and portable. many of the software issues can be addressed using facilities available in high level language compil- ers or assemblers. the software overhead for perform- ing byte swapping where necessary will probably not hinder performance. the system designer should determine performance impact based on processor speed and instruction set. solution # 1 requires no additional hardware nor add any additional logic delay in the data paths of the pcnet-isa controller. solution # 2 will probably have less performance impact than solution # 1. in each case, the impact of ease of understanding and maintenance from the software viewpoint should also be considered. solution #3 will add some logic to the design. in some cases, some of the logic required for address decoding may be combined with existing logic. additional delays may be incurred by adding byte swap logic, depending on how the byte swap logic is implemented. for those designs where the pcnet-isa controller already has a set of transceivers, additional byte swap transceivers as suggested in appendix a add no extra delay to the path between the pcnet-isa controller and memory. byte 1 byte 0 byte 3 byte 2 15 8 7 0 a4 a3 a2 a1 0000 0001 0010 0011 (a) little endian a0=1 a0=0 byte 0 byte 1 byte 2 byte 3 a4 a3 a2 a1 0000 0001 0010 0011 19889a-17 (b) big endian a0=0 a0=1 15 8 7 0 figure 16. big endian/little endian orientation micro processor pcnet-isa memory 19889a-18 figure 17. basic system block diagram
amd 24 pcnet application examples err babl cerr miss merr rint tint idon init strt stop tdmd txon rxon inea intr 15 0 14131211109 87 6543 21 19889a-19 figure 18a. example of pcnet-isa csr0 enp stp def one more res err own 15 8 7 0 hadr 14 13 12 11 10 9 19889a-20 figure 18b. example transmit descriptor ring tmd1
amd 25 pcnet application examples d<0:7> d<8:15> micro processor 0 7 8 15 07 815 0 7 8 15 d<0:7> d<8:15> pcnet-isa memory <0:7> <8:15> 19889a-21 figure 19. byte reverse wiring
amd 26 pcnet application examples sa<0:3> master address decoder enable big endian micro processor pcnet-isa bank a wr rd memw memr sd<0:7> sd<8:15> byte swap logic <0:7> 4 <8:15> w y x z bank b processor byte write logic pcnet-isa byte write logic wrb wra byte swap path combinations enable = 0 enable = 1 w-x, y-z w-z, x-y memory 19889a-22 figure 20. logical block diagram for byte swap
amd 27 pcnet application examples m u x 0 1 1 m u x 0 1 1 m u x 0 1 1 m u x 0 1 1 sa0 sa1 sa2 sa3 4 adr reg 4 clock load sd<0:3> a b c d decoder en 0 master byte swap enable 19889a-23 figure 21a. logical implementation for programmable transmit/receive buffer
amd 28 pcnet application examples wr control logic and decode sa<0:3> sd<0:3> we 4 4 4 enable mapper ram a d r 1 sd4 a d out ce master +5 v 1 k 19889a-24 d in figure 21b. mapper ram
amd 29 pcnet application examples memr memw 0:7 8:15 pcnet-isa 0:7 8:15 rd wr adr dec enable sa<0:3> master memr memw thruena swapenrd swap transceivers swap transceivers micro processor thruenb 0:7 8:15 memory /as thruenb swapenrd swapenwr swapenwr thruena thruena thruenb swapenrd swapenwr 19889a-25 figure 22. byte swap transceivers
amd 30 pcnet application examples decode dbusen r/ w sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 sd10 sd11 sd12 sd13 sd14 sd15 pcnet-isa memr memw micro processor d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 pal 16v8 pal 16v8 pal 16v8 d2 d3 d10 d11 sd2 sd3 sd10 sd11 d4 d5 d12 d13 sd4 sd5 sd12 sd13 d6 d7 d14 d15 sd6 sd7 sd14 sd15 pal 16v8 memory 16 d<0:15> pal 16v8 slave access decode memr pal 16v8 sdbusen datacc ring acc sa<0:3> master memr memw pcnetdec memw sa<0:3> 4 master 8 8 8 4 access type decode /as /a<1:10> r/ w 19889a-26 figure 23a. pal mux byte swap
amd 31 pcnet application examples rd m p pcnet-isa isadec pal device swapen d0 d8 sd0 sd8 wr memr memw d8 d0 sd8 sd0 note: symbol indicates pal external pin. example equations: swapen = la20 la21 la22 la23 master sd0 = d0 /swapen + d8 swapen; sd0.trst = wr isadecode + memr master; d0 = sd0 /swapen + sd8 swapen; do.trst = rd isadecode + memw master 19889a-27 figure 23b. expanded view of byte swap (2 bits) implementation discussion for solution #3 [hardware only] it is probably best to partition the swapping hardware into two separate blocks (reference figure 20): one for address decode and one for byte swapping. different options for implementing byte swapping will be discussed later. the address decode logic must decode the address area for buffer memory when the pcnet-isa controller is a bus master and generate an enable to the byte swap logic. to do this, some number of address bits are required to decode the data ring buffer area of memory. in this example, four upper address bits are being used. the fact that the pcnet-isa controller is performing a master mode transfer is known when the signal master is asserted by the pcnet-isa controller. an enable is then generated and gated with the pcnet-isa controller read/write command signals, memr and memw, to drive data in the proper direction to or from memory. the decode logic must also control bus drivers associated with the byte swap logic for all processor reads and writes to the pcnet-isa controller as well as all the pcnet-isa controller master mode transfers. since pcnet-isa controller addresses will set up before read/write commands, it may be better to start the address decode early, that is, not include address decode in the byte swap logic. in this way, the byte swap enable signal can have time to set up before the read/write command is asserted. the logic that controls the byte swap hardware then only need gate the enable signal with memr or memw, which can be done in a fast pal or fast gate to minimize delay. note that in some system designs where the pcnet-isa
amd 32 pcnet application examples controller has tri-state bus drivers, there may already be decode logic to enable these drivers. the decode enable for the byte swap logic may be shared, for example, in same logic as the existing tri-state enables (this is usually easy if the decode is done using a pal). address decode hardware with fixed address transmit/receive buffers for this implementation the decode of the ring buffer area is fixed. the transmit or receive buffer ring buffer area has been pre-defined and its decode fixed in hardware. in this case (reference figure 20), we are assuming four upper address bits can be used to decode this area. when an access to this area is detected with the cycle being a pcnet-isa controllers master mode access, the byte swap logic will be enabled. positive logic equations are shown below (assumes that sa<0:3> are <1001> when transmit/receive ring buffers are accessed). enable = sa0 * sa1 * sa2 * sa3 * master. address decode hardware with programmable address transmit/receive buffers for this implementation, some means of programming the polarity of the address bits seen by the decode logic must be implemented. figure 21a depicts a logic implementation that would work. the adr reg is loaded as an access to a peripheral and could share the peripheral address space of the pcnet-isa controller. the address register is loaded with a bit pattern that will generate an enable when locations of the transmit/re- ceive buffer memory are accessed by the pcnet-isa controller. for example, assume the decode logic will generate an enable when 1111 is on sa<0:3>, which relates to the address space of transmit/receive data buffer area in memory. the adr reg would be loaded with 1111 (d<0:3> respectively). if the transmit/receive address space is changed to sa<0:3> = 1010, the adr reg is loaded with 1010. the mux will now present the correct sense of address bits to generate a decode when sa<0:3> is 1010. once the adr reg is loaded, the decoder can enable the byte swap logic when an access to this area in master mode is performed by the pcnet-isa controller. if the system decides to change the memory space of the transmit/receive buffers, the adr reg is reprogrammed. one issue here is that an extra layer of logic is required. the address delay to decode is a bit longer but, since addresses set up about 55ns before the memr or memw signal, the extra delay will prob- ably not be a problem for most implementations. another implementation uses a ram to decode ad- dresses (reference figure 21b). the mapper ram locations are loaded by system software via the data bus as a peripheral. the mapper ram is programmed to generate an enable when master mode transmit/ receive buffer accesses are performed. that is, when sa and master indicate a master data buffer access, the mapper ram is accessed such that dout generates enable low. byte swap logic options there are several options to perform the byte swapping that will be outlined here. byte swap transceivers (reference figure 22): this may be the best approach from a timing viewpoint. a set of transceivers are added to swap bytes for the pcnet-isa controllers access. the address decoder, as previously discussed, provides an enable that then is qualified with memr, memw or r/w to enable the transceivers in the proper direction. the system design may already have a set of transceivers between the pcnet-isa controller and memory anyway. in those cases, this scheme does not add any additional delay to the pcnet-isa controller related transfers since data is traveling through a set of buffers anyway. the design will probably already have tri-state driver enable logic which may be shared with the byte swap enable logic. for this case, the additional logic may add a little overhead, and no additional delay to the pcnet-isa controller transfers.
amd 33 pcnet application examples note: the swap and thru transceivers should be enabled as follows: 1) assume sa<0:3> = 1111 for a data buffer access. 2) pcnetdec is a decode of a<0:3> bits denoting that the pcnet-isa controller registers are being accessed. swapenrd = master * sa0 * sa1 * sa2 * sa3 * memr ; pcnet-isa data ; buffer read swapenwr = master * sa0 * sa1 * sa2 * sa3 * memw ; pcnet-isa data ; buffer write thruena = (pcnetdec)*/r/w ; pcnet-isa slave + (memr * master)( sa0 + sa1 + sa2 + sa3 ) ; write pcnet-isa ; ring buffer read thruenb = (pcnetdec)*r/w ; pcnet-isa slave + (memw * master)( sa0 + sa1 + sa2 + sa3 ) ; read pcnet-isa ; ring buffer write byte swap pal mux (reference figures 23): a rough diagram of the byte swap logic using a pal mux is shown in figure 23. the pal implements a mux, providing byte swapped and non swapped paths, as well as tri-state enables for the up and the pcnet-isa controller buses. two pals are used for decoding access information. the slave access decode pal determines whether the pcnet-isa controller is being accessed as a slave. the access type decode pal determines the type of access: pcnet-isa controller ring buffer or data buffer access, etc. the byte swapping is accom- plished using one pal per 4 bits of data. note, another programmable logic implementation for byte swapping could be done using amd mach devices. use of these parts could save board space over a pal implementation.
amd 34 pcnet application examples sample pal logic equations are as follows: note : these equations assume that the pcnet-isa controller is accessing data buffer memory when sa<0:3> = <1111> slave access decode pal: this pal will generate the signal pcnetdec. it will use the as signal and a<1:10> to determine if the pcnet-isa controller is being accessed as a slave. therefore the decode of the address bits will be whatever peripheral address has been assigned to the pcnet-isa controller. access type decode pal: dbusen = master * memw ; pcnet-isa memory write + pcnetdec * r/w ; pcnet-isa slave read sdbusen = master * memr ; pcnet-isa mem read + pcnetdec * r /w ; pcnet-isa slave write datacc = master *sa0*sa*sa2*sa3 ; pcnet-isa data buffer access ringacc = master * sa0 ; pcnet-isa + master * sa1 ; ring + master * sa2 ; buffer + master * sa3 ; access sample byte swap pal equations: sd0 = d8 * datacc * memr ; pcnet-isa swapped data buffer read + d0 * pcnetdec * r /w ; pcnet-isa slave write + d0 * ringacc * memr ; pcnet-isa ring buffer read sd0.trst = sdbusen ; tri-state enable for sd bus d0 = sd8 * datacc * memw ; pcnet-isa swapped data buffer write + sd0 * pcnetdec * r/w ; pcnet-isa slave read + sd0 * ringacc * memw ; pcnet-isa ring buffer write d0.trst = dbusen trademarks copyright ? 1995 advanced micro devices, inc. all rights reserved. amd, the amd logo, pal, and mach are registered trademarks of advanced micro devices, inc. pcnet is a trademark of advanced micro devices, inc. product names used in this publication are for identification purposes only and may be trademarks of their respective companies.

▲Up To Search▲

Price & Availability of 19889

	To Download 19889 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .