Extend SDRAM Documentation to Cover GW2AR-18 Devices

[Seyviour]

This pull request extends the existing SDRAM documentation to include the pinout of the embedded SDRAM on the GW2AR-18 devices, among other minor changes. The information provided is almost certainly correct and has been verified by analysing the vendor-generated bitstream from a design that uses the embedded SDRAM controller IP.

[pepijndevos]

Hey cool thanks. Have you tried actually using it?

[Seyviour]

I'm currently working on that. I intend to test it with nand2mario's controller. https://github.com/nand2mario/sdram-tang-nano-20k.

Am I correct to assume that if I can signal the existence of these IO pins in Apicula, then I can write matching constraints to allow nextpnr to use the pins in PnR?

[pepijndevos]

Sorta. Since they aren't external pins there isn't the usual pin mapping, so you have to constrain them to a specific location. I forget if we have cst syntax for this or if you have to annotate placement on the iob primitive directly.

[Seyviour]

Got it. I'll check to see what the cst parser can do. Thankfully, the locations of the IOB tiles are as expected.

[Seyviour]

The constraints can be specified in the IO[LRTB] format, and routing succeeds to the specified locations, or at the very least, nextpnr does not report any problems. I haven't dared to flash the FPGA with the bitstream because I suspect I'm missing something. I expect that there should be some sort of power connection to the SDRAM but I haven't identified that yet.

In other news, it turns out the Gowin IDE will tell you if a pin is an embedded SDRAM pin if you use it in a constraint.

[pepijndevos]

From what I remember from GW1NR-9 there wasn't any power connection.

One interesting thing to look at is LiteX, which uses LiteDRAM and has support for Gowin through the vendor toolchain but using its own DRAM core. Gowin just gave them the pinouts and chip model I think.

[Seyviour]

The way I see it, they would have seen no need to tell them about a power pin, since knowledge of it is not necessary to write a controller. Presumably, the Gowin tool silently makes the appropriate connection. I only started thinking about the possibility of a power pin after I looked at the datasheet of a different SDRAM device.

Would a constraints file like below be more suited to nextpnr or here. If in nextpnr, I suggest storing it under the gowin techlibs folder. Something like techlibs/gowin/constraints/GW2AR-embedded-sdram.cst

    IO_PORT "O_sdram_clk"  IO_TYPE=LVCMOS33 BANK_VCCIO=3.3;
    IO_LOC "O_sdram_cke" IOL13A;
    IO_PORT "O_sdram_cke"  IO_TYPE=LVCMOS33 BANK_VCCIO=3.3;
    IO_LOC "O_sdram_cs_n" IOL14B;
    .
    .
    .

[yrabbit]

it looks like a directory from yosys :)

But seriously - if no code in nextpnr is tied to this cst, then does it have a place in nextpnr?
On the other hand, you will add the use of SDRAM to apicula examples, right?

[Seyviour]

I believe you're right. It makes sense for it to be in Yosys. If nextpnr needs to know anything, we can put it in the chipdb. And if anyone wants to manually edit the constraints, they can get it in Apicula.

[Seyviour]

Good News, I think it's working 🥳 🥳

I am running the test that is in https://github.com/nand2mario/sdram-tang-nano-20k, and it is landing at the correct end state, represented by the LEDS.

I've had trouble getting the UART print to work since the routine uses the bit streaming operator and Yosys doesn't support it. But the LEDS say the test executes successfully!!!

That means I was wrong about the power pin, @pepijndevos.

This is all downstream of the incredible work you've done, @yrabbit. Routing was failing until a commit that you made on nextpnr yesterday :)

[Seyviour]

One thing to note is that, this datasheet http://cdn.gowinsemi.com.cn/DS226E.pdf states that the interface to SDRAM is LVTTL33, which we don't have currently, but I tried it with LVCMOS33 and it seems to work okay.

[yrabbit]

One thing to note is that, this datasheet http://cdn.gowinsemi.com.cn/DS226E.pdf states that the interface to SDRAM is LVTTL33, which we don't have currently, but I tried it with LVCMOS33 and it seems to work okay.

Interesting. At what stage exactly do you get the error and which one if you specified LVTTL33?

[Seyviour]

I got it while running the packer.

I also have a small repo here that has the constraints if you want to try it out. https://github.com/seyviour/sdram-tang-nano-20k-os-example

[yrabbit]

yeah, we will need to do something with the packer. Not that this is critical - these modes are practically aliases, but VCCIO needs to be handled.

[pepijndevos]

Merging this since it seems to work 👍
Of course always happy to have further improvements and examples in a follow up PR :)

[Seyviour]

Thanks for merging! I will add an example as soon as I can. What folder would it be appropriate to place that in? I hope the steps in the repo I shared suffice for now.

[pepijndevos]

Probably somewhere in examples/himbaechel, in its own folder if it's multiple files.