ACC-5E / ACC-24E3 compatibility

[pennells]

Are this cards compatible? We have a Power PMAC mastering the card cage and, without the ACC-5E in the card cage, it utilized the ACC-24E3 clock for the Phase/Servo clock and everything runs. When we put our newly received ACC-5E into the system, the phase and servo clocks point to the ACC-5E but the phase and servo clocks stop running (the NoClocks flag becomes true as well).

We can run MacroControllerInit and the terminal returns:

 

Ring 0:Includes the following Accessories

ACC5E[0].RingMasterNum = 0

ACC5E[1].MasterNum = 1

 

but, the clocks are no longer running. Is there some test to run to ensure that the ACC-5E clock is functional or is this a compatibility problem.

[Omron Forums Support]

pennells,

 

ACC-5E needs to be the clock source and ACC-24E3 needs to receive those clocks. To enable this, please set Gate3.PhaseServoDir=3 for all of your ACC-24E3s. Does this fix the issue?

 

Please note that in order to write to any Gate3 structure, you must first issue this command: Gate3.WpKey=$AAAAAAAA

[pennells]

Unfortunately, I just checked. All of the Gate3 cards (ACC24E3 and ACC59E3) have Gate3.PhaseServoDir=3 already and it doesn't seem to work. The cage has a Power PMAC, an ACC59E3 (Gate3[0]), an ACC24E3 (Gate3[8]), and an ACC65E (GateIo[9]) along with the ACC5E (Gate2[0] and Gate2[1]) being look at.

 

It should be noted that PhaseServoDir for Gate2[0] is 0 and for Gate2[1] is 1 (which I suspect is correct).

 

As a quick check, I changed the Gate2 PhaseServoDir (s) to 3 and set it to 0 for the ACC24E3. The NoClocks flag clears. Is it possible that the ACC5E is not producing a Clock signal or is there some way to disable the ACC5E clock and it needs to be re-enabled. It's a brand new ACC-5E that we just received.

[Omron Forums Support]

We recommend issuing a $$$*** SAVE $$$ command sequence every time new hardware is installed.

 

I'll check with some of the other engineers to see whether they know this combination of cards to be an issue.

[pennells]

I did do a $$$*** SAVE $$$ command sequence when I installed the board.

 

I does appear to have some issue with the ACC-5E clock. What can cause the clock not to function? What is the issues that may arise if I use the clock on one of the ACC-24E3s that we have in our system? Will all MACRO functionality still work?

[wfsteele]

Each UMAC card using Gate2 chip(s) (such as the ACC-5E) has a bi-directional buffer chip interfacing the board's clock to the bus. The direction of the clock has to be set for each buffer chip (this is in addition to setting PhaseServoDir on the Gate2 chip(s)). This only applies to board using Gate2 chips, boards with Gate3 chips do this automatically when setting the PhaseClock direction. When the ACC5E is sourcing the PhaseClock, the buffer chip direction must be set by assigning the value 1 to Cid[n].Dir, where n depends on the Gate2 chip number. For Gate2[0] set Cid[4].Dir = 1. Check the table on page 1014 of the Power PMAC software manual. Also read pages 36 - 37 in the Power PMAC User's manual.

 

I encountered the same problem after upgrading to the new firmware last month. Apparently the older firmware took care of all this upon $$$***, but the new firmware seems not too. I submitted a complaint about this a month ago, which seems to have been ignored.

[pennells]

Thanks, "Cid[4].Dir = 1" is the answer to all the issues. The ACC-5E now appears to work correctly using it's clock. Figures that we didn't get the ACC-5E until after we had updated to the latest firmware so I thought that it must be a faulty card.

[curtwilson]

We have not been able to duplicate this problem here at the factory. In this configuration, the ASIC clock directions and any clock buffers always come up correctly as specified on any re-initialization. Still investigating.

[Omron Forums Support]

I also tested this. With firmware version 1.5.3.0 and with ACC-5E and ACC-24E3, at $$$*** I have cid[4].dir=1 and the clocks work fine.

[pennells]

Well, it no longer really matters. I've save the settings with cid[4].dir = 1 so it automatically gets set to that every time we do a $$$*** or reboot anyway but I did have to set it manually in the first place.

[wfsteele]

Both pennells & I had the same problem, so I think that it is a real problem. One thing that pennells & I have in common is that the ACC-5E card has the optional second Gate2 chip. Perhaps Delta-Tau used the single chip version in their attempt to duplicate the problem, which, possibly, only appears with the dual chip version.

[wfsteele]

Upon installing a pre-release version of the firmware (1.5.6.0), once again the PPMAC came up with sys.noclocks = 1 and I had to manually set cid[4].dir = 1 to use the ACC-5E clock.

[curtwilson]

We have tracked this down now. The re-initialization algorithm treats the two MACRO ICs on a fully populated ACC-5E as having separate bi-directional buffers. It sets up the first IC for clock outputs and the buffer for clock outputs. Then it sets up the second IC for clock inputs and the buffer for clock inputs, overwriting the original buffer direction. This has been fixed now in our working development firmware, and will get into the next maintenance release. Thank you for helping us track this down.

[shansen]

Curt, I just ran into the same issue, but was able to fix it using Cid[4].dir=1 as suggested above. Will this fix be in the next firmware release? Any idea when the next firmware release will be?

[curtwilson]

The fix will be in the next release, which is expected in the 3rd quarter of this year.