IXP1200 Ready Bus Sequencer

[Johnson, Erik J]

We use this:

TEMPLATE_PROG1 = 0x1fdb1fd7
PROG2 = PROG3 = 0x0

Alternativly, I have also used PROG2 = PROG3 = 0x1f1f1f1f

Basically the PROG1 says (nop, poll rcv rdy for macs 0 and 1, nop, 
poll tx rdy), PROG2 = 0 says flow ctl, and 1f says nops.  I understand
the nops and have been explained that the flow ctls are faster (fewer
cycles) and that is why they are used in many cases.

erik

> -----Original Message-----
> From: Tammo Spalink [mailto:tspalink at CS.Princeton.EDU]
> Sent: Tuesday, September 19, 2000 3:46 PM
> To: ixp1200 at CS.Princeton.EDU
> Subject: Re: IXP1200 Ready Bus Sequencer 
> 
> 
> 
> I am pretty sure I deal with stale flags correctly.
> 
> What I was hoping for is an example set of 12 sequencer instructions
> that are known to work well for my scenario: 8x100Mb, no autopush.
> 
> Tammo
> 
> On Tue, 19 Sep 2000, "Paige, Dale W" wrote:
> > A commonly encountered problem can be encountererd when the 
> ready bus
> > sequencer is servicing "slow ports" (10/100 ports).  The 
> collection of the
> > ready flags is asynchronous with the operation of the IX 
> Bus receive state
> > machine.  You can read the ready flags and find flags that 
> are set even
> > though a rcv_req has been queued or even completed for the 
> port indicating a
> > need for service.  This is due to the latency in handling 
> the ready receive
> > requests.  Imagine a ready bus rxrdy command collecting the 
> flags the IX Bus
> > cycle before the MAC de-asserts its RxReady signal for the 
> port which is the
> > subject of an IX Bus read.  We refer to such flags as stale flags.
> > 
> > To deal with stale flags the RxReady flags can be "aged" by 
> holding them for
> > one or two ready bus sequencer cycles before using them and 
> AND'ing them
> > with the inverse of a "rcv_req outstanding" bit map.  The 
> RCV_RDY_CNT
> > associated with a set of RxReady flags is generally used to 
> assist in this
> > purpose, although the RCV_CNTL_CNT can be used for an even 
> more precise (yet
> > computationally intricate) tracking of the state of the 
> RxReady flags.
> > Refer to the Hardware Reference manual section 6.6.4.8, 
> "Interpreting The
> > Receive Ready Flags", for more information.
> > 
> > On the transmit side you want to read the TxReady flags 
> fairly frequently so
> > your transmit process can proceed as quickly as possible.
>