Jump to content

Skylär Astaröt

Members
  • Posts

    7
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Skylär Astaröt reacted to zygot in Dev Board with Artix UltraScale+   
    In terms of maximum data bandwidth either LPC or HPC FMC beats SYZYGY by virtue of the availability of transceivers and shear number of IO available on the FMC connector. Both FMC and SYZYGY have a limited number of mezzanine cards or pods available. SYZYGY pods are generally cheaper, but are smaller. SYZYGY does provide for a transceiver pod type, but unlike FMC it's a separate pod from the standard pod. The Opal Kelly transceiver pods are geared toward the lower data rates of Artix devices.

    I've not used the USB104 A7 platform, but it is an interesting non-ZYNQ possibility. Not a lot has been posted about this platform however. I would imagine that this platform could provide most of what you want in terms of PC connectivity and interfaces.. particularly if yo are prepared to design your own custom add-on card. Cost wise it appears to be a reasonable platform for anyone starting out in FPGA development. The fact is that any Series 7 or UltraScale platform lets you explore using the FPGA DSP functionality in any level of detail, from "simple" macro instantiation to the most abstract HDL usage.. if that's your main interest as your post suggests. One SYZYGY port is pretty limiting if you want to add interfaces like ADC/DAC etc. As far as I know there are no pods with both ADC and DAC functionality.

    Opal Kelly uses a proprietary PC interface for configuration and PC connectivity ( not Digilent's go-to FTDI USB 2,.0 solution ) . This makes it incompatible with the ADEPT API. Their boards do usually include a JTAG header compatible with the ADEPT Windows Utility and Digilent JTAG cables but you will likely have to add a specific device ID code to the utility in order for it to recognize a device. This is a way to get around using Front Panel for both configuration and using VIO or ILA debugging, and I have done that when not needing the USB connectivity. Front Panel isn't integrated into Vivado Hardware Manager, so debugging isn't seamless. I've used the XEM7320 with the Digilent Zmods and found it to be quite superior to the Eclypse-A7 for the kinds of projects that I tend to do. The USB 3.0 interface is very nice. The Nexys Video and Genesys2 both deserve the higher bandwidth of USB 3.0. There is a lot to dislike about Opal Kelly's closed approach to products ( such as no schematics ) but they do integrate great PC connectivity via USB 3.0 to a variety of software frameworks which is, I suppose, their customer draw. It's certainly nice to be able to write a single PC executable in C that does both configuration and data transfers. But there aren't a lot of options as Opal Kelly only supplies encrypted netlists of the required components for doing that.

    Intel FPGA programmable devices also have DSP functionality ( perhaps superior to the Xilinx ones ) and a pretty rich HSMC ecosystem. It is worth the time to explore as an alternative. Personally, I prefer the AMD/Xilinx world but frequently find myself using Intel world hardware and tools when they are a better fit for my purposes. Unfortunately, Intel has taken programmable logic toward a higher cost path in deference to low budget applications. The free tools are pretty much limited to Cyclone V and earlier. Cyclone 10 LP is pretty pointless but also supported.. to a limited extent by the free tools. Intel has always been committed to wrangling the most money out of customers as possible, even to the extent of losing customers.

    If this is your first venture into FPGA development I'd advise against giving in to the urge of trying to find a cheap platform that will support your interests for years to come. This almost never works out. Better to start off as cheap as possible and then decide on specific project goals and buy the best platform that fits the goals.
  2. Like
    Skylär Astaröt reacted to zygot in Dev Board with Artix UltraScale+   
    Well, that's the trick, isn't it; identifying the platform and tools that support the requirements of a particular project goal. One problem with being dependent on a MATLAB design flow is that you are dependent on their support for any platform that you choose. ( MATLAB/FPGA tool integration may well have improved since the days when I used it. )
    If I were you I'd avoid restricting my platform choice criteria to one FPGA vendor. Intel has been in the MATLAB design game longer than Xilinx and better support for OpenCL and such adventures. They also have the devices, if you have a thick wallet, and platforms that are similar to the Versal family. Intel wants to squeeze more money from its customers than Xilinx has traditionally, but in the end the investment in cost and effort probably isn't all that different than for a Xilinx based effort if you are targeting high-end FPGA devices and platforms. You aren't going to avoid paying for tools with a Versal project either. There's a lot of homework to do, and it's likely more complicated for someone used to the convenience of using MATLAB for FPGA development. Simplicity and convenience cost a lot of money... and often end up not getting you across the finish line due to limitations of what can be supported by such a framework.
    If someone has a limited budget then they probably will have to scale their project goals to fit what is affordable. This is, of course, adds complications, and diminishes convenience and simplicity. It's always  possible to implement enough of a concept to demonstrate ( not prove ) that you have a path to a larger goal.
    For someone who wants to get on with developing an idea without having to get mired in the details, I'd advise sticking with known platforms supported by MATLAB and used by other researchers in a particular field. This isn't likely to be the place to get such information, though perhaps you'll get lucky.
  3. Like
    Skylär Astaröt reacted to asmi in Dev Board with Artix UltraScale+   
    Right now there is only one devboard available, from Opal Kelly with AU25P device. I've sent them enquiry about acquiring some 10/15U devices to build a devboard for our internal evaluation, we'll see what they say, but I suspect with the semiconductor shortages it won't be easy, though if I would be them, I'd reserve a chunk of the first batch specifically for samples to get them out to the field to secure future volume orders.
  4. Like
    Skylär Astaröt reacted to zygot in Dev Board with Artix UltraScale+   
    DSP48E isn't a complete specifier as there have been a lot of variations among the various families over the years that have seen significant changes to the operation and performance of the hard core. But, if absolute maximum performance isn't a criteria and you have a netlist for the device you are targeting you are correct.
  5. Like
    Skylär Astaröt got a reaction from BMiller in Dev Board with Artix UltraScale+   
    Thank you very much for your information Zygot, but given my interest, as long as the DSP48E works and the NetList is available, I can work without problems with MATLAB DSP HDL Toolbox, HDL Coder and HDL Verifier. I don't want interference, I don't need complications, just versatility and simplicity, to work as fast as possible.
    The Versal Premium board is much better for me because it has everything I need to implement my projects in different ways, but I don't think I'm in a position to mortgage my apartment to get the Xilinx VPK120 Evaluation Kit.
    I need something simple and fast, so that later I can scale up and have some luck to get into some technology project incubator, so for the moment I'm on my own.
  6. Like
    Skylär Astaröt reacted to zimbot in ADP3450 for Audio Analysis   
    Just thinking this through...
    Starting with 100MHz sample rate (but only about ~30MHz bandwidth) measurements and 14bits, down-sampling to 768kHz is a factor of about 130 (close to 128) which would allow you to increase the effective bit depth by a little more than 7 additional bits.  So that gets you up to between 21 and 22 bits, not 24 bits.  This would work better if there is a little high-frequency noise in your starting signal, at a magnitude of about 1/2 a bit (kind of like dither).  The result *might* be good enough, depending on your needs.  Or, to get to full 24 bits, that would be a decimation factor of 10, and 2^10 = 1024, which pulls it down to just over the standard 96kHz sample rate.  Other, off-the-shelf audio interfaces can do that with a lot less trouble (but whether any provides calibration quality at an affordable price is another question, which I cannot answer).
×
×
  • Create New...