Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • C cmsgemos
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 100
    • Issues 100
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • cmsgemonline
  • gem-daq
  • cmsgemos
  • Issues
  • #129
Closed
Open
Created Oct 25, 2020 by Laurent Petre@lpetreOwner

Produce configuration blobs for the blaster

Summary

Although no database is currently implemented, the configuration to be applied to the front-end is stored in text files on the back-end board (inside /mnt/persistent/gempro/etc/gem). The blaster data format is defined and documented and the block ram (BRAM) memory to be used is already exposed through registers in the back-end firmware address table.

The blob objects could be produced based on the information contained into those configuration text files and pushed to the BRAM.

What is the expected correct behavior?

Write a function that produces the blaster blobs for the different front-end components:

  1. GBTx from /mnt/persistent/gempro/etc/gem/gbt/config_OHn_GBTm.cfg
  2. VFAT from /mnt/persistent/gempro/etc/gem/vfat/config_OHn_VFATm.cfg
  3. OptoHybrid from ...
Edited Oct 25, 2020 by Laurent Petre
Assignee
Assign to
Time tracking