September 2002 - ixp1200 - lists.cs.princeton.edu

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

Fast Ports - sop_seq roll over
by Yannis Haritakis 04 Sep '02

04 Sep '02

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. 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. 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) 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 ? I think the answer is "no necessarily"! Yannis Charitakis haritak(a)ics.forth.gr

1 0

microC development
by Najati Imam 04 Sep '02

04 Sep '02

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

1 0

Running IXP sample code in Unoptimized mode
by Deepa Srinivasan 04 Sep '02

04 Sep '02

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

2 1

RE: [ixp1200] reading statistics registers from the ixf440 ( ixp1 2eb)
by Arthur Berkovitch 03 Sep '02

03 Sep '02

reading a scratch address from core can be done by: #define FBI_SCRATCH_PAD_BASE 0xB0044000 #define READ_LWORD(addr, val) *((volatile unsigned int *)(val)) = *((unsigned int *)(addr)) #define SCRATCH_READ(addr, val) READ_LWORD(((addr)<<2)+FBI_SCRATCH_PAD_BASE, (val)) look at hal_fbi.h and core_io.h under $(IXP_ROOT)/include -----Original Message----- From: tomer [mailto:bahart@bgumail.bgu.ac.il] Sent: Monday, September 02, 2002 10:51 AM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] reading statistics registers from the ixf440 ( ixp12eb) 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.

2 1