Jaxartes

Members
  • Content count

    90
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Jaxartes

  1. Jaxartes

    About FPGAs and how to choice

    Re FPGA capability, short answer: It's complicated. And I'm almost a newbie, but here are some thoughts and pointers. For figuring out what a given FPGA can do, the best way is to look at what results people have gotten from trying similar designs on similar FPGAs. Somewhere on the forum there're discussions about resource usage and clock rate with AVR8 (an Atmel-compatible core) running on a Papilio board; the results may extend to other boards using the same FPGA chips. You can download vendor tools, and run them on an actual design (for whatever chips you have in mind) and see what results they give you. The general story is more complicated than number of gates or any straightforward set of numbers. It's going to depend on the particular FPGA architecture and the particular design and how the features of one make the other work. For instance, logic on the Xilinx Spartan3 (used in Papilio One) consists primarily of 4-input lookup tables (LUTs), while that on the Xilinx Spartan6 (used in Papilio Pro and Duo) is in 6-input LUTs. A 6-input LUT is "more logic" than a 4-input LUT, but it'd be hard to quantify how much more. Either one is more than a 2-input "gate" but again, by how much? And FPGAs have other, more specialized logic in addition to the LUTs: Block RAM, carry chains, multipliers. It can make a big difference, how well your design takes advantage of those. 10k gates sounds really small. Even 100k gates sounds small; the smallest that the Papilio series uses is 250k gates. Clock rate also can vary a lot, depending again on the particular logic design and how it fits into the FPGA's particular resources. It can vary pretty widely. 8MHz doesn't seem like a problem, though, for recent chips. Choosing an FPGA board often comes down to other things, for me it was what I/O devices are attached to it, and how it connects to a host computer. I found "100 Power Tips for FPGA Designers", by Evgeni Stavinov, very helpful. The e-book edition is much cheaper than the print one, by the way. (Code examples are in Verilog, but code examples aren't IMO the most important part.)
  2. Jaxartes

    N-Core CPU

    It seems possible to get a usable CPU down to a bit below 10% of this FPGA. There's a 442-LUT version of ZPU, for example. (My own CPU in progress is 549 LUTs at last count -- just a hair under 10%, but it's 16 bit, and incomplete.) ZPUino's size includes a higher-performance implementation of ZPU, plus various peripherals. You won't need the performance, and you won't need to duplicate the peripherals for each CPU core, and that should save you some space. OTOH, one can always be surprised by how much space things take up.
  3. One thing about clock generation is that using a logic signal as a clock (as in 'rising_edge(tap)' above) is discouraged in FPGAs. As I understand it (which is limited, I'm still sort of a newbie) one of the problems is: Logic is sometimes "glitchy" (temporary bogus output values that last less than a clock cycle, and thus wouldn't matter, unless you use them as a clock). Another has something to do with routing and timing analysis. One alternative, if you want to run part of your circuit slower than your clock, is to use a clock enable. Suppose, for example, "CLK" is your clock and "en" is a signal that's HIGH for one out of every five clock cycles. Then you'd do the following: if rising_edge(CLK) and en = '1' then do <= stuff; end if; (Please pardon any syntax mistakes, I mostly use Verilog and am unfamiliar with VHDL.) The FPGA hardware has special support for handling this sort of thing.
  4. Jaxartes

    About papilio one board

    You can find those at http://papilio.cc/index.php?n=Papilio.PapilioOne. Look near the bottom of the page.
  5. Jaxartes

    LogicStart Shield for the Papilio DUO

    Ralph -- One thing that failed for me, on my very first design, was that somehow Xilinx ISE didn't read the UCF I gave it, and ended up assigning the wrong pins to everything. I don't know why it did that for me, and I have no way of knowing if that's what happened to you. But it's one possible explanation. Glad to hear it's working now.
  6. I haven't tried running it, but there seem to be some mistakes in the tutorial: 1. It's shifting bits in from the right, so the last bit received is the least significant bit. But from the info I've seen, it should be the other way around. 2. While I understand all the explanation of why the TX line is the FPGA's input in the tutorial, it doesn't seem to be the case. In my own designs I've used that same "TX" pin (T105 on the Papilio Pro) as output. And while my designs have failed many times in many ways, they've sometimes worked. Examination of the Papilio Pro schematic and the FT2232D data sheet reveals that they refer to that pin as "RX". So I think the names TX/RX were switched in the UCF file, to be easier to understand, and then the tutorial explains switching them again. #2 seems more likely to be relevant. #1 wouldn't make a noticeable difference when illuminating LEDs, it would just get them backwards. Another project I took a look at also seems to use the "P105" pin as output, not input: https://github.com/alvieboy/ZPUino-HDL/blob/dcache/zpu/hdl/zpuino/boards/papilio-pro/S6LX9/papilio_pro_top.vhd https://github.com/alvieboy/ZPUino-HDL/blob/dcache/zpu/hdl/zpuino/boards/papilio-pro/S6LX9/papilio_pro.ucf
  7. Jaxartes

    USB

    Not native USB, but a virtual serial port over USB. Which is a bit more "old school" with the advantages and disadvantages that implies. (Less plug-and-play, less possibilities for custom protocol, but easier to manage at both ends.) I base what I'm saying on the Papilio Pro, but http://papilio.cc/index.php?n=Papilio.PapilioDUOHardwareGuide, seems to indicate the Duo will be similar: "Channel B is connected to the Papilio DUO in an Asynchronous serial UART configuration that is capable of speeds up to 3MHz". I haven't used the Duo; I have a Papilio Pro which is similar but without the ATmega chip. The USB connection to the Papilio would appear on the host computer as a serial port -- that is a COM port on Windows, a TTY on Linux. Data rate is less than full USB, but may still be good enough, depending on how much data you want to pass. Your protocol would require some changes to go over serial (which is just a stream of bytes each way) instead of USB (which has more control).
  8. Jaxartes

    Newbie on Mojo V3

    Here's a rough outline of how I'd approach this problem, and a dump of a few "places to look" for various details. The general approach is: 1. Figure out what you've got already decided for you; what you're pretty much free to find somewhere; and what you're expected to put together for yourself. That's going to depend on what your Professor wants and what you're being tested on. Generally the "parts" for this are: a. The FPGA board. That's already decided for you: Mojo v3 b. Wiring on the VGA side. That may already be done for you (in the form of an I/O board that plugs into the Mojo), or maybe you're expected to design and put one together. The schematic of the Arcade MegaWing might give you some ideas (http://papilio.cc/index.php?n=Papilio.ArcadeMegaWing). c. Wiring on the serial-port side. Sounds from what you're saying like that's chosen for you. d. What protocol you're going to use for transmitting the image from computer to FPGA, over the serial port. Could be simple, or fancy. Could be standard, or roll-your-own. Could be decided for you, or you could be free to come up with your own. d. The RTL (Verilog or VHDL) for the serial port communication. There are plenty already implemented, or if you have to do your own, it's not impossible (was my first substantial project). e. The RTL (Verilog or VHDL) for the VGA output. There are plenty already implemented, or you can do your own. f. Memory to store the image while it's on the FPGA. Almost certainly this is whatever memory is built into your FPGA. The one that's used in the Mojo, and in the Papilio Pro, has ~64kB. That's enough for 800x600x1bpp, or 400x300x4bpp, or so on. Off-FPGA memory is also possible, but more painful to work with, even on a board (such as the Papilio Pro) that has it. 2. For each, if it's decided for you: Figure out how it interacts with the other parts. If you're free to choose: Pick one, figure out how it will interact with the other parts. If you have to make your own: Figure out how it should interact with the other parts; and how it should work. 3. Go for it. Now for the dump of sources of information: http://tinyvga.com/vga-timing -- lists VGA timing parameters http://www.fpga4fun.com -- walks you through a few sample designs http://opencores.org/project,uart2bus -- Verilog for a way to send data (not quite "raw") over a serial port into various registers. I haven't used it, but I've used something similar, and it's quite convenient. http://www.digilentinc.com -- The manuals for this company's FPGA boards also include overviews of various I/Os such as VGA and serial ports. Random other thoughts: Debugging. You're almost certain to have to do debugging. If you use something like uart2bus to access your FPGA design "like memory," you can use it not only to transfer image data from host to FPGA, but also to transfer whatever debugging information you want to collect, back to the host, where you can display and examine it more conveniently. There's also dealing with the tools (Xilinx ISE is the one I've been using) and whatever they need just to tie things together. On Xilinx there's the "constraints file" (suffix UCF) which identifies what pins on the FPGA go to what (named) connections in your Verilog code, among other things like their electrical and timing characteristics. If an I/O board is provided for you, containing the VGA port, then there's probably a UCF file to go with it you can copy and start working with.
  9. Some things occur to me. These are oriented toward the Spartan 6 but I'd expect them to be similar on the Spartan 3E. Oh and I'm kind of a newbie so these are just ideas. 1. You really shouldn't need to be using the separate rising / falling clock edges like you're doing. The block RAM is dual ported; you can have one port doing write while another is doing read. But there are some limitations. Quoting from a book on the subject, "The inference rules and limitations are specific to a synthesis tool. For example, XST cannot infer dual-ported BRAMs with different port widths, read and write capability on both ports, or different clocks on each port." [stavinov, Evgeni (2011-05-18). 100 Power Tips for FPGA Designers (p. 165). OutputLogic.com. Kindle Edition.] And "different clocks on each port" might include using different edges of the same clock. 2. It seems best to use the same clock edge for everything. Speaking of which, in the ZIP file you attached, the code is different from your initial post; it uses falling_edge() for both ports of ram_bank, and one other place, but rising_edge() in other places. 3. Admittedly, that doesn't explain why it didn't work when you used the same clock edge on both ports, but that could just be some unrelated problem. 4. You ask if 200MHz is too fast. As I look at "main.twr" (file you included in your ZIP) I see at the bottom, "Maximum frequency: 23.753MHz". Now, that's relative to the 32MHz system clock and not the 200MHz derived clock, but still, it's not meeting it. That file also lists a few of the worst-performing logic paths. One of them is allowed only 1.250 ns, trying to squeeze some event between a tick of the 32MHz clock and a tick of the 200MHz clock. Since this is going to an I/O port it probably shouldn't be a big issue. But maybe by adding an entry to the UCF file, telling ISE to relax about the timing of this one particular path, you could see if there are timing failures in your actual logic. 5. I see some timing information in "main.syr" too.
  10. Some ideas, many of them depend on what you want to do with those extra slide switches, and on how advanced you are in all this. 1. You can get more than 2, up to 5 bits out of the mini joystick if you're willing to put up with some inconvenience to the user (you), and losing some of your LEDs. The idea would be to have "virtual slide switches" (registers on the FPGA) and each of the five momentary contacts would flip the corresponding switch. The two main requirements are: (i) debounce (so that they don't flip twice) and (ii) use an LED to show the state of each virtual switch. 2. If you just want to get data in (or out) of the Papilio, and don't need it to be switches, buttons, etc, then one option is to go over the USB cable from your PC. Implementing a serial port from scratch might be a little tricky, but there are also pre-made cores available for that. You might look at http://opencores.org/project,uart2bus; I haven't tried it myself, but it seems similar to (and a bit better than) what I've been using. The idea is that UART-to-Bus treats your design like memory; you then decode, this address refers to one of your signals, that address refers to another one, and so on. 3. Regarding your ADC idea, you can also get a working SPI implementation from somewhere if you don't want to make your own. For instance, there's one in chapter 24 of Hamster's "Introducing the Spartan 3E FPGA and VHDL" ebook. I'm curious what you want to use all those slide switches for.
  11. Jaxartes

    Math-free digital clock.

    @johnbeetem: I'd assume "math-free" really means "numeric-arithmetic-free." And one advantage of working with polynomials modulo 2, as in LFSRs and CRCs, is that the analogues to addition and multiplication are exclusive-OR, AND, and shift. There's no carry. And if you use Galois-style LFSRs instead of the more popular kind, you can keep the logic depth constant, which might help you achieve a high clock rate. It might not save you very much on an FPGA, though, which has stuff like hardware carry chains to speed up addition. In a book I read, the author tested various counters for maximum clock rate, and found the LFSR to actually be a little slower than the binary counter, and use more LUTs, though fewer slices. @hamster: Kewl. So, is the 'lfsr <= "0111110111010111001000000"' in pulse_per_second.vhd meant to shorten the cycle from 2^25-1 to 32 million clocks?
  12. hib1 -- One possible cause of those errors is if "counter30" is missing from your project. See if the files containing both the pieces of VHDL code from Hamster's post are included in your ISE project. I tried this out just now: copied those two pieces of code into two files, added both files to a new ISE project, and built it. And it succeeded, without errors and mostly without warnings (what warnings I got may relate to the fact that I didn't bother including a constraint file). Then I removed the first one, the one which defined counter30(), and tried building again: It failed with the same two errors you list.
  13. The UCF file, and the bit file generated by the ISE tools, don't need to contain the layout of the boards. The UCF just identifies what pin on the FPGA corresponds to each of several signals in your design; and any special electrical signalling they need. For instance, in 'NET switch_1 LOC = "P3" | IOSTANDARD=LVTTL;': 'NET switch_1' -- indicates that the signal is referred to in the VHDL code as "switch_1" 'LOC="P3"' -- attaches it to pin 3 on the FPGA chip 'IOSTANDARD=LVTTL' -- identifies the electrical signals used. Pin 3 on the FPGA chip is connected to a particular trace on the Papilio board, and through it to a particular pin on the Papilio's expansion header. The LogicStart MegaWing, in turn, connects that particular pin to one of the switches. A different wing might connect it to a different device. This page describes what pin is connected to what on the LogicStart: http://papilio.cc/index.php?n=Papilio.LogicStartMegaWing As far as the FPGA software is concerned, it doesn't much matter what physical device it's connected to. It just needs to know which signal in your VHDL code goes to which pin, and what kind of electrical behavior and timing it needs. The downloads section of this forum has UCF files for the various combinations of Papilio and MegaWing boards. All I did was download the one for mine, then trim off the lines for signals I'm not using in my current project. (The constraints file can do a lot more than this, but I haven't tried that stuff yet and it's not really related to the question.)
  14. Jaxartes

    Rising_edge and falling_edge

    @Chris_C: I think the point of the flancter is not the counting (that's just given as an example) but handling input pulses that are so short that you can't sample them with your clock. I gather that crossing clock domains, or dealing with asynchronous (clockless) data, is quite a pain. That's what would make the flancter useful. Re synthesis: I've also heard that what's synthesizable on one FPGA might not be on another; or even with a different synthesis tool. Another reason I can think of that you might want to simulate something you can't synthesize, is if half your circuit is synthesizable RTL (your circuit in all its glory) and the other half is a non-sythesizable behavioral model. Like perhaps that second part isn't done yet; or it's something you're going to buy and this is just a sample; or it's an off-FPGA component on your board. Re simulation: My simulator of choice is Icarus Verilog. Free, relatively capable, command line oriented. But so far I seem to be using it more for debugging than testing. Also a quick (if over-lenient) syntax checker.
  15. Well, condition codes as such are definitely not needed; many architectures don't have them. But they have some kind of conditional instruction. Oh, I could see doing without it but it's more convenient. A couple of approaches I've seen to doing conditionals without a conditional flag: checking a register directly (jump if Ra > 0); or skipping the next instruction. Skipping would be made trickier by having variable length instructions, but could still be done. Including a stack in your instruction set isn't necessary, if you're willing to use ordinary address arithmetic and an index register to accomplish it. Then what you'd really need to add is an instruction to save PC to a general purpose register, either by itself or combined with a jump. One thing if you're using a small data path size like 8 bits, is you'll want a way to build wider operations out of it. A common way is to use a carry flag. If you really want to do without conditional instructions, I have some idea how it might be accomplished, here's an example: "if (A >= 0) then go to T else go to E" might be done as: shift A right 7 bits // extract the sign bit subtract 1 from A // now, if it was negative, we get 0; if positive, we get 255 build a target pointer P: P = (A & T) | (~A & E) and jump to P But conditional logic is such a common thing to program, you'll probably want it to be easier than that. Maybe a single instruction, "if the last operation's result was in the range 1-127, copy A to B; otherwise do nothing"?