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@CS.Princeton.EDU] Sent: Tuesday, September 19, 2000 3:46 PM To: ixp1200@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.