• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by mkarlsson

  1. No, the ft232R does not have an MPSSE unit, which is what the Papilio loader is using for JTAG. Magnus
  2. 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
  3. 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
  4. 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: 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: collision: asteroids game: (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) 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
  5. 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: 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
  6. 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: For more info and a MacPlus disk image etc., see this link:
  7. You will get this message if the FTDI chip can not find a JTAG device in the JTAG chain. This will typically happen if there is a problem on the board with the FPGA JTAG connection to the FTDI chip OR if there are other FTDI boards present on the computer and the papilio loader happens to open the wrong FTDI chip (the default behavior is to open the first FTDI chip that it finds). BTW, the "insane" error message have been fixed in later version of the papilio loader to more clearly identify the problem (i.e. no FPGA chip found).. Magnus
  8. FYI, I had a discussion a couple of years ago with Jan Willem Janssen (JaWi, the author of the ols client software) regarding bugs in the RLE code. The problem I found was that RLE processing in demux mode (i.e. 200 MHz sampling mode) was completely broken. This is what I wrote him back then: The reason I think demux mode is a hack is that only the input sampling module and the trigger module knows about demux mode, the rest of the pipeline is tricked into processing two 16-bit values as one 32-bit value. This works fine as long as the client receiving the data is processing it as a sequence of 16-bit values, but when you add RLE encoding to the mix then it starts to fall apart since the RLE encoder knows nothing about demux mode. For example, 32-bit RLE mode is using bit 31 as a flag (if set it indicates a repeat count) so you only have 31 channels in this mode and the most significant channel is always 0. This means that in demux mode the sample stored in bits 16-31 will have it's top channel value zeroed out bit not the value stored in bits 0 - 15. This could be fixed if the RLE module knows about demux mode. A more significant side-effect of processing two 16-bit values as one 32-bit value in the RLE encoder is that you are really RLE-encoding pairs of 16-bit values. If the stream of 16-bit values look like this: 0x5000, 0x5100, 0x5000, 0x5100, 0x5000, 0x5100 then the RLE encoder will process this as the value 0x51005000 repeated three times. To process this correctly the RLE decoder in the client must first create the original sequence of 32-bit values based on the RLE flag and RLE count, and then process them as a sequence 16-bit sample values. In other words, the process order in the client must be the reverse of the process order in the RTL code and must operate in the same context as the RTL code (first do RLE as 32-bit values, then the sample values as 16-bit values). However, looking at your code (in I believe this is not how it's done in your client, it's trying to do both at the same time. If I read your code correctly it looks like you are processing the data as a single16-bit value and if the RLE flag is set and in demux mode then you try to modify the repeat-count for this 16-bit value somehow by using the next 16-bit value and then multiplying the result it by 2, rather than processing it as repeated pairs of 16-bit values. It also looks like you are applying the 32-bit rleCountValue and rleCountMask to the 16-bit sample value in 16-bit demux mode? In other words, RLE in 200 MHz mode (a.k.a. demux mode) does not work in the client software. I don't think this has been fixed by JaWi. Magnus
  9. Well, they wanted to plug that possibility so if you install Vivado then they also update the Digilent plugin You can however revert to the ISE version by going to (assuming 64-bit Windows) C:\Xilinx\14.7\ISE_DS\common\bin\nt64\digilent and run install_digilent.exe It will prompt if you want to "downgrade" the plugin.
  10. Hi Thorsten, The video you are referring to was done 2012, well before the Papilio Duo board was introduced and is only applicable to the Papilio One boards. Papilio One uses a different FTDI chip than Papilio Duo (FT2232D vs. FT2232H) and the instructions in the video only works for FT2232D. Also, the Papilio One boards are shipped with a blank EEPROM so the instruction at the end of the video to restore the board to the way it was shipped by erasing the EEPROM is correct, but only for Papilio One. If you want to use the Xilinx cable then the FTDI pins used for JTAG must not interfere with the Xilinx cable. In normal UART mode (i.e. when the EEPROM is blank or Port A is configured as UART in the EEPROM) then those pins are used for TXD. RXD, RTS and CTS and will mess up the Xilinx cable signals. The solution is the reprogram the FTDI EEPROM to a mode where the signals are not driven by the FTDI chip. For the FT2232D chip, one way to do that is to program Port A to Opto Isolate mode. However, on FT2232H this mode does not exists for Port A, only for Port B. An alternative is to program Port A to 245 FIFO mode instead, this works for both FT2232D and FT2232H. Hope this helps, Magnus
  11. The problem above is related to bugs in JaWi's SUMP client, not the FPGA board. When the pulldown menu says 6 kB capture it really means 6 kS, i.e. it's the number of samples not the number of bytes. But then in the time calculation he incorrectly scales the resulting time by the number of channel groups. 6 kS at say 1 MS/s will always take the same time (in this case about 6 msec) independent of how many channel groups are enabled. If you try to select 12 kB or 24 kB samples (really 12 kS or 24 kS) with all four channel groups enabled then the memory is not enough so the error message is correct. As an alternative to Jack's Sump Logic Analyzer bit files for Papilio One 250k/500k you could try one of the bit files here: , they are generated from the current Open Bench Logic Sniffer Verilog source files. Cheers, Magnus
  12. Or any other Xilinx FPGA board with an FTDI chip with MPSSE-engine connected to the JTAG pins (like Pipistrello but not Mojo or Saturn). This is using the xilinx virtual cable driver. Playtag is written by Patrick Maupin. Steps: 1) you need python 2.7 installed. Get it here: 2) unzip the attached zip file somewhere on your computer 3) open a cmd-window and cd to <playtag>\tools\jtag 4) connect your Papilo board to the computer 5) type ftdi, this will report the available FTDI ports.You should see the A and B ports of the Papilio board (see image). 6) type ftdi 0, this will start the xilinx virtual cable server on the A port of the Papilo board 7) you can now use impact and chipscope etc. by selecting the xilinx_xvc plugin. Use this plugin settings: xilinx_xvc host=localhost:2542 disableversioncheck=true See attached images and zip file. Do a google-search for xilinx_xvc for more info on how to use the virtual cable driver. Magnus
  13. xvc supports three types of commands - getinfo:, settck: and shift:. getinfo: can be used by the program to ask about target info, settck: can be used to set the jtag clock frequency, and shift: is used for all jtag data transfers. (See above in the thread for more info about the commands.) In impact, if you set disableversioncheck=true like the instruction says then impact will not send the getinfo: command, and if you don't change the default jtag clock frequency then the settck: will not be sent either, so the only command impact will send is the shift: command. The playtag python script assumes this is true and will only respond to the shift: command, and has asserts that will fire if it gets any other command besides the shift: command. What you see is this assert firing, so chipscope pro has obviously sent either the getinfo: command or the settck: command. In order to use the playtag script with chipscope pro you either need to make chipscope pro not send those commands (like the disableversioncheck=true setting in impact) or update the playtag script to also support those commands. BTW, I did not write the playtag script, Patrick Maupin wrote it. See . Also, xvcd might be an alternative to use. See . Magnus
  14. To follow up on the code example, I did complete it as a module and ran it through ISE. The syntax checker said no errors but when I tried to synthesize the module I got this error: ERROR:HDLCompiler:608 - "test.v" Line 16: Multiple event control statements in one always/initial process block are not supported in this case. In other words, it's valid syntax but can't be synthesized. I also did the code for a flip-flop using the same code style to emphasize that always is a keyword by itself: always begin a = 0; @ (posedge clk) q <= ~q; end and it had no problem synthesize the code. Magnus
  15. My gripe about most HDL guide books is that they very often have misleading, confusing and sometimes completely incorrect statements about the language, and the David Romano book mentioned above is a typical example. Rather than explaining the language in the context of how it was originally intended to be used (i.e. a language for logic simulation) it is often instead explained in the context of logic synthesis (i.e creating real hardware). Logic synthesis did not exist when VHDL or Verilog was created, if came later when companies like Synopsys realized that it's possible to create hardware design files from the HDL code BUT only if you use a small subset of the language and use code templates for common structures so that the synthesis process can easy translate it to real hardware. The HOWTO books then describes this small subset and the templates for synthesis as the definition of the language and it makes it very hard for a beginner to understand why the language is defined as it is. By focusing on simulation instead of synthesis it's much easier to understand why the language looks like it does - it's defined to make simulation as easy as possible, not to make synthesis as easy as possible. Here is a case from the David Romano book to illustrate what I'm talking about. Here is what the book says about the Verilog always block: Example 3-3. Syntax of always block always @(sensitivity_list) begin //one or more procedural assignment //statements end This is completely incorrect - this is not the Verilog syntax of the always block, this is the synthesis template for combinatorial logic! The concept sensitivity_list is not mentioned in the IEEE standard, it's made up by people looking at Verilog code from synthesis viewpoint. The correct IEEE Verilog definition of the always block is this: always <statement> where <statement> can be a long list of things including delays (#) and event control (@). For instance, this is legal (but maybe not possible to synthesize): always begin @ (posedge test) a = 0; @ (negedge test) a = 1; end It's easy to explain what happens here if you look at it from the simulator's viewpoint. The always block is like the loop() statement in Arduino - the simulator will process the statements in the always block forever, when it gets to the bottom it will start again from the top. The @() part is called event control, the simulator will stop and wait for the event, in this case it will wait for the signal test to have a rising edge. It will then set a = 0 and continue to the next line which is another event control. The simulator will pause until test have a falling edge and then it will set a = 1; This will be repeated forever. Easy if you look at it as a simulator. The synthesis template for a D flip-flop looks like this: always @ (posedge clk) q <= d; and it's easy to see that from the simulator's viewpoint this will simulate a D flip-flop - the simulator will wait for the event rising edge of clk, then set the signal q the same as d. This will be repeated forever. Magnus
  16. You are correct. This error is corrected in the latest version of the generic Pipistrello UCF file (pipistrello_v2.03.ucf). Magnus pipistrello_v2.03.ucf
  17. I have been working on porting the Arduino 1.5.2 code base to Pipistrello using the Microblaze soft processor running at 100 MHz. This is definitely a work-in-process but I think it's complete enough to share. The biggest downside of using the Microblaze core in this project is that it requires an EDK license which is not free. It's possible to swich to Microblaze_mcs which is part of the free ISE Webpack but it would restrict the processor to 64 KB address space and use the lower-performance 3-stage processor vs. the high-performance 5-stage Microblaze in EDK so at this point I'm sticking with the full Microblaze core since it will also allow full access the the Pipistrello 64 MB DRAM space. The full arduino-1.5.2-windows version of this can be downloaded here: The Linux version is almost there, just fighting silly FTDi serial port issues (man, I love Linux but why does it have to be so difficult to do simple things like user-space serial port access) What works and what's not there yet? I think it's easier to answer what's not there instead of what's there. The following things are not impemented: analogRead(), analogReference(), analogReadResolution() : No analog input on Pipistrello tone(), noTone(): the hardware for this is not yet there attachInterrupt(), detachInterupt(), interrupts(), noInterrupts(): the interrupt system is not yet impemented hardware for I2C is not yet implemented SPI hardware is master-mode only OK, so what does work? The following Arduino functions are implemented: pinMode() digitalRead() digitalWrite() analogWrite() AnalogWriteResolution() millis() micros() delay() delayMicroseconds() pulseIn() (not yet calibrated though) shiftIn() shiftOut() Serial() Serial1,2,3() Pins: Wing A pins 0 - 15 has arduino pins 0 - 15. They can all do digital in/out and analog out. Analog out has 16 bit resolution but is scaled down to 10 bits for compatibility with the Atmega parts. However, the new function analogWriteResolution() introduced in arduino-1.5 for Due allows you to change the resolution to 16 bit. Wing B pins 0 - 7 has arduino pins 16 - 23. They are digital only or SPI ports (if enabled). The LEDs on the board are mapped to pins 12,13,14 and 15 but can be remapped to any of pins 0 - 15 by writing to a register (the arduino code for this is not there yet). Just like for Mega there are 4 serial ports - Serial, Serial1, Serial2 and Serial3. Serial is connected to the FTDI chip and Serial1 - 3 are connected to Wing B pins (8,9), (10,11) and (12,13). There are 3 SPI ports in hardware - the default is connected to the SD card socket and is using arduino pin 53 as chip select. The 2 extra SPI ports are not yet exposed in the Arduino code. The library SPI is working as well as the SD library that uses the SPI library Things to try: Examples -> 01.Basic -> Blink (should run without any changes and blink the red LED L2) Examples -> 03.Analog -> Fading (change the LED pin from 9 one of pins 12 - 15) Examples -> SD -> CardInfo (needs a microSD card, change chipSelect from pin 4 to pin 53 and enable a serial console) Magnus
  18. BTW, here is a link to a complete project using Microblaze_MCS: The folder ise has has a complete xilinx project to build the hardware platform, including all the rtl files needed (the processor and all the custom I/O modules). The folder arduino-1.5.2-mcs contains the complete arduino environment for Windows with added microblaze support, including the gcc compiler and core arduino code for the microblaze hardware platform. The file waveplayer.ino is an arduino sketch for this system that plays wave files stored on a sd-card. It uses standard arduino libraries for SPI and sd-card support. Magnus
  19. This is a quite complex undertaking and I'm not sure a forum post can explain all the aspects of doing a Arduino port for a different processor but I will try to give you a few hints on how to do this. 1) You need to create the hardware platform so that you can support the basic Arduino system, i.e. processor, memory, timer, digital I/O with optional PWM, uarts, SPI controller etc. The nice thing with creating your own I/O modules is that you can make them so that the porting of the Arduino core code is easier than if you use the Xilinx IP or other open-source I/O modules. For instance, if you make the SPI controller work the same as the AVR SPI controller (same registers and control bits) then you can use the already available SPI library with minimal modifications. 2) You need to understand the Arduino build system and create the necessary files and folders to support a new processor. The added files and folders will go in the <Arduino>/hardware folder. You can see how they added support for the ARM processor (i.e. sam) and create the same structure for microblaze. Part of this will be to port the core arduino code to your hardware platform and create the files platform.txt and boards.txt that will control how the build is done. This is the hard part of doing the port. The gcc compiler will be in the <Arduino>/hardware/tools directory. 3) For bootloader there are several possibility. One is to have bootloader code resident on the hardware platform that talks to a bootloader running on the development system (Linux or Windows) like how the did it for ZPUino (this mimics the Arduino way of loading code). Another alternative is to use the data2mem program and merge in the generated arduino sketch code directly to the bit file and download the resulting bitfile using JTAG (no bootloader needed but only works if the system memory is in BRAM). A third alternative is the store the arduino sketch code in elf format in the flash memory after the bit file and have an elf loader resident on the hardware platform that will load the elf code from flash to main memory and execute it (works for both BRAM and external memory). I have implemented the last two options for my systems. For Vivado, mb-gcc can be found in the Xilinx SDK directory. On my Windows install it can be found at C:/Xilinx/SDK/2015.3/gnu/microblaze/nt. I have not installed Vivado on my Ubuntu system so I can't say the exact path but my guess would be /opt/Xilinx/2015.3/SDK/gnu/microblaze/lin64 or something like that. Hope this helps.
  20. FYI, OLS version 0.9.7 SP1 is compatible with Java 1.8 Magus
  21. The CMT (Clock Management Tile) is a block containing one PLL unit and two DCM units. You can either instantiate a PLL or DCM unit directly in your code or use the "clocking wizard" to do it for you. The clocking wizard is part of the Xilinx CORE generator (under FPGA Features and Design -> Clocking -> Clocking Wizard). To learn more about the CMT, PLL and DCM check out this document: Spartan-6 FPGA Clocking Recources User Guide This guide will tell you how to directly instantiate a PLL or DCM unit (or any other library component) in your code: Xilinx Spartan-6 Libraries Guide for HDL Designs (page 99 and 213 for DCM and PLL). You should use the 32 MHz on-board oscillator as your clocking source, not the AVR SPI clock. If you let us know more about what you want to do (like I want to generate a 100 MHz clock for my circuit, how do I do that?) then we can give you more specific help. Edit: BTW, if you just want a clock input to your design but don't really care about the frequency then just use the 32 MHz on-board oscillator as your clock source, no need for a PLL or DCM. You only need a PLL or DCM if you want to generated a different clock frequency (or multiple clocks with different clock frequencies). For example, if your circuit has a VGA controller that needs to be clocked at 25 MHz then a DCM or a PLL will let you generate that clock from the 32 MHz input clock. Magnus
  22. max_counter has an initial value of all 1's but never assigned any other value so it's basically a constant. The warning is just another way of saying that. As for the timing of this block, I'm not sure what you are trying to accomplish here. A 20 bit PWM circuit clocked at 200 MHz will have a period of about 200 Hz so you will need a very low frequency low-pass filter (~50 Hz) on the PWM output if you are trying to implement some sort of DAC. In general, for PWM DACs and delta-sigma DACs, the more bits of resolution you have the lower frequency components will show up on the output. Maybe your application is fine with a 50 Hz cut-off on the output, if not then I suggest rethinking your design. I'm not sure this relates to your project but this thread might have useful information: Magnus
  23. The GadgetFactory blog page has this story about the snake game written in Verilog so I decided to take a look at it. Sadly to say it's pretty much a textbook example of how not to write HDL code. However, this idea seemed pretty cool so I decided to do an almost complete rewrite of the code (basically the only thing left from the original code is the VGA controller) while still keeping all the functionality of the original code. The new version uses about a 1/4 of the FPGA resources compared to the original code when compiled for Spartan6 and it now fits an LX9. The complete project can be found at and should be easy to adapt to any LX9 based board like Papilio Pro or Duo with a VGA wing. Magnus
  24. Here is a version for Papilio_Pro with LogicStart Megawing. The joystick controls the snake movement and switch 7 (the rightmost switch) is the run/stop input. Complete project (including bit file in the ise directory) can be downloaded here: (Unfortunately my upload allowance is maxed out so I can't post the project here) Magnus
  25. In simulation there needs to be a "test bench" that your circuit plugs into. The test bench drives the clk signal with a 32 MHz square wave. In other words, you need to generate the 32 MHz clock signal in simulation. In real life it's driven by the oscillator on the board. Magnus