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

RE: IXP clock rate question
by Perry Wagle 20 Jul '00

20 Jul '00

My cover letters (with "A14985-001" at the bottom) don't state this. > I found it. The note about 176 MHz is on a single sheet of paper > with Intel letterhead that came with the system. It simply listed > what came with the Evaluation System plus the note Susan quotes. >> "Also note, the IXP1200 Network Processor on this evaluation system runs at >> a core frequency of 176 MHz. This temporary condition is due to a lack of >> component availability used to design the evaluation board." ------------------------------------------------------------------------------ Also, out of curiosity, what value in hex does my "mmu_id_chip" routine return on your systems? -- Perry

1 0

RE: IXP clock rate question
by Scott C. Karlin 20 Jul '00

20 Jul '00

I found it. The note about 176 MHz is on a single sheet of paper with Intel letterhead that came with the system. It simply listed what came with the Evaluation System plus the note Susan quotes. -Scott Perry Wagle writes: > > Susan Yost writes: > > You have Evaluation Systems based on the A-3 step of the IXP1200 Network > > Processor. Buried at the bottom of the cover letter included with your > > systems is the following: > > > > "Also note, the IXP1200 Network Processor on this evaluation system runs at > > a core frequency of 176 MHz. This temporary condition is due to a lack of > > component availability used to design the evaluation board." > > > > Intel officially supports 166 MHz and now 200 MHz versions of the IXP1200. > > Our first version of the Evaluation System run at 176 MHz as indicated > > above. > > > > Susan Yost > > IXP1200 Tech Marketing > > I don't find the "core frequency of 176" in the printed documentation > that came with the systems, though now that you mention it, I seem to > remember reading that line somewhere. Could you be more specific > about its location? (I'm hoping to find other important information > there.) -------------------------------------------------------------------------- Scott C. Karlin Princeton University Graduate Student Department of Computer Science Voice: (609) 258-5386 35 Olden Street Email: scott(a)cs.princeton.edu Princeton, NJ 08544-2087 WWW: http://www.cs.princeton.edu/~scott --------------------------------------------------------------------------

1 0

RE: IXP clock rate question
by Perry Wagle 20 Jul '00

20 Jul '00

> You have Evaluation Systems based on the A-3 step of the IXP1200 Network > Processor. Buried at the bottom of the cover letter included with your > systems is the following: > > "Also note, the IXP1200 Network Processor on this evaluation system runs at > a core frequency of 176 MHz. This temporary condition is due to a lack of > component availability used to design the evaluation board." > > Intel officially supports 166 MHz and now 200 MHz versions of the IXP1200. > Our first version of the Evaluation System run at 176 MHz as indicated > above. > > Susan Yost > IXP1200 Tech Marketing I don't find the "core frequency of 176" in the printed documentation that came with the systems, though now that you mention it, I seem to remember reading that line somewhere. Could you be more specific about its location? (I'm hoping to find other important information there.) ----------------------------------------------------------------------------- My routine queries the MMU for its "ID_CHIP" function: static inline int mmu_id_chip (void) { register int x ; __asm__ __volatile__ ( "mrc 15, 0, %0, c0, c0, 0" : "=r" (x)) ; return x ; } and returns: mmu_id_chip 6901c120 which translates to [IMP]lementer = 0x69 (the documentated constant) [ARCH]itecture version = 0x01 (the documentated constant) [P]art [N]umber = 0xc12 (the documented constant for IXP1200) [REV]ision number = 0x0 I think our other system (which is currently dead) showed a higher revision number. The working system has a revision number of zero, which I'm of the impression is a earlier rev that A-3? Unlike the dead system, this board had come in a unsealed bag with no plugs for the gigabit ports, so might have been "previously owned". Do we have a revision mismatch from what we are supposed to have? ----------------------------------------------------------------------------- If my fast_clock is running at 176 MHz, what is my slow clock running at? The documentation for the PLL_CFG register on page 28 of the "IXP1200 Network Processor Specification Update (June 2000)" specifies that bits 4:0 being equal to 0x10 means 162.20 MHz if my slow_clock frequency is 3.6864 MHz. The ratio of these two constants is just about correct, given the relative frequency of interrupts generated by timers based on them. If you are telling me that my fast_clock is really running at 176Mhz, then what is my slow clock running at then? Or are you telling me that I should set bits 4:0 of the PLL_CFG register to 0x11 to make it run at 176.95Mhz as the documentation indicates? In either case, is it possible to get the exact values of both the slow_clock and the fast_clock? (down to the unit Hz) Thanks! -- Perry

1 0

RE: IXP clock rate question
by Yost, Susan 20 Jul '00

20 Jul '00

Hi All, You have Evaluation Systems based on the A-3 step of the IXP1200 Network Processor. Buried at the bottom of the cover letter included with your systems is the following: "Also note, the IXP1200 Network Processor on this evaluation system runs at a core frequency of 176 MHz. This temporary condition is due to a lack of component availability used to design the evaluation board." Intel officially supports 166 MHz and now 200 MHz versions of the IXP1200. Our first version of the Evaluation System run at 176 MHz as indicated above. Susan Yost IXP1200 Tech Marketing -----Original Message----- From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] Sent: Thursday, July 20, 2000 3:58 PM To: Perry Wagle Cc: ixp1200(a)CS.Princeton.EDU Subject: Re: IXP clock rate question Don't really know what rev board we have. I think it's an A-somthing. Our numbers might not need to be the same, however, since I am timing the microengine cycle speed and not the StrongARM. Tammo On Thu, 20 Jul 2000, Perry Wagle wrote: > > Measurements with the microengine cycle counters suggest that the > > clock speed of our system is 177MHz as opposed to the manual's claim > > of 166MHz. > > > > Does this sound accurate? > > I'm including my own observations in my answer to your question: > > I'm loading my boot loader from angel on a rev A board. I have the > RTC firing an interrupt "once a second", and TIMER_1 firing "a hundred > times a second". Angel has set the PLL_CFG register to (my debugging > routine dumps "label address value"): > > pll_cfg 90000c00 00000010 > > which I've assumed to be "correct", so haven't tried changing it, > especially since the documentation warns againts setting it too high. > > The RTC uses what I call the "slow clock" (~ 3 MHz), and the TIMER's > use what I call the "fast clock" (~ 162 Mhz). > > To initialize the RTC calibration, I set the RTC_DIV register to my > slow_clock (expressed in Hz) divided by 128, and currently get: > > rtc_div 90002000 00037080 > > (so RDIV = 0x7080) and to initialized the TIMER_1 calibration, I set > the TIMER_1_LOAD register to the my fast_clock (expressed in Hz) > divided by 100, and currently get: > > timer_1_load 42000300 0018bff0 > timer_1_control 42000308 000000c0 > > (notice that the value of timer_1_control shows that I am counting CPU > cycles without a divisor). > > With my slow_clock constant set to 3686400 Hz and my fast_clock > constant set to 162200000, I am getting approximately 100.15 TIMER_1 > interrupts per RTC interrupt (over a 12 hour period). These two > values correspond to the ROUNDED values of the two clock rates from > page 28 of the "IXP1200 Network Processor Specification Update (June > 2000)". The roundoff is SIGNIFICANT to my measurement, and I wish the > documentation writers WOULDN'T ROUND OFF THE VALUES. For example, > since the given value of the fast_clock was almost exactly 44 times > the given value of the slow_clock, I tried just setting the fast_clock > to exactly 44 times the slow clock, and got 100.5 TIMER_1 interrupts > per second. BOTH values of the fast_clock were within the roundoff of > the value given in the documentation. > > My setting of the slow_clock is consistant with the documentation's > suggestion, and the seconds doesn't skew according to my eyeball's > comparison with my wristwatch. It's close enough that I'm not going > to worry more about it more until I have Linux running XNTP. > > So my answer to your original question is that I'm somewhat confident > that I have the Core Clock measured at about 162 MHz (+- 1 Mhz), at > least with respect to the RTC and TIMER_1 hardware on Rev A hardware. > Which Rev do you guys have? > > -- Perry >

1 0

Re: IXP clock rate question
by Perry Wagle 20 Jul '00

20 Jul '00

> Measurements with the microengine cycle counters suggest that the > clock speed of our system is 177MHz as opposed to the manual's claim > of 166MHz. > > Does this sound accurate? I'm including my own observations in my answer to your question: I'm loading my boot loader from angel on a rev A board. I have the RTC firing an interrupt "once a second", and TIMER_1 firing "a hundred times a second". Angel has set the PLL_CFG register to (my debugging routine dumps "label address value"): pll_cfg 90000c00 00000010 which I've assumed to be "correct", so haven't tried changing it, especially since the documentation warns againts setting it too high. The RTC uses what I call the "slow clock" (~ 3 MHz), and the TIMER's use what I call the "fast clock" (~ 162 Mhz). To initialize the RTC calibration, I set the RTC_DIV register to my slow_clock (expressed in Hz) divided by 128, and currently get: rtc_div 90002000 00037080 (so RDIV = 0x7080) and to initialized the TIMER_1 calibration, I set the TIMER_1_LOAD register to the my fast_clock (expressed in Hz) divided by 100, and currently get: timer_1_load 42000300 0018bff0 timer_1_control 42000308 000000c0 (notice that the value of timer_1_control shows that I am counting CPU cycles without a divisor). With my slow_clock constant set to 3686400 Hz and my fast_clock constant set to 162200000, I am getting approximately 100.15 TIMER_1 interrupts per RTC interrupt (over a 12 hour period). These two values correspond to the ROUNDED values of the two clock rates from page 28 of the "IXP1200 Network Processor Specification Update (June 2000)". The roundoff is SIGNIFICANT to my measurement, and I wish the documentation writers WOULDN'T ROUND OFF THE VALUES. For example, since the given value of the fast_clock was almost exactly 44 times the given value of the slow_clock, I tried just setting the fast_clock to exactly 44 times the slow clock, and got 100.5 TIMER_1 interrupts per second. BOTH values of the fast_clock were within the roundoff of the value given in the documentation. My setting of the slow_clock is consistant with the documentation's suggestion, and the seconds doesn't skew according to my eyeball's comparison with my wristwatch. It's close enough that I'm not going to worry more about it more until I have Linux running XNTP. So my answer to your original question is that I'm somewhat confident that I have the Core Clock measured at about 162 MHz (+- 1 Mhz), at least with respect to the RTC and TIMER_1 hardware on Rev A hardware. Which Rev do you guys have? -- Perry

2 1

IXP clock rate question
by Tammo Spalink 20 Jul '00

20 Jul '00

Measurements with the microengine cycle counters suggest that the clock speed of our system is 177MHz as opposed to the manual's claim of 166MHz. Does this sound accurate? Tammo

1 0

IXP1200 Workbench Key
by Tammo Spalink 19 Jul '00

19 Jul '00

We recently received a new IXP development CD (Version 1.0 release) from Intel. This one appears to require key/password to get at the executables. However, when we try to go to the website to get the keys the link does not work. Has anyone else had luck with this? If it's not just us, maybe Intel could look into it. The link I am trying to use is from the developer.intel.com IXP1200 site: http://apps-cic.jf.intel.com/CNFY2/e_register.asp?cnfy2=xx&Actv_ID=2797 Thanks, Tammo

1 0

21440 transmit success
by Tammo Spalink 18 Jul '00

18 Jul '00

I finally got it to work: I can send as well as receive a packet. For me the trick appears to be using the 64 bit wide IXBus mode. I have yet to discover why this is. Using 32 bit wide mode results in, for every 8 bytes sent, bytes 0-3 are replicated in positions 4-7 replacing what should be there. Tammo

1 0

RE: UART interrupts
by Ananthanarayanan, Arul 11 Jul '00

11 Jul '00

Perry, On the B step the CoProcessor 15 ID_CHIP command will return a 1 in bit 0. If you read a 0, you have the A step. You have the old cdrom. You need to get the new 1.0 version (1.0.1129) as it has the specification update that lists all the differences between the steps. You should be able to get this from your Intel support person. Arul -----Original Message----- From: Perry Wagle [mailto:wagle@cse.ogi.edu] Sent: Tuesday, July 11, 2000 3:36 PM To: arul.ananthanarayanan(a)intel.com; ixp1200(a)CS.Princeton.EDU; wagle(a)cse.ogi.edu Subject: RE: UART interrupts Arul -- How do I tell for sure whether I have an A or B step IXP1200? The Coprocessor 15 (MMU) ID_CHIP command (section 4.10.1) returns 0x6901c120, which means revision 0 of something (the MMU?). The edge of the board near the serial connector says "A13033-001 A01 L1" on the side with most of the chips, and "A13033 001 A01 L8" on the other side. What are all the differences between Rev A and Rev B? If the documentation I have is going to be this far off in general, I'm not sure I can port Linux to the board, and I need to complain. Which document on the Version 1.0.1011 CDrom (that came with the boards) are you talking about that describes the uart? --- I thought I'd tried setting mystery bit 9 to see if it would clear the interupt. It seems to work now. You have to reinitialize the uart (setting baud, etc) after each interupt? Thanks! -- Perry > From arul.ananthanarayanan(a)intel.com Tue Jul 11 14:34:53 2000 > From: "Ananthanarayanan, Arul" <arul.ananthanarayanan(a)intel.com> > To: "'Perry Wagle'" <wagle(a)cse.ogi.edu>, ixp1200(a)CS.Princeton.EDU > Subject: RE: UART interrupts > Date: Tue, 11 Jul 2000 14:34:47 -0700 > MIME-Version: 1.0 > Perry, > > The documentation refers to the B stepping of the IXP1200. You > probably have > the A step of the processor and there are differences in handling the UART. > In the A stepping, bit 6 of the IRQ register is really the UART interrupt > (not the RTC). > You do need to clear the UART interrupts on the A step, so the mystery bit 9 > of the > UART_SR is what you need to set before exiting your handler. > There is a specification update on the Version 1.0 developers CD that > details the changes > for the A step. > Arul > -----Original Message----- > From: Perry Wagle [mailto:wagle@cse.ogi.edu] > Sent: Monday, July 10, 2000 5:22 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: UART interupts > Has anyone gotten the UART interupts to work right? > I can read and write the UART just fine with polled i/o, but > interupts seem all messed up. I suspect the March 2000 IXP1200 > Network Processor Programmer's Reference is either false or I wasn't > given the board that it corresponds to. > Section 4.6.10 UART_CR (page 4-78): The UART generates a IRQ interupt > regardless of what I set set bit 9 (UIS, select IRQ or FIQ) to. > Setting bit 4 (RIE) is necessary to get IRQ interupts to fire, but > once I get them to fire, they won't stop firing. My IRQ handler will > be entered even if there are no characters ready to read from the UART > after I've left it for the first time. It won't enter my IRQ_handler > the first time until I've send a character. If I read the UART_CR > register, I get what I set it to except for UIS is always zero; ie, > 0x001700f0 (9600baud, the mystery bit 9 (UIS) is clear, transmit > interupts disabled, uart enabled, 8 bits data size, recieve interupts > enabled, 1 stop bit, no parity). > What is the mystery bit 9? > Section 4.6.9 UART_SR (page 4-77): This register address is always [?] > equal to "RXD pin set, transmit fifo full, ... , transmit fifo empty, > ..." (0x00000180) when my IRQ_handler is entered (except the first > time, when the "receive fifo ready" bit is also set (0x00000190)). > It would seem impossible that the transmit fifo is both full and empty > at the same time, what's going on? > Section 4.6.17 IRQ (page 4-86): When my IRQ_handler is entered, this > register is always equal to "IRQ interupt generated by RTC" (bit 6 = > 0x00000040), and no matter what I do to the UART status, control, and > data registers, its still set when my IRQ_handler is ready to leave > (ie, after its read one character after waiting for it to become > available). I suspect that since I'm not succeeding in clearing the > interupt condition, that its being reissued just as soon as I leave > the interupt handler. > I'm thinking that bit 6 corresponds to the UART, and not the RTC, > since my IRQ handler is only entered for the first time when I send a > character to the IXP1200 serial port. I have apparently not succeeded > (yet) in getting the RTC to generate an interupt. What is the correct > layout of the IRQ register? > My foreground job (spin the led with an ever-incrementing unsigned > char counter in a tight infinite loop) usually doesn't make progress > after my IRQ_handler is entered for the first time. But when it does, > it has only 2-3 "favorite" values that the led ends up displaying. It > seems odd that I've got such a good phase lock on 2-3 out of 256 > possible values, but I can't imagine what this information is telling > me. > -- Perry

1 0

RE: UART interrupts
by Perry Wagle 11 Jul '00

11 Jul '00

Arul -- How do I tell for sure whether I have an A or B step IXP1200? The Coprocessor 15 (MMU) ID_CHIP command (section 4.10.1) returns 0x6901c120, which means revision 0 of something (the MMU?). The edge of the board near the serial connector says "A13033-001 A01 L1" on the side with most of the chips, and "A13033 001 A01 L8" on the other side. What are all the differences between Rev A and Rev B? If the documentation I have is going to be this far off in general, I'm not sure I can port Linux to the board, and I need to complain. Which document on the Version 1.0.1011 CDrom (that came with the boards) are you talking about that describes the uart? --- I thought I'd tried setting mystery bit 9 to see if it would clear the interupt. It seems to work now. You have to reinitialize the uart (setting baud, etc) after each interupt? Thanks! -- Perry > From arul.ananthanarayanan(a)intel.com Tue Jul 11 14:34:53 2000 > From: "Ananthanarayanan, Arul" <arul.ananthanarayanan(a)intel.com> > To: "'Perry Wagle'" <wagle(a)cse.ogi.edu>, ixp1200(a)CS.Princeton.EDU > Subject: RE: UART interrupts > Date: Tue, 11 Jul 2000 14:34:47 -0700 > MIME-Version: 1.0 > Perry, > > The documentation refers to the B stepping of the IXP1200. You > probably have > the A step of the processor and there are differences in handling the UART. > In the A stepping, bit 6 of the IRQ register is really the UART interrupt > (not the RTC). > You do need to clear the UART interrupts on the A step, so the mystery bit 9 > of the > UART_SR is what you need to set before exiting your handler. > There is a specification update on the Version 1.0 developers CD that > details the changes > for the A step. > Arul > -----Original Message----- > From: Perry Wagle [mailto:wagle@cse.ogi.edu] > Sent: Monday, July 10, 2000 5:22 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: UART interupts > Has anyone gotten the UART interupts to work right? > I can read and write the UART just fine with polled i/o, but > interupts seem all messed up. I suspect the March 2000 IXP1200 > Network Processor Programmer's Reference is either false or I wasn't > given the board that it corresponds to. > Section 4.6.10 UART_CR (page 4-78): The UART generates a IRQ interupt > regardless of what I set set bit 9 (UIS, select IRQ or FIQ) to. > Setting bit 4 (RIE) is necessary to get IRQ interupts to fire, but > once I get them to fire, they won't stop firing. My IRQ handler will > be entered even if there are no characters ready to read from the UART > after I've left it for the first time. It won't enter my IRQ_handler > the first time until I've send a character. If I read the UART_CR > register, I get what I set it to except for UIS is always zero; ie, > 0x001700f0 (9600baud, the mystery bit 9 (UIS) is clear, transmit > interupts disabled, uart enabled, 8 bits data size, recieve interupts > enabled, 1 stop bit, no parity). > What is the mystery bit 9? > Section 4.6.9 UART_SR (page 4-77): This register address is always [?] > equal to "RXD pin set, transmit fifo full, ... , transmit fifo empty, > ..." (0x00000180) when my IRQ_handler is entered (except the first > time, when the "receive fifo ready" bit is also set (0x00000190)). > It would seem impossible that the transmit fifo is both full and empty > at the same time, what's going on? > Section 4.6.17 IRQ (page 4-86): When my IRQ_handler is entered, this > register is always equal to "IRQ interupt generated by RTC" (bit 6 = > 0x00000040), and no matter what I do to the UART status, control, and > data registers, its still set when my IRQ_handler is ready to leave > (ie, after its read one character after waiting for it to become > available). I suspect that since I'm not succeeding in clearing the > interupt condition, that its being reissued just as soon as I leave > the interupt handler. > I'm thinking that bit 6 corresponds to the UART, and not the RTC, > since my IRQ handler is only entered for the first time when I send a > character to the IXP1200 serial port. I have apparently not succeeded > (yet) in getting the RTC to generate an interupt. What is the correct > layout of the IRQ register? > My foreground job (spin the led with an ever-incrementing unsigned > char counter in a tight infinite loop) usually doesn't make progress > after my IRQ_handler is entered for the first time. But when it does, > it has only 2-3 "favorite" values that the led ends up displaying. It > seems odd that I've got such a good phase lock on 2-3 out of 256 > possible values, but I can't imagine what this information is telling > me. > -- Perry

1 0