1.No mention is made about the ePLL. Figure 1 does not indicate which clocks are used by the various blocks. How does the VMM capture block guarantee that the incoming data, driven by the ROclk sent to the VMM, meets the setup and hold times of the clock used in the ROC’s VMM capture block? I suggest a section identifying clock domains and how their interfaces are handled. a.ROclk can be individually skewed, starting from 320MHz reference. b.With known phase of ePLL outputs, the Syn/PnR tool can adjust clock propagation (detailed ePLL specs not in hand yet) 2.The ROC needs to be configured by I2C. The eight SPI chip selects on the SCA are taken by the 8 VMMs. This frees 2 of the 4 pins that were dedicated to the four SPI signals. a.Yes configuration is handled via I2C 3.A section on configuration is needed with an enumeration of all configuration registers. a.Yes 4.Reset: hard reset is from SCA, either using a GPIO pin or an I2C reg; soft reset is from TTC. The hard reset is currently said to be an SLVS pin; it should be CMOS1.2. a.yes

5.What are SCAN_IN, OUT, EN, SCAN_EN, TEST_MODE? They are not described in the text. (Also SCAN_OUT is presumably an output.) a.These are scan-chain ports for DFT implementation. They ared only used for chip testing. They provide serial accs to all FF in the design. Automated test patterns are used to validate design 6.We no longer plan to use the connectivity shown in “Table 1”, at the bottom of page 16. We will take advantage of the flexibility of the full crossbar, so this table, the preceding paragraph and Table 10 should be shown only as an example. a.We should be very careful about the total data flow through the cross-bar. Currently it handles 1.28Gbps (32bit x 40MHz). May have to use higher speed and this may affect implementation. 7.NEW REQUIREMENT: Delay the output of the TestPulse for the VMM that is sent via the TTC by a configurable time. Could use the two (or four) different phases of the 160MHz clock. This is needed in order to calibrate the timing of the VMM. a.This can be done using 320MHz as reference clock. I suppose 3.125ns would be enough.

- The current version of the specification seems to still be incomplete. There is detail on the internal blocks, however the top-level interface could be better specified, e.g. the input and output data rates are missing. It would also be helpful to have a short description for the function of each of the I/O pins. Also the input and output data formats should be detailed at the top level. - generic data rates were assumed for the simulations. Need help to determine right data flow parameters - The TDS interface signals are not shown in the top-level diagram in figure 1. - will do. They are a fan-out of the BCR and BC clock from the TTC block - Although some configuration bits are specified in the description of the various blocks, there is no combined list of all the configuration registers. Also some blocks seem to have status outputs, but it's not clear if they go to status register bits, error counter or in the event format. - will do - The TTC interface is not specified. - TTC input format is still undefined. L0 Phase-2 scenario may impose important changes to the current proposal based on L0/L1 phase-2 scenario. - The pin list shows an SPI interface whereas the top-level connection diagram shows I2C, which is the interface used? - I2C - What is the CMOS I/O voltage level? 1.2V? - 1.2V - Where does the SEU output go? - GPIO pin of SCA chip

 What determines that the data_valid_o output of the DES block will be at one ?  There are still references to either I2C (text, excel table, main sytem figure) or SPI (Figure 1, Table page 8) interface : which one is correct ? o I2C  There is no description (a minima) for signals TDS_BClk and TDS_BCR at the top level (Figure 1) o Will add. They are fanout of BC clock and BCR signal from the TTC block  Is it envisaged to bypass the 8b/10b decoders/encoders, for straightforward debugging ? o Will take this into consideration The ROC document contains many detailed (gate level) diagrams: what is the logic design methodology (RTL code, synthesis tools etc …).? What is the verification methodology ? RTL and tools: Verilog, Cadence (RC, Encounter)

1.VMM3 to ROC data link. a.Has the byte and bit order been defined unambiguously at both ends of this interface. This concern is moot if this feature is programmable at one of the devices, but our reading indicates that this is not the case. i.We will be using the same Verilog sources, and verify with common testbench. Did not foresee programmable features (can be considered if time allows, eg. Comma selection) b.Has the entire data packet definition been reconciled between the VMM3 and ROC? In particular, the “message word and ID” fields do not appear to be consistent between both devices. i.Messages were not implemented. ROC has error/status registers. Selected errors can be taken outside to INTERRUPT pins of SCA. (SCA can sends automatically messages to Felix if INT pins change value) c.Full interface simulations between VMM3 and ROC could put this issue to rest. i.Will do that

1.ROC issues a.Does a specification exist for the clocks generated by the PLL? i.Unfortunately detail specification of ePLL (as of the core itself) it is not yet in hand. We should have it in short time. b.A detailed description of the TTC decoder needs to be provided. i.TTC format needs to be fixed. Depends on choices of Phase-2 operation.