Thomas Hornschuh

Members
  • Content count

    46
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

2 Neutral

About Thomas Hornschuh

  • Rank
    Advanced Member

Profile Information

  • Gender Male
  • Location Wiesloch, Germany
  • Interests RISC-V, FPGA
  1. Papilio Pro still produced?

    Hi Papry, I can‘t speak for others, but at the end the DRAM is not that complicated, given that you don’t need to write all the code from scratch, there exist several implementations, one is the Hamsterworks controller. The latest version on his website unfortunately had a small issue which prevents running it out of the box. Here https://github.com/bonfireprocessor/bonfire-soc/tree/master/sdram you find my slightly modified version which definitely works (tested with a clock frequency of 96Mhz, its best you start with a clock close to it. When you build a design with it, you should definitely simulate it, there are two different simulation models for the SDRAM chip in the link above, I only have used the sdram_model.vhd yet. With simulation you will also easily understand how the thing works and how to run fast pipelined back-to-back reads or writes. The DRAM has some advantages over SRAM: It requires less adress lines and has 16 Bit width. So the peak throuput is actually nearly twice of a 8 Bit SRAM. If you are interested in a SRAM based board in the Papilio price range take a look at the Digilent Cmod A7, it works with the newer Artix-7 FPGA and 512KBytes SRAM, otherwise it is quite similar to the Papilio Pro.
  2. Docker is indeed not intended for "End Users", it is a product for DevOps professionals. Do use it you need also understand basically how it works. For example it is not a got idea to always execute the docker run command you mentioned above every time, because you will fill up your machine with containers. It is better to use only docker start/stop after the initialization. It helps of course to bundle independent software packages (e.g. ISE, fusesoc and the gcc toolchain for your favorite soft processor) into a reproducible environment. But it has also a lot of drawbacks. The question is what you want to reach. The cloud9/Docker approach would make senses when combined really with the cloud version of cloud9, running also the builder in the cloud. Combined with maybe some "extended" version of fusesoc to configure e.g. the slots of zpuino. For people that want to use the FPGA as a "super-flexible" Microcontroller instead of diving deep into FPGA design. In the meantime I have switched the workflow for Bonfire to FuseSoC. For editing and debugging I use ISE, but only on the project generated by FuseSoc (with the --no-export option). So i can use the comfort of ISE and isim, but have always a project structure which I can easily reproduce on a new computer/VM. I'm always trying to have an environment which I can recreate in a few hours. In the past I had often a development machine, maintained over years where I simply didn't know anymore how it was setup and was therefore also not able to break down the prerequisites of a project. Nowadays my development VMs are usually only a few weeks or months old and I frequently create new ones. So I will not update my Vivado 17.02 VM to 17.03, I will create a new one from scratch and move all my work over. I never install anything besides Office and a Web Browser on the host system (which usually is Windows). fusesoc helps a lot, because it is a tool chain agnostic method to organize and package HDL projects. BTW: I have started with the zpuino UART to isolate it and extract it to a FuseSoC project, I will post details soon.
  3. Hi Jack, I tried out the docker image and extended it with a "bonfire version": Added the riscv-gcc toolchain to it Added the lua 5.1 and some lua libs to it (is required for the eLua build system) Replaced fusesoc with "my" version Works really well. I think I will also add ghdl to it, than I'm finished. The only "drawback" I see with the current image, is that it runs only as root (I have tried the --user option of docker, but than it does not work correctly). Running with root means that using the image will clutter the users home directory (which is mapped to /workspace as volume) with lot of files owned by root.Have you build your image with a Dockerfile or "interactivly" with docker commit? Another question: Are you sure that Xilinx has no problem with providing a Docker image with ISE installed? Is releasing it without a license key "enough"? Thomas
  4. Hi Jack, I was able to start the container now. So on a first glance it works. But I'm still fighting with Docker, it runs only with sudo (as root), which also means that all worksapce files are owned by root. Most commands in the docker documentation didn't work, neither "docker-machine ls". The different docker versions/editions seem to have different commands. Can you tell me what docker version and eidition you installed? Thomas
  5. Ok, I was not aware that there is a local version of cloud9, my understanding was always that you need to connect to their cloud. I have some basic knowledge about docker, but not really experience with it. What you describe is hopefully a good way for people who want to "consume" reproduced FPGA IP, maybe reconfigure it a bit. When you need serious debugging you will at the end require at least the isim gui. I think a good IDE together with FuseSoC can easily replace ISE, but not the simulator/debugger. I hope I have a chance on the weekend to try it out.
  6. After taking a look at the Coud9 website I'm still a bit confused how things are setup, e.g. what runs in the cloud and what locally. I have seen that you can create a SSL connection between the build/tools machine in the IDE. Does this require a unique public IP address? Maybe you can outline the deployment setup you aim for.
  7. some updates needed

    The ISE Issue is well known, but as you have already found out, there are workarounds for that. On my Windows 10 machines I have no Issues with Papilio loader and papilio-prog. Do you have downloaded the latest version? Does the USB Serial Port of the Papilio appear as com port in Windows? Thomas
  8. 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 ?
  9. 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
  10. 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
  11. 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.
  12. FuseSOC for managing Papilio projects and libraries.

    Hi Jack, let us start with the good news: Your ghdl simulation run was in fact successful and as expected. The "failed" message is caused by my quick and dirty attempt to stop the simulator. Test finished with result 00000001 says that it was successful. The test bench contains a special "monitor port". Writing to address 0 of this port by convention marks the simulation end. Writing to other addresses are just debug values. I have now changed the testbench to stop the clock on simulation end, which also terminates simulation because there are no stimulus anymore. Just pull the latest commit. It also shows that ghdl is more reliable (or at least reproducible) than isim Your interactive isim run encountered the same problem as my first try with ghdl: It didnt find the std_logic_textio package. I learned in the mean time that this library is not really part of the ieee standard libraries, it is some extension from synopsis. I have still to find out, why it sometimes is found and sometimes not. ISE 14.7 definitely has it in its standard installation. For ghdl I added a local copy (check the bonfire-cpu/verify/std_logic_textio directory). The version of sim_MainMemory in the riscv_fusesoc branch is already adapted to load the local version. Maybe a quick work around, I have to dig deeper into it. Why isim segfaults for you is still strange. My first suspect was the small size of the fuessoc.elf in your listing. But my has exactly the same size. Nevertheless I think it is only some form of stub. If you dig deeper into the "isim" subdir you will find the following thomas@thomas-lubuntu1604:~/fusesoc_proj/bonfire-cpu/build/bonfire_cpu_0/sim-isim/isim/fusesoc.elf.sim$ ls -lh total 580K -rw-rw-r-- 1 thomas thomas 167K Oct 1 23:57 ISimEngine-DesignHierarchy.dbg -rwxrwxr-x 1 thomas thomas 385K Oct 1 23:57 fusesoc.elf -rw-rw-r-- 1 thomas thomas 0 Oct 1 23:57 isimcrash.log -rw-rw-r-- 1 thomas thomas 579 Oct 1 23:57 isimkernel.log -rw-rw-r-- 1 thomas thomas 11K Oct 1 23:57 netId.dat drwxrwxr-x 2 thomas thomas 4.0K Oct 1 23:57 tmp_save drwxrwxr-x 2 thomas thomas 4.0K Oct 1 23:57 work Can you check if isimcrash.log contains some content on your computer? In general sometimes it is hard to get things running.... My initial plan for this weekend was to make the whole bonfire for Papiplio working with fusesoc. But I started with the idea to back port the data cache which I developed for the Arty version to the Papilio. In simulation this was easy, but for some reason on the real thing it does not work. Synthesis is correct, I spend hours to analyze the post-synthesis netlist (I feel still exhausted from this exercise) but did not find any obvious problem, it looks ok. I wrote a lot of test programs. Now I'm at least at the point that I have narrowed down the problem, but still no idea why this happens. Thomas
  13. FuseSOC for managing Papilio projects and libraries.

    I have not found any reason, why it is not working for you. On the positive side, I successfully get the simulation working with ghdl. This option gives a makes fully open source test/verification possible. The main obstacle was that ghdl requires the files sorted by dependencies because it builds the work library incrementally. There are other differences and glitches, but my latest commit works with isim and ghdl. Thomas
  14. FuseSOC for managing Papilio projects and libraries.

    Edit, ignore the striketrough text... Strange. I suspect that there is some small bug somewhere in my HDL code which makes isim crash, I had such encounters in the past. Unfortunately I also had Isim crashes also on perfectly legal but possibly "unusal" VHDL code. As As a first try I will check the compiler warning about the empty Range. Can you attach the full log of the run ? What happens when you go to the build/bonfire_cpu_0/sim-isim directory and start ./fusesoc.elf manually? It should start with an ISim> prompt. If this works, what happens when you enter "run all" at the prompt? If your time budget allows you, it would also be nice when you try to run simulation in interactive mode in ISE, with opening the ise/tb_bonfire_cpu ISE project ? Most likely you need to adapt the path to the timer_irq.hex file. Thomas
  15. FuseSOC for managing Papilio projects and libraries.

    Does it isim support foward slashes in a path under Windows? I assume it should, but I’m not sure.., I tested the commands in my post above in a clean directory (on Linux)