So far we received the following comments:

GM:

Programming model:

p4: 3: Now it has been agreed, does it mean that an unique S/W common to
the JEM and ROD/CMM could be written to write to system ACE via VME?

p5: Glad to see that the I2C interface follow the CPM one's. The HDMC
I2C register format should be used now. This could be tested quickly.

-------------
On the Production note:
p4. 1.3: Does the JTAG tester include VME, CAN and TTC external port?
loopback minibackplane: could you test this at a later stage with a LSM
, your 9U crate and dedicated pattern different for each LVDS input? You
might also need 2 old CMM prototypes for the hit.

   I don't really understand why you are swapping 8 times and you don't
need to move the cables? Nevermind, ffter the production
crate test, you can probably have more Lsm and LVDS cables if needed.

last para: At B'ham, there is no infrastructure to test with a ROD. It
was not planned to have one. Actually, it will be nice to have one for the
production run.

-------------------------------------
JEM :
P13: 2.7.3 DCS

   Could you control via VME the Running/programming of the CAN
controller? I didn't see any bit related to it.

   Adam Davies keep connecting the pin2 to pin8 of the Philips part on
the CPM to make it working. Do you required the same fix?

p23. Timing: I will be curious to know any clock boundary crossing
 between deskew1 and deskew2 on the overall board.

p25: sect 3.10: 1st parag: Modules were broken: what was broken? PCB?
pins? track layers?

p27: fig 12: the ROD specification precise in the spec of the frame of
each individual jet element a serialiser error. I assume is it a parity error,
as stipulated in your figure, and no other kind of error?

p28: table 5: I found it hard to follow the cable numbers when I tried to
connect to the PPM spec p44 to the Jet/Energy backplane layout. I believe
a page is missing in the PPM spec as, according to PPM spec, cable 18
and 19 are half connected, and you expect them to be connected to
jet elements A and B. 

RS

In the Programming Model document, Section 1 Memory Map , 1.1 Mode, there is reference to VME block Transfers and
Broadcast operation of the JEM. The VME-- bus doesnt support block transfers , or a broadcast as the VMM only passes on
the A24D16 single-cycle VME transfers. I guess for a broadcast to all JEMs , care must be taken as the CPU will respond
to the first DTACK of the 'fastest' JEM. Will thse options be removed from the specification?

In the Test Results Document, 4th paragraph, there is a solution to fix the 3.3V MAX6656 Sensor/5V CANuC interface
problem using a level translator. Why not just replace the 3.3V MAX6656 with the 5V equivalent MAX6655, which has the
same footprint and could be fitted to existing JEMs?

Appologies if I've missed this, but are there any plans to stress the JEM by opperating it over a large temperature
range, at a higher TTC frequency, and also by running circuitry, such as the LVDS receivers and GLinks, at a lower
supply voltage?