View CA91C078A-33EG_8010375.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

s c v64? u s er manual h t t p : / / ww w . t u n dr a . c o m
t he i n for m a t ion i n t hi s doc u m e nt i s s ubj e c t t o ch a ng e w i tho u t not i c e a nd s hou l d n ot be c on s tru e d a s a c o m mi t m e n t b y t un d ra s e m i con d uc t o r co r por a ti o n. wh i l e re a s ona b le pre c a u ti o n s h a v e b e e n t a k e n , t un d ra s e m i con d uc t or corpo r a t ion assumes no respo n s i bi l i t y f o r a n y err o rs t h a t may a ppe a r in th i s d o cume n t. no pa r t o f t h i s doc u m e n t m a y b e co p ie d or r e produ c e d i n a n y fo r m o r b y a n y m e a n s wi t hou t t h e pri o r wr i tt e n c on s en t o f t undr a s e mic o ndu c tor co r por a ti o n. t undr a ? prod u c t s a re no t d esi g ned , in t en d ed , or au t hor i z e d f or use as c o m p o nen t s i n s y s t ems i nt e nd e d for s u r g i c a l i m p l a n t i n t o th e bod y , or o th e r a ppl i c a t i on s i n te n d e d to s u p por t or s u s t a i n l i fe , or f o r a n y ot h er a ppl i c a t i on i n whi c h th e f a i l ur e of t h e t u ndr a produ c t c ou l d cr e a t e a s i t u a t ion w h er e per s o n a l in j u ry or d e a th ma y o c cu r . shou l d b u ye r pur c h a s e o r u s e t undr a p r odu c t s f o r a n y s u c h u n in t en d ed o r una u tho r iz e d a ppl i c a t i on , buy e r s h a l l ind e mnif y an d hol d t u n d ra an d it s o ff i c er s , emp l oy e e s , s ub s id i ar i e s , a f f il i a t e s a n d d i str i b utors h a r m l ess a g a ins t a l l c l a ims, cos t s , dama g es , a nd e xp e nses , a nd re a sona b l e a t t orn e y f e es ar i s i ng o u t o f, di r e c tl y o r i n dir e c t l y , a n y c l a im o f p e r s ona l i n ju r y o r d e a t h a s s o c i a t ed wi t h s u c h u n in t en d ed or u n au t hor i z e d u s e , e v e n if s u ch c l a im a ll e ge s th a t t u n d ra w a s n e gl i g e n t r e g a rdi n g t h e d e s ign or m a nu f a c t u re of t h e pa r t. t h e a c c ep t an c e o f th i s d o cume n t w i l l b e con s t ru e d a s a n a c c e p t a nc e o f t h e for e goi n g c ond i t i on s . scv6 4 ? us e r m a nu a l c o pyr i gh t 2001 , t undr a s e m i co n duc t o r corp o ra t ion a l l righ t s r e ser v e d. do c u men t : 8091 0 78 _ ma001_01 p r i n t ed in c a n a d a t undr a a nd t u n dra l o go ar e r e gist e r e d t ra d emarks of t u n dra semi c ond u ct o r c orpor a t i on . scv6 4 i s a t rad e m a rk of t u n dra semi c ond u c t o r c orpor a t i on . b i-mod e i s is a r e g i st e red t r ad e m a rk of d y - 4 sys t em s , in c .
iii table of contents 1 general information ............................................................................................ 1-1 1.1 introduction............................................................................................. 1-1 1.2 product overview ................................................................................... 1-1 1.2.1 flexibility and features.......................................................... 1-1 1.3 using this document ............................................................................. 1-4 1.4 conventions ............................................................................................ 1-5 1.4.1 signals .................................................................................... 1-5 1.4.2 symbols.................................................................................. 1-5 1.4.3 mathematical notation........................................................... 1-5 2 functional description......................................................................................... 2-1 2.1 introduction............................................................................................. 2-1 2.1.1 organization of the functional description ........................... 2-1 2.1.2 functional overview .............................................................. 2-2 2.1.2.1 data path ............................................................................... 2-2 2.1.2.2 vmebus interface ................................................................. 2-5 2.1.2.3 local bus interface ............................................................... 2-6 2.2 vmebus requester ................................................................................. 2-8 2.2.1 function.................................................................................. 2-8 2.2.2 bus request modes................................................................ 2-9 2.2.2.1 fair and demand modes ....................................................... 2-9 2.2.2.2 vmebus request levels....................................................... 2-9 2.2.3 bus release modes .............................................................. 2-10 2.2.3.1 bus clear enabling ............................................................. 2-10 2.2.3.2 release on request and release when done .................... 2-10 2.2.3.3 ownership timer ................................................................ 2-11 2.2.4 other bus release mechanisms........................................... 2-11 2.2.4.1 local memory interrupt ...................................................... 2-11 2.2.4.2 bi-mode .............................................................................. 2-12
iv 2.2.4.3 local and system reset ....................................................... 2-12 2.3 interrupter .............................................................................................. 2-13 2.3.1 vmebus interrupts ...............................................................2-13 2.3.1.1 interrupt generation............................................................. 2-13 2.3.1.2 bi-mode effects ................................................................... 2-14 2.3.1.3 reset effects ........................................................................ 2-14 2.3.2 local bus interrupts..............................................................2-15 2.4 interrupt handler ................................................................................... 2-18 2.4.1 interrupt enabling and status ...............................................2-20 2.4.1.1 local interrupt level mapping............................................ 2-21 2.4.2 interrupt acknowledge cycles .............................................2-22 2.4.2.1 auto-vectored interrupts ..................................................... 2-25 2.4.2.2 vectored interrupts .............................................................. 2-26 2.4.2.3 bi-mode effects .................................................................. 2-29 2.4.2.4 reset effects ........................................................................ 2-29 2.5 system controller functions ................................................................. 2-30 2.5.1 syscon determination...........................................................2-30 2.5.2 iack daisy chain driver ....................................................2-31 2.5.3 vmebus arbiter ...................................................................2-31 2.5.3.1 arbitration modes ............................................................... 2-31 2.5.3.2 arbitration time-out............................................................ 2-33 2.5.3.3 reset effects ........................................................................ 2-33 2.5.4 bus timer .............................................................................2-34 2.5.5 system clock driver.............................................................2-34 2.5.6 external inputs ......................................................................2-34 2.5.6.1 external status ..................................................................... 2-34 2.5.6.2 off-board reset input ......................................................... 2-35 2.5.7 reset effects on syscon functions .......................................2-35 2.6 data path................................................................................................ 2-36 2.6.1 scv64 as vme slave...........................................................2-39 2.6.1.1 coupled mode...................................................................... 2-39
v 2.6.1.2 decoupled mode ................................................................. 2-39 2.6.2 scv64 as vme master........................................................ 2-41 2.6.2.1 coupled mode..................................................................... 2-41 2.6.2.2 decoupled mode ................................................................. 2-42 2.6.2.3 dma transfers ................................................................... 2-43 2.7 memory mapping ................................................................................. 2-45 2.7.1 cpu memory map ............................................................... 2-45 2.7.2 vme slave memory map.................................................... 2-49 2.7.2.1 automatic base address programming .............................. 2-51 2.7.2.2 access protection ................................................................ 2-52 2.8 vmebus interface ................................................................................. 2-53 2.8.1 scv64 as vme master........................................................ 2-53 2.8.1.1 address translation ............................................................ 2-53 2.8.1.2 byte lane translation ......................................................... 2-54 2.8.1.3 vmebus mastership............................................................ 2-56 2.8.1.4 rmw cycles ....................................................................... 2-57 2.8.1.5 termination of a master cycle with retry* ................... 2-58 2.8.2 scv64 as vme slave .......................................................... 2-58 2.8.2.1 address translation ............................................................ 2-58 2.8.2.2 byte lane translation ......................................................... 2-59 2.8.2.3 local bus mastership.......................................................... 2-60 2.8.3 dma transfers .................................................................... 2-61 2.8.4 master/slave deadlock resolution ...................................... 2-61 2.8.5 location monitor access ..................................................... 2-62 2.8.6 bus busy glitch ................................................................... 2-63 2.8.7 bi-mode effects................................................................... 2-63 2.8.8 bus error handling .............................................................. 2-64 2.9 local bus interface ............................................................................... 2-66 2.9.1 local bus arbitration........................................................... 2-66 2.9.1.1 local arbiter bypassed....................................................... 2-66 2.9.1.2 local arbiter active ........................................................... 2-67
vi 2.9.2 local cycles C overview......................................................2-73 2.9.2.1 cycle initiation .................................................................... 2-73 2.9.2.2 data transfer ....................................................................... 2-74 2.9.2.3 cycle termination signals................................................... 2-76 2.9.2.4 bus error handling .............................................................. 2-77 2.9.3 scv64 as local slave ..........................................................2-78 2.9.4 scv64 as local master ........................................................2-83 2.9.5 register access.....................................................................2-87 2.9.6 burst cycles ..........................................................................2-89 2.9.6.1 burst reads .......................................................................... 2-89 2.9.6.2 burst writes ......................................................................... 2-90 2.9.6.3 local address incrementation ............................................. 2-96 2.9.7 read-modify-write cycles...................................................2-97 2.9.8 master/slave deadlock resolution.......................................2-98 2.9.8.1 deadlock resolution in decoupled mode ........................... 2-98 2.9.9 location monitor access ......................................................2-99 2.9.10 reflected cycles ...................................................................2-99 2.9.11 vsbbus access...................................................................2-100 2.9.12 bi-mode..............................................................................2-100 2.10 location monitor and lmfifo........................................................... 2-101 2.11 dma controller................................................................................... 2-102 2.11.1 dma initialization..............................................................2-102 2.11.2 addressing and data transfer modes ................................2-104 2.11.3 data transfer counts ..........................................................2-107 2.11.4 fill option ........................................................................2-107 2.11.5 no release option ..............................................................2-108 2.11.6 dma completion and error checking...............................2-108 2.12 resets, clocks and timers................................................................... 2-110 2.12.1 resets ..................................................................................2-110 2.12.1.1 local reset ........................................................................ 2-110 2.12.1.2 system reset...................................................................... 2-111
vii 2.12.1.3 power-up reset ................................................................. 2-111 2.12.1.4 reset effects on scv64 internal resources..................... 2-112 2.12.2 clocks................................................................................. 2-113 2.12.2.1 clocks required ................................................................ 2-113 2.12.2.2 clocks generated .............................................................. 2-114 2.12.3 timers ................................................................................ 2-115 2.12.3.1 local bus timer................................................................ 2-115 2.12.3.2 tick timer......................................................................... 2-115 2.12.3.3 watchdog timer................................................................ 2-116 2.12.3.4 vmebus timers ................................................................ 2-116 2.13 power-up modes ................................................................................. 2-117 2.13.1 local iack cycle decoding ............................................. 2-117 2.13.2 auto syscon select ......................................................... 2-118 2.13.3 local arbiter bypass.......................................................... 2-118 2.13.4 automatic base address programming ............................. 2-118 2.14 bi-mode .............................................................................................. 2-119 2.15 auto-id ............................................................................................... 2-121 2.15.1 the auto-id cycle............................................................. 2-121 2.15.2 auto-id self test ............................................................... 2-123 2.16 internal delay line calibration .......................................................... 2-124 2.17 test and diagnostic modes................................................................. 2-126 2.17.1 decoupled write diagnostics ............................................ 2-126 2.17.2 loopback diagnostics........................................................ 2-126 2.17.2.1 loopback mode ................................................................ 2-126 2.17.2.2 dma loopback ................................................................ 2-128 2.17.2.3 interrupt loopback............................................................ 2-128 2.17.2.4 jtag support ................................................................... 2-128 3 description of scv64 signals ............................................................................. 3-1 3.1 vmebus signals ............................................................................................................ 3-1 3.2 local signals .......................................................................................... 3-5
viii 4 signals and dc characteristics ........................................................................... 4-1 4.1 terminology ............................................................................................ 4-1 4.2 dc characteristics ................................................................................... 4-2 4.3 capacitive loading ................................................................................ 4-10 4.4 pin configuration................................................................................... 4-11 app-a registers....................................................................................................... app a-1 a.1 control and status registers........................................................... app a-1 app-b scv64 timing characteristics ................................................................... app b-1 b.1 timing parameters.......................................................................... app b-1 b.2 capacitive loading ....................................................................... app b-13 b.3 timing diagrams .......................................................................... app b-14 app-c performance ................................................................................................ app c-1 c.1 coupled cycles............................................................................... app c-1 c.1.1 scv64 as vme master ................................................. app c-2 c.1.2 scv64 as vme slave.................................................... app c-5 c.2 decoupled cycles ........................................................................... app c-7 c.2.1 scv64 as vme master ................................................. app c-7 c.2.2 scv64 as vme slave.................................................... app c-7 c.3 daisy chains................................................................................... app c-8 c.4 arbiter functions ............................................................................ app c-8 c.5 summary......................................................................................... app c-9 app-d vmebus-local bus cycle mapping.......................................................... app d-1 d.1 cycle translation............................................................................ app d-1 d.2 address space mapping ............................................................... app d-12 app-e applications .................................................................................................. app e-1 e.1 vmebus interface........................................................................... app e-1 e.1.1 buffered signals ............................................................ app e-1 e.1.2 layout issues ................................................................. app e-1
ix e.1.3 decoupling vdd and vss ............................................ app e-3 e.1.4 bgxin*[3:0] signals ..................................................... app e-3 e.1.5 retry*/ vrmc pin .................................................... app e-6 e.1.6 bi-mode and irq1* ...................................................... app e-7 e.2 local bus interface for slave only applications ........................... app e-8 e.2.1 initialization ................................................................... app e-8 e.2.2 vmebus programming .................................................. app e-8 e.3 local bus interface for mc68030 application ............................ app e-11 e.4 local bus interface for mc68040 application ............................ app e-12 e.4.1 design philosophy ....................................................... app e-12 e.4.2 design overview.......................................................... app e-13 e.4.3 bus adapter operation................................................. app e-16 e.4.4 cycle translation state machine ................................. app e-17 e.4.5 dynamic bus sizing..................................................... app e-20 e.4.6 transfer attributes ....................................................... app e-21 e.4.7 interrupts ...................................................................... app e-24 app-f initialization................................................................................................. app f-1 f.1 hardware configuration ................................................................. app f-1 f.1.1 power-up modes ........................................................... app f-1 f.1.2 test mode pins............................................................... app f-2 f.1.3 bi-mode ......................................................................... app f-2 f.1.4 jtag .............................................................................. app f-2 f.1.5 clocks............................................................................. app f-2 f.1.6 resets ............................................................................. app f-3 f.1.7 retry*/vrmc............................................................ app f-3 f.2 software .......................................................................................... app f-4 f.2.1 delay line initialization ................................................ app f-5 f.2.2 byte lane mapping and cycle conversion ................... app f-6 f.2.3 slave address programming.......................................... app f-6 f.2.4 memory map overlay initialization .............................. app f-7 f.2.5 bi-mode ......................................................................... app f-7
x f.2.6 retry*/vrmc configuration .................................... app f-7 f.2.7 other local options....................................................... app f-8 f.2.8 local bursts ................................................................... app f-8 f.2.9 local arbiter.................................................................. app f-8 f.2.10 interrupts ........................................................................ app f-8 f.2.11 local timer functions ................................................... app f-9 f.2.12 sysfail* ..................................................................... app f-9 f.2.13 vme requester.............................................................. app f-9 f.2.14 vme arbiter .................................................................. app f-9 app-g reliability prediction .................................................................................. app g-1 g.1 device description ......................................................................... app g-1 g.1.1 physical characteristics ..................................................app g-1 g.1.2 thermal characteristics ..................................................app g-1 g.1.3 latch-up current.............................................................app g-2 g.2 parameters....................................................................................... app g-2 app-h environmental and operating parameters .............................................. app h-1 app-i revision history ............................................................................................ app i-1 app-j mechanical and ordering information ..................................................... app j-1 j.1 mechanical information................................................................... app j-1 j.2 ordering information....................................................................... app j-3 index ........................................................................................................................ i ndex-1
xi list of figures figure 1.1 : coupled versus decoupled cycles ................................................... 1-2 figure 2.1 : functional block diagram................................................................ 2-3 figure 2.2 : interrupt handler block diagram ................................................... 2-19 figure 2.3 : connections resulting from changing local iack decoding ..... 2-24 figure 2.4 : local interrupt cycle - auto-vectored........................................... 2-26 figure 2.5 : timing for local interrupts ............................................................ 2-27 figure 2.6 : vectored interrupt cycle - with local and vme interrupter ......... 2-28 figure 2.7 : coupled cycles on the vmebus..................................................... 2-37 figure 2.8 : decoupled cycles on the vmebus ................................................. 2-38 figure 2.9 : sample cpu memory map as determined by local address decoder................................................................... 2-46 figure 2.10 : scv64 vme access overlay for the cpu memory map ............. 2-47 figure 2.11 : sample cpu memory map with scv64 vme and vsb space overlay ................................................................................. 2-48 figure 2.12 : sample vme slave memory map (accessed as a32 and a24) .... 2-51 figure 2.13 : local to vme byte lane translation with bussiz=1 ................. 2-55 figure 2.14 : local to vme byte lane translation with bussiz=0 ................. 2-56 figure 2.15 : local bus arbitration with local arbiter bypass .......................... 2-67 figure 2.16 : local bus arbiter state machine.................................................... 2-68 figure 2.17 : local arbitration for internal requester ........................................ 2-70 figure 2.18 : local arbitration for external device - with acknowledgment ... 2-72 figure 2.19 : local arbitration for external device - without acknowledgment ............................................................................ 2-72 figure 2.20 : example of longword transfer to a 16-bit port ............................ 2-76 figure 2.21 : flowchart for a local cycle with scv64 as local slave .............. 2-79 figure 2.22 : decoupled write cycle C scv64 as local slave........................... 2-82 figure 2.23 : flowchart for a local cycle with scv64 as local master............ 2-84 figure 2.24 : write cycle C scv64 as local master.......................................... 2-85
xii figure 2.25 : flowchart for a burst read cycle - scv64 as local master.......... 2-91 figure 2.26 : burst read cycle ............................................................................. 2-92 figure 2.27 : flowchart for a burst write cycle - scv64 as local master......... 2-94 figure 2.28 : burst write cycle ............................................................................ 2-95 figure 2.29 : local interface for maximum burst length of 4 longwords............. 2-96 figure 2.30 : procedural steps in normal dma reads and writes. .................. 2-103 figure 2.31 : sample power-up reset circuit..................................................... 2-112 figure 2.32 : connections with different local iack decoding ...................... 2-117 figure 2.33 : timing for auto-id cycle............................................................. 2-122 figure 2.34 : functional block diagram for delay lines .................................. 2-125 figure 4.1 : pin configuration for 299-pin cpga package ............................... 4-11 figure 4.2 : pin configuration for 304-pin pqfp package ................................ 4-12 figure b.1 : clocks and timers .................................................................. app b-14 figure b.2 : reset timing........................................................................... app b-15 figure b.3 : local interrupts - generation ................................................. app b-16 figure b.4 : local interrupts-acknowledgment......................................... app b-17 figure b.5 : register access....................................................................... app b-18 figure b.6 : register access effects .......................................................... app b-19 figure b.7 : decoupled write cycle - scv64 as local master................. app b-20 figure b.8 : decoupled write cycle - scv64 as local slave................... app b-21 figure b.9 : coupled cycle - scv64 as local master............................... app b-22 figure b.10 : coupled cycle - scv64 as local slave................................. app b-23 figure b.11 : burst write cycle - scv64 as local master ......................... app b-24 figure b.12 : burst read cycle - scv64 as local master .......................... app b-25 figure b.13 : slave image/vsb/location monitor access.......................... app b-26 figure b.14a : local requester C arbiter bypassed ...................................... app b-27 figure b.14b : local requester/arbiter: request by scv64......................... app b-27 figure b.14c : local requester/arbiter: request by an external device C with acknowledge............................................................... app b-28 figure b.14d : local requester/arbiter: request by an external device C without acknowledge.......................................................... app b-28 figure b.15a : local bus error termination - write or read cycle
xiii with berrchk bit=0 (scv64 as local master) ..................app b-29 figure b.15b : local bus error termination - read cycle with berrchk bit=1 (scv64 as local master) .............................................. app b-29 figure b.15c : deadlock retry termination (scv64 as local slave)........... app b-29 figure b.16 : daisy chain driver timing .................................................... app b-30 figure b.17a : vmebus requester - normal release ....................................app b-31 figure b.17b : vmebus requester - release with bclr*............................ app b-31 figure b.18 : vmebus arbiter timing......................................................... app b-32 figure b.19 : vmebus interrupter timing ................................................... app b-33 figure b.20 : vmebus interrupt handler ..................................................... app b-34 figure b.21 : decoupled write cycle - scv64 as vme master ................. app b-35 figure b.22 : decoupled write cycle - scv64 as vme slave ................... app b-36 figure b.23 : coupled cycle - scv64 as vme master ............................... app b-37 figure b.24 : coupled cycle - scv64 as vme slave ................................. app b-38 figure b.25 : blt/mblt writes - scv64 as vme master........................ app b-39 figure b.26 : blt/mblt writes - scv64 as vme slave .......................... app b-40 figure b.27 : blt/mblt read cycle - scv64 as vme master................ app b-41 figure b.28 : blt read cycle - scv64 as vme slave .............................. app b-42 figure b.29 : mblt read cycle - scv64 as vme slave........................... app b-43 figure c.1 : scv64 as vme master - rwd mode ...................................... app c-3 figure c.2 : scv64 as vme master - ror mode ....................................... app c-4 figure c.3 : coupled cycle - scv64 as vme slave (local arbiter active) .. app c-6 figure c.4 : coupled cycle-scv64 as vme slave (local arbiter bypassed) app c-6 figure d.1 : single longword aligned byte transfer with swap = 0 ...... app d-2 figure d.2 : single longword aligned byte transfer with swap = 1 ...... app d-2 figure d.3 : tri-byte transfer with bussiz = 1......................................... app d-4 figure d.4 : tri-byte transfer with bussiz = 0......................................... app d-4 figure e.1 : orientation of the scv64 (cpga and pqfp) to minimize distance to the connector ............................................................................ app e-2 figure e.2 : scv64 interface to vmebus .................................................... app e-5 figure e.3 : bus grant daisy chain usage in system ................................. app e-6 figure e.4 : implementation of vrmc and retry* ................................. app e-7
xiv figure e.5 : connections for slave only design ....................................... app e-10 figure e.6 : connections for 68030 design ............................................... app e-11 figure e.7 : shared local bus structure .................................................... app e-13 figure e.8 : hierarchical local bus structure ........................................... app e-13 figure e.9 : mc68040 to scv64 bus adapter block diagram ................ app e-15 figure e.10 : mc68040 bus transfer control............................................. app e-16 figure e.11 : scv64 bus transfer control ................................................. app e-17 figure e.12 : cycle translation unit state machine.................................... app e-19 figure e.13 : cycle translation timing diagram........................................ app e-20 figure e.14 : local bus arbiter state machine ........................................... app e-24 figure e.15 : kiack generation................................................................. app e-25 figure e.16 : iack cycle interrupt level generation ................................ app e-25 figure e.17 : reset circuit ........................................................................... app e-26 figure j.1 : 299-pin cavity-down cpga package....................................... app j-1 figure j.2 : mechanical drawing for 304-pin pqfp package ..................... app j-2
xv list of tables table 1.1 : signals used in this manual .............................................................. 1-5 table 1.2 : technical support documentation references.................................. 1-6 table 2.1 : vmebus request and release modes ............................................... 2-8 table 2.2 : setting vmebus request levels ....................................................... 2-9 table 2.3 : setting the vmebus ownership timer ........................................... 2-11 table 2.4 : encoding for vmebus interrupt levels .......................................... 2-13 table 2.5 : kipl2-kipl0 encoding for cpu interrupt levels ......................... 2-15 table 2.6 : mapping bits for general local interrupts...................................... 2-16 table 2.7 : encoding for general local interrupt level mapping .................... 2-16 table 2.8 : properties of interrupt sources ........................................................ 2-18 table 2.9 : control bits for interrupt sources ................................................... 2-20 table 2.10 : status bits for interrupt sources ...................................................... 2-21 table 2.11 : mapping bits for general local interrupts...................................... 2-22 table 2.12 : encoding for general local interrupt level mapping .................... 2-22 table 2.13 : kaddr3-1 encoding for cpu interrupt levels ............................ 2-24 table 2.14 : correlation between kfc1 and local iack decoding ................. 2-25 table 2.15 : setting vmebus arbitration modes ................................................ 2-32 table 2.16 : setting vmebus time-out period ................................................... 2-34 table 2.17 : functions for different settings of kfc2 and kfc0...................... 2-52 table 2.18 : txctl register bits description ................................................... 2-64 table 2.19 : kfc encodings for transfer type .................................................. 2-73 table 2.20 : transfer size encoding.................................................................... 2-74 table 2.21 : port size as indicated by bussiz and cycle termination ............. 2-74 table 2.22 : byte lanes for different port sizes on the local bus..................... 2-75 table 2.23 : encoding for address offset on the local bus ............................... 2-75 table 2.24 : a summary of scv64 register accesses ....................................... 2-87 table 2.25 : scv64 register map ....................................................................... 2-88 table 2.26 : local bus frequency and allowable wait states during burst writes ..................................................................................... 2-93
xvi table 2.27 : bit settings for dma transfer modes .......................................... 2-105 table 2.28 : setting the tick timer interval...................................................... 2-116 table 2.29 : vmebus signal behavior in bi-mode........................................... 2-120 table 4.1 : dc electrical characteristics ........................................................... 4-2 table 4.2 : pin list and dc characteristics for scv64 signals (-55c to 125c) .............................................................................. 4-3 table 4.3 : vmebus address and data input and output signal bits................. 4-7 table 4.4 : local bus address and data input and output signal bits............... 4-8 table 4.6 : pin assignments for power................................................................ 4-9 table 4.5 : pin assignments for ground.............................................................. 4-9 table 4.7 : input capacitive loading................................................................. 4-10 table a.1 : a summary of scv64 register accesses ................................ app a-1 table a.2 : scv64 register map .............................................................. app a-2 table a.3 : dma local address register (dmalar).............................. app a-4 table a.4 : dma vmebus address register (dmavar)........................ app a-4 table a.5 : dma transfer count register (dmatc) ............................... app a-5 table a.6 : control and status register (dcsr) ........................................ app a-6 table a.7 : vmebus slave base address register (vmebar) ................ app a-9 table a.8 : a24 slave image programming ............................................. app a-10 table a.9 : a32 slave image size (4 bit field) ........................................ app a-12 table a.10 : a32 slave image base address (5 bit field) ......................... app a-12 table a.11 : rxfifo data register (rxdata) ....................................... app a-13 table a.12 : rxfifo address register (rxaddr) ................................. app a-13 table a.13 : rxfifo control register (rxctl) ...................................... app a-14 table a.14 : vmebus/vsb bus select (bussel)..................................... app a-15 table a.15 : vmebus interrupter vector (ivect)..................................... app a-16 table a.16 : access protect boundary register (apbr)............................ app a-17 table a.17 : txfifo data output latch register (txdata) ................. app a-18 table a.18 : txfifo address output latch register (txaddr) ........... app a-18 table a.19 : transmit fifo am code and control bit latch (txctl) ... app a-19 table a.20 : location monitor fifo read port (lmfifo) ....................... app a-20
xvii table a.21 : mode control (mode) .......................................................... app a-21 table a.22 : slave a64 base address register (sa64bar) ..................... app a-25 table a.23 : master a64 base address register (ma64bar) .................. app a-26 table a.24 : local address generator (lag) ............................................ app a-26 table a.25 : dma vmebus transfer count (dmavtc) ......................... app a-27 table a.26 : status register 0 (stat0)...................................................... app a-28 table a.27 : status register 1 (stat1)...................................................... app a-29 table a.28 : general control register (genctl)..................................... app a-30 table a.29 : vmebus interrupter requester (vint).................................. app a-31 table a.30 : vmebus requester register (vreq) .................................... app a-32 table a.31 : vmebus arbiter register (varb) ........................................ app a-33 table a.32 : id register (id) ...................................................................... app a-34 table a.33 : control and status register (ctl2) ....................................... app a-35 table a.34 : level 7 interrupt status register (7is) ................................... app a-36 table a.35 : local interrupt status register (lis)...................................... app a-37 table a.36 : level 7 interrupt enable register (7ie) ................................. app a-38 table a.37 : local interrupt enable register (lie) .................................... app a-39 table a.38 : vmebus interrupt enable register (vie) .............................. app a-40 table a.39 : local interrupts 1 and 0 control register (ic10)................... app a-41 table a.40 : local interrupts 3 and 2 control register (ic32)................... app a-41 table a.41 : local interrupts 5 and 4 control register (ic54)................... app a-42 table a.42 : miscellaneous control register (misc) ................................ app a-43 table a.43 : delay line control register (dlct) ..................................... app a-44 table a.44 : delay line status register 1 (dlst1)................................... app a-45 table a.45 : delay line status register 2 (dlst2)................................... app a-46 table a.46 : delay line status register 3 (dlst3)) ................................. app a-47 table a.47 : mailbox register 0 (mbox0) ................................................ app a-48 table a.48 : mailbox register 1 (mbox1) ................................................ app a-48 table a.49 : mailbox register 2 (mbox2) ................................................ app a-48 table a.50 : mailbox register 3 (mbox3) ................................................ app a-48 table b.1 : scv64 ac characteristics .......................................................app b-1
xviii table b.2 : capacitive loading from output signals ................................app b-13 table c.1 : timing parameters .....................................................................app c-9 table c.2 : data transfer - scv64 as vme master ..................................app c-10 table c.3 : data transfer - dma...............................................................app c-10 table c.4 : data transfer - scv64 as vme slave ....................................app c-11 table c.5 : daisy chains ............................................................................app c-11 table c.6 : vmebus arbiter ......................................................................app c-11 table d.1 : effect of swap bit in the mode register on byte lane translation ................................................................................ app d-2 table d.2 : port size as indicated by bussiz and cycle termination ...... app d-3 table d.3 : transfer size encoding............................................................. app d-5 table d.4 : read cycles - scv64 as local slave/vme master (swap=0) ................................................................................ app d-6 table d.5 : read cycles-scv64 as local slave/vme master (swap=1) app d-7 table d.6 : write cycles - scv64 as local slave/vme master (swap=0) ................................................................................ app d-8 table d.7 : write cycles-scv64 as local slave/vme master (swap=1) ................................................................................ app d-9 table d.8 : read/write cycles - scv64 as local master/vme slave (swap =x, bussiz=x) ......................................................... app d-11 table d.9 : kfc signal translation to vme address space (scv64 as vme master)........................................................ app d-12 table d.10 : vme am code translation to kfc signals (scv64 as vme slave) ............................................................................ app d-13 table e.1 : 68040 terminations ................................................................. app e-16 table e.2 : scv64 terminations ............................................................... app e-17 table e.3 : 68040 transfer type encoding ............................................... app e-21 table e.4 : local and vme bus space mapping .......................................app e-22 table f.1 : pin levels for specific power-up modes .................................. app f-1 table f.2 : software initialization summary ............................................... app f-4 table f.3 : programming for vme slave address ...................................... app f-6 table f.4 : address space enabling ............................................................ app f-7 table h.1 : recommended operating conditions ....................................... app h-1
xix table h.2 : absolute maximum ratings ..................................................... app h-1
xx
vmebus inte r fa c e co m pon e nt s scv64 us e r m a n u a l tund r a s e m i c ondu c to r c o r po r ati o n 1 -1 1 general in f o rmation 1 .1 int r o d u ct i on the singl e c h i p vme b us inte r face chi p (scv64, ca91 c 078 a ) is a member o f t undra s g r o win g l ine of b a ckplan e i nter f ace component s , and pr o vides a reliable hig h per f ormance 64 - bi t vme b us i n t e r f a ce i n one d e vic e . t h e scv64 re s u lts from a f our year d e v elopment e f fort in v m e b us inter f ace de s ign an d support, an i n v e stment w h i c h orig i n a ll y p rod u c ed the ad v a nced vm e b us inte r face chip set ( a v i cs ) . design e d in collabo r a t i o n wi t h d y -4 system s , th e s c v64 is c o m p liant w i th both th e vme64 and ie e e 101 4 r e v c speci f ications. in a ddi t ion, th e scv64 pr o v ides th e high reliability of motorola semiconductors m a n ufactur i n g pr o c es s es. th e s c v64 is manu f a c tu r e d with a c m o s process and is a v ailabl e in 299 - pin cpga an d 304-pi n pqf p pakag e s. th e scv6 4 i s ide a l l y suite d f or cpu boards whic h as s u m e both m a ster an d sl a ve roles in the vme s y stem. under this wo r k ing e n vi r onm e n t, the us e r can m a k e f u ll use o f th e s c v64 s mul t iple featu r e s an d options. 1 .2 p r o d u ct o v e r vi e w 1. 2 .1 f l e x ibi l ity a n d f eat u r es on e o f the major s t r engths of th e scv6 4 i s its functional fl e x ibilit y . a rich poo l o f f e a tu r es and op e rational mode s all o w s the us e r to tailor a vm e b u s interfac e for a v ar i e ty of data- passing e n vironments. the fl e xibility pr o vided b y the scv6 4 der i v e s f rom the nume r ous option s a v a i l a b l e to the u s e r at e ach major functiona l layer : the v m e b u s inter f a c e , the data path , and the local b us i nt e r f a ce . at th e vme b us inte r f a ce, th e user ma y enabl e and/or con f igu r e all of t he foll o win g f e atu r e s : ? vme b u s sy s t e m controlle r f un c t i on s , ? auto - id vme s lo t identi f ic a t i on, ? automatic v m e b us sy s con identi f ication, ? mul t iple vme b us r e quest an d relea s e op t ion s , ? mul t iple vme b us arbi t ration scheme s ,
general information scv64 user manual 1-2 tundra semiconductor corporation ? vmebus interrupter and interrupt handler for all seven vmebus interrupts, ? master/slave a64/d64, a32/d64, a24/d32, d16, d08 (eo) interface, ? master a16/d16, d08 (eo) capabilities, ? vme slave image access protection, and ? automatic vme base address programming. data transfer between the local bus and the vmebus normally involves coupling handshake protocols used by separate buses. this means that mastership of three buses (master local bus, vmebus, and slave local bus) must be maintained even though data transfer only occurs on one bus at a time. the bus that originated the data transfer is only released when the last bus in the data transfer chain completes its cycle. the idle time created by cycle coupling across different buses constitutes a loss of effective bandwidth. the scv64 decouples data transfer by acting as a cycle shuttle at the local bus-vmebus interface. when a cycle arrives from one bus (local or vme), it is queued in an internal scv64 fifo and the originating bus is notified of cycle completion. while the scv64 acquires the other bus and completes the data transfer, the original bus is released and is free to conduct other business (see figure 1.1 below). first bus second bus cycle generation cycle termination cycle termination cycle translation coupled cycle first bus second bus cycle generation cycle termination cycle termination cycle translation, decoupled cycle available with scv64 cycle generation cycle termination, and cycle relay scv64 regular vme interface figure 1.1 : coupled versus decoupled cycles
tundra semiconductor corporation 1-3 scv64 user manual general information along with the unique decoupling function, the scv64 offers the following data path options: ? integral a64, a32, a24/d64, d32, d16 direct memory access controller (dmac), ? a64/a32/a24 multiplexed block transfers (mblt), ? a32/a24 block transfers (blt), ? location monitor with 31 deep message fifo for inter-process communication, and ? a bus isolation (bi-mode ? ) controller unique to the scv64. like the vmebus interface, the scv64s local interface may be adapted by the user to a variety of operational modes. the scv64 local interface offers: ? a local bus requester and arbiter, ? local bus burst mode to complement blt and mblt cycles on the vmebus, ? local interrupt handler functions, ? compatibility with bus-sizing or nonbus-sizing cpus, and ? local clocks and timers. from the list of features and options available with the vmebus interface, the data path, and the local bus interface, it is clear that the scv64 offers a configuration to suit most vme interface requirements.
general information scv64 user manual 1-4 tundra semiconductor corporation 1.3 using this document the scv64 manual is organized into the following sections: ? chapter 1- general information, ? chapter 2 - functional description, ? chapter 3 - signal description, ? chapter 4 - dc characteristics, ? appendix a - registers, ? appendix b - timing characteristics, ? appendix c - scv64 performance, ? appendix d - vmebus-local bus cycle mapping, ? appendix e - typical applications, ? appendix f - reliability prediction ? appendix g - initialization, ? appendix h- environmental and operating parameters, ? appendix i - revision history, ? appendix j - mechanical and ordering information, and ? index. chapter 1 introduces the scv64 and provides the reader with information about the necessary concepts and conventions required to use the manual. chapters 2 to 4 describe scv64 function, beginning with overall functionality in chapter 2 to detailed signal descriptions in chapters 3 and 4. the appendices are reference sources necessary for the implementation of the scv64 (for example, register programming, timing characteristics etc.). in addition, the appendices contain application information to aid the user in system design. appendix i points out substantial revisions in this current version of the scv64 user manual and is important for users with previous versions of the manual. an index is provided to assist the reader in accessing information using key words. entries which refer to definitive passages in the text are highlighted with bold type face. the sales network lists our current team of national and international sales representatives and distributors.
tundra semiconductor corporation 1-5 scv64 user manual general information 1.4 conventions 1.4.1 signals signals on the vmebus and those on the local bus, may be active high or active low. active low signals are defined as being true (asserted) when they are at logic low. similarly, active high signals are defined as being true when they are at a logic high. signals are said to be asserted when active and negated when inactive, irrespective of voltage levels. for voltage levels, the use of 0 indicates a low voltage while a 1 indicates a high voltage. 1.4.2 symbols caution: this symbol alerts the reader to procedures or operating levels which may result in misuse of or damage to the scv64. note: this symbol directs the readers attention to useful information or suggestions. 1.4.3 mathematical notation 0x will be used to prefix hexadecimal digits. table 1.1 : signals used in this manual signals v l k asterisk suffix to direct connect vmebus active low signals on-card active low signals that do not connect directly to the vmebus prefix for nondirect-connect vmebus signals prefix for general local signals prefix for signals connected to the local cpu overbar !
general information scv64 user manual 1-6 tundra semiconductor corporation for general technical information, please consult the references listed in table 1.2. table 1.2 : technical support documentation references document number institution description isbn 0-13-567017-9 isbn 0-13-566969-3 C ieee 1014-1987 vme64 motorola motorola vita ieee vita mc68020 users manual mc68030 users manual the vmebus handbook, 1991 vmebus specification vme64 specification
vmebus interface componentsscv64 user manual tundra semiconductor corporation 2-1 2 functional description 2.1 introduction 2.1.1 organization of the functional description the functional description of the scv64 is organized into the following sections: 2.1 introduction 2.2 vmebus requester 2.3 interrupter 2.4 interrupt handler 2.5 system controller functions 2.6 data path 2.7 memory mapping 2.8 vmebus interface 2.9 local bus interface 2.10 location monitor and lmfifo 2.11 dma controller 2.12 resets, clocks and timers 2.13 power-up modes 2.14 bi-mode 2.15 auto-id 2.16 internal delay line calibration 2.17 test and diagnostic modes sections 2.3 to 2.5 address vmebus ownership, interrupts and interrupt handling, and vmebus system controller functions provided by the scv64. since the control and monitoring of vmebus and local interrupts share many characteristics within the scv64, both types of interrupts are discussed in the interrupter and interrupt handler sections.
introduction scv64 user manual 2-2 tundra semiconductor corporation sections 2.6 to 2.11 focus on the architectural concepts for data transfer as performed by the scv64. sections 2.6 and 2.7 provide important theoretical background for the user, while sections 2.8 and 2.9 examine cycle translation in detail at the vmebus and local bus interfaces. sections 2.12 to 2.17 cover a variety of additional functions and features found in the scv64. the influence of these additional functions and features on the vmebus interface, the data path, and the local bus interface is described in detail in each of these sections. 2.1.2 functional overview the following overview uses the functional block diagram in figure 2.1 on page 2-3 to organize the different components of the scv64. the blocks which comprise the three major functional layers (data path, vmebus interface, local bus interface) are examined in general terms below. these brief descriptions of the various functional components are intended to introduce the reader to important concepts and point to more detailed sections within the main text of this chapter. 2.1.2.1 data path receive and transmit fifos when the scv64 is in decoupled mode, incoming cycles (i.e. vmebus to local bus) are queued in the receive fifo (rxfifo) and the scv64 terminates the cycle on the vmebus. on the local side, the scv64 requests the local bus as soon as entries appear in the rxfifo. outgoing cycles (i.e. local bus to vmebus) are queued in the transmit fifo (txfifo). when a cycle is entered in the txfifo, the scv64 terminates the local cycle by asserting , and requests access to the vmebus. the scv64 can be programmed to request the vmebus as soon as any entries appear in the txfifo or only when the txfifo is filled. once the scv64 has obtained the vmebus, it will maintain ownership according to its bus release mode (see vmebus interfacebelow). for further information, see data path on page 2-36. dma controller for optimum bandwidth usage, the scv64 provides a dma controller suited to the transfer of large batches of data. with this in mind, the scv64 is designed to generate all outgoing blt and mblt cycles through the dma controller. in addition, all dma transfers are decoupled and make use of the rxfifo or txfifo. kdsackx
scv64 user manual introduction tundra semiconductor corporation 2-3 figure 2.1 : functional block diagram dma controller vme bus cycle generator vme bus local bus bus timer vme bus arbiter sysclk* driver auto syscon detect location monitor fifo bi mode rx fifo local bus cycle generator daisy chain drivers local bus requester vme bus requester local bus arbiter clocks, timers bypass path tx fifo address decode local bus interrupter local bus interrupt handler auto slot id vme bus interrupter vmebus interrupt handler register block syscon fifo controller local bus interface vmebus interface data path
introduction scv64 user manual 2-4 tundra semiconductor corporation the dma controller in the scv64 is software configurable for a variety of address and data modes (mblt, blt, a64, a32, a24, a16, d32, d16). various control and status registers allow the user to direct and monitor dma transfers. a transfer count register allows users to program up to 4 mbytes in one dma operation, and several error checking bits provide valuable tools for data recovery in the event of bus errors. to further maximize the rate of data transfer for dma operations or for incoming blt and mblt cycles, the scv64 provides a local burst mode. in burst mode, multiple blocks of data are transferred with only one address phase. if local burst reads are enabled, then the dma controller will initiate a local burst cycle to fill the txfifo. similarly, the scv64 can be programmed to initiate local burst writes whenever a series of blt or mblt entries appear in the rxfifo. for further information see dma controller on page 2-102. register access a wide range of status and control registers in the scv64 provide a window to scv64 operations and allow the user to configure the device for a variety of functional modes. registers may be accessed both from the local and the vme side, allowing local and other masters control over the boards vme interface. the scv64 always responds as a 32-bit port when a master accesses the address range occupied by its control and status registers. for further information see register access on page 2-87. location monitor the location monitor allows for inter-process communication between vme masters. writes to the location monitor generate a specific local interrupt ( ) which is usually tied to a local interrupt relayed to the cpu. data written to the location monitor enters a 32 bit wide, 31 stage deep location monitor fifo (lmfifo). the oldest entry in the lmfifo is automatically written to the lmfifo register. for further information see location monitor and lmfifo on page 2-101). bus isolation mode (bi-mode ? ) bi-mode is a unique feature offered by the scv64 which allows the user to functionally isolate a board from vmebus transactions. several bi-mode initiators are available to the user, allowing for different local designs. the user can reactivate an isolated board at any time. some potential applications for bi-mode are: ? hot standby systems, ? system diagnostics for routine maintenance, or ? fault isolation in the case of a board failure. for further information see bi-mode on page 2-119. lmint
scv64 user manual introduction tundra semiconductor corporation 2-5 2.1.2.2 vmebus interface vmebus requester the scv64 can be programmed to request the vmebus at any of the four (br3*, br2*, br1*, and br0*) levels given in the vmebus specification, and is configurable for either fair or demand mode. in fair mode, the scv64 will not issue a bus request until the bus is clear and there are no other requests pending. in demand mode, the scv64 will request the bus irrespective of requests at other levels. once the scv64 acquires the vmebus, its release of the bus depends upon whether it is programmed for release on request (ror) or release when done (rwd). with ror, the scv64 releases the bus only if another request is pending. in rwd mode, the scv64 releases the vmebus only when the current cycle is complete and the txfifo is empty. to support priority arbitration, the vmebus specification provides a bus clear signal (bclr*) to force low level requesters off the bus in favour of higher level requesters. the scv64 can be programmed to accept or ignore the bclr* signal. for further information see vmebus requester on page 2-8. vmebus interrupter the scv64 is a single level interrupter, software configurable for all seven vmebus interrupt levels. when the scv64 detects an iack cycle on the level of its current interrupt, it places an 8-bit interrupt vector on the bus and terminates the cycle (the scv64 is strictly release on acknowledgment, roak). while all vmebus interrupt levels are supported by the scv64, the level one vmebus interrupt (irq1*) may be reconfigured as a bi-mode initiator. when irq1* is set to this state, it is enabled and monitored through specific control and status registers. for further information see vmebus interrupts on page 2-13. vmebus interrupt handler all seven vmebus interrupt levels are accepted by the scv64, but since they are software maskable, the user is free to control which interrupt levels the scv64 receives. when a vme interrupt is enabled and received by the scv64, it is translated to a corresponding local interrupt and relayed to the local cpu via the lines. when the cpu generates an interrupt acknowledgment for a vme interrupt, the scv64 generates an iack cycle on the vmebus. in what is essentially a coupled read cycle, the scv64 accepts the interrupt vector from the vme interrupter and places it on the local bus for the cpu. for further information see interrupt handler on page 2-18. kipl2-0
introduction scv64 user manual 2-6 tundra semiconductor corporation system controller functions the scv64 automatically becomes vmebus system controller (syscon) if it resides at the top of the bus grant daisy chain. the following syscon functions are provided by the scv64: ?arbiter, ? bus timer, ? system clock driver. all arbitration modes defined in the vmebus specification are provided by the scv64, namely: ? full priority, ? round robin, and ? single level arbiter (a subset of full priority). in addition, two mixed priority modes are provided: ? priority level 3, and ? priority levels 2 and 3. the different arbitration modes are software configurable. there is also an arbitration time-out function to ensure that bus arbitration resumes in the event of an unanswered bus grant signal. similar to the arbitration timer, the scv64 provides a vme bus timer which times out unacknowledged cycles with bus error (berr*) unless the vme slave responds within a specific time. the vme bus timer is also software configurable and, if activated, can be set to 16, 32, or 64 s. the scv64 provides a 16mhz system clock within vme specifications. for further information see system controller functions on page 2-30. 2.1.2.3 local bus interface local arbiter/requester the scv64 provides an internal local arbiter which relays bus requests from a single sub- requester to the cpu or other external arbiters. the scv64 arbiter can be configured to either give priority to the external requester, or arbitrate between itself and the external requester at an equal priority level. the user may also entirely bypass the scv64 arbiter at power-up. the scv64 arbiter allows the external requester to maintain bus ownership with either bus grant acknowledgment or the bus request signal. by using bus grant acknowledgment to hold the bus, the bus request line is available to other local devices before the current cycle is complete.
scv64 user manual introduction tundra semiconductor corporation 2-7 for further information see local bus arbitration on page 2-66. local interrupter interrupts to the local cpu can be generated at any one of 7 levels using the lines. in its function as local interrupt handler, the scv64 uses the lines to relay interrupts from various sources (vme and local) to the cpu. two other local interrupts, and , are provided by the scv64 and are used to notify the cpu of specific scv64 activity. informs the cpu of writes to the location monitor, while is asserted whenever specific error and status bits become set. for further information see local bus interrupts on page 2-15. local interrupt handler the scv64 provides a local interrupt management function in that it accepts interrupts from different local sources, prioritizes the interrupts and then relays the signals to the local cpu via the lines. the handling of the subsequent cpu-generated iack cycle depends upon whether the original interrupt source is vectored or auto-vectored. if the local interrupter is vectored, the scv64 communicates the interrupt acknowledgment to the interrupt source which then places its interrupt vector on the local data bus. if the local interrupter is auto- vectored, then the scv64 signals the cpu to generate its own interrupt vector internally. for further information see interrupt handler on page 2-18. local clocks and timers three different clocks are made available by the scv64. baudclk provides a 2.4615 mhz signal for use by local devices generating baud rate clocks. a 14 s clock signal, derived from 32 mhz input, is constantly synchronized with the cpu clock. for additional general purpose applications, the scv64 generates an 8 mhz clock. along with the local clocks provided by the scv64, there are three local timers. these are: a local bus timer (synchronized to the cpu clock), the watchdog timer and the tick timer. for further information see resets, clocks and timers on page 2-110. kipl2-0 kipl2-0 lmint vmeint lmint vmeint kipl2-0
vmebus requester scv64 user manual 2-8 tundra semiconductor corporation 2.2 vmebus requester 2.2.1 function the scv64 vmebus requester requests vmebus ownership if: ? an outgoing cycle is initiated (see memory mapping on page 2-45), ? under the direction of its dma controller (see dma controller on page 2-102), or ? the cpu accesses its own vme slave image and the scv64 is in loopback mode (see loopback diagnostics on page 2-126). the scv64 releases the bus if: ? the vmebus signal bclr* is received (due to the arbiter receiving a higher priority vmebus request, ror mode), ? data transfer is complete (rwd mode), or ? its programmed ownership period has expired. while the scv64 owns the vmebus, it asserts bbsy* (as indicated by the mybbsy bit in the ctl2 register, table a.33). several request and release modes are listed in table 2.1 and described in the following sections. note: since the following initiators of request and release act independently of each other, some functional overlap may occur. table 2.1 : vmebus request and release modes request mode description fair or demand controls the interaction of the requester with bbsy* levels 3 to 0 vmebus request level release mode description bus clear enable or disable controls the interaction of the requester with bclr* release on request gives up bus ownership with any request release when done gives up bus ownership only when transaction is complete ownership time-out an optional timer can be used to limit the requesters ownership of the vmebus
scv64 user manual vmebus requester tundra semiconductor corporation 2-9 2.2.2 bus request modes 2.2.2.1 fair and demand modes the requester can be programmed for either the fair mode or the demand mode by setting the req control bit in the vreq register (see table a.30). in fair mode, the scv64 waits until there are no requests pending at its programmed level and bbsy* is high. this mode ensures that every requester on a given level has access to the bus. in demand mode (the default setting), the requester asserts its bus request under the following conditions: ? entries exist in the transmit fifo, ? coupled read or write is initiated by local bus, or ? a vmebus iack cycle is pending. by requesting the bus frequently, requesters far down the daisy chain may be prevented from ever obtaining bus ownership. this is referred to as starving those requesters. 2.2.2.2 vmebus request levels the level used by the requester is selected through the lvl1 and lvl0 bits in the vreq register (table a.30, see table 2.15 below). level 3 is the default setting after reset. during pri arbitration, level 3 has the highest priority and level 0 the lowest (see vmebus arbiter on page 2-31). caution: the lvl1 and lvl0 bits must not be changed while the vmebus is being arbitrated; that is, while the requester is propagating any bgnout* signals. changing these bits during arbitration may introduce pulses on the bgnout* signals of the current and next request levels involved. it is recommended that the bits be changed when the vmebus is not in use (such as after a reset when all potential masters are performing self tests and configuration, or while the system is in bi-mode). table 2.2 : setting vmebus request levels request level setting for lvl1,0 br0* 00 br1* 01 br2* 10 br3* 11 !
vmebus requester scv64 user manual 2-10 tundra semiconductor corporation if a request for the data transfer bus is initiated and then withdrawn, the scv64: 1. continues its request for vmebus ownership according to its programmed modes, 2. asserts bbsy* for at least the minimum specified time, and then 3. releases the bus. the protocol above is in compliance with the vmebus specification. the requester may initiate the protocol during the resolution of deadlock cycles when the cpu attempts a coupled access to the vmebus while the vmebus is already attempting a coupled access to the local bus. 2.2.3 bus release modes 2.2.3.1 bus clear enabling bus clear (bclr*) is asserted by the vmebus arbiter if a request is asserted that has higher priority than the current owner (see vmebus arbiter on page 2-31) or if bus ownership has timed out (see bus timer on page 2-34). release on bclr* is enabled by setting the bcen bit in the vreq register (table a.30, and below). if release on bclr* is enabled, the requester in the scv64 releases the bus when bclr* becomes asserted. the default setting after reset is with bclr* ignored. 2.2.3.2 release on request and release when done the scv64 can be programmed to either release on request (ror) or release when done (rwd). these two modes are controlled by rel bit in the vreq register (table a.30). when the rel bit is set to ror, the bbsy* signal is released by the requester only if a bus request is pending. in rwd mode (the default setting), the requester only releases the data transfer bus when: ? there are no further entries in the txfifo, ? the coupled cycle is complete, or ? the iack cycle is complete. caution: if the scv64 is programmed in fair and ror mode, and some other board is using the bus on the same request level, the cpu and scv64 may toggle endlessly, requesting bus grant and discarding it. to avoid this configuration, use different request levels, but not the fair and ror modes at the same time. !
scv64 user manual vmebus requester tundra semiconductor corporation 2-11 2.2.3.3 ownership timer vmebus ownership time can be limited using an ownership timer. the timer is enabled using the oten bit in the vreq register. the time-out period is selected using the ot1 and ot0 bits in the same register (table a.30, and see table 2.3 below). if the ownership timer is enabled (the default setting), the requester releases the vmebus after it has owned it for the programmed time (8 s is the default setting). programming the ot1and ot0 bits for zero time limits the scv64 to only one or two transfers on the bus. if the ownership timer is not enabled the ownership period is unlimited. the ownership timer permits rapid bus mastership switching by allowing other vme masters predictable bus access latencies. 2.2.4 other bus release mechanisms 2.2.4.1 local memory interrupt asserting the pin causes the scv64 to release the vmebus when the pin is enabled (see interrupt enabling and status on page 2-20). in addition, no further bus requests will be issued while is asserted. if is asserted after a request has been issued, the scv64: 1. obtains the bus, 2. asserts bbsy* for at least the minimum required time and releases the bus with- out performing any transfers. the input can be programmed to indicate a local memory failure. using this feature, the requester will prevent a device such as dma from transferring unreliable memory contents to the bus until the local cpu has resolved the memory fault and cleared . table 2.3 : setting the vmebus ownership timer timer duration setting for ot1,0 0 time 00 2 s 01 4 s 10 8 s (default) 11 l7imem l7imem l7imem l7imem l7imem l7imem
vmebus requester scv64 user manual 2-12 tundra semiconductor corporation 2.2.4.2 bi-mode bi-mode has the same effect on the requester as . the requester releases the bus and will not generate any new bus requests. requests in progress are completed and then aborted with minimum bbsy* assertion. bi-mode functionality is described in bi-mode on page 2-119. 2.2.4.3 local and system reset local or system reset causes the requester to immediately deassert all of its outputs including: ? any bus requests, ? any bus grants, and ? bbsy*. note that deasserting a request in progress through a local or system reset may generate improper timing of a bus grant propagating on the level programmed for use by the requester. l7imem
scv64 user manual interrupter tundra semiconductor corporation 2-13 2.3 interrupter 2.3.1 vmebus interrupts 2.3.1.1 interrupt generation the scv64 can be programmed to generate vmebus interrupts on any one of the seven vme interrupt levels. the interrupt level and interrupt initiation are both controlled by the vint register (table a.29). interrupt level is set using the il2-il0 bits, see table 2.4 for a complete listing of vmebus interrupt levels and il2-il0 encoding. setting the int bit in the same register initiates a vmebus interrupt at the level programmed with the il0-il2 bits. the scv64 clears the int bit after the interrupter has placed its interrupt vector on the data transfer bus. note that an interrupt can only be deasserted by writing 0 to the il2-il0 bits in the vint register. writing 0 to the int bit has no effect on interrupt assertion. the irq1* signal can be configured either as an interrupt or as a bi-mode initiator. by default, the irq1* signal serves as a bi-mode initiator. under this configuration, setting the abi bit in the genctl register (table a.28) asserts irq1* as a bi-mode initiator. alternatively, irq1* can be configured as a vmebus interrupt by clearing the vi1bi bit in the genctl register. caution: changing the interrupt level while int is state 1 may cause improper operation in the iack dcd logic. table 2.4 : encoding for vmebus interrupt levels vmebus interrupt level setting for il2-il0 7 111 6 110 5 101 4 100 3 011 2 010 1 001 0 (no interrupt) 000 !
interrupter scv64 user manual 2-14 tundra semiconductor corporation when the scv64 detects an iack cycle on its interrupt level, it places its 8-bit interrupt vector on the data lines vdata 07-00 and asserts dtack* (the scv64 is strictly release on acknowledgment, roak). the interrupt vector is held on the bus until ds0* is negated. the interrupt vector is programmed into the lower 8-bits of the ivect register (table a.15). although the upper 3 bytes of the ivect register are unused, the register must still be accessed as a longword port. in addition, since the scv64 is strictly an 8-bit interrupter, the data strobe and lword* signals are not decoded for information about data transfer size. 2.3.1.2 bi-mode effects entry into bi-mode causes any scv64-generated interrupts to be immediately deasserted. if the scv64 is asserting an interrupt, then the iack daisy chain will be sensitive to bi-mode entry if it is generating iackout*. under these circumstances, the scv64 will either rescind the signal or not generate iackout*. typically, a vme data transfer timer will then end the iack cycle by asserting berr*. the interrupter can be programmed while it is in bi-mode. although no interrupts are asserted while the scv64 is in bi-mode, programmed interrupts will be asserted when the scv64 exits bi-mode. to cancel a pending interrupt, the il2-il0 bits in the vint register must be cleared. when the scv64 exits bi-mode, the interrupt logic completes the clearing operation by resetting the int bit in the vint register. 2.3.1.3 reset effects any reset (power reset, system reset, external reset or software reset, see resets on page 2-110) will return the scv64 registers to their default settings. therefore, after reset the user can expect that: ? all vmebus interrupts are deasserted (the il2-il0 bits in the vint register have been cleared), and ? the irq1* signal has returned to its default configuration as a bi-mode initiator.
scv64 user manual interrupter tundra semiconductor corporation 2-15 2.3.2 local bus interrupts as part of its function as interrupt handler, the scv64 generates interrupts to the cpu using the kipl2-kipl0 signals (see figure 2.2 on page 2-19). the kipl2-kipl0 signals encode7 possible cpu interrupt levels (level 7 to 1) according to table 2.5. interrupt requests from level 7, local, and vme sources are all channelled via prioritizing logic to a common set of cpu interrupt levels. level 7 interrupts are automatically mapped to the highest cpu interrupt level, while vmebus interrupts are all pre-mapped to their corresponding cpu interrupt levels. however, the general local interrupts ( - ) can be programmed to different cpu interrupt levels. the kipl2-kipl0 signals assert asynchronously upon the assertion of any local interrupt source, and similarly only negate (kipl [2:0] = 111) once the source interrupt is negated. if a higher priority interrupt occurs, then the kipl2-kipl0 signals immediately change to reflect the new interrupt level. local interface logic should be designed to latch the interrupt level on the kipl [2:0] lines when generating the level for an interrupt acknowledge cycle. table 2.5 : kipl2-kipl0 encoding for cpu interrupt levels cpu interrupt level setting for kipl2-kipl0 7 000 6 001 5 010 4 011 3 100 2 101 1 110 0 (no interrupt) 111 lirq5 lirq0
interrupter scv64 user manual 2-16 tundra semiconductor corporation local interrupt level mapping is performed through the ic10 register (table a.39), the ic32 register (table a.40), and ic54 register (table a.41) (see table 2.11 below for a complete listing of general local interrupts and their corresponding mapping bits). each interrupt source has a group of 3 mapping bits which are used to assign that particular interrupt pin a cpu interrupt level between 0 and 7. for example, writing 001 to bits 3l2, 3l1 and 3l0 in the ic32 register maps to cpu interrupt level 1 (table 2.12 below provides the encoding for different interrupt levels). all general local interrupts default to cpu interrupt level 0 after reset. two other local interrupt sources are available by using the and pins. these two interrupts can typically be tied to any of the general local interrupt inputs ( - ). is held asserted while there are entries in the location monitor fifo, as indicated by the lmhd bit in the dcsr register (see location monitor and lmfifo on page 2-101). while the / pin is in mode (see page 2-25), the signal is tied to the line. table 2.6 : mapping bits for general local interrupts local interrupt register mapping bits ic54 5l2-5l0 4l2-4l0 ic32 3l2-3l0 2l2-2l0 ic10 1l2-1l0 0l2-0l0 table 2.7 : encoding for general local interrupt level mapping cpu interrupt level setting for mapping bits 7 111 6 110 5 101 4 100 3 011 2 010 1 001 0 (no interrupt) 000 lirq3 lirq5 lirq4 lirq3 lirq2 lirq1 lirq0 lmint vmeint lirq5 lirq0 lmint lirq2 kiack kiack lmint lirq2
scv64 user manual interrupter tundra semiconductor corporation 2-17 the signal is asserted when any of the following flags in the dcsr register become set: ? cerr (indicating a dma configuration error, see dma completion and error checking on page 2-108), ? rmcerr (indicating a lockup in a read modify write cycle, see during burst transfers, the scv64 presents addresses only at burst length boundaries. therefore, for some applications, a local address counter has to be provided as the scv64 does not increment the addresses during the burst. on page 2-96), ? dlberr (indicating a local bus error while the dma controller owns the local bus, see dma completion and error checking on page 2-108), ? lberr (indicating a local bus error during data transfer from the rxfifo, see dma completion and error checking on page 2-108), ? vberr (indicating a vmebus error during data transfer from the txfifo, see dma completion and error checking on page 2-108), and ? done (indicating that the dma data transfer is complete, see dma completion and error checking on page 2-108). vmeint
interrupt handler scv64 user manual 2-18 tundra semiconductor corporation 2.4 interrupt handler the interrupt handler module (shown in figure 2.2 on page 2-19) accepts interrupt requests from three groups of interrupt sources. these are listed below according to their priority: 1. level 7 interrupts, 2. general local interrupts, and 3. vmebus interrupts. figure 2.2 shows how the different interrupt sources are prioritized and channelled to interrupt levels recognized by the cpu (as encoded by the signals). not only are all interrupt sources channelled through a common interrupt handler module, but all interrupt acknowledge cycles are processed by the same acknowledge module (see figure 2.2). the acknowledge module output depends upon the interrupt level and the original interrupt source. this section first describes how to enable interrupts and monitor their status, and then discusses the different types of iack cycles. table 2.8 : properties of interrupt sources interrupt sensitivity maskable latch latch readable source readable vectored auto- vectored bimode level yes yes yes yes no yes edge no yes yes yes no yes level yes yes yes yes no yes sysfail* level yes yes yes yes no yes level yes yes yes yes no yes level yes no no yes yes yes level yes no no yes no yes irq7-2* level yes no no no yes no irq1* level yes no no yes yes (as irq1*) yes (as bi-mode signal) kipl2-0 l7nmi l7imem l7iacf lirq5-4 lirq3-0
scv64 user manual interrupt handler tundra semiconductor corporation 2-19 figure 2.2 : interrupt handler block diagram latch latch latch latch enable enable enable enable enable enable enable enable enable enable enable enable enable enable enable enable map map map map map map prioritizing logic interrupt enabled by control bit latches interrupt cleared by disable maps interrupt to any cpu level 1-7 samples interrupts at start of cycle symbol legend latch enable map sampler l7nmi l7imem l7iacf bimode lirq5 lirq4 lirq3 lirq2 lirq1 lirq0 irq7* irq6* irq5* irq4* irq3* irq2* irq1* kipl2 kipl1 kipl0 kavec iack* liack5 liack4 kiack and cpu acknowledge level status status status interrupt sources to cpu from cpu to interrupter acknowledge sampler latch enable sysfail*
interrupt handler scv64 user manual 2-20 tundra semiconductor corporation 2.4.1 interrupt enabling and status each interrupt group has its own control register for enabling. the 7ie register (table a.36) enables level 7 interrupts, the lie register (table a.37) enables general local interrupts, and the vie register (table a.38) enables vmebus interrupts. the interrupt source is enabled by setting its corresponding control bit (see table 2.9 for a complete listing). note that is always enabled and its control bit in the 7ie register only serves to clear the interrupt. note that irq1* defaults as a bi-mode initiator. to use irq1* as a vme interrupt signal, the user must clear the vi1bi bit in the genctl register (table a.28). do not assert irq1* via the abi bit in the genctl register when irq1* is configured as a vme interrupt. all level 7 interrupts (except l7inmi ) are reset by disabling and then re-enabling them through their corresponding control bit. l7inmi is reset by clearing the nmiclr bit in the 7ie register. the status of level 7 interrupts and general local interrupts is monitored through interrupt status registers. as shown in figure 2.2 on page 2-19, the status of level 7 interrupts can be read both at the pin level (stat0 register, table a.26) and the latch level (7is register, table a.34). the status of general local interrupts is monitored only at the pin level through the lis register (table a.35). if the interrupts corresponding status bit is set, then the pin is asserted (or the interrupt is latched in the case of the 7is register). see table 2.10 below for a complete list of level 7 and vmebus interrupts with their corresponding status bits. table 2.9 : control bits for interrupt sources level 7 interrupts control bits in 7ie register general local interrupts control bits in lie interrupts vmebus interrupts control bits in vie registers nmiclr l5e irq7* v7e memie l4e irq6* v6e acfie l3e irq5* v5e bimode bie l2e irq4* v4e sysfail* syfie l1e irq3* v3e l0e irq2* v2e irq1* v1e l7inmi l7nmi lirq5 l7imem lirq4 l7iacf lirq3 lirq2 lirq1 lirq0
scv64 user manual interrupt handler tundra semiconductor corporation 2-21 note the status of vmebus interrupts cannot be monitored. the exception is irq1*, which can serve as a bi-mode initiator and is monitored through the vi1 bit in the stat0 register (table a.26). 2.4.1.1 local interrupt level mapping by definition, level 7 interrupts are all mapped to the highest cpu interrupt level ( = 000), while vmebus interrupts are all pre-mapped to their corresponding cpu interrupt levels. however, the general local interrupts ( - ) can be programmed to different cpu interrupt levels. local interrupt level mapping is performed through the ic10 register (table a.39), the ic32 register (table a.40), and ic54 register (table a.41) (see table 2.11 below for a complete listing of general local interrupts and their corresponding mapping bits). each general local interrupt source has a group of 3 mapping bits which are used to assign that particular interrupt pin a cpu interrupt level between 0 and 7. for example, writing 001 to bits 3l2, 3l1 and 3l0 in the ic32 register maps to cpu interrupt level 1 (table 2.12 below provides the encoding for different interrupt levels). all general local interrupts default to level 0 after reset. table 2.10 : status bits for interrupt sources level 7 interrupts - pin status status bits in stat0 register level 7 interrupts - latch status status bits in 7is register general local interrupts status bits in lis interrupts nmiip nmiis li5 memip memis li4 acfip acfis li3 bimode vi1 bimode bis li2 sysfail* syfip sysfail* syfis li1 li0 l7nmi l7nmi lirq5 l7imem l7imem lirq4 l7iacf l7iacf lirq3 lirq2 lirq1 lirq0 kipl2-0 lirq5 lirq0 lirq3
interrupt handler scv64 user manual 2-22 tundra semiconductor corporation since and can be vectored or auto-vectored, the ic54 register contains bits (5av and 4av) which are used to set these interrupts to either of these states. the interrupt is auto- vectored if its corresponding auto-vector control bit is set. for example, clearing the 5av bit in the ic54 register programs as a vectored interrupt. interrupts - can only be auto-vectored. the auto-vector control bits default to 0 after reset ( and are vectored). 2.4.2 interrupt acknowledge cycles figure 2.2 on page 2-19 shows that when the interrupt handler module receives an interrupt request (either vectored or auto-vectored), it propagates the interrupt to the cpu using the signals. when the local cpu receives the interrupt, it generates an interrupt acknowledge cycle. this iack cycle can be either decoded by an external device or decoded internally by the scv64. in either case, the iack cycle generated by the cpu leads to the scv64 receiving . the input signals the scv64 to generate an iack cycle. table 2.11 : mapping bits for general local interrupts local interrupt register mapping bits ic54 5l2-5l0 4l2-4l0 ic32 3l2-3l0 2l2-2l0 ic10 1l2-1l0 0l2-0l0 table 2.12 : encoding for general local interrupt level mapping cpu interrupt level setting for mapping bits 7 111 6 110 5 101 4 100 3 011 2 010 1 001 0 (no interrupt) 000 lirq5 lirq4 lirq5 lirq3 lirq0 lirq5 lirq4 lirq5 lirq4 lirq3 lirq2 lirq1 lirq0 kipl2-0 kiack kiack
scv64 user manual interrupt handler tundra semiconductor corporation 2-23 / are functionally defined at power-up (see figure 2.3), and the mode for this pin depends upon whether the scv64 uses internal or external local iack decoding. the iack cycle level need not match the current level reflected on the kipl lines. any active and enabled interrupt level may be acknowledged. for interrupts mapped to the same level, the acknowledge priority is: ? any auto-vectored interrupts on that level, ? lirq 5 if vectored and programmed for that level, ? lirq 4 if vectored and programmed for that level, ? the vme interrupt on that level. for internal iack decoding ( / pin serves as ) the scv64 requires: ? kfc = 111, ? kaddr3-1 = level of interrupt being acknowledged (see table 2.13 below), ? kaddr0 = 1 ? = 0, ? kaddr19-16 = 1111, and ? = 0. for external iack decoding ( / pin serves as ) the scv64 requires: ? = 0, ? kaddr3-1 = level of interrupt being acknowledged (see table 2.13 below), ? kaddr0 = 1, ? = 0, and ? = 0. lirq2 kiack lirq2 kiack lirq2 kas kds lirq2 kiack kiack kiack kas kds
interrupt handler scv64 user manual 2-24 tundra semiconductor corporation in mode, the signal is internally tied to the line (see figure 2.3). table 2.13 : kaddr3-1 encoding for cpu interrupt levels cpu interrupt level signal on kaddr3-1 7 111 6 110 5 101 4 100 3 011 2 010 1 001 kiack lmint lirq2 kiack lirq2 lmint lmint kiack lirq2 / kiack lirq2 lmint lmint kiack lirq2 / external decoding internal decode figure 2.3 : connections resulting from changing local iack decoding internal decoding
scv64 user manual interrupt handler tundra semiconductor corporation 2-25 table 2.14 : correlation between kfc1 and local iack decoding 2.4.2.1 auto-vectored interrupts if the interrupter cannot supply an interrupt vector, then the iack cycle is terminated with (see figure 2.4 and figure 2.5 below). signals the cpu to generate its own interrupt vector internally. the scv64 acknowledge module shown in figure 2.2 on page 2-19 asserts if it samples any of the following interrupts: ? all local dedicated level 7 interrupts, ? and (if configured as auto-vectored), or ? to . note: since the scv64 auto-vectors all level 7 interrupts, expanding any of the pins to more sources is easily accomplished by wire or-ing several signals and adding a pull-up resistor to any of the pins. kfc1 mode high low kiack lirq2 kavec kavec kavec lirq5 lirq4 lirq3 lirq0 l7ixxx l7ixxx
interrupt handler scv64 user manual 2-26 tundra semiconductor corporation 2.4.2.2 vectored interrupts vectored interrupts may originate from either local sources (using or ) or vmebus interrupters. the flow for these two types of iack cycles are similar and are both described in figure 2.6 on page 2-28. however, because the iack cycle for a vmebus interrupter is essentially a coupled read, its timing differs significantly from a local vectored iack cycle (see figure 2.5 on page 2-27). see local cycles C overview on page 2-73 and scv64 as local slave on page 2-78 for further information on local bus cycles. local interrupter scv64 local cpu figure 2.4 : local interrupt cycle - auto-vectored - decode priority - assert kipl2-0 generate iack cycle - see interrupt acknowledge cycles on page 2-22 generate interrupt - assert or l7ixxx lirqx terminate iack cycle - assert kavec terminate iack cycle - negate above signals - perform interrupt routine lirq5 lirq4
scv64 user manual interrupt handler tundra semiconductor corporation 2-27 the scv64 signals a local vectored interrupter about the iack cycle by asserting or , depending upon the original interrupt. when the local interrupter receives notification of iack, it places the interrupt vector on the data bus and asserts . the cpu latches the vector and negates and . in a similar manner, the scv64 notifies a vme interrupter of the iack cycle by asserting iack*. when the vmebus interrupter receives iackin* on its iack daisy chain driver, it places its 8 bit vector on the vmebus and asserts dtack*. as in any coupled read, the scv64 transfers the data from the vmebus to the local data bus and asserts . the cpu latches the data and negates and . vectored iack cycles with a vme interrupter differ from a strictly local iack cycle in that the scv64 places the vector on the local data bus. in addition, since the iack cycle for a vme interrupter is coupled, the vmebus is only released when the local iack cycle is complete. liack5 liack4 kdsackx kds kas kdsackx kds kas figure 2.5 : timing for local interrupts s0 s1 s2 s3 s4 s5 sw sw kaddr16-19 kfc kiack kds kwr kclk kdsackn liackn kavec kaddr1-3 lirqn kas
interrupt handler scv64 user manual 2-28 tundra semiconductor corporation interrupter scv64 local cpu generate interrupt local - assert or vme - assert irqx* lirq5 lirq4 - decode priority - assert kipl2-0 generate iack cycle - place interrupt level on kaddr03-01 - kaddr19-16 = 1111 - set kfc2-0 for cpu space - assert and kas kds translate iack cycle local - assert or depending upon original source vme - obtain vmebus - assert as*, ds0* - assert iack* - vaddr03-01 liack5 liack4 acquire vector - latch data - negate , , etc. kas kds terminate local cycle - remove data from bus (for read) - negate kdsackx terminate coupled cycle - negate - negate ds0*, as*, iack*, vaddr kdsackx start next cycle present vector local - place data on kdata - assert vme - place data on vdata - assert dtack* kdsackx transfer data - place interrupt vector on kdata - assert kdsackx figure 2.6 : vectored interrupt cycle - with local and vme interrupter
scv64 user manual interrupt handler tundra semiconductor corporation 2-29 2.4.2.3 bi-mode effects if the scv64 is in bi-mode, it will still decode vmebus interrupts to the cpu. however, local iack cycles generated by the cpu in response to vmebus interrupts will not be propagated to the vmebus. the local bus timer is expected to time out the local iack cycle with . 2.4.2.4 reset effects resetting the scv64 returns its registers to their default settings. therefore, all interrupts (except ) will be disabled (see interrupt enabling and status on page 2-20). the user must re-initialize all interrupt control registers after reset. kberr l7inmi
system controller functions scv64 user manual 2-30 tundra semiconductor corporation 2.5 system controller functions 2.5.1 syscon determination the scv64 samples bg3in* 500 ns after the pin is deasserted, and at every rising edge of sysrst*. if bg3in* is sampled low, the scv64: ? becomes the syscon, ? enables its syscon functions, and ? sets the sysc bit in the stat1 register (table a.27). if bg3in* is high, the scv64 does not become, or ceases to be, the syscon, and clears the sysc bit in the stat1 register. if desired, the sysc bit may be used to either enable or disable syscon functions. caution: software designers should ensure that there is no activity on the vmebus before enabling or disabling the syscon through this bit. to ensure automatic syscon determination, the board in slot 1 must have a 10k? pull-down resistor from bg3in* to ground. if the host board is not at the top of the bus grant daisy chain, then the preceding board in the chain drives the bgnin* signals. during system reset, the vmebus specification requires that boards reset and drive their bgnout* signals high. if the scv64 host board is at the top of the bus grant daisy chain, the pull-down resistor will drive bg3in* low, ensuring that the scv64 in slot 1 becomes syscon. caution: the scv64 requires that the board preceding it in the bus grant daisy chain adhere to the vmebus specification that all bus grant outputs be driven high during reset. if the preceding board is driving its bg3out t low at the end of reset, then more than one scv64 could become system controller, causing a system malfunction. pwrrst ! !
scv64 user manual system controller functions tundra semiconductor corporation 2-31 2.5.2 iack daisy chain driver when the scv64 is syscon, it generates iackout* which is passed along the iack daisy chain. when the interrupter receives iackin* on the same level as it is currently requesting, it will respond to the interrupt acknowledge cycle and not propagate the falling edge down the iack daisy chain. the interrupter places its status/id onto the data bus and terminates the iack cycle with dtack*. otherwise, the iack daisy chain driver asserts iackout* and the next board receives its opportunity to respond to the interrupt acknowledgment. note that due to the use of the iack daisy chain driver in an auto-id system on the scv64 (see auto-id on page 2-121), iackout* assertion will be delayed by an extra 5 clock cycles for the first level one interrupt after system reset. 2.5.3 vmebus arbiter the arbiter module is enabled whenever the scv64 is the system controller. there are four programmable arbitration modes as well as an arbitration time-out function. 2.5.3.1 arbitration modes the scv64 provides all arbitration modes defined in the vmebus specification. these are: ? full priority (pri), ? round robin, and ? single level arbiter (a subset of full priority). in addition, two mixed priority modes are provided: ? priority level 3, and ? priority levels 2 and 3.
system controller functions scv64 user manual 2-32 tundra semiconductor corporation all arbitration modes are determined by the arb1 and arb0 bits in the varb register (table a.31, and below). since arbiter logic continuously samples the varb register, any changes to arb1 and arb0 will immediately be reflected in the current arbitration mode. the arbiter defaults to full round robin mode after reset. full priority arbitration in the full priority mode, the order of priority is br3*, br2*, br1*, br0*, as defined by the vmebus specification. the arbiter samples these lines every 31.25 ns and issues a bus grant to the highest requesting level. if a bus request of a higher priority than the current bus owner becomes asserted, the arbiter asserts bclr* until the owner releases the bus (bbsy* released). full round robin arbitration this mode arbitrates all levels in a round robin mode, repeatedly scanning from levels 3 to 0. only one grant is issued per level and one owner is never forced from the bus in favour of another requester (bclr* is never asserted). since only one grant is issued per level on each round robin cycle, several scans will be required to service a queue of requests at one level. if each requester on a round robin level is in the fair mode (see fair and demand modes on page 2-9), then every board eventually receives bus ownership. single level arbiter a single level arbiter can be implemented by programming the arbiter to full priority mode, and then connecting all requesters to level 3. leaving the arbiter in default round robin mode wastes time by scanning unused levels. there is no provision for masking off-bus request levels. table 2.15 : setting vmebus arbitration modes arbitration mode setting for arb1,0 full round robin 00 priority 3, round robin 2,1,0 01 priority 3, 2; round robin 1,0 10 full priority 11
scv64 user manual system controller functions tundra semiconductor corporation 2-33 br3* priority this version of mixed mode arbitration gives immediate priority to br3* while br2*, br1* and br0* are allocated to a round robin group. the arbiter repeatedly scans levels 2, 1 and 0 in a circular fashion and if a request is detected on one of those levels, then a bus grant is issued. the scan continues only after the owner releases the bus by deasserting bbsy*. round robin arbitration is superseded if a request on level 3 is made. with a level 3 request, bclr* is asserted to clear the bus of any lower priority owner. after all pending requests on level 3 have been granted, the scanning of the round robin group continues at the point of interruption. note that multiple requests on level 3 may prevent levels 2 through 0 from obtaining the bus. br3*, br2* priority this mixed arbitration mode is similar to the br3* priority mode, in that levels 1 and 0 are allocated to a round robin group, while requests at levels 3 or 2 are given priority. the arbiter scans levels 1 and 0, issuing one bus grant per level per scan. round robin arbitration is interrupted if a request occurs at level 3 or 2. the arbiter asserts bclr* to clear the bus for the highest priority (level 3 or 2) request. level 3 has priority over all other levels, and all requests pending on that level are served first. requests on level 2 are also all granted before round robin group scanning is resumed. unless there is heavy bus traffic on levels 3 or 2, all requesters on levels 1 and 0 eventually gain access to the bus if they request in the fair mode (see fair and demand modes on page 2-9). 2.5.3.2 arbitration time-out arbitration time-out ensures that bus arbitration will resume if bbsy* is not asserted within 16 s of a bus grant signal. time-out returns the arbiter to its previous mode and outstanding requests. arbitration time-out is enabled by default and is deactivated by clearing the aten bit in the varb register (table a.31). 2.5.3.3 reset effects local reset does not disrupt arbiter operation, although the arbiter will revert to its default settings (the varb register is re-initialized). system reset and power reset immediately cause deassertion of all arbiter signals. additional information concerning reset effects is provided in resets on page 2-110.
system controller functions scv64 user manual 2-34 tundra semiconductor corporation 2.5.4 bus timer the scv64 uses berr* to terminate vmebus data transfers if a slave does not respond within a specific programmed time. the time-out period before berr* is driven low can be 16 s, 32 s, 64 s (the default setting), or never, depending upon the value of the vxl1 and vxl0 bits in the varb register (table a.31). the never setting should only be used during system debug, since the vmebus cannot recover from errors (such as incorrect addressing) in this mode. note also that the auto-id function depends on bus time-out. the timer is held reset while ds1* and ds0* are high, and begins running when either data strobe becomes asserted. at time-out, the scv64 asserts and maintains berr* until both ds1* and ds0* are high. note that a race condition can occur if a slave takes a long time to respond and asserts dtack* coincidentally with the scv64 assertion of berr*. under these conditions, the master may see dtack* and berr* simultaneously. on-board logic may be required to respond to this conflict. 2.5.5 system clock driver when the scv64 is the syscon, the sysclk driver supplies a 16 mhz, 50% duty cycle clock, meeting vmebus specifications. the scv64 provides this clock before sysrst* deasserts at power-up. if two scv64s exchange syscon roles at a sysrst* deassertion, then an invalid level may occur for one or two clock periods while one sysclk driver is enabled and the other is disabled. 2.5.6 external inputs 2.5.6.1 external status the bg2in* and bg1in* signals are available as user defined, off-board input status bits when the scv64 is syscon. the input from these two pins is read from the bg2in and bg1in bits in the stat1 register (table a.27). table 2.16 : setting vmebus time-out period time-out period setting for vxl1,0 never 00 16 s 01 32 s 10 64 s (default) 11
scv64 user manual system controller functions tundra semiconductor corporation 2-35 the bg2in and bg1in bits indicate the true state of the bg2in* and bg1in* pins, which in turn may indicate different system modes defined by the user. note: the bg2in and bg1in bits are not sampled and can change while being read. 2.5.6.2 off-board reset input when the scv64 is syscon, a low level on the bg0in* pin for more than 70 ms will initiate system reset. the sysrst* signal will remain asserted for 0.25 sec beyond the release of bg0in*. sensitivity to noise on the bg0in* line is reduced by a digital pulse filter. bg0in* is sampled every 14.3 ms, and four successive low samples must be recorded before sysrst* is driven low. the digital pulse filter introduces a latency period of 43 to 57 ms between bg0in* assertion and sysrst* assertion. caution: the bgoin* pin does not provide a schmitt trigger input circuit. therefore, the pin must be pulled up with a resistor if it is unused and the scv64 is in slot 1. 2.5.7 reset effects on syscon functions local reset may alter arbiter function by resetting the varb register to its default settings (see vmebus arbiter on page 2-31). however, the arbiter is designed to accept mode changes during operation, so re-initialization of the varb register will not generate any improper responses. similarly, arbitration time-out will be returned to its enabled default setting after local reset (see arbitration time-out on page 2-33). if the disabled option is required, the user will have to re-initialize the varb register. since local reset re-initializes all registers to their default settings, the user can expect the data transfer timer to return a setting of 64 s. the counter will be cleared correctly when ds1* and ds0* are both high, but the reset may result in improper operation if the timer has just expired. if the timer has asserted berr* just before the reset (when programmed to 16 or 32 s), berr* is deasserted until the 64 s mark is reached, and then re-asserted. !
data path scv64 user manual 2-36 tundra semiconductor corporation 2.6 data path the scv64 can transfer data across the local/vmebus interface in either a coupled or decoupled mode. the coupled mode is the conventional vmebus cycle (see figure 2.7 below). because mastership of three buses is maintained during a coupled transfer (master local bus, vmebus, and slave local bus), two buses are idle while the third bus performs its cycle(s). this idle time constitutes a loss in effective bus bandwidth. decoupled mode uses fifos to buffer the local bus from the vmebus. data from the vmebus is written to a 15 stage deep, 71-bit wide receive fifo (rxfifo). once the incoming cycles are recorded and queued within the rxfifo, the scv64 asserts dtack* and ends the vmebus cycle. having freed the vmebus for other operations, the rxfifo then obtains the local bus and completes the data transfer. note that in decoupled mode the scv64 gives a vme slave response as close to the minimum permitted by the vme specification. the rxfifo is reset using the rxrst bit in the dcsr register (table a.6). data from the local bus is written to a 15 stage deep, 72-bit wide transmit fifo (txfifo) in the scv64. once the outgoing cycles are recorded and queued within the txfifo, the scv64 asserts and ends the local cycle. having freed the local bus for other operations, the txfifo obtains the vmebus and completes the data transfer. this decoupled operation permits single wait state writes to the vmebus. the txfifo is reset using the txrst bit in the dcsr register (table a.6). for both types of fifos, different cycle types from different sources may be interleaved and are individually managed (e.g. cpu cycle interleaved with dma cycles in the rxfifo). in both incoming (vme to local) and outgoing (local to vme) transfers, the fifos decouple the local and vmebus by allowing the bus cycles to be sequential and independent. decoupling the local and vmebus in this manner maximizes vmebus throughput (less time is lost waiting for completion of local bus cycles) and minimizes local bus loading. although incoming and outgoing transfers are similar, the function of the rxfifo and txfifo differ in some respects. the detailed operation of data transfers in these two directions will be discussed separately below (scv64 as vme slave on page 2-39 and scv64 as vme master on page 2-41). dma transfers, which are strictly decoupled, will be discussed separately, since dma entails a different application of the receive and transmit fifos. kdsackx
scv64 user manual data path tundra semiconductor corporation 2-37 master local bus vmebus slave local bus initiate vmebus cycle request the vmebus and wait for bus grant drive the cycle onto bus assert ds* and wait for dtack* decode cycle arbitrate for local bus drive cycle onto local bus wait for dsack from local device local bus released vmebus driven with dtack* vmebus released cycle complete, release bus. figure 2.7 : coupled cycles on the vmebus master local bus engaged vmebus engaged slave local bus engaged
data path scv64 user manual 2-38 tundra semiconductor corporation master local bus vmebus slave local bus cycle complete, dtack* from slave scv64 request the vmebus and wait for bus grant drive the cycle onto bus assert ds* and wait for dtack* initiate vmebus cycle arbitrate for local bus drive cycle onto local bus wait for dsack from local device local bus released vmebus released scv64 decodes cycle and responds with dsack. bus released figure 2.8 : decoupled cycles on the vmebus to txfifo to rxfifo
scv64 user manual data path tundra semiconductor corporation 2-39 2.6.1 scv64 as vme slave 2.6.1.1 coupled mode reads from a slave scv64 are always coupled, although writes may be either coupled or decoupled. coupled mode for vme slave write cycles is programmed by setting the rxatom bit in the mode register (table a.21). if the bit is set while entries still exist in the rxfifo, then the scv64 completes all pending cycles in the rxfifo before entering coupled mode. clearing this bit returns the scv64 to decoupled mode (its default setting). while in coupled mode, the local bus is released after each local cycle. the exception is during mblt slave reads in which the local bus is released every two local cycles. the scv64 samples and on the falling edge of the local clock and ends the cycle when or are double sampled low. when the local cycle is terminated, the scv64 asserts dtack* to end the vmebus cycle. if a slave read is initiated while there are entries in its rxfifo, the cycles in the rxfifo will be completed before the coupled read is allowed. similarly, the scv64 will complete all entries in its txfifo before initiating a coupled master read cycle. in both cases the master cpu will execute wait states until the fifo is empty. completing pending write cycles before allowing reads ensures sequential consistency; that is, the data being read is the most current. caution: the rxatom bit should not be modified by the local cpu while there is the possibility of an incoming vme slave cycle because this might prevent the scv64 from decoding the cycle. in order to ensure that there is no incoming vme cycle, the user can program the scv64 to obtain ownership of the vmebus. once the scv64 has ownership of the vmebus, the state of the rxatom bit may be changed. (see page 2-22). 2.6.1.2 decoupled mode writes to a slave scv64 may be either coupled or decoupled. the scv64 is programmed for decoupled mode by clearing the rxatom bit in the mode register (see table a.21). the scv64 defaults to decoupled mode. the rxatom bit in the mode register should not be modified by the local cpu while there is the possibility of an incoming vmebus slave cycle since the scv64 may not be able to decode the incoming cycle. if you need to modify the rxatom bit when there is the possibility of an incoming vmebus slave cycle, see the programming solution described on page a-24. after the slave address decoder and protection logic validate the access, write cycles from the vmebus are loaded into the rxfifo and acknowledged with dtack* on the vmebus. if the access is protected (see access protection on page 2-52), the scv64 asserts berr*. kdsackn kberr kdsackn kberr !
data path scv64 user manual 2-40 tundra semiconductor corporation if the rxfifo is full, the scv64 does not accept writes until at least one is cleared from the rxfifo, making space available. note that the vmebus data transfer rate is limited by the rate at which the slave local bus completes its cycles. therefore, a full rxfifo effectively couples the buses. if the rxfifo cannot perform its writes on the local bus, the vmebus transfer times out with a berr* signal. each 71-bit entry in the rxfifo is made up of 3 components - control, address, and data. the 3 components for the most current or last completed cycle (the oldest entry in the rxfifo) are read from: ? the rxfifo control register (rxctl, table a.13), ? the rxfifo address register (rxaddr, table a.12), or ? the rxfifo data register (rxdata, table a.11). the rxctl register contains 6 control bits which qualify the rxfifo entry. these control bits: ? identify the entry as the beginning of a block transfer, ? indicate whether the entry is a blt or mblt cycle, ? provide the size of the cycle (longword, byte, word, or triple byte), and ? give the local function code for non-privileged or supervisory program and data space. the rxaddr register is 32 bits and gives the rxfifo output address. during mblt cycles, this register provides the top 32 bits of the 64-bit data transfer. the rxdata register is also 32 bits wide and provides the rxfifo output data. the local bus is requested by the rxfifo whenever entries appear. arbitration of the local bus follows these priorities: 1. (if scv64 is not in default fair mode), 2. the rxfifo, and 3. the dma controller. the rxfifo is given priority over the dma controller to ensure sequential consistency (the most current data is available). entries in the rxfifo are transferred to their indicated address by single local cycles or burst mode. using zero wait state memory on the local bus, the scv64 can transfer one longword every 3 clock cycles (see local bus interface on page 2-66). lbrq1
scv64 user manual data path tundra semiconductor corporation 2-41 the scv64 can be programmed to perform burst double clock write cycles. with a 33 mhz local clock, burst writes allow data transfer rates up to 62 mbytes/sec. burst writes are enabled by setting the fifoben bit in the mode register (table a.21). the blen1 and blen0 bits in the mode register set the maximum burst length (4, 8, 16, or 32 longwords). the default setting for maximum burst length is 4 longwords. if the fifoben bit is set, then the scv64 will initiate burst writes when there are 2 sequential mblt entries or 4 sequential blt entries in the rxfifo. if a sufficient number of blt or mblt entries are queued, the scv64 initiates a burst write. the burst write is terminated if the scv64: ? encounters a different entry type (e.g. a blt entry after a series of mblt entries), ? completes its maximum burst length, or ? empties the rxfifo. unlike the txfifo, which is disabled by a vmebus error, the rxfifo is not disabled if a local bus error occurs. however, the rxfifo can be disabled by setting the disrx bit in the mode register (table a.21) (by default, the rxfifo is enabled). if the rxfifo is disabled, then it can only be emptied by using the rxshft bit in the dcsr register. writing 1 to the rxshft bit discards the oldest entry and shifts the rxfifo queue forward by one step. the vmebus can still write to the rxfifo if it is disabled, but doing so will set the lberr bit in the dcsr register and cause to be asserted. if the rxfifo fills while it is disabled, then the pending vme cycles will time out. 2.6.2 scv64 as vme master 2.6.2.1 coupled mode master read cycles are always coupled, although writes may be either coupled or decoupled. coupled mode for vme master cycles is programmed by setting the txatom bit in the mode register (table a.21). if the bit is set while entries still exist in the txfifo, then the scv64 completes all pending cycles in the txfifo before entering coupled mode. clearing this bit returns the scv64 to decoupled mode (its default setting). in coupled mode, the cpu transfer is not queued by the txfifo but is directly linked to the vmebus. the cpu enters wait states until a dtack* or berr* signal is generated by the vmebus slave. the scv64 copies the cycle termination through to the local master, which then ends the master local cycle. if berr* is received during the coupled cycle, the vberr flag is set in the dcsr register (table a.6), and is asserted. vmeint vmeint
data path scv64 user manual 2-42 tundra semiconductor corporation if the scv64 initiates a coupled slave read while there are still entries in its txfifo, the cycles in the txfifo will be completed before the coupled read is allowed. similarly, the scv64 will complete all entries in its rxfifo before initiating a coupled master write cycle. in both cases the master cpu must execute wait states until the fifo is empty. completing pending cycles before allowing subsequent coupled cycles ensures sequential consistency; that is, the data being read is the most current. 2.6.2.2 decoupled mode writes from a master scv64 to a slave may be either coupled or decoupled. the scv64 is programmed for decoupled write cycles by clearing the txatom bit in the mode register (see table a.21). the scv64 defaults to decoupled mode. in decoupled mode, writes to the vmebus are loaded into the txfifo. the txfifo queues the entries and asserts and to terminate the master local cycle. in normal operation, the scv64 requests the vmebus as soon as entries appear in the txfifo. however, while the device is in dma mode, the scv64 can be programmed to request the vmebus only when the txfifo is filled. this option is programmed by setting the fill bit in the mode register (see table a.21). note that to ensure sequential consistency, read and iack cycles are blocked until all txfifo entries are processed. if the txfifo is full, the scv64 does not accept writes until an entry is unloaded to the vmebus, making space available. note that the master local bus data transfer rate is limited by the rate at which the slave bus completes its cycles. therefore, a full txfifo effectively couples the buses. if the txfifo cannot perform its writes on the vmebus, the master local bus transfer times out with a signal. the user should consider the capabilities of slave buses and alternate between cycles for slower and faster buses. each 72-bit entry in the txfifo is made up of three components - control, address, and data. the three components for the most current or last completed cycle are read from the following three registers: ? the txfifo control register (txctl, table a.19), ? the txfifo address register (txaddr, table a.18), and ? the txfifo data register (txdata, table a.17). the txctl register contains 8 control bits which qualify the txfifo entry. these control bits: ? identify the cycle as mblt or blt, ? provide information about transfer size (longword, byte, word, or triple byte), kdsack1 kdsack0 kberr
scv64 user manual data path tundra semiconductor corporation 2-43 ? identify the address space (a32, a24, a16), ? distinguish whether the cycle is supervisory or non-privileged, and ? identify the data type as program or data. the txaddr register is 32 bits and gives the txfifo output address. during mblt cycles, this register provides the top 32 lines of the 64-bit data transfer. the txdata register is also 32 bits wide and provides the txfifo output data. when a vmebus berr* signal is received by the scv64, it releases the bus, sets the vberr bit in the dcsr register (table a.6), asserts and negates brn*. while the vberr flag is set, entries may still be queued in the txfifo until it reaches a full condition. after the txfifo is full, any local cycles will time out on the local bus. the txfifo is unable to dequeue cycles to the vmebus until the vberr flag is cleared. the txctl, txaddr and txdata registers in the scv64 record the values that were present at the output stage of the txfifo when the error occurred. they may be read by the cpu to obtain the address, data and control codes in the failed write cycle. this information can be examined by software to determine the fault, or used to rerun the cycle. the failed cycle will not remain in the txfifo when the vberr bit is cleared, and must be regenerated in order for it to be retried. 2.6.2.3 dma transfers the scv64 performs all master blt and mblt cycles through the dma controller. since master dma cycles are always decoupled, the operation of the dma controller is closely associated with the rxfifo and txfifo (see dma controller on page 2-102). in either dma reads or dma writes, the dma controller always reads from one bus and writes to a fifo. the fundamental differences between a dma read and write depend upon, ? which bus (local or vme) is read from, and ? whether the dma controller writes to a rxfifo or txfifo. the various addressing and data transfer modes used in dma operations are selected using the mode register (table a.21). the required bit settings for the different modes are given in addressing and data transfer modes on page 2-104. the available address modes are a64, a32, and a24. all address modes can be combined with the two data modes, d32 and d16. however, only a64 and a32 may be combined with mblt (d64). note that for a64 transfers, the ma64bar register (table a.23) is used for the upper 32 bits of the vme a64 address. vmeint
data path scv64 user manual 2-44 tundra semiconductor corporation the scv64 provides a burst mode which optimizes dma operations involving blt or mblt cycles. for dma reads the scv64 can initiate burst write cycles from the rxfifo to local memory (see page 2-41). for dma writes, the dma controller can initiate burst read cycles from local memory to the txfifo. all burst start addresses will be longword aligned for blts and double-longword aligned for mblts. in order to keep local address registers updated, burst cycles are automatically terminated and restarted at every burst-length boundary. for example, for a programmed burst of 8 longwords starting at address 0x08, the scv64 will terminate and restart the burst at addresses 0x20. bursts may terminate on any longword aligned address for blts and any double-longword aligned address for mblts. burst read cycles are terminated if: ? the maximum burst length is reached, ? the dma transfer count is completed (see data transfer counts on page 2-107), ? local bus ownership is granted to a higher priority request, or ? the txfifo fills. if the txfifo fills, the scv64 will release the local bus before any additional cycles are initiated. during dma transfers, the local bus is automatically released when the txfifo contains 15 entries (the txfifo is 15 stages deep). during mblt cycles, the local bus is automatically released when the txfifo contains 14 entries (since each mblt cycle requires two local bus cycles).
scv64 user manual memory mapping tundra semiconductor corporation 2-45 2.7 memory mapping there are two types of memory maps involved in the vme-local bus interface. one memory map, the cpu memory map, is from the perspective of the local bus looking onto local and vme addresses. the other memory map, the vme slave image, is from the perspective of the vmebus looking into the local address space. this section describes the properties and function of these two memory maps: the cpu memory map, and the vme slave image memory map. 2.7.1 cpu memory map local devices and memory are accessed through the cpu memory map with a local address decoder and chip select signals (see figure 2.9 below for a sample cpu memory map). vme address space is also allocated a position within the cpu memory map. vme address space is defined by a local address decoder asserting the signal. if a vme space is accessed, a local address decoder asserts which signals the scv64 to initiate a vmebus cycle or queue the cycle in the txfifo. the scv64 subdivides the cpu memory map with a vme access overlay (see figure 2.10 on page 2-47). this vme access overlay is divided into 32 pages, 128 mbytes per page and defines the accesses to various vme address and data spaces. pages 0 to 30 are by default defined as a32:d32/d16/d08 (referred to as a32:d32 for the sake of brevity, see figure 2.10 on page 2-47). therefore, any vme address space accessed on these pages of the cpu memory map will be automatically accessed as a32:d32. similarly, a24 vme accesses must be made in the lower 32 mbytes of page 31 in the cpu memory map (see figure 2.10). by default, any vme address space assigned to this region of the cpu memory map will be accessed as a24. access to an address with the lower 16 mbyte portion of the a24 region results in an a24:d16 vmebus cycle. accesses to the upper 16 mbyte portion of the a24 region results in a24:d32 vmebus cycles. the a24 vme address space can be disabled by setting the a24di bit in the mode register (table a.21). alternatively, the vme a24 space can be moved to the lower 32 mbytes of page 0 in the cpu memory map. moving the a24 region to page 0 converts the default a24 region to a32:d32 vme space (see figure 2.10). a16:d16 access can be made only to vme address space located in the top 64 kbytes of the cpu memory map (see figure 2.10). any vme address space assigned to this region (using the signal) will automatically be accessed as a16:d16. the a16:d16 region can be disabled by setting the a16di bit in the mode register (table a.21). figure 2.9 shows the effect of the scv64 vme overlay on the sample cpu memory map previously shown in figure 2.9. vmeout vmeout vmeout
memory mapping scv64 user manual 2-46 tundra semiconductor corporation rom ram scv64 registers i/o vme (vmeout asserted) figure 2.9 : sample cpu memory map as determined by local address decoder 0000 0000 0001 0000 0010 0000 0011 0000 0100 0000 ffff ffff
scv64 user manual memory mapping tundra semiconductor corporation 2-47 figure 2.10 : scv64 vme access overlay for the cpu memory map page 30, a32:d32 page 29, a32:d32 page 28, a32:d32 page 27, a32:d32 page 26, a32:d32 page 25, a32:d32 page 24, a32:d32 page 23, a32:d32 page 22, a32:d32 page 21, a32:d32 page 20, a32:d32 page 19, a32:d32 page 18, a32:d32 page 17, a32:d32 page 16, a32:d32 page 15, a32:d32 page 14, a32:d32 page 13, a32:d32 page 12, a32:d32 page 11, a32:d32 page 10, a32:d32 page 9, a32:d32 page 8, a32:d32 page 7, a32:d32 page 6, a32:d32 page 5, a32:d32 page 4, a32:d32 page 3, a32:d32 page 2, a32:d32 page 1, a32:d32 page 00 page 31 page number vmebus master type local address ffff ffff f800 0000 f000 0000 e800 0000 e000 0000 d800 0000 d000 0000 c800 0000 c000 0000 b800 0000 b000 0000 a800 0000 a000 0000 9800 0000 9000 0000 8800 0000 8000 0000 7800 0000 7000 0000 6800 0000 6000 0000 5800 0000 5000 0000 4800 0000 4000 0000 3800 0000 3000 0000 2800 0000 2000 0000 1800 0000 1000 0000 0800 0000 0000 0000 a32:d32 space default a24:d32 location ffff ffff ffff 0000 fa00 0000 f900 0000 f800 0000 default a24:d16 location a16:d16 location 128 mbytes 64 kbytes 96 mbytes less 64 kbytes 16 mbytes 16 mbytes a32:d32 space possible a24:d32 location 07ff ffff 0200 0000 0100 0000 0000 0000 possible a24:d16 location 96 mbytes 16 mbytes 16 mbytes 4 gbyte addressing space
memory mapping scv64 user manual 2-48 tundra semiconductor corporation rom ram scv64 registers i/o 0000 0000 0001 0000 0010 0000 0011 0000 0100 0000 ffff ffff f800 0000 ffff ffff f800 0000 a16:d16 vme a32:d32 vme a24:d32 vme a24:d16 vme a32:d32 vme vsb access d000 0000 c000 0000 a32:d32 vme figure 2.11 : sample cpu memory map with scv64 vme and vsb space overlay
scv64 user manual memory mapping tundra semiconductor corporation 2-49 data transfers using a64 mode must be made with the dma controller. note that all dma addressing modes are entirely independent of the cpu memory map and must be determined within the mode register. a64 mode is initiated by setting the dmaa64 bit in the mode register (table a.21, see dma controller on page 2-102). data modes for dma transfer are also programmed using the mode register (see table 2.27 on page 2-105 for a full listing of address and data modes for dma). there are two special conditions under which the scv64 will not generate a vmebus cycle when is asserted. 1. if the cpu accesses vsb address space: the scv64 uses the same 32 page map described above to define vsb space in the cpu memory map. any of the 32 pages can be designated vsb space using the bussel register (table a.14), where each of the 32 bits in the bussel register corresponds to one of the 32 pages overlaying the cpu memory map. for example, setting bits 24 and 25 in the bussel register designates pages 24 and 25 (256 mbytes) of the cpus memory map as vsb space (figure 2.9 on page 2-46). if the cpu accesses vsbbus address space, the local address decoder asserts and the scv64 (after decoding the address) asserts . an external address decoder will use the signal to initiate a transfer to the vsbbus. note that no vmebus or fifo activity is caused by this access. 2. if the cpu accesses its own image in vme address space: if the cpu attempts access to its own vme address range, a local address decoder still asserts , but the scv64 decodes the address as being the boards own vme address space and asserts . is used by a local address decoder to select a set of addresses for local devices and memory accessible from the vme- bus (this set of addresses is defined as the vme slave image). note that no vme- bus or fifo activity is caused by this access. 2.7.2 vme slave memory map the address range of the local bus from the perspective of the vmebus is termed the boards vme slave image. the scv64 signal is used by the local address decoder to select a set of addresses for local devices and memory which are accessible from the vmebus. is also asserted during dma transfers when accessing the local bus, and during cpu accesses to its own vme slave image. the vme slave image memory map may be accessed as either a24 or a32 (see figure 2.12 below), but not a16. the base addresses for the a24 and a32 slave images are programmed using the vmebar register (table a.7). vmeout vmeout vsbsel vsbsel vmeout ramsel ramsel ramsel ramsel
memory mapping scv64 user manual 2-50 tundra semiconductor corporation the a32 image base address can be programmed to any 128 mbyte boundary and to any size from 4 kbytes to 128 mbytes. the a24 image base address can be programmed to any half megabyte boundary or multiple of its programmed size (512 kb, 1, 2 or 4 mbytes), whichever is larger, within the 16 mbyte a24 addressing space. for example, if the a24 slave image is 4 mbytes, then its possible base addresses are 0x00 0000, 0x40 0000, 0x80 0000, or 0xc0 0000. the upper 32 bits of the a64 base address are set using the sa64bar register (table a.22). the scv64 will set the a64bardy bit in the dcsr register (table a.6) when both the master and slave a64 base addresses have been programmed. on the local bus, the scv64 drives the low address lines relevant to the programmed size of the vme slave image to a state matching the low address bits used as the vme address. kaddr31 - kaddr27 are driven to an undefined state, while all other address lines are driven low. for example, if the slave image size is programmed for 2 mbytes, the scv64 drives kaddr20-kaddr0 to match the bits on the vmebus; kaddr26-kaddr21 will be zero, while kaddr31-kaddr27 will be undefined. with this in mind, the local address decoding logic should be designed in such a way that it ignores the upper five address lines while the scv64 is driving the local address. a common way to implement this is to qualify the local address lines into the decoder with the ramsel signal. in a64 accesses, the upper 32 bits of the a64 base address are not carried onto the local bus, and the lower 32 bits are handled like any a32 access. note that when scv64 registers are accessed from the vmebus, the scv64 treats itself as it would any other local device. the local bus is requested and data is transferred through a local cycle to the appropriate register address.
scv64 user manual memory mapping tundra semiconductor corporation 2-51 2.7.2.1 automatic base address programming a slave boot mode (autobar) is available which facilitates design when no local intelligence is available to initialize the scv64 base address. the autobar mode allows the scv64 to power up with its slave image accessible from the vmebus, facilitating the design of slave-only cards. on the rising edge of , the vme base address register (see table a.7 for a description of the base address register) is loaded with the current local bus value. setting kfc2 high and kfc0 low during a power on reset sets the enabling bits that allow slave images to be defined (see table 2.17). by use of an external address decoder, the vmebus can then access scv64 registers on power up. the autobar mode is indicated by a 1 value in the autobar bit in the misc register. 8020 0000 8002 0000 ram 8001 0000 i/o 8000 0000 control and status 8010 0000 scv64 registers registers e2 0000 e1 0000 i/o e0 0000 control and status f0 0000 scv64 registers registers a32 memory map a32 base address = 0x8000 0000 a32 size = 2 mbytes a24 memory map a24 base address = 0xe0 0000 a24 size = 1 mbyte figure 2.12 : sample vme slave memory map (accessed as a32 and a24) vme address local address vme address local address 0020 0000 0002 0000 0001 0000 0000 0000 0010 0000 0002 0000 0001 0000 0000 0000 0010 0000 programming for (table a.7) would be = 0x003c 0130 pwrrst
memory mapping scv64 user manual 2-52 tundra semiconductor corporation table 2.17 : functions for different settings of kfc2 and kfc0 note: sysrst* does not return the initial base address programmed at power- up. instead, the initial base address will remain at the address given prior to the system reset with both a24 and a32 images enabled. 2.7.2.2 access protection access protection allows the user to mask specific ranges of its vme slave image from the vme masters. the type of access protection is specified using the prot bit in the mode register (table a.21). the setting defaults to write protection; setting the bit programs read and write protection. the lower 4 bits in the apb register are used to specify the extent of slave image protection (values between 16 kbytes to the entire 128 mbytes are available), where the protected range always begins at the base address and proceeds upwards. the apb register defaults to 0 after reset (no protection). if access to a protected area is attempted from the vmebus, the scv64 generates a berr* signal. protection is not applied to accesses by the local cpu to its own slave images. if write protection has been programmed and a read-modify-write operation is attempted on the protected memory, the rmw read cycles complete successfully but the write cycles are terminated with berr*. protecting the entire 128 mbyte slave image will still leave the location monitor unprotected. the location monitor (see location monitor and lmfifo on page 2-101) resides in the upper longword (or even word of the upper longword for 16 bit accesses) of the slave image and is used in interprocess communication and for bi-mode release (see bi-mode on page 2-119). kfc2 kfc0 function 0xreserved 1 1 vinen and a24slven cleared 1 0 autobar mode: set vinen and a24slven
scv64 user manual vmebus interface tundra semiconductor corporation 2-53 2.8 vmebus interface the scv64 offers a flexible high performance master/slave vmebus interface adaptable to a variety of applications. as discussed elsewhere (see data path on page 2-36), data can be transferred using either a coupled or decoupled architecture, where decoupling the vmebus and local bus optimizes bus bandwidth usage. although the coupling or decoupling of bus cycles greatly affects data transfer rates, it has no effect on the translation of address and control information between the vmebus and local bus. however, the translation process does vary depending upon whether the transfer is a master cycle (scv64 is the vme master) or a slave cycle (scv64 is the vme slave). this section describes the translation process between vmebus cycles and local bus cycles when the scv64 is the vme master or vme slave. 2.8.1 scv64 as vme master as vme master, the scv64 generates read, write and read-modify-write cycles (but does not generate address only cycles). outgoing cycles pass through external buffers before reaching the vmebus. the scv64 controls the direction of these buffers through the following signals: ? vaddrout (for address lines a31-a00 and vlword*), ? vdataout (for data lines vdata31-vdata00), and ? vstrbout (for , , , , and vam5-vam0). the buffers are placed in transmit configuration (scv64 is driving vmebus) when these signals are driven high. by default, the scv64 sets the buffers to receive (vmebus to local bus). note that the direction of the data buffers will change depending upon whether the cycle is a read or write (transmit for a write and receive for a read, assuming the scv64 is vme master). 2.8.1.1 address translation in transfers not involving the dma controller, the scv64 uses the vme address range in the cpu memory map to determine address and data modes (see cpu memory map on page 2-45). local function codes (kfc2-kfc0) are used to specify the address space (supervisory or non-privileged, program or data). based upon the address and function codes, the scv64 will generate the appropriate address modifier code on the vmebus. the 32 address lines on the local bus are mapped directly to the 31 vme address lines. the mapping between function codes, vme address space and am codes is given in appendix-d. vas vds1 vds0 vwr
vmebus interface scv64 user manual 2-54 tundra semiconductor corporation blt and mblt master cycles must be performed using dma transfers. the address size and privilege type for dma transfers is specified in the mode register (table a.21, see addressing and data transfer modes on page 2-104). for a64 master cycles (which can only be performed with dma), the ma64bar register (table a.23) is used to program the top longword of the master a64 address. the vme specification limits blt cycles to 256 bytes and mblt cycles to transfer sizes up to 2 kbytes. for transfers larger than the specified limit, the scv64 will automatically insert a new address at transfer size boundaries. 2.8.1.2 byte lane translation the control signals on the vmebus relevant to data sizing (ds1*, ds0*, a01, lword*, and a02) indicate both data transfer size as well as the byte lanes used in the transfer. ultimately, this information specifies the address offset at which data is written to or read from. a byte(n) convention is used in the vmebus specification to indicate the position of the data in memory, where n is the address offset from a longword boundary. in the scv64 local interface, information about data transfer size and address offset is provided with 4 bits, ksize1, ksize0, kaddr00, and kaddr01. during a read cycle with the scv64 as vme master, the scv64 decodes the vmebus byte lanes and translates them to specific byte lanes on the local bus. byte translation depends upon the swap bit setting in the mode register, the transfer size and address offset. when swap is set, then the byte lanes are mapped directly from the vmebus to the local bus. if swap is cleared then byte lane translation follows the protocol specified in appendix-d. for example, a single byte transfer with no address offset on vmebus data lines vdata15-vdata08 will be translated to local bus data lines kdata31-kdata24. during a write cycle with the scv64 as vme master, there are two possible byte lane translation options depending upon the setting of the swap bit in the mode register (table a.21). when the swap bit is cleared, byte lane translation follows the protocol specified in appendix-d. when the swap bit is set, then byte lanes are directly mapped from the local to the vmebus: that is, data lines kdata31-24 are mapped to vdata31-24, kdata23-16 are mapped to vdata23-16, etc. (see appendix-d). the scv64 accepts unaligned transfers from the vmebus, but will only generate unaligned transfers if the bussiz bit in the mode register (table a.21) is set (see appendix-d). when the bussiz bit is set, the scv64 always responds to the cpu as a 32-bit port and will use all 32 vmebus data lines for unaligned transfers on the vmebus. for example, if the cpu sends the scv64 a three byte transfer with an address offset of 1, the scv64 responds as a 32-bit port and generates a uat(1-3) transfer on the vmebus (see figure 2.13). since the scv64 responds as a 32-bit port and all data is accepted from the local bus, the cpu is not required to perform dynamic bus sizing.
scv64 user manual vmebus interface tundra semiconductor corporation 2-55 if the bussiz bit is cleared, the scv64 may respond to the cpu as a 16-bit port, depending upon the vme access (see memory mapping on page 2-45). under this configuration, the cpu will need to dynamically bus size in order to complete unaligned transfers. revisiting the example above, the cpu initiates a three byte transfer with address offset of 1, but in this case the device responds as a 16-bit port. in the first cycle, the scv64 generates a single byte transfer on the vmebus (transferring the top byte of the three byte transfer) and responds to the cpu as a 16-bit port. the cpu must then send the remaining 2 bytes with an address offset of two (the original offset of 1 plus the byte already sent). the scv64 translates this second local cycle to a vmebus dbl byte(2-3) transfer (see figure 2.14). note that it is the dynamic bus sizing capacity of the cpu that allows the scv64 to accept unaligned transfers from the local bus and send aligned transfers on the vmebus. kdata31 kdata01 local bus: three byte transfer with address offset of 1 bussiz=1 vdata31 vdata01 vmebus: uat(1-3) figure 2.13 : local to vme byte lane translation with bussiz=1 123 123
vmebus interface scv64 user manual 2-56 tundra semiconductor corporation 2.8.1.3 vmebus mastership while in coupled mode, the local bus will only be released by the cpu when the vmebus is released (see figure 2.7 on page 2-37) by the scv64. in decoupled operation, the scv64 requests the vmebus as soon as entries appear in the txfifo. however, while the device is in dma mode, the scv64 can be programmed to request the vmebus only when the txfifo is filled. this option is programmed by setting the fill bit in the mode register (see table a.21). kdata31 kdata01 local bus, 1st cycle: three byte transfer with address offset of 1 bussiz=0 vdata31 vdata01 vmebus, 1st cycle: byte(1) kdata31 kdata01 local bus, 2nd cycle: double byte transfer with address offset of 2 vdata31 vdata01 vmebus, 2nd cycle: dbl byte(2-3) figure 2.14 : local to vme byte lane translation with bussiz=0 12 3 1 23 23
scv64 user manual vmebus interface tundra semiconductor corporation 2-57 ownership and release of the vmebus by the scv64 will depend upon whether the scv64 is set as ror or rwd (see vmebus requester on page 2-8). if it is set as ror, then the scv64 will only release bbsy* if another request is pending. in rwd mode, the scv64 only releases the vmebus when: ? there are no further entries in the txfifo, ? the coupled cycle is complete, or ? the iack cycle is complete. vmebus ownership can be throttled using the bus ownership timer (see ownership timer on page 2-11). the ownership timer (enable by default) can be set for 0, 2, 4, or 8s (the default setting). the scv64 will give up ownership of the vmebus within 1 or 2 cycles after the ownership timer expires (provided it is enabled). vmebus release modes can also be programmed through the norel bit in the mode register (table a.21). setting this bit causes the scv64 to not release the bus unless otherwise instructed by the arbiter (see vmebus arbiter on page 2-31). if the norel bit is cleared, the scv64 will only release the vmebus when no entries remain in the txfifo. the bus ownership timer can be used to control the duration of no release mode. caution: if the txfifo is set for no release and the ownership timer is disabled, then the scv64 will only release the bus if it receives bclr* and bclr* is enabled. the vmebus will also be released under these conditions: ? interrupt, ? bi-mode, or ? local or system reset (see other bus release mechanisms on page 2-11). 2.8.1.4 rmw cycles the vme read-modify-write cycle when scv64 is vme master can be configured in two ways. in one configuration, the assertion of on the local bus causes the scv64 to hold as* ( ) low on the vmebus. setting the tascon bit in the mode register (table a.21) programs the scv64 to hold asserted when the cpu asserts . in the other rmw configuration, the vmebus retry* line is used as a proprietary vmebus rmc signal (this is programmed by clearing the rmcpin bit in the mode register). when the cpu asserts , the scv64 asserts retry*/ . if the slave is programmed to accept retry*/ as an rmw signal, then the slave local bus and the vmebus will be locked until the rmw cycle is complete and retry*/ is released. will be asserted on the slave local bus during this cycle. ! l7imem krmc vas vas krmc krmc vrmc vrmc vrmc krmc
vmebus interface scv64 user manual 2-58 tundra semiconductor corporation as a vme bus slave, vme read-modify-write (rmw) cycles prevent re-arbitration of the scv64s local bus until as* is negated. this effectively locks the local resource until the vme bus rmw cycle is complete. note that when retry* is used as a proprietary rmw signal, the as* line is free for multiple addressing during the rmw cycle. however, if as* is used to indicate rmw, then only single address rmw cycles may be performed. 2.8.1.5 termination of a master cycle with retry* if the scv64 (as vme master) receives retry* and berr* from the vme slave during a coupled cycle, it translates the error signal to on the local bus, asserts and sets the vberr and retry bits in the dcsr register (table a.6). if the scv64 receives retry* and berr* during a decoupled cycle, then it asserts and sets the vberr and retry bits, but does not assert . the txfifo will be locked until the cpu clears the vberr bit. note that the retry* line is only an input signal. 2.8.2 scv64 as vme slave as vme slave, the scv64 receives read, write and read-modify-write cycles (but does not respond to address only cycles). incoming cycles pass through external buffers before reaching the scv64. the scv64 controls the direction of these buffers through the following signals: ? vaddrout (for address lines a31-a00) and vlword*, ? vdataout (for data lines vdata31-vdata00), and ? vstrbout (for , , , , and vam5-vam0). the buffers are placed in receive configuration (buffers are driving scv64 pins) when these signals are driven low. by default, the scv64 sets the buffers to receive. note that the direction of the data buffers will change depending upon whether the cycle is a read or write (transmit for a read and receive for a write, assuming the scv64 is vme slave). 2.8.2.1 address translation during a32 accesses, the scv64 drives the low address lines on the local bus relevant to the programmed size of the vme slave image to a state matching the low address bits used as the vme address. kaddr31-kaddr27 are driven to an undefined state, while all other address lines are driven low. for example, if the slave image size is programmed for 1 mbyte, the scv64 will drive kaddr20-kaddr0 to match the bits on the vmebus; kaddr26- kaddr21 will be zero, while kaddr31-kaddr27 will be undefined. during a24 accesses, the scv64 drives kaddr31-kaddr27 undefined, at least kaddr26- kberr vmeint vmeint kberr vas vds1 vds0 vwr
scv64 user manual vmebus interface tundra semiconductor corporation 2-59 kaddr22 low depending on the programmed a24 slave image size, and the remaining address bits straight through from the vmebus. because the top two bits of the a24 image (kaddr23 and kaddr22) are always driven low, the a32 and a24 slave images will share common local addresses in the lower 16 mbytes of the a32 image (within this range there are no bits available to distinguish between an a24 or a32 address). see vme slave memory map on page 2-49 for more information about a32 and a24 slave images. the scv64 monitors the am codes to determine the vme cycles address mode and transfer type (supervisory or non-privileged, data or program). the address size is not translated into an equivalent message on the local bus, but the scv64 does translate the transfer type into local function codes (kfc2-kfc0). a complete translation table for am codes to local function codes is provided in appendix-d. 2.8.2.2 byte lane translation the control signals on the vmebus relevant to data sizing (ds1*, ds0*, a01, lword*, and a02) indicate both data transfer size as well as the byte lanes used in the transfer. ultimately, this information specifies the address offset at which data is written to or read from. a byte(n) convention is used in the vmebus specification to indicate the position of the data in memory, where n is the address offset from a longword boundary. in the scv64 local interface, information about data transfer size and address offset is provided with 4 bits, ksiz1, ksiz0, kaddr00, and kaddr01. during a write cycle with the scv64 as vme slave, the scv64 decodes the vme byte lanes and translates them to specific byte lanes on the local bus. byte translation depends upon the transfer size and address offset. for example, a single byte transfer with no address offset on vmebus data lines vdata15-vdata08 will be translated to local bus data lines kdata31- kdata24 (see appendix-d). during a read cycle with the scv64 as vme slave, byte lane translation is from the local bus to the vmebus. the scv64 will expect the data to be presented on the appropriate local data lanes as determined by the transfer size and address offset. the setting of the swap bit does not affect the byte lane translation when the scv64 is the vme slave. see table d.8 for further information on byte lane translation when the scv64 is the vme slave. the scv64 accepts unaligned transfers from the vmebus, but will only generate unaligned transfers if the bussiz bit in the mode register (table a.21) is set (see appendix-d). when the bussiz bit is set, the scv64 always responds to the cpu as a 32-bit port and will use all 32 vmebus data lines for unaligned transfers on the vmebus. for example, if the cpu sends the scv64 a three byte transfer with an address offset of 1, the scv64 responds as a 32-bit port and generates a uat(1-3) transfer on the vmebus (see figure 2.13 on page 2-55). since the scv64 responds as a 32-bit port and all data is accepted from the local bus, the cpu is not required to perform dynamic bus sizing.
vmebus interface scv64 user manual 2-60 tundra semiconductor corporation if the bussiz bit is cleared, the scv64 may respond to the cpu as a 16-bit port, depending upon the vme access (see memory mapping on page 2-45). under this configuration, the cpu will need to dynamically bus size in order to complete unaligned transfers. revisiting the example above, the cpu initiates a three byte transfer with address offset of 1, but in this case the device responds as a 16-bit port. in the first cycle, the scv64 generates a single byte transfer on the vmebus (transferring the top byte of the three byte transfer) and responds to the cpu as a 16-bit port. the cpu must then use dynamic bus sizing to send the remaining 2 bytes with an address offset of two (the original offset of 1 plus the byte already sent). the scv64 translates this second local cycle to a vmebus dbl byte(2-3) transfer (see figure 2.14 on page 2-56). 2.8.2.3 local bus mastership when the scv64 receives and decodes an incoming vme cycle, it requests and obtains the local bus using its local bus arbitration protocol (see local bus arbitration on page 2-66). the means for obtaining the local bus does not vary with the type of incoming cycle. however, the type of incoming cycle does affect bus release. during coupled read and write cycles, the scv64 will release the bus after each single cycle. the exception to this is mblt reads or writes, where the scv64 will only release the bus after every 2 cycles (in order to transfer the necessary 64 bits of data). during decoupled cycles, the local bus is released only after the rxfifo is emptied or local bus grant is removed. in addition, burst mode can be initiated during decoupled blt and mblt cycles. if the rxfifo has 2 consecutive mblt entries, or 4 consecutive blt entries, then the scv64 will initiate a local burst write. the local burst write only stops when it: ? encounters a different entry type (e.g. a blt entry following an mblt entry), ? completes its maximum burst length (see scv64 as vme slave on page 2-39), or ? empties the rxfifo. local bus mastership is controlled differently during read-modify-write (rmw) cycles compared to normal read and write cycles. there are two types of rmw slave cycles. in one type, holding as* low locks the vmebus and local bus until as* is deasserted. is held asserted on the local bus as long as as* is held asserted, thus disabling re-arbitration of the local bus. in the other type of rmw cycle, the vmebus retry* signal is used as a proprietary vmebus rmc signal (this is programmed by setting the rmcpin bit in the mode register). if retry*/ becomes asserted in this configuration, then the scv64 asserts to indicate an rmw cycle on the local bus. under these conditions, the local bus is only released when retry*/ is deasserted. kbrq vrmc krmc vrmc
scv64 user manual vmebus interface tundra semiconductor corporation 2-61 note that when retry* is used as a proprietary rmw signal, the as* line is free for multiple addressing during the rmw cycle. however, if as* is used to indicate rmw, then only single address rmw cycles will be compliant with vme specifications. 2.8.3 dma transfers during dma transfers, the scv64 is both the vme and local master. the dma local address register (dmalar, table a.3) is used for the source address in dma writes, and the dma vme address register (dmavar, table a.4) is for the source address in dma reads (see figure 2.30). data from the source address is then transferred to the rxfifo in the case of a dma read, and to the txfifo in the case of a dma write. once the dma cycle is entered in either of the fifos, it is managed independently of other cycles queued in the same fifo. the various addressing and data transfer modes used in dma operations are selected using the mode register (table a.21). the required bit settings for the different modes are given in table 2.27 on page 105. the available address modes are a64, a32, and a24. all address modes can be combined with the two data modes, d32 and d16. however, only a64 and a32 may be combined with mblt (d64). note that for a64 transfers, the ma64bar register (table a.23) is used for the upper 32 bits of the destination address for a dma read, or the upper 32 bits of the source address for a dma write. on the local side, the scv64 can initiate burst reads and writes which will optimize data transfer during blt and mblt cycles. in a dma read, the scv64 will initiate a local burst write if the rxfifo contains 2 consecutive mblt entries or 4 consecutive blt entries. for blt or mblt writes, the dma controller will initiate local burst reads from local memory. for more information on local burst mode, see dma controller on page 2-102 and burst cycles on page 2-89. 2.8.4 master/slave deadlock resolution if the scv64 is waiting for vmebus ownership in order to perform a coupled master cycle (or a master write cycle to a full txfifo) while there is an incoming coupled slave cycle (or an incoming decoupled write cycle to a full rxfifo), then the scv64 asserts either , or and (depending upon the cycle type and the setting of the rmcretry bit in the mode register). this is intended to force the cpu to retry its master cycle and allows the incoming cycle to be completed first, thus resolving the deadlock. kberr kberr khalt
vmebus interface scv64 user manual 2-62 tundra semiconductor corporation the cycles which can result in deadlock include: ? coupled write, ? decoupled write cycle from the vmebus when the rxfifo is full, ? read or rmw, or ? iack cycles. the assertion of and in response to the master/slave deadlock is controlled by the rmcretry bit in the mode register (table a.21). by default this bit is cleared, which means that the scv64 will assert only . setting rmcretry will cause the scv64 to resolve the deadlock condition by asserting both and . 2.8.5 location monitor access the location monitor resides at the top longword (32 bits) of each a32 and a24 slave image and is accessible from both the local and vmebus (see location monitor and lmfifo on page 2-101). the bottom (even) word of the location monitor is used for 16-bit messages. since the location monitor replaces the longword of memory which otherwise exists at that address, writes to the location monitor are not turned into local cycles or entered into the rxfifo. in addition, read accesses to the location monitor result in a bus error. writes to the location monitor are queued in the lmfifo (32 bits wide and 31 stages deep) and read from the lmfifo register (table a.20). while there are entries in the lmfifo, the scv64 asserts and sets the lmhd bit in the dcsr register (table a.6). since is only asserted while there are entries in the lmfifo, an interrupt service routine or polling of the signal can be used to test for entries in the lmfifo and support various location monitor functions. note that may be tied directly to during external local iack decoding (see interrupt acknowledge cycles on page 2-22). the cpu may write to its own location monitor through its slave image as it would any address on the vmebus (i.e. asserting with the address). the scv64 address decoder responds by redirecting the message to the lmfifo. from there the message is handled in the same manner as a write from the vmebus side. if the condition occurs in which the local cpu and vmebus write to the location monitor at the same time, the race condition is resolved and the writes queued without loss of either of the messages (providing space is available in the lmfifo). one function of the location monitor is as a command to exit bi-mode. when there is a write to the location monitor, the scv64 is removed from bi-mode and the bimode signal is cleared (see bi-mode on page 2-119). kberr khalt kberr kberr khalt lmint lmint lmint lmint lirq2 vmeout
scv64 user manual vmebus interface tundra semiconductor corporation 2-63 2.8.6 bus busy glitch the vme bus busy glitch is a common characteristic of the vmebus. the acc and scv64 have bbsy glitch filters that should filter out problems by double sampling with c32mhz. to help avoid the occurrence of this type of glitch, it is recommended that the backplane be designed with at least 12 to 14 layers. backplane designs with only 2 or 3 layers are prone to have this glitch. 2.8.7 bi-mode effects while the scv64 is in bi-mode, its vmebus transceivers are pointed inwards and it ceases any master or slave activity on the vmebus. even though its slave images may have been programmed, it does not respond to any accesses and the vmebus times out if such an access is attempted. syscon functions, location monitor access, vmebus daisy chain logic and all functions related to internal card activity are not affected. the internal registers of the scv64 are fully accessible to the local cpu while in bi-mode. the local memory slave image, at the programmed base address and size, is also accessible to the local cpu. such an access does not use the vmebus or fifos unless the scv64 is in loopback mode (see test and diagnostic modes on page 2-126). address decoding for the vsb also remains active, for those pages that have been mapped over to that bus (see cpu memory map on page 2-45), though the card design may externally block such access while in bi-mode.
vmebus interface scv64 user manual 2-64 tundra semiconductor corporation 2.8.8 bus error handling a berr* encountered by the scv64, whether as a result of a coupled cycle, a decoupled write, or a dma cycle, disables the scv64s vme master interface. in each case, the scv64 asserts the pin, and sets the vberr bit. the vme master interface remains disabled until the vberr bit is cleared. while the interface is disabled, cpu initiated coupled cycles time-out on the local bus. cycles from a cpu initiated decoupled write (or a dma write) may continued to be written into the txfifo but they will not progress beyond the txfifo. once the txfifo fills, all future cycles time-out on the local bus and the dma will stop. the transmit fifo registers always contain information about the most current or recently attempted cycle including the failed cycle. the txaddr and txdata registers contain the attempted address and the data being written. the txctl register contains information on the type of cycle attempted and the information to be used to determine the cycles address modifier code (am code). table 2.18 : txctl register bits description decoupled writes which terminate with berr* on the vmebus cause to be asserted, the transmit fifo to be locked up, and the vberr bit in the dcsr register to be set. vberr will be set and will be asserted in response to berr* during a dma initiated read or write cycle as well. the cycle that failed will still be in the txfifo registers txaddr, txdata, and txctl. the local cpus interrupt service routine for the pin should examine the dcsr register to determine if the cause of the interrupt was a vmebus error. if either the dcsr registers done bit is set or the dmatc registers contents are non-zero, then the error occurred during a dma transfer. the done bit is set if the dma has just completed its transfers, although some cycles may still be queued in either fifo. bit description type if part of a cpu cycle, this bit indicates program or data transfer super this bit indicates supervisory or user privilege level spc the spc bit indicates the size of address space being accessed siz the siz bit indicates the size of data being transferred blt this bit indicates whether this is part of a blt transfer mblt this bit indicates whether this is part of an mblt transfer vmeint vmeint vmeint vmeint
scv64 user manual vmebus interface tundra semiconductor corporation 2-65 a dma read operation which terminates with berr* on the vmebus results in the scv64 halting further reads from the vmebus; however, the scv64 will transfer any cycles already queued in the receive fifo onto the local bus. failed cycles can be queued back into the fifo except for cycles that were parts of block transfers (blt and mblt). block transfers can only be queued back into the fifo as standard transfers, not as block transfers. to queue a cycle back into the fifo, recreate the cycle using the information contained in the fifo registers. it may be necessary to unlock the transmit fifo if it is full by clearing the error bits in the dcsr. the transmit fifo should then recommence the cycles that have been previously queued. if sequential consistency of write cycles is a concern, the fifo contents can be recirculated to put the failed cycle back at the fifo head.with the fifo still disabled, manually shift out the contents of the fifo using the txshft bit in the dcsr register. this bit will shift the contents of the fifo one entry at a time into the transmit fifo registers. examine the contents of these entries as they are shifted out and store them into memory. continue this process until the fifo is empty as indicated by the txhd bit in the dcsr register being cleared. no other local devices should be allowed onto the local bus during this period to perform writes to the vmebus. once the contents of the fifo have been determined and stored, unlock the fifo by clearing the relevant error bit in the dcsr register. re-queue the original write cycles, including the modified one, by duplicating them using the information gathered earlier from the fifo registers. if the failed cycle does not need to be re-attempted, the fifo may be unlocked at any time. any cycles previously queued up within it will, in their turn, be carried out on the vmebus.
local bus interface scv64 user manual 2-66 tundra semiconductor corporation 2.9 local bus interface 2.9.1 local bus arbitration the scv64 provides a local arbiter which may be bypassed if required. bypassing the local arbiter causes the scv64 to function only as a local requester. if the local arbiter is active, then three arbitration conditions arise: ? an scv64 request, ? a request from an external device using bus grant acknowledgment to maintain bus ownership, and ? a request from an external device not using bus grant acknowledgment to maintain bus ownership. the scv64 asserts to request the bus (from the cpu or external arbiter), and accepts as its bus grant signal. as the arbiter, the scv64 accepts as a bus request from an external device (e.g. a dma controller), and generates as a bus grant signal to the local requester. for internal requests (e.g. from the internal dma, or the rxfifo), the internal bus request and bus grant signals will be referred to as intreq and intgr, respectively. these internal signals cannot be monitored but are included in the following description of local arbiter operation. 2.9.1.1 local arbiter bypassed the local arbiter in the scv64 can be bypassed by holding low during a low to high transition on . bypass mode disables request level 1, making and undefined, and sets the arbbyp bit in the misc register (see table a.42). with the local arbiter bypassed, any bus requests from internal requesters (e.g. dma controller) are routed directly to kbrq . a local bus grant ( kbgr ) must be issued to the scv64 by the external arbiter when the bus is released by the previous bus master. the scv64 retains bus mastership while it holds kbrq or kas asserted (see figure 2.15). the grant ( kbgr ) should not remain asserted to the scv64 once it has negated both kbrq and kas . to force the scv64 to relinquish bus mastership, the local bus may negate kbgr at any point. the scv64 gives up the bus within one or two transfers except under the following conditions: ? during mblt slave writes or dma mblt reads when bursts are disabled (fifoben bit cleared), or ? during burst reads. kbrq kbgr lbrq1 lbgr1 kbgack pwrrst lbrq1 lbgr1
scv64 user manual local bus interface tundra semiconductor corporation 2-67 in the first instance, the scv64 gives up the local bus once the rxfifo is emptied or a block transfer boundary is reached. in the second instance, the scv64 releases the bus once the txfifo is filled. note that should be pulled to a defined logic level while the scv64 local arbiter is bypassed. transitions of should be expected but can be ignored. 2.9.1.2 local arbiter active internal requests internal requests are received by the arbiter on the intreq line and enter the local arbiter state machine (see figure 2.16) which runs off the kclk clock input. the numerical value of the different states (e.g. s0, s1, etc.) reflect the internal accounting system of the state machine and do not reflect any underlying ordering scheme. the timing for internal arbitration is shown in figure 2.17 on page 2-70. state 0 the state machine idles in s0 until a request is received on or intreq. when either of these requests are asserted, the scv64 drives low and enters s1 on the next rising clock edge. state 1 the scv64 holds low and remains in s1 for one clock cycle before entering s3. figure 2.15 : local bus arbitration with local arbiter bypass kclk kbrq kbgr kas kbgack kbgack lbrq1 kbrq kbrq
local bus interface scv64 user manual 2-68 tundra semiconductor corporation s0 C idle s1 C request s3 C resolve s2 C wait s6 C grant se C use 1 sc C using 1 s8 C end s8 C end s8 C end s5 C using 0 s7 C use 0 reset kbrq !lbrq and!intreq lbrq1 or intreq kbgack or kas or!kbgr lbgr1 kgback intgr !kbgack and lbrq1 kbgack or lbrq1 or kas !kbgack and !lbrq1 and !kas !kbgack !lbrq1 and intreq or kas intreq or kas intreq or kas !lbrq1 !intreq and !kas to s0 C idle to s0 C idle to s0 C idle figure 2.16 : local bus arbiter state machine internal requester external device - with kbgack external device - without kbgack kbrq kbrq kbrq kbrq kbrq lbgr1 kbrq intgr kgback internal request external request without kbgack with kbgack !kbgack and!kas and kbgr lbrq1 or intreq !kbgack and lbrq1
scv64 user manual local bus interface tundra semiconductor corporation 2-69 state 3 during this state, the scv64 resolves priority between and intreq. if the lbram bit in the ctl2 register is set, then will receive bus grant before the internal request. lbram defaults to fair arbitration (scv64 given fair arbitration level as external requester). the priority resolution lasts one clock cycle and the scv64 enters s2. state 2 the state machine idles in s2 until these following conditions are met: ? high, ? high, and ? asserted. these signals are sampled on the falling edge of s2. if the above conditions are met, then the state machine enters s6. state 6 if arbitration is for an external request, see external requests (with or without acknowledgment) on page 2-71, then the scv64 enters state e. if arbitration is for an internal request (i.e. for the scv64 itself), then the scv64 enters state 7. state 7 is asserted during s7, indicating that the scv64 is local master. at the end of s7, the arbiter asserts the internal bus grant signal, intgr, and enters s5. is released at the end of s7, allowing other devices the opportunity to request the bus while the scv64 is master. state 5 the state machine will idle in s5, holding low, until the internal request and are negated. when is deasserted, is released after s5. if (an external request) is asserted at any time while the scv64 is master, then will be negated and released after s5. (the state machine terminates the cycle in s8 and then returns to s0.) intgr is maintained until the scv64 removes its internal request or , or is asserted while the arbiter is in demand mode. once intgr is removed, the scv64 removes its intrq and ; is negated by the arbiter, and the arbiter moves to s8. if intrq is removed first, then intgr is removed immediately, is negated at end of s5 and arbiter goes to s8. lbrq1 lbrq1 kbgack kas kbgr kbgack kbrq kbgack kas kas kbgack lbrq1 kas kbgack kas lbrq1 kas kbgack kbgack
local bus interface scv64 user manual 2-70 tundra semiconductor corporation figure 2.17 : local arbitration for internal requester kas kbgack kclk s0 s1 s3 s2 s6 lbgr1 lbrq1 kbrq kbgr s7 s5 s5 s5 s5 ramsel local bus ? ? note: local bus signals include: kaddr, ksiz, kas, kds, kwr, and krmc
scv64 user manual local bus interface tundra semiconductor corporation 2-71 external requests (with or without acknowledgment) external bus requests are asserted on the line. when the local arbiter is active, both external and internal bus requests enter the local arbiter state machine (see figure 2.16). the numerical value of the different states (e.g. s0, s1, etc.) reflect the internal accounting system of the state machine and do not reflect any underlying ordering scheme. arbitration timing for external requests is shown in figure 2.18 and figure 2.19 on page 2-72. state 0 the state machine idles in s0 until a request is received on or intreq. when either of these requests are asserted, the scv64 asserts and enters s1 on the rising clock edge. state 1 the scv64 holds low and remains in s1 for one clock cycle before entering s3. state 3 during this state, the scv64 resolves priority between and intreq. if lbram in the ctl2 register is set, then will receive bus grant before the internal request. by default, lbram is cleared and the scv64 is given equal priority to external requesters. the priority resolution lasts one clock cycle and the scv64 enters s2. state 2 the state machine idles in s2 until these following conditions are met: ? high, ? high, and ? asserted. these signals are sampled during s2. if the above conditions are met, then the state machine enters s6. state 6 if arbitration is for an internal requester (see internal requests on page 2-67), then the scv64 enters state 7. if arbitration is for an external requester, then the scv64 enters state e. lbrq1 lbrq1 kbrq kbrq lbrq1 lbrq1 kbgack kas kbgr
local bus interface scv64 user manual 2-72 tundra semiconductor corporation state e and state c the state machine can branch from se along two directions. in one direction (with acknowledgment), the local requester asserts on the falling edge of se, the arbiter releases , and the cycle enters state c. in sc, the local requester remains bus master as long as is asserted. since has been negated, other devices can request the bus while the external device has ownership. in the other direction (without acknowledgment), the local requester does not assert . instead, the requester owns the bus as long as it asserts . since is maintained by the scv64 throughout the cycle, no other device can request the bus until the cycle is complete. under these conditions, the local arbiter state machine remains in se until is negated. kbgack kbrq kbgack kbrq kbgack lbrq1 kbrq lbrq1 figure 2.18 : local arbitration for external device - with acknowledgment kas kbgack kclk s0 s1 s3 s2 s6 se se sc sc s8 s lbgr1 lbrq1 kbrq kbgr sc figure 2.19 : local arbitration for external device - without acknowledgment kclk lbrq1 lbgr1 kbrq kbgr kbgack kas s0 s1 s3 s2 s6 se se se se se s8 s
scv64 user manual local bus interface tundra semiconductor corporation 2-73 2.9.2 local cycles C overview scv64 local cycles are synchronous, meaning that bus and control input signals are externally synchronized to the cpu clock (kclk). however, the and signals may be provided asynchronously and will be double sampled by the scv64. in the following discussion, bus cycles are divided into three phases: 1. cycle initiation, 2. data transfer, and 3. cycle termination. the signals and general operation for each of these three phases will be described in the overview below. 2.9.2.1 cycle initiation local bus cycles are initiated by driving the address, function codes, size, and read/write signals onto the bus. the function code signals (kfc0-kfc2) select the transfer type (supervisory or nonprivileged, program or data, table 2.19). the ksiz0-ksiz1 signals indicate the number of bytes to be transferred in the cycle. the write signal ( ) is negated for reads and asserted for write operations. the signal is asserted for read-modify- write cycles. these signals are all qualified with the local address strobe ( ). table 2.19 : kfc encodings for transfer type kfc2 kfc1 kfc0 transfer type 000 C 0 0 1 nonpriviledged data space 0 1 0 nonprivileged program space 011 C 100 C 1 0 1 supervisory data space 1 1 0 supervisory program space 111 C kdsackx kberr kwr krmc kas
local bus interface scv64 user manual 2-74 tundra semiconductor corporation 2.9.2.2 data transfer when the scv64 is local slave, it signals its port size to the cpu using the signals at cycle termination (see table 2.21). as discussed earlier (see cpu memory map on page 2-45), the address and data mode used during vme cycles depends upon the vme address range accessed by the cpu. the data mode for the vme cycle determines the port size that the scv64 signals to the cpu. for example, if the cpu accesses a16:d16 vme space, then the scv64 will respond to the cpu as a 16-bit port. if the bussiz bit in the mode register (table a.21) is cleared, then the scv64 will vary its apparent port size, depending upon the current cycle. note that the scv64 cannot generate unaligned vme transfers while the bussiz bit is cleared. if the bussiz bit is set, then the scv64 always responds as a 32-bit port. in addition, setting this bit also allows the scv64 to generate unaligned transfers on the vmebus (see table 2.21 for effect of bussiz on indicated port size). *longword and longword aligned accesses only. dynamic bus sizing by the cpu means that the cpu will perform more than one cycle for a specific transfer, depending upon the initial transfer size and the local slave port size. for example, a longword transfer to an 16-bit port will require more than one cycle. a cpu that bus sizes will automatically generate additional cycles when it is notified of the slaves port size. table 2.20 : transfer size encoding ksiz1 ksiz0 size 01byte 10word 1 1 3 bytes 0 0 long word table 2.21 : port size as indicated by bussiz and cycle termination data space bussiz port size d32 0* 0 0 32 bit 0 1 0 16 bit 1 0 0 32 bit d16 0 1 0 16 bit 1 0 0 32 bit kdsackx kdsack1 kdsack0
scv64 user manual local bus interface tundra semiconductor corporation 2-75 bus sizing requires that certain byte lanes on the data bus be used for ports of certain sizes. for example, an 16-bit port resides on data bus bits 31-16 (see table 2.22 for the protocol used by the scv64). however, data can be routed to different byte lanes through the use of an address offset. address offset is specified with the a00 and a01 address lines (see table 2.23). figure 2.20 below gives an example of a cpu using the scv64 signals for bus sizing. the cpu drives address, function codes and transfer size onto the bus, indicating that the transfer is longword with an address offset of 0. the cpu is accessing d16 space, so the scv64 latches only the first two bytes of the transfer and identifies itself as a 16-bit port with encoding ( = 01). the cpu must then run another cycle to transfer the remaining 2 bytes. the transfer size in this second cycle is 2 bytes and the address offset is also 2 bytes (to allow for the 2 bytes already transferred). the final two bytes are latched by the scv64 and it responds with to complete the cycle. table 2.22 : byte lanes for different port sizes on the local bus port size data lines 32 31-0 16 31-16 08 31-24 table 2.23 : encoding for address offset on the local bus a1 a0 address offset 0 0 + 0 bytes 0 1 + 1 byte 1 0 + 2 bytes 1 1 + 3 bytes kdsackx kdsackx kdsackx kdsackx
local bus interface scv64 user manual 2-76 tundra semiconductor corporation besides indicating port size, the signals are also used to generate wait states. the scv64 signals a wait state by holding and high. the exception to this is in burst cycles, where and are held high to signal a wait state. 2.9.2.3 cycle termination signals signals are used by the scv64 to asynchronously terminate local transfers and to indicate port size (see above). during a write cycle, signals also indicate that the data has been stored and the cycle can be terminated. during a read cycle, the signals tell the local master to latch the data and terminate the transfer. ksiz1 ksiz0 a1 a0 0000 01 kdsack1 kdsack0 cpu drives first cycle cpu scv64 scv64 latches d16-d31 and returns kdsackx identifying itself as a 16-bit port (assumes bussiz=0) onto the bus, longword transfer ksiz1 ksiz0 a1 a0 1010 cpu drives second cycle onto the bus, 2 byte transfer 01 kdsack1 kdsack0 scv64 latches d16-d31 and returns kdsackx to complete the transfer. figure 2.20 : example of longword transfer to a 16-bit port with no address offset with address offset of 2 bytes kdsackx kdsack1 kdsack0 kdsack1 kberr kdsackx kdsackx kdsackx
scv64 user manual local bus interface tundra semiconductor corporation 2-77 as local master, the scv64 must sample on two consecutive falling edges before terminating the cycle. after the first successful sample of (on the falling edge of s2) the scv64 enters s3 and samples again on the falling edge of s4. if is low on this second sample, then the cycle is terminated. the scv64 does not perform dynamic bus sizing and accepts any combination of as a signal to terminate the cycle. is sampled in the same manner as . however, if the berrchk bit in the mode register is set, then the scv64 will sample for up to two clock cycles after cycle termination. is also used as a termination signal (in combination with ) during master/slave deadlocks (see master/slave deadlock resolution on page 2-61). the combination of and is a signal from the scv64 indicating that the cpu retry its cycle. local interrupt acknowledge cycles can be terminated with , which signals the cpu to generate its own vector for an interrupt service routine (see interrupt handler on page 2-18). 2.9.2.4 bus error handling when the scv64 is the local master, it can encounter bus errors due to the following operations: ? coupled read or write cycles (scv64 is the vme slave) ? decoupled write cycles (scv64 is the vme slave) ? dma initiated read cycles (scv64 is the vme master) during coupled read or write cycles, the bus error is propagated back to the vme master where it should be handled normally. during decoupled write cycles (scv64 as vme slave) and dma initiated read cycles (scv64 as vme master), the scv64 is the initiator of the cycle either because of a previously enqueued write cycle or because the dma was performing local reads to fill the transmit fifo. in either case, it is not possible to propagate the error information back to the appropriate cpu. bus errors encountered during local write cycles initiated from the receive fifo do not have any external effect, the pin is not asserted and the fifo does not stop emptying its contents; however, the lberr bit in the dcsr register is set. if more information is required, local logic must latch the relevant information when a bus error occurs, and then act upon it appropriately. kdsackx kdsackx kdsackx kdsackx kdsackx kberr kdsackx kberr kberr khalt kberr khalt kavec vmeint
local bus interface scv64 user manual 2-78 tundra semiconductor corporation when the dma is the initiator of a local read cycle that fails with a bus error, the dma will continue on with its operations, assert the pin, and set the dlberr bit in the dcsr register. the failed cycle will still be enqueued in the transmit fifo. local logic must respond appropriately and if necessary, take action to recover from the error. 2.9.3 scv64 as local slave the scv64 becomes local slave if the cpu accesses ? scv64 registers (see register access on page 2-87), or ? vme address space. this section will deal only with the latter case where the cpu accesses vme space; scv64 register access is described in register access on page 2-87. as described elsewhere (see data path on page 2-36), transfers between the local bus and vmebus can be coupled or decoupled, where decoupling involves the use of a rxfifo or txfifo. however, coupling or decoupling does not alter the local bus protocol used by the scv64. from the perspective of the local bus, coupled cycles are essentially identical to decoupled cycles, except for the inclusion of several wait states while vmebus arbitration and data transfer is completed. therefore, local bus cycles with the scv64 as local slave will be described together with unique properties of particular transfers mentioned where necessary. for further information about how the following cycles are combined with vmebus transfers, see data path on page 2-36, vmebus interface on page 2-53, and dma controller on page 2-102. for information concerning byte lane translation, see byte lane translation on page 2-59. a flow chart describing a local cycle with scv64 as local slave is provided in figure 2.23 on page 2-84. when the local cpu performs a coupled access to the vmebus, the cycle must compete on the vmebus before it completes on the local bus. the cycle is not allowed to time-out (i.e., kberr asserted) on the local bus before the cycle is terminated on the vmebus. vmeint !
scv64 user manual local bus interface tundra semiconductor corporation 2-79 local cpu address device - set - drive address - drive kfc2-0, ksiz1-0 - place data on local bus - assert , kwr kas kds scv64 accept data - translate cycle - latch data in txfifo for decoupled write cycle or transfer data to vmebus for coupled write cycle - obtain vmebus and write data to vme slave for a coupled write cycle or obtain data from vme slave for read cycle - assert kdsackx terminate cycle - negate , - remove data from kdata31-0 (for write cycle) kas kds - negate kdsackx figure 2.21 : flowchart for a local cycle with scv64 as local slave - start next cycle
local bus interface scv64 user manual 2-80 tundra semiconductor corporation state 0 typically, the processor drives the address, function codes, and size information onto the local bus during s0. in addition, will be driven to indicate either a read or write. state 1 during this period, the local address decoder asserts to the scv64. together with , this signals the scv64 to initiate a vme cycle. after putting address information on the bus, the scv64 expects to be asserted indicating that the address on the bus is valid. if the transfer is a register access, the cpu must assert during this time as well. state 2 during a coupled write cycle, the data is placed on the data bus by the end of s2 and qualified with . note that the events in s0 and s1 do not have to occur in the order given. the only restriction is that the various signals be stable by the falling edge of s2. if the necessary signals are present by s2, then the scv64 recognizes the cycle. kwr vmeout kas kas kds kds
scv64 user manual local bus interface tundra semiconductor corporation 2-81 state 3 if neither of the are recognized by the beginning of s3, then the cycle enters wait states. the different cycle types will typically have wait states inserted as follows: ? indeterminate number of wait states for coupled cycles), ? 1wait states for a decoupled cycle (see figure 2.22 on page 2-82), ? 1 wait state for register, slave image, or vsb access, and ? 2 wait states for location monitor access. both signals must be negated in order for wait states to be inserted. when either is recognized, the cycle enters s3 (first sample of ). state 4 signals are sampled a second time on the falling edge of s4. the second positive sampling of indicates that the data can either be latched by local memory (for a read cycle) or that the vme slave has successfully latched the data (for a write cycle). state 5 is negated during s5. kdsackx kdsackx kdsackx kdsackx kdsackx kdsackx kas
local bus interface scv64 user manual 2-82 tundra semiconductor corporation figure 2.22 : decoupled write cycle C scv64 as local slave vmeout kaddr kfc ksize kas kds kwr kclk kdsack1 kdsack0 s0 s3 s4 s5 kdata s0 s2 s1 sw sw
scv64 user manual local bus interface tundra semiconductor corporation 2-83 2.9.4 scv64 as local master the scv64 becomes local master: ? during vme accesses to local memory (which makes the scv64 vme slave), or ? during data transfers involving the scv64 dma controller (which makes the scv64 both local master and vme master, see dma controller on page 2-102). as discussed elsewhere (data path on page 2-36), access from the vmebus may be either coupled or decoupled, where decoupling involves the use of a rxfifo or txfifo. read cycles are always coupled, but write cycles can be either coupled or decoupled. however, coupling or decoupling does not alter the local bus protocol used by the scv64. coupled and decoupled cycles are essentially identical from the perspective of the local bus. therefore, local bus cycles with the scv64 as local master will be described together with unique properties of particular transfers mentioned where necessary. for further information about how the following cycles are combined with vmebus transfers, see data path on page 2-36, vmebus interface on page 2-53, and dma controller on page 2-102. for information concerning byte lane translation, see byte lane translation on page 2-54. when the scv64 initiates a local master cycle as a result of a coupled vme cycle, the cycle must complete on the local bus before it completes on the vme bus. it is not acceptable for a coupled access to time-out on the vmebus with berr* while the cycle is still waiting to receive its termination on the local bus. a flow chart describing a local cycle with scv64 as local master is provided in figure 2.23 on page 2-84. timing for a decoupled write cycle with scv64 as local master is given in figure 2.24 on page 2-85. state 0 the scv64 drives the address, function codes, and size information onto the local bus. is asserted by the scv64 when its vme slave image is accessed (see vme slave memory map on page 2-49). is set during s0 to indicate a read or write. state 1 one half clock after putting address information on the bus, the scv64 asserts indicating that the address on the bus is valid. if the transfer is a read cycle, the scv64 asserts during this time as well. ! ramsel kwr kas kds
local bus interface scv64 user manual 2-84 tundra semiconductor corporation scv64 address device - assert - set - drive address - drive kfc2-0, ksiz1-0 - place data on local bus (for write) - assert , ramsel kwr kas kds local slave - accept data (for write) - place data on bus (for read) - assert kdsackx terminate local cycle - negate , - remove data from kdata31-0 (for write) kas kds - negate kdsackx figure 2.23 : flowchart for a local cycle with scv64 as local master - start next cycle
scv64 user manual local bus interface tundra semiconductor corporation 2-85 figure 2.24 : write cycle C scv64 as local master ramsel kaddr kfc ksize kds kwr kclk kdsack1 kdsack0 s0 s1 s2 s3 s4 s5 kdata kas
local bus interface scv64 user manual 2-86 tundra semiconductor corporation state 2 during a write cycle, the data is placed on the data bus by the end of s2 and qualified with . state 3 if neither of the are recognized by the beginning of s3, then the scv64 inserts waits states. both signals must be negated in order for wait states to be inserted. when either is recognized by the scv64, the cycle enters s3 (first sample of ). state 4 if signals are still asserted (second sample of ), then the data is latched on the falling edge of s4 for a read cycle. during a write cycle, the second positive sampling of indicates that the local slave has successfully latched the data. state 5 , and are negated during s5. address, functions code, and size information are held valid until after s5 to ensure hold time for memory systems. kds kdsackx kdsackx kdsackx kdsackx kdsackx kdsackx kdsackx kas kds kdsackx
scv64 user manual local bus interface tundra semiconductor corporation 2-87 2.9.5 register access the scv64 registers are accessed in order to: ? read status or information, or ? write to data registers or control bits. the protocol for read and write cycles to registers are as described in scv64 as local slave on page 2-78, except that the scv64 chip select ( ) is asserted instead of . in addition, the scv64 always responds as a 32-bit port during register accesses (both and are asserted). if scv64 registers are accessed from the vmebus, then the scv64 treats itself as it would any other local device by asserting and initiating a cycle on the local bus. a local address decoder asserts and directs the cycle to the scv64 registers. once the transfer has completed by the scv64 asserting both kdsack1 and kdsack0, the scv64 releases the local bus. the cycle completes normally on the local and the vmebus. the scv64 decodes access to its registers using local address lines kaddr08 to kaddr00. registers in address range 0x000 to 0x04c respond only to aligned longword transfers; the scv64 will assert with any other access. registers in address range 0x080 to 0x0bf accept any size transfer, but ignore all data lines except kdata07 to kdata00 (these are effectively one byte registers in this address range, see table 2.24 below and table 2.25 on page 88). the master a64 base address register (ma64bar) and the slave a64 base address register (sa64bar) can only be programmed from the vmebus by using a coupled cycle (see coupled mode on page 2-39). also, if the vmebus slave base address register (vmebar) is programmed from the vmebus using a decoupled cycle, the vmebus slave base address will not be updated immediately. table 2.24 : a summary of scv64 register accesses address range 32-bit access 16-bit access 8-bit access 000 to 04c yes 050 to 07f 080 to 0bf yes yes yes 0c0 to 0e0 yes 0e4 to 1ff scv64sel vmeout kdsack1 kdsack0 ramsel scv64sel kberr kberr kberr kberr kberr kberr kberr kberr kberr kberr kberr
local bus interface scv64 user manual 2-88 tundra semiconductor corporation table 2.25 : scv64 register map longword register address register name xxxx x000 dma local address dmalar xxxx x004 dma vmebus address dmavar xxxx x008 dma transfer count dmatc xxxx x00c control and status dcsr xxxx x010 vmebus slave base address vmebar xxxx x014 rxfifo data rxdata xxxx x018 rxfifo address register rxaddr xxxx x01c rxfifo control register rxctl xxxx x020 vmebus/vsb bus select bussel xxxx x024 vmebus interrupter vector ivect xxxx x028 access protect boundary apbr xxxx x02c txfifo data output latch txdata xxxx x030 txfifo address output latch txaddr xxxx x034 txfifo am code and control bit latch txctl xxxx x038 location monitor fifo read port lmfifo xxxx x03c scv64 mode control mode xxxx x040 slave a64 base address sa64bar xxxx x044 master a64 base address ma64bar xxxx x048 local address generator lag xxxx x04c dma vmebus transfer count dmavtc xxxx 050 to xxxx 07f reserved xxxx x080 status register 0 stat0 xxxx x084 status register 1 stat1 xxxx x088 general control register genctl xxxx x08c vmebus interrupter requester vint xxxx x090 vmebus requester register vreq xxxx x094 vmebus arbiter register varb xxxx x098 id register id xxxx x09c control and status register ctl2 xxxx x0a0 level 7 interrupt status register 7is xxxx x0a4 local interrupt status register lis xxxx x0a8 level 7 interrupt enable register 7ie xxxx x0ac local interrupt enable register lie xxxx x0b0 vmebus interrupt enable register vie xxxx x0b4 local interrupts 1 and 0 control register ic10
scv64 user manual local bus interface tundra semiconductor corporation 2-89 2.9.6 burst cycles the scv64 can be programmed to initiate burst cycles to increase data transfer rate on the local bus, thus increasing the efficiency of blt and mblt transfers on the vmebus. the scv64 can perform burst read cycles (data from local memory to the txfifo) during dma write operations, and burst write cycles (data from the rxfifo to local memory) during dma read operations. the scv64 also supports burst mode for slave d32blt write cycles. burst mode is not supported d08 or d16blt cycles. all burst start addresses must be longword aligned for blts and double-longword aligned for mblts. burst cycles are automatically terminated and restarted at every burst-length boundary. for example, a programmed burst of 8 longwords starting at address 0x08 terminates and restarts at address 0x20. 2.9.6.1 burst reads burst reads are enabled by setting the dmaben bit in the mode register (table a.21). the maximum length for a burst read can be 4, 8, 16 or 32 longwords, and is set using the blen1- 0 bits in the same register. if burst mode is enabled, the dma controller will initiate a burst cycle by placing address, size, and function code information on the bus, and asserting and (see figure 2.25). a function code of 3 identifies the transfer as a burst cycle. xxxx x0b8 local interrupts 3 and 2 control register ic32 xxxx x0bc local interrupts 5 and 4 control register ic54 xxxx x0c0 miscellaneous control register misc xxxx x0c4 delay line control register dlct xxxx x0c8 delay line status register 1 dlst1 xxxx x0cc delay line status register 2 dlst2 xxxx x0d0 delay line status register 3 dlst3 xxxx x0d4 mailbox register 0 mbox0 xxxx x0d8 mailbox register 1 mbox1 xxxx x0dc mailbox register 2 mbox2 xxxx x0e0 mailbox register 3 mbox3 xxxx x0e4 to xxxx x1fc reserved table 2.25 : scv64 register map (continued) longword register address register name kas kds
local bus interface scv64 user manual 2-90 tundra semiconductor corporation on the second rising clock edge, the scv64 begins to sample and , and repeats this sampling on every subsequent rising edge (see figure 2.26 on page 2-92). if is asserted on a rising clock edge, then the scv64 will latch the data on the subsequent falling clock edge. however, if and are sampled high, then the scv64 will insert wait states until one of these two signals are sampled low. one longword is transferred per clock cycle. upon assertion of kberr during a burst read, the scv64 sets the dlberr bit in the dcsr register and asserts vmeint . however, the burst does not terminate unless kberr is asserted for two falling edges of kclk. when this occurs, the burst does not immediately terminate. instead, up to four more longwords may be transferred. burst read cycles are automatically terminated by negating and at burst-length boundaries and restarting with a new address phase. burst read cycles are terminated but not restarted if: ? the dma transfer count is completed (see data transfer counts on page 2-107), ? local bus ownership is granted to a higher priority request (bus grant negated), or ? the txfifo fills. if the txfifo fills, the scv64 will release the local bus before any additional cycles are completed. during blt transfers, the local bus is automatically released when the txfifo contains 15 entries (the txfifo is 15 stages deep). during mblt cycles, the local bus is automatically released when the txfifo contains 14 entries (since each mblt cycle requires two local bus cycles). note that is negated on the first falling edge after the last sample. in some designs this may cause the slave to put data onto the bus which will be ignored by the scv64. 2.9.6.2 burst writes burst writes are enabled by setting the fifoben bit in the mode register (table a.21). the maximum length for a burst write can be 4, 8, 16 or 32 longwords, and is set using the blen1-0 bits in the same register. if fifoben is set, the scv64 will initiate a burst cycle if there are 2 sequential mblt entries or 4 sequential blt entries in the rxfifo. the scv64 begins the burst cycle by placing address, size, and function code information on the bus, and asserting and (see figure 2.27). a function code of 3 identifies the transfer as a burst cycle. kdsack1 kberr kdsack1 kdsack1 kberr kas kds kas kdsackx kas kds
scv64 user manual local bus interface tundra semiconductor corporation 2-91 scv64 address device - set to read - drive address - drive kfc=3, ksiz1-0=0 - assert - assert kwr kas kds local slave present data - assert kdsack1 accept data - latch data from kdata31-0 - place data on bus figure 2.25 : flowchart for a burst read cycle - scv64 as local master - start next cycle terminate cycle - negate , kas kds - maximum burst length reached, or - dma transfer count complete, or - negated, or - txfifo fills. kbgr - negate kdsack1 - throttle transfer with kdsack1
local bus interface scv64 user manual 2-92 tundra semiconductor corporation figure 2.26 : burst read cycle s0 s1 s2 s3 s4 s5 sw sw s6 s7 s8 s9 s10 s11 s0 s1 kaddr kfc ksize kas kdata kds kwr kclk kdsack1 ramsel 3 kdsack sampled low data latched kdsack sampled low data latched kdsack sampled low data latched kdsack sampled low data latched kdsack sampled high
scv64 user manual local bus interface tundra semiconductor corporation 2-93 is sampled on the second rising clock edge after cycle initiation to determine whether the slave device is ready to accept data. if is asserted, then data is written on the next rising clock edge. this cycle is repeated until the cycle ends or is sampled high. if and are high, then the scv64 will insert wait states and sample and on every rising clock edge. data transfer resumes when or is sampled low. assertion of kberr does not terminate the burst write, or activate any error logic. unlike burst reads, where one longword is transferred every clock cycle, burst writes allow one longword transfer every 2 clock cycles (see figure 2.28 on page 2-95). caution: except during the first two burst data beats of local bus tenure, the number of waits that may be inserted during burst writes is limited by the local bus frequency (see table 2.26 below). if not performing mblt operations, any number wait states may be inserted. during the first data beat of a burst that is not the first burst of a local tenure, the maximum number of wait states that may be inserted during the first data beat is two fewer than that shown in table 2.26. if more wait states must be inserted during the first data beat, remove the scv64 from local bus ownership at the end of each burst cycle (through negation of kbgr in arbiter bypass mode.) the grant signal (kbgr) must be negated with a setup of -2ns (ac parameter t598) to the next falling edge of kclk once kas has been negated by the scv64 (see figure b.11). this ensures that the first data beat of a burst is always the first one of a bus tenure. the burst is terminated ( and negated) if the scv64: ? encounters a different entry type (e.g. a blt entry following a series of mblt), ? is negated (in which case the burst will terminate on the next burst length boundary), ? completes its maximum burst length, or ? empties the rxfifo. table 2.26 : local bus frequency and allowable wait states during burst writes kclk frequency (mhz) maximum number of wait states 20 2 25 3 33 4 40 5 kdsack1 kdsack1 kdsack1 kdsack1 kberr kdsack1 kberr kdsack1 kberr ! kas kds kbgr
local bus interface scv64 user manual 2-94 tundra semiconductor corporation scv64 address device - set - drive address - drive kfc=3, ksiz1-0 - assert - place address on bus - assert - drive kdata kwr kas kds local slave - assert to signal readiness to accept data kdsack1 present data - write data to slave - negate kdsack1 figure 2.27 : flowchart for a burst write cycle - scv64 as local - start next cycle terminate cycle - negate , kas kds - maximum burst length reached, or - negated, or - different entry type encountered, or - rxfifo is empty kbgr - latch data - throttle transfer with kdsack1
scv64 user manual local bus interface tundra semiconductor corporation 2-95 figure 2.28 : burst write cycle kaddr kfc ksize kas kds kwr kclk s0 s1 s2 s3 s4 s5 s6 s7 sw sw s8 s9 s10 s11 s12 s13 s14 s15 s16 s17 s18 s19 kdata kdsack1 3 s0 s1 kdsack sampled low data dequeued kdsack sampled low data dequeued kdsack sampled low data dequeued kdsack sampled high ramsel
local bus interface scv64 user manual 2-96 tundra semiconductor corporation 2.9.6.3 local address incrementation during burst transfers, the scv64 presents addresses only at burst length boundaries. therefore, for some applications, a local address counter has to be provided as the scv64 does not increment the addresses during the burst. for example, if the burst length is programmed to be 4 longwords, then a 2-bit counter is required to increment address bits 2 and 3. bits 0 and 1 remain low because burst transfers must be longword-aligned. burst boundary conditions would occur at addresses 0x00, 0x10, 0x20, etc. if the programmed burst starts at address 0x04, then the scv64 would perform 3 data beats before terminating the burst at the next burst boundary condition, 0x10. provided there was still data available in the rxfifo in the case of a burst write, or room available in the txfifo in the case of a burst read, then the scv64 would begin the next burst at address 0x10. in the example above, kaddr3 and kaddr2 can be routed through some pld (see figure 2.29). between burst boundaries, the scv64 does not tristate kaddr3 and kaddr2 so these pins should not be directly connected to the local bus. the counter can be controlled by using kclk, kas, kfc2-0 and kdsack1. state machine 3 2 3 2 kaddr[31:0] klck kfc[2:0] kas kdsack1 31...4, 1, 0 local address bus figure 2.29 : local interface for maximum burst length of 4 longwords
scv64 user manual local bus interface tundra semiconductor corporation 2-97 2.9.7 read-modify-write cycles on the vmebus, as* is typically used to lock the bus during a rmw operation. setting the tascon bit in the mode register (table a.21) will program the scv64 to assert as* for multiple cycles on the vmebus while is asserted on the local bus. note that this approach allows only single address rmw cycles. as a vme bus slave, the scv64 does not allow re-arbitration of the local bus until as* is negated. this effectively locks the local resource until the vme bus rmw cycle is complete. alternatively, the vmebus retry* line can be used by the scv64 as a proprietary vmebus rmc signal (by clearing the rmcpin bit in the mode register). this is only possible if the vme slave is programmed to accept retry*/ for this function. when the scv64 receives from the local master, it asserts retry*/ , thus locking the local and vmebus during the rmw cycle. using this method, the as* line is free to qualify multiple addresses during the rmw transfer. if the vme slave is equipped with an scv64 on board, and is configured to accept retry* as a proprietary vmebus rmc line, then the assertion of retry*/ will cause to be asserted on the local bus. under these conditions, the local bus is only released when retry*/ is negated. krmc vrmc krmc vrmc vrmc krmc vrmc
local bus interface scv64 user manual 2-98 tundra semiconductor corporation 2.9.8 master/slave deadlock resolution if the scv64 is waiting for vmebus ownership in order to perform a coupled master cycle (or a master write cycle to a full txfifo) while there is an incoming coupled slave cycle (or an incoming write cycle to a full rxfifo), then the scv64 asserts either , or and . this is intended to force the cpu to retry its local master cycle and allows the incoming cycle to be completed first (or a rxfifo entry to be completed), thus resolving the deadlock. the cycles which can result in deadlock include: ? coupled write, ? decoupled write cycle from the vmebus when the rxfifo is full, ? read or rmw, or ? iack cycles. the assertion of and in response to the master/slave deadlock is controlled by the rmcretry bit in the mode register (table a.21). during deadlocked rmw cycles (i.e. with asserted), the scv64 will assert only by default. however, setting rmcretry programs the scv64 to assert both and during a master/slave deadlock. the lberr bit in dcsr register is not set during deadlocked cycles. 2.9.8.1 deadlock resolution in decoupled mode caution: there is a potential deadlock resolution problem which users should avoid. the problem occurs when the scv64 is in decoupled mode (txfifo). the scv64 card performs a vmebus write cycle that terminates in a bus error, then performs a coupled vme cycle before clearing the vberr bit in the dcsr register. if that coupled cycle encounters a deadlock condition with an incoming coupled cycle, then the scv64 will fail to issue and to resolve this. instead, both bus cycles will terminate with time-out bus errors. one way of dealing with this issue is by implementing this hardware mechanism: if kbrq from the scv64 and vmeout are both asserted for at least 1 us, then assume a deadlock condition and generate berr and halt with external logic to the local processor. kberr kberr khalt kberr khalt krmc kberr kberr khalt ! kberr khalt
scv64 user manual local bus interface tundra semiconductor corporation 2-99 2.9.9 location monitor access the location monitor resides at the top longword of each a32 and a24 slave image (see vme slave memory map on page 2-49) and is accessible from both the local and vmebus. the bottom (even) word of the location monitor is used for 16-bit messages. writes to the location monitor from the vmebus are recorded in the lmfifo, a 31 longword deep message queue. whenever an entry appears in the lmfifo, the scv64 generates a local interrupt ( ) and sets the lmhd bit in the dcsr register (table a.6). is only negated when the lmfifo is emptied. messages in the lmfifo are read from the lmfifo register (table a.6). reads from the lmfifo itself returns only undefined data. the cpu may write to its own location monitor as it would any other vme address. the scv64 address decoder responds by redirecting the message to the lmfifo. is only asserted after the write to the lmfifo is complete. from there, the message is handled in the same manner as any location monitor write from the vmebus ( asserted and lmhd bit set). note that a location monitor write involves 2 more wait states (one more clock cycle) than a register access or reflected cycle. if the condition occurs where the cpu and vmebus write to the location monitor at the same time, priorities are resolved and both writes are queued provided there is sufficient space in the lmfifo. 2.9.10 reflected cycles if the cpu accesses its own vme slave image (see vme slave memory map on page 2-49), the scv64 redirects the access onto the local bus by asserting . no vmebus cycle is initiated (although is still asserted by a local address decoder). is asserted one clock cycle after the local address strobe, and is only negated after is deasserted. the scv64 only supports reflected cycles once the vmebar register has been written to. this is independent of whether the device has powered up with autobar mode enabled. when the scv64 is in loopback mode, accesses to the slave image will result in the scv64 generating a vme cycle (see test and diagnostic modes on page 2-126). lmint lmint lmint lmint ramsel vmeout ramsel kas
local bus interface scv64 user manual 2-100 tundra semiconductor corporation 2.9.11 vsbbus access when the cpu accesses a vsb address space (see figure 2.9 in cpu memory map on page 2-45), a local address decoder asserts as it would for any vme access. however, instead of initiating a vme cycle, the scv64 decodes the access by asserting . this signal directs the cycle to an external device which handles the vsbbus/local bus interface. is deasserted only after and are negated. note that may be assigned other device or memory select functions. 2.9.12 bi-mode bi-mode completely isolates the local bus from the vmebus, except for the location monitor (see bi-mode on page 2-119 for bi-mode initiation). if the scv64 enters bi-mode while there are entries in the rxfifo, the rxfifo will still complete all pending write cycles. however, all txfifo entries will be lost. if the cpu attempts a vme access during bi-mode, the scv64 ignores the cycle and the local bus times out with . however, the scv64 registers and the boards own vme slave image are still accessible to the cpu. address decoding for vsb access will also remain active, though the board design may externally block such an access during bi-mode. vmeout vsbsel vsbsel kas vmeout vsbsel kberr
scv64 user manual location monitor and lmfifo tundra semiconductor corporation 2-101 2.10 location monitor and lmfifo the location monitor is provided to assist with inter-processor or inter-process communication. it incorporates a location monitor message fifo (lmfifo) which allows either 16 or 32-bit messages to be sent between processes. while there are entries in the lmfifo, the scv64 sets the lmhd bit in the dcsr register (table a.6) and generates an interrupt to the local cpu by asserting . the location monitor resides at the top longword (32 bits) of each a32 and a24 slave image and is accessible from both the local and vmebus. the bottom (even) word of the location monitor is used for 16-bit messages. since the location monitor replaces the longword of memory which otherwise exists at that address, writes to the location monitor are not entered into memory. in addition, read accesses to the location monitor result in a bus error. the lmfifo is a 32-bit wide and 31 longword deep message queue for incoming data. longwords from the location monitor are written to the lmfifo as space becomes available. if an even word has been written to the location monitor, then the upper 16 bits in the lmfifo entry are set to one (1). if the lmfifo is full when a location monitor write is made, the cycle receives no response. the write will be accepted any time before bus time-out (see bus timer on page 2-34) if the local cpu reads the oldest entry in the fifo thus opening a position for a new message. however, if a position does not become available before bus time-out, then the cycle ends with a bus error. a local interrupt is generated ( asserted) as long as there are entries in the lmfifo. is only negated when the lmfifo is empty at the end of the end of the lmfifo read cycle. the status of the lm fifo is indicated by the state of the lmhd bit in the dcsr register (see table a.6). the lmhd bit is set while there is data in the lmfifo. note that if the lmfifo is read while it is empty and a message arrives from the vmebus, then unstable data may be put onto the local bus. do not read the lmfifo unless the lmhd bit is set and is asserted. messages in the lmfifo are read from the lmfifo register (see table a.20). reads to the empty lmfifo return only undefined data (with ). since is only asserted while there are entries in the lmfifo, an interrupt service routine or polling of the signal can be used to test for entries in the lmfifo. the cpu may write to its own location monitor through its slave image as it would any address on the vmebus (i.e. asserting with the address). the scv64 address decoder responds by redirecting the message to the lmfifo. from there the message is handled in the same manner as a write from the vmebus side. lmint lmint lmint lmint kdsackn lmint lmint vmeout
dma controller scv64 user manual 2-102 tundra semiconductor corporation if the race condition occurs in which the local cpu and vmebus write to the location monitor at the same time, the race condition is resolved and the writes queued without loss of either of the messages (providing space is available in the lmfifo). one function of the location monitor is as a command to exit bi-mode. when there is a write to the location monitor and bi-mode initiators are absent, the scv64 is removed from bi- mode and the bimode signal is cleared (see bi-mode on page 2-119). 2.11 dma controller the scv64 performs all blt and mblt cycles through the dma controller; single cycle transfers may be accomplished with or without dma. since dma cycles are always decoupled, the operation of the dma controller is closely associated with the rxfifo and txfifo (see data path on page 2-36). in either dma reads or dma writes, the dma controller always reads from a source address and writes to a fifo (the fifo entry will contain the destination address). the fundamental differences between a dma read and write depend upon, ? which bus (local or vme) is required in order to access memory, and ? whether the dmac writes to a rxfifo or txfifo. 2.11.1 dma initialization the steps for initiating both dma reads and writes are given in figure 2.30 on page 2-103. in summary, the steps are: 1. clear the dcsr register (so that a new dma transfer may begin, see dma completion and error checking on page 2-108), 2. ensure that the scv64 is in decoupled mode, 3. set the appropriate address and data modes (see addressing and data transfer modesbelow), 4. fix the direction of transfer (dma read or write), 5. provide the requisite source and destination addresses, and 6. program the transfer count.
scv64 user manual dma controller tundra semiconductor corporation 2-103 dmatc = dmatc - 1 dmavar = dmavar + 1 dmalar = dmalar + 1 insert source address in the dmavar register, and the destination address in the dmalar register. set the direction of the dma transfer using the dmard bit in the mode register insert source address in the dmalar register, and the destination address in the d m ava r r e g i s t e r. program dma transfer count register. set dmago bit in the dcsr register program dma transfer count register. set dmago bit in the dcsr register dma controller acquires the vmebus. dma controller acquires the local bus. the dma controller obtains the source address from the dmavar register and transfers data from memory to the rxfifo. included with the data is the destination address read from the dmalar register. the dma controller obtains the source address from the dmalar register and transfers data from memory to the txfifo. included with the data is the destination address read from the dmavar register. read? (dmard bit is set). yes n o set for decoupled cycles by clearing either the rxatom or txatom bit in the mode register. set address and data modes rxfifo entries are handled in the usual manner. txfifo entries are handled in the usual manner. when dma transfer is complete, the done flag in the dscr register is set and vmeint asserted clear the dcsr register if burst mode is used with blt or mblt cycles, set the appropriate bits for burst enabling dmatc = 0? ye s no dmatc = dmatc - 1 dmalar = dmalar + 1 d m ava r = d m ava r + 1 dmatc = 0? yes no clear done bit to negate vmeint figure 2.30 : procedural steps in normal dma reads and writes.
dma controller scv64 user manual 2-104 tundra semiconductor corporation setting the decoupled mode and selecting the direction of transfer are done through the single bits given in figure 2.30 on page 2-103. however, many options exist for the addressing and data transfer modes, and address registers will be used differently depending upon the direction of transfer and the selected address mode. these various considerations are discussed below. 2.11.2 addressing and data transfer modes the source and destination addresses for a dma data transfer are obtained from two registers: the dma local address register (dmalar, table a.3), and the dma vme address register (dmavar, table a.4). dmalar is the starting local address and dmavar is the starting vme address for the dma transfer (see figure 2.30). the association of each register (dmalar or dmavar) with the source or destination address is dependant on the direction of the data transfer (dma read or dma write). the various addressing and data transfer modes used in dma operations are selected using the mode register (see table a.21). the required bit settings for the different modes are given below in table 2.27. the available address modes are a64, a32, and a24. all address modes can be combined with the two data modes, d32 and d16. however, only a64 and a32 may be combined with mblt (d64). the dpriv bit in the mode register can be used to switch between non privileged and supervisory am codes. when performing dma transfers the scv64 always uses a variant of a data access am code (i.e there is no mechanism to switch between program and data variant am codes). note that for a64 transfers, the ma64bar register (table a.23) is used for the upper 32 bits of the masters (scv64) address. the table below lists the different operational modes available for the dma controller, and the necessary programming to obtain that mode. note that some modes are mutually exclusive. for example, the blt bit cannot be set at the same time as the mblt bit when attempting to perform a mblt cycle. caution: the dma mode register bits must be programmed before any changes are made to the dmalar, dmavar, or dmatc registers. caution: the dmatc or dmavtc registers cannot be read while a dma transfer is taking place. ! !
scv64 user manual dma controller tundra semiconductor corporation 2-105 caution: if a dma blt/mblt transfer finishes at or within the last data transfer address before a block boundary condition as defined by the subsequent dma transfer, and the subsequent dma blt/mblt transfer begins at an address that is one data beat before the address boundary condition, then you must clear the dmavar register before programming the vme address for the subsequent dma cycle. for example, if a dma d16 blt transfer completed its last word transfer at address 7f6, 7f8, 7fa, or 7fc, and the next dma cycle to be performed was an mblt transfer beginning at address 7f8 (one double longword before the address boundary) then you must clear the dmavar register before beginning the programming sequence for the mblt dma transfer. when block transfers are received from the vmebus, the scv64 increments the local address for each transfer using the lag register (table a.24). each cycle within a block transfer entering the rxfifo receives a unique address from the lag register. table 2.27 : bit settings for dma transfer modes mode pertinent bits in mode register (table a.21) dmard dmaa64 dma24 mblt dmad16 blt dpriv disrx rxatom txatom dma read1xxxxxx 0 for dma read 0 for dma read 0 for dma write dma write0xxxxxx a64 x101x00 a32 x00xxxx a24 x01xxxx mblt(d64)xany address mode100x d32 xany address mode00xx d16 xany address mode01xx blt xany address mode0x1x non-privileged xxxxxx0 supervisoryxxxxxx1 !
dma controller scv64 user manual 2-106 tundra semiconductor corporation the scv64 provides a burst mode which optimizes dma operations involving blt or mblt cycles. for dma reads, the scv64 can initiate burst write cycles from the rxfifo to local memory. with a 25 mhz local clock, burst writes allow data transfer rates up to 50 mbytes/sec. burst writes are enabled by setting the fifoben bit in the mode register (table a.21). the blen1 and blen0 bits in the mode register set the maximum burst length (4, 8, 16, or 32 longwords). the default setting for maximum burst length is 4 longwords. the scv64 only performs longword bursts. if you have programmed the dma controller to perform d16 block transfers with bursts enabled, then the scv64 will initiate single word cycles on the local bus. if the fifoben bit is set, then the scv64 will initiate burst writes when there are 2 sequential mblt entries or 4 sequential blt entries in the rxfifo. the scv64 checks the blkst bit in rxctl register to test for the beginning of a block. if this bit is set, the scv64 counts the number of blt or mblt entries appearing in series. a blt or mblt entry is indicated by the blt and mblt bits in the rxctl register. if a sufficient number of blt or mblt entries are queued, the scv64 initiates a burst write. the burst write is terminated if the scv64: ? encounters a different entry type, ? is negated, ? completes its maximum burst length, or ? empties the rxfifo. for dma writes, the dma controller can initiate burst read cycles from local memory to the txfifo. burst reads are enabled by setting the dmaben bit in the mode register (table a.21). the maximum burst length (4, 8, 16, or 32 longwords) is set using the blen1-0 bits in the same register. if burst mode has been set, the dma initiates a burst read by asserting and issuing a local function code of 3. is sampled on the second rising edge of kclk after the cycle is initiated and on every subsequent rising edge. if is asserted on a rising clock edge, then data is transferred on the next falling clock edge. one longword is transferred per clock cycle. all burst start addresses must be longword aligned for blts and double-longword aligned for mblts. data enqueued into the rxfifo from an mblt transfer is dequeued on the local bus in the following order: data from the vmebus address lines (bytes 0-3) is presented first; then the data from the vmebus data lines (bytes 4-7 of the mblt transfer) is presented. in order to keep local address registers updated, burst cycles are automatically terminated and restarted at every burst-length boundary. for example, for a programmed burst of 8 longwords starting at address 0x08h, the scv64 will terminate and restart the burst at addresses 0x20h. bursts may terminate on any longword aligned address for blts and any double-longword aligned address for mblts. kbgr kas kdsack1 kdsack1
scv64 user manual dma controller tundra semiconductor corporation 2-107 burst read cycles are terminated if: ? the maximum burst length is reached, ? the dma transfer count is completed (see data transfer counts on page 2-107), or ? the txfifo fills. if the txfifo fills, the scv64 will release the local bus before any additional cycles are completed. during blt transfers, the local bus is automatically released when the txfifo contains 15 entries (the txfifo is 15 stages deep). during mblt cycles, the local bus is automatically released when the txfifo contains 14 entries (since each mblt cycle requires two local bus cycles). 2.11.3 data transfer counts the size of the data transfer is controlled by both the dmatc register (table a.5) and the dtcsiz bit in the mode register. when the dtcsiz bit is cleared (the default setting), the dmatc register will count up to 4096 longword transfers (16 kbytes). if the dtcsiz bit is set, then the dmatc register will count up to 1,048,576 longword transfers (4 mbytes). transfer count for vmebus cycles is recorded in the dmavtc register (table a.25). the difference between the value in this register and the value in the dmatc register is equal to the number of entries in the rxfifo or txfifo. note that the dma local and vmebus address registers and the transfer count register may change while being read, unless the dma is stopped before reading. 2.11.4 fill option during a dma write, the dma controller transfers data from local memory to the txfifo. past this point the dma controller is no longer involved in data transfer. the txfifo entries are handled by the vme cycle generator (see data path on page 2-36). in normal operation, the scv64 requests the vmebus as soon as entries appear in the txfifo. however, while the device is in dma mode, the scv64 can be programmed to request the vmebus only when the txfifo is filled. this option is programmed by setting the fill bit in the mode register (see table a.21). the fill mode is useful in applications involving the transfer of large batches of data.
dma controller scv64 user manual 2-108 tundra semiconductor corporation 2.11.5 no release option once the txfifo has obtained the vmebus, it can be programmed using the norel bit in the mode register (table a.21) to not release the bus unless otherwise instructed by the requester block (much like ror mode, see release on request and release when done on page 2-10). clearing the norel bit causes the scv64 to release the vmebus when there are no entries remaining in the txfifo (much like rwd). the bus ownership timer (see bus timer on page 2-34) can be used to control the duration of no release mode. caution: if the txfifo is set for no release and the requester is set for rwd (see vmebus requester on page 2-8), then the scv64 will not release the vmebus unless it times out or receives bclr*. 2.11.6 dma completion and error checking when the dma transfer is completed: ? the done flag in the dcsr register (table a.6) is set, ? the dmago bit in the dcsr register is cleared, and ? the pin is asserted. the dma can be stopped before completion of data transfer by clearing the dmago bit. under this circumstance, the done bit and the pin cannot be monitored for completion of the dma transfer. when stopped, the dma controller will complete its transfer on the source bus within one or two cycles. before reprogramming another dma transfer, ensure that the previous dma transfer completed on the local bus. the dma transfer will also stop before a complete data transfer if: ? there is a local bus error, ? there is a vmebus error, or ? the scv64 receives a late local bus error. a late local bus error is detected only if the scv64 has been programmed by setting the berrchk bit in the mode register (table a.21). setting this bit allows the scv64 to check for local bus errors one local clock cycle after completion of dma. ! vmeint vmeint
scv64 user manual dma controller tundra semiconductor corporation 2-109 the cerr bit in the csr register will be set if incompatible options are programmed in the mode register. the cerr will be set if any of the following register bits are both programmed to 1: ? dpriv and dma64, ? dmard and disrx, ? mblt and blt, ? dma64 and mblt, ? dma64 and dma24, ?dmard & rxatom, ? dmard and lpbk, or ?txatom in the event of one of the local bus errors listed above, the dmac clears the dmago bit, asserts the vmeint pin, but does not set the done flag. in the event of a vmebus error, the dmago bit may or may not be cleared. the cleared done flag indicates that a bus error has terminated data transfer. the type of bus error is indicated by the following bits in the dcsr register: ? lberr is set for a local bus error when the rxfifo has the bus, ? vberr is set for a vmebus error when the txfifo has the bus, and ? dlberr is set for a local bus error when the dma is performing local reads. the error bits indicate which registers (txfifo, rxfifo or dma) the user should read for data recovery. note that the done bit will be set after dma completion even while there are entries remaining in the fifo. therefore, a bus error can occur after dma completion but during data transfer. the user should always poll the error bits to ensure that no errors have occurred. the pin will be asserted (and the done bit set) when the transfer has completed. these completed conditions apply: ? during dma reads or dma block writes when the transfer has completed on the vmebus, and ? during single dma writes when the cycle has finished on the local bus. vmeint
resets, clocks and timers scv64 user manual 2-110 tundra semiconductor corporation 2.12 resets, clocks and timers 2.12.1 resets 2.12.1.1 local reset the scv64 asserts local reset ( ) under any one of the following conditions: ? power-up reset ( ), ? external reset ( ), ? vmebus system reset (sysrst*), ? software reset using the swrst bit in the genctl register (see table a.28). ? bg0in* asserted while the scv64 is syscon. all circuitry in the scv64 is held reset while is asserted. when this signal is released, the scv64 keeps asserted a further 0.25 seconds. caution: the scv64s kclk input must be clocked in order for lrst to negate . the pin is intended to be driven by any on-board logic that needs to initiate a local reset. the signal is asserted immediately and kept asserted for another 0.25 seconds after is negated. local reset is also asserted for the duration of any vmebus sysrst* assertion. since the vmebus specification ensures that sysrst* be driven for at least 200 ms, the scv64 does not extend assertion as it does in the reset conditions described above. software reset is controlled through the swrst bit in the genctl register (table a.28). the reset circuitry captures the high value of swrst and asserts and sysrst* for 0.25 seconds. local reset only deasserts after sysrst* has been deasserted, since sysrst* directly asserts . sysrst* is an open collector bused line on the backplane, so does not actually negate until the last board in the system releases sysrst*. lrst pwrrst extrst pwrrst lrst ! extrst lrst extrst lrst lrst lrst lrst
scv64 user manual resets, clocks and timers tundra semiconductor corporation 2-111 2.12.1.2 system reset the scv64 asserts system reset (sysrst*) under any one of the following conditions: ? power-up reset pin () is asserted, ? the vmebus bg0in* pin is asserted while the scv64 is syscon, ? software reset using the swrst bit in the genctl register (table a.28). as with local reset, power-up causes sysrst* to be asserted for 0.25 seconds. since the bgnin* lines are not driven by the arbiter when the scv64 is in slot 1 (i.e. syscon), the bgnin* pin functions may be redefined. in the scv64, the bg0in* pin is used for off- board reset inputs (see external inputs on page 2-34). noise sensitivity is reduced with a digital pulse filter, which must record four successive low samples on bg0in* before sysrst* is asserted. therefore, there will be a 43 to 57 ms latency between bg0in* assertion and system reset. the same control bit, swrst, in the genctl register (table a.28) that initiates a local reset also causes sysrst* to be asserted for 0.25 seconds. 2.12.1.3 power-up reset the input is passed through a schmitt trigger input circuit so that noise expected from rc timing circuits is rejected. the pin directly resets all circuits in the scv64, and should be held low for a minimum of 100 ns after power becomes stable. reset through the pin sets the pwrup bit in the stat1 register (table a.27), thus indicating to the user that the last reset was due to power-up. this bit is cleared under all other reset conditions. figure 2.31 depicts a typical power-up reset circuit. pwrrst pwrrst pwrrst pwrrst
resets, clocks and timers scv64 user manual 2-112 tundra semiconductor corporation 2.12.1.4 reset effects on scv64 internal resources most modules in the scv64 are affected by or sysrst*, but not both. the effect of , sysrst* , and on the pertinent functional blocks is described below. a summary of the and sysrst* initiators is also given. ? (input pin) resets every circuit in the scv64. causes sysfail* and sysfled to be asserted. these signals can be negated by clearing the sysfail bit in the misc_ctl register. ? (by , , sysrst*, or software) resets: all control registers the local bus requester local bus timer tick timer the interrupt handler, and the vmebus interrupt generator does not affect any clocks or vmebus services 100 k w 10 k w vdd 33 m f + - pwrrst to scv64 figure 2.31 : sample power-up reset circuit lrst pwrrst lrst lrst pwrrst lrst pwrrst extrst
scv64 user manual resets, clocks and timers tundra semiconductor corporation 2-113 does not affect the watchdog timer, unless the initiator is places the board in bi-mode. causes sysfail* and sysfled to be asserted. these signals can be negated by clearing the sysfail bit in the misc_ctl register. ? sysrst* (by , bg0in*, software or another board) resets the following vmebus related modules: arbiter requester iack daisy chain driver resets all modules specified under , because it is also an initiator. places the board in bi-mode. causes sysfail* and sysfled to be asserted. these signals can be negated by clearing the sysfail bit in the misc_ctl register. clocks and the watchdog timer remain unaffected 2.12.2 clocks 2.12.2.1 clocks required the scv64 operation requires two clocks: ? a constant 32 mhz input to generate clocks of specified frequency, and ? a cpu clock for sections that must be synchronous to the cpu. the 32 mhz input: ? generates all timers, ? synchronizes sampling of several local and vme signals, ? synchronizes operation of internal state machines, and ? is used for auto-calibration of internal delay lines. the sysclk frequency is defined as 16 mhz, although the scv64 does not depend on this value. some logic in the register local bus interface depends on timing between cpu signals and kclk. these timing requirements usually necessitate a direct connection between the cpu and the scv64 kclk pin (with its related signal pins and ) without intervening buffers or signal skew. pwrrst pwrrst lrst lrst kas kds
resets, clocks and timers scv64 user manual 2-114 tundra semiconductor corporation 2.12.2.2 clocks generated the clocks generated by the scv64 are: ? vmebus system clock sysclk ? master baud rate clock baudclk ? 14 s clock c14us ? 8 mhz clock c8mhz ? three timers local bus timer no direct pin tick timer watchdog timer the clocks are described as follows: sysclk a 16 mhz, 50% duty cycle signal generated while the scv64 is the syscon. the clock stops only while is asserted, and is driven only when the scv64 is the syscon. baudclk a 2.4615 mhz (32 mhz divided by 13) clock, with a 6/13 duty cycle, provided for use by a baud rate generator, which must divide it down to standard baud rates. the clock stops only while is asserted. c14us a 14 s clock (32 mhz 448), 50% duty cycle (approximately) with 1 clock sampling jitter, synchronized by kclk to the local cpu. the relationship between kclk and c14us is shown in the timing specifications in appendix b. this clock is typically used by dynamic memory refresh control circuits. the clock runs as long as is not asserted and kclk is running. c8mhz general purpose 8 mhz clock output. tick wdog pwrrst pwrrst pwrrst
scv64 user manual resets, clocks and timers tundra semiconductor corporation 2-115 2.12.3 timers 2.12.3.1 local bus timer the local bus timer defaults to enabled after reset and begins counting as soon as the local data strobe, , is asserted. if is still asserted after 512 s, the scv64 asserts (vmeint is not asserted). the signal remains low until is deasserted, then goes high until the falling edge of the next kclk pulse, when it is tristated. the assertion of is not synchronized to kclk. the local bus timer does not use either of the local data strobe acknowledgment signals ( or ). therefore, if some device asserts one of these signals when the timer is about to generate , both of the signals will be ignored and may be asserted to the cpu. this occurrence may create an illegal timing condition if the local bus master is not a 680x0 cpu. the local bus timer is disabled by the ltoen bit in the genctl register (table a.28). the timer should only be disabled in a system development environment, but not in any application. if a vmebus lockout occurs when the timer is disabled, the local cpu hangs and the board stops accepting accesses from the vmebus. 2.12.3.2 tick timer the tick timer is used to schedule interrupts or other functions. the pin is driven low each time the timer expires, and stays low until software resets it through the clrtik bit in the stat0 register (table a.26). clearing the clrtik bit only resets the tick pins output back to the inactive state and does not internally reset the timer. to use the tick signal, connect it externally to the destination device, usually a general purpose local interrupt. tick timer output can only be read if the pin is connected to one of the interrupts. the tick timer mode (normal or fast) is set using the tickm bit in the ctl2 register (table a.33). kds kds kberr kberr kds kberr kdsack0 kdsack1 kberr tick
resets, clocks and timers scv64 user manual 2-116 tundra semiconductor corporation within normal and fast mode, various tick intervals can be selected using the tlen1 and tlen0 bits in the genctl register. in normal mode, the tick interval can be set to one of 5, 10, 50, or 100 ms (the default setting). the fast mode, with settings of 0.2, 0.4, 2, and 4 ms, offers tick intervals 25 times briefer than the normal mode. 2.12.3.3 watchdog timer the watchdog timer is another general purpose timer supplied by the scv64. in the absence of any power resets, the watchdog timer will continuously count a two second interval, assert the pin for 200 ms, and reset its counter. the watchdog timer is only affected by three sources: the pin, the endog bit in the misc register (table a.42) and the clrdog bit in the stat0 register. when the pin is asserted, counter reset is held. neither local reset nor system reset have this effect, so the watchdog timer may time-out after these resets. the significance of a watchdog time-out will depend on the user-defined application for the timer. writing to the clrdog bit will clear and restart the counter. if the clrdog bit is already 1 and the cpu writes another 1, the watchdog counter is not affected. this edge sensitivity helps protect against software failure while clearing the watchdog. 2.12.3.4 vmebus timers the scv64 provides a vmebus ownership timer (see ownership timer on page 2-11) a vmebus data transfer time-out (see bus timer on page 2-34) and a vmebus arbitration timer (see arbitration time-out on page 2-33). table 2.28 : setting the tick timer interval interval setting for tlen 1,0 normal mode fast mode 5 ms 0.2 ms 00 10 ms 0.4 ms 01 50 ms 2 ms 10 100 ms 4 ms 11 wdog pwrrst pwrrst
scv64 user manual power-up modes tundra semiconductor corporation 2-117 2.13 power-up modes 2.13.1 local iack cycle decoding the function of the / pin is determined by the state of the kfc1 pin immediately following a power reset condition (a low to high transition on ). if kfc1 is sampled high, the / pin implements the function; if kfc1 is sampled low, the / pin implements the function. in mode, the scv64 accepts iack decoding from an external device (see interrupt acknowledge cycles on page 2-22), and the internal resources dedicated to the interrupt are assigned to the location monitor interrupt ( ). in mode, local interrupt acknowledge cycles are decoded directly from the 68030/020 bus and is generated internally. the / mode is indicated after reset by the extkiack bit in the misc register (table a.42). lirq2 kiack pwrrst lirq2 kiack kiack lirq2 kiack lirq2 kiack lirq2 lmint lirq2 kiack kiack lirq2 lmint lmint kiack lirq2 / kiack lirq2 lmint lmint kiack lirq2 / internal decode figure 2.32 : connections with different local iack decoding external iack decoding internal iack decoding lirq2 kiack
power-up modes scv64 user manual 2-118 tundra semiconductor corporation 2.13.2 auto syscon select the scv64 will become the vmebus system controller if bgin3* is low upon a low to high transition on or (see syscon determination on page 2-30). 2.13.3 local arbiter bypass the local arbiter in the scv64 may be bypassed by holding low during a low to high transition on power reset. this causes request level 1 to the scv64 arbiter to be disabled, and decreases the arbitration delay for scv64 requests to the local bus. is ignored and is undefined in this mode. any scv64 request is mapped directly to and grants from the external arbiter come via . 2.13.4 automatic base address programming a slave boot mode (autobar) is available which facilitates design when no local intelligence is available to initialize the scv64 base address. the autobar mode allows the scv64 to power up with its slave image accessible from the vmebus, facilitating the design of slave-only cards (see automatic base address programming on page 2-51). if kfc2 is held high and kfc0 is held low during power reset, then the scv64 will automatically load and enable its base address. the automatic base addressing function can be verified by reading the autobar bit in the misc register (table a.42). note that if the function codes are not set as described above, then the base address will still be loaded but not enabled. note: sysrst* does not return the initial base address programmed at power- up. instead, the initial base address will remain at the address given prior to the system reset with both a24 and a32 images enabled. pwrrst sysrst kbgack lbrq1 lbgr1 kbrq kbgr
scv64 user manual bi-mode tundra semiconductor corporation 2-119 2.14 bi-mode bus isolation mode (bi-mode) disables communication between the local bus and the vmebus. daisy chain and syscon functions remain operative, but the board ceases all master and slave activity on the vmebus until bi-mode is released. by isolating boards from the vmebus, the user can implement: ? hot-standby systems ? system diagnostics for routine maintenance, or ? fault isolation in the event of a card failure. bi-mode is initiated (the bimode output pin becomes asserted) under any of these conditions: ? during resets ( , , or sysrst*), ? when irq1 * is asserted (using abi bit in the genctl register, table a.28) and configured as a bi-mode initiator, ? when the sbi bit in the genctl register (table a.28) is set, or ? after asserting . while in bi-mode, all transceivers point inwards and all accesses to the boards vme slave image will time out on the vmebus (dtack* is disabled). similarly, if the local cpu attempts to access the vmebus during bi-mode, the local cycle will time out. however, the scv64 vme slave image and its internal registers are still fully accessible to the cpu. address decoding for vsb accesses will also remain active. the board will remain in bi-mode while any of the initiating conditions listed above are present. once initiating conditions are cleared, bimode is released by either writing to the location monitor or asserting . by tying low, the scv64 can be configured to automatically come out of bi-mode when initiating signals are removed. note that bi-mode signals have higher priority than bi-mode release signals. therefore, the scv64 will not come out of bi-mode unless all initiating signals are absent. extrst pwrrst bitrig birel birel
bi-mode scv64 user manual 2-120 tundra semiconductor corporation table 2.29 : vmebus signal behavior in bi-mode vmebus signal name normal behaviour bi-mode behaviour a31 C a01 bi-directional address lines ignored acfail* input signal for power failure unaffected am0 C am5 bi-directional address modifier input only as* bi-directional address strobe input only bbsy* bi-directional requester signal tristate berr* input signal for vmebus error disabled br0* C br3* bi-directional bus request disabled d31 C d00 bi-directional data lines input only ds1*, ds0* bi-directional data strobes input only dtack* bi-directional acknowledge disabled iack* interrupt handler output and decode input input only iackin* input for iack daisy chain unaffected iackout* output for iack daisy chain unaffected irq7* C irq2* bi-directional interrupt request lines disabled irq1* bi-directional interrupt input only lword* bidirectional signal to indicate transfer size input only serclk, serdat not used unaffected sysclk bidirectional signal for system clock unaffected sysfail* bi-directional signal for system failure unaffected sysreset* bi-directional signal for system reset unaffected write* bi-directional write signal input only
scv64 user manual auto-id tundra semiconductor corporation 2-121 2.15 auto-id the auto-id function identifies the relative position of each board in the system, without using jumpers or on-board information. the id number generated by auto-id can then be used to determine the boards base address. bypassing the use of jumpers through auto-id: ? increases the speed of system level repairs in the field, ? reduces the possibility of incorrect configurations, and ? reduces the number of unique spare cards that must be stocked. in addition, if the system includes a vsb bus (which means no user defined pins are available), then the auto-id system provided by the scv64 becomes even more useful. 2.15.1 the auto-id cycle after any system reset (assertion of sysrst*), the auto-id logic responds to the first level one iack cycle on the vmebus. the level one iack* signal can either be generated normally in response to an irq1* signal or it can be synthesized without the use of irq1*. if the irq1* signal is asserted to run the auto-id cycle, care must be taken to ensure that the asserting module is physically last in the iack daisy chain. if the asserting module is in any other position, then the auto-id cycle will be halted at that location when the iack cycle is accepted (see iack daisy chain driver on page 2-31). alternatively, a member of the 680x0 cpu family can synthesize a level one iack without asserting irq1* by running the following instructions: move.l #?,d? movec. l d?,sfc moves.b $xxxx xxx2,d? since the synthesized level one iack* entails no interrupt source requiring acknowledgment, the auto-id cycle will run through all modules in the system until the cycle terminates in berr*.
auto-id scv64 user manual 2-122 tundra semiconductor corporation after the level one iack* signal has been asserted (either through irq1* or with a synthesized version), the scv64 in slot 1 counts five clocks from the start of the cycle and then asserts iackout* to the second board in the system (see figure 2.33). all other boards continue counting until they receive iackin*, then count four more clocks and assert iackout* to the next board. finally, the last board asserts iackout* and the bus pauses until the data transfer time-out circuit ends the bus cycle by asserting berr*. because all boards are four clocks wide, the value in the clock counter is divided by four to identify the slot in which the board is installed; any remainder is discarded. note that since the start of the iack cycle is not synchronized to sysclk, a one count variation from the theoretical value of the board can occur. however, in all cases the id value of a board is greater than that of a board in a lower slot number. when the auto-id cycle is completed, the idgot bit in the stat1 register (see table a.27) is set, and the id count is written to the id register (see table a.32). the value in the id register is unique for each scv64 equipped board. note that synchronization errors and variations in iackin* and iackout* delay may cause the id value to vary between auto- id cycles. if all boards contain scv64 auto-id circuits, the board position can be directly identified from the id register. after the id value has been determined and placed in the id register, each board can either identify itself to a master cpu board which has access to system configuration information, or calculate its own base address using information in local eprom. figure 2.33 : timing for auto-id cycle sysclk as* ds0 t iack t iackout t (card 1) iackout t (card 2) iackout t (card 3) id counter value d c b a 00123456789101112131415 id = 5 id = 9 id = 13
scv64 user manual auto-id tundra semiconductor corporation 2-123 if the boards identify themselves to some master cpu, then this master board must provide an empty table with a capacity for 256 entries. the software then: 1. verifies that the proper boards are present, 2. enters the base addresses and other configuration information into the table, and 3. signals the other boards that the table is ready to be used. the auto-id function is compatible with any vmebus board with iackin* to iackout* delay less than 750 ns. any delay greater than 750 ns may cause the cycle to be terminated with a berr*. boards without auto-id can be interspersed in the vmebus system with boards having auto- id. such a mixed system results in id numbers that do not numerically correspond to slot numbers, but which can still be used to determine auto-id locations. caution: if a read of the id register is the first cycle which occurs on the scv64s local bus after the auto-id cycle completes, then an incorrect value will be returned. the user must ensure that a register access (read or write, from either interface) is made to any of the other scv64 registers before this register is accessed. 2.15.2 auto-id self test the auto-id logic is tested using the idtst bit in the genctl register (see table a.28). auto-id control logic is functioning correctly if writing 1 to the idtst bit increments the id value in the id register. the idtst bit defaults to zero after reset. !
internal delay line calibration scv64 user manual 2-124 tundra semiconductor corporation 2.16 internal delay line calibration the scv64 contains five individual digital delay lines providing delay values of 20, 30 and 40 ns. each delay line is a series of logic elements, with access points or taps between each element. the delay lines are calibrated to automatically compensate for internal gate delay variations due to changes in the scv64 supply voltage, operating temperature and semiconductor processing. voltage and temperature change compensation is achieved using control circuits internal to the scv64, while software control (see appendix-f) is used to compensate for semiconductor processing. the following is a brief description of delay line function, but an understanding of their operation is not required by the user. appendix-f provides all the necessary information required to implement delay function. the calibration unit, seen in figure 2.3, uses the 32 mhz reference clock to produce a digital value for the 20, 30 and 40 ns delays. the calibration targets indicate the appropriate tap select for the digital delay lines. the cal_xx fields of the dlst1 register give the values of these calibration unit targets. each of the five delay lines is loaded with its target upon the negation of . subsequent changes to the calibration targets are then tracked by the individual delay lines. this is autocalibrate mode, and is the default. caution: all voltage, temperature and process compensation is lost if the offset fields are modified without factory instruction (see appendix-f). lrst !
scv64 user manual internal delay line calibration tundra semiconductor corporation 2-125 + offset_20 offset_30 offset_40 cal_20 cal_30 cal_40 mux mux tracking tracking tracking mux tracking tracking + + mux mux sel_40 sel_30 sel_20 delay line delay line delay line delay line delay line act_40_3 act_40_2 act_40_1 act_30 act_20 cflg_40_3 cflg_40_2 cflg_40_1 cflg_30 cflg_20 32 mhz clock figure 2.34 : functional block diagram for delay lines calibration unit
test and diagnostic modes scv64 user manual 2-126 tundra semiconductor corporation 2.17 test and diagnostic modes 2.17.1 decoupled write diagnostics txfifo data, address and control signals for a current write cycle may be read from the txdata, txaddr, and txctl registers, respectively. note that although these registers can be used to recover a current write cycle terminated by a vmebus error, they do not show the subsequent cycle at the output stage of the txfifo. however, the subsequent cycle in the txfifo can be moved to the registers described above using the txshft bit in the dcsr register (table a.6). the failed cycle read back from the rxfifo registers may be retried by the cpu, but the retry will occur only after other writes queued ahead in the txfifo are completed. note that the cycle is not automatically retried by the scv64 when the vberr flag is cleared; instead, the scv64 proceeds with the next cycle in the txfifo. 2.17.2 loopback diagnostics 2.17.2.1 loopback mode by placing the scv64 in loopback mode, any write cycle by the local cpu to its own vme slave image does not go directly to memory (see reflected cycles on page 2-99) but is instead sent out to the vmebus and from there into the scv64 rxfifo. once the cycle loops back into the rxfifo, dtack* on the vmebus is both asserted and received by the scv64 to end the cycle. note that vmebus address and data transceivers drive the cycle onto the vmebus, but the scv64 loads the cycle into its rxfifo from its own output pins, so the loopback mode does not test the external vmebus buffers. read cycles are not looped back, because the scv64 needs local bus mastership to complete the read and the cpu is the current owner. read cycles are always directed into memory with the pin in the same manner as a reflected cycle. loopback mode can be used to test: ? the base address and size of the slave image (see vme slave memory map on page 2-49), ? the access protection (access protection on page 2-52), and ? the integrity of the rxfifo and txfifo. ramsel
scv64 user manual test and diagnostic modes tundra semiconductor corporation 2-127 address and data faults either on the vmebus or in the vmebus transceivers cannot be detected, since address and data signals are received by the scv64 from its own output pins. the base and size of the slave image can be tested in two ways. the local slave image detector can be verified while still in bi-mode. without using loopback, reads or writes to memory are completed just as to the direct image. the second slave image detector exists on the vmebus side and loopback mode or interactive testing using another vmebus master can be used to verify that circuit. access protection can be verified as follows: 1. write to the slave image with no protection, 2. allow time for the write to occur, and then verify that the write succeeded, 3. enable protection, and check that the vberr bit in the dcsr register is set when the write is repeated. integrity of the rxfifo can be checked by disabling the rxfifo and then shifting and unloading each cycle in the queue. as each cycle is shifted to the end of the rxfifo, it can be read from the rxdata, rxaddr, rxctl registers. note that this shift and read process can be done only when no other card is accessing the scv64. the rxfifo is disabled by setting the disrx bit in the mode register; setting the rxshft bit in the dcsr register shifts the rxfifo ahead by one entry. the scv64 clears rxshft after completing the shift. loopback mode is initiated by setting the lpbk bit in the mode register. lpbk can be set or cleared at any time, since it only affects the path of cpu cycles to its own slave image (therefore, an access will not be in progress during programming). however, loopback mode only operates when the scv64 is set to decoupled mode, and cannot be used in bi-mode. note that data coherency is no longer assured during loopback mode. for example, the cpu can dispatch a decoupled write to its own memory through the scv64, and then immediately begin a read to the same address on the local bus. the local read cycle would likely start before the write cycle is propagated through the vmebus and back through the rxfifo. therefore, the local read would not return the most current data.
test and diagnostic modes scv64 user manual 2-128 tundra semiconductor corporation 2.17.2.2 dma loopback the scv64 can be programmed to perform a dma loopback which is an effective way to test the functionality of the chip. during a dma write, it is possible to program the vme address to correspond to the programmed slave image. the scv64 reads the data from the local bus and writes it to the txfifo, which then completes the cycle on the vmebus to its own slave image by latching the data into the rxfifo and asserting dtack*. the scv64 will then take local bus control away from the dma controller, and write the data back to local memory. dma read loopbacks are similar to the dma write loopbacks. the dma controller reads from the vmebus and the cycle is reflected back to the local side to read from local memory. the data is read from local memory and passed back through the scv64s coupled path to the vmebus. dtack is asserted and received by the scv64 and the data is queued into the rxfifo. when the rxfifo gains control of the local bus, the scv64 writes the data back to the local bus. although this technique can be used to dma data between local resources, it is slow and involves tying up the vme. 2.17.2.3 interrupt loopback the scv64 can perform an interrupt loopback by asserting a vme interrupt using the vint register. if that interrupt is enabled, it causes an interrupt to be asserted on the kipl lines. a local iack cycle is performed which causes the scv64 to perform a vmebus iack cycle. the scv64 supplies its own vector from the vmebus interrupter vector register (ivect) and asserts dtack* and the vmebus iack cycle completes. the vector is then passed back to the local bus and the local bus iack cycle is terminated by the scv64 asserting . 2.17.2.4 jtag support the scv64 provides the following jtag (ieee p1149.1) pins: ?jtms, ? jtclk, ?jtdi, ? and jtdo. the scv64 presently has no internal jtag controller. jtms and jtclk may be connected to ground or to the corresponding board level signals. jtdi and jtdo are internally connected, allowing subsequent implementation of a complete jtag board level test. kdsackn
vmebus interface componentsscv64 user manual tundra semiconductor corporation 3-1 3 description of scv64 signals the following detailed description of the scv64 signals is organized according to these functional groups: ? vmebus signals ? local signals 3.1 vmebus signals bbsy * active low open drain high current bidirect vmebus bus busy C signal driven by the scv64 while it owns the bus. bclr * active low tristate high current bidirect vmebus bus clear C requests that the current owner release the bus. the scv64 requester circuit can be configured to use or ignore this line. if the scv64 is the syscon, the arbiter circuit asserts this line when higher priority requests are pending. berr* active low open drain high current bidirect vmebus bus error C a low level signal indicates that the addressed slave has not responded, or is signalling an error. bg3in*-bg0in* active low inputs vmebus bus grant inputs C the vme arbiter awards use of the data transfer bus by driving these bus grant lines low. the signal propagates down the bus grant daisy chain and is either: ? accepted by a requester if it requesting at the appropriate level, or ? passed on as a bgnout* to the next board in the bus grant daisy chain. if the scv64 is the syscon, then the bg0in* signal can be used to trigger system reset (see off-board reset input on page 2-35).
description of signals scv64 user manual 3-2 tundra semiconductor corporation bg3out *- bg0out* active low outputs vmebus bus grant outputs C only one output is asserted at any time, according to the level at which the vmebus is being granted. three lines are propagated to bgnout* while the fourth bgnin* may be terminated on the scv64, if the scv64 is requesting the bus at this level. if the scv64 is configured as the vmebus syscon (i.e. the card is in slot 1), then a low level on bg0in* causes the scv64 to generate local and system reset. bg3in* is used for determination. if bg3in* is sampled low after , then the scv64 is enabled as the vmebus syscon if the scv64 is enabled as the syscon, then bg2in* and bg1in* can be read by software. therefore, it is recommended that 10k? external pull-down resistors be used on bg2in* and bg1in* if the scv64 is syscon. br 3C0 * active low open drain high current bidirects vmebus bus request lines C these signals are asserted by the scv64 requester when requesting use of the data transfer bus. the level of the request is programmed using the lvl1 and lvl0 bits in the vreq register. if the scv64 is the syscon, the arbiter logic monitors these signals and generates the appropriate bus grant signals. dtack * active low open drain high current bidirect vmebus data transfer acknowledge C dtack* driven low indicates that the addressed slave has responded to the transfer. iack * tristate high current bidirect vmebus interrupt acknowledge indicates that the cycle just beginning is an interrupt acknowledge cycle. iackin* active low input vmebus interrupt acknowledge in input for iack daisy chain driver. if interrupt acknowledge is at same level as interrupt currently generated by the scv64, then the cycle is accepted. if interrupt acknowledge is not at same level as current interrupt or scv64 is not generating an interrupt, then the scv64 propagates iackout*. iackout* active low output vmebus interrupt acknowledge out generated by the scv64 if it receives iackin* and is not currently generating an interrupt at the level being acknowledged. irq 7C2 * active low open drain high current bidirects vmebus interrupts 7 through 2 C these interrupts map directly onto cpu interrupt levels 7 through 2. irq7-2* are individually maskable, but cannot be read. any of them can be asserted by the scv64 under software control. 3.1 vmebus signals (continued) syscon pwrrst
scv64 user manual description of signals tundra semiconductor corporation 3-3 irq1 * active low open drain high current bidirect vmebus interrupt 1 C this signal can be as either a vme interrupt or a bi-mode initiator. if configured as a bi-mode initiator, then irq1* is asserted by writing to the abi bit in the genctl register. the status of irq1* (asserted or negated) is monitored through the vi1 bit in the stat0 register. sysclk high current bidirect vmebus system clock C generated by the scv64 when it is the syscon, and used by the auto-id state machine and id counter. sysfail* open drain bidirect vmebus system failure C this signal is asserted using the sysfail bit in the misc register. when sysfail* is asserted by the scv64, is also asserted. when sysfail* is asserted on the vmebus the scv64 can signal a level 7 interrupt to the local cpu (see interrupt handler on page 2-18.) sysrst * active low open drain high current bidirect vmebus system reset C the scv64 asserts sysrst* under the following conditions: ? on power-up, if is asserted (the scv64 drives sysrst* for 250 ms), ? when bg0in* is asserted and the scv64 is the syscon, or ? if the software reset bit (swrst) in the genctl register is set. vaddr 31 C 01 bidirects vmebus address lines 31 to 01 C during mblt transfers, vaddr31-01 serve as data bits d63-d33. vaddr03-01 are used to indicate interrupt level on the vmebus. vaddrout active high output vmebus address transceiver direction control C the scv64 controls the direction of the address (vaddr31-01, vlword*) transceivers as required for master, slave and bus isolation modes. va m 5 C 0 bidirects vmebus address modifier codes C these codes indicate the address space being accessed (a16, a24, a32, a64), the privilege level (user, supervisor), the cycle type (standard, blt, mblt) and the data type (program, data). active low bidirect vmebus address strobe C the falling edge of indicates a valid address on the bus. by continuing to assert , ownership of the bus is maintained during a rmw cycle. vdata 31 C 00 bidirects vmebus data lines 31 through 00. 3.1 vmebus signals (continued) sysfled pwrrst vas vas vas
description of signals scv64 user manual 3-4 tundra semiconductor corporation vdataout active high output vmebus data transceiver direction control C the scv64 controls the direction of the data transceivers as required for read, write and bus isolation modes. 1 C 0 active low bidirects vmebus data strobes: ? during write cycles, the falling edge indicates valid data on the bus. ? during read cycles, assertion indicates a request to a slave to provide data. active low bidirect vmebus longword data transfer size indicator C this signal is used in conjunction with the two data strobes and vaddr 01 to indicate the number of bytes (1 C 4) in the current transfer. during mblt transfers, , serves as data bit d32. vstrbout active high output vmebus address and data strobe transceiver direction control C the scv64 points the control strobe transceivers outward when it is the bus master. in all other cases, the transceivers are pointed inward, presenting a high impedance to the vmebus. retry*/ active low bidirect retry*: vmebus retry C input indicating that current data transfer cannot occur, but should be retried. : proprietary vmebus rmw signal C bidirectional signal used to signal a rmw cycle over the vmebus. using this signal allows multiple addressing during a rmw cycle. active low bidirect vmebus write signal timing of this signal is defined relative to the data strobes and indicates the direction of data transfer. 3.1 vmebus signals (continued) vds vlword vds vlword vrmc vrmc vwr
scv64 user manual description of signals tundra semiconductor corporation 3-5 3.2 local signals baudclk output baud clock C this is a 2.4615 mhz clock signal generated from the 32 mhz input (32 mhz 13 and 38.6% duty cycle) used by devices to generate baud rate clocks. bimode active high output bi-mode signal C generated by the scv64 to indicate that logic on the card must isolate itself from the bus. active low input bi-mode release C releases the scv64 from bi-mode and negates bimode if both vmebus irq1*, , and the sbi bit in the genctl register are not asserted. otherwise, the bi-mode state is maintained. active low input bi-mode trigger C asserting puts the scv64 into bi-mode in a similar manner as irq1* when irq1* is configured as a bi-mode initiator. c14us output the 14 s clock signal is generated from the 32 mhz input (32 mhz 448 and 50% duty cycle) and sampled by the falling edge of kclk to synchronize c14us to cpu logic. this clock is typically used by dram refresh logic. c8mhz output 8 mhz general purpose clock output. c32mhz input 32 mhz clock signal used to generate clock signals and run state machines related to the vmebus. this signal is used to generate the 16.0 mhz sysclk signal, and delay line calibration. active low input external reset C this reset can be driven by any on-board logic requiring local reset. external reset affects sections of the scv64 related to local functions, but not those sections related to vmebus functions . sysrst* is not generated. jtclk input jtag test clock - not used jtdi input jtag test data - not used, connected internally to jtdo jtd0 output jtag test data - not used, connected internally to jtdi birel birel bitrig b itrig bitrig extrst
description of signals scv64 user manual 3-6 tundra semiconductor corporation jtms input jtag test mode select - not used kaddr 31 C 00 bidirects local address lines C kaddr03-01 are used to signal the interrupt level during interrupt acknowledge cycles. active low bidirect local address strobe C used to qualify address on the local bus. active low output auto-vector C asserted to the cpu during an interrupt acknowledge cycle indicating that the cycle be auto- vectored by the cpu. active low bidirect local bus error C asserted to the local cpu to indicate a local bus time-out or invalid transfer. this signal requires an external pull-up resistor of approximately 4.7k?. active low open drain bidirect local bus grant acknowledge C driven by the scv64 during mastership of local bus. in arbiter active mode, it indicates ownership of local bus by the device driving the signal. in arbiter bypass mode, it may be driven to undefined state. this signal is used during power-up to set the arbiter mode. this signal requires an external pull-up resistor of approximately 4.7k? to use the local arbiter or a pull- down resistor of a similar value if the local arbiter is bypassed (see local bus arbitration on page 2-66). active low input cpu bus grant C a signal from the cpu indicating that the bus is available. when is received and the scv64 local arbiter is active, the scv64 acknowledges bus grant (if it is the requester) or generates to the local requester. active low output cpu bus request C asserted to the cpu from the scv64 when is asserted. kclk input local clock C derived from the local cpu. kdata 31 C 00 bidirects local bus data lines 31to 00 C data lines 31 to 00 are used to transfer data during scv64 register accesses. 3.2 local signals (continued) kas kavec kberr kbgack kbgr kbgr lbgr1 kbrq lbrq1
scv64 user manual description of signals tundra semiconductor corporation 3-7 active low bidirect local data strobe C used in local cycles to indicate valid data during a write and a request for data during a read. the scv64 does not monitor when it is the local slave except during accesses to scv64 registers. active low bidirects local bus data transfer and size acknowledge. the slave for the current cycle asserts one or both of these signals to acknowledge the cycle and indicates the size of transfer accepted. data transfer size 0 0 4 bytes 0 1 2 bytes 1 0 1 byte 1 1 wait states inserted kfc2-0 bidirects local function codes C used to encode transfer type on the local bus. these signals are used during power- up to determine autobar configuration, and lirq 2 / kiack pin definition. active low bidirect cpu halt signal C may be used in conjunction with to resolve a master/slave deadlock. active low outputs cpu interrupt priority level C the scv64 channels all interrupt sources to 7 cpu interrupt levels. the lines are used to encode the 7 cpu interrupt levels. active low bidirect local read modify write C this signal indicates that the current cycle is part of a read-modify-write cycle. ksize 1 C 0 bidirects local bus data transfer size C this code indicates the number of bytes (including current cycle) to be transferred to complete the operation. ksize1 ksize0 data transfer size 0 0 4 bytes 1 1 3 bytes 1 0 2 bytes 0 1 1 byte active low bidirect write signal C used to indicate a read ( negated) or write ( asserted) active low input ac failure signalC may be connected directly to acfail* 3.2 local signals (continued) kds kds kdsack1-0 kdsack1 ksack0 khalt kberr kipl2-0 kipl2-0 krmc kwr kwr kwr l7iacf
description of signals scv64 user manual 3-8 tundra semiconductor corporation active low input local level 7 interrupt C this interrupt is intended to come from local memory fault detection circuitry. the interrupt is level sensitive, latched and maskable. the vmebus requester circuit requests that the scv64 release the vmebus while keeping negated and not initiate any new vmebus requests while is asserted. however, the scv64 or other device can remain the local bus owner as long as remains asserted. active low input local level 7 interrupt C this interrupt is not maskable by the scv64. the interrupt is edge sensitive and latched and can be cleared by the cpu. active low output local bus grant C this signal is asserted to a local requester when the local bus is available. active low input local bus request C this request is generated by a local requester to the scv64. is asserted when the bus is available. active low outputs local interrupt acknowledgment C this signal is sent to the device connected to either the or line. active low inputs local interrupts C each interrupt may be mapped to any of the seven cpu interrupt levels. all six interrupts are level sensitive, not latched, individually maskable and can be read. / active low inputs external local iack decoding C this pin must be in mode internal local iack decoding C this pin is available for active low output location monitor interrupt C this interrupt indicates that there are entries in the location monitor fifo. is negated when the fifo becomes empty. this signal is usually connected to the scv64 as one of the auto-vectored interrupt inputs. active low output local reset C ends any cycles being performed by the scv64 and clears various internal registers. active low cmos threshold schmitt trigger input power-on-reset C this reset is typically supplied by a resistor-capacitor network. all circuitry in the scv64 is directly reset by this signal. during power reset, the scv64 generates local and system reset. 3.2 local signals (continued) l7imem lbgr1 l7imem lbrq1 l7inmi lbgr1 lbrq1 lbgr1 liack5-4 lirq5 lirq4 lirq5-0 lirq2 kiack kiack lirq2 lmint lmint lrst pwrrst
scv64 user manual description of signals tundra semiconductor corporation 3-9 active low output memory select C this signal is asserted by the scv64: ? to select local memory during accesses from the vmebus, ? when the scv64 dma is accessing memory, or ? when the local cpu is accessing its own vme slave image. active low input scv64 chip select C used by a local address decoder for scv64 register accesses. active low output sysfail led driver C this signal can be used to directly control an onboard led, typically a faceplate indicator of the boards status. asserted when sysfail* is asserted. active low output tick timer C the tick timer period is determined by the tlen0 and tlen1 bits in the genctl register, and can be set to 5, 10, 50 or 100 ms in normal mode, or 200, 400 s and 2 or 4 ms in fast mode. fast mode is determined using the tickm bit in the ctl2 register (see tick timer on page 2-115). tmode1-0 active high inputs input signals used to test the scv64 during chip fabrication. caution: these inputs must be connected to ground for proper scv64 operation. active low output vmebus activity interrupt C this interrupt indicates an event related to vmebus use has occurred (such as dma finished or a bus error received). the signal is negated when appropriate flags in the scv64 status register are cleared. can also be used as an interrupt to the local cpu and is usually connected via one of the auto-vectored interrupt inputs. 3.2 local signals (continued) ramsel scv64sel sysfled tick ! vmeint vmeint
description of signals scv64 user manual 3-10 tundra semiconductor corporation active low input vmebus selectC this signal is generated by the local address decoder to indicate that the scv64 should attempt to initiate a vmebus cycle. the address map within the scv64 may indicate that the access is to the boards vme slave image or a vsb bus cycle and assert or respectively. otherwise, a vmebus cycle is initiated. active low output vsb select C this signal is asserted by the scv64 when a local cpu access to the vmebus has been mapped onto the vsb (by scv64 internal registers). the scv64 does not perform a vmebus cycle, but expects a vsb interface to complete the transfer. active low output watchdog timer C watchdog runs for 2 sec, asserts low for 200 ms, then begins the 2 sec time-out again. only power-up reset or clearing the watchdog (by writing to the clrdog bit in the stat0 register) can reset the timer. clearing the endog bit in the misc register disables the watchdog timer. 3.2 local signals (continued) vmeout ramsel vsbsel vsbsel wdog wdog
vmebus interface componentsscv64 user manual tundra semiconductor corporation 4-1 4 signals and dc characteristics 4.1 terminology the input and output types have all been abbreviated with a letter code. for example, the vdata31-00 signals are shown as input type cttl (which are cmos inputs with normal ttl voltage thresholds) and output type ts (which are tri-stateable outputs). the following is a list of abbreviations: cmos cmos input with cmos thresholds cmos sch schmitt trigger input with cmos thresholds cttl sch schmitt trigger input with ttl thresholds cttl cmos input with ttl thresholds i input i/o input/output o output od open drain output tp totem pole output ts tri-state totem pole output vod vmebus specification open drain output vts vmebus specification tri-state totem pole output
signals and dc characteristics scv64 user manual 4-2 tundra semiconductor corporation 4.2 dc characteristics table 4.1 : dc electrical characteristics symbol parameter signal type test conditions te sted at -40c, 25c, 85c v dd = 5v5% te sted at -55c, 125c v dd = 5v10% min max min max v ih min. high- level input cttl v out = 0.1v or v dd - 0.1v; [i out ] = 20 a 2.0 v - 2.0 v - cmos v out = 0.1v or v dd - 0.1v; [i out ] = 20 a 0.7v dd -0.7v dd - v il max. low- level input cttl v out = 0.1v or v dd - 0.1v; [i out ] = 20 a - 0.8v - 0.8v cmos v out = 0.1v or v dd - 0.1v; [i out ] = 20 a - 0.3v dd -0.3v dd v t+ positive going schmitt trigger voltage cttl/sc h v out = 0.1v or v dd - 0.1v; [i out ] = 20 a 1.2 v 2.4 v 1.2 v 2.4 v cmos/sc h v out = 0.1v or v dd - 0.1v; [i out ] = 20 a 0.42v dd 0.94v dd 0.4v dd 1.03v dd v t- negative going schmitt trigger voltage cttl/sc h v out = 0.1v or v dd - 0.1v; [i out ] = 20 a 0.8 v 2.0 v 0.8 v 2.0 v cmos/sc h v out = 0.1v or v dd - 0.1v; [i out ] = 20 a 0.31v dd 0.69v dd 0.29 v dd 0.76 v dd v hysteresis schmitt trigger hysteresis voltage cttl/sc h v t+ to v t- 0.06v dd 0.12v dd 0.05 v dd 0.14 v dd cmos/sc h v t+ to v t- 0.11v dd 0.25v dd 0.11 v dd 0.27 v dd i in maximum input leakage current cmos and cttl with no pull-up resistor (v in = v ss or v dd ) -5.0 a 5.0 a -5.0 a 5.0 a i oz maximum output leakage current ts (v out = v ss or v dd ) -10.0 a 10.0 a -10.0 a 10.0 a od (v out = v dd ) -10.0 a 10.0 a -10.0 a 10.0 a
tundra semiconductor corporation 4-3 scv64 user manual signals and dc characteristics table 4.2 : pin list and dc characteristics for scv64 signals (-55c to 125c) signal name type pin number in type out type i ol (ma) v ol =0.4, * 0.6 v min i oh (ma) v oh =3.5v min signal description cpga pqfp baudclk o e4 88 - tp 10 -10 baud clock bbsy* i/o c20 295 cttl/ sch v0d 48* - vmebus bbsy* signal bclr* i/o n17 252 cttl/ sch vts 64* -50 vmebus bclr* signal berr* i/o e19 291 cttl/ sch vod 48* - vmebus error bg0in* i p19 251 cttl - - - vmebus bus grant in bg1in* i n19 253 cttl - - - vmebus bus grant in bg2in* i l19 262 cttl - - - vmebus bus grant in bg3in* i l17 264 cttl - - - vmebus bus grant in bg0out* o u9 182 - tp 10 -10 vmebus bus grant out bg1out* o t9 183 - tp 10 -10 vmebus bus grant out bg2out* o v9 184 - tp 10 -10 vmebus bus grant out bg3out* o w10 186 - tp 10 -10 vmebus bus grant out bimode o d2 87 - tp 10 -10 bi-mode output i a13 25 cttl/ sch - - - bi-mode release i d11 36 cttl/ sch - - - bi-mode trigger br0* i/o d13 24 cttl/ sch vod 48* - vmebus bus request br1* i/o b12 35 cttl/ sch vod 48* - vmebus bus request br2* i/o d8 54 cttl/ sch vod 48* - vmebus bus request br3* i/o b17 11 cttl/ sch vod 48* - vmebus bus request c14us o d7 58 - tp 10 -10 clock out - 14us period c32mhz i l3 114 cmos - - - 32mhz clock input c8mhz o l4 116 - tp 10 -10 clock output - 8mhz dtack* i/o n20 255 cttl/ sch vod 48* - vmebus dtack* signal i d6 64 cttl/ sch - - - external reset iack* i/o u19 239 cttl vts 48* -40 vmebus iack* signal iacki* i n18 254 cttl - - - vmebus iackin* signal iacko* o w19 233 - tp 10 -10 vmebus iackout* sig- nal birel bitrig extrst
signals and dc characteristics scv64 user manual 4-4 tundra semiconductor corporation irq1* i/o w4 163 cttl/ sch vod 48* - vmebus interrupt request irq2* i/o w6 167 cttl/ sch vod 48* - vmebus interrupt request irq3* i/o u8 176 cttl/ sch vod 48* - vmebus interrupt request irq4* i/o w11 195 cttl/ sch vod 48* - vmebus interrupt request irq5* i/o v14 206 cttl/ sch vod 48* - vmebus interrupt request irq6* i/o w15 215 cttl/ sch vod 48* - vmebus interrupt request irq7* i/o y18 219 cttl/ sch vod 48* - vmebus interrupt request jtclk i j1 119 cttl - - - jtag test clock jtdi i k4 110 cttl - - - jtag test data jtdo o j5 111 - ts 10 -10 jtag test data jtms i m3 120 cttl - - - jtag test mode select kaddr (31:0) i/o see ta b le 4.4 see ta b le 4.4 cttl ts 5 -5 cpu address bus i/o k2 112 cttl ts 10 -10 cpu address strobe o c5 70 - tp 5 -5 avec interrupt termination i/o a3 69 cttl ts 10 -10 cpu bus error i/o b4 67 cttl/ sch od 10 - cpu bus grant acknowledge i b8 55 cttl - - - cpu bus grant o b9 53 - tp 5 -5 cpu bus request kclk i k3 108 cmos - - - cpu clock kdata (31:0) i/o see ta b le 4.4 see ta b le 4.4 cttl ts 5 -5 cpu data bus i/o c8 52 cttl ts 5 -5 cpu data strobe i/o e10 47 cttl ts 10 -10 cpu data transfer and size acknowledge i/o d9 48 cttl ts 10 -10 cpu data transfer and size acknowledge kfc0 i/o c10 40 cttl ts 5 -5 cpu function code kfc1 i/o a11 41 cttl ts 5 -5 cpu function code kfc2 i/o d10 42 cttl ts 5 -5 cpu function code i/o a10 43 cttl ts 10 -10 cpu halt table 4.2 : pin list and dc characteristics for scv64 signals (-55c to 125c) (continued) signal name type pin number in type out type i ol (ma) v ol =0.4, * 0.6 v min i oh (ma) v oh =3.5v min signal description cpga pqfp kas kavec kberr kbgack kbgr kbrq kds kdsack0 kdsack1 khalt
tundra semiconductor corporation 4-5 scv64 user manual signals and dc characteristics / i w8 175 cttl - - - local interrupt acknowledge o r2 139 - tp 5 -5 cpu interrupt priority level o r4 140 - tp 5 -5 cpu interrupt priority level o t2 141 - tp 5 -5 cpu interrupt priority level i/o b10 44 cttl ts 2 -2 cpu rmc ksize0 i/o a12 37 cttl ts 5 -5 cpu transfer size code ksize1 i/o c11 38 cttl ts 5 -5 cpu transfer size code i/o c9 46 cttl ts 10 -10 cpu write i f17 292 cttl - - - level 7 interrupt (acfail) i e18 294 cttl - - - level 7 interrupt (memory error) i c16 12 cttl - - - level 7 interrupt (non-maskable) o b11 34 - tp 5 -5 local bus grant (external dma) i v16 218 cttl - - - local bus request (external dma) o v7 174 - tp 5 -5 local interrupt acknowledge 4 o v8 178 - tp 5 -5 local interrupt acknowledge 5 i v5 164 cttl - - - local interrupt i u6 166 cttl - - - local interrupt / i w8 175 cttl - - - local interrupt i u11 194 cttl - - - local interrupt i w12 205 cttl - - - local interrupt i u15 216 cttl - - - local interrupt o y8 177 - tp 2 -2 location monitor interrupt o u7 172 - tp 20 -20 local reset i r17 240 cttl/ sch - - - power-up reset o c13 26 - tp 5 -5 local memory select retry*/ i/o b6 63 cttl/ sch ts 2 -2 vmebus retry* (i), or vmebus rmc signal (i/o) i g19 283 cttl - - - scv64 chip select sysclk i/o k16 263 cttl vts 64* -50 vmebus sysclk table 4.2 : pin list and dc characteristics for scv64 signals (-55c to 125c) (continued) signal name type pin number in type out type i ol (ma) v ol =0.4, * 0.6 v min i oh (ma) v oh =3.5v min signal description cpga pqfp lirq2 kiack kipl0 kipl1 kipl2 krmc kwr l7iacf l7imem l7inmi lbgr1 lbrq1 liack4 liack5 lirq0 lirq1 lirq2 kiack lirq3 lirq4 lirq5 lmint lrst pwrrst ramsel vrmc scv64sel
signals and dc characteristics scv64 user manual 4-6 tundra semiconductor corporation sysfail* i/o r18 242 cttl/ sch vod 48* - vmebus sysfail o c12 32 - od 24* - sysfail led driver sysrst* i/o h17 282 cttl/ sch vod 48* - vmebus sysreset o d12 30 - tp 5 -5 tick clock tmode0 i j2 117 cmos /sch - - - test mode enable connect to ground tmode1 i l5 118 cmos /sch - - - test mode enable connect to ground vaddr (31:1) i/o see ta b le 4.3 see ta b le 4.3 cttl ts 2 -2 vmebus address bus vaddrout o c14 22 - tp 10 -10 vmebus address direction control vam0 i/o m17 258 cttl ts 2 -2 vmebus address modifier 0 vam1 i/o m19 259 cttl ts 2 -2 vmebus address modifier 1 vam2 i/o m18 260 cttl ts 2 -2 vmebus address modifier 2 vam3 i/o l18 266 cttl ts 2 -2 vmebus address modifier 3 vam4 i/o k18 268 cttl ts 2 -2 vmebus address modifier 4 vam5 i/o l20 269 cttl ts 2 -2 vmebus address modifier 5 i/o u18 235 cttl/ sch ts 5 -5 vmebus address strobe vdata (31:0) i/o see ta b le 4 .3 see ta b le 4 .3 cttl ts 2 -2 vmebus data bus vdataout o d14 20 - tp 10 -10 vmebus data direction i/o v18 231 cttl ts 5 -5 vmebus data strobe i/o u17 232 cttl ts 5 -5 vmebus data strobe i/o w9 187 cttl ts 2 -2 vmebus lword* signal o c15 18 - tp 2 -2 vmebus activity interrupt i v20 241 cttl - - - vmebus select retry*/ i/o b6 63 cttl/ sch ts 2 -2 vmebus retry* (i), or vmebus rmc signal (i/o) o b13 23 - tp 5 -5 vsbbus select vstrbout o b14 21 - tp 5 -5 vmebus strobe direction i/o t17 234 cttl ts 2 -2 vmebus write* signal o e12 31 - tp 5 -5 watchdog interrupt output table 4.2 : pin list and dc characteristics for scv64 signals (-55c to 125c) (continued) signal name type pin number in type out type i ol (ma) v ol =0.4, * 0.6 v min i oh (ma) v oh =3.5v min signal description cpga pqfp sysfled tick vas vds0 vds1 vlword vmeint vmeout vrmc vsbsel vwr wdog
tundra semiconductor corporation 4-7 scv64 user manual signals and dc characteristics table 4.3 : vmebus address and data input and output signal bits signal cpga pin pqfp pin signal cpga pin pqfp pin vaddr1 u10 188 vdata0 k17 270 vaddr2 y10 189 vdata1 k19 271 vaddr3 v10 190 vdata2 j18 272 vaddr4 v11 192 vdata3 j17 274 vaddr5 y11 193 vdata4 k20 275 vaddr6 v12 196 vdata5 j16 276 vaddr7 u12 198 vdata6 j19 279 vaddr8 t11 199 vdata7 h18 280 vaddr9 v13 200 vdata8 h19 281 vaddr10 u13 204 vdata9 g18 284 vaddr11 w13 207 vdata10 f20 285 vaddr12 t13 208 vdata11 g17 286 vaddr13 w14 209 vdata12 f18 288 vaddr14 u14 210 vdata13 f19 289 vaddr15 v15 212 vdata14 d19 293 vaddr16 y15 213 vdata15 c19 297 vaddr17 w16 217 vdata16 f16 298 vaddr18 w17 221 vdata17 d18 299 vaddr19 t15 222 vdata18 e17 300 vaddr20 w18 223 vdata19 c18 301 vaddr21 u16 224 vdata20 e16 302 vaddr22 v17 225 vdata21 b19 3 vaddr23 t16 226 vdata22 d17 4 vaddr24 t18 236 vdata23 b18 5 vaddr25 v19 237 vdata24 e15 6 vaddr26 t19 243 vdata25 c17 7 vaddr27 r19 245 vdata26 d16 8 vaddr28 p17 246 vdata27 a18 9 vaddr29 n16 248 vdata28 b16 13 vaddr30 r20 249 vdata29 d15 14 vaddr31 p18 250 vdata30 b15 15 vdata31 a15 17
signals and dc characteristics scv64 user manual 4-8 tundra semiconductor corporation table 4.4 : local bus address and data input and output signal bits signal cpga pin pqfp pin signal cpga pin pqfp pin kaddr0 c7 56 kdata0 m4 122 kaddr1 b7 57 kdata1 l2 123 kaddr2 c6 60 kdata2 n3 124 kaddr3 a6 61 kdata3 l1 127 kaddr4 b5 65 kdata4 n4 128 kaddr5 e7 66 kdata5 m2 129 kaddr6 c4 71 kdata6 p3 130 kaddr7 d5 72 kdata7 n2 131 kaddr8 b3 73 kdata8 n5 132 kaddr9 c3 74 kdata9 p2 133 kaddr10 b2 79 kdata10 p4 134 kaddr11 e5 80 kdata11 r3 136 kaddr12 c2 81 kdata12 r1 137 kaddr13 d4 82 kdata13 t3 142 kaddr14 d3 83 kdata14 u2 143 kaddr15 f5 84 kdata15 v1 145 kaddr16 c1 85 kdata16 t4 146 kaddr17 e3 89 kdata17 v2 147 kaddr18 f4 90 kdata18 u3 148 kaddr19 e2 91 kdata19 w2 149 kaddr20 f3 93 kdata20 t5 150 kaddr21 g4 94 kdata21 v3 155 kaddr22 g3 96 kdata22 u4 156 kaddr23 f2 97 kdata23 w3 157 kaddr24 h4 98 kdata24 t6 158 kaddr25 f1 99 kdata25 v4 159 kaddr26 h3 100 kdata26 u5 160 kaddr27 g2 101 kdata27 y3 161 kaddr28 j4 102 kdata28 w5 165 kaddr29 h2 103 kdata29 y6 169 kaddr30 j3 106 kdata30 v6 170 kaddr31 h1 107 kdata 31 w7 173
tundra semiconductor corporation 4-9 scv64 user manual signals and dc characteristics table 4.6 : pin assignments for power table 4.5 : pin assignments for ground v ss pins cpga pqfp a2 a4 a7 76 68 59 a9 a14 a17 50 45 39 a19 b1 b20 33 28 19 d1 d20 e8 10 1 304 e11 e14 g1 296 287 278 g5 g16 g20 273 267 261 j20 k1 k5 256 247 238 l16m1 p1 229228220 p5 p16 p20 211 202 197 t7 t10 t14 191 185 180 u1 u20 w1 171 162 153 w20 y2 y4 152 144 135 y7 y12 y14 126 121 115 y17 y19 109 104 95 86 77 v dd pins cpga pqfp a1 a5 a8 75 62 51 a16 a20 e1 49 29 27 e9 e13 e20 16 2 303 h5 h16 h20 290 277 265 m5 m16 m20 257 244 230 n1 r5 r16 227 214 203 t1 t8 t12 201 181 179 t20 y1 y5 168 154 151 y9 y13 y16 138 125 113 y20 105 92 78
signals and dc characteristics scv64 user manual 4-10 tundra semiconductor corporation 4.3 capacitive loading table 4.7 : input capacitive loading signal type signal name input capacitance (pf) input bgin[3:0], birel, bitrig, c32mhz, extrst, jtclk, jtdi, jtms, kbgr, kclk, l7iacf, l7imem, l7inmi, lbrq, lirq[5:0], pwrrst, tmode[1:0], iackin, vmeout 18 input/output iack, kaddr[31:0], kas, kberr, kdata[31:0], kds, kdsack[1:0], kfc[2:0], khalt, ksize[1:0], kwr, krmc, scv64sel , vaddr[31:1], vam[5:0], vas, vdata[31:0], vds[1:0], vlword, vretry, vwr 18 bbsy, br[3:0], berr, dtack, irq[7:1], sysfail, sysrst 24 bclr, sysclk 30 output jtdo 18
tund r a s e m i c ondu c to r c o r po r ati o n 4 -11 scv6 4 use r manua l signa l s and d c chara c t e r i s t ics 4.4 pin c o n f i g ura t ion the 299 - pin cpga con f iguratio n is s h o w n here i n figur e 4 .1 w h i le the 30 4 pin pq f p package is illu s t rated i n figu r e 4.2. f igu r e 4 . 1 : p i n con f igurat i on f or 299 - pi n cpg a p ackage vdata <19> vdata <25> l7inmi vmeint vaddrout ramsel sysfled ksize1 kfc0 kwr kds kaddr <00> kaddr <02 > vdata <22> vdata <26> vdata <29> vdataout br0* tick bitrig kfc2 ca91c078 a scv64 bottom view a b c d e f g h j k l m n p r t u kavec kaddr <06> kaddr <09> kaddr <12> 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 17 kdsack1 br2* c14us extrst kaddr <07> kaddr <13> bimode kaddr <14> kaddr <11> baudclk kaddr <19> kaddr <17> kaddr <15> kaddr <18> kaddr <23> kaddr <20> vss kaddr <21> kaddr <27> kaddr <22> jtd0 kaddr <28> tmode0 kaddr <30> vss jtdi kas kclk tmode1 c8mhz kdata <01> c32mhz vdd kdata <00> kdata <05> jtms kdata <08> kdata <04> kdata <07> kdata <02> vss kdata <10> kdata <09> kdata <06> vdd kipl1 kipl0 kdata <11> kdata <20> kdata <16> kipl2 kdata <13> kdata <26> kdata <22> kdata <14> kdata <18> lirq0 kdata <25> kdata <17> kdata <21> kdata <28> irq1* kdata <19> kdata <23> vdd kaddr <24> kaddr <29> kaddr <26> bg1out* vdd kdata <24> vss bg0out* irq3* lirq1 lrst bg2out* liack5 kdata <30> liack4 vlword lirq2/kiack irq2* kdata <31> vaddr <12> vdd vss vaddr <08> vaddr <10> vaddr <07> vaddr <01> lirq3 vaddr <09> vaddr <06> vaddr <03> vaddr <04> vaddr <11> lirq4 bg3out* irq4* vwr vaddr <23> vss vaddr <19> vds1 vaddr <21> vaddr <14> lirq5 vaddr <22> lbrq1 irq5* vaddr <15> vaddr <18> vaddr <17> vaddr <13> irq6* vam2 vam0 vdd iacki* bclr* vaddr <29> vaddr <31> vaddr <28> vss sysfail* pwrrst vdd vaddr <24> vas vaddr <20> vds0 vam4 vdata <00> sysclk vam3 bg3in* vss vdata <07> sysrst* vdd vdata <02> vdata <03> vdata <05> vdata <12> l7iacf vdata <16> vdata <09> vdata <11> vss l7imem vdata <18> vdata <24> vdata <20> vss vdd vss wdog kdsack0 vdd kaddr <05> vss bbsy* vdata <15> vss vdata <14> 1 8 19 vaddr <26> iack* vaddr <25> iacko* vdd vam1 dtack* bg1in* vss bg0in* vaddr <30> vaddr <27> vdd vss vss vmeout vdata <04> vdata <01> vam5 bg2in* vdd vdata <08> vss vdata <06> vdata <10> vdata <13> vss scv64sel vdd berr* vdd vss vss kdata <27 > vdd lmint kdata <29> vs s vdd vss vaddr <02> vaddr <05> vss vdd vss vaddr <16> irq7* vss vdd kaddr <16> vss vdd kaddr <25> vss jtclk vss kdata <03> vss vdd vss kdata <12> vdd vss kdata <15> vss kaddr <31> vdd vdata <27> vss vdd vdata <31> vss birel ksize0 kfc1 khalt vss vdd vss kaddr <03> vdata <23> br3* vdata <28> vdata <30> vstrbout vsbsel br1* lbgr1 krmc vdd vss kberr vss kbrq kbgr kaddr <01> retry*/vrmc kaddr <04> kbgack kaddr <10> kaddr <08> vdd vss vss vdata <21> vdd vss v w y 20 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 20 a b c d e f g h j k l m n p r t u v w y vdata <17>
si g n a ls a n d d c cha r a c te r isti c s scv64 u s e r man u a l 4- 1 2 tund r a s e mi c on d u c to r co r po r a tion index mark pin 1 pin 76 pin 77 pin 152 pin 153 pin 228 pin 22 9 pin 304 ca91c078a top view fig u r e 4.2 : pin con f iguration f or 304- p in pq f p p a c k age 304 p in p l as t ic q f p 153. v ss 154. v dd 155. k d a t a21 156. k d a t a22 157. k d a t a23 158. k d a t a24 159. k d a t a25 160. k d a t a26 161. k d a t a27 162. v ss 163. i r q 1* 164. 165. k d a t a28 166. 167. i r q 2* 168. v dd 169. k d a t a29 170. k d a t a30 171. v ss 172. 173. k d a t a31 174. 175. / 176. i r q 3* 177. 178. 179. v dd 180. v ss 181. v dd 182. b g 0 o u t * 183. b g 1 o u t * 184. b g 2 o u t * 185. v ss 186. b g 3 o u t * 187. 188. v a ddr1 189. v a ddr2 190. v a ddr3 lir q 0 lir q 1 lr s t li a ck4 lir q 2 k i a c k l m i n t li a ck5 v l w o r d 191. v ss 192. v a ddr4 193. v a ddr5 194. 195. ir q 4* 196. v a ddr6 197. v ss 198. v a ddr7 199. v a ddr8 200. v a ddr9 201. v dd 202. v ss 203. v dd 204. v a ddr10 205. 206. ir q 5* 207. v a ddr11 208. v a ddr12 209. v a ddr13 210. v a ddr14 211. v ss 212. v a ddr15 213. v a ddr16 214. v dd 215. ir q 6* 216. 217. v a ddr17 218. 219. ir q 7* 220. v ss 221. v a ddr18 222. v a ddr19 223. v a ddr20 224. v a ddr21 225. v a ddr22 226. v a ddr23 227. v dd 228. v ss lir q 3 lir q 4 lir q 5 lb r q 1 1. v ss 2. v dd 3 . v d a t a21 4 . v d a t a22 5 . v d a t a23 6 . v d a t a24 7 . v d a t a25 8 . v d a t a26 9 . v d a t a27 1 0 . v ss 1 1 . b r 3 * 1 2 . 1 3 . v d a t a 2 8 1 4 . v d a t a 2 9 1 5 . v d a t a 3 0 1 6 . v dd 1 7 . v d a t a 3 1 1 8 . 1 9 . v ss 2 0 . v d a t a o u t 2 1 . vs t r b o u t 2 2. v a dd r o ut 2 3 . 2 4 . b r 0 * 2 5 . 2 6 . 2 7 . v dd 2 8 . v ss 2 9 . v dd 3 0 . 3 1 . 3 2 . 3 3 . v ss 3 4 . 3 5 . b r 1 * 3 6 . 3 7 . ks i z e 0 3 8 . ks i z e 1 39. v ss 40. k f c0 41. k f c1 42. k f c2 43. 44. 45. v ss 46. 47. 48. 49. v dd 50. v s s 51. v dd 52. 53. 54. br 2 * 55. 56. k a ddr0 57. k a ddr1 58. c14us 59. v ss 60. k a ddr2 61. k a ddr3 62. v dd 63. re t r y */ 64. 65. k a ddr4 66. k a ddr5 67. 68. v ss 69. 70 . k a vec 71. k a ddr6 72. k a ddr7 73. k a ddr8 74. k a ddr9 75. v dd 76. v ss 77. v ss 78. v dd 79. k a ddr10 80. k a ddr11 81. k a ddr12 82. k a ddr13 83. k a ddr14 84. k a ddr15 85. k a ddr16 86. v ss 87. bim o de 88. b a udclk 89. k a ddr17 90. k a ddr18 91. k a ddr19 92. v dd 93. k a ddr20 94. k a ddr21 95. v ss 96. k a ddr22 97. k a ddr23 98. k a ddr24 99. k a ddr25 10 0 . k a ddr26 10 1 . k a ddr27 10 2 . k a ddr28 10 3 . k a ddr29 10 4 . v ss 10 5 . vdd 10 6 . k a ddr30 10 7 . k a ddr31 10 8 . kclk 10 9 . v ss 11 0 . j t di 11 1 . j t do 11 2 . 11 3 . v dd 11 4 . c32mhz 115. v ss 116. c8mhz 117. t m o d e 0 118. t m o d e 1 119. j t clk 120. j t ms 121. v ss 122. k d a t a 0 123. k d a t a 1 124. k d a t a 2 125. v dd 126. v ss 127. k d a t a 3 128. k d a t a 4 129. k d a t a 5 130. k d a t a 6 131. k d a t a 7 132. k d a t a 8 133. k d a t a 9 134. k d a t a 10 135. v ss 136. k d a t a 11 137. k d a t a 12 138. v dd 139. 140. 141. 142. k d a t a 13 143. k d a t a 14 144. v ss 145. k d a t a 15 146. k d a t a 16 147. k d a t a 17 148. k d a t a 18 149. k d a t a 19 150. k d a t a 20 151. v dd 152. v ss l 7 inmi v m e i n t v s b s el b i r e l r a m s e l t i c k w d og s y s f led lb g r1 b i t r i g k h a l t k r mc k w r k d s a c k 0 k d s a c k 1 k d s k b r q k b gr v r mc ex t r s t k b g a c k k be r r k a s k i p l0 k i p l1 k i p l2 229. v ss 230. v dd 231. 232. 233. i a c k o * 234. 235. 236. v a ddr24 237. v a ddr25 238. v ss 239. i a c k * 240. 241. 242. s y s f ail* 243. v a ddr26 244. v dd 245. v a ddr27 246. v a ddr28 247. v ss 248. v a ddr29 249. v a ddr30 250. v a ddr31 251. b g 0in* 252. bc l r * 253. b g 1in* 254. i a c k i* 255. d t a ck* 256. v ss 257. v dd 258. v a m0 259. v a m1 260. v a m2 261. v s s 262. b g 2in* 263. s y sclk 264. b g 3in* 265. v dd 266. v a m3 267. v ss 268. v am4 269. v am5 270. v d a t a0 271. v d a t a1 272. v d a t a2 273. v ss 274. v d a t a3 275. v d a t a4 276. v d a t a5 277. v dd 278. v ss 279. v d a t a6 280. v d a t a7 281. v d a t a8 282. s ysr s t * 283. 284. v d a t a9 285. v d a t a10 286. v d a t a11 287. v ss 288. v d a t a12 289. v d a t a13 290. v dd 291. b err* 292. 293. v d a t a14 294. 295. b bs y * 296. v ss 297. v d a t a15 298. v d a t a16 299. v d a t a17 300. v d a t a18 301. v d a t a19 302. v d a t a20 303. v dd 304. v ss v d s 0 v d s1 v w r v a s p w rr s t v m e o u t s c v 6 4 s el l 7 iacf l7i m em
vmebus interface componentsscv64 user manual tundra semiconductor corporation app a-1 appendix a registers a.1 control and status registers the scv64 decodes local bus access to its addressable internal registers using the pin and the least significant 9 local address lines, kaddr[8:0]. address range 000 to 04c will respond only to aligned 32-bit transfers, and will assert otherwise. address range 080 to 0bf responds to any size transfer with any alignment but always transfers data using the least significant data lines kdata[7:0]. since the upper 24 data lines are ignored on writes to these registers and are always driven to zero, table a.26 to table a.41 will include only the 8 least significant bits. however, note that the scv64 always responds as a 32-bit port, i.e. both and are asserted. any attempted access to a reserved register addresses will terminate with (see table a.1 and table a.2). table a.1 : a summary of scv64 register accesses address range (hexadecimal) 32-bit access 16-bit access 8-bit access 000 to 04c yes 050 to 07f 080 to 0bf yes yes yes 0c0 to 0e0 yes 0e4 to 1ff scv64sel kberr kdsack0 kdsack1 kberr kberr kberr kberr kberr kberr kberr kberr kberr kberr kberr
registers scv64 user manual app a-2 tundra semiconductor corporation table a.2 : scv64 register map longword register address register name xxxx x000 dma local address dmalar xxxx x004 dma vmebus address dmavar xxxx x008 dma transfer count dmatc xxxx x00c control and status dcsr xxxx x010 vmebus slave base address vmebar xxxx x014 rx fifo data rxdata xxxx x018 rx fifo address register rxaddr xxxx x01c rx fifo control register rxctl xxxx x020 vmebus/vsb bus select bussel xxxx x024 vmebus interrupter vector ivect xxxx x028 access protect boundary apbr xxxx x02c tx fifo data output latch txdata xxxx x030 tx fifo address output latch txaddr xxxx x034 tx fifo am code and control bit latch txctl xxxx x038 location monitor fifo read port lmfifo xxxx x03c scv64 mode control mode xxxx x040 slave a64 base address sa64bar xxxx x044 master a64 base address ma64bar xxxx x048 local address generator lag xxxx x04c dma vmebus transfer count dmavtc xxxx 050 to xxxx 07f reserved xxxx x080 status register 0 stat0 xxxx x084 status register 1 stat1 xxxx x088 general control register genctl xxxx x08c vmebus interrupter requester vint xxxx x090 vmebus requester register vreq xxxx x094 vmebus arbiter register varb xxxx x098 id register id xxxx x09c control and status register ctl2 xxxx x0a0 level 7 interrupt status register 7is xxxx x0a4 local interrupt status register lis xxxx x0a8 level 7 interrupt enable register 7ie xxxx x0ac local interrupt enable register lie xxxx x0b0 vmebus interrupt enable register vie xxxx x0b4 local interrupts 1 and 0 control register ic10 xxxx x0b8 local interrupts 3 and 2 control register ic32
scv64 user manual registers tundra semiconductor corporation app a-3 xxxx x0bc local interrupts 5 and 4 control register ic54 xxxx x0c0 miscellaneous control register misc xxxx x0c4 delay line control register dlct xxxx x0c8 delay line status register 1 dlst1 xxxx x0cc delay line status register 2 dlst2 xxxx x0d0 delay line status register 3 dlst3 xxxx x0d4 mailbox register 0 mbox0 xxxx x0d8 mailbox register 1 mbox1 xxxx x0dc mailbox register 2 mbox2 xxxx x0e0 mailbox register 3 mbox3 xxxx x0e4 to xxxx x1fc reserved table a.2 : scv64 register map (continued) longword register address register name
registers scv64 user manual app a-4 tundra semiconductor corporation table a.3 : dma local address register (dmalar) table a.4 : dma vmebus address register (dmavar) register name: dmalar register number: xxxx x000 bits function 31-24 not used (5 bits) dla (dma local address) 23-16 dla (dma local address) - byte 2 15-08 dla (dma local address) - byte 1 07-00 dla (dma local address) - byte 0 (total 27 bits) 0 dmalar description name type condition after reset state function dla 26 C 01 r/w u dma local address bits 26 C 01 dla 00 r 0 0 dma local address bit 00 is always 0 dla 01 r/w u C dma local address bit 01 is always 0 for d32 blt, or mblt transfers dla 02 r/w u C dma local address 02 is always 0 for mblt transfers register name: dmavar register address: xxxx x004 bits function 31-24 dva (dma vme bus address) - byte 3 23-16 dva (dma vme bus address) - byte 2 15-08 dva (dma vme bus address) - byte 1 07-00 dva (dma vme bus address) - byte 0 0 dmavar description name type condition after reset state function dva 31 C 01 r/w u dma vmebus address bits 31 C 01 dva 00 r 0 0 dma vmebus address bit 00 is always 0 dva 01 r/w u C dma vmebus address bit 01 is always 0 for d32 blt, or mblt transfers dva 02 r/w u C dma vmebus address bit 02 is always 0 for mblt transfers
scv64 user manual registers tundra semiconductor corporation app a-5 table a.5 : dma transfer count register (dmatc) notes : 1. dtc19-12 are only used when dtcsiz (bit 31 in mode control register) is set. 2. bit 00 is read-only value 0, as mblt vmebus transfers are double longwords. register name: dmatc register address: xxxx x008 bits function 31-24 not used 23-16 not used dtc (dma transfer count) 15-08 dtc (dma transfer count) dtc (dma transfer count) 07-00 (dma transfer count) (total 20 bits) dmatc description name type condition after reset state function dtc19 C 00 (note 1) r/w u dma transfer count: specifies the number of local bus transfers to perform, summarized as follows:. dma mode register value non-block, d16 words non-block, d32 longwords blt, d16 words blt, d32 longwords mblt longwords, (note 2)
registers scv64 user manual app a-6 tundra semiconductor corporation table a.6 : control and status register (dcsr) register name: dcsr register address: xxxx x00c bits function 31-24 not used reserved 23-16 not used cerr 15-08 txshift retry rmcerr a64bardy reserved rxshift rxrst txrst 07-00 rxhd txhd dlberr lmhd lberr vberr done dmago dcsr description name type condition after reset state function cerr r/w 0 configuration error: asserts while 1. clear by writing 0 to this bit. see dma completion and error checking on page 2-108. 0 no conflicting configurations set 1 incompatible options are set txshft r/w 0 transmit fifo shift r clears self; always reads zero w0 w1 no effect tx fifo shifts one forward retry r/w 0 state of vmebus retry* signal during last failed cycle 0 not asserted 1 asserted rmcerr r/w 0 rmc cycle lockup flag r0 last was not issued due to rmw lockup r1 last was issued due to rmw lockup w0 clear w1 no effect a64bardy r 0 a64 base address ready flag 0 ma64bar and sa64bar registers not programmed yet 1 master and slave a64 base addresses are programmed rxshft r/w 0 receive fifo shift r clears self; always reads zero w0 no effect w1 rx fifo shifts one forward vmeint kberr kberr
scv64 user manual registers tundra semiconductor corporation app a-7 rxrst r/w o receive fifo reset r clears self; always reads zero w0 no effect w1 resets entire receive fifo txrst r/w o transmit fifo reset r clears self; always reads zero w0 no effect w1 resets entire transmit fifo and any vme-out cycle in progress rxhd r o receive fifo status 0 receive fifo is empty 1 receive fifo has entries txhd r o transmit fifo status 0 transmit fifo is empty 1 transmit fifo has entries dlberr r/w o dma local bus error indicator; asserts pin while 1 r0 no error indicated r1 dma received a local bus error w0 clears dlberr indicator w1 no effect lmhd r o location monitor fifo status; asserts pin while 1 0 lm fifo is empty 1 lm fifo has entries lberr r/w o local received while in coupled or decoupled mode; asserts pin while 1 r0 no error indicated r1 local bus error received w0 clears lberr indicator w1 no effect. vberr r/w o vmebus berr* received while in coupled or decoupled mode; causes the scv64 to halt vme master cycles and assert the pin while 1 r0 no error indicated r1 vmebus berr* received w0 clears berr* indicator w1 no effect. dcsr description (continued) name type condition after reset state function vmeint lmint kberr vmeint vmeint
registers scv64 user manual app a-8 tundra semiconductor corporation done r/w o dma done indicator; asserts pin while 1 r0 dma not done yet r1 dma finished or stopped by cpu; not set if stopped due to berr* w0 clear done bit w1 no effect dmago r/w o dma go bit r0 dma is stopped, by self or cpu r1 dma is running w0 dma stop request w1 starts dma dcsr description (continued) name type condition after reset state function vmeint
scv64 user manual registers tundra semiconductor corporation app a-9 table a.7 : vmebus slave base address register (vmebar) note: if vmebar is programmed from the vmebus using a decoupled cycle, the vmebus slave base address will not be updated immediately register name: vmebar register address: xxxx x010 bits function 31-24 not used 23-16 not used a24siz (2 bits) a24ba (5 bits) 15-08 not used a32siz 07-00 a32siz (total 4 bits) a32ba (5 bits) vmebar description name type condition after reset state function a24siz r/w u sets size of a24 slave image 0 512k 1 1m 2 2m 3 4m a24ba r/w u see table a.8 sets base address of a24 slave image. programmed size of the image will force the low three order a24ba address bits (register bits 18, 17, and 16) to zero as appropriate. bits 20 C 16 will be compared against vmebus address bits a23 C a19. a32siz r/w u see table a.9 sets size of a32 slave image a32ba r/w u see table a.10 sets base address of a32 image
registers scv64 user manual app a-10 tundra semiconductor corporation table a.8 : a24 slave image programming a24siz state a24 slave image size acceptable a24 slave image base addresses a24ba state 00 512 kbytes 00 0000 00 08 0000 01 10 0000 02 18 0000 03 20 0000 04 28 0000 05 30 0000 06 38 0000 07 40 0000 08 48 0000 09 50 0000 0a 58 0000 0b 60 0000 0c 68 0000 0d 70 0000 0e 78 0000 0f 80 0000 10 88 0000 11 90 0000 12 98 0000 13 a0 0000 14 a8 0000 15 b0 0000 16 b8 0000 17 c0 0000 18 c8 0000 19 d0 0000 1a d8 0000 1b e0 0000 1c e8 0000 1d f0 0000 1e f8 0000 1f
scv64 user manual registers tundra semiconductor corporation app a-11 01 1mbyte 00 0000 00 10 0000 02 20 0000 04 30 0000 06 40 0000 08 50 0000 0a 60 0000 0c 70 0000 0e 80 0000 10 90 0000 12 a0 0000 14 b0 0000 16 c0 0000 18 d0 0000 1a e0 0000 1c f0 0000 1e 10 2 mbytes 00 0000 00 20 0000 04 40 0000 08 60 0000 0c 80 0000 10 a0 0000 14 c0 0000 18 e0 0000 1c 11 4 mbytes 00 0000 00 40 0000 08 80 0000 10 c0 0000 18 table a.8 : a24 slave image programming (continued) a24siz state a24 slave image size acceptable a24 slave image base addresses a24ba state
registers scv64 user manual app a-12 tundra semiconductor corporation table a.9 : a32 slave image size (4 bit field) state a32 slave image size state a32 slave image size state a32 slave image size state a32 slave image size 0 4k 4 64k 8 1m c 16m 1 8k 5 128k 9 2m d 32m 2 16k 6 256k a 4m e 64m 3 32k 7 512k b 8m f 128m table a.10 : a32 slave image base address (5 bit field) state acceptable a32 slave image base address state acceptable a32 slave image base address state acceptable a32 slave image base address state acceptable a32 slave image base address 0 0000.0000 8 4000.0000 10 8000.0000 18 c000.0000 1 0800.0000 9 4800.0000 11 8800.0000 19 c800.0000 2 1000.0000 a 5000.0000 12 9000.0000 1a d000.0000 3 1800.0000 b 5800.0000 13 9800.0000 1b d800.0000 4 2000.0000 c 6000.0000 14 a000.0000 1c e000.0000 5 2800.0000 d 6800.0000 15 a800.0000 1d e800.0000 6 3000.0000 e 7000.0000 16 b000.0000 1e f000.0000 7 3800.0000 f 7800.0000 17 b800.0000 1f f800.0000
scv64 user manual registers tundra semiconductor corporation app a-13 table a.11 : rxfifo data register (rxdata) table a.12 : rxfifo address register (rxaddr) register name: rxdata register address: xxxx x014 bits function 31-24 data lane at output stage of receive fifo - byte 3 23-16 data lane at output stage of receive fifo - byte 2 15-08 data lane at output stage of receive fifo - byte 1 07-00 data lane at output stage of receive fifo - byte 0 rxdata description name type condition after reset state function rdata 31 C 00 r u receive fifo output data register name: rxaddr register address: xxxx x018 bits function 31-24 address lane at output stage of receive fifo - byte 3 23-16 address lane at output stage of receive fifo - byte 2 15-08 address lane at output stage of receive fifo - byte 1 07-00 address lane at output stage of receive fifo - byte 0 rxaddr description name type condition after reset state function raddr 31 C 00 r u receive fifo output address, except during mul- tiplexed block data transfers in which case d63- d32 are provided here. upper address bits may be zeroed according to the size of slave image programmed that accepted the transfer. no zero- ing effect on the data received during mblt transfers.
registers scv64 user manual app a-14 tundra semiconductor corporation table a.13 : rxfifo control register (rxctl) register name: rxctl register address: xxxx 01c bits function 31-24 not used 23-16 not used 15-08 not used 0 07-00 0 blkst mblt blt siz1 siz0 spc1 spc0 rxctl description name type condition after reset state function blkst r u flags the start of a block in the fifo 0 this cycle is not the start of a block 1 this cycle is the start of a block mblt r u identifies the entry as being part of an mblt block 0 this cycle is not part of an mblt block 1 this cycle is part of an mblt block blt r u identifies the entry as being part of a blt block 0 this cycle is not part of a blt block 1 this cycle is part of a blt block siz0, 1 r u data size 0,0 longword 0,1 byte 1,0 word 1,1 tri-byte spc0, 1 r u receive fifo tc1, 0 output bits 0,0 user program space 0,1 user data space 1,0 supervisor program space 1,1 supervisor data space
scv64 user manual registers tundra semiconductor corporation app a-15 table a.14 : vmebus/vsb bus select (bussel) register name: bussel register address: xxxx x020 bits function 31-24 vsben (vmebus/vsb data transfer cycle routing bits) - byte 3 23-16 vsben (vmebus/vsb data transfer cycle routing bits) - byte 2 15-08 vsben (vmebus/vsb data transfer cycle routing bits) - byte 1 07-00 vsben (vmebus/vsb data transfer cycle routing bits) - byte 0 bussel description name type condition after reset state function vsben 31 C 00 r/w 0 vmebus/vsb select bits, one for each of the 32 by 128 mbyte pages (refer to address range map below) 0 vmebus selected 1 vsb selected bit address range mapped bit address range mapped 0 0000.0000 - 07ff.ffff 16 8000.0000 - 87ff.ffff 1 0800.0000 - 0fff.ffff 17 8800.0000 - 8fff.ffff 2 1000.0000 - 17ff.ffff 18 9000.0000 - 97ff.ffff 3 1800.0000 - 1fff.ffff 19 9800.0000 - 9fff.ffff 4 2000.0000 - 27ff.ffff 20 a000.0000 - a7ff.ffff 5 2800.0000 - 2fff.ffff 21 a800.0000 - afff.ffff 6 3000.0000 - 37ff.ffff 22 b000.0000 - b7ff.ffff 7 3800.0000 - 3fff.ffff 23 b800.0000 - bfff.ffff 8 4000.0000 - 47ff.ffff 24 c000.0000 - c7ff.ffff 9 4800.0000 - 4fff.ffff 25 c800.0000 - cfff.ffff 10 5000.0000 - 57ff.ffff 26 d000.0000 - d7ff.ffff 11 5800.0000 - 5fff.ffff 27 d800.0000 - dfff.ffff 12 6000.0000 - 67ff.ffff 28 e000.0000 - e7ff.ffff 13 6800.0000 - 6fff.ffff 29 e800.0000 - efff.ffff 14 7000.0000 - 77ff.ffff 30 f000.0000 - f7ff.ffff 15 7800.0000 - 7fff.ffff 31 f800.0000 - ffff.ffff
registers scv64 user manual app a-16 tundra semiconductor corporation table a.15 : vmebus interrupter vector (ivect) register name: ivect register address: xxxx x024 bits function 31-24 not used 23-16 not used 15-08 not used 07-00 ivect (interrupt vector) ivect description name type condition after reset state function ivect 07 C 00 r/w u vmebus interrupt vector bits
scv64 user manual registers tundra semiconductor corporation app a-17 table a.16 : access protect boundary register (apbr) register name: apbr register address: xxxx x028 bits function 31-24 not used 23-16 not used 15-08 not used 07-00 not used apb03 apb02 apb01 apb00 apbr description name type condition after reset state function apb03 C 00 r/w 0 access protection boundary; protection enforced below 0 no protection 1 lower 64 kb 2 lower 128 kb 3 lower 256 kb 4 lower 512 kb 5 lower 1 mb 6 lower 2 mb 7 lower 4 mb 8 lower 8 mb 9 lower 16 mb a lower 32 mb b lower 64 mb c entire 128 mb d entire 128 mb e entire 128 mb f entire 128 mb
registers scv64 user manual app a-18 tundra semiconductor corporation table a.17 : txfifo data output latch register (txdata) table a.18 : txfifo address output latch register (txaddr) register name: txdata register address: xxxx x02c bits function 31-24 lm (data at output stage of location monitor fifo) - byte 3 23-16 lm (data at output stage of location monitor fifo) - byte 2 15-08 lm (data at output stage of location monitor fifo) - byte 1 07-00 lm (data at output stage of location monitor fifo) - byte 0 txdata description name type condition after reset state function tdata 31 C 00 r u data at transmit fifo data lane output stage. during d64 cycles this will be d31 C d00. register name: txaddr register address: xxxx x030 bits function 31-24 address lane at output stage of transmit fifo - byte 3 23-16 address lane at output stage of transmit fifo - byte 2 15-08 address lane at output stage of transmit fifo - byte1 07-00 address lane at output stage of transmit fifo - byte0 txaddr description name type condition after reset state function taddr 31 C 00 r u address at transmit fifo stage for discrete or non-block dma transfers. d63 C d32 data dur- ing multiplexed block transfers.
scv64 user manual registers tundra semiconductor corporation app a-19 table a.19 : transmit fifo am code and control bit latch (txctl) register name: txctl register address: xxxx x034 bits function 31-24 not used 23-16 not used 15-08 not used 07-00 mblt blt siz1 siz0 spc1 spc0 super type txctl description name type condition after reset state function mblt r u mblt transfer type flag 0 this transfer is not part of an mblt block 1 this transfer is part of an mblt block blt r u blt transfer type flag 0 this transfer is not part of a blt block 1 this transfer is part of a blt block siz0-1 r u transfer size 0,0 longword 0,1 byte 1,0 word 1,1 tri-byte spc0-1 r u address space 0,0 a32 0,1 reserved 1,0 a16 1,1 a24 super r u privilege level of transfer 0 user (non privileged) 1 supervisor type r u data type is cpu transfer: 0 program 1 data data type is dma transfer: 0 mblt 1 blt or non-block
registers scv64 user manual app a-20 tundra semiconductor corporation table a.20 : location monitor fifo read port (lmfifo) register name: lmfifo register address: xxxx x038 bits function 31-24 lm (location monitor fifo output stage data) - byte 3 23-16 lm (location monitor fifo output stage data) - byte 2 15-08 lm (location monitor fifo output stage data) - byte 1 07-00 lm (location monitor fifo output stage data) - byte 0 lmfifo description name type condition after reset state function lm 31 C 00 r u data at output stage of location monitor fifo
scv64 user manual registers tundra semiconductor corporation app a-21 table a.21 : mode control (mode) register name: mode register address xxxx x03c bits function 31-24 dctsiz reserved rmcretry dmaben rmcpin bussiz swap 0 23-16 dpriv norel fill dma64 mblt blt dmad16 dmard 15-08 fifoben blen (2 bits) rxatom txatom a24slven dma24 berrchk 07-00 tascon a24po lpbk disrx a24di a16di prot vinen mode description name type condition after reset state function dtcsiz r/w 0 sets the dma transfer count size 0 12 bit transfer count (4k) 1 20 bit transfer count (1 m) rmcretry r/w 0 response to a rmw cycle deadlock 0 indivisible (rmw) cycles that encounter deadlock conditions are terminated with . 1 indivisible (rmw) cycles that encounter deadlock conditions are terminated with and . dmaben r/w 0 dma local bus burst enable 0 burst mode disabled for dma 1 burst mode enabled for dma rmcpin r/w 0 rmc pin configuration 0 retry/vrmc pin in vrmc mode 1 retry/vrmc pin is in retry mode bussiz r/w 0 dynamic bus sizing request enable 0 enable sizing requests to cpu, implement d16 spaces, disable uat cycles 1 disable sizing requests to cpu, set vmebus to all d32, enable uat cycles swap r/w 0 word swap enable 0 disable word swapping 1 enable word swapping dpriv r/w 0 dmac privilege type for vmebus cycles 0 dmac uses non-privileged am codes 1 dmac uses supervisory am codes kberr kberr khalt
registers scv64 user manual app a-22 tundra semiconductor corporation norel r/w 0 vmebus no-release mode 0 scv64 will release vmebus when done 1 scv64 will maintain vmebus ownership until forced off fill r/w 0 transmit fifo fill mode 0 request vmebus when any entries are in the fifo 1 if dma is running, wait for fifo full before request- ing vmebus. if dma is not running, same as fill = 0 dmaa64 r/w 0 a64 mode control for the dma 0 dmac does not use a64 mode 1 dma uses a64 mode and master a64 base addr reg mblt r/w 0 multiplexed block transfer mode dmac control 0 dmac does not use mblt mode 1 dmac uses mblt mode blt r/w 0 non-multiplexed block transfer mode control for dmac 0 dmac does not use blt mode 1 dmac uses blt mode dmad16 r/w 0 data size for dmac in non-block and blt block modes 0 dmac uses d32 transfers 1 dmac uses d16 transfers dmard r/w 0 dmac read or write mode 0 dmac transfers from local memory to vmebus 1 dmac transfers from vmebus into local memory fifoben r/w 0 receive fifo burst enable 0 disable burst mode for receive fifo 1 enable burst mode for receive fifo blen 1-0 r/w 0 local bus maximum burst length 0 4longwords 1 8longwords 2 16longwords 3 32longwords rxatom r/w 0 receive fifo coupled and decoupled 0 rx fifos used in decoupled mode 1 rx fifos bypassed (coupled mode) mode description (continued) name type condition after reset state function
scv64 user manual registers tundra semiconductor corporation app a-23 txatom r/w 0 transmit fifo coupled and decoupled 0 tx fifos used in decoupled mode 1 tx fifos bypassed (coupled mode) a24slven r/w 0 a24 slave image enable 0 image will not respond 1 image is enabled dma24 r/w 0 dma destination address size 0 dma operates as a32 master 1 dma operates as a24 master berrchk r/w 0 local late bus error enable 0 no extra delay inserted. 1 2clock local delay inserted to check for late berr from ram ta s co n r/w 0 as* modifier for rmw cycles 0 as* negated between every vmebus cycle 1 as* not negated between cycles while cpu rmc is asserted a24po r/w 0 vmebus a24 space address 0 a24 space located at f800.0000 1 a24 space located at 0000.0000 lpbk r/w 0 loopback enable bit 0 no loopback 1 loopback through fifos enabled disrx r/w 0 receive fifo disable bit 0 normal operation 1 fifo emptied by rxshft control bit only a24di r/w 0 page 0 vmebus a24 disable bit 0 a24 responds per a24p0 bit 1 a24 disabled if in page 0 a16di r/w 0 vmebus a16 disable bit 0 vmebus a16 located at ffff.0000 1 a16 space disabled prot r/w 0 access protection type 0 write protection only 1 read and write protection mode description (continued) name type condition after reset state function
registers scv64 user manual app a-24 tundra semiconductor corporation caution: the rxatom bit in the mode register should not be modified by the local cpu while there is the possibility of an incoming vmebus slave cycle since the scv64 may not be able to decode the incoming cycle. if you need to modify the rxatom bit when there is the possibility of an incoming vmebus slave cycle, have the scv64 obtain and hold the vmebus before changing the bit, as follows: ? clear the oten and bcen bits in the vreq register. ? set the norel bit in the mode register. ? have the local cpu perform a read of vme memory (forces the scv64 to obtain the vme bus). ? change the status of the rxatom bit in the mode register ? clear the norel bit in the mode register ? restore the oten and bcen bits to their original state. if a vme host would like to program a slave scv64 board into coupled mode (i.e. rxatom changing from 0 to 1), then a vme read of any resource on the same slave board should immediately follow the vme write cycle. the read cycle forces the write to the mode register to complete on the local bus and therefore the rxatom bit to be changed without any adverse effects. the vme host must maintain ownership of the vmebus between the write and read cycles. vinen r/w 0 slave images enabling r 0 all slave images are disabled r 1 all programmed images enabled w 0 disable all slave images w 1 enable all programmed images mode description (continued) name type condition after reset state function !
scv64 user manual registers tundra semiconductor corporation app a-25 table a.22 : slave a64 base address register (sa64bar) sa64bar can only be programmed from the vmebus by using a coupled cycle (see coupled mode on page 2-39). register name: sa64bar register address: xxxx040 bits function 31-24 a63 - a56 address bits for slave a64 base address 23-16 a55 - a48 address bits for slave a64 base address 15-08 a47 - a40 address bits for slave a64 base address 07-00 a39 - a32 address bits for slave a64 base address sa64bar description name type condition after reset state function sa64b31 C 00 r/w u x this parameter defines the base address for slave a64 accesses.
registers scv64 user manual app a-26 tundra semiconductor corporation table a.23 : master a64 base address register (ma64bar) ma64bar can only be programmed from the vmebus by using a coupled cycle (see coupled mode on page 2-39). table a.24 : local address generator (lag) register name: ma64bar register address: xxxx x044 bits function 31-24 a63 - a56 address bits for master a64 base address 23-16 a55 - a48 address bits for master a64 base address 15-08 a47 - a40 address bits for master a64 base address 07-00 a39 - a32 address bits for master a64 base address ma64bar description name type condition after reset state function ma64b31 C 00 r/w u x a64 - a32 address bits during master a64 dma transfers register name: lag register address: xxxx x048 bits function 31-24 not used (5 bits) local address generator value 23-16 local address generator value 15-08 local address generator value 07-00 local address generator value (total 27 bits) lag description name type condition after reset state function lag26 C 00 r u x this is the next local address to be used in block mode transfers received from the vmebus, either as a slave or by dmac transfers from the vme- bus to local memory.
scv64 user manual registers tundra semiconductor corporation app a-27 table a.25 : dma vmebus transfer count (dmavtc) register name: dmavtc register address: xxxx x04c bits function 31-24 not used 23-16 not used dma vmebus transfer count 15-08 dma vmebus transfer count 07-00 dma vmebus transfer count (total 20 bits) dmavtc description name type condition after reset state function dmavtc19-00 r u 0 the number of vmebus cycles remaining to per- form in the blt or non-block dma transfer. if an mblt transfer is being performed then the number of cycles remaining is half the value read from this register.
registers scv64 user manual app a-28 tundra semiconductor corporation table a.26 : status register 0 (stat0) register name: stat0 register address: xxxx x080 bits function 07-00 clrdog clrtik lto vi1 syfip acfip memip nmiip stat0 description name type condition after reset state function clrdog r/w 0 watchdog clear and restart w0 no effect w1 if 0 before write, resets; if 1 before write, no effect clrtik r/w 0 clear tick signal r always reads as zero w 0 tick pin cleared to high w 1 no effect lto r/w 0 local bus timed out flag r 0 no time-out has occurred r 1 local bus time-out occurred w 0 clears lto bit (does not reset counter) w 1 no effect vi1 r x vmebus irq1* (bi-mode line) 0 irq1* is not asserted 1 irq1* is asserted syfip r 1 sysfail* pin 0 pin is not asserted 1 pin is asserted acfip r x interrupt pin 0 pin is not asserted 1 pin is asserted memip r x interrupt pin 0 pin is not asserted 1 pin is asserted nmiip r x interrupt pin 0 pin is not asserted 1 pin is asserted l7iacf l7imem l7inmi
scv64 user manual registers tundra semiconductor corporation app a-29 table a.27 : status register 1 (stat1) register name: stat1 register address: xxxx x084 bits function 07-00 1 0 sysc bi pwrup idgot bg2in bg1in stat1 description name type condition after reset state function sysc r/w x vmebus syscon mode bit r0 scv64 is not syscon r1 scv64 is syscon w0 scv64 ceases to be syscon w1 scv64 becomes syscon bi r 1 bi-mode indicator 0 scv64 is not in bi-mode 1 scv64 is in bi-mode pwrup r x power-up indicator 0 last reset was not by power up 1 last reset was due to power up idgot r x auto-id completion indicator 0 auto-id cycle not done yet 1 auto-id cycle completed bg2in r x bus grant 2 in pin 0 bg2in* is low or scv64 isnt syscon 1 bg2in* is high and scv64 is syscon bg1in r x bus grant 1 in pin 0 bg1in* is low or scv64 isnt syscon 1 bg1in* is high and scv64 is syscon
registers scv64 user manual app a-30 tundra semiconductor corporation table a.28 : general control register (genctl) register name: genctl register address: xxxx x088 bits function 07-00 swrst abi sbi tlen1 tlen0 ltoen idtst vi1bi genctl description name type condition after reset state function swrst r/w 0 software initiated system reset 0 no effect 1 initiates reset abi r/w 0 assert bi-mode line (irq1*) 0 de-assert irq1* 1 assert irq1* sbi r/w 0 self bi-mode control bit 0 de-assert software bi-mode trigger 1 set self into bi-mode tlen1 r/w 3 tick timer length code tlen0 norm fast 0 5 ms 0.2 ms 1 10 ms 0.4 ms 2 50 ms 2 ms 3 100 ms 4 ms lto en r/w 1 local bus time-out enable 0 disable time-out 1 enable time-out (512 s) idtst r/w 0 auto-id test bit w 0 no effect w 1 if previously 0, increment id w 1 if previously 1, no effect vi1bi r/w 1 irq1* configuration control bit 0 irq1* as interrupt only 1 irq1* as bi-mode line only
scv64 user manual registers tundra semiconductor corporation app a-31 table a.29 : vmebus interrupter requester (vint) caution: changing the interrupt level while int is state 1 may cause improper operation in the iack dcd logic. register name: vint register address: xxxx x08c bits function 07-000000intil2il1il0 vint description name type condition after reset state function int r/w 0 interrupt control and status bit r 0 no interrupt is pending r 1 interrupt is presently asserted w 0 no effect; does not change to 0 w 1 assert interrupt il2 r/w 0 interrupt level il1 0 interrupter clears itself il0 1-7 sets interrupt level !
registers scv64 user manual app a-32 tundra semiconductor corporation table a.30 : vmebus requester register (vreq) register name: vreq register address: xxxx x090 bits function 07-00 oten bcen rel req ot1 ot0 lvl1 lvl0 vreq description name type condition after reset state function oten r/w 1 vmebus ownership timer enable 0 disable timer 1 enable timer bcen r/w 0 bus clear recognition control 0 ignore bclr* signal 1 release bus if bclr* asserted rel r/w 1 vmebus release mode control 0 release on request (ror) 1 release when done (rwd) req r/w 1 vmebus request mode control 0 fair 1 demand ot1 r/w 3 vmebus ownership timer (time-out period) ot0 0 zero 1 2 s 2 4 s 3 8 s lv l 1 r/w 3 vmebus request level lv l 0 0 level 0 1 level 1 2 level 2 3 level 3
scv64 user manual registers tundra semiconductor corporation app a-33 table a.31 : vmebus arbiter register (varb) register name: varb register address: xxxx x094 bits function 07-00 0 0 vxl1 vxl0 0 aten arb1 arb0 varb description name type condition after reset state function vxl1 r/w 3 data transfer time-out period vxl0 0 never 1 16 s 2 32 s 3 64 s at e n r/w 1 arbitration time-out enable 0 disable arbitration time-out 1 enable arbitration time-out arb1 r/w 0 arbitration mode arb0 0 round robin all four levels 1 priority 3, round robin 2, 1, 0 2 priority 3, 2, round robin 1, 0 3 priority on all four levels
registers scv64 user manual app a-34 tundra semiconductor corporation table a.32 : id register (id) caution: if a read of the auto-id register is the first cycle which occurs on the scv64s local bus after the id cycle completes, then an incorrect value will be returned. the user must ensure that a register access (read or write, from either interface) is made to any of the other scv64 registers before this register is accessed. register name: id register address: xxxx x098 bits function 07-00 id7 id6 id5 id4 id3 id2 id1 id0 id description name type condition after reset state function id r 0 auto-id card slot id n value of id counter !
scv64 user manual registers tundra semiconductor corporation app a-35 table a.33 : control and status register (ctl2) register name: ctl2 register address: xxxx x09c bits function 07-00 0 0 mybbsy bitrig 0 lbram memim tickm ctl2 description name type condition after reset state function mybbsy r 0 scv64 bbsy* output 0 bbsy* is not asserted 1 bbsy* is driven low bitrig r u bi-mode trigger 0 bitrig is not asserted 1 bitrig is asserted lbram r/w 0 local bus requester mode 0 channels 0 and 1 fair 1 channel 1 pre-empts channel 0 memim r/w 1 effect on requester 0 does not affect requester 1 forces requester to release vmebus tickm r/w 0 tick speed 0 normal rates 1 fast rates l7imem l7imem l7imem
registers scv64 user manual app a-36 tundra semiconductor corporation table a.34 : level 7 interrupt status register (7is) note: the bits in this status register represent the current state of the interrupt latches corresponding to the five interrupts. the interrupt inputs themselves can be read through status register 0. the initial state of nmiis is dependent on the circuit card design. register name: 7is register address: xxxx x0a0 bits function 07-00 0 0 0 bis syfis acfis memis nmiis 7is description name type condition after reset state function bis r x bi-mode interrupt 0 interrupt is not asserted 1 interrupt is asserted syfis r 0 sysfail* pin interrupt 0 interrupt is not asserted 1 interrupt is asserted acfis r 0 pin interrupt 0 interrupt is not asserted 1 interrupt is asserted memis r 0 pin interrupt 0 interrupt is not asserted 1 interrupt is asserted nmiis r (note) pin interrupt 0 interrupt is not asserted 1 interrupt is asserted l7iacf l7imem l7inmi
scv64 user manual registers tundra semiconductor corporation app a-37 table a.35 : local interrupt status register (lis) register name: lis register address: xxxx x0a4 bits function 07-00 0 0 li5 li4 li3 li2 li1 li0 lis description name type condition after reset state function li5 r x local interrupt five () 0 pin is not asserted 1 interrupt pin is asserted li4 r x local interrupt four ( ) 0 pin is not asserted 1 interrupt pin is asserted li3 r x local interrupt three ( ) 0 pin is not asserted 1 interrupt pin is asserted li2 r x local interrupt two ( ) 0 pin is not asserted 1 interrupt pin is asserted li1 r x local interrupt one ( ) 0 pin is not asserted 1 interrupt pin is asserted li0 r x local interrupt zero ( ) 0 pin is not asserted 1 interrupt pin is asserted lirq5 lirq5 lirq4 lirq4 lirq3 lirq3 lirq2 lirq2 lirq1 lirq1 lirq0 lirq0
registers scv64 user manual app a-38 tundra semiconductor corporation table a.36 : level 7 interrupt enable register (7ie) register name: 7ie register address: xxxx x0a8 bits function 07-00 0 0 0 bie syfie acfie memie nmiclr 7ie description name type condition after reset state function bie r/w 0 bi-mode interrupt enable 0 disable interrupt 1 enable interrupt syfie r/w 0 sysfail* pin interrupt enable 0 disable interrupt 1 enable interrupt acfie r/w 0 pin interrupt enable 0 disable interrupt 1 enable interrupt memie r/w 0 pin interrupt enable 0 disable interrupt 1 enable interrupt nmiclr r/w 1 pin interrupt clear r always reads one w 0 clear interrupt; remains enabled w 1 no effect; always enabled l7iacf l7imem l7inmi
scv64 user manual registers tundra semiconductor corporation app a-39 table a.37 : local interrupt enable register (lie) register name: lie register address: xxxx x0ac bits function 07-00 0 0 l5e l4e l3e l2e l1e l0e lie description name type condition after reset state function l5e r/w 0 local interrupt 5 ( ) enable 0 disable interrupt 1 enable interrupt l4e r/w 0 local interrupt 4 ( ) enable 0 disable interrupt 1 enable interrupt l3e r/w 0 local interrupt 3 ( ) enable 0 disable interrupt 1 enable interrupt l2e r/w 0 local interrupt 2 ( ) enable 0 disable interrupt 1 enable interrupt l1e r/w 0 local interrupt 1 ( ) enable 0 disable interrupt 1 enable interrupt l0e r/w 0 local interrupt 0 ( ) enable 0 disable interrupt 1 enable interrupt lirq5 lirq4 lirq3 lirq2 lirq1 lirq0
registers scv64 user manual app a-40 tundra semiconductor corporation table a.38 : vmebus interrupt enable register (vie) register name: vie register address: xxxx x0b0 bits function 07-00 0 v7e v6e v5e v4e v3e v2e v1e vie description name type condition after reset state function v7e r/w 0 vmebus interrupt 7 enable 0 interrupt disabled 1 interrupt enabled v6e r/w 0 vmebus interrupt 6 enable 0 interrupt disabled 1 interrupt enabled v5e r/w 0 vmebus interrupt 5 enable 0 interrupt disabled 1 interrupt enabled v4e r/w 0 vmebus interrupt 4 enable 0 interrupt disabled 1 interrupt enabled v3e r/w 0 vmebus interrupt 3 enable 0 interrupt disabled 1 interrupt enabled v2e r/w 0 vmebus interrupt 2 enable 0 interrupt disabled 1 interrupt enabled v1e r/w 0 vmebus interrupt 1 enable 0 interrupt disabled 1 interrupt enabled
scv64 user manual registers tundra semiconductor corporation app a-41 table a.39 : local interrupts 1 and 0 control register (ic10) table a.40 : local interrupts 3 and 2 control register (ic32) register name: ic10 register: xxxx x0b4 bits function 07-00 1 1l2 1l1 1l0 1 0l2 0l1 0l0 ic10 description name type condition after reset state function 1l2 r/w 0 local interrupt 1 ( ) level 1l1 0 masks interrupt 1l0 1-7 maps pin to level 1-7 0l2 r/w 0 local interrupt 0 ( ) level 0l1 0 masks interrupt 0l0 1-7 maps pin to level 1-7 register name: ic32 register address: xxxx x0b8 bits function 07-00 1 3l2 3l1 3l0 1 2l2 2l1 2l0 ic32 description name type condition after reset state function 3l2 r/w 0 local interrupt 3 ( ) level 3l1 0 masks interrupt 3l0 1-7 maps pin to level 1-7 2l2 r/w 0 local interrupt 2 ( ) level 2l1 0 masks interrupt 2l0 1-7 maps pin to level 1-7 lirq1 lirq0 lirq3 lirq2
registers scv64 user manual app a-42 tundra semiconductor corporation table a.41 : local interrupts 5 and 4 control register (ic54) register name: ic54 register address: xxxx x0bc bits function 07-00 5av 5l2 5l1 5l0 4av 4l2 4l1 4l0 ic54 description name type condition after reset state function 5av rw 0 local interrupt 5 ( ) vector 0 vectored 1 auto-vectored 5l2 r/w 0 local interrupt 5 ( ) level 5l1 0 masks interrupt 5l0 1-7 maps pin to level 1-7 4av r/w 0 local interrupt 4 ( ) vector 0 vectored 1 autovectored 4l2 r/w 0 local interrupt 4 ( ) level 4l1 0 masks interrupt 4l0 1-7 maps pin to level 1-7 lirq5 lirq5 lirq4 lirq4
scv64 user manual registers tundra semiconductor corporation app a-43 table a.42 : miscellaneous control register (misc) register name: misc register address: xxxx x0c0 bits function 31-24 reserved 23-16 reserved 15-08 reserved extkiack arbbyp autobar 07-00 reserved endog sysfail misc description name type condition after reset state function extkiack r configurable 0 1 internal kiack decode external kiack decode arbbyp r configurable 0 1 local arbiter active local arbiter bypassed autobar r configurable 0 1 autobar disabled autobar enabled endog r/w 0 0 1 watchdog timer disabled watchdog timer enabled sysfail r/w 1 0 1 release sysfail* and assert sysfail* and sysfled sysfled
registers scv64 user manual app a-44 tundra semiconductor corporation table a.43 : delay line control register (dlct) caution: always write 0 to these bits. writing values other than 0 to this area will cause unpredictable scv64 operation. register name: dlct register address: xxxx x0c4 bits function 31-24 sel_40 offset_40 23-16 sel_30 offset_30 15-08 sel_20 offset_20 07-00 see caution below mkey key_20 key_30 key_40 dlct description name type condition after reset state function sel_40 r/w 0 0 1 add offset to calibrated value only use offset value offset_40 r/w 0 3f 00 40 calibrated value + 3f taps calibrated value + 0 taps calibrated value - 40 taps sel_30 r/w 0 0 1 add offset to calibrated value only use offset value offset_30 r/w 0 3f 00 40 calibrated value + 3f taps calibrated value + 0 taps calibrated value -40 taps sel_20 r/w 0 0 1 add offset to calibrated value only use offset value offset_20 r/w 0 3f 00 40 calibrated value + 3f taps calibrated value + 0 taps calibrated value - 40 taps see caution below read and write 0 n/a user must write 0 mkey r/w 1 0 1 permanently disables writes to keys until next . enable writes to keys key_20 r/w 1 0 1 disables writes to offset_20 field enables writes to offset_20 field key_30 r/w 1 0 1 disables writes to offset_30 field enables writes to offset_30 field key_40 r/w 1 0 1 disables writes to offset_40 field enables writes to offset_40 field lrst !
scv64 user manual registers tundra semiconductor corporation app a-45 table a.44 : delay line status register 1 (dlst1) the cal fields in the dlst1 register will be updated to reflect their new values once the offset fields in the dlct register are programmed. register name: dlst1 register address: xxxx x0c8 bits function 31-24 reserved 23-16 reserved cal_40 15-08 reserved cal_30 07-00 reserved cal_20 name type condition after reset state function cal_40 r n/a n/a internal calibration target for 40ns delay line cal_30 r n/a n/a internal calibration target for 30ns delay line cal_20 r n/a n/a internal calibration target for 20ns delay line
registers scv64 user manual app a-46 tundra semiconductor corporation table a.45 : delay line status register 2 (dlst2) register name: dlst2 register address: xxxx x0cc bits function 31-24 reserved 23-16 reserved 15-08 c flag-30 act-30 07-00 c flag-20 act-20 name type condition after reset state function cflg_30 r n/a 0 1 30ns delay line not calibrated 30ns delay line calibrated cflg_20 r n/a 0 1 20ns delay line not calibrated 20ns delay line calibrated act_30 r n/a n/a actual selected tap for 30ns delay lines act_20 r n/a n/a actual selected tap for 20ns delay lines
scv64 user manual registers tundra semiconductor corporation app a-47 table a.46 : delay line status register 3 (dlst3) ) register name: dlst3 register address: xxxx x0d0 bits function 31-24 reserved 23-16 cflg_40_3 act_40_3 15-08 cflg_40_2 act_40_2 07-00 cflg_40_1 act_40_1 name type condition after reset state function cflg_40_3 r n/a 0 1 40_3 ns delay line not calibrated 40_3 ns delay line calibrated cflg_40_2 r n/a 0 1 40_2 ns delay line not calibrated 40_2 ns delay line calibrated cflg_40_1 r n/a 0 1 40_1 ns delay line not calibrated 40_1 ns delay line calibrated act_40_3 r n/a n/a actual tap offset for 40 ns delay line 3 act_40_2 r n/a n/a actual tap offset for 40 ns delay line 2 act_40_1 r n/a n/a actual tap offset for 40 ns delay line 1
registers scv64 user manual app a-48 tundra semiconductor corporation table a.47 : mailbox register 0 (mbox0) table a.48 : mailbox register 1 (mbox1) table a.49 : mailbox register 2 (mbox2) table a.50 : mailbox register 3 (mbox3) register name: mbox0 register address: xxxx x0d4 bits function 31-24 user defined 23-16 15-08 07-00 register name: mbox1 register address: xxxx x0d8 bits function 31-24 user defined 23-16 15-08 07-00 register name: mbox2 register address: xxxx x0dc bits function 31-24 user defined 23-16 15-08 07-00 register name: mbox3 register address: xxxx x0e0 bits function 31-24 user defined 23-16 15-08 07-00
vmebus interface componentsscv64 user manual tundra semiconductor corporation app b-1 appendix b scv64 timing characteristics b.1 timing parameters test conditions for the timing parameters in table b.1 are: commercial (com) 0c to 70c, 5v 0.25v, and extended (ext) -55c to 125c, 5v 0.5v. table b.1 : scv64 ac characteristics timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max C kclk frequency (note 29) 20 33 20 40 25 mhz t 10 c32mhz high time (note 10) 10 C 10 C C ns t 11 c32mhz low time (note 10) 10 C 10 C C ns t 12 kclk high time note: extended at 25 mhz is a minimum 15.5 ns 14.5 C 12.0 C C ns t 13 kclk low time note: extended at 25 mhz is a minimum 16.5 ns 14.5 C 12.0 C C ns t 14 c32mhz, kclk fall time C5C5 5 ns t 15 c32mhz, kclk rise time C5C5 5 ns t 16 kclk to c14us low 5 17 5 14 19 ns t 17 kclk to c14us high 5 18 5 15 20 ns t 18 c14us low time 6.99 7.01 6.99 7.01 7.01 s t 19 c14us high time 6.99 7.01 6.99 7.01 7.01 s t 20 c14us period 14 14 14 14 14 s t 21 c32mhz to sysclk high 3103 8 11 ns t 22 c32mhz to sysclk low 3113 9 12 ns t 23 sysclk high time 31 33 31 33 33 ns t 24 sysclk low time 30 30 30 30 31 ns * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value
scv64 timing characteristics scv64 user manual app b-2 tundra semiconductor corporation t 25 sysclk period (note 1) 62.5 62.5 62.5 62.5 62.5 ns t 26 c32mhz to c8mhz high 4 13 4 11 14 ns t 27 c32mhz to c8mhz low 4 13 4 11 14 ns t 28 c8mhz high time 62.3 62.5 62.3 62.5 62.4 ns t 29 c8mhz low time 62.3 62.4 62.3 62.4 62.5 ns t 30 c8mhz period (note 1) 124.8 124.8 124.8 124.8 124.8 ns t 31 c32mhz to baudclk high 4 13 4 11 14 ns t 32 c32mhz to baudclk low 4 12 4 10 13 ns t 33 baudclk high time 186 187 186 187 187 ns t 34 baudclk low time 218 220 218 220 220 ns t 35 baudclk period (note 1) 406 406 406 406 406 ns t 36 low time 2222 2 s t 38 asserted to high 4 13 4 11 14 ns t 39 asserted to high 9 27 9 22 30 ns t 45 bg0in* asserted to sysrst* (when syscon) (note 1) 56 70 56 70 70 ms t 46 bg0in* minimum low time (note 1) 84 C 84 C C ms t 50 change from asserted 6 26 6 21 27 ns t 51 change from asserted (notes 1 and 7) 66 83 66 80 85 ns t 52 change from sysfail* asserted (notes 1 and 7) 66 83 66 80 85 ns t 53 change from irqn* asserted 4 17 4 14 19 ns t 54 change from kclk (unmasking interrupt) 9 31 9 25 34 ns t 55 sysrst* minimum assertion time (note 1, 15) 224 238 224 238 238 ms t 56 minimum assertion time (note 1) 62 94 62 94 94 ns t 57 sysfail* minimum assertion time (note 1) 62 94 62 94 94 ns t 58 minimum low time 50 C 50 C C ns t 59 minimum low time 50 C 50 C C ns t 60 asserted from start of s5 (lm write) 8 26 8 21 29 ns t 61 negated from negated (lm fifo read) 7 25 7 20 27 ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value wdog pwrrst wdog lrst wdog kipl lirqn kipl l 7 ixxx kipl kipl kipl l 7 ixxx pwrrst extrst lmint lmint kas
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-3 t 62 bimode negated from kclk (lm write) 6 21 6 17 23 ns t 70 asserted from kclk 5 18 5 14 20 ns t 71 negated from (notes 4 and 6) 0 16 0 13 17 ns t 72 asserted from kclk 6 19 6 16 21 ns t 73 negated from (notes 4 and 6) 0 17 0 14 19 ns t 74 negated from negated (notes 4, 6) 4 14 4 12 16 ns t 75 negated from negated (notes 4, 6) 5 16 5 13 17 ns t 76 negated from (note 5) 5 16 5 13 17 ns t 77 negated from (note 5) 6 19 6 16 21 ns t 78 negated from negated 4 18 4 15 20 ns t 79 negated from negated 4 19 4 16 21 ns t 81 setup to kclk 10C8C C ns t 85 sysrst asserted from asserted 5 16 5 13 18 ns t 86 asserted from asserted 6 20 6 16 22 ns t 87 to asserted 6 18 6 15 20 ns t 88 sysrst* asserted to asserted (note 14) 6 18 6 15 20 ns t 89 bimode asserted from asserted (note 14) 1615 7 ns t 95 held low from v dd stable (v dd = 4.5v) 100 C 100 C C ns t 97 bg3in* hold from negated (note 1) 750 C 750 C C ns t 98 bg3in* hold from sysrst* 20 C 20 C C ns t 99 kfc, , kdata hold from negated 25 C 25 C C ns t 100 setup to end of s2 11C9C C ns t 101 hold from 9C8C C ns t 103 setup to (notes 31 and 34) -(2t-5) C -(2t-5) C C ns t 105 kaddr, kfc, ksize setup to kclk 12 C 10 C C ns t 106 kaddr, ksize hold from kclk 0C0C C ns t 107 kaddr, ksize hold from 0C0C C ns t 108 kdata setup to kclk 5C3C C ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value liackn liackn kds kavec kavec kds liackn kiack kavec kiack liackn kas kavec kas liackn lirqn kavec lirqn kiack pwrrst lrst pwrrst extrst lrst lrst lrst pwrrst pwrrst kgback pwrrst scv 64 sel scv 64 sel kas scv 64 sel kas kas
scv64 timing characteristics scv64 user manual app b-4 tundra semiconductor corporation t 109 kdata hold from kclk 12C9C C ns t 111 held high from end of s0 5C4C C ns t 112 , setup to kclk 5C4C C ns t 113 , hold from kclk 7C6C C ns t 116 setup to kclk 2C2C C ns t 117 hold from or 10C8C C ns t 118 hold from kclk 5C4C C ns t 120 asserted from end of s2 0 31 0 25 34 ns t 121 negated from kas negated 5 18 5 15 20 ns t 122 tri-state from kclk 0 34 0 28 37 ns t 123 asserted from end of s2 8 31 8 25 34 ns t 124 negated from negated 7 25 7 20 28 ns t 125 tri-state from negated 10 32 10 26 35 ns t 127 asserted from end of s2 6 20 6 16 22 ns t 128 negated from end of s5 4 16 4 13 17 ns t 129 tri-state from negated 5 16 5 13 18 ns t 130 kdata driven from end of s2 8 32 8 26 35 ns t 131 kdata valid from end of s2 8 32 8 26 35 ns t 136 negated to kdata invalid (note 2) 0 31 0 25 33 ns t 137 negated to kdata tri-state (note 2) 0 31 0 25 34 ns t 138 kdata invalid from end of s5 (note 2) 3 29 3 24 31 ns t 139 kdata released from end of s5 (note 2) 4 29 4 24 32 ns t 144 setup to kclk 10C8C C ns t 145 hold from 10C8C C ns t 147 asynchronous setup to kclk 0C0C C ns t 148 hold from 0C0C C ns t 150 timer cleared, reset from start of s3 6 20 6 16 22 ns t 152 asserted from start of s3 (swrst bit) 10 31 10 25 34 ns t 153 bimode asserted from start of s3 (sbi) 8 26 8 21 29 ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value kas kas kds kas kds kwr kwr kas kds kwr kdsack kdsack kdsack kberr kberr kas kberr kberr khalt khalt khalt khalt kas kas vmeout vmeout kas krmc krmc kdsackx tick lrst
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-5 t 154 sysrst* asserted from start of s3 (swrst bit) 9 27 9 22 30 ns t 157 negated from kclk 5 16 5 13 18 ns t 159 irq1* asserted from start of s3 (abi bit) 8 25 8 21 27 ns t 160 irq1* negated from start of s3 (abi bit) 10 32 10 26 35 ns t 161 asserted from kclk (cerr bit) 8 26 8 21 28 ns t 162 negated from kclk (cerr bit) 7 23 7 19 25 ns t 163 negated from kclk (clearing dma do) 5 18 5 15 19 ns t 164 sysfail asserted from kclk (sysfail bit) 6 21 6 17 22 ns t 165 asserted from kclk 4 15 4 12 17 ns t 166 sysfail negated from kclk 8 26 8 21 28 ns t 167 negated from kclk 5 16 5 13 18 ns t 168 sysfail asserted from kclk (swrst bit) 14 42 14 34 46 ns t 169 asserted from start of s3 (swrst bit) 12 36 12 29 40 ns t 170 dtack* to kdata driven 46 73 46 68 77 ns t 171 dtack* to kdata valid 46 73 46 68 78 ns t 172 dtack* to asserted 47 71 47 67 75 ns t 175 asserted from berr* asserted 11 35 11 28 39 ns t 180 kdata asynchronous setup to klck (coupled write) 0-0C - ns t 181 kdata hold from (coupled write) 0-0C - ns t 200 asserted from kclk 5 19 5 14 21 ns t 201 negated from kclk 5 17 5 12 19 ns t 202 asserted from asserted, kaddr valid 5 18 5 15 19 ns t 203 negated from negated, or kaddr invalid 4 15 4 12 16 ns t 204 driven from kclk 5 20 5 14 21 ns t 205 tri-state from kclk 10 33 10 24 37 ns t 206 negated from negated 5 16 5 13 17 ns t 210 kclk to kaddr, kfc, ksize driven 5 23 5 19 26 ns t 211 kclk to address valid 8 29 8 21 31 ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value lrst vmeint vmeint vmeint sysfled sysfled sysfled kdsackx kberr kdsackx ramsel ramsel vsbsel vmeout vsbsel vmeout kwr kwr ramsel kas
scv64 timing characteristics scv64 user manual app b-6 tundra semiconductor corporation t 212 kclk to address invalid 7 29 7 20 30 ns t 213 address invalid from negated 16 27 16 22 28 ns t 214 kaddr, kfc, ksize tri-state from kclk 8 25 8 20 28 ns t 215 address invalid from kclk 0C0C C ns t 218 asserted from kclk 6 21 6 17 22 ns t 219 negated from kclk 0C0C C ns t 220 kdata driven from start of s2 6 26 6 21 28 ns t 221 kdata valid from start of s2 6 26 6 21 29 ns t 222 kdata invalid from end of s5 8 27 8 22 30 ns t 223 kdata released from end of s5 8 28 8 23 30 ns t 225 negated to kdata released 17 26 17 21 27 ns t 230 asserted from kclk 6 19 6 14 21 ns t 231 negated from kclk 5 18 5 13 19 ns t 232 tri-state from kclk 10 33 10 27 36 ns t 233 , tri-state from kclk 4 33 4 27 36 ns t 235 asserted from kclk 4 14 4 10 15 ns t 236 negated from kclk 4 14 4 10 15 ns t 240 / setup kclk (note 3) 5C2C C ns t 241 / hold from kclk (note 3) 5C2C C ns t 242 hold from negated 5C4C C ns t 245 asserted to asserted 5C4C C ns t 248 late setup to kclk (note 12) 5C4C C ns t 249 late hold from kclk (note 12) 5C4C C ns t 250 kdata driven from start of s2 6 20 6 14 22 ns t 251 kdata valid from kclk 8 37 8 30 41 ns t 252 kdata invalid form kclk 10 36 10 27 39 ns t 253 kdata released from kclk 9 28 9 21 30 ns t 260 setup to kclk 5C4C C ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value kas krmc krmc kas kas kas kas kas kds kds kds kdsack kberr kdsack kberr kdsack kas kdsack kberr kberr kberr lbrq1
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-7 t 261 asserted from asserted 4 15 4 12 16 ns t 263 asserted from kclk 5 17 5 14 18 ns t 264 negated from kclk 5 15 5 12 17 ns t 265 asserted from kclk (scv64 request) 8 26 8 21 28 ns t 266 negated from kclk 7 23 7 19 25 ns t 268 setup to kclk (note 9) 5C4C C ns t 270 asserted from kclk (scv64 request - bypassed) (note 30) 5 16 4 13 17 ns t 271 negated from kclk (scv64 request - bypassed) (note 30) 5 16 4 13 17 ns t 272 setup to kclk (scv64 request - bypassed) (note 9) 5C4C C ns t 273 kclk to local bus driven (note 11) 0 23 0 19 26 ns t 274 kclk to local bus released (note 11) 0 33 0 27 36 ns t 275 asserted from kclk (scv64 request) 6 20 6 16 21 ns t 276 negated from kclk (scv64 request bypassed) 6 20 6 16 21 ns t 277 setup to kclk 5C4C C ns t 278 setup to kclk 5C4C C ns t 279 hold from kclk 5C4C C ns t 301 , , dtack*, berr*, iackin* asynchronous setup to c32mhz (note 16) 0C0C C ns t 302 iackout* asserted from c32mhz (note 16) 4 14 4 14 15 ns t 303 iackout* negated from negated 3 10 3 10 10 ns t 304 iack daisy chain delay (note 17) 77 108 77 108 109 ns t 308 bus grant daisy chain delay (assertion) (note 32) 4 13 4 13 15 ns t 309 bus grant daisy chain delay (negation) 4 14 4 14 15 ns t 310 brn* asserted from c32mhz 5 18 5 18 20 ns t 311 brn* negated from c32mhz (note 19) 7 23 7 23 25 ns t 312 bgnin* asynchronous setup to c32mhz 10 C 10 C C ns t 315 bbsy* asserted from c32mhz (note 18) 6 18 6 18 19 ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value kbrq lbrq1 lbgr1 lbgr1 kbrq kbrq kbgr kbrq kbrq kbgr kbgack kbgack kbgack kas kas vas vds vas
scv64 timing characteristics scv64 user manual app b-8 tundra semiconductor corporation t 316 bbsy* hold from bgnin* negated 31 C 31 C C ns t 317 bbsy* negated from c32mhz (note 20) 8 26 8 26 28 ns t 319 bclr* asynchronous setup to c32mhz 10 C 10 C C ns t 320 brn* asynchronous setup to c32mhz 10 C 10 C C ns t 321 bgnout* asserted from c32mhz (note 21) 5 18 5 18 18 ns t 322 bgnout* negated from c32mhz (note 22) 5 17 5 17 19 ns t 324 bbsy* asynchronous setup to c32mhz 10 C 10 C C ns t 325 bbsy* minimum assertion time (note 1) 73 C 73 C C ns t 328 bclr* asserted from c32mhz (note 23) 4 17 4 17 18 ns t 329 bclr* negated from c32mhz (note 24) 4 13 4 13 14 ns t 350 irqn* asserted from end of state 5 5 20 5 20 21 ns t 351 irqn* negated from c32mhz (note 27) 9 31 9 31 31 ns t 360 vaddout high from kclk 6 18 6 18 20 ns t 361 vstrbout high from kclk 6 18 6 18 20 ns t 362 vdatout high from kclk 4 15 4 15 16 ns t 363 kclk to vdatout high (a64 only) 7 23 7 23 25 ns t 364 vaddr, vam, released from vaddout low 0303 3 ns t 365 vstrbout low from negated 6 18 6 18 20 ns t 366 dtack* negated to vasout low (mblt) 11 33 11 33 36 ns t 367 vdata released from vdatout low 0303 3 ns t 369 vaddout low from 7 22 7 22 24 ns t 404 vaddr, vam, setup to 10 C 10 C C ns t 405 minimum high time 30 C 30 C C ns t 408 data setup to asserted (vaddr and vdata) 10 C 10 C C ns t 410 to skew -10 C -10 C C ns t 411 minimum high time 30 C 30 C C ns t 412 setup to asserted 10 C 10 C C ns t 413 skew C 20 C 20 20 ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value vlword vas vdsb vlword vas vas vdsa vas vds vds vwr vdsa vds
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-9 t 414 vaddr, hold from dtack* asserted 0C0C C ns t 416 vam hold from dtack* asserted 0C0C C ns t 418 hold from dtack* asserted 0C0C C ns t 420 hold from dtack* asserted 0C0C C ns t 421 hold from dtack* asserted 0C0C C ns t 422 data hold from dtack* asserted (vaddr & vdata) 0C0C C ns t 423 hold from negated 0C0C C ns t 428 scv64 slave response (note 28) 38 59 38 59 65 ns t 429 vdata invalid from negated 6 25 6 25 26 ns t 430 dtack* negated from negated 8 27 8 27 29 ns t 431 vdata invalid to dtack* negated 32 37 32 37 39 ns t 432 vaddr, vam, vlword* setup to 10 C 10 C C ns t 450 vdata valid from kclk rising (note 25) 5 16 5 16 17 ns t 451 dtack* asserted from kclk (note 26) 4 16 4 16 17 ns t 458 vaddr setup to asserted -10 C -10 C C ns t 480 dtack* negated from negated 40 61 40 61 64 ns t 481 berr* released from negated 6 20 6 20 22 ns t 490 vdata driven from kclk 5 21 5 21 23 ns t 491 vdata (and vaddr for mblt) valid from start of s5 6 23 6 23 26 ns t 493 dtack*, berr* asserted from end of s5 (note 28) 7 23 7 23 25 ns t 504 vaddr, , vam valid to asserted 26 37 26 37 39 ns t 505 minimum high time 39 50 39 50 53 ns t 508 vdata setup to asserted 33 35 33 35 36 ns t 509 dtack* negated to next asserted (writes) 7 23 7 23 25 ns t 510 to skew C6C6 6 ns t 511 minimum high time 49 67 49 67 72 ns t 513 skew 0101 1 ns t 514 vaddr, vlword* invalid from dtack* asserted (writes) 11 42 11 42 45 ns t 516 iack* negated from dtack* asserted 53 89 53 89 95 ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value vlword vas vdsa vdsb vwr vds vdsb vdsb vds vdsa vdsb vdsb vlword vas vas vdsa vds vas vds vds vds
scv64 timing characteristics scv64 user manual app b-10 tundra semiconductor corporation t 518 dtack* asserted to negated (writes) 7 23 7 23 25 ns t 519 minimum assertion time (writes) 44 59 44 59 65 ns t 520 negated from dtack* asserted (writes) 7 21 7 21 23 ns t 521 negated from dtack* asserted (writes) 7 23 7 23 25 ns t 522 data invalid from dtack* asserted 11 36 11 36 39 ns t 523 hold from negated 6 21 6 21 22 ns t 527 vdata setup to dtack* asserted -25 C -25 C C ns t 528 minimum slave response time 30 C 30 C C ns t 529 vdata hold from negated 0C0C C ns t 530 dtack* hold from negated 0C0C C ns t 533 low time 42 59 42 59 63 ns t 550 vaddr driven from kclk 5 16 5 16 17 ns t 552 driven from kclk 4 20 4 20 22 ns t 553 kclk to iack* asserted 10 32 10 32 35 ns t 555 first asserted from kclk 31 62 31 62 67 ns t 557 vdata driven from kclk 7 27 7 27 30 ns t 559 dtack* negated to next asserted (reads) 47 68 47 68 69 ns t 560 negated from dtack* asserted (last cycle) 17 51 17 51 55 ns t 564 address invalid from dtack* asserted (reads) 50 83 50 83 89 ns t 567 negated from dtack* asserted 54 92 54 92 97 ns t 568 negated from dtack* asserted (reads) 44 64 44 64 67 ns t 569 minimum low time (reads) 82 94 82 94 102 ns t 570 negated from dtack* asserted (reads) 44 62 44 62 66 ns t 571 negated from dtack* asserted (reads) 44 64 44 64 67 ns t 572 vdata tri-state from dtack* asserted 14 43 14 43 47 ns t 574 vaddr, vam, released from dtack* asserted 14 44 14 44 48 ns t 580 negated from berr* asserted 8 28 8 28 31 ns t 581 negated from berr* asserted 9 28 9 28 31 ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value vas vas vdsa vdsb vwr vds vdsa vds vds vwr vas vds vas vas vas vas vdsa vdsb vlword vdsa vdsb
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-11 notes: 1. these parameters are based upon a c32mhz frequency of 32 mhz. 2. use the worse case of t 136 /t 138 and t 137 /t 139 for register access. 3. these are synchronous acknowledgments for burst cycles. for all other cycles, are double sampled by the falling edge of kclk. 4. when using the power-up option. 5. when using the interrupt acknowledge decode power-up option, , are negated on the first of negated or negated. 6. , are negated on the first of negated, negated, negated. 7. this signal is double sampled by rising edge of c32mhz. 8. this includes 40 ns internal delay line. 9. signal is double sampled by kclk. 10. t 10 + t 11 = 31.25 ns 0.50 ns. 11. in arbiter bypass mode, the local bus is driven after has been sampled low on consecutive falling then rising edges of k clk, and released on the rising edge after and are negated. in internal arbiter mode, it is driven on the rising edge after is released. 12. late is setup and held from the rising edge of kclk two clocks after a cycle completes. 13. goes high two falling edges of kclk after sysrst* is negated, and 224 to 238 ms after and are negated, and 224 to 238 ms after a software reset. 14. due to sysrst* asserted externally or sysrst* asserted by , software reset, or bg0in* (as syscon). 15. sysrst* is negated 224 to 238 ms after bg0in* or are released or a software reset. 16. iackout* is asserted on the third rising edge of c32mhz after: ? iackin* is low, ? is low, ? either or is low, and ? dtack* and berr* are high. 17. this is derived from parameters t 301 and t 302 and a 32 mhz c32mhz frequency. 18. bbsy* is asserted on the first edge after bgnin* is sampled low twice by c32mhz. 19. brn* is negated on the second edge after bgnin* is sampled low twice by c32mhz. t 584 address invalid from berr* asserted 15 47 15 47 51 ns t 588 negated from berr* asserted 18 57 18 57 62 ns t 590 asserted from kclk 11 34 11 34 37 ns t 594 vaddr / vdata invalid/hi-z from dtack* asserted (blt) 45 65 45 65 68 ns t 597 negated from dtack* asserted (for last read cycle) 54 93 54 93 98 ns t 598 setup of kbgr to kclk (note 33) -2C-2C C ns table b.1 : scv64 ac characteristics (continued) timing parameter description 33 mhz (all variants) 40 mhz (com) 25 mhz (ext) units min max min max max * use the minimum value in the 33 mhz column for the 25 mhz extended minimum timing value vas vrmc vas kdsack kiack liackn kavec kas lirqn liackn kavec kiack kds lirqn kbgr kbrq kas kbrq kberr lrst pwrrst extrst pwrrst pwrrst vas vds0 vds1
scv64 timing characteristics scv64 user manual app b-12 tundra semiconductor corporation 20. bbsy* is negated once bclr* is sampled low twice by c32mhz. 21. bgnout* is asserted on first edge after brn* has been sampled low on two consecutive edges and bbsy* has been sampled hig h on two consec- utive edges of c32mhz. 22. bgnout* is negated on the first edge of c32mhz after bbsy* has been sampled low on two consecutive edges of c32mhz. 23. bclr* is asserted once a higher level request has been sampled low twice. 24. bclr* is negated once bbsy* has been sampled high twice. 25. vdata is driven on the first rising edge of kclk after the iack conditions have been true for three consecutive c32mhz ed ges. 26. dtack* is asserted on the third clock edge after the iack conditions have been true for 3 consecutive c32mhz edges. 27. irqn* is negated on the next rising edge of c32mhz after iackin*, , and are double sampled low by c32mhz, and vaddr03-01 are at the appropriate level, and dtack* and berr* are high. 28. for the address phase of mblt cycles, dtack* is asserted three kclks (rising edges) after is asserted. dtack*/berr* are asserted at the end of s5 when berrchk=0. during reads, with berrchk=1, dtack*/berr* will be asserted two clock cycles later. 29. contact the factory for operation at frequencies lower than 20 mhz. 30. kbrq is negated for a minimum of 3 kclk periods before the next assertion of kbrq . if kbrq is negated during the current bus cycle, it will not be reasserted until at least 2 kclk cycles after kas has been negated. 31. t represents one clock period. 32. if the scv64 is passing a bus grant on the same level that it is requesting on, then the scv64 double samples the bgnin* signal with the c32mhz clock before asserting bgnout*. 33. this parameter need only be implemented if your logic will be exceeding the maximum number of wait states that can be tol erated by the scv64 during a burst write cycle which resulted from a mblt transfer on the vmebus (see burst writes on page 2 90). 34. this timing parameter allows the kas signal to preceed the scv64sec signal by no more than 2 kclk cycles less 5 ns. vas vds vdsa
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-13 b.2 capacitive loading the timing parameters in table b.1 were determined assuming the values for capacitive loading in table . table b.2 : capacitive loading from output signals signal name typical capacitance (pf) baudclk, c14us, c8mhz, jtdo, kavec, kbgack, kbrq, kds, kipl2-0, lbgr1, liack5, liack4, lmint, sysfled, tick, vaddout, vaddr31-1, vam5-0, vas, vasout, vdata31-0, vdataout, vds1, vds0, vlword, vmeint, vretry, vwr, wdog 30.0 ramsel 40.0 bgout3-0, iackout, 50.0 bimode, kfc2-0, ksize1, ksize0, vsbsel 60.0 kaddr31-0, kdata31-0, krmc 80.0 kas, kberr, kdsack1, kdsack0, khalt, kwr, lrst 130.0 bbsy, bclr, berr, br3-0, dtack, iack, irq7-1, sysclk, sysfail, sysrst 200.0
scv64 timing characteristics scv64 user manual app b-14 tundra semiconductor corporation b.3 timing diagrams figure b.1 : clocks and timers c32mhz kclk kclk c14us c32mhz sysclk baudclk c8mhz t 12 t 10 t 11 t 13 t 14 t 15 t 16 t 17 t 18 t 20 t 19 t 21 t 22 t 23 t 24 t 25 t 27 t 26 t 28 t 29 t 31 t 30 t 32 t 34 t 33 t 35 t 36 wdog
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-15 figure b.2 : reset timing pwrrst bgin0* extrst lrst sysrst* bimode kbgack kfc bgin3* wdog kdata kclk? s0 s1 s2 sw sw s3 s4 s5 v dd ? note: shown to reference software reset effects , and lrst ne g ation t 38 t 58 t 152 t 59 t 87 t 46 t 45 t 85 t 88 t 55 t 86 t 39 t 154 t 89 t 95 t 99 t 97 t 98 t 157
scv64 timing characteristics scv64 user manual app b-16 tundra semiconductor corporation figure b.3 : local interrupts - generation s0 s1 s2 sw sw s3 s4 s5 s0 t 54 t 57 t 56 t 51 t 52 t 53 t 50 lirqn l7ixxx sysfail* irqn* kclk kipl
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-17 s0 s1 s2 s3 s4 s5 sw sw kaddr16-19 kfc kiack kds kwr kclk kdsackn liackn kavec t 105 t 81 t 70 t 72 t 71 t 73 kaddr1-3 lirqn t 74 t 75 kas t 76 t 77 t 79 t 78 ? note: the timing for kdsack when obtaining the vector from the vmebus can be obtained from figure b.10. figure b.4 : local interrupts-acknowledgment
scv64 timing characteristics scv64 user manual app b-18 tundra semiconductor corporation figure b.5 : register access scv64sel kaddr0-8 kclk s0 s1 s2 sw sw s3 s4 s5 ksize kas kdata (r) kds kwr kdsack1 kdsack0 kberr kdata (w) t 100 t 103 t 105 t 131 t 130 t 108 t 111 t 112 t 112 t 116 t 120 t 123 t 125 t 124 t 121 t 122 t 117 t 107 t 113 t 113 t 101 t 136 t 109 t 137 t 138 t 139 t 106 ? note: the kfc signals are not decoded by the scv64 during register accesses
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-19 figure b.6 : register access effects t 159 kclk scv64sel kas s0 kds kdsack tick lrst bimode sysrst* irqi* t 154 t 153 t 150 lmint s2 s1 sw sw s3 s4 s5 vmeint vmeint t 160 sysfail* sysfail* sysfled sysfled t 161 t 162 t 163 t 152 t 168 t 166 t 169 t 167 t 165 t 164 t 61 t 157 (sysfail bit) (swrst bit) (sysfail bit) (swrst bit) (dma cerr) (dma done bi (lm fifo read)
scv64 timing characteristics scv64 user manual app b-20 tundra semiconductor corporation ramsel kaddr kfc ksize kds kwr kclk kdsack1 kdsack0 kberr s0 s1 s2 s3 s4 s5 s0 s1 s2 s3 s4 s5 s0 s1 s2 s3 s4 s5 t 200 t 210 t 204 t 211 t 230 t 231 kdata t 222 t 221 t 235 t 241 t 240 t 240 t 241 t 236 kas t 232 t 213 t 212 t 201 t 205 t 241 figure b.7 : decoupled write cycle - scv64 as local master
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-21 figure b.8 : decoupled write cycle - scv64 as local slave vmeout kaddr kfc ksize kas kds ? kwr kclk kdsack1 kdsack0 s0 s3 s4 s5 kdata s0 s2 s1 sw sw t 144 t 105 t 108 t 111 t 112 t 116 t 120 t 121 t 122 t 118 t 113 t 109 t 145 t 106 ? note: kds is not monitored by the scv64 during this operation. it is shown here onl y for completeness
scv64 timing characteristics scv64 user manual app b-22 tundra semiconductor corporation figure b.9 : coupled cycle - scv64 as local master ramsel kaddr kfc ksize kas kds kwr kclk kdsack1 kdsack0 kberr s0 s3 s4 s5 kdata (r) s2 s1 t 201 t 231 t 108 t 109 t 236 t 240 t 240 t 230 t 204 t 210 t 200 t 241 t 241 t 235 kdata (w) t 221 t 222 t 215 t 218 t 219 t 235 krmc
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-23 figure b.10 : coupled cycle - scv64 as local slave (see figure b.23 for vme timing) kclk kaddr ksize kdsack1 kdsack0 kberr vaddr vas vdata(r) dtack* berr* sw sw sw s3 s4 s5 kwr kdata(r) kds ? kas vmeout kfc t 111 t 112 t 116 t 145 t 106 t 113 t 137 t 136 t 122 t 121 t 171 t 170 t 124 t 125 t 175 t 172 kdata(w) s0 s1 s2 t 180 vdata(w) t 181 ? note: kds is not monitored by the scv64 during this operation. it is shown here onl y for completeness krmc t 147 t 148 t 118 t 144 t 105
scv64 timing characteristics scv64 user manual app b-24 tundra semiconductor corporation figure b.11 : burst write cycle - scv64 as local master (see figure b.14a and figure b.14b for full start/stop timing) kaddr kfc ksize kas kds kwr kclk s0 s1 s2 s3 s4 s5 s6 s7 sw sw s8 s9 s10 s11 s12 s13 s14 s15 s16 s17 s18 s19 kdata kdsack1 t 211 t 230 t 235 t 204 t 251 t 250 t 251 t 252 t 240 t 241 t 240 t 240 t 241 t 253 t 205 t 236 t 231 t 212 3 s0 s1 t 211 t 201 ramsel kbgr t 230 t 598
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-25 figure b.12 : burst read cycle - scv64 as local master s0 s1 s2 s3 s4 s5 sw sw s6 s7 s8 s9 s10 s11 s0 s1 kaddr kfc ksize kas kdata kds kwr kclk kdsack1 ramsel t 211 t 200 t 230 t 235 t 204 t 108 t 109 t 240 t 241 t 241 t 240 t 240 t 205 t 236 t 231 t 211 t 212 t 201 3 t 235 t 230
scv64 timing characteristics scv64 user manual app b-26 tundra semiconductor corporation figure b.13 : slave image/vsb/location monitor access s0 s1 s2 sw sw s3 s4 s5 s0 vmeout kaddr, ksize kas vsbsel kds kclk lmint bimode ramsel t 202 t 200 t 62 t 60 t 61 t 203 t 201 ? note: location monitor writes involve two wait states ( i.e. one additional clk ) lmint ? (lm fifo read) (lm write)
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-27 figure b.14a : local requester C arbiter bypassed t 270 t 272 kclk kbrq kbgr t 271 t 273 t 200 t 274 t 201 local bus ? ramsel ? note: local bus signals include: kaddr, kfc, ksiz, kas, kds, kwr, krmc tristated off the rising edge of s5 and kas , kds tristated off the fallin g ed g e of s4. caution: the scv64 may negate its request early. therefore local arbitration logic should be implemented in a manner which keeps the grant asserted to the scv64 while either kas or kbrq is asserted. in order to force the scv64 off the bus during a decoupled write after only 1 transfer, the (kbgr) must be negated in order to meet a setup time to the falling edge of s2. ! figure b.14b : local requester/arbiter: request by scv64 kas kbgack kclk s0 s1 s3 s2 s6 lbgr1 lbrq1 kbrq kbgr t 265 t 268 t 278 s7 s5 s5 t 266 t 275 s5 s4 s0 t 276 s5 t 273 t 200 t 274 t 201 ramsel local bus ? ? note: local bus signals include: kaddr, kfc, ksiz, kas, kds, kwr, and krmc
scv64 timing characteristics scv64 user manual app b-28 tundra semiconductor corporation figure b.14c : local requester/arbiter: request by an external device C with acknowledge kas kbgack kclk s0 s1 s3 s2 s6 se se sc sc lbgr1 lbrq1 kbrq kbgr t 260 t 261 t 268 t 279 t 278 t 277 t 266 t 264 t 263 s8 s0 t 277 sc t 278 figure b.14d : local requester/arbiter: request by an external device C without acknowledge t 263 kclk t 279 t 261 t 260 t 278 lbrq1 lbgr1 kbrq kbgr kbgack kas s0 s1 s3 s2 s6 se se se t 268 t 266 t 264 t 260 se se s8 s0 t 278
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-29 figure b.15a : local bus error termination - write or read cycle with berrchk bit=0 (scv64 as local master) kas kberr kdsack dtack*/berr* s1 s2 s3 s4 s5 kclk t 240 t 240 t 241 t 241 t 493 figure b.15b : local bus error termination - read cycle with berrchk bit=1 (scv64 as local master) kas kberr kdsack dtack*/berr* s1 s2 s3 s4 s5 kclk t 240 t 241 t 248 t 249 t 493 figure b.15c : deadlock retry termination (scv64 as local slave) kas khalt kberr s0 s1 s2 sw sw s3 s4 s5 t 128 t 129 t 124 t 125 t 127 t 123 kclk
scv64 timing characteristics scv64 user manual app b-30 tundra semiconductor corporation figure b.16 : daisy chain driver timing vas vds dtack* berr* bgnin* bgnout* c32mhz iackin* iackout* t 301 t 302 t 304 t 303 t 309 t 308
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-31 figure b.17a : vmebus requester - normal release brn* bgnin* bbsy* c32mhz t 310 t 312 t 311 t 315 t 316 figure b.17b : vmebus requester - release with bclr* c32mhz bbsy* bclr* t 319 t 317
scv64 timing characteristics scv64 user manual app b-32 tundra semiconductor corporation figure b.18 : vmebus arbiter timing brn* (lower level) bgnout* bbsy* bclr* bgmout* brm* (higher level) c32mhz t 320 t 321 t 324 t 322 t 325 t 320 t 328 t 324 t 329 t 321
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-33 figure b.19 : vmebus interrupter timing c32mhz scv64sel kaddr0-8 kdsack kas irqn* vaddr01-03 iackin* iack* vdsn vas kclk vdata0-7 vdataout dtack* s0 s5 s4 s3 sw sw s2 s1 08c t 350 t 351 t 404 t 410 t 450 t 362 t 420 t 418 t 480 t 429 t 367 t 414 t 451
scv64 timing characteristics scv64 user manual app b-34 tundra semiconductor corporation figure b.20 : vmebus interrupt handler kclk kipl kas kaddr1-3 kds kdata kdsack vaddrout vaddr01-03 iack* vstrbout vas irqn* dtack* vds1 vds0 vdataout vdata t 553 t 53 t 550 t 360 t 504 t 555 t 361 t 510 t 53 t 516 t 564 t 364 t 567 t 365 t 527 t 529 t 570 t 530
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-35 figure b.21 : decoupled write cycle - scv64 as vme master kclk vam vaddrout, vlword* vwr vas vdsa vdata vstrbout vdsb dtack* vdataout vaddr t 364 t 523 t 550 t 362 t 557 t 361 t 521 t 518 t 510 t 509 t 513 t 520 t 504 t 514 t 504 t 574 t 360 t 555 t 505 t 519 t 552 t 511 t 560 t 365 t 572 t 367 t 522 t 528 t 508 t 520 t 521
scv64 timing characteristics scv64 user manual app b-36 tundra semiconductor corporation figure b.22 : decoupled write cycle - scv64 as vme slave vam vaddrout vwr vas vstrbout vdsb vdsa vdataout vdata vaddr, vlword dtack* t 404 t 414 t 416 t 405 t 423 t 430 t 411 t 413 t 408 t 422 t 428 t 410 t 418 t 412 t 420 t 421
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-37 kclk vam vaddrout vas vwr vdata(w) vdsb vdsa vdataout dtack*/berr* vstrbout vaddr, vlword vdata(r) retry*/vrmc t 550 t 360 t 552 t 564, t 514 t 504 t 568, t 518 t 505 t 564, t 514 t 364 t 523 t 597 t 570, t 520 t 365 t 571, t 521 t 510 t 559, t 509 t 511 t 530 t 570, t 520 t 571, t 521 t 533 t 569, t 519 t 510 t 528 t 513 t 504 t 555 t 590 t 361 t 527 t 529 ? note: retry*/vrmc asserted low during rmw cycles when the vretry line is confi g ured as the scv64 proprietar y read-modif y -write pin figure b.23 : coupled cycle - scv64 as vme master
scv64 timing characteristics scv64 user manual app b-38 tundra semiconductor corporation kclk kas kdata(r) kds kdsack/kberr kwr vam vaddr/vlword vdsa vas kaddr vdsb vdata(r) vdataout vwr dtack* s0 s4 s3 s2 s1 s5 t 410 kdata(w) vdata(w) t 404 t 413 t 490 t 491 t 414 t 418 t 423 t 420 t 421 t 429 t 431 t 422 t 367 t 430,480 t 493 t 362 t 412 figure b.24 : coupled cycle - scv64 as vme slave (see figure 9 for local timing)
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-39 figure b.25 : blt/mblt writes - scv64 as vme master kclk vam vaddrout vwr vas vdsa vdata vstrbout vdsb dtack* vdataout vaddr/vlword t 528 up to 64 (blt) or 256 (mblt) transfers t 550 t 504 t 555 t 360 t 504 t 514 t 520 t 574 t 364 t 518 t 523 t 365 t 509 t 511 t 530 t 508 t 521 t 533 t 510 t 513 t 508 t 557 t 361 t 362 t 522 t 572 t 367 t 552
scv64 timing characteristics scv64 user manual app b-40 tundra semiconductor corporation figure b.26 : blt/mblt writes - scv64 as vme slave vaddr, vlword (mblt) vaddrout vam vwr vas vdsa vdata (blt) vstrbout vdsb vdataout vdata (mblt) vaddr, vlword (blt) dtack* t 408 vaddr32-vaddr63 or invalid data up to 64 (blt) or 256 (mblt) transfers t 404 t 410 t 412 t 420 t 413 t 421 t 430 t 414 t 411 t 408 t 408 t 428 t 422 t 428 t 408 t 413 t 430 t 422 t 430 t 423 t 421 t 420 t 418 t 416 t 422 t 422 t 422
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-41 figure b.27 : blt/mblt read cycle - scv64 as vme master kclk vaddr,vlword (mblt) vaddrout vam vwr vas vdsa vdata (blt) vstrbout vdsb vdataout vdata (mblt) vaddr,vlword (blt) dtack* va32-va63 for a64, or not driven up to 64 (blt) or 256 (mblt) transfers t 550 t 504 t 360 t 555 t 552 t 510 t 564 t 364 t 527 t 529 t 594 t 529 t 564 t 364 t 597 t 523 t 570 t 528 t 513 t 571 t 366 t 529 t 570 t 571 t 527 t 511 t 559 t 530 t 570 t 528 t 513 t 571 t 527 t 550 t 361 t 363 t 594 t 367 t 530
scv64 timing characteristics scv64 user manual app b-42 tundra semiconductor corporation figure b.28 : blt read cycle - scv64 as vme slave kclk kas kdata kds kdsack/kberr kwr vaddr, vlword vas vaddrout vam vdsa vwr kaddr, kfc, ksiz berr* dtack* vdataout vdata vstrbout vdsb s0 s1 s5 s4 s3 s2 s0 s5 s4 s3 s2 s1 ? note: see fi g ure b.9 for local side timin g up to 64 transfers t 404 t 410 t 412 t 413 t 414 t 420 t 421 t 490 t 362 t 491 t 493 t 493 t 411 t 413 t 429 t 367 t 480 t 481 t 420 t 421 t 429 t 491 t 367 t 480 t 481 t 493 t 493
scv64 user manual scv64 timing characteristics tundra semiconductor corporation app b-43 kclk kas kdata kds kdsack/kberr kwr vaddr, vlword vas vaddrout vam vdsa vwr kaddr, kfc, ksize berr* dtack* vdataout vdata vstrbout vdsb s2 s4 s0 s2 s4 s1 s3 s5 s1 s3 a64 only ? note: see fi g ure b-9 for local side timin g up to 256 transfers t 404 t 412 t 410 t 413 t 408 t 414 t 420 t 413 t 411 t 422 t 421 t 480 t 491 t 429 t 369 t 420 t 421 t 413 t 411 t 491 t 429 t 367 t 493 t 480 t 493 t 481 t 493 t 493 t 367 t 429 t 491 t 420 t 491 t 429 t 369 figure b.29 : mblt read cycle - scv64 as vme slave
scv64 timing characteristics scv64 user manual app b-44 tundra semiconductor corporation
vmebus interface componentsscv64 user manual tundra semiconductor corporation app c-1 appendix c performance the scv64 provides a complete high performance vmebus interface for a variety of applications from high end multi-processing cpu cards, to low end slave only i/o and i/o manipulation cards. the following discussion outlines what performance can be expected from the scv64 during data transfer, arbitration and daisy chaining. data transfer performance is handled in two sections: one covering coupled performance; the other covering decoupled performance. the operation and performance of these two modes varies considerably between the two. generally coupled mode, because of its relative performance inefficiency would be used primarily for barrier transactions. these are transactions where the cpu does not terminate until the full transfer has completed. the cpu enters wait-states either waiting for data to be returned during a read, or for data to be successfully stored in the final destination. coupled (barrier) transactions are increasingly the exception on the vmebus, as raw processing moves off the bus, and onto multi-processing cards. instead, the vmebus is being used to transfer large blocks of data between independent processes. an example might be a video frame grabber which transfers frame blocks over the vmebus to a dsp card, which synthesizes data based upon the video frames. the data transfer would typically be handled in decoupled mode to maximize bus bandwidth. the dsp card may then report to a main controller either with barrier transactions or not, depending upon the application. to perform these block data transfers in coupled mode, would quickly saturate the system resources, whereas decoupling frees up resources and cpu processing power to perform other essential operations. the following analyses show the scv64's performance only up to its pins. buffer delays and backplane skew were not incorporated into the calculations. c.1 coupled cycles coupled cycles are performed by the scv64 during all read cycles (except dma initiated reads), vme interrupt acknowledge cycles, and during write cycles when the fifos have been coupled. when evaluating the performance of the scv64 during coupled cycles, the characteristics of both the vme and local operations must be examined. because of the involvement of both buses during the cycle, and the required arbitration for one bus, coupled cycles have considerably lower performance than decoupled ones.
scv64 performance scv64 user manual app c-2 tundra semiconductor corporation c.1.1 scv64 as vme master during a coupled cycle when the scv64 is the vme master, the following operations occur ? the local cycle is decoded, ? the vme bus is requested and granted, ? the cycle is driven onto the vme bus, ? the vme slave responds to and terminates the cycle, and ? the scv64 terminates the local cycle. the bus release mechanism programmed for the scv64 affects performance. if the scv64 is in release when done (rwd) mode, it must re-arbitrate for the bus during each cycle. in release on request (ror) mode, the bus need only be arbitrated for once, and then all subsequent cycles may proceed at a higher rate. the following figures illustrate the scv64 performing coupled cycles in rwd and ror mode. each figure shows the relationship between operations on the two buses, and the two clock inputs, kclk, and c32mhz. kclk is used mostly for the local synchronous bus, while c32mhz is used for vmebus request and ownership operations. because it is coupled to the local bus, and because the local bus operates synchronous to kclk, the vmebus also tends to operate synchronous to kclk.
scv64 user manual scv64 performance tundra semiconductor corporation app c-3 kdsack kaddr kclk c32mhz kas brn* bbsy* vaddr vas dtack* bgnin* figure c.1 : scv64 as vme master - rwd mode
scv64 performance scv64 user manual app c-4 tundra semiconductor corporation on the falling edge of each kclk, the scv64 examines the state of , and . once both these pins are asserted, it initiates internal state machines running off of both kclk, and c32mhz. the typical measurements one may expect for coupled master cycles are: rwd mode: to brn*: 3k clk + 2.5 c32 mhz + t 310 bgnin* to : 3.5k clk + 2.5 c32 mhz + t 555 dtack* to : t 172 ror mode: to : 6k clk + 2.5 c32 mhz + t 555 dtack* to : t 172 kclk c32mhz kaddr kas kdsack vaddr vas dtack* figure c.2 : scv64 as vme master - ror mode kas vmeout kas vas kdsack kas vas kdsack
scv64 user manual scv64 performance tundra semiconductor corporation app c-5 a complete cycle (from s0 through to s5) will take: rwd mode: 10k clk + 5 c32 mhz + t 310 + (bus grant time) + t 555 + (slave response) + t 172 ror mode: 10k clk + 2.5 c32 mhz + t 555 + (slave response) + t 172 c.1.2 scv64 as vme slave during a coupled cycle when the scv64 is the vme slave, the following operations occur: ? the cycle is decoded to determine if it is relevant to the scv64, ? the local bus must be requested and granted, ? the cycle is driven onto the local bus, ? the local slave responds to and terminates the local cycle, and ? the scv64 terminates the vme cycle. the scv64 provides a local bus arbiter which may be used to arbitrate between the scv64, and another device for access on the bus. this function uses an internal state machine to perform the arbitration. however, if the internal arbiter is not required such as when the scv64 is the only master on the bus, or when an external arbiter is implemented, the designer may bypass the internal arbiter, and as such increase performance. the figures on the following page show coupled cycles (reads, and writes perform identically) both when the internal arbiter is active, and when it is bypassed. the net effect is the addition of several clock cycles when the arbiter is active. both figures assume zero wait-state memory.
scv64 performance scv64 user manual app c-6 tundra semiconductor corporation kclk vaddr vas kdsack kaddr kas kbrq kbgr kbgack dtack* figure c.3 : coupled cycle - scv64 as vme slave (local arbiter active) kclk vaddr vas kdsack kaddr kas kbrq kbgr dtack* figure c.4 : coupled cycle-scv64 as vme slave (local arbiter bypassed)
scv64 user manual scv64 performance tundra semiconductor corporation app c-7 from the previous figures, the typical slave response ( asserted to dtack*) can be calculated. arbiter active: 15k clk + t 493 arbiter bypassed: 10k clk + t 493 these figures assume the minimum local bus grant time, which for arbiter active is 4 kclk periods from the edge where is asserted, and for arbiter bypassed, 1 clock period from the same edge. c.2 decoupled cycles the scv64 operates at its peak performance, when in decoupled mode. since the local and vme buses operate independently of each other, arbitration latencies have no effect on performance. c.2.1 scv64 as vme master as a vme master, when the scv64 is accessing an ideal vme slave (slave response = 30 ns), each data transfer will take 103 ns. this is the measurement taken from asserted to the next asserted. it does not take into account the initial arbitration time. however, so long as the transmit fifo contains entries, the scv64 will not re-arbitrate for the bus, and as such, the initial arbitration time becomes negligible. when performing d32 standard writes, the above data transfer period translates to a peak transfer rate of 39 mb/s -- close to the theoretical vme maximum of 50mb/s (or an 80 ns period). blt transfers occur at the same rate, since the scv64 takes advantage of address pipelining during standard transfers. the transfer rate doubles to 78mb/s for mblts. c.2.2 scv64 as vme slave when the scv64 is being written to, and its receive fifo has been enabled, it has a slave response time of 56 ns (vds* to dtack* asserted) vas kbrq vas vas
scv64 performance scv64 user manual app c-8 tundra semiconductor corporation c.3 daisy chains the scv64 propagates three of the four bgnout* lines directly from the bgnin* lines. the fourth line, the level that the scv64 is performing its bus requests on is double sampled by the 32mhz clock before being propagated. as such there are two performance numbers to be considered for the bus grant propagation delays: bus grant propagation delay:t 308 (not requesting level) 1.5 c32 mhzt+ t 307 (requesting level) as with bus grant propagation delay for the scv64's requesting level, the iack daisy chain driver is also double sampled by the c32mhz clock before being propagated: iack daisy chain delay: 1.5 c32 mhzt+ t 302 c.4 arbiter functions when the scv64 is acting as the system arbiter, it uses the c32mhz clock to double sample each bus request before issuing a bus grant to propagate down the daisy chain. when configured as a priority (pri) arbiter, the grant is issued on the next edge of the c32mhz clock, if the bus is currently not in use ( , and bbsy* high). as such, the bus request to grant delay when the bus is free will typically be: bus grant arbitration delay:2.5 c32 mhz + t 321 (pri mode) when configured for round robin (rr) arbitration, the scv64 cycles through each of the request levels issuing a grant to any request on the currently examined level. if a request comes in while the scv64 is monitoring that level, it will respond with the grant in the same time as in pri mode above. however, the request may come in just as that level has passed in the request level ring. in this case, the grant take a further 6 c32 mhz clocks before being issued (two clocks per level), assuming no other requests are pending on other levels. on average then, the grant will typically take 3 clocks longer than in pri mode: bus grant arbitration delay:5.5 c32 mhz + t 321 (rr mode) vas
scv64 user manual scv64 performance tundra semiconductor corporation app c-9 c.5 summary the following tables describe the scv64's performance under the following conditions: ? kclk = 33mhz ? c32mhz = 32mhz ?v dd = 5 v ? temp = 25c period refers to the time between consecutive cycles. for standard cycles this would refer to the time from address strobe to the next address strobe. for block transfer, it refers to the time from data strobe to data strobe. in the case of blt, and mblt transfers this refers to the data beat of the transfer, since the effect of the address phase diminishes with increasing block length. tr ansfe r rate is the expected data transfer frequency with a 32 bit data bus width (64 bit for mblt transfers). bus request to bus grant delays are assumed to be that which can be expected when the scv64 is the syscon, and there is no bus contention. also, when calculating it's master performance, a slave response of 30ns (the vme minimum) is used. under typical conditions?, the following parameters are used: table c.1 : timing parameters ? typical conditions are: v dd = 5.0 v temp = 25c timing parameter description typical (ns) t 172 dtack* to asserted 61 t 302 iackout* asserted from c32mhz 8 t 308 bus grant daisy chain delay 8 t 310 brn* asserted from c32mhz 10 t 493 dtack* asserted from kclk 13 t 321 bgnout* asserted from c32mhz 11 t 555 first asserted from kclk 59 kdsack vas
scv64 performance scv64 user manual app c-10 tundra semiconductor corporation table c.2 : data transfer - scv64 as vme master table c.3 : data transfer - dma cycle type period (ns) rate (mb/s) coupled standard read - rwd mode 693 5.8 coupled standard read - ror mode 528 7.6 coupled standard write - rwd mode 693 5.8 coupled standard write - ror mode 528 7.6 decoupled write 103 38.8 cycle type period (ns) rate (mb/s) standard read 145 27.6 standard write 103 38.8 blt read 145 27.6 blt write 103 38.8 mblt read 145 55.2 mblt write 103 77.6 local burst reads 30 133.3 local burst writes 60 66.7 local single cycle reads 90 44.4 local single cycle writes 90 44.4
scv64 user manual scv64 performance tundra semiconductor corporation app c-11 table c.4 : data transfer - scv64 as vme slave note: the above measurements assume a to delay, of less than 10ns for arbiter bypassed, or 90ns for arbiter active, and zero wait state memory. table c.5 : daisy chains table c.6 : vmebus arbiter cycle type slave response (ns) coupled d32 read - arbiter active 463 coupled d32 read - arbiter bypassed 313 coupled d32 write - arbiter active 463 coupled d32 write - arbiter bypassed 313 coupled mblt cycle - arbiter active 553 coupled mblt cycle - arbiter bypassed 403 decoupled write 56 decoupled blt write 56 decoupled mblt write 56 daisy chain propagation delay (ns) bgnin* to bgnout* (not requesting level) 8 bgnin* to bgnout* (requesting level) 56 iackin* to iackout* 86 cycle type delay (ns) bus request to bus grant - pri or next rr request in ring 87 bus request to bus grant - typical rr 181 bus clear delay - higher bus request to bclr asserted 56 kbrq kbgr
scv64 performance scv64 user manual app c-12 tundra semiconductor corporation
vmebus interface componentsscv64 user manual tundra semiconductor corporation app d-1 appendix d vmebus-local bus cycle mapping d.1 cycle translation the vme/local cycle mapping functionality provided by the scv64, while targeted at 68020/030 cpu's, can be used under a variety of architectures. this appendix outlines how the scv64 maps local cycles into vme cycles, and vme cycles into local ones, as well as which byte lanes are active during the cycle. cycle type and byte lane translation are based upon: ? type of cycle (read / write), ? direction of cycle (vme to local, or local to vme), ? the value of the swap bit in the mode register, and ? the value of the bussiz bit in the mode register the tables below are grouped primarily upon type and direction of the cycle. they are further differentiated by whether the scv64 is acting as the local master (vme slave), or local slave (vme master). when acting as the local master, the scv64 will be asserting , while as the local slave, will be asserted by a local device. separate tables exist for cases where the swap bit (see mode register) is cleared or set. when swap is cleared and the scv64 is the local slave, the scv64 will use local byte lanes in accordance with a 68020/030 architecture. when swap is set during these accesses, the scv64 will use byte lanes matching directly with the relevant byte lanes on the vmebus. the type of transfer generated onto the vmebus is not affected by this bit. ramsel vmeout
vmebus-local bus cycle mapping scv64 user manual app d-2 tundra semiconductor corporation for example, when performing a single byte, longword aligned (byte (0)) transfer, the scv64 will use the data in the highest byte lane (kdata31-24) to generate a single byte transfer on the vmebus. however, with the swap bit set the scv64 will use the second byte lane (kdata 15-08) to generate the same transfer. note: byte lane requirements are not affected by the swap bit during accesses from the vmebus. (i.e. when the scv64 is acting as the vme slave.) table d.1 : effect of swap bit in the mode register on byte lane translation swap effect 0 map local big endian byte lanes to vme byte lanes 1 map local byte lanes directly to vme byte lanes figure d.1 : single longword aligned byte transfer with swap = 0 kd31-24 kd23-16 kd15-8 kd7-0 local data bus vd31-24 vd23-16 vd15-8 vd7-0 vme data bus data data figure d.2 : single longword aligned byte transfer with swap = 1 kd31-24 kd23-16 kd15-8 kd7-0 local data bus vd31-24 vd23-16 vd15-8 vd7-0 vme data bus data data
scv64 user manual vmebus-local bus cycle mapping tundra semiconductor corporation app d-3 as well as showing the type of cycle generated on one bus as a result of an incoming cycle on the other, the following tables also outline the byte lane requirements. for this purpose, a byte(n) convention is used, where n represents the address offset from an even 32-bit boundary (longword aligned). each table shows either where the scv64 presents data, or where data is expected to be present for the scv64 to transfer. in several cases, when the scv64 is driving the local data lanes, it presents the same data in duplicate byte lanes. this is compatible with 68020/030 architectures, and local devices may pick up the data from either byte position. as well, required data presentation of data on the byte lanes varies depending on the state of the bussiz bit in the mode register. this bit affects whether or not unaligned transfers (uats) will be generated on the vmebus by the scv64. when set, the scv64 will generate uat cycles, and will always respond with a 32-bit . this implies that the user- defined d16 areas of the memory map will become d32. the size of the data transfer will be uniquely defined by the state of the ksiz lines. *longword and longword aligned accesses only. when cleared, the scv64 disables uat generation on the vmebus and will now terminate cycles with either a 32-bit or a 16-bit . it terminates longword aligned transfers with a 32-bit . all others are terminated with a 16-bit . a 16-bit termination implies that only data in the uppermost two byte lanes (kdata31-24, and kdata23-16) are relevant to the cycle. any data on the other two byte lanes must be transferred in a later cycle. table d.2 : port size as indicated by bussiz and cycle termination data space bussiz port size d32 0* 0 0 32 bit 0 1 0 16 bit 1 0 0 32 bit d16 0 1 0 16 bit 1 0 0 32 bit kdsackx kdsack1 kdsack0 kdsackx kdsackx kdsackx kdsackx
vmebus-local bus cycle mapping scv64 user manual app d-4 tundra semiconductor corporation for example, consider a tri-byte write at a longword offset 1. with bussiz = 1, the scv64 will pick up data in the low three byte lanes, and terminate the cycle with a 32 bit dsack, and generate a unaligned tri-byte write on the vmebus. with bussiz = 0, the scv64 will terminate the cycle with a 16-bit dsack, and generate a single byte write at offset 1 (byte(1)). figure d.3 : tri-byte transfer with bussiz = 1 kdsackx = 00 scv64 transferred all data c y cle complete (1) (2) (3) (1) (2) (3) local side vme side figure d.4 : tri-byte transfer with bussiz = 0 kdsackx = 10 not all data transferred transfer low two byte lane (1) (2) (3) (1) local side vme side fulll data transferred cycle complete (2) (3) (2) (3)
scv64 user manual vmebus-local bus cycle mapping tundra semiconductor corporation app d-5 the state of the bussiz bit can also determine where relevant data will be expected by the scv64, even when the cycle performed on the vmebus is identical. when bussiz = 0, the scv64 will generally pick up, and present data on the uppermost byte lanes - the exception being longword, longword aligned transfers where all four byte lanes are used. when bussiz = 1, byte lane use is determined by the offset from the bytes being transferred relative to a longword boundary. byte(0) always appears in the uppermost byte lane, byte(1) always appears in the next byte lane, and so on. both states can be supported by duplicating the data in the uppermost two byte lanes with data in the lowermost two byte lanes when the transfer is either byte size, or word size. when performing read cycles where the scv64 is the local slave, it is not necessary to know the state of the bussiz bit. the byte lanes relevant to the cycle can be uniquely determined through knowledge of the transfer size, the address offset, and the kdsack returned by the scv64. note: during cycles where the scv64 is the local master (vme slave), the bussiz bit has no effect either on type of cycle generated on the local bus, or on the byte lanes in use during the cycle. table d.3 : transfer size encoding ksize1 ksize0 size 01byte 10word 113 bytes 0 0 long word
vmebus-local bus cycle mapping scv64 user manual app d-6 tundra semiconductor corporation table d.4 : read cycles - scv64 as local slave/vme master (swap=0) ksize ka01-00 kdsack data lanes driven by scv64 vme cycle generated kd31-24 kd23-16 kd15-08 kd07-00 00 00 00 byte(0) byte(1) byte(2) byte(3) quad(0-3) 00 00 01 byte(0) byte(1) byte(0) byte(1) dbl byte(0-1) 00 01 00 byte(1) byte(2) byte(3) uat(1-3) 00 01 01 byte(1) byte(1) byte(1) 00 10 00 byte(2) byte(3) dbl byte(2-3) 00 10 01 byte(2) byte(3) byte(2) byte(3) dbl byte(2-3) 00 11 00 byte(3) byte(3) 00 11 01 byte(3) byte(3) byte(3) 01 00 00 byte(0) byte(0) byte(0) 01 00 01 byte(0) byte(0) byte(0) 01 01 00 byte(1) byte(1) byte(1) 01 01 01 byte(1) byte(1) byte(1) 01 10 00 byte(2) byte(2) 01 10 01 byte(2) byte(2) byte(2) 01 11 00 byte(3) byte(3) 01 11 01 byte(3) byte(3) byte(3) 10 00 00 byte(0) byte(1) byte(0) byte(1) dbl byte(0-1) 10 00 01 byte(0) byte(1) byte(0) byte(1) dbl byte(0-1) 10 01 00 byte(1) byte(2) uat(1-2) 10 01 01 byte(1) byte(1) byte(1) 10 10 00 byte(2) byte(3) dbl byte(2-3) 10 10 01 byte(2) byte(3) byte(2) byte(3) dbl byte(2-3) 10 11 00 byte(3) byte(3) 10 11 01 byte(3) byte(3) byte(3) 11 00 00 byte(0) byte(1) byte(2) uat(0-2) 11 00 01 byte(0) byte(1) byte(0) byte(1) dbl byte(0-1) 11 01 00 byte(1) byte(2) byte(3) uat(1-3) 11 01 01 byte(1) byte(1) byte(1) 11 10 00 byte(2) byte(3) dbl byte(2-3) 11 10 01 byte(2) byte(3) byte(2) byte(3) dbl byte(2-3) 11 11 00 byte(3) byte(3) 11 11 01 byte(3) byte(3) byte(3)
scv64 user manual vmebus-local bus cycle mapping tundra semiconductor corporation app d-7 table d.5 : read cycles-scv64 as local slave/vme master (swap=1) ksize ka01-00 kdsack data lanes driven by scv64 vme cycle generated kd31-24 kd23-16 kd15-08 kd07-00 00 00 00 byte(0) byte(1) byte(2) byte(3) quad(0-3) 00 00 01 byte(0) byte(1) dbl byte(0-1) 00 01 00 byte(1) byte(2) byte(3) uat(1-3) 00 01 01 byte(1) byte(1) 00 10 00 byte(2) byte(3) dbl byte(2-3) 00 10 01 byte(2) byte(3) dbl byte(2-3) 00 11 00 byte(3) byte(3) 00 11 01 byte(3) byte(3) 01 00 00 byte(0) byte(0) 01 00 01 byte(0) byte(0) 01 01 00 byte(1) byte(1) 01 01 01 byte(1) byte(1) 01 10 00 byte(2) byte(2) 01 10 01 byte(2) byte(2) 01 11 00 byte(3) byte(3) 01 11 01 byte(3) byte(3) 10 00 00 byte(0) byte(1) dbl byte(0-1) 10 00 01 byte(0) byte(1) dbl byte(0-1) 10 01 00 byte(1) byte(2) uat(1-2) 10 01 01 byte(1) byte(1) 10 10 00 byte(2) byte(3) dbl byte(2-3) 10 10 01 byte(2) byte(3) dbl byte(2-3) 10 11 00 byte(3) byte(3) 10 11 01 byte(3) byte(3) 11 00 00 byte(0) byte(1) byte(2) uat(0-2) 11 00 01 byte(0) byte(1) dbl byte(0-1) 11 01 00 byte(1) byte(2) byte(3) uat(1-3) 11 01 01 byte(1) byte(1) 11 10 00 byte(2) byte(3) dbl byte(2-3) 11 10 01 byte(2) byte(3) dbl byte(2-3) 11 11 00 byte(3) byte(3) 11 11 01 byte(3) byte(3)
vmebus-local bus cycle mapping scv64 user manual app d-8 tundra semiconductor corporation notes: all other byte lanes applicable to both bussiz = 0, and bussiz = 1 table d.6 : write cycles - scv64 as local slave/vme master (swap=0) data lanes driven by local device vme cycle generated ksize ka01-00 kd31-24 kd23-16 kd15-08 kd07-00 bussiz = 0 bussiz = 1 00 00 byte(0) byte(1) byte(2) byte(3) quad(0-3) quad(0-3) 00 01 byte(1) byte(2) byte(3) byte(1) uat(1-3) 00 10 byte(2) byte(3) byte(2) byte(3) dbl byte(2-3) dbl byte(2-3) 00 11 byte(3) byte(3) byte(3) byte(3) 01 00 byte(0) byte(0) byte(0) 01 01 byte(1) byte(1) byte(1) 01 10 byte(2) byte(2) byte(2) byte(2) 01 11 byte(3) byte(3) byte(3) byte(3) 10 00 byte(0) byte(1) dbl byte(0-1) dbl byte(0-1) 10 01 byte(1) byte(2) byte(1) uat(1-2) 10 10 byte(2) byte(3) byte(2) byte(3) dbl byte(2-3) dbl byte(2-3) 10 11 byte(3) byte(3) byte(3) byte(3) 11 00 byte(0) byte(1) byte(2) dbl byte(0-1) uat(0-2) 11 01 byte(1) byte(2) byte(3) byte(1) uat(1-3) 11 10 byte(2) byte(3) byte(2) byte(3) dbl byte(2-3) dbl byte(2-3) 11 11 byte(3) byte(3) byte(3) byte(3) indicates byte lanes applicable only to bussiz = 0 indicates byte lanes applicable only to bussiz = 1
scv64 user manual vmebus-local bus cycle mapping tundra semiconductor corporation app d-9 table d.7 : write cycles-scv64 as local slave/vme master (swap=1) ksize ka01-00 data lines driven by local device vme cycle generated kd31-24 kd23-16 kd15-08 kd07-00 bussiz = 0 bussiz = 1 00 00 byte(0) byte(1) byte(2) byte(3) quad(0-3) quad(0-3) 00 01 byte(1) byte(2) (1) (3) byte(1) uat(1-3) 00 10 byte(2) byte(3) dbl byte(2-3) dbl byte(2-3) 00 11 byte(3) byte(3) byte(3) 01 00 byte(0) byte(0) byte(0) 01 01 byte(1) byte(1) byte(1) 01 10 byte(2) byte(2) byte(2) 01 11 byte(3) byte(3) byte(3) 10 00 byte(0) byte(1) dbl byte(0-1) dbl byte(0-1) 10 01 byte(1) byte(2) (byte(1) byte(1) uat(1-2) 10 10 byte(2) byte(3) dbl byte(2-3) dbl byte(2-3) 10 11 byte(3) byte(3) byte(3) 11 00 byte(0) byte(1) (0) (2) byte(1) dbl byte(0-1) uat(0-2) 11 01 byte(1) byte(2) (1) (3) byte(1) uat(1-3) 11 10 byte(2) byte(3) dbl byte(2-3) dbl byte(2-3) 11 11 byte(3) byte(3) byte(3)
vmebus-local bus cycle mapping scv64 user manual app d-10 tundra semiconductor corporation notes: all other byte lanes applicable to both bussiz = 0, and bussiz = 1 indicates byte lanes applicable only to bussiz = 0 indicates byte lanes applicable only to bussiz = 1
scv64 user manual vmebus-local bus cycle mapping tundra semiconductor corporation app d-11 note: duplicated entries for vmein writes are given heavy outlines in the table above. table d.8 : read/write cycles - scv64 as local master/vme slave (swap =x, bussiz=x) ksize ka01-00 data lines driven by local device vme cycle accepted kd31-24 kd23-16 kd15-08 kd07-00 00 00 byte(0) byte(1) byte(2) byte(3) quad(0-3) 0001---- - 0010---- - 0011---- - 01 00 byte(0) byte(0) byte(0) 01 01 byte(1) byte(1) byte(1) 01 10 byte(2) byte(2) 01 11 byte(3) byte(3) 10 00 byte(0) byte(1) byte(0) byte(1) dbl byte(0-1) 10 01 byte(1) byte(2) uat(1-2) 10 10 byte(2) byte(3) dbl byte(2-3) 1011---- - 11 00 byte(0) byte(1) byte(2) uat(0-2) 11 01 byte(1) byte(2) byte(3) uat(1-3) 1110---- - 1111---- -
vmebus-local bus cycle mapping scv64 user manual app d-12 tundra semiconductor corporation d.2 address space mapping table d.9 : kfc signal translation to vme address space (scv64 as vme master) kfc2 kfc1 kfc0 am codes vme address space 0 0 0 0a, 29, 3a non-privileged program access 0 0 1 09, 29, 39 non-privileged data access 0 1 0 0a, 29, 3a non-privileged program access 0 1 1 09, 29, 39 non-privileged data access 1 0 0 0e, 2d, 3e supervisory program access 1 0 1 0d, 2d, 3d supervisory data access 1 1 0 0e, 2d 3e supervisory program access 1 1 1 0d, 2d, 3d supervisory data access
scv64 user manual vmebus-local bus cycle mapping tundra semiconductor corporation app d-13 table d.10 : vme am code translation to kfc signals (scv64 as vme slave) am code vme address space kfc2 kfc1 kfc0 C000 09, 39 0b, 3b 00 non-privileged data access non-privileged block transfer a64 64-bit block transfer 001 0a, 3a 08, 38 00 non-privileged program access non-privileged 64-bit block transfer a64 64-bit block transfer 010 blt, mblt (fifoben set) 0 1 1 C100 0d, 3d 0f, 3f supervisory data access supervisory block transfer 101 0e, 3e 0c, 3c supervisory program access supervisory 64-bit block transfer 110
vmebus-local bus cycle mapping scv64 user manual app d-14 tundra semiconductor corporation
vmebus interface componentsscv64 user manual tundra semiconductor corporation app e-1 appendix e applications this appendix covers the following topics: ? vmebus interface on page e-1 ? local bus interface for slave only applications on page e-8, ? local bus interface for mc68030 application on page e-11, and ? local bus interface for mc68040 application on page e-12. e.1 vmebus interface e.1.1 buffered signals the scv64 requires ten 8-bit transceivers (or five 16-bit transceivers) to buffer the vme address, data, address modifiers, and strobes. while always enabled, the direction of each of these transceivers is controlled by one of three signals generated by the scv64 (vaddrout, vdataout, and vstrbout) as shown in figure e.2 on page e-5. tundra recommends the use of '245 transceivers in the vmebus interface. in particular 'f245, 'fctat245, and 'abt245 may be used. the most commonly used component is the 'f245. these buffers are available in a wide range of packages from many vendors with up to 36 transceivers per package. the low profile of the tsop package allows the mounting of these components on the backside of vme boards, so this package may be of particular interest to designers with limited real estate. e.1.2 layout issues as with all high frequency designs, proper layout of your board is critical in order eliminate crosstalk and minimize noise on the board. glitches or crosstalk can occur on many of the vmebus signals which may cause the scv64 to behave in an undesirable manner. the following scv64 signals are particular sensitive to noise: the bus grant inputs, bus busy signal and the five highest vme address lines.
typical applications scv64 user manual app e-2 tundra semiconductor corporation noise or glitches which occur on the bus grant inputs usually originate from crosstalk induced on the board. in order to minimize crosstalk these tracks should be as short as possible (see figure e.1) and should be routed on a separate layer. if a glitch occurs on the bus grant inputs the scv64 can interpret this glitch as an additional bus grant, in which case you could end up with contention on the vmebus. the scv64 does not always de-glitch these signals in order to accelerate the propagation of a bus grant down the bus grant daisy chain. the vme bus bbsy* signal is inherently very noisy. the scv64 internally de-glitches this signal on a rising and a subsequent falling edge of the c32mhz clock; however, care should still be taken to minimize the length of this track. the third group of signals in which noise can impact the scv64 is on the upper 5 vme address lines vaddr[31-27]. these signals are used by the scv64 in decoding an a32 slave access and reside on the p2 connector along with other user defined signals. if your design involves the use of a secondary bus (i.e. the vsb bus) then you must take precaution in ensuring that the switching of these user-defined signals doesn't induce noise onto these five vme address lines, otherwise the scv64 may not decode a slave access that was intended for it. all of these potential problems mentioned above can be eliminated with proper layout techniques which begin with the proper placement of the scv64 device (see figure e.1). this orientation of the scv64 placed closer to the p1 connector than the p2 connector will minimize the length of the vme signals to the scv64's pins and should allow you to meet the "2-inch" rule of the vmebus specification. the following board stackup has been used successfully without any glitches or noise occurring on the above mentioned signals. ---ground shield signal these two layers are used to route the vme data lines from the connectors to the transceivers. signal ===vcc signal these two layers are used to route bbsy*, bclr*, bgxin*, bgxout*,brx* signal ---ground figure e.1 : orientation of the scv64 (cpga and pqfp) to minimize distance to the connector p1 scv64 pin a1 cpga orientation p1 scv64 pin 1 pqfp orientation
scv64 user manual typical applications tundra semiconductor corporation app e-3 signal these two layers used to route the data lines from the scv64 to the transceivers. signal ---ground shield as noted before, the bbsy* signal is especially sensitive to picking up crosstalk on the pcb and therefore it is suggested than the bbsy* track be routed at the very outside of its layer and never underneath any data buffers. similarly, the four bus grant inputs should not be routed underneath any of the vme buffers. the bg3in* signal will likely have a pulldown resistor (refer to the next section) attached to this track. care should be taken to minimize the length of the stub to this resistor in order to alleviate any noise on this bus grant input. the bg0in* signal can be used as an external reset input if the scv64 is the syscon. if the scv64 is being used in this manner then the length of the stub connection from this reset logic to the bg0in* track should be minimized as well. a way to minimize the effect of the ground bounce which can be induced on the vme address lines by the undefined pins on the p2 connector switching at the same time is to separate the routing of these undefined pins from the vme address pins on your board. this can be done by routing the vme signals on one side of a power plane and the undefined p2 signals on the other side of the power plane. other possibilities to reduce ground bounce would be to investigate using the new 5 row connectors which have added rows "z" and "d" to the connector. if your board was plugged into a backplane with the 5 row receptacles, these additional ground pins will reduce the ground bounce, and therefore the noise on the vme address lines. e.1.3 decoupling vdd and vss in order to decouple low frequencies, a 22 f capacitor should be placed near the scv64 between the v dd and v ss power layers. in order to decouple high frequencies, it is recommended that at least six 0.1f bypass capacitors be distributed around the pairs of v dd and v ss pins on the device. e.1.4 bgxin*[3:0] signals while the bgxin*[3:0] signals are direct connects to the backplane bus grant daisy chain, these signals also serve special purposes for system controller configuration and determination. the scv64's auto-syscon detect mechanism relies upon bg3in* to determine its system controller status at system reset. if bg3in* is low immediately after system reset, then the scv64 will automatically become the system controller. otherwise, the system controller functions are disabled. this feature is part of the new vme64 specification, and is fully compliant with revision c systems.
typical applications scv64 user manual app e-4 tundra semiconductor corporation to make use of auto-syscon detect feature, the scv64 requires a pull-down resistor of approximately 4.7k? on the bg3in* signal. this will not in any way impact the performance of the bus grant daisy chain. with this resistor in place, no jumpers are required to configure system controller enabling. when a card is configured as the system controller, the other three bus grant in signals, bgin*[2:0] , are typically unused. however, the scv64 uses the bg0in* signal as an off card reset, while the two other signals may be used as off-card configuration inputs, monitored through internal registers.
scv64 user manual typical applications tundra semiconductor corporation app e-5 figure e.2 : scv64 interface to vmebus
typical applications scv64 user manual app e-6 tundra semiconductor corporation bg0in* will act as an active-low system reset signal when the scv64 is the system controller. if the bg0in* signal is used in this capacity, then all scv64 equipped cards must put a pull-up resistor on the bg0in* signal of approximately 4.7k?. bg1in* and bg2in* are configuration inputs only, monitored through the stat1 register. since they are non-functional signals, these signals do not need to have pull-ups or pull-downs on them, and may be left directly connected to the vmebus. alternatively, they may be connected to chassis mounted switches. e.1.5 retry*/ vrmc pin the scv64 has a dual purpose pin, retry*/vrmc , which may be used as either the vme64 specification retry* line, or may be used as a tundra proprietary read-modify- write (rmw) cycle pin. the configuration of the retry*/vrmc pin is controlled by the rmcpin bit in the mode register, and defaults to use as the vrmc pin. when configured as the vrmc pin, the signal is a bi-direct and must be buffered through a transceiver with direction controlled by vstrbout. one of the unused inputs on the strobe transceiver may be used for this purpose. when configured as retry*, the signal acts only as an input. it may be directly connected to the backplane. bg0in bg2in bg1in bg3in reset bg0out bg2out bg1out bg3out bg0out bg2out bg1out bg3out bg0in bg2in bg1in bg3in bg0in bg2in bg1in bg3in configuration slot 1 slot 2 slot n figure e.3 : bus grant daisy chain usage in system
scv64 user manual typical applications tundra semiconductor corporation app e-7 retry* is defined in the new vme64 specification as occupying the b3 (formerly reserved), on the p2 connector. however, many current implementations of vrmc use that same pin. to maintain compatibility with other board vendors using tundra's vme interface components, it may be necessary to continue to use this pin, in violation of the new definition of this pin in the vme64 specification. note that this will only be possible if p2 pin b3 is not being used as the retry* in other parts of the system. to provide as much flexibility as possible, many board vendors choose to use a jumper option to provide the capability of having the pin operate as either the vrmc pin on p2 pin b3, or as retry*. this jumper either takes the buffered version of the signal through the transceiver for vrmc , or the direct connect for retry* (see figure e.4 below). note that if either vrmc or retry* is implemented on p2 pin b3, that this signal should be properly terminated on the backplane. vme64 style backplanes will already have provision for the termination of this line. if termination is not provided on the backplane, ensure that there is termination on-board to pull retry*/vrmc to the inactive state. if neither vrmc or retry* is to be implemented on the board, ensure that the retry*/vrmc is pulled to the inactive state (high) to ensure proper function. e.1.6 bi-mode and irq1* the scv64's bi-mode feature may be triggered through four mechanisms: ?reset, ? assertion of the bitrig pin, ? software (through the sbi bit), and ? assertion of irq1* (when configured as such). to connector p2 pin b3 rmc* (through transceiver to scv64) retry* (direct connect to scv64) figure e.4 : implementation of vrmc and retry*
typical applications scv64 user manual app e-8 tundra semiconductor corporation irq1* defaults upon reset to being a bi-mode initiator, which means that the scv64 will enter bi-mode whenever irq1* is asserted. when configured as bi-mode initiator, irq1* triggers a local interrupt on level 7 (if so enabled through the bie bit in the 7ie register). when configured as an interrupt source, a local interrupt on level 1 is generated upon assertion of irq1* if that level is enabled in the vie register. to reconfigure this signal as an interrupt only, the vi1bi bit in the genctl register should be cleared, typically as part of a reset routine. e.2 local bus interface for slave only applications the scv64 is intended for use both in applications where a local processor is provided and in applications where no local intelligence processor is provided. this is achieved primarily through a power-up option enabling the device to automatically initialize all internal registers required to enable access to the vmebus. e.2.1 initialization all internal register bits required for vmebus operation are set automatically when the autobar power-up option is enabled. this option is enabled by pulling kfc2 high and kfc0 low at the rising edge of pwrrst . at this time, the vmebar register is loaded with the value on the local data bus and all required internal bits are set to enable slave access to the device. e.2.2 vmebus programming in conjunction with the automatic initialization of the device, additional register accesses may be required to complete initialization of the device or to reprogram functionality. this is achieved by programming any additional internal registers from the vmebus. access to the internal registers is made through the slave image programmed during automatic initialization of the device. the scv64 will generate a cycle on the local bus of the scv64 in the same way as an access to local memory or any other local bus device. this cycle must be decoded to generate a chip select signal for the scv64 (scv64sel ). the scv64 accepts the register access from the local bus and terminates the local cycle with kdsack . access to the local bus for register programming may be through either a24 or a32 addressing spaces.
scv64 user manual typical applications tundra semiconductor corporation app e-9 an example circuit diagram is provided. in this circuit, an addressing decoding block decodes the select signal for the scv64 (scv64sel ) in addition to any other select signals required on the local bus. a transceiver in conjunction with user defined programming (resistors or jumpers) provides a24 programming bits for the vmebar register during the rising edge of pwrrst. 7 bits are shown which select the a24 base address and size. all unused a32 base address and size bits are left undefined in this example. vmebar register bits may be left undefined provided that system design and initialization are unaffected by undefined a24 or a32 images. in this case, all initialization must be completed using the defined a24 address space. alternatively, logic could be provided to program both a24 and a32 base addresses and sizes during power-up.
typical applications scv64 user manual app e-10 tundra semiconductor corporation va31-01 vd31-00 vlword vaddrout vdataout g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 vas vwr vds0 vds1 vam5-0 vstrbout g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 g dir a0 a1 a2 a3 a4 a5 a6 a7 b0 b1 b2 b3 b4 b5 b6 b7 am5-0* as* wr* ds0* ds1* a31-1 d31-0 lword* bgin* br* irq* iack* bgout* iacki* iacko* bbsy* bclr* dtack* sysclk* berr* sysfail* bg0in* - bg3in* bg0out* - bg3out* br0* - br3* irq7* - irq1* iack* iacki* iacko* bbsy* bclr* dtack* sysclk* berr* sysfail* scv64 direct connect vmebus signals vmebus interface sysrst* vretry sysrst* vretry +5v +5v 2 10 local bus interface kfc(2..0) kdata(31..0) scv64sel ramsel c32mhz kclk c32mhz kclk pwrrst extrst lrst kas kds kwr kdsack(1..0) kberr khalt krmc ksiz(1..0) kbrq kbgr kbgack kipl(2..0) kavec local control signals local reset output external reset input power on reset lbrq1 lbgr1 l7inmi l7imem l7iacf lirq(5..0) address decode kclk kas kdsack(1..0) kfc(2..0) ksiz(1..0) scv64sel kaddr(31..0) bitrig birel bimode local data bus local address bus kaddr bi-mode control vmeout vmebar programming kdata(22...16) pwwrst local device selects kclk +5v +5v +5v +5v +5v 0 1 autobar and arbiter bypass power-up options figure e.5 : connections for slave only design
scv64 user manual typical applications tundra semiconductor corporation app e-11 e.3 local bus interface for mc68030 application a circuit diagram is provided in figure e.6 below which illustrates local connections for a mc68030 application. va31-01 vd31-00 vlword vaddrout vdataout vas vwr vds0 vds1 vam5-0 vstrbout bgin* br* irq* iack* bgout* iacki* iacko* bbsy* bclr* dtack* sysclk* berr* sysfail* scv64 vmebus interface local bus interface sysrst* vretry kfc(2..0) kdata(31..0) scv64sel ramsel c32mhz kclk c32mhz kclk pwrrst extrst lrst kas kds kwr kdsack(1..0) kberr khalt 68030 as ds r/w dsack(1..0) berr halt krmc ksiz(1..0) kbrq kbgr kbgack br bg bgack fc(2..0) siz(1..0) kipl(2..0) kavec avec local control signals local reset output external reset input power on reset size and memory space encoding lbrq1 lbgr1 l7inmi l7imem l7iacf lirq(5..0) clk address decode kclk kas kdsack(1..0) kfc(2..0) ksiz(1..0) ramsel vmeout scv64sel kaddr(31..0) bitrig birel bimode d(31..0) a(31..0) local data bus local address bus alternate local bus request alternate local bus grant local interrupt sources rmc kaddr bi-mode control reset ipl(2..0) vmeout figure e.6 : connections for 68030 design
typical applications scv64 user manual app e-12 tundra semiconductor corporation e.4 local bus interface for mc68040 application the scv64, while designed with a mc68030 compatible interface, lends itself well to a variety of other processing environments. because of its similarity to the mc68030, the mc68040 is particularly suited among processors for use with the scv64 in a multi- processing vme environment. this application note provides an overview of one possible implementation of a scv64/mc68040 interface design. over the past decade, the mc68000 family of processors has dominated vme board design. this is in large part due to motorola?'s market dominance in the field, but also to the similarities between the vmebus and a 680x0 style bus. while other processors, particularly risc processors, are growing in importance within vme applications, 680x0 boards still predominate because of their relative affordability and availability. the prevalence of 680x0 hardware entails the prevalence of 680x0 software in vme applications. taking advantage of this investment in software is a major factor in choosing processors for a new vme design. every member of the 680x0 family, including the 68040, is object-code compatible with each other. therefore, the significant investment in software need not be duplicated when upgrading a system's performance. upgrading a 68030 system to 68040 significantly increases performance at minimum cost. although upgrading to a 68040 improves a board's raw processing power, these gains may be lost on communication and data transfer unless the system bus is optimized. vmebus can be a powerful tool in optimizing the system throughput, but the bus is only as powerful as its interface. the scv64 provides that powerful interface. its internal fifo architecture effectively decouples bus performance, allowing both the vmebus and local cpu bus to operate at their peak capacities. in addition, the integral dma allows high speed data transfer between boards at close to the theoretical bus limit. e.4.1 design philosophy in this design, the scv64 and the cpu occupy bandwidth on the same local bus. this implies that there are two masters (the scv64 and the cpu) on the local bus, and possibly more if the application demands it. the address, data, control, and interrupt facilities on the local bus are shared. as such, the scv64 must compete with other masters for access to local resources. the basic layout for this architecture is shown in figure e.7 below.
scv64 user manual typical applications tundra semiconductor corporation app e-13 a different approach involves a hierarchical structure, as in figure e.8, where the cpu resides on its own bus. a bridge allows the cpu to access an i/o bus from which the cpu can access the vmebus. the advantage of such a scheme is that activities occur simultaneously on the i/o bus and on the cpu bus. the implementation of a hierarchical system is not discussed in this manual. the present discussion focuses on the scheme shown in figure e.7. to make this application as general as possible, cache coherency protocols are not discussed. therefore, the flow of cycles is either from the cpu to the vmebus or memory, or from the scv64 to memory. scv64 cycles are never translated into equivalent cpu cycles for snooping requirements. thus, the adapter design translates cycles only in the direction of the cpu to the scv64. e.4.2 design overview there are four major components of the bus adapter design that are discussed here: arbitration, interrupts, address space mapping, and the cycle translation unit. figure e.7 : shared local bus structure figure e.8 : hierarchical local bus structure vmebus 68040 memory other masters scv64 local bus vmebus 68040 scv64 cpu memory dual port memory bridge shared i/o bus cpu bus other masters
typical applications scv64 user manual app e-14 tundra semiconductor corporation the arbitration unit provides the design for a typical arbiter. it arbitrates only between the scv64 and the cpu, although other masters may be added. the arbitration follows a simple priority scheme, where the cpu has the greatest priority on the bus. ownership of the bus is granted to the scv64 only when the bus is idle. if the scv64 has ownership of the bus when the cpu requests it, the scv64's ownership is immediately rescinded. the scv64 typically gives up the local bus within one or two cycles after ownership rescission. the priority scheme also implies that locking capability is built-in. the arbiter will never remove ownership of the bus from the cpu, and during lock sequences, the scv64 will hold the bus despite rescission of its grant. the interrupt unit adapts the mc68040 interrupt acknowledgment cycle to an equivalent cycle for the scv64. note that the scv64's internal interrupt handler can be used to provide efficient interrupt management. the scv64 can monitor up to six general purpose interrupt sources as vectored or auto-vectored, all seven vme interrupts, as well as a non-maskable interrupt, sysfail*, and acfail*. all of these interrupt sources can be seamlessly adapted to mc68040's interrupt capabilities. the address mapping and decode unit provide access to multiple vme address spaces. access to a16, a24 and a32 spaces is provided through the scv64's internal address decode mechanisms, while access to program/data and supervisory/non-privilege address spaces is mapped directly from the cpu's equivalent address spaces indicated on the transfer mode lines. the address decode unit also provides access to the scv64's internal registers. the fourth unit within the bus adapter is the cycle translation unit, providing mapping of mc68040 cycles into equivalent scv64 cycles. the unit implements a state machine to map cpu read and write cycles into single wait state vme accesses. it handles bus errored, deadlock, as well as auto-vectored terminations. while dynamic bus sizing is provided as a programmable option within the scv64, it is not implemented by the mc68040. therefore, it is not available with this design. if dynamic bus sizing is a requirement in the system, then the designer may wish to refer to the mc68150 dynamic read/write bus sizer documentation available from motorola?.
scv64 user manual typical applications tundra semiconductor corporation app e-15 figure e.9 : mc68040 to scv64 bus adapter block diagram address decode scv64 kdata(31..0) kaddr(31..0) local bus device selects c32mhz kclk local arbiter kbrq kbgr kbgack kfc(2..0) +5v 210 scv64sel ramsel vmeout 3 2 1 31..4,0 3 2 1 iack cycle decode kiack kas kds krmc kdsack1 kberr birel bitrig bimode +5v extrst lrst to all other card resets kavec khalt kipl(2..0) kwr ksiz(1..0) ts ta tea br bg lock locke tt0,1 tm2-0 siz(0,1) ipl(2..0) data(31..0) addr(31..0) r/w tip avec tci tbi cycle translation bb bclk pclk 68040 rsto rsti kdsack0 +5v 2 x kclk +5v +5v memory / memory controller pwrrst power reset circuit mc88915 sc0 sc1
typical applications scv64 user manual app e-16 tundra semiconductor corporation e.4.3 bus adapter operation cycle translation unit the main unit of the bus adapter maps the 68040 strobe and termination signals to the equivalent scv64 signals. this mapping is performed through a state machine running off the rising edge of the processor clock, pclk. scv64 and mc68040 read/write cycle overview the 68040 has a minimum two clock cycle composed of states c1 and c2. in c1, ts is asserted by the 68040, with setup to the falling edge of bclk. the processor then goes into state c2, sampling the termination signals ta, tea, and avec on the falling edge of bclk. data is considered valid by the 68040 on the edge that ta is asserted. if none of these signals is sampled low, the processor enters wait states. the significance of each of the termination combinations is shown in table e.1. table e.1 : 68040 terminations figure e.10 : mc68040 bus transfer control the scv64 has a minimum three clock cycle composed of states s0 through s5, following the 68030 convention. the address strobe, as, is typically asserted in s1. however, as a slave (i.e. when the cpu is accessing internal registers or the vmebus) the scv64 only examines its strobe, kas, on the falling edge of s2. if kas and either of scv64sel or vmeout are asserted, the scv64 becomes the local slave. ta tea avec termination description 0 1 1 successful 101 bus error 0 0 1 deadlock retry 0 1 0 auto-vectored iack cycle bclk ta / tea / avec ts c1 c2 c2
scv64 user manual typical applications tundra semiconductor corporation app e-17 the scv64 terminates slave accesses by asserting a combination of kdsack0, kdsack1, kberr, kavec, and khalt. each combination indicates a different type of termination (see table e.2). if none of kdsackx, kberr, or kavec is asserted, the cpu is expected to insert wait states. table e.2 : scv64 terminations each of the termination signals may be considered asynchronous. as such, the local master should double-sample the termination signals on the falling edge of kclk. data is generally considered valid during the second sample, although during register write cycles the scv64 may latch the data on the first sample. figure e.11 : scv64 bus transfer control e.4.4 cycle translation state machine the 68040 read and write cycles are mapped to scv64 cycles by the state machine in figure e.12. while both the scv64 and the 68040 use the same bus clock (kclk and bclk), the 68040 processor clock (pclk) is used as the state machine clock. pclk is double the frequency of the bus clock. the processor clock is used since state transitions may occur on either edge of the bus clock. kdsack 0 kdsack 1 kberr kavec khalt termination description 01111 16-bit successful 00111 32-bit successful 11011 bus error 11010 deadlock retry 11101 auto-vectored kclk kdsackx / kberr / kavec kas s0 s2 s1 sw s3 sw s4 s5
typical applications scv64 user manual app e-18 tundra semiconductor corporation the cycle translation state machine sits in the idle state, m0, until the 68040 asserts its ts signal, when it enters m1. in this state, the machine starts the cycle to the scv64 by asserting kas and kds. unlike the standard 68030 protocol, kds is not required on the next clock during write cycles. the scv64 ignores that signal until later in the cycle. if none of the terminations is returned from the scv64 before the next state transition, then the machine progresses to state m3, and then back to m1. this process continues until one of the termination signals has been sampled low on the falling edge of kclk/bclk. when this occurs, the machine progresses to state m2, and then m4 on the next transition. if the terminations are not still active at the end of m4, then the machine moves back to state m1 to begin the double sampling process again. otherwise, one of the terminations has been active for two sample periods, and the state machine moves to state m5, where it terminates the 68040 cycle by asserting the appropriate cycle acknowledge to the 68040. the type of acknowledge generated depends upon the state of the scv64 termination lines (see figure e.12 below).
scv64 user manual typical applications tundra semiconductor corporation app e-19 the scv64 latches the data on the data lines during the second sample of the terminations at the end of m4. the 68040 will latch the data at end of the next state m5 when ta is asserted. note that to maintain valid data until the end of m5, the state machine keeps kas asserted an extra half clock. (this violates the mc68030 specification.) after m5, the state machine enters m6, where it drives all outputs high, including ta, tea, avec, kas, and kds. it is not until it moves back to the idle state during the next transition that these signals are tri-stated. some signals may not need to be tri-stated if they are not being used as open-collector signals. figure e.12 : cycle translation unit state machine !kdsackx & !kberr & !kavec ts kas, kds m0 kdsackx + kberr + kavec kdsackx + kberr + kavec kas, kds m1 m5 kdsackx & !kberr !kdsackx & kberr & khalt !kdsackx & kberr & !khalt kavec ta ta, tea tea ta, avec m6 !kas, !kds, !ta, !tea, !avec kas, kds m2 kas, kds m4 m3 !kdsackx & !kberr & !kavec
typical applications scv64 user manual app e-20 tundra semiconductor corporation figure e.13 : cycle translation timing diagram e.4.5 dynamic bus sizing dynamic bus sizing is the capability of a cpu to transparently break a data transfer into multiple transfers based upon the size of the destination port. while the scv64 does provide a capability to request the cpu to break-up a cycle, the 68040 does not recognize this protocol. the scv64 can request that the cpu break an unaligned transfer into aligned 16- or 8-bit transfers, or to force 16-bit transfers to d16 vme boards. however, the 68040 expects that the addressed port is capable of accepting the current transfer, thus transferring the responsibility for bus sizing onto software. kclk/bclk kdsackx / kberr / kavec kas/kds ta / tea / avec ts pclk data (rd) data (wr) s0 s2 s1 sw s3 sw s4 s5 addr m0 m1 m2 m5 m0 from scv from 040 m4 m3 m1 m6 c1 c2 c2 c2
scv64 user manual typical applications tundra semiconductor corporation app e-21 the scv64 can be programmed to disable its dynamic bus sizing capability, matching it with the 68040. this is done through setting the bussiz bit in the mode register. when the bussiz bit is set, the scv64 responds with a 32-bit kdsack (both kdsack lines asserted). with dynamic bus sizing disabled (bussiz = 1), only one of the two kdsack lines need to be fed into the cycle translation state machine: kdsack0. e.4.6 transfer attributes transfer type the transfer type lines on the 68040 are driven by the cpu to indicate the type of access of the current bus cycle (see table e.3). only two of the four possible encodings are of interest in a scv64 application. these are normal access, and acknowledge access. the acknowledge access can be used to generate the scv64's interrupt acknowledge signal (see the section on interrupts). normal access bus cycles should be used exclusively for scv64 accesses. as such, the address decoder (see the section on the address decoder) can use the tt1,0 lines to generate scv64sel and vmeout. table e.3 : 68040 transfer type encoding since the scv64 can not accept burst cycles as the local slave, all move16 bus cycles should be either bus errored, or allowed to time-out with the bus timer. as an option, the alternate logical function code access may be used by the address decoder to redefine the address map. one application may be to use this code exclusively for vmebus accesses. transfer modifier / function codes the transfer modifier lines on the 68040 are driven to indicate the data space being accessed. the definition of these lines change depending upon whether or not the current bus cycle is an alternate function codes access. in either case, the lines may be mapped one for one to the scv64 function code lines kfc[2:0]. tt1 tt0 transfer type 0 0 normal access 0 1 move16 access 1 0 alternate logical function code access 1 1 acknowledge access
typical applications scv64 user manual app e-22 tundra semiconductor corporation the function code lines are used by the scv64 in determining the address modifiers on the vmebus. with the tm2-0 lines connected directly to the kfc2-0 lines, address spaces on the 68040 bus are mapped to equivalent spaces on the vmebus (see table e.4). table e.4 : local and vme bus space mapping transfer size the transfer size lines on the 68040 are defined almost identically to those on the scv64 (ksiz0, ksiz1): both indicate the size of the current bus cycle. the scv64 and the mc68040 differ in the case where ksiz1 = 1 and ksiz0= 1. in this case, the scv64 indicates this is a 3-byte transfer and the 68040 indicates this is a line transfer. the transfer size lines may be directly connected between the two devices; however, the scv64 does not support line read or line write cycles from the 68040. bus arbitration the local bus arbiter of the bus adapter provides arbitration between the scv64 and the 68040. the arbiter implemented here is a priority arbiter, where the 68040 has priority over the scv64. the scv64 is forced to give up the local bus either when it is done, or when the 68040 has a request pending. the scv64 has two arbitration protocols which are selected at power-up. the three-wire protocol provides 68030 style arbitration, while the two-wire protocol is more general, and intended for non-68030 applications. the bus arbiter described here uses the two-wire protocol (kbgack must be low during power-up). the arbiter starts in state m0, the idle state. if it receives a request from the scv64, and there are no requests from the 68040, the arbiter progresses to state m3 where it grants the bus to the scv64 and asserts bus busy to the 68040. the grant to the scv64 can not be removed until the first cycle has started. this is to ensure that the scv64's request line will negate when the grant is negated later. therefore, the scv64 is only recognized as bus owner once it has asserted kas. once in state m4, the arbiter continues scv64 bus ownership until one of two events occur: either the scv64 no longer requires the bus (as indicated by its request line and kas negating), or the 68040 requires the bus (indicated by its request line asserted). 68040 space vmebus space user data non-privileged data user program non-privileged program supervisor data supervisory data supervisor program supervisory program
scv64 user manual typical applications tundra semiconductor corporation app e-23 if the scv64 no longer requires the bus, the arbiter proceeds back to the idle state, waiting for the next request. this transition may be removed if desired, implementing a release-on- request scheme instead. if the 68040 requests the bus and the scv64 is not performing a read-modify-write cycle, the scv64's grant is removed, and the arbiter proceeds to state m5. in state m5, the arbiter grants the bus to the 68040 and waits for the scv64 to complete its bus tenure. note that the 68040 does not actually begin its tenure until the arbiter releases the bus busy (bb) signal and proceeds to state m1. once in m1, the 68040 obtains bus ownership when the arbiter releases the bb signal. unless a deadlock condition is indicated by the scv64 (khalt asserted), the arbiter maintains the grant to the cpu while the cpu's request signal is still valid. while the cpu has bus ownership, the arbiter asserts 040_master, which is used by the iack logic block to determine when to drive address lines. since the cpu maintains ownership until it has no further cycles to perform, there is no requirement to implement the 68040's lock signals, lock and locke in this arbiter design. if some other design is to be implemented, these signals may be required. deadlock situations are handled through state m2. if the 68040 is the current bus master (i.e. the arbiter is in state m1) attempting a vme access, and khalt is asserted by the scv64, the arbiter removes the cpu's bus grant and proceeds to state m2. the arbiter remains in m2 until the scv64 requests the bus and the cpu releases the bus.
typical applications scv64 user manual app e-24 tundra semiconductor corporation figure e.14 : local bus arbiter state machine e.4.7 interrupts generation since both the 68040 and the scv64 use the same encoding of interrupts on the interrupt priority level lines (ipl0-2), these lines can be directly connected between the two devices. acknowledge cycles the major difficulty in interfacing a 68040 interrupt acknowledge cycle is identifying the interrupt level being acknowledged. the scv64 expects the interrupt level to be encoded on kaddr[3:1], but the 68040 encodes the level on its transfer modifier lines, tm0-2. !br & ! krmc m0 m1 m3 m2 m4 m5 kbrq & !br & !bb br !br & !bb khalt kbrq & !bb kas br & !krmc !kbrq & !kas !kbrq & !kas bg kbgr, bb kbgr bb bg, bb 040_master !khalt
scv64 user manual typical applications tundra semiconductor corporation app e-25 the interrupt acknowledge block of the bus adapter must detect that a 68040 iack cycle is being performed and indicate that to the scv64. the transfer type signals on the 68040 indicate that an iack cycle is being performed, while the kiack input performs the same function from the scv64s perspective. note that the scv64 has two iack modes for internal and external decoding. the internal iack decoding works with 68030 style iack cycles. for non-68030 iack cycles, the scv64 is set for external decoding mode (kfc1 held high at power-up). in external mode, the kiack pin is used to select iack cycles.. the generation of kiack to the scv64 can be generated directly from a decoding of the tt0-1 as in figure e.15. it is not necessary to qualify kiack with any other signal since the scv64 performs its own qualification of the signal with kas, generated by the cycle translation state machine. figure e.15 : kiack generation the low address lines (kaddr[3:1]) must be buffered in order to be used to encode the interrupt level. kaddr[3:1] must be driven with the 68040 address lines (a[3:1]) during standard bus cycles, but with the transfer modifier lines (tm[2:0]) during iack cycles. a signal from the arbiter is also required in order to indicate when the 68040 is the current bus master. figure e.16 : iack cycle interrupt level generation tt0 tt1 kiac k a(1:3) tm(0:2) 2:1 mux kiack kaddr(1:3 ) 040_master
typical applications scv64 user manual app e-26 tundra semiconductor corporation address decoder the address decoder provides chip-selects to various devices on the local bus, including the scv64. the scv64 requires two chip-select signals: vmeout, and scv64sel . asserting vmeout initiates vme master accesses, while scv64sel selects the scv64's internal registers. while many chip-selects are typically required to be qualified by an address strobe, this is not the case for the scv64. it internally qualifies vmeout, scv64sel , and kiack with kas. hence these signals may be directly decoded from the address and possibly the transfer type and transfer modifier lines. (see the section on interrupts for details on generation of kiack.) details on decoding these signals are not provided here since they are application dependent. however, vmeout is usually asserted whenever no other device on the local bus is selected. this ensures the local bus has maximum access to vmebus resources. ramsel is asserted by the scv64 when it is accessing local resources. it can be used as part of the decode scheme to provide a different perspective on the local memory map from the vmebus. see memory mapping on page 2-45 for more information about address decoding resets the scv64 has an internal reset mechanism for sorting several resets on the board. it has a pwrrst pin for reset on power-up, extrst for locally generated resets, sysrst for vmebus generated resets, and lrst, an output for resetting all local devices. the 68040 has a reset output pin, rsto, and a reset input pin, rsti. the various elements of the reset scheme can be connected as in figure e.17 below. figure e.17 : reset circuit +5v rsto rsti extrst lrst power reset circuit pwrrs t
scv64 user manual typical applications tundra semiconductor corporation app e-27 bi-mode mechanisms many designers may find that they do not require use of the scv64's bi-mode feature. if this is the case, disable bi-mode, by tying bitrig high, and birel low. this ensures that the scv64 will come out of bi-mode immediately after reset. the vi1bi bit in the genctl register should also be cleared to reconfigure irq1* as a vme interrupt instead of a bi-mode initiator. (see bi-mode effects on page 2-63 and on page 2-119 for more details on bi- mode.
typical applications scv64 user manual app e-28 tundra semiconductor corporation
vmebus interface componentsscv64 user manual tundra semiconductor corporation app f-1 appendix f initialization f.1 hardware configuration the following describes various hardware issues that require attention during initialization. f.1.1 power-up modes the following scv64 pins must be at the levels given in table f.1 during the rising edge of pwrrst to ensure that the device comes up in a defined state. note all of these pins may be driven at some later point during normal operation, by the scv64. for this reason, all pins specified as bidirectional, must be pulled to an appropriate logic level through an external resistor. table f.1 : pin levels for specific power-up modes pin sample point level power-up mode kbgack pwwrst low internal arbiter bypassed high internal arbiter implemented kfc2, kfc0 pwwrst low, low reserved low, high reserved high, high vmebar loaded with kdata, not enabled high, low vmebar loaded with kdata, enabled kfc1 pwwrst low kiack/lirq2 configured as lirq2 pin high kiack/lirq2 configured as kiack pin kds a a. the scv64's kds pin must be sampled as a logic high on the rising edge of the scv64's lrst output which can occur up to 250 ms after a reset initiator (pwrrst, sysrst, extrst, swrst bit) has negated. one possible solution to ensure that the kds pin is always sampled as a logic high is to use the scv64's lrst output to control the local cpu's reset input. this will prevent the local cpu from driving the kds line active when lrst negates. pwrrst, sysrst, extrst, lrst high must be high to ensure normal operation bg3in pwrrst, low scv64 becomes vme syscon sysrst high scv64 does not become vme syscon kdata pwrrst x kdata is latched into vmebar register
initialization scv64 user manual app f-2 tundra semiconductor corporation f.1.2 test mode pins these pins are used by the factory during manufacturing and test. both must be grounded during normal operation. if in-circuit testing is to be performed on the board, pins tmode1 and tmode0 should be pulled low through 4.7 k w resistors. contact tundras applications department for more detail. f. 1 . 3 b i - m o d e if bi-mode is not to be used in the system, tie birel to ground, and bitrig to a high level. the scv64 will enter bi-mode whenever one of the bi-mode initiators is active, but will automatically return to an operational state when the initiator is removed. initiators are: ?any reset, ? irq1* (when configured as a bi-mode initiator), ? the sbi bit in the genctl register, ?bitrig irq1* defaults as a bi-mode initiator, meaning that if this signal is low after reset, the scv64 will remain in bi-mode, until it is released. normally, all irq lines are pulled high by the vme backplane, however, some backplanes are shipped without terminating resistors. systems where irq1* is floating may see erratic entry into bi-mode until irq1* is reconfigured as a vme interrupt source using the vi1bi bit in the genctl register. f.1.4 jtag the scv64 presently has no internal jtag controller. jtms and jtclk may be connected to ground or to the corresponding board level signals. jtdi and jtdo are internally connected, allowing subsequent implementation of a complete jtag board level test. f.1.5 clocks the c32mhz clock input on the scv64 controls several internal timing functions. besides generating the scv64 clock/timer outputs (c8mhz, c14us, baudclk, tick, and wdog, sysclk), it also affects: ? the local bus timer ? the vmebus ownership timer
tundra semiconductor corporation app f-3 scv64 user manual initialization ? the vmebus time-out timer ? calibration of internal delay lines to ensure reliable operation of the scv64, this pin must be tied to a 32mhz clock. the kclk clock input should be synchronous to the local cpu clock, and may be any frequency up to the specified limit. f.1.6 resets the scv64 can be reset through one of several sources: pwrrst, extrst, sysrst*, a software reset, and, when configured as the syscon, bg0in*. some backplanes do not terminate bg0in* on slot 1. ensure that this signal is tied to an appropriate level, or to an external reset switch. note: for slave applications, where the vme slave image is configured using the autobar process, the slave image will not be reset or reloaded during any reset except pwrrst. as such, a designer may wish to route the sysrst pin to the pwrrst pin, to guarantee that the slave base addresses are reprogrammed to their initial values. f.1.7 retry*/vrmc the scv64 retry*/vrmc pin may be configured as either the retry* pin, or as a proprietary read-modify-write pin. the use of this pin is configured with the rmcpin bit in the mode register. when configured as retry*, it may be direct connected to the vmebus connector. when configured as the vrmc pin, is should be routed through the strobes buffer (along with vas, vds0, vds1, etc.) with the direction controlled by vstrbout.
initialization scv64 user manual app f-4 tundra semiconductor corporation f.2 software the following describes various software issues for the programmer during initialization. table f.2 : software initialization summary functional group register bit description delay lines dlst1 cal20 cal30 cal40 20 ns process calibration value 30 ns process calibration value 40 ns process calibration value dlct offset20 offset30 offset40 20 ns delay line process offset 30 ns delay line process offset 40 ns delay line process offset cycle generation mode bussiz unaligned cycle generation / bus sizing swap vme to local byte lane mapping slave image vmebar a24ba a24 slave image base address a24siz a24 slave image size a32ba a32 slave image base address a32siz a32 slave image size mode a24slven a24 slave image enable vinen a32 slave image enable sa64bar - a64 slave image enable local memory map mode a16di disable a16 accesses a24di disable a24 accesses a24po a24 page location vsbsel - vsb decode area bi-mode genctl vi1bi irq1* bi-mode configuration rmc/retry mode rmcpin retry*/vrmc pin use burst cycles mode fifoben enable rx fifo bursts to local side local timers misc endog enable watchdog timer ctl2 tickm tick timer speed tlen1,0 tick timer length genctl lt o en local bus timer enable other local options mode rmcretry read-modify-write deadlock termination berrchk check for late bus error on vmein reads local arbiter ctl2 lbram arbitration mode (scv64 vs. lbrq1) interrupts ic54 lirq5, 4 interrupt level mapping ic32 lirq3,2 interrupt level mapping ic10 lirq1, 0 interrupt level mapping ic54 5 av, 4 av lirq5, 4 auto-vector configuration sysfail misc sysfail assertion of vme sysfail*
tundra semiconductor corporation app f-5 scv64 user manual initialization f.2.1 delay line initialization the scv64 has five internal delay lines (three 40ns delay lines and one each of 30ns and 20ns) which provide for necessary timing to satisfy conditions of the vme specification. these delay lines are continuously calibrated for temperature and voltage. initially, to ensure optimum performance, they must also be calibrated for processing. this is done through reading a value from a status register for each delay line, and altering another based upon this value. three register fields must be read. these are cal40, cal30, and cal20, all in the dlst1 register. a new value based upon the original contents of these registers must be written to the offset_40, offset_30, and offset_20 fields in the dlct register (the sel_40, sel_30, and sel_20 bits must be 0 during the write). once written, the offset fields need not be re-calculated until the next reset of the scv64, and can be locked until the next reset through writes to the key fields in the same register. follow the setting of the key_20, key_30, and key_40 bits with setting of the mkey bit to lock the offset fields. perform the following operations (truncating the results to integral values): offset_40 = (cal40 40) + 3, offset_30 = (cal30 6) + 4, and offset_20 = cal20 35. write these above values to the appropriate fields in the dlct register. vme requester vreq oten vme ownership timer enable ot1,0 vme ownership timer length bcen bus clear (bclr*) recognition rel release mode (ror or rwd) req request mode (fair or demand) lv l 1 ,0 request level ctl2 memim l7imem effect of vme requester vme arbiter va r b arb1,0 arbitration mode (pri, rr, mixed) aten arbitration time-out enable vxl1,0 arbitration time-out length table f.2 : software initialization summary (continued) functional group register bit description
initialization scv64 user manual app f-6 tundra semiconductor corporation these values can be locked in through setting bits key_40, key_30, and key_20. a subsequent setting of bit mkey permanently locks all these values until the next reset. note: the sel bits in the dlct register must not be set. f.2.2 byte lane mapping and cycle conversion two bits in the mode register control the form that the local bus interface to the vmebus takes on. these are the bussiz bit and the swap bit. essentially, the bussiz bit controls how local cpu cycles are converted into vme cycles through enabling the generation of unaligned cycles on the vmebus, while the swap bit controls what byte lanes are relevant to a particular cycle. f.2.3 slave address programming the scv64's vme slave address may be automatically set and enabled at power up, or configured and enabled at any other point in time through programming a series of registers as follows: access protection may also be applied to any portion or all of the a24 or a32 slave images through programming the apbr register. this protection may be either write protection only, or read and write protection, as set by the prot bit in the mode register. table f.3 : programming for vme slave address requirement register field a24 slave image base address vmebar a24ba a24 slave image size vmebar a24siz a24 slave image enable mode a24slven+vinen a32 slave image base address vmebar a32ba a32 slave image size vmebar a32siz a32 slave image enable mode vinen a64 slave image base address sa64bar - a64 slave image size always 4gb a64 slave image enable enabled by write to sa64bar+vinen bit in mode register
tundra semiconductor corporation app f-7 scv64 user manual initialization f.2.4 memory map overlay initialization the scv64's memory map overlay can be configured to enable or disable a24 and a16 vme access. in addition, a24 accesses may be configured as either in the first page or last page of cpu addresses. this is done through bits in the mode register: when a24 or a16 accesses are disabled, accesses in these areas become a32. a portion of the memory map overlay may also be set aside for vsb or other device selects. this is programmed through the bussel register. f. 2 . 5 b i - m o d e if was not tied low, and tied high as described above (see hardware configuration on page app f-1), then the scv64 will come out of reset in bi-mode. it can be removed from bi-mode through a single write to the scv64 location monitor, located in the upper longword of the a24 slave image and the a32 slave image. it may be written to from either the vme side (the location monitor is still accessible in bi-mode), or from the local side. if bi-mode is not to be used in a system, irq1* should be reconfigured to be a vme interrupt, instead of its default as a bi-mode initiator. this is done through clearing the vi1bi bit in the genctl register. f.2.6 retry*/vrmc configuration the retry*/ pin defaults as a proprietary read-modify-write pin, allowing multiple locked reads and writes at multiple addresses. instead, it may be configured as the vme retry* pin. setting the rmcpin bit in the mode register will configure this pin as the retry* pin. if this pin is configured as the retry* pin, vme style read-modify-writes may still be enabled through setting the tascon bit in the mode register. setting this bit forces low for multiple cycles while the local pin is held low. note that read-modify-write using this method can only be performed on a single address per cycle. table f.4 : address space enabling mode register bit effect when set effect when cleared a16di disable a16 accesses enable a16 accesses a24di disable a24 accesses enable a24 accesses a24po a24 accesses in top page a24 accesses in page 0 birel bitrig vrmc vas kmrc
initialization scv64 user manual app f-8 tundra semiconductor corporation f.2.7 other local options during deadlocked cycles (due to a coupled cycle coming from the vme bus while another is attempting to go out), the scv64 will force the local cycle to terminate through asserting and . read-modify-write cycles have the option of terminating with and or just with . the scv64 will default to asserting only kberr during read-modify-write lockups, but by setting the rmcretry bit in the mode register, these lockups will terminate with and . during reads initiated from the vmebus the designer may wish to check for data parity allowing the cycle to terminate. when the berrchk in the mode register is set, the scv64 will wait a further two clock cycles after dsack has been asserted before terminating the cycle on the vmebus with either berr* or dtack*. f.2.8 local bursts local burst of data from the rxfifo may be enabled by setting the fifoben bit in the mode register. when there are more than two mblt or four blt transfers queued in the rxfifo, and this bit is set, the blt and mblt data will generate local burst cycles. use the blen bits to limit the length of local burst to 4, 8, 16, or 32 longwords. f.2.9 local arbiter the scv64's internal arbiter, when not bypassed (in the arbiter bypass power-up mode), may be configured to use fair or demand arbitration between the scv64 and the external request, . when in demand mode, the external request has highest priority. local arbitration mode is controlled through the lbram bit in the ctl2 register. f.2.10 interrupts local and vme interrupt sources may be individually enabled using the lie, vie, and 7ie registers. all local general interrupt sources ( - ) may be mapped to interrupt levels using registers ic54, ic32, and ic10. vme interrupt levels are permanently mapped to the corresponding level on the local bus. as well, two general interrupt sources, and , may be configured as vectored, or auto-vectored sources through the ic54 register. kberr khalt kberr khalt kberr kberr khalt lbrq1 lirq0 lirq5 lirq4 lirq5
tundra semiconductor corporation app f-9 scv64 user manual initialization f.2.11 local timer functions the scv64 has a variety of timers, both for the vme and local buses. the watchdog timer, , is enabled using the endog bit in the misc register. the tick timer rate is set through the tickm bit in the ctl2 register and the tlen bits in the genctl register. finally, the local bus timer, used to time out local cycles, may be disabled through the ltoen bit in the genctl register. f.2.12 sysfail* assertion of the sysfail* pin is controlled through the sysfail bit in the misc register. it defaults to set, driving the sysfail* line. after completing diagnostics, the designer will want to clear this bit. f.2.13 vme requester the vme requester module may be configured for several options. the options available in the vreq register are: ? release on request vs. release when done ? fair or demand requesting ? ownership timer ? request level ? recognition of the bclr* signal as well, the l7imem interrupt source may be configured, through the memim bit in the ctl2 register, to force the requester to release the vmebus or have no effect. f.2.14 vme arbiter the scv64's vmebus arbiter may be configured for round robin, priority, or mixed mode arbitration with the varb register. this register also controls the arbitration time-out period: never, 16us, 32us, 64us, or disabled. wdog
initialization scv64 user manual app f-10 tundra semiconductor corporation
scv64 user manual tundra semiconductor corporation app g-1 appendix g reliability prediction this section is designed to help the user to estimate the inherent reliability of the scv64, as based on the requirements of mil-hdbk-217f. this information is recommended for personnel who are familiar with the methods and limitations contained in mil-hdbk-217f. the information serves as a guide only; meaningful results will be obtained only through careful consideration of the device, its operating environment, and its application. g.1 device description g.1.1 physical characteristics ? cmos gate array ? 54,184 gates ? 0.7m feature size ? 9.931mm x 9.931mm scribed die size g.1.2 thermal characteristics thermal resistance (junction to case) q jc 299-pin pin grid array (pga) 2.0c/w 304-pin plastic quad flat pack (pqfp) 2.0c/w thermal resistance (junction to ambient) q ja 299 pin pin grid array (pga) 19.3c/w 304-pin plastic quad flat pack (pqfp) 21.30c/w
reliability scv64 user manual app g-2 tundra semiconductor corporation power dissipation (worst case) 1.50w worst case power dissipation is defined as ? fully loaded vmebus backplane ? vdd = 5.5volts ? worst case data pattern (alternate ffff ffff, 0000 0000 on consecutive data transfer cycles) ? device is operating as a system controller. power dissipation (typical) system controller enabled 0.75w system controller disabled 0.50w g.1.3 latch-up current ? greater than 500ma per jedec standard no. 17 g.2 parameters the equation used for reliability predictions is found in section 5 of mil-hdbk-217f, in the subsection pertaining to microcircuits, gate/logic arrays and microprocessors. this equation incorporates the following parameters: mos digital and linear gate/logic array die complexity failure rate this parameter is derived from the number of gates in the scv64 (54,184). temperature factor derive this parameter from the tables provided using the worst case junction temperature of the device as above. package failure rate the number of functional pins (which equals power and ground pins subtracted from total number of pins) on the 299 pin pga is 230. we recommend using a value of 0.099 based upon the formula supplied for the pga package and the number of pins.
scv64 us e r manual r e l i abil i ty tund r a s e m i c ondu c to r c o r po r ati o n app g-3 e n v i r o n m e n ta l f a c tor t h is numbe r is d e r i v ed f ro m the t a bles supplied, an d requires kn o wledge of th e d e vice ope r a t in g e n viro n m e n t . o p e r a t in g e n vi r onm e n ts v ary wit h the applic a t i on, a nd selection o f this pa r a m e te r can onl y be determ i n e d b y th e e n d us e r . l e a r n i ng fa c tor the ca91c078a d e vice has been i n productio n sin c e de cemb e r 199 8 .
vmebus interface componentsscv64 user manual tundra semiconductor corporation app h-1 appendix h environmental and operating parameters warning: stresses beyond those listed above may cause permanent damage to the devices. these are stress ratings only, and functional operation of the devices at these or any other conditions beyond those indicated in the operational sections of this document is not implied. exposure to maximum rating conditions for extended periods may affect device reliability. warning: plastic packages should not be out of drypack for more than 48 hours at standard conditions of 45% rh and 25c. any packages out of drypack for extended time periods should be redried by baking in air for 12 hours at 125c. higher temperatures and longer times may cause solderability failures. table h.1 : recommended operating conditions dc supply voltage (v dd )5 v power dissipation 1.5 w ambient operating temperature (t a commercial) 0c to +70c ambient operating temperature (t a military) -55c to +125c table h.2 : absolute maximum ratings dc supply voltage -0.5 to 7.0 v input voltage (v in )-1.5 to v dd +1.5 v dc current drain per pin, any single input or output 100 ma dc current drain per pin, any paralleled outputs 100 ma dc current drain v dd and v ss pins 75 ma storage temperature, (t stg ) -65c to +150c ! !
vmebus interface componentsscv64 user manual tundra semiconductor corporation app i-1 appendix i revision history this revision of the scv64 users manual incorporates minor modifications from the previous revision. the changes reflect the correction of errata and the addition of new information. modifications are indicated by change barsi.e., horizontal lines in the left margin of the affected lines of text.
revision history scv64 user manual app i-2 tundra semiconductor corporation
vmebus interface componentsscv64 user manual tundra semiconductor corporation app j-1 appendix j mechanical and ordering information j.1 mechanical information figure j.1 : 299-pin cavity-down cpga package l a q a1 d1 square e square b index mark f dimension pga 299 ceramic a 0.090 in. 0.110 in. a1 b q (note 1) d1 0.905 in. e 2.040 in. 2.080 in. f l min. max. 0.105 in. 0.185 in. 0.112 in. 0.144 in. 0.055 in. 0.045 in. 0.895 in. 0.095 in. 0.175 in. 0.055 in. 0.045 in. c c 0.019 in. 0.017 in. 299 x .0.018 0.001 0.20 m c a a b 0.10 controlling dimensions in inches -b- -c- 0.004 a m m m note 1. this dimension applies to the 4 ceramic disks on pins b2, b19, w2, and w19, which are used to hold the device above the printed circuit board.
mechanical and ordering scv64 user manual app j-2 tundra semiconductor corporation figure j.2 : mechanical drawing for 304-pin pqfp package index mark e pin 1 e1 e3 m 0.20 c d d s a-b s 0.05 0.20 h a-b s d s l m a1 q r detail q l e b a a2 detail r 0.10 seating plane -c- n n base metal section n-n p g 0.10 c a-b s d s m -a, b, d- -h- -a- -b- -d- controlling dimensions in millimetres dimension 304 pqfp min. max. a 3.95 mm 4.5 mm a1 0.25 mm a2 3.60 mm 4.00 mm b 0.14 mm 0.30 mm e 0.50 mm e 43.00 mm 43.40 mm e1 39.90 mm 40.10 mm e3 37.5 mm g 0.10 mm l 0.70 mm .090 mm m 1.25 mm p 0.09 mm 0.20 mm
tund r a s e m i c ondu c to r c o r po r ati o n ap p j-3 scv64 us e r manual m e c han i c a l a n d o r d e r ing j .2 orde r ing i n f o rm a tion t undra products are d e signate d b y a pro d u c t cod e . when ordering, r e f er t o p r odu c ts by their f ull code. f or detailed mechanic a l dr a wings or alternat i v e p a ckagin g requirements, ple a se contact ou r f actor y directl y . v a lid s u f f i x es f o r c a 91c078a x y z 25 i q 25 e g 33 c g, q 33 i q 33 e g 40 c g, q ca91c0 7 8 a - x y z p a r t n u m b e r s peed 25 mhz 33 mhz 40 mhz p a c kaging g - pga ( ce r am i c) q - qfp (p l as t i c) exc i s e d f r om mcr t e m p erat u re c - comme r c i a l ( 0 t o 7 0c) i - i ndus t r i a l ( -40 t o 8 5 c) e - ex t end e d t e m p . ( - 55 to +12 5 c)
mechanical and ordering scv64 user manual app j-4 tundra semiconductor corporation
vmebus interface componentsscv64 user manual tundra semiconductor corporation index-1 numerics 122 2-89 a a16 2-45, 2-49, 2-74 a16di 2-45 a24 2-45, 2-51, 2-61, 2-99, 2-104, 2-118 a24di 2-45 a24slven 2-52 a32 2-45, 2-49, 2-51, 2-52, 2-61, 2-101, 2- 104, 2-118 a64 2-43, 2-49, 2-50, 2-54, 2-61, 2-104 a64bardy 2-50 abi 2-13, 2-20, 2-119 access protection 2-52 specifying 2-52 acfie 2-20 acfip 2-21 acfis 2-21 address offset 2-75 address translation scv64 as vme master 2-53 scv64 as vme slave 2-58 apbr 2-88 arb0 2-32 arb1 2-32 arbbyp 2-66 arbitration modes 2-31 br3* priority 2-33 br3*, br2* priority 2-33 full priority arbitration 2-32 full round robin 2-32 as* 2-57 aten 2-33 autobar 2-51, 2-118 auto-id 2-121 self test 2-123 automatic base address programming 2-51 , 2-118 b baudclk 3-5 bbsy* 2-9, 2-10, 2-33, 3-1 bcen 2-10 bclr 2-57 bclr* 2-8, 2-10, 2-32, 2-33, 3-1 berr* 2-39, 2-43, 3-1 berrchk 2-77, 2-108 bg0in* 2-35 bg1in 2-34 bg2in 2-34 bg2in* and bg1in* external inputs 2-34 bg3in* 2-30 bg3in*-bg0in* 3-1 bg3out*-bg0out* 3-2 bgnin* 2-111 bgnout* 2-9 bie 2-20 bimode 3-5 bi-mode 2-4 , 2-100, 2-119 index entries in bold type-face indicate definitions.
index scv64 user manual index-2 tundra semiconductor corporation bi-mode effects 2-14, 2-29, 2-63 birel 3-5 bis 2-21 bitrig 2-119, 3-5 blen 2-41, 2-89, 2-106 blen1 2-90 blkst 2-106 blt 2-44, 2-54, 2-61, 2-102, 2-104 blt and mblt dma transfers 2-43 br 3C0* 3-2 br0* 2-32 br1* 2-32 br2* 2-32 br3* 2-32 burst mode 2-4 dma transfers 2-106 local bus mastership 2-60 maximum burst length 2-41 reads 2-44, 2-60, 2-89 termination 2-89 writes 2-60, 2-90 burst reads termination 2-89 burst writes 2-41, 2-44 termination 2-93 bussel 2-49, 2-88 bussiz 2-55, 2-59, 2-74 byte lane translation 2-54 scv64 as vme master 2-54 scv64 as vme slave 2-59 byte lanes 2-54 byte lanes 2-59 c c14us 3-5 c32mhz 3-5 c8mhz 3-5 cerr 2-17 clocks 2-113 clrdog 2-116 clrtik 2-115 coupled mode 2-36 cpu memory map 2-45 ctl2 vmebus busy 2-8 d d16 2-45, 2-61, 2-104 d32 2-45, 2-61, 2-104 d64 2-61, 2-104 d64(mblt) 2-104 dcsr 2-36, 2-58, 2-62, 2-64, 2-77, 2-88, 2- 99, 2-101, 2-108, 2-126, 2-127 decoupled mode 2-36 disrx 2-41, 2-105, 2-127 dlber 2-17, 2-78, 2-109 dlct 2-89 dlst1 2-89, 2-124 dlst2 2-89 dlst3 2-89 dma controller 2-2 dma transfers completion and error checking 2-108 data transfer counts 2-107 initialization 2-102 dma24 2-105 dmaa64 2-49, 2-105 dmaben 2-89, 2-106 dmad 2-105 dmago 2-108 dmalar 2-61, 2-88 dmard 2-103, 2-105
tundra semiconductor corporation index-3 scv64 user manual index dmatc 2-64, 2-88, 2-104, 2-107 dmavar 2-61, 2-88, 2-104 dmavtc 2-88, 2-104, 2-107 vmebus dma transfer count 2-107 done 2-17, 2-64, 2-108 dpriv 2-105 dtack* 2-31, 2-39, 3-2 dtcsiz 2-107 dynamic bus sizing 2-74 e endog 2-116 external inputs 2-34 off-board reset 2-35 extkiack 2-117 extrst 2-110, 3-5 f fair and demand modes 2-5 , 2-9 fifoben 2-41, 2-90, 2-106 fill 2-42, 2-56, 2-107 fill mode 2-56, 2-107 g genctl tick timer 2-116 general local interrupts level mapping 2-21 i iack daisy chain driver 2-31 iack* 2-121, 3-2 iackin* 2-31, 2-122 iackout* 2-31, 2-122 ic10 2-16, 2-21, 2-22, 2-88 local interrupt level mapping 2-16 ic32 2-16, 2-21, 2-89 local interrupt level mapping 2-16 ic54 2-16, 2-21, 2-89 local interrupt level mapping 2-16 id register 2-88 id register 2-122, 2-123 idgot 2-122 idtst 2-123 interrupt acknowledge cycles auto-id 2-121 auto-vectored 2-25 local decoding 2-22, 2-117 vectored 2-26 interrupt vector local interrupter 2-27 vme interrupter 2-27 interrupter 2-13 local interrupts 2-15 vmebus interrupts 2-13 interrupts auto-vectored 2-25 local timing 2-27 vectored 2-26 vme timing 2-28 ip 2-21 irq 7C2* 3-2 irq1* 2-13, 2-119, 2-121 ivect 2-14, 2-88 j jtclk 3-5 jtd0 3-5 jtd1 3-5
index scv64 user manual index-4 tundra semiconductor corporation jtms 3-6 k kaddr 31 C 00 3-6 kas 2-69, 2-73, 2-80, 2-83, 2-89, 2-93, 2- 99, 3-6 kavec 2-77, 3-6 kberr 2-77, 3-6 kbgack 2-69, 2-71, 3-6 kbgr 2-66, 2-69, 2-71, 3-6 kbrq 2-66, 2-71, 3-6 kclk 3-6 kdata 31 C 00 3-6 kds 2-73, 2-80, 2-83, 2-89, 2-93, 3-7 kdsack1 2-89, 2-93 kdsack1-0 3-7 kdsackx 2-80, 2-83 kfc2-kfc0 2-73 khalt 2-77 kipl2-0 3-7 krmc 3-7 ksiz0-ksiz1 2-73 ksize 1 C 0 3-7 kwr 3-7 l l7imem 2-11, 3-8 l7inmi 3-8 lberr 2-17, 2-41, 2-77, 2-109 lbgr1 2-66, 3-8 lbram 2-69, 2-71 lbrq1 2-66, 2-71, 3-8 liack5-4 3-8 lie 2-20, 2-88 interrupt enabling 2-20 lirq5-0 3-8 lirq5-lirq0 2-21 lis interrupt status 2-20 lmfifo 2-1, 2-4 , 2-88, 2-99, 2-101 lmfifo entries 2-62 lmhd 2-16, 2-62, 2-99, 2-101 lmint 2-7, 2-16, 2-62, 2-99, 2-101, 3-8 local 2-115 local 2-7, 2-29, 2-114 local arbiter bypass 2-66, 2-118 local bus arbitration 2-66 arbiter state machine 2-67, 2-71 external requests 2-71 internal requests 2-67 local bus cycles data transfer 2-74 initiation 2-73 termination 2-76 local bus mastership 2-60, 2-61 arbitration 2-66 local bus timer 2-7, 2-29, 2-114 local reset 2-110 location monitor 2-4 , 2-101 access 2-62, 2-99 lmfifo 2-62 lmint 2-62 lpbk 2-127 lrst 2-110, 3-8 ltoen 2-115 lvl0 2-9 lvl1 2-9 lword* 2-14 m master/slave deadlock 2-61, 2-77, 2-98
tundra semiconductor corporation index-5 scv64 user manual index mblt 1-3 , 2-2, 2-39, 2-43, 2-61, 2-89, 2- 102, 2-104, 2-106 mbox0 2-89 mbox1 2-89 mbox2 2-89 mbox3 2-89 memie 2-20 memip 2-21 memis 2-21 mybbsy 2-8 n nmiclr 2-20 nmiis 2-21 nmip 2-21 no release option 2-57, 2-108 norel 2-57, 2-108 o ot0 2-11 ot1 2-11 oten 2-11 p power-up reset 2-111 prot 2-52 pwrrst 2-30, 2-111, 3-8 pwrup 2-111 r r 2-115 ramsel 2-83, 2-87, 2-99, 3-9 read modify write 2-57, 2-60 scv64 as vme master 2-57 scv64 as vme slave 2-60 receive fifo (rxfifo) 2-2 , 2-36 shift 2-41 reflected cycles 2-49 , 2-99 register access 2-87 registers 7ie interrupt enabling 2-20 7is interrupt status 2-20 apbr access protection 2-52 bussel vsb space 2-49 ctl2 local arbitration 2-69 tick speed 2-115 dcsr dma completion and error checking 2-108 dma initialization 2-102 error bits 2-16 location monitor access 2-99, 2-101 rxfifo shift 2-41 vmebus error 2-43 dmatc dma transfer count 2-107 genctl auto-id test 2-123 bi-mode 2-119 irq1* programming 2-13 local bus timer 2-115 software reset 2-110, 2-111 ivect interrupt vector 2-14 lag local address generator 2-105 ma64bar dma addressing 2-43 dma transfers 2-61, 2-104
index scv64 user manual index-6 tundra semiconductor corporation mode a16 disabling 2-45 a24 disabling 2-45 access protection 2-52 coupled mode 2-39 decoupled mode 2-39 dma transfers 2-104 fill mode 2-56 fill option 2-107 no release option 2-57, 2-108 rmw control 2-57 rmw retry 2-62, 2-98 rxctl, rxaddr, rxdata rxfifo entry 2-40 sa64bar a64 base address 2-50 stat1 auto-id 2-122 bg2in*, bg1in* status 2-34 external status 2-34 power-up reset 2-111 syscon indicator 2-30 txctl, txaddr, txdata txfifo entry 2-42 varb ownership timer 2-34 vreq demand mode 2-9 fair mode 2-9 release modes 2-10, 2-11 request levels 2-9 vmebus ownership timer 2-11 rel 2-10 release on acknowledgment (roak) 2-5 , 2-14 release on request (ror) 2-5 , 2-10, 2-57 release when done (rwd) 2-5 , 2-10, 2-57 request and release modes 2-8 reset effects 2-14, 2-29, 2-33, 2-35, 2-112 retry 2-57, 2-60, 2-97 retry* 2-57, 2-58 retry*/vrmc 3-4 rmcerr 2-17 rmcpin 2-57, 2-60, 2-97 rmcretry 2-61, 2-98 rxaddr 2-40, 2-88, 2-127 rxatom 2-39, 2-103, 2-105 rxctl 2-40, 2-88, 2-106, 2-127 rxdata 2-40, 2-88, 2-127 rxrst 2-36 rxshft 2-41, 2-127 s sbi 2-119 scv64 as local master rxfifo 2-83 txfifo 2-83 scv64 as local slave local bus interface 2-78 rxfifo 2-78 txfifo 2-78 scv64 as vme master address translation 2-53 coupled mode 2-41 decoupled mode 2-42 scv64 as vme slave 2-39, 2-58 address translation 2-58 coupled mode 2-39 decoupled mode 2-39 scv64sel 2-87, 3-9 sequential consistency 2-40 siz 2-64 spc 2-64 stat0 2-20, 2-88, 2-115 status/id 2-31 super 2-64 swap 2-54, 2-59 swrst 2-110
tundra semiconductor corporation index-7 scv64 user manual index syfie 2-20 syfip 2-21 syfis 2-21 sysc 2-30 syscon determination 2-30, 2-118 sysfail 2-18, 2-20, 2-21, 2-120 sysfail* 3-3 sysfled 3-9 sysrst* 2-30, 2-35, 2-52, 2-110, 2-111, 2- 118, 3-3 system clock driver 2-34 t tascon 2-57, 2-97 tick 3-9 tickm 2-115 timers 2-115 arbitration 2-33 tick timer 2-115 vmebus ownership 2-34 watchdog timer 2-116 tlen 2-116 tmode1-0 3-9 transmit fifo (txfifo) 2-2 , 2-36 txaddr 2-42, 2-64, 2-88, 2-126 txatom 2-41, 2-103, 2-105 txctl 2-42, 2-64, 2-88, 2-126 txdata 2-42, 2-64, 2-88, 2-126 txhd 2-65 txrst 2-36 txshft 2-65, 2-126 type 2-64 v vaddr 31 C 01 3-3 vaddrout 2-53, 2-58, 3-3 vam 5 C 0 3-3 vas 2-57, 3-3 vberr 2-17, 2-41, 2-58, 2-64, 2-109, 2- 126, 2-127 vdataout 2-53, 2-58, 3-4 vds 3-4 vi1 2-13, 2-20 vie 2-20, 2-88 vinen 2-52 vint 2-13, 2-88, 2-128 vlword 3-4 vme accesses a16 2-45 a24 2-45 a32 2-45 a64 2-49 d16 2-45 d32 2-45 vme base addressing a24 2-50 a32 2-50 a64 2-50 vme slave image 2-49 vmebar 2-49, 2-51, 2-88 vmebus arbiter 2-31 vmebus interrupts generation 2-13 vmebus mastership 2-56 vmebus ownership timer 2-11 vmebus requester 2-8 vmeint 2-7, 2-16, 2-41, 3-9 vmeout 2-80, 2-99, 2-101, 3-10 vsb bus accesses 2-49, 2-100 vsbsel 2-49, 2-100, 3-10 vstrbout 2-53, 2-58, 3-4 vwr 3-4
index scv64 user manual index-8 tundra semiconductor corporation vxl0 2-34 vxl1 2-34 w wdog 3-10

▲Up To Search▲

Price & Availability of CA91C078A-33EG

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