Choose timezone
Your profile timezone:
TB: BGI hardware architecture
→
Europe/Zurich
866/2-D05 (CERN)
Description
The BGI team will present a comparison of candidate hardware architectures for the BGI project - more specifically the upcoming ATS SoC platform versus a hosted SoC solution.
The goal of this TB is for the group to endorse the selection of architecture.
TB: BGI hardware architecture
Distribution: SY-BI-Group@cern.ch
Present: S. Bart Pedersen, D. Belohrad, A. Boccardi, E. Calvo, I. Degl'Innocenti, L. Golino, S. Jackson, S. Jensen, J. Joul, T. Lefevre, T. Levens, O. Marqversen, M. Mclean, C. Pasquino, J. Storey, C. Zamantzas
Juri presented performance requirements and architectural comparisons
Mark presented comparisons of various PCIe based SoC and FPGA mezzanine modules
Actions:
1) Mark will lead the effort to specify requirements for a PCIe based "big-data" acquisition system to be provided by CEM
Decisions:
1) The BGI system will not be based on the ATS SoC module
2) Instead, standard FECs with PCIe based mezzanine modules (SoC or FPGA) will be used
3) The BGI team will select the PCIe based mezzanine module to use
4) If feasible and beneficial, BGI systems will be ported to the ATS SoM during LS3
Discussion:
Mark: The Techway module is costly, perhaps we should go for something cheaper.
Thibaut: The hardware cost is minimal compared the cost of manpower in the project, so choose what works best.
Andrea: The ATS SoM gives you all kinds of possibilities - but you have to develop a carrier board.
You could consider using a PCIe-over-fibre approach.
Tom: This sounds like a lot of development, you can buy commercial solutions.
Thibaut: We should go through the CTTB and align with agreed solutions, rather than going (too) quickly.
Mark: We can still develop during the year.
Christos: CEM should provide a PCI card for the SoM.
Thibaut: CEM have mentioned they will do this, as there are several interested users such as the ObsBox.
Mark: So we develop the software on a commercial board and wait for the CEM hardware.
=> General agreement.
James We need to have a prototype system running by the end of the year.
Thibaut: We must follow the dynamics of the sector and I will be happy to question if we need to be operational before LS3.
Otherwise we again risk doing a custom solution.
David: This could also be used for the Spill.
Thibaut: And for diamond BLMs => we need to align everything and be ready for LS3.
The current off-the-shelf solution can be seen as a prototype which can then be moved to CEM hardware in LS3.
Mark: Like this we can still be operational next year.
Thibaut: This could be OK and we have to be realistic with what we can do - we have to converge towards the CEM/CSS solution.
Andrea: We need to be present to give our requirements for new CEM hardware.
Mark: Ioan has been pushing for us to buy a commercial board.
Thibaut: We should be able to generate basic BGI specs for the working-group defining the CEM hardware specs.
For now, choose the hardware that is best for you.
Mark: We should talk to CSS - perhaps they are already using qDMA.
Our interest for now is to demonstrate the system.
Thibaut: To me, the TB should follow up to define specifications for a CEM PCIe data acquisition system ("big data acquisition").
Mark: I can follow this up.
Thibaut: Agreed. BGI can decide the hardware to use now and then move to a CEM solution during LS3.
Andrea: See also with David and Manoel about a common SoM carrier.
David: We are looking for a PCIe card and the SoM would be inconvenient due to heating/cooling issue.
If we find a PCIe with Zynq, the EDGE drivers already exist.
Andrea: Is the heating due to using the processor ?
David: Yes - you cannot turn the FPGA CPU off, even if it does nothing
Thibaut: We need to show we also have a solution for the Spill, so please join the specification effort.
This should all go through the CTTB so David, don't make a final choice now
Andrea: Are you in contact with David Nisbeth ?
Mark: Yes
Tom: I do not have any big plans for now, but the HI-LUMI BPMs (BPW acquisition) would be SoC or a PCI digitizer - the sampling rates require a full PCI board
Thibaut: There will be a CTTB for digitizers and big-data acquisition
Juri: So is the FELIX board off the table ?
Andrea: Be careful, ATLAS is the one that strays the most from agreed standards
Thibaut: This decision is not ours to make, but rather CTTB. It would mean basing a future BGI on an already obsolete module.
For now focus on the prototype and prepare good input for CTTB.
Juri: So it is agreed that we move away from ATS SoC ?
=> No objection.
Thibaut: Still do your best to provide for OP, i.e. buy the cards you need.
Mark: We would then aim for CPS and SPS, i.e. 4-8 cards including labs and LHC.
Thibaut: So with the Telescope we are looking at ~30kChF.
Andrea: The ATS SoM is aiming for a solution for Q2 this year and a carrier board (with FMC connector if several projects need it) for end 2025.
Irene They will simply use the DI/OT carrier which includes PCIe.
A bit of technical discussion followed on this topic concerning physical layer vs. protocol
Thibaut: See with David Nisbeth.
Tom: CEM does not intend to provide a SoM carrier - we need to provide one for PCI ourselves.
Thibaut: We need to launch a working group with CEM on this, thanks mark for volunteering to steer this
There are minutes attached to this event.
Show them.
