zygot

Members
  • Content Count

    1533
  • Joined

  • Last visited

  • Days Won

    71

zygot last won the day on September 16

zygot had the most liked content!

10 Followers

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

8595 profile views
  1. @[email protected], I just got an email from a well known high end FPGA board vendor claiming 200 Gbps Digital IO. Yes this is far fetched but I had to know why a respected vendor would make such a claim. The answer turns out to be OCuLink. No, I was unaware that this is a thing but a google search returns plenty of hits. Some variants of the RfSoC have multiple lanes of transceivers that run at 25 Gbps. Connect 8 of these transceivers to an interface and you have 200 Gbps of something. Calling that something digital IO is beyond misleading. PCIe transceivers aren't like Select IO pins. My PCs have spare 4 lane Gen 3 (8 Gbps) slots. What do you think my chances of using one for GPIO are? BTW, finding OCuLink hits for things that you can connect to your 200 Gbps FPGA board interface is a different proposition. Beware of marketing claims. They can take a kernel of truth and turn it into a fantastical claim... unless you understand the context. The FPGA vendor claims that it can use this interface to connect two boards with a very high speed interface. Now that's believable but practical sustained data rates would likely be no where near 25 GB/s. [edit] It's curious that these beasts have such limited PL logic clocking support given the capability of the PS hard logic and the transceivers.
  2. @xc6lx45, Spoiler Alert! This is one of those ZYNQ beasts with onboard ADC and DAC converters. The issue is essentially a lack of documentation and transparency on the part of Xilinx on how their devices work. My earlier posts to this thread shows that I didn't get it at first either.
  3. Looking at the static levels of digital signals is analogous to looking at a picture of the front of an elephant and trying to peek around to see its rear. You can't because a picture is just a 2D representation of a 3D object. Trying to look at the static state of a signal is similar. You need to have another dimension which is time. For something like SERDES where there are multiple transitions per clock just make things more complicated. I'm glad that you got to your initial goal. I'm hoping that you don't stop there but can take more steps.
  4. That's not how TMDS termination works. Read the material that I've suggested. Do not try and connect custom hardware or wires to your board unless you understand supported IOSTANDARD specifications and terminations for your device and bank Vccio. TMDS_33 termination resistors are external. The FPGA IO PULL_UP and PULL_DOWN are not suitable. Again, you need to do your homework before starting any experimentation. You are not likely to find what you are looking for using Xilinx IP. and the board design flow. You will have better fortunes if you learn Verilog or VHDL. The Digilent staff are keen on the board design approach perhaps you will be lucky and one of them will have some suggestions. But really, the appropriate thing to do here is write your own HDL to experiment with IOSERDES.
  5. Do you mean that your design constraints uses the 1.2V LVCMOS_12 IOSTANDARD for your outputs? I hope that you aren't using external pull-up resistors to 3.3V on your outputs. Did you intend to say that your constraints selected internal pullups to Vccio? Did you make sure that you properly set the Vccio bank voltage for your FMC IO to 1.2V using the pins described in the Nexys Video Manual?
  6. If you are using TMDS33 then you MUST have 50 ohm termination. See the Series7 Select IO user guide. I'm not sure what exactly you are trying to do here but you'd be far better off using an HDL rather than the board design flow. Trying to use really slow clocks out of an MMCM and switch inputs for output data and LEDs for input data is not a very effective way to explore this.
  7. If this is your first FPGA project you jumped into the deep end of the pool. The UltraScale devices are a lot more complicated than the normal devices used in products normally discussed in the Digilent Forum and the key information tends to be a lot more difficult to tease out. The first thing that you want to do is try to at least build the demo projects that come with your development kit. You might not be able to run them due to odd requirements. This is what I ran into with the ZCU106 TRD. But, with a bit modification of the tcl I did manage to build the demo.
  8. I did manage to bump into pg269-rf-data-converter.pdf. While not as expansive as I'd want it does shed some light on how the DDC and DUC work using the hardware NCO and mixer components. I suspect that for now at least you are stuck with using Xilinx IP if you want to use the converters. You might want to read this IP user guide. [edit] I believe that you need to use Xilinx IP but be aware that you have to use specific hardware paths between your baseband logic and the converters. The normal DDC and DUC IP for other devices that I'm familiar with aren't appropriate. Have you tried getting help on the Xilinx User Community website? It's a real pain to use and often not helpful for specific issues but Digilent neither sells nor supports products based on your device and most users of the Digilent Forums have no experience with it.
  9. I totally agree with the second sentence if it stood by itself but in the context of this thread and the with the preceding sentence I'm intrigued. Please elaborate.
  10. I hadn't realized that Xilinx started delivering evaluation boards for its RFSOC devices. I did try and get available datasheets for your device and I think that I understand the nature of your confusion now. If Xilinx has published the information relevant to your questions then I wasn't able to find it. Fmax for the the PL global clock buffer is 775 MHz. This is also the maximum MMCM output clock rate. For comparison Fmax for the global clock buffer is 710 MHz for the Kintex on my Genesys2 and the maximum MMCM output is 933 MHz. This would suggest an upper baseband clock rate. The PLL is a bit more interesting. The datasheet lists PL_Foutmax as 667-775 MHz for the clkouts but also 2133-2667 for clkoutphy. I haven't been able to find published information about the devices PL resources yet. My guess is that the clkoutphy is used to drive the DDC and DUC elements, which I'm guessing are hardware based. I ca only offer conjecture about how the converters connect to baseband signals because I don't have the pertinent information. I would hope that customers who've purchased kits would have access to this information.
  11. Well... that does make a difference. To feed the DDR controller that I mentioned earlier I used a 1024-bit data bus to work with the controller low speed clock rate. The width conversion was done by the BRAM in an asymmetric FIFO. I would expect problems trying to do it in logic. II certainly wouldn't want to try this using multiple instances of the Xilinx DDS IP. I might be wrong but I suspect that Vivado HLS is not a viable way to go, but I have no experience with Xilinx support for the RFSOC devices.
  12. I'm not sure what you are looking at or what "suggests support for" means. I'm pretty sure that you can't afford to buy any high end FPGA devices. There have been companies that have implemented very high speed FPGA architectures using exotic materials supporting GHz level logic clocking but I'm not sure that any have survived. If they have then they have a very small customer base with lots of money to spend. Here's an alternate quickie analysis. I recently posted about a project that I did in fact implement in an Artix XEM7320 to capture 4 channels of 100 MHz ADC samples into 4 128 M sample buffers. The DDR memory is 32 bit wide and runs at 400 MHz. That's 64 bits of data per clock or an aggregate of 25.6 Gbps peak data rate. Let's say that you have 16-bit sine and cosine data samples for a 32-bit sample word. That works out to less than 1 G sample/s. This is done with the help of the Xilinx MIG external memory IP and carefully laid out PCB traces using IO banks specifically supporting DDR memory. Perhaps you can find an expensive board with a Virtex part supporting DDR 1600 speeds. You still aren't close to the 83.2 Gbps aggregate data rate you need. Then there's the problem of supporting the interface of whatever you expect to connect your DDS data to as well as finding the IO to do it. At a minimum you are talking about a custom FPGA board.. Lastly you have to figure out how to create and mux all of those DDS cores to fabricate one useful signal. Many years ago I worked on a similar project. We used the AD9957 which makes the whole problem much simpler. All you have to do is feed it I/Q data and it does the up conversion. That device support 1 GHz signals.
  13. Now, that is a picture of an impressive feat. I suspect that even the top guns on board presented a special salute to the captain of that plane and the deck crew. I guess that you don't have pictures of the thing taking off...
  14. I'm not criticizing your mentor. My suspicion is that you misunderstood his intended point. I don't know the context. I do not believe that your interpretation, as stated by "pick a clock rate' , is a good general way to approach logic design. I am not trying to nit-pick particular suggestions that you've made; in another context they might make for an interesting discussion. Not only is Jean confused but he is aware of that. The solution to confusion is replacing ignorance with knowledge. I don't think that you are helping him in this regard. I will nit-pick this line however; "Theoretically, if you could bring a 2.6 GHz signal into an FPGA (you'd need to sample at 5.2GHz or more), you could process 32 samples at a time and so handle the issue. " It is not a good idea to ignore device specifications to try and achieve a result that the tools can't support. Yes, I know that you can manually place logic into specific LUTs and create a ring counter that has signals that toggle well above the device specifications for guaranteed operation. This is a totally different topic worthy of its own discussion and will not help Jean at all. From all appearances this is someone who knows nothing about FPGA devices and tools and little more than the existence of certain IP that for some reason he believes will allow him to achieve an impossible result. I don't think that asking someone who presents solutions that appear to be well outside of normal practice to back it up with code is being critical. All you have to do is demonstrate that the general concept is viable. If you haven't actually been successful at implementing a concept in hardware that is robust and repeatable then perhaps you shouldn't mention it in this setting.
  15. @[email protected] Ignore the attribution of the above statements from the Digilent hosting software. Really man, I think that you are not helping the person that you are posting to. When you haven't actually done something it's easy to spout nonsensical solutions. And I know that you haven't generated multiple parallel sin/cosine waveforms and wrapped them up into a 2.6 GHz word/s package on any device. BTW if you think that you are going to serialize even 12-bit sine/cosign data at 2.6 GHz Fs you are in for disappointment. But go ahead, post your code for this so that we can all be amazed and in awe of your skills. Talking about doing something and doing something are two different enterprise. Sound concepts don't always extrapolate to mystical proportions. I think that your mentor set you on an unfortunate path if what you describe is how you think about logic design. Anyway, I'm happy to leave you to each other.