artvvb

Hi @connoisseur_de_mimi
An STP file for the enclosure kit is now available here: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse_Z7_Enclosure.stp
Thanks,
Arthur

I've been for two years in the same exact situation as you were. I checked some custom IPs tutorials to learn how to communicate with the AXI bus, and with the Vivado integrated tool turns out to be pretty easy.
I've created a tutorial showing an example of the exact same thing you wanted: PS-PL USART data exchange. Check it on my GitHub.
I hope that it will help other people, and I'm open to accept PR of code improvements from people more experienced that I am.

I solved the problem. It wasnt any timing issue what so ever. The traitor was the packetizer all along. Basically my rvalid signal was delayed by one clock cycle which caused all the problems.
Sorry for wasting your time, it was a very simple mistake, but still thank you for responding!

I dug a little deeper using the dpmutil library. SyzygyReadDNAHeader() called in dpmutilFEnum() reads 0xFF only from EEPROM. I2C communication appears to work correctly, at least the I2C HAL does not return any errors, which should also mean the firmware is running correctly. I have read out the EEPROM with avrdude, it matches the file created by syzygy-tools.py. Lots of dead ends.
What solved this issue in the end was patching the syzygy-tools.py script to work with my programmer and using it to flash the Pod MCUs 😩 Vio is now set as defined in the dna json.

Found it. It was an inconsistency (or rather a consistency in this case) in the definitions. main() was pulling the DMA_ID for the scope rather than the awg. The projects use the same definition identifier for their respective DMA_IDs. 
Changing 
#define DMA_ID XPAR_ZMODAWG_PORTB_MM2SDMATRANSFER_0_AXI_DMA_0_DEVICE_ID -> #define DMA_ID_AWG XPAR_ZMODAWG_PORTB_MM2SDMATRANSFER_0_AXI_DMA_0_DEVICE_ID and editing the file accordingly did the trick. 

looking good, thanks :)

Hi @connoisseur_de_mimi
See example code here: https://github.com/Digilent/Eclypse-Z7-SW/blob/b42fb15a8ab4c52a38db2c15918cd7263e84f65e/src/calibration_reader/src/main.c
Thanks,
Arthur

Thanks @artvvb, it worked! I also added the Pullup constraint, as suggested (its not needed as my I2C devices have pullups built in, but it should make debugging easier).
 
my constraints are now
 

Hi @connoisseur_de_mimi
Yeah, the issue is likely that it's a differential buffer.
Manual instantiation of the IO buffers isn't necessary. You could just make the entire I2C interface external and constrain the two pins. Vivado will automatically add tristate buffers as appropriate. You can also add pullups through an XDC file with "pullup true" constraints like here:
Also, port names for the below screenshot would be "IIC_0_scl_io" and "IIC_0_sda_io".

Thanks,
Arthur

Responded over in another thread, but the gist is that we're unfortunately not able to help much. The SiFive repo that the guide depends on was archived back in 2021, so they may not be much help either. 
 

Hi @shreyash
Unfortunately, we can't provide much support for this guide anymore - the sources it clones from were archived as read-only by the third party who created it some time ago. We're looking at either taking down the guide or strengthening the warnings at the top so that others don't run into the same issues you have.
Apologies,
Arthur

@artvvb
I have the hardware design loaded and a software SOC testing now.  Exciting progress!  Getting an XAXIDMA_Device_To_DMA transfer length failure now!  Progress!
Thanks for your continuing support, sorry to have two separate threads on my issues going.

Hi @silverdiamond
The following should work:
WaveForms' Script Editor is based on JavaScript.
Thanks,
Arthur

Posted a project  and some constraints over here: 
 
Just means that you are trying to use the same location constraint for two different pins - more incorrect constraints. sADC_Sclk_1 should probably be at AA13.

Hi @Xband
The AXI port names in the list of unplaced ports make me think that you have the wrong top module. Please make sure that the block design HDL wrapper is set as the top module for your project in the sources pane. It should be bolded, like here:

You can change which module is selected as the top module by right-clicking on the one you want and selecting "Set as Top".
Thanks,
Arthur

Please review your HDL wrapper module, and confirm that all port names in XDCs match names in the wrapper. The issue with the github source that you linked is that it is intended to be used with a script that reproduces part of a block design, which also finds and replaces all of the "nameHier" text in the XDC. It then has the correct names of ports, since it creates the ports in a known way, as long as ports aren't manually renamed later.

Thanks,
Arthur

Hi @silverdiamond
These measurements are all briefly described in the in-app help's Scope -> Measurements section (5.11): 
Some can also be seen as example code by "editing" predefined measurements in the app:

For limiting max/min within a microsecond, careful placement of the acquisition window by setting your trigger, time position, and time base could work, making it so that the acquisition only covers a single period of the input signal is reasonable.
The 3.20.27 beta's measurement "extent" feature also lets you limit the data measurements are applied to within a larger acquisition: 
 
Alternatively, filtering out the low-frequency signals could work:

Thanks,
Arthur

@artvvb
I think the problem my have popped up because I started the project first adding the Zynq processor and other parts, running the connection automation along the way, then later I added the "clock wizard" ip.  Could have been the root of the issue.  I went back and rebuilt the project again and seem to have avoided this problem so far.  Thanks again for your help.

Also, a tangentially related issue I've run into before, the default "single-ended clock capable pin" input source parameter of the clock wizard can lead to critical warnings in the implementation methodology reports. Using "global buffer" ought to resolve it. More info here: https://support.xilinx.com/s/question/0D52E00006hpQy0SAE/ps-clock-as-pll-input?language=en_US
Thanks,
Arthur
 

In addition to project settings, I believe Tools -> Settings -> IP Defaults will add the IP repo to all future projects. Might not always be desired, if you're managing multiple versions of the same repo or IPs, but it's an option.

Ok, 
I think I have it now, added it through "settings" rather than the "+" icon.  Don't recall this process previously, Thanks for your help. 
 
 

Oh yes that explains a lot.
Thank you very much, that was very helpful.

Hi @Stefanski881
Per the calibration section (on page nine) of the ZmodScopeController manual:
This means that data passed through into the DMA is effectively the full 16 bits, instead of just the lowest 14. The same shift is applied in test mode, where the incoming raw data is padded with two zero bits at the bottom of the vector. In both cases, this means the 14 bits you want to treat as the sample are the top 14 of your `number` variable, not the bottom 14.
There's a baremetal application in this under construction demo that uses dpmutil to read calibration coefficients out of DNA, which may also be helpful: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming
Thanks,
Arthur

I deleted that entire section in the constraints file and re-typed it and then it was OK.
Thanks for your help.
Scott

Thank you for the support!
Cheers,
Ricky