Thomas Hornschuh

  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

2 Neutral

About Thomas Hornschuh

  • Rank
    Advanced Member

Profile Information

  • Gender Male
  • Location Wiesloch, Germany
  • Interests RISC-V, FPGA
  1. 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 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 ?
  2. 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
  3. 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 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
  4. 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.
  5. 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
  6. 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
  7. 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
  8. 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)
  9. FuseSOC for managing Papilio projects and libraries.

    Maybe the problem is the path in the toplevel (constant TestFile :-...). isim is famous for segfaulting with errors of this type. dbus_cyc_o : OUT std_logic; dbus_stb_o : OUT std_logic; dbus_we_o : OUT std_logic; dbus_sel_o : OUT std_logic_vector(3 downto 0); dbus_ack_i : IN std_logic; dbus_adr_o : OUT std_logic_vector(31 downto 2); dbus_dat_o : OUT std_logic_vector(31 downto 0); dbus_dat_i : IN std_logic_vector(31 downto 0); irq_i : IN std_logic_vector(7 downto 0) ); END COMPONENT; constant TestFile : string := "../src/bonfire_cpu_0/ise/tb_bonfire_cpu/compiled_tests/timer_irq.hex"; --Inputs signal clk_i : std_logic := '0'; signal rst_i : std_logic := '0'; I run all my FPGA design stuff in different Linux VM, not using Windows anymore. Most command line things like git, etc. work better with Linux, and until recent there was also no RISC-V gcc toolchain with Windows.
  10. FuseSOC for managing Papilio projects and libraries.

    Hi Jack, I succeed to simulate the Bonfire CPU with FuseSOC. The example is limited to simulation because it is my CPU core test bench. Doing the same with the full Bonfire SoC will not be much more effort, I decided to make it in two steps, because my understanding of FuseSOC is that a project is composed of cores, so I want to try this approach and hope that the SoC can reuse the CPU as IP core. Nevertheless, it is easy to try it out: git clone cd bonfire-cpu git checkout riscv_fusesoc fusesoc --cores-root=. sim --sim=isim bonfire_cpu Is should compile the core in isim and run the simulation (of course ISE must be installed and in the path ). The result should look like this: at 395 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 655 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 875 ns(1): Note: Monitor: value 0x80000007 written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 1235 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 1495 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 1715 ns(1): Note: Monitor: value 0x80000007 written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 2075 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 2335 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 2555 ns(1): Note: Monitor: value 0x80000007 written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 2915 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 3175 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 3395 ns(1): Note: Monitor: value 0x80000007 written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 3755 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 4015 ns(1): Note: Monitor: value 0x0000000B written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 4235 ns(1): Note: Monitor: value 0x80000007 written to address 0x0000001 (/tb_cpu_core/Inst_monitor/). at 4495 ns(1): Note: Monitor: value 0x00000001 written to address 0x0000000 (/tb_cpu_core/Inst_monitor/). at 4495 ns(3): Note: Test finished with result 00000001 (/tb_cpu_core/). Unfortunately I have to find out how to complete the simulation. Currently you must hit Ctrl-C to stop it. But I'm really impressed how well it works. BTW: The RISC-V Test program the simulation executes is in Thomas
  11. Back to Basics

    Hi Jack, maybe the disappointment is caused by your "advertising" (e.g. Videos) could be misleading it shows simple "draw your circuits" examples. But in this discussion here are two guys expressing their disappointment? Are they representative? I must confess that I never downloaded Designlab, it was just not a fit for my requirements. Nevertheless, and I repeat myself, your products and your website are a great starting point for FPGAs. I think you have some bias on retro computing, which is not that bad, because retro computing projects also are a good starting point for digging deeper into the FPGA topic. Legacy technology is just better accessible. VGA and PS/2 is much easier to understand and implement than HDMI and USB for example. I think also ZPUIno is great, because it is a complete open source SoC with a clear system architecture. And given the example of Vivado IP integrator, schematic entry as tool for building a system from ready-to-integrate IP cores is not the wrong way. You just tried it with inappropriate tools 100% Agree. Maybe consider it to be independent of Papilio, this may open your work to a greater audience. Thomas
  12. FuseSOC for managing Papilio projects and libraries.

    Hi Jack, Great I will check this out. I did not take a deeper look yet into this, because CI is personally not a high prio for me. I learned about FuseSoc because I was at a conference from the "Fossi Foundation" They use FuseSOC as a base to LibreCores CI Maybe there are some opportunities to share. But at least your example motivates me to try out FuseSOC on the Papilio version of Bonfire. I'm already in the process of publishing the projects in an easy to reproduce form. My Github Repos currentlly only contain the RTL and not any toolchain specific files (e.g. ISE projects) which makes reproducing them hard. An obstacle for me is that I personally don't like python, which is really a problem nowadays given the popularity of this language. Maybe I need to overcome my aversion Thomas
  13. Back to Basics

    If this really makes the difference for somebody I think he has not enough patience for software or hardware development With Arduino everything is easy as long as you write small programs and can work with the polling model the Arduino libs. If you need to do something special (e.g writing interrupt handlers) you have to read Atmel manuals and doing all sorts of low level stuff. Also dealing with PROGMEM attributes, etc. Arduino tries to draw a nice simplified picture over MCU programming, it even tries to hide that it is C++ and give people that it is some user friendly beginners language. But immediately below this surface are lying all that pitfalls. I know it quite well, because I once published an Arduino Library for a RC equipment telemetry bus popular in Germany. It has now about 100 downloads and despite I tried to make it easy to use, from the feedback I get I would assume that only about half of the downloaders are able to successfully finish a application with it. Some of them are not even able to run the example. And only a very small fraction is on a level that they would understand the library and modify it. And given the tools, gcc may give better error messages than ISE, but with standard Arduino there is no possibility to debug code. In this sense Arduino (at least on the ATMEGAs) suffers from the same problem than the FPGA topic: The "professional" tools are proprietary and sometimes need expensive equipment from the Vendor. Nevertheless Arduino creates a great value in providing at least the easy entry: As starter you don't have to worry about JTAG adpaters, Fuse programming, and the hardware registers. You can start with what Arduino provides out of the box and then grow into as you go further. It just softens the "bare metal" experience of a raw ATMEGA or similar MCU. Indeed I found this also very helpful, having many years of development experience including systems programming, but never used a MCU before. But my experience with the Papilio Pro was equally positive. On the other hand the world has changed, the larger vendors like Digilent or Avnet became aware of a the "maker and hobbyist" market segment and came out with products where people like Jack will have a hard time to compete. With the proper board support packages you can connect I/O, memory and processing cores together to a system and then export the design to SDK and write the software on top of it. To use the DDR3 RAM on the board you don't need to read the 200 pages "Xiling Memory Interface generator" manual. Just move the RAM from the board view to IP Integrator. It sets up a MIG with the right parameters for the chip soldered to the board, you don't even need to edit a constraint file, this all works automatically. I think what Arduino has done to the industry is the "consumeration" of embedded electronics products. Vendors publish their official evaluation boards in Arduino form factor. "Professional" toolsets are equiped with Arduino compatible libraries. So I don't see the difference you mention. Is the Digilent Arty series (there are three boards in the meantime) a "FPGA evlaution board" or an "Arduino with a Soft SOC implemented in a FPGA? Thomas
  14. Back to Basics

    Hi, actually converting Wishbone to axi4 on the master side is quite easy. To write an AXI4 slave supporting all the bell and wristles may be hard, but the master require only support what it needs. When porting Bonfire to Vivado/Arty I build two simple Wishbone to AXI4 bridges. Now the toplevel of Bonfire is more or less compatible to Microblaze, it has an IC (Instruction Cache) and DC (Data Cahe) master which is burst capable, and a DP AXI4Lite port for peripherals. The both bridges (see attachments) are nearly identical, that could be combined to one with generics. But because AXI4Lite has much less signals I decided to keep them separate for convenience. A better solution may be to make axi4lite as a wrapper to axi4. The bridges collapse to around 10 LUTs when Vivado optimizes the design. They are just fitted to my requirements, support of AXI4 Burst transactions requires also Wishbone Burst support. On the other hand it don't support pipelined mode yet. Maybe you remember our discussion a while ago about the different bus implementation of ZPUIno vs. Bonfire. The bridges passed a run to Xilinx axi verification IP, so there protocol implementation is "correct". Nevertheless they are not very bulletproof yet, when master or slave prematurely abort a burst behavior is not defined. Also you need to make sure that the bridge and the Wishbone master use the same burst size. The nice part about AXI with Vivado is, that you can easily use the Xilinx Cores (like e.g. the Ethernet controller). And you can use the AXI Smartconnect, this is a universal bus connect which almost automatically adapt to the situation. It can for example convert between AXI4 and AXI4Lite, it can convert bursts to devices not supporting bursts, it can adapt to different bus widths and can cross clock domains and much more. Of course it is far away from the open source idea. But as long as we need to use the proprietary tools of the vendors anyway, why not use things that makes live easier from time to time Thomas wishbone_to_axi4lite.vhd wishbone_to_axi4.vhd
  15. Back to Basics

    OK, ISE is quite large and not the most user friendly (which is in my opinion also true for the "number one" IDE in general - Eclipse). But it is not really complicated to install. To blame Xilinx that does not run on MacOS X is a bit unfair, given the market share of Macs in typical hardware labs. ISE and Vivado run very well on Linux. Also getting a Web Pack license is not that complicated. When I started with the Papilio I got the example in Hamsters tutorial running after half a day, and this included the dirty hack required to get ISE running with Windows 10. FPGAs a very complex devices and synthesis of VHDL/Verilog to the FPGA hardware is much more complicated than writing a software compiler. For such I have great respect for people building such tools and don't agree with you blaming them. I also think that FPGAs will never be as easy and popular as Arduino, etc, but this not because of the tools, it is caused by the very concept. There are simple mucher fewer use cases for a FPGA instead of a MCU it will justify the effort (time and cost) of using a FPGA. Most things can be done easier in software, if it is to slow, in many cases you can just switch to a more powerful board to solve that problem. So I think "hobby" FPGA is limited to people like me, who are interested in the topic itself and wan't do design hardware. It was always my dream to design a processor and now I can do it. Does it make sense in an economical way? Of course not, my $100 FPGA board cannot do more than $20 (or even cheaper) board with some ARM Cortex-M clone. My real "productive" MCU applications (like telemetry sensors for RC model airplanes - my "other" hobby") are all done with Arduino mini boards. The have just a more convenient form factor... This is unfortunately not possible because the vendors document FPGAs in a way that it can be programmed without their tools. There is one exception: The project IceStrom from Clifford Wolf: He reverse engineered a specific FPGA family from Lattice Semiconductor and build a complete open source toolchain for it. Such a toolchain could be installed in a freely distributed VM or cloud solution. But I have no idea how long the iCE40 FPGAs will stay on the market. The release of IceStorm at least led to a high demand of the respective evaluation boards and out-of-stock situations. The iCE40 are also quite small, IceStorm only supports Verilog and no VHDL, the tools are also much less mature and user friendly than commercial too chains from the vendors. So for the moment I will stay with ISE and Vivado (for the newer Xilinx FPGAs). I cannot imagine that this makes any sense, to be honest. One of the advantages of FPGAs over a "fixed function" MCU is that you don't need to build in things you do not use. So instead of trying to understand some crazy complex I/O controller on an MCU I just create one in VHDL which has exactly the functionality I require. Muxes are the performance killer number one on FPGAs to my experience. For Block RAM I agree (Xilinx data2mem is exactly doing this). But for LUTs it does not make sense. Even if it is possible, the mapping can dramatically change with small deviations in the design. Of course it is possible to do manual technology mapping and instantiate LUTs with respective macros. There is one crazy guy doing this with a complete processor btw... But to be honest, making all this complicated things which as consequence makes it impossible to write your design as clean, readable and portable VHDL/Verilog coding just to avoid installing a tool and a license key is ridiculous. It is good practice in HDL design to rely on inference as much as possible instead of instantiation. Thomas