Tang nano 20k support

[jeremyherbert]

Hi,

Is anyone working on support for the GW2AR-LV18QN88C8/I7 which is used on the Tang Nano 20k ?

I suspect that these two issues may be related:

#206 (NR is the same as N, but with SDRAM)
#181 (Same part family, no SDRAM and different package)

Just checking here before I start trying to have a look at it myself.

[yrabbit]

Tangnano20k is supported up to the point where it runs this RISC thing called ATTOSOC, look at the Makefile for examples:

apicula/examples/himbaechel/Makefile.himbaechel

Lines 9 to 13 in a4f04e0

	blinky-tangnano20k.fs shift-tangnano20k.fs blinky-tbuf-tangnano20k.fs blinky-oddr-tangnano20k.fs \
	blinky-osc-tangnano20k.fs tlvds-tangnano20k.fs elvds-tangnano20k.fs oddr-tlvds-tangnano20k.fs \
	oddr-elvds-tangnano20k.fs pll-nanolcd-tangnano20k.fs attosoc-tangnano20k.fs \
	oser4-tangnano20k.fs ovideo-tangnano20k.fs oser8-tangnano20k.fs oser10-tangnano20k.fs \
	ides4-tangnano20k.fs ivideo-tangnano20k.fs ides8-tangnano20k.fs ides10-tangnano20k.fs \

If you want to put things in order with R and NR, then PR is always welcome.

[jeremyherbert]

Thanks for the tip, I was looking in the examples folder only, not the himbaechel one.

I will have a look to see if I can work out something for the R/NR.

[pepijndevos]

We should really add it to the readme, we tell people to install from git anyway so I don't think we need to wait for a release

[chili-chips-ba]

@Juninho99 is stuck on this BRAM-related error. Any tips or advice on how to proceed from here?

[yrabbit]

nextpnr says that there are no descriptions for DPX9 primitives in the chip database.
So I'm wondering which version of nextpnr (nextpnr-gowin or himbaechel) you are using and which version.

And I’ll say right away that legacy gowin has no memory support.

[chili-chips-ba]

Thank you, that's good input, unfortunately not directly forthcoming from documentation.
As @Juninho99 has now upgraded to all the latest tool versions, and also moved to himbaechel, the new error is as follows:

[chili-chips-ba]

BTW, the design that's giving us this trouble is a game in which CPU writes into memory, while HDMI hardware is reading from it. So, it's dual-port BRAM...

• https://github.com/chili-chips-ba/openXC7-TetriSaraj

[yrabbit]

But this is exactly what follows from the documentation: Tangnano9k does not support Dual Port.

I'm a little confused by how you jump from 20k to 9k. :)

[yrabbit]

BTW, the design that's giving us this trouble is a game in which CPU writes into memory, while HDMI hardware is reading from it. So, it's dual-port BRAM...

• https://github.com/chili-chips-ba/openXC7-TetriSaraj

I must say that I am very glad that a project using BRAM has appeared - I myself am not very knowledgeable about this and it will be interesting and instructive to get your thing working. Especially if you don’t use primitives directly, but trust yosys to make the memory for you - this is generally a dark forest for me.

Unfortunately, at the moment, three days before the New Year, I can only answer the simplest questions and definitely do not have the opportunity to dive into the code. I had plans to deal with memory issues around January 7th, so don’t blame me for simple answers.

[chili-chips-ba]

.... thank you, your answers are super-quick in coming, and also very informative!

As the idea for this project came from @edmundhumenberger, kudos go to him :-)

@Juninho99 is a designer based in Sarajevo, Bosnia-Herzegovina, currently deeply at sleep, and anxious to answer your question first thing tomorrow morning /* while we believe he was able to use DP RAM on TangNano9K with Gowin tools, he is definitely in the best position to provide additional detail about it */

Yes, this BRAM is indeed inferred. Here is the first case:

//parameter MEM_INIT_FILE = "vid_ram.mem";
(* ram_style = "block" *) reg [3:0] map_ram [0:1199];   
// memory for 40x30 position Mega Character with value between 0-15 for CharacterID

and, here is the second:

//parameter MEM_INIT_FILE = "vid_ram.mem";
(* ram_style = "block" *) reg [11:0] ram [0:12287];   
// memory for 16 characters: 4095 for 640x480; 12287 for 1280x720;

The PLL is obviously instantiated. Juninho99 has it all working fine with Gowin proprietary flow. He is in the process of porting this design to open-source tools. We are all very enthusiastic about the value-add you see in enabling this project for nextpnr-himbaechel, and are here to do what it takes to make it happen.

[yrabbit]

Everything is possible, maybe Gowin made a mistake in the documentation: I have an edition dated May 25, 2023. If it really happened in Tangnano9k to use the DP primitive, then I will make changes in 1.5 weeks (or you yourself earlier).
I have not yet researched how yosys makes memory, so here you have the freedom to change the files https://github.com/YosysHQ/yosys/blob/master/techlibs/gowin/brams.txt and https://github.com/ YosysHQ/yosys/blob/master/techlibs/gowin/brams_map.v

[chili-chips-ba]

Gowin seems to be playing some yield optimization (bug engineering) games with their low-cost GW1NR family.
#210 (comment)

Here is what we know thus far:

1. We are with no doubt using their DP RAM on TangNano9K in Bypass + Read-before-Write mode

• Admittedly, the board is consistently crashing (in a way that almost looked like a short) when DPRAM is configured to Pipeline + Read-before-Write (@tibrahimovic has complete detail)

2. Gowin has subsequently rechristened GW1NR-9C to GW1NR-9
3. ... to then claim that the DP RAM was not supported at all in the "plain-vanilla" GW1NR-9

DS117-3.0E_GW1NR series of FPGA Products Data Sheet.pdf

We are reaching out to Gowin for additional detail...

[yrabbit]

You will still need to edit memory inferring - I made primitives that exist at the moment, and inferring was written in those days when primitives were called differently (roughly speaking, there was no letter B in the names).
This file can be edited without recompiling yosys, I think. correct DP -> DPB and DPX9 ->DPX9B
For me it is located along the path /usr/local/share/yosys/gowin/brams_map.v

https://github.com/YosysHQ/yosys/blob/ea7818d31bb2533d4ecceb2ed1bcf4a22b850453/techlibs/gowin/brams_map.v#L227

https://github.com/YosysHQ/yosys/blob/ea7818d31bb2533d4ecceb2ed1bcf4a22b850453/techlibs/gowin/brams_map.v#L269

[yrabbit]

These are the types of errors that I am going to look for and correct after January 7, 2024 :)

[chili-chips-ba]

... even the latest proprietary tool (Gowin_V1.9.9_x64_win) allows instantiation of DP BRAM for TangNano9K. Granted, the Read-before-Write mode is not available any more, and we are now left only with Write-Through and Normal. For the Read side, their latest tool seems to still allow Bypass and Pipeline.

Most importantly, 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 tools from Gowin...

[Juninho99]

Hi,
As @yrabbit said, I changed lines 227 and 269 in bsram_map.v (DP -> DPB and DPX9 ->DPX9B). Additionally, I need to make yosys. After that I started synth_gowin, but after a while I got this message "/usr/local/bin/../share/yosys/gowin/cells_sim.v:0: ERROR: Cannot find object for defparam BLK_SEL! " .

Is there anything else I can do with bsram_map.v or any other file?

[yrabbit]

These were the general instructions on how to experiment :)
Of course, you can correct it directly in the specified source file and recompile yosys every time, but I would simply find where in the system these files are INSTALLED and the edit them there. Without compilation. This makes it much faster to try different options.

Further, inderring was written (not by me) long before Gowin renamed the primitives and therefore the DP and DPB parameters are slightly different. You will have to work to ensure that they comply with the documentation (see below about the same BLK_SEL).

This is if you have the desire to dig so deep, of course, otherwise you can always go skiing or skating or celebrate noisily and wait until I finish the festive activity and get on with it. :)

[Juninho99]

Great. Thank you. I will definitely try something because the mountains around Sarajevo are now without snow (temperatures about 10C above zero)

[chili-chips-ba]

@yrabbit is your plan to, when holiday is over and these RAM issues behind us, also contribute nextpnr-himaechel to nix packaging system?!

[yrabbit]

Well, I have a feeling that this will not be a sprint, but a marathon, because I haven’t dealt with such high-level code that is used for inferring - I’m more into primitives.
And as for NIX, it’s very unlikely, because DragonFlyBSD is not among the supported platforms, and this is my main working OS; all the others are installed in very modest virtual machines.

[Juninho99]

Hello Yrabbit. I hope you enjoy your holidays. I would like to say that I tried something but without much success. After changing some things in 'bsram_map.v' and the synthesis worked, I ran into another problem, related to "cell type 'DP'". I will stop here with the file changes and await your intervention. As you said, it will be a marathon for sure.

[yrabbit]

Thank you.
Look, if nextpnr is trying to find a cell of type DP, then it was told to look for it. But there are no such primitives (they existed, but have already been excluded from the Gowin documentation, etc.), there are DPB and DPX9B, see if there is a DP in the JSON after synthesis and find a way to teach yosys to use the correct primitives instead.

[chili-chips]

We have filed an issue with Yosys team ( @cliffordwolf ).
YosysHQ/yosys#4098