Skip to content
Permalink
Browse files

kasli_tester: enable EEPROM for Urukul synchronization

  • Loading branch information...
sbourdeauducq committed Mar 13, 2019
1 parent 04e0c23 commit 346299e7f8532423a8f645e1210f384438d3f9b0
Showing with 9 additions and 1 deletion.
  1. +9 −1 artiq/examples/kasli_tester/device_db.py
@@ -57,6 +57,12 @@

# Urukul (EEM1) starting at RTIO channel 12
device_db.update(
eeprom_urukul0={
"type": "local",
"module": "artiq.coredevice.kasli_i2c",
"class": "KasliEEPROM",
"arguments": {"port": "EEM1"}
},
spi_urukul0={
"type": "local",
"module": "artiq.coredevice.spi2",
@@ -122,7 +128,9 @@
"pll_n": 32,
"chip_select": 4 + i,
"cpld_device": "urukul0_cpld",
"sw_device": "ttl_urukul0_sw" + str(i)
"sw_device": "ttl_urukul0_sw" + str(i),
"sync_delay_seed": "eeprom_urukul0:" + str(48 + 4*i),

This comment has been minimized.

@jordens

jordens Mar 15, 2019

Member

I have an EEPROM format that would support several use cases (identification, calibration data, tracking boards and versions, etc) including this one. THe format would give you bytes 64-127 (the second quarter of the address space, and half of the entire writable space) for board specific board_data such as these entries.
https://github.com/quartiq/kasli-i2c/blob/0a4442385971e331d81330f5555b99b35092dc60/sinara.py#L17
How about increasing the offset from 48 to 64?
I would reserve user_data for the user and not touch it in ARTIQ.

This comment has been minimized.

@sbourdeauducq

sbourdeauducq Mar 15, 2019

Author Member

Ok.

"io_update_delay": "eeprom_urukul0:" + str(48 + 4*i),
}
}

4 comments on commit 346299e

@gkasprow

This comment has been minimized.

Copy link
Collaborator

gkasprow replied Mar 15, 2019

What about using the same or compatible layout as FMC specification defines?
Here is a tool that generates such content
ADI has also some tools that support it
It would be nice to extend something already existing by the information we need.
Someday we may want to support FMC boards in MTCA or other carriers.
BTW, the simple AMC FMC Carrier is at the layout stage. It is designed with Kicad and guys from Berkley want to provide Migen support for it.

@jordens

This comment has been minimized.

Copy link
Member

jordens replied Mar 15, 2019

https://www.kernel.org/doc/Documentation/fmc/identifiers.txt regarding the usefulness and quality of that format.
Some reasons not to use that format:

  • Space. We would spend most of the space on data that we really won't need.
  • Usefulness. There is little format for what we really need, namely info about gateware versions, ports, variants, calibration data etc.
@gkasprow

This comment has been minimized.

Copy link
Collaborator

gkasprow replied Mar 15, 2019

@jordens true, there is a lot of info that is not really useful. I'm just thinking about some more general data format that could not be limited to EEM boards. At least we should add EEPROM content type ID that would indicate if the EEPROM content is compliant to EEM or something else. Something like ETHERTYPE field in IP :)

@sbourdeauducq

This comment has been minimized.

Copy link
Member Author

sbourdeauducq replied Mar 16, 2019

"IPMI is a lie I'd better not expand" 🤣 🤣

This makes me think, maybe a saner way to deal with MicroTCA is simply:

  • replace the MCH and its pile of cruft (they even put a FPGA in there) with one little STM32 and Ethernet. Maybe an integrated Ethernet switch chip if we care about in-crate Ethernet.
  • ditch crappy NATView, proprietary protocols over the network (use JSON/MQTT instead), buggy MCH firmware, crappy web interface, crappy MCH configuration files and their management, etc.
  • replace IPMI to our cards with a NIH protocol or a better existing standard.
  • just figure out the bare minimum set of IPMI commands to make the Schroff power supply and fans behave themselves.

The mechanical standard isn't too bad, only the software/firmware and the protocols are really awful...

Please sign in to comment.
You can’t perform that action at this time.