mkarlsson

Members
  • Content count

    284
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by mkarlsson

  1. mkarlsson

    Boo

    Well, I do have a github account but have been bad at updating it. The opl3 code for pipistrello can be downloaded here: http://www.saanlima.com/download/pipistrello-v2.0/opl3_pipistrello_lx45.zip The latest doom bitfile for pipistrello is here: http://www.saanlima.com/download/pipistrello-v2.0/doom.bit The latest doom c source code is here: http://www.saanlima.com/download/pipistrello-v2.0/mb_doom_sound3.zip Without support for Spartan6 in Vivado and no more updates for ISE, the old Spartan6 boards are unfortunately getting obsolete, and with the subsidized pricing of the Digilent Arty boards etc. there is very little incentive for me to develop Artix7-based replacement boards Kalmar is a nice place with a castle and all. We have an apartment in Örebro that we use as a home base in Sweden.
  2. mkarlsson

    SoundBlaster FM HDL

    I think I nuked too many files in the ipcore_dir folder for it to compile so I just downloaded the whole project again, this time with all the files. If you have problems building it just re-download the zip file. Magnus
  3. mkarlsson

    SoundBlaster FM HDL

    Here is a video of it running on a Pepino LX9 board: http://www.saanlima.com/videos/IMG_4882.mov If you have a Pepino LX9 board and want to try it, here is how: Download the zip file opl2_pepino_lx9.zip and unzip it somewhere Place the files in the dro directory on a micro-sd card and put it in the sd-card socket on Pepino Open up a terminal (like Putty) at 115200 baud connected to the Pepino board Load or flash the bitfile opl2player.bit in the opl2player director At the promt on the terminal, enter the name of the dro-file you want to play (it will loop forever). Stop it by entering S. BTW, the code should work on a Papilio Pro by modifying the .ucf file to match the pins for the sd-card and audio wings and re-synthesize. Magnus
  4. mkarlsson

    SoundBlaster FM HDL

    Bringing this old thread back to life... In my quest to get a fully working version of Doom (including music) running on Pipistrello I found Greg's OPL3 project and decided to port it to Verilog as he mentioned above, and got it running on Pipistrello, as well as an OPL2 version running on Pepino LX9 (100% of slices occupied!). It uses a Microblaze_mcs processor with 32K ram to play .dro files. Here is a link to a zip file with the Pepino_lx9 project (including Verilog sources and a simple dro-file player): http://www.saanlima.com/download/pepino-v1.1/opl2_pepino_lx9.zip Video of it running on Pipistrello: http://www.saanlima.com/videos/IMG_4880.mov Cheers, Magnus
  5. mkarlsson

    Boo

    Hi Alex, long time no hear.. I made the opposite trip some 30 years ago (Sweden to US) but still have my roots there and go back several times a year (actually going there this coming Wednesday). I finally got around to work on one of my old projects that I left unfinished - Doom running on Pipistrello. The project was based on a port of Chocolate Doom to the NIOS soft processor by two guys from Finland and I got it to sort of work but had not realized how much they had sacrificed to get it to work on NIOS. The sound system was completely hacked up (8 channel stereo sound effects cut down to a single mono channel with no volume control) and the game crashed at the end of the first level due to non-implemented stuff. So I put back the original code from Chocolate Doom so the game worked and got the full sound system working by porting over the sound mixing from the Linux version of doom. I also added mouse support so the game is now really playable. The only thing really missing now is to play the music tracks. They were implemented in a format similar to MIDI and played on DOS via an OPL2 or OPL3 chip found on some sound cards. I looked around I found that Greg Taylor had done a clone of OPL3 using systemVerilog running on a ZYBO board so I decided to try a port of that code to plain Verilog (since ISE do not support systemVerilog). After some stuggle (systemVerilog has some powerful features that are hard to replicate in Verilog) I got it to work - both the full OPL3 and cut-down version that only support the OPL2 features (Doom only use the OPL2 subset). The OPL2 version fits in an LX9 together with a Microblaze_mcs system. Here is a link to a video showing it running: http://www.saanlima.com/videos/IMG_4880.mov Next thing is to incorporate it into the doom version. Cheers, Magnus
  6. mkarlsson

    Flash Erase

    See page 77 in this document: https://www.xilinx.com/support/documentation/user_guides/ug380.pdf The flash chip is erased in units (aka sectors) of 64kB so programming a 65kB bitfile will erase a 128kB area. Magnus
  7. 1) download this tar file https://www.xilinx.com/member/forms/download/xef.html?filename=Xilinx_ISE_DS_Win_14.7_1015_1.tar&akdm=1 2) untar the file somewhere on you computer (7-zip can do this for you) 3) go to the location of the untar'ed files and run xsetup.exe 4) after installation you need to fix a few things in order to have it run on win10. See https://www.eevblog.com/forum/microcontrollers/guide-getting-xilinx-ise-to-work-with-windows-8-64-bit/ The PlanAhead part is optional (not needed for DesignLab)
  8. mkarlsson

    How does data get from the PC to the Spartan-6 Flash

    Xilinx call it indirect programming. See https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_c_introduction_indirect_programming.htm The second serial port is available as a regular serial port (virtual COM port) to the user for any purpose. It's commonly used with a soft CPU to implement an embedded system. Magnus
  9. mkarlsson

    How does data get from the PC to the Spartan-6 Flash

    Almost got it right First a a flash programming bitfile is sent to the FPGA via JTAG. This bitfile uses a special library component (BSCAN_SPARTAN6) that allows the logic fabric to access the JTAG port. Flash SPI programming commands are then sent to the FPGA via JTAG, which will forward them to the flash chip. Magnus
  10. A new version of the Open Bench Logic Sniffer code is now available for Pipistrello. This version has the capture buffer increased to 64 MB by using the onboard LPDRAM instead of using internal BRAM. The capture rate is still the same, i.e. it still support 200 MHz 8 and 16-bit capture as well as 100 MHz 32-bit capture. The serial communication speed is set to 921600 baud. The original SUMP protocol unfortunately has a capture size limitation (in both hardware and software) to a maximum of 256k samples (512k samples in mux mode). This version of the verilog code has an alternative set of capture size registers that will allow up to 256M samples. However, the SUMP client on the PC must be modified to take advantage of the new registers so I have modified JaWi's OLS client to allow longer captures. BTW, the bit file will also work with the current release of the SUMP client but with the capture size limitation mentioned above. Here is a link to a zip file that has the bit file, the full Xilinx ISE project and the modified version of JaWi's OLS client: http://www.saanlima.com/download/pipistrello-v2.0/Pipistrello_OLS_64M.zip Enjoy! BTW, if anyone is interested in using the built-in DRAM memory controller in Spartan-6 parts this code might be a good starting point. It's setup to use one 64-bit read/wire port but this can be changed by using different parameters when instantiating the memory controller block.
  11. mkarlsson

    Open Bench Logic Sniffer with 64MB capture buffer

    Sorry but I stopped following the sigrok/pulseview stuff years ago since the development was in my view not the way to go unless you are prepared to do all the compiling yourself. Windows is supported in a very limited way with the nightly build of whatever development code they have that day. However, you can build the windows installer of the last release code on a Linux system yourself if you follow the instructions. The biggest problem is that on windows you need to replace the FTDI driver for the FT2232 chip with a driver based on the Linux libftdi driver. I have not managed to get that working since early 2014. This is really a question to the sigrok team though.
  12. mkarlsson

    Back to Basics

    At work we have switched most of our Spartan-6 products to Artix-7 and for the most part the switch-over was painless, the only area that needed a bit work was places in the code where we directly instantiated low level design elements (like serdes blocks, BSCAN_SPARTAN6 etc.) that had to be re-coded using 7 series elements, and the new way of setting contstrains. However, one area that Xilinx keep messing up is LVDS outputs, which we use lots of. On the Spartan-6 part that we used, only 2 of the 4 banks could have LVDS outputs. On Artix-7 all banks can have LVDS outputs but the bank must have VCCIO set to 2.5V! This means that Digilent boards like Arty and CMOD A7 and Avnet boards like miniZed etc. can't do LVDS output at all since all banks are powered by 3.3V! This is pretty lame since LVDS is the future for high speed I/O, just look at UHS-II sd-card standard where 2 LVDS pairs are added for high speed applications. As for my FPGA "hobby" busyness, I have no desire to develop an Artix-7 or Zynq based board and compete with heavily subsidized products from Digilent and Avnet. And there won't be any more Spartan-6 based boards made by me either (Pipistrello LX45 and Pepino LX25 are sold out and discontinued and once the Pepino LX9 boards are sold there won't be any more boards made). End of the road... I totally agree. I have a long history of designing custom chips, starting in the 1980's with schematic-based design entry for ASICs. When we switched to text-based design entry (i.e. HDL) in the 1990's the productivity gain was incredible. We could do much more complex designs and still understand what it did, and we could use all the tools developed for software to maintain the code (like CVS for code repository, using the text editor that we liked most for design entry, and simple things like text compare). Going back to schematic-based design entry is in my mind a huge step back. Magnus
  13. mkarlsson

    SPI to initialize TFT

    For a more detailed description of the first line see https://www.nandland.com/verilog/examples/example-reduction-operators.html Magnus
  14. mkarlsson

    SPI to initialize TFT

    idle is set to 1 if all bits in counter are 1 (unary reduction operator AND) if internalSck is high then cs is set to 0
  15. mkarlsson

    FPGA as USB PIA

    Hi Tim, Cool. I will include the Linux version. Yeah, the sigrok p-ols driver is fifo mode only. In serial mode the (i.e. with a serial mode bitstream loaded and the FT2232H is serial mode) the board is basically a Open Bench Logic Sniffer with higher baud rate (921600 instead of 115200) and more memory (64MB instead of 24kB) and it should be trivial to modify the sigrok ols driver to support pipistrello in serial mode. Note that the SUMP protocol limits the samples to 256k so if you want to sample more you need to use the extended range registers that I added (see the p-ols driver). As for the sampling of TMDS data, you should be able to use the HDMI connector for that but you would need to add the 50 ohm terminator resistor packs on the bottom side of the board (the layout is prepared for this). Initially the plan was to support both HDMI-out and HDMI-in and an earlier XL9 board I made worked great in both modes but I was sloppy when I did the Pipistrello layout and did not place the CLK pair on GCLK pins . However, if you just want to asynchronously sample the TMDS data at 4x the bit rate then this should work fine since you don't use the CLK pair as an input clock. You would need to change the Pipistrello OLS code to use SERDES for sampling the data etc. but you should be fine from memory bandwidth standpoint (4 bits at ~1Gb/s is 500 MB/s and the memory controller on Pipistrello can easily do that when using the maximum burst length). If you want to work on this then I can hopefully give you a hand. Cheers, Magnus
  16. mkarlsson

    FPGA as USB PIA

    Should be back now. Please note that this code is for Pipistrello and might have to be modified for other boards. Magnus
  17. No, that's not "equivalent" - you did not declare wb_data_i in the verilog version like you do in the vhdl version so it defaults to a single wire. Try this: input [100:0] wishbone_in; wire [31:0] wb_dat_i; assign wb_dat_i = wishbone_in [59:28]; Magnus
  18. mkarlsson

    Unknown Papilio Board

    On DUO there is a third possible reason for this error - the FT2232H chip on this board has two jtag controllers (port A and port B ) and if papilioprog is trying to open the wrong one you will get this error. If that's the case then one option is to specifically open the correct port using the "-d device name" option. Without the -d option papilioprog will open the first one it finds.
  19. mkarlsson

    Unknown Papilio Board

    This cryptic error message means that it can't find a jtag device connected to the FTDI chip (the error message have been changed in later versions of papilioprog). There are two possible cause for this error - you either have several FTDI devices connected to the computer and papilioprog is talking to the wrong one, or the papilio board has a problem with the jtag wiring from the FTDI chip to the FPGA. Magnus
  20. No, the ft232R does not have an MPSSE unit, which is what the Papilio loader is using for JTAG. Magnus
  21. mkarlsson

    Loading the SPI Flash on the Papilio Pro

    The only difference between my version of the bscan files and the papilioprog bscan files is that I also drive flash_wp and flash_hold. The flash chip on Pipistrello can do quad-spi mode where flash_wp and flash_hold are used as data lines. The pullups on the board for those two lines are too weak to overcome the default spartan6 pulldown on unused pins so I define them as inputs. See attached file. Magnus bscan_spi_spartan6.vhd
  22. mkarlsson

    Loading the SPI Flash on the Papilio Pro

    This basically means that the data returned from the flash is 0. As you said, if it works with iMPACT then it's most likely not a hardware problem. Could it be that you are using a bscan_spi_xxx bitfile designed for xc3sprog with fpgaprog? The fpgaprog/papilioprog bscan_spi_xxx files are incompatible with the bscan_spi files designed for xc3sprog and you would definitely not get the correct data back if you use the wrong bscan file. Magnus
  23. mkarlsson

    Gameduino on Pipistrello

    Just like Jack I have been playing with Gameduino, a really cool project by James Bowman. Originally it was a add-on shield for an Arduino board that implemented a sprite engine and much more, while the Arduino board did all the computing and sending commands to the Gameduino shield via a SPI interface. For more info see this link to the Gameduino page: http://excamera.com/sphinx/gameduino/ with cool pictures and a complete description of the system To port this to Pipistrello I expanded the code by adding two more blocks so it's basically now made up of three blocks: * Original Gameduino block (no functional changes, just some code cleanup) * VGA-to-DVI converter to send out the display via HDMI to a DVI monitor instead of VGA * Microblaze_mcs system running at 100 MHz with added hardware I/O modules (SPI, timer, DIO, UARTs etc.) The Microblaze_mcs I/O system is designed to simplify the porting of the core Arduino code to this new platform. The result is a completely self-contained system that can run most of the example sketches for Gameduino without any extra hardware, using the familiar Arduino GUI. Links to a few bit files to show off what it can do (just download the bit file to the fpga, i.e. fpgaprog -v -f <bitfile.bit>) 256 sprites: http://www.saanlima.com/download/pipistrello-v2.0/sprites256.bit collision: http://www.saanlima.com/download/pipistrello-v2.0/collision.bit asteroids game: http://www.saanlima.com/download/pipistrello-v2.0/asteroids.bit (pins A3 - A6 controls the game) Link to my version of the Arduino GUI (windows) with Microblaze support that can be used to compile and download the demo sketches (included as examples) http://www.saanlima.com/download/pipistrello-v2.0/arduino-1.5.2-gameduino.zip Instructions: * Download the Arduino zip file (it's about 160 MB) to your computer (sorry, windows-only at the moment) * Unzip to any directory * Go to this directory and launch the Arduino GUI by clicking on the Arduino icon * In Tools -> Board select "Microblaze_mcs with Gameduino" * Connect the Pipistrello board to the computer, a DVI monitor and optionally a sound system * Load one of the Gameduino examples by going to File -> Examples -> Gameduino * Click on the Upload button. The sketch will be compiled, then merged with the base bit file and then downloaded to the Pipistrello board Enjoy! Magnus
  24. mkarlsson

    Interfacing memory to papilio fpga board

    No, there is no reason why a board like that would not work. I would keep the wires as short as possible though. One option is to make the layout to match the papilio wing headers and populate the board with pin headers to minimize the signal length. The memory you linked to has a 12ns access time and you should be able to do reads and writes at 25 - 40 MHz. A quick rule of thumb is to add 5ns address output delay and 5 ns data input delay to the 12ns access time = 22ns access cycle time. You should be able to use this memory to generate video signals at 8 bits/pixel, 640x480. The problem is that if you want to dynamically update the video image then you would need bandwidth for both video readout access and video update access. For 640x480 VGA that typically means the you need 50 MHz pixel access bandwidth (2x 25 MHz video pixel rate). If this is your goal then you might want to consider a 10nS memory part. Here is a link to a zip file with a Eagle board layout for a memory board that fits the Papilio headers: http://www.saanlima.com/download/sram_wing1.zip It implements a 32-bit wide 2MB memory system using two 512Kx16 SRAM chips and an address latch to save pins. This board has up to 100 MB/s bandwidth using 10nS memory chips and can be used to implement a 16-bit/pixel VGA buffer with read/write access bandwidth. While this is a bit more than what you plan to do, it might give you some ideas. Magnus
  25. This is a port of the Plus Too code from Big Mess o' Wires to Pepino LX9/1MB. This code base have been dormant for quite some time but the folks at MiST picked it up a while ago and added more features like keyboard and sound support etc. The code supports a virtual SCSI hard drive via the sd-card socket. This is based on the MIST scsi code but the disk interface is quite different - the MIST board have a ARM processor that is handling the sd-card read and write functions and talks to the FPGA via SPI, while in the Pepino implementation the FPGA is directly connected to the sd card using the native 4-bit SD protocol. The interesting part of this project is that the 128KB ROM data is stored in flash memory after the bit file and is executed directly from the flash chip (the need for this is due to the Pepino LX9 RAM limitation, the MacPlus needs the full 1MB of RAM). It's possible to do this since the flash chip on Pepino (Micron N25Q128A) can operate in quad-spi mode at up to 108 MHz clock rate. In quad-spi mode, 4 bits are transferred on each clock instead of 1 bit. However, due to access time restrictions there needs to be dummy cycles between the cmd/address part and the data transfer part based on the clock frequency used. The default number of dummy cycles is 10 matching the highest clock rate (108 MHz). So with the default dummy clock settings a 16-bit word transfer in quad-spi mode will take 2 + 6 + 10 + 4 = 22 clocks, corresponding to 1 byte command, 3 byte address, 10 dummy clocks and 2 byte data. (BTW, there is a possibility to eliminate the command byte by using XIP, eXecute-In-Place mode supported by this chip, but it was not needed in this case). In this project the spi bus is clocked at 65 MHz and the Mac 68000 processor is clocked at 8.25MHz. The 68000 memory access cycle takes 4 clocks for an effective memory access rate of about 2 MHz, which means that there is time for 32 spi clocks for each memory access (65 MHz/2.03125 MHz = 32). So the 22 clocks needed to read one instruction in quad-spi mode will easily fit in the 32 cycle window. The full ISE project can be found here: http://www.saanlima.com/download/pepino-v1.1/PlusToo_scsi_LX9.zip For more info and a MacPlus disk image etc., see this link: http://www.saanlima.com/pepino/index.php?title=Pepino_PlusToo http://www.saanlima.com/images/128M.JPG