search

YosysHQ / nextpnr

nextpnr portable FPGA place and route tool
ISC License
1.24k stars 237 forks source link

Allowing family aliases for gowin #1243

Open jeremyherbert opened 7 months ago

jeremyherbert commented 7 months ago

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: https://github.com/YosysHQ/apicula/issues/206 and PR https://github.com/YosysHQ/apicula/pull/210

yrabbit commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

Ah, I found my answer: https://github.com/YosysHQ/nextpnr/blob/5bfe0dd1b137e43d8ed85485552e126a6b7ee978/himbaechel/uarch/gowin/gowin.cc#L95 - you do pass the family arg for this case

jeremyherbert commented 7 months ago

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

gatecat commented 7 months ago

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

chili-chips-ba commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.

chili-chips-ba commented 7 months ago

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

Juninho99 commented 7 months ago

Question from @Juninho99: _gowinbba came with installation of Apicula project. That's the very file I am using for build with nextpnr-gowin. Is there an equivalent _himbaechelbba 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 _gowinbba. Do I need something similar for nextpnr-himbaechel, and how do I get that?

Ravenslofty commented 7 months ago
Ravenslofty commented 7 months ago

Question from @Juninho99: _gowinbba came with installation of Apicula project. That's the very file I am using for build with nextpnr-gowin. Is there an equivalent _himbaechelbba 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 _gowinbba. 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 commented 7 months ago
  • 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 commented 7 months ago

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

jeremyherbert commented 7 months ago

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 commented 7 months ago

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

jeremyherbert commented 7 months ago

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.