search

ZipCPU / arrowzip

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

Great article #9

Closed NeuerUser closed 5 years ago

NeuerUser commented 5 years ago

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.

ZipCPU commented 5 years ago
  1. The port.h issues has been fixed.
  2. Including pin definitions is a marvelous idea.
  3. Would love to hear a better solution to the hard path in sw/board/Makefile. I agree that it's an issue.

The slow flash speed

My plan for the slower flash speed is to integrate two ZipCPU programs into the flash loader. There's a little bit of trickery required of the compiler, since I'd want these two programs to remain the same even if the block RAM or the flash address(es) change. When done right, it'll keep the loader from needing to send the same data across the slow interface about 6 times. As currently designed, two ZipCPU programs will be used: an erase function of about 500 bytes and a write function of 830 bytes, including the data to be written. So, ... this is currently a work in progress.

If you want to be a part of working on this at all, then I can put my chicken-scratches into a new branch where you can see what's going on and the plan for moving forward. Similarly, the conversation on this topic should be moved to a new thread ... just to keep things focused and easy to find.

The slow debugger

Sadly, this is a known issue, and it dates back to how I built the zipbones/zipsystem debugging interface. These really need to be updated with a newer interface sporting a separate address per register. This would fix the issue, but it would also break every program I have using that interface. This has kept it from the forefront so far.

Size of the SoC

The size of the SoC is what makes this the ArrowZip project as opposed to the OpenArty (autoarty branch right now for AutoFPGA), the VideoZip project, the TinyZip project, or even the IcoZip project. All of these projects share a large amount of code, and use AutoFPGA to control their various interfaces. If you look around, you'll find the faster/pipelined CPU in the OpenArty and VideoZip projects, together with the faster/compressed debugging bus. You'll also find a GPIO module in those projects that would be nice to move over into this one.

This project, though, will be unique in supporting the accelerometer+A/D, since I don't have that chip on any of my other boards.

Dan

NeuerUser commented 5 years ago 
3\. Would love to hear a better solution to the hard path in sw/board/Makefile.  I agree that it's an issue.

I guess there is no perfect solution. I opted for using a relative path which assumes that you have the ZipCPU repo and the ArrowZip repo as two folders in parallel in the same directory. So:

INSTALLD=../../../zipcpu/sw/install

That assumes the following structure:

-- some_dir
          -- zipcpu
                     -- ...
          -- arrowzip
                     -- ...
ZipCPU commented 5 years ago

I'm closing this issue, in spite of the hard-path problem. Feel free to open a hard path issue if it's still a problem for you.