l1calo fw meeting progress and plans: fex atca hub€¦ · 11/08/2016 · l1calo fw meeting...
TRANSCRIPT
L1Calo FW Meeting
Progress and Plans:
FEX ATCA Hub
Dan Edmunds, Yuri Ermoline
Brian Ferguson, Wade Fisher,
Philippe Laurens, Pawel Plucinski
11 August 2016
Overview of Efforts
2
Three primary categories of current efforts • Firmware to support operation of production Hub modules
• Firmware to support prototype Hub commissioning / testing, ROD+Hub
tests, etc.
• Studies/tests of Ultrascale FPGA MGT usage
Firmware to support Hub operations
3
Primary list of FW modules remains the same as reported in June • Interface to FEX/ROD data
• Includes Hub→FEX/ROD transmission and FEX/ROD→Hub transmission
• GBT/TTC Interface • Clock recovery and TTC decoding, merging of L1Calo-specific signals
• IPbus / Gb Ethernet • IPbus implementation on Hub FPGA, communication/control interfaces to switch
• IPMC Interface • A bit of an unknown for now, but expect some I2C management to be needed
Preliminary work plan to develop preliminary versions of required
functionality to support Hub commissioning • Some areas are better understood, so focusing on unknowns for now
• Eg, Ultrascale/Aurora questions
• But some questions remain and need L1Calo input • Eg, FEX→ROD data protocol
Ongoing Studies
4
Ultrascale-specific tests • We’ve discovered that the Ultrascale GTY transceivers cannot be configured in
Aurora 8b/10b protocol • Aurora 64b/66b is OK, but there is an additional overhead when using GTY
• Seems to be related to the GTY transceiver, so tests are underway to characterize
any apparent differences between GTH/GTY usage.
• In any case, we strongly prefer 8b/10b encoding so a solution is needed.
• Worries about Xilinx power estimation represented a significant delay, but this
seems largely resolved (hopefully) • DC/DC rail supplies will be tested in further detail on the Hub prototype.
IPbus interface • The Hub switch/FPGA interface represents considerable complexity, so this
has begun earlier than other efforts. • Current implementation of IPbus on Virtex-7 development board,
• Migration from ISE to Vivado underway (follows what Ed has been working with),
• Then transition to Virtex Ultrascale development board implementation.
Firmware to support Hub commissioning
5
Hub-only tests • We are planning optical and electrical data transmission tests
• Only a few MGTs can be accessed, but still useful
• IBERT and user-data transmission planned: but would be best if we can implement
a protocol as close as possible to what we will use for FEX→ROD
• Hopefully this is something that can be defined soon
• I2C board monitoring tools should be standard or at least common in L1Calo
• Prototype IPbus/GbE interfaces should look very much like the final version • Switch should work without Hub FPGA FW for initial tests
Hub+ROD Tests • This should look a lot like the Hub-only tests
• Access to a few more MGTs + HPIO lines: optical/electrical communications
• Careful focus here on ROD power load, supply stability
• Hub+ROD I2C interface, “via Hub” ROD access points
• Need to discuss in more detail with Ed
Some Outstanding Questions
6
IPMC I2C monitoring • We expect that the IPMC will gather monitoring information from targets on the
various modules. How should this info be handled? • If there is a IPMC→Shelf Manager→DCS path, where will the data→engineering
unit conversion occur? Stored in some database?
• Or should the conversion somehow occur on the module itself?
External I2C management • There may be targets on the I2C bus that require some degree of
management. For example, power supplies with a PMBus interface • If there is an allowed path of IPBus→FPGA→I2CBus→Target, do we have a means
to suspend the IPMC as I2CBus master?
• Following the PMBus example, are we allowed to manage power supplies or are
such configurations required to be “fixed”. E.g., trimming of DC voltage levels.
Common IPBus/I2C firmware • If we envision IPBus→FPGA→I2CBus communication, we should have
common conversion firmware. Is this on the list of L1Calo common FW?
A few notes
7
FEX→ROD data protocol should be chosen soon • Good to avoid building a throw-away version for Hub testing
IPMC remains a concern • We could use some advice on what to expect as a function of time to help drive
our plans
We need a meeting to discuss ROD+Hub test plans • We assume we’ll send a Hub to Cambridge, and a ROD to MSU. True?
• What FW does Cambridge/MSU need from MSU/Cambridge to support tests?
• Etc.
Extra Details on Firmware Plans
8
Firmware Modules
9
Firmware Modules
10 FEX Hub Module, 09 Feb 2016
Note: this is a description of what’s planned, not a prioritized list • Short- / medium- / long-term milestones are identified and evolving.
• Matching prioritizations with Hub module status/needs with preliminary versions of
FW is happening in parallel.
Firmware Modules: FEX/ROD Data
11
Several, inter-related FEX/ROD data signals to be handled • FEX data to Hub, ROD data to Hub, Hub-1 data to Hub-2 (& vice versa)
• Lower priority in early efforts**, expect to have significant overlap with ROD firmware • ** Current focus on this area to understand Aurora channel bonding requirements,
clocking limitations, etc. Though not required for early prototype tests, still being pushed.
Also required to validate Hub PCB design.
FEX Hub Module, 07 June 2016
Firmware Modules: GBT/TTC
12
Clock and Combined-Data distribution/processing • Clock recovery and distribution to FEX/ROD modules
• Decode GBT “TTC” payload from FELIX and merge with ROD/Hub back-pressure,
distribute to FEX modules
• Clock distribution in early system is essential. • Clock-source logic embedded (GBT vs crystal), so task is just distribution
• Combined data protocol to be defined
• Modifications of example designs produced/tested
Firmware Modules: IPBus/GbE
13
GbE network operation and Hub FPGA interface • On-startup configuration/setup of GbE network is an early high priority
• Interfaces to Hub FPGA may be numerous, but include: nominal communications (as
with any other module), network monitoring, configuration management.
• Early firmware work has focused on the GbE interface • Implementation, configuration, management
• Not starting from scratch (examples exist) and maintaining contact with other L1Calo
firmware engineers.
Firmware Modules: IPMC
14
Interface and communication with IPMC • Access to core IPMC functionality: geographical addressing, etc
• Still-undefined communication options (see previous slide)
• Eg: “Line-clear” signal for asserting I2C bus master status?
• Beyond what’s known now, not well defined • Beyond core functions, not much is required for early commissioning
• We will need to get more sophisticated in our overall understanding of the IPMC functions
FEX Hub Module, 07 June 2016
Firmware Modules: Other
15
Minipods, LEDs, front panel, etc • Requirements for optical interfaces will evolve over time, but optical communication will
likely be useful in Hub commissioning
• Front panel/LED functions are a high priority
• To proceed as other core Hub functions are developed • These are well-defined and largely not novel or specific to the Hub module
FEX Hub Module, 07 June 2016