johnbeetem

Members
  • Content count

    85
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

3 Neutral

About johnbeetem

  • Rank
    Advanced Member

Profile Information

  • Gender Male
  1. Yes. You can create designs using the standard Xilinx ISE and VHDL or Verilog.
  2. 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"
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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/
  8. 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.
  9. 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.
  10. 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?
  11. 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.
  12. 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.
  13. Thank you for this perspective. I was wondering about this aspect of working with Zynq. Along with cost, this may help explain why Zynq doesn't seem to be getting a lot of traction.
  14. Adding to Jack's comment, it seems like they have an awful lot of boards there which is going to dilute their effort quite a bit. While the $55 is impressive, you'll probably need a base board to do anything useful with it. So add $10 for "down connectors" and another $55 for the piSmasher and now you're at $120, which is not so impressive. As is usual for me, I also object to their calling it "Open Source" without noting that the Xilinx Vivado software is absolutely not open-source and that there's no open-source tool-chain for Zynq that I know of. Please correct me if I'm wrong!
  15. True, most tool users aren't going to modify their tools. However, others do improve open-source software and all users benefit from the results. The reason GNU/Linux and GCC have such high quality is that since the source code is available bugs can be found and fixed, and people who redistribute the improved software are required to make the modified source code available so that improvements can be incorporated back into the mainstream code. IMO the fact that we can get cheap, high-performance microprocessors and microcontrollers is largely because chip manufacturers can adopt GNU/Linux and GCC and only modify drivers, greatly reducing software development and licensing issues so they can concentrate on the silicon. FPGA manufacturers could have taken advantage of this same opportunity if they had opened their bitstreams and IMO this could have made FPGAs a mainstream technology instead of something expensive and esoteric. Fortunately, it's not too late for them to come around. The reality is that most FPGA vendor software has a steep learning curve and since there's no competing software there's no incentive for vendors to improve things. I've found the learning curve gets steeper with each new FPGA family, and recently spent hours debugging a problem because the Xilinx ISE error message steered me in the wrong direction. Can I improve the error message? Nope, because it's not open source. Regarding RMS, I think his MacArthur Fellowship and his long list of honorary doctorates and professorships speak for themselves. Regarding IceStorm, I've been playing with IceStorm tools and arachne-pnr over the last month and I'm very impressed with their reliability and speed. I'm planning to incorporate them into my XXICC software.