Are the firmware complete ? what is left to do ?

1. SourceCard Review 25/09/2008 Questions to be answered: • Are the firmware complete ? what is left to do ? • Are the TS software complete ? What is left to do ? • How do we improve and document the SC monitoring system in the TS ? • Now that the system is understood can we remove the delays of the USB? How do we study if it is still robust with USB transactions ? • Known problems and errors with the Source Cards (TTCRx Address, BC0 ...) How do we address them ?

2. 1. Are the firmware complete ? what is left to do ? Firmware completeness is in the eye of the beholder. Short answer: yes - it works. Two recent additions: 1) Inherent firmware revision & timestamp registers 2) “RCT” BC0 insertion To be considered: 1) The “proper” USB power-up/enumeration (never implemented) 2) How to “raise the alarm” when RCT BC0 is wrong

3. 2. Are the TS software complete ? What is left to do ? The TS software is also complete in that it does everything it is “meant” to. However what it is “meant” to do today is not necessarily the same as what it will need to do tomorrow as the requirements/specification/framework are all changing. If you want a definitive answer ask Marc and Ildefons when they will stop changing things… • Requested items: • To send BRAM patterns → already there – its an option in the database • Jim requested a capture utility → done, included in the next update • Send logging to central logging server → should be a trivial change in the configuration files

4. 3. How do we improve and document the SC monitoring system in the TS ? What does this mean? Could you please clarify… There is a large amount of TS monitoring infrastructure which I have heard discussion about but which appears to not actually be implemented yet - i.e. logging the monitoring tables to database (= the most fundamental operation it should perform), monitoring critical parameters, plotting monitoring data against time, etc The SC TS dumps the entire configuration and status spaces for all SCs to tables which it returns to the TS. What happens from there is anyone’s guess… Alex informs me that this is to do with the monitoring panel which Rob’s student is doing. We have to decide what we want from it…

5. 4. Now that the system is understood can we remove the delays of the USB? How do we study if it is still robust with USB transactions ? What USB delay? Could you please clarify… • There are two things to be considered here: • Initialization: Yes there is a long delay associated with safely restarting the TTCrx. This is compounded in the TS by slow database access. It is nothing to do with the USB. • Configuration: This takes of the order seconds. The other delays of significance are the delays associated with the PROM rebooting of the SCs where you have to wait for the FPGA to be reprogrammed.

6. 5. Known problems and errors with the Source Cards (TTCRx Address, BC0 ...) How do we address them ? • The problem of the TTCrx address has been dealt with in the new FW/SW release. Summarised in the email I sent and included here for completeness. 1a) I have made some major changes to the SC software base classes as per Costas' request that the SCs should always be able to return the correct TTCid, even if the TTCrx screws up. In the newest firmware there is now a register which keeps track of FW revision and a second that records the build date and time. This used to be done in the PROM usercode space. The PROM usercode is now used to store the TTCid. SO... the TTCid is now stored independently in two locations (TTCrx and PROM) and the two can be compared and errors flagged. 1b) This has necessitated more intelligent management of firmware. I have created a new class which manages the firmware (called FirmwareManager). In the SourceCardFirmware directory there is a tab-delimited .dat file recording all the variously available firmwares, revisions, build dates, time stamps etc. It is from this file that all firmware management is now performed - there is no more messing about with symlinks to .bit files. 1c) The above has however meant structural changes to both the SourceCardInterface and SourceCardManager classes. I have made all changes backward compatible with the older SW and intercompatible with all old firmware versions. 1d) This also allows the trigger supervisor to perform firmware version checking rather than ignoring it and hoping it is not a problem.

7. 5. Known problems and errors with the Source Cards (TTCRx Address, BC0 ...) How do we address them ? 2) The problem of the Leaf requiring a BC0 from the RCT before it can configure has also been dealt with in the newest FW/SW release. Again summarised in the email I sent and included here for completeness. 2a) I have added a firmware module that allows the SCs to generate the "RCT" BC0 a programable #BX after the TTC BC0 (and also to toggle the phase of the phase bit). 2b) I have added the necessary control for this functionality to all layers of code: SourceCardInterface, SourceCardManager, TS, database and XDAQ and tested this with the leaf cards in the lab. And it works. It is currently a black art to find the correct phase settings to get the leaf to latch to it but once they are found it works repeatedly.

8. 5. Known problems and errors with the Source Cards (TTCRx Address, BC0 ...) How do we address them ? 3) The problem of the unstable BC0 MAY not be in the bulk-data path domain at all but in the SC TTC clocking domain: There is a clock bridge the links the 40MHz TTCrx signals into the 80MHz SC domain. However, in changing the optical links to 100MHz, the 80MHz domain was forced to be a 2xMultiplied version of the TTC clock so that the bridge was clocking the signal on (in effect) the same edge (and changing the TTC fine clock delay doesn’t help). This theory needs to be tested but can only be done with RCT. However, if this was the cause then it should have caused the same 80MHz shift in the test patterns (not seen)… The good news is that this can be fixed in SW. Also summarised in the email I sent and included here for completeness. 3a) Thanks to JJ for pointing me to the likely (but currently untested) cause of the BC0 instability problems. This is most likely an edge effect that appeared when the clocking in the SCs was changed to accomodate the 100MHz oscillators. This can be fixed by setting a register which was previously never accessed. I have added the neccessary SW to set this register but will need the RCT to test this.

9. 5. Known problems and errors with the Source Cards (TTCRx Address, BC0 ...) How do we address them ? 4.1) There was concern about the USB bus getting bunged up and requiring power cycling of the crates. The reason that this has disappeared of recent months is that I updated the software to perform a hard HW reboot in the initialization rather than the soft reboot that was in there. This uses the other endpoint on the Cypress SX2 and so can be performed even if the bus is jammed, clearing the jam. 4.2) Because the firmware still does not handle the “proper” USB power-up/enumeration the USB is still dependent on the order in which you power up the hubs.