StarEmu: hccID=0b1111 by default in dynamic addressing

Added a new Emu controller parameter addressingModeDynamic=true|false and the corresponding m_addressing_mode_dynamic in StarChipsetEmu. It defines whether the emulator constructor sets the HCC ID to 0b1111 in the StarCfg, or leaves it to the value that is defined in the json config file, as if it is set by the bonds-pads.

modified:   src/libStarEmu/StarChipsetEmu.cpp
modified:   src/libStarEmu/StarEmu.cpp
modified:   src/libStarEmu/include/StarChipsetEmu.h
modified:   src/libStarEmu/include/StarEmu.h

mentioned in issue #199 (closed)

Let me check what's up with the address==Addressing branch, and we can merge it.

mentioned in merge request !665 (merged)

added 6 commits

• 53b7045e...4a476a51 - 3 commits from branch YARR:star_read_fuse_id
• 45561c32 - StarEmu: hccID=0b1111 by default in dynamic addressing
• eac619c4 - Final corrections
• 7960931b - Now it's all

Compare with previous version

It works, but there is 1 unsolved caveat: HccCfg::setDefaults sets the addressing register value with the current hccID, not some default like 0b1111:

uint32_t addressing_value = ((m_hccID & 0xf) << 28) | (m_fuseID & 0xffffff);

It is not the expected behavior, so may create a problem in some cases.

added 1 commit

• aac89fa0 - StarEmu test a basic comfig with dynamicAddressing false

Compare with previous version

No idea why the emu tests stopped passing. The first failing test that expects zeroes from register 11 actually gets 3|c followed by zeroes. Not sure how this can be connected with the hccID or fuseID.

The other thing to think about is the fuse ID. Some options:

• Set based on counter (first to be created gets 0, next gets 1)
• Random number
• Hash of counter
• Something I've not thought of

We want something that's different each time so the ID can be set, but also predictable enough for unit tests.

Aha, so fuse_id could go in the emulator configuration file!

my idea was to take the HCC ID and fuse ID from the chipCfg in the emulator config. There are a number of constructors and loadConfigs at play, so it was not clear where is the right place to modify.

StarCfg::m_fuse_id is set from the FE config file by StarCfg::loadConfig. Which is called in StarEmu constructor before calling StarEmuChipset. So, by the time of the chipset constructor the fuse ID must be valid.

Note that it's possible to have a different HCC ID and fuse ID for the StarCfg and for the emulator config.

yes, the emulator can have a different file in its json chipCfg. Then the scan may not receive any data. But that's correct behavior.

changed this line in version 9 of the diff

Catching up with the comments in #199 (closed), I think we need to think about IDs (where they come from in config, how they get set normally vs in emulator).

So, I think I agree with @ztao that addressingModeDynamic is not needed. You can set ID to 0b1111 in the constructor and then let dynamic addressing take over. But, we do need a way to set the fuse ID for the emulator (so they can be different and therefore make the ID settable).

but do we want the emulator to implement the bonds addressing mode?

Now it just takes the fuseID and hccID from the chip config file. Then, if the emulator addressingModeDynamic=true, it sets the hccID to 0xf. StarEmuChipset::writeRegister also tests for address == Addressing && m_addressingModeDynamic. So, if the dynamic mode is false, it behaves like the bond addressing mode, with hccID taken from the chip config file.

Does it work to just skip the ID from the config file for that case?

The point is that the HCC doesn't have different modes, so the same logic should still work.

At some point we need to do something like the "auto ID" that ITSDAQ does, but that might be less important in the short term when testing Staves/Petals that have HCC IDs set differently.

My understanding is when the emulator's m_starCfg gets its HCC ID (as well as fuse id) from a json file (default_star.json for example), it is more or less equivalent to an actual chip getting its ID from the bond pad. The initial HCC ID stored as the top 4 bits of the Addressing register does not have to be 0xf for the dynamic addressing to work, therefore not necessary to have a flag addressingModeDynamic to set the HCC ID when loading the config in the emulator's constructor. When we would like to set the HCC ID of the (emulated) front end to a different value, we can send a broadcast HCC register write to the Addressing register with the value (new_4bit_id << 28) + (24bit_fuse_id_of_the_target_hcc), and only the HCC with the matching fuse id will react to the broadcast register write command.

The dynamic addressing did not work with the emulator previously because the emulated HCCs did not have their unique fuse ids or serial numbers set in each m_starCfg, even though the logic is implemented already in StarChipsetEmu::writeRegister.

Maybe I am missing something here, but I think that without the initial hccID=0xf in the dynamic mode, the emulator does not behave correctly. If the emulator always gets the hccID from the config file, even without the user calling StarChips::setHccId, the emulator will work when the real chip does not.

That is the situation in the current devel branch: the emulator works when the real chips do not. Without Bruce's star_read_fuse_id, StarChips::configure() never calls StarChips::setHccId because m_sn is not set. So the real chips never get their hccID set and do not respond to the writeRegister with the config. But the emulator does not need setHccId because its hccID is already set from the file.

Yeah, since we have corrected the StarCfg::loadConfig to have the fuse_id/serialnumber, the real chips are configured correctly now. But the emulator behavior is still wrong. The emulator just always works. It does not need the address==Addressing branch to be ever executed, that's why the bit-match to 0xfff passed unnoticed.

When we would like to set the HCC ID of the (emulated) front end to a different value, we can send a broadcast HCC register write to the Addressing register with the value (new_4bit_id << 28) + (24bit_fuse_id_of_the_target_hcc), and only the HCC with the matching fuse id will react to the broadcast register write command.

But if we do not set the emulator HCC ID, the emulator still accepts all register writes, because its HCC ID is already set from the file.

Again, maybe I am missing something, and this logic can indeed be done without an explicit dynamicMode flag.

Maybe I am missing something here, but I think that without the initial hccID=0xf in the dynamic mode, the emulator does not behave correctly. If the emulator always gets the hccID from the config file, even without the user calling StarChips::setHccId, the emulator will work when the real chip does not.

The reason why the emulator would always work without calling StarChips::setHccId is the emulator m_starCfg by default uses the same config json file (default_star.json) as what is used in the connectivity config. Therefore, the HCC ID in the emulator is already set up correctly in the sense that it matches what is described in the StarCfg of the front ends for the scanConsole. While with a real chip, the HCC ID before configuring may not necessarily be the same as what in the connectivity config, and we need to set the ID using StarChips::setHccId. We could use a different default chip config for the emulator, or as Bruce suggested above, we could always set the HCC ID to a default 0x0 or 0xf and ignore the ID in the chip config when constructing the emulator to make it more realistic.

But if we do not set the emulator HCC ID, the emulator still accepts all register writes, because its HCC ID is already set from the file.

The emulator should only get some initial HCC ID from the config (or alternatively always default to 0xf, but we'll have to update the test accordingly). The emulator should only accept register commands that match to its ID or broadcast commands and ignore others (if this is not the case, we probably have a bug somewhere.) What initial HCC ID the emulator has shouldn't matter as long as we always configure the front-end IDs via StarChips::setHccId before running tests/scans, after which the (emulated) front ends should have the same 4-bit IDs as what we specify in the connectivity config.

My preference would be keeping the possibility to set the emulator's HCC ID directly from the json config for convenience (kind of like setting the real chip IDs via bond pad), assigning a unique fuse id to each emulated HCC via StarCfg, and ensuring StarChips::setHccId work correctly for the emulator via dynamic addressing.

What you are saying is that if we set hccID=0xf in the emulator json config, then it implicitly behaves like a "dynamic addressing" mode, and if it is set to anything else, then it is implicitly "bonds addressing" mode. In this case the user has to always keep in mind that the emulator has to run on a different chip config file (with hccID=0xf) than the real chips and the scan configs (with some hccID=2), instead of just running on the same chip config file + adding the "dynamicAddressing" in the emulator config.

Indeed, yes, it works fine like that.

But, I would only say that it is error-prone, as the user has to know implicit rules or read somewhere that the emulator has to be configured with a different chip config file. We killed multiple months in SR1 trying to find why the devel branch cannot configure the chips. And at the end I stumbled on the m_sn absolutely randomly.

In this case, it is probably indeed better to make the default hccID=0xf and forget about the "bonds addressing" and the hccID in the emulator chip config. It seems like the most robust compromise.

What you are saying is that if we set hccID=0xf in the emulator json config, then it implicitly behaves like a "dynamic addressing" mode, and if it is set to anything else, then it is implicitly "bonds addressing" mode.

Not really. I guess the confusion might be that I suppose there is not really a "dynamic addressing mode" v.s. "bonds addressing mode" for HCCStar. My understanding is that the HCC can get its ID from bond pad after power-up or hard reset, and its 4-bit ID can always be modified later to something else via dynamic addressing.

If I understand correctly the issue before was the emulator wasn't able to catch the problem/bug on configuring HCC IDs. I believe this is due to the lack of fuse id (should be fixed by Bruce's MR) as well as due to the lack of dedicated unit test (should be added in this MR). What initial HCC ID the emulator picked up, either from the json config or some default value, should not matter much as long as we set up a test for dynamic addressing properly.

Indeed it's the lack of failure when the fuse id was not set.

Yes, we can add a unit test:

1. a new emulator
2. no writeRegister to the Addressing register
3. reads & writes must fail

This test would work when the default hccID is 0xf.

I think bool addressingModeDynamic emulator parameter registers 1 external fact: whether the bond pads are set on the emulated chips or no. And I don't see a clean way to derive this fact from the chip config file alone, unless you make assumptions of what the chip config means for the emulator and for the scan. In case of scan, it means what the user sends to the chip. In case of the emulator, the same thing means what the emulated chip gets on "power up". (It is not a problem for fuseID, because the user never "sends fuseID".) Maybe with some explanation of the emulator configs, these assumptions are fine. An additional parameter would just make it more explicit, and there wouldn't be a need to duplicate the chip config files just for the emulator.

In principle, since the emulator uses only the fuseID and hccID from its chip config file, then maybe it could have a completely different reduced chip config file format. That would make it more explicit.

Originally, I thought that when the emulator loads its chip config file, it uses all the other parameters like ADCS1, BVREF etc to emulate the data. So, you could "reconstruct" the emulator config by running an analysis over its response. But if that's not in the plans, and we use the chip configs only for the IDs in the emulator, then it could make sense to make it explicit in the format of the emulator chip configs.

Oh Ok I think I understand better what you meant. Regarding the bond pads, my thought was if the HCC ID field is provided in the json config to construct the emulator, its ID is set via the bond bad; if the json config does not include an explicit ID field for the emulator, the ID is not set and should take the default from the StarCfg. But in either case, we should still be able to modify the HCC IDs later via dynamic addressing.

The emulator does react accordingly to some other registers besides the IDs, mostly for ABCs e.g. LATENCY, ENCOUNT, LP_ENABLE, etc., but also TESTHPR, STOPHPR for both ABC and HCC, so it is convenient to just use StarCfg.

Note, the only thing (that survive the reset) read from the controller's "chipCfg" is tx/rx and some HCC/ABC IDs (which come from the chip config files).

It might simplify things to drop the "chipCfg" loading from file, and instead have some basic patterns:

• Dynamically create (when enabled/configured by TxCore) FEs with HCC ID/fuse ID based on rx position (either only one tx, or one tx per rx). In most cases you can pretend to have 11 ABCs behind each HCC and they'll be enabled as appropriate by HCC ICenable.
• Petal geometry
• Stave geometry
• Maybe something more configurable is needed for the unit tests

But that's probably not this merge request. Maybe addressingModeDynamic could just become initialHCCID?

added 1 commit

• 14ded5a5 - Corrected the StarEmu test to pass dynamic addressing

Compare with previous version

added 1 commit

• 0a9d65bb - Moved the fuseID and Addressing reg logic to EmuChipset

Compare with previous version

added 1 commit

• 0c2d822a - Forgot to check the dynamic addressing mode in Emu writeRegister

Compare with previous version

added 1 commit

• ac1965e0 - Test changing hccID

Compare with previous version

I should add a test for the bonds addressing.

added 1 commit

• daeb59d4 - Default m_hccID=0 and test the emu bonds addressing

Compare with previous version

the test_emulator.cpp has ^M line endings, unlike other files.

yeah it was inherited from the original test file. No objection from me in case you would like to fix that.