artvvb

@artvvb Assigning to unconnected pins has solved my problem.

Assigning random pins should work. I'd suggest using pins from another Pmod port, if you have any that are unused/free.

Yes, as long as you are using make external, you need to use two AD1 modules to control two Pmod AD1s, and you are able to constrain the each module's ports to the pins of a single Pmod port. The Pmod pins you use for each port in this case are arbitrary - you can map whatever module port to whatever physical location using the XDC - so top row and bottom row is doable.
Thanks,
Arthur

Hey Udayan,
No, a single Pmod AD1 controller only controls a single Pmod AD1. Assuming you use the board file interface, it must be connected to the top row of the Pmod port the module is attached to - due to limitations of the Pmod IP when its used in this way, the lower four pins must be constrained, but are not attached to any logic in the FPGA.
Thanks,
Arthur

Hi @Eran Zeavi
If you haven't already, you should install the board files for the Zybo Z7: Instructions are here.
The board files include a Zynq preset which is applied to the PS IP during Block Automation, which includes all of the relevant DDR configuration settings.
Which examples are you trying to use? In general for PL-to-DDR configuration, you will need some kind of DMA controller. The DMA Audio and HDMI demos for the Zybo Z7 implement several different Xilinx DMA IP, and include Zynq PS configurations.
Thanks,
Arthur

This was caused was a ufw firewall configuration change to occurred during a Ubuntu OS upgrade. tftp server ufw configuration solve the problem.

Over two years ago, I authored a driver for the Pmod SSD that uses minimal CPU overhead. You can find it in the Project Vault. I titled it MuxSSD. Regards, Tim S.
 

To keep the topic contained in one place, I'm going to address this question over here: 
Thanks!
Arthur
 

Hi @mahinay,
Welcome to the forums.
Digilent doesn't provide a Pmod IP core for the Pmod SSD. That said, there should be examples out there which will fit your needs. What are you trying to practice? The route you take will differ pretty strongly depending on whether you want to get data from the Zynq processor on the ZC702 onto the display, or if you are trying to get data from elsewhere in the Zynq PL onto the display.
Thanks,
Arthur
 
 

@artvvbI'd like to make a suggestion - If you ever redesign this board, please use a different cooling fan. The one in use now - has a strange tendency to brush up against equipment and personnel. This is annoying to say the least and possibly dangerous. Thank you.
 
Udayan Mallik

Hey Arthur,
I really appreciate  your response. This is exactly what I was looking for! Thank you! Like I say, I am pretty new and I haven't attempted anything with the Microblaze yet. Super stoked about the technology though! Thanks again!

Hey Lowell, welcome to the forums!
Storing your project in flash can differ depending on what kind of project it is. Are you using Microblaze, and if so, are you using external memory (as in, not the on-chip BRAM)?
If not-MicroBlaze, there are some steps presented in this reference page that should be helpful: https://digilent.com/reference/learn/programmable-logic/tutorials/cmod-a7-programming-guide/start
The screenshots are fairly old, but the process used to flash the board should largely remain the same in even the newest versions of Vivado.
Thanks,
Arthur

Did you simulate?
Sounds like something like a counter is not properly initialized and it takes about 10 minutes for it to roll over.

@artvvb Thank you very much for the link. My fan is up and running. Not sure why I did not scroll down and check myself. I expected to see a struct with  a pointer that acquires some of the parameters. Thank you again. My system now operates safely with a Fan up top.

Hi @Udayan Mallik
The code block below is a snippet of the comment header that goes with the function definition of dpmutilSetFanConfig in dpmutil.c (pulled from here: https://github.com/Digilent/dpmutil/blob/master/dpmutil.c).
More information about the specific capabilities of the Eclypse's PMCU can be found in the PMCU specification: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse-PMCU-Specification-Public.pdf
** Description: ** Modify one or more field of the Platform MCU (PMCU) ** FAN_n_CONFIGURATION register. The FAN_n_CONFIGURATION register is ** used to specify the settings of the associated fan. This may include ** the enable state of the fan, the fan's speed, and the associated ** temperature probe. Please note that not all fan ports support ** enable/disable, fixed speed control, or automatic speed control ** (temperature based). Changes to a FAN_n_CONFIGURATION register ** will be restricted to the be within the supported capabilities of ** the port and take effect immediately after the register is written. ** Additionally, the FAN configuration is written to EEPROM and will ** restored each time the PMCU is reset or power cycled. ** ** The "fanid <0...3>" parameter must be used to specify ID of the ** fan configuration to be modified. ** ** The "enable <fTrue,fFalse>" parameter can be used to enable or disable the ** associated fan. ** ** The "speed <0...3>" parameter can be used to specify the speed of ** the associated fan. Please note that not all fans support this ** functionality and some ports that do support this functionality ** may not support automatic fan speed control. ** 0 - minimum ** 1 - medium ** 2 - maximum ** 3 - auto ** ** The "-probe <0...4>" parameter can be used to specify the ** temperature probe associated with a fan if that fan supports automatic ** speed control. ** 0 - none ** 1...4 - probe[1...4]  
Thanks,
Arthur

Hi @orenderj
Found the bug that is causing the issues you are seeing. The register that the levels are sent to hardware through was written, however, an additional register write which is required to trigger the "UserRegisters" module to pass that register value through its CDC handshake mechanism to the trigger generator was omitted, causing the levels at the trigger detector to never be updated from the default 0. To correct this, UserRegisters_IssueApStart should be called after the WriteReg call. Here's a snippet from the corrected LevelTriggerAcquisition with the surrounding context:
// Configure the trigger TriggerSetPosition (TrigPtr, BufferLength, TriggerPosition); TriggerSetEnable (TrigPtr, TrigEnable); u32 Levels = ((u32)(Ch1Level) << 16) | (Ch2Level); UserRegisters_WriteReg(LevelTriggerPtr->BaseAddr, USER_REGISTERS_OUTPUT0_REG_OFFSET, Levels); UserRegisters_IssueApStart(LevelTriggerPtr); // ADD THIS LINE AxiStreamSourceMonitorSetSelect(TrafficGenPtr, SWITCH_SOURCE_SCOPE); To answer the question about the data format:
The stream data consists of two signed 16-bit values, one for each channel. Channel 1 is bits 31:16 and Channel 2 is bits 15:0. These are the output of the calibration modules in the ZmodScopeController. The 14-bit ADC samples are padded prior to going through the calibration module.
The trigger levels are encoded the same way as the data: essentially 14-bit twos-complement ADC data, padded up two bits.
There's some more information on the calibration scheme in the ZmodScopeController's User Guide, pages 6-10. Figure three may be particularly helpful.
This function, which I've quickly tested with a 0.5V level trigger, should let you calculate the raw levels:
u16 VoltsToTriggerLevel (float data, u8 resolution, u8 gain) { #define IDEAL_RANGE_ADC_LOW 25.0f #define IDEAL_RANGE_ADC_HIGH 1.0f float vMax = gain ? IDEAL_RANGE_ADC_HIGH : IDEAL_RANGE_ADC_LOW; return (u16) (data * (float)(1 << (resolution - 1)) / vMax) << (16 - resolution); } It's effectively the inverse of the data to raw floating point volt conversion functions, plus a two bit pad.
Thanks,
Arthur

https://fpgaer.tech/?p=447

Thanks for the info...now i can build the project

Thanks @artvvb. I actually found that using the WaveForms SDK and the Eclypse Z7 that I can capture the samples that I need to bring into a custom C# application, but I'd really like to be able to do the same thing with your trigger example code as I can modify the block design quite easily and insert some signal processing modules along the way. The trigger code is very useful in theory, but I havent been able to get it to work. The manual trigger always fires even if I'm basically at 0v and have a terminator on the SMA with a rising edge trigger way above my signal. If you expect some bug fixes soon, I'll continue using the SDK to get me going, but if not, I'll take your information from the post above and try and get things working. Thanks again!

The AD9648 has a pipelined architecture by design. That's how it works.

Generally this type of ADC is continuously sampled so latency is only an issue with respect to the first sample, and then only if there's some absolute time event in your system design that sample need to be referenced to. The piplined delay is fixed. A for phase delay, systems often have elements in the analog conditioning circuitry that have a bigger effect on phase lag and are frequency dependent. This is part of the design analysis for every specific use case when using an ADC.

You should get the AD9648 datasheet before trying to use the device even if you are relying on a packaged FPGA HW scheme.

I'm not understanding your perceived association between gain and phase latency.

I've never looked into how exactly to do it, but Vivado's simulator should also be able to be controlled through TCL, and based on these posts, the simulator can be invoked separately from Vivado entirely through the xsim command.

This is what we ended up with and it seems to work in our Jenkins pipeline
# Run with the following command line for the 3eg # vivado2022 -mode batch -source mta_build.tcl -tclargs mta_3eg # or for the 5ev board use the following command # vivado2022 -mode batch -source mta_build.tcl -tclargs mta_5ev # if { $argc != 1 } { puts "This script requires one argument for the board you are building" } else { open_project [lindex $argv 0].xpr make_wrapper -files [get_files [lindex $argv 0].bd] -top -import launch_runs synth_1 wait_on_run synth_1 launch_runs impl_1 -to_step write_bitstream wait_on_run impl_1 write_hw_platform -fixed -include_bit -force -file [lindex $argv 0].xsa } Now if we could only add some tests

Hi @Eminem
Welcome to the Forums!
Here are a couple of good blog posts on this exact topic:
https://www.starwaredesign.com/index.php/blog/63-fpga-meets-devops-xilinx-vivado-and-git https://www.starwaredesign.com/index.php/blog/64-fpga-meets-devops-xilinx-vivado-and-jenkins-with-docker Running build scripts written in TCL from the command line via Vivado's batch mode is the way to go. The first post above discusses this topic in some detail.
The checkout script in digilent-vivado-scripts also optionally builds the checked out project, but that requires following the same file structure as Digilent's Vivado projects on Github. We haven't used this with Jenkins or Docker before, so I couldn't comment on how easy that would be to use as a starting point.
Thanks,
Arthur

Hi @suung33
You need to modify the data being sent to the device. Currently, in the posted code, a 132-byte-long buffer filled with the sequence 0,1,2,3,... is being sent. You should refer to the I2C Serial Interface Communication section of the MCP4725 datasheet to determine what bytes you should be sending (https://www.microchip.com/en-us/product/MCP4725). Both the buffer contents should be changed to match whatever you need to send to the device and the buffer size argument passed the XIicPs_MasterSendPolled function should be modified to match the number of bytes you want to send. For example, from an initial skim of the datasheet, a general call reset should be able to be issued with the following snippet (though I haven't tested it), which sends two bytes, a 0x0 followed by a 0x6.
u8 SendBuf[2]; SendBuf[0] = 0; SendBuf[1] = 0x6; XIicPs_MasterSendPolled(&Iic, SendBuf, 2, IIC_SLAVE_ADDR); Arduino sources can't be run directly on the Zybo, but you might use those projects to figure out what bytes you should be sending and receiving.
Thanks,
Arthur

thank you; that solve my problem; just could not see the part.,
rt