search

YosysHQ / apicula

Project Apicula 🐝: bitstream documentation for Gowin FPGAs
MIT License
446 stars 64 forks source link

Add IDCODE override #210

Open jeremyherbert opened 8 months ago

jeremyherbert commented 8 months ago

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

Still to do:

jeremyherbert commented 8 months ago

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

pepijndevos commented 8 months ago

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

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

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

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.

jeremyherbert commented 8 months ago

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

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

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

GW1NR-9C

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

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 :

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

chili-chips-ba commented 6 months ago

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.

https://github.com/YosysHQ/apicula/issues/208#issuecomment-1869962123