zygot

Gee, that's refreshing to read. Perhaps I'm not wasting my time trying to help people with their problems after all...

Yeah, I got that from the original post.

I believe that I addressed this in my original post. It depends on the converter. It depends on whether pin assignments on the carrier board and mezzanine card are compatible. This is especially important for clock signals going into the FPGA as there are rules based on clocking regions and IO banks. This is especially true for LVDS clock schemes with separate reference and data clocking. Does the FL9627 have a demo with source for use with the Genesys2? Due to FPGA complexity and differences between devices FMC isn't a "Plug and Play" standard. This means that you have to do your own homework or take a chance on someone else's claims. I've evaluated a LOT of FMC mezzanine cards for the Nexys Video and Genesys2 and am not talking out of my butt. But, no one should do something or not do something based solely on anything that I post. Ask yourself this: if someone were to post an answer that was "sure why not?" , how big of a risk taker are you? I suppose that you could look at the list of FMC mezzanine boards that Digilent certifies is guaranteed to work with any of their FPGA boards equipped with an FMC connector. Don't bother looking as there is no such list. In fact, if you browse through all of the Digilent posts on the subject the only thing that you will find is that Digilent does not test or certify that any FMC card will work with any of their FPGA boards. Either you know how to do the analysis for yourselves or you don't. I can't help you do your own due diligence. I might be able to help you figure out how to do the analysis for yourselves. As I mentioned, a whole other line of inquiry is whether or not a ADC card converter and analog front end is suitable for acquiring the kind of signal that you want to convert to a digital data stream. There are an awful lot of details in converting analog into digital that can be problematic. I realize that this isn't the answer that you want. I believe that it's likely the most informed and honest answer that you can hope to get.

What happens if you try flow control? You can use hardware flow control using CTSn and RTSn or XON/XOFF flow control using embedded ascii control codes. If you have a data source that can't stop sending data or a data sink that can't keep up or isn't constantly paying attention then, regardless of the communications type, you are going to have problems. Usually, for data interfaces serviced by software you need elastic storage on both ends to handle times when the interface can't be serviced.

You may well be correct about this, It's been a while since I've done this, and it was for a Xilinx board, the ZCU106. Yeah, that's what's bothering me. I'd expect that this shouldn't happen, unless you are updating or changing something. Sorry, I'm out of my league on this one. Hopefully, someone from Digilent who does this regularly will have something more useful to report.

I't been over a year now that the two big CPU companies have owned the two programmable companies that cover 90% of the programmable logic market. Today, both are losing money because they have bet big on bleeding edge, high margin, CPUs and support chips that serve a narrow market. A big part of this is the marketing strategy maximizing profits by saturating market segments in a pricing tier structure. That's the good news. Here's the bad news. Neither company is interested in the commodity programmable logic market that serves a vast array of small to mid-sized product vendors who need these devices. One can't even find a reference to MAX10 these days much less get a delivery date on a particular device. I know of companies that have had to EOL products because of this. Who know how many have had to shelve products because they can't get parts. Neither AMD nor Intel wants to invest in 40+ nm fabs, though I'm sure that there's pressure in the automotive industry for an easing of part availability. This is a freaking catastrophe for western economies. While government regulators are busy worrying about Microsoft abusing the gaming industry they seem to be oblivious to a much larger problem that is affecting a huge part of their economies. It's time for Intel and AMD to divest themselves of part, if not all of their programmable logic holdings. For the sake of the worlds economic health, regulators, worry about something important ( after making Microsoft split off it's Windows business ). And, no, that little rant didn't make me feel better...

I don't have a great answer for you as I don't do a lot of Linux builds using Linux tools for ZYNQ platforms. I do know that you have the option of downloading extra support packages like BSPs and sstate-cache Artifacts. Personally, I am loathe to do development that requires on-line access to current resources; partly for just the situation that you appear to have run into where things change and go missing. I do this kind of development on a PC that normally doesn't have internet access. I'm posting this as a potential route of investigation that might cause you to re-evaluate your development processes. Every road to a terminal point has pros and cons to consider. It's about control and time management. If your tool controls your project in a way that suits you and saves time then that's great. I haven't found that to be the case in general.

What FPGA board are you referring to? The schematics will provide all of the information that you need. I've used a LOT of FPGA development boards and only come across one with errors in the schematics: the NetFPGA-1G-CML.

Gee, wouldn't it be great if someone made a HPC FMC mezzanine card with standard, wide, and transceiver SYZYGY ports? Gee, wouldn't it be nice if Digilent, maker FPGA boards with FMC equipped connectors, had the gumption to make any FMC mezzanine cards to support their own products? Unfortunately, things aren't great or nice. If you want to use an FMC card with your FPGA board you have two basic options. You can find a vendor of FMC mezzanine cards that have the functionality that you are looking for. Make sure that they have a demo using that card with your board, and that they supply source code and a way to build a project in the version of your tools. Analog Devices sells A/D and D/A converters. They sell evaluation cards, sometimes with FMC or HSMC connectors, and provide limited HDL support to build a demo for that card. There may be others, but I don't know of any. Your second option is to find an FMC mezzanine card and do the work of making sure that it's compatible with your FPGA board. If LVDS or clocking is involved there is a good chance that there will be issues. It depends on the devices involved and pin assignments. Once you've established that there are no obvious issues of compatibility, you can then create you own HDL design to use the mezzanine board's functionality. With either option, you are unlikely to get exactly what you want. Sometimes you get lucky and find something close enough. If what you want to do is capture analog signals ( that's a whole discussion ) and use an HDMI connector to plot the signals on a monitor, there's 0% chance of finding an add-on card provided with HDL source code such an application.

For some endeavors, the distance between two points, such as starting from zero experience and ending up with a completed working design running on hardware, is usually not a straight line. Everyone learns differently and at a different pace. Be prepared for the unexpected and you'll be fine. Mere mortals like me have learned that starting off simple and adding complexity as I gain experience generally works out to be the quicker route to success. But that's what seems to work best for me, most of the time.... [edit] It's always tempting to ask yourself "can X platform be used to accomplish Y goals?" instead of "is there sufficient evidence that I can use X platform to complete Y goals within my budget and time constraints?" What you don't know can hurt you. When evaluating suitability for a particular platform it helps to see what the platform vendor demos for their products offer, and what version of the tools were used to implement them. I tend to be cautious because I know that facts out of context, and advertising promises rarely hold up when I'm doing actual real-world project development. Bord capabilities and board functionality are not the same. There are a lot of "ifs" and "exceptions" lurking in the details that the advertising doesn't cover. Again, I'm me doing "me projects". Your mileage, or download speed, or whatever may vary...

Start fixing errors from the top of you toplevel entity and work you way down. Your first error is that your VHDL tells synthesis to use a package that, I presume, hasn't been added to the project. Start there. You've read the documentation for using SimUAid for synthesis, right?

If there's ever been a programmable logic vendor with more than 2% market share I've used their tools and devices. Even still, my experience is limited as far as all of the device possibilities and application possibilities are concerned. Sadly, for the kinds of projects that I do, for the case where a general purpose FPGA board can substitute for actual custom designed application specific hardware, Intel based platforms are better than AMD based platforms, in general. This is certainly true for applications requiring lots of IO or differential signalling or when I want to integrate a platform into a solution. It's true for PCIe based applications when everything, including software is taken into account. HSMC prototyping options, if you don't want to build your own boards is better than FMC options. There are exceptions. If you want to experiment with transceivers for communications or video then there are AMD based boards, like the Genesys2, that provide better options. Frankly, I prefer AMD/XILINX devices over Intel devices (for the low end free to use devices ). AMD/XILINX tools and device support for low budget development is superior and wider. If you can afford high annual tool expenditures for high-end device support, or have an academic free-pass, then the calculus might be different. There just aren't any board vendors supplying great platforms at a reasonable price for AMD/XILINX development for the kinds of projects that I want to do. It's a frustrating experience for the experienced FPGA developer and absolutely bewildering for the average newcomer.

There are few things to mention with regard to using Intel tools that might not be obvious to everyone. First of all,.Intel has a loathsome marketing policy designed to extract maximum money out of it's customers. The free version of Quartus is generally fine for MAX10, Cyclone 10LP, and Cyclone IV or V devices, if you don't use external DDR or exotic features like transceivers. You will have to pay handsomely for a tool license for other devices and families. Companies that only design with Intel FPGA devices likely have to pay for 2-3 licenses to cover all of the devices that they might want to use. Just be aware of this. Every newcomer to FPGA development thinks that an FPGA with an ARM core block in it must be better. It certainly is harder to develop as you need to master both the HW and SW tools. For a product that is micro-controller based ZYNQ or SOC devices may indeed be the way to go. Make sure that you understand the host requirements for the EDS tools before purchasing a board. ( the same can be said for AMD/XILINX VItis if you need to run a Linux OS on your ZYNQ ). I didn't mention any of Terasic's SOC boards because I really, really dislike their ARM toolchain. Developing a complete HW/SW set of applications for a project is much more complicated than just a logic application if none of the vendor IP provides a magic solution. Your application is not one that begs for an embedded processor; it can more easily be implemented in logic. FPGA devices are complicated. FPGA devices with hard processor blocks are 10X as complicated for real world projects. Then, apply another multiplier for learning how to get along with the tools. It's the subtle details that cause the most development effort. If you have experience with nVidia embedded platforms, then you have an idea of what I'm talking about. This can get considerably more difficult if you have to integrate new hardware support into your nvidia-debian kernel using the nvidia software development tools. The DE-10 may be your best solution, I can't evaluate this. Just consider all of the potential hazards before making a commitment. Getting a heads-up from experienced developers is a good way to expose hazards that are hidden by the advertising glitz. Unfortunately, it's not practical to launch into a comprehensive discourse when replying to a question like yours. I am frequently criticized for being too wordy as it is. For the record, I do not make recommendations about product purchases. I can, however, provide guidance with regard to tools and platforms that I've spent time using and impart a bit of hard earned wisdom (opinions based on experience) along the way. I will always advise getting some experience with the tools before spending money on hardware. For devices supported in the free version of the tools you can get a good idea of what you are getting into as well as suitability of a particular device for your project without any expenditure. For programmable devices with hard ARM cores, this becomes a bit more complicated as there's no simulation tool that covers the logic and processor simulation. But you can see what a typical software application development flow looks like. Learning all of this after making a committment and while you are doing your project development is not a happy place.

I hope that you didn't think that my thoughts were being critical. You are right that using tcl scripts to generate FPGA projects, and obtain configuration files, that work for any version of one vendors tools can be complicated and frustrating. That's why it's great that you started a thread on the subject. I don't know about you, but I'm hoping that it generates some constructive posts from a variety of people bothering to read it. Gems are usually easy to miss lying in the grass. FPGA design flow for a published project meant to enlighten a wide range of readers or just pose a concept to think about is generally different than that for paid commercial work. For me, it's usually get an idea implemented with a reasonable amount of time and effort and publish it or never get around to the publish part. Sharing a project that only requires running a script to reproduce may be ideal.. or maybe not. I guess that it depends, depending on what your aim is. I agree with you that an all text source HDL project is a preferred goal. It generally involves a lot more work. Sometimes, the GUI IP is informative and might make for better designs. I believe that this is the case for MMCM or PLL clocking resource instantiation. Of course you can always do a design using a clocking "wizard" and then instantiate a macro or primitive in your published design. The same argument can be made for hard multipliers or DSP blocks; perhaps more so as tool support for these has gotten worse and more constrained, in terms of feature use, over the years. Vivado doesn't even support primitive instantiation of DSP blocks officially anymore. Then there are external memory controllers. There are transceiver based interfaces like PCIe and serial communications. Push-button bitstream creation ( running one script ) hides a lot of details that might be good to be aware of... even for the designer who might want to update an old design in a newer tool version, even when they think that they've previously covered all of the details. There are usually a lot of unseen things going one behind the scripting text that have more importance or risk then one might reasonable assume. And a really complicated set of scripts can be as hard to follow as any other project flow. All of those thoughts are for one FPGA vendor projects. Trying to create vendor agnostic projects can drive one crazy. One thing that I know for sure, my preference is to have all sources for a project in a text format ( not HTML ) that I can read through and run utilities that help manage text files. I'm more comfortable designing in VHDL. I think that, for a variety of reasons, Verilog design is superior. VHDL just hasn't gotten the love, and updating, that it deserves.... Last thought for now is that Quartus will be happy to create a tcl script for your project, if you like excitement. But it will help with the boilerplate.

In case this indicates that you are short on programmable logic development experience, I'd suggest choosing a vendor and sticking with it. A significant part of FPGA development is dealing with the tools. In terms of synthesis, Verilog and VHDL are not really programming languages. Each device family from a vendor has specific libraries supporting the architecture and resources of that family. Some aspects of FPGA resources require device specific library support ( for simulation ), like clocking and block memory.These differences will show up, especially from vendor to vendor. The tools, and even the versions of tools have their own quirks, and bugs to deal with. Quartus used to provide a free version of ModelSim for simulation, until version 20 or so, but now that's gone in favor of an Intel simulator. If you have an older installed version of Quartus available, then ModelSim is an options. You can't download anhy Quartus installer now that has it. I'm trying to say that dealing with 2 sets of vendor devices and tools is a big complication for experienced FPGA developers; so much more so for someone "learning on the job". Even the simulation work flow is different for different vendors tools. I mention this only in case you might develop additional questions.

I have no idea why this just now registered in my mind as I was busy doing something completely unrelated... but, about matrix multiplication. I highly suggest that you prototype your logic design in simulation for a particular board before making any assumptions about what you can do with the hard multipliers in Series 7 devices. Yes the DSP blocks are very fast, ~500 MHz on even the Artix. Except for particular topologies, the fabric connectivity of DSPs is not great. DSP slices have 2 DSP blocks and work well together. When connecting groups of DSP slices into a computational structure timing can get pretty bad. It's something that you will want to research before committing to a design concept. [edit] You'll need to run implementation to get timing information. You can do a timing simulation on the resulting netlist or just review the reports. For all logic designs with no soft-processor simulation is generally quicker than generating a bitstream if you are adjusting the design and there are no long self-calibration or delay elements in the design. My point is that, with any programmable logic vendor device, NEVER make assumptions about using DSP blocks.

Not every version of Windows is worth Microsoft's interest to support. Anyone remember Vista? Win10 had a large enough user base that users could "upgrade" to Win11. That hasn't happened very often in the annals of Microsoft domination of the PC market. Personally, Win10 is the last thing that Microsoft will force me to buy, whether I use it or not. UEFI and Linux can be problematic but it's Linux for my future. Once you figure out how to use your Linux distribution effectively Linux is a much more "engineering" friendly platform than the others. [edit] The last thought reminds me of a quote that I've read once. To paraphrase: "Unix is the worst operating system, except for all the others".

Terasic still sells the kind of FPGA boards that are ideal for these kinds of projects. The DE0 Nano and DE0-CV both have 68 IO pins on 2 40-pin headers. They are relatively cheap. The Cyclone GX Starter Kit has one 40-pin header and 1 HSMC connector with a lot more connectivity options. All of them have easy to use SDRAM. The GX board also has less-than easy to use LPDDR2, but that's only because the free Quartus is really badly supported, as is DDR IP for the cheaper Intel families. But I've done BL8 DDR designs for the GX board after a LOT of effort. Gee, if only there was an AMD/XILINX based vendor of FPGA development boards that had an interest in this market. Hmmmm.... if only I could think of a company with years of XILINX board design experience.... ideas anyone?

Not necessarily. For most Digilent FPGA boards an older version of Vivado is fine to use; perhaps even better than a newer version. Newer tool versions may not have the free IP that you want, and older versions have. If you are contemplating a board purchase look around to see what version of Vivado the demos for your board use. There's a big problem with Digilent demos and tool versions. Installers for older versions of Vivado fit on a DVD. Current versions of the tools ban be a 60+ GB download. As to why you are using Win8, that's another issue as that hasn't had Microsoft support for a while now. An alternative is to install a supported version of Linux for Vivado onto a second HD and boot to either Win8 or Linux via BIOS boot options. Windows has a tendency to interfere with Linux boot block code. I like to keep the separate to the extent possible. Personally, I'd be worried about exposing a PC with unsupported an OS to the internet. If all you want to do is learn how to do FPGA development and learn how to use the tools you can install any version of Vivado, pick any FPGA platform, and simulate your designs. Just be aware that newer Vivado tool versions might have changes making porting projects built in earlier versions a bit of effort, and that constraint syntax changes. If you want to use a ZYNQ device, tool version earlier than 2019.2 have quite different software development frameworks. This is the only real downside to using an older version of the tools... you are learning how to use a tool that is not current. Generally this is not a big issue, especially for a beginner who just wants to start off. The Vivado doesn't need "activation". The free version provides most of the functionality the you will need. You will need create a user account with AMD/XILINX to download and get access to most of the documentation. This is free to do. Most Artix devices and most ZYNQ devices are supported with the free tools.

An interface to an external device would involve more FPGA IO pins, unless the platform has a UART or USB interface on-board. You can always use a couple of pins to use an external USB UART. The Nexys Video and Genesys 2 boards have both UART and a USB 2 interfaces as well as a 1 GbE Ethernet PHY, which can connect the FPGA to a PC. To connect to an uController, SPI ports are likely to be available at decent data rate. SPi is not hard to implement in logic. I2C type interfaces tend to be pretty slow on such devices. There's always Ethernet, though implementing this in logic can be more difficult, though perfectly possible. 10/100 Ethernet is pretty slow compared to something like the Digilent DPTI USB 2.0 interface. It is possible to implement an Ethernet connection entirely in logic ( assuming that your FPGA platform has enough spare pins or an on-board Ethernet PHY ), with no MAC involved and use a software raw socket implementation on the uControler or PC. How you do this depends on where you want the processed data to end up. There are a number of possible choices. You might even be able to connect your FPGA to a controller using a parallel data interface. I've used the (unofficial) 18-bit SMI interface on RPi 3 and 4 to do this. I've also connected FPGA boards to RPi3, RPi4, and Nvidia platforms over USB using D2XX APi. However you implement the FPGA/MCU interface in your design I'd recommend avoiding odd clock rates. It's usually easier to use a faster data transport stream interface at an arbitrary data rate and either zero stuff bits or if the data is packetized, adjust the packet payload size. There are a lot of options depending on what the specific devices involved will be. What you choose will largely depend on how complicated you want your logic application and software application(s) to be. It's always a trade-off as far as time and effort goes. As a general rule of thumb any source synchronous interface at around 50 MHz or higher makes using a logic derived clock impractical and you'll need to use FPGA clocking resources. Lastly, give some thought to elastic buffer memory in your FPGA design to accommodate software latencies in the MCU/GPU implementation of the data stream interface. Most modern FPGA devices like the Artix and Cyclone V will have sufficient BRAM to implement small FIFOs or DPRAM for this. It's easy to prototype a concept in a logic simulation for a specific FPGA variant to help choose your FPGA device and platform. I'd guess that an A50T would be sufficient... only a guessitmate. Designing and assembling an FMC mezzanine card is not a trivial or inexpensive endeavor if you are only building 1 or 2 prototypes. Be aware that most PMOD implementations have 200 ohm series resistors. These can always be shorted or replaced with 0 ohm shunts. Digilent PMOD pin assignments are arbitrary and not designed for wide busses; another reason why they aren't ideal for this kind of project. Seems, like you are on your way. There are cheap Cyclone V or Artix based FPGA platforms available that should be suitable for a quick prototype construction. HSMC is an alternative to FMC and might be easier to use.

I'm looking at the MP34DT01-M onmi-directional MEMS sensor datasheet. All your FPGA platform would need to do is provide a power supply ( ideally 1.8V ), a L/R select output, a CLK output, and a DATA input for each of the sensors. That's 3 pins per sensor, or 384 pins for 128 sensors, if you were to control 128 separately. Of course, you might not need to do that exactly. If the sensors that you plan on using are similar, then it's an all digital design effort with no SPI or I2C interface... just direct connection. There are complications; there are always complications. You probably want to spatially arrange the sensors in some sort of configuration, each with a particular orientation in space. If this isn't a 2D configuration, then wiring gets to be a problem. I'd pay particular attention to how you implement the CLK distribution. A logic derived CLK would be sufficient. You probably don't want to create one CLK output and try and drive all 128 sensors with it, though this would save you 128 pin connections. A tree of external buffers might be good. Separate CLK output pins driving a group of sensors might work as well. It really depends on the physical location and wiring of the sensors. All of those CLK, DATA and L/R lines can be problematic... The MP34DT01-M can work with 3.3V Vdd, which would be ideal for most FPGA development platforms because most cheap ones only supply a fixed 3.3V Vccio to the IO banks. You need to make sure that the CLK, L/R and DATA signalling is compatible with the IOSTANDARD logic that your FPGA platform can support. For most Digilent FPGA boards this is 3.3V TTL or CMOS. You can always use logic level converters, but this would seriously complicate your prototype. A 3.3V working Vdd introduces its own issues to take into consideration. For this sensor, the L/R has to be either Vdd or GND, not Voh or Vol ( logic high or logic low) This is important to understand. Even if you can reduce your IO output pin requirements to the minimum this is 128 input pins. You can add digital multiplexers to the design to make the pin requirements a bit more palatable, but at the expense of more complexity and more sampling in-coherency. This is all up to your project requirements. So far all that I've addressed is the sensor side of your project. What are you planning on doing with the processed data that the FPGA logic produces? Digilent boards are not ideal for such a project. I didn't spend a lot of time on this reply, it doesn't represent a robust design concept, and I might not have gotten everything covered correctly, but hopefully provided some things to consider. In the end, you are the one who has to live with you choices.,

Could you be more specific? What kind(s) of sensors are you talking about? It's hard to provide a good answer without enough information. In general Digilent FPGA boards are designed to support their PMOD ecosystem, and are IO pin deficient. They do sell a couple of boards with 1 FMC connector but finding an off-the-shelf mezzanine card that supports 128 undefined sensors is going to be a problem. Even if you can list all of the exact sensors by part number an answer is not likely to be a simple one. Usually, for low Fs, multiple channel ADC applications, analog inputs to the sampler(s) are time mutiplexed. Are you prepared to do some digital and analog design and prototype construction?

Digilent's published description of their so-called "high-speed" PMOD, or "high-speed differential" PMOD is nothing short of willful misrepresentation of their product capabilities. There are no IOSTANDARD logic types supporting differential receivers for pin connected to IO banks with a Vccio of 3.3V, except for TMDS_33 which requires 50 ohm termination at the receiver end. This has been pointed out by users for some time now and they simply refuse to change their product advertising. Enough already. UG471 7Series Selectio User Guide describes all of the possible logic types that are supported for IO banks having a fixed Vccio, as well as proper termination. You can find application notes about possible ways to connect external logic to pins on IO banks that don't support a compatible IOSTANDARD. None of Digilent's FPGA board PMOD headers ( except one on the ATLYS ) are connected to an IO bank with anything other than a fixed 3.3V Vccio. [edit] PMODs connected to ZYNQ MIO pins are a different subject ] Differential IO and single-ended IO are not interchangeable; differential inputs and outputs use differential buffers and single-ended inputs and outputs use single-ended buffers. UG471 has guidance for mixing IOSTANDARD IO on the same IO bank. The synthesis, implementation, and bitgen tools know the rules and prevent a user design from breaking them. Before making a purchase of any FPGA board, first read the relevant FPGA vendor material and then look at the board schematic to see if it is appropriate for your needs.

Most people who visit this site use the IPI flow, because that's what the FPGA vendors want to promote, and it's for product vendors to easily to throw a simple demo together. For simple HDL flow designs, with no vendor IP ( not even BRAM or FIFOs ) a simple tcl script is a great idea. If you have any sources that are subject to vendor tool version changes then the tcl build script can get very messy. Digilent has proven that over and over with IPI demo tcl scripts that only work with one Vivado tool version. You don't even have to have any vendor dependent sources in your design as Xilinx has a habit of rendering projects created in one tool version into a whole new project by changing the syntax of constraints, or changing the tool database structure, etc., etc. Still, even for simple projects that don't need timing closure effort, even for hobby use, avoiding the GUI can be a really good idea. Of course, for commercial development text based build scripts are the only reasonable option. My view is that posts like this are only useful for getting people to think about things that they might not have experience with, or didn't think that they had time to explore. With that thought, great post. Someone should have started it long ago. even on an IPI, MicroBlaze oriented forum like this one.

The jig has been up for a while now. Respect your customers and show them that you have some respect for yourselves. This pretense of configuration IP has gone from annoying to sad.. and an unnecessary source of customer irritation.