Well, I would advise you to forget about nextpnr-gowin since I don’t think it will last long, and change himbaechel/gowin.

The call to himbaechel is made with the full device name:
nextpnr-himbaechel --device GW1NSR-LV4CQN48PC7/I6 --vopt cst=tangnano4k.cst

so there is probably some sort of recoding inside to select the database file.

Thanks, I will take a look at himbaechel. If the family is not supplied, how does the place and route know whether it is targeting, for example, GW1N-9 or GW1N-9C ? Since they both have the same part number (outside of the date code)

Ah, I found my answer:

I suppose another option could be just hardcoding the translation, given that it is unlikely to change. That’s probably the easiest option.

I think in the circumstances you are right and hardcoding it is the best solution here.

Well, I would advise you to forget about nextpnr-gowin since I don’t think it will last long, and change himbaechel/gowin.

Any quick read you can point to on the diffs between these two, and advantages of taking himbaechel route?

well, in short:
https://github.com/YosysHQ/nextpnr/blob/master/docs/himbaechel.md

netxtpnr-gowin does not receive updates and I don’t even know if it will be possible to build an image for Tangnano20k or TangPrimer20k, which are supported in the himbaechel version.

Well, I would advise you to forget about nextpnr-gowin since I don’t think it will last long, and change himbaechel/gowin.

Any quick read you can point to on the diffs between these two, and advantages of taking himbaechel route?

nextpnr-gowin started off as a fork of nextpnr-generic, and generic suffers from scaling issues that mean that while supporting the <= 9K LUT chips is feasible, larger chips run into problems that would require a more radical overhaul of generic.

That radical overhaul of generic is himbaechel, which has a significantly more scalable core (we've tested it with 500K LUT FPGAs), and improves development speed by having sensible defaults which himbaechel/gowin hooks into to override behaviour where needed.

From what we can tell, Project Apicula is still on nextpnr-gowin. While @yrabbit does not think that nextpnr-gowin will last long, @Juninho99 is having trouble here-and-now to tie nextpnr-himbaechel into existing Apicula framework.

• Any tips you can offer on how to go about it?

Question from @Juninho99: gowin_bba came with installation of Apicula project. That's the very file I am using for build with nextpnr-gowin. Is there an equivalent himbaechel_bba file I need to download and install in order to build nextpnr-himbaechel ?

Question from @Juninho99: gowin_bba came with installation of Apicula project. That's the very file I am using for build with nextpnr-gowin. Is there an equivalent himbaechel_bba file I need to download and install in order to build nextpnr-himbaechel ?

Could you maybe explain the procedure to enable nextpnr-himbaechel? With the Apicula project, I got gowin_bba. Do I need something similar for nextpnr-himbaechel, and how do I get that?

• make a completely fresh build directory inside the nextpnr source tree, say, build-himbaechel.
• inside that directory, run cmake .. -D ARCH=himbaechel -D HIMBAECHEL_GOWIN_DEVICES=all, assuming that you have Apicula set up.
• then run make with whatever flags you like to build nextpnr; a sign that things are going smoothly is that you have "Deduplicating tile shapes..." as a message during the build.
• this will then give you a nextpnr-himbaechel executable and a share folder; you can run make install as root to install them to your system.
• note that the syntax for a nextpnr-himbaechel run will differ from the equivalent nextpnr-gowin run.

Question from @Juninho99: gowin_bba came with installation of Apicula project. That's the very file I am using for build with nextpnr-gowin. Is there an equivalent himbaechel_bba file I need to download and install in order to build nextpnr-himbaechel ?

Could you maybe explain the procedure to enable nextpnr-himbaechel? With the Apicula project, I got gowin_bba. Do I need something similar for nextpnr-himbaechel, and how do I get that?

the equivalent to gowin_bba is bundled with nextpnr, so you don't need to do anything.

• make a completely fresh build directory inside the nextpnr source tree, say, build-himbaechel.
• inside that directory, run cmake .. -D ARCH=himbaechel -D HIMBAECHEL_GOWIN_DEVICES=all, assuming that you have Apicula set up.
• then run make with whatever flags you like to build nextpnr; a sign that things are going smoothly is that you have "Deduplicating tile shapes..." as a message during the build.
• this will then give you a nextpnr-himbaechel executable and a share folder; you can run make install as root to install them to your system.
• note that the syntax for a nextpnr-himbaechel run will differ from the equivalent nextpnr-gowin run.

After I execute these two commands:
yosys -D LEDS_NR=6 -p "read_verilog blinky.v; synth_gowin -json blinky.json"
nextpnr-himbaechel --json blinky.json --write pnrblinky.json --device GW1NSR-LV4CQN48PC7/I6 --vopt cst=tangnano4k.cst
Can I, and if so, how, use gowin_pack with himbaechel?
gowin_pack -d GW1NS-4 -o pack.fs pnrblinky.json Like this, but in a way that allows me to set the family to GW1NSR-4C?

@Ravenslofty @yrabbit @jeremyherbert @gatecat - Any additional tips and insights you can offer for @Juninho99 question above?!

I think it is not possible since gowin_pack.py did not set the IDCODE field before the PR I proposed. But with the PR it should work fine.

Are you saying that it should work now?
Or, that we need to wait a bit more for you to complete the PR??

If the PR is merged I think it will work assuming that the NS-4C silicon is supported. You just pass “GW1NSR-4C” as the device and the packer will fix the jtag ID.