lriesebos

ok now you got me confused. as far as I am aware, there is no EEPROM on the urukul cards that can be accessed. I could be wrong here, but that is my understanding. all the EEPROM is on the kasli controller. so all of that EEPROM is accessible regardless of the cards installed.

Yes, that was also my first hypothesis, but after checking the schematics with our electrical engineer, I think only LOC0 is Kasli's EEPROM, and EEMx is the I2C buses going to the extension module connected to EEM port x.

See the attached excerpts from the schematics:



  • IC5 in the Kasli schematic is the LOC0 using the 24AA025E48 EEPROM (red)
  • SHARED_SDA and SHARED_SCL make up the I2C bus from the second I2CSwitch to the Kasli's EEPROM (green)
  • I2C_SDA_x and I2C_SCL_x make up the I2C bus going the the xth EEM extension module (orange)
  • IC8B in the Urukul schematic is the EEMx 24AA02E48 EEPROM (blue)

    Do TTL cards also have EEPROM then? because we have TTL cards in the first two EEM slots, but use the EEPROM successfully on those channels. We also have our urukuls connected with two EEM connectors, and use EEPROM chips on both EEM channels. I have not noticed any problems.

    Besides, this would also cause issues with DRTIO, because I don't think we get I2CSwitch devices on any DRTIO destinations. This is getting me really confused.

    @Pavel (assuming this is the Pawel from technosystem, Hi, hope all is going well!) sorry for dragging you in here, but do you maybe know how this works?

      Thanks sb10q , that clears up some things.

      Just wondering, do Urukuls have EEPROM chips for both EEM channels? Because that is how we are using it right now.

      @bodokaiser I have the feeling that the issues we experienced were different from yours. it might still be worth trying to map to different EEPROM chips, but your symptoms seem a bit different from mine.

          lriesebos

          Just wondering, do Urukuls have EEPROM chips for both EEM channels? Because that is how we are using it right now.

          If I am not mistaken, the pins of both EEM connectors are attached to the same nets. So one can use either EEM port to write to the same EEPROM.

          @bodokaiser I have the feeling that the issues we experienced were different from yours. it might still be worth trying to map to different EEPROM chips, but your symptoms seem a bit different from mine.

          I think our problems have some overlap but are not the same. @fsagbuya helped me get the LOC0 option working. For us this will be the new default to store DDS timing data as its invariant under the EEM module configuration of the master Kasli.

              Interesting enough, I don't see that behavior. I have an urukul connected to EEM10/11, and my DDB points both urukul 1 and 2 to those respective EEPROM ports. if I read their sync data, their values are different. @sb10q can you confirm if two EEM ports on an urukul wire to the same EEPROM or not?

              10 months later

              bodokaiser
              Do you mind sharing your implementation? We just ran into this issue (again? [1]):

              • M: Master with 2 Urukuls
              • S1: Satellite1 with 2 Urukuls
              • S2: Sattellite2 with 3 Urukuls

              Apparently, the the device DB entry for Urukul3's EEPROM in S2 got an EMM address assigned, that is not populated on M. This makes the Urukul unsuable.
              Rather than using [2] by franken-steining the EEPROMs of random cards in the M for S1/S2 Urukuls, we would love to use the the Kasli EEPROM of M (LOC0). It seems like, you went that route.
              So my question is: How did you implement it?
              And also: Does your implementation allow individual sync data (none-shared) for all Urukuls?

              [1] We have already seen sync issues on RTIO before https://github.com/m-labs/artiq/issues/1692 . But that bug uncovered also a hardware issue in the end. Disregarding the HW bug, I still think sync is broken on DRTIO with this eeprom mixup.
              [2] https://forum.m-labs.hk/d/622-eeprom-aliasing-when-using-drtio/2

                  KlausZipfel Apparently, the the device DB entry for Urukul3's EEPROM in S2 got an EMM address assigned, that is not populated on M. This makes the Urukul unsuable.

                  Sounds surprising. Did you physically check that it is not populated? Where is this card from?

                      sb10q I just checked our device configuration json file. EEM10 on the master is not populated. So satellite2 can not "frankestein" any EEPROM on EEM10 on the master for syncing the Urukul on satellite2

                      In my honest opinion, this behaviour is absolutely annoying on DRTIO setups and needs to be adressed.
                      For standalone, it the behaviour works as intended.

                        sb10q I think, the problem seems to be the way how the device DB is generated or the master/compiler intepreting it. Yes, channels are assigned correctly but I2C access is performed always locally on the master crate.

                        This is an excerpt of our master json file

                            {
	"type": "urukul",
	"ports": [3, 4],
...
	"synchronization": true
    },
    {
	"type": "urukul",
	"ports": [5, 6],
...
	"synchronization": true
    },

                        This is satellite 1 (which by chances has the same EEM ports as the Urukuls on the master)

                            {
	"type": "urukul",
	"ports": [3, 4],
...
	"synchronization": true
    },
    {
	"type": "urukul",
	"ports": [5, 6],
	}

                        And here finally satellite 2

                            {
        "type": "urukul",
        "ports": [4, 5],
...
        "synchronization": true
    },
    {
        "type": "urukul",
        "ports": [6, 7],
...
        "synchronization": true
    },
    {
        "type": "urukul",
        "ports": [10, 11],
...
        "synchronization": true
    },

                        The device db has been derived via artiq_ddb_template -s 2 yb-satellite.json -s 1 yb-satellite2.json yb-master.json > device_db_auto.py which resulted in entries like this:

                        # Master
device_db["eeprom_urukul0"] = {
    "type": "local",
    "module": "artiq.coredevice.kasli_i2c",
    "class": "KasliEEPROM",
    "arguments": {"port": "EEM3"}
}

device_db["eeprom_urukul1"] = {
...
    "arguments": {"port": "EEM5"}
}


# Satellite 1
device_db["eeprom_urukul2"] = {
    "type": "local",
    "module": "artiq.coredevice.kasli_i2c",
    "class": "KasliEEPROM",
    "arguments": {"port": "EEM3"}
}

device_db["eeprom_urukul3"] = {
...
    "arguments": {"port": "EEM5"}
}


# Satellite 2
device_db["eeprom_urukul4"] = {
    "type": "local",
    "module": "artiq.coredevice.kasli_i2c",
    "class": "KasliEEPROM",
    "arguments": {"port": "EEM4"}
}

device_db["eeprom_urukul5"] = {
...
    "arguments": {"port": "EEM6"}
}

device_db["eeprom_urukul6"] = {
...
    "arguments": {"port": "EEM10"}
}

                        Assessment

                        • Satellite 1's Urukuls access the same EEPROM as on the master.
                        • Satellite 2's first two Urukuls access an EEPROM offset by +1 on the master (which - due to how we connected the urukuls on the master - is again the masters Urukul EEPROMs).
                        • But the third Urukul on Satellite 2 now wants to access an EEPROM on EEM10 (which is not populated on the master).
                        • No satellite access the EEPROMs on the respective satellite via remote I2C

                        Since you pointed out remote I2C: It simply seems like this feature does not work as intended with the ddb above. If one could figure out, how to make this work, it would be the most elegant solution TBH.

                          Those KasliEEPROM device entries have no way to tell which satellite to access. Obviously this needs to change. Might even be the only change required.