@User I have logic available. Most interesting part is boot immediately following release of reset. We are seeing program loads and, what looks like, a pause or restart.

tell me if there's anything else you need

@User and @User For MPW-1, can we use the slippage.py script for IO settings? The goal is to set io8 - io18 as inputs, io19 - io27 as outputs. As I understand, any non-zero value will enable the input path to user area (to meet the 8-18 range)

@User: "slippage.py" is only relevant for ChipIgnite-1. There is possibly similar behavior in MPW-1, but seems more like a failure to load on specific I/Os than any kind of bit slippage across the shift register.

From io-mapper perspective on verifying GPIO config, is the read-back accurate? The idea is to 1. load the pin configuration 2. read a target register: e.g., mprj_io[x] 3. in executable code, jump to that value read from the register The value would be visible on the address requested from the core for execution. The intent is to determine the true value latched in the pin config register. This exercise would verify the value latched in the specified mprj_io reg. @User @User

@User: There are two sets of registers, one in the management SoC and the other distributed around the padframe. The "transfer" bit copies the data from management SoC to the padframe. If you read back from the location where you wrote the data, you will only confirm that the data are correct in the management SoC, not that the data are correct in the padframe. The only way to confirm the values in the padframe is to set the state of the GPIO to output and apply a value. If you apply some sort of slow toggling value to all the GPIO outputs, then you can immediately probe which ones are set to input or output.

Hi @Matt Venn , @Tim Edwards @jeffdi and Everyone I am creating a board-level document for mpw-one since I just received chips. As per the below image I am not seeing VDDIO_PAD in sky130_ef_io.v Am I missing anything?

Hi, Can I use any other FPGA board (ZYBO Z7) with PyFive MPW-1 postmortem board instead of ICE-Breaker? @tnt @Matt Venn

Of course but you will have to port the gateware

There are a few icebreaker in stock if you hurry

All, please be understanding. Our company placed an order 12APR and has not yet shipped. It would be good to see open stock ship first to open orders.

In the short term, the design was ported to commercial CPLD.

Hey there! We (https://www.smaract.com/en/metrology) took some SEM images of devices @Anish(Slot 35, at Metal Layer 2) and @Matt Venn (Slot 12, at the Local Interconnect layer) kindly provided to us. Maybe some of you is interested in having a look, too. Please treat the files as CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/). Warning: some of the files are huge 😉

@Yatharth Agarwal this is probably the best place to write about MPW1 bringup

Hey everyone, I had some doubts and ideas related to the MPW1 bringup and would really love to get some inputs! Due to customs in my country I only received my MPW1 chips a week back. My current goal is to get the management GPIO blinking and would consider that a huge success. I dont have access to an FT232H (USB to SPI chip) to directly interface with the Housekeeping SPI, Nor do I have an icebreaker FPGA, and I am not really well versed with FPGA's to port it to an ARTIX7 FPGA that i have access to. On further analysing the solution by @Matt Venn and @tnt , I noticed that it doesnt use an ft232h, and directly communicates with SPI to the QSPI ports on the caravel ( D8, D9, D10 and C10 on caravel) . With this I have 2 solutions in mind, 1. Write data to an external SPI flash (like w25q32) and then connect it the same QSPI pins and then boot the Caravel IC, 2. Write a firmware on an Arduino to communicate via SPI to QSPI pins. I have Vddio and Vdda connected to 1.8v and Vcca to 1.5v. and the clock is connected to a 10Mhz crystal. I tried the first method by writing the hex file at https://github.com/efabless/caravel_board/blob/main/firmware/blink2/blink2.hex to address 0x000 of the external SPI Flash and dont seem to get any results. First are any of these solutions viable? If yes, what am I doing wrong in the first method or I should try the second method? If the second method, how should I go about it?? Sorry for such a long message and thank you for taking the time to read it and any help!

Hey @Yatharth Agarwal I was just trying to find the work done by @Anish

it used to be here: https://github.com/asinghani/mpw1-bringup

and used a raspberry pi pico, so maybe it would be easier for you?

the main reason we did it how we did was because only a few chips work, and then only withhin a very specific voltage range

so the work by @tnt was about scanning through the voltages and counting how many firmware reads were made before it crashed. Then we could pick a value in the middle of the range and use some hand coded ASM to setup the IOs

then we also had to work around the hold violations in the IOs,

tnt also had a system to do that

that used the fpga to detect when pins went high or low

so I would definitely start by getting your core voltage controllable by the arduino or whatever, and then have it counting reads to the memory, whether that's simulated or real

ah @Matt Venn yeah I had been restructuring the repo, it's back at the same url now

@Yatharth Agarwal make sure you take a look at @Anish repo: https://github.com/asinghani/mpw1-bringup

@Vijayan Krishnan has left the channel

@Eric Smith has left the channel