JColvin

Hi @Mathias
The instructions are long mostly because they are written to be fairly verbose and (ideally) clear.
Vitis should not be that big to install; or at least when I use the self-extracting web installer and only leave board options that I need checked, the final disk installation size of both Vivado and Vitis 2021.1 for me is just shy of 70 GB. Makes me yearn for the less than 15 GB size that 2015.4 was to be sure, but that's neither here nor there.
I asked another co-worker to make a DDR demo and they're hoping to get it completed in the next couple of weeks (in between all of their other tasks and making sure the documentation/tutorial aspect is clean).
Let me know if you have any questions.
Thanks,
JColvin

I would probably recommend that you reach out to your computer manufacturer for support on this topic.
Thanks,
JColvin

The device node-locked licenses are perpetual on the machine that they are installed on but only allow 1 year of updates. That is, if you use the voucher for Vivado 2020.x then you can also use it for any new versions up to 1 year from when you initially use it. You can use Vivado 2020.x for as long as your PC lives. The licenses seem to work with previous tool versions as well.

Hi @AML,
I have moved your question to a more appropriate section of the forum.
Thanks,
JColvin

Hello,
I'll be honest in saying that I've read through this thread a few times now, but I don't understand how the breakdown in communication happened. I do not think it is my place to decide who is right or wrong or who started what, nor is a random forum thread on the internet the place to do it; we're all adults who know they can learn more things regarding FPGAs/SoC hardware and software tools.
But I'll try to answer some of the original questions.
Not terribly difficult with the existing Xilinx functions, though I had to do some digging to find them.
These functions are the same ones used in zygot's original reply:
^This is checking for serial data being available
^This one gets gets the actual character and stores it in a user variable.
You can then do a switch case statement like zygot did to process if the user chose 'y' or 'n' or could do a if else if statement style like the one that is available on Xilinx's Github, https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/uartps/examples/xuartps_low_echo_example.c (which uses the same XUartPS_ functions from various Xilinx provided libraries) that takes a letter character received in the serial terminal and then spits back out the opposite case (upper or lower) of that same character. You could then modify either example to do some other function once it gets that that particular case/if statement. I can't find the power supply for my zedboard at the moment, but I was able to readily confirm that Xilinx's example worked as is on a blank C application project on a Arty Z7-10 (using Tera Term) that had more or less the exact same block design as created in the tutorial you linked (minus the custom IP) in Vivado/Vitis 2020.1. The caveat with the Xilinx example is that it's a blocking function in the sense that it's doing nothing else while waiting for the user input; maybe that's fine for your system, maybe not.
Thanks,
JColvin

Hi @SIB-V2,
I pulled out a Pmod ACL2 and an Analog Discovery 2 and was able to get the existing Pmod ACL2 example with WaveForms (under Protocol -> SPI tab -> Custom tab -> Pmod ACL2 example) working on the first try with using the same wire setup that you show in your picture in this specific post (https://forum.digilentinc.com/topic/19237-waveforms-with-accelerometer/?do=findComment&comment=52066, though this post shows that you are attempting to use the Pmod ACL code in the Sensor tab rather than the Pmod ACL2 code in the Custom tab). The example as it's currently structured only runs through a single iteration rather than providing multiple pieces of data over time. I will also concede that the measured temperate is confusing (it is thankfully not 2 degrees Celsius in my office), but that it is because it's measuring the internal temperature of the chip with respect the environment rather than reporting absolute temperature, but I also don't plan on specifically using an accelerometer to measure absolute temperature.
I also took a look at the work spaces you attached and noticed the following things.
Direct_protocol_test -- You don't have a supplies tab open to provide a 3.3V power supply to the board and the DQ2 and DQ3 are also mapped to DIO 4 and DIO 5, respectively, which are already being used in your other pin assignments that you changed for some reason. Once you open the Supplies tab and set up a 3.3V voltage and change DQ2 and DQ3 to other DIO pins (I changed them to DIO 0 and DIO 1), the script works.
SPI_test --- You have the same issue with DQ2 and DQ3. You also use "write" with a lowercase 'w' rather than "Write" with an uppercase 'W'. Additionally you use the wrong command to read the device IDs; you use the write command '0x0A' rather than '0x0B' to read the device ID which is what the code is attempting to do. You later do the exact same thing with the second (correctly capitalized) Write function sending a write command rather than read command. Once I changed those details and added back in the lines of code that set the module into measurement mode rather than leaving it in standby mode which is the default state of the ADXL362, I started successfully receiving data though I'm not sure what data conversion you're doing for each variable, though I can tell you that you are doing it incorrectly because the ADXL362 does not provide data in the registers MSB to LSB as you are presuming it does in you calculations. The module as per the datasheet instead provides bits 7 through 0, then bits 15 through 8 of the two bytes which is why the built in sample code Attila has pointed to does some bit manipulation and rearranging.
I didn't check the logic analyzer tool that you had pulled up in this workspace.
You also have the SPI clock running at 5 kHz where as the datasheet recommends a serial clock rate between 1 MHz and 8 MHz, especially for multibyte transfers like you are doing.
SPI_test_2 --- Looking at the protocol tab, there are the same issues with DQ2 and DQ3, the lack of turning on measurement mode, slow SPI clock, and the conversion is incorrect as explained previously. Again, once I added in measurement mode to your else statement and fixed DQ2 and DQ3, I started receiving data correctly.

The script seems to work (or at least provides numbers) when I adjusted DQ2 and DQ3 in the Protocol tab to non DIO 4 and DIO5 values; by default it does not work. You can also specify the details specifically in the setup. The Power Control register bit of the script only sets up measurement and the ultralow noise mode, not the adjust the autosleep function that is mentioned in the comments. I didn't look into it much though.
SPI_test_3 --- Looking at the protocol tab, there are the same issues with DQ2 and DQ3, the lack of turning on measurement mode, slow SPI clock, and wrong conversion that you are performing. Again, once I added in measurement mode to your else statement and fixed DQ2 and DQ3, I started receiving data correctly. I didn't check the script.
SPI_test_4 --- For the protocol tab, this only needed the DQ2 and DQ3 to be fixed. I didn't look at the script tab.
SPI_test_5 --- The protocol tab is successfully reading back the 4 register values as configured. I didn't check the script tab. 
Based on my experiences though, which to be fair is only a single person with only one Pmod ACL2 to test, I think that the WaveForms software and the Analog Discovery 2 is supremely well supported by Digilent and specifically Attila.
If you have any questions or comments, please let me know.
Thanks,
JColvin

Hi @Resul,
I believe this change is implemented starting with beta version 3.16.33: https://forum.digilentinc.com/topic/8908-waveforms-beta-download/.
Let us know how this goes for you.
Thanks,
JColvin
 

HI @druiz
The detail I was looking for is that it uses a JTAG-SMT2-NC (which I found out via Xilinx's schematics for the KCU105). I have sent you a PM with some instructions.
Thanks,
JColvin

LED's are blinking and serial ports are talking!
oooooh, MAN this feels good.
 
thanks again for the help.

Including the xil_io.h header removes the error and allows me to successfully run the application. I assumed that my custom IP header contained all the necessary operations, but I traced them and there was no mention of the read/write operations. Looking at my other applications, they all include files which somehow trace to xil_io.h.

Hi @Brando Davalos,
The WaveForms SDK, which is included as part of the WaveForms software download, is what you are looking for. There are a number of examples, including Python based examples, that come as part of the installation. You can learn more about it on it's Resource Center here: https://reference.digilentinc.com/software/waveforms/waveforms-sdk/start.
If you have any specific questions about the WaveForms SDK, feel free to ask them in the Test and Measurement section of the our Forum where the engineer most familiar with the WaveForms SDK will be able to see and respond to your questions.
Thanks,
JColvin

I've resolved my issue by following those steps in this link :
https://learn.sparkfun.com/tutorials/how-to-install-ftdi-drivers/windows---in-depth

I finally found the problem!
By sending a dump command (sending d through RealTerm, which will clear the buffer on the synth) the XFM2 finally worked with the Arduino.

Hi @JColvin,
Thank you very much!! I should have looked at the schematic. I raised pin 15 voltage to 3.3V and saw full range on the 12bit value. I have a really good XADC configuration which is working well for me. I will post it tomorrow if others are interested. It converts a single channel continuously and has a data valid signal.... very simple.
Great support is why my company buys Digilent.

For the record, here is the same post with answers:
 

Hi @Ahmed Alfadhel,
Those of us at Digilent don't have any direct advice to offer regarding neural networking, but a cursory internet search yielded these two papers (link1, link2) that might be of interest to you.
Thanks,
JColvin

Hi @baricaptain,
I apologize for the delay.
The xdc files for all Digilent boards cab be found on our GitHub here: https://github.com/Digilent/digilent-xdc/.
I will make sure the manuals are appropriately updated to direct readers to the appropriate location.
Thanks,
JColvin

Hi @gigametre,
I have sent you a message.
Thanks,
JColvin

JC,
I received a new Micro USB cable and I am making progress.  I now see what I should be seeing under 'Device Manager.'   I also see that the Adept App connects.  
So, thank you very much.  It appears that my first Micro USB Cable was deficient. 
Steve

Readers of this thread (including myself) may be surprised to learn that I received a company email yesterday evening notifying me that the Genesys ZU 5EV has moved out of the prototyping phase and into the production phase.
I do not have a release date/timeline/quarter to share (despite me asking for one) or other details to share at the moment, but still wanted to give out this update. Screenshot of evidence attached as promised.  
Thanks,
JColvin
 

Hi @lukelouyu,
I guess I am a bit confused; if you are able to get the pH and EC sensor working as expected with the xadc demo that you linked (which seems to be originally designed for the Zedboard for an older version of Vivado based on the screenshots used) and getting expected voltages after doing some conversions, I'm not certain what issue you are running into; just not being able to then generate the bitstream after adding more Pmods?
I'm not certain what problem you are seeing with the Peripheral I/O pins on the Zynq block reconfiguration screenshot; from what I can see it is the same as the Digilent block configuration that I have for the Zybo Z7-20 on Vivado 2019.2. One screenshot in the Lab3 document shows disabling Timer0 for the APU, but that is already done by default in the Digilent board files for the Zybo Z7-20. I'm guessing they needed to do it in the tutorial because the tutorial creators were using a different set of board files for the Zedboard and didn't have the Zynq IP pre-configured as needed.
I don't have all of the Pmods with me while working from home to test anything, but I did the following steps to get a bitstream and successfully reporting data received by the xadc (which Pmod JA) is attached to on a serial terminal in Vivado 2019.2
Add Zynq IP to new empty block design and run block automation with board preset Double click on Zynq IP to add a second PL Fabric clock (FCLK_CLK1) at 100 MHz for the Pmod ESP32 From the board tab, add in the different Pmods to their connectors (ALS JB, AQS JC, HYGRO JD, ESP32 JE) but not clicking run connection automation. Add in XADC wizard IP. Double click on the IP to reconfigure the defaults to enable Channel Sequencer and have vauxp6, 7, 14, and 15 enabled and vp/vn disabled. Make Vauxp# and Vauxn# on the XADC wizard IP external. Run Connection Automation. Make sure to have three clock sources (master, slave, and bridge if I recall the names correctly) for both the GPIO and UART AXI interfaces on the Pmod ESP32 be set to the 100 MHz clock in the pop-up where you select which things you want to automate. I left all of the other connections to be default, but you can specify for them to use the default 50 MHz fabric clock. Validate the design, acknowledge the messages on negative DQS skews, and create a wrapper. In the sources tab, add a constraints file with the following details:
set_property -dict { PACKAGE_PIN N15   IOSTANDARD LVCMOS33 } [get_ports { vauxp14_0 }]; #IO_L21P_T3_DQS_AD14P_35 Sch=JA1_R_p           
set_property -dict { PACKAGE_PIN L14   IOSTANDARD LVCMOS33 } [get_ports { vauxp7_0 }]; #IO_L22P_T3_AD7P_35 Sch=JA2_R_P             
set_property -dict { PACKAGE_PIN K16   IOSTANDARD LVCMOS33 } [get_ports { vauxp15_0 }]; #IO_L24P_T3_AD15P_35 Sch=JA3_R_P            
set_property -dict { PACKAGE_PIN K14   IOSTANDARD LVCMOS33 } [get_ports { vauxp6_0 }]; #IO_L20P_T3_AD6P_35 Sch=JA4_R_P             
set_property -dict { PACKAGE_PIN N16   IOSTANDARD LVCMOS33 } [get_ports { vauxn14_0 }]; #IO_L21N_T3_DQS_AD14N_35 Sch=JA1_R_N        
set_property -dict { PACKAGE_PIN L15   IOSTANDARD LVCMOS33 } [get_ports { vauxn7_0 }]; #IO_L22N_T3_AD7N_35 Sch=JA2_R_N             
set_property -dict { PACKAGE_PIN J16   IOSTANDARD LVCMOS33 } [get_ports { vauxn15_0 }]; #IO_L24N_T3_AD15N_35 Sch=JA3_R_N            
set_property -dict { PACKAGE_PIN J14   IOSTANDARD LVCMOS33 } [get_ports { vauxn6_0 }]; #IO_L20N_T3_AD6N_35 Sch=JA4_R_N Generate a bitstream and export the xsa including the bitstream I kept getting various errors on the Vitis side of things with the xadc so I haven't gotten to debug those, but if you are able to reliably use the xadc code you posted, adding in other Pmods to the associated block design should in theory be more straightforward. I'll keep looking into it tomorrow.
Thanks,
JColvin

Hi @rappysaha,
I don't believe you will be able to do this as the appropriate IC's aren't loaded and the 3EG is lacking the GTH transcievers needed, as noted in the Genesys ZU Reference Manual and schematic. I have reached out to get official confirmation on this.
Thanks,
JColvin

Hi @rappysaha,
I have not heard any updates at this point in time.
I will be sure to post any updates that I hear (and have verifiable evidence for) on this thread.
Thanks,
JColvin

The latest information that I have heard is that we are hoping for a late Q1 release, though this can vary depending on a number of factors. If it's any consolation, it's a later release date than Digilent would like it to be as well.

Hello @Erosand,
I do not know when I will have time to fix the library (or I guess the single file) but I identified a few weird things that are likely resulting in problems.
The CMPS2_init() sets the global maximum variable to -32768, and the global minimum variable to 32767. This mismatch causes problems later. Global midpoint is set to 0. The CMPS2_read_XYZ() inside of the CMPS2_getHeading() then checks to see if the measured X and Y data (after already converting it into mG, so they aren't even the same units) is greater than the global maximum variable and the less than the global minimum variable. Because of bullet point 1, this (mostly likely) sets the global max and min values to be exactly the same as the measurement value. The global midpoint is set to the average of these two values, so exactly the same value. In the CMPS2_getHeading() a Reset function is performed (to get an opposite phase shift I guess) after bullet point 2 and then CMPS_read_XYZ is performed again. However, because the global max and min values have not been reset, the new measurement data is getting compared to the exact same data. I guess in theory if you continually repeated this process as the module was rotated around, you would get the max and min values for the X and Y axis, but this isn't done in the code. So the max or minimum may have changed slightly, but not both, and the global midpoint is the bifurcation of this potential small change. I might be misunderstanding the code though. In the CMPS2_getHeading() after bullet point 3, it says offset is eliminated between the two measurements, but all it does is assign the calculated offset to a temporary variable, component[i]. In the CMPS2_getHeading() after bullet point 4, it then uses these calculated offsets, rather than actual values, to compare to the global midpoint, in order to determine what quadrant and thus what equation should be used to determine the corresponding degree heading. I'll ask around to see if somebody will be able to address some of these changes.
Thanks,
JColvin