Udayan Mallik

The ports you are referring to are likely interface ports, which are effectively buses made up of multiple individual ports/signals. Check your HDL wrapper file to determine the actual ports which are created for your design - I expect you will find sixteen inouts instead of two output ports, see below for an example with one interface port.
Thanks,
Arthur

It depends on your XDC file. Pin 1 of the IP/module is intended to be connected to Pin 1 of the physical pmod port (same goes for the rest of the pins, 2-4, 7-10). However, the XDC file decides what pin on the IP actually connects to what physical FPGA pin. This means you can constrain one module's pins 1-4 to pins 1-4 of JA, constrain another module's pins 1-4 to pins 7-10 of JA, and pins 7-10 of both modules to whatever other FPGA I/O is available.

@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 @Udayan Mallik,
I am not certain which exact error you are getting as I cannot see the error code in the Message console in your screenshots.
If I had to guess as what error your receiving, my guess would be that Vivado is saying that it cannot properly connect the pins 7, 8, 9, and 10 of the Pmod AD1. You can fix this by deleting the "pmod_jb" port and then right-clicking on the Pmod Out interface and choosing the Make External option.
After the interface has been made external and you make the wrapper for the project, you can find the correct names to explicitly name the Pmod pins in the .xdc by finding their names in the wrapper.v file. There are a couple of screenshots showing what I am attempting to describe in this post here:
Please let me know if you have any questions about this process.
Thanks,
JColvin

Perhaps. It all depends on your work flow, design flow and what you want to do. I'm not sure who or what you are referring to when you mention "Cores provided by the Manufacturer". If Digilent has any RGMII, SGMII to GMII cores I've not run into them. All FPGA vendors that I know of take great pains to tie their Ethernet PHY "cores" to encrypted MAC cores and their proprietary soft-processor IP. In the case of UltraScale, Xilinx obfuscates it's actual PHY implementation and embeds a "virtual" serial management interface with a pass-through to the actual physical PHY. If you want to use their Ethernet cores, you have to implement your own serial management interface and program a couple of internal core registers in order to make them work. What are you going to do when your boss tells you that starting tomorrow you'll be using programmable devices from a different vendor, and you have a week to port your designs?  Why would anyone consider this a best bet?
Sure, if you aren't using your FPGA to do anything else you can feed lots of resources to a MicroBlaze and  have fun creating and debugging a loadable executable with the SDK or Vivis. If all you want to do is be able to rebuild someone else's project or a simple application perhaps this is OK.
None of that works for me. If what you want to do is learn about Ethernet and implement an easy to use point to point full-duplex communication interface that works at a much higher bandwidth than I suggest ignoring everything that FPGA board vendors and FPGA vendors are offering you. With a bit of work you'll end up with something that doesn't have any vendor IP, uses a fraction of the FPGA resources, doesn't have any FPGA software, and ( with a bit of work ) is portable to any FPGA vendor tools. 
Sometimes free stuff is worth the price; often it end up being too expensive and not all that useful.

Hi @Udayan Mallik,
The Pmod ACL2 IP would not be able to acquire data from the Pmod AD1; while they both use the SPI protocol, the two modules have different SPI clock frequencies, registers to manipulate, and different bit lengths of data.
I would instead recommend you use the existing Pmod AD1 IP for the Pmod AD1.
Let me know if you have any questions.
Thanks
JColvin

@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

@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.

All Series 7 FPGA devices have access to the substrate temperature sensor via XDAC. For ZYNQ, getting the temperature is pretty straight-forward.

I highly recommend users of all Series 7 FPGA devices to incorporate temperature monitoring into their HW and SW designs as a matter of habit. It is possible to configure all Digilent boards ( most FPGA development boards for that matter ), heat sink or not, fan or not, with a design that will over-tax the power supply and thermal dissipation capabilities. Don't think that a fan or heat sink removes proper design tasks from your plate... they don't. Access to FPGA internal temperature and voltages were put into the Series 7 devices for a reason. Except for trivial deigns, depending on the platform, designers are responsible for managing out of spec conditions.

The Eclypse-Z7 suffers from a lot of poorly thought out SYZYGY DNA and house-keeping design decisions, the fan control being just one. Don't wait for a solution to important issues without addressing them for yourself while you wait for a convenient solution from your board vendor.

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

@artvvbI have solved this problem. I disabled the IPV6 option and used the IPV4 option instead

@artvvb
After much experimentation my lwip_echo_server routine is now operational. I can ping an Eclypse Z7 card. Since I use Vitis 2021.2 a large part of online help tends to be useless. I proceeded as follows.
 
1. To confirm that the Realtek PHY chipset can communicate with a Zynq FPGA I used the document found here https://media.digikey.com/pdf/Data Sheets/Digilent PDFs/Eclypse_Z7_HRM_Web.pdf 
2. To use lwip resources I altered the Board Support Package in Vitis.
 A. In the Platform project - Double click the Platform.spr file.
B. Click the ps7_cortex_a9->Zynq fsbl->Board Support Package Tab in the drop down menu.
C. Click on the "Modify BSP Settings ..." tab near the top of the page.
i. In the Overview tab - Select lwip211 libraries.
ii. Then click the Standalone tab.
Set the use_axieth_on_zynq to 0 (since the ZYNQ GEM will be used).
D. Click the ps7_cortex_a9->Standalone on ps7_cortex_a9_0
E. Click on the "Modify BSP Settings ..." tab near the top of the page.
i. In the Overview tab - Select lwip211 libraries.
ii. Then click the Standalone tab.
Set the use_axieth_on_zynq to 0 (since the ZYNQ GEM will be used).
 F. Create a new Application program with the lwip_server_echo option (instead of Hello World) and voila! You have ethernet connection. You can ping IP address 192.168.1.10.

MIO peripherals - the various hard cores in PS - don't require constraints unless you are routing them through the PL via EMIO. These are dedicated multiplexed input/output lines that get routed to specific pins depending on the configuration of the Zynq Processing System. That is to say, the ethernet already gets enabled when you apply the Zynq preset from the board files. This is effectively the same as how you would enable a UART connection through the USBUART bridge, the UART0 and UART1 controllers are also PS peripherals that route through MIO.
Thanks,
Arthur

You are correct. You can use the free version of the tools and there are no IP licenses required to develop for that platform.

Update for this thread. 3D models have been created for the Eclypse Z7, Zmod AWG, and Zmod Scope. They can be found at the following locations:
https://digilent.com/reference/programmable-logic/eclypse-z7/start#additional_resources
https://digilent.com/reference/zmod/scope/start#additional_resources
https://digilent.com/reference/zmod/awg/start#additional_resources
Thanks,
JColvin

C ( and C++?) are highly typed languages so it is worth learning to be precise with constants and data types to avoid unexpected errors.
In C, 2 != 2.0f != 2.0. The first is an integer, the second a single precision float and the last is double which is what C defaults without the 'f' suffix. Yes, the compiler can automatically convert in some cases but it is better to be completely explicit. For example, your code maybe working just fine but you are implicitly using double (64 bit) floating point.

Thank you for your response. I have successfully implemented a sine wave.
My equation used to be 3.9*sin(2*3.14*125*(1/100000000)*j*255) - this produces a Sine wave in Matlab (for j = 1:3138) and, if entered in google (try 3.9*sin(2*3.14*125*(1/100000000)*758*255) where j is 758 and can vary between 0:3138)
Evidently in an embedded system 1/100000000 = 0
However, since where there is a will there is always a way, changing the said number to 3.9*sin(2*3.14*125*(1/100000000.00)*j*255) does the trick (Converting the 100000000 to a 100000000.00). See image attached.
 

If you haven't yet, you could verify whether sin is the issue by checking the function calling sin by either throwing in some prints or stepping through it in the debugger.
How are you converting data from floating point to u16s to load into the transmit buffer? (edit, just noticed getSignedRawFromVolt, ought to be fine, but verifying this in the debugger may be useful)
It looks like m may not be required for C++ after all, as I ran the snippet below, successfully printing some nonzero values. This is the Xilinx AR I was referencing earlier: https://support.xilinx.com/s/article/52971
 
#include <math.h> #include <iostream> int main() { for (float i = 0.0f; i < 1.0f; i += 0.1f) { std::cout << sin(i) << std::endl; } return 0; }  

@artvvb Here it is. You are required to modify the "main" routine and the "dacRampDemo" routine as shown below.
void dacRampDemo(float offset, float amplitude, float step, uint8_t channel, uint8_t frequencyDivider, uint8_t gain)
{
    ZMODDAC1411 dacZmod(ZMOD_DAC_BASE_ADDR, DMA_DAC_BASE_ADDR, IIC_BASE_ADDR, FLASH_ADDR_DAC, DMA_DAC_IRQ);
xil_printf("Not Doing anything\n\r");
uint32_t *buf;
float val;
uint32_t valBuf_1, valBuf_2;
int16_t valRaw;
size_t length = (int)(amplitude/step) << 2;
int i;
if (length > ((1<<14) - 1))
{
// limit the length to maximum buffer size (1<<14 - 1)
length = ((1<<14) - 1);
// adjust step
step = amplitude/(length>>2);
}
buf = dacZmod.allocChannelsBuffer(length);
dacZmod.setOutputSampleFrequencyDivider(frequencyDivider);
dacZmod.setGain(channel, gain);
dacZmod.setGain(channel-1, gain);
i = 0;
// ramp up
for(val = -amplitude; val < amplitude; val += step)
{
    valRaw = dacZmod.getSignedRawFromVolt(val + offset, gain);
    valBuf_1 = dacZmod.arrangeChannelData(channel, valRaw);
    valBuf_2 = dacZmod.arrangeChannelData(channel-1, valRaw);
    buf[i++] = (valBuf_1<<16) | (valBuf_2>>16);
}
// ramp down
for(val = amplitude; val > -amplitude; val -= step)
{
    valRaw = dacZmod.getSignedRawFromVolt(val + offset, gain);
    valBuf_1 = dacZmod.arrangeChannelData(channel, valRaw);
    valBuf_2 = dacZmod.arrangeChannelData(channel-1, valRaw);
    buf[i++] = (valBuf_1<<16) | (valBuf_2>>16);
}
// send data to DAC and start the instrument
dacZmod.setData(buf, length);
dacZmod.start();
dacZmod.freeChannelsBuffer(buf, length);
}
int main()
{
    init_platform();
    xil_printf("Hello Eclypse Z7!\n\r");
    //xil_printf("Testing ADC ZMOD...\n\r");     // COMMENTED
    //adcDemo(0, 0, TRANSFER_LEN);            // COMMENTED
    xil_printf("Testing DAC ZMOD...\n\r");
    dacRampDemo(-0.05, 3.90, 0.005, 1, 255, 1);
    cleanup_platform();
    return 0;
}

I successfully imported your design to 2021.2 I also managed to create my own design using tools made available on github. Thank you.