zygot

It's a shame about the lack of LVDS capability or usability on Digilent's FPGA boards. If you need balanced connectivity to an external board you can usually design a simple PMOD compatible interface board using discrete parts. This might be preferable as you have a wider selection of differential logic types to choose from. Some receivers have internal termination which is ideal when it should be as close to the receiver inputs as possible. It's a shame that PMODs only support 8 IO pins with no guarantee that any of the will be clock capable FPGA pins. Furthermore, even if you want to use a high speed PMOD that has reasonably length matched pair pins, it's unlikely that matching of all pairs will be very good. Modifying your board's power supply isn't recommended as GPIO connectors likely have their pins tied to IO banks which also have peripheral interfaces that need 3.3V tied to it, and you might not want to lose functionality. Of course you can check the schematic to see what's connected to an IO bank. Digilent's schematics of course have blank pages. The best option is to find a board that supports LVDS connectivity, as you need to implement it, by design. The low end Xilinx FPGA device don't have HP IO banks or internal termination options.

Sampling rate isn't specifically an FPGA issue. Having external clock inputs and outputs isn't just about clock synchronization. Imagine that you a system with one of the components an FPGA based board with ADC and DAC capability. There are a number of reasons why you might need coherent system wide sampling. If your ADC is converting a signal generated by a system DAC you might have phasing requirements. An external clock input allows your FPGA platform to have an Fs that is more accurate or steady over time or environmental fluctuations than what the board vendor can provide for a reasonable cost. Sytem Fs might not be constant over the measurement interval. Fs might not originate on one FPGA board. You might not have only one FPGA based board with converters in a system. Clocking is the very basic place where systems engineering starts. As a purely educational platform not having external clocking access might be fine, for a limited set of purposes. As a working platform this might be a huge problem. A couple of SMA connectors certainly isn't a prohibitive additive cost for something that the Eclypse-Z7 aspires to be. Not all customers of low cost FPGA platforms have simple educational projects in mind. The Eclypse-Z7 is Digilent's foray into SYZYGY compatibility. SYZYGY is a standard that let's Xilinx customers use the Series 7 IO to all of its capabilities with relatively low cost and high performance headers. Customers can use pods available in the market place or create their own custom pods within a tight budget ( not that these connectors are trivial to lay out using free PCB tools or for low layer count board design ). Digilent is free to pursue whatever market strategy they choose to. FPGA board users are a diverse group and just want to be able to use FPGA device features to accomplish a task. I don't speak for Digilent or any other vendor. I speak on behalf of their customers and users. As a user I don't want to buy a platform that is designed to limit its usefulness, especially when there isn't a cost or technical justification for doing so.

I would certainly encourage you to start with the datasheets and MicroChip documentation to see what you are getting into before making a selection. The SPI interface is indeed the limiting factor in data throughput. But the devices have other interface modes... if the board design takes advantage of it. You can find the information that you need at MicroChip. There's no software programmable capability in these devices. If you need basic Ethernet connectivity and can write a driver these might be something to consider, as long as you understand what you are getting into and don't care about throughput or latency.

I don't think that you should have to apologize for not being able to figure out what speed grade the particular part is on your board... it should be more obvious. Especially since this information is required to create a design for the board. The (partial) answer to your question lies in Figure 6-4 on ug475_7Series_Pkg_Pinout.pdf available in the Xilinx Documentation Navigator installed with Vivado. The top number is the Device Type: XC7A35T The second row are the Package/Data code: CPG236 though frankly, I'm not sure how to separate the Date Code and Package The 3rd row is the Lot Code and below that is a line with the Speed Grade and Operating Temperature Code. Likely, this is a 1C for the slowest speed grade and Commercial temperature operating range. If that information is missing then it raises suspicions about whether the part is legitimate. Vendors charge a premium for faster speed graded parts and these are unlikely to found on inexpensive products. Ideally, this information is provided in the master constraints file. I believe that Digilent does provide all of the necessary part information in its vivado-boards-master repository that you can point Vivado to when picking a board instead of a part. Of course there's the matter of identifying your board version and the Digilent keeping its repositories up to date with product runs. I'm sure that the past months have been very difficult for board vendors finding parts to do a run and it is conceivable, not if unlikely, that a different FPGA speed grade than 1 is on your board. But sometimes you take what you can get if you want to manufacture product. Hopefully no one is buying parts on the black or grey markets, but customers have no control over where distributors get product from. Chip vendors have a big incentive to protect the 'chain of custody' for their devices as it flows down board product vendors through various intermediaries. I can't think of a valid reason for anyone removing any of the package markings except for shady interlopers. If in doubt you can always select the lowest speed grade for FPGA tools as there's no lesser option. Few people want to pay for the higher speed grade unless they have a particular requirement to do so.

When I look at the Digilent store I see only one ZMOD ADC 1410 offering, hence the confusion.

Well, what sample rates do you want? There is no set of available sample rates for the ADC and DAC devices on these SYZYGY compatible pods. However the pods include more than just a converter. There's also analog circuitry included which make them good general purpose add-on boards. This also implies that the analog support circuitry is optimized to work near the limits of the converter upper sampling range. This doesn't mean that you have to use the maximum Fs for the pods, but you have to understand the consequences for choosing an arbitrary Fs. Digilent has provided very good documentation about the designs of both. The converter vendors also supply a datasheet and good applications information. If you do ADC sampling at say, 100 MHz, that doesn't mean that your system has to work with 100 MHz samples. You can process those 100 MHz samples to achieve an almost arbitrary sample rate using decimation and interpolation. The Eclypse-Z7 has a number of design flaws as a mixed signal FPGA platform. The most glaring is the lack of external clock inputs and outputs limiting its usefulness. This isn't because of any deficiency in the SYZYGY specification, though the standard pod sizes don't leave a lot of room for extra connectors. Still, allowing for an external synchronization clock on the pods might have been an option. This doesn't mean that there aren't good uses for the Eclypse-Z7 or ZMODS. I view these boards as suitable for developers with advanced skills in HDLs, AXI busses, and perhaps Linux development. At the minimum anyone considering using them should be able to understand the requirements of the projects they intend to develop for them and be able to complete the HDL and software components from scratch. That's just my opinion, based on experience with them.

JTAG is a boundary scan standard use for a lot of purposes. It has a hardware layer used by a lot of companies for a myriad of purposes, including programming internal device resources. OpenOCD and OpenJTAG might be useful places to visit for information. You should not be expecting that every company using the JTAG hardware interface has a consistent programming algorithm. There are a lot of differences between devices. If you want to program Atmel components I'd suggest starting with Atmel (now MicroChip ) resources. You an find a lot of useful information there. Maybe, maybe not. It can get expensive relying on word of mouth or partial information. It's up to buyers to do their homework before spending money... this is a lesson that you don't want to repeat. Make sure that you have the full story before acting on a hunch. Anyway, as you suspect there's more to JTAG than a hardware interface and a cable. You have to format the data properly and have the correct software to perform the actual programming algorithm required by a specific device.

Well, I did suspect that he (I'm guessing ) was a Xilinx engineer. But he has one opinion, and likely a defensive one. I'm curious as to the pulse of the many working engineers there. Of course the opinion of an engineer working on a product is going to be different than that of customer of that product who has to use it to make a living while fending off ancillary pressures and deadlines. I've been in both situations. I can't disagree though that some useful communication between producers and users might not be a good thing. I've conditioned that statement because engineers, even senior engineers rarely have a say in where their ship is sailing to; even when everyone knows that their opinions might be correct. Still, if customers don't try and communicate untenable situations to their vendors then they can only blame themselves for their predicament. Competition is, in theory, supposed to resolve these kinds of problems; but competition, unfortunately, is a passe notion at the moment. I'm hoping that someone like you, who might earn a bit of respect, at least to the point of spurring FPGA vendors into trying to engage the user community honestly will bear some fruit. My fear is that it's too late and they no longer have the ability to control the beasts that they've created. Perhaps the decision makers at Xilinx aren't even steering the ship at this point. According to recent media articles Intel has had a vision and claims that it can reconstruct the old days when technical and production prowess was a thing for them. I'm a skeptic.. but what alternative do I have but to hope for the unlikely scenario that they will make good on this pledge. Given the headaches trying to use the current ZYNQ tools can anyone really believe that devices with a 'sea of processor complexes', tons of embedded memory and scattered logic complexes can be supported by the tool designers? Can you see a straight line between here and there? I can't. But who has the time? I expend most of my energy trying get around new bugs that get in the way of all-HDL designs. My WIn10 box has ISE 14.7. I installed it from a DVD. I installed a Linux version of ISE onto a separate HD. The last Vivado download to do ZYNQ development was over 60 GB. There isn't a lot of VHDL or Verilog functionality that ISE couldn't do. While Vivado has added a few feature support for later HDL incarnations it seem to be worse in terms of getting work done. This isn't my idea of progress. You'll have to point out what it is about the Reddit thread that has you upbeat. All I noticed, in connection to AXI IP, was the assertion that Xilinx gave ARM the bus specification and design.... who cares who fathered a bus specification? That doesn't prove competency. All that Vivado users care about is that whatever Xilinx peddles works... period. Well, that about sums up my current feelings on the topic. It seems to me that the GUI flow is a huge problem in terms of release to release continuity. Big FPGA user companies don't use the GUI tools. But then they have dozens or hundreds of engineers writing Perl and TCL scripts... all as support for designers and verification engineers who rarely do both. Perhaps you can guide them to the shore. Are they willing to abandon the board design flow and get back to supporting something that the users need? Something that allows any size company to develop products in a maintainable way over time? I try wading through the Xilinx Community Forum posts from time to time. Do you think that this senior engineer spends much time doing that? Of course the context of the Reddit thread in question is something that I'm not privy to. Obviously, there been some interaction bewteen you and the OP. No one can really understand anything without context.

Well, possibly. Please do read carefully the SelectIO reference manual with regard to termination. It might also help to do a bit of homework in exactly what TMDS means. Lastly, understand the consequences of termination, especially when it is on the receiving end of a cable and connected to equipment with a separate power supply. You can have some serious power supply sequencing issues. 50 ohm termination allows for a substantial current draw that might be unintended. There can be a lot of nuanced details to trip up on when adding external components for termination.

I'm not a fan of the standard social media platforms so I have no plans on signing up to add content to one; but it is interesting to get a sense of the frustration out there among those who do and have to use FPGA devices to make a living. But you've used Vivado. Many many versions of Vivado. So your perspective is useful though perhaps you aren't in a position to speak freely. When the device vendors are unresponsive to, or incapable of addressing customer issues with their tools then the customers are left to fend for themselves. I don't think that the Digilent forums are the place to do this, except as it relates to Digilent products, but I'm not sure where this might take place. Even for seasoned developers it's hard to navigate the swamp alone. If you want to see frustration you just need to go to the official Xilinx Community Forums. Personally, I haven't found that site very useful in terms of getting information or answers to mysteries that I encounter. It's so vast that I can't even find my own posts in a reasonable amount of time. Managing complexity takes commitment... and investment.

And perhaps some of the Digilent readers have been thinking that I'm the lone, eccentric odd whining voice in the wind? I've been using programmable logic from before the FPGA era. I've used devices, tools, and HDL languages from companies long since gone. The perspective of historical contrext shouldn't be ignored. So, I read the posts to the reddit thread and didn't see much new. I'm not sure what the intent of the thread moderator is but one thing is for sure... Xilinx can't blame anyone for it's slide into the black hole of tool dysfunction on anyone other than it's own management. What should anyone expect from a compressed 60+ MB ( and growing ) amalgam of semi-integrated collection of executables, scripts and IP that get tinkered with 2-3 time a year. At some point no one, not even the clowns, are running the circus. It just doesn't have to be this way. Frankly, I'd be a lot more interested in hearing what Xilinx engineers think about what's happened to their product and franchise. Not the tools necessarily because I believe that responsibility for that was long ago off-shored to subcontractors. My only hope now is that AMD won't make Xilinx FPGAs a game just for a few top companies and abandon the little guys. As Intel and Xilinx chase the high end market there's real concern for anyone hoping to be in the programmable device business and not part of a mega-corporation. Oops, I'm guessing that @JColvinwas expecting me to press my many grievances on Reddit. Well, entropy is a well known phenomenon, so I'll just keep trying to get stuff done with older versions of the tools until the PCs that they are installed on no longer work and if the older, less odious, versions of the tools are available and work with newer OSes. Incidentally, I've been using ISE lately because of bizarre Vivado PCIe tool issues and it's a revelation. I remember now why I resisted using Vivado for so long when it came out. It's all about getting work done in a timely manner with minimum time spent trying to work around tool bugs, mindless syntax changes, and disappointing results. There never was a great time for programmable logic tools ( though Quartus was noticeably less annoying for a period years ago ) but things have gotten ridiculous to the point of being worthy of a horror movie. BTW, the link as posted above didn't work for me but I was able to copy it and get my browser to see the thread discussion. No surprise to see @D@nrepresented there... keep on truckin' Dan...

The naming convention for Xilinx tools in regard to differential signals is "<name>_p", "<name>_n". The tools are sensitive to this convention. But this isn't your only problem. You are assigning single-ended IOSTANDARD LVCMOS33 to pins that you intend to be differential. But, that's likely not the biggest problem. The only differential IOSTANDARD for pins on IO banks powered by 3.3V is TMDS, which requires external 50 ohm terminators to ground. Before trying to do a design using a particular logic standard you need to understand the capabilities and limitations of the device. For Xilinx Series 7 FPGAs almost everything that you need to know is in the ug471_7Series_SelectIO Reference Manual. This is no different than trying to use any electronics componet; it's just that FPGA devices are a bit more complex. It's unfortunate that FPGA board vendors are confusing customers by implying that their products can support differential signalling when, by design, they can't. Digilent isn't the only one doing this. To my knowledge the ATLYS is the only FPGA board sold by Digilent that has a PMOD connected to and IO bank that can be driven by a user selected Vccio compatible with differential signalling IO other than TMDS. The FMC equipped boards do provide this, but only for the FMC pins. Even the CMOD product line only offers 3.3V IO. If you want to use a PMOD pin to drive or receive differential signals then your best option is to use en external differential driver/receiver device that converts differential signals to single-ended 3.3V signals and visa versa. So how many years is it that I've been trying to get Digilent to allow their customers the freedom to use Xilinx FPGAs to their full capability to no avail? Well, they do have 2 SYZYGY capable FPGA platforms that do this. Unfortunately, not all users are able to design custom SYZYGY pods. Connecting external interfaces to high density SMT connectors is beyond the capability of most FPGA board users. There really isn't a good excuse for not providing at least one 2.54mm or 2mm header with pin connections suitable for differential signalling so that customers can at least experiment with it. Ultimate performance isn't so important and is unlikely to be achieved anyway unless the FPGA has HP IO banks and internal termination options.

There's always been confusion over naming conventions for UART signals; both RxD and TxD are either inputs or outputs. Is RxD an input to the FPGA or UART device? Some of us remember the days of RS-232 equipped PCs... gender changers, n-pin <--> m-pin adapters... what a mess. Is the PC the data terminal equioment or is it the thing that I'm connecting my PC to the data terminal equipment? There never was any universally followed convention. What if 2 PCs are connected via an RS-232 interface? I still get a headache thinking about it... I still have a drawer filled with adapters. Generally as long as Digilent is consistent everyone can be happy. Their master constraints files have all used the uart_rxd_out and uart_txd_in convention indicating that the direction of these signals is from the perspective of the UART device; TxD on one device has to be connected to RxD on the other device. Connecting TxD to another TxD is a no-no. From the perspective of each device, RxD is an input; but both ends of a wire using the name RxD can't have inputs tied together and do anything useful. The big problem is TxD. This conventions is not honored by everyone. If you use the board design flow you should be able to let the tools handle pin location assignments regardless of the design signal names. Always, any signal designated as an out has to have an output buffer driving the pin assigned to it and that should agree with the schematic and datasheet for the external device connected to that pin ( the pin on the external device has to be an input ). A 'problem' with letting the FPGA development tools take care of the details is that the toplevel signal direction isn't always easy to identify and when things go wrong it's confusing. Vivado doesn't always make is easy to find all of its constraints sources. Personally, I'd rather do the work and be responsible for getting the details right. Regardless, when in doubt, consult the schematic and appropriate datasheets. Really, the perspective quandary can apply to any external interface. You can't always rely on the schematic names as a guide either. I've had to resolve this recently for the PCIe interface on a different board. Don't take for granted that a signal name in design sources, constraint files or even schematics are a reliable means of knowing if the FPGA pin is an input or an output. You can damage your FPGA by connecting an output buffer to a pin that's also being driven by an external driver. You can damage your FPGA by driving a bi-directional ( inout ) at the same time as an external device does; this is called bus contention. So, to my thinking letting the tools handle the details is a more risky way to do FPGA development ( for a number of other reasons as well ). BTW, if your UART interface is only using the two signals mentioned then you aren't using hardware flow control. This is fine for relatively low baud rates but most USB UART devices also provide additional signals for hardware flow control that are generally connected to FPGA pins. If you need to use the maximum possible baud rate possible then you will have to inlcue these additional signals in your design and the board design flow is likely to let you down, and you will have to take responsibility for the details anyway.

Digilent has support for the PMOD AD2 in the vivado-library repository in GitHub. This may or may not be useful as is, but there is source code to work from. It's always a good idea to check out current Digilent support for it's PMODs. Not all PMODs have any support. The Digilent PMOD AD2 product site here: https://reference.digilentinc.com/pmod/pmodad2/start also has links to other project sources, such as those by ADI. ADI has good FPGA support for a number of its products suitable for Linux hosts. You should get the datasheet for the AD7991 from the Analog Devices and read through it even if you don't intend on doing substantial HDL development on your own. It's always a good idea to understand how your hardware works and what its limitations are. In general demos and other available published project code for particular hardware has limited usability for user applications unless you are prepared to do some HDL work.

Awesome! Keep in touch with your progress.

Well, your requirements seem to fit well with what the demo code supports as far as sample depth is concerned. You ought to be able to work out a way to do 4 'simultaneous' channels. Read the Digilent comments about sample synchronization across channels. You might have to do some experimentation and calibration to assure correlation. Even though the demo ( I haven't looked at the repository for some time now ) seems to support one channel at a time this can be worked out as long as all 4 channels have capture buffers in the PL. You likely will have to work out better support for things like AC/DC coupling, scaling etc. but perhaps the prospects for completing your project without excessive effort isn't so bleak in your case. The Z7020 AXI is quite capable of DMAing 64-bit data into the external DDR at 100 MHz data rates so this might be an option and a way to increase sample depth per channel. [edit] Without bit packing, 4 channels of 100 MHz sample need to transfer 800 M bytes/s to DMA data directly into the PS controlled DDR . I've done close to 1100 M bytes/s on the Eclypse-Z7, albeit at a higher AXI clock rate, so this is doable. It would have been nice if Digilent provided better support for Ethernet data exchange as the platform doesn't have a decent alternative or extra IO headers suitable for high speed PC communication. But this isn't an insurmountable obstacle. The ADP3450 shows that Digilent know s how to do this and at the same time likely circumvents any such support for the Eclypse-Z7.

I love hearing about projects done for personal edification. The best engineers like doing engineering because they are curious and love the challenge. I don't know of any add-on boards for doing what you want to do using analog circuitry. But perhaps I could give you an idea or two to ponder without spoiling the adventure. Perhaps there are multiple paths to explore. Let's say that you have two 5 MHz sine signals with a fixed phase offset between them. Thinking about them, as two separate signals suggests a straight-forward time domain analysis for phase detection using direct analog to digital conversion and some mathematical magic. But what if you choose to think about them as the product of a sine-wave generator driving a variable impedance load? One representing voltage and the other current at the load. If you think about them in that context, the thought of considering power as it relates to magnitude and phase offset might lead to an interesting approach. As long as you don't have to deal with instantaneous phase offset that 1 MHz Fs isn't looking so inadequate. Can the XADC and some analog manipulation get you phase detection to within +/- 1 degree? I doubt it, but I doubt that the brute-force approach and a pair of 100 MHz "14-bit" ADCs will either. But you can come up with a rough estimation of what it would take. Instead of expecting to hit the target on the first cut I'd suggest starting out with lower objectives and seeing how different approaches go. This is why, when doing experiments because you want to learn, the journey really can be more valuable that finding answers. Usually, along the way you find more questions to answer. Sometimes, these are more interesting than the original problem. Almost certainly the result of constructing experiments to solve problems makes your conceptualization of what's going on in the hardware less naive. That's just one thought. I'm sure that you can come up with others. There's always a brute-force approach to solving puzzles but sometimes the way that you think about them can lead to an elegant solution using low cost hardware. The point is that the obvious way to approach problems can involve considerable hardware complexity and cost but often there are ways to get around the expensive requirements and still get good enough results to meet your requirements. That's the joy and beauty of embedded design; doing in logic or with limited computational power what a computer does with MATLAB or expensive custom libraries. I don't want to discourage you from taking the ADC route as there is a lot to learn about converters and fixed point math using logic. But, we all have budgets to consider. I'm assuming that 5-10 MHz is a fungible criteria. You can almost always scale down the initial specifications to fit a low hardware budget and still come up with an implementation to prove a solution concept. Two audio frequency sine waves would certainly require cheaper hardware. If you want to try building you own add-on circuitry to convert analog measurements to digital data the De0 Nano and Express PCB are easy to use to do almost anything. The De0 Nano has two 40-pin headers for expansion and while not the cheapest way to do you own PCB designs Express PCB, once you get used to its peculiarities, is pretty painless. It just doesn't work well for really high speed connectors and really small parts. You can get some decent ADCs from distributors that work in the 5-10 MHZ range, or perhaps used components to take an alternate route.

"simple data acquisition system" isn't much to work with; simple and data acquisition aren't concepts that I tend to associate with each other. I'm imagining that besides simple your implementation has to be useful for some particular purpose. Can you be more specific? For instance, what sample depth do you need? Do you need to process data in 'real time' or just collect n samples. What do you want to do with the samples? In my experience trying to go from the Digilent demo sources to a custom design isn't as simple as one would imagine. I had better results using the low level ADC controller code with some modifications and replacing the AXI level controllers all together. That's just one opinion from someone who's used the hardware. Unfortunately, the many good features of the ZMOD ADC1410 modules aren't fully implemented in the demos. I recommend being generous with estimating the time and effort to do a unique project with this platform.

I would certainly agree with you that the 1 MHz XADC, or equivalent, found in modern FPGA deices is inadequate in terms of Fs. Unfortunately, there aren't any low cost ( under $200 ) FPGA boards that support ADC or DAC conversion in the 100 MHz and higher Fs range. The Digilent ZMOD1410 dual ADC alone costs more that $200, but is the best low cost ADC module that you are likely to find. The question is what SYZYGY compatible FPGA platform do you want to use. Digilent offers two of them and Opal Kelly a couple as well. Unless you are specifically required to implement the entire project as an embedded solution you don't need a ZYNQ based FPGA board. I would suggest that the non-ARM based FPGA platforms are the preferred choice, depending on your HDL skills. Certainly I'd go with something like the XME7320 and a ZMOD 1410. But, this isn't cheap. Terasic's DDC dual ADDC/DAC board on an Intel platform is a decent alternative and could be used with a number of HSMC equipped FPGA platforms. For low Fs applications I'd recommend staying away from the cheaper Terasic ADC boards because they aren't setup for dealing with low speed signalling. Since you mention unspecified additional calculations to be performed I'm guessing that direct signal conversion to digital is an imperative. Given the lack of low cost educational quality hardware available you might consider an FPGA board that isn't limited by 12-pin PMOD interfaces and designing you own ADC add-on board. That would certainly be an impressive implementation, but be careful as the circuitry between your ADC input pins and your signals can easily subvert accurate phase measurements. Seems like an expensive project requirement for a student funded exercise.... If this isn't an educational exercise then I'd be asking about the accuracy/resolution of the phase measurements as this could dictate hardware choices. Designing a solution to a problem that has poorly defined specifications is often a fool's enterprise. [edit] I'm assuming a few things here; mostly that this is a student project. I can think of a few potential alternate ways to do this in the analog domain. Of course this depends on your measurement specifications. But it would simplify your signalling interface work and expense. For a student project you generally have to show some understanding of coursework preparation. [edit2] I forgot all about FPGA instruments like the AD2 and RedPitya. In the latter case this is an open system that allows for real custom FPGA application development. It also happens to be ZYNQ based, if that's what you want. There are affordable versions with 2 channels of ADCs that might be suitable, though sample depth is limited. You might not require a lot of samples per cycle if you are smart about how you do you detection. Be prepared for a significant amount of software effort. If you can figure out how to integrate the hardware and software frameworks into your project this is probably the most cost effective platform available... at least to my knowledge. You'll need to be proficient in Linux, Verilog and System Verilog to complete a project in any sort of reasonable time frame.

Could you be a bit more generous in describing the goals of this project? Are the input signals related, and if so how? Are the input signals sinusoidal, clocks, digital..?

Newer versions of FPGA tools usually come with support for the newest devices and package in production. Sometimes, they add valuable features such as support for newer HDL standard features. Always, they come with a raft of new bugs. It's been my experience that the 202x.x Vivado tools have some pretty dumb and annoying bugs. One weird one seems to be providing error or warning messages that suggest a workaround that, if followed explicitly, results in either a new error complaining about the syntax just offered. I've gotten messages from the tools referring to "<signal_name>_IBUF" instead of <signal_name> from the recent Vivado tools that I never saw in earlier versions. I've also had the newer tools offer syntax for constraints that are then rejected by the same tool. There are a number of strategies to deal with tool bugs. Don't use the latest version of the tools unless you have to: you are using a part that isn't supported by previous versions you need to use an HDL feature that isn't supported by previous versions you need a supporting feature in a particular tool version. Node-locked device licenses are generally honored in tool versions prior to the one that you got the license for Every tool release mentions a host OS version that is supposed to support it. In general older FPGA tools can be installed on newer OS releases, though sometimes this takes some extra effort. Tool version-host OS version pairings can get messy, especially for Linux hosts. Always check the post-route pin location assignments against the schematic and current master constraints file manually. In general, as far as tool version go, it's better to stick with the 'devil that you know' rather than the 'devil that you don't know'. Sometimes, the newer tool versions are just too much bother to deal with so I frequently use one that I've gotten used to. As to the CLOCK_DEDICATED_ROUTE FALSE constraint; you shouldn't be needing it in reference to the external global clock input pin for your FPGA board as this is a valid clock capable pin. Of course if the HDL name doesn't match exactly the constraint name then that's a problem. If you are using an MMCM or PLL between the clock input pin and your logic, it's not uncommon to get a warning about competing timing constraints. This is because the tool IP often creates its own timing constraints. When confronted with unexpected or weird build results you either have to track down the exact cause of the problem or just use a tool version that doesn't give you more headaches than you are prepared to deal with.

Replacing the FPGA on a cheap board with a faster grade part is rather extreme; certainly not cost effective. Be aware that there are unexpected issues that might crop up when trying to push a board beyond the original design capabilities. These things aren't PC motherboards. Perhaps it's work out fine; perhaps not. Did the company that did the work supply proof of connectivity, like xray scans? Do they guarantee their work?

I've spent many an hour over the years looking into connecting various converter EVMs to Digilent FPGA boards and I can tell you that this is tricky and requires a lot of work, even if the EVM has a compatible FMC connector. The first place, before you start thinking about timing constraints, is to understand the advanced IO features of the FPGA you will be using. This means reading the Series7 Select IO and clocking reference manuals very carefully. There are rules and limitations to understand that aren't obvious to someone without prior experience. Xilinx offers a number of application notes with sources that can be informative, but you need to know what questions to ask as you go over them. These will help you understand the mechanics of how to get LVDS working. 14x LVDS isn't the same as 7x LVDS. Since you already have the FPGA platform decided on the easiest path would be to use an ADC EVM that has an LPC FMC connector and comes with demonstration support. Since you didn't mention your converter requirements, I won't mention the subject except to say that not all converters are appropriate for all applications, especially those aimed at comms. Be aware that a lot of vendors use the connector that the FMC standard uses. This doesn't necessarily mean that they are compatible with Vita57 or any particular standard... just that the connector was used. Even if the EVM is Vita57 compatible there are still potential issues for LVDS greater than 8x data rates. You need to confirm not only connectivity of signals between the EVM ADC and the FPGA but that the data and clocks make it to the right IO bank according to the rules for your device. ADI has a number of EVMs that come with demonstration projects to work with specific FPGA platforms. ADI has better FPGA support than other vendors. It's typical, especially for high speed converter devices, for vendors to require that EVMs be used with another expensive control board. Understand that most converter EVMs are designed for confirming specifications only, not for use in a real world project application. The vendors don't want to be in competition with their customers for obvious reasons. If you are going to select an ADC EVM without an FMC connector then you have to figure out how to connect the two boards. Working with even the LPC FMC connector isn't trivial. Expect to use at least 4 signal layers on any adapter PCB you might design. Differential routing for very high speed signals requires more than just matched _n and _p length matching. You likely need to implement proper differential signal routing. If you use wires or cables then you need twisted pair cabling. Even if you find a cheap way to do this routing signals to a custom cable assembly header isn't trivial. Be aware that converter EMVs may be set up is a way that isn't compatible with your application needs. Assuming that you've worked out all of the connectivity issues you should read everything that Xilinx documentation has to offer concerning timing closure and constraints. The material tends to be out of date with respect to the tool versions. The main GUI page of Vivado offers templates for all manner of constraint syntax if you plan on writing your own constraints; that's how I prefer to do things. In my experience though the templates aren't necessarily that helpful as I've followed them on many occasions only to have the tools reject the syntax, and constraint, without sufficient guidance. Usually though you can do enough googling to figure out how to correct the syntax to work with your VIvado version. You can also use the Vivado TCL console to get help with just about any detail including syntax. Personally, I don't I don't find the constraints wizard to be all that helpful. The real head-scratchers come when you get into the details. My main point here is that figuring out what the vital details are and working out a solution often can't be worked out after selecting hardware, so get it right before you commit to hardware. All of the observations above assume that you've already worked out the timing according to the AC specifications for your FPGA device.

Further thoughts. I have the KC705 that comes with a heat-sink plus fan but Xilinx simply doesn't provide a part number for it. I did manged to find what looks to be the part from Radian. Recently, I've been working with the NetFPGA-1G-CML that uses the same K325T but in the FFG676 package. The board doesn't come with any thermal management. I had a passive heat sink, similar to the part linked to above, that appears to be from Radian ( probably got it from Jameco years ago ). Without any heatsink the FPGA gets quite toasty to the touch. I was measuring an average substrate temperature of around 63C for a very small test project using XADC. With the passive heatsink attached ( it came with a sticky pad attached ) but no forced airflow there wasn't much improvement after the heat-sink warmed up to a stead-state temperature. There is just minimal convection air-flow generated by these types of heat-sinks. With a fan blowing over it at low speed ( i.e. non-intrusive fan noise ) the average substrate temperature was down by about 30C. None of this information is shocking but it's easy to be fooled into a blissful state when you aren't looking for critical conditions. The XADC has programmable alarms so, again, I highly recommend using that feature for any Series7 project work and monitoring vital signs for distress. It's quite easy to implement the XADC primitive and send readings out from a UART or to an LCD periodically with minimal logic for HDL coding effort.

If there is you should be able to google it. I'm not familiar with what you are referring to. Intel might be a better platform for your interests as there is a (relatively) low cost path to your interest. Look at the Terasic Cyclone V based OpenVino boards. I could be wrong but I don't think that Xilinx supports low cost neural network experimentation as well as Intel. Picking an FPGA platform and trying to find free tools to support a particular project is usually a tour of dead ends. You are usually better off selecting hardware that has support for your project needs.