• Content count

  • Joined

  • Last visited

  • Days Won


Jaxartes last won the day on February 27 2016

Jaxartes had the most liked content!

Community Reputation

7 Neutral

About Jaxartes

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,639 profile views
  1. Jaxartes

    VERILOG SDRAM controller for Papilio Pro

    Maybe. I don't know of one exactly. Here are some I do know of: Hamster (Mike Fields) wrote one that's been used on the Papilio Pro. But it's in VHDL not Verilog. And the links to his site aren't working tonight. Here's a thread discussing it: http://forum.gadgetfactory.net/topic/2551-hamsters-sdram_controller/. And here's one self contained project which used the controller: http://sowerbutts.com/socz80/. Here's an SDRAM controller written in Verilog, but it's for a different chip than the one used in the Papilio Pro: https://opencores.org/projects/sdram_16bit. I've got one, Verilog for Papilio Pro; but it didn't work. I gave up on it in April 2016. There are probably others, if you search. One that's in VHDL, not Verilog, might still be understandable enough to help you. One that's for a different SDRAM chip might still help you learn something.
  2. Jaxartes

    What is a good source of reset signal?

    Not if you pass the result of all your reset logic through a register before using it as a reset -- which I recommended above (in my 2nd post) for other reasons. Then it shouldn't make any difference, to that warning, what is controlling the register. I think the cause of the warning is not with using the pin for something related to reset, but only with directly driving reset from it. The Xilinx tools will try to figure out how long signals take to propagate from where they originate to wherever they are needed. There can be a problem if they take too long, or if the time is too hard to predict. The register improves both. I don't see anything in the warning about fanout, either. I've read about reset fanout being a problem, but haven't encountered it. But then, my designs have been fairly small, have not demanded the utmost of performance, and have used synchronous rather than asynchronous reset.
  3. Jaxartes

    What is a good source of reset signal?

    Additional tip: The output of the reset logic should be synchronized by a register. That's to avoid glitches which might be troublesome with an async reset.
  4. Jaxartes

    What is a good source of reset signal?

    Can you insert a small amount of VHDL (or Verilog) code into your Clash design, and use its output as a RESET, instead of taking RESET from an external pin? Using initializers it'd fairly easy to generate a 1 for a few clock cycles after the FPGA is initialized, and 0 afterwards. It can also be combined with a button so you'd have both ways of causing a reset. It seems like something that would have already been done, and made available as a Clash primitive, by somebody. As I think about it, you might be able to do it just in Clash, with two resets: the "outer reset" is either always 0, or is driven by a button, and is only used by the reset logic the "reset logic" has a few bits of state that's initially zero, and filled in with ones the "inner reset" is driven by the reset logic, and is the NAND of the reset logic's state Not sure of all the details, as I've never used Clash.
  5. Jaxartes

    Where can I buy Papilio Plus or similar?

    Papilio DUO from Gadget Factory has SRAM (512kB or 2MB). Pepino from saanlima.com has SRAM (1MB). The FPGA chip in both is the same.
  6. Jaxartes

    wishbone address bits

    I would guess the reason for the "downto 2" is that the bus address is in word (32 bit) units while the addresses seen by code are in byte (8 bit) units. Thus, with "26 downto 2", the numbers of the bits more closely correspond with the processor address space, i.e. wb_adr_i(10) will be byte 1024 (2**10). At least that's why I did the equivalent in my own 32 bit design.
  7. Jaxartes

    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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.)
  12. Jaxartes

    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
  13. Jaxartes

    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.
  14. Jaxartes

    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:
  15. 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.