6502.org

https://wiki.sipeed.com/hardware/en/tan ... o-20k.html

Reference system:
https://tildegit.org/potato/TangNano20K ... xperiments
I am implementing a system to explore the Nano2k and the GW2AR-18. Currently:
* 65c02 core at 70MHz (Arlet's enhanced core);
* 64K BRAM (less IO page at FE00);
* UART, 115200bps
* 6 LEDs output
* SD card (SPI mode), FAT16 support in progress
* Reset button

Software:
* bootloader/Wozmon ROM (768 bytes at $FCxx,$FDxx,$FFxx),
* TaliForth
* EHBASIC
* VTL
* figFORTH

Unused resources:
* 32KB BRAM;
* 2MB SDRAM;
* WS2812 (rgb led)
* IO pins
* HDMI output
* Audio

Relevant links:
viewtopic.php?f=10&t=8133&start=51 How to use command-line tools with the GOWIN IDE
https://github.com/venomix666/nano6502 venomix666 built full system including HDMI video, SDcard support, and CP/M

BigEd -- saw your Beeb message on the unboxing page. Did you ever get yours to work?

Yes indeed - in fact today, with various helpings of helpfulness from @hoglet, I got his BeebFPGA design running, with HDMI out to a monitor, SD card full of disk images, and a PS/2 keyboard connected through a cheap level shifter board. Oh, and a 1970s Radio Shack speaker on the board's sound output. (Dave's been porting the design to the tang 20k, and improving it, over the past couple of weeks.)

One thing we did find is that the boards I bought came variously and randomly with two different versions of firmware on the microcontroller - the older version worked exactly as advertised, and the newer version we found a couple of problems with: one, that the serial comms speed had to be configured at 4x the desired rate, and two, that the OpenFPGALoader doesn't presently succeed in loading a design. But the proprietary loader does work.

BeebFPGA can boot into one of four flavours of machine: Beeb (6502), Master (65C02), variously with or without 4MHz second processor. And there are two builds of the design: with and without the auxiliary debug processor, which offers single stepping, breakpoints, disassembly, and so on. The design includes a SID chip, the Music 5000 digital synthesiser, and RobC's VideoNuLA enhanced video subsystem.

This particular design is mixed VHDL and verilog, and presently we're building using the proprietary tools, which work pretty well, on windows, linux, and Apple silicon Mac.

It's a great board and I expect there will be lots more we can do with it.

Great! Is there more info on your project somewhere?

If you have any tricks to share, please do.

I am still trying to figure out the pinouts. The examples show pin 4 as clk input, and I am getting a warning that it is not a proper pin for connecting to the clock routing, etc:
WARN (TA1132) : 'clk' was determined to be a clock but was not created.
WARN (PR1014) : Generic routing resource will be used to clock signal 'clk_d' by the specified constraint. And then it may lead to the excessive delay or skew

I think the BeebFPGA documentation is in the github wiki - which hasn't yet caught up with the existence of this very new nano port, but the SpecNext part of the wiki will probably answer a lot of questions:
https://github.com/hoglet67/BeebFpga/wiki/Spectrum-Next

BeebFPGA also uses pin 4 as clock (sys_clk) and also gets a warning:
WARN (PR1014) : Generic routing resource will be used to clock signal 'sys_clk_d' by the specified constraint. And then it may lead to the excessive delay or skew

But I don't know what the relationship is meant to be between sys_clk (which only drives two PLLs to generate the actual clocks used in the design) and sys_clk_d (which doesn't appear in the source at all)

We don't see TA1132 and that doesn't look like a good warning.

I think this warning means you are missing a create_clock constraint from the SDC file. There is a dedicated path between pin 4 and the PLL1 clock input, but not the PLL2 clock input. That warning is letting you know that a bit of generic routing resouce is being used instead. So there may be a bit of additional skew between the two PLLs. The timing analyzer should tell you how much.

Dave

The Tangnano9k-65c02-experiments system configured right up -- with minor changes to the pinning.

Disappointingly, fMax is projected as 61.862 MHz, with the longest path via ALU timing at ~16ns. This is suspiciously almost identical to the 9K, and I wonder if something is stuck in the project from the 9K version, as the GW2AR-LV18QN88C8/I7 is roughly twice as fast in every way.[wrong, 9K was half speed, and 75MHz is current speed]

I have to investigate that clock constraint, and see about a few other things.

On the plus side, it looks like the PLL instantiation is the same as for the GW1, so I can still use the calculator at https://juj.github.io/gowin_fpga_code_g ... lator.html.

More bad news: it took 1min 46secs to build my system, with only 6% of logic utilization. Gah.

hoglet, have you had any luck specifying which PLL should be engaged?

I've not had any problems using both of the PLLs being driven from the 27MHz oscillator connected to pin 4. You can see the way the PLLs are instantiated in the VHDL here:
https://github.com/hoglet67/BeebFpga/bl ... k.vhd#L478

Are you having problems?

We also have the SDRAM working, doing random access cycles at 8MHz.

Dave

hoglet: no problems, just disappointed with build time and expected a higher fMax. Thanks for the link.

60MHz may be good, actually -- I looked at my notes for the Nano 9K, and 30MHz was as fast as I could get with GW1N. And the GW2N is twice as fast, so yeah.

Running solidly at 60MHz, with projected fMax of 60.3MHz.

The PLL calculator at https://juj.github.io/gowin_fpga_code_g ... lator.html does not have a 20K mode, but the 9K almost works. You just have to make sure that the VCO is >500MHz for it to work, by adjusting the ODIV_SELECT.

The longest timing paths seem to do with how I set up the IO muxes.

I am thinking of streamlining the IO mux, and maybe pipelining it with a wait state for IO operations.

BRAM investigation

I've been trying to figure out the best way to use BRAMs. For a full memory, the best arrangement is to aggregate 4 groups of 16Kx8, and use the high 2 address bits to control which group is active (disregarding IO mapping for now).

BRAMS have 3 block_select bits, and matching parameter bits which can be configured. The documentation is vague, stating something like "BSRAM selection signal for multiple BSRAM memory unit cascading to realize memory expansion". My assumption was that each BRAM can be configured to respond to a 3-bit 'address'.

I was hoping that BRAMS that are not selected set their output to 0, so I can OR them together instead of muxing.

But no, the waveform charts show 'INVALID DATA' when not selected. So a mux is still required on output.

What is the purpose of select bits then? Powering down the BRAM for lower consumption perhaps?

Xilinx BRAMS, if I remember correctly, have a configurable value that is output when deselected, and I think an output enable to allow ORing.

P.S. Confirmed: generated IP memory has muxes, and OR does not work.
One benefit: deselected BRAMS are not written to, and don't need an input mux.

The Gowin IDE -- the verilog compiler, anyway, does not like to loop over 2000 times.

So, with $readmemh you cannot initialize the top of your 64KB memory. You have to either create a big file containing mostly 00's, or load the bottom 2K (in my case), and copy it up using a verilog loop. But no, the limit is 2000!

Took me a while to figure it out, and copy 2 bytes with a loop of 1024.

There's a global attribute called syn_looplimit that should allow this to be increased.

Dave

Got SPI and SD card working. Enough to read sectors with fast SPI from a 16GB SanDisc card. Kind of psyched as the last time I tried with Chochi I gave up...

The SPI interface uses 30 flops, including clock generation for fast and slow clock and the shift register. Not bad.

My immediate goal is to parse enough of FAT32 to identify the location of a known file, and be able to read/write blocks into it. That would be at least good enough for FigForth blocks, or being able to page in code...