Leaderboard

Popular Content

Showing content with the highest reputation since 08/06/2012 in all areas

  1. Hmm, this is something I started myself a while ago. One of the problems with extending the AVR softcore is that it just didn't seem to be built for a peripheral rich setup (IO space, etc). But I didn't want to leave an open source GCC based solution. Which is why I've watched the ZPU work with interest. I recently tried to use a quadrature interface from opencores, but it was far too featureful and resource heavy. So instead, I created my own "simple" quadrature interface for the ZPU, and using the standard HD44780 code in the ZPUino IDE install, created a sketch to read the quad counter and write to the LCD. It is so very nice to read a quadrature encoder as simply as: unsigned int y=REGISTER ( IO_SLOT (8) ,0); Serial.println(y); And to know that it is being clocked at 96Mhz. (Of course, I most probably have created a piece of junk, full of bugs - but I think it's cute) The code's a complete mess, but if you're interested... it's attached. View attachment: ZpuQuadDec.zip
    3 points
  2. Hi all, over the last half year I have implemented a processor and surrounding SoC bringing the RISC-V ISA (http://riscv.org) to the Papilio Pro. It implements the 32Bit integer subset (RV32IM). The project is hosted on Gitub (https://github.com/bonfireprocessor). It still needs some additional documentation, cleanup and ready-to-run ISE projects to make it easy reproducable for others. But I post this link now, to find out if anybody is interested in my work. I will soon also post a bitstream here so anybody with access to a Papilio Pro can play with it. I have also ported eLua to it http://www.eluaproject.net @Jack: If you like I can also present the project in the GadgetFactory blog. Regards Thomas
    2 points
  3. 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 points
  4. Hi, I just got started with Papilio Pro last week (side note: Great work with the papilio family and wings.. Im really excited about the board's potential). The Pro was my first entry to the papilio line. I was mostly able to figure out how to get the board running and programming. But, many of the instructions/downloads on the papilio website are either outdated or directed towards Papilio One, so getting started took about 4 hours longer than I expected. I thought I'd put together a list of links and instructions for problems I encountered along the way so that perhaps others starting with the Papilio Pro could have something up-to-date (well, as of April 2013, that is): 1. Windows FTDI Drivers: I had some real trouble getting the Papilio recognized as both a USB and a virtual COM port. For my problem, the device was ALWAYS recognized on Windows-- even when I did not have the Gadget Factory drivers installed. And it never showed a virtual COM port. Troubleshooting suggests using a different cable, or editing the device properties. Apparently in my situation, the Papilio was recognized as an FTDI device first and was not using the Gadget Factory drivers. My solution: Download the FTDI CDM Uninstaller. Using FTDI's USBView utility, find the Device Vendor ID and Product ID. Use the CDM Uninstaller to uninstall the FTDI drivers for the Papilio. After plugging and replugging, Windows recognized a virtual COM port. I could also connect through putty and see the default ASCII table output which was apparently the factory default program. 2. Getting Started Bitfile: http://papilio.cc/index.php?n=Papilio.GettingStarted It appears as though the getting started website (as of April 5 2013) does not include the getting started bit file for Papilio Pro. In my beginner state, I assumed this website would have the materials I needed, so I fumbled around trying to use the Papilio One 500K bitfile. After a while, I realized it certainly doesnt make sense to try to use the Papilio One bitfile, especially since the Papilio Pro uses a completely different FPGA. I dont think I've found a replacement for the "Getting Started" bitfile for the LX9 yet. 3. Papilio Loader: As with the bitfiles, the Papilio Loader GUI on the Getting Started Page is out of date (it downloads v1.7). According to a forum discussion around December 2012, the Papilio Loader was modified to support the Papilio Pro. Download the Papilio Loader GUI specifically from the Downloads webpage (this should be version 2.1 or later): http://forum.gadgetfactory.net/index.php?/files/category/2-papilio-fpga/ 4. ZPUino Core and Loader: I think the official ZPUino download page is a little out of date for Papilio Pro. It looks like the papilio website ZPUino getting started guide is out of date too- It uses an old version of the IDE and does not include links for the Papilio Pro bitfiles. Instead a forum post indicates the RetroCade installer works with the Papilio Pro. So, to get the ZPUino to work, download the Retrocade Synth Windows Installer from the Download Page. Use the bitfile ZPUIno_SOC/zpuino-1.0-PapilioPro-S6LX9-RetroCade-1.0.bit to program the Pro. The installer should also include a version of the Arduino GUI which includes a board option for ZPUino on Papilio Pro (LX9). 5. Intro to FPGA Book: With a functioning Papilio Loader and a ZPUino core/ GUI, I was basically good to go with the Intro to FPGA E-book. I also installed the Xilinx toolchain as instructed. No issues there. I'm looking forward to generating and programming with my own bitfiles shortly. It would, however, be nice to have an updated Xilinx webpack quickstart page: http://papilio.cc/index.php?n=Papilio.XilinxISEWebpackQuickStart. EDIT: I installed the wrong Xilinx tools at first. The default link inside the Intro to FPGA E-book now leads to the Xilinx Vivado suite, which doesnt support the Spartan 3 or Spartan 6 series. Instead, make sure to download and install the ISE Design Suite. 6. Papilio Arcade: I also tried the papilio arcade wing. Just make sure to download the correct LX9 bit files from the github https://github.com/GadgetFactory/Papilio-Arcade I havent looked at the AVR8 softcore processor. This is on my list to test with the Papilio Pro, along with some other fun things (SoC editor is on the horizon too). Like I said, Im a big fan of the board. Overall, it looks to be a really great FPGA. I do want to see the usability/ learning curve get to the Arduino level, and it helps to have a good getting started procedure for all boards. Hopefully this helps another beginner in the same situation. Thanks for all the work so far! EJ
    2 points
  5. This is a library for Designlab and Papilio Duo. The decoder module can have up to 4 encoders. For example 4 wheels on a mobile robot platform. Optionally this can be use with a PID regulator for controlling current position, velocity, and direction of an object. - The shown pins are totally optional - By default the Avr chip is disabled Download: Quadrature_decoder.zip
    2 points
  6. 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.
    2 points
  7. I have done it successfully in the past, but make sure the jumper is indeed removed. Also ensure you use as much 5V and GND wing pins as possible to lower noise and increase current capability. However, I wonder if you are replacing a PROM which used 5V as IO voltage. In this case DO NOT connect it to the wings, since IOs on the FPGA are 3.3V. There are a few solutions to convert those signals, but will depend on the IO standard (TTL or CMOS) that your system uses. If it's a TTL system, then using some 5V-tolerant buffers should do the trick. I have a design which interfaces a 3.3V FPGA to a 5V TTL system, and seems to be working OK, I can send you a link for the project if you are interested. Alvie
    1 point
  8. Hi Ben, yes the Papilio boards are a great choice. One of these boards was my very first FPGA board, and I have had lots of fun and frustration. Iniitially using the Papilio One didn't go well, but I managed to work through the various problems and finally was able to start writing my own code. Still no idea what has happened to jack :-(
    1 point
  9. Here's my first motherboard submission to the gadgetbox project: GadgetBox-Propeller. This uses the Propeller CPU which is a custom 8-core CPU designed by Parallax. All of the GPIO pins are the same, so this was fairly easy to lay out. CPU product page Known things to do at this point: Add GPIO pin labels Validate serial programming eCog graphics
    1 point
  10. Here is the problem - you take the signal from the button connected to pin C4 and use that as a clock for the ledst0 flip-flop. This is not how you use an FPGA. Pin C4 is not a clock input pin, which cause the error 1108 you see, and logic signals like btnl should not be used as a clock. FPGAs are intended to be used for synchronous logic designs where a large number of flip-flops are clocked with a common clock. In order to make this possible the clock is distributed to all the flip-flops in this clock domain using special clock buffers and clock networks. The source of the clock is typically coming from an input pin on the FPGA and only a select few pins can be used as clock input. The input clock can be used as is or can be feed to a clock management tile that has resources like PLLs and DCMs that allow you to create a clock with different clock frequency. The Nexys3 board has a 100 MHz clock input signal connected to pin V10 that can be used as system clock. This is what the Nexys3 manual states: Try this code instead: .ucf file: BTW, your switch might "bounce", so you might have to de-bounce the signal from the switch. See What is debouncing? Magnus
    1 point
  11. I finally got around to making a github repository where I've started to collect my FPGA projects together in one place. https://github.com/james10952001 These are mostly arcade related although I did add a recreation of the Heathkit ET-3400 microprocessor trainer. I still have not had a chance to fix the Xilinx ISE installation on my laptop so I haven't ported any of these to the Papilio yet but doing so should be very easy, it's all as platform agnostic as possible.
    1 point
  12. Hello, I am using DesignLab 1.0.8 under Linux and I have a small problem when generating new bit files. The problem is that the case of the files is different from the default and therefore the IDE won't flash my new file. I either need to rename the file or create a symlink. For example the Multiple_Serial_Ports example Creates a Papilio_Pro.bit file while the IDE expects papilio_pro.bit. With kind regards
    1 point
  13. The libraries are a fantastic aspect of the Arduino and the key thing that makes it a worthwhile if otherwise rather flawed platform. It took me a long time to warm up to Arduino but I love the way I can grab some widget and very often grab a library with example code to make it do something right away. It provides a great way to test the thing out and explore its capabilities right off the bat. I'd love to see a similar collection of HDL modules form, blocks of code that do the grunt work like initializing the device and communicating via whatever interface it uses and bring the controls out to sensible interfaces that can be tied into other modules in the top level file. Ideally these modules should be well commented, especially at the top level explaining what all the inputs and outputs do and what sort of signals they expect.
    1 point
  14. Hmmm... the old Papilios use the FT2232D USB chip, the newer ones (e.g. Papilio Pro) the FT2232H high speed variant. With a more recent board, uploads "should" be fast. I'm using high speed (30 MHz, clock divider 0) JTAG with the -H chip routinely. For xc3sprog, it may be enough to write cables.txt via command line option, then edit the clock rate. I think I've done that once and got upload times (but probably for a compressed bitstream) 200 ms or so.
    1 point
  15. Excellent. Now, we should document that somewhere... just unsure where. The code size different is substantial I believe, even if you don't actually use writes. Alvie
    1 point
  16. BTW, here is the official definition of drive strength, straight from the horse's mouth: https://www.xilinx.com/support/answers/38820.html "The drive strength of an I/O specifies how much current we can drive and sink while maintaining the minimum Voh and Vol levels." The bold part is the catch: it doesn't refer to the short circuit current.
    1 point
  17. Hi Jack, Sorry for the delay. Attached is the file. Thanks, fpga_guy top.bit
    1 point
  18. That's fine, thanks for giving it a go. I'll take a look over the weekend and upload a ready to go configuration.
    1 point
  19. Well here's where I am with this so far, I'm posting these in case I get hit by a bus or something, one of my pet peeves is when people show off cool projects but then never release the code, so here's the code. Currently this is set up for an Altera FPGA but it was originally written for Xilinx and I do intend to port it back to the Papilio, doing so is relatively easy. These are set up to work with the program ROMs in an external parallel EEPROM because the little EP2C5T155C8 I'm using lacks sufficient block RAM to hold all the ROMs internally but the FPGA on the Papilio boards is large enough that this is not needed. Anyway here's the state of things: Asteroids Deluxe - Fully working, no high score save yet but that was never implemented by MikeJ who originally released this on fpgaarcade.com Asteroids - Works but several of the sounds are missing which really detracts from the game. If someone wants to work on modeling the missing sound circuits that would be cool. Lunar Lander - This is not working at all yet and I'm banging my head against the wall trying to determine why. The hardware is very, very similar to that of Asteroids, more ROM, less RAM, one of the input banks is done differently, it also has an analog input for the thrust control but that shouldn't be necessary for the attract mode to run. I could really use a bit of help getting this to run at all at which point I'll work on the details. Currently I've got the watchdog disabled because otherwise the reset keeps pulsing. Trying to figure this out has distracted me from finalizing the hardware revisions and polishing up the other two games. I printed out the schematics, highlighted all the changes I could find and then methodically implemented them in the code but it's possible I missed something somewhere. Asteroids Deluxe.zip Asteroids.zip Lunar Lander.zip
    1 point
  20. Yes. You can create designs using the standard Xilinx ISE and VHDL or Verilog.
    1 point
  21. check out papilio loader http://papilio.cc/index.php?n=Papilio.PapilioLoaderV2 i think thats the latest. if you have problems, search the forum for papilio loader assumes that you know how to use xilinx ise, et al. // F
    1 point
  22. 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.
    1 point
  23. 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: http://www.saanlima.com/download/Papilio_One/ , they are generated from the current Open Bench Logic Sniffer Verilog source files. Cheers, Magnus
    1 point
  24. Hey all! I'm a graduate student in chemical engineering at UC Berkeley and as a side-project, I'm exploring the possibility of implementing various types of process controllers on FPGAs. My home operating system is Ubuntu and I had a heck of a night scraping together bits and pieces of advice from across the Internet to get Xilinx ISE and Papilio Loader set up and successfully writing bitfiles to the FPGA, so this morning I wrote up a little how-to guide: https://github.com/brandoncurtis/fpga This is just a starting point, and I hope to provide step-by-step guides to more advanced projects as I learn them. I'm particularly interested in updating the examples in the excellent but venerable Intro to Spartan FPGA eBook to run on the Papilio Duo and whatever other hardware I can get my hands on, and enable a side-by-side comparison of VHDL and Verilog for anyone who's interested in learning both. I'll improve the setup guide by trimming unnecessary steps just as soon as I have the opportunity to do a fresh install on another machine. In the meantime, I'd love feedback! If you're using Ubuntu, let me know these steps are working for you or if you know of comprehensive guides elsewhere.
    1 point
  25. Thanks Jack! It would be an honor to see this on the Gadget Factory blog. This project was quite suitable for the Duo, since it makes use of the AVR chip for some of the basic math and input controls processing, and leaves the hard stuff to the FPGA. Also, hats off to Hamster, whose own Mandelbrot project were the inspiration for this. My project was not a copy of his (after all, my objective here was to learn), but I did learn quite a bit from his implementation on how to pipeline a project like this. I posted a few other details on the project on the YouTube post, but I suspect some of the readers here would be more interested. Here is the bullet point description: • The Atmega32U4 is used to process the analog joystick, buttons, and rotary encoder to set the cursor position, zoom, and color map. This information is sent over to the FPGA via an SPI interface. • The FPGA runs the 800x600 pixel fractal calculations at 200 MHz using the onboard DSP48s. • The fractals are saved to SRAM, with each pixel stored as a 1 byte word. • A set of selectable 12-bit color maps are stored using the FPGA BRAM. I currently have over a dozen, and am planning on adding more color maps. • An 800x600 pixel SVGA controller on the FPGA is used to send a 12-bit color image to the LCD. I used the snap-off VGA wing from the LogicStart Shield. The LCD was an inexpensive 7” screen purchased off eBay, typically used for Raspberry Pi projects. • The case for this design was 3D printed, and custom designed just for this project. Finally, the 3D case could be easily modified for a more general purpose Papilio Arcade. The Papilio Duo drops right into it. Perhaps I'll post the SketchUp file on Thingiverse if there is interest.
    1 point
  26. congrats, and welcome to the papilio world.
    1 point
  27. You will need to eventually filter those, and also do some clock domain crosssing. All depends on exactly what you want to do. Simulation and real-world differs a lot when the IO pins are used. Care to share more information ?
    1 point
  28. Pics, as promised. All 5 wings now with proper headers, and packed (ESD-bag) for shipping.
    1 point
  29. I don't have a Nexsys 3 board but from the schematic the clock coming in on Pin V10 is a 100MHz clock. You can't define it differently in the ucf, even if you do it will still be 100MHz. You need to run it into a DCM and generate the appropriate clock, which looks like it needs to be 20MHz. Use the IP manager in ISE or Vivado to do that, then instantiate it where it tells you to in the top level file (below line 52 in the original, it says -- use a DCM to generate 20Mhz clock required by VGA process)
    1 point
  30. I finally got to a computer and was able to download your original file and can see some of your problems. 1) You declare the VGA signals correctly in the top level entity on lines 15-17 as std_logic_vector but on lines 26-28 you need to keep VideoR, VideoG and VideoB as std_logic, not std_logic_vectors. This will fix the errors that come up on lines 88, 90 and 93 during synthesis. Change lines 26-28 to this: signal VideoR : std_logic; signal VideoG : std_logic; signal VideoB : std_logic; 2) On line 46 do connect the signal VideoR to each bit of the O_VIDEO_R like this: O_VIDEO_R <= VideoR & VideoR & VideoR; Do the same for the other two colors: O_VIDEO_G <= VideoG & VideoG & VideoG; O_VIDEO_B <= VideoB & VideoB; -- only 2 bits. That should get you through synthesis. Now for the Place & Route, you need to make sure you have the correct signal names in the ucf file. You need to uncomment (remove the leading #) and match the names to the names on your top level entity. For example on the nexys3_master.ucf you need the change line 156 to: NET O_VIDEO_R<0> LOC = "U7" | IOSTANDARD = "LVCMOS33"; do this for all the signals on your top level entity. I think that will get you through all the problems I can see.
    1 point
  31. I went to google code and looked at the original source your are trying to modify. I don't know what other mods you made but from what I can see the errors you are getting above are caused by the fact that you didn't change the O_VIDEO_x signals into vectors. You are also trying to connect the outputs to the internal signal in some cases, it only works the other way around. Since the top level signals you are trying to make into 2 or 3 bit vectors are defined as std_logic right now if you want to make them 3 bit std_logic_vectors you need to do this: change O_VIDEO_R : out std_logic; to O_VIDEO_R : out std_logic_vector(2 downto 0); in the entity definition (line 15 in the original code). Do the same for the O_VIDEO_G and O_VIDEO_B, if you want them to be 2 bit instead of 3 then define them as std_logic_vector(1 downto 0); then where the O_VIDEO_R is connected to the internal signal in the architecture (line 46 in the original code) connect it like this: O_VIDEO_R <= VideoR & VideoR & VideoR; Do the same thing for G and B. The other thing you have to do is make changes in the constraints file to account for these extra bits. The ucf files have the bits defined already you just need to comment out the original O_VIDEO_R (and G and B ) lines by inserting a pound sign in front of them (#) then remove the pound sign from the front of the lines that you want to connect, like O_VIDEO_R(2), O_VIDEO_R(1), O_VIDEO_R(0) and make sure all the signals are connected to the right pins on the FPGA.
    1 point
  32. I agree with Jaxartes that when going from one bit to multibit vectors connection of the single bit to all bits of the vector is a better solution, go from zero to full scale. Thanks for correcting that. If you want to go the other way from multibit to one bit you would use just the msbit of the vector as its transition from 0 to 1 represents the mid point. This is only on unsigned of course.
    1 point
  33. 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.
    1 point
  34. 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.
    1 point
  35. And we were able to do a full simulation of the system, so we can find bugs on it.
    1 point
  36. 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
    1 point
  37. 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."
    1 point
  38. 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).
    1 point
  39. 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
    1 point
  40. I'm only using the FPGA on my Papilio DUO, so I force the AVR into reset by setting ARD_RESET (FPGA pin 139) low. I think this makes all AVR I/Os high-impedance.
    1 point
  41. 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...
    1 point
  42. Jack, Yeah I would agree. I think it is a tall order and they can't be making any money doing it. They must have some sort of plan for generating income from other methods to support it. Hopefully it pans out though. John, I don't know the kind of projects you work on, but for the ones I working on the $55 board with like $15 is connectors and wires would work fine for me. Most of the projects I am working on only require networking and GPIO. I would agree on the open source term. I think probably they are referring to their app and configurator and the hardware being open source, just like designlab is open source but ISE is not. But I think you are 100% correct that all Zynq use closed source for the FPGA portion at least. Of course, the Linux that runs on the ARM's hard processors is open source so possibly if you don't use the FPGA fabric it could be considered open source, but to me that defeats the purpose of using a Zynq board, might as well just use a cheaper ARM. What I hope works out is their app for configuration and deploying solutions, if they get enough of solutions to chose from. If anyone has worked on a Zynq project, one that is more than just loading an demo image, all I can say the process is tedious at best. I have one configuration that I have petalinux on CPU0 and bare metal on CPU1(AMP config) plus FPGA logic. Very tedious to build the multiple board support packages, bootloaders, drivers, on top of normal code and keep it all in sync so it all builds. Just my thoughts. Thanks, Chris
    1 point
  43. 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.
    1 point
  44. Hi all, I received my Duo last week, and this weekend I've been porting the Acorn Atom FPGA design to run on it. Here's the end result: You can get more details from the thread over at stardot.org.uk. This design currently uses an AVR Soft Processor to run the AtomMMC software stack for the SDCard interface. My next step is to try switching to the ATmega32U4, which will free up quite a lot of FPGA resources. All of the VHDL code is on github: https://github.com/hoglet67/AtomFpga There is also a Duo bit file: https://github.com/hoglet67/AtomFpga/blob/master/Atomic_top_duo.bit If you want to try this out, you'll need the Atom Software Archive. Download AtomSoftwareArchive_20140817_V7.zip from the above thread, unzip it onto a blank FAT32 format MicroSD card, pop in into the Duo and hit Shift-F10 (F10 is mapped to the Atom Break key). Here's a screenshot of the Menu system help page: Search (S) is the single most useful way of finding a specific program, once you know what it's called. GALAXIAN (Bug Byte) is a good program to try first! Please let me know if you manage to get this working, either here, or over on the stardot.org.uk forums. Dave
    1 point
  45. Jack I have used the standard Arduino PS2 library which I found here: http://playground.arduino.cc/ComponentLib/Ps2mouse The link to download the library is http://playground.arduino.cc/uploads/ComponentLib/ps2.zip Please note - that in the header file ps2.h you have to change WProgram.h" with "Arduino.h". I put the mouse into PS2/A and the keyboard into PS2/B You set up the pins with the following lines of code: PS2 mouse(5, 4); //PS2/A Mouse Clock = 5, Data = 4PS2 kbd(39, 41); //PS2/B Keyboard Clock = 39, Data = 41 Here's the simple test sketch #include <ps2.h>#define circuit Computing_Shieldunsigned int x_abs = 32767;unsigned int y_abs = 32767;int delta_x = 0;int delta_y = 0;/* * an arduino sketch to interface with a ps/2 mouse. * Also uses serial protocol to talk back to the host * and report what it finds. *//* * Pin 5 is the mouse data pin, pin 6 is the clock pin * Feel free to use whatever pins are convenient. */PS2 mouse(5, 4);PS2 kbd(39, 41);void kbd_init(){ char ack; kbd.write(0xff); // send reset code ack = kbd.read(); // byte, kbd does self test ack = kbd.read(); // another ack when self test is done}/* * initialize the mouse. Reset it, and place it into remote * mode, so we can get the encoder data on demand. */void mouse_init(){ mouse.write(0xff); // reset mouse.read(); // ack byte mouse.read(); // blank */ mouse.read(); // blank */ mouse.write(0xf0); // remote mode mouse.read(); // ack delayMicroseconds(100);}void setup(){ Serial.begin(115200); mouse_init(); kbd_init(); Serial.println("Starting"); }/* * get a reading from the mouse and report it back to the * host via the serial line. */void loop(){ char mstat; char mx; char my; unsigned char code; /* get a reading from the mouse */ mouse.write(0xeb); // give me data! mouse.read(); // ignore ack mstat = mouse.read(); // left button = 001, right = 010 mx = mouse.read(); my = mouse.read(); if(mx>=0 && mx <= 127) { delta_x = mx; } if(mx>=128 && mx <= 255) { delta_x = -(255 - mx); } if(my>=0 && my <= 127) { delta_y = my; } if(my>=128 && my <= 255) { delta_y = -(255 - my); } x_abs = x_abs +delta_x; y_abs = y_abs +delta_y; Serial.print(mstat, BIN); Serial.print(" "); Serial.print("\tX="); Serial.print(mx, DEC); Serial.print("\tY="); Serial.print(my, DEC); Serial.print("\dX="); Serial.print(delta_x, DEC); Serial.print("\dY="); Serial.print(delta_y, DEC); Serial.print(x_abs, DEC); Serial.print(" "); Serial.print(y_abs, DEC); Serial.println();// code = kbd.read(); // Serial.print(code, HEX); // Serial.print(" ");} My more complicated sketch can be found on github gists here https://gist.github.com/anonymous/892a097bc8bbbbf1c5ca regards Ken
    1 point
  46. Yes, no functional difference at all. However, if you do want to use "counterNext" more than once, it will tell synthesis tool that you want only one adder. Although it may not follow the advice. Not always true. Actually, I find the opposite much more readable and understanding, if you follow some rules/conventions. What I often do is this: -- Inputssignal ina, inb: std_logic;-- outputssignal outa, outb: std_logic;type sync_elements_type is record a: std_logic; b: std_logic;end record;signal r: sync_elements_type;process( clk, r, ina, inb ) variable w: sync_elements_type;begin w := r; -- copy regs into variable if ina=1 then w.a := '1'; -- Synchronous. outa <= '0'; -- Asynchronous outb <= '1'; elsif inb='1' then w.b :='1'; -- Synchronous. outb <= '0'; -- Asynchronous. outa <= '1'; else outa <= '1'; outb <= '1'; end if; if rising_edge(clk) then r <= w; -- Update synchronous elements. end if;end process;Alvie [Edit: it posted before I finished]
    1 point
  47. I decided to also port the Demon 3.07 verilog code to Papilio_One. This version is identical to the code running on the OpenBench Logic Sniffer board except for using 32MHz oscillator and using serial@115200 instead of SPI. It supports both meta data and input pin data query. The full XISE project can be found here: http://www.saanlima.com/download/Papilio_One/Papilio_One_OLS_3.07.zip 250K and 500K bit files are attached. Let me know if you notice any strange behavior. View attachment: logic_sniffer_P1_250K.bit View attachment: logic_sniffer_P1_500K.bit
    1 point
  48. Since I started digging though the Galaxian code yesterday, I couldn't just stop there so I ended up doing the following: The video on my monitor seemed to ride a little too high (in portrait mode) so I'd have to fiddle with the adjustments to center the picture. I got sick of doing that and replaced the scan doubler originally written by MikeJ or fpgaarcade with my own that I developed for my BombJack implementation. My scan doubler does a few things differently and more closely implements the VGA timing for the sync signals therefore the picture just ends up centered on the monitor without having to fiddle with buttons, in fact just reseting the monitor settings to factory defaults still ends up with a centered picture due to the scan doubler observing the correct front/back porch and sync signal polarity and duration. It also requires and generates composite blanking signals, see why below. In the process I also simplified the clock section and had it generate one additional 24Mhz clock which I required for my scan doubler, but more importantly that clock is required if you want to bolt on an HDMI output on the end of the scan doubler. The reason 24Mhz is required is because it is very close to the VGA standard 25.175MHz but also is an integer multiple of the 6Mhz that the game video runs at. To run an HDMI output you simply feed the scan doubler output into the DVID module that Mike Fields created. That module requires composite blanking signals as well as 24Mhz and 24*5 Mhz clocks to generate an as close as possible to VGA signal. This was tested successfully and it works. I didn't like how the top module of the project that was geared towards a Papilio board just contained all the game sub-modules. I think it is more proper to separate the game logic from the board implementation. As such the game module itself should be self contained, it should take as inputs some clocks and player controls and it should have as outputs the original video (not scan doubled) and sound. This game module can then be imported into a top level board specific module that then connects other stuff to the game module to make it work in a particular environment. Such add ons can be the scan doubler, a PS2 keyboard controller that is then converted to button presses and fed to the game module, the DACs, etc. So I went ahead and separated the game logic itself from the board specific bits and pieces. While trying to eliminate some warnings, I also ended up switching some negative logic signals to positive logic simplifying some code across several modules. Finally, some good stuff, the sound! I saw some complaints that the Galaxian was missing the right channel, sound effects. These include the ship explosion sound, the shooting sound and the background sound. Initially I looked at how the original author tried to implement this. He basically had three sampled sounds, one for each of the above sounds listed above and would just play the relevant sample as appropriate. These samples had been missing in the source and I couldn't find them on teh nets. I fired up MAME and recorded the background sound and the ship shooting sound but could not get a clean ship explosion as there are always other sound effects going on when the ship explodes. So I cheated and added a generic explosion sound effect. I down-sampled all of them to 11025Hz and added them to the game. Upon playing a test game I noticed that while the shooting and explosion sounds were OK, the background droning sound was just the static sample repeated over and over. The original Galaxian game actually plays that sound faster and faster as the game progresses adding a sense of urgency to the game play. I realized that just having this static sample would not do. I pulled out the schematic of Galaxian and had a look. The original hardware implements this sound with old fashioned 555 timer chips (no fancy sound generators here). Basically the CPU writes a 4 bit value to a 4 bit DAC implemented by latch 9M in the schematic. This is converted to an analog voltage by an 2-2R ladder and then feeds into a current mirror (transistors Q1 and Q2). This current mirror controls the first 555 timer labeled 9R. It causes it to generate a sweeping analog voltage, the sweep rate (how fast it sweeps) is controlled by the 4 bit A/D value from about once per second to ... um, really fast. This sweep voltage is fed to three other 555 chips, 8R, 8S, and 8T. Each of these is configured as an astable multivibrator and each is tuned to a different base frequency but the sweep voltage causes each of them to detune making each of them sweep across a range of frequencies. Essentially they are voltage controlled oscillators (VCOs). The outputs of these three VCOs are a set of square waves that combine together via resistors R24, R27 and R30 and are further filtered by C20, therefore this is a low pass RC filter causing the sharp sound of the square waves to be smoothed into the familiar droning Galaxian background sound. Each of the three VCOs is further controlled by lines FS1, FS2 and FS3 so each of them can be selectively enabled or disabled from producing sound. These lines were not connected in the original game source as they didn't have anything to control since the original author just played a static sample for the background. So what I did was implement a VCO module, that currently just generates a sine wave of a certain frequency based on an input value. I didn't want to bother with generating square waves and then passing them through digital filters, while that would have been a more faithful representation it adds complexity. So the VCO module it replicated three times and they are all controlled by a modulator that uses lookup tables to feed the VCOs their frequency based on the 4 bit A/D value generated by the game CPU. In practice, the game is much more realistic now with the background sound that changes cadence as the game progresses and becomes faster and faster just as the original Galaxian. The other sounds, the shooting and explosion are still just samples even though the original game implements them with discrete hardware. The explosion sound is a one bit digital noise that is passed through a low pass filter to create a the explosion noise. The fading volume of the explosion (starts loud and fades to quiet) is implemented via an analogue switch and a capacitor that discharges as the sound it played controlling the volume. The shooting sound is also a combination of a 555 timer chip 7S producing a base frequency which is modulated by the one bit digital noise after passing through an RC filter. The fading volume is also implemented by another analogue switch and capacitor. Implementing these two types of sounds in hardware is a bit challenging due to all the analogue electronics involved so for now we'll just have to put up with the two sampled sounds each consuming exactly 8KiB. I haven't uploaded the source anywhere yet as I'm still fiddling with it, if there is any interest I will share the last stable snapshot. Oh forgot to say, this of course means that other games using the Galaxian hardware will have these sounds, tested with Balck Hole so far.
    1 point
  49. I've just got DVI-D running on a Spartan 6, starting from scratch (well, the DDWG specs at http://www.ddwg.org/downloads.asp ) You can find the details of my project (incl all the vhdl source) here: http://hamsterworks....x.php/Dvid_test Feel free to use it in your own projects. Wonder if it will work on the Papilio Pro? Might have to butcher a cheap HDMI cable... Mike This post was covered on Hackaday too. http://hackaday.com/...m-vga-to-dvi-d/
    1 point