Digilent Staff
  • Content Count

  • Joined

  • Last visited

Posts posted by Ionut

  1. Hi kenken,

    In the VI you sent, you use two different methods to write to a measurements file: the "Write Delimited Spreadsheet" subVI I mentioned before and an Express VI for writing spreadsheets. You don't need both - any one of them would be enough. Therefore, I removed the Express VI and kept the "Write Delimited Spreadsheet".


    - You did not wire a file path control or constant to the "file path" input, so I added a control for that;

    - The waveform data you wanted to wire to the "1D data" input has a red dot next to the connection to the "Write Delimited Spreadsheet". This means some conversion must be done to the data, and this might mean it would not be written correctly to the spreadsheet. In our case, only one value gets written per run. The correct way to fix this is to index the array and take only the first waveform from it.

    - Then, from the waveform you obtain, you only want the actual data samples, so you unbundle the data array (1-D) from the waveform; you then connect the result to the "Write Delimited Spreadsheet" 1D data input.

    - The delimiter needs to be changed to a comma, so each written value corresponds to one CSV cell.

    - If you want to save the waveform values with more digits after the decimal point, you can change the format from the default %.3f to, for example, %.7f.

    I made the above changes, and uploaded the edited VI and a generated CSV file.

    Best Regards!


  2. Hi kenken,

    For logging the data in a spreadsheet, please right-click in a LabVIEW block diagram, select "Search" and look for "Write Delimited Spreadsheet". Double click on the search result, and then drag the icon that is highlighted into your block diagram. It should look like in the picture below.


    You then need to connect the data you want to put in a line to the "1D data" input, set the "append to file?" to T and also make sure you connect a constant or control with the file path and name to the "file path" input. This icon will create a CSV (Comma-Separated Values) file, which you can then open and edit in Excel or other similar programs.

    Best Regards!

  3. Hello,

    T means True and logic 1, which is a high level on your DIOs.

    F means False and logic 0, which is a low level on your DIOs.

    Pretrigger time is just the time the oscilloscope input acquires signal before the actual pulse is generated; this can be useful in case you want to see an event or noise before the actual pulse.

    Yes, the "Wait for 20ms between reading the data and displaying + saving it." records the waveform 20ms after acquiring the waveform.

    Best Regards!

  4. Hi tomii,

    From your posts, it seems that the Pmod AD1 generates data correctly when its data outputs are not connected to the FPGA board.

    The series 100 ohm resistors are rather small, so any FPGA input buffer with an input impedance of tens of KOhms should not decrease the signal amplitude (by creating a voltage divider with the series 100 ohm resistor) below the minimum input high level.

    You could also try to enable pullup resistors on the FPGA input pins (using the | PULLUP keyword at the end of the respective NET lines in the UCF file). The pullup ressitors should not affect the voltage levels generated by the Pmod AD1:

    - The logic high level should not be affected as the pullup is connected to a similar voltage (3.3V);

    - The logic low level should not be affected because the pullup resistor value for Spartan 3E is at least 10 KOhms, way larger than the series 100 ohm resistor.

    Then measure the values on those FPGA pins with the Pmod AD1 module disconnected from the FPGA board:

    - If the measured value is close to 3.3V, you can then try to connect the Pmod AD1 module to it and see if it works.
    - If the measured value is closer to 0V, it means there may be a problem with the FPGA IC or with the FPGA board. If so, as the board is manufactured by Opal Kelly, I recommend contacting them.

    For more information about the PULLUP keyword, you can go to

    Best Regards!

  5. Hi kenken,

    If you look at your screenshot, from left to right:

    - The first circled item is the initial value for DIO14 and DIO15 (F = false = logic 0); you can leave it the way it is;

    - The second circled item is a flat sequence with a delay time inside; the value of the delay time is given by a local variable called "Pretrigger time (ms)", which takes its value from the front panel control with the same name. This delay is necessary so that the oscilloscope input has time to acquire the samples corresponding to the pretrigger time (i.e. the time before the rising edge that you trigger on). You can leave this the way it is too. However, you can change the value of the front panel control called "Pretrigger time (ms)", to adjust the position of the pulse on your front panel waveform.

    - The third item is the high value of the pulse on DIO14 and DIO15 (T = true = logic 1); you can leave it the way it is;

    - The fourth item is a delay corresponding to the pulse duration, in ms. Now it is 1ms, but you can change it to other values as well.

    - The fifth item is the final value of the pulse (F = false = logic 0). You should leave this too the way it is.

    Best Regards!

  6. Hi kenken,

    In order to wait for 20ms between reading the waveform and displaying it in the VI, you can simply add a "Wait (ms)" LabVIEW function with 20ms at its input, inside a flat sequence structure, on the wire going to the Waveform Graph. I did this in the attached VI.

    Also, in your VI the pretrigger time was too large (500ms, when the entire acquisition time was 500ms); there was no way to see the pulse with that pretrigger time setting.

    Finally, before generating the 1ms pulse, you need to wait for the pretrigger time to elapse, so that Analog Discovery can read the corresponding pretrigger samples.

    I fixed this in the attached VI, and set the pretrigger time to 100ms; any setting smaller than the acquisition time should work.

    Best Regards!

  7. Hi kenken,

    I'm not sure I understand your problem. Do you want to wait for 20ms between reading the waveform and displaying it in the VI?

    Or do you want to acquire data using the oscilloscope input 20ms after the pulse has been generated?

    The case where the pulse wave is not displayed on the oscilloscope refers to the triggering problem I mentioned in my previous post. I contacted a colleague bout this, and hopefully we will have a solution soon.

    I have another question: which of the two attached VIs did you use: or

    Best Regards!

  8. Hi kenken,

    I'm sorry for the delay in answering you.

    Generating a pulse using the digital outputs would look like in the upper part of the attached VI (see comments in the VI block diagram for details).

    However, using this method you would not be able to control the width of the pulse very accurately, as this is controlled by software. A desired 1ms pulse width could end up being 0.5ms or 2ms in reality.

    Because of this, I recommend using the method described in my previous post above (Using Waveforms SDK and LabVIEW, for example), for which the timing is controlled by hardware, and it is therefore more accurate.

    Please note that for the VI attached to this post, there is also another problem: triggering on the oscilloscope input channels does not work when looping back the digital output channels to them. If you are happy with the software-controlled timing offered by this VI, I will contact one of my colleagues to further debug the triggering issue.

    Best Regards!

  9. Hi kenken,

    Please look at the attached It contains the following items:
    - A version of the Digilent Waveforms library I imported into LabVIEW 2015 ("DwfLibrary" folder);
    - A LabVIEW 2015 test project with contains this library, together with a test VI in which I started adding the functions indicated in the source code;
    - The file;
    - The WaveForms SDK Reference Manual.pdf manual.

    To complete your project, you would need to continue to add functions to the Test VI, as indicated by the source code. You can open the Python source code with any text editor. For extra information on the needed parameters, please follow the WaveForms SDK Reference Manual.pdf.

    Best Regards!

  10. Hi kenken,

    If I understood correctly, you would like to generate a single 5V pulse? What length would that have? 1ms?

    In any case, the digital outputs on the Analog Discovery 2 can only generate up to 3.3V output, so they would not work for your intended use case.

    You can use instead one of the Waveform generator outputs to generate the pulse. However, the Digilent Waveforms VIs you are currently using do not provide the ability to reliably generate a single digital pulse. This functionality does exist in the Waveforms SDK, which is a library installed together with the Waveforms software.

    I've attached to this answer a Python example showing how to generate a pulse ( using Waveforms SDK.

    If you would like to use LabVIEW instead of Python, you could import the Waveforms SDK library (called dwf.dll and found in the Windows\system32 folder) into LabVIEW (here is how: and re-implement the attached Python script in LabVIEW.

    Please let me know if you have any other questions.

    Best Regards!

  11. Hi Duncan,

    From your description, it seems the "bad" start condition is recognized for some transactions, but not for others. It most likely is marginal all the time, and sometimes the ADV7611 recognizes it correctly, on other times it doesn't.

    But it is weird that the problem only occurs when using the FMC interface pins, but not the Pmod pins. It would be interesting to compare the FPGA implementation results between the version using FMC for the I2C lines vs. the one using the Pmod pins:

    - Are the two internal circuits the same (I/O buffers, gates, flip-flops)?

    - Are the output flip-flop to FPGA pin delays relatively the same between the two implementations?

    Also, it would be worth checking, if possible, if there are any significant routing delays on the FPGA board, between the FPGA-to-FMC I2C pins and the FPGA-to-Pmod I2C pins.

    Best Regards!

  12. Hi Duncan,

    I'm sorry for the delay in answering you.

    Yes, you get the Acknowledge from the slave device, but only for the prior transaction(s), for example for the 0xFD byte. For the 0x99 byte, you do not get the Acknowledge anymore. So I would ask the question: do you see a "bad" start condition (like the one from your picture for byte 0x99) for other bytes, before the 0x99 byte? Or is the "bad" start condition only appearing in that one isolated case?

    Best Regards!

  13. Hi kenken,

    Thank you for sending the VI!

    I managed to run your VI and ended up at the following conclusions:

    1. In your oscilloscope settings, you were setting the vertical range to only 1V, too small to see the entire signal you were generating. Once I set it to a value larger than the peak-to-peak level of your signal (at 5V amplitude, peak-to-peak would be 10V, so I set the vertical range to 20V), the correct signal level appeared.

    2. The default buffer size for the oscilloscope input channels which is provided by Analog Discovery 2 is 8192 samples/channel (please see for details). At your set sampling rate of 20kSamples/s, this means only 409.6ms, which you obtained. Once I lowered the sampling rate to 10kSamples/s, I managed to see the 500ms you wanted.

    3. However, I could not reproduce the spikes on the waveform which you showed in your capture above. Every time I ran the VI, the waveform looks rectangular. Please make sure you connect both terminals of oscilloscope channel 1: the "+" needs to connect to Waveform Generator 1 terminal, while the "-" needs to connect to GND.

    I've attached the updated VI here, together with some comments next to where I made the updates.

    Please let me know if you encounter any other issues.

    Best Regards!

  14. Hello,

    From the waveform you attached, it seems you are issuing a stop command after the first byte (which is 0xFD), and then you attempt a start command before the second byte (which is 0x99). However, it seems to me that the SDA low pulse during the respective start command is too short, and the corresponding SCL rising edge comes rather late. Therefore, the start condition may not be properly interpreted by the ADV7611. Please see the attached picture for more info (I edited the picture you attached).

    I think you should try to correct the Start condition generation, and then try to communicate with the ADV7611 again.

    Please let me know if you still see issues afterwards.

    Best Regards!


  15. Hello,

    You only have the hardware platform in SDK. You need to import the other projects from the SDK folder (fsbl, fsbl_bsp, pcam_vdma_hdmi and pcam_vdma_hdmi_bsp) into SDK, by selecting File -> Import -> General -> Existing Projects into Workspace -> Next -> Select Root Directory as \Zybo-Z7-20-pcam-5c-master\sdk -> Select the above-mentioned projects -> Finish.

    Then follow steps 3 through 5 from the above post.

    Best Regards,


  16. Hello,


    The debug module for the CSI-2 IP is only used for HW debugging inside the IP itself, it is not used for setting up parameters like camera resolution. For these parameters, the AXI-Lite interface is used instead. So the messages in the UART terminal should appear regardless of the IP Debug settings.

    After the bitstream is generated by Vivado, please make sure you do the following:

    1. Export the hardware (File -> Export -> Export Hardware -> Include bitstream) to the \Zybo-Z7-20-pcam-5c-master\hw_handoff folder, overwriting the existing file.

    2. Launch SDK from Vivado (File -> Launch SDK), setting up the Exported location to \Zybo-Z7-20-pcam-5c-master\hw_handoff and the Workspace to \Zybo-Z7-20-pcam-5c-master\sdk.

    3. Left click on the pcam_vdma_hdmi project and then from the top menu select Project -> Build Automatically.

    4. Re-generate BSP sources for fsbl_bsp and for pcam_vdma_hdmi_bsp, by right clicking on each of these projects and selecting Re-generate BSP Sources.

    5. Left click on the pcam_vdma_hdmi project. From the top icons, select Program FPGA. Then, from the top menu, select Run -> Run -> Launch on Hardware (System Debugger).

    The Pcam 5C demo project should then work fine.

    Please let me know if you encounter any issues with this.

    Best Regards,


  17. Hello,

    I would like to make a correction to my previous statement that I didn't know of a way to reduce the size of the Pcam 5C Demo Project to fit on the Zybo Z7-10 board. Actually, there is a way to reduce the size of the design, by disabling Debug Module for the CSI-2 IP. You can perform the following steps in order to do this:

    1. Download the latest version of the Pcam 5C Demo project from, in zip format.

    2. Use the vivado library zip file (which includes the D-PHY and CSI-2 IPs) you previously downloaded from, or download it again.

    3. Unzip the two zip files, put the vivado library in its folder under the repo folder.

    4. Run the create_project.tcl script from Vivado 2017.4.

    5. In the project block diagram, double-click on the MIPI_CSI_2_RX_0 IP and deselect Debug Module. Press OK. Save the project.

    6. In the project settings, change the project device to xc7z010clg400-1, in order to match the Zybo Z7-10 board.

    7. Report IP Status -> Upgrade Selected.

    Synthesis, implementation and bitstream generation should then work fine. You should then be able to run the Pcam 5C Demo project on the Zybo Z7-10 board.

    I hope this is helpful for you. I am sorry for the initial answer on the project size.

    Best Regards,


  18. Hello,

    The Pcam 5C demo project does not fit onto the Z7-10 PL: you need a total of 18202 LUTs, and you only have 17600 on the Z7-10. In other words, at some point in the placement phase, you have 2903 available slices, while there still are 3493 slices required in order to finish placing the design.

    I don't know of any IP block you can remove/reduce in size in the demo project, in order to make it fit the Z7-10, while still keeping the project functional.

    I recommend switching to a Zybo Z7-20, where the project would fit.

    Best Regards,


  19. After following the above steps, you may still see an error during Implementation which is similar to the one you initially described. This occurs because the system-level block diagram of the demo project is no longer the project top-level.

    To fix this error, in Vivado please right-click on the system_i block-diagram item and select "Create HDL Wrapper...". Then right-click on the HDL wrapper you just created and select "Set as Top". You will then see this HDL wrapper becoming the project top-level.

    If you then rerun synthesis and implementation, they should work fine.

    We will update the IP versions in the demo project on GitHub.

    Best Regards,


  20. Hello,

    Could you try the following steps, in order, for building your Pcam 5C Vivado project?

    1. The master vivado-library branch is missing the D-PHY and CSI-2 IPs needed for the Pcam 5C demo project. Please download the d-phy vivado-library branch instead:

    2. Once you downloaded this version of the library please unzip it and copy its contents (the "if" folder, the "ip" folder, the ".gitignore" file, the "License.txt" file and the "" file) directly at the following location in your unzipped Pcam 5C Vivado project (without any additional subfolder in the path): <path to your unzipped Pcam 5C proj>\Zybo-Z7-20-pcam-5c-master\repo\vivado-library\ .

    3. Clean up the project and rerun the \Zybo-Z7-20-pcam-5c-master\proj\create_project.tcl script from Vivado.

    4. You may see an error in Vivado about the D-PHY and CSI-2 IPs being locked. To fix it, please run from Vivado: Tools -> Report -> Report IP Status. This will open a window saying the D-PHY and CSI-2 IPs need to be upgraded. Select "Upgrade Selected". Once this is finished, you should be able to correctly synthesize and implement the Pcam 5C Demo project.

    Please let me know if you encounter any other issue with the Demo Project.

    Best Regards,