• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by offroad

  1. BTW, here is the official definition of drive strength, straight from the horse's mouth: "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.
  2. 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...)
  3. 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).
  4. 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.
  5. 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).
  6. 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.
  7. 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.
  8. 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.
  9. 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 :-)
  10. 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.
  11. 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.
  12. 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).
  13. 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.
  14. 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).
  15. 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).
  16. Have a look at the FTDI application note: It's actually quite readable. 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...
  17. 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).
  18. 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.
  19. 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.
  20. follow-up: my example bitstream uploader actually re-started the bitstream from the flash. This was seriously broken. I've got it working but don't have time to turn it into a standalone example. If anybody needs this, please send me a PM. BTW, through the JTAG USER1 register I'm getting a sustained data rate > 6MBit/s (using FTDI CLK divider 1), almost 8k independent write transactions per second or 4k independent write-read transactions. For comparison, a USB virtual COM port (UART) usually manages 1 MBaud (~900 kBit/s) and 1k transactions/second. A parallel FTDI-FPGA interface (Pipistrello) should still be faster, but the feature is rare on off-the-shelf boards.
  21. You could also order it from a distributor. For example, here it is on stock: edit: But then, is there any reason you need those smaller boards: The Papilio Pro is only marginally more expensive, they have it on stock here: There are more distributors. If you search a little, you might find one closer to you.
  22. And vivado doesn't even support Spartan 6 AFAIK.
  23. Hi, you can download it here:
  24. An additional bugfix to FTDI's FTCJTAG library: The final data bit in JTAG_WriteRead appears to be broken. The attached library source should fix it. BTW, if anybody wonders what this is all about: With up to 30 MHz clock rate, we should be able to get data to and from the board much faster than with the usual UARTs, also with sub-ms latency. All that using the JTAG "channel" of the FTDI chip (which is usually idle after configuration), leaving the UART "channel" free for other stuff.
  25. In BYPASS mode I'm measuring a roundtrip time of ~0.15 ms (the code below needs ~1.5 s). Not too bad... printf("Start\n"); int ix; for (ix = 0; ix < 10000; ++ix){ // === bypass test === WriteDataBuffer[0] = 31; // bypass ftStatus = JTAG_Write(ftHandle, true, 6, &WriteDataBuffer, 1, RUN_TEST_IDLE_STATE); assert(ftStatus == FTC_SUCCESS); WriteDataBuffer[0] = ix&0x7F; // write any number 0..127 ftStatus = JTAG_WriteRead(ftHandle, false, 8, &WriteDataBuffer, 1, &ReadDataBuffer, &dwNumBytesReturned, RUN_TEST_IDLE_STATE); assert(ftStatus == FTC_SUCCESS); if (ReadDataBuffer[0] != (ix & 0x7F) << 1) // check that output is shifted by 1 printf("Error\n"); } printf("Stop\n");