Jack Gassett

Hey Thomas, I put this together because the number one complaint that people had in the back to basics thread was frustration with downloading and installing the tools and setting up the environment. This solves that problem... Think of it as a lightweight virtual machine, it has all the tools needed pre-installed but without the need to include the OS. Xilinx ISE, fusesoc, zpuino toolchain, a local version of cloud9, and could also include your bonfire toolchain and the arduino toolchain. It has everything pre-installed and configured to build bit files for the papilio board. If I had done this with virtualbox then I would have to include the OS inside virtualbox, we would easily be pushing a 30GB download really quick. With Docker we can setup a VM that does not require the OS and has the benefit of a centralized repository and compresses the download. If I remember correctly you only have to download 4GB or something like that for this setup. If you are already on Linux its super easy to get up and running. Just do a "apt-get install docker.io" and then the docker run command that I posted earlier. Docker does all the rest, it will download the virtual machine (called images in docker) and then run it in a container and bind the port 8181 from the container (think virtual machine) to your local machine port 8181. Then you just fire up a browser, connect to port 8181 and you are in a versio of cloud9 IDE that is running in the container (virtual machine) with a terminal window that has everything setup to make a bit file inside the container. The other thing docker will do is that it will map the workspace inside the container to the directory that you ran the docker run command in so you can work with the source files with cloud9 or any local editor you prefer. You just need to supply a Xilinx.lic file and you are up and running in a couple of minutes... Try it out, its magical. Jack.

Yes, cloud9 has a nice editor with VHDL support. But where it shines is that it integrates the environment needed to run code into a cloud IDE. You just connect to it and start coding, no installs and setup to deal with... Here is what the VHDL editor looks like:

I've been working on making a build environment that has everything needed to do Papilio development already installed and ready to go, including the Cloud9 IDE. This is a rough start and still needs a lot of work but might be worth checking out. Do the following to get it up and running on your local machine. You need to have Docker installed and working first, then: docker run -v $(pwd):/workspace -p 8181:8181 gassettj/papilio-environment-cloud9 --auth username:password You can get the ip address of the cloud9 instance by doing: docker-machine ls This will give you an ip address under the URL column. You can then open up a web browser at http://<the docker machine ip>:8181 and use username=username and password=password Once you are in cloud9 you will have to upload a Xilinx.lic file to the ~/.Xilinx directory (There is a upload tool built into the file menu). In the Cloud9 IDE you will see a terminal window, in that window type: git clone https://gitlab.com/Papilio-FPGA/papilio-quickstart-vhdl.git cd papilio-quickstart-vhdl/ fusesoc --cores-root=. build webpack_quickstart You should see the project build in the terminal window and you can navigate to the project source files on the left. Once the build is done you can right click on the bit file that is generated, download it, and run it on the papilio pro board. Still needs a lot more work, but is a pretty cool start!

Yes, I hear you, forking is not the long term solution. I forked the project because I needed to add special parameters to the tcl script that creates the .xise project file and I didn't see any support to do so in the code. I also wasn't sure if FuseoSOC was going to be suitable for what I wanted to accomplish so the quickest and easiest thing to do was just hard code what I needed into the part that generates the tcl script. The plan is to circle back around and either code the functionality I need and push it back to the main project or create an issue and request the functionality. Either way, the fork should just be a temporary thing while I'm figuring out the workflows that I need. The papilio base library can be added to a config file from what I've read, so the fork isn't needed for that. I'm not sure I've gotten as far as you have to really see this problem yet. But one thing I was uncertain about was how to update the cache? When I make a change to my base repository I have to wipe out the local cache and do a fuesesoc init again. There must be an easier way that I'm not seeing in the quick help... One of the problems I ran into is that I want to have my ucf files in the papilio-boards.core file and just add it as a dependency. I have to hard code a path that would be changing when the module changes version numbers which is not a great solution. The only thing I can think of so far is to add the ucf files as git submodules... So maybe a hybrid solution of git submodules and fusesoc is the best solution... Yes, absolutely, that is what I was thinking. Part of the problem that people have with using zpuino is that the board files are buried way down in the directory structure. I would like to get all of the files that you need to modify to customize a zpuino instance checked into a top level git project and then use fusesoc to pull in all the supporting files that people don't need to worry about. Would love some help along these lines and also integration with other projects. Also, I would like to branch out to Altera and ICE Papilio boards. I think fusesoc will help with creating and managing a common code base for non xilinx Papilio boards.

What is the behavior when it stops working? More details could help me give you better advice. You might try doubling your sample rate, maybe it not working is just that the sample rate is not high enough? When I test the SUMP core the main things I do is have the serial port send out the ascii table and then make sure that I can capture it. I'm almost 100% certain I did this with the SUMP core in the example you are using... But it's been a while so I don't remember exactly. The example in DesignLab should be the best one to work off, definitely don't use the wishbone interface one, that is not even close to being ready. jtagserver should be easy to port to linux, its a cygwin app under windows if I remember correctly. I just never had the time (and no one showed interest) to make any little changes needed to work under linux. Jack

Hey Blake, Are you talking about Jawi's OLS client or the original sump client? I don't recall ever seeing the problem you are talking about...

Ok, I made more progress today and have got ZPUino fusesoc cores designed and a vanilla version of ZPUino synthesizing for the Papilio Pro. These are the steps to recreate what I've done: git clone https://github.com/GadgetFactory/fusesoc.git cd fusesoc pip2 install -e . fusesoc init cd ~ git clone https://gitlab.com/Papilio-FPGA/Papilio-ZPUino-SOC.git cd Papilio-ZPUino-SOC fusesoc --cores-root=. build papilio-pro-zpuinoSOC The bin an bit files can then be found under: build/papilio-pro-zpuinoSOC_0/bld-ise/ It's also possible to make the ZPUino SOC the old fashioned way by doing: git clone https://gitlab.com/Papilio-FPGA/Papilio-ZPUino-SOC.git git submodule update --init --recursive make Next steps are to make a core to generate the bootloader.vhd file and to get this working in an automated fashion in Docker.

I'll see if we can start putting the invoice on the outside... We should be getting more Pro's in a couple of weeks if all goes well. Jack.

Ah! Sweet, thank you. I'm attaching it here too in case wayback machine loses it. Jack. YAVGA_Source_1.0.zip

Actually there is a readme that explains better how to setup the libraries so you can modify them. I'd make a fork of the github repository and then follow the readme, then you can track your changes back to github. https://github.com/GadgetFactory/DesignLab_Examples

Hello keesj, Generally what I would do if I was going to make changes to the libraries was to delete the library from the DesignLab-1.0.8/libraries folder and put it in my home directory under the Designlab folder. I don't remember the exact path but you should be a directory there for sketches and if there is a subdirectory for libraries it will use that. I would copy this entire github repository there and make my changes there and post them back up to github. https://github.com/GadgetFactory/DesignLab_Examples Also, please be advised that I am working towards a more sane method of managing libraries and code examples. It's just getting started but I think using FuseSoc is going to help us make things clearer, easier, and not depend on the Arduino IDE. The conversation is starting up here:

Hello keesj, Thank you for the heads up, I will see if I can put a change into github for this problem. Jack.

Ok, thanks for the heads up, we will look into what is going on... Jack

Here is the list of distributors, not sure they are all in stock at the moment though. http://store.gadgetfactory.net/distributors Jack.

I came across this article recently and wondered if anyone has any more details about this? https://www.patreon.com/posts/12886887 Jack.