Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERROR: Unable to find legal placement for all cells, design is probably at utilisation limit. #15

Open
WillNilges opened this issue Feb 25, 2023 · 9 comments
Labels
question Further information is requested

Comments

@WillNilges
Copy link

Getting the following error when running make:

ERROR: Unable to find legal placement for all cells, design is probably at utilisation limit.

It does, indeed, appear that some components of the device are at 100% utilisation.

Info: Device utilisation:
Info:            ICESTORM_LC:  4959/ 5280    93%
Info:           ICESTORM_RAM:    18/   30    60%
Info:                  SB_IO:    14/   96    14%
Info:                  SB_GB:     8/    8   100%
Info:           ICESTORM_PLL:     1/    1   100%
Info:            SB_WARMBOOT:     1/    1   100%
Info:           ICESTORM_DSP:     0/    8     0%
Info:         ICESTORM_HFOSC:     0/    1     0%
Info:         ICESTORM_LFOSC:     0/    1     0%
Info:                 SB_I2C:     0/    2     0%
Info:                 SB_SPI:     0/    2     0%
Info:                 IO_I3C:     0/    2     0%
Info:            SB_LEDDA_IP:     0/    1     0%
Info:            SB_RGBA_DRV:     0/    1     0%
Info:         ICESTORM_SPRAM:     0/    4     0%

I checked the most recent CI run, and it looks like the numbers are slightly different than mine... That's weird?

Info: Device utilisation:
Info: 	         ICESTORM_LC:  4621/ 5280    87%
Info: 	        ICESTORM_RAM:    18/   30    60%
Info: 	               SB_IO:    14/   96    14%
Info: 	               SB_GB:     8/    8   100%
Info: 	        ICESTORM_PLL:     1/    1   100%
Info: 	         SB_WARMBOOT:     1/    1   100%
Info: 	        ICESTORM_DSP:     0/    8     0%
Info: 	      ICESTORM_HFOSC:     0/    1     0%
Info: 	      ICESTORM_LFOSC:     0/    1     0%
Info: 	              SB_I2C:     0/    2     0%
Info: 	              SB_SPI:     0/    2     0%
Info: 	              IO_I3C:     0/    2     0%
Info: 	         SB_LEDDA_IP:     0/    1     0%
Info: 	         SB_RGBA_DRV:     0/    1     0%
Info: 	      ICESTORM_SPRAM:     0/    4     0%

Info: Placed 17 cells based on constraints.
Info: Creating initial analytic placement for 4202 cells, random placement wirelen = 111165.
Info:     at initial placer iter 0, wirelen = 1157
Info:     at initial placer iter 1, wirelen = 1020
Info:     at initial placer iter 2, wirelen = 1103
Info:     at initial placer iter 3, wirelen = 1097

This does not seem like the kind of thing that changing the seed, as mentioned in the README, would help, but I thought I would open this issue while I investigate.

@krichardsson
Copy link
Contributor

Are you building with the toolbelt (the docker builder) or have you installed locally? If you have a local install there is maybe some difference in versions?

@WillNilges
Copy link
Author

WillNilges commented Mar 1, 2023

This was a baremetal install (before I realized that toolbelt was a thing :P). 99% sure it's an issue with version differences. Building with a container yields more expected results (timing errors).

ERROR: Max frequency for clock          'Core_clk': 47.03 MHz (FAIL at 48.00 MHz)
ERROR: Max frequency for clock 'Slow_clk_$glb_clk': 21.16 MHz (FAIL at 24.00 MHz)

For that, I'm just pulling the fpga-builder container and running it in podman. I chose to do it this way because Copypasta'ing the toolbelt commands from Docker to Podman didn't immediately work, but that's kind of off topic.

In an attempt to remedy the errors, I tried running search_seed.py, but didn't have a lighthouse.json file. After mounting my project directory inside the container and running the build, I realized that was some kind of build artifact. So now I'm running search_seed.py inside the container. How long should it take to find a seed?

@WillNilges
Copy link
Author

WillNilges commented Mar 1, 2023

Ok, it was taking too long so I parallelized it and ran it on the biggest computer I had access to. After running all 1000 seeds three times for the V6 tag, I got 129, 280 and 577, neither of which appear to be actually working?

@ataffanel
Copy link
Member

I am not sure what you mean about the found seeds not working. If a seed is found by the script, it should be working to build again with that seed in the Makefile.

The current design is really close to the limit. An easy way to ease a little bit the pressure is to set the 'speedMultipler' parameter of the PulseOffsetFinder to 1:

val pulseOffsetFinder = new PulseOffsetFinder(speedMultiplier = 4)
.

This will slow down the pulse processing but it should work fine nonetheless: it was designed to be able to cope with receiving 8 lighthouse base-station at the same time in the worst case. This should be relaxed with what we know now:

  • Receiving 8 basestation at the same time should never happen, it does not results in stable signals
  • We will never be at the worst case (max offset) for all the sweeps at once.

So setting the multiplier to 1 should work. I have not had time to test it yet though which is why it is not yet the default.

@WillNilges
Copy link
Author

WillNilges commented Mar 8, 2023

Thanks for the reply. What I meant by the found seeds not working was that even with a seed that the script said was good, I was still getting timing failures.

ERROR: Max frequency for clock          'Core_clk': 43.99 MHz (FAIL at 48.00 MHz)
ERROR: Max frequency for clock 'Slow_clk_$glb_clk': 22.84 MHz (FAIL at 24.00 MHz)

I set the speed multiplier to 1, and it compiles! I'm still pretty far off from properly testing this thing, but I'll let you know if I run into more problems, thank you!

@ataffanel
Copy link
Member

Have you been using the same compiler to find the seed and then to try to compile again later? A seed is only good for one version of a compiler and the search_seed.py script is by default searching the seed in a docker container (this same container is then used in CI. So using the same container later should yield the same result.

@WillNilges
Copy link
Author

I had reverted to the V6 tag, and was using a parallelized version of the search_seed.py script I had found therein. Admittedly, I haven't really messed around with the latest code and included docker container, primarily because I don't want to use Docker.

#!/usr/bin/env python3

import subprocess
import sys
from joblib import Parallel, delayed

def pnr(seed: int):
    result = subprocess.run(["nextpnr-ice40", "--seed",  str(seed),
                        "--package", "sg48",
                        "--up5k", "--json", "lighthouse.json", "--asc",
                        "lighthouse.asc", "--pcf", "lighthouse4_revB.pcf"])
    if result.returncode == 0:
        with open(f"seed_{seed}.txt", "w") as file:
            file.write("Seed is {}".format(seed))
        print("Seed is {}".format(seed))
        sys.exit()

results = Parallel(n_jobs=48)(delayed(pnr)(i) for i in range(1000))

Searching all 1000 seeds on my laptop would have taken hours, maybe a day or two.

I apologize for making what seems like RTFM mistakes 😅 Suppose I was just impatient and wanted to use Podman.

@WillNilges
Copy link
Author

I should explicitly ask, though: how should I compile this? The readme suggested install the tools baremetal, but that didn't really work. Should I use toolbelt?

@ataffanel
Copy link
Member

You can use either a local tool or the toolbelt, the important things is to use the exact same build when searching the seed and when building, for this Docker is quite useful but as long as you use the same system to find the seed and building new bitstream you can use your locally-installed toolchain.

If you find a seed and then it does not work anymore though, you might have found a bug in the router: my understanding is that the seed makes routing repeatable.

@knmcguire knmcguire added the question Further information is requested label Mar 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants