- ixp1200 - lists.cs.princeton.edu

Connectivity problems
by Magesh Kannan 30 Sep '02

30 Sep '02

Hi, What kind of cabling is needed to connect the 10/100 ethernet ports on the IXP1200 to an ethernet card on another PC? I tried CAT-5 crossover cable but the LEDs on either card do not come on. I also tried straight through cable. The orange LED on the IXP ethernet port blinks and the Link LED on the other card also blinks, but it seems that connectivity is not fine. Should the ports be explicitly brought up? I only added the MAC and IP addresses of the two machines that I am trying to connect via the IXP1200 to the route cache in ipmm.c. Ping from either machine does not work and debug output on IXP's serial port does not seem to indicate any packet reception. Thanks, Magesh

2 1

Addressing I21555's Interrupt regs....
by Himanshu Raj 30 Sep '02

30 Sep '02

Hi, Does anyone know where in the Virtual address space of strong arm core are Primary Set IRQ and Primary clear IRQ of i21555 available (if they are?) I was trying to map the appropriate 512 MB addresses into the physical memory by changing CSR_PCIADDR_EXT variable whose lower half should be available in the virtual address space. Thanks, Himanshu

1 0

Problem updating flash
by Magesh Kannan 30 Sep '02

30 Sep '02

Hi, This is a follow-up to my previous mail on Friday, reporting a problem while updating the flash of an IXP1200 evaluation board with a new VERA image. Tracking the problem back from where the assertion violation occurs at Flash/ixp1200/sa/src/flash.c:61 (which checks if some bus address is less than 128M), it seems this bus address is determined when the 'vera_flash' driver is initially loaded (in the function init_module of Flash/linux-386/driver/drvVera_flash.c). The address is actually a translation of what is returned by __get_free_pages (Line 316 of drvVera_flash.c) The machine I am using has 256 MB of physical memory and the address returned by __get_free_pages and hence translated by 'virt_to_bus' can be between 0 and 256M. I am guessing that the code in flash.c assumes that the host machine has only 128MB of memory and hence the sanity check on the bus address. Is that correct? Is the flash utility designed to work with only 128MB of memory? If not, can I just modify the 'assert' call in question in flash.c and will flash updation work fine? Thanks, Magesh

2 1

I`m sorry
by Roberto Maccaferri 25 Sep '02

25 Sep '02

I`m sorry in the last letter I sad that I had problem to compile the book`s example. I made mistake, because I tried to compile it in windows (under vmware), but now that I tried under linux, it works. But I have a question, I have understand that for compile the microcode I need to use a compiler that is developed only for windows. Or I have understand wrong or in this case I don`t have this type of code. I`m sorry but probably I haven`t the idea enough clear I have to eat, maybe later I write an other e-mail where I`m going to explain better what I have not understood Bye Thanks Ronberto Maccaferri

1 0

Help
by Roberto Maccaferri 25 Sep '02

25 Sep '02

I`m Roberto I work at Computer Science Departement at UCLA, I am new about this topic of research and I have been started for a month, now I`m studing the ixp1200. I read the documentation "tutorial" and the "Developer`s guide" and the book "ixp1200 Programming" but I have not the idea very clear. I was able to compile and to run the example of the tutorial. Now I would like to do something but I think the tutorial does not cover all the aspect, like IDL call and the use of Resource Manager. I also had some problem to compile the example of the bool chapter 11 when I compile, writing malke I recive the message: tao_idl:not found make[3]:***[source/idl/bridging_sk_c.c] Error 127 I ask if someone has other tutorial or some guides (made for internal purposes) or some programs that I could use as example for better understanding the ixp1200 functionaliti Last question, I remember to have read (but I don`t remember where) that if I don`t have the licence for Cmicrocode I can only compile tha programs for only degud purpose. Is it right? Thanks an advance for the reply Roberto Maccaferri

1 0

VMware Host-Only Mode
by Jo Ueyama 25 Sep '02

25 Sep '02

All, I can not run Vmware (host-only mode) properly, since whenever I boot win2k from Linux host, Vmware starts detecting and installing new devices again and again. Moreover, it can not carry out the installation since an error occurs during the installation of the device, saying that the 'data is invalid'. This happen for net card, video and ide controller installation. Does it mean that my devices (net card, video and ide disk) are not supported by Vmware? BTW, has anyone ever faced this such problem? Any hint/tip is quite welcome! With Thanks, -Jo

1 0

Error building IPmm
by Magesh Kannan 23 Sep '02

23 Sep '02

I get the following errors when trying to make IPmm ============= echo "Linking main.o" Linking main.o arm-unknown-coff-ld -o ipmm.coff /home/magesh/ixp1200/Vera/Runtime/ixp1200/sa/lib/crt0.o main.o ipmm.o /home/magesh/ixp1200/Vera/Libsck/lib/arm/libsck.a /home/magesh/ixp1200/Vera/Libesc/lib/arm/libesc.a /home/magesh/ixp1200/Vera/Runtime/ixp1200/sa/lib/libIXP1200.a /home/magesh/ixp1200/Vera/Libixprouter/sa/lib/libIXPRouter.a /home/magesh/ixp1200/Vera/Libcii/lib/arm/libcii.a -L/home/magesh/ixp1200/Vera/Libcii/lib/arm -L/home/magesh/ixp1200/Vera/Libesc/lib/arm -L/home/magesh/ixp1200/Vera/Libixprouter/sa/lib -L/home/magesh/ixp1200/Vera/Libsck/lib/arm -L/home/magesh/ixp1200/Vera/Runtime/ixp1200/sa/lib -L/usr/xcc/arm/lib/gcc-lib/arm-unknown-coff/2.95.2 -X -T /home/magesh/ixp1200/Vera/Runtime/ixp1200/sa/lib/coffarmIXP1200.x -lsck -lesc -lIXP1200 -lIXPRouter -lcii -lgcc /home/magesh/ixp1200/Vera/Libixprouter/sa/lib/libIXPRouter.a(control.o)(.text+0xb4):fake: undefined reference to `atoi' /home/magesh/ixp1200/Vera/Libixprouter/sa/lib/libIXPRouter.a(control.o)(.text+0xb4):fake: relocation truncated to fit: ARM_26 atoi ========== Which library defines the function 'atoi'? Thanks, Magesh

2 1

looking for microcode transmit and recive scheduelers exampels
by tomer 20 Sep '02

20 Sep '02

hi, I am looking for microcode and macro transmit and receive priority schedulers examples for the microengens. thanks rotem.

1 0

Jump instruction in C compiler
by xtan＠mail 19 Sep '02

19 Sep '02

Hello everyone, Problem has it that the C compiler does not support jump instruction of ixp1200. Thus the switch-case statement will not gain benefit from the jump instruction. As we know jump instruction with 'target' option token could easily depict the switch-case scenery which means a better run time performance. But the C compiler does not allow this instruction. Currently I try br=byte instruction instead, but the performance still not match. If there are any methods I can generate the jump instruction (with target token) in C environment? Thanks Zhangxi Tan Dept. of CS Tsinghua Univ.

1 0

Error building Libixprouter
by Magesh Kannan 18 Sep '02

18 Sep '02

Hi, I tried to make the latest version of Libixprouter and get the following errors ======= make[2]: *** No rule to make target `p3tosa.h', needed by `copyhdrs'. Stop. make[1]: *** [install] Error 2 control.c:25: config.h: No such file or directory In file included from control.c:28: queue.h:21: config.h: No such file or directory control.c:29: ucode.h: No such file or directory make[2]: *** [control.o] Error 1 make[1]: *** [install] Error 2 ======= Please tell me how to fix it. Where do I find the updated firmware that should be downloaded to the flash? Is it built as a result of making Libixprouter? Thanks, Magesh

2 1

loking for priority scheduling examples
by tomer 17 Sep '02

17 Sep '02

hi , I am running the software release microcode "pfwd16" and I am looking for receive and transmit schedulers microcode examples on priority scheduling. thanks.. rotem.

1 0

Call for Papers: IEEE Network Magazine -- special issue on Networ k Processors: Architectures, Tools and Applications
by Vin, HarrickX 13 Sep '02

13 Sep '02

Our apologies if you receive multiple copies of this announcement. CALL FOR PAPERS IEEE Network Magazine Special Issue on Network Processors: Architectures, Tools, and Applications Guest Editors: Raj Yavatkar Prof. Harrick Vin Intel Corporation Department of Computer Sciences 2111 NE 25th Avenue, JF3-462 University of Texas at Austin Hillsboro, OR, 97124 Austin, TX 78712-1188 raj.yavatkar(a)intel.com vin(a)cs.utexas.edu Tel: (503) 264 9077 Tel: (512) 471-9732 Scope: The rapid and pervasive evolution of the Internet has created an insatiable need for supporting sophisticated services and high bandwidth at both edges of the network and within the network infrastructure. Traditionally, telecom and datacom equipment vendors have used fixed-function ASICs to implement packet-processing functions in hardware. However, such ASICs provide little flexibility when the type or nature of the media interfaces change or new protocol standards require changes to lookup operations or header processing. To meet the demand for higher performance, flexibility, and economy, an alternative to ASICs, called network processors (NPs), has emerged. These processors are programmable and their designs are optimized for processing packets; they can be used to implement efficiently a wide range of network services such as IP datagram forwarding, label switching, content-based routing, voice-over-packet, VPNs, and Quality of Service (QoS). We use the term network processor here in a generic sense to represent devices ranging from task-specific processors, such as classification and encryption engines, to more general-purpose, programmable packet or communications processors. Because many of these NPs are programmable, they offer a significant advantage over ASICs as new features or functions can be introduced or modified easily without having to re-design a network component. Design and development of networking systems using network processors is an emerging field that offers numerous challenges and opportunities. The goal of this special issue is to publish contributions from both industry and academia that describe the state-of-the-art in the architecture, design, programming, software tools, and use of network processors. Papers with tutorial/survey content are also welcome. Topics of particular interest include (but are not limited to): * Architectures for network processors * Novel product designs based on NPs * Co-processors for search/lookup, packet classification, compression, encryption and security, etc. * Design and implementation of new techniques/algorithms for QoS, voice-over-packet, wireless communication, etc * Programming languages, tools, and development environments for software development on NPs * Benchmarking and performance analysis * Interfaces to high-speed packet buses and switch fabrics * Techniques for accelerating network services * Performance measurement and analysis * Novel applications made possible by NPs Submission Guidelines: Interested authors should submit an electronic version of the manuscript either in Postscript or PDF format as an email attachment to one of the guest editors. Additional information including "Guidelines for authors" is available at the IEEE Network Website: http://www.comsoc.org/pubs/net/ntwrk/authors.html Important Dates: Paper Submission Deadline: October 30, 2002 Feedback to Authors: February 1, 2003 Final Manuscripts to Publisher: April 1, 2003 Publication of Special Issue: July 2003

1 0

reading statistics registers from the ixf440 ( ixp12eb)
by tomer 12 Sep '02

12 Sep '02

Hi I am working on the ixp12eb supported by the vxworks os. I am trying to read the statistic registers from the ixf440, so far no success. I went through your example codes. In the control.c file ( libixprouter.tar ) i saw that you use the scratchRead32( ) function to do the job. I could not find this function. Can you advise me on this matter? You my find this Q too obvious, but i am a beginner on the system, anything is helpful to me. thanks Tomer.

3 4

help, ACE Framework.
by Timen 11 Sep '02

11 Sep '02

hi, Some problems about IXP1200 troubles me now. I'm running 2.01 software release. When I test the Microcode "L3fwd16" with "PETH", I found, if I ftp packets (more than 100Mbytes) from a computer to another one, the packets transmitting always stop occasionally. And I found the reason is that three transmit threads of MicroEngine 4/5 stop forever. Everytime, always one transmit thread stops at the Macro: tx_packetlinklist_read[]. It made me puzzle. Finally, it seems that I got the answer from the two articles: "pethTestplan.doc" and "pethDriverNotes.doc". The articles let me know there is a bug in the hardware that occasionally causes "sram_read_lock()" fails. And in the Macro: tx_packetlinklist_read[], there is exactly an instruction as followed: sram[read_lock, out_xfr_queue_descriptor0, in_queue_descriptor_base, in_queue_offset, 2], priority, ctx_swap "The best solution is to eliminate the need to use SRAM CAM locks from the core. This can be accomplished with a ring data structure that decouples the "producer" and "consumer" information. " Then, I tested the "L3_8_1Gig" microcode project. It exactly has this idea. And, finally, I found, when I transmit packet again, it runs very well. Never stop. But, the speed of transmitting packets is just about 7.6e+02 Kbytes/sec , much lower than "peth"(about 5Mbytes/sec). Could you tell me why? Is it caused by ACE Framwork? How can I deal with it? Best regards! 　　　　　　　　Timen 　　　　　　　　hhf(a)sunyard.com 　　　　　　　　　　2002-09-12

1 0

SDK 2.01a : Problems in reserving memory for variables
by Yannis Haritakis 09 Sep '02

09 Sep '02

Hi all, Under SDK 2.01a the following problem occured: Eventhough the linker is instructed to use addresses above 0x200 for variables (residing in scratch pad), it falsely allocates space that starts from address 0x0. That means address 0x0 is handled both for a variable declared in scratch pad, and by code that explicitly operates on that address. I have attached the files of a project that demostrate the problem. It can easily be demostrated if you run the simulation for 100cycles. Check the references of thread 0. Below is the code : Note that : 1) The linker is instructed of which address space to use for variables via the menu Build->Settings->Linker->Reserved Space for variables 2) The false assigment occurs only in optimize for speed, and optimize for size cases. 3) It only allocates falsely the buf array of thread 0 #include "ixp.h" void main(void) { __declspec(scratch) unsigned int buf[20]; unsigned int i; while (1) { for (i=0; i<20; i=i+1) buf[i] = 1; ctx_swap(); for (i=0; i<20; i=i+1) if (buf[i] == 1) buf[i] = 2; } } If anyone is interested on reproducing the problem i can send the whole project files. (I said If! :-) ) Thanks Yannis Charitakis haritak(a)ics.forth.gr

1 0

Generating packets in the SDK
by Shruti Gorappa 09 Sep '02

09 Sep '02

Hi I have just begun learning about the IXA. I want to try to send some kind of control information to and from my machine (That is running the reference design). I want to know if I can build and transmit control packets using the SDK. Also, is there some way that I can connect the machine that I am using to another machine and bounce control information between them. Thanks! SG

1 0

Multiple newbie questions
by Magesh Kannan 06 Sep '02

06 Sep '02

Hi All, I am trying to get started on learning to program the IXP1200 and have some questions. I have access to the IXP1200 evaluation board and IXA SDK 2.0 1. IXA SDK 2.0 comes with a 60-day free trial of the Microengine C compiler. However, there seems to be a bug in the installation program that prevents me from installing the trial version. If I choose not to enter a license key, the setup aborts without installing anything. Has anyone faced this problem? 2. I am planning to get the Intel book "IXP1200 Programming". The examples in the book are in Microengine C. Given the above problem with SDK 2.0, I may not be able to install even a trial version of the Microengine C compiler. What's the difference between Microengine C and the C used in Vera? Will the book be useful in understanding (say) LibIXPRouter? 3. If I can get hold of the Microengine C compiler, will I be able to use the IXP1200 evaluation board to run the examples in the Intel book? Excuse me if some of these questions are a little off-topic. Thanks for your help, Magesh Graduate Research Assistant Information and Telecommunication Technology Center The University of Kansas Lawrence, KS

1 0

RE: [ixp1200] Fast Ports - sop_seq roll over
by Johnson, Erik J 06 Sep '02

06 Sep '02

I will agree with you, that the most probable is this: the RSM updates SOP_SEQ and pushes the rcv_cntl info into the 4-entry FIFO. That is, changing SOP_SEQ register before the thread reads the corresponding rcv_cntl register. This means that if 4 SOP-MPKTs arrive back to back (that is 4 PACKETS of length 64Bytes arrive back to back), then when a thread reads the rcv_cntl register from the top of the FIFO queue, the SOP_SEQ register will already have changed three more times. Moreover, assuming that a thread executes the above two commands (repeated bellow): > csr_read(sop_seq, sync_none); > csr_read(rcv_cntl, ctx_wait); Both commands will be queued in the same fbi-fifo (in the pull engine). But before that the two commands will have to be queued in the local (to the uengine fifo), and then the Bus Arbiter will decide if both commands will go back to back on the shared bus to the pull engine or if they will be split in order for another microengine to be serviced. If the Bus Arbiter is servicing a microengine until no more requests exist, then we are ok. If not then we have no guarantee. Am I right??? Does anyone have more information?? [Erik J. Johnson] My experiments agree with the above conclusions/assumptions. Namely, the two values do differ. However, I don't think that this is a consequence of the two commands not being serviced "atomically", I think this is entirely due to the fact that the SOP_SEQ is updated immediately by the RSM. erik ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yannis Charitakis haritak(a)ics.forth.gr

1 0

hash unit
by Damien 05 Sep '02

05 Sep '02

Does anyone know exactly what function the hash unit implements? I'm getting weird results for my test hashes and I want to double check it against what I'm supposed to get. --Damien

2 1

RE: [ixp1200] microC development
by Kunze, Aaron 05 Sep '02

05 Sep '02

Najati, If you are using the workbench, the process for loading microC is the same as the process for loading microengine assembly. It's been a long time since I've loaded any code without the microACE framework, so my memory is rusty. :) If your board is running Linux, you have to make sure that the ue.o driver is loaded and that the rs_udebug process is running in the background. Both of these ship with the SDK and can be found in ixasdk/bin/arm-be. Then, in the workbench hardware settings on your development system, say "Connect via Ethernet" and give it the IP address of the debug port of the board. If you are using VxWorks, the development system side is the same, but on the board you need to run VxWorksNetApp.o. There is a readme file with the workbench that can walk you through this process. It is called VxWorksBuild_ReadMe.txt. Hope this helps! Aaron ------------------------ Aaron Kunze Intel Labs aaron.kunze(a)intel.com -PGP Key ID: 0x81124B7C- -NOT SPEAKING FOR INTEL- ------GO BOILERS!!------ > -----Original Message----- > From: Najati Imam [mailto:nrimam0@uky.edu] > Sent: Wednesday, September 04, 2002 1:47 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: Re: [ixp1200] microC development > > > > > Let me clarify this a bit. Development of microC > *microACEs* is not > > supported by Intel in IXA SDK 2.x. Use of microC outside of the > > microACE framework is supported and microC code will run on the > > IXP1200 hardware. > > Oh? thats cool. What does one need as far as run time > environment to do > so? Namely, can one take a uof compiled from the workbench > and start it > on a microengine(s) and if so how? > > guilt >

2 1

l3fwdr weird behavior
by Nimit Sawhney 05 Sep '02

05 Sep '02

We are trying to run the "l3fwdr" project on the IXP1200 hardware and are facing a weird problem. The setup is: OS: Suse linux 8.0 (2.4.18) The PCI driver works correctly (ping between the host & target works) Port 0 of the IXP board is connected to another linux machine via a cross-over cable. After the NFS mount, when we try the "ixstart", tcpdump on the above mentioned linux machine's interface starts showing an "insane" number of received packets. Here is a snapshot. 04:22:38.693713 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 04:22:38.694229 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 04:22:38.694580 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 04:22:38.694910 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 04:22:38.695319 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 The moment we type "ixstop", this packet flow stops. We are using the "ixsys.config-l3fwdr" with 4 interfaces configured. The ping between this second linux machine and IXP board (via the cross cable) doesnt work inspite of all the route/arp entries being correct although at least some of packets seem to be getting through (the RX/TX counts of the interfaces do change) We had a similar setup working last year (with an older version of the driver and ofcourse an older linux kernel). The version we are trying to use now is the one distributed at the IXA event this year in May. Any ideas as to the cause of this problem ???? Thanks in advance, Rgds, -Nimit

1 0

RE: [ixp1200] Fast Ports - sop_seq roll over
by Johnson, Erik J 04 Sep '02

04 Sep '02

I guess I am the guilty party again =). Comments are inline. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Yannis Haritakis [mailto:haritak@ics.forth.gr] Sent: Wednesday, September 04, 2002 10:46 AM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] Fast Ports - sop_seq roll over Hi, Based on the example of Fast Port usage of the book programming IXP1200 (intel press), I made the following observation. (If familiar please respond). The example uses sop_seq field from rcv_ctl register in order to put the MPKTs of a PACKET in the correct order. <erik> No, it doesn't. It uses the SOP_SEQ fields to order packets, not mpackets. Mpacket ordering is ensured through the interthread signals. (See page 227, first paragraph). I think the point was the this field could be used to order mpackets, but the example does not do that. However, in general, using the sop_seq allows for only 16 different MPKTS. That is, the number rolls over after 0xF. A 1500bytes PACKET results in 24 MPKTS. If more than one thread handle these MPKTS in parallel, there is a possibility for two threads to receive the same sop_seq. <erik> See answer above. What is precluded is receiving more than 16 packets simultaneously, since then the packet ordering might be lost. Again, that is an implementation issue. Interthread signaling (or any kind of ordered lock) could be used ensure packet ordering if you needed more than 16 packets to be received simultaneously. Another relative issue is the next one : In the book it is written that the sop_seq field of rcv_cntl register, follows the values of the sop_seq register. This is wrong. The sop_seq register changes only when an SOP-MPKT is received, while the sop_seq field in rcv_cntl register behaves as described in the book. (Always increases, and get the sop_seq value when a SOP-MPKT is received). To support this behavior there are two counters (documented in hardware reference manual) <erik> Good point. I'll add the correction/clarification to the book's errata. The two fields only track for SOP mpackets. Now the question is this : If a thread, after the ctx_wait(start_receive) executes two back-to-back csr_reads : csr_read(sop_seq, sync_none); csr_read(rcv_cntl, ctx_wait); will end up having two sop_seq: The value of the register and the field of rcv_cntl. Will the value of the register be the sop-seq number that was assigned to the PACKET that this thread is working for ? <erik> for the same reason you mentioned above. Now, the more interesting question is if the mpacket is an SOP, will the two values be the same? In that case, there still seems to me to be the possibility of them differing (i.e., a race condition) if the SOP_SEQ register is updated based on the RSM receiving the mpacket (instead of after the rcv control register is read). I am not sure of the actual behavior of the hardware. I think the answer is "no necessarily"! Yannis Charitakis haritak(a)ics.forth.gr

2 1

RE: [ixp1200] microC development
by Kunze, Aaron 04 Sep '02

04 Sep '02

Najati, Let me clarify this a bit. Development of microC *microACEs* is not supported by Intel in IXA SDK 2.x. Use of microC outside of the microACE framework is supported and microC code will run on the IXP1200 hardware. A ------------------------ Aaron Kunze Intel Labs aaron.kunze(a)intel.com -PGP Key ID: 0x81124B7C- -NOT SPEAKING FOR INTEL- ------GO BOILERS!!------ > -----Original Message----- > From: Najati Imam [mailto:nrimam0@uky.edu] > Sent: Wednesday, September 04, 2002 10:42 AM > To: ixp1200(a)CS.Princeton.EDU > Subject: [ixp1200] microC development > > > We've recently found out from our Intel guys that the SDK does not > supposed running microC-developed images on the IXP1200 hardware. Is > there no way to use microC (or anything but microcode, really) to > develop for the microengines? > > Najati >

2 1

RE: [ixp1200] False register allocation (similar to Francis and S rinivasan)
by Johnson, Erik J 04 Sep '02

04 Sep '02

I think I misread the note. What you have seems like a defect in the compiler. It should never reuse the transfer register $0 in this case. The free_write_buffer() intrinsic would enable the compiler to reuse the transfer register. If you want to send me the code, I can try to reproduce the problem. erik ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Johnson, Erik J [mailto:erik.j.johnson@intel.com] Sent: Wednesday, September 04, 2002 10:48 AM To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] False register allocation (similar to Francis and S rinivasan) Actually, I believe the preferred (and required) solution is the free_write_buffer() intrinsic. This informs the compiler of the life time of any write transfer registers. So after the second call, put free_write_buffer(&swrtmp); erik ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Yannis Haritakis [mailto:haritak@ics.forth.gr] Sent: Wednesday, September 04, 2002 10:19 AM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] False register allocation (similar to Francis and Srinivasan) Hi, another variant of false register allocation occured in SDK 2.01a but this time using optimizations for speed. Below you will find the generated code and two workarounds: /**************************************************************** The compiler falsely reuses sram_write_register $0. $0 is first used to hold swrtmp and then is used to hold swrtmp2 Therefore, both writes to scratch write the same value : the value of swrtmp2. ****************************************************************/ immed[$0, -1, 0] //swrtmp = 0xffffffff; scratch[write, $0, _myTID:a2, 17, 1] //scratch_write(&swrtmp, BASE_THREAD_SLOTS + myTID, 1, sync_none); alu[$0, --, B, _myCTX:b1] //swrtmp2 = myTID; scratch[write, $0, rc_sop_seq_315_V$99$1$0:b0, 0, 1], ctx_swap //scratch_write(&swrtmp2, rc_sop_seq, 1, ctx_swap); /* Workarounds: 1. context swap after first scratch write By adding a ctx_swap after the second command the context will be swapped and when awakened it will be able to reuse the $0 (not a good solution though....) 2. Change the order of the commands. (PREFFERED) First do the assignments and then do the intrinsic function calls. This way the compiler produces the following code which is correct: //swrtmp = 0xffffffff; //swrtmp2 = myTID; //scratch_write(&swrtmp, (__declspec(scratch) void *) (BASE_THREAD_SLOTS + myTID), 1, sync_none); //scratch_write(&swrtmp2, (__declspec(scratch) void *) rc_sop_seq, 1, ctx_swap); immed[$0, -1, 0] alu[$1, --, B, _myCTX:b1] scratch[write, $0, _myTID:a2, 17, 1] scratch[write, $1, rc_sop_seq_315_V$99$1$0:b0, 0, 1], ctx_swap Yannis Charitakis haritak(a)ics.forth.gr Foundation of Research and Technology Heraklion Crete Greece On Thu, 29 Aug 2002, Deepa Srinivasan wrote: > I saw another variant of this problem (reported by Francis Chang for > the the example in Chapter 5 of the IXP book). When run in unoptmized > mode, the compiler generates the following code (My comments start > with //*** ) > > For: > buf_handle = receive_packet(0, 5, &cur_pkt_len); > > Code generated: > /******/ buf_handle = receive_packet(0, 5, &cur_pkt_len); > l_8#: > immed[port_num_96_V$bc$2$5:a4, 0, <<0] //*** USES SAME REGISTER a4 > immed[rfifo_num_96_V$bd$2$5:a4, 5, <<0] //*** USES SAME REGISTER a4 > br[_receive_packet#], defer[1] > load_addr[a2, l_55#] > ------------------ > The same register is being used for both the in parameters. > ----------------- > > If I change the function receive_packet to use temporary variables: > > buffer_handle_t receive_packet( unsigned int port_num , > unsigned int rfifo_num , > unsigned int *pkt_length) > { > unsigned int a = 0, b = 0; //*** temp variables > rcv_state_t rcv_state = { 0 }; > rcv_cntl_reg_t rcv_control; > __declspec(sdram) void *buf_data_ptr; > > a = port_num; //*** temp variables > b = rfifo_num; //*** temp variables > > do > { > rcv_control = get_mpacket(a, b); //*** use temp variables instead of > original code: rcv_control = get_mpacket(port_num, rfifo_num); *** > ... ... > } > ------------- > This produces the following code: > > immed[port_num_96_V$bc$2$5:a0, 0, <<0] //*** USES different register a0 > *** > immed[rfifo_num_96_V$bd$2$5:a4, 5, <<0] //*** USES different register a4 > *** > br[_receive_packet#], defer[1] > load_addr[b3, l_55#] > /******/ scratch_incr(cntr, no_signal); > l_55#: > scratch[incr, --, cntr_105$2$4:b0, 0, 1], no_signal > /******/ *byte_count += cur_pkt_len; > > scratch[read, $0, byte_count_105$2$4:a2, 0, 1], ctx_swap sram[read, > $1, pkt_length_96_V$be$2$5:b3, 0, 1], ctx_swap ..... > ..... > > ---------------- > On return from the function call, the value of cntr is overwritten by > code within the function (that writes the out value pkt_lenth to the > same register b0). I can send more detailed code if required. Is there > a workaround/fix for this, (where the registers do not get corrupted > in Debug mode)? > > Thanks, > Deepa > > > From: "Francis" <francis(a)francischang.com> > To: <ixp1200(a)CS.Princeton.EDU> > Subject: [ixp1200] IXA SDK Bug > Date: Mon, 12 Aug 2002 07:58:52 -0700 > > There seems to be a bug in the uEngine C Compiler, when run in > unoptimized mode. I was wondering if anyone's seen this behaviour > before, and if they can suggest work-arounds. > > One of the sample IXA applications (single-threaded-packet counter) > I'm looking at exhibits this bug. It works on the "optimize for speed" > settings, but when I put it into the non-optimized mode, it generates > questionable micro-engine assembly output. > > The compiler seems to want to use GPR a0 to store both a pointer into > scratch memory, as well as function return address. Predictably, this > causes problems :) > > This behaviour is consistent in the Intel IXA Software Developers Kit > for IXP1200, versions 2.0, 2.01 and 2.01a. > > -- > Francis > > > >From owner-ixp1200(a)upright.CS.Princeton.EDU Tue Aug 13 19:13:22 2002 > Received: (from daemon@localhost) > by upright.CS.Princeton.EDU (8.11.6/8.11.6) id g7DND3w21081; Tue, 13 > Aug 2002 19:13:03 -0400 (EDT) > Mailbox-Line: From vkrish(a)cs.ucr.edu Tue Aug 13 16:12:57 2002 > Date: Tue, 13 Aug 2002 16:12:56 -0700 (PDT) > From: Vaishnavi Krishnamurthy <vkrish(a)cs.ucr.edu> > To: <ixp1200(a)CS.Princeton.EDU> > Subject: [ixp1200] Optimization > Message-ID: <Pine.LNX.4.30.0208131610170.30815-100000(a)hill.cs.ucr.edu> > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > X-Spam-Status: No, hits=0.0 required=5.0 > tests=none > version=2.31 > X-Spam-Level: > X-Virus-Scanned: by AMaViS perl-11 > Sender: owner-ixp1200(a)CS.Princeton.EDU > Reply-To: ixp1200(a)CS.Princeton.EDU > > Hi Francis, > I have had the same problem as you..when optimized for size or speed > there are no errors but when the program is made to run without any > optimization it gives some error. Is there any way to remove these > errors? Please let me know. Thanks, > vaish. > > > >From owner-ixp1200(a)upright.CS.Princeton.EDU Tue Aug 13 19:42:01 2002 > Received: (from daemon@localhost) > by upright.CS.Princeton.EDU (8.11.6/8.11.6) id g7DNfvN25523; Tue, 13 > Aug 2002 19:41:57 -0400 (EDT) > From: "Francis" <francis(a)francischang.com> > To: <ixp1200(a)CS.Princeton.EDU> > Subject: RE: [ixp1200] IXA SDK Bug > Date: Tue, 13 Aug 2002 16:41:36 -0700 > Message-ID: <MGEPIIPBFFLPBNIPBJLEEECNCIAA.francis(a)francischang.com> > MIME-Version: 1.0 > Content-Type: text/plain; > charset="US-ASCII" > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > Sender: owner-ixp1200(a)CS.Princeton.EDU > Reply-To: ixp1200(a)CS.Princeton.EDU > > It's been suggested that I should provide some more details on this > particular problem, so here goes :) > > The sample code I have is from "IXP1200 Programming" by Erik J. > Johnson and Aaron R. Kunze. It's chapter 5's sample, the > single-threaded packet counter. > > This is an excerpt of the uC compiler output. > // My comments will in C++ style > > // Initialize the cntr variable, as GPR a0 > ;****** cntr = (__declspec(scratch) unsigned int *)0; > immed[cntr_109$2$4:a0, 0, <<0] > // Write "0" into the scratchpad memory > ;****** *cntr = 0; > immed[$0, 0, <<0] > scratch[write, $0, cntr_109$2$4:a0, 0, 1], ctx_swap > // Call the receive_packet function. Load the return address into a0 > ;****** buf_handle = receive_packet(0, 5, &cur_pkt_len); > immed[port_num_100_V$ca$2$5:b2, 0, <<0] > immed[rfifo_num_100_V$cb$2$5:a2, 5, <<0] br[_receive_packet#], > defer[1] load_addr[a0, l_55#] > // Increment the packet count in scratch memory. Notice, however, that a0, > // the pointer to scratch memory a0 now contains the return address of > // label 1_55#, and not a valid pointer into scratch memory. > l_55#: > ;****** scratch_incr(cntr, no_signal); > scratch[incr, --, cntr_109$2$4:a0, 0, 1], no_signal > > > -- > Francis > >

1 0

RE: [ixp1200] False register allocation (similar to Francis and S rinivasan)
by Johnson, Erik J 04 Sep '02

04 Sep '02

Actually, I believe the preferred (and required) solution is the free_write_buffer() intrinsic. This informs the compiler of the life time of any write transfer registers. So after the second call, put free_write_buffer(&swrtmp); erik ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Yannis Haritakis [mailto:haritak@ics.forth.gr] Sent: Wednesday, September 04, 2002 10:19 AM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] False register allocation (similar to Francis and Srinivasan) Hi, another variant of false register allocation occured in SDK 2.01a but this time using optimizations for speed. Below you will find the generated code and two workarounds: /**************************************************************** The compiler falsely reuses sram_write_register $0. $0 is first used to hold swrtmp and then is used to hold swrtmp2 Therefore, both writes to scratch write the same value : the value of swrtmp2. ****************************************************************/ immed[$0, -1, 0] //swrtmp = 0xffffffff; scratch[write, $0, _myTID:a2, 17, 1] //scratch_write(&swrtmp, BASE_THREAD_SLOTS + myTID, 1, sync_none); alu[$0, --, B, _myCTX:b1] //swrtmp2 = myTID; scratch[write, $0, rc_sop_seq_315_V$99$1$0:b0, 0, 1], ctx_swap //scratch_write(&swrtmp2, rc_sop_seq, 1, ctx_swap); /* Workarounds: 1. context swap after first scratch write By adding a ctx_swap after the second command the context will be swapped and when awakened it will be able to reuse the $0 (not a good solution though....) 2. Change the order of the commands. (PREFFERED) First do the assignments and then do the intrinsic function calls. This way the compiler produces the following code which is correct: //swrtmp = 0xffffffff; //swrtmp2 = myTID; //scratch_write(&swrtmp, (__declspec(scratch) void *) (BASE_THREAD_SLOTS + myTID), 1, sync_none); //scratch_write(&swrtmp2, (__declspec(scratch) void *) rc_sop_seq, 1, ctx_swap); immed[$0, -1, 0] alu[$1, --, B, _myCTX:b1] scratch[write, $0, _myTID:a2, 17, 1] scratch[write, $1, rc_sop_seq_315_V$99$1$0:b0, 0, 1], ctx_swap Yannis Charitakis haritak(a)ics.forth.gr Foundation of Research and Technology Heraklion Crete Greece On Thu, 29 Aug 2002, Deepa Srinivasan wrote: > I saw another variant of this problem (reported by Francis Chang for > the the example in Chapter 5 of the IXP book). When run in unoptmized > mode, the compiler generates the following code (My comments start > with //*** ) > > For: > buf_handle = receive_packet(0, 5, &cur_pkt_len); > > Code generated: > /******/ buf_handle = receive_packet(0, 5, &cur_pkt_len); > l_8#: > immed[port_num_96_V$bc$2$5:a4, 0, <<0] //*** USES SAME REGISTER a4 > immed[rfifo_num_96_V$bd$2$5:a4, 5, <<0] //*** USES SAME REGISTER a4 > br[_receive_packet#], defer[1] > load_addr[a2, l_55#] > ------------------ > The same register is being used for both the in parameters. > ----------------- > > If I change the function receive_packet to use temporary variables: > > buffer_handle_t receive_packet( unsigned int port_num , > unsigned int rfifo_num , > unsigned int *pkt_length) > { > unsigned int a = 0, b = 0; //*** temp variables > rcv_state_t rcv_state = { 0 }; > rcv_cntl_reg_t rcv_control; > __declspec(sdram) void *buf_data_ptr; > > a = port_num; //*** temp variables > b = rfifo_num; //*** temp variables > > do > { > rcv_control = get_mpacket(a, b); //*** use temp variables instead of > original code: rcv_control = get_mpacket(port_num, rfifo_num); *** > ... ... > } > ------------- > This produces the following code: > > immed[port_num_96_V$bc$2$5:a0, 0, <<0] //*** USES different register a0 > *** > immed[rfifo_num_96_V$bd$2$5:a4, 5, <<0] //*** USES different register a4 > *** > br[_receive_packet#], defer[1] > load_addr[b3, l_55#] > /******/ scratch_incr(cntr, no_signal); > l_55#: > scratch[incr, --, cntr_105$2$4:b0, 0, 1], no_signal > /******/ *byte_count += cur_pkt_len; > > scratch[read, $0, byte_count_105$2$4:a2, 0, 1], ctx_swap sram[read, > $1, pkt_length_96_V$be$2$5:b3, 0, 1], ctx_swap ..... > ..... > > ---------------- > On return from the function call, the value of cntr is overwritten by > code within the function (that writes the out value pkt_lenth to the > same register b0). I can send more detailed code if required. Is there > a workaround/fix for this, (where the registers do not get corrupted > in Debug mode)? > > Thanks, > Deepa > > > From: "Francis" <francis(a)francischang.com> > To: <ixp1200(a)CS.Princeton.EDU> > Subject: [ixp1200] IXA SDK Bug > Date: Mon, 12 Aug 2002 07:58:52 -0700 > > There seems to be a bug in the uEngine C Compiler, when run in > unoptimized mode. I was wondering if anyone's seen this behaviour > before, and if they can suggest work-arounds. > > One of the sample IXA applications (single-threaded-packet counter) > I'm looking at exhibits this bug. It works on the "optimize for speed" > settings, but when I put it into the non-optimized mode, it generates > questionable micro-engine assembly output. > > The compiler seems to want to use GPR a0 to store both a pointer into > scratch memory, as well as function return address. Predictably, this > causes problems :) > > This behaviour is consistent in the Intel IXA Software Developers Kit > for IXP1200, versions 2.0, 2.01 and 2.01a. > > -- > Francis > > > >From owner-ixp1200(a)upright.CS.Princeton.EDU Tue Aug 13 19:13:22 2002 > Received: (from daemon@localhost) > by upright.CS.Princeton.EDU (8.11.6/8.11.6) id g7DND3w21081; Tue, 13 > Aug 2002 19:13:03 -0400 (EDT) > Mailbox-Line: From vkrish(a)cs.ucr.edu Tue Aug 13 16:12:57 2002 > Date: Tue, 13 Aug 2002 16:12:56 -0700 (PDT) > From: Vaishnavi Krishnamurthy <vkrish(a)cs.ucr.edu> > To: <ixp1200(a)CS.Princeton.EDU> > Subject: [ixp1200] Optimization > Message-ID: <Pine.LNX.4.30.0208131610170.30815-100000(a)hill.cs.ucr.edu> > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > X-Spam-Status: No, hits=0.0 required=5.0 > tests=none > version=2.31 > X-Spam-Level: > X-Virus-Scanned: by AMaViS perl-11 > Sender: owner-ixp1200(a)CS.Princeton.EDU > Reply-To: ixp1200(a)CS.Princeton.EDU > > Hi Francis, > I have had the same problem as you..when optimized for size or speed > there are no errors but when the program is made to run without any > optimization it gives some error. Is there any way to remove these > errors? Please let me know. Thanks, > vaish. > > > >From owner-ixp1200(a)upright.CS.Princeton.EDU Tue Aug 13 19:42:01 2002 > Received: (from daemon@localhost) > by upright.CS.Princeton.EDU (8.11.6/8.11.6) id g7DNfvN25523; Tue, 13 > Aug 2002 19:41:57 -0400 (EDT) > From: "Francis" <francis(a)francischang.com> > To: <ixp1200(a)CS.Princeton.EDU> > Subject: RE: [ixp1200] IXA SDK Bug > Date: Tue, 13 Aug 2002 16:41:36 -0700 > Message-ID: <MGEPIIPBFFLPBNIPBJLEEECNCIAA.francis(a)francischang.com> > MIME-Version: 1.0 > Content-Type: text/plain; > charset="US-ASCII" > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > Sender: owner-ixp1200(a)CS.Princeton.EDU > Reply-To: ixp1200(a)CS.Princeton.EDU > > It's been suggested that I should provide some more details on this > particular problem, so here goes :) > > The sample code I have is from "IXP1200 Programming" by Erik J. > Johnson and Aaron R. Kunze. It's chapter 5's sample, the > single-threaded packet counter. > > This is an excerpt of the uC compiler output. > // My comments will in C++ style > > // Initialize the cntr variable, as GPR a0 > ;****** cntr = (__declspec(scratch) unsigned int *)0; > immed[cntr_109$2$4:a0, 0, <<0] > // Write "0" into the scratchpad memory > ;****** *cntr = 0; > immed[$0, 0, <<0] > scratch[write, $0, cntr_109$2$4:a0, 0, 1], ctx_swap > // Call the receive_packet function. Load the return address into a0 > ;****** buf_handle = receive_packet(0, 5, &cur_pkt_len); > immed[port_num_100_V$ca$2$5:b2, 0, <<0] > immed[rfifo_num_100_V$cb$2$5:a2, 5, <<0] br[_receive_packet#], > defer[1] load_addr[a0, l_55#] > // Increment the packet count in scratch memory. Notice, however, that a0, > // the pointer to scratch memory a0 now contains the return address of > // label 1_55#, and not a valid pointer into scratch memory. > l_55#: > ;****** scratch_incr(cntr, no_signal); > scratch[incr, --, cntr_109$2$4:a0, 0, 1], no_signal > > > -- > Francis > >

1 0