3. New Delhi Release
| Package | Version | Source | Binary | Docs |
|---|---|---|---|---|
| VXW | V2-0-0 | none | bin | none |
| CMX | V2-0-0 | none | bin | none |
| GNAT | V1-0-21 | src | bin | gnat, xbrd |
| GTEM | V1-3-4 | src | bin | doc |
| GAEM | V2-1-2 | src | bin | doc |
| GDAB | V1-1-1 | src | bin | doc |
| GGLT | V1-3-6 | src | bin | doc |
| EVUT | V1-1-11 | src | bin | doc |
| CTST | V0-0-20 | src | bin | none |
Table 7. Package Versions
This release adds a minor update to the GTEM package, correcting a software bug while checking the GCRC/GCFE ERROR_SUMMARY bit. This bit is returned by the GCRC with every CAL read command. Previously this bit was not checked correctly, with the result that the summary error bit was never detected. Now if the summary bit is set gGCRCread() and gGCFEread() will return GCAL_ERR_SUMMARY.
This release also adds a minor update to the GAEM package, correcting a hardware bug with the GARC version 3 design. The software fix changes the parity calculation used when forming GAFE command bit strings. This fix did not affect any public software interfaces.
3.1. GARC version 3 Bug Details
 | This release of GAEM only supports version 3 of the GARC chip. You cannot mix version 2 and version 3 GARC chips. If you must use version 2 GARC chips then you must use V2-1-1 of the GAEM library. |
The full description of the version 3 GARC problem follows, courtesy of Bob Baker:
One of the GARC V2 to V3 changes was to move the sampling time of the GAFE return data from the (20 MHz) clock pulse just after generating the GAFE Clock positive edge to the (20 MHz) clock pulse just before generating the GAFE Clock positive edge. This was done because for some GAFE5's under some conditions the return data was changing at the sampling time and could not be detected reliably. The change allows an extra 100 nsec for the signals to propagate and settle. The change also causes the last command bit from the GARC to the GAFE (the parity bit) to be cleared to zero 100 nsec too early. For commands with parity=1, the GAFE sees parity of 0 and rejects the command.
The change in the verilog is in the gafe_command_handler state machine. In state SEND_GAFE_ZEROES, the condition (sck_ctr == 1) is used to both clear the gafe_cmdd and shift in the gafe_readback_reg. The condition in GARC V2 was (sck_cntr == 3). The timing diagram shows the new return data sampling time and the parity bit truncation.
The workaround is to form all AEM to ACD GAFE commands so that the GARC to GAFE parity bit computes to zero. Bit 15 in the data field becomes an odd parity bit over the fields: GAFE Address, Read/Write, Register Number, Data[14:0]. This fix does not effect any of the GAFE functions since data bit 15 is not used. (The GAFE CONFIG_REG does contain and read back all 16 bits but bit 15 does not control anything). This fix will work for any GARC version.
At SLAC we discovered a minor implication of this fix. While true none of the GAFE registers use all 16 bits, the GAFE CONFIGURATION register lets you write all 16-bits, even though only the lower order 6 bits have any meaning. The consequence is that when the register is read back the 16th bit may or may not be set depending the required parity.
For example you write 0x20 to the CONFIGURATION register. During the write operation the GAEM software high-jacks the 16th bit of the payload to ensure odd parity, which under certain circumstances, means making the 16th bit a one which makes the 16-bit payload 0x8020. When you read the CONFIGURATION register back you get the value 0x8020 instead of 0x20.
So we decided to strip off the 16th bit of the response payload for GAFE read commands. This is OK for the same reasons Bob Baker states above, no GAFE register uses the MSB of the 16-bit payload.
If anyone(perhaps ACD I&T) has a GAFE register write/read test that depends on the 16th bit of the GAFE_CONFIGURATION register being writable it will no longer work. This a minor issue as the upper order bits of the GAFE CONFIGURATION register have no effect.