Using DFRAME# to Differentiate Address Phases
[from Data Phases of PCI Bus Transactions]

This article was orginally published by Future Plus Systems Corporation in their 3Q 1995 edition of "The Bus Analyzer", a newsletter targeted at users of the HP16500 series Logic Analyzer and their legacy FS16P32E interface card.

My 9323A PCI Extender and Interface Board is a cost-effective alternative to expensive, high-end interface cards, suitable for most hardware and software developers, hobbyists, and anyone interested in learning how PCI devices work at the hardware level.

Using DFRAME# to Differentiate Address Phases

Requirements: HP 16500 series logic analyzer mainframe with 16550 or 16555 Timing/State module; 9323A or Future+ FS16P32E interface card (later became the FS2000), Future Plus Systems Inverse Assembler for PCI bus transactions.

By adding a fast PAL to your PCI preprocessor board, you can easily differentiate the address/command phase from the data phase for enhanced state analysis. Although strictly speaking, the second load on CLK and FRAME# makes the device noncompliant, it is a piece of test equipment and the loading does not adversely affect operation, even if the device under test is plugged in the top connector.

Keeping wire lengths as short as possible, attach a 5 ns 16V8 to the preprocessor connected as follows:

The following equations are programmed in to generate DFRAME# which becomes available on the USER 2 input of the analyzer configuration. Alternatively you could use USER 1. Do not use pod 1 bit 15 even though it appears unassigned in the HP 16550 format menu. Create the DFRAME label in the format menu.

;PALASM Design Description
;-------------------------- Declaration Segment ----------
TITLE pal to generate DFRAME for logic analyzer
PATTERN dframe.pds
CHIP _dframe PALCE16V8
;-------------------------- PIN Declarations -------------
PIN 1 clk
PIN 9 /frame
PIN 10 gnd
PIN 11 /oe
PIN 15 /dframe
PIN 20 vcc
;-------------------------- Boolean Equation Segment ------
EQUATIONS
dframe := frame ; dframe follows frame 1 clk later
;----------------------------------------------------------

After assigning the DFRAME# label in the analyzer configuration, new terms can be defined in the trigger menu:

A_PHASE = (FRAME# = 0) • (DFRAME# = 1) ; address/command phase
D_PHASE = (IRDY# = 0) • (TRDY# = 0) ; data transfer phase

A_PHASE will only be true on the first CLK edge of any PCI transaction including a burst. D_PHASE will only be true for data transfers. State listings can therefore be set up to exclude all wait states, or further qualified to store only particular transaction types. This is excellent for timing software operations or hardware events, and for determining burst lengths or merge behavior. The advantage of this method over invasm suppression is that only the states you need to look at are stored, increasing the visible event window. The disadvantage is that the state listings can appear different due to invasm confusion. However, they are easily interpreted and will not be in error (i.e., the inverse assembler will never show incorrect information; convince yourself by comparing any qualified state-mode listing against an identically triggered timing-mode waveform). This is best demonstrated by example.

Figure 1 shows how bursts get displayed. State 2 is a 16-bit transfer to A18D2-3. State 3 (which was merged) and state 4 continue the burst up to A18D9. State 5 is a new burst transaction starting at A18DA. The user is cautioned to use this simplified form only if target-initiated termination is impossible or irrelevant to your trace, since you will lose the ends of these cycles.

Figure 1. Memory write burst.

Analyzer trigger setup:

1: While storing "A_PHASE+D_PHASE"
    TRIGGER on "A_PHASE • g" 1 time
     g=(FRAME=0 • ADDR=000Axxxx)

2: Store "A_PHASE+D_PHASE"

Figure 2 includes additional qualification of stored states and includes the "i" term to store retries (which, if excluded as in Fig. 1, will produce incorrect results that appear as "WAIT" states – which simply cannot be stored – should they occur). The only other misleading result that can happen is in the case of master abort. The storage conditions inhibit recording of the ends of master aborted cycles. Master aborts are easy to identify, however: they will appear as "WAIT-TARGET AND INITIATOR NOT READY" due to invasm confusion (more on this later). Note that since the store conditions prevent any wait states from being recorded, such a reference uniquely identifies master aborts, which are usually rare events (often limited to bios configuration accesses and memory activity in the unpopulated upper areas of the 4-gig space). Master-aborted DAC Snoop cycles are also permitted in PCI 2.1.

Figure 2. I/O reads with retries stored.

Analyzer trigger setup:

1: While storing "A_PHASE+D_PHASE"
    TRIGGER on "A_PHASE • g" 1 time
    g=(FRAME=0 • ADDR=00000064 • CBE=001x)

2: Store "A_PHASE+D_PHASE+i"
     i=(IRDY=0 • STOP=0)

Sometimes more complicated trigger and storage conditions will be required, such as when you only care about time between the beginnings of long bursts of data transfers rather than the actual data (Figure 3 uses the timer to expire the transfer term).

Figure 4 will store every bios configuration access during the boot process. It could easily be modified to capture other activities such as writes to the expansion rom base address register or the register-level programming activities during Windows 95 bootup. Keep in mind that you don't need to trigger at all to get a great state recording! This method works particularly well when looking for the most recent in a long string of repeated events.

Take notice to the appearance in Figure 4 of the master aborts at states 377-379 and how the missing end interfered with the address phase whose transfer was at state 380. Figure 5 adds a term that helps unconfuse the inverse assembler (IA) by attempting to store the ends of master aborts (with relative success). The weakness is that the shortest timer HP allows is 400 ns. Three clocks (100 ns) would be completely reliable; in this example we are counting on system bios not executing master aborts closer than 400 ns (usually but not always true). Note how the master aborted cycle has changed to "WAIT-NO DEVICE SELECT." The IA still can't tell it was really a master abort, but the indication is more accurate than before. Careful observers might also notice that the byte enables in states 550 and 553 are for either Device ID then Vendor ID, not both as implied by the IA. A future revision will indicate unenabled bytes in configuration space appropriately.

Figure 3. Use of timer to disqualify the ends of long data transfers.

Analyzer trigger setup:

1: While storing "no state"
    TRIGGER on "i" 1 time
    i=(FRAME=0 • ADDR=000Axxxxx • CBE=011x)

2: While storing "A_PHASE+((D_PHASE+g) • timer2<400ns)"
    Then find "A_PHASE" 1 time
    Else on "no state" go to level 2
    TimerControl="–S"
    g=(IRDY=0 • STOP=0)

3: Store "A_PHASE+((D_PHASE+g) • timer2<400ns)"
     On "A_PHASE" go to level 2
     TC="–S"

Figure 4. Configuration accesses.

Analyzer trigger setup:

1: While storing "no state" TRIGGER on "IDLE" 1 time
    post store 93%, branches taken stored.

2: While storing "no state" Then find "C_PHASE" 1 time
     —> Press STOP after boot completes.

3: While storing "C_PHASE"
    Then find "D_PHASE+g" 1 time
    C_PHASE=(FRAME=0 • DFRAME=1 • CBE=101x)
    g=(IRDY=0 • STOP=0)

4: Store "C_PHASE+D_PHASE+g"
     On "IDLE" goto level 2

Figure 5. Configuration accesses with master abort fix.

Analyzer trigger setup:

1: While storing "no state" TRIGGER on "IDLE" 1 time
2: While storing "no state" Then find "C_PHASE" 1 time
     TimerControl="–S"
3: While storing "C_PHASE"
        TC="–S"
     Then find "D_PHASE+g+(j • timer2>400ns)" 1 time
     j=(FRAME=1 • DEVSEL=1 • IRDY=0)
4: Store "C_PHASE+D_PHASE+g+(j • timer2>400ns)"
     TC="–S"
     On "IDLE" goto level 2

#  #  #

If you are interested in purchasing a product, developing a new one, or discussing how I can help you make your current technology or software products better, email me.