Add IDCODE override

[jeremyherbert]

Some parts have the same "base" family as far as nextpnr is concerned but different IDCODEs (for example, GW1N-9 and GW1NR-9). This PR contains some work to change gowin_pack.py to override the IDCODE for the different parts as necessary.

related: #206

Still to do:

• get someone to check that I'm not breaking oss-cad-suite

[jeremyherbert]

Assuming that the nextpnr PR gets accepted, this should be OK for review now.

[pepijndevos]

What is the intended use for this? We mostly expect people to supply the full part number which we parse into the relevant parts to resolve the correct chip database. I consider passing a shorthand almost a legacy feature or implementation detail, because different parts of the tools care about different levels of detail, so it's better to just have a makefile for your project with the full device ID and pass that to all the different tools.

[chili-chips-ba]

... from our perspective, as users, the current need to specify both --family and --device is indeed a bit confusing and extra work, forcing us to look for definitions of the scope of each. And esp. so if tool --family classification is in the misalignment with Gowin's

[jeremyherbert]

For the tang nano 9k, you must pass the family as Gowin apparently shipped two different incompatible silicon dies with the same part number. So it will always be necessary to have the option to pass a family (or a new quasi-part will need to be added which doesn’t exist in the Gowin catalog).

[chili-chips-ba]

That's interesting!
You seem to be saying that the GW1NR-9 QN88P that comes with TangNano9K may have one of two different FPGA dies inside the package.

• What exactly are these two unintended variants?
  The more insight you can offer on the topic, the better.

[jeremyherbert]

From what I understand, there are two Gowin families that are distinct and incompatible, the GW1N-9 and GW1N-9C. However, you can’t tell what family the part is using the part number, you need to look at the date code on the IC to know. The IDCODEs are also different:

"GW1N-9": {
"idcode": "1100581B",
"base_family": "GW1N-9"
},
"GW1N-9C": {
"idcode": "1100481B",
"base_family": "GW1N-9C"
},

It also looks like the same problem may exist for the GW2A-18 and GW2A-18C, though they have the same idcode:

"GW2A-18": {
"idcode": "0000081B",
"base_family": "GW2A-18"
},
"GW2A-18C": {
"idcode": "0000081B",
"base_family": "GW2A-18C"
},

Having different base families here means that the hash of the device db in the Gowin tools is different.

[chili-chips-ba]

http://cdn.gowinsemi.com.cn/DS117E.pdf

Our hunch is that the "C" was their highest speed bin, but they at some point decided not to take that route, and standardize on the somewhat relaxed spec base edition, without "C" suffix.

GW1NR-9

• PFD range = 3MHz - 400 MHz
• VCO range = 400MHz to 1000MHz
• CLKOUT range = 3.125MHz to 500MHz

GW1NR-9C

• PFD range = 3MHz - 400 MHz
• VCO range = 400MHz - 1200MHz
• CLKOUT range = 3.125MHz to 600MHz

Such approach would certainly help them reduce operational expenses and increase yield, which all help keep the customer visible pricing very attractive.

We have seen similar discrepancies with their Dual-Port BRAM. @tibrahimovic has directly worked on that segment and can provide additional info.

[chili-chips-ba]

For completeness, here is the Dual-Port BRAM problem we ran into. This may also have to do with this part number restructuring, such as the feature that existed in GW1NR-9C, but was marginal in the GW1NR-9 :

• Design was working fine with DPRAM in Bypass + Read-before-Write mode
• but crashed (in a way that almost looked like a short) with DPRAM in Pipeline + Read-before-Write

Later on, a newer version of UG285 has eliminated the Read-before-Write mode for DPRAM configuration, along with timing diagrams for it.

[chili-chips-ba]

BTW, the proper part to use for TangNano9K is GW1NR-9C -- If we build for the GW1NR-9 target, the chip on the board returns IDCODE mismatch. This is all with the latest proprietary tool - Gowin_V1.9.9_x64_win.

#208 (comment)