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(a)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.
>
