xc6lx45

Members
  • Content Count

    407
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by xc6lx45

  1. ... was just in the middle of rephrasing the above post somewhat more diplomatically. There are many good reasons to use FPGA, e.g. an FPGA engineer will probably earn a higher hourly rate than a Raspberry PI programmer so don't let me distract you πŸ™‚
  2. Hi, >> applying various algorithms if you don't know the algorithms yet, it might be easier to get the ADC data into a softcore CPU, then prototype in C using floating point. The point is, experimental prototyping of algorithms in fixed point RTL is a slow and painful process.whereas reloading a .elf binary takes a second. I'm guessing your intent but I suspect you'll find eventually that an FPGA is not the optimal platform choice for your application. Meaning, you can most likely get the same result cheaper and with less effort e.g. using a Raspberry PI + SPI converter. I'm guessing this simply because higher-rate ADCs where FPGA makes sense (hundreds of MHz) are hard to come by as OTS modules. Otherwise, if you design for, say, 1 MSPS, the FPGA fabric will do less than 1 % of the work it could do but you pay for 100 % so people usually don't use FPGA, if a CPU or DSP will do the job.
  3. The module uses an on-board-antenna, which is always a compromise. So yes, you have the option to connect a more suitable antenna. But this is an "amateur radio" topic, there is nothing "software defined" about it. Boosting the transmitter on one side of the link for a modern two-way protocol won't help much - beyond its own transmit range, the remote end may hear you but it cannot acknowledge reception. Hint: If interested, you can do quite serious software defined "radio" with audio and loudspeakers, e.g. OFDM. The basic challenges - synchronization, frequency error estimation and correction, channel frequency response, multipath reflections etc are pretty much the same if not more visible. And, a white noise spectrum will break most loudspeakers. Don't ask how I know πŸ™‚
  4. Hi, there's a lot of new information in your last post. You aren't just "trying" FPGA but have a professional interest in Zynq. Don't let anybody scare you it's "difficult" and go for it, possibly with the cheapest board, no tutorials and low expectations like, blinking LEDs for quite a while. Given the price tag of any industrial training coarse, an FPGA board for self-study is a no-brainer. Maybe save some money to buy your FPGA engineer a coffee once a week, with some questions in mind
  5. Hi, >> I would be really glad if someone helps ο»Ώ no one is going to do your course homework for you. But, I think you should talk with your supervisor. You've been thrown in at the deep end of the pool, which is OK only for someone who knows how to swim. Reading between the lines, you don't. Now if this is a follow-up to a VHDL course: Review the course material and lab exercises, it will probably give you some shortcuts. If one could teach simply by throwing people into the pool, there would be no need for schools... Otherwise, it looks (based on your post, of course), like a nasty amount of work without any focus e.g. connecting to "a" toy RC car feels like an exercise in tinkering, not engineering e.g. buy a $10 RC toy and hack the transmitter with an MTC61-ish optocoupler. To the FPGA, it looks like a LED. Do not assume it's easy (in a sense of "don't assume swimming is easy").
  6. True - the added noise breaks up "coherent" quantization error and spreads it evenly across the bandwidth (where I can usually filter away most of it digitally) Most analog designers will scratch their heads if given a minimum noise specification for the driver amp but hey, it's physics πŸ™‚
  7. but watch out, the resolution may be closer to 8 bit than the 16 bits mentioned in the original post. This is at least what I got with a GSM signal around 900 MHz (plus a frequency offset I had to correct by resampling, since the average scope does not have a reference clock input). Your mileage may vary. I had more luck the other way using an RF vector analyzer with IQ inputs as a very expensive oscilloscope but that's about 180 degrees out of phase with the topic πŸ™‚
  8. >> But it will cost me a bomb and I need to be sure I am investing on the correct thing. My entry for the "shortest answer" competition: Get a CMOD A7 or similar. It's dirt cheap - consider it disposable and save the idea of buying something "more capable" for long term motivation. Starting with an expensive board, then being afraid to use it for fear of breaking it does not help with learning. Zynq is significantly more complex than Artix and the FPGA part is less accessible.
  9. Before you spend money, sit down for an evening and read through forum posts. In a nutshell (see the earlier post for an example, the wideband-/narrowband configuration thing): Eval boards are not modules Sometimes it works but there is a high risk involved (such as, you place your order based on studying board revision X and get revision Y, which is completely different). If the FPGA is needed only as adapter, have a look at digitizer cards in PCI or PXI form factor.
  10. You might have a look at Trenz Electronics "Zynqberry". I think they managed to get one of the cameras to work (not sure). What I do remember is that the board has some custom resistor circuitry to additional pins for the required low-speed signaling.
  11. Just wondering, are you aware of Xilinx Webpack? It needs a license but you can just request it.
  12. Hi, since you asked for (FPGA) RAM, check out the "inferred memory" concept e.g. here: https://forums.xilinx.com/t5/Synthesis/UG901-distributed-vs-block-ram-inference/td-p/775730 if you open Vivado main window, then "Tools" menu, there is an option "Language templates". You may also find some useful material there (and some other that is very specialized). One advantage is that these examples are specific for FPGA, whereas generic VHDL instructions may be targeting ASICs or simulation, which are less restricted than FPGA.
  13. xc6lx45

    Power consumption

    what do you think? What does actually cause the power consumption in modern CMOS?
  14. Hi, >> I understand the if the pin is an output, then current should exit from it Most likely, your understanding of the output cell is wrong.The point is the "C" in CMOS, "complementary". Look at the first picture in the link - there are two (MOS) transistors, one to positive supply voltage and one to negative / GND. The pin can source and sink current. This is the magic behind almost all modern digital circuitry. And if anybody wonders what would happen if both switches would open at the same time. Magic smoke appears πŸ™‚
  15. Maybe you want to re-think Arduino, with a professional technical background. It may be that a Raspberry Pi with the "wiring" library is more useful long term. Just as a note, the guitar FX is a surprisingly challenging project, if it's supposed to be borderline useful. E.g. "aliasing" - you bend a note up and half of the little monkeys in your sound bend down at the same time. It gets tiring
  16. Then your bandwidth is 6 MHz, not 60 MHz (according to what's printed on the probe). Try to set it to x10 mode. The divider allows for a wider bandwidth.
  17. are you maybe using a low-speed analog output with 200 ohms series resistor? Check the schematic of the board for a direct output.
  18. xc6lx45

    Cmod S6 - Multilayer?

    You might go to Texas Instruments' site (or AD or both) and find documentation for some $500 high frequency ADC or DAC eval board as example to study.. There's nothing wrong with copper planes, generally. Free-standing structures (such as non-connected filler polygons) can be bad, if they resonate. So are loops if the driving wire spans an area together with the GND return wire (for which the ground plane is an obvious solution). The worst resonators have high quality factor meaning loose coupling meaning it can be surprising how the energy managed to couple in. There's no such thing as too many ground vias... Note, your ground plane can do very interesting things in combination with the metal box it's in (resonant cavity) but that's a different story.
  19. laughing out loud ... Formula-1-performance is niche business, combine harvesters bring home the money, walking barefoot is the norm. And why not, I'm even discouraging people to touch it as long as a UART does the job. Same as with fast cars, speed is largely overrated. Those who know otherwise, you know who you are πŸ™‚
  20. >> Is there a strategy that targets the re-use of logic? this is a slightly different question, but can help the tools with timing: Sometimes I need to replicate logic that starts with an input register on the same data for all instances (e.g. multiple blocks using identical high-frequency counters as internal timebase). The tools will recognize them as logically equivalent and try to use one shared register. This is bad, when the downstream logic is timing-critical. In this case, I can manually flag the register as "DONT'T TOUCH" so the replicas are preserved and placed closer to the critical logic. Optimization would eventually reach the same conclusion after thinking long and hard. There is a "-keep-equivalent-registers" option that makes this the default. The "rebalancing" option is under Synthesis options "-retiming".
  21. 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).
  22. Hi, it may help to close timing. But most likely it's a dead end, for several reasons: P&R is at the end of the design process. It fails here but the root cause lies somewhere else most likely (blind guess, assuming from the nature of the question that you're not a power user), the problem lies in the constraints. Specifically, a missing "false_path" to timing-uncritical IOs like switches or LEDs. This can be a timing killer, because it leads to an impossible job for the tool. inserting pipeline registers will most likely fix it. In most cases (no closed loops, no rigid latency constraints) it's fairly easy to insert single-cycle delays across a "cut plane" through the design, leaving the functionality unchanged. Regardless of the strategy, check that "register rebalancing" option is enabled even if you manage to close timing once by tool options, the design will be difficult to work with, long P&R times and no guarantee of success. When squeezing a commercial, large volume design into the smallest possible device this may be worth the trouble, but not during R&D unless the design is "pushing the envelope".
  23. Hi, I suspect you're using slow default options for bitstream generation. Increase the clock rate and enable bitstream compression. It should be much faster.
  24. BTW, if you use a 1 MSPS ADC for 10 kHz bandwidth, you may gain the two bits from oversampling gain. E.g. accumulate 64 samples and use sum[21:6]. It causes some deviation in the frequency response "sin(x)/x", if in doubt use less averaging than theoretically possible. Just be aware that the smooth early learning curve is designed carefully into some technologies e.g. Labview. FPGA in general is not one of them... No free lunch here. I'm still hoping someone will say it's possible with AD2.