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@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