artvvb

I never thanked you for the reply, @artvvb.  Certainly appreciate it.
 

"The max rate isn't specified. You can find other users trying to get Pmods going as fast as possible"
It's hard to argue with a statement that doesn't make any assertions.

Be aware that all of the PMODs on the Basys3 are the "low speed" variety; that is they have 200 ohm series resistors between the FPGA pins and the PMOD connector pins.

If all you want to do is toggle pins at 100 MHz, yes you can do that. if you want to use such a signal to transmit information, then there's a lot more to consider.

Only the so called high speed differential PMODs have any PCB trace length matching. That's only between the _n/_p pin pairs. And no PMOD, except on n the ATLYS can do differential signalling.

None of the PMODs that I know of have length matching across all 8 pins.

Most PMODs don;t have a clock capable pin connected to any of the PMOD pins. This might be a problem for high speed interfaces.

10 MHz toggle rate is what most of Digilent's Reference Manuals suggest for the standard low speed PMOD. That's probably very conservative. I'd certainly implemented SPI interfaces using PMOD connector to external devices via a custom PCB adapter that exceed 32 MHz; on the high speed PMODs. I'm guessing from past experimentation that ~50 MHz is practical limit for useful educational work. Of course the termination on the receiving end, the quality of the transmission line from FPGA pin to receiver pin, the current drive, slew rate, etc will determine the quality of your signal. Large amounts of overshoot or undershoot will degrade performance and potentially reliability.

Basically, what I'm trying to say is that if you want a good answer to your question, then you need to ask a better question. A nebulous question invites a nebulous answer.

I suppose that what you really want to know is whether or not your design idea will work with a Basys3 PMOD connected to some external circuit. A good answer requires more information about what you are trying to do.

I looked over the current Basys3 Reference Manual and was surprised to see that it didn't mention a useful toggle rate for the PMOD connectors. Since that board is pretty old I assume that this information was scrubbed from the original manual. This seems to be consistent with the new Digilent policy of removing important information from easy access when it doesn't reflect well on the product capabilities and replace specifications with ill-defined comments that suggest something more positive.

Hi @artvvb
 
It worked on my Arty S7.
 
Thanks for your help
 
 

Looking into it. The calibration reader app expects the names to be "Zmod ADC 1410-105" and "Zmod DAC 1411-125", based on the original names of the products before a rebrand. The EEPROM contents that store the product model name must have been changed. Changing lines 23:27 and 53:57 of main.c in the calibration_reader app as follows should clear the issue, using this as the point of comparison if you've made any changes: https://github.com/Digilent/Eclypse-Z7-SW/blob/ddr-streaming/src/calibration_reader/src/main.c.
Thanks,
Arthur

Welcome to the forum!

Welcome to the forum!

Happy new year!
This question was responded to over here: 
Thanks,
Arthur

Hi @Mavitaka
Modifiable in what way? By a human tweaking amplitudes in real-time, setting amplitudes from software on a computer, or selection based on some FPGA input? The first two could potentially be accomplished via a custom waveform in the WaveForms app (see below, where the third harmonic of a wave is set to 0.3x of the original wave's amplitude) or WaveForms SDK. The last would require a custom design in Vivado potentially adapting one of the demos, which would not be trivial.
If you haven't bought hardware, you can try out the WaveForms app without it. Edit to add: Note that any WaveForms-compatible device with analog output (like AD3, which is cheaper) is capable of this, ignoring any other specifications that might be necessary for your application.
Thanks,
Arthur
 

Hi @werosic
I assume based on previous threads that you are trying to use zmodlib and the lwip echo server template project together? I assume that you've replaced zmodlib with C (not C++) sources that accomplish similar things.
Generally, the ADC sources and ethernet sources should not affect each other, except where shared resources are being accessed, or where performance concerns become a problem. I would check whether both the ADC library and the ethernet sources are initializing the GIC - the Zynq's interrupt controller, as it seems like the most likely potentially-shared system to cause an issue like this. If they both reset it and initialize it with their interrupt handlers, then the last subsystem initialized could cancel out part of the initialization of the other subsystem.
Thanks,
Arthur

Great news,
the original goal has mostly been accomplished at this point, thank you! I'm receiving data over Ethernet from the custom IP in the firmware, and better still, so far it appears correct. In main() I'm sending data once a connection is made via the accept callback.
My question now is how can I detect an active connection. The accept callback increments the connection variable, but it doesn't decrement it. So I'm wondering how to reliably detect that an active connection exists.
The way the C code works is it fills a ring buffer with data, from the IP in the firmware, and pushes that out to an active connection as long as new data exists. I'm currently looping on 3 conditions: an active connection, data available, & a state I call sending. I'm using the connection variable in the accept callback to determine if a connection is active. But, this value does seem to track disconnects.
 
err_t accept_callback(void *arg, struct tcp_pcb *newpcb, err_t err)
{
    static int connection = 1;
    xil_printf("Echo: c_pcb=%u\n\r",(u32)newpcb);
    /* set the receive callback for this connection */
    tcp_recv(newpcb, recv_callback);
    /* set the sent callback for this connection */
    tcp_sent(newpcb, sent_callback); // <- add this
    /* just use an integer number indicating the connection id as the
       callback argument */
    tcp_arg(newpcb, (void*)(UINTPTR)connection);
    /* increment for subsequent accepted connections */
    connection++;
    return ERR_OK;
}

Thank you @artvvb, with your advice I was able to successfully interface with the onboard flash.

C sources should include xil_cache.h and call Xil_DCacheInvalidateRange before accessing the memory that the IP has written into. I think what's happening is that the data written on the first pass is being cached and the cached values are being read instead of new stuff in DDR on every subsequent pass. https://github.com/Digilent/Zybo-Z7-SW/blob/c21218c91e7d6dfd2018d35932a5f0d9d38eec9a/src/Zybo-Z7-20-DMA/src/demo.c#L262 is where the audio demo invalidates cache for received data. Your base address and byte count for the call will differ. You might call this in the handler or wherever in your C source you're reading that data.

Ow wow! That did it, thanks for the easy fix! Side question, is it possible to read from DDR while within an ISR? Does it require any special consideration(s)?

I connected up a slow 200MHz scope to the custom_int signal in the block design. What I see is distorted pulse that does otherwise appear correct.
After this, I replaced the single cycle pulse by a slow 4Hz clock, the ISR appears to be working as expected now. I expected some distortion on the probe, but I don't think the interface between the Zynq/IP should be effected by this. I'm cautiously optimistic that the problem has been resolved.
I'm now attempting to merge this code with the Ethernet Example you provided. I'll follow up with you after making some progress. Thanks!

I reproduced this and I think fixed it. Below 1446 bytes, the system only actually sends a single burst, indicated by the sent_callback only being entered once per client request. Above it, multiple callbacks would occur, but some data would be lost. What seems to be happening is that submitting more data to tcp_write than fits in a single segment (typically 1500 bytes, slightly lower for a reason I'm not sure of here) maybe causes the additional data to be lost or ignored. What worked for me to fix it was to replace the tcp_sndbuf(tpcb) calls in the sent and recv callbacks with tcp_mss(tpcb), so that no more data than fits into a single segment is included in a single tcp_write call. "MSS" in the function name stands for max segment size. I've revised the code in the blog post.
Thanks!
Arthur

Excellent, got it working. Thanks for your help.

I think I've resolved my issue by following the instructions listed here:
 
https://digilent.com/reference/test-and-measurement/guides/waveforms-sdk-getting-started#:~:text=Installing the Package

Hi @Suprith
The reset button on the Arty Z7 is not directly connected to the FPGA PL. Reviewing the schematic, the reset button, connected to the PS_RST net, triggers the PS side of the chip to reset and drives a reset on the CK_RST net, which is connected to the shield header reset pin. CK_RST is also connected to PS MIO12, however, this would not allow the PS to read a reset button press, since the upstream PS_RST will be applied.
Reset signals within the FPGA can alternatively be driven by resets associated with the FCLKs.
Thanks,
Arthur

Dear Arthur.
Thanks for the reply.  I think I will complete my current project with the remaining WiFires I currently have. It is a nice product because it requires very basic programming (I use the Arduino IDE) and I have full confidence in the timing. It is also uniquely fast at 200 MHz.  Eventually I think I will bite the bullet and tackle the Raspberry Pi and its extra layers of operating system.  Thanks for the help.
Bob

Hi @jayasha
Yes, saving and processing images in software should be possible without modifications to the Vivado project.
Thanks,
Arthur
 

Hi @Suprith
The template XDC file for the Arty Z7-10 includes pin locations for the Pmod ports: https://github.com/Digilent/digilent-xdc/blob/master/Arty-Z7-10-Master.xdc. The schematics also include this information: https://files.digilent.com/resources/programmable-logic/arty-z7/arty-z7-d0-sch.PDF.
Thanks,
Arthur

Hi @Suprith
Please review section 11, Clock Sources, of the Arty Z7 reference manual. When using Zynq PS software, FCLK pins inside of the chip can be used to clock FPGA fabric. Otherwise, the 125 MHz ethernet reference clock connected to H16 can be used.
Thanks,
Arthur

Thanks Arthur, I've watched Whitney's videos and found them very good (although I don't like her cat's attitude, it's as if it doesn't care!). I'll check around and see if I can put the process together from bits and pieces of both of them.
Thanks for all you help!!
And now it's Pub time.
Cheers!!

After trying to create my own version of a hello world, I finally figured it out. I had JP5 jumper installed on QSPI vice JTAG, I want to die. 
For some reason my own hello world attempt threw me an error that was googlable enough to find the solution, but the demo version never gave me any sort of error. I'm having so much fun!

It depends on how you want to store data - if you want to grab and manipulate a frame in DDR, since the frames are already moving through DDR, this is possible with minor software changes only. You could also potentially dump image data out to an external application for further processing using UART (which would be slow) or ethernet. Writing an image from DDR to a file system, on, for example, an SD card, would also be possible - it requires having software access to the file system, which could potentially be done using additional libraries in baremetal, or by replicating the entire system using PetaLinux.
Thanks,
ARthur