Allowing family aliases for gowin

[jeremyherbert]

Hi,

Some gowin families have different names but that is because of how the SoC is configured, the FPGA silicon is still the same. For example, GW1NR-9C and GW1N-9C both work with nextpnr and have the same FPGA silicon. However, to get the GW1NR- 9C to work in nextpnr, you need to pass GW1N-9C as the family (no R), even though technically gowin considers them a different family.

I have modified apicula so that it fixes the IDCODE part of the problem, but I would also like to try to modify nextpnr so that when you pass GW1NR-9C, internally it knows that this is an alias and it goes back to GW1N-9C. I have modified apicula to generate a family_info.json file which maps the family to the "base family" (ie, the family corresponding to the FPGA silicon) from the vendor tools.

There are a few approaches I can think of, but I'd really like to know which would be best for me to pursue:

1. Copy or symlink the chipdbs during build so that all families are defined
2. Edit gowin/main.cc to load this JSON file at runtime and then change from the alias back to the base family
3. Generate some sort of cc file which contains the map for family -> base family at build time from the JSON, and then edit gowin/main.cc to look in this and change the alias to the base family
4. Something else?

One thing I have noticed is that there is no JSON reader in this project, so that sort of precludes option 2. And I'm not quite sure how to generate the cc file - are python scripts allowed in the build system? Or maybe it could be part of gowin_bba ?

I would appreciate any thoughts on this.

Related issue here: YosysHQ/apicula#206 and PR YosysHQ/apicula#210

[yrabbit]

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.

[jeremyherbert]

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)

[jeremyherbert]

Ah, I found my answer:

nextpnr/himbaechel/uarch/gowin/gowin.cc

Line 95 in 5bfe0dd

log_error("For the GW1N-9 series you need to specify -vopt family=GW1N-9 or -vopt family=GW1N-9C\n");

- you do pass the family arg for this case

[jeremyherbert]

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

[gatecat]

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

[chili-chips-ba]

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?

[yrabbit]

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.

[Ravenslofty]

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.

[chili-chips-ba]

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?

[chili-chips-ba]

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 ?

[Juninho99]

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?

[Ravenslofty]

• 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.

[Ravenslofty]

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.

[Juninho99]

• 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?

[chili-chips]

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

[jeremyherbert]

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.

[chili-chips]

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

[jeremyherbert]

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.