I dont care about the management pins and the management core does not need to do anything, I just need to enable the pins as all input. Even all digital input would probably work if I dont care about the power burnt in the input buffer with analog signals.

I am unclear on the register writes required to configure GPIO values at all though

reg_mprj_xfer seems to be some register you write 1 to shift out the GPIO configuration data? Its not labeled as such in the memory map

It looks like writing reg_mprj_datal and reg_mprj_datah sets the output value for all pins though?

But yes, you need to apply a "1" to the low bit of the transfer register to copy the configuration from the memory mapped location to the GPIOs around the padframe. But the datal and datah values are directly connected to the I/O pads and get applied (or read) immediately.

reg_mprj_datal is GPIO 31 to 0, and reg_mprj_datah is GPIO 37 to 32 (only the lower 6 bits are meaningful).

Also, there is the whole GPIO_MODE_MGMT vs GPIO_MODE_USER distinction

If I am understanding things correctly, I set the reg_mprj_io_x value for each pin. Then I write one to reg_mprj_xfer and it shifts everything out?

And for reg_mprj_io_1 - reg_mprj_io_4 only the user/mgmt bit is flipped?

And for the right side (reg_mprj_io_1 - reg_mprj_io_13) the clock is still off, so bits may "slip" where an bit in the chain is lost. So for the higher order pins its likely that everything gets shifted 1 or more bits to the right?

But the left side of the chip is fine?

Although the one chip I looked at does happen to be a copy of your design. If I can get over my soldering issue, then I can help you more directly with your testing.

Also, sorry for all the questions, but this memory map does not seem to match https://github.com/efabless/caravel/blob/mpw-2b/docs/source/gpio.rst#user-project-area-gpio-mprj_io370-configure-registers

its missing the reg_mprj_datal and reg_mprj_datah registers

so everything is shifted

The known-good memory mapping is the defs.h file, or in the case of your ChipIgnite run, the modified defs.h file (which only differs in the bit definitions for the GPIO configuration).

I'll try to get in a pull requiest with the updated/corrected register mapping.

and the groups that are shifted out are the left side and the right side independently?

And I assume that the furthest GPIO on each side from the core is the last one?

and the clock tree can cause dropped bits.

And yes, the configuration bits are loaded into one long serial chain. Two chains, actually, one on the right side and one one the left, which is how it's possible for one side to work correctly and the other side not to

My right side of the chip is only digital input. And by digital inputs I mean its all just pin strapping.

If the pin is assigned to management will the user project still be able to read the I/O state?

And if its a digital output and I write a value will that value get read by the input buffer?

Yes, the user project should be able to read an input bit when the GPIO is configured for management control.

Also, Jeff said "if you need IO from the management area - we have been able to successfully configure IOs 19 - 37 using a slower clock of 5 MHz"?

which makes sense if its a hold issue. Worth trying? I can drive the clock from my function gen

Actually, I had no problem at all programming the left side I/Os at the original 10MHz. Note that hold violations are (usually) not solved by slowing down the clock. Only setup violations are. The left side configuration had the clocks arranged in such a way that it is immune to hold violations, but the slack margin got cut down so that it raised the possibility of a setup violation. I didn't see that on my chip on the bench, but Jeff was seeing it and could work around it by slowing the clock down.

Personally, I have difficulty believing that the arrangement of clock signals cut the timing margin by so much that it won't work at 10MHz, but that's apparently what Jeff was seeing on the bench.

but if I am careful with the timing I can power cycle the board right after the erase prompt appears, which actually causes the flash to be erased. And then I can load new firmware

I guess I can just work around this by using an external flash programmer though

Im not that familiar with the flash, but I seems that the flash status registers are indicating something is wrong? Here is a good flash after a power cycle erase, and here is a flash attempt after that:

status reg_1 = 0x0
status reg_2 = 0xff
************************************
verifying...
************************************
status reg_1 = 0x0
status reg_2 = 0x2
setting address to 0x0
addr 0x0: read compare successful
addr 0x100: read compare successful
addr 0x200: read compare successful
addr 0x300: read compare successful

total_bytes = 1016
pll_trim = b'00'



subsequent flash


python3 ../util/caravel_hkflash.py blink.hex
Success: Found one matching FTDI device at <ftdi://ftdi:232>h:1:13/1
 
Caravel data:
   mfg        = 0456
   product    = 10
   project ID = 00000000
 
Resetting Flash...
status = 0x00
 
JEDEC = b'ef4016'
Erasing chip...
done
status = 0x0
setting address to 0x0
addr 0x0: flash page write successful
addr 0x100: flash page write successful
addr 0x200: flash page write successful
addr 0x300: flash page write successful

total_bytes = 1024
status reg_1 = 0x0
status reg_2 = 0x2
************************************
verifying...
************************************
status reg_1 = 0x0
status reg_2 = 0x2
setting address to 0x0
addr 0x0: *** read compare FAILED ***
b'930000009301000013020000930200001303000093030000130400009304000013050000930500001306000093060000130700009307000013080000930800001309000093090000130a0000930a0000130b0000930b0000130c0000930c0000130d0000930d0000130e0000930e0000130f0000930f00001705000013058538970500f1938505f8170600f1130686f763dcc5008326050023a0d5001305450093854500e3c8c5fe170500f1130585f5970500f1938505f56358b5002320050013054500e34cb5feef00400b6f000000b70200281303001223906200a381020063080602130f80009373f60f93de73002380d20193ee0e012380d20193931300'
<----->
b'930000009301000013020000930200001303000093030000130400009304000013050000930500001306000093060000130700009307000013080000930800001309000093090000130a0000930a0000130b0000930b0000130c0000930c0000130d0000930d0000130e0000930e0000130f0000930f00001705000013050538970500f1938505f8170600f1130686f763dcc5008326050023a0d5001305450093854500e3c8c5fe170500f1130585f5970500f1938505f56358b5002320050013054500e34cb5feef00400b6f000000b70200281303001223906200a381020063080602130f80009373f60f93de73002380d20193ee0e012380d20193931300'
addr 0x100: read compare successful
addr 0x200: read compare successful
addr 0x300: *** read compare FAILED ***
b'372700001307878023a0e700b70700269387c70023a00700b70700261307100023a0e70013000000b707002603a7070093071000e30af7feb70700219387470023a00700b70700219387870023a00700b70700219387c70023a00700b70700211307100023a0e700b707002123a00700b70700269387c70023a00700b70700269387070123a00700232604fe6f0000018327c4fe938717002326f4fe0327c4feb7170000938777bbe3d4e7feb70700211307100023a0e700b70700269387c7003707ffff23a0e700b7070026938707011307f0ff23a0e700232604fe6f0000018327c4fe938717002326f4fe0327c4feb7170000938777bbe3d4e7fe6ff0dff6'
<----->
b'372700001307878023a0e700b70700269387c70023a00700b70700261307100023a0e70013000000b707002603a7070093071000e30af7feb70700219387470023a00700b70700219387870023a00700b70700219387c70023a00700b70700211307100023a0e700b707002123a00700b70700269387c70023a00700b70700269387070123a00700232604fe6f0000018327c4fe938717002326f4fe0327c4fe9307b012e3d6e7feb70700211307100023a0e700b70700269387c7003707ffff23a0e700b7070026938707011307f0ff23a0e700232604fe6f0000018327c4fe938717002326f4fe0327c4fe9307b012e3d6e7fe6ff05ff7ffffffffffffffff'

total_bytes = 1024
pll_trim = b'00'

1. For the working flash it has a status of 0x00 after erasing, status reg_1 = 0xff, status reg_2 = 0xff, after programming. And fails on verify. the program just halts.

On the follow up flash (same hex file) status = 0xff after erasing, status reg_1 = 0x0, status reg_2 = 0xff after programming, status reg_1 = 0x0 status reg_2 = 0x2 on verify. Verify is sucessful because its verifying the previous bitstream.

trying to flash a new hex file without corrupting the flash contents after that has a status of 0x00 after erasing, 0x0 status reg_2 = 0x2 after programming, and 0x0 status reg_2 = 0x2 when verifying. It then fails verify

If the status registers read 0xff, though, it's a sign that the flash chip is no longer responding to anything (or is not receiving the commands).

I guess I could try holding reset down before plugging in the board

I added a long delay before configuration though. And if I start programming before that everything works

So im going to declare this not solved but work'ed around and no longer a pressing issue.

Also, I got the first signs of life 🙂 https://twitter.com/WestonBraun/status/1488989735875796994

Also: Thansks for all the feedback, and great work getting something up and running (it always takes me at least one day before anything works).

I added a long delay (~5 seconds) at the start of my program before GPIO configuration (the write to reg_mprj_xfer) which allows me to start the programming before it configured

Now that I think about it, perhaps another workaround would be to hold the reset button before you apply power to the board.

It seems that the reset button does not restore the power on GPIO configuration

(Okay, posted that at the same time, but sounds like we have arrived at the same conclusion.)

/ it actually seems to be programming

I just flashed

//left side GPIO, bottom to top 
   reg_mprj_io_37 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_36 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_35 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_34 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_33 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_32 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_31 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_30 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_29 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_28 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_27 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_26 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_25 = GPIO_MODE_MGMT_STD_OUTPUT;

   //right side GPIO, bottom to top 
   
   reg_mprj_io_1 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_2 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_3 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_4 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_5 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_6 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_7 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_8 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_9 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_10 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_11 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_12 = GPIO_MODE_MGMT_STD_OUTPUT;
   reg_mprj_io_13 = GPIO_MODE_MGMT_STD_OUTPUT;

    reg_mprj_io_4 = GPIO_MODE_USER_STD_INPUT_NOPULL;
    reg_mprj_io_3 = GPIO_MODE_USER_STD_INPUT_NOPULL;
    reg_mprj_io_2 = GPIO_MODE_USER_STD_INPUT_NOPULL;   // 0x0403
    reg_mprj_io_1 = GPIO_MODE_USER_STD_BIDIRECTIONAL;  // 0x1803
    reg_mprj_io_0 = GPIO_MODE_MGMT_STD_OUTPUT;

and I tried to strobe all pins through writes to

reg_mprj_datal = 0xffffff00; reg_mprj_datah = 0xffffffff;

Nothing is strobing on either side of the IC. io_8 is randomly high, and my oscilator is still working so I know that io_7 and io_32 and in some analog friendly mode.

At this point I guess its just a matter of trying configuration bits / PVT + frequency variation to get the IO configured?

Jeff said "by default - all GPIO (5 - 37) are set to user mode bi-directional - which means you should be able to access them from your user project area"

I left the output enable and such pins on my project floating. Could I make this work without pin configuration at all?

Yah, looking at the default value I think I may be able to just skip GPIO configuration

I left the OEB pins and output pins unconnected in the user project because I was told I could. Whats actually happening in that case?

Were they somehow tied such that the GPIO output buffer will be disabled when managed by the user project?

Im gonna check through. One can hope they are floating the right way. If so I might be able to avoid configuring the IO entirely

No luck. most of the pins are pulled low 😕

for the digital inputs you think I can force them?

Drive the input with a low impedance that can override the output buffer

Its a chain, so if bits are lost the top N pins are nor fully configurable. Luckily thats the bare pins for the power stage. So if every n'th bit is lost or something I should be able to configure.

I cant configure the left side either though. Im going to need to try the 5MHz clock

My model mostly fits observed data. Mostly.

// NOTE:  The following list sets too many bits, but all
    // channels operate correctly as management-controlled outputs
    reg_mprj_io_13 = 0x0fff;
    reg_mprj_io_12 = 0x0fff;
    reg_mprj_io_11 = 0x0fff;
    reg_mprj_io_10 = 0x17ff;
    reg_mprj_io_9  = 0x1fdf;
    reg_mprj_io_8  = 0x0fff;
    reg_mprj_io_7  = 0x1ffe;
    reg_mprj_io_6  = 0x0fff;
    reg_mprj_io_5  = 0x17ff;
    reg_mprj_io_4  = 0x0fff;
    reg_mprj_io_3  = 0x0fff;
    reg_mprj_io_2  = 0x0fff;
    reg_mprj_io_1  = 0x1808;
    reg_mprj_io_0  = 0x1808;

This was one of my more successful experiments. I was able to run a program that toggles all the outputs, and the configuration above had all positions on thie right side toggling except for 1-4, which are (probably) being driven by the FTDI chip.

I think the all 0's value works for digital inputs to the user project

I assume 001 does that to?

what actually happens when the pin is disabled for digital input? Does it float? Does it copy the output register value?

"value 001" in that table should say "digital input, no pull-up/pull-down", not "analog mode".

I assume that 010 and 011 ignore the digital input disable bin at the very least?

Just bear in mind that OE_N is a configuration bit for management control, but a pin input for the user control.

at this point I am just looking for any way to set digital inputs to all of the right side, even if I have to force a pin. These are all just pin strapping type things so I could also just set their values via the managment control

and I need to propigate this all the way to io[13]

The management core should also always be able to read the input buffer, right?

and reading reg_mprj_datal gives the value as read on the output of the input buffer?

Yes, reading reg_mprj_datal gives the pad value, not the value written to reg_mprj_datal.

Also, to clarify your model for the IO issue, every 12th bit (the last bit?) gets doubled? But only once?

I assume this happens because there is a delay between when each word gets shifted out?

And any error like this just means I have a rotating field where the bit is doubled and thus is under specified

My theory about it is that there is a hold violation between the GPIO blocks, so that for each GPIO block, the clock arrives too late, and the data that just got clocked to the output of the previous GPIO's shift register gets copied into the next one, overwriting whatever was supposed to be the first bit in the next GPIO.

That would be a classic hold violation case due to clock skew.

I am also still unable to strobe any pins on the left side of the chip, even with a 5MHz clock

correction: one pin is flashing. pin 13

but the state of the GPIO is not looking very optimistic 😕

are 19-37 the better working I/O? Or the worst working I/O

because right now I have a 5MHz clock and set every pin to GPIO_MODE_MGMT_STD_OUTPUT. The only two pins toggling on the board are the LED pin and 13

Yeah, that surprises me because I was testing your chip and I had no problem at all programming GPIO 19 to 37 (or rather 25 to 37, since it's a Caravan chip and there is no GPIO 14 to 24).

also, im running bink.c. Should I try running hello.c?

Working with power electronics gives you plenty of time to learn how to replace blown things

Jeff must have split out "spi_io.h" recently, because it's not in my clone of the repository. @User: Are you aware that you didn't commit

spi_io.h

?

I dont know if I ever saw the other side blink. I was not really investigating it.

I dont think I damaged anything? I can still talk to the chip and my oscilator works.

I am also still having intermittent problems flashing the chip. I got rid of my workaround that delays the configuration and tried just holding reset on power on. I am once again unable to re-flash

And my trick is not working either. Im going to need to get an external SPI flash programmer.

I’m trying to catch up on this thread. what are trying to do at this point?

reprogram the flash or setup the gpio to be used by the mgmt soc?

if the latter, you will need to drive the xclk at 5Mhz and jumper J6.

for the former, I would go back to the blink firmware and try to program that. you will need to hold the processor in reset while powering up. continue to hold reset while programming.

configuring the gpio can interfere with the housekeeping IO configuration and programming the flash.

you can comment the spi_io.h from the hello.c example if you are not trying to use it.

This is with a 5MHz clock (I disabled the oscillator and am feeding in an external 5MHz clock).

I am also getting bizarre issues where I am not able to consistently reprogram the board through passthrough mode. It does not seem the flash is actually erasing

I hooked up my scope to do protocol decode on the flash SPI bus and I can see the erase command being transmitted and the write enable command before it.

But oddly, it only consistently works when the scope is connected to the clock line. Which suggests some signal integrity issue. Which is a bit confusing given that the timing looks good and I lowered the FTDI SPI speed to 1MHz as a test

I have been holding the flash in reset for all programming debug.

As shown in my other post I seem to have actually solved the SPI programming issue (or at least found a workaround). And for reasons I do not fully understand the GPIO 19 - 37 are now correctly configurable. So now its on to figuring out GPIO configuration for io0 - io13

I see the blink demo does not try to blink the first few io. I know they have other functions, but can the IO blink io0 - io6? With the caveat that the pins may contest with the FTDI chip?

Its probably easiest to start from io0 and work my way up

@User im working my way through the bit shifts for the other I/O bank but getting weird test results for the lower managment IOs (right now im on io5. Does the management core share the IO control with anything on that pin that can impact the state?

I was assuming (until the bit slip wraps around) I could just step the two adjacent 00 bits around until I align with the location of the managment bit == 0 and output enable bar == 0. But that does not seem to be working for the gpios I am trying other than io_6

Also, at some point I lost the other I/O bank again. I am back at running at 10MHz though

I think more than a single bit slip aligned with the configuration word is up with the GPIO though. Or else my method would be working

Oh, you think between multiple I/O blocks there may be some bit slippage? So more than 1 bit is getting doubled per word?

Im not making much progress on this without more insight into the problem. I also dont have any good way to check if I am getting the input to be enabled.

I keep randomly losing it. And I am not subjecting my chip to significant variations in temp or anything

And it seems to be independent of clock

And I am now running at a 5MHz clock

Right now its hard to pin down what is an actual issue and what is not. Like I am now pretty sure the SPI programming is an issue that is not just me

Likewise, I had a few issues with flash SPI programming which I chalked up to bad soldering or any number of different things. Now that you found the clock rising as CS is deasserted, that all makes sense. Also, I'm pretty sure I have a software workaround that doesn't involve an extra capacitor.

FKkh5GOUYAAHHoW.jpeg

Without the lower bank inputs working all I can do is verify the error amplifier and oscillator

@User can you clarify "But as long as input disable is 0, then the GPIO is configured as an input for mangement, not an output, and the management can read the pad value.". is this muxed at the GPIO block itself, or at the management core? (will it depend on the actual value shifted in, or will it depend on the value as set in the original register? Or subject to some different bit slippage?). I had the idea of just trying a working input on the other I/O bank to a pin under test, driving the pin pair with a function generator, and permuting the configuration bits until the readings of the two pins match. This should allow me to write an automate test script that should pretty quickly find some working input configuration if it exists.

I am trying with a known good pin and getting pretty good results. I am not getting any results I know to be invalid (nothing that has the input actually disabled, from the digital mode = 000 or input buffer disable ==1

it takes ~30 seconds to step through all itterations of the configuration word with 20 pin toggle cycles to weed out false positives. And I am getting 1457 results with that number only varying +-2 or so between runs.

So I think is is going to work! I am going to try it for a pin on the non functional bank now

Bleh. Im not having any luck with the bad I/O bank. I can see the I/O pin behavior is changing though. I might have to try shifting the configuration word more

woot! I am not itterating over possible bit slips and finding stuff!

Huh. This method seems to have run out of steam at io11. Not sure what do do now. I really need io12 and io13

I think I am getting false positives due to floating lines coupling to other lines

If I really work on this I think I can get a valid set of values though

@User: FYI, I looked at the RTL code to figure out why the SPI flash clock goes high with the chip select, and decided it's because someone unwisely stuck a pull-up resistor on that pin on the development board (R16). Removing R16 or grounding the other end to make it a pull-down should solve the problem. The data line (R15) probably shouldn't have a pull-up resistor either, but that's less problematic than the clock.

/ whats the impedance of the connection to the bus?

I am not opposed to figuring out how the bit slippage is occurring. My only worry is that its not just a constant duplication, but that the value of the duplicated bit is dependent on the left and right bit values

I think I am pretty close to figuring out a fully working combination. I have been able to derive working values for most of the inputs this way

At the very least, being able to check the digital input buffer from the management core significantly simplifies testing

It probably helps to have this illustration, too, to know where the switches are that connect the amux buses.

IE: Can I only configure the working bank and leave the other bank at the reset values

So, no, unfortunately the two sides are not on independent clocks, so as soon as you apply the "xfer" bit, all values on both sides are going to get modified.

Ah ha. I think I got bit on the analog bus connections for some of the inputs I was deriving. It seems the bus is tied to my system analog rail, so I need to check the values I derive while that rail is powered.

Huh. I think I want to filter my results by most number of zeros

Ah, I ran some more tests and I started actually parsing the valid combinations produced by my scripts and I think I am getting somewhere

so far for I/O 8 and 9 at least, the bit shift is 1 per I/O bank, as you expected

and the overlap seems to be on the end of the configuration word. So, for example, the actual value for IO_CONFIG9[0] is the same as IO_CONFIG8[12]

which is fine, as thats the management control bit and the top bit of the digital mode bit field

management control bit should be 0 so the processor controls the I/O state. And the only requirement on the digital mode bit field is that all 3 bits cant be 0, as that disables the input buffer

Do you mean pins 8 and 9?

Looking at my tables the value of managment enable for pin n is the same as the top bit of digital mode for pin n-1

so if you want pin 9 to be managed by the test harness the digital mode for pin 8 has to be 1xx, which precludes all the digital output combinations

So I think thats what you are seeing?

However, you should still be able to put consecutive pins in digital output mode and have them controlled by the user project. which is good.

Hopefully I will not find any more bit shifts or that will make things more messy

I am slightly confused on one thing I am seeing though. I am reading valid inputs from the input buffer when I have the management enable bit at 1 or 0. But only when the !OE bit is at 1. Does the user project not actually control its own !OE signal? Because I dont think I would be seeing this behavior otherwise.

What I am observing would explain the inability to set consecutive pins for digital output under control of the test harness processor

I think my analysis is right. I have input from IO13 - IO8 with values I calculated

But I dont have input from IO 10. Not sure if I am screwing up testing or what...

I could have damaged that pin with all my testing

Sorry if its messy, but here is how pins 13 and 12 work. Everything is just a bitshift as you first described

from this you can see how the management enable of pin 13 overlaps with the digital mode of pin 12

Something else seems slightly up though, because my configuration for IO 11 is not working

But the bitshift has not changed. I dont know if data is getting clobbered in some other way or what.

My brute force script is finding lots of valid configurations for it.

but if the bit-shift values were off things would be very wrong for all the I/O

wait, sorry. IO config 10

I am very perplexed right now. All the other inputs work with the same shifted configuration values and this value appears as valid in my test script for this pin

I dont think its a soldering issue

Ok. This is bizarre. Are there multiple register paths that are tee'ed off or something?

everything else seems to be shifted that I have checked. All the other bits, all the other I/O pins.

this configuration word is shifted by 10 bits. But it seems not that one value.

I am investigating further, but it is quite perplexing.

I dont know whats going on anymore. I was so close too

Only one I/O was not working

Oh wait, I might have a workaround that I can not directly check

Or I have the root cause.

You said that when the output for the management processor is enabled it can not read the input buffer because there is only one physical signal line.

How is that controlled / what drives the mux?

Because when I am unable to read this value the bit field in the actual configuration register on the management side for input disable is 1. So is it triggering the signal mux off of that?

You previously said "To answer one of your questions from a while back, though, the value on the pad will always show up in the user project 

user_gpio_in

 pin as long as the input buffer is enabled, regardless of any other setting (such as management enable/disable)."

basically I need to put a 1 in the input disable bit field so it gets shifted to the !output enable buffer. And if the mux is controlled by the actual value in that register the processor has access to, not the serial shifted one, its going to cause issues with how the managment core reads the pin, but my user project should be fine

I think that the other side of this mux may also explain why I always had the !output enable pin asserted for my other tests. It was not actually interfering with the input buffer but how the managment core reads the state of the input buffer

I decide to go ahead and try. It seems it works!

Power stage is making waveforms now 🙂

And I have verified the operation of the input pins that I could not read through the management processor. So that was the issues.

At your convenience, please confirm my understanding of the GPIO programming on the right side (GPIO 0 to 18), which I would summarize as follows: It appears that (1) everything is consistent with a simple hold violation between each of the GPIO configuration stages along the serial load chain , and (2) the hold violation causes the last bit of each stage (DM[2]) to "bleed" into the first bit of the next stage (management disable). In other words, the configuration word for each channel is effectively 12 bits instead of 13, and the "DM[2]" bit is shared with the "management disable" bit of the next channel, and all the configuration registers are compressed to 19*12 bits instead of 19*13 bits. Since DM[2] has to be set to 1 to get any GPIO to be an output, then any GPIO that is set to an output will prevent the GPIO next to it from being set to management control.  That is an annoyance, but a relatively minor issue, since most people are going to be interested in configuring the GPIO for user area control. In that case, for the same reason as just stated, the "DM[2]" bit has to be set to 1 to make the next GPIO set to user control. This prevents the channel before it from being set to a no-pull input, but it can still be set to a weak pull-up + pull-down output, which should be weak enough to be overridden by an external signal.

@User: This is a helper script based on my understanding of the full discussion. At the top of the file is the intended settings for the first 19 GPIOs. Then the bit slip is applied in reverse (management disable bit copied back to the previous GPIO configuration), and each GPIO configuration is checked to see if it changed from output to input or vice versa. Then, if an input is changed to output, the configuration is modified to be a weak output so that it can still act as an input. If an output was changed to an input but the adjacent GPIO is supposed to be an input, then the management disable bit is changed. Then the script dumps the actual configuration needed to achieve the intended result. With the script, it's obvious to see that multiple adjacent management-controlled outputs are impossible.

I think I would need a better understanding of how that bus works to make sense of it.

But if the input disable field in the original configuration word is set that shared line or whatever will get disconnected and the management can not read the pin, even if the actual value shifted into the input disable pin at the GPIO is 0.

And I think something similar in the opposite direction with the !output disable pin being shifted into the GPIO messing up that bus state, which is why in my pin toggle test script script I was never able to read the pin input state when that bit was asserted.

Also, I had an error in my script, so this is the corrected script:

Its exciting, I am going to have some of the first test results for an open source IC on sky130!

Looking forward to your results!

The provided test board was pretty useful for initial bringup and having a known good design though.

Adding some shunt resistors and headers to measure them to check power consumption would have been somewhat useful

Feel free to take the picture and post it where ever if you want

@User did I read correctly earlier in this conversation that for MPW2 there was a change so that after POR, the user project IO defaults to user project control? Except for some lower order IO needed by the SOC? Is this change also present for chipIgnite 2106 run?

The TL:DR is that flash passthrough is a bit buggy unless you remove the pullup resistor on the SPI clock line. And the configuration word for the lower number I/O bank is shifted by 1. And there may be very intermittent configuration issues with the higher order I/O bank that I have not been able to consistently reproduce.

I have never tried full resistance extraction on my FET. So many cells, it would be a giant mess.

But with just the FET model resistance I was at:

NMOS: 306 um x 306 um, 36 x 36 grid, ~175 mΩ
PMOS: 372 um x 372 um, 48 x 48 grid, ~325 mΩ

and my measured values are

0.6 for NMOS and 0.642 for pmos.

I have 3 bond wires for power, 3 for switching node, and 4 for ground. So thats contributing 0.113 ohms for the NMOS and 0.136 ohms for the pmos.

The connections to the power FETs all use the bare pad with the extra routing on all metal layers up to the edge of the project area

It might be a bit difficult to modify my PCB, but it would be interesting to use one of the pin connections as a kelvin connection. Which would allow me to measure the resistance after the I/O pad

I guess I am going to need to make some modifications to a board to use other pins as kelvin connections

also, metal current density stuff is all long term reliability concerns, right? I am pretty sure I am exceeding the current density limits in a few places...