I did get the flow to work (technically with the MPW-2 boards but the M.2 boards seem to be exactly the same) on an ARM mac, albeit with a few changes (using

mpy-cross-v6

instead of

mpy-cross

in the Makefile, manually specifying the

DEV

serial port, and commenting out the

export PATH

line in the nucleo Makefile). Some results I've gotten: • Wishbone-interfaced accelerator works beautifully with control code running on the Caravel RISC-V • Logic analyzer to control my designs works great • SPI master on the Caravel works (not sure if anyone actually needs this but I happened to need more RAM for testing one of my designs, so I hooked up an SPI RAM chip) • After configuring I/O, UART RX and TX on the Caravel works (9600 baud at the default 10 MHz clock) • Can successfully configure both I/O chains on some parts (some parts work at 1.6V, some at 1.45V) • 25MHz VGA output works from one of the cores in my design (at the 1.6V core voltage) - the slew-rate on some of the signals isn't great for some reason, but its good enough for 640x480 VGA esp with a large-enough pullup resistor (I also only tried one part so it's possible its just a quirk of the GPIO config on that part; more analysis needed)

Can you share serial rx example? No one has got that working yet as far as I know

Bidirectional serial at 9600 baud, works with the USB port on the nucleo hat board, just need to jumper the UART_EN in the top left corner (although the jumper needs to be removed in order to flash it, because the FTDI has the same pins connected to the serial and to the flash for some reason). Just set pin 5 to C_MGMT_IN and 6 to C_MGMT_OUT in the

gpio_config_io.py

Yep i did try this but im not able to receive data. Were you able to successfully do that? And yes, it would be really great if you could share the code! Thanks for the help.

@Yatharth Agarwal the code is attached in my message above, are you not able to see the file?

My bad. Able to see it now. Thanks alot!

Just using the USB port on the hat board as a 9600 baud serial port (I'm using CoolTerm, although any serial terminal software should do)

@Anish: There is an issue in which the hold violations will specifically cause the last bit of the GPIO configuration (which is generally 1 for outputs, 0 for inputs) to bleed into the first bit of the GPIO configuration for the next channel (which is the management enable bit). That means that outputs configured for "user output" modes have problems if they are in contiguous channels, because the output configuration of one will force the next GPIO into a management-controlled mode. Our general-purpose solution to that was to use a different output mode which has a configuration high bit of 0 always. That solves the problem of neighboring channels. But it also means that the output mode has a resistor in series with the output. That's what is giving you the slow slew rate (not really a slew rate, but it has the same result). Depending on what pins you use as outputs, some portion of these channels may be able to be configured to have full-bandwidth output. Because the solution is very project-dependent, we use the "general purpose" solution instead---that's enough to get projects up and running. I can help you recover the full-bandwidth outputs if it's possible to do so. I would need to see a list of your output configuration settings.

@Anish That jumper that you are referring to as UART_EN can you highlight it on a picture?

@Christoph Weiser yeah, J2

@Anish: This is the block diagram of the control structure around the GPIOs: https://github.com/efabless/caravel_mpw-one/blob/master/docs/source/_static/single_gpio_pad_structure_used_all_pads_except_0_and_1.svg and this is the description of the I/O pads: https://skywater-pdk.readthedocs.io/en/main/contents/libraries/sky130_fd_io/docs/user_guide.html In the 2nd reference, look about a third of the way down that page for "Table 110 sky130_fd_io__gpiov2 output buffer configurations".

ah thanks. so the options are weak 1/strong 0 or strong 1/weak 0? unfortunate but good to know, I'll play around with the io bit stream generation

Both statements above are correct. The one where the next I/O is independent is, of course, going to be different from chip to chip, so depends on how lucky you might be with the samples you have.