- ixp1200 - lists.cs.princeton.edu

RE: [ixp1200] problem with the simuator
by Kunze, Aaron 29 Aug '02

29 Aug '02

Hey! Try setting the hash multiplier in the FBI CSRs. If the multiplier is 0, the hash unit will return 0. A ------------------------ Aaron Kunze Intel Labs aaron.kunze(a)intel.com -PGP Key ID: 0x81124B7C- -NOT SPEAKING FOR INTEL- ------GO BOILERS!!------ > -----Original Message----- > From: damien [mailto:damien@cse.ogi.edu] > Sent: Thursday, August 29, 2002 4:54 PM > To: ixp > Subject: [ixp1200] problem with the simuator > > > Hi all, > I'm trying to use the developer workbench > to simulate the hash unit. > My problem is the function hash_64() always returns 0... > Could someone please tell me what's wrong in the following code: > > / long long data_to_hash = 0x1234567899; > __declspec(sram_write_reg) long long hash_Input; > __declspec(sram_read_reg) long long hash_Output; > long long result; > > while(1) > { > if(ctx() == 0) > { > hash_Input = data_to_hash; > hash_64((__declspec(sram_write_reg) void *)&hash_Input, > (__declspec(sram_read_reg) void *)&hash_Output, 1, sig_done); > ctx_wait(fbi); > result = hash_Output; > > } > else > { > ctx_wait(voluntary); > } > }/ > > --Damien >

2 1

problem with the simuator
by damien 29 Aug '02

29 Aug '02

Hi all, I'm trying to use the developer workbench to simulate the hash unit. My problem is the function hash_64() always returns 0... Could someone please tell me what's wrong in the following code: / long long data_to_hash = 0x1234567899; __declspec(sram_write_reg) long long hash_Input; __declspec(sram_read_reg) long long hash_Output; long long result; while(1) { if(ctx() == 0) { hash_Input = data_to_hash; hash_64((__declspec(sram_write_reg) void *)&hash_Input, (__declspec(sram_read_reg) void *)&hash_Output, 1, sig_done); ctx_wait(fbi); result = hash_Output; } else { ctx_wait(voluntary); } }/ --Damien

1 0

RE: [ixp1200] ixp1200 absolute register programming problem
by Johnson, Erik J 23 Aug '02

23 Aug '02

The problem is not in the compiler, the problem is that an absolute register is not allowed with either a shift specifier (alu_shf) or an immediate operand. So the real problem is with the 1. The documentation is misleading, but if you read after the example in the alu[] instruction documentation, this restriction is hinted at. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: xtan@mail [mailto:xtan@csnet1.cs.tsinghua.edu.cn] Sent: Thursday, August 22, 2002 6:27 PM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] ixp1200 absolute register programming problem Hello everybody: Here is an absolute register programming problem that I encountered with IXP1200 C (asm) compiler. The detail code goes here: __declspec(shared gp_reg) a; void main() { __asm alu[a, 1, +, a]; } The compiler will report an error: (0): error : #0: Inst has bad operands (d:\cvs\uc\ixp1200\uEngineC\pdev\ixp_cg\ixpasm.c, line 2109) While the IXP programming guide said the B operand and the dest_reg could use absolute register leaving A operand a immediate data. Is there anything wrong with my syntax or it is just a compiler bug? Besides, using global absolute register is convenient in the communications between threads, but this failure will lead to an exaggerate code generation which dramatically decrease the performance. I will very appreciate if anyone could help me. Zhanxi Tan Dep. of CS Tsinghua Univ.

1 0

ixp1200 absolute register programming problem
by xtan＠mail 22 Aug '02

22 Aug '02

Hello everybody: Here is an absolute register programming problem that I encountered with IXP1200 C (asm) compiler. The detail code goes here: __declspec(shared gp_reg) a; void main() { __asm alu[a, 1, +, a]; } The compiler will report an error: (0): error : #0: Inst has bad operands (d:\cvs\uc\ixp1200\uEngineC\pdev\ixp_cg\ixpasm.c, line 2109) While the IXP programming guide said the B operand and the dest_reg could use absolute register leaving A operand a immediate data. Is there anything wrong with my syntax or it is just a compiler bug? Besides, using global absolute register is convenient in the communications between threads, but this failure will lead to an exaggerate code generation which dramatically decrease the performance. I will very appreciate if anyone could help me. Zhanxi Tan Dep. of CS Tsinghua Univ.

1 0

Optimization
by Vaishnavi Krishnamurthy 22 Aug '02

22 Aug '02

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.

3 4

Booting ENP-2505 IXP1200 Board
by Jo Ueyama 21 Aug '02

21 Aug '02

All, I am trying to boot the IXP1200 board but I simply can not do it, since the 'bootixp' script calls minicom program and then it gets stuck. Likewise, a message appears on the screen saying that minicom has not found the configuration file. Can anyone please tell me how to solve this problem? Thanks a lot! Regards, Jo Ueyama

3 2

Wrong results in Workbench
by Tommy Tran 16 Aug '02

16 Aug '02

Hi all, have problem running the l3fwdr app in workbench mode. The board kept dumping packats to all 4 of its ports and cause the host linux box to crash soon after. Here is the content of the packats captured by tcpdump: 15:33:08.562578 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 15:33:08.572013 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 15:33:08.619845 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 ...

1 1

Gerry Murphy/Radisys_Corporation/US is out of the office.
by Gerry.Murphy＠radisys.com 16 Aug '02

16 Aug '02

I will be out of the office starting 08/14/2002 and will not return until 09/02/2002. I will respond to your message when I return.

1 0

Re: [ixp1200] UC Library Update
by Deepa Srinivasan 15 Aug '02

15 Aug '02

This could be because the PATH environment variable is not set properly. The uccl.exe is in the C:\IXP1200\bin directory (or in the bin directory of the IXP1200 install). You would need to make sure that the PATH environment variable (found in My Computer - Properties - Advanced - Environment Variables) includes this value. If there is a PATH in both the System and User variables, make sure both have this directory. I got the same error message that you are seeing and doing this fixed it. Hope this helps. - Deepa >From: Vaishnavi Krishnamurthy <vkrish(a)cs.ucr.edu> >Reply-To: ixp1200(a)CS.Princeton.EDU >To: <ixp1200(a)CS.Princeton.EDU> >Subject: [ixp1200] UC Library Update >Date: Thu, 15 Aug 2002 16:31:23 -0700 (PDT) > >Hi, > I downloaded the UClibrary.exe from the Intel website and updated my >UEngineC but when I am trying to compile the L3Fwdr_RFC1812 project, it >gives me 6 errors which are > >Compiling for rec_f0.list... >(0): error : could not find directory in which uccl resides >Compiling for rec_f1.list... >(0): error : could not find directory in which uccl resides >Compiling for rec_f2.list... >(0): error : could not find directory in which uccl resides >Compiling for rec_f3.list... >(0): error : could not find directory in which uccl resides >Compiling for xmit_f4.list... >(0): error : could not find directory in which uccl resides >Compiling for xmit_f5.list... >(0): error : could not find directory in which uccl resides > >The last time I downloaded and compiled, I did not get any such errors. >Can >anyone tell me if they got such a problem and if so how you solved it? >Thanks, >Vaish. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

1 0

RE: [ixp1200] IXA SDK Bug
by Francis 13 Aug '02

13 Aug '02

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