Thomas Hornschuh

Members
  • Content count

    60
  • Joined

  • Last visited

  • Days Won

    2

Thomas Hornschuh last won the day on October 10 2017

Thomas Hornschuh had the most liked content!

Community Reputation

2 Neutral

About Thomas Hornschuh

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Wiesloch, Germany
  • Interests
    RISC-V, FPGA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Awesome. I will check it in the next days.
  2. 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.
  3. Thomas Hornschuh

    RISC-V on Papilio Pro

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

    Flash Erase

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

    Flash Erase

    Normally it just erases the number of blocks the new bitstream occupies.
  6. Thomas Hornschuh

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

    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
  8. Thomas Hornschuh

    SDRAM controller for Papilio Pro

    What do you mean with "cartridge"?
  9. Thomas Hornschuh

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

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

    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
  12. Thomas Hornschuh

    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?
  13. Thomas Hornschuh

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

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

    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.