Ravi,
Just to make clear, the use of "port 18" is only the software design used in
our example designs. Basically, it is a software maintained queue that the
SA Core is polling for exception packets.
As far as the basic methodologies for Core/Microengine communication, you
would use shared memory (SRAM/SDRAM) and the use of interrupts/signals. As
far as the actual mechanism, like using mailboxes, linked lists or circular
queues, it is up to the programmer.
Eric Heaton
Technical Marketing Engineer
Intel Corporation - NPBU
-----Original Message-----
From: Johnson, Erik J [mailto:erik.j.johnson@intel.com]
Sent: Wednesday, March 20, 2002 12:35 PM
To: 'ixp1200(a)CS.Princeton.EDU'
Subject: RE: [ixp1200] packet to strong arm
> My question is...
> 1)Is there any major modification to be done in the
> code to run a project written for a 64 bit
> bidirectional IXbus mode to make it run on 32 bit
> unidirectional IXBus mode??
>From a software perspective, no. That is, you don't need to change the
receive or transmit microcode. The hardware must agree upon the format
(i.e., the MAC and IXP1200 must both be using the same mode)
> 2)what exactly is the communicaton mechanism between
> the microengines and the core?What I have understood
> is that the receive thread creates a descriptor which
> contains info about which port to send the packet
> to,and then the transmit thread reads this descriptor
> and transmits the packet to the specified port.But in
> this case the port number is 18,then how does trasmit
> thread make use of this port 18.Please correct me if I
> am wrong.
In the reference designs, port 18 is not handled by the transmit
microengines. Rather, when the ingress code enqueues a descriptor on port
18, the PETH driver (or any other software you want) running in the core
dequeues the descriptor and hands it (usually) to the IP stack of the OS.
When the core needs to transmit a packet, it directly enqueues on the
transmit queue for the outgoing port.
Note that a similar model is taken by the microblocks/microACE model in IXA
SDK 2.0, but the actual implementation is a bit different. In this model
there are also queues between the microengines and core, but these queues
avoid core/microengine locks and there are APIs for demultiplexing the
packets on either side of the queues to the appropriate piece of core or
microengine code.
>
> Thanks and regards
> Ravi Modgekar
>
