FABulous FPGA fabric on MPW2 successfully brought up to the blinky stage (configuration isn't 100% reliable yet, I need to investigate)

Excellent!!! Congrats

@gatecat can you share the bring up methodology you're using?

the caravel firmware is https://github.com/gatecat/fabulous-mpw2-bringup/blob/main/caravel/gpio_test.c although all that matters is the IO configuration from https://github.com/gatecat/fabulous-mpw2-bringup/blob/main/caravel/gpio_config_io.py, the LA stuff is some now-unnecessary debugging. during debugging I switched to the

gpio_convert.py

script so you'll need to come up with a config pattern for your chip and then paste it into the firmware (or try and see if the config-stream approach works) the https://github.com/gatecat/fabulous-mpw2-bringup/blob/main/sim/build_test_design.sh script will build a bitstream for the fabric given latest yosys and nextpnr; and FABulous checked out somewhere https://github.com/gatecat/fabulous-mpw2-bringup/blob/main/caravel/caravel_spi.py is the micropython that loads the bitstream and runs it, printing the output (it's somewhat badly named because I was originally trying to interact with the hkspi). https://github.com/gatecat/fabulous-mpw2-bringup/blob/main/caravel/run.sh copies that script to the nucleo along with the bitstream from above once all this is set up I put the LEDs on pins [20..23]

There is a known problem that if any chip has too many dependent hold violations in the configuration shift register on one side, the I/O cannot be configured after a certain point. The dependent hold violation keeps knocking off the last 1 in a run of *1*s; the workaround is to keep filling in with extra *1*s so that just the right number of them get knocked off and you end up with the right bits by the time the configuration gets to the right register. But after, I think, eight dependent hold violations, the extra *1*s you have to insert collide with the next GPIO configuration word, and that trick stops working. So if you can't get past GPIO 10, and you need those GPIOs, you'll need to find another chip that has fewer dependent hold violations. In effect, this becomes a yield hit on parts for people who need access to GPIOs toward the end of each serial chain.

Unfortunately, GPIO 10-11 or 12 are the configuration interface and so the most critical ones (though it might also be possible to configure the fabric via Wishbone I haven't looked into any timing issues there yet)

@gatecat so is this the actual fpga fabric doing the blinking?

yes, correct!

amazing

sure!

I already interviewd the design team here: https://www.zerotoasiccourse.com/post/interview-with-dirk-koch-and-nguyen-dao/

a simple VGA generator also works on the fabric, although everything is very blurred (it should be distinct squares) because of the open drain IO

@gatecat have you tested the BRAM blocks?

Nope, thus far I've only looked at LUTs and FFs. Carry, DSP, RegFile and BRAM still all need to be tested.

@gatecat: Which pins drive the VGA output in the application above? Since it's a fabric, can they be moved around? Our software currently delivers a "safe" solution which is easier to get to work, by always using the weak pull-down mode for output. But if you can put the outputs on non-contiguous GPIO channels, then it would be possible to configure them for high-drive output and get a clean display.

At the moment they were on contiguous IO (15-19). But yeah, with some tweaking we can put them anywhere in IO 15 to 37

You probably have higher priorities at the moment then producing a display without fuzzy edges, but if you're interested, I can describe how you can do it.

It'd be useful to know in general for anything we do that needs fast IO, but no need to explain right now if you've got other priorities too

The "quick & dirty" explanation is that the script

gpio_config_builder.py

defines nine common/useful types which, assuming that you followed the instructions, you're using in your C code, like

C_USER_OUT

. At lines 118 and 142 it defines the configuration word for this type, which is (from line 118)

0110000000010

. The first three bits are the output mode;

011

is the weak-pulldown mode. The mode was chosen because the high bit is zero---the high bit that will bleed into the next channel if there's an independent hold violation between that channel and the next. If a

1

bit bleeds into the next channel, then it automatically becomes management controlled (that sets the management enable bit). That won't be a problem under the following conditions: (1) there is a dependent hold violation between that channel and the next (

1

bits won't slip across); (2) the next channel is an input (the user project can see input on channels set for management control), (3) the next channel is supposed to be management-controlled, or (4) the next channel is not being used. The quick fix would be to use

C_USER_BIDIR

. The configuration bit sequence for this is

1100000000000

which has the mode for a high-drive output (it also enables the input buffer, which you will simply ignore). You just need to make sure there isn't an incompatible definition in the channel next to it in the configuration serial chain (that is, the next channel meets the constraints I outlined above).

@gatecat what are the I/O actually used by the design?

How does this quote sound? With the MPW2 silicon back and provided harness, we were able to obtain our first silicon results from the FABulous eFPGA fabric generator. This included building a demo that tests all the fabric features - not just LUTs and FFs but also DSPs and BRAM (using an OpenRAM macro).