Thomas Hornschuh

Members
  • Posts

    60
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Thomas Hornschuh

  1. With ISE it should be theoretically possible, because it is a X Windows application. So setting the DISPLAY env variable in Docker and enabling access to the X server from the container should make it working. I have not yet tried this on my own.
  2. Hi all, more than a year passed by since my last post. I made some progress with the Bonfire Project. Since a few days my new Project site is online: https://bonfirecpu.eu The main changes in the last year are: The build system is completely based on FuseSoC There is an Implementation on a Digilent Arty Board, with Networking, SD Card, etc There is a top level for the processor that can be directly used in a Xilinx IP Integrator Because this is a Papilio Pro Thread: The PaPro is still fully supported, only currently a bit lagging behind the Arty version. My choice to support Arty is that I wanted also a more "Mainstream" option with a Board which is can be more easy bought in Europe. I still like the Papilio Pro version very much, because it relies solely on Open Source RTL, while the Arty version uses Xilinx IP, mainly for the DDR SDRAM and the Ethernet Interface
  3. A non compressed bitstream has always the same size which directly relates to the type of fpga. For a spartan-6 lx9 it is around 330KByte (when I remember it right, I‘m currently traveling so I cannot check). But it is possible to attach additional data to the bitstream e.g. with a program like bitmerge http://hamsterworks.co.nz/mediawiki/index.php/Config_flash or the -a option of papilio-prog This additional data can than be read with a spi flash interface added to the fpga design. I‘m not sure if papilio-prog erase always sectors (64KB) or pages (4KB). The flash chip on the Papilio Pro supports both. Anyway, when I use the flash in the Papilio Pro for own data I always start at 512KB, this is on the save side.
  4. Normally it just erases the number of blocks the new bitstream occupies.
  5. Basically all your above variants will result in the same circuit on synthesis, because the processes will completely disappear and only the logic equations will remain. For such simple combinatorial logic the process statement is completely superfluous, you could just write the equations after the begin of your architecture section. For more complex circuits some hints: processes must be used for synchronous circuits (which depend on some clock signal as the only signal in the dependency list). processes can be used for combinatorial circuits (not depending on a clock) when the logic is to complex to be easily written with combinatorical statements. Be aware that the dependency list is a common source of error. How to organize processes is partly a matter of taste, but some restrictions should be observed: Every signal can only be set in one process, otherwise it will be a „multi driven net“ Synthesis tools often require specific patterns to „infer“ some logic (e.g. a RAM) from the description. Mixing some custom additional logic into the same process can confuse them. I usually group together things which belong together. For simulation it may depend on the simulator, but I think the total complexity of the circuit is the key factor for computing time, so don’t bother. To my personal experience the best coding style is the one which allows you to understand your code a year later. This applies to every code in any language not just VHDL. A usuable (far away from perfect) tutorial for VHDL is the „free range VHDL“ eBook, it is also linked somewhere on Gadgetfactory... Thomas
  6. Hi Olof, thanks for passing by. First I must say, that I'm only a happy GadgetFactory customer and Papilio Pro User. The big advantage of the Papilio Pro is that its SDRAM can be accessed with an open source soft core without having to rely on proprietary IP of the FPGA vendor. FuseSoC is a in addition a genius idea to solve the problem of having a tool vendor independent build description. I heard about LibreCores, FuseSoC and FOSSI at the FOSSIC RISC-V event last year in Munich. The funny thing is, that I didn't gave FuseSoC much attention until Jack started to play around with it after my hint. After his initial proof of concept I realized how easy to use FuseSoC is. In the meantime I updated Bonfire a lot, separated it into several FuseSoC cores, and also created a few Dockerfiles which allow to create a complete Build environment for Bonfire, including the RISC-V toolchain, ghdl for simulation and the tools to build eLua for Bonfire. Of course I have the same problem as you, lacking time, especially for Documentation. I have also a version of Bonfire / eLua running on a Digilent ARTY board including TCP/IP networking. Because its uses a Xilinx IP Integrator block Design (for accessing SDRAM and Ethenernet PHY with Xilinx IP) it cannot be build with FuseSoC yet. Maybe the tcl Script option you mentioned above will help to solve this. I already considered it. Also here the limiting part is that the cores are not fulfilling my own standards regarding documentation yet... Many thanks, I'm thinking about it. But as stated above I'm just a Papilio Customer Regards Thomas
  7. Hi Sergey, your wavewforms look a bit strange... First I see some "undefined" values (where the waveform is in the middle between 0 and 1). In a real circuit there are no "undefined" values, in an FPGA it will be either 0 or 1. When your code has something like if signal='0' then ... endif it will never execute the then part in a simulation when signal is e.g. 'X' or 'U' , but in a real circuit it will most likely fulfill the condition. So you should clean you design in the simulation that it does not contain undefined values expect in areas where you really expect it (e.g. on reset...). Than I'm wondering about your wishbone ack signal. I assume that every 1 pulse of the spi_data_ready is a new data word. Then I would expect one Wishbone write transaction with exactly one ack pulse. Put you have a lot of them without any change in data and address. So you write the same word a lot of times. This itself will not directly doing any harm, but it gives me a hint that your design is not working as intended. Maybe you should take a look into the Wishbone B4 spec (just google it please...) Thomas
  8. Hi Sergey, it will be hard to help you without having a look in your whole design. I'm missing also a lot of information about e.g. the data rate, the clock frequencies, the amount of data. It would also help to post e.g. simulation waveforms of the SPI and Wishbone interfaces. As an general advice I suggest you to strip down your design to the key building blocks and test them separately. You can also do this on the hardware. When you start with a design using block RAMs you can avoid a lot of pitfalls. BRAMs are dual ported so you can easily use read and write processes without taking care of data contention. The LX9 has 64KByte of BRAMs so it should be enough for some basic testing. Regarding simulation you should build unit tests for the parts of your design and check how they work. Maybe you can look at https://github.com/bonfireprocessor/bonfire-dcache/blob/master/tb_dcache.vhd as an example. It contains also test code to "consume" data from a wishbone master (process mem_simul). Thomas
  9. Hi Anirban, all pins in one so called IO Bank of a Xilinx FPGA share the same Vcc voltage. This means, that you need to assign them a IOSTANDARD with a compatible voltage. So you can for example mix LVTTL (which is 3.3V) and LVCMOS33, but not LVCMOS33 and LVCMOS25. I don't know the details of the Papilio One, but at the Papilio Pro which I use all IOBanks are connected to a 3.3V supply. Why the standard UCF for the Papilo One specifies the clock pin with LVCMOS25 I don't know. Thomas
  10. Hi Sergey, without referring to the actual source code it is hard to understand to what version of the controller you refer to (especially the "simple" one). As you noticed Hamsters Website is offline, so there is no documentation anymore. What I remember from my mind is, that he developed several version of the controller, they differ in complexity of their state machines and their performance. The most basic one he wrote just executed every DRAM access isolated (with opening the row, opening the column, reading/writing and then closing the row and going back to idle state). This is very slow, because every access to the DRAM requires more than 20 clock cycles. The more advanced versions support back-to-back read/writes, which means that several sequential accesses to adjacent addresses of the DRAM can be run much faster. Actually the latest version of his controller is not really "huge", it is around 550 lines of code and it is well commented. To understand it, you should read the SDRAM chips datasheet it describes quite well how it works. Once you understand it, hamsters controller looks quite straight forward. You should consider using my version of it (see link above), it worked in several Papilio Pro designs right out of the box. I usually use a clock frequency of 96Mhz, believe me, it works. I'm sure the Alvies version in zpuino is equally proven, looking in the source code I think it is based on Hamsters "older" design. It requires two phase shifted clocks (which can easily by accomplished), while the 0.6 version creates a phase 180 degrees phase shifted clock internally with the help of a ODDR2 block. The shifted clock is required to compensate for the pcb trace delays and ensuring that the control and data signals are stable when the clock arrives at the DRAM chip ("setup and hold times"). The zupino variant with the extra clock is more complex, but maybe works over a wider clock frequency range, because the phase shift does not depend on the frequency, it keeps constant. I never tried different versions of Hamsters controller, this latest ensures for example that the Flip-Flops in the IO Blocks of the FPGA are used, this is very important for reliable operation. You can verify this in the "Design Overview /IOB Properties" Node in ISE: In Column "Regs" "IFF", "OFF" or both of them must be reported for Inputs/Outputs/Bidirectionals. Are you using the SDRAM Controller directly or do you have e.g. a Wishbone interface in between? Have you tried my advice and simulated the design?
  11. Hi, the latest version of Hamster Controller on his website did not work without a slight modification on the Papilio. Here is a corrected version, which works for me in several designs on the Papilio: https://github.com/bonfireprocessor/bonfire-soc/blob/master/sdram/SDRAM_Controller.vhd The Fix is the "delay_line_length " parameter, which must be 5 for the Papilio. Clock frequency should be ~100Mhz. My version also has an "hold_row_open " parameter, which can improve performance in some applications (end reduce in others...). It holds the active row open until a different row or a refresh is needed. I also strongly recommend simulating the design, Hamster also has an sdram simulator (you can also get a slightly modified version here: https://github.com/bonfireprocessor/bonfire-soc/blob/master/sdram/sdram_model.vhd). You can also check with a simulation if your access to the controller works in the right way. If you like I can post a few simulation screen shots here to show how it should work. You should also install a bit file of a proven design, like socz80, Zpuino or for example: (this post contains a "monitor.bit" which you can upload into the Papilio. The boot monitor contains a DRAM test which can be started with the "T" command. It is just that you can verify that your Papilio Pro board has no hardware defect (unlikely but not impossible...) Thomas
  12. Unfortunately they say nearly nothing about the project. I think Sorg may be right for the moment, that they just use the ARM cores. But it can change in the future. I just took a quick look into the Retroarch/Libretro documentation. To my understanding Retroarch is the frontend (a kind of "Player" for the game engines), while the Libretro cores are the real implementation of the game. The interface between both are on the level of video output and controller input. The simplest way is that the core is doing all the rendering and just updates the frontend with every new image. This works for 2D or older games. When running modern 3D games there is an Open GL subset which the core can use. So the rendering in this case is done on the Frontend. Basically this architecture means that a Libretro core can also be implemented in the FPGA fabric (e.g. with a Soft CPU, etc.) and there is just a thin "interface" layer running on the ARM core for communication with the frontend. The Zynq 70XX devices did not contain a GPU, so video output is usually also realized in the FPGA fabric, there are predefined IP cores for this purpose which realize a framebuffer in the DDR3 RAM attached to the Zynq. So a possible setup would be to run the video frame buffer / HDMI output in the FPGA fabric, run a game core also in the fabric and use Linux/Retroarch on the ARM for all the mangement between these things. So everything is possible. It has the potential to move FPGA retro game implementations out of their nice. There are a lot of aggressively priced Zynq boards now entering the market. I'm even considering using a Zynq board for stand alone FPGA development, they just have a better price/ performance ratio than many pure FPGA boards. One additional advantage of the Zynq is that it has a high performance AXI port to the second level cache of the ARM core. One big problem with Softcore implementations on e.g. an Artix-7 is that without a Cache access to DDR RAM is very slow. But block RAM is to much limited to build a large enough cache.
  13. 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.
  14. 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.
  15. 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
  16. 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
  17. 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.
  18. 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.
  19. 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
  20. 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 ?
  21. 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
  22. 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
  23. 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.