• Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

7 Neutral

About Jaxartes

  • Rank
    Advanced Member

Profile Information

  • Gender Not Telling
  1. SDRAM controller for Papilio Pro

    SDRAM isn't something I'd recommend a newbie try to deal with. It is tricky, and further complicated by the fact that until read and write both work, nothing works. Starting with simpler projects is recommended. I can't point you to any examples meant for teaching, but here are some existing projects, which use the SDRAM, that come to mind; they might be informative. "socz80" at http://sowerbutts.com/socz80/ uses Hamster's SDRAM controller with a Z80 CPU. The "ZPUino" port for Papilio Pro also uses that controller, see https://github.com/alvieboy/ZPUino-HDL/blob/master/zpu/hdl/zpuino/boards/papilio-pro/S6LX9/variants/vanilla/sdram_hamster.vhd and https://github.com/alvieboy/ZPUino-HDL/blob/master/zpu/hdl/zpuino/boards/papilio-pro/S6LX9/variants/vanilla/sdram_wrap.vhd. These might also be using different versions of the controller. I believe clock rate matters for this controller, ZPUino runs at 96MHz, socz80 at 128MHz; at much lower clock rates it won't operate right. I've found that anything on an FPGA requires a lot of debugging, it's just something you have to do.
  2. You already have ZPUino, it just needs to be loaded onto your Papilio Pro. DesignLab can do that. There's probably a menu item in DesignLab, something like load circuit, to do that, which you need to do before loading the sketch on top of it. When you tell it to load circuit, it loads a bitstream image onto the FPGA on the Papilio Pro, which configures it to act as a particular circuit. The ones with ZPUino contain a "ZPU" 32 bit processor and various I/O devices. The software in your sketch runs on the ZPU processor and manipulates those devices.
  3. More: I'm not aware of there being any chart mapping bit values to voltages. That doesn't mean there isn't one. I'd expect it to be pretty nearly linear, at least that's what I guess as "ideal." So if you measure the actual binary-analog relationship you're getting (between nybble values within your Verilog, and voltages at the VGA pins), it might tell you something. In particular: Is it the same for all three colors? Do certain bits make more or less difference than you'd expect, assuming linearity? Does any actually match what you'd expect for that bit, or one of the other bits, assuming linearity and a 0.7v full range? Does this FPGA have configurable output voltages (less than 3.3v)? Any chance one of those is in use? But it seems unlikely to cause the major difference you're seeing.
  4. Various minor thoughts, none of them very novel but I'll toss them out here: At http://papilio.cc/index.php?n=Papilio.ClassicComputingShield there are tables of pin mappings according to various notations. I wonder if settings for output current or drive strength, on the FPGA pins used for VGA, could be an issue? I haven't dealt with those, and it's probably completely different on Altera. Hooking a scope up to the digital lines (where you'd expect 3.3V) might help solve this problem. I don't have firsthand experience of the Computing Shield, but I'd expect that it generates pretty much full range 0 to 0.7v. I've used the Papilio Arcade MegaWing and didn't find the colors to be dim. If the order of bits were reversed, then I'd expect some low nybble values like 2 or 4 to show up brightly, which isn't what happened. Pick 8 of the 12 VGA color bits and put them on the (I think) 8 LEDs on the BeMicro Max 10. Then display colors. Pick just one of the 12 VGA color bits and put it on all 12 of those pins. Then trying displaying all possible color values.
  5. Regarding video timings, the pixel rate is generally higher than the calculation of refresh*horizontal*vertical, due to periods that no pixels are being transferred. For the most common 640x480x60Hz resolution, it's 40ns per pixel instead of 54ns. http://tinyvga.com/vga-timing has more detail. One way to stretch that time is to buffer part of the screen in the FPGA's own on-chip memory. If you read and buffer one scan line at a time, you can get it to 50ns per byte, using only 640 bytes of buffer memory. (Calcuation: 640 pixels in a scan line, one byte per pixel, a buffer to hold one scan line is 640 bytes; in the standard 640x480 screen, a scan line takes 32us; 32us/640=50ns.) If you can reduce the amount of memory your screen image takes up, you might be able to fit it entirely onto the FPGA without any off-FPGA RAM. That gives you a number of benefits: It's easy to work with, it's fast, and (at least on the ones I've used) it's dual-ported. The downside is that capacity is limited (it depends on the particular FPGA). But you may be able to reduce how much you need, using techniques from back when computers' memory was much smaller: Fewer bits per pixel; text mode / tile mapped graphics. (For example, 1024x768x8bpp would be 768kB, but https://github.com/Jaxartes/fpga_robots_game/ gets 1024x768 resolution with only 12kB RAM for video.)
  6. Where is the reset

    The "FPGA reset" pin resets this FPGA itself. So maybe the Xilinx software doesn't let you use that pin. There wouldn't be any purpose in using it, since your logic wouldn't be running while the FPGA is being reset. So you'd need to find an alternative. Some that come to mind: If you've got a shield board plugged into the Papilio DUO, and that shield board has one or more buttons, you can use one of the buttons as your reset. There's a slide switch on P104. If you're not using it for anything else, you could use it as a reset. It's a little inconvenient to use a slide switch for that, because you'd have to move the switch twice (once to reset, and once to stop resetting). It's also possible to write some logic that processes the switch state, so that every movement of the slide switch generates a reset. It's not trivial but it's fairly simple. The easiest way for me to describe the logic is to write it in Verilog; here goes: module reset_finder(input clk, input slide_switch, output switch_moved); reg slide_switch_delayed = 1'd0; always @(posedge clk) slide_switch_delayed <= slide_switch; assign switch_moved = slide_switch != slide_switch_delayed; endmodule
  7. Where is the reset

    I believe that's the wrong pin [in reference to a question about the clock input, and pin P55, that has been edited out I think]. The Papilio DUO generic UCF file has the following: NET CLK LOC="P94" | IOSTANDARD=LVTTL; TIMESPEC TS_Period_1 = PERIOD "CLK" 31.25 ns HIGH 50%; See also http://forum.gadgetfactory.net/index.php?/files/file/235-papilio-duo-generic-ucf/. P55 seems to be one of the external pins on the board. Generally finding out what pins map to what, I rely on the published UCF files from this site, and then if there's a confusion I refer to the schematic. Note that there is more than one set of pin numbers (FPGA, and board) and more than one kind of thing termed "clock" (SPI bus clock signal for example). I don't see the references that identify P55 as clock or P38 as reset.
  8. Robots Game

    The "snake" game from a few months ago inspired me to do something similar for the classic "robots" game (turned out, much more work than I'd anticipated!). It's implemented in Verilog on the Papilio Pro with the Papilio Arcade, but should be portable to other FPGA platforms with comparable basic capacity. I don't know if it would work on Papilio One; it uses a relatively small fraction of the on-chip resources but the timing margin is a kind of narrow. Source code repository at: https://github.com/Jaxartes/fpga_robots_game It displays in 1024x768 on a VGA monitor, and is controlled by keyboard. Or, it can be controlled from the serial port for those without a PS/2 keyboard hooked up. There's a one-minute demonstration video:
  9. Some miscellaneous tips; know that I'm not very advanced at this (I've been doing FPGA designs for two years, but only as a Saturday afternoon hobby). Using logic output as a clock is not recommended on FPGAs. I'm not up on what can go wrong with it, but I believe the routing for the two kinds of signals is different. Glitches (false edges produced by the logic) might be a problem too. Two alternatives are: Use one of the on-chip PLLs to convert the 32MHz clock to another speed (but 10Hz might be way out of its range). Use the higher speed clock (32MHz) and control the speed of your logic by applying a "clock enable" signal to every flip-flop. The clock enable is a synchronous signal, with 10 pulses per second, 1 clock cycle per pulse. That's is what I'd recommend here. Net names have to get mapped to the pins on the FPGA. Generally the constraints file (which in ISE is a UCF file) controls this. If your constraints file is missing or absent or ISE is not set to use it, you might have problems. (I don't know what exact problems they are.) You can find out what pin is used for what. It's in the GUI as "Pinout Report", or in a file named projectname_pad.txt. The first two columns are pin number and net name. Look for warning messages from the build tools. These give so very many warnings that it's a nuisance, and I often ignore them, but when something stops working, they might tell you something. The GUI can show them to you, or they appear in various output files. Some filename suffixes are: .syr, .par, .map, .bgn, .drc. ISE contains a simulator. If you can get that to work, it could show you what's going on inside your design. I haven't used it, so can't give many pointers, except I think you probably want to not use the 10Hz divided-down clock with it, it'll take too much time.
  10. edit schematic opens pdf

    .xise files are supposed to be opened by Xilinx's ISE toolkit. They're not PDF files, but for some reason it looks like your Windows system thinks Adobe Reader is supposed to open them anyway. Maybe ISE is not installed right or something. I wouldn't know why, I don't use Windows much. Operating systems trying to figure out what application to use to open a given file sometimes get it wrong.
  11. It may be possible to have a logic analyzer on the FPGA, and connect it only internally. Regarding what a wrong wishbone slot might do: No, there are ways it could turn out badly: If the register it's writing to controls the serial port: Then you might lose connectivity. And it might appear like a lockup, even though your code is running ok, it can't communicate. If there is no device responding to that address, not even enough to do an ACK: Then it would wait forever. I think ZPUino has something to prevent this, but I don't really know. A few more debugging ideas: Put short temporary debug prints in the sections of code you want to watch. You can see with more precision where exactly it's getting stuck. It might not be where you think it is. I'd use single characters. In place of the LEDs suggested above, use audio output as an indicator: Superimpose a particular sound on top, to indicate a particular state. It has its own difficulties -- it's not the simple on-off of LEDs, and you can't hear a 48MHz square wave (and probably wouldn't want to - ouch!). But if audio's what interests you, and what you have, you can use it.
  12. Some thoughts on debugging: I'm not aware of any general FPGA "debuggers" but I wouldn't necessarily know. (And I'm not a big fan of "debugger" tools anyway -- I often don't use them when I debug software.) Debugging is a real important thing when working with FPGAs. I recommend developing a wide variety of techniques, and patiently applying those techniques to the problem. One thing you can do is add output signals derived from whatever you want to monitor. So if you have a pair of LEDs unused, you could light one up when in a particular bus state, and light the other up when not in that particular bus state. When you get it running, if the "yes" LED is lit, and the "no" LED is not, then it's perhaps stuck in that bus state. If the "no" LED is lit, and the "yes" is not, then it's probably stuck in some other bus state. If both are lit, it's not stuck in any one bus state (but may be stuck in a cycle of them). Each time you do this, you might (or might not) get some information. Repeated several times, monitoring for different states, might get you somewhere. (Like: what's it doing? writing to an address. is it the device address? no. what address is it? the wrong address.) Make sure you got the right wishbone slot. If the one in your C++ code (6) doesn't match the one in your circuit, then you might be writing to some other device's registers, which could have unpredictable and dire consequences, such as causing a lockup (or causing a loss of communication). A "logic analyzer" tool exists in DesignLab, though I don't know much about it.
  13. Re mixing Verilog and VHDL: Yes, it can be done. I think it's not very difficult. Re Wishbone bus: It looks like both sides are using the Wishbone bus. The signal names are different, a few signals are missing from one or the other, and it's possible there are semantic differences between signals with similar names. I'd recommend looking at the wbfmtx page at OpenCores for some documentation of its Wishbone interface. Like maybe this one here: http://opencores.org/websvn,filedetails?repname=wbfmtx&path=%2Fwbfmtx%2Ftrunk%2Fdoc%2Fspec.pdf. (E.g. it says o_wb_stall is always set to zero) Also the Wishbone bus specification is worth looking at. That can be found at OpenCores too. Overall: I recommend trying a less ambitious project. Interfacing two complex cores together is tricky. Writing your own Wishbone core and interfacing to that, might be a good "warm up" exercise. When I was in a similar situation, I ended up writing a small Wishbone "timer" device. The advantage of a timer is it has easy to understand and investigate behavior, and it has no external interfacing other than the Wishbone bus.
  14. The "papilio-prog" command line tool displays the device DNA when I use it to load a bitfile on a Papilio Pro (Spartan6). Source code is in the "papilio_prog" subdirectory of https://github.com/GadgetFactory/Papilio-Loader. Example (underlining added): user@host:~ $ sudo ~/bin/papilio-prog -vf fpga_robots_game.bit Using built-in device list JTAG chainpos: 0 Device IDCODE = 0x24001093 Desc: XC6SLX9 Created from NCD file: fpga_robots_game.ncd;UserID=0xFFFFFFFF Target device: 6slx9tqg144 Created: 2016/06/25 15:02:07 Bitstream length: 2724832 bits Uploading "fpga_robots_game.bit". DNA is 0x59aa4afe43849eff Done. Programming time 684.9 ms USB transactions: Write 176 read 8 retries 7
  15. I expect so, though I haven't tried it. The Spartan6 FPGA, at least, can read its own "Device DNA" with the DNA_PORT primitive according to http://www.xilinx.com/support/documentation/user_guides/ug380.pdf. It sounds like maybe Spartan3E can't according to http://www.xilinx.com/support/documentation/user_guides/ug332.pdf. I don't know if reading it via JTAG boundary scan over the USB connection will work, but that also seems like a possibility.