Jump to content

xc6lx45

Members
  • Posts

    762
  • Joined

  • Last visited

Everything posted by xc6lx45

  1. Hi, most likely your scope and probe are the bottleneck. I remember doing the experiment once, and getting rise times around 3 ns from one of the direct outputs of a CMOD A7, after switching to an active probe on a "non-hobbyist" scope.
  2. I dimly recall the process ... it's been a while ago... yes I think you can do the two steps separately from the command line (first upload the bridge .bit file, then do flash operations). But when you get the readout of the flash ID bytes, that part seems to be working already (it can be also done in a single command). And, spartan 6 / 7 are very similar if not identical as far as xc3sprog is concerned.
  3. I haven't studied the code but I suspect you have to add the 0x16 size ID (e.g. from datasheet, see the format of other entries). Actually I'd check first that all the other bytes (after JEDEC) match the identity of the flash chip (see datasheet, search again for JEDEC). If yes, your programming bitstream is working correctly (and probably it does already now, but the specific device isn't supported yet).
  4. Yes, two steps. First it uploads the attached bitstream to the FPGA, then that is used to access the flash. I think it detects the flash by reading some vendor ID from standardized registers (there is no "scan chain", the flash is not on JTAG but SPI). And yes, the pins in question go to the flash memory. Note, the last two lines of the constraint file are important but I think they match the regular CMOD A7 constraints file (but please check).
  5. Hi, with xc3sprog I believe you'll have to compile the programming bitstream for your target device as it's not included. You may also need to make minimal changes to the executable e.g. add the vendor ID (if I remember correctly). The hard part is setting up the build process with CMAKE etc. Expect to spend a working day or two on this. The attached programming file did work with Artix on a Trenz module (not tried specifically with CMOD A7). You'll have to put in correct constraints for the chip in question and build with Vivado, then have xc3sprog load it as programmer bitstream. xc3sprog.zip
  6. HI, if you search the forum you may find a few similar requests. Apparently you are unaware that the FTDI/JTAG solution is licensed, please search the forum (I haven't heard of anyone using the FT4232H though). For plain bitstream upload you could adapt this project (the bitstream uploader is a small part of it, just delete the rest). Alternatively, there are other FTDI/JTAG solutions e.g. xc3sprog. But none of them will provide you deep integration wíth the Xilinx tools. The quickest way might be to break out the electrical JTAG interface, get a licensed module and integrate it with a hot glue gun...
  7. OT but yes I think that is generally the idea. Usually you scale devices down (start with a big one for faster build cycle, ILA etc). Then squeeze the design into the smallest device possible in volume production. If you scale up, it obviously puts more stress on DC / thermal design.
  8. Hi, for a DA converter hack, you could also have a look at the one I used here: There was quite a bit of discussion about reconstruction filtering . The shown measurements are taken using the on-board XADC, which acts as lowpass filter. I think the first two plot labels are wrong (plot 1, 2 show a sine wave. Plot 3, 4 show an 8-tone test signal) It's not sigma-delta but open-loop PWM with creative dithering. The idea is - I generate a PWM signal simply by comparing the output value MSBs against a periodic ramp (e.g. 4 bit) - for the lower bits, use pseudorandom numbers It modulates most of the quantization error up to higher frequencies, where it can be filtered by analog means. Sigma-Delta is more sophisticated (this one might be 8..10 bit equivalent for an audio signal). The main advantage of the PWM scheme is that it works rail-to-rail, where sigma-delta does not. Missing above: "outputBitReg <= myDacVal >= pwm; Note that it's feedforward-only so it should be clocked fairly high e.g. 250 MHz on Artix. The code allows also a 5-bit ramp but I got best results using 4 bits (if in doubt, experiment - depends on the lowpass).
  9. One question you should answer for yourself (after deciding on Xilinx, which is more or less implied by the nature of the forum) is whether you want to go for plain FPGA or Zynq with embedded ARM processor. Reading between the lines of your post, I suspect strongly that your vision will map better to a conventional CPU-centric architecture with some FPGA accelerators than 100 % RTL (or even worse, a softcore CPU added as an afterthought after you've hit the wall and start to do some simple math on HOW MUCH EXACTLY will it cost to have every line of your code mapped to LUTs that wait most of the time for that particular line of code to get executed). Now my Zynq advice is a double-edged sword - the edge facing your way is more of a bludgeon (complexity) but it hurts nonetheless. Somewhat less so if you hire Zynq developers from the start but doing that without serious hands-on experience... opens up a can of worms or maybe a barrel.
  10. BTW, now that Altera pops up (BTW, please read the above "Bill's University" post carefully), there are boards that seem quite specifically made for your requirements list, since you're probably not the first one to use an FPGA for trading. You might search around what they use in network research. From my own past, I remember Terasic DE-4 (by now a very old board) and it does have 4x onboard ethernet, PCI, DRAM, even ships with jumper cables to cascade several boards via high-speed serial. But as said, selecting hardware should be the least of your worries (possibly pick one ethernet chip early if you intend to do spin your own high-performance drivers and TCP/IP stack). Digilent will probably have something similar if you search a little.
  11. Hi, I don't know if this applies to you but there is a very common pitfall, that is first doing isolated, abstract hardware / platform research and then only learning FPGA development. I am not certain with this statement - maybe it will work out for you. But I see a very high risk that it will not, even for bright people ... it's a bit like "buy a guitar, learn to play, form a band, become a rock star". For the vast majority, this plan does not succeed, and especially those who get stuck on the "buy a guitar" part.
  12. Hi, I have written a bitstream uploader for 7 series FPGAs which is included here (run the demo with an CMOD A7-35 board and it will upload its own test bitstream at startup). But it's not a turnkey solution in general. .NET exists in the mac world, AFAIK, so you should be able to build it. But it'll probably require some modifications to link dynamically with the mac's equivalent of the FTDI DLL. The Xilinx protocol at JTAG level is described in UG470. There are a few other projects on the web e.g. xc3sprog or urjtag that may be more general, once you figure out how to use them. xc3sprog will require minor changes for 7 series e.g. IDCODE.
  13. well... if you need something that works, I think the mainstream solution is to buy a licensed module and drop it in on the PCB. Doesn't answer your question but wouldn't be the first time in FPGA land where things "should" be simple but are not. Besides the Digilent ones, you can also buy a different type from Trenz. I've used that one quite extensively but suspect that it is limited to 15 MHz operation by the speed of the CPLD device where a plain FTDI chip or the circuitry on e.g. CMOD A7 can manage 30 MHz.
  14. well, by default your signal is between 0 V and Vref. The opamp circuit has a gain of 2 (range 0.. 2 VRef) but subtracts a constant VRef (range now -VRef..Vref). It'll just shift the waveform on the scope, and double its AC magnitude.
  15. is this the absolute group delay or the delay uncertainty? The latter you can calibrate out. And I can interpolate mathematically between samples in a way that is indistinguishable from a faster converter, for a bandlimited signal. Absolute latency, yes, the sample rate sets an obvious limit, but read the converter datasheet carefully (internal processing latency). Now I'm guessing on what you're trying to achieve: note that sampling rate has nothing to do at all with time-of-arrival estimation error (theoretical limit: the so-called "Cramér-Rao" bound. It depends solely on the spectral shape and some signal-to-noise ratio).
  16. Just thinking aloud... 2 MSPS for a 10 kHz signal seems unusual. E.g. CD audio uses 0.044 MSPS for 15 kHz BW. Have you double-checked why e.g. a conventional audio codec would be insufficient?
  17. laughing out loud... Welcome to the wonderworld of 2018 test engineering. Exciting new bugs are waiting for YOU to be discovered - it's as simple as trying to use an instrument for its advertised purpose (sorry, couldn't resist...)
  18. >> remote data logging application, maybe running for months One RPI option is to drive an external ADC through SPI, if that's sufficient for the data acquisition job. I've used this approach in the past with an MBED LPC1768 as host, and this ADC module http://papilio.cc/index.php?n=Papilio.AnalogGroveWing. I'm sure similar PMOD modules can be found on this site.
  19. ... and FYI: xc3sprog can be modded trivially if you add the IDCODE for Artix and the JEDEC ID of the EEPROM (no guarantees on the latter, but worked for me once, with the above board).
  20. Hint: You can buy an officially licensed adapter module here: https://shop.trenz-electronic.de/de/TE0790-02-XMOD-FTDI-JTAG-Adapter-Xilinx-kompatibel The description is awfully German :-) but it's pretty straightforward together with a TE0725 board (which is BTW interesting in a sense that it's available up to Artix 100 size and EOL predicted ~2028) Caveats: Weak regulator (Clearly stated in the doc, but in my experience a Microblaze test design will run on USB bus power) Does not support 30 MHz signals, if you intend to do your own MPSSE JTAG programming. Clock divider 1 / 15 MHz works reliably.
×
×
  • Create New...