nextpnr-ice40 vers .9 and .10 give "unmatched constraint" warnings for each pin defined in .pcf

[ProbabilityEngineer]

When building with nextpnr-ice40 in version .9 and .10 I get warnings such as:
"Warning: unmatched constraint 'clk_in' (on line 5)" for each set_io line in the .pcf.
You can still build and upload from the command line.

In Icestudio I get:
"There are errors in the Design...
ERROR: 10 'o' is unconstrained in
PCF (override this error with --pcf-allow-unconstrained)"
Icestudio stops building at these errors.

I don't know if this is a bug or a design change.

If I replace nextpnr-ice40 with the .08 version it doesn't throw warnings in command line. This doesn't stop the errors in Icestudio! Returning to the .08 package in full fixes the problem.

I repeated this behavior on nandland go board and ice40-hx1k-evb board with examples led and bilnky.

I did not get this evhavior with ulx3s-85f ecp5 board.

[cavearr]

Hi @Sam99C, I'm working on the new version of the toolchain for osx arm64 with your advice, I was working on other things and I didn't check the nwjs project since August and I didn't know that they finally released the native version of arm, many thanks for the feedback, very soon we have a native osx arm version.

Yesterday and today I have been working on it and now I am preparing version 0.10 with the new versions of oss-cad-suite, openfpgaloader, etc. (now working version of wip is 0.9).

I need to test many boards until I publish them and it will take me a couple of days.

The 0.8 toolchain is very old and the tools evolve a lot. Your errors are probably design errors, which at the time (in the publication of 0.8 they were valid but now with the evolution of the tools there will be checks that fail) if you send me your .ice I will try to help you.

If you want to join the fpgawars group and put your problem, there are more colleagues who can help you,
https://groups.google.com/g/fpga-wars-explorando-el-lado-libre

Although it is apparently in Spanish, we usually communicate in English.

[ProbabilityEngineer]

Hey there, thanks for getting back to me so fast!

I don't have a project with a problem, I'm an absolute beginner playing with the examples! I was just testing things to see if I could make a workaround for gatekeeper objecting to the toolchain so I could make an install guide on youtube. It sounds like I should just wait for a native version before making videos.

I only have a nandland go board but if I can help with testing please get in touch.

Thanks for all your hard work! I wouldn't be able to play with FPGAs without Icestudio to get me started!

[cavearr]

Hi @Sam99C !! don't worry if you want to try and experiment with this, go ahead!! and tell me all of you need.

If you prefer wait for the new version, it's ok!

And thanks to you for use Icestudio and give me feedback, and try to document and fix things.

If you make videos, tutorials, etc, tell me please!

[zapta]

Hi @ProbabilityEngineer, do you have a sample project that we can use to reproduce it?

[ProbabilityEngineer]

I have a feeling I fixed this, possibly by diffing the versions of the toolchain, but I don’t remember. Either that or it was fundamental to the updated toolchain and I changed the project I was working on. I don’t have a computer right now so I can’t dig into it further, sorry. Remind me in a month if you want.

[zapta]

@ProbabilityEngineer, can you post here an example that reproduces the problem?

[ProbabilityEngineer]

Hi there, I've just gotten a computer after being without for a year. I haven't looked into this, but I did find some screenshots, attached. To fix it, I'm pretty sure I diffed and edited a file so it was readable text, or I simply used a file from a different version of the toolchain. I think it was a simple fix. I'd be surprised if it was still broken.

[cavearr]

Sorry @ProbabilityEngineer we are updating the toolchain and the latest wips could be broken for couple of days, work with the stable toolchain for the moment and when we finish it, i'm ping you in this thread.

Sorry for the inconvenience

[zapta]

@cavearr, is this an oss-cad-suite package issue, or should it be moved to apio or icestudio?

[cavearr]

the problem is in Icestudio, i'm migrating the commands just now

[ProbabilityEngineer]

I don't know if this is still relevant -

I think I modded METADATA.

I think I fixed it by diffing the METADATA file from apio-0.9.0-dist-info and apio-0.10.0-dist-info and backporting the change from 10 to 9. I found my files but I don't have the original 0.9.0 version to check.



toolchain-error.txt
icestudio-(min-apio-version)-package.json
METADATA.txt

[cavearr]

thanks @ProbabilityEngineer for the feedback, i'm reviewing it now. I don't have this board, i could be your help to do some tests

[ProbabilityEngineer]

I’ll be happy to run tests, send me project files when you’re ready - I can’t even remember what code triggered the error. At the time I was hacking stuff together replacing the intel mac nw.js with apple arm nw.js, and massaging the toolchain scripts to install arm versions (I still have a package installer I built.) That was a year ago and now you have a mac arm package, the problem may be fixed already.

[cavearr]

Hi @ProbabilityEngineer first of all, thanks again and going to this question i need to unify the environment to check it together.

today OSX wip is broken because I'm renewing my license from Apple and it will probably take me a week (Apple is validating some documentation and it takes some time), if it could wait you could update your icestudio package (which is now native to arm: ). ).

The problem is that since the last few weeks we improved Apio, @zapta is doing a great job and making a lot of changes to make more "platformio-like" Apio commands and the latest toolchain could fail if it doesn't work with the latest version of Apio and the latest Apio only works with the latest icestudio development branch (https://downloads.icestuio.io). or starting it from code with "npm start" in the development branch.

In these changes we decided to change the verification process to use verilator which is better than the old iverilog (more strict and better detects conflicting or erroneous situations). With that change many examples could fail because they may contain errors that could work in the previous version of Icestudio.

Your error could be a PCF error in the definition board or an error arising from a more stringent verification tool.

Please tell me if you could start the latest development version of Icestudio with npm start and if not, I would need to wait for the binary package to work again to verify it with you with the same tools and versions.

Tell me how you see it!

[ProbabilityEngineer]

By latest dev version do you mean .12rc1 ? Or is there a link to nightlies for mac? I will read up on using npm-start when I get a moment. I’m not in a rush if you’re not, I’m just tinkering.

[ProbabilityEngineer]

it works in 0.12rc1. I used the same project that gave the error last year with 0.11.w3 -

5. Two LEDs alternate blink.ice

For some reason that project originally assigned a wire to an undefined pin 44 which isn't listed in the .pcf for the Nandland Go board. Once I removed and re-added the wires the prokect verified, built and uploaded and worked correctly on the nandland go board with no errors.

Does 0.12rc1 use verilator?

If not I am happy to test a WIP/nightly with npm start (instructions on using it) if you send me a link or a zip

commad output attached:
command-output-05. Two LEDs alternate blink.ice.txt

gracias!

[cavearr]

Hi @ProbabilityEngineer. I'm very happy this works on 0.12rc1, this is the latest stable one. In two or three days the Apple license should be renewed and then I will have the latest wip so you can try it.

The pin 44 could be an migragion error, because the example is for Alhambra II, i review the migration code.

0.12rc1 does not work with verilator. In verilator many examples generate errors when "verify", they all synthesize, but it fails with the "verify" command. This is good, because small misconceptions can cause strange errors in the real world (on the fpga) and it's nice to be able to catch and fix them. Sometimes things may work but are not "implemented well" and could cause strange behavior or not work and you don't know why. Fixing these types of verilog errors generates great learning and results in much more stable code.

I'm telling you when wip for osx will be ready, thanks for your feedback and tests, are very useful!

[ProbabilityEngineer]

That’s great, I am happy to test the next version whenever it comes out. (I also think pin 44 was a migration error) Additionally I have nandland go and alhambra boards and I’m happy to test anything you want to send my way going forward.