zipcpu / arrowzip

A ZipCPU based demonstration of the MAX1000 FPGA board

ArrowZip

This design is currently a work in progress. The goal is to place a ZipCPU onto a $30 Max1000 FPGA, as sold by Arrow and Trenz Electronics.

If all goes well, this will include access to ...

• The on-board SDRAM. This includes not only the Verilog code to access this SDRAM, but also a simulation component for the SDRAM, as well as an AutoFPGA script to add (or remove) the SDRAM from this build.

  This capability now works.

• A dual-I/O flash, running in both XIP (Execute in Place) mode as well as a debug-bus configuration override. As with the SDRAM, this will include not only the Verilog code, but also a simulation component and an AutoFPGA script to add (or remove) the flash from this build.

  The flash controller now works as well.

• The on-board MEMS motion sensor.

  This last piece remains a work in progress.

20190307 Update: The SDRAM is working

1. The design now builds and runs, both in simulation and on hardware, using the flash controller.

2. The SDRAM controller now passes a memory test, and should be ready to use.

3. The I/O drivers are currently Intel generated IP. These still need to be replaced by references to the actual underlying drivers. However, if you create the I/O drivers yourself, then you can run the design as is.

To run this design ...

First, install Quartus, Verilator, and the ZipCPU toolchain.

To run from simulation, build the design (make) and then cd into the sim/verilated. Type "main_tb" to start the simulator. "main_tb -d" will start creating a VCD file at the same time. "main ../../sw/board/cputest" will load the CPU test into the ZipCPU. While running the simulation, you can telnet into "localhost 6956" to interact with the serial port of the design. You can also use the wbregs program to read and set various addresses peripheral and otehrwise within the design.

For example, "wbregs stopwatch 1" will start the stopwatch capability. "wbregs timer 0x130" will start a timer counting down from one minute and thirty seconds. "wbregs clock 0x210837" will set the RTC clock time to 9:08:37 PM.

To run the design on the device itself, build the design and then load it into the device (see the vendor's instructions) and then run "netuart" from the sw/host directory. You may need to give it the name of your serial port, as in "netuart /dev/ttyUSB0". (Both the simulator and netuart use the same network port, so you'll only be able to run one of these at a time.) You should then be able to use the wbregs program to interact with the various registers within the design. To load the cputest, run "zipload -r ../board/cputest" from the sw/host directory. You should then see a series of tests results posted on the serial port.

To reconfigure the design, such as to add or remove device or to adjust the amount of block RAM, you'll need to adjust the files in the auto-data directory and re-run AutoFPGA.

arrowzip's Issues

output of memtest

If I read the memtest prog correctly, it should turn on 5 of the 8 LEDs, right?
Well, after starting, the program just turns on all 8 LEDs. No output on telnet or netuart, which is to be expected, right?

$ time ./zipload -v -r ../board/memtest
ZipLoad: Verbose mode on
Halting the CPU
Loading: ../board/memtest
Writing to MEM: 00c00000-00c0039c
Clearing the CPUs registers
Setting PC to 00c00000
Starting the CPU
CPU Status is: 0000200f

real    0m4.846s
user    0m1.380s
sys     0m3.431s

Loading is pretty fast.

dumpflash not working

Before this test I had run "hello", so that the flash got successfully written to.

 ./wbregs version
00600014 ( VERSION) : [....] 20190309
$ ./wbregs buildtime
00600000 (BUILDTIME) : [..GC] 00114743
$ time ./dumpflash 
Before starting, nread = 0
VERSION: 20190309

READ-COMPLETE
The read was accomplished in 19 bytes over the UART

real    0m0.019s
user    0m0.000s
sys     0m0.013s

The file is 8MB large, but contains only zeros.

great project

I also got this board to learn about FPGA. It would be too great to also have the ZipCPU on this board.
But it looks very daunting to me. Do you think you can get it working?

Cheers

Michael

Where to continue?

Hi Dan

So, I have the design running on the MAX1000 now. I am, however, not sure if it works correctly, as I don't know the whole thing at all. Here are my observations so far:

• board consumes 134mA
• LEDs are running knightrider
• wbregs works when reading, but not when writing, it seems:

 $./wbregs BUILDTIME
00400000 (BUILDTIME) : [.!5(] 00213528
 $./wbregs VERSION
00400014 ( VERSION) : [....] 20190219
$ ./wbregs TIMER
00500044 (   TIMER) : [....] 00000000
$ ./wbregs TIMER 0x12345678
00500044 (   TIMER)-> 12345678
$ ./wbregs TIMER
00500044 (   TIMER) : [....] 00000000
$ ./wbregs FLASH
00800000 (   FLASH) : [....] 00000000
$ ./wbregs RAM
00600000 (     RAM) : [....] 00000000
$ ./wbregs ALARM
0050004c (   ALARM) : [....] 00000000
$ ./wbregs BUSTIMER
00500000 (BUSTIMER) : [....] 00000000
$ ./wbregs BUSTIMER 0x01
00500000 (BUSTIMER)-> 00000001
$ ./wbregs BUSTIMER
00500000 (BUSTIMER) : [....] 00000000

• zipload complains about wrong board

$ ./zipload ../board/cputest
Could not communicate with board (invalid version)

• zipdbg shows buserror:

Peripherals                   CPU State: 0x00000613 Supervisor mode
>PIC > 0x00000000<   WDT : 0x00000000    WBUS: 0x00000000    PIC2: 0x00000000
 TMRA: 0x00000000    TMRB: 0x00000000    TMRC: 0x00000000    JIF : 0x00000000
 MTSK: 0x00000000    MOST: 0x00000000    MPST: 0x00000000    MICT: 0x00000000

Supervisor Registers
 sR0 : 0x00000000    sR1 : 0x00000000    sR2 : 0x00000000    sR3 : 0x00000000 
 sR4 : 0x00000000    sR5 : 0x00000000    sR6 : 0x00000000    sR7 : 0x00000000 
 sR8 : 0x00000000    sR9 : 0x00000000    sR10: 0x00000000    sR11: 0x00000000 
 sR12: 0x00000000    sSP : 0x00000000    sCC :           Z   sPC : 0x0060000c 
User Registers
 uR0 : 0x00000000    uR1 : 0x00000000    uR2 : 0x00000000    uR3 : 0x00000000
 uR4 : 0x00000000    uR5 : 0x00000000    uR6 : 0x00000000    uR7 : 0x00000000
 uR8 : 0x00000000    uR9 : 0x00000000    uR10: 0x00000000    uR11: 0x00000000
 uR12: 0x00000000    uSP : 0x00000000    uCC :               uPC : 0x00000000


                                                     >00000000 (Bus Err)
 0x00600014 0x00000000  SUB        $0,R0              00000004 (Bus Err)
 0x00600010 0x00000000  SUB        $0,R0              00000008 (Bus Err)
>0x0060000c 0x00000000  SUB        $0,R0              0000000c (Bus Err)
 0x00600008 0x00000000  SUB        $0,R0              00000010 (Bus Err)

Any idea, how best to go forward? I still don't know this well enough...

hello.c

I'm having problems to get any output from the test program "hello".

$ ./wbregs version; ./wbregs buildtime
00800014 ( VERSION) : [....] 20190308
00800000 (BUILDTIME) : [....] 00081204

When I start zipload 'hello' the first time, I get an error:

 time ./zipload -v -r ../board/hello
ZipLoad: Verbose mode on
Halting the CPU
Loading: ../board/hello
Sending to flash: 01000000-01000134
Sending to flash: 01000134-01004a54
ERASING SECTOR: 01000000
Erasing sector: 000000
SECTOR ERASE FAILED!
ERR: Could not write program to flash

real    1m18.194s
user    0m0.323s
sys     0m1.361s

This seems to be the flash erase.

Starting a second time, no flash erase is done. Instead the code is written:

$ time ./zipload -v -r ../board/hello                                                            ZipLoad: Verbose mode on
Halting the CPU
Loading: ../board/hello
Sending to flash: 01000000-01000134
Sending to flash: 01000134-01004a54
Writing page: 0x01000000 - 0x010000ff
Writing page: 0x01000100 - 0x010001ff
Writing page: 0x01000200 - 0x010002ff
Writing page: 0x01000300 - 0x010003ff
[...]
Writing page: 0x01004900 - 0x010049ff
Writing page: 0x01004a00 - 0x01004aff
Clearing the CPUs registers
Setting PC to 01000000
Starting the CPU
CPU Status is: 0000000f

real    8m22.885s
user    1m45.880s
sys     4m4.044s

After taking this 8,5 min, there is no output visible, neither on telnet session, nor on the netuart console.

If I read the code correctly (which is rather small), it should output "Hello, world!".

Support for CYC1000

The CYC1000 (https://www.arrow.com/en/products/cyc1000/arrow-development-tools) is a sister board of the MAX1000. It is very similar, in size as well as the components used. The main difference is the FPGA. Instead of a MAX FPGA it is a 10CL025YU256C8G. This differs in so far as it is a.) much bigger (24kLE compared to the 8kLE of the MAX10, and twice the amount of RAM), b.) uses external flash to store its configuration and 3.) doesn't support analog inputs.

Interestingly, it is very easy to compile and run the arrowzip on that board with only minimal changes:

Fitter Status	Successful - Thu Mar 14 11:05:45 2019
Quartus Prime Version	18.1.0 Build 625 09/12/2018 SJ Lite Edition
Revision Name	CYC1000Zip
Top-level Entity Name	toplevel
Family	Cyclone 10 LP
Device	10CL025YU256C8G
Timing Models	Final
Total logic elements	5,568 / 24,624 ( 23 % )
Total registers	3025
Total pins	54 / 151 ( 36 % )
Total virtual pins	0
Total memory bits	265,216 / 608,256 ( 44 % )
Embedded Multiplier 9-bit elements	16 / 132 ( 12 % )
Total PLLs	1 / 4 ( 25 % )

All test programs (cputest, memtest and hello) all work perfectly fine!
The changes needed to get this working are very little:

• new pin definition file (qsf)
• exchange of the yaddro and yaddrio functions

There are still some small issues to be tackled:

1. The SPI flash is only 2MB big. The first MB is used to store the FPGA config and should not be accessible.
2. The FPGA has twice as much RAM, which could be used.

Can you direct me how best to change these settings? I guess they are somewhere in auto-data, right?

And how would you think it makes most sense to manage this revision? Adding a new branch within git or better a revision within Quartus?

Great article

Hi Dan

I read your article (http://zipcpu.com/zipcpu/2019/03/12/arrowzip.html). It is really very well written and contains lots of useful information. Thanks for publishing that!

I have a couple of remarks from my side as a beginner/user here:

Missing files in repo:

Great that you could get rid of the altera_gpio_lite file. Still, the repo is having some small changes needed in order to make it usable as is: 1.) it needs the pin definition file (qsf) 2.) "port.h" still has as a default the "jericho" hostname instead of "localhost" and 3) "sw/board/Makefile" is referring to "/home/dan/work/..." (I replaced that with a relative path; not sure though if that would be the best approach)
I can send you a small patch that adds the missing files and fixes the "jericho". These are really minor changes (the last 0.01%), but could help newbies like me.

Interface and Flash speed:

I completely agree. That is a major issue. If you really want to write programs that run on the arrowzip, then you can't always wait for 10 min to flash a simple "Hello World". I have no idea, howto fix this. Maybe a mixture of a faster interface (using compression?) and flashing locally via small helper program on zipcpu.
A faster communication would also help with zipdbg. Currently it takes about 5 seconds to move the cursor. So, for real on device debugging, it is rather useless. What do you think?

"Missing" functionality, e.g. accelerator

While I also think that the accelerator is not really needed, it would be fun to have. Additionally, there are also ADCs on the board that can read from several analog input pins (and even with the possibility to read the temperature of the board). And let's not forget there are of course many digital I/Os, which would be nice to be able to use. So, on top of the accelerator module, a module for GPIO usage and one for analog inputs would be great.

Size of the Soc on the FPGA:

While I agree that 5700 is not really "slim", I do think it doesn't matter. I believe that, instead, everything should be included that makes sense on the board, even if it goes up to 100% usage. Why? Because due to your great AutoFPGA, it should easily be possible for the user to comment out blocks such as the RTC etc, if the user needs more free space on the FPGA. Adding stuff is always more difficult than removing. So, I'd love to see a faster communication module, GPIO, ADC and accelerator support included, with the possibility to easily comment them out of the Makefile, if not needed.

As mentioned, these are just small suggestions. Your arrowzip is a great piece of work. I am sure many users of the MAX1000 will try it out.

Flash erase not recognizing finished erase

Hi Dan

As you already mentioned, there is an issue with the flash controller not recognizing the finished erase cycle. I thought I could make sense to follow that issue with a separate issue. So, here is the info:

$ ./wbregs version
00600014 ( VERSION) : [....] 20190309
$ ./wbregs buildtime
00600000 (BUILDTIME) : [..GC] 00114743
$ ./zipload -v -r ../board/hello
ZipLoad: Verbose mode on
Halting the CPU
Loading: ../board/hello
Sending to flash: 01000000-01000134
Sending to flash: 01000134-01004a54
ERASING SECTOR: 01000000
Erasing sector: 000000

** [not finishing at all even after 20 min]**

$ ./zipload -v -r ../board/hello
ZipLoad: Verbose mode on
Halting the CPU
Loading: ../board/hello
Sending to flash: 01000000-01000134
Sending to flash: 01000134-01004a54
Writing page: 0x01000000 - 0x010000ff
Writing page: 0x01000100 - 0x010001ff
[...]
Writing page: 0x01004900 - 0x010049ff
Writing page: 0x01004a00 - 0x01004aff
Clearing the CPUs registers
Setting PC to 01000000
Starting the CPU
CPU Status is: 0000000f

A second start then recognizes that the flash is erased and starts writing.

Error (12006): Node instance "dspi_ddr_csn" instantiates undefined entity "altoddr".

I am still very new to FPGAs and your AutoMake powered designs in special. So, please bear with me.

When I try to import this design into quartus, I get the following errors on design analysis:

Error (12006): Node instance "dspi_ddr_csn" instantiates undefined entity "altoddr". Ensure that required library paths are specified correctly, define the specified entity, or change the instantiation. If this entity represents Intel FPGA or third-party IP, generate the synthesis files for the IP.
Error (12006): Node instance "dspi_ddr_sck" instantiates undefined entity "altoddr". Ensure that required library paths are specified correctly, define the specified entity, or change the instantiation. If this entity represents Intel FPGA or third-party IP, generate the synthesis files for the IP.
Error (12006): Node instance "dspi_d0" instantiates undefined entity "addrio". Ensure that required library paths are specified correctly, define the specified entity, or change the instantiation. If this entity represents Intel FPGA or third-party IP, generate the synthesis files for the IP.
Error (12006): Node instance "dspi_d1" instantiates undefined entity "addrio". Ensure that required library paths are specified correctly, define the specified entity, or change the instantiation. If this entity represents Intel FPGA or third-party IP, generate the synthesis files for the IP.

This seems to emenate from the toplevel.v file, where there are the following instatiations:

	// Wires for setting up the QSPI flash wishbone peripheral
	//
	//
	// QSPI)BMOD, Dual SPI bus mode, Bus modes are:
	//	0?	Normal serial mode, one bit in one bit out
	//	10	Dual SPI mode, going out
	//	11	Dual SPI mode coming from the device (read mode)
	altoddr dspi_ddr_csn(
		.outclock(s_clk),
		.din({(2){ w_dspi_cs_n}}),
		.pad_out(o_dspi_cs_n));
	altoddr dspi_ddr_sck( .outclock(s_clk),
		// .din({ !w_dspi_sck, 1'b1 }),
		.din({(2){w_dspi_sck}}),
		.pad_out(o_dspi_sck));
	addrio	dspi_d0(.inclock(s_clk), .outclock(s_clk),
			.dout({dspi_datp[0], dspi_datn[0]}),
			.din({(2){o_dspi_dat[0]}}),
			.pad_io(io_dspi_dat[0]),
			.oe(!dspi_bmod[0]));
	addrio	dspi_d1(.inclock(s_clk), .outclock(s_clk),
			.dout({dspi_datp[1], dspi_datn[1]}),
			.din({(2){o_dspi_dat[1]}}),
			.pad_io(io_dspi_dat[1]),
			.oe((dspi_bmod == 2'b10)?1'b1:1'b0));

What am I missing here? Where do I find these modules?

Thanks!

[Enforcement] Variable defined before used in hbconsole.v.

According to the Verilog LRM (IEEE Std 1800™-2012) Section 6.5, all variables must be declared before they are used, apart from implicit nets. Without the `default_nettype set to none, the variable ps_full could be inferred as a local net by different synthesis tools.

This line uses ps_full before is declared.
Lines 156 to 170 of hbconsole.v can be moved above this declaration to accomplish the design intent.

RTC working ?

Hi Dan

Just a short question: Is it possible that the rtclight module is not really working?

I do have the regs CLOCK, ALARM, TIMER, STOPWATCH, but none of them counts in any case. I can set the regs, but they don't seem to change at all.

But maybe I am missing something...