PEB20534 - Infineon Technologies

ICs for Communications

Using the DEMUX Interface Option of Siemens’ PCI based

Protocol Controllers

MUNICH32X PEB 20321

MUNICH128X PEB 20324

DSCC4 PEB 20534

Applic ation Note 03.99 DS 1

For questions on technology, delivery and prices please contact the Semiconductor Group Offices

in Germany or the Siem ens Compani es and Representatives world wide: see our webpage at

http://www.siemens.de/semiconductor/communication

PEB 20321, PEB 20324, PEB 20534

Revision History: Current Version: 03.99

Previou s Version:

Page

(i n prev ious

Version)

Page

(in current

Version)

Subjec ts (major changes since last re vision)

Edition 03.99

P ub l ishe d by Siemens AG,

HL SC,

Balanstraße 73,

81541 München

Attention please!

As far as patents or other rights of third parties are concerned, liability is only assumed for components, not for

applications, processes and circuits implemented within components or assemblies.

The information describes the type of component and shall not be considered as assured characteristics.

Terms of delivery and rights to change design reserved.

Due to technical requirements components may contain dangerous substances. For information on the types in

question please contact your nearest Siemens Office, Semiconductor Group.

Siemens AG is an approved CECC manufacturer.

Packing

Please use the recycling operators known to you. We can also help you – get in touch with your nearest sales

office. By agreement we will take packing material back, if it is sorted. You must bear the costs of transport.

For packing material that is returned to us unsorted or which we are not obliged to accept, we shall have to invoice

you for any costs incu rred.

Components used in life-support devices or systems must be expressly authorized for such purpose!

Critical components1 of the Semiconductor Group of Siemens AG, may only be used in life-support devices or

systems2 with the express written approval of the Semiconductor Group of Siemens AG.

1 A critical component is a component used in a life-support device or system whose failure can reasonably be

expected to cause the failure of that life-support device or system, or to affect its safety or effectiveness of that

device or system.

2 Life support devices or systems are intended (a) to be implanted in the human body, or (b) to support and/or

maintain and sustain human life. If they fail, it is reasonable to assume that the health of the user may be en-

dangered.

ABM®, AOP ®, ARCOFI®, ARCOFI®-BA, ARCOFI®-SP, DigiTape®, EPIC®-1, EPIC®-S, ELIC®, FALC®54, FALC®56,

FALC®-E1, FALC®-LH, IDEC®, IOM®, IOM®-1, IOM®-2, IPAT®-2, ISAC®-P, ISAC®-S, ISAC®-S TE, ISAC®-P TE,

ITAC®, IWE®, MUSAC®-A, OCTAT®-P, QUAT®-S, SICAT®, SICOFI®, SICOFI®-2, SICOFI®-4, SICOFI®-4µC,

SLICOFI® are registered trademarks of Siemens AG.

ACE™, ASM™, ASP™, POTSWIRE™, QuadFALC™, SCOUT™ are trademarks of Siemens AG.

PCI based Controllers in de-multiplexed Operation
Table of Conte nts Page
Semico nductor Group  3 Appli cation Note 03.99
1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
2 P CI Control  Signal s Descript ion   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
2Differences betw een PCI- and DEMUX-Operation  . . . . . . . . . . . . . . . . . .6
1 Sepa rat e Address Bus and 32 Bi t Dat a Bus  . . . . . . . . . . . . . . . . . . . . . . . . .6
2 Different Function of the C/BE(3:0) signals  . . . . . . . . . . . . . . . . . . . . . . . . . .7
3 Function of the addi tional W/R# Signal  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
4 Different Function of Signal IDSEL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
5 No Evaluation / Generation of  Parity  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
6 Burst Limitation  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
3Signals to provide to Glue Logi c  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
4Detail led Description of DEMUX Bus States . . . . . . . . . . . . . . . . . . . . . .10
1 Bus State: Take over Busmastership (Arbitration) . . . . . . . . . . . . . . . . . . . .10
2 Bus State: Transaction Start  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3 Bus State: Data Transfer  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
4 Bus State: Wait State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
5 Bus State: Transaction End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
6 Complete Transactions  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
7 First cycles after reset and basic device initialization  . . . . . . . . . . . . . . . . .12
7.1 Device Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
7.2 Build memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
7.3 En abling master and slave funtions  of the device  . . . . . . . . . . . . . . . . . .14
7.4 Setting latency timer  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
7.5 Interrupt Line  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
7.6 Device Driver Initialization  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
5Device specific di ffere nces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
1 MUNICH32X  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
2 MUNICH128X  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3 DSCC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
6Application Examples for de-multiplexed Bus Operation  . . . . . . . . .  . .16
1 Connection to the MC68360 de-multiplexed Interface . . . . . . . . . . . . . . . . .16
1.1 MC68360 Signals Description  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
1.2 Bus Arbitration Flow Chart for Single Request   . . . . . . . . . . . . . . . . . . . .18
1.3 Bu s Arbi tration between MC683 60 and Dem ux-Interface  . . . . . . . . . . . .18
1.3. 1 Arbit er GA L Logic   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
1.3.2 Simulation of Arbiter GAL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
1.4 Master  GAL  Logic  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
1.4.1 Simulation of Master GAL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
1.5 Slave GAL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

PCI based Controllers in de-multiplexed Operation
Semico nductor Group  4 Appli cation Note 03.99
 
1.5.1 Simulation of Slave GAL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
2 Connection to Intel i960 de-multiplexed Interface  . . . . . . . . . . . . . . . . . . . .29
2.1 i960 Contr ol Si gnals   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
2.2 Logic for Arbiter GAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
2.2.1 Simulation of  Arbiter GAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
2.3 Logic for Master GAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
2.3.1 Simulation of Master GAL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
2.4 Logic for Slave GAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
2.4.1 Simulation of Slave GAL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
7Burst functional ity of the Demux-Interface . . . . . . . . . . . . . . . . . . . . . . .40
1 Incrementing Address lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
2 Handling addr ess count er overflows  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

PCI based Controllers in de-multiplexed Operation

Overview

Semico nductor Group 5 Appli cation Note 03.99

1 Overview

The SIEMENS PCI based protoc ol contr ollers MUNICH3 2X, MUNICH128X and DSCC4

may be configured for 33 MHz/32-bit de-multiplexed (’DEMUX’) bus operation for

connection to non-PCI systems with de-multiplexed processors such as the Intel’s

i960Hx or Motorola’s M C 68EC0x0 and M P C860. The de-multiplexed bus interface uses

majorly the control signals of the PCI bus, so some glue-logic is needed to adapt these

control signals to any 32 bit non-PCI microprocessor bus. The intension of this

application note is to support the hardware designer to implem ent this glue-logic either

into GALs or into an FPGA, which is often already part of the design.

Although the designer implementing this de-multiplexed bus interface is not always

familiar with the PCI bus standard, it is recommended to look up a few operational

explana tions in the PCI specif ication Rev. 2.1 . There will be given refer ences to the most

helpful parts of the PCI specification in this document.

1.1 Terminology

Bus Master

is the device, that is granted the bus for one (or more) transaction. All

other devices connected to the bus are

Bus Slaves

in that moment.

With

Bus Transaction

a complete cyc le of eit her a Read or a Write operation i s m eant,

from the first to the last clock cycle.

The curren t Bus Master is the

Initiator

of a

Bus Transaction

, which addresses one of the

Bus Slaves

as the

Targe t

for the intended Read or Write Transaction.

Bus Transaction

consists of one

Address Phase

and one

Data Phase

, where the

Address Phase

takes place in the first clock cyc le of a

B us Transaction

, fol lowed by the

Data Phase

In the Data Phase the transfer of data takes place. If only one 32bit word (

Long Word

)

is to be transferred, the

Data Phase

is lim ited to 1

Data Transfer

cycle. Nevertheless

one

Data Pha se

may consist of more than one

Data Tra nsfers

, called a ’

Burst’

. Th e Data

is writt en to or read fr om consecuti ve address es in the Targ et. Both, the

Initiator

and the

Target

have to auto-increment the address by 04h for each

Long Word Data Transfer

1.2 PCI Control Signals Descri ption

FRAME: Fram e is driven by the current initiat or a nd ind icates the start (whe n it is first

asserted) and duration (the duration of its assertion) of a transaction. In

order to determine the bus ownership has been acquired the master must

sample FRAME and IRDY b oth de- assert ed and GNT asse rted o n t he sam e

rising edge of the CLK. A transaction may consist of one or more data

transfers between the current initiator and target. Frame is de-asserted

when the ini tiator is ready to complete the final data phase.

PCI based Controllers in de-multiplexed Operation

Overview

Semico nductor Group 6 Appli cation Note 03.99

TRDY: Target ready i s dr iven by t he curr ently- addres sed t arget. It is ass erted whe n

the target is ready to complete the current data transfer. A data transfer is

completed when the target is asserting TRDY an d the init iato r is ass erti ng

IRDY at the r i sing edge of the clock. Dur ing a re ad TRDY as ser ted ind icates

that the target is driving valid data. During a write TRDY asserted indicates

the target is ready to accept the data from the master.

IRDY: Initiator ready is driven by the current bus master. During a write, IRDY

asserted indicates that the init iator i s driving valid data on the bus. During a

read IRDY asserted indicates that the initiator is ready to accept data from

the target.

STOP: The target asserts STOP to indicate that it wants the initiator to stop the

transaction in progress.

IDSEL: This signal is used as a chip select during an access to one of the device’s

configuration register (PCI configuration space; refer to chapter 6 in PCI

specification Rev 2.1).

DEVSEL: Device select is asserted by a target when the target has decoded its

address. It is an input to the current initiator. If a master initiates a transfer

and does not detect a DEVSEL within 6 clock cycles it assumes that the

target cannot respond (refer to chapter 3.3.3.1, Figure 3-4 in PCI

specification Rev 2.1).

C/BE(3:0): In the address phase these signals contain the command for the initiated

PCI cyc le (e.g. if t he the cycl e is a mem ory r ead, m emory wite, confi gurat io n

read or configuration write cycle, there are much more combinations and

commands specified) during the data phase the signals contain the byte

enable information, one for each octet of the AD lines. If BE0 is asserted

data is transfered on AD(7:0). If all 4 lines are asserted a whole 32 bit word

is t ransf ered on AD(31: 0). In demulti plexed inte rface mode t his si gna ls hav e

a only byte enable function dur ing the data phase.

REQ: If a master (e.g. the Demux-Interface of the SIEMENS protocol controller)

wants to transfer data on the PCI bus it request the bus control via this line

from the central bus arbiter.

GNT: When t his si gnal i s assert ed from t he arbi ter to the devi ce, the devi ce wil l be

next bus master. It im mideatly can start the transfer if the PCI bus is idle. If

currently a PCI transaction from the previous master is active, the new

master will st art its transaction af terwards.

DWord:

DWord

is used as a short form for Double Word and represents a 32 bit

word.

PCI based Controllers in de-multiplexed Operation

Diff erences bet w een PCI- and DEMUX-Op eration

Semico nductor Group 7 Appli cation Note 03.99

2 Differences between PCI- and DEMUX-Operation

The devi ce ca n be sw itched into d e-mult iplex ed ope rati on by conne cting the DEMUX (or

DPCI[0]) pin to VDD. If the device is working in a PCI environment, this pin has to be

connected to VSS.

The de-multiplexed bus interface is a synchronous interface similar to the PCI bus with

the exceptions listed in the following chapters. Beside these exceptions all control

signals and timings are equal to PCI bus interface mode. For a basic understanding of

bus transactions it is recommended to read chapter 3.3.1 (Read Transactions) and

chapter 3.3.2 (Write Transactions) of the PCI Local Bus Specification, Rev. 2.1.

2.1 Separate Add ress Bus and 32 Bit Data Bus

The address for an inten ded trans action is driven on or taken from the additional addr ess

bus, A[ 31..2] for MUNICH32X a nd DSCC4; A[27..2] for MUNICH128X. The address lines

are vali d for the complete transacti on, i.e. during addr ess phase and data phase. When

MUNICH128X is addressed as a slave, it evaluates the address on the first clock cycle

with FRAME# asserted.

2.2 Different Function of the C/BE(3:0) signals

The C/BE(3:0) signals have only a Byte Enable function BE(3:0) in demultiplexed

interface mode during the data phase. During the address phase (first clock cycle with

active FRAME signal) this signal will not be evaluated in slave mode and shall not be

evaluated by the glue logic when the device acts as bus m aster.

2.3 Fun ction of the additional W/R# Signal

The W/R# input/out put signal replaces the func tion of the four bit PCI c om m and on pins

C/BE#[3. .0]. In maste r op eration t hi s addit ional signal stays valid unt il the cor re spondin g

write/read transaction is completed. When being bus slave, it is evaluated with the first

clock of the tr ansacti on. Th e Byte Ena ble s C/BE#[3 ..0] have to be dr iven l ow d uring data

is tra nsferred to the MUNICH128X, in dicating t hat 32 bit tran sfers take place.

2.4 Different Function of Signal IDSEL

The pin IDSEL has the function of a chip-select for the configuration space registers of

the device (refer to the corresponding section "PCI Configuration Space Register

Overview" in the data sheet). As mentioned above, it is not neccessary to supply the

configuration cycle command on C/BE(3:0) in the address phase like in PCI

envir onments. Progr amming the conf iguration space is also nece ssary in de-multipl exed

bus operation, since the device e.g. has a built-in chip-select logic which decides

whether bei ng addres sed or not by direc tly evaluating the bus address.

PCI based Controllers in de-multiplexed Operation

Diff erences bet w een PCI- and DEMUX-Op eration

Semico nductor Group 8 Appli cation Note 03.99

2.5 No Evaluation / Generation of Parity

The parity signal PAR is no t generated as a mast er and it is not eval uated as a slave. A

pull- up resi stor should be connect ed to this pin.

2.6 Burst Limitation

Burst capability has only to be taken into accout for transfers initiated by the protocol

controller , i .e. when the device is reading from/writing to the ho st mem ory. Burst s to the

on-chip regist ers are not all owed.

The number of 32bit words bursted consecutively on the de-multiplexed processor

interface can be limited depending on the device. Optionally the burst limitation can be

disabl ed, i .e. t he devic e behav es li ke in a PCI envir onment and perf orms (due to inter nal

architecture) its maximum count of bursts. Anyway the burst length can be limited by

asserting the STOP# signal to the Demux-Interface, as described in the PCI Local Bus

Specification Rev. 2.1, chapter 3.3.3.2. The following table gives an overview on the

diff erent burst featur es of Siemens’ PCI based Controllers i n dem ult iplexed bus mode:

Table 1

Device max. Dem ux

Burst

Capability

Demux Burst

Enable by

Demux Burst

Limitation to1)

1) Anyway for eac h devic e the Dem ux Bur st can be l im ited to 1 (sin gle tran sfer s only) by setti ng CO NF.D BE=0

or GMODE.DBE=0.

Demux Burst

Limitation by

MUNICH32X 3 CONF.DBE=1 - -

MUNICH128X 8 CONF.DBE=1 4 CONF.DBL=12)

2) CONF.DBL is only valid if CONF.DBE=1.

DSCC4 4 GMODE.DBE=1 - -

PCI based Controllers in de-multiplexed Operation

Signals to provide to Glue Logi c

Semico nductor Group 9 Appli cation Note 03.99

3 Signals to provide to Glue Logic

The fol lowing block di ag ram gives an ov erall overvi ew of t he signa ls that may have to be

generated and/or evalu ated by glue logi c, dependi ng on the system enviro nm ent.

Figure 1 Glue Logic for the Demultipl exed Inte rface

If possible, provide all the PCI control signals to your glue logic. It may e.g. happen that

systems h ave to as sert the ST OP# signal to the MUNICH12 8X, when t hey cannot accept

data (or a burst of 4 long words). This depends very much on the system environment.

Note: The examples in this application note use the demultiplexed interface without

burst functionality only to present the basics as simple as possible. A special

chapter will inform about the neccessary add-ons for using the burst capability of

the devices.

gluelogic.wmf

DEMUX-

INTERFACE

as Slave

FRAME#

DEMUX-

INTERFACE

DEMUX-

INTERFACE

as Master

Determin

Bus Master

REQ#

GNT#

Bus Request

Bus Grant

DEMUX-INT.

is Bus Master

IRDY#

TRDY#

W/R#

IDSEL

DEVSEL#

Write / Read#

"Chip Select" for PCI Config Space

A[27:2]

D[31:0]

A[27:2]

D[31:0]

A[31:28] (hardcoded) STOP#

PCI based Controllers in de-multiplexed Operation

Detailed Description of DEMUX Bus States

Semiconductor Group 10 Application Note 03.99

4 Detailed Description of DEMUX Bus States

This chapter will introduce to the major different bus states that are determined and

generated by the Dem ux-Interface. A basic understanding of these o perating behaviors

is necessary to adapt the device to your processor environment.

4.1 Bus State: Take over Busmastership (Arbitration)

The bus is requested by t he Demux-Int erface by ass erting th e REQ# signal. By providing

an activ e GNT# to the chi p, it i s owner of the bus by the next time t he bus is idl e until th e

transa ction is finished, eve n if GNT# is de-a sserted earlier. The arb itration st rategy is not

part of the PCI specifi cation and is sy stem dependent .

4.2 Bus State: Transaction Start

Any bus tr ansa ction star ts wit h a high- to-l ow trans iti on of the low-act ive FRAME# si gnal .

The Demux-Interface as a bus master will provide the address and a valid W/R# signal

from the first clock of the transaction until the last data transfer has been completed.

Being a bus slave, the Demux-Int erfac e eval uates t he addres s and W/ R# infor mation o n

the first clock cyc le, where FRAME# i s asserted.

The addressed t arget device has to asse rt the DEVSEL# line in order t o announce, that

it has decoded its address, within 3 clock cycles after the Address Cycle. For

transactions, in whi ch the protocol controll er is the i nitiat or, this signal mus t be provided

to the devi ce in time (re fer to PCI Specification 2.1, chapt er 3.3.3.1).

4.3 B u s State: Data Transfer

Any time during the Data Phase, when both the TRDY# and the IRDY# (or both) signal

are asserted, the corresponding clock cycle is a valid data transfer and data has to be

transf ered on rising edge of clock by both, t he Ini tiator of the tra nsfer and the Target.

4.4 B u s State: Wait State

Any time during the Data Phase, when either the TRDY# or the IRDY# (or both) signal

is de-asserted, the corresponding clock cycle is not a valid data transfer and has to be

discar ded by both, the Init iato r of the transf er and the Tar get. Wit h these two si gnals i t is

easy to ins ert neces sary Wait Stat es.

If t he Dem ux-Interface i s the Initi ator o f a transfer reading or writi ng to the host m emory,

the system may delay thi s process by not asserting the TRDY# signal to the device.

When the Demux-Interface is the Target (e.g. being read or written to by the CPU), the

processor environment must take Wait States forced by the Demux-Interface into

consideration. This is the case, when the device drives its TRDY# signal inactive (i.e.

high).

PCI based Controllers in de-multiplexed Operation

Detailed Description of DEMUX Bus States

Semiconductor Group 11 Application Note 03.99

Normall y there i s no need for th e Ini tiat or to in sert Wait States by de-as ser ting its I RDY#

signal .

4.5 Bus State: Transac tion End

Once the init iator de- asserts the FRAME # signa l, the next data trans action performed is

the last one. If n o burst capability is used, the FRAME# can be de- assert ed immedi ately

after the first cl ock cycl e, the addre ss phas e. A bus tr ansacti on is comple ted with a vali d

data tr ansfer during FRAME# being inactive.

As mentioned before, the GNT# signal can not be used to te rminate a transaction.

4.6 Com plete Transacti ons

A single read and write transaction is shown below. Starting the transaction with the

FRAME# signal and address phase the data is transfered during active signals IRDY#

and TRDY#. The tra nsaction is terminated wi th t his single data tr ansfer.

Figure 2 Single Read and Write transaction

Address

0ns 100ns 200ns

CLK

FRAME

D(31:0) Address

(don’t care)

Data Address

(don’t care)

Data

A(31:2)

BE(3:0)

W / R

IRDY

TRDY

Address

BE(3:0) BE(3:0)

Read Access Write Access

DEVSEL

singlerw.wfm

PCI based Controllers in de-multiplexed Operation

Detailed Description of DEMUX Bus States

Semiconductor Group 12 Application Note 03.99

A burst transaction transfers multiple data within the data phase. In each clock cycle in

which bot h IRDY# and TRDY# are asserte d one singl e DWORD is being t ransfe red . For

insertion of waitstates IRDY#, TRDY# or both the signals have to be deasserted. The

burst terminates after the la st data tr ansfer which is started by de assert ing the FRAME#

signal.

Figure 3 Burst Read/Writ e transaction wit h w aitstate i n sertion

4.7 First cycles after reset and basic device initial ization

Before t he device re gister s can be accesse d the standa rd PCI init ial izati on procedu re of

the configuration space has to be done. For the register mapping in the configuration

space used in this descriptions please refer to PCI specification 2.1 or the appropriate

data sheet of the con trolle r device . For example th e steps 1. .5 could be done by a ce ntral

bios function f or al l devices, step 6 then is done by each specifi c device driver.

1. Device Identifi cation (Pl ug and Play suppo rt)

2. Build memory map (Determining valid base addresses and required address range

and setting all neccessary base addresses).

3. Enabling master and slave functions of the device

4. Setting latency timer

0ns 100ns 200ns

CLK

FRAME

D(31:0) Address

(don’t care)

Data 1 Data 3 Data 4

A(31:2)

BE(3:0)

W / R

IRDY

TRDY

BE(3:0)

WRITE / READ Access

Address

BE(3:0)

Data 2

BE(3:0)

Waitstate

DEVSEL

burstrw.wmf

PCI based Controllers in de-multiplexed Operation

Detailed Description of DEMUX Bus States

Semiconductor Group 13 Application Note 03.99

5. Interrupt Line

6. Device Driver Initialisation

4.7.1 Device Identification

The device is identified by s everal fields in the prede fined header. Generic configuratio n

software will be able to easily determine what devices are available on the bus.

Vendor ID

This field identifies the manufacturer of the device. SIEMENS devices

use the value 110Ah.

Devi ce ID

This field identifies the particular device. This identifier is allocated by

SIEMENS to the following values:

Revi sion ID

This register specifies a device specific revision identifier. Generic

softwa re may us e this v alue to be have tol erant t o slig ht versi on changes

(refer e.g. to appropriate delta sheets of the devices)

Header Type

For detai led desc ri ption please refer t o PCI-Specification 2.1.

Class C ode

For detai led desc ri ption please refer t o PCI-Specification 2.1.

These val ues may su pport “ Plug and Pla y” fun ctiona lit y in gen eric s oftwar e to ass ign the

ressources (e.g. base addresses to the appropriate driver).

4.7.2 Build memory map

At system power-up, device independent software must be able to determine what

devices are present and build a consistent address map.

The base to calculate this address map is represented by the BAR registers. They

generally have a read/write functionality. Nevertheless some bits are hardcoded

internally. This feature has to be used to determine the required address space.

Therefore power-up softwar e has to write a val ue of all 1’ s to t he register and then read

back the value. The device will return 0’s in all don’t-care address bits, effectively

specif ying th e address spa ce req uired. For calcu lati on of the memory map and the bas e

addresse s it has to be c onsider ed that t he base addr ess es must not use bi ts set that ar e

hard coded to 0.

Table 2

Device Device ID

MUNICH32X 2101h

MUNICH128X 2103h

DSCC4 2102h

PCI based Controllers in de-multiplexed Operation

Detailed Description of DEMUX Bus States

Semiconductor Group 14 Application Note 03.99

In demult iplex ed inter face mode all devices descr ibed in this app not e use BAR1 register

only. Even if MUNICH32X and DSCC4 respond to programming BAR2 register this bas e

address is not used in demul tiplexed bus mode.

The Demux-Interface recognizes the address on the bus and calulates itself its internal

chipse lect. This internal chipselect is the r esult of a bitwise AND-operation of the address

lines and the conten t of the BAR regi ster compa red to the content of BAR:

CS = ( (A[31:2] & BAR1) == BAR1) && (COMMAND.MemorySpace);

Example using MUNICH32X:

1. Write access to BAR1 register with value FFFFFFFFh.

2. Re ad ac cess to B AR1 will de live r FFFFFF00h, so the required address range is 256

bytes.

3. Determination of mem ory map delivers a base address for this device: 40000000h.

4. Write calculated base address (40000000h) to BAR1.

5. Plug and Play sof tware may c ont inue wi th the ot her BARx r egist ers and ot her devices

in the system.

An alternate way is simply to c hoose t he base add ress an d rese rve an address range of

256 byte for MUNICH32X/MUNICH128X registers and 512 byte for DSCC4 registers.

Even if BAR2 register is write-/readable the BAR2 functions are not supported and will

be ignored by the device. Therefore its recommended that software also ignores the

BAR2 regist er.

4.7.3 Ena bling master and slave funtions of the device

To enable the function that the device reacts to addresses the Bit 1 in Command

(COMMAND.MemorySpace) field has to be set. As all the described devices use as an

evident feature the “mas ter capabilit y” this f unction has al so to be enabl ed by set ti ng Bit

2 (COMMAND.BusMaster). In order to enable both two functions the Command field of

the configuration space should be “ored” by 6.

4.7.4 S etting latency tim er

The latency timer field should be programmed with F8h. This way the function of the

laten cy timer is di sabled for common systems. Because all des cribed devi ces have a low

maximum bust size the bus latency caused by theses devices will keep low.

4.7.5 Interr up t Line

Start up software t hat assignes ressourc es to the system and has knowle dge about some

hardware related considerations should write the appropriate information into this field

that i s used e.g. by the devi ce driver to enable the interrupt .

In general this fiel d contai ns the int errupt line number used for this devi ce in the sys tem.

PCI based Controllers in de-multiplexed Operation

Detailed Description of DEMUX Bus States

Semiconductor Group 15 Application Note 03.99

4.7.6 Device Driver Initialization

After a central start-up function has assigned all ressources each device driver may

search for its related devices and read out all neccessary informations about the

assigned ress ources out o f its confi guration space.

PCI based Controllers in de-multiplexed Operation

Device specific differences

Semiconductor Group 16 Application Note 03.99

5 Device specific differences

5.1 MUNICH32X

• Even if both BAR1 and BAR2 reg ister are writeable and readable in demultipl exed bus

mode BAR1 is u sed by t he device onl y. If any ad dress on the bu s would fit to setti ngs

in BAR2, this cycle w il l be ignore d and t he MU NICH32X will keep passi ve on t he bus.

• The address lines are functionally multiplexed to LA(15:0) and LD(15:0) lines of

standard PCI m ode. The function is switched to A[31:2] by pulli ng DEMU X pin to Vdd.

5.2 MUNICH128X

• Due to limitations in pin count the MUNICH128X has only 26 address lines A(27:2).

Nevert heless sof tware is abl e to us e most s ignif icant bit s when pr ogra mming the BAR

hardwired to zero and also compared to BAR1 for address matching. When

addressing the device the software may use the upper address nibble which is not

observ ed by t he devic e so that logica lly t he MUNICH12 8X is als o locat ed in the upper

range of the memory .

Note:It is neccessary that no other device is located in a memory range of

(BAR1 & 0FFFFF00

) ... (BAR1 & 0FFFFFFF

) or

(BAR1 & FFFFFF00

) ... (BAR1 & FFFFFFFF

)

the MUNICH128X will respond to.

• If one or more of the A(31:28) lines are used in the specific design the glue logic has

to provide these signals to the bus when MUNICH128X is bus master.

• Demultiplexed address lines are not multiplexed to other pins.

• Demultiplexed Bus functionality is switched by DPCI(1:0)=102.

5.3 DSCC4

• Even if both BAR1 and BAR2 reg ister are writeable and readable in demultipl exed bus

mode BAR1 is u sed by t he device onl y. If any ad dress on the bu s would fit to setti ngs

in BAR2, th is cycle will be ignored and the DSCC4 will keep passive on the bus.

• The address lines are functionally multiplexed to LA(15:0) and LD(15:0) lines of

standard PCI mode. The function is switched to A[31:2] by pulling DEMUX pin

(pin188) to V dd.

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 17 Application Note 03.99

6 Application Examples for de-multiplexed Bus

Operation

This chapter discusses the connections of Motorola’s MC68360 and Intel’s I960

connections to Siemens protocol family of products, PEB 20534 (DSCC4), PEB 20321

(MUNICH32X), PEB 20324 (MUNICH128X) in the de-multiplexed mode.

In these examples only single read/write operations in the de-multiplexed modes are

used. All examples have been written and simulated in OPAL Open Programmable

Architecture Language from National Semiconductor Version 2.0.

Some syntax related details are:

inputs

defines all inputs of the GAL. A fixed assignment of pins is done by

“= x” with x as pin number

outputs

defines all output s of the G AL. A fixed assignm ent of pins is done by

“= x” with x as pin number

feedbacks

defin es all output s ignals of a gal that can be reu sed as inp ut to ot her

logical equations of the GAL. A fixed assignment of pins is done by

“= x” with x as pin number

(com)

defines the outputs and feebacks as combinatorical pin types. Per

default all logical equations are put out with minimum delay after

changing inputs of the equation.

(reg)

defines the outputs and fee dback as clocked pi n types . The result of

a changing input pin is latched out with next rising/falling edge of

clock.

“=”

keeps the default pin assignment in the equation.

“:=”

changes out put of an equati on to cl ocked ty pe regar dless t he o riginal

type of t he signal (reg ) or (com).

“/”

before the signal name in the pin definition part declares this signal

as low active and inverts the logical assignment between value and

voltage. E.g. a signal

/test

is defined as low signal. The assignment

of a “1” by:

“/test = 1;”

forces a voltage of 0V on the output pin

assigned to “

/test

”.

.oe

defines that this output i s enabled by the GAL’ s output enable signal

declared behind the “=”.

defines that this output is clocked by the GAL’s clock input signal

declared behind the “=”.

Note: All statepi ns and all counter pins are clocked type pins by def ault.

Note: Simulation pattern st art with definition of signal inputs. The pr obe defini tion d efines

the pr obed signa ls . “c” defi nes a cloc k si gnal wit h trans itions Low- Hig h-Low wit hin

one simulation cycle.

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 18 Application Note 03.99

6.1 C o nnectio n to the MC68360 de-mu ltiplexed Interface

Figure 4 B lock Diagram of Adaptation Motorola Bus to De-Multiplexed

Interface

The above bl ock diagra m shows t he connec tions o f t he contr ol and bu s signal s be tween

the DSCC4 and the MC68360. 3 GALs are required for this De-multiplexed mode. The

Arbiter GAL is a GAL16V8 type, the Master GAL and the Slave GAL are each a

GAL22V10A type.

The Arbit er GAL provides the arbitr ation for t he bus ma ster (eit her the Demux-Interface

or th e MC683 60 is th e mas ter). W hen the Demux-I nter face i s the mast er, the PCI co ntrol

signals come from the device to the Master GAL which provides the control signals to

the local bus.

When t he Dem ux-Interface is the slave, t he M C 68360 pr ovides the input cont rol signals

to the sl ave G AL which is responsible f or pr oviding the PCI signals to the device.

6.1.1 MC68360 Signals Description

/AS indicates valid address on the bus.

IDSEL

SIEMENS

Device

with Demux-

Interface

MUNICH32X

MUNICH128X

DSCC4

A[31..0]

D[31..0]

Motorola

Bus

68360

Slave-GAL

Master-GAL

Arbiter-GAL

/STOP

/TRDY

/IRDY

/FRAME

/ERRINT

/DS

/DSACK

/AS

R/W#

/BMP/BMD/BR

/BG

/BGACK /GNT

/REQ

W/R#

INV

[15:0] LA

[15:0] D

[31:0]

/DEVSEL

motorola.wmf

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 19 Application Note 03.99

/DS indicat es that a valid addres s is to be pl aced on the data bus by an external

device. /DSACK is used to indicate that a data transfer operation is

completed.

R/W* Indicates if it is a Read or a Write cycle. A high level indicates a read cycle

a low level indicates a write cycle.

/BR This signal indicates that an external device needs to become the bus

master.

/BG This signal indicates that the MC68030 will release ownership of the bus

mast er on com plet ion of th e current b us cycle.

/BGACK This signal indicates that an external device has become the bus master.

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 20 Application Note 03.99

6.1.2 Bus Arbitration Flow Chart for Single Request

Figure 5 Motorola bus arbitrat ion function

6.1.3 Bus Arbitration between MC68360 and Demux-Interface

6.1.3.1 Ar biter GAL Logi c

{

TITLE DEMUX_ARB

PATTERN Arbitration of Motorola 68360-Bus for DSCC4 on DEMUX-

Interface

MC68360 Requesting Device

Request for Bus

1. Assert Bus Request (BR)

Grant Bus Arbitration

1. Assert Bus Grant (BG)

Acknowledge Bus Mastership

1. External Arbitration

determines next master

2. N ext bus master waits for

current cycl e to fin ish

3. N ext Bus Master asserts Bus

Grant Ackno wledge (BGACK)

to become new master

4. Bus Master Negates BR

Term inate Arbitration

1. Negate BG and wait for

BGACK to be negated Opera te as Bus Master

1. Perform data tr ansfers (R/W-

cycles)

Re-Arbit rate Bus Operation

to different Bus Master Release Bus Master

1. Negate BGACK

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 21 Application Note 03.99

REVISION 1.0

AUTHOR Thomas Mies

COMPANY SIEMENS HL EZ D DA AE

DATE 28.01.1999

CHIP ARBITER GAL16V8

}

begin definition

device G16V8;

inputs BCLK = 1, { Bus-Clock }

/BG_I = 2, { BusGrant input from µP }

/MREQ_I = 3, { DSCC4 Request input from DSCC4 }

/DFRAME_I = 4, { FRAME input from Demux-Interface }

/DIRDY_I = 5, { IRDY input from Demux-Interface }

/DTRDY_I = 6, { TRDY input from Demux-Interface }

/BGACK_I = 7; { BusGrantAck Input from µP }

feedback (com)

/BMP_O = 14, { Busmaster is Processor }

/BMM_O = 15, { Busmaster is Demux-Interface}

/BR_O = 16, { BusRequest to µP }

/BGACK_O = 17, { BusGntAck to µP }

/MGNT_O = 18, { Gnt to Demux-Interface }

busy = 19; { Demux-Interface is busy on the bus until

final TRDY, even if it releases req/gnt

during current bus-cycle}

statebits sb1,sb0;

state_names bIDLE=0,bW_TRDY,bW_NTRDY;

end definition

begin equation

BR_O = MREQ_I;

MGNT_O = BG_I*BMM_O;

BGACK_O = busy;

BMM_O = busy ;

BMP_O = /(busy ) ;

end equations

begin state_diagram

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 22 Application Note 03.99

state bIDLE: busy = 0;

if (BG_I & /BGACK_I) then bW_FRAME; with busy = 1; endwith;

else bIDLE;

state bW_FRAME:

busy = 1; {wait for FRAME-signal}

if (DFRAME_I) then bW_TRDY

else if (DTRDY_I) then bW_NTRDY

else bW_FRAME;

state bW_TRDY:

busy = 1; {wait for TRDY-signal}

if (/DIRDY_I) then bIDLE

else if (DTRDY_I) then bW_NTRDY

else bW_TRDY;

state bW_NTRDY:

busy = 1; {wait for "TRDY-signal released"

("Not TRDY")}

if (/DTRDY_I ) then bIDLE with busy = 0; endwith;

else bW_NTRDY;

end state_diagram

6.1.3.2 Sim ulation of Arbiter GAL

Begin vector

BCLK, /MREQ_I, /BG_I, /DFRAME_I, /DIRDY_I ,/DTRDY_I,/BGACK_I;

probe /BR_O, /MGNT_O, /BGACK_O, /BMM_O, /BMP_O, busy, sb1,sb0;

c 111111

c 111110

c 011110

c 001110

c 001111

c 000111

c 001011

c 101011

c 111011

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 23 Application Note 03.99

c 111011

c 111001

c 111111

loop 15

c 111111

end

end vector

Figure 6 Timing Diagram of Arbiter GAL

6.1.4 Master GAL Logic

{

TITLE DEMUX_MASTER

PATTERN Adaptation of Motorola 68360-Bus to DEMUX-Interface

Part B: Master-Access

REVISION 1.0

COMPANY SIEMENS HL EZ D DA AE

DATE 28.01.1999

CHIP DEMUX_MASTER GAL22V10A

}

begin definition

device G22V10;

inputs BCLK = 1, { Bus Clock }

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 24 Application Note 03.99

/DFRAME_I = 2, { FRAME input from Demux-Interface }

/DIRDY_I = 3, { IRDY input from Demux-Interface }

/BDSACK_I = 4, { DSACK input from µP-Bus }

/BMDMUX = 5, { BusMaster is Demux-Interface (BMM)}

/BUCARRY = 6, { extension for future burst supplement }

DWR_I = 7; { to Demux-interface: W/R-Pin }

feedback (com)

/BAS_O = 23, { AS output to µP-Bus }

/BDS_O = 22, { DS output to µP-Bus }

/DTRDY_O = 21, { TRDY output to Demux-Interface }

/DDEVSEL_O = 20, { DEVSEL output to Demux-Interface }

/DSTOP_O = 19; { STOP output to Demux-Interface }

statebits sb2,sb1,sb0;

state_names pIDLE=0, pAS, pW_DSACK, pTRDY, pDIS1, pDIS2;

end definition

begin equation

BAS_O.oe = BMDMUX;

BDS_O.oe = BMDMUX;

DTRDY_O.oe = BMDMUX;

DDEVSEL_O.oe = BMDMUX;

DSTOP_O.oe = BMDMUX;

end equations

begin state_diagram

state pIDLE:

BAS_O = 0;

DDEVSEL_O = 0;

DTRDY_O = 0;

DSTOP_O = 0;

if (DFRAME_I & BMDMUX) then pAS; with BAS_O = 1; endwith;

else pIDLE;

state pAS: BAS_O = 1; { set AS }

DDEVSEL_O = 1;

DTRDY_O = 0;

DSTOP_O = 0;

if DIRDY_I then pW_DSACK

else pAS;

state pW_DSACK:

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 25 Application Note 03.99

BAS_O = 1; { give DS and wait for DSACK }

BDS_O = (DIRDY_I * /DWR_I)+ (DTRDY_O * DWR_I);

DDEVSEL_O = 1;

DTRDY_O = 0;

DSTOP_O = 0;

if BDSACK_I then pTRDY with DTRDY_O = 1; endwith;

else pW_DSACK;

state pTRDY:

BAS_O = 1; { give TRDY }

BDS_O = DTRDY_O;

DDEVSEL_O = 1;

DTRDY_O = 1;

DSTOP_O = 0;

if DFRAME_I then pDIS1

else if /DIRDY_I then pIDLE with DTRDY_O=0; endwith;

else pTRDY;

state pDIS1:

BAS_O = 0; { Disconnect }

DDEVSEL_O = 1;

DTRDY_O = 0;

DSTOP_O = 1;

goto pDIS2;

state pDIS2:

BAS_O = 0; { Disconnect }

DDEVSEL_O = DFRAME_I;

DTRDY_O = 0;

DSTOP_O = DFRAME_I;

if (/DFRAME_I) then pIDLE

else pDIS2;

end state_diagram

6.1.4.1 Simulation of Master GAL

Begin vector

BCLK, /DFRAME_I, /DIRDY_I, DWR_I, /BDSACK_I, /BMDMUX, /BUCARRY;

probe /BAS_O, /BDS_O, /DTRDY_O, /DDEVSEL_O, /DSTOP_O, sb2, sb1, sb0;

c 111111

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 26 Application Note 03.99

c 111101

c 011101

c 101101

c 101001

c 111101

c 111111

c 111101

c 010101

c 100101

c 100001

c 110101

c 111101

c 111111

c 111101

c 011101

c 001101

c 001001

c 011101

c 111101

loop 15

c 111111

end

end vector

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 27 Application Note 03.99

Figure 7 Timin g of Master GAL (DSCC4 is Master MC68 360 is Sl ave)

6.1.5 Slave GAL

{

TITLE DEMUX_SLAVE

PATTERN Adaptation of Motorola 68360-Bus to DEMUX-Interface

Part A: Slave-Access

REVISION 1.0

COMPANY SIEMENS HL EZ D DA AE

DATE 28.01.1999

CHIP DEMUX_SLAVE GAL22V10A

}

begin definition

device G22V10;

inputs BCLK = 1, { Bus clock }

/BAS_I = 2, { AS input from µP-Bus }

/BDS_I = 3, { DS input from µP-Bus }

/DTRDY_I = 5, { TRDY input from Demux-Interface }

/DSTOP_I = 6, { STOP input from Demux-Interface }

/DDEVSELI = 7, { DEVSEL input from Demux-Interface }

/BCS = 8, { Chipselect selects PCI Config Space }

/BMP = 9; { Busmaster is Processsor }

feedback (com)

/BDSACK_O = 14, { combined /DSACK0 and /DSACK1 or /STERM

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 28 Application Note 03.99

to µP-Bus}

/DFRAME_O = 15, { FRAME output to Demux-Interface }

/DIRDY_O = 16, { IRDY output to Demux-Interface }

/ERRINT = 17; { Error-Indication to µP if no device

reacts }

feedback (reg) cnt2,cnt1,cnt0;

sets cnt = [cnt2,cnt1,cnt0];

statebits sb2,sb1,sb0;

state_names bIDLE=0, bCNT, bW_TRDY, bRDY, bRETRY1, bRETRY2, bABORT;

end definition

begin equation

DFRAME_O.oe =BMP;

DIRDY_O.oe =BMP;

ERRINT.oe =BMP;

BDSACK_O.oe =BMP;

end equations

begin state_diagram

state bIDLE:

DFRAME_O = 0;

DIRDY_O = 0;

ERRINT = 0;

BDSACK_O = 0;

if (BAS_I & BMP) then bCNT with cnt := ^b000; endwith;

else bIDLE;

state bCNT:

cnt := cnt @+ 1;

DFRAME_O = 1;

DIRDY_O = 0;

BDSACK_O = 0;

if (DDEVSEL_I) then bW_TRDY

else if cnt == ^b110 then bABORT;

else bCNT;

state bW_TRDY:

DFRAME_O = 0; { wait for TRDY }

DIRDY_O = BDS_I;

BDSACK_O = 0;

ERRINT = 0;

if (DTRDY_I & !DSTOP_I) then bRDY with cnt:=^b000; endwith;

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 29 Application Note 03.99

else if DTRDY_I & DSTOP_I then bRETRY1

else bW_TRDY;

state bRDY:

DFRAME_O = 0; { Ready }

DIRDY_O = BDS_I;

BDSACK_O = 1;

if (/BAS_I * /BDS_I ) then bIDLE with BDSACK_O = 0; endwith;

else bRDY;

state bRETRY1:

DFRAME_O = 0; { Retry: Error handling }

DIRDY_O = BDS_I;

BDSACK_O = 0;

goto bRETRY2;

state bRETRY2:

DFRAME_O = 0;

DIRDY_O = 0;

BDSACK_O = 0;

goto bW_TRDY;

state bABORT:

DFRAME_O = 0; { abort: error handling }

DIRDY_O = 0;

ERRINT = 1;

BDSACK_O = 1;

goto bIDLE;

end state_diagram

6.1.5.1 Simulation of Slave GA L

Begin vector

BCLK, /BAS_I, /BDS_I,/DTRDY_I, /DSTOP_I, DDEVSEL_I, /BCS, /BMP;

probe /DFRAME_O, /DIRDY_O, /BDSACK_O, /ERRINT, cnt, sb2, sb1, sb0;

c 1111111

c 1111110

c 0111110

c 0011010

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 30 Application Note 03.99

c 0011110

c 0001110

c 1111110

c 1111111

c 1111110

c 0111110

c 0011110

c 0111110

c 1111110

loop 15

c 1111111

end

end vector

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 31 Application Note 03.99

Figure 8 Timing of Slave GAL

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 32 Application Note 03.99

6.2 C o nnectio n to Intel i960 de-multiplexed Interface

Figure 9 i960 Block Diagram of De-Mul tiplexed Mode

6.2.1 i960 Control Signals

/ADS: Indicates a valid addres s and start of a new bus access.

/BLAST: Indi cates the la st tra nsfer in a bus acces s. BLAST is asser ted in the l ast data

transfer of burst and non-burst access. It becomes inactive after the final

data tr ansfer .

/TMORDY: This signal indicates that the read data on the bus is valid or that a write

transfer is comp let ed or a optional TimeOut.

/BREQ: This si gnal indicates a bus request is pendi ng in the bus contr oller.

W/R* : Thi s signal is low f or read re sponse and hi gh fo r write acces ses. It becomes

valid for the addr ess phase of the bus cycl e and remains valid till

HOLD: This signals that an extern al device is req uesting access to the processor’s

address, data and control buses.

HOLDA: Indicates to an external master that the processor has relinquished control

of the bus.

IDSEL

SIEMENS

Device

with Demux-

Interface

MUNICH32X

MUNICH128X

DSCC4

A[31..0]

D[31..0]

Intel

Bus

i960

Slave-GAL

Master-GAL

Arbiter-GAL

/STOP

/TRDY

/IRDY

/FRAME

/ERRINT

/BLAST

/TMORDY

/ADS

W/R#

/BMP/BMDHOLD

HOLDA

/GNT

/REQ

[15:0] LA

[15:0] D

[31:0]

W/R#

/DEVSEL

intel.wmf

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 33 Application Note 03.99

6.2.2 Log ic for Arbiter GAL

Arbiter-Logic t o supply /BMP (Bus Maste r is Processor) and BMM (BusMaster is DSCC4)

{

TITLE I960_ARB

PATTERN Arbitration of Intel I960-Bus for DEMUX-Interface

REVISION 1.0

COMPANY SIEMENS HL EZ D DA AE

DATE 28.01.1999

CHIP I960_ARB GAL16V8

}

begin definition

device G16V8;

inputs BCLK = 1, { Bus-Clock }

HOLDA_I = 2, { BusGrant input from µP }

/MREQ_I = 3, { DSCC4 Request input for Bus }

/DFRAME_I = 4, { FRAME input from Demux-Interface }

/DIRDY_I = 5, { IRDY input from Demux-Interface }

/DTRDY_I = 6; { TRDY input from Demux-Interface }

feedback (com)

/BMP_O = 14, { Busmaster is Processor }

/BMM_O = 15, { Busmaster is Demux-Interface}

HOLD_O = 16, { BusRequest to µP }

/MGNT_O = 17, { Gnt to Demux-Interface }

busy = 19; { device is busy on the bus until

last TRDY, even if it releases req/gnt

during current bus-cycle}

statebits sb1, sb0;

state_names bIDLE=0, bW_TRDY, bW_NTRDY;

end definition

begin equation

HOLD_O = MREQ_I;

MGNT_O = HOLDA_I;

BMM_O = busy + BG_I;

BMP_O = /(busy + BG_I) ;

end equations

begin state_diagram

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 34 Application Note 03.99

state bIDLE:

busy = 0;

if (HOLDA_I) then bW_FRAME; with busy = 1; endwith;

else bIDLE;

state bW_FRAME:

busy = 1; {wait for FRAME-signal}

if (DFRAME_I) then bW_TRDY

else if (DTRDY_I) then bW_NTRDY

else bW_FRAME;

state bW_TRDY:

busy = 1; {wait for TRDY-signal}

if (/DIRDY_I) then bIDLE

else if (DTRDY_I) then bW_NTRDY

else bW_TRDY;

state bW_NTRDY:

busy = 1; {wait for "TRDY-signal released"

("Not TRDY")}

if (/DTRDY_I ) then bIDLE with busy = 0; endwith;

else bW_NTRDY;

end state_diagram

6.2.2.1 Sim ulation of Arbiter GAL

Begin vector

BCLK, /MREQ_I, /HOLDA_I, /DFRAME_I, /DIRDY_I ,/DTRDY_I;

probe HOLD_O, /MGNT_O, /BGACK_O, /BMM_O, /BMP_O, busy, sb1,sb0;

c 11111

c 01111

c 00111

c 00011

c 00101

c 10101

c 11101

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 35 Application Note 03.99

c 11101

c 11100

c 11111

loop 15

c 11111

end

end vector

Figure 10 Timing Diagram of Arbiter GAL

6.2.3 Log ic for Master GAL

{

TITLE I960_MASTER

PATTERN Adaption of I960-Bus to Demux-Interface

REVISION 1.0

COMPANY SIEMENS HL EZ D DA AE

DATE 28.01.1999

CHIP I960_MASTER GAL22V10A

}

begin defination

device G22V10;

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 36 Application Note 03.99

inputs BCLK = 1,

/DFRAME_I = 2,

/DFRAME_IF = 3,

/DIRDY_I = 4,

/BMDMUX = 5,

/BUCARRY = 6;

feedback (com)

/BADS_O = 23,

/BBLAST_O = 22,

/DMXWAIT = 21,

/DTRDY_O = 20,

/DDEVSEL_O = 19,

/DSTOP_O = 18,

didle = 17;

statebits sb2, sb1, sb0;

state_names pIDLE=0, pADS, pBL1, pBL2, pBL3, pDIS1, pDIS2;

end definition

begin equation

BADS_O.oe = BMDMUX;

BBLAST_O.oe = BMDMUX;

DMXWAIT.oe = BMDMUX:

DTRDY_O.oe = BMMUX;

DDEVSEL_O.oe =BMDMUX:

DSTOP_O.oe = BMDMUX;

didle.oe = BMDMUX;

end equations

Begin state_diagram

state pIDLE:

didle = 0;

BADS_O = 0;

BBLAST_O = 0;

DMXWAIT = 0;

DDEVSEL_O = 0;

DTRDY_O = 0;

DSTOP_O = 0;

If(DFRAME_IF & BMDMUX) then pADS;

else pIDLE;

state pADS: BADS_O = 1;

BBLAST_O = 0;

DMXWAIT = 0;

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 37 Application Note 03.99

DDEVSEL_O = 1;

DTRDY_O = 0;

DSTOP_O = 0;

goto pBL1;

state pBL1: BADS_O = 0;

BBLAST_O = 0;

DMXWAIT = 1;

DDEVSEL_O = 1;

DTRDY_O = 0;

DSTOP_O = 0;

goto pBL2;

state pBL2: BADS_O = 0;

BBLAST_O = 0;

DMXWAIT = 1;

DDEVSEL_O = 1;

DTRDY_O = 0;

DSTOP_O = 0;

goto pBL3;

state pBL3: BADS_O = 0;

BBLAST_O = 1;

DMXWAIT = 0;

DDEVSEL_O = 1;

DTRDY_O = 1;

DSTOP_O = 0;

If(/DFRAME_IF)then pIDLE with didle=1;endwith

else pDIS1;

state pDIS1: BADS_O = 0;

BBLAST_O = 0;

DMXWAIT = 0;

DDEVSEL_O = 1;

DTRDY_O = 0;

DSTOP_O = 1;

goto pDIS2;

state pDIS2: BADS_O = 0;

BBLAST_O = 0;

DMXWAIT = 0;

DDEVSEL_O = D_FRAME_I;

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 38 Application Note 03.99

DTRDY_O = 0;

DSTOP_O = DFRAME_I;

If(/DFRAME_I) then pIDLE with didle=1;endwith

else pDIS2;

end state_diagram

6.2.3.1 Sim ulation of Mas ter GAL

Begin vector

BCLK, /DFRAME_I, /DFRAME_IF, /DIRDY_I, /BMDMUX, /BUCARRY;

Probe /BADS_O, /BBLAST_O, /DMXWAIT, /DTRDY_O, /DDEVSEL_O, /DSTOP_O,

didle, sb2, sb1, sb0;

c 11111

c 11101

c 01101

c 00101

c 10101

c 11101

c 11111

loop 15

c 11111

end

end vector

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 39 Application Note 03.99

Figure 11 Timing Diagram of Master GAL

6.2.4 Log ic for Slave GAL

{

TITLE I960_SLAVE

PATTERN Adaption of I960-Bus to Demux-Interface

Rev 1.0

REVISION 1.0

COMPANY SIEMENS HL EZ D DA AE

DATE 28.01.1999

}

begin defination

device G22V10;

inputs BCLK = 1,

/BADS_I = 2,

/BBLAST_I = 3,

/BWAIT = 4,

/DTRDY_I = 5,

/DSTOP_I = 6,

/DDEVSEL_I = 7,

/DEMUXCS = 8,

/BM960 = 9;

feedback (com)

/DFRAME_O = 23,

/DIRDY_O = 22,

/TMORDY = 21,

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 40 Application Note 03.99

/ERRINT = 20;

feedback(reg)

cnt2, cnt1, cnt0;

set cnt=[cnt2,cnt1,cnt0];

statebits sb2, sb1, sb0;

state_names bIDLE=0, bCNT, bW_TRDY, bRDY, bRETRY1, bRETRY2;

end definition

begin equation

DFRAME_O.oe = BM960;

DIRDY_O.oe = BM960;

TMORDY.oe = BM960:

ERRINT.oe = BM960;

end equations

Begin state_diagram

state bIDLE:

DFRAME_O = 0;

DIRDY_O = 0;

TMORDY = 0;

If( BADS_I & BM960) then bCNT With cnt:=^b000;endwith;

else bIDLE;

state bCNT:

cnt := cnt@+1;

DFRAME_O = 1;

DIRDY_O = 0;

TMORDY = 0;

If cnt==^b100 then bW_TRDY

else bCNT;

state bW_TRDY:

DFRAME_O = 1;

DIRDY_O = 0;

TMORDY = 0;

If (DTRDY_I& !DSTOP_I)then bRDY

else if DTRDY_I & DSTOP_I then bRETRY1

else bW_TRDY;

state bRDY:

DFRAME_O = 0;

DIRDY_O = 1;

TMORDY_O = 1;

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 41 Application Note 03.99

goto bIDLE;

state bRETRY1:

DFRAME_O = 0;

DIRDY_O = 1;

TMORDY = 0;

goto bRETRY2;

state bRETRY2:

DFRAME_O = 0;

DIRDY_O = 0;

TMORDY = 0;

goto bW_TRDY;

End state_diagram

6.2.4.1 S im ulation of Slave GA L

Begin vector

BCLK, /BADS_I, /BBLAST_I, /BWAIT, /DTRDY_I, /DSTOP_I, /DDEVSEL_I,

/BM960;

Probe /DFRAME_O, /DIRDY_O, /TMORDY, /ERRINT, cnt, sb2, sb1, sb0;

c 11111111

c 01111100

c 11011100

c 10111100

c 11101100

c 11111100

c 11111110

loop 15

c 11111111

end

end vector

PCI based Controllers in de-multiplexed Operation

Application Examples for de-mul tiplexed Bus Operation

Semiconductor Group 42 Application Note 03.99

Figure 12 Timing Diagram of Slave GAL

PCI based Controllers in de-multiplexed Operation

Burst functionality of the Demux-Interface

Semiconductor Group 43 Application Note 03.99

7 Burst functionality of the Demux-Interface

Any glue logic that supports burst functionality depends very much on the specific

design. So it could be neccessary to adapt the hints given in this chapter. As

MUNICH128X provides most burst features thi s device is take n for example.

7.1 Incrementing Address lines

Generally the Demux-Interface does not increment the address lines during one burst

cycle but keeps the initial address of the first transfered DWord. So if the target (RAM,

or RAM controller interface) in the system does not support a similar burst functionality

some lower order address lines must not be connected directly from the Demux-

Interface to the system bus. The incrementation has to be performed by the glue logic

using t he given address of each burst cy cle as the init ial value . The incr emented address

lines are then provided to the system bus. The following figure shows a typical

envir onment using 4 ad dress lin es for inc rementatio n. The coun t of incr emented address

lines depends on the sys tem and its inte rnal requirements.

Figure 13 Glue Logic for the Demu lt iplexed Interface supporting the burst

functionality of the device (example with MUNICH128X).

MUNICH128X

as Slave

FRAME#

MUNICH128X

as Master

Determin

Bus Master

REQ#

GNT#

Bus Request

Bus Grant

MUNICH128X

is Bus Master

IRDY#

TRDY#

W/R#

IDSEL

DEVSEL#

Write / Read#

"Chip Select" for PCI Config Space

A[27:6]

D[31:0]

A[27:6]

D[31:0]

A[31:28] (hardcoded)

Demux-A[5:2]

Bus-A[5:2](incrementing)

gluelogicburst.wmf

PCI based Controllers in de-multiplexed Operation

Burst functionality of the Demux-Interface

Semiconductor Group 44 Application Note 03.99

The master par t of the glue logi c loads the in itial val ue of the addr ess line s and provides

this value to the bus during the address phase and the first data phase. For each

consecutively transfered DWord within the burst the address lines Bus-A(x:2) get

incremented by one.

7.2 Handling ad dres s counter over flows

As the addr ess count er in t he glue logi c ha s a limited number of bi ts i t will swi tch i n s ome

cases f ro m 11112 to 00002 which leads to a non conse cutive addres s on the system bus.

To avoid this the current burst cycle has to be interrupted using one the follwoing two

possibilities:

1. Target Disconnect with Data and Retry: At this implementation the STOP line is

assert ed while t he last DWor d is trans fered toget her with both TRDY and IRDY acti ve.

As condition the logic shou ld assert STOP when

the counter is 1111,

FRAME, IRDY and TRDY are active.

2. Target Di sc onnect withou t Dat a a nd Retr y: At thi s implement ati on the last DWor d gets

transfered normally. The TRDY gets deasser ted and STOP a sserte d. No furt her dat a

gets transfered and the master will terminate the current bus cycle to rearbitrate the

bus and retry to get the data on the consecutive address with a new tr ansaction.

The device then will t erminate the current cy cle and release the bus. As there are some

DWords of the tra nsfer missing the device wi ll re- arbitrat e the bus a few cl ock cycles later

on to start a new transfer beginning with the first not transfered DWord of the prior

transaction.

The counte r ove rflo w situat ion can ha ppen ev en at the be ginnin g of the bur st depen din g

on the start address of the burst and the bit count the address counter provides. E.g. if

an 8-DWord-burst starts at address 10002038h and the counter provides 4 bit the first

burst can only have a size of two. The device then initiates a second burst with 6

DWords. The following figure gives an overview what happens to the burst in the

memory map. By enlarging the bit capability of the counter the probability of retry

operations and therefore the bus load can be decreased and the efficiency of the bus

ut ilis a tio n can be in cr e a se d .

PCI based Controllers in de-multiplexed Operation

Burst functionality of the Demux-Interface

Semiconductor Group 45 Application Note 03.99

Figure 14 Seperation of one burst into 2 burst s because of counter overflow

1002020h 0100

1002024h 0101

1002028h 0110

100202Ch 0111

1002030h 1100

1002034h 1101

1002038h 1110

100203Ch 1111

1002040h 0000

1002044h 0001

1002048h 0010

100204Ch 0011

1002050h 0100

1002054h 0101

Whole Burst: 8 DWords

1st Burst: 2DWords

2nd Burst: 6 DWor ds

Terminate Burst

with STOP Signal

Device "Retries"

with new burst

Address Counter

burstretry.wmf