Jack Gassett

  • Content count

  • Joined

  • Last visited

Everything posted by Jack Gassett

  1. Papilio DUO Gameduino sketches not compiling

    Hello, Did you get this to work? I think the important thing is that you need to have the selected board as the AVR board and not the FPGA board. Jack.
  2. Programing Error Codes

    Hello, Did you get this resolved? If not can you post the full error message? I also suggest comparing the *.xise file with a known good xise file using a text editor to see what the differences might be. Jack.
  3. hamster tutorial help

    Excellent, glad you got that sorted out too. BTW, I'm working on new papilio pro examples over at gitlab. I've still got a long way to go but it might be interesting to see what you think. https://gitlab.com/Papilio-FPGA/papilio-quickstart-vhdl I've also put together a cloud environment so you don't have to mess around with installing Xilinx ISE to synthesize these new projects. You will need to place your Xilinx.lic file in ~/.Xilinx/Xilinx.lic for it to work. Keep in mind this is all just tests that I'm running, not really ready for prime time yet. But might be worth checking out if you are interested. https://codenvy.io/f?id=factoryyd01z6lgdawlk52f Jack
  4. Path of least resistance for beginner..

    Rob, Glad you got it working, there are tutorials over at http://learn.gadgetfactory.net that can help you get started too. Jack.
  5. DesignLab_Examples/00.Papilio_Schematic_Library/Libraries/Wishbone_Peripherals is outdated, you should use the other one... I will have to take a look later at how to update that library, it has been a while. Jack
  6. 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!
  7. AVR8 Core on Nexys 4 Artix 7 using Xilinx Vivado

    Hello Patrick, It shouldn't be too hard to compare the datasheet for RAMB4_S8 and compare it to the equivalent thing for the Artix 7 and then make the changes you need to make it work. I had to do that when I made it work for the Spartan 6, it was different memory block between Spartan 3E too. The other thing to figure out is if the tools to load code into BRAM is different between Vivado and ISE... Even if they are, maybe you can just use the ISE tool, data2mem. Good luck, Jack.
  8. Super Breakout preview

    Hello James, Killer! I'm curious about the tools, workflow, and methodology that you use while working on these games. Is it something you can write some more about? I don't know if you saw that I'm working on a cloud based ide solution for the Papilio, I can't help but wonder if we can package up everything needed to work on these types of games into Docker and make it easier for people to start hacking on these types of projects? What do you think? The big roadblock to this type of thing in the past has just been getting all of the tools setup to hack on your own arcade games. But if we can automate that process and just provide a link that people click (which I have almost ready to go) on and have a web ide with all the tools setup and ready to rock, then they can just look at source code and do stuff like change "High Score" to "My High Score" then it would be awesome.
  9. SPI MODE0

    Hey, Did you have any luck with this? I was sick all last week so was not watching the forums very well. This is a question that Alvie can probably answer easily, but I think a search of the forum might answer it too... I seem to remember a post about this topic before. Jack.
  10. This type of project would be a great candidate to get setup with Docker/Codenvy so all the files are in place and ready to go for people... Jack.
  11. I'm not sure, one of the downsides that I'm worried about is that maybe docker is too complicated for some people... I was looking at other options and Eclipse Che might be easier for end users. Eclipse Che is hosted as a cloud service at Codenvy.io and I was able to create what is called a Factory which is just a URL that people click on and it will automatically start up the docker environment, any example projects we want, and the eclipse che IDE. Here is an example: https://codenvy.io/f?id=factoryyd01z6lgdawlk52f (fuseSOC is not working correctly in this example but gives the idea of how easy this is for an end user.) Then if a user wants to be local there is a docker command they can give to pull their workspace down locally... The IDE is not as slick as the cloud9 IDE and there is no default support for VHDL and Verilog files. But, it looks like it uses the same standard as the VS Code so we can pull those modules into Eclipse Che and have nice support for not only VHDL/Verilog, but also code snippets, templates, and builders/wizards for ZPUino and Bonfire. I think it looks straightforward to get a graphical wave viewer supported too for simulations. I really don't know. I started down this path because I noticed that Xilinx has released an Amazon AMI (virtual machine) that has Vivado pre-installed and direct people to run the licensing tool after they start the AMI. I figured that if they were doing this then they must realize the benefits of this type of approach for their customers... Maybe they will shut it down at some point, but I have a backup plan. I'm thinking to develop an "agent" that will run on your workstation and that will be called from the cloud instance. When you invoke it, it will download all project source files, synthesize on your local machine, and upload the results back to the cloud server. Ultimately though, if Xilinx will not allow this type of use case then I will be migrating Papilio boards away from Xilinx and to other vendors that do allow it.
  12. 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.
  13. 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:
  14. In another discussion about getting back to basics FuseSOC was mentioned as a possible tool to manage HDL libraries. I've been looking over the documentation (which is extremely sparse) and think it might be a good fit. I'm attempting to first setup a simple project to autobuild with it. I added a FuseSOC .core file to this existing project: https://github.com/GadgetFactory/VHDL_Example_Code/tree/master/WebPack_QuickStart Then on a linux machine on AWS I did the following commands: sudo apt-get install python2 python-pip https://github.com/GadgetFactory/fusesoc.git cd fusesoc/ sudo pip install -e . cd .. git clone https://github.com/GadgetFactory/VHDL_Example_Code.git cd VHDL_Example_Code/WebPack_QuickStart/ fusesoc --cores-root=. build quickstart The result is a fully automated build process that creates a WebPack_QuickStart.bit file in the build/quickstart_0/bld-ise/ directory. I was unable to figure out how to make changes to the xise project file for things that we use with the Papilio so I had to fork the project and hard code the necessary changes for now. This is the commit I made: https://github.com/GadgetFactory/fusesoc/commit/5c69ec3a57f23e84d014686d96ea68c3225d1fab I added the following two lines to the tcl script that creates the project: project set "Allow unmatched LOC Constraints" true project set "Create Binary Configuration File" true The first one allows us to use a ucf file that has all the papilio pins defined without throwing up errors. The second line creates a bin file that can be loaded using zpuinoprogrammer. This is a good first step to test out automated builds, up next is using the library management features and then getting it under CI. Jack.
  15. 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.
  16. So Alvie and I have been talking and we want to work on a Wishbone version of the Sump Blaze Logic Analyzer core. The main benefits of this are: The ability to use SRAM, SDRAM, or DDR ram through the Wishbone bus via DMA transfers. This will get us much more memory available for the Logic Analyzer.It will be much easier to output the captured samples in different formats since it will be C code instead of VHDL code. It will be easy to add support for your favorite Logic Analyzer clients. Not only Jawi's OLS client but special modes for the Saleae client can be easily added as well.So to get the ball rolling on this effort I've made a special version of the Sump Logic Analyzer core that has its control interface mapped to Wishbone bus registers. This version still uses internal BRAM but I've setup a simulation test bench to make the transition to DMA transfers for RAM easier to work out. The branch on github can be found here: https://github.com/GadgetFactory/DesignLab_Examples/tree/Wishbone_Logic_Analyzer The commit is: https://github.com/GadgetFactory/DesignLab_Examples/commit/6019352579070f378304e9f710604b92e0f961cc Or if you prefer a ready to go zip file: Wishbone_Sump_LA.zip Just open the Chip_Designer.xise file, change to simulation mode, and simulate the Simulate_Your_Chip_Design module as the top level. The next step, moving to DMA memory, is something that's beyond my skills. Going to have to defer to Alvie's expertise for the next step, but am hoping to learn from the example of how DMA memory can be used with his new burst controller. Jack.
  17. SUMP Logic analyzer not responding

    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
  18. Wishbone version of the Sump Blaze Logic Analyzer

    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...
  19. 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.
  20. Best place to order from the EU

    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.
  21. Download Error YAVGA

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

    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
  23. Modifying the libraries

    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:
  24. CaseSensitive bit

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

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