zygot

Is the FLASH device on your CMOD-A7 the device that you think it is? Due to availability, there are a lot of variants out there and Digilent isn't very good at posting information about production run versions. Sadly, not all FLASH devices that seem to be "drop-in replacement" turn out to be so. A read through of the Series 7 Configuration Users' Manual might help focus your debug efforts.

Learning how to do FPGA development using Vivado by reading random source code can be tricky. If you don't understand what what you are reading is doing and why it's written the way that it is, it's easy to make bad assumptions. Let's go back to your ToDo list. What skills do you have in order to prepare for this project?

I'm not sure what exactly that you have in mind. If I wanted to capture/manipulate/display a live video source, using the Genesys2 HDMI inputs and outputs, I'd likely have a very different architecture for such a project. The architecture would be highly dependent on what I wanted to accomplish. Simultaneously writing and reading video line buffers in external memory would require a faster MiG controller than the one that I use in the Nexys Video or Genesy2 demos in this tutorial; assuming that I needed external memory. Both the Nexys Video and Genesys2 ( and the Mimas A7 ) can capture video using the HDMI input port. I haven't used Digilent's dvi2rgb or rgb2dvi IP. As an alternative you might browse Mike Field's archive here: https://github.com/hamsternz Be aware of content protection features in HDMI transport.

Wow that was confusing to read. I think that what you intended to say was that if the delay in your combinatorial logic approaches or exceeds the period of your register clock then your design will exhibit errors. Synthesis doesn't change clock frequencies for your design based on logic delays. In the case of an FPGA device external clocks and derived internal clocks generated by MMCM or PLL hardware are (mostly) fixed. Where your logic gets placed is fixed. If post-implementation timing analysis determines that logic path delays are excessive, based on clock periods, IO timing constraints, how the logic is synthesized, where it's placed, etc, etc, then your design won't work or, worse yest, will be unreliable. If your external input signals change in a way that is different than your timing constraints for those pins, then even a design that has no timing issues can fail. For outputs, even if you provide perfectly good timing constraints, there's no guarantee that the tools will meet those constraints. In that case you need to provide placement constraints for sections of your logic. It's all fairly complicated and not perfectly controllable. I don't know what "single deep combinatorial circuit" is supposed to mean. Combinatorial logic structures may require many levels of delays between parts of the structure. Even if there's one output of the structure the delay may not be the same depending how the inputs change. This is easier to conceptualize if you think of your logic structure in terms of and, or, not type boolean logic gates and draw a schematic of it. When you describe your logic in VHDL or Verilog code thinking about levels and delays is a lot harder to do. Tools like Vivado will create a schematic view of your logic ( well actually of what it is after synthesis has finished with it ) , and that might help you understand it better. Personally, I have had a design appear to work until one of my logic structures encountered a combination inputs and previous last state that cause excessive delay, and hence failure on running hardware. There was no timing warning, so the post implementation timing analysis was not as complete as it should have been. We make a lot of assumptions about how the tools work and what the reports mean. The reason why I'm bothering to post this is because of the nature of your project. It's pretty much the worst case use of an FPGA device.The analysis starts with a good practical understanding of digital design theory of your input signals before they even get past input buffers in your FPGA devices' input pins. Commercial use of FPGA devices rarely use off-the shelf third party FPGA boards; usually it's a board custom designed for a specific application. In general this means that often signals going into an FPGA are conditioned by some external circuit so that what the FPGA application sees meets dc and ac specifications.

Sequential circuits do not have to be clocked. Flip-flops don't have to be clocked. It's quite possible to have sequential logic ( depends on the state of previous output ) with memory that depends on a previous state. An example is an asynchronous RS flip-flop built using 2 2-input nor gates. Essentially, this is combinatorial logic with memory. This distinction is important because your HDL description of your design can cause synthesis to infer a latch (memory) which may not be what you intend to do. In the old days of MSI and LSI logic devices, or even PAL devices, logic was built from discrete basic boolean gates. A clock wasn't necessary. In FPGA devices, logic is implemented in LUTs not and/or/not gates. The problem of delay through levels of combinatorial logic as implemented in LUTs is still a problem, as it was in the old days. The way to manage the problem of delay is by using clocked registers ( also has memory ) to control timing between parts of a design. I've personally never attempted to implement a complete design in an FPGA that didn't use clocked registers. I suppose that it's possible. Most, if not all, FPGA designs use at least one clock to control their logic. It might be an external clock source or a number of clocks that are derived from an external clock source. When a design has multiple external clock sources that are unrelated ( not derived or synchronized ) to each other, or has inputs that can change state and violate setup or hold times, then your design starts getting complicated. Trying to simplify and condense a digital design course into a couple of posts to a thread like this is difficult because it's easy to miss, or confuse, really important concepts. Concepts like delay, clock setup time and clock hold time, meta-stability, etc. Can one turn on and off an LED on an FPGA board without understanding these concepts? Sure.

Not to be offensive, but "verified on hardware" as the only verification hurdle that a company providing HDL sources as support for their products would find to be acceptable is disappointing to say the least. That's the biggest reason why the original code didn't work.

You also see that the pulse has a rise time of 5.40 ns and a fall time of 8.10. This is with a scope of unknown analog bandwidth and a 1 GHz sampler. If nothing else, the scope picture should be telling you that capturing this SPD output is more than a simple digital exercise. Be careful of how you interpret oscilloscope signal renderings. Consider two of these that have arbitrary phase relationships on their leading and trailing edges relative to each other and, I assume any logic clock. The picture doesn't tell us this, but I'd assume that the cable from the SPD is plugged directly into the scope input that's set for 50 ohm termination. Doing this with a cheap FPGA board using PMOD headers with a trace between the header and IO pin that's not ideally impedance matched and having a much less than ideal termination will be something to consider. More importantly, consider that (if) the SPD doesn't provide a reference clock for defining phase relationships you will be doing asynchronous detection.. on 2 channels. Does an FPGA have the functionality to handle this? I don't have an opinion that I want to share. I would say that I'd think about doing the hard stuff using and external circuit so that I have a good idea of what the FPGA logic is seeing. It doesn't matter what logic is implemented in programmable logic if what it's working on is substantially different than the external signals. In theory, someone with a lot of experience might be able to pull this off in a reasonable amount of time. It would take more effort to verify than implement I imagine. Note that I have no experience using SPD type devices specifically.

For an Artix -1 speed grade device the maximum global clock buffer rate is 464 MHz. This is fastest that you can clock your design internally. For IOB clocking BUFIO maximum rate is 600 MHz. This the fastest rate that you can run the IO normally. For ISERDES it's 600 Mbps or 900 Mbps. It doesn't matter what the external clock source frequency is. These are the basic maximum capabilities of a typical low end FPGA device. Clocking a whole design implemented in a ARTY-A7 at 450 MHz will likely be problematic, but you can clock some of your logic at that rate and other parts of your design at a slower rate and meet timing closure.

In my browser, it's not obvious that there is even a dropdown under the Using the Latest Release part of the HTML page ( it's not visible by default ). But this doesn't answer the question about why there is an obvious link to downloading a "source code zip file" which is empty. This is not only confusing ( no one expects to download a source code archive that's empty ) and very irritating. It would've been nice if the IP included the simulation testbench, assuming that one was used to verify the design. As a general impression, the way that Digilent releases source code has gotten overly complicated for the user and not particularly friendly or easy to track down all of the requirements, instructions, information about what's included, etc. etc.; it's unnecessarily an exercise in frustration to do something that should be straight-forward. Does anyone at Digilent bother to take the time to experience what the customer experiences and think,"Great!"?

I'm not sure how good a plan this is for someone with no experience in using and digital design, HDL or Xilinx tools, but it is a plan. Don't trivialize the learning curve for implementing and debugging an attempt this as a first project. Don't trivialize the hardware design issues of connecting external equipment to a general purpose FPGA board. Before you can assess your storage requirement and a suitable way to convey collected data to a PC, you likely need to perform your tests first using expensive lab equipment. You need to set some reasonable parameters for your design specifications. It's certainly possible to use ISERDES to sample source-synchronous inputs at very high data rates. I suspect that doing this for 2 channels will be a bit more complicated than you anticipate. It might work out; I have no opinion about that.

Well, I suppose that it's nice that someone got around to fixing this. I downloaded the Nexys-Video-OLED-2022..1-2 "project source" using the link you provided. Of course it's just an empty archive except for empty folders and a README file about how to get the GIT. Why you you bother providing links to empty zip files? I won't bother getting the git sources as I assume that the format is the same as the earlier Digilent vivado-library IP and includes a netlist instead of actual source code. Also, I don't use MicroBlaze.

Does lsusb -d 0403:6010 -v tell you that what you are looking at is a Digilent endpoint? Vivado Hardware Manager seems to indicate that its found your board. If it's a kernel issue then I wouldn't expect this to happen. I'm not using kernel 6.2.13 so I can't test this. It's been reported that reverting to the previous kernel resolved Vivado driver issues. I also don't have the latest version of Vivado, and there are a lot of bugs in newer versions that don't get resolved before the next release. i guess that I'm saying that I can't replicate your user experience. Have you tried right-clicking on the localhost to see what options Vivado will give you? You can also not use auto-connect but go through the process of creating a new connection. Even with Vivado 2020.2 on Windows Vivado Hardware Manager gets confused if you connect a number of different boards because you are doing projects for two targets at the same time. I can;t say that you are on your own, but you are definitely on the bleeding-edge with your setup. From my notes: I did this to install the cable driver: $ cd user/opt/Xilinx/Vivado/2022.2/data/xicom/cable_drivers/lin64/install_script/install_drivers $ sudo ./install_drivers $ sudo adduser $user dialout where I've replaced my username with user. BTW, you don't need to install Adept in order to use a Digilent board with Vivado Hardware Manager. I installed Vivado and got it to work with a few of my Digilent FPGA boards before installing Adept on Ubuntu 22.04. A while ago Vivado Hardware Manager let you debug your JTAG connectivity but that tool, unfortunately, has been depreciated.

Part of the debugging process is trying to figure out why you aren't getting expected results. It could be your coding implementation or it could be that your design doesn't understand how the hardware works well enough. I don't see any harm in putting a 100 ms sleep() delay between the lines where you set the DAC and read the ADC. If that produces results that are more like you expect than you've learned something. You can always tweak the delay to be as short as possible. You can also read the last voltage by getting an ADC sample prior to setting the next one. This is a bit more complicated but might result in a much faster test. As to whether or not the AD2 is suitable for your application.. I don't know enough about your application to form an opinion. Generally, expecting some delay between when a voltage source is commanded to change the output level and when it settles on a new value is important to keep in mind. It's possible that due to the timing of transmitting commands to your test hardware, the AD2, makes that update/settle time irrelevant. From the information that you've provided so far, your approach suggests that it isn't irrelevant. Adding delays between test steps is easy enough to add, and remove later if there's no effect on results.

For what it's worth, this is my reaction to the statement above. Changing a voltage source and expecting it to settle to another level instantaneously is not a good idea, even if the output is a fast DAC plus some analog circuitry. This is especially true if reading the actual value involves some analog circuitry plus an ADC. So, some settling time is required to determine if the desired change happened and is stable. In practical terms a couple of ADC samples is required. The question is whether or not the interface is slow enough to provide a time lag between setting the DAC, having the output buffer settle, and obtaining a new ADC sample. I don't know the answer to that question, but as a general rule adding some short delay between setting an output of a voltage source and reading the input of the same source makes sense to me. However you do this, you need a good scope with a very high analog bandwidth to verify slew rates. Even then actual performance will depend on the input impedance of the load on the voltage source if it's not just the ADC input circuitry. Conversion between analog an digital realms is not a trivial endeavor.

A simple counter might suffice as a timetagger. I do this all the time to debug FPGA applications running on hardware where things like the ILA just don't work.

The key part of this thought is "considering events in a time window relative to some trigger". Sounds simpler than it usually is, especially when using an FPGA platform. Analyzing what's taking place inside a logic implementation in an FPGA is the easy part. Physicists have been using Time-to-Digital techniques to measure relative event times to picosecond resolution for a long time, often for photonic measurements. These can 'mostly' be implemented in logic, even an FPGA device.

This might require a lot of event storage, or not much at all. It depends on how many signal transitions occur over the experiment time interval and what you store. It also depends on whether the signal activity is bursty, intermittent, constant etc. A UART interface at a 921600 baud rate can do 80-90 K bytes/s without flow control assuming the your PC uses enough buffer storage. At 12 Mbaud a UART can do a little over 1 MB/s with hardware flow control. As long as the data being sent doesn't outpace the interface a small FPGA buffer using BRAM might be sufficient. There are often faster PC interfaces available on FPGA platforms for streaming data at higher rates. A bit if cleverness in a design architecture can overcome data transfer interface limitations performed in a simplistic manner. I'd say that something like an Analog Discovery product might be what you want to look at but the functionality of these can't be changed by the user. The Red Pitaya is a similar product to the ADx product line and allow for the user to add custom logic. The problem with that platform is that it's not well supported and hard to work with. For someone with good FPGA development experience, and some knowledge about the expected behavior of the hardware that you are measuring this is a 2 day project. Learning how to do FPGA development using Verilog or VHDL isn't a 2 day project.

@attila,Thanks for the trigger IO specification. I think that I understand most of what I need to know about the AD3 external clocking. It's been unavailable to me because I'm not going to go through the hassle of obtaining the latest beta version of Waveforms just to understand if a new product is suitable for any of my needs. Is this understandable? Digilent has always had a problem turning out documentation other than schematics for its products. It's obvious that the chore has always been assigned to an intern or least knowledgeable member of the staff and that sufficient editing and oversight by someone who's technically knowledgeable isn't done. I can see how a small company with limited resources might get caught up in this. It's a shame when it happens.

Asynchronous sampling means that the low-high and high-low transitions of your external signal have no phase relationship to the clocking of your FPGA logic. Whether or not asynchronous sampling is appropriate depends on how fast your logic can be clocked and the toggle rate or your external signal. For something like a user push button, synchronous sampling is not possible because you don't have an input clock associated with the button signal to define a fixed phase relationship. I imagine that this is the same with your photon detector. If a sensor provides both a clock and signal data, then you can so source-synchronous sampling of the data, as long as the external clock can be connected to a clock-capable pin of your FPGA. FPGA design is really digital logic design, so developers need to have basic knowledge of designing with real logic devices. In the early days of Xilinx programmable logic the tools only supported a schematic capture method of telling the tools how you wanted your design to function. Later, HDLs were supported so that your design could be presented in a text format. FPGA vendor tools such as Quartus and VIvado provide limited free IP, basically pre-designed functional blocks of HDL code, that allow implementing a limited range of design functionality, using a GUI schematic-like interface, without requiring the user to know anything about the source code. Eventually, developing skill with an HDL becomes a requirement if you want to do implement a custom design.

I have Vivado 2022.2 installed on Ubuntu 22.04. I also have Vivado 2022.2 Labs Edition installed here as well. One thing that I've noticed with the later versions of Vivado is that the Hardware Manager fails to auto-connect to targets and spews out error messages. In the Labs edition I use it for connecting to an ILA on one of the FPGA board. After spitting out error messages it then shows a valid target, that if I right-click on it and open that target works. lsusb -v is a useful command for making sure that your target is being enumerated by your Linux OS. Assuming that it lists a device like this: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC, try lsusb -d 0403:6010 -v You should see something like this: idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6010 FT2232C/D/H Dual UART/FIFO IC bcdDevice 7.00 iManufacturer 1 Digilent iProduct 2 Digilent Adept USB Device Can you describe your user experience better? NOTE: I've experience a lot of bugs and ill-behavior with recent versions of Vivado on Windows and Linux. One thing that is rather amazing to me is that Vivado pretty much looks the same on both hosts. I've used Vivado on Centos and Ubuntu, two distros with very different approaches to security, and for both installing FPGA vendor tools in a user owned directory solves a lot of headaches.

One might see this as a jab at VHDL. I see it as useful information.... Of course, Verilog isn't perfect either.

This might not be simpler. Mechanical buttons and switches feature contact bounce that can easily last for milliseconds. You need to account for this. Usually this is done with a "debounce" module or entity... oh now I see that Dan mentioned this already. the UART is the easiest way to pass data between your FPGA board and a PC. Whether you are timing a photonic sensor or a button, you will be doing asynchronous sampling at some appropriate clock rate that is unrelated to your DUT (device under test). On idea is to detect your pulse edges and save a timestamp and edge direction ( rising or falling ) to a FIFO. All of this can be done in VHDL or Verilog pretty easily and take up very few resources, depending on how much data you need to collect.

Well I wanted to see your response before getting more explicit. Due to the limitations of VHDL you are only able to specify signal types as is defined by the IEEE libraries that you use. You want to use both ieee.std_logic_1164 and ieee.numeric_std libraries. These are not the best combination of choices. I suggest either using ieee.numeric_std, or ieee.std_logic_1164 and either ieee.std_logic_unsigned or ieee.std_logic_signed depending on what format your want to work with. As it stands, you will likely run into conflicts with the synthesis tools as it tries to figure out what you mean by the '+' or '-' operators; if not in this project then in more complex ones. Let's presume that you comment out ieee.numeric_std and go with the 1164 and unsigned libraries. You are constrained to putting std_logic or std_logic_vector types on your toplevel port list. The problem with this is that Vivado synthesis interprets these as single-ended IO signals requiring single-ended output buffers. You are probably thinking that since your constraints file declares IOSTANDARD TMDS_33, synthesis would understand that it needs to instantiate a differential output buffer. Unfortunately, this isn't how VIvado works. Don' ask me why, ask your tool vendor. Your only recourse is to explicitly instantiate an appropriate differential output buffer, like OBUFDS, in your code to help out synthesis understand your design. While you can get away with letting Vivado synthesis instantiate IO buffers for you, it's a much better idea to do this for yourself. Read UG472 Series7 Select IO User Manual for more information.

Part of your confusion is that HDLs like VHDL and Verilog were not designed for logic synthesis. You'd think that after 40 years or so of allowing VHDL as a source for tools like Quartus or Vivado or ISE that HDLs would have kept up. They haven't, probably because there isn't much incentive for FPGA vendors to push for it. The result of all of this is relevant to your problem: VHDL doesn't know anything about differential signalling. This means that you can't specify a differential signal directly in your VHDL source code. VHDL doesn't know anything about IO buffers either. This is all vendor specific. A lot of things that you might want to include in your VHDL are things that VHDL is ignorant about. You have to instantiate vendor specific macros or primitives instead. Notably, vendors do allow you to put some of their vendor specific specifications, directives, and other information into your source that VHDL doesn't understand but that the tools do. Unfortunately, it's all vendor specific and worse yet completely arbitrary. Timing specifications is another area where HDLs are inadequate. So, there's a disconnect between what the HDL can do and what is required by FPGA vendor tools. None of them let you put location constraints in your source code, which in my humble opinion, is where they belong. In other technologies, third parties set definitions for how devices are specified and conform; MSI or LSI logic being an example. The vendors then conform to those standards. In the programmable logic world, this never happened. FPGA vendors would much rather do their own thing and make it hard to change vendors. So, HDLs are still in the 20th century and vendors design their synthesis tools to be unique and hard to port to other vendors tools. Over the years I've seen a lot of attempts at creating a framework for FPGA design that is vendor agnostic. Some of them have very impressive, but limited, application demos to get people interested. None of the one's that I've come across are suitable alternatives to what the FPGA vendors want the world to look like. What the world needs is a good 21st century HDL that lets you do your entire design using the HDL keywords. This would require programmable logic vendors to conform to a 3rd party specification for synthesis. I don't see that happening any time soon.

This part of your question makes no sense at all. Of course your question is about both your VHDL and constraints; it always is. Your question is about a bitgen error that you have no idea how to resolve. The answer to your question is in your VHDL source. If your HDL source doesn't explicitly instantiate input or output buffers, then the tool will try and instantiate one for you based on your HDL source. A couple of other hints is that logic IO buffers are distinct from clock IO buffers, and single-ended IO buffers are not the same as differential IO buffers. Your HDL source and constraints must agree and the port names must match in both places.