Leaderboard


Popular Content

Showing content with the highest reputation since 05/22/2015 in all areas

  1. 2 points
    Original version of game was running on PIC18F6622 and Dingoo A320. Now it's running on Papilio One 500K + Arcade Megawing. I've used the ZPUino soft processor which is realized by Xilinx Spartan-3E FPGA. VGA signal is also generated by the FPGA. The game can be played with integrated buttons of Arcade Megawing or with Atari/Commodore joysticks. I've used a QuickShot II Plus (SVI-102 Plus) joystick in the video below: Demo Please, use the .bit file included in the ZIP. Otherwise buttons and joystick are not working properly. sometris_v121.zip
  2. 2 points
    I have the J1 CPU running on the Papilio Duo. It runs a standard 32-bit ANS Forth, communication is through the UART. It is working quite well; in fact I used it to run my slides for a presentation last week (slides were on microSD, buttons and VGA output from the Computing Shield). Is anyone interested in giving it a tryout? Let me know if so and I will put together a release. Thanks! J.
  3. 1 point
    Loading your own programs into block RAM there are many ways to load data into a block RAM. These can be broken down into two general categories - pre-synthisis or post-presynthisis. Assuming that you are going to place a compiled AVR project into the program memory of the AVR8 processor you will most probably want to use both at differnt times, as pre-systhisis is best suited for debugging test programs for the FPGA "hardware", where as post-systhisis is really convienient for implmenting new software revisions. Pre-synthesis This involves adding the required data into the FPGA source tree, and then building a new FPGA programming bitstream. Pros: Data is present in BRAM allowing source level simulation Easy to visualise and understand Cons: Long turnaround time, as a full rebuild is required to change RAM contents before configuring devices Data must be converted into a FPGA tool friendly format Data must be known at designtime A full FPGA development toolset is needed to update the BRAM contents If you use the VDHL 'GENERATE' contruct to create multiple BRAM blocks they will all have the same contents, limiting you to around 1k of code. Only really works with BRAMs who's width matches that of the target architecture. Putting data into an 8kx8bit memory out of eight 8kx1bit bit-planes isn't feasible. A new FPGA build is required for each different BRAM contents (in this case programs) Post-synthesis This involves updating the contents of the FPGA bitstram to contain the correct data in the correct location. Pros: All BRAM instances can have different contents Only a limited FPGA toolset is required to merge the new BRAM contents into the bitstream (the data2mem utility). Fast turnaround, as no project rebuild is required Can usually be integrated into the a software development toolchain (e.g. "makefile"). Can handle more complex memory configurations such as 'bit slices'. you build the hardware once and then merge many different programs quickly Cons: Can not be used with source level simulation, but can be used with device level simulation Far more complex to understand and implement How to update BRAM contents pre-synthesis The recipie for this is: Convert your '.hex' file to VDHL 'INIT_xx' attributes. In my Papillo build this is XPM8kx16.vhd Replace the existing 'INIT_xx' in the PM_INST instance in the AVR8 processor Rebuild the project Configure the device with the resulting bit file Note that the 'INIT_xx' parameters are interpeated like really large integers (32 byte integers) in LSB format. So if your wanted to have the following bytes in memory 0000: [tt] 0000: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF [/tt] Your init string will be: [tt] INIT_00 => X"00000000000000000000000000000000FFEEDDCCBBAA99887766554433221100", [/tt] This doesn't make much sense until put in the context that BRAM blocks can have different widths. I've written a small 'C' program (available in the Papillo playground) which takes an Intel '.hex' file and outputs the lines to cut and past into the VDHL source. Another option (not useful in the context of the AVR8 processor) is to create a '.coe' file, which is used by the Block RAM generator wizard to set the inital values. A small example is: [tt] memory_initialization_radix=16; memory_initialization_vector=00,11,22,33,44,55,66,77,88,99,AA,BB,CC,DD,EE,FF; [/tt] If you do use a '.coe' file you will need to rebuild the BRAM IP and then the entire project after changing the file to include the updated data in your project. It is very long winded! How to update BRAM contents post-synthisis The recipie for this is: Convert your HEX file to a ".mem" file. Use the Xilinx "data2mem" program to insert the data in the '.mem' file into the '.bit' file. Configure the device with the resulting bit file. The merging process uses a "_bd.bmm" file define the "address space" created by one or more BRAM blocks. The BMM file for my AVR8 looks like: [tt] ADDRESS_MAP avrmap PPC405 0 0x00000000:0x00003FFF (16 KBytes). ADDRESS_SPACE rom_code RAMB16 [0x00000000:0x00003FFF] BUS_BLOCK avr_processor/PM_Inst/RAM_Inst[0].RAM_Word [15:0] PLACED = X1Y7; END_BUS_BLOCK; BUS_BLOCK avr_processor/PM_Inst/RAM_Inst[1].RAM_Word [15:0] PLACED = X1Y0; END_BUS_BLOCK; ... BUS_BLOCK avr_processor/PM_Inst/RAM_Inst[7].RAM_Word [15:0] PLACED = X1Y6; END_BUS_BLOCK; END_ADDRESS_SPACE; END_ADDRESS_MAP; [/tt] What first perplexed me was how to get the vaules for the "PLACED = XxYy" clause, but I discoved that the FPGA toolset does this for you. You first create a template "whatever.bmm" (e.g. "progmem.bmm") without the PLACED clauses, and during the Place & Route this gets updated and saved as "whatever_bd.bmm". Simple really once you know how it works. I've chosen to implement my merge as a windows CMD script, which copies in the ".hex" file from the project, then srec_cat converts it, and finally data2mem merges it with the FPGA bitstream: [tt] copy "c:AVR\vgatest\default\vgatest.hex" . srec_cat vgatest.hex -Intel --byte-swap 2 -Data_Only -Line_Length 105 -o vgatest.mem -vmem 8 C:\Xilinx\12.4\ISE_DS\ISE\bin\nt\data2mem -bm progmem_bd.bmm -bd vgatest.mem -bt avr8.bit -o b vgatest.bit [/tt] Due to unexpected behaviour in data2mem the ".mem" file needs to have an even number of bytes per line. A line length of "105" is enough to have 32 bytes on each line and matches nicely with the data in the '.hex' file. Debugging when things go wrong As with all things, debugging is the hard bit. The data2mem utility allows you to dump the contents of a bitstream, and you can then view it in a text editor. If you are lucky to be running on UNIX you can then use the 'diff' utility to compare the bitstream contents before and after the data2mem. As the AVR8 has an interrupt table at the start of memory it's regular structure is a great help. If you also use supply "_bd.bmm" file the BRAMs will be named with their instance names: [tt] C:\Xilinx\12.4\ISE_DS\ISE\bin\nt\data2mem -bm progmem_bd.bmm -bt avr8.bit -d [/tt] Gives me: [tt] ... BRAM data, Column 01, Row 07. Design instance "avr_processor/PM_Inst/RAM_Inst[0].RAM_Word". 00000000: 94 0C 00 30 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 ...0...R...R...R...R...R...R...R 00000020: 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 94 0C 00 52 ...R...R...R...R...R...R...R...R ... [/tt] And there you have it! Hope it saves you a few days of banging you head against what feels like a brick wall.
  4. 1 point
    Hi all, I know it will sound stupid, but anyone knows if I have to enable something in ISE (14.7) to get the symbol manager? I followed the tutorial on the learning site but, after I loaded the example project, the Tools dropdown ends with "Smart Xplorer" and there are no other options as on the screenshot..... Where am I missing the point? :-D Thanks!
  5. 1 point
  6. 1 point
    I don't have the code you referenced but I am assuming it is displaying a seven segment on vga. Maybe you are trying to connect the virtual seven segment lines to the vga lines. I believe the errors you are getting are because you are attempting to connect a std_logic_vector to a std_logic signal. If you are trying to connect a one bit vga signal to a three bit you should probably connect the single bit to the msb of the multibit and set the non-msbs to zero.
  7. 1 point
    Regarding the error message: I can't read it in your post, it just shows up as "?" for some reason. Regarding how to "call" it: The "Code x32" means "character code 0x32". That is, when the value 50 (0x32) is found in the video_ram, the corresponding font data (what you quoted above) is displayed on the screen. So the question for you is how to get the codes for "hello world" into the video_ram. It looks like emitCharCodes.pl is part of that process. I think it's used to generate a new video_ram.coe file, and then you build the whole thing using ISE.
  8. 1 point
    And we were able to do a full simulation of the system, so we can find bugs on it.
  9. 1 point
    Hi Alvie, I'm building at the moment directly the s3e500 under papilio-one from your github without changes and I also run it on a Papilio-one with S3e500. So its correct that it's not LX9. After I get everything running on the one I want to move to the LX9. Tobias
  10. 1 point
    For more info see: https://www.llnl.gov/news/nih-taps-lab-develop-sophisticated-electrode-array-system-monitor-brain-activity The NIH project is a collaboration between LLNL's Neural Technology Group; the laboratory of Loren Frank at University of California, San Francisco (UCSF); Intan Technology; and SpikeGadgets. Housed at the Center for Bioengineering, the Neural Technology Group will work with UCSF researchers to design and build electrode arrays that can record hundreds to thousands of brain cells simultaneously. Their goal is to develop 1,000-plus channel arrays that can eventually be expanded to 10,000 channels. These arrays will use new microchips designed at Intan and will send data to a system developed at SpikeGadgets. UCSF will coordinate these efforts and test the technologies. The arrays will penetrate multiple regions of the brain without interfering with normal functions during the experiments, allowing for detailed studies of brain circuits that underlie behavior. "This collaboration combines the engineering talent of LLNL with UCSF's expertise in neural recording and modulation systems, and the design and programming skills of Intan and SpikeGadgets," Frank said. "The result will be a system that will help us understand how different brain areas communicate and carry out complex mental functions."
  11. 1 point
    And I happen to work on a system that samples up to 1024 analog signals each 16-bit at 30 kHz sampling rate using up to 16 ADCs, each with a 64 ch mux All done with an Spartan6 LX16 and streaming the data out using a TMDS link (i.e. like HDMI but just clock and data) at 78.6 MB/s. using regular HDMI connectors and cables. For something like this you definitely need an FPGA. Here is a picture of a 640 ch system. FPGA board to the right with micro-HDMI connector for power and data, 5 ADC boards in the middle, each with 2 ADCs (i.e. 128 ch each), and LVDS terminator board to the left. The ADCs are connected to the FPGA using SPI with LVDS signaling (CS, CLK, MOSI, 16x MISO).
  12. 1 point
    Hi Im new to FPGA but have one question: Concerning Commodore MOS chips Is there open source for: 1351 Mouse Controller C64/C128 Ram chips REC memory controller SID: 6581,6582,8580 last known revisions? The last item is: I have heard that CBM MOS chips could possibly be redone using xilinx using PLD but its difficult but would any of the Papilio code still work with Xilinx software? Is there any open source for anything like the CBM MOS 1351 controller chip. (1351 was CBM Mouse, worked in Joystick Mode and Proportional mode). Other controllers wont work because the 1351 somehow worked along with the SID Oscillator, without that it wouldn't work. I hope I asked this in the right forum so any help is appreciated. Thank you, Terry Raymond
  13. 1 point
    it works. Using this Source and the Device source: http://www.macronix.com/Lists/ApplicationNote/Attachments/1148/AN0245V2%20-%20Using%20Macronix%20Serial%20Flash%20with%20Xilinx%20iMPACT%20Tools.pdf part: N25Q64
  14. 1 point
    @Jack - maybe we need to make testbed files for the p500 like i did for the pduo ? @island_peter - if you want to send your p500/arcade megawing to me i can test it for you ( i live near wiesbaden ) but as jack said, RomVault - Papilio Edition is a good way to test since it comes with a few free games and it loads them with just 2 clicks.
  15. 1 point
    Thank you very much for this project. I've been wanting to try and receive some kind of low-res digital video signal, say 640x480, for a while. For some (misguided) reason I started by reading the DisplayPort standard, but I quickly realized it's waaay too complex for my abilities. Compared to it, HDMI / DVI-D seems a piece of cake. I mean, It even comes with its own clock line! Actually I never knew HDMI was just DVI-D repackaged. That's quite sleazy of them. I don't have a Papilion (yet). Would you strongly recommend using an FPGA with builtin support for TMDS? Said another way, what kind of circuit would I need to hook the TMDS pairs to a simple CPLD, or maybe to a Cyclone IV? (which is what I have atm.*) I don't have any experience with differential transmission lines, so if it's more complicated than a few components, I'll just get a Papilion. Finally, I couldn't find the schematics for your wing board on your wiki, could you please send me a copy? Even if it's just a sketch or a screenshot, I'm a beginner and every bit helps * Cyclone IV datasheet says "Differential I/O: SSTL, HSTL, LVPECL, BLVDS, LVDS, mini-LVDS, RSDS, and PPDS" but I don't have a clue whether any of them are physically compatible with TMDS!
  16. 1 point
    Heh, "pay $10 more OR we will solder the connectors to the wrong side" Anyway, Zynq could be an interesting chip for the future. On a "fun" scale, Xilinx ISE is about the same as DIY dental surgery. Maybe Vivado improves on that...
  17. 1 point
    Thanks everyone for the replies. Sorry to make you wait. It turned out to be my logic analyser was not keeping up. I went out and got a Digilent CMod S6. This board runs at 8MHz. After loading the same exact same code, the wave form came out as expected. I then did some research and loaded up the papilio pro with a DCM that cuts the speed down to 8MHz. The papilio pro works like a champ also. After some frustrating math and and trying to figure out how the world works, it turns out the 62.5ns pulse width combined with the slight difference in speed between the oscillator of the board and the logic analyser caused a rolling variation of just enough for the samples to catch the pulses for a few ticks and then miss for a few ticks. A lesson learned indeed. Some notes: Yes, I had a reset and the counter was initialized. All the extra trimmings were in the tutorial code. But when the results were not as expected, I wanted to remove as much as possible while trying to troubleshoot the issue. My logic analyser is the Saleae Logic (the first one). It only works reliably up to 16Msps on my pc. I thought 16Msps would be good enough, but after this adventure, I think I can talk my wife into letting me get one of the new models Thanks again, and please forgive my noobness. Gotta start somewhere.
  18. 1 point
    almost there. For some reason OpenSCAD is now choking on rendering while in the GUI mode so had to use it's commandline render and export feature. The screen capture is while FreeCAD had the STL file open for viewing. I'll try to swap my filament tomorrow and print the top before printing a new bottom part too. You should see the idea from this screen capture. I also want to put holes in the top for a cover which will cover and hold the Papilio 16bit I/O level shifter wing. But if I can't figure out what's causing OpenSCAD to choke, those holes might have to be hand drilled which isn't great because I don't generally print solid parts so only the top's top and bottom would be solid(3 top/bottom layers).
  19. 1 point
    Rewiring and JTAG are outside my expertise, sorry. But I will note that according to the Papilio One Hardware Guide (http://papilio.cc/index.php?n=Papilio.PapilioOne), JTAG on this board already operates between 2.5V and 3.3V levels. It says the FTDI chip is 3.3V while the Spartan 3E's JTAG port is 2.5V. So maybe the problem is something else?
  20. 1 point
    IMO the biggest challenge facing FPGA development boards is cost. A Raspberry Pi 2 or ODROID-C1 is US$35 for a desktop-capable quad-core ARMv7 with 1 GB RAM, quad (or more) USB 2.0, and Ethernet. The cheapest Spartan-6 board I have seen from a reputable vendor is about US$70, twice as much. I had hopes for the Hackaday Arduino-Compatible FPGA board when it was first announced at US$50, but now it's up to US$70. US$35 is a great price point, because it's at a level that a hobbyist can buy without spousal approval and something students can afford. US$25 would be even better for an FPGA board. If you look at Spartan-6 LX9 pricing, it's not the chip cost. The problem is that FPGA boards aren't popular enough to manufacture in 10K or larger lots, like Raspberry Pi. The fact that there are so many different FPGA boards diluting an already small market makes the problem worse. So I would recommend designing an FPGA board that really drives the price down. I really like the Butterfly Platform that Jack posted upstream. Very simple board, with just an FPGA, bypass caps, and connectors. Spartan-6 is nice because you only need 3.3V and 1.2V -- you don't need 2.5V like the Spartan-3E. While I like having an FT2232H on board for programming, the fact is that those chips are pricey. For US$15 you can get an Adafruit FT232H breakout board which makes a dandy JTAG programmer, and you can use it for all your FPGA boards. The other big challenge is the steep learning curve of vendor FPGA software, but a number of us are working on that with various approaches. If it the software was a lot easier and there was a really cheap board we could help a lot of new FPGA users get started. JMO/YMMV
  21. 1 point
    Although TI documentation is far from the best out there Search for 'sprug04a'. Anyway, the implementation will be similar, but not exactly the same. I don't want to do a clone, for obvious reasons. Alvie
  22. 1 point
    Built two boards last night - one was trashed due to a misaligned HDMI connector, the other is looking OK. Haven't powered it up yet! Only problem so far is that the HDMI connector holes are a little bit too big... and yes, I also need to get some nice clean solder for attaching the pins, not my fifteen year old through-hole stuff!
  23. 1 point
    Yeah the subscription is only $50/year for the electronic edition (pdf download). I've been reading CC since I was a young whipper snapper, I have a full pdf collection back to issue 1.
  24. 1 point
    Assuming the need to go to multi-layer for the BGA part, that looks like it will be a very expensive board. You might look at a part such as the XC3S500E-4PQG208I which is in a 208 pin PQFP package. The FPGA is a bit more expensive but the PCB will be a fraction the cost if you can keep it to 2 layers. Also at least when it comes to Seeed, the cost of the board increases rapidly with size. 5cm * 5cm max is around $1/bd, 10cm * 10cm max is $2.50/bd, while the next size up, 15cm * 15cm max is close to $9/bd. If you can manage to keep it within 10cm square then the bare boards are ridiculously cheap.
  25. 1 point
    Latest code for windows and linux32 can be found here: http://pipistrello.saanlima.com/index.php?title=Arduino-1.5.2_on_Pipistrello