offroad

Members
  • Content count

    281
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by offroad

  1. Well, but you are looking at FPGA design from a fairly unusual viewpoint :-) Thinking pragmatically, an Artix-7 would make a new user's life considerably easier over Spartan 6 simply because it comes with Vivado instead of ISE. I don't think the user needs to know anything about the internal architecture - click the green arrow and out comes a bitstream. Of course this approach will hit some wall eventually, but at a surprisingly high level, possibly into the realm of VGA pixel clocks.
  2. Thanks, you're right. I checked my board, it's D alright.
  3. Hmmm... the old Papilios use the FT2232D USB chip, the newer ones (e.g. Papilio Pro) the FT2232H high speed variant. With a more recent board, uploads "should" be fast. I'm using high speed (30 MHz, clock divider 0) JTAG with the -H chip routinely. For xc3sprog, it may be enough to write cables.txt via command line option, then edit the clock rate. I think I've done that once and got upload times (but probably for a compressed bitstream) 200 ms or so.
  4. Hi, you could check Trenz TE0725 with Artix 7 up to -100 size. I once had a Microblaze on one of them (was replaced later in the design cycle) and it definitely utilized less than 1/3 of resources. You'll want the Digilent-licensed "XMOD-FTDI" adapter to use the debugger (no idea how hard it is to set up with multiple targets, there is one JTAG option USER1-4 in the MB config that might be relevant). There is a 1.8 V variant, most likely 3.3 V is the better choice. To put it into perspective, it's probably 2x...3x the price of a Papilio. With Vivado on Artix I think you have more microblaze configuration options than on Spartan with ISE. Note: I'm not aware of any ready-made solution to access the memory module on that board. For the Papilios there are soft memory controllers, and Pipistrelly can use the hardware core that's bonded out on the larger FPGA sizes. And, for Spartan 6 there is some community but I haven't found that yet for Artix...
  5. Nice that you got it working. Just make sure no one reads this as a recommended first-step response to a board that doesn't show on USB... My experience: I've thrown some of my own (boxed) FPGA designs across the lab and smashed them against hard surfaces under the pretense :-) of drop testing. Several dozens of units. While this led to mechanical design changes, I've never managed to break a crystal, or in fact anything electronic on a board. So I wouldn't be too worried about shock-sensitive crystals. To me, this seems a failure mode as likely as thousands of others.
  6. FYI: This is the FTDI board to rule them all: "-H" means high speed version, the MPSSE will clock up to 30 MHz and this works reliably with JTAG+Xilinx. http://eu.mouser.com/ProductDetail/FTDI/FT2232H-MINI-MODULE/?qs=pB3G9VbQXIf%2bpWyngo5ZjA== You can get it from many vendors.The same exists for quad-channel FT4232H BTW, but I prefer the remaining pins as GPIO. It has proper protection circuitry on the USB port, which most other boards are lacking. I am using those in volume for industrial automation BTW.
  7. BTW, here is the official definition of drive strength, straight from the horse's mouth: https://www.xilinx.com/support/answers/38820.html "The drive strength of an I/O specifies how much current we can drive and sink while maintaining the minimum Voh and Vol levels." The bold part is the catch: it doesn't refer to the short circuit current.
  8. Hi, the outputs cannot be used as constant current source. Been there, done that, got the T-shirt and had to buy a new LED. If absolutely desperate, I'd use PWM: E.g. generate a 200 MHz clock and a counter that generates one pulse in 32 or so. With a short circuit current ~ 300 mA this should give no more than ~ 10 mA in average. But this is a hack in oh-so-many ways (among them: tune it to a radio station of your choice...)
  9. Hi, the very bright decimal points were indeed one "feature" of the resistor-less board. But best take a magnifying glass and look for the resistors, then you have peace of mind. I'd simply use a multimeter in diode mode on the headers to check the segments, or jumper wires to +3.3 V / GND (but don't do this without resistors or there will be 7-segment magic smoke).
  10. Hi, random guess: Is it possible that the UART pins are swapped? It seems unlikely, but undriven digital inputs can do this kind of crosscoupling voodoo.
  11. If it helps: there is no need for resistors. You can plug male-female jumper wires into the FPGA board on one side and a 15 pin VGA cable on the other (the diameter of the pin matches). I'm using this as a standard debug tool in 640x480 just HSYNC, VSYNC, GREEN (on/off) and GND. The voltage is slightly out-of-spec but the monitors I've tried with didn't object. I think you won't regret buying a scope. Another immensely useful and free tool is an "activity detector" where you trigger a counter using an unused input and put e.g. every 5th bit on a different LED. Then plug a wire into the input and probe as needed. You could try to fit a SUMP logic analyzer core into the design (disclaimer, never tried this myself. For me it works as advertised on a 2nd board). Edit and pay attention to your programming LED. It is possible that the FPGA resets for whatever reason (e.g. random short circuit on 3.3 V when you move the boards a certain way).
  12. Just wondering: Do you know the Microblaze debugger that comes with Web-edition Vivado? I've used the basic features (breakpoints, step, edit variables etc) on an Artix. It was surprisingly simple and usable without having read any manual.
  13. BTW if anybody is interested: I could dig up my 640x480 monochrome text adapter (40x20 char) that fits into a single 2kByte block ram. It's ugly as hell but excellent for debugging as one write port of DP ram can be used by the application at any clock without restrictions.
  14. Hi, did you check the voltage rating of the RAM? I think it's 5 V, won't work in a 3.3 V environment. The Papilio Duo might be able to do the job with its on-board SRAM, or Saanlima's Pepino.
  15. Stumbling over my old post, if someone is sent here by Google on a mission to reduce latency... The secret to achieving low latency with a UART is... don't use a UART. The 2232H chip, programmed through the DLL interface, can achieve physical roundtrip (!) times, e.g. send a byte via JTAG bypass through the FPGA and back in MPSSE mode, of slightly over 1/8 ms. If I extrapolate the 3.75 ms UART roundtrip time I achieved earlier... my boss wouldn't be happy :-)
  16. Hi, is it possible that the usb_cts and usb_rts nets in the pipistrello.ucf constraint file are mixed up? In my opinion, the following should be correct: #NET "usb_cts" LOC = "A9" | IOSTANDARD = LVTTL | DRIVE = 8 | SLEW = FAST ; // SWITCHED WITH RTS -mn #NET "usb_rts" LOC = "C10" | IOSTANDARD = LVTTL | PULLUP; // SWITCHED WITH CTS -mn Schematic: RTS# = pin 40 on U7 = D2 = C10 on FPGA CTS# = pin 41 on U7 = D3 = A9 on FPGA In my understanding (please correct if wrong) CTS serves double duty on the FTDI chip: - Setting 1'b1 (which mean "not clear to send") blocks incoming traffic from USB. - Any level change kicks off the current 62+2 byte package over USB without waiting for the latency timer. I did an experiment with existing code where triggering a pulse on CTS decreased the roundtrip time (for two "rounds") from 4.00 to 3.75 ms, a small but measurable improvement.
  17. just noticed this old post... It's "reasonably" easy to attach it via SPI, I've done it once, takes only four wires and it worked at fairly high clock speed ~50 MHz if I recall correctly. "Reasonably" in quotation marks if I need realtime, but that's Raspberry Pi territory.
  18. Just remembered something: If someone actually reads this >> there are ways to give the device name (which you can find out for example with FTDI's FT_PROG, free download) note that the FT2232H includes two independent devices (e.g. for JTAG and UART). The name of the device "A" or "B" needs to be appended to what is shown in FT_PROG. To make matters more confusing, it's automatically attached to the description with a space character in-between, but to the serial number without (if I remember correctly).
  19. Yes... that error message is a classic... If I didn't know any better I'd guess it came straight from Seattle Unplug everything from USB that might include an FTDI USB-to-serial converter. If in doubt, everything except keyboard / mouse. When this fixes the problem, there are ways to give the device name (which you can find out for example with FTDI's FT_PROG, free download) as an argument so the uploader knows which chip to talk to.
  20. It might be the easiest to write it yourself. From how I understand it (disclaimer - I never actually hacked it) it boils down to write a few bytes to a UART. See this link at "Long commands". At first glance the trigger section looks exactly like what's available in the GUI. As a personal comment: I've learned programming on Unix and often feel sorry for those folks who know only Microsoft GUI-driven madness. But, for FPGAs the additional burden from running Linux is too much for a hobbyist, IMHO. I'd pick my battles carefully... (and PS: In Windows C#, the minimal program to open a serial port, write some bytes, pick some output bytes will probably fit on one screen or two. It's extremely usable for this kind of job).
  21. Hi, >> Pity that development appears to have really slowed down, as it is really close to being brilliant. the disclaimer first, I'm using SUMP only with the Pipistrello board, where I have it in flash ROM. This keeps the Papilio board free for "higher risk" stuff :-) Anyway: If I had to do serious work with the logic analyzer, the first thing I'd do is hijack the interface code and then write a very simple command line back-end that sets trigger conditions, start an acquisition, then dumps everything to .vcd (the file format is trivial BTW) so that it can be analyzed in GTKwave later. My $0.02... So far I've been lucky to get the complex issues sorted out in simulation, the logic analyzer is more like a swiss army knife (which does save the day, occasionally).
  22. Have a look at the FTDI application note: It's actually quite readable. http://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf I think MPSSE is geared towards serial IO, with a pre-assigned CLK pin. BTW, after spending a working day on FTDI's JTAG sample code (and bulldozing over 95 % of lines, and it still works, oh yeah) I've come to the conclusion that JTAG and SPI are things I'd rather deal with in Verilog than in C. It seems a total no-brainer, but only from a safe distance...
  23. Hi, FTDI provides a JTAG library for use with their chips. I implemented a bitstream uploader on top of that (FPGA only, no flash). Uploading the Pipistrello (LX45) logic analyzer bitstream takes about one second. It's marginally slower than fpgaprog - mainly the library startup; transfer time according to the LED seems about the same. The project is attached. Note, this is meant as example code, not as a polished tool with command line options etc. One possible advantage is that the FTDI JTAG library is open-source but not encumbered by a GPL license so it can be linked into a commercial project. The .bit filename is hardcoded; and the IDCODE response of the FPGA needs to be changed or assertions will fail (here table 5-13). jtagLoader.zip
  24. Hi Captbill, check the MPSSE capabilities carefully. As far as I know, the "fast" commands are tied to a few pre-selected pins so you'll have to write and sample the whole 8-bit IO bank. That means, the "programming paradigm" for the FTDI chip is completely different from the regular MPSSE SPI/JTAG/etc libraries, where MPSSE commands operate largely on a single pin. The clock toggles at twice the data rate so you'd probably have to write D0[0..7] | CLK_low D0[0..7] | CLK_high D1[0..7] | CLK_low D1[0..7] | CLK_high D2[0..7] | CLK_low D2[0..7] | CLK_high ... Assuming the FTDI chip can't help you with handling the clock on an arbitrary pin, you might end up with 1/3 of the data rate of a "by-the-book" MPSSE implementation. The slightly-broken FTDI library posted above will run at clock divider 0, so I do achieve the maximum possible 1-bit data rate. As a word of advice: JTAG isn't rocket science but in implementation it is much harder than it looks due to its flexibility (try to read other peoples' code if you don't believe it). Most communication standards sacrifice some performance for simplicity (regular framing, layer stacks). This one is flat, and your USB "layer" adds complexity (e.g. max. size of a single FT_Write/FT_Read transaction, formatting the data for MPSSE, ..). When it comes to "imagining": As an artist, an FPGA inspires and provokes me like a blank sheet of paper because of its infinite potential. As an engineer, blank paper is a no-cost item hauled around with forklifts by the ton PS: Magnus' "FIFO" logic analyzer code might give some examples to 8-bit data handling.
  25. So you're trying to port this to an Altera FPGA? Of course, the easier way would be to make it work first on the original hardware. Then port it. If I had to debug this design, what I would do first check for valid HSYNC and VSYNC. Does the monitor recognize the frame timing? With valid sync signals applied, connecting any color signal e.g. VGA_greeen to 3.3 V should result in a bright (e.g. green) screen. When this works, we know the basic clocks are correct. DISCLAIMER: My monitor does not turn into a fireball when I do this but I don't know about yours. But as said, porting a design without reference on working hardware is an uphill battle. Besides simulating, maybe it's a good time to buy a Papilio Pro as a logic analyzer which might be part of the 2nd step I'd do.