search

ZipCPU / arrowzip

A ZipCPU based demonstration of the MAX1000 FPGA board
21 stars 5 forks source link

Support for CYC1000 #10

Closed NeuerUser closed 5 years ago

NeuerUser commented 5 years ago

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:

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?

ZipCPU commented 5 years ago

Changing the flash size is the easy part. The size of the flash should be completely parameterized by the @$LGFLASHSZ tag in auto-data/flexpress.txt. Adjust that, rerun autofpga, and everything should be back to normal.

The same is true of adjusting the amount of block RAM: if y ou adjust @$LGMEMSZ in auto-data/bkram.txt, and re-run AutoFPGA, you'll have a new design updated for the new RAM size.

There is a consequence of these changes, however, you'll need to adjust the default ZipCPU boot address. This would be used in case you want the ZipCPU to start on a power up. (It's currently set to start halted, but that's a one-bit parameter change in auto-data/zipbones.txt). Specifically, inside auto-data/zipbones.txt, you'll want to adjust the @$RESET_ADDRESS tag to point to roughly a quarter of the way into the flash--or wherever it will not interfere with the design image file. Perhaps something like:

@$RESET_ADDRESS=@$(flash.REGBASE)+@$(flash.NBYTES)/4

As far as managing the revision ... I'm not sure. I'm open to suggestions.

Dan

NeuerUser commented 5 years ago

Hi Dan Is it also possible to allow the FPGA access to only the second half of the flash? A small write to the first would render the FPGA image defect.

ZipCPU commented 5 years ago

Anything is possible. But I think you are asking the wrong question. I think what you want is a that will never change the FPGA image, not one that doesn't allow the ZipCPU access to read the FPGA image. Since reading and writing are handled in software, that would need to be handled in the flashdrvr.cpp which issues the erase/write commands. The actual flash controller is designed to be so simple and bare bones that you can issue any command to it. Indeed, it assumes that you are old enough to be responsible with your hardware.

NeuerUser commented 5 years ago

As far as managing the revision ... I'm not sure. I'm open to suggestions.

Well, the code is pretty identical. Just a new qsf file, two different yaddr(i)o.v files, and two changes in two auto-data files, right?

So, I think the easiest to maintain that, and make it easy to synthesize is probably this approach:

I have already setup the second half of that (the Quartus part) and am trying to adapt the makefiles. Let's see if I can get it working.

ZipCPU commented 5 years ago

Ok, I finally took a look at the CYC1000 today. It doesn't look like it would be nearly as thought as I was expecting to create a CYC1000 repository or (better yet) to adjust this repository to handle both. I can also see how/why the argument for keeping a single repository would work.

Sadly, I don't have a CYC1000, so I'm not (yet) certain how I'd move forward with this issue.