zygot

Here's a random but pertinent musing about "plug and play" FPGA based carrier/mezzanine boards. In theory, the HPC or LPC FMC connector, which has become common on both Xilinx and Intel FPGA carrier boards, could provide some "plug and play" functionality as there is a two wire serial link generally assigned to the pins in order to be "compatible" with the Vita57 specification. Not all FPGA boards or FMC mezzanine cards claim or even try to be Vita57 compliant. All of the FMC mezzanine boards that I've used do connect that serial link to an EEPROM. So, in theory, one could do something similar to the SYZYGY DNA in terms of determining adjustable voltages. In this case, the serial link and EEPROM are tied to a 3.3V rail and available to the FPGA. Well, this is true for the Series7 and older devices, but perhaps could complicate the design of newer FPGA devices if there are no IO compatible with 3.3V logic. I've yet to encounter a situation in which the mezzanine card contains any usable information about Vadj voltage and current requirements. For the Nexys Video one could conceivably use such information to set the Vadj rail because GPIO pins are connected to the power supply for user Vadj selection. For the Genesys2 Vadj is controlled by physical user switch settings. For SYZYGY, where a carrier board might have 5 or more SYZYGY ports one can see how this might become an overly complicated power supply problem for the carrier board vendor. I have more than a few FMC mezzanine cards that are compatible with my Series 7 FPGA boards but not my UltraScale+ FPGA boards, and visa versa. UltraScale+ is 16nm technology, which isn't near the bleeding edge, so one can envision that the IO rail voltage limits will continue to get lower over time. While, as an FPGA board user I'd prefer having the FPGA have a direct link to any add-on card data, this isn't universally easy or cheap to achieve, given the tendency of newer FPGA devices to have ever low maximum IO bank Vccio rails. There's another issue though that perhaps the SYZYGY specification hasn't addressed completely yet. In order to obtain a bitstream or sof file you need to pass a DRC test that requires specifying an IOSTANDARD. Having a pod submit a minimum Vio voltage and maximum Vio voltage as well as the maximum current levels each would see and then allowing the carrier board to select one may be fine for some applications but not for others. At this time however, it's certainly too late to go back and change the constraints to rebuild your FPGA design. For me, the suitability of "plug and play" for the FPGA space is not certain. In addition to what I've just mentioned, there are real issues with IO bank clocking region restrictions, and other details that render even the FMC connect, Vita57 or not, incompatible with any "plug and play" scheme that I can think of. Then there's the issue of FPGA vendors making their newer devices, like UltraScale, with IO that isn't very general purpose. I do appreciate that Opal Kelly has invested in an attempt at it though. What I want is to be able to use the FPGA IO to its full capability, without having to make a complicated and expensive custom multi-layer add-on card. One doesn't need standard interfaces to accomplish that, just sensible board designs. This isn't the market space that Digilent wants to be in, though they do have boards with FMC and SYZYGY connectors. While it doesn't necessarily service my needs it is something. All of this might be moot anyway. For the kinds of things that I want to do I find myself using older devices like Cyclone IV, Cyclone V, Series 7 and when I look into my crystal ball I don't see these existing in the future. What I do see is very expensive, overly complex devices with some programmable logic and tools that are having a hard time keeping up with the changes. I'm not saying that the new stuff isn't exciting or useful for anything.. it just isn't programmable logic ideally suitable for the traditional kinds of problems that programmable logic was designed to address. I'm quite certain that there will be those traditional problems to solve for a long time to come, I just wonder if there will be the availability of suitable devices. A lot of concepts, like JIT, are great when everything is normal, but a real pestilence when the world is in turmoil. Having just two vendors control 90% of a market has unfortunate consequences, even in good times. It's worth thinking about; well, I think about it a lot as I go about my normal business. In electronics, sporadic and seismic change is the only constant.

With regard to how one should implement a one-off custom SYZYGY pod, the following is obviously my personal opinion. The DNA part of the SYZYGY specification represents a basic feature as this is what tells the carrier board that a pod is present and what the Vadj rail should be set to. By not including this, in even a simple custom pod, you are breaking not only the "plug and play" nature of the interface but the initialization process as well. I realize that it's tempting to omit this part of a custom pod design, as it requires a secondary HW and SW effort. but there are unfortunate consequences and risks for doing so. I'd advise against making this choice. Nevertheless, I suppose that carrier vendors are free to amend the specs if the user is willing to be responsible for the outcomes. If Digilent provides a VADJ_A_OVERRIDE register then there's a tacit advertisement that they support users setting or changing a port Vio voltage on the fly. Perhaps this functionality hasn't been implemented yet? Given that the spec has a pod providing min/max Vio requests and the carrier board deciding what Vio will actually be provided there might be some important details for a specific SYZYGY carrier board that might get missed if the user simply selects on Vio voltage; it's something to consider. I can see a situation where a user wants to insist on a particular Vio but without the DNA interaction the carrier has no idea what the max current draw for a pod might be. This may or may not be a problem.

Note that the SYZYGY specification is supposed to be "plug and play" using the SYZYGY DNA negotiation phase post power-on. Pods are not meant to have a "hot-plug" capability. This means that you need to secure your pods to the carrier boards ports. I would be nice if SYZYGY pod vendors supplied the necessary hardware to do that, or at least recommended specific spacers, nuts and bolts. 5mm spacers are not readily available. The safest bet is probably to use nylon spacers, nuts and bolts to avoid stressing the pod and carrier board PCBs. Also, users should not normally try and circumvent whatever Vadj is arrived at by the DNA process. If one were doing development on a custom pod board I suppose that manually setting Vadj might be useful as an interim step toward completing the pod design. This would require some careful planning to avoid unintended consequences for your pod and carrier board. Opal Kelly publishes SYZYGY specifications and I'd suggest that anyone using the SYZYGY interface familiarize themselves with this documentation. The Eclypse-Z7 implementation of the SYZYGY DNA specification, particularly with respect to ADC and DAC calibration data, is not quite "plug and play" across SYZYGY vendors. Ideally, one would like to be able to choose a SYZYGY carrier board from any vendor and a SYZYGY pod from any other vendor and be able to take full advantage of the hardware. To me that's what 'plug and play' means in the FPGA space. I think that the Eclypse-Z7 situation is mostly a lack of specificity on the part of Opal Kelly's specifications. Given the range of possible pod types this might not be avoidable in all cases. Perhaps now that there are a few SYZYGY pod vendors the specification could be updated for ADC and DAC pods. At least SYZYGY carrier board vendors should consider offering better flexibility in providing access to DNA data. The PMCU also controls the Eclypse-Z7 fan and this might be something that you might want to control as you are using the board. You don't need to be running Linux on the Eclypse-Z7 in order to change the fan settings but doing so isn't exactly straight-forward using the Standalone OS, but it can be done.

All FPGA vendors have reference material available regarding their licensing rules and procedures. You need to work with AMD/Xilinx to get answers to a particular licensing issue. Xilinx, now AMD, is unique in offering their node-locked device license. It is, I believe, intended to be tied to only 1 host PC for one Xilinx user account, and while it will work perpetually on that one host forever will not survive though more than 1 tools upgrade or so. All vendors sell network licenses for their tools, as well as node-locked licenses, for a considerable sum of money. I doubt that "sharing" a license with a colleague is within the bounds of any software license unless that colleague is using your host PC to do their work. Ever so briefly, Altera ( now Intel ) offered let you buy a USB dongle that served as a license key. This allowed for using the paid for tools license on more than 1 host PC, but only one at a time. That didn't last long. I suspect that tools licenses are a significant source of income that programmable logic device vendors don't want to give up. It's kind of remarkable that Xilinx tool licensing has been as generous as it is given the economic pressures of current world markets. We'll have to see if this changes now that AMD owns Xilinx, but I doubt that it will. Anyway, I have no personal complaints considering my experience with the licensing policy of their competitors.

Read the Digilent User Manual for your board. The mode switches determine how your FPGA gets configured once it powers on. If set to configure from FLASH (QSPI), it will automatically get configured with the demo written to the FLASH PROM before being shipped ( or any bitstream that the user writes to FLASH ) and start doing whatever the demo is supposed to do. If the mode switches are set for JTAG configuration, then the FPGA will be un-configured until the user explicitly configures it using the Vivado HW Manager or some other application. Until they are configured, programmable logic devices have no functionality and don't drive any output pins. Make sure that you've read the basic Xilinx literature about your device. Then start reading all of the supporting reference manuals such as configuration, clocking, IO, memory, etc. I believe that your problems so far are mostly due to wrong expectations for what you are working with.

How exactly, are readers expected to interpret this sentence ? Most people would probably assume that they can just download the archived project files and generate a bitstream file that works as advertised with minimal effort. They would assume that any Xilinx IP used would be free to use without an evaluation license. I've used the latest ML edition of the tools on both Win10 Pro and Ubuntu 20.04 but since installing it have found that it takes a very long time to bring up any of the Vivado editions that are installed, sometimes resulting in a timeout error ( though it does eventually start anyway ). I believe that the edition of the tools that users probably want to use depends on a lot of factors, like device support ( ML supports the most ) and what they want to do, and what design flow they prefer. Xilinx IP might be free in one version and not in another. Vitis 2021.2 is a 60+ GB install and Vivado 2017.3 plus the SDK is about 10% of that. Either can support anything that the Nexys Video board is capable of. As you point out it is usually possible to install the Xilinx tools on host OS versions not specifically supported by Xilinx; though sometimes this involves some unexpected work-arounds. Out of curiosity I downloaded the Nexys-Video-HDMI02020.1-1.zip source only to discover that it was totally empty of any code sources.

Xilinx abandoned the SDK with the 2019.2 version of the tools. You need to use Vitis which makes your tutorial out of date. You might consider using an earlier version of the tools to get started.. perhaps Vivado 2019.1. The Zedboard has been around for longer than Vivado so really any tool version will work. If you are just trying to learn how to use the tools it would be easier to use the version that your tutorials and demos are using. The basic concepts haven't changed but lots of things get depreciated with tool version releases, and this can complicate and confuse anyone trying to follow an out of date tutorial. ZYNQ based development is doubly affected by tool version incompatibilities because it always involves a HW plus SW design effort. Though Vitis was supposed to integrate all of the software tools better than previous versions, if you want ot use Linux, you still need to install Petalinux separately and use a Linux based OS Host for developments. Microsoft has been trying to subsume Linux into Windows for a while now so, in theory, this situation might eventually change. As for new releases of FPGA tools breaking old design source code as well as vendor IP; this is just the way that it is, and has always been across the programmable device market space.

Digilent sells its CMOD boards though the single ground pin is a problem. ( Well there are also 2 ground pins on the PMOD but you can't connect these directly to a custom PCB... which is really what the CMOD for factor is supposed to address ). Personally, my cheap go-to FPGA board is the Terasic DE0 Nano. I have a few ot them dedicated as components in custom instruments. They are great for insertion into a custom PCB with 2 40-pin GPIO headers having sufficient ground pins, GPIO, and clock capable inputs. You can use the free version of Quartus with them ( this includes a fre version of ModelSim ). There's no PC connectivity, but I always have a couple of 3.3V compatible TTL USB UART cables and breakout boards available. The Cyclone 10 development board might be a good fits as it has everything that you need. The Terasic Cyclone V GX Starter Kit is a nice low cost platform ( though no Ethernet unless you buy an add-on HSMC board. The MAX10 Development kit is is nice but there are no MAX10 devices or boards available anywhere that I know of. BTW, no one reqards me for mentioning a vendor product... I'm just thinking of what I use and have found to be useful. For Intel stick with Cyclone IV, Cyclone V, MAX10 ( well perhaps in the near future ) or Cyclone 10LP if you are working on a budget. I really wich that some Xilinx FPGA board vendor would come up with a Artix version of the DE0 Nano. In the Xilinx world the Mimas A7 is reasonably priced and feature rich with plenty of IO, including a 1 GbE port. It's pretty hard to find cheap Xilinx based boards with sufficient IO for use as a general purpose project these days. Unfortunately, this isa bad time to buy any electronic components. Everything that is available in distribution is more expensive than a year ago... and there isn't a lot in stock. Sometimes you have to be resourceful. A really cheap board like the DE0 Nano can have one of its GPIO headers connected to a Raspberry Pi 3 or 4 and the other connected to you project external hardware. You can get a good 3 MB/s out of the SPI ports with an SCLK of 31.25 MHz and 12-40 MB out ot the ALT1 pin functions (SMI); at least for small blocks of data. The RPi makes the Ethernet part pretty straight-forward ( and if you want to have full Etherent capability this is not the case for any FPGA platform ). You might garner snickers with such a setup but if it gets the job done quickly and relatively painlessly those are easy to ignore. If you want to use the RPi as an add-on board for your cheap FPGA board make sure to use the latest OS release, if for no other reason than the ability to use ramdisk(s) for temporary storage

Your concern about cross-talk between _n and _p pair traces is something to consider. Yes, I've been able to use the "high speed" differential PMOD connectors as single-ended signals for board to board connections on the Nexys Video, Genesys, and Genesys2 boards without noticing evidence of cross-talk. That's why I'm making the assumption that these signals, while matched to 10 mils or so, aren't laid out on the PCB as true differential signals. Also, I don't see any such traces on the top and bottom PCB layers; but this doesn't mean much as differential pairs can exist on separate PCB layers. The 12-pin connectors are not particularly suited for high speed, as in a typical LVDS display application, but I've seen similar connectors, using true differential signalling, run at 500+ MHz on boards from other FPGA board vendors. I guess that it all depends on what you mean by high speed, how many signals you need to accommodate, and the timing nature of your signals. There are a lot of details to get right for any specific signalling application. I haven't tried sending a couple of really narrow strobes through the Digilent "high speed differential" PMODs. I did once, a long time ago, make some custom PCB add-on boards that attempted to attach true single-ended to LVDS drivers and receivers to these PMODs and try and see how fast I could communicate bstween 2 FPGA boards. As I remember I got stuck and never got back to it, but the problem could have due to an error in the official Digilent master constraints files that I was using at the time. Always double check your routed pin location assignments against the schematic.

Digilent documentation is somewhat random on this point. For some of its FPGA boards, they specify the stand PMOD at a 10 MHz toggle rate in the board's Reference Manual. For other boards and ( as I remember ) the PMOD specification doesn't mention this. I think that this might be somewhat conservative but a 200 ohm series terminator placed at a random distance from a driver is not ideal. Most of the Digilent FPGA boards have two standard PMOD headers and 2 "high speed" headers. The standard PMOD headers have 200 ohm series resistors as device protection, and that might be important. The "high speed differential" PMODs don't have series resistors. The _n and _p signal pairs are somewhat length matched but these don't support differential signaling due to the IO Bank Vccio being 3.3V. The only exception that I know of is the ATLYS, with 1 differential PMOD with pins connected to an IO bank that can have its Vccio user selected. I've used these at 30-40+ MHz toggling rates for a couple of Digilent's boards in a few projects successfully. I don't believe that the _n/_p pair PCB traces are laid out is a differential manner, which is good because they can be used for signal-ended applications... which is the only differential IOSTANDARD available ( other than TMDS ) for series7 devices. So, for most boards you get 8 slow GPIO and 8 faster GPIO, which isn't a lot unless you are going to use PMOD add-on boards... which is what the standard PMODs are designed for. I'm unaware of any PMOD add-on boards designed to be used with the so called "high speed" PMOD connectors on the FPGA boards. Before selecting an FPGA platform do read the user reference manual and schematic. If these aren't provided then you might want to keep looking.

I've pretty much abandoned the Eclypse-Z7 as a platform due to the poor support and hardware design limitations so it's been a while since I've messed with the inner workings of that platform. There are just better ways to accomplish the same functionality on other platforms. Also, except for looking at the demos supplied by Digilent, I've only used the low-level controller IP as the AXI IP iis limited. The most straightforward way to use the DAC1411 pod to provide a single-shot waveform might be to mux the low-level DAC1411 controller sCh1In and sCh2In inputs with either your waveform source or a static quiescent value. This involves breaking into the code base supplied by Digilent, which isn't a trivial task the way that they have their GitHub repository set up. You'll likely have to add some AXI GPIO signals to interact with the HW changes. When the Eclypse-Z7 is running Linux this may involve some agony as you will have to add user space access to them. You definitely, don't want to try and control this in a Linux application directly; you'll need supporting hardware to make the timing work. Digilent seems to be headed toward an instrument based product line as opposed to concentrating on general purpose FPGA hardware ( just a sense based on what's been offered in the way of new products recently ). I wouldn't expect their support for their SYZYGY boards to be competitive with their more expensive instrument products. Basically, I view the Eclypse-Z7 code base as a half-hearted way to demonstrate that the hardware can do something rather than a good starting point for a custom application like yours. That's not to say that other users of the platform might have a more favorable view depending on what they want to accomplish. One other thought. Using an SD card based Linux OS on a ZYNQ platform involves a real risk of corrupting the FS during development if you can't shutdown the OS in an orderly fashion. A better way to do this is to have teh OS run our of a ramdisk. You'll want to store data collected by applications in a ramdisk anyway to avoid SD card deterioration from excessive write operations. I would suggest that using the Exlypse-Z7 with the Xilinx Standalone OS code and circumventing the Digilent AXI interfaces might be an easier, and quicker, way to get to where you want to be. If you search the Digilent forums there was someone else who posted about their project, which was the same as yours, and that was their approach.

If it were possible to find one anywhere I'd say that the $200 MAX10 development board is a great general purpose Ethernet based data server. It has external DDR, 2 1 GbE PHYs ( though I've never been able to use both simultaneously ) and an HSMC connector with > 70 GPIO. The MAX10 device is nice because it has internal FLASH for configuration so you can program it, wire it up to whatever, put it in a box and use it as an appliance. The MAX10 is billed as a CPLD but realistically acts like a reduced performance FPGA. FPGA vendor development boards were never intended to be used this way... but for quick on-off projects why not? I don't know why Xilinx got out of this area of the programmable market. Maybe AMD will have other ideas?

I realize that this might sound, on the face of it, like a stupid idea but I'm used to making do with what's available. If I were doing this kind of project, the first choice would be to make my own custom FPGA / ADC board. But that's a lot of work and time ( though you can spend a lot of time trying to make unsuitable hardware into something usable as well ), nor is it cheap and simple. My second choice might, depending on options and restrictions, be to use a simple FPGA board, like the DE0 Nano, connected to the converters and an RPi ( which has the Ethernet connectivity already packaged ) using a custom PCB without an FPGA device. You can get about 3 MB/s data transfer between the FPGA and the RPi via one SPI interface. There's also the mysterious Secondary Memory Interface that can do 16+ MB/s though not comfortably. Unfortunately, there's no kernel support for it so you have to accept the consequences of bypassing kernel services. I know.... this still requires a custom PCB, albeit a much more simple one ) and involves 3 boards. But sometimes such a solution is the best one available.

FPGA development is very complicated. Anyone trying to get started, without out any formal training, and with a software development mindset could easily get confused. For anyone with a pretty good head start, that is solid HDL experience and tool usage experience, the Digilent board reference manual documentation is pretty good and sufficient. Without that, it's possible to make some pretty bad assumptions that will get one into the weeds. One step at a time. See if you can power the board and get the Hardware Manager in Vivado to find and connect to it. Then try and build a demo and configure the FPGA.

I'm pretty sure that just about any low end FPGA can do the processing. Data storage requirements would, on the face of it appear to be minimal. Any FPGA platform with a 1 GbE interface can send the processed data to wherever it's going, though there might be details to work out. The issue is that 48,000,000 bytes of data transfer during the active phased of ADC sampling that is making this complicated. What are you thinking of as an ADC that has 16(32) serial data output pins ( one per ADC channel ) and a continuous 1 Ms Fs? I can't think of any. There are some nice 1 Ms multi-channel ADC devices out there ( though you have to read the datasheet very carefully to make sure that this is the continuous rate at which channels can be sampled and transferred out of the device ). I don't know of any 32 channel ADC devices like that. And then you have to consider if all of the channels need to be samples simultaneously. If you need to use more ADC devices, then you will need more control/status pins. The larger concern is the FPGA platform IO. Assuming that you don't want to select new hardware for the 32 channel version of your project, you'll need 32 GPIO plus as many control and status pins to control the ADC device(s). This is where the cheaper Digilent boards will let you down. In fact, I can't think of a cheap FPGA board with and Ethernet port and 40-50 GPIO tied to connectors in a convenient arrangement. The Terasic DE0 Nano would work but doesn't have and Ethernet PHY. The Mimas A7 might work though the GPIO isn't all that great for tying everything together with a custom PCB. Since Digilent likes to use MicroBlaze, even it's cheap boards tend to have an Ethernet PHY; this is great. Unfortunately, as I mentioned before, these boards serve a different purpose than as a platform for your kind of project, because they are meant to connected to 1 or more PMOD add-on boards, each with only 8 GPIO, and randomly placed clock capable pins if any at all. If it were currently possible to find an MAX10 devices available for sale I'd recommend designing your own FPGA/ADC platform using something available in a flatpack package. Unfortunately, these are on my current, and lengthy, list of things that money can't buy.

I don't think that you understood my first answer. In the case where the PS controls the external DDR memory ( all of the Z7000 boards sold by any vendor that I'm aware of ) the MIG IP is completely irrelevant; you can't use it. The MIG IP is for external memory interfaces connected to logic pins ( as for the Arty A7 board ). The only way for the PL to get access to the PS DDR is through one of the master or slave AXI busses. There are a number of Xilinx AXI IP that might be usable, though the best way would be to write own AXI master or AXI slave interface; this is not for the inexperienced FPGA developer ). The AXI streaming IP can DMA data between PS external memory and the PL. You will still need to have some understanding of how AXI works. There's always the limited, but still potentially alternatives, like using Xilinx AXI BRAM controllers in a configuration that allows access to DPRAM to both the AXI IP and your own PL code. This is conceptually the easiest method but requires PS software to either copy data to PS memory or use the ZYNQ DMA controller to do it. As I mentioned the only ZYNQ FPGA board that I know of with PL connected external memory is the ZCU106. In this case, UltraScale+ external memory controller IP is not the same as Series7 MIG IP.

No FPGA vendor gives away MAC IP without requiring a license. You may be able to obtain a free limited time MAC license in order to build your bitstream. Read the IP documentation.

The DDR in ZYNQ based boards are controlled by the PS so you can't control it from the PL. You can use an AXI master to transfer data between the PL and PS DDR however. There aren't a lot of Xilinx boards with external DDR connected to the PL.The ZCU106 is the only one that I'm aware of.

So I just realized that the ADC part of your project is more difficult than I thought. 32 channels of 12-bit 1 Msps is 32 12 Mbsp stream pins; and that's just for the data. You don't mention if you need coherent sampling which complicates things considerably. Possibly, your converters can output streams of parallel data but you likely need more than one converter. Either way you are likely to run into a shortage of GPIO connector pins and likely not enough clock capable pins if you want to use a really cheap FPGA platform. Again, this is where the PMOD universe isn't amenable to other than simple projects. In principle, 12 Mbsp data streams are within the capability of any Digilent PMOD. My thought for such a project would be to make a custom PCB tying all of the interfaces to a cheap FPGA board suitable for application as a system component. I don't think that this is part of the market that Digilent wants to serve. There are Digilent boards with FMC connectors, but designing a custom FMC mezzanine card isn't trivial. And these boards aren't something that you'd want to stick onto a larger custom PCB. I suppose that it could be possible to design a SYZYGY pod that would work on the Eclypse-Z7 board... but that's a lot of work and at a considerable cost premium.

It just so happens that I've been playing around with FPGA/ Raspberry Pi SPI connectivity. You need to pay attention to timing for MOSI. At low SCLK rates you can be fairly careless an read data on the RPi. At the highest SPI SCLK ( about 30 MHz ) timing gets complicated. What is your goal here?

Yeah, I remember a time a long time ago when bio-feedback was a new and hot idea for detecting alpha waves and such; and there were a number of DYI ideas floated about. Here's what I'm thinking. If I were just playing around and experimenting I'd consider a lot of options. If I were trying to achieve a particular goal, in a specific time frame, and my future depended on it, I'd be a lot more choosy about options. Building something, and building something that's usable ( whatever that means ) are rarely the same thing. Of course, there are a lot of people who are a LOT smarter than I am so I might be overly conservative. My impression is that capturing useful EEG waveforms is a lot more complicated than converting microvolt potentials into digital data. I'm thinking sub-cutaneous probes and current driven pickup. I could be wrong though.

All of this appears to be reasonable. The Arty A7 has a 10/100 Mbps Ethernet PHY so you may have an issue with streaming gap-less data for 32 channels using normal short packets. I'd be thinking of a 1 GbE Ethernet if Ethernet is the required interface. Data pacing requirements are a bug factor in any design. I don't think that there would be an issue processing your data as you describe it in an all HDL design. The Ethernet part might be more complicated than you anticipate, depending on your requirements and experience but is also doable. Usually, people use a soft processor if they need Ethernet because the free IP makes it easier. The problem there is that, for a small device, a MicroBlaze could consume most of the resources. You'd have to prototype a concept for various devices to get a sense. If you are doing point to point Ethernet then this isn't an overly difficult thing to implement in HDL. If you are connecting to a network though switches then it might be a problem. If you can simplify the Ethernet data flow, then things get easier. If I were to select from platforms for a project like this that I have available I'd be thinking of the MAX10 Development Kit or ( currently MAX10 devices and boards are as plentiful as hen's canines ) or the Mimas A7 ( currently over-priced if available at all ). Both are about $200 and have 1 GbE. There are some inexpensive ZYNQ based boards that might be an option for 1 GbE. ( Actually, I'd probably use the Genesys 2 because it's currently on my work bench; but I'm trying to meet you in the low end budget space as that's where you are starting ). Since the ZYNQ PS has a MAC and 1 GbE you might over estimate the task involved in transferring data over Ethernet. But, from a HW design standpoint it certainly would be simpler. Some Ethernet applications using ZYNQ are trivial like implementing a web server. Other applications not so much. ZYNQ Ethernet is complicated. If you are comfortable creating a custom Linux OS using Yocto or other framework then perhaps this is the best platform to use. It all depends on the Ethernet environment and requirements. A less elegant approach might be a really cheap Artix board and a Raspberry Pi for Ethernet connectivity. Three wires and a GND could connect the FPGA and RPi using SPI at up to 31.25 MHz data rates. The repetition rate of your data works in favor here. I'd be spending some time trying to figure out how to disconnect the Ethernet part from the FPGA part.. but really this is based on very little information.. and personal preferences. One nice thing about FPGA development is that you can mock up a prototype design and build it for any device or board in order to get a handle on resource usage, as well as simulate it, before selecting a hardware platform. [edit] Opps, I forgot about the ADC. One problem with Digilent FPGA boards are those outdated 12-pin PMODs. They aren't very friendly for experimenter's wanting to use a cheap board with custom hardware interfaces. There certainly are mult-channel ADC devices consistent with your requirements available but using the PMODs may be problematic. Not all PMODs on all boards have clock capable pin assignments that might complicate things. Digilent has the CMOD form factor and, if (almost) all of the available IO are inputs **might** be suitable. In general , I don't consider these to be suitable as general purpose 'components' in a system design for a number of reasons. The Terasic DE0 Nano is at a similar price and more robust. It has a better header design for most of the things that I want to do. You'll need to work this out. In terms of the Artix devices, as long as you don't use a MicroBlaze, any size should work. ADC design for a specific application isn't necessarily straight-forward so you are on your own there :).

You've probably got the parts for capturing data and doing analysis of a common range of signals, but I doubt that you have the parts required for the front-end analog conditioning required for capturing usable Biopotential signals. I'm not making any assumptions about the capabilities of your student, it's just that designing circuits for acquiring such low level signals requires some special knowledge. There are a few ICs for such a project like the ADS1299 or MAX30001 that might be available in a kit form and **might** be suitable. At least you can go to Analog Devices and Texas Instruments and do a search on what's available ( ADI now owns Maxim IC ). I think that I've seen an EEG product on Crown Supply at one time. Scrounging around the lab for stuff to do EEG signal acquisition or build a DYI electron microscope seems to be a bit much even for a brilliant mind that's a very quick study. Designing a safe usable EEG analog front-end from scratch would be quite a challenge even with an unlimited parts stock available for even a Biomedical Engineer I imagine. A place to start is by finding a good engineering text on the subject if for nothing else than getting a sense of what you are getting into. For ECG applications there are some good non-invasive ways to acquire biometric signals but I doubt that the same is true for EEG. I'm no expert on this by the way though I do have some medical device design experience.

Or maybe you've just gotten accustomed to buying products that don't quite work as advertised? Perhaps, but those pesky software libraries that all software products are built with are highly dependent on compiler versions, other library versions, OS versions, kernel versions, framework versions, and so on and so on.... things can get out of hand if your tool executables and scripts take up 150 GB of disk space. FPGA vendors always need to push out support for new devices. Fortunately, for everyone involved, the pace of XIlinx tool releases has been slowing down in recent years. I didn't mean to cause alarm, but questions about why Digilent demos don't work with a particular tool version is a common theme. New tool versions breaking old projects is more of a problem for people or companies that have to maintain sources over time.. not unlike software, but for different reasons. Depending on your interest and how long it lasts this might not even be a problem for you. But you can go to the product page for your board and see what demos are available and what tools versions they were designed in. Most of Digilent's demos are MicroBlaze based so you have twice the opportunity for problems ( HW and SW ). But do check out what's available to see the requirements. I'll warn you that approaching FPGA development as if it is similar to software development is likely going to be an obstacle for learning, if you want to become competent at it. But really it all depends on what your goals and objectives are. Every version of Xilinx tools ever produced has bugs so you want to stick with one version of the tools, when possible, so that you don't have to spend excessive time on tool bugs instead of those in your own project sources. I'd be surprised if no one posts a different answer to your question.

Here's one opinion ( make's me think of the old saw: if you want 10 answers to a question about economics just ask 3 economists. If you are new to FPGA development and have already purchased a development board, I'd suggest installing the version of the tools that were used to create the vendor's demo projects. This will reduce the time, complexity, and unknowns for rebuilding the demo. Fortunately, Digilent has a few such demos for most of its boards. Unfortunately, it's not likely that all of them will have been built using the same version of the tools. This should be useful information about FPGA development. FPGA vendors have a bad habit of breaking designs using older versions of their tools, especially if they are dependent on that vendor's IP and GUI 'drag and drop' design flow. Most vendors demos do use that flow because it's what the vendors prefer, or they imagine that creating HDL code to show their customers that all of the devices on their boards actually do work is a bad investment. The truth is that, for the most part, if they just made the initial investment in creating HDL sources for their boards interfaces maintaining demos through vendor's tool versions would be a whole lot easier... and there would be no issues over the years as tool versions are released. One caveat here is that FPGA development tools are dependent on specific OS versions ( not just Windows verses Linux, but specific Windows and Linux release versions). For the most part, older tools can be installed and will work just fine on newer OS versions. Another reason for my advice is that vendor IP used for specific hardware that might be free one version may not be in later versions. This is common. It doesn't hurt that older versions of the tools require significantly less disk space and download time. At some point you might want to keep installing new tool versions but you likely won't want to get rid of older installations for older projects that you've built. Unfortunately, Xilinx has problems co-mingling tool versions installed on one host. The latest version of Vivado supports a greater variety of devices than previous versions, which is good for someone with years of project to support. Since I installed Vivado ML, though, it frequently times out trying to open on WIn10. Worse yet, the same thing happens with the other versions that I use. So I wait for 2 minutes while nothing is happening after clicking on the launcher icon only to get a message that Vivado has timed out trying to start and then it starts anyway.. and now this is how all of the versions behave. No one is likely to create a list of preferred tool versions for particular hardware that is appropriate for general consumption because no one is going to be happen with it anyway. It would be great if board vendors provided HDL demo projects that demonstrate all of the resources on their boards; that would make the problem of tool version inconpatibitily moot; but I don't expect that to happen even though it would be less work and make everyone happier in the end. Tool version compatibility issues is completely avoidable as it only happens with script generated IP and project scripting that is not backward compatible ( or a change in constraint syntax ). It's an issue created by the FPGA vendors that affects their customers and affiliate vendors. Occasionally, the synthesis tools will support a feature that appears in a newer version of VHDL or Verilog that a customer wants to use but this is a rare thing. The tool vendors know that their development tools are too big and complex to maintain and yet they don't seem to want, or be able, to do anything about it. It's true that the P&R part of the tools gets more complicated as more and more devices are supported but that problem has a solution. [edit] All of the above assumes that you are one of the normal people who want to see their purchase do something.. and now. If you are just interested in learning VHDL or Verilog then the tool version doesn't matter, except for ZYNQ based boards. You can write HDL code and testbenches and try them out in simulation with no problem. Of course you don't actually need to have a board to do that. One vendor IP that I do recommend is the Clocking Wizard for most people. But there aren't too many options there so it's easy to setup from scratch for most use cases. The latest Vitis/Vivado tools come in a hefty 60 GB or so download package as opposed to the under 8 GB downloads of earlier versions, which might factor into a decision if you don't have a broadband connection.