johnbeetem

Members
  • Content count

    88
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

3 Neutral

About johnbeetem

  • Rank
    Advanced Member

Profile Information

  • Gender Male
  1. Thank you for the quick reply and the info on Papilio Unity. Will it have provision for JTAG, even if just an unpopulated header? When I'm developing for FPGAs I like to blast a bitstream directly into the FPGA rather than program an SPI flash. If the target board doesn't have an FT2232D/H, I use a US$15 Adafruit FT232H Breakout Board as a JTAG programmer. It's basically a single-channel FT2232H. I'll miss Spartan-3E/A. But they're on the way out and Spartan-6 is now the "sweet spot" last time I looked. Spartan-6 is a very complex architecture which makes life extra difficult for the new user. Fortunately there's the Lattice iCE40 if you want a simple, easy-to-understand architecture :-)
  2. The Papilio DUO uses the FT2232H, which is great (high-speed USB, 480 Mb/s). The Pro uses the FT2232D (full-speed USB, 12 Mb/s). I don't have a Pro so I have no personal experience. I get 200 ms or so for the Papilio One 250K, which is within human reaction time. The 500K is more like 500 msec, which adds significant delay to compiling and loading a small design. This is with my Flavia software, so the compile step is less than a second for a small design.
  3. Is the Papilio 250K coming back some day? For a long time I've recommended it as the best value for getting started with FPGAs and I'd like to know if I should still be doing so. I was playing with mine today and I love it way it downloads so quickly.
  4. Yes. You can create designs using the standard Xilinx ISE and VHDL or Verilog.
  5. GPMC can probably be used synchronously, but I suspect most people use it to talk to async devices such as SRAM and NOR Flash. If async buses are dead, I guess it was a bad idea to put asynchronous SRAM on Papilio DUO, eh? Seriously, an async parallel bus is still a good way to talk to lots of peripherals and has the advantage that you don't need a device driver -- you can just use mmap(). This can be an important feature for a Linux newbie who doesn't want to become a device driver guru. The Spartan-6 LX9 has lots of dual-port RAM, so an effective way to do data acquisition is to store inbound data to one side of a dual-port RAM and have the other side talk to the CPU. "Long dead" reminds me of an early unix "man" page for assembly language. IIRC, the page read "Assembly language is dead. Necrophilia will be punished." Funny, you don't see that page any more if you enter "man as"
  6. For talking to a Papilio I agree with Alvie that SPI is the way to go. While I suppose it's bad manners to mention other FPGA boards here, you might want to check out the ValentF(x) LOGI-Bone, which is a Spartan-6 LX9 FPGA board that plugs directly into a BeagleBone. This gives you the option of treating the FPGA as a 16-bit wide memory using BeagleBone's General-Purpose Memory Controller (GPMC). You also have SPI and I2C. LOGI-Bone is a nice solution provided you don't have to separate the boards too often since it's a pain to pry those connectors apart.
  7. While I'm a huge fan of FPGAs, what you want to do might be an excellent fit for the BeagleBone's Programmable Real-time Unit (PRU) Sub-System (PRUSS). In addition to its ARM Cortex-A8 BeagleBone's SoC has two 200 MHz RISC processors for real-time I/O and signal conditioning. Here's a good starting point: http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/08/04/bbb--high-speed-data-acquisition-and-web-based-ui
  8. The FTDI FT2232H USB chip has two serial channels, A and B. The FPGA programming software needs to talk to Channel A which is connected to the FPGA JTAG pins. My understanding is that the RX and TX LEDs are on Channel B which talks to ordinary FPGA I/Os, so if RX is blinking it means your programming software is talking to the wrong channel. See if Felix's suggestion works. If it doesn't, please indicate what OS and software you're using to program the FPGA.
  9. First, on latches: The Xilinx Spartan-6 does support latches. The registers in a CLB can be edge-triggered flip-flops or level-sensitive latches. The are other FPGA families that only have edge-triggered flip-flops. The CLK placement error is more serious. This error usually means that there's a conflict between two or more clock signals trying to use the same clock buffers. Your conflict might be the latch clock, or it could be something else. Spartan-6 clocking is very complex (see the Xilinx "Spartan-6 FPGA Clocking Resources User Guide UG382). Take a look at all the signals in the Map/Placement report that Xilinx thinks are clocks, and how Xilinx has assigned them to pins and clock buffers. There may be some surprises there. I've found it useful to print out some of the clock diagrams in UG382 to check for conflicts. It might be useful to post your VHDL source. I mostly do Verilog myself, but others in this community might see from the VHDL why you're having problems. In FPGA designs, it's usually best to have a single clock. You then sample inputs using this clock, usually with an extra flip-flop stage to reduce metastability. Slower clocks are often simulated by the FF's clock enable to convert the master clock to a slower clock.
  10. 1) You just need a Mini USB cable. Papilio DUO has an FTDI USB peripheral chip that talks to the FPGA's JTAG pins for programming. The Mini USB also provides enough power for most projects, assuming you get a cable that has wires thick enough to carry the current. 2) I recommend Gadget Factory's Button/LED Wing: you do need something more than DUO's single LED and slide switch for reasonable projects. There are a bunch of other Wings for more advanced projects like VGA: http://www.gadgetfactory.net/papilio-wings/
  11. cawhitely: If you haven't already done so, add a clock frequency constraint to your UCF (User Constraint File). This will tell the Xilinx tools to take timing more seriously when doing map/place & route and give a warning if it can't meet your constraint. You may have to reduce your clock multiplier to get your design to work.
  12. This means that some part of your design has a delay path that's 47.081 ns from clock to clock and you shouldn't clock your design faster than 21.240 MHz. This is assuming worst case temperature (electrons move slower at higher temperature), worst case supply voltage (electrons move slower at lower supply voltage), and worst case process (some chips are faster than others when manufactured). At room temperature with good voltage regulation (which you get with Papilio DUO), you can go faster than this -- maybe as much as a factor of 2. I don't know if the timing analysis considers the PLL multiplier -- I've never used Xilinx PLLs or DLLs, so someone will have to help me out here. If the timing analysis doesn't consider the PLL, your design is nowhere near fast enough for a 248 MHz clock. If timing analysis considers the PLL, it's telling you that the maximum reference clock is 21.240 MHz. That means Papilio DUO's 32 MHz oscillator is 50% too fast, which may be OK at room temperature. If the clock is too fast, the fast parts of your design will work but the slow parts will be unreliable. Update: alvieboy says timing analysis considers the PLL multiplier, so in your case the maximum reference clock is 21.240 MHz, which means Papilio DUO's 32 MHz oscillator is too fast for reliable operation. It may be that your design is working as far as timing is concerned, but that you don't have the BRAM configured properly. BRAM options are complex, and you have to get the pipelining correct. For example, when reading from BRAM you set up the address in the current clock cycle, but the data isn't available until the next clock cycle. Individual blocks in an FPGA are very fast, like the 300 MHz BRAM and look-up tables which are around a nanosecond. What's slow in an FPGA is the routing, especially when a design gets large and signals have lots of fanout. My Flavia (Free Logic Array via...) Spartan-6 design is basically a bunch of multiplexers that connect to each other. I get a 16 ns minimum clock cycle even though the logic is pretty shallow. All the delay is in the routing, which has to go all over the chip. Most designs are going to be a LOT better than that.
  13. I've never tried a very fast clock on an FPGA because a 3 ns or faster clock requires extremely simple combinational logic between registers. You probably can't do much of anything in 1 ns. Most of my designs are 33-50 MHz (30-20 ns clock period) which allows quite a few levels of logic and routing. When you run the Xilinx tools for your tests, what clock period or frequency do you get for post-P&R timing analysis?
  14. 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.
  15. Over a decade ago I looked into Xilinx Virtex-II Pro (FPGA + Power PC CPU) for my then-employer. It seemed like an excellent match, since we used Power PC processors. The pricing of the chips convinced us otherwise, as did the difficulty in getting a Virtex-II Pro FPGA running. IIRC, you had to configure the FPGA before you could use the CPU, which meant that you couldn't use the CPU to download the FPGA. I don't know how many mistakes Xilinx chose to retain for Zynq. We ended up using an AMCC (now Applied Micro) PPC405EP, a low-cost SoC with dedicated SDRAM interface and 32-bit PCI bus connected to a Xilinx Spartan-IIE. That worked beautifully. Unfortunately Applied Micro has deemphasized Power PC in favor of ARMv8, so it's really hard to find suitable Power PC parts nowadays. I consider Power PC to be a superior architecture, but ARM has the ecosystem on its side.