Fail to boot user image with >2 BRAMs


I have a Simple Design that seems to break when changing almost any part of the Verilog or pin mapping.

Most changes to the design seem to cause the user image to fail booting. I have narrowed it down to the amount of BRAMs I am using.

If I use 2x then the image works, if I use 1x then the image fails. If i use more than 2x then the image also fails. This can be observed by the user_led hanging at a dim brightness.

You can tell for yourself using the code here:

When ROMDEPTH is set to 512 the design boots successfully. Changing ROMDEPTH to any number >512 causes the image to fail. Changing ROMDEPTH to any number <=256 causes it to fail aswell. This corresponds the the number of BRAMs allocated by arachne-pnr…

Note that this design does not boot at all when using nextpnr.

Any tips would help a lot. I have a feeling my clock domain may be interfering with LUTs accessing the BRAMs but I’m not experienced enough to say decidedly.


You have some unconstrained pins in your design, such as GBACART_CS2. This is never a good idea even if they are unused as it could cause unpredictable behaviour, and should be an error in nextpnr. I’m not sure if this is actually the problem though.

To debug this further, I would try and narrow down where it is failing. First try connecting the user LED to a constant 1’b1, so it should always be lit if the design boots correctly. Then perhaps connect it to a counter and check that the counter blinks.


You are doing strange things with the usb pins, which could be a problem. If you are not using usb, you should set pin_pu = 0 and not use the other usb pins.


Changing to pin_pu = 1' b0 actually helped things a lot. I am now able to remove the unconstrained pins from my top module and increase the rom size at will (all the way up to 8912 words, 32 BRAMs)

However I am not able to remove the LED pin from my pcf file or my top module outputs as that causes booting to fail. But I don’t mind keeping an unused pin on the module if it means my design will work.

Also now my design works in nextpnr where it was failing no matter what beforehand!

After doing this I noticed that the design will boot to the LED assignment even if there is a failure. I am assuming that the statically assigned net is getting configured at boot time before the logic nets are put into fabric which causes the LED to stay high even on a failed boot.


You could try grouping the pins by I/O bank as I mentioned on twitter and see if it helps - not as easy to do this on the TinyBX as it was for me to do on the BlackIce II though… here’s my quick attempt at reorganising the .pcf file:

set_io GBACART_RD     D8 # PIN_16
set_io GBACART_CS     A9 # PIN_18
set_io GBACART_AD[0]  A1 # PIN_2
set_io GBACART_AD[1]  A2 # PIN_1
set_io GBACART_AD[2]  A6 # PIN_24
set_io GBACART_AD[3]  A7 # PIN_22
set_io GBACART_AD[4]  A8 # PIN_20
set_io GBACART_AD[5]  B6 # PIN_23
set_io GBACART_AD[6]  B7 # PIN_21
set_io GBACART_AD[7]  B8 # PIN_19
set_io GBACART_AD[8]  B1 # PIN_3
set_io GBACART_AD[9]  C1 # PIN_5
set_io GBACART_AD[10] C2 # PIN_4
set_io GBACART_AD[11] D1 # PIN_7
set_io GBACART_AD[12] D2 # PIN_6
set_io GBACART_AD[13] G2 # PIN_10
set_io GBACART_AD[14] E1 # PIN_9
set_io GBACART_AD[15] E2 # PIN_8


Re-jiggered it after looking at the schematic! :sweat_smile:


Oh you were talking about the the package pins rather than the through hole headers. I understand… I’ll give this configuration a try and see if it helps with signal noise. Thanks!