D0 Note XXXX

D0 Note 3479

D Zero Preliminary Report on a New VBD working with Two VRBs in Central Tracking (CT) Mode.

R. Angstadt

July 7, 1998

Introduction

An upgraded VBD was tested in Central Tracking Mode with two Fermilab VRBs with firmware Version 2.21A. Although an old (Marc Baert designed and built) SARC board was physically present in the crate, software wise it was not accessed except for being initialized (reset). The crate under test was a new VME-64 "VIPA" crate with a Bit3 Model 406 (Address 32, Data 16, no DMA ) set up in slot 1 as bus arbitrator. No 68K or other processor was present in the crate for this test. A VME-Metro VBT 321 was also in the crate to verify operation.

Platform and Software

On the other end of the Bit3 was a Gateway P-90 overdriven with a P-150Mhz (Intel) CPU running Windows -95 and Excel-97 (Version 8.0). Custom Fermilab software allows access to the Bit3 and thus VME address space. This software was used for initializing the boards under tests and some preliminary algorithm verification. Once operation was verified a faster DOS Turbo Pascal Program, "VBD98", was written to exercise the crate as fast as possible. This was based on some very old code used in testing the original Run I VBD and only took about 1 working day to remold (code reuse).

Test Results

For the actual loop test Windows-95 was shut down after initializing the crate under test. This would eliminate some overhead and allow the test to have a few more CPU cycles. VBD98 was then started and allowed to run overnight so that >24,000,000 test loops were executed. No errors were detected of any kind! Random runs of the VME Metro confirmed that data was moving across the backplane as it was supposed to. VRB activity lights also indicated they were in use and were on almost solid. The test lasted > 16 solid hours (including a summer storm) averaging a loop test frequency of ~400 hertz. The VBD error LED was NOT on when the test was terminated in the morning to re-arrange the test area workspace

No errors were detected in 24 million loops. The test pattern in each VRB is 142 words times 2 VRBs means that 6.816 billion words were longword block transferred (DMA) between the VRB to the VBD. With the VBD header and trailers added this inflates to 322 words per loop so that 7.728 billion words were read over the Bit3 into the computer (one 16 bit word at a time) where they were compared. No comparison errors (or VME bus errors) were detected. Since each word is 16 bits for this test the bit error was less than an impressive 1 in 123,648,000,000 (123.648 billion ) bits!

During program development one error every loop associated with a Bit3 timeout was eventually traced to the program not waiting long enough after the VBD was told to go=0x3d. After adding the only program delay of ~1 millisecond this error was eliminated. The rest of the VME crate hardware went faster than the P.C. interface could go so handshaking was not implemented for this test. I believe the code was working correctly as VME Metro samples help confirm that everything was working as shown in Appendix V.

Timing

Appendix V is also useful for deriving some basic timing. All times are in microseconds unless other wise stated. Throughput rates are in Mega Bytes per Second or MBS. The Event setup time with a Bit3 model 406 as bus arbitrator and nothing else using the bus is:

microseconds	Line	Comment
5.16	219	reads event number (bug in VRB?)
1.32	220	reads crate I.D.
6.48		Total microseconds

Table 1

The first list element setup time for the slot 9 VRB is:

microseconds	Line	Comment
3.8	221	reads word count from VRB
2	222	read the first word from the FIFO (start of DMA)
5.8		Total microseconds

Table 2

The second list element setup time for the slot 11 VRB is:

microseconds	Line	Comment
3.08	293	reads word count from VRB
2.04	294	read the first word from the FIFO (start of DMA)
5.12		Total microseconds

Table 3

Each longword in the DMA typically takes 0.12 microseconds. One over this for frequency and then times four for conversion to bytes gives a typical (maximum) basic data rate of 33.333Mega Bytes per second. However looking at the Metro trace more carefully one realizes that there are a few slowdowns. One slowdown is predictable and is modulo 256 and has to do with VME specification of a DMA block size limit of 256. This penalty is typical of the ~0.320 and 0.360 microseconds listed on lines 280 and 352. One will also note that in a small number of cases the 0.12 jumps up to 0.20 microseconds. In Appendix V this occurs in the middle of a block 4 times on lines 284, 328, 339, 350. In other cases I think I've counted on the order of 5 times. So taking the modulo 256 and random increases into account we have:

microseconds	0.12	basic (max) data rate (33.333Mega Bytes per second)
17.04	142	number of bytes in 1 loop, header, trailer, test pattern
0.16	0.08	block transfer has 1-3 random increases to 0.2 per VRB use 2x
0.22	0.22	modulo 256 increase
17.42		sum
0.122676056	32.60619977	Mega Bytes per second for 1 VRB test pattern attained.

Table 4

Using a list setup time of :

3.44		average of word count read
2.02		average of time to first word of FIFO
22.88000000	24.82517483	Time & MBS. Including each list set up for 1 VRBs = 142 words
45.76000000	24.82517483	Time & MBS. Including each list set up for 2 VRBs = 322 words
68.64000000	24.82517483	Time & MBS Including each list set up for 3 VRBs = 426 words

Table 5

The point of the above table is that this is going to be relatively constant and independent of the number of VRBs. List element set up time lowers the basic transfer rate to a VRB unit rate of ~24.8MBS independent of the number of VRBs but strongly coupled to the payload size. As the event size goes up this rate will approach closer to ~32.6 MBS or for empty records the data rate will decrease as setup times predominate.

Adding in the constant setup of 6.18 microseconds for the crate I.D. and Event number reduces things down to the following table as the number of VRBs are increased and the event size increments as a constant at 142 words per VRB:

29.36000000	19.34604905	Time & MBS. Including all set up overhead for 1 VRBs = 142 words.
52.24000000	21.74578867	Time & MBS. Including all set up overhead for 2 VRBs = 322 words.
75.12000000	22.68370607	Time & MBS. Including all set up overhead for 3 VRBs = 426 words.
98.00000000	23.18367347	Time & MBS. Including all set up overhead for 4 VRBs = 568 words.
120.88000000	23.49437459	Time & MBS. Including all set up overhead for 5 VRBs = 710 words.
143.76000000	23.70617696	Time & MBS. Including all set up overhead for 6 VRBs = 852 words.
166.64000000	23.85981757	Time & MBS. Including all set up overhead for 7 VRBs = 994 words.
189.52000000	23.97636133	Time & MBS. Including all set up overhead for 8 VRBs = 1136 words.

Table 6

This will continue to approach the basic VRB unit rate of ~24.8MBS as more VRBs are added to the limit of the crate.

Request for Comment

Note that the VRB header is 7 longwords in Appendix III. Mark Bowden would like to change this ASAP to 8 longwords if we agree so that if the VBD ever supports huge words (64 bit words) as per VME-64 we won't leave half of a huge word (32 bits) floating in limbo. The VRB does support huge word block transfers. Is the VBD going to support huge word transfers ever? Commercial VME 64 I/O boards are now advertising VME64 DMA Block Mode transfers at sustained 40M Bytes/sec using VME 64. Each would have to be evaluated in terms of the various setup times and DMA transfer size as that can quickly dominate as the tables attempt to show.

Introduction to VIPA Crates

Severe physical problems of inserting old style VME boards in the present VIPA test crate was observed. Proper VIPA boards are supposed to have Insertion/Extraction levers with a ~4 to 1 mechanical advantage as part of the VIPA standard to overcome 9U insertion forces of 175 pounds according to Rittal. Other VIPA physical standards I recently became aware of include external connector stiffeners and thicker G10 with milled down edges to fit in specially designed plastic spring loaded rails which are screwed in as opposed to the normal VME snap in. Further the screw heads are inconveniently facing the Power Supply and Fan Pack so that typically the crate must be removed to get at the screws. Old style 6U and/or shorter than 400mm VME boards must be accommodated with some sort of extender board or the rails must be cut out and/or front panels removed.

When some older VME boards were forced in by hand from the front panel they exhibited frightening board flexing due to high insertions forces of normally too thin G10. A standard VME extender/adapter for the Bit3 was used which worked very well in this VIPA showing no signs of flexing. on insertion. It had heavy enough extraction levers and solid enough front panel which was obviously over-engineered for standard VME as they worked without breaking on the higher insertion force VIPA crate. It had no insertion levers which is a problem but currently no other extenders really do either! Please see Appendix 6 for further information.

Conclusion

Once all VME boards were fully seated in the VIPA crate, electrically the VBD and VRB work together with error rates to low to measure for this limited test. More testing needs to be done in a configuration with a SARC controller. Although an old style SARC was plugged in the bus, it was NOT really used in this test. No errors were found in 123,648,000,000 bits! (~123.648 billion bits).

Basic data rates are 120 nanoseconds per longword during block transfers. This works out to an impressive 33.333Mega Bytes per second (MBS) fastest rate. Additional overheads reduce this rate slightly to ~32.6 MBS. List processing setup times of ~5.5 microseconds give a maximum VRB rate of ~24.8MBS for a VRB size of 142 words. When the event setup overhead is added Table 6 shows 1 VRB to have a rate of ~19.3MBS. With 8 VRBs the rate climbs to ~23.9 never going over ~24.8MBS for the test payload of 142 words (16 bit words). No testing was done with a different VME bus arbitrator. For example a Motorola MV 162 board set up as crate arbitrator might grant the bus quicker setup times might go down and data rates up.

Although bit error was impressively non-existent at this level of testing for such high performance hardware, the present state of VIPA mechanicals with respect to supporting old VME cards was disappointing to the point of being alarming. Existing under designed levers for 9U crate insertion forces of 175 pounds combined with weak front panels mounted on thin flexy G10 do not make for an over-engineered mechanical system in any way. The hastily retrofitted SARC controller already has one pin epoxied back in after it was pushed out of its connector. At least four slots in the Feinman center VRB VIPA test are not usable. These are VME 64 slots and not old style slots. Please refer to Appendix 6 for more.

Appendix I: VBD Download

hex			hex
add	val (hex)	count	val to write	Comment
A000	40	1	0c	unlock VBD board
A008	0	2	2	Put VBD in CT mode
A00A	0	3	002a	address of event # (offset in VRB address)
A00C	4	4	c0d0	crate ID address
A010	40	5	bb00	code for add. Mod for reading data
A012	0	6	f900	code for add Mod for I/O addresses
A014	42	7	ff09	high word of address
B000	43	8	0032	beginning of word count list
B002	44	9	0032	next word count list
B004	44	10	0	list null terminator
B800	45	11	0009	pointer to data (high 16)
B802	46	12	0018	pointer to data (low 16)
B804	47	13	000B	pointer to data (high 16)
B806	47	14	0018	pointer to data (low 16)
A000	48	15	80	lock memory List and reset VBD
A000	1C	16	1c	lock board

Figure 1

Above is an Example How to Downloading the VBD to use 2 VRBs.

According to Dave Cutts, the latest VBD incarnation for CT mode has only changed the count register from byte count to long word count. The first column addresses are all VBD registers in VME short I/O space with VME address modifier 0x2d. The "val to write" column contains the value written to the VBD register in the left column, "hex add". The first target VRB board is in slot 9 with a geographically assigned VME base address of 0x90000. The second target VRB board is in slot 0xB with a geographically assigned address of 0xB0000. Line ("count") # 7 could be changed to point to the SARC controller card at 0x4800xx to read the event I.D. from there instead of where it is presently pointing to at the first VRB board base address of 0x90000.

When the VBD runs it will use line #7 and Line #3 values to form a complete address to read the event number with a VME address modifier derived from the code value entered in line #5. Empirical results courtesy of the VME-Metro show that in this case the line 5 value of 0xbb means to use 0x3b with all 24 address lines driven (Figure 4). Line 6 works in a similar way for "I/O addresses" according to some Run I documentation.

Line #8 begins the low 16 bit address list for obtaining the long word count from. Line #10 signifies that this is the end of the list with a 0=null terminator. Next begins a list of full 32 bit address displayed as high/low 16 bit pairs which determine where to read the data from = the DMA FIFO's address.

When the VBD processes this list it uses for example the high address word from line 11 with the low address word from line 8 to get the first long word count from the first VRB=0x90032. Then it reads the data from the address in line 11 and line 12 to read the data FIFO via DMA. This completes the first element of the list. The second list element is on line #9 combined with the high address in line 13. After doing this it then reads the data FIFO from the next complete address in line 13 and 14. The limitation of this scheme is that the long word count address and data FIFO address must be in the same 64K byte segment. The other limitation of the VBD that is that the VBD really has no high byte address drivers so the target boards cannot be located above 0xff ffff. However at the present time I see no address conflicts with this scheme. Please speak up now if anyone knows why this scheme will not (continue) to work for the next run!

Figure 2

End of VBD Download.

The VME-Metro shows that after line 15 is downloaded (0x80 = VBD reset) the VBD immediately (7.08 microseconds) goes out and reads the crate I.D. # at address 0xC0D0 which in this case is 0x002c before the relatively slow download finished at line 16 (both figures #1 and #2).

Appendix II:

VRB/SARC Download Sequence

Figure 3: VRB Download.

Figure 3 is a VME-Metro trace of initializing the VRBs and resetting the SARC. Figure 4 references Figure 3 and attempts to give some meaning to the codes sent. The definitive guide to VRBs

Is at http://www-ese.fnal.gov/eseproj/svx/vrb/vrb.htm.

*hex*	hex	Figure 3
add	val to write	Line	COMMENT
B0070	40	TRIG	enable SVX chip (channels) 0-7
B0072	FF	1	enable simulation mode
B0074	0	2	gray code disable
B003C	0	3	reset VRB
48c001	40	4	reset SARC (byte access)
90070	40	5	enable SVX chip (channels) 0-7
90072	FF	6	enable simulation mode
90074	0	7	gray code disable
9003C	0	8	reset VRB

Figure 4.

VRB Download Comments.

Appendix III:

Single VRB "Payload" (Excel View of Unchanging VRB Header and Test Pattern)

	32 bit word #	16 bit Word #
16 bit direct VRB read
11C		1
CD	1	2
0		3
0	2	4
0		5
0	3	6
0		7
0	4	8
0		9
0	5	10
0		11
0	6	12
100		13
0	7	14
0		15
101	8	16
202		17
303	9	18
404		19
505	10	20
606		21
707	11	22
808		23
909	12	24
A0A		25
B0B	13	26
C0C		27
D0D	14	28
E0E		29
F0F	15	30
1010		31
1111	16	32
1212		33
1313	17	34
1414		35
1515	18	36
1616		37
1717	19	38
1818		39
1919	20	40
1A1A		41
1B1B	21	42
1C1C		43
1D1D	22	44
1E1E		45
1F1F	23	46
2020		47
2121	24	48
2222		49
2323	25	50
2424		51
2525	26	52
2626		53
2727	27	54
2828		55
2929	28	56
2A2A		57
2B2B	29	58
2C2C		59
2D2D	30	60
2E2E		61
2F2F	31	62
3030		63
3131	32	64
3232		65
3333	33	66
3434		67
3535	34	68
3636		69
3737	35	70
3838		71
3939	36	72
3A3A		73
3B3B	37	74
3C3C		75
3D3D	38	76
3E3E		77
3F3F	39	78
4040		79
4141	40	80
4242		81
4343	41	82
4444		83
4545	42	84
4646		85
4747	43	86
4848		87
4949	44	88
4A4A		89
4B4B	45	90
4C4C		91
4D4D	46	92
4E4E		93
4F4F	47	94
5050		95
5151	48	96
5252		97
5353	49	98
5454		99
5555	50	100
5656		101
5757	51	102
5858		103
5959	52	104
5A5A		105
5B5B	53	106
5C5C		107
5D5D	54	108
5E5E		109
5F5F	55	110
6060		111
6161	56	112
6262		113
6363	57	114
6464		115
6565	58	116
6666		117
6767	59	118
6868		119
6969	60	120
6A6A		121
6B6B	61	122
6C6C		123
6D6D	62	124
6E6E		125
6F6F	63	126
7070		127
7171	64	128
7272		129
7373	65	130
7474		131
7575	66	132
7676		133
7777	67	134
7878		135
7979	68	136
7A7A		137
7B7B	69	138
7C7C		139
7D7D	70	140
7E7E		141
7F7F	71	142

Appendix IV:

VBD Header Trailer Plus 2 Consecutive VRB "Payloads" and VBD Trailer

(Excel View)

	32 bit word #	16 bit Word #
VBD read
0		1
A0	1	2
CD		3
2C	2	4
3333		5
CCCC	3	6
4444		7
BBBB	4	8
5555		9
AAAA	5	10
6666		11
9999	6	12
7777		13
8888	7	14
8888		15
7777	8	16
11C		17
CD	9	18
0		19
0	10	20
0		21
0	11	22
0		23
0	12	24
0		25
0	13	26
0		27
0	14	28
100		29
0	15	30
0		31
101	16	32
202		33
303	17	34
404		35
505	18	36
606		37
707	19	38
808		39
909	20	40
A0A		41
B0B	21	42
C0C		43
D0D	22	44
E0E		45
F0F	23	46
1010		47
1111	24	48
1212		49
1313	25	50
1414		51
1515	26	52
1616		53
1717	27	54
1818		55
1919	28	56
1A1A		57
1B1B	29	58
1C1C		59
1D1D	30	60
1E1E		61
1F1F	31	62
2020		63
2121	32	64
2222		65
2323	33	66
2424		67
2525	34	68
2626		69
2727	35	70
2828		71
2929	36	72
2A2A		73
2B2B	37	74
2C2C		75
2D2D	38	76
2E2E		77
2F2F	39	78
3030		79
3131	40	80
3232		81
3333	41	82
3434		83
3535	42	84
3636		85
3737	43	86
3838		87
3939	44	88
3A3A		89
3B3B	45	90
3C3C		91
3D3D	46	92
3E3E		93
3F3F	47	94
4040		95
4141	48	96
4242		97
4343	49	98
4444		99
4545	50	100
4646		101
4747	51	102
4848		103
4949	52	104
4A4A		105
4B4B	53	106
4C4C		107
4D4D	54	108
4E4E		109
4F4F	55	110
5050		111
5151	56	112
5252		113
5353	57	114
5454		115
5555	58	116
5656		117
5757	59	118
5858		119
5959	60	120
5A5A		121
5B5B	61	122
5C5C		123
5D5D	62	124
5E5E		125
5F5F	63	126
6060		127
6161	64	128
6262		129
6363	65	130
6464		131
6565	66	132
6666		133
6767	67	134
6868		135
6969	68	136
6A6A		137
6B6B	69	138
6C6C		139
6D6D	70	140
6E6E		141
6F6F	71	142
7070		143
7171	72	144
7272		145
7373	74	146
7474		147
7575	75	148
7676		149
7777	76	150
7878		151
7979	77	152
7A7A		153
7B7B	78	154
7C7C		155
7D7D	79	156
7E7E		157
7F7F	80	158
11C		159
CD	81	160
0		161
0	82	162
0		163
0	83	164
0		165
0	84	166
0		167
0	85	168
0		169
0	86	170
100		171
0	87	172
0		173
101	88	174
202		175
303	89	176
404		177
505	90	178
606		179
707	91	180
808		181
909	92	182
A0A		183
B0B	93	184
C0C		185
D0D	94	186
E0E		187
F0F	95	188
1010		189
1111	96	190
1212		191
1313	97	192
1414		193
1515	98	194
1616		195
1717	99	196
1818		197
1919	100	198
1A1A		199
1B1B	101	200
1C1C		201
1D1D	102	202
1E1E		203
1F1F	103	204
2020		205
2121	104	206
2222		207
2323	105	208
2424		209
2525	106	210
2626		211
2727	107	212
2828		213
2929	108	214
2A2A		215
2B2B	109	216
2C2C		217
2D2D	110	218
2E2E		219
2F2F	111	220
3030		221
3131	112	222
3232		223
3333	113	224
3434		225
3535	114	226
3636		227
3737	115	228
3838		229
3939	116	230
3A3A		231
3B3B	117	232
3C3C		233
3D3D	118	234
3E3E		235
3F3F	119	236
4040		237
4141	120	238
4242		239
4343	121	240
4444		241
4545	122	242
4646		243
4747	123	244
4848		245
4949	124	246
4A4A		247
4B4B	125	248
4C4C		249
4D4D	126	250
4E4E		251
4F4F	127	252
5050		253
5151	128	254
5252		255
5353	129	256
5454		257
5555	130	258
5656		259
5757	131	260
5858		261
5959	132	262
5A5A		263
5B5B	133	264
5C5C		265
5D5D	134	266
5E5E		267
5F5F	135	268
6060		269
6161	136	270
6262		271
6363	137	272
6464		273
6565	138	274
6666		275
6767	139	276
6868		277
6969	140	278
6A6A		279
6B6B	141	280
6C6C		281
6D6D	142	282
6E6E		283
6F6F	143	284
7070		285
7171	144	286
7272		287
7373	145	288
7474		289
7575	146	290
7676		291
7777	147	292
7878		293
7979	148	294
7A7A		295
7B7B	149	296
7C7C		297
7D7D	150	298
7E7E		299
7F7F	151	300
1107		301
EEF8	152	302
2218		303
DDE7	153	304
3329		305
CCD6	154	306
443A		307
BBC5	155	308
554B		309
AAB4	156	310
665C		311
99A3	157	312
776D		313
8892	158	314
887E		315
7781	159	316
998F		317
6670	160	318
AAA0		319
555F	161	320
BBB1		321
444E	162	322

Appendix V:

VME Metro Scan of 1 Test Loop of VBD reading 2 VRBs.

The following VME-Metro dumps were sampled the morning after it had run for > 16 hours near the 24 millionth loop. The trigger is not set on anything special so I have found where the P.C. read and compared the last trailer of the last loop at 0x380292 indicated by the "==>" at Line 209; thus line 210 is the first line of the next complete loop.

Lines 210 through 217 basically set up the VRBs for the next loop. Line 210 tells the first VRB to load (in this case a simulated event as that's the mode we initialized the VRB in earlier) to buffer #4. In Line 211 the P.C. is loading the VRB with an arbitrary Bunch Crossing number of "ABCD". Line 212 is supposed to be loaded with the Event Number, an arbitrary "ABCD". Line 213 together tells the VRB to move the contents of buffer #4 to the output buffer. Lines 214 through 217 inclusive do the same as above for the second VRB in slot 0xb.

Line 218 tells the VBD to begin to process it's list or "go" as if a Trigger had been generated (0x3d is the software "trigger"). In the next line the VBD reads the event number "CD" (which should be "ABCD": I think I remember Mark Bowden saying he knew about this bug and was working on a fix?) Next the VBD reads the crate I.D. from short I/O (notice the "2D" for the modifier but notice also that the Metro show the high address bits being driven with 0x09 by the VBD instead of 0xff? Is this because I did not initialize the VBD with the correct addressing code earlier? Which one and what should it be? At any rate it does works as it presently is.)

In line 221 the VBD reads the long word count of 0x47 and then begins the DMA in the next line.

The data matches the first column of Appendix III: VRB test pattern.

In line 365 the P.C. is waiting a millisecond to wait for the VBD to finish doing its block transfer. Although this delay is (a lot) longer than necessary (the delay is not tuned), it was the quickest and easiest way to stop always having a timeout error on the first read. Thereafter the P.C. is reading and comparing each word read to an internal array in ~5 microseconds per word. Line 366 is the long word count of the data to follow (exclusive of word count).

Line 664 is the end of the P.C. reading the "payload" and then it begins reading the VBD "trailer". The section that is omitted is essentially the data in Appendix IV with addresses steadily incrementing by two

Line 686 is the last read of the VBD "trailer" by the P.C. and signifies the end of 1 test loop. The next is the beginning of the next loop.

Appendix VI:

For Those Who Have Not Had the Pleasure to Drive a New VIPA Crate.

As the Oldsmobile commercial says "it's not your father's car" so is a VIPA crate to a VME crate in terms of it's physical properties. After trying to take this thing on a (two week too long) test drive to say I was disappointed is an understatement: I'd leave it by the side of the road where the steering wheel came off in my hand. (The less than two week old (new) extraction lever broke in my hand on attempting to remove a (poorly) retrofitted VME card from the crate.)

Saying that there is nothing physically over-engineered in terms of extra robustness is an understatement. When I spoke to Ed Barsotti about the problem he suggested that I call Eike Waltz of Rittal who was introduced to me as "one of the best VME mechanical engineers (Ed) knows". After speaking with Eike I was at first (very) optimistic that a quick fix (better levers) would soon be in my hot sweaty little hands. Eike admitted that the plastic extraction levers were never really designed for the 175 pounds of insertion force necessary for a VME-64 board in a 9U crate and that he would immediately (that weekend, this was Friday) begin designing new (much more expensive) "metal" levers. That's about the extent of my customer service call so far: "too expensive" for the model with the steering wheel that really works! Yep, I'm definitely not at a Saturn dealership because this is not a fun experience.

Personally I don't think grinding off the too sharp edges of the rail caused by a backward stamp is going to make the problem(s) go away on what is basically a part never intended for use on a 9U crate according to "one of the best" VME mechanical engineers. What else wasn't really designed for the forces in a 9U crate? There's a nice set of custom curved rails (when they are new they are straight) caused by this same lever on the Feinmen center VRB test crate from having been bent and then incompletely straightened.

So currently there is nothing from customer service in the works other than a grind job unless perhaps D0 comes up with something more robust. My opinion is that driving a full crate of these with a weak steering wheel isn't the way we want to go.

Ed wants us to know that lots of (sales?) documents are available including IEEE 1101.1, 1101.10 & 1101.11. In addition he has requested the following be distributed:

"People,

Bob Downing and I have prepared a document which should help people

manufacture VME64 Extensions (VME64x) modules and transition modules

correctly. It also contains recommendations for 'retrofitting' old VME32

modules of various sizes including commercially-available 6U x 160mm

modules. This document can be found at the following URL:

http://www-ese.fnal.gov//VIPA/UserInfo/ModSubH.pdf

We ask people, especially D0, to become familiar with the specifications

referenced in this document and the guidelines both referenced and contained

in this document. We then ask people needing further help to contact one of

us for individual assistance.

Please distribute this e-mail to appropriate people.

Ed Barsotti

Fermilab, MS368

P.O. Box 500

Batavia, IL 60510 USA

Ph: (630) 840-4061

FAX: (630) 406-9735"