Thomas Hornschuh

Members
  • Posts

    60
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Thomas Hornschuh

  1. 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

     

     

  2. 11 hours ago, dindea said:

    Thank you for the info, Thomas Hornschuh. It was as I hoped. But what do you mean by "Normally"? Are there cases when the entire flash is erased?

     

    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.

  3. 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

     

  4. 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.

     

    On 14.2.2018 at 10:17 PM, Olof Kindgren said:

    Also, make sure to register your projects at librecores.org.

    I already considered it. Also here the limiting part is that the cores are not fulfilling my own standards regarding documentation yet...

     

    On 14.2.2018 at 10:17 PM, Olof Kindgren said:

    Consider this also an invitation to our yearly conference, ORConf. We would love to see some presence from the Papilio corner and I believe many in our audience would like to hear a presentation of your work

    Many thanks, I'm thinking about it. But as stated above I'm just a Papilio Customer ;) 

     

    Regards

    Thomas

  5. 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

     

     

     

  6. 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 

     

  7. 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

     

  8. 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?

     

  9. 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
     

     

     

     

     

  10. 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. 

     

     

     

     

     

     

     

     

     

     

     

     

  11. 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.

     

  12. On 31.10.2017 at 1:19 AM, Jack Gassett said:

    I'm not sure, one of the downsides that I'm worried about is that maybe docker is too complicated for some people.

    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. 

     

  13. 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
     

     

  14. 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
     

  15. 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.

     

  16. 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
     

  17. 13 hours ago, Jack Gassett said:

    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.

    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. 

     

    14 hours ago, Jack Gassett said:

    I'm not sure I've gotten as far as you have to really see this problem yet.

    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. 

     

    13 hours ago, Jack Gassett said:

    So maybe a hybrid solution of git submodules and fusesoc is the best solution...

    Yes. this is exactly what I'm doing currently, checkout https://github.com/bonfireprocessor/bonfire

     

    13 hours ago, Jack Gassett said:

    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

    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.

     

    14 hours ago, Jack Gassett said:

    I would like to branch out to Altera and ICE Papilio boards

    Do you have specific plans in this direction ?

  18. 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

     

     

  19. 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

     

     

     

  20. 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.