|
|
* Status: common data structure to hold information about the memory map is agreed. See https://gitlab.cern.ch/Cheburashka/PyCheb (ppluteck branch, which will soon be merged into the devlopment branch). This allows different file formats to be used, by writing appropriate import/export functions to/from the Python object. Tristan has started
|
|
|
working on HDL generation. Bartek and Przemek have worked on driver generation (C++ wrapper and simulation of hardware) and FESA generation.
|
|
|
* John reminds us that the low-latency CO-RF bus needs to be supported in addition to Wishbone.
|
|
|
* Regarding file formats, there is agreement that the data structure is more fundamental than the files themselves, and that having different file formats poses no big maintenance problem, so supporting XML, YAML and JSON is fine for everybody.
|
|
|
* Export to CCDB: it is agreed that having a single source of truth for the memory maps is a good idea. Currently, this role is played by text files. In the future, it could well be the CCDB (with a two-way method to go from/to Cheby files). There is concern that the CCDB might not be expressive enough to maintain all the information currently held in the files. Lukasz proposes a staged approach, uploading full files to CCDB
|
|
|
in a first phase and working towards a more structured database later on. To be followed.
|
|
|
* Action: Michel should discuss with Bartek and Przemek to see how to integrate into EDGE (the new Encore) features which are useful and requested by several groups such as HW simulation, both for VME and PCI/PCIe. He should also see if, in the C++ wrapper idea of RF, there is part which can be factored out and provided as a service for all users
|
|
|
of EDGE. See https://gitlab.cern.ch/Cheburashka/Meta/driver-wrapper-proposal (if you
|
|
|
have access).
|
|
|
* Action: Tristan needs to migrate his HDL generation work to use the agreed Python data structure and not work directly from the YAML file.
|
|
|
* Regarding reuse of Gena code vs developing HDL generation from scratch, the decision lies with Tristan. He commits to supporting all Gena features but fears that wbgen concepts might be difficult to fit into the existing Gena code base. In any case, he commits to having a solution which can be tested by the end of June.
|
|
|
* Action: Tristan should discuss with Anthony to see how and when the necessary work on the GUI can happen.
|
|
|
* FESA generation: there is a phase 1 when Bartek and Przemek will continue generating XML directly. This is part of the first release of Cheby (expected end of October 2018). Some time later, Fred intends to provide a Python API to generate FESA classes programmatically, which he believes is a more future-proof solution. The migration of the FESA generation code to that paradigm can be discussed when the API becomes
|
|
|
available.
|
|
|
* Generally speaking, the schedule we had foreseen until October does not look compromised. |
|
|
\ No newline at end of file |