June 2003 - ixp1200 - lists.cs.princeton.edu

IXP1200 timings.
by Liam.Noonan 19 Jun '03

19 Jun '03

Hi, As part of my research into network processors I am examining the IXP1200. I am trying to obtain information regarding the number of cycles/ length of time it takes the IXP1200 to peform the following tasks. 1, move an mpacket from the a port to rfifo 2, moving mpackets from rfifo to the Microengines, SDRAM 3. Moving mpackets from SDRAM and the Microengine to TFIFO 4. Moving mpackets from TFIFO to an out going port. 5. access times for accessing SRAM. I have reviewed the various literature and publications provided by Intel, but obtaining this information is proving challenging. Any information would be appreciated. Thanks Liam Noonan Dept EC&E University Of Limerick Ireland

3 2

IXA SDK 2.01 with IXP12EB
by C.Liacs 19 Jun '03

19 Jun '03

Hello I'm trying to setup Intel IXA SDK 2.01 to work with IXP12EB evaluation board. Currently I have linux 2.3.99-pre3-rmk3 running on IXP but when I tried to load ue.o from SDK, I got this error: ue.o: unresolved symbol get_virtual_mem_map ue.o: unresolved symbol get_physical_mem_map ue.o: unresolved symbol get_virt_from_phys I found these functions in "mm-ixp1200.h" file in Linux kernel supplied with SDK but I couldn't get this kernel running on ixp12eb. I would appreciate any help. Regards, Charlie

2 2

RE: [ixp1200] Monitoring the IXBus using Workbench
by Botham, Mick 18 Jun '03

18 Jun '03

Liam, The Workbench will show cycles for the microengines and the IX bus, the 'IX bus device status' shows the IX data bus and the status pins, so you can see the cycle count when EOP is asserted, a data watch on the RFIFO elements will show you when the MPKT is written into the RFIFO. I ran the L3fwd8_1f project, this looks like 8 microengine cycles to transfer the MPKT into the RFIFO. Rgds -----Original Message----- From: Liam.Noonan [mailto:Liam.Noonan@ul.ie] Sent: 17 June 2003 12:35 To: 'ixp1200(a)CS.Princeton.EDU' Subject: [ixp1200] Monitoring the IXBus using Workbench Hi, I am trying to determine the amount of cycles/time required to transfer an Mpacket from an IXF 440 to RFIFO. I have loaded and examined the receive code from chapter 5 in the IXP 1200 book. The history window however displays the information from the microengine point of view. I am interested from both the IXF 440 and RBS point of view the amount of cycles each unit utilises to accomplish this task. Any suggestions as to how I can view this information on workbench would be appreciated. Regards Liam University of Limerick Ireland

1 0

Monitoring the IXBus using Workbench
by Liam.Noonan 17 Jun '03

17 Jun '03

Hi, I am trying to determine the amount of cycles/time required to transfer an Mpacket from an IXF 440 to RFIFO. I have loaded and examined the receive code from chapter 5 in the IXP 1200 book. The history window however displays the information from the microengine point of view. I am interested from both the IXF 440 and RBS point of view the amount of cycles each unit utilises to accomplish this task. Any suggestions as to how I can view this information on workbench would be appreciated. Regards Liam University of Limerick Ireland

1 0

FW: [ixp1200] ld DWARF error
by David Mentre 16 Jun '03

16 Jun '03

I repost my message from this morning without the attachement. You'll find the script in the below url. -----Original Message----- From: David Mentre Sent: Monday, June 16, 2003 9:26 AM To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] ld DWARF error Hello Cyrus, > From: Cyrus Hall [mailto:hallcp@cs.colorado.edu] > David Mantre's instructions are good, but I need C++ support, so only > recompiling ld seems like the best solution. You're lucky. Jeremy McNicoll also needed C++ support and made a fully automatized script to build the cross toolchain: http://lists.arm.linux.org.uk/pipermail/linux-arm/2003-May/005450.html Best regards, d.

1 0

ld DWARF error
by Cyrus Hall 13 Jun '03

13 Jun '03

I've been moving some C++ code over to the ARM lately and have run into the following error upon linking a particular program with a library I have also ported over: collect2: ld terminated with signal 11 [Segmentation fault], core dumped /usr/local/armbe/armv4b-unknown-linux/bin/ld: Dwarf Error: Could not find abbrev number 66. /usr/local/armbe/armv4b-unknown-linux/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. I used the same procedure to compile and link this particular library as several others I've ported over, and the others work just fine and dandy. If I comment out the library calls in the trouble program, every thing compiles fine. I am staticly linking. Goolge makes this appear as a binutils issue. Needless to say, this is rather disheartening, as I don't relish the idea of having to figure out how to upgrade the dev environment. I have read over David Mantre's toolchain howto from some time ago, and that's where I go next unless someone has a save. Anyone one else seen and delt with this issue? Thanks, Cyrus

1 1

Re: [ixp1200] Question on uEngine C compiler
by Shyamal Pandya 13 Jun '03

13 Jun '03

That is because there are a total of 64 sram xfer registers, so each of the four contexts of a microengine gets 16 locally addressable xfer regs, out of which 8 are read and 8 are for write. Maybe you should use global addressing for your xfer registers, which will give you access to more than 8 read xfer registers. Of course will mean you can access fewer local registers. -- Shyamal Pandya Arizona State University Addr: 920 S Terrace Rd #102 Tempe AZ 85281 Phone: 1-480-966-1982 >From: "xtan" <xtan(a)csnet1.cs.tsinghua.edu.cn> >Reply-To: ixp1200(a)CS.Princeton.EDU >To: <ixp1200(a)CS.Princeton.EDU> >Subject: [ixp1200] Question on uEngine C compiler >Date: Fri, 30 May 2003 20:49:31 +0800 > >Hello everybody, >Recently, I encountered a problem that I have to read 16 long words from >SRAM one at a time. But the sram_read intrinsic function can only support >up >to 8 long words. Besides, implementing 16 sram_reg in array format (ex. >X[16]) seems impossible.(Only 8 are allowed) > >Does anyone have good suggestions? Thanks in advance. > >Zhangxi Tan > _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

4 3

Re: [ixp1200] ACE question
by nikhil rao 10 Jun '03

10 Jun '03

This time I am trying to send a packet from the stack ace to the L3 forwarder ace using the following binding in the ixsys.config-l3fwdr bind regular stackace/tx L3Fwdr I have defined the ix_action_default in the L3Fwdr.cpp file. where I simply pass the buffer to the ifaceOutput ace. My expectation is that ix_action_default gets called for every packet that gets sent through the stackAce from the TCP/IP stack. but this doesn't happen. Does anyone have any clue why this could be the case ? Thanks, Nikhil >From: "nikhil rao" <nikhil_p_rao(a)hotmail.com> >Reply-To: ixp1200(a)CS.Princeton.EDU >To: <ixp1200(a)CS.Princeton.EDU> >Subject: [ixp1200] ACE question >Date: Mon, 9 Jun 2003 08:54:36 -0700 > >I need to send a packet from a Linux user application to the core component >of the L3Fwdr >ace. This packet will pass through the stack ace. Right now the stack ace >is >bound to egress >ace. What is the mechanism for hooking the stack ace to some callback >function in the >L3Fwdr ? > >Nikhil _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Re: [ixp1200] ACE question
by Shyamal Pandya 09 Jun '03

09 Jun '03

Hi Nikhil, You can implement a crosscall function in the L3Forwarder microace using the idl provided. Then you can call that function from the stack ace. The SDK Reference and the SDK Guide provides the necessary information on how to implement and invoke crosscall api. -- Shyamal Pandya Arizona State University Addr: 920 S Terrace Rd #102 Tempe AZ 85281 Phone: 1-480-966-1982 >From: "nikhil rao" <nikhil_p_rao(a)hotmail.com> >Reply-To: ixp1200(a)CS.Princeton.EDU >To: <ixp1200(a)CS.Princeton.EDU> >Subject: [ixp1200] ACE question >Date: Mon, 9 Jun 2003 08:54:36 -0700 > >I need to send a packet from a Linux user application to the core component >of the L3Fwdr >ace. This packet will pass through the stack ace. Right now the stack ace >is >bound to egress >ace. What is the mechanism for hooking the stack ace to some callback >function in the >L3Fwdr ? > >Nikhil _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Help reg problem with scheduler-worker design.
by Jagannathan Iyer Venkatesan 09 Jun '03

09 Jun '03

Hi, I have succeded in making the scheduler-worker design work for packets that are less than 214 bytes (size includes all the headers including the MAC header size; with UDP, the size of UDP data is 170 bytes). I have avoided reading stale rcv_rdy_lo flag by looping around using the RCV_RDY_CNT register. But when I increase the packet by 215 byte (in UDP datagram, this translates to 171 bytes of UDP data), I see overflow in the MAC registers. Also, the scenario is peculiar and is explained as follows : I use my UDP client which sends 1) a single 22 byte data first (always) [64 byte packet after MAC layers' encapsulation]. No problem with this packet. /* Also, any packet size above this will make it successfully. */ 2) Send packets of data size 171 bytes repeatedly!! The strange this, every other 171 packet makes it across to the destination. The first one does not cause any MAC overflow but the next one does cause a MAC overflow. The third 171 one makes it across the board. The fourth 171 fails. This goes on. (171 + 44 = 215 after MAC encapsulation. 64 *3 = 192; 64*4 = 256; and so the last chunk has ractional data of size 23 bytes) { the same packet sending can be repeated with data size = 172,173, etc. } 3) If I increase to very large packets, eg 234 butes, the first one and subsequent ones never make it across the board. Between packets, I have a getchar() and on key stroke, I send packets. The machines are in a linear configuration, i.e source <==> IXP <==> destn. The destn does not send any packet back. I think there is no overflow of the RCV_REQ_CNT byte in the RCV_RDY_CNT register because just 4 chunks have come. Can anyone suggest why I am getting this problem ? Any pointers will be very helpful. Jagan. PS : To gain more insight, the design looks almost as the transaltion of the following pseudocode. The thread allocation to the port is static and there is only one thread that takes care of receive from one port. The scheduler is working as follows : while(1) { read_reg(rcv_rdy_lo); old = read( RCV_RDY_CNT); /* reads value as X*/ if(rcv_rdy_lo==0) continue; see_which_microengine_has_to be informed(); construct_the_rcv_req(other_uc_TID); // so that the correct // microengine is signalled write_to_rcv_req(); new=read(RCV_RDY_CNT);/*reads value as X if transfer is not over reads value as X+1 if transfer is over. while(old <=new) { new=read(RCV_RDY_CNT); /* if X+1, then quit. */ } The worker thread looks like : while (1) { wait_for_signal(start_receive); read_the register(rcv_cntl); read_the packet_from_fifo(); eop=process_the packet(); if(eop) { peek intocache and tranmit the packet to the outgoing i/f } else { assemble the packet till eop comes. } }

3 2