From blevan@fnal.gov Wed Apr 10 09:28:53 2002 Date: Fri, 05 Apr 2002 11:26:02 -0600 From: Levan Babukhadia To: l1_ctt_ps_firmware@listserv.fnal.gov Subject: new CTT/PS protocols, also now in one file! Dear all, It is my pleasure to announce the new version of the L1CTT/PS protocols. Many changes have taken effect and I made an extra effort to collect all relevant definitions, codes, etc., in one place. Many thanks to all of you who have contributed with your constructive comments and suggestions! I started from scratch and I put all the protocols into one file, which is also easily printable -- something that I myself and we all have always very much desired to have. I'm attaching the new version of the protocols in a pdf format -- this is exactly how they will be made available for yours and others references. I will maintain all the necessary sources for the protocols and any further changes will have to go through approval process. You should now review the protocols, especially the ones affecting your inputs and outputs, and should e-mail me and/or come to the Tuesday meeting with your comments and suggestions, especially if you will notice overlooked inconsistencies, which I'd be surprised if aren't there. In either case, you should provide your feedback also in writing to facilitate implementation. Since all of us have been actively reviewing the protocols recently, a short period for your feedback should suffice and so I would like to collect your comments and suggestions by or during our next meeting on Tuesday, April 9. Note however that certain formatting issues, appearances, etc., may not be easy to change at this point and we should not spend much time on such things. Instead, in the first place, we should try to concentrate on the contents of the protocols and any inconsistencies therein. After the April 9 meeting, this new version of the protocols (v07-00) will become in effect superseding all previous versions. This also means that the present web-based protocols with pop-ups unfortunately can no longer be supported or maintained after that time. I will however maintain the earlier protocols on the web pages for historic reference purposes. At that time, I will also circulate these new protocols to all the relevant Level 2 and some other parties for their final sign-off -- even though recently I have been discussing these matters with them a lot and we have consensus on all the issues, it's always a good idea to double- check, just in case. Below I list (not in any particular order) some of the important changes or redefinitions and clarifications in order to draw your attention at most critical in my opinion matters regarding the new protocols. Regards, Levan -- The protocols will be organized according to the hardware. E.g. protocols for LVDS transfers in Level 1 time are grouped together, protocols for G-Link transfers to Level 2 preprocessors together and so on. -- Bitfield definitions will not follow the protocol tables immediately. Rather, all definitions, also grouped according to the hardware, will follow after all the protocol tables. Within each section, definitions will be alphabetically ordered according to bitfield name. If the same bitfield appears in more than one hardware specific transfers, its definition will appear only once, wherever it happens to appear the first time. Everywhere else only a reference will be made to where this bitfield has already been described. This avoids unnecessary duplication of information and avoids many mistakes that usually follow when updating such duplicated information. -- This structure works very well from the point of view of presentation and maintaining of the protocols, which is not an easy task! Granted, it makes looking up a particular definition not ideally easy, but we'll have to compromise for any help we can get for the ease of maintaining the protocols! -- Now we have the new, re-arranged DFES protocols in, thanks to Qichun for careful discussions on this issue. Not every bitfield is absolutely fixed yet because DFES inputs are not yet completely specified. However, the format is general enough to accommodate any mapping of AFE inputs and reflects the architecture change from the DFES/CPSS/L2PSpp system to just the DFES/L2PSpp system. -- Having talked to Roger Moore of Level 2, it turns out that we unfortunately can not change Status and Proc bit allocations in the header of the transfers to L2 preprocessors. In fact, we have no control whatsoever over the Status bits, but the Proc bits are entirely in our control. So, the old protocols have been restored there to have 8-bit fields for Status and Proc bits. The Proc bits will be left to the firmware authors to define their bit-by-bit meanings as they wish. This unfortunately means that we will not be able to insert the detailed diagnostic information, unlike what we have been discussing recently. However, we are free to merge the Status and Proc bits in the header of transfers to the L3/VRB, so we are taking advantage of this fact there. -- The DATA TYPE codes for the use within our system had to change somewhat. It turns out that the old codes weren't quite single-bit self-correcting, at least not all of them. Besides, no code is needed for L2CPS Stereo data now that we don't have DFES/CPSS LVDS transfers. Only two of the six old codes survived. I came up with two more unique codes, and with the total of four codes we are able to encode all different L1 and L2 data types (also of course making use of the L1/L2 bitfield, as before). -- The PAD frames in L2pp communications revert to the old scheme. Namely, they are inserted after the vertical parity frame to make the total number of the 16-bit frames divisible by 8. Note that therefore the last frame marker will sometimes end up in the second from of the padding word. -- In the first header of Level 2 LVDS transfers there was a mistake in the web based protocols in that the order of fields in the second byte was messed up as compared to the original definition. There is no reason for such a change, this was an accidental mistake, plus the simulator software has already adopted the original scheme, so we are restoring the original order of bitfields in the second byte. -- The L2 DATA TYPE codes are now present in the documentation and they are exactly what the Level 2 people expect us to provide. -- In case of the L3/VRB transfers, we have new L3 DATA TYPE codes. Some of them had already been defined in the simulator. I put the complete list of codes in the current documentation for all our unique transfers to the L3/VRB readout. -- Note that there were some changes in the STOV/STSX system, nothing that is at all affecting the rest of the world, but mostly the communications between the STOV and the STSX. The latest here is now properly documented, I hope. -- For some time, we have debated about the total maximum number of objects to be sent to L2 preprocessors. We now have a consensus reflected in the protocols documentation that up to 48 tracks or clusters will be sent in all cases (i.e. from CTQDs, both L2CFT and L2CPSax data, from STSXs, from DFESs, and from FPSSs). ------------------------------------------------------------------------------ Levan Babukhadia Phone: +1-(630)-840-3105 (Work) Research Associate +1-(630)-848-1268 (Home) SUNY at Stony Brook, NY 11794. Fax: +1-(630)-840-6650 (Work) MS 357, Fermilab P.O. Box 500, E-mail: blevan@fnal.gov Batavia, IL 60510. WWW: http://www-d0.fnal.gov/~blevan ------------------------------------------------------------------------------ [ Part 2, "" Application/PDF 651KB. ] [ Unable to print this part. ]