All Activity

This stream auto-updates   

  1. Today
  2. 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:
  3. Last week
  4. did you get it figured out? if not, try this zipfile.. extract somewhere, replace the file bitfiles/RetroCade.bit with the proper one (the one there is just a place holder.. I don't use RetroCade so have no idea what bitfile to use..) run the (PapilioDUO_TB.bat) batch file and use option 6. the archive was meant for the papilio duo but in this case it should work for RetroCade.. didn't get around to making one for the PPRO =/ PapilioDUO_TB_(v1_1).zip
  5. FuseSOC for managing Papilio projects and libraries.

    I have seen Olof is very helpful and responsive. He also accepted a small pull request from me. I have the feeling that ISE is not so much on their focus, neither VHDL. Most people involved in FuseSoC have their roots in the OpenCores/OpenRISC movement and belong to a network of european open source hardware advocats, which at the end aim for open source ASICs. So they are quite open to suggestions on the ISE//VHDL flows. So e.g. supporting additional options for the tool section ([ise] in our case) should not present a big problem. Maybe at the we moment just aim for slightly different targets. You focus on a CI flow, I'm more focussing on the problem of managing my development work which currently targets two fpga boards (Papilio Pro and Arty) which use different tool chains. So I'm not "packaging" a finished project into FuseSoC, I want to use FuseSoC as a kind of "automake". It actually works very well for this purpose, especially with the --no-export option I can load the generated ISE project into ISE, analyze e.g. synthesis results and edit the source files at their original location. When I use the [provider] option, it works only with the committed/pushed version of the project. Yes. this is exactly what I'm doing currently, checkout https://github.com/bonfireprocessor/bonfire This was exactly what stopped me form using things like the uart from zpuino. The other topic for me was that zpuino use Wishbone pipeline mode a lot, which is incompatible with non-pipeline mode (bonfire uses wishbone burst cycles instead). But especially for uart, gpio and spi it should not be to hard to remove the dependencies to the zpuino packages and replace the required parameters with generics. Maybe I will give the uart a try as a first attempt. Do you have specific plans in this direction ?
  6. Sounds promising. I will hopefully try it out soon. I'm not familiar with Cloud 9, does it have an editor with VHDL support? I think the final target of your effort a cloud build environments or "casual users". For a local development workflow there is not really an alternative to have access to ISE and the isim gui to analyze and troubleshoot the code. On my local machine currently I use a combination of Geany as a lightweight editor with VHDL and build support, FuseSOC and ISE/isim. It works quite well. Maybe one day I will learn enough tcl do write a script which updates a FuseSoc core description with the changes from ISE (e.g. adding a source file). Thomas
  7. Help with Hamster Book tutorial (newbie stupid question inside)

    Hi Alvie ! First of all thank you for you taking the time for such a thorough answer: really appreciated I've used Excel in order to calculate the sine sample values, and your last formula: int(128+100*sin($n*2*pi/2048)) works as expected , giving values between 28 and 228, with 'n' from '0' to '2047'. The problem in Hamster Book's formula seems to be the '+1' after the sine (sine(n*PI()/1024)+1)*100), that you have ignored in your formula, that makes the multiplier of '100' to be between '0' and '2', instead between '-1' and '1', giving as a result a different range of values. Now to my Papilio ! Thanks again.
  8. Well the behavior is that the capture never completes. One small modification I did that appeared to improve a little was replacing the if(serial.available) by while(serial.available). I will perform more tests(also try @bnusbick's suggestion.
  9. zpuino processor

    Hi, I have Papilio Pro. I have encountered a lot of ZPUINO Soft Processor examples Emulation is no problem now. However, no matter how I look, there is no example to simulate zpuino Soft Processor. I am using zpuino - 1.0 version. xilinx ISE is in use. What I want to do is to have a simulation example of running the bin and hex files on top of the zpuino processor. Can you give me an example?
  10. Today
  11. 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!
  12. Last week
  13. 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.
  14. SUMP Logic analyzer not responding

    Try making channel 2 always high and see if OLS still stops working. Blake
  15. Wishbone version of the Sump Blaze Logic Analyzer

    Both Jawi's OLS client and the one that comes with Designlab 1.07 and 1.08 seem to have the same problem for me.
  16. FuseSOC for managing Papilio projects and libraries.

    Hi Jack, sounds great. I was in the meantime also able to build the bonfire project with FuseSoC. I will update the respective thread with instructions. I had some contact with Olof Kindgren, the author of FuseSoC. He fixed a bug I reported quite fast https://github.com/olofk/fusesoc/issues/175. My understanding is, that you have a own fork of FuseSoC which, among other things, also adds the "papilio base library". I think there must be a better way than forking the original sources. FuseSoC is in its infancy, and forking will either create much burden on reintegrating upstream progress or will cut off your version. I'm also not sure how to deal with this library stuff. I try to use FuseSoC not only as build tool, I try to integrate into my development process, e.g. for maintaining a common base for Vivado and ISE. When using the -no-export and some other options of FuseSoC it works quite well. The [provider] option in the core seems to interfere with this kind of workflow. because it has precedence over local source files when it is present - which means that FuseSoC clones the source into its cache and uses the cached versions to build. When looking at the fusesoc-cores lib it seems that they have a local core file in each repo (without [provider] section) and add a copy of the core file (with [provider] added) to their library repo. Not really an elegant way of doing things, a clear violation of the "don't repeat yourself" principle. To avoid this problems for the moment I have added a .core file to all the different part of bonfire, added them as git sub-modules to top-level project (which itself is almost empty). FuseSoC searches for core files in all subdirs of a cores-root,so running git clone, git submodule update and fusesoc build will do almost the same as using the [provider] section. Nevertheless, I think it could be an idea to decompose zpuino further into cores, e.g. for UART, SPI, GPIO. Do you (or Alvie?) have plans in this direction? I'm currently thinking of replacing the Bonfire SoC I/O modules with the ZPUino ones, providing them as cores would help (of course I can also help with this if you like the idea). Thomas
  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. Wishbone version of the Sump Blaze Logic Analyzer

    Jack, When I replace the following in LogicSnifferConfigDialog.java: result = String.format( "comm:%s;baudrate=%d;bitsperchar=8;parity=none;stopbits=1;flowcontrol=xon_xoff", with: result = String.format( "comm:%s;baudrate=%d;bitsperchar=8;parity=none;stopbits=1;flowcontrol=off", it no longer hangs when I send the test pattern, or when I make channels 0,1, and 4 high on the Papilio One 250K OLS client. Having a logic analyzer hang when it receives 0x13 during data acquistion is very undesirable to me. Blake
  20. Wishbone version of the Sump Blaze Logic Analyzer

    Hi Jack, I was able to debug the OLS application in Eclipse. When it was hanging, the host was receiving all 1024 characters, but was hanging when the host was in the loop sending CMD_RST five times. It was actually hanging the second time it sent the CMD_RST. When I modified the source so it would only send CMD_RST once, it hung on closing the port (it does this after every data acquisition). Since this seemed to be a driver issue below OLS, I went back to trying to figure out why it hangs when I send a certain sequence. I was able to isolate it the value 0x13, which is the flow control character. If I take the Papilio 250 with the standard OLS client and short channels 0, 1, and 4 to 3.3 volts, it hangs the exact same way (I am only using Channel group 0). I would think the solution would be to get both sides to ignore flow control. Do you have any thoughts on how to achieve this? I am running on Linux, so I don't know if it would display the same behavior on Windows. Blake
  21. 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.
  22. 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.
  23. 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
  24. Download Error YAVGA

    It's archived on wayback, I was able to download the source today. https://web.archive.org/web/20131110085527/http://gadgetforge.gadgetfactory.net/gf/download/frsrelease/156/524/YAVGA_Source_1.0.zip
  25. Best place to order from the EU

    I always order directly from Gadgetfactory, I live in Germany. In Germany thy only add VAT (normal rate, 19% in Germany). I order with US postal service, because of the fair price. They usually require a week for shipping to Germany, the remining time depends on the speed of German customs, sometimes they need a day, sometimes 4 weeks... I assume that in NL it should be similar. When Jack would place the invoice in a slip outside the package and not in ghe package processing would be much faster and no visit to the local customs office would be needed. But Im afraid that the Pro is also out of stock at GadgetFactory currently.
  26. perl -e 'use Math::Trig qw/pi/; foreach my $n(0..2047) { print int(128+100*sin($n*2*pi/2048)), "\n"; }' You should be able to translate this to other languages as well.
  27. Ok let's look at the formula. I have not actually read that part in the manual. For the sine argument it splits the full 2*PI range into 2048 entries - so if "n" on that argument ranges from 0 to 2047, it will yield a sinewave across the full 2*PI (360 degrees). It would probably made more sense to write it as "sine( (n/2048) * (2*PI) ). Assuming you indeed want the 360 degree waveform, The waveform amplitude is given by the "100" value - since the output from sine() will be between -1 and +1, the output range [ of (sine(n*PI()/1024)+1)*100) ] will be from -100 to +100. Since you need to bias the output for 1/2 VCC (it's an 8-bit output, no negative values, hence ranges from 0 to 255, "zero" is depicted by 128) you add the 128 bias. That will make the output range from 128-100=28 to 128+100=228. You can change the amplitude at will between 0 and 127. Exactly how to create the COE file... long time I used such tools. Alvie
  28. Help with Hamster Book tutorial (newbie stupid question inside)

    Thanks ! You're right, it's a math question and not a proper FPGA problem. I'm now using this formula: 127*SIN(n*2*pi/256) + 128 Almost surely I'm wrong, but I have the sentation the formula in Hamster book cannot give the expected 28 to 228 values. Thanks again.
  29. Help with Hamster Book tutorial (newbie stupid question inside)

    That's a math question rather than an FPGA question. I know that I've found read-made sine tables out there before, if math is not your thing you can probably find one already made. Another option is to just make something up using ballpark values, you don't even have to make it a sine wave, you can use the DAC to generate any arbitrary waveform you want.
  30. Load more activity