Thomas Hornschuh

Members
  • Content count

    55
  • 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. VHDL processes

    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
  2. FuseSOC for managing Papilio projects and libraries.

    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
  3. SDRAM controller for Papilio Pro

    What do you mean with "cartridge"?
  4. SDRAM controller for Papilio Pro

    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
  5. SDRAM controller for Papilio Pro

    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
  6. ISE Placement Error

    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
  7. SDRAM controller for Papilio Pro

    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?
  8. SDRAM controller for Papilio Pro

    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
  9. RetroArch running on FPGA.

    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.
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. 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.
  15. 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.