gen_edge3: implement LIF, device ident and resource tables
Finish the implementation of the hardware-module, identification and resource tables.
Hardware module table
https://be-cem-edl.web.cern.ch/EDGE/v3.0.0/edge-schema.html#hardware-module-csv-table
From what I can see reksio's code generator:
hw-mod-name: module-type
hw-lif-name: board-type
hw-lif-vers: driver-version, driver-version-suffix
edge-vers: schema-version
bus: bus-type (VME/PCI)
endian: endianness (big/little)
If not present:
-
endianness
isbig
for VME,little
otherwise (ref) -
board-type
ismodule-type.lower()
I would propose to make module-type
the cheby map name if not present.
Identification table
https://be-cem-edl.web.cern.ch/EDGE/v3.0.0/edge-schema.html#identification-csv-table
reksio defines:
x-driver-edge:
pci-device-info:
vendor-id: 0x1234
device-id: 0x1234
subvendor-id: 0x1234 (optional)
subdevice-id: 0x1234 (optional)
Which is fine for PCI. But VME64x/PLATFORM need a similar structure. Two options I can see:
- Define separate
pci-device-info
,vme64x-device-info
andplatform-device-info
. - Replace
pci-device-info
by a more genericdevice-info
which covers all busses.
Resource table
https://be-cem-edl.web.cern.ch/EDGE/v3.0.0/edge-schema.html#resource-csv-table
In reksio this is pretty much hardcoded for VME/PCI based on the memory map size:
I think that the address width is somehow determined automatically based on the bus type. But there seems to be no way to override this, so it is probably not generic enough to cover all VME use cases.
For PCI specifically it is possible to define extra BARs:
x-driver-edge:
pci-bars:
- pci-bar:
name: bar1
number: 1
- pci-bar:
name: bar4
number: 4
and then on a block you can define:
x-driver-edge:
pci-bar-name: bar4
Again we have the same choices as for the identification table.