It does something. (no flash emulation yet, just providing a clock / reset).

That's typical of the response I would get from the processor. I could get it to run longer by finding just the right "sweet spot" for the 1.8V supply (which often had to be just right, and would fail if I moved it by 0.01V). But the "sweet spot" wasn't enough to overcome all of the hold violations in the processor. With a special start.s assembly routine, I managed to get it to run a trivially simple program indefinitely, but I was never able to get it to run any actual useful program. Attempting to write to a memory-mapped register (almost) always ended in failure.

So ... it's possible to actually get IOs configured. I got ... one.

@User: The dedicated "gpio" pin for the management SoC is the only one I could get to work at all as an output. The other GPIOs have to be configured by the serial loader, and the serial loader has some of the worst clock skew violations on the chip. I can, under some conditions, load the serial register, but either it won't trigger the load signal to transfer the data, or else the counter for the serial load won't stop. The user project GPIOs are configured as management-controlled inputs on power-up, and are most likely never to be able to be configured as anything else. Recognizing that this was a massive single-point failure on the chip, we designed the chip from MPW-two to have multiple ways around this point of failure, including (1) the ability to configure all the GPIOs to power up in a specific user-defined state (from MPW-four), (2) the ability to manually bit-bang the serial load if needed, and (3) the ability to run the serial loader from the housekeeping SPI in addition to the management SoC.

Ah, I got one of my IO configured. Only one and that was probably dumb luck, but it started outputting the signal I'd expect out of it ( just a 50% square wave, it's the output of a PDM modulator which is by default at mid-point ).

Okay, that last bit is unfortunate, but I'm wondering how you got one I/O configured. The serial loader works by being triggered from software, and initiates a load of data into the shift register running around the padframe. At the end of shifting in 13 * 38 bits, it initiates a load which copies data from the shift registers into the I/O control blocks. I have never been able to get the load to work, and have confirmed through timing analysis that there is a hold violation of several nanoseconds on that line, making it seemingly impossible to ever trigger it. But I also had a sample size of one on my desk, and I have not simulated under every possible PVT condition (and I don't know what "P" would be for my chip, anyway, or how much chip-to-chip variation there is). So it's always possible that the load signal can pulse correctly. But then I would expect either all of the I/O to work, or none. There's a possibility that there's a hold violation in the serial chain, so that the configuration data are systematically wrong, in which case behavior would depend on what bits ended up in the output enable and the user enable registers for each I/O. However, if the data are really systematically wrong, then it may be possible to set the configuration values so that they end up right after the serial load. Since I never got the serial load to work, I never got to that point.

It definitely didn't load the config I asked for ... since I tried configuring all my IOs and only one got the expected output. Although most of the others, it's hard to know since they don't do anything, but at least the one right next to it should be the same ( it's a left/right audio output circuit ) and that one wasn't working. But it was working consistently , powered at around 1.35v and the spi fetch seemed to confirm proper execution flow as well.

@User: Which I/O is that?

IO18

I can't see anything special about IO17 (or 18, for that matter). It's in the middle of the serial load chain. Startup behavior is for the pad to be configured as output but with OEB = 1, so the output buffer is disabled. So it seems that the serial load completed and latched. I never got any evidence on the bench that the latching of the shift register data occurred, and I couldn't get it to work in simulation, either (but the timing is very sensitive to conditions and so I've only ever been able to get "qualitatively similar" results from simulation).

I'm actually starting to wonder if the write to the config register isn't what's failing.

I had my chip in one state where writing to a config register would cause the whole chip to reset.

Is the managemtn UART IO initialized by default to a good state ?

All of the I/O except for the management housekeeping SPI are initialized to the same state, which is: configured as an output, tristated, and with an active input buffer. So the Rx line should be good, but the Tx line won't signal unless OEB is flipped in the configuration.

What's weird is I need to write to 2600006c to configure IO 17 which huh ... I don't explain.

That could be explained by hold violations in the data along the serial chain. If there was a hold violation at the start of each GPIO configuration block, then a bit might clock into the next block 1 cycle early. Just thinking out loud here---not sure if that works out or not.

Yeah, that's probably something like that. in addition to loading 0x1808 to IO19 ( 2600006c ), I set IO20 and IO18 to 0x0000 .. it doesn't work.

I thought about that possibility and decided it would be a pain to figure out, but since I couldn't get the serial load to latch, I never got to that point anyway.

What's the default value of those register ?

Yes, that's correct.

😩 Of course that would have been too simple. Turns out I can write 0 or anything to 2600006c, that doesn't seem to matter. I need to write to it for it to work, but it doesn't seem to matter what value I write.

More than I managed to get working!