November 2000 - ixp1200 - lists.cs.princeton.edu

RE: debugging in hardware
by Heaton, Eric D 30 Nov '00

30 Nov '00

1. I think if you are doing some kind of interthread communication where one thread is waiting for a signal from another, you could get into a situation where the signal is missed and a microengine will hang forever if you start getting your code out of sync. Chances are it wouldn't happen with just one (or perhaps many) stop/starts, but the possiblity goes up as you increase breakpoint frequency. 2. This is more a problem of exceeding the capabilities of the reference designs. One example might be if there is packet loss for a gigabit port, the gigabit code will loop forever waiting for the missing packet number. Now you're in reset-city. ;) -- Eric Heaton -- -----Original Message----- From: Alok Kumar [mailto:alok@cs.utexas.edu] Sent: Thursday, November 30, 2000 1:07 PM To: Heaton, Eric D Cc: ixp1200(a)CS.Princeton.EDU; Brandewie, Dirk J Subject: RE: debugging in hardware Hi Eric, Thanks a lot for the answers to my queries. 1. The 1st reason you gave should not affect the behavior of the microcode running. Anyway, microengines are running independentely of each other and even if they stop at slightly different times and start at slightly different time, it will not make changes in final outcome. This will not at least make some thread to goto unwanted state and theoritically final behaviour should be unchanged. 2. For the second reason, I was wondering whether this is a problem of reference design or of the debugging environment? Thanks Alok On Thu, 30 Nov 2000, Heaton, Eric D wrote: > I know we've seen problems when inserting breakpoints in hardware. > sometimes the Microengines get into an undefined state for reasons mostly > related to either: > > 1. Getting the Microengines out of sync with each other (i.e. when you set a > breakpoint in one Microengine, the other Microengines don't stop > immediately, but only stop after their respective, currently running, > threads swap out) or.. > > 2. Setting breakpoints while the IXP1200 is trying to receive or transmit > packets. This point is due to the fact that the reference designs aren't as > robust as one might like... they are, however, a very good starting point to > get a feel for the IXP1200 and to start developing your own applications. > > -- Eric Heaton -- > > -----Original Message----- > From: Alok Kumar [mailto:alok@cs.utexas.edu] > Sent: Wednesday, November 29, 2000 3:30 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: debugging in hardware > > > Hi, > > I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am > eventually successful in getting packets through it but here are some > problems I am getting. If anyone has any thoughts or comments on it, > please, let me know. > > 1. When I use the Intel's latest release (version 1.1), the packets > greater than 64 bytes are not forwarded correctly. In version 1.0, there > is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. > > 2. When I try to debug code in hardware by inserting breakpoint to follow > the execution of code, it does not forward any packet but rather go to > some undesirable state. This problem happens in both the version. > > If I use reference design of version 1.0 and do not insert any breakpoints > in code, I get packets forwarded as expected. > > If anyone has successfully run reference designs from version 1.1 or > successfully followed code execution in hardware, please, let me know. > > Thanks > Alok > > ____________________________________________________________________________ > ___ > > Alok Kumar > > Residence: > 3401 Red River St #201 > Austin, TX 78705 > > Office: > Dept of Computer Science > ACES Building > University of Texas > Austin, TX 78712 > > Ph: Home - (512) 472-6443 > Office - (512) 232-7883 > Fax: (401) 679 8171 > > Homepage: http://www.cs.utexas.edu/~alok > ____________________________________________________________________________ > ___ > > > ____________________________________________________________________________ ___ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok ____________________________________________________________________________ ___

1 0

RE: debugging in hardware
by Heaton, Eric D 30 Nov '00

30 Nov '00

I know we've seen problems when inserting breakpoints in hardware. sometimes the Microengines get into an undefined state for reasons mostly related to either: 1. Getting the Microengines out of sync with each other (i.e. when you set a breakpoint in one Microengine, the other Microengines don't stop immediately, but only stop after their respective, currently running, threads swap out) or.. 2. Setting breakpoints while the IXP1200 is trying to receive or transmit packets. This point is due to the fact that the reference designs aren't as robust as one might like... they are, however, a very good starting point to get a feel for the IXP1200 and to start developing your own applications. -- Eric Heaton -- -----Original Message----- From: Alok Kumar [mailto:alok@cs.utexas.edu] Sent: Wednesday, November 29, 2000 3:30 PM To: ixp1200(a)CS.Princeton.EDU Subject: debugging in hardware Hi, I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am eventually successful in getting packets through it but here are some problems I am getting. If anyone has any thoughts or comments on it, please, let me know. 1. When I use the Intel's latest release (version 1.1), the packets greater than 64 bytes are not forwarded correctly. In version 1.0, there is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. 2. When I try to debug code in hardware by inserting breakpoint to follow the execution of code, it does not forward any packet but rather go to some undesirable state. This problem happens in both the version. If I use reference design of version 1.0 and do not insert any breakpoints in code, I get packets forwarded as expected. If anyone has successfully run reference designs from version 1.1 or successfully followed code execution in hardware, please, let me know. Thanks Alok ____________________________________________________________________________ ___ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok ____________________________________________________________________________ ___

2 1

RE: debugging in hardware
by Sprajc, Barry 30 Nov '00

30 Nov '00

One nasty debugging pitfall I've run into while trying to debug in hardware ( using L3fwd16) is the following: If a thread issues a read_lock or write_lock command and a breakpoint happens before an unlock occurs, the sram signal gets lost and the thread sits forever waiting for the signal, so following instructions which issue an unlock command never occur, all other threads who issues a read/write command never complete and wait forever on a read/write lock, and the issuing thread never continues. The only way I've been able to get past this problem is to reset the card. /b > -----Original Message----- > From: Heaton, Eric D [SMTP:eric.d.heaton@intel.com] > Sent: Thursday, November 30, 2000 9:14 AM > To: 'Alok Kumar'; ixp1200(a)CS.Princeton.EDU; Brandewie, Dirk J > Subject: RE: debugging in hardware > > I know we've seen problems when inserting breakpoints in hardware. > sometimes the Microengines get into an undefined state for reasons mostly > related to either: > > 1. Getting the Microengines out of sync with each other (i.e. when you set > a > breakpoint in one Microengine, the other Microengines don't stop > immediately, but only stop after their respective, currently running, > threads swap out) or.. > > 2. Setting breakpoints while the IXP1200 is trying to receive or transmit > packets. This point is due to the fact that the reference designs aren't > as > robust as one might like... they are, however, a very good starting point > to > get a feel for the IXP1200 and to start developing your own applications. > > -- Eric Heaton -- > > -----Original Message----- > From: Alok Kumar [mailto:alok@cs.utexas.edu] > Sent: Wednesday, November 29, 2000 3:30 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: debugging in hardware > > > Hi, > > I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am > eventually successful in getting packets through it but here are some > problems I am getting. If anyone has any thoughts or comments on it, > please, let me know. > > 1. When I use the Intel's latest release (version 1.1), the packets > greater than 64 bytes are not forwarded correctly. In version 1.0, there > is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. > > 2. When I try to debug code in hardware by inserting breakpoint to follow > the execution of code, it does not forward any packet but rather go to > some undesirable state. This problem happens in both the version. > > If I use reference design of version 1.0 and do not insert any breakpoints > in code, I get packets forwarded as expected. > > If anyone has successfully run reference designs from version 1.1 or > successfully followed code execution in hardware, please, let me know. > > Thanks > Alok > > __________________________________________________________________________ > __ > ___ > > Alok Kumar > > Residence: > 3401 Red River St #201 > Austin, TX 78705 > > Office: > Dept of Computer Science > ACES Building > University of Texas > Austin, TX 78712 > > Ph: Home - (512) 472-6443 > Office - (512) 232-7883 > Fax: (401) 679 8171 > > Homepage: http://www.cs.utexas.edu/~alok > __________________________________________________________________________ > __ > ___ > >

1 0

RE: debugging in hardware
by Brandewie, Dirk J 29 Nov '00

29 Nov '00

Hi Alok, Others have seen this problem also. I have asked our support group to look at the problem and if there are any workarounds. I will post to the list any information I can gather on the problem. Sorry I can't give a more direct answer that would fix your problem. --Dirk > Hi, > > I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am > eventually successful in getting packets through it but here are some > problems I am getting. If anyone has any thoughts or comments on it, > please, let me know. > > 1. When I use the Intel's latest release (version 1.1), the packets > greater than 64 bytes are not forwarded correctly. In version > 1.0, there > is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. > > 2. When I try to debug code in hardware by inserting > breakpoint to follow > the execution of code, it does not forward any packet but rather go to > some undesirable state. This problem happens in both the version. > > If I use reference design of version 1.0 and do not insert > any breakpoints > in code, I get packets forwarded as expected. > > If anyone has successfully run reference designs from version 1.1 or > successfully followed code execution in hardware, please, let me know. >

1 0

RE: strong arm development
by Heaton, Eric D 29 Nov '00

29 Nov '00

Information on the StrongARM Core API to interact with the other functional units of the IXP1200 (like the IX Bus, the Microengines, etc.) can be found in Section 2 of the IXP1200 Software Reference Manual. For StrongARM Core development, one could use a development environment, such as Tornado from WindRiver www.windriver.com or some other StrongARM-compatible compiler and debugger. One way to simulate the StrongARM interacting with the microengines is by creating a foreign model, which acts as an extension to the capabilities of Transactor, which is a cycle and data accurate software model of IXP1200. More information on how to create a foreign model can be found in Section 6 of the IXP1200 Development Tool User's Guide v005. To generate packet traffic in simulation on the Developer's Workbench v1.1, you can use the IX Bus Simulator found under the "Simulation" at the top menu bar. Here you can configure one or more devices attached to the IX Bus, i.e. MACs as well as the packet streams you want to flow through them. More information on how to create a foreign model can be found in Section 2.9.21 of the IXP1200 Development Tool User's Guide v005. -- Eric Heaton -- -----Original Message----- From: Sachin Jain [mailto:sachin@cs.utexas.edu] Sent: Wednesday, November 29, 2000 3:49 PM To: ixp1200(a)CS.Princeton.EDU Subject: strong arm development Hi, I have some questions regarding strong arm development and its simulation? I want to add code in the strong arm that spawns a process that periodically does some computations. In which file in strong arm code could this be added? How does one rebuild the strong arm image after making changes? Where can i find documentation for finding the API for spawning process and getting values from sram etc? How does one simulate a reference design with strong arm image in software i.e without downloading on the hardware? If we simulate in hardware - is there a way to generate packet flows using the development bench? I will appreciate help on any of the questions... Sachin Jain Graduate student, computer sciences Univ. of Texas - Austin Res: 3401, Red River Street, #201 Austin, Tx - 78705 Ph : (512)-4726443 (R)

1 0

debugging in hardware
by Alok Kumar 29 Nov '00

29 Nov '00

Hi, I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am eventually successful in getting packets through it but here are some problems I am getting. If anyone has any thoughts or comments on it, please, let me know. 1. When I use the Intel's latest release (version 1.1), the packets greater than 64 bytes are not forwarded correctly. In version 1.0, there is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. 2. When I try to debug code in hardware by inserting breakpoint to follow the execution of code, it does not forward any packet but rather go to some undesirable state. This problem happens in both the version. If I use reference design of version 1.0 and do not insert any breakpoints in code, I get packets forwarded as expected. If anyone has successfully run reference designs from version 1.1 or successfully followed code execution in hardware, please, let me know. Thanks Alok _______________________________________________________________________________ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok _______________________________________________________________________________

2 1

RE: building vxworks
by Sprajc, Barry 29 Nov '00

29 Nov '00

This can also be accomplished by running \tornado\host\x86-win32\bin\torVars.bat which will also add some important stuff to the PATH variable. BTW - If anyone has had success rebuilding the BSP to support debugging through the serial port rather than the 10/100 NIC( an actually getting it to work ), please let me know. Thanks, barry.sprajc(a)intel.com > -----Original Message----- > From: Brandewie, Dirk J [SMTP:dirk.j.brandewie@intel.com] > Sent: Wednesday, November 29, 2000 10:07 AM > To: 'Hilarie Orman'; ixp1200(a)CS.Princeton.EDU > Subject: RE: building vxworks > > Can you capture the real error message? To compile from > the command line there are two environment variables that > need to be set. > > WIND_BASE=c:\Tornado > WIND_HOST_TYPE=x86-win32 > > Also make sure that the Tornado tools are on your path. CD > into the BSP directory and type "make clean" then "make". > > Hope this helps > --Dirk > > -----Original Message----- > > From: Hilarie Orman [mailto:HORMAN@novell.com] > > Sent: Wednesday, November 29, 2000 9:57 AM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: building vxworks > > > > > > I am trying to build a vxworks kernel with Tornado using the > > BSP from the > > IXPl 1.1 CD; this fails due to a script error re "toolfindbyname" > > (roughly). Anyone know how to fix it? > > > > Hilarie Orman > > > > > > >

1 0

RE: building vxworks
by Brandewie, Dirk J 29 Nov '00

29 Nov '00

Can you capture the real error message? To compile from the command line there are two environment variables that need to be set. WIND_BASE=c:\Tornado WIND_HOST_TYPE=x86-win32 Also make sure that the Tornado tools are on your path. CD into the BSP directory and type "make clean" then "make". Hope this helps --Dirk > -----Original Message----- > From: Hilarie Orman [mailto:HORMAN@novell.com] > Sent: Wednesday, November 29, 2000 9:57 AM > To: ixp1200(a)CS.Princeton.EDU > Subject: building vxworks > > > I am trying to build a vxworks kernel with Tornado using the > BSP from the > IXPl 1.1 CD; this fails due to a script error re "toolfindbyname" > (roughly). Anyone know how to fix it? > > Hilarie Orman > > >

1 0

building vxworks
by Hilarie Orman 29 Nov '00

29 Nov '00

I am trying to build a vxworks kernel with Tornado using the BSP from the IXPl 1.1 CD; this fails due to a script error re "toolfindbyname" (roughly). Anyone know how to fix it? Hilarie Orman

1 0

RE: Reference Design
by Sprajc, Barry 27 Nov '00

27 Nov '00

Hi folks, The initalization script contains rt_add(.....) to add routes, however this does not include the necessary parms for MAC address. Please look at the prototype for route_add(....) ( I can't remember of the top of my head what is ) and change the script to use route_add() instead of rt_add(). route_add() includes ( I think 2 ) extra parms for the low and high portions of the destination MAC address ( MAC address for a given client ip address ) /b > -----Original Message----- > From: Taroon Mandhana [SMTP:mandhana@cs.utexas.edu] > Sent: Sunday, November 26, 2000 3:09 PM > To: Petcharat Suriyachai > Cc: ixp1200(a)CS.Princeton.EDU > Subject: Re: Reference Design > > Hi Petcharat, > > We are trying to run pfwd8_1f_rx16_tx6 on the new board - B0. Our > understanding is that the default route table here is that 1.1.1.1 goes to > port 1, 2.2.2.2 to port 2 and so on. We have two end points with IP > addresses 1.1.1.1(machine A) and 2.2.2.2(m/c B) connected to port 1 and 2 > respectively on the board. > > Here is step by step what we are doing. > > 1. On the board, download VxWorks Image from > > ixp1200/boardsupport/bin/vb/vxworks > > 2. Start Tornado and get the command shell > > 3. Run Netapp (as specified in the manual) > > 4. Open developer workbench with pfwd8_1f_rx16_tx6 and start running the > ref design in hardware. > > 5. On m/c A, do telnet 2.2.2.2 > > The Rx led blinks for port 1 on receiving, however, nothing gets > transmitted on port 2. > > I was wondering if you did the similar thing. Any help is greatly > appreciated. > > thanks, > Taroon > > > On Mon, 20 Nov 2000, Petcharat Suriyachai wrote: > > > The pfwd8_1f_rx16_tx6 project should work on the hardware. > > > > > > On Sun, 19 Nov 2000, Alok Kumar wrote: > > > > > Hi All, > > > > > > Can anyone help me out to make some reference design work in actual > > > hardware? Which reference design in the latest CD is known to actually > > > work in B0 hardware without any problem? What is the semantics of > routing > > > table in that reference? > > > > > > I have downloaded vxworks in the hardware and also run tornado. Now, I > > > download mircocode through workbench and it runs ( I can see PC > > > changing). Now, I want to send some packets and get them routed. So, > > > please tell me which reference design should I download? > > > > > > Thanks > > > Alok > > > > > > > __________________________________________________________________________ > _____ > > > > > > Alok Kumar > > > > > > Residence: > > > 3401 Red River St #201 > > > Austin, TX 78705 > > > > > > Office: > > > Dept of Computer Science > > > ACES Building > > > University of Texas > > > Austin, TX 78712 > > > > > > Ph: Home - (512) 472-6443 > > > Office - (512) 232-7883 > > > Fax: (401) 679 8171 > > > > > > Homepage: http://www.cs.utexas.edu/~alok > > > > __________________________________________________________________________ > _____ > > > > > > > >

1 0