• Content Count

  • Joined

  • Last visited

  • Days Won


xc6lx45 last won the day on March 14

xc6lx45 had the most liked content!

About xc6lx45

  • Rank
    Prolific Poster

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
  • Interests
    RF / DSP / algorithms / systems / implementation / characterization / high-speed PA test and creative abuse of Pedal Steel Guitars

Recent Profile Visitors

3221 profile views
  1. Hi, >> but I feel like lost in documents Welcome to FPGAs. This is pretty much the name of the game (but it also makes the struggle worthwhile - if it were easy, everybody would do it šŸ™‚ ). As a general direction, a solid (basic) tutorial is good but don't expect to be led by the hand all the way. The constant version changes make this quite difficult (good news: it means there is technological progress ... well at least in theory but the guys from the marketing department said so and they'll surely know ...). More specific directions: Have a look at Microblaze MCS. It's fairly simple - set up the most basic system with some BRAM (=memory "internal" to the FPGA fabric) and one UART. Once you've got that printing "Hello World" - which is mostly a question of baud rates and not mixing Tx/Rx pins, you can add features one by one and the sky is the limit. Well, at least until the little girl next door pulls out her Raspberry Pi, running four cores at 10x the clock frequency - don't complain no one told you: by absolute standards, the performance of any softcore CPU is pathetic, compared to a regular ASIC CPU on the same technology node. So eventually you'll have to move into FPGA territory, or it makes little sense except as a learning exercise.
  2. BTW a reliable decoding / recoding UART repeater is conceptually harder than you'd think: UART has a fairly high (percent range) tolerance for timing mismatch. If your source clock is slightly fast and data is uninterrupted, the repeater will eventually be forced to drop bytes.
  3. Hi, as a simple (oversimplified?) answer, designing for higher clock speed requires higher effort (possibly "much" higher effort), and the resulting optimizations make the code harder to work with. Using the clocking wizard to generate a 500 MHz PLL is easy (try it). But writing logic at those frequencies is a different story (e.g. try to implement a conventional counter that divides down to 1 Hz. Why do all those XYX_CARRY signals show up in the timing report already at synthesis?). You also need to distinguish between what is feasible in plain logic fabric, and what can be done with dedicated "hard-macro" IP blocks such as SERDES.
  4. well, don't bother with PXI. It's industrial stuff but cost is 10x off. Check for something that works with minor adjustments. The amateur radio folks are really good at coming up with low-cost solutions, but often there's a crazy amount of work and high level of expertise that goes into it. >> Iā€™m not a programmer Stay away from FPGA šŸ™‚ At least, do your homework before you start buying gear that "should'" do the right thing.
  5. Hi, >> Want use Digilent modules for A plug and play SDR. you can probably find an ADC board that meets your specs but that leaves you with unsolved problems a) SDR b) plug-and-play and c) radio issues that are beyond software, e.g. interferers as below. From between the lines I read that you're not majoring in radio / communications engineering, and probably are not inclined to learn it all the hard way on your "plug-and-play" project... A more practical approach might be to find a similar application and check, what equipment they use. Do you have any clue about the interferers that will be present? 1/2 f, 1/3 f, combinations of a*f1 + b*f2 = f ? Strong blockers in your band of interest? The sensitivity will most likely be useless unless you have solved all the problems in this chapter. If I had to whip up something quickly (but not for pennies), I'd start with PXI cards, some minicircuits LNA, most likely some external filter. The "plug-and-play" SDR continues then from the IQ data.
  6. I can only speak for myself but I'm wondering whether openly asking other people to do your homework problem is accepted use of this forum.
  7. OK I think there's quite a bit lost in translation. Yes, PLL (/MMCM) are the conventional way to go, via the clocking wizard.
  8. is this a homework problem?
  9. I suspect the AD2 with 100 MHz converters won't be much help but actually this nanovna you mentioned looks cool. Thanks for the link, I think I'll get one for my lab coat pocket (note, this one is designed as VNA and does have a RF frontend with synthesizers and mixers). There's quite a few experiments e.g. antenna matching where ballpark-level readings are fully adequate. For example, you can make a fairly decent GHz-ish antenna just by stripping the outer conductor from a coax cable for an inch, then cut down incrementally until the S11 minimum is at target frequency. Make two of them and I can show the inverse square law (-6 dB for doubling the distance in the far field), multipath fading (repeat same over a metal surface), polarisation (turn one antenna 90 degrees). This can be a real eye-opener for those who know RF only from equations, and a $60 VNA will easily pay back for itself in the next job interview.
  10. well... a 2.4 GHz VNA without RF frontend is not going to happen in 2020. Probably not in 2030, too. Even if we could afford ADCs and DACs at such rates to slap together, it would still make a pitiful VNA because real-world instrumentation is designed around the narrow-band nature of the signal path. It simply makes no sense to pay for components capable at sampling 2 GHz worth of spectrum, then discard 1.9999 GHz (assuming a 100 kHz IF filter). Oversampling can buy resolution but the exponents are not in your favor - in reality it's the difference between a GSM mobile phone you have to charge once a month and military SIGINT gear that ships with power supply on a separate trailer.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. Very quick answer: If you want to learn FPGA, pick some entry level board and stop looking for shiny bits you could buy. That's the level ground before the learning curve even starts, don't waste any time there. If you're disciplined, a few LEDs and switches will keep you busy for months or even years. Just asking, have you considered Verilog? And BTW, "PIC" sounds like microcontroller, not FPGA.