Hi everyone, I am currently testing MPW-5 chips containing the FABulous_eFPGA project by @Nguyen Dao and since I did not find a separate channel for MPW-5, I will post this here. If there is a better place, please let me know. When checking for the Hold-Time-Violation pattern, I noticed that all chips seem to have the same pattern. The first ten pins after

IO[0]

/

IO[37]

of each chain are marked as

H_DEPENDENT

, the next seven pins are marked as

H_INDEPENDENT

and the last pin of each chain fails the check and is marked as

H_UNKNOWN

(so also both chains on the same chip have the same pattern). I tested eight chips so far, all of them at 1.5V and one also at 1.8V with the exact same result. Is this expected for MPW-5? Did anyone else get similar results? For MPW-2 I got different results for almost every chip and also for different voltages for the same chip. Is there something I could be doing wrong when checking the MPW-5 chips? Thanks in advance for any answers and feedback!

I don't have an MPW-5 chip in hand so I can't speak to the behavior. Having the exact same behavior on all chips, for both channels, does seem suspicious. The MPW-5 silicon, however, should be the same as the MPW-3 silicon other than process differences between the two runs. The algorithm for calibration will be exactly the same. Every "dependent" hold violation knocks a bit off the sequence going through it, so after ten dependent violations, there is no margin left, and no pad after the 11th dependent hold violation can be reached because all the bits have been knocked off until nothing is left. That unambiguously explains the

H_UNKNOWN

in the last pin on each side. The flaky behavior of MPW-2 chips was due to the fact that the timing of the hold violations was just at the edge of working/not working. Process variations from run to run could easily account for moving the hold violations out of that range and making them stable and predictable, which is a good thing. How badly is operation impacted by not being able to reach GPIO 18 and 19?

Thanks for your clarifications! I now tested all 18 chips I have at hand, and also found two chips with slight variations. One chip failed at

IO[30]

and one at

IO[32]

. The lower chain however remains the same. Its nice that all other chips have the same pattern, I guess that will make things easier! Since the design is an FPGA, many pins are configurable and not being able to reach

IO[18]

and

IO[19]

fortunately does not affect the functionality at all (other than just losing two GPIOs ofc). Only pins 7 to 13 are hardwired to special functionality of the fabric (7-12 input, 13 output). So far I was not able to get a bitstream running on the MPW-5 chip. I tried the same GPIO config and Caravel firmware as for the MPW-2 design, since the fabric pins are at the same location. However, the problem could be independent of the GPIO config since there are still small differences in the FPGA fabric. Is there a possibility to check whether the pins are configured as intended so the GPIO config can be isolated from the rest of the troubleshooting?

I'm hoping that the consistency among the chips might also mean that you get the same pattern whether the board is on or off the Nucleo. However, it is always a challenge when the GPIO state is yet another unknown in your testing sequence. It is not easy to test the states of the GPIO because some configurations, especially at the end of the chain, are not reachable, so setting a specific configuration like pull-up or pull-down doesn't necessarily tell you anything useful about the configuration that you need for testing the user project. At least for all configurations with the input driver enabled: The input goes to both the management processor and the user project simultaneously, so you should be able to set all GPIO as inputs, apply power or ground to the pin, and read that state from the management processor. At least being able to do that would raise confidence that the GPIO configuration works. You will probably want to run

gpio_config/gpio_config_simulator.py

and take a look at what the GPIOs are actually set to. Especially since you have 10 dependent hold violations in a row, all the GPIOs after that have a very limited number of configurations they can be set to. If you need help getting a configuration that works right for you, please let me know. Can you clarify what you mean by "not able to get a bistream running"? Does that mean complete failure (other than GPIO 0 and 37, which always work)? Or partial failure? Or the software is telling you it can't do it and refuses to create a bitstream?

I'm hoping that the consistency among the chips might also mean that you get the same pattern whether the board is on or off the Nucleo.

This luckily also was no issue for the MPW-2 chips, so I suppose it will be the same for MPW-5. I read some of your previous messages and in one message you wrote that your understanding at that point was that it does not matter if it is on or off, is that correct?

At least for all configurations with the input driver enabled: The input goes to both the management processor and the user project simultaneously, so you should be able to set all GPIO as inputs, apply power or ground to the pin, and read that state from the management processor.

So on the input side a pin is always connected to both the MGMT and the user area? Only the output is exclusive?

You will probably want to run gpio_config/gpio_config_simulator.py and take a look at what the GPIOs are actually set to.

Thanks for the tip, I will check this!

Especially since you have 10 dependent hold violations in a row, all the GPIOs after that have a very limited number of configurations they can be set to. If you need help getting a configuration that works right for you, please let me know.

What I need is a configuration that sets pins 7 -12 to inputs (while only 8,9 and 12 are critical, the rest is more or less nice to have), 13 to output (quite nice to have) and 14 - 37 to bidirectional. For the MPW-2 Chip I was able to achieve this by settings all pins to bidirectional.

Can you clarify what you mean by "not able to get a bistream running"? Does that mean complete failure (other than GPIO 0 and 37, which always work)? Or partial failure? Or the software is telling you it can't do it and refuses to create a bitstream?

Sorry, I didn't clarify this enough. What I'm doing is creating a bitstream for the FPGA fabric using the FABulous framework. The user logic design to create this bitstream from is just a simple counter which toggles all IOs from

IO[14]

to

IO[36]

while

IO[37]

is used as a reset. I am able to upload the bitstream for this design onto the MPW-2 fabric and see the pins toggle (which is currently my definition for "bitstream upload successful"/"bitstrea running"). I have not yet achieved that on the MPW-5 chip. This could be due to a wrong IO config, but also due to other reasons which are beyond the scope of this channel and are more related to FABulous (if you are however still interested in these reasons, let me know). I hope this clarifies what I'm trying to achieve. If you need any more information, just let me know! Thanks for your help so far!

If at any point you think it might still be an issue with the GPIOs, please let me know right away (and ping me by name so I get an alert). I am certainly interested in how testing goes on the FABulous project. Early in the life of the open PDK, I said that I wanted to do an eFPGA project, but I never had the time for it, and it's great to see several such projects come through the open MPW runs. (@Leo Moser may also be interested in the FABulous testing, although he is probably already aware of it.)

I am indeed very much interested in how the bring-up goes 😃 @Marcel Jung MPW-5 is the open-everything FPGA, if I'm right?

Yes, that's right! 🙂 So I will keep you all updated on how it goes. If you want any specific information beforehand, just let me know!

That's great! I might have some specific questions for you at a later time, thanks 👏

I'm also still lurking around and did the MPW2 FABulous bring up if you need any help...

I'm also still lurking around and did the MPW2 FABulous bring up if you need any help...

Thanks! 🙂 without your work I would not have been able to bringup the MPW-2 chip myself! Indeed I have a specific question about the fabric code: In the MPW-2 design, the seven pins used for the FPGA configuration have their

io_oeb

bits set to

7'b0111111

while in the MPW-5 design they are set to

7'b1000000

: MPW-2: https://github.com/gatecat/fabulous-mpw2-bringup/blob/main/fabric/verilog/eFPGA_v3_top_sky130.v#L204 MPW-5: https://github.com/nguyendao-uom/open_eFPGA/blob/main/verilog/rtl/eFPGA_v3_top_sky130.v#L221 I don't understand why the bits are not inverted anymore in MPW-5, since

io_oeb

for me sounds like active low and we need the first six pins as inputs and then one output for the RX LED. Did the IO pads change from MPW-2 to MPW-5? I also asked @Nguyen Dao and @Dirk Koch but we could not yet find the reason for the change.

If the IO are configured correctly and the config interface is receiving bitbang data, then you should see activity (a single clock cycle pulse every received word, iirc) on the ReceiveLED output

Yes, I get a blinking LED for the MPW-2 design which lights up constantly while the fabric receives data (when using the UART config port). However I do not get that for the MPW-5 open everything FPGA (which could be due to the

io_oeb

setting described above).

I don't think the IO pads changed, so that is probably isn't correct, unless there's another layer of inversion in the user project that's being missed somewhere. It's possible to force pins to be inputs in the IO configuration, but not force an output to be enabled. So the config input pins can still be usable, but the RX LED pin would be non-functional

unless there's another layer of inversion in the user project that's being missed somewhere.

Do you have any idea where I could look for this?

It's possible to force pins to be inputs in the IO configuration, but not force an output to be enabled. So the config input pins can still be usable, but the RX LED pin would be non-functional

Isn't it also a problem that the output of a pin then effectively directly drives the input?

Do you have any idea where I could look for this?

The only place it could be is here but there's no inversion, so that's not it

Isn't it also a problem that the output of a pin then effectively directly drives the input?

I believe if the pin is configured as an input only in the IO config (the config loaded into the shift registers), then the output related functionality is totally disabled regardless of oeb

I believe if the pin is configured as an input only in the IO config (the config loaded into the shift registers), then the output related functionality is totally disabled regardless of oeb

Okay thanks, I will look into this!

The input signal gets routed to the user design either way, so in this case, there's no harm setting it to management mode in order to force it into being an input

The input signal gets routed to the user design either way, so in this case, there's no harm setting it to management mode in order to force it into being an input

Yes you're right, it should just be enough to set the as management input only pins. Thanks!

There might be another way that setting them as inputs that also disables the output buffer (or at least configures it for weak drive)

@Marcel Jung: I agree with Myrtle and was thinking along the same lines: It's okay to have the output buffer turned on if it's in a weak pull mode. I was thinking maybe the configuration to try to hit is `1000000000001`: Open-drain, strong pull-down, management control. There are enough zero bits in the middle to be able to hit this configuration. The

100

mode is open-drain, so even though the output buffer is turned on, if you apply (from the management side) an output value of 1, the output is effectively disabled due to the open drain. The input buffer is enabled, so it should still behave like an input.

This sounds promising! I will try this and report on how it went.

Thanks for reporting back, very nice to know that it's working!

@Marcel Jung: It's great that you found a workaround (wish I'd thought of that one!), although I still think that in theory what I proposed should have worked, as having it set to management control means that the user project should not be able to drive the output. But the logic in the GPIO control blocks is complicated enough that I may have missed some reason that it doesn't work.

@Tim Edwards some further things I noticed: Almost all pins marked as

H_DEPENDENT

are working as expected, at least in the high chain where there is not conflict with the

oeb

setting of the fabric. Only

IO[29]

-

IO[27]

are not working as inputs.

C_USER_BIDIR_WPU

was used for all FPGA user design pins, since there is just a single bit set for this config and input/output behavior can then be defined in the user design. However, Pins marked as

H_INDEPENDENT

are behaving a bit strange: If all of them are set to

C_USER_BIDIR_WPU

, there is an output on most pins, but only on some it is the correct output. On the screenshot the signals captured by a logic analyzer can be seen. The desired output would be to have alternating waveforms of frequencies

f

and

2*f

on every pin. On the first screenshot it can be seen that some signals are missing every second high value. Zooming in on the rising edge of such a signal (second screenshot) shows many oscillations before the signal gets steady. This is not the case for the falling edge. When experimenting with the config values I also noticed the following: If the

H_INDEPENDENT

pins are set alternating to

C_DISABLE

and

C_USER_BIDIR_WPU

, the ones set to

C_DISABLE

work, while those set to

C_USER_BIDIR_WPU

are not working (multiple chips were tested). I also still had no success in uploading a bitstream after the GPIOs are configured with setting the fixed fabric pins to the suggested GPIO config. Maybe this is also related to the strange behavior of the

H_INDEPENDENT

Pins? With the alternation described above, enough pins are working for our purposes, so I will stop further investigation since I have to move on to doing other stuff. I still wanted to leave this here for anyone who is interested or might even experience the same behavior. If there are any questions I will of course try to answer them.