cmod S7 zyboZ7 connection

[Pier]

could i connect a CMOD s7 to a zyboZ7 and program the cmod to write on zyboz7 ddr memory?

[elodg]

Sure you can, but probably not worth the hassle. You need to implement and inter-board protocol on both ends and use the Pmod as a physical medium. Probably UART or SPI, to keep things simple. Then on the Zybo Z7 implement a SPI to AXI adapter to get tot the memory.

[Pier]

Thx a lot for your answer,

what would you think the fastest way to send from cmod to zybo an array of 1024 16bits value?

[elodg]

Sending it to a PC first then to the ZyboZ7 through two USB-UART connections.

[Pier]

mmmm.. thx, but the pc is not invited at the party,

it's a romantic cmod zybo meeting

[elodg]

UART over Pmod.

[zygot]

4 hours ago, elodg said:

UART over Pmod.

I agree with all of @elodg's comments so far but I'd clarify that you want to use the PMOD pins, not a PMOD. The ZYBO has very limited GPIO. I'd probably choose to define my own 8-bit protocol using the pins on 2 standard PMODs and 16 of the CMOD pins. This would add a bit of ZYNQ programming overhead. Any way you go, it's going to involve some coding exercises. It all depends on your specifications for the data interface. You did start with the specifications, right?

I use a lot of UARTs in my designs and 921600 is an easy baud rate to implement without any flow control. Again, it's a matter of your specification requirements.

Be aware the in the Vivado SDK the UART Console window only supports up to 115200 baud, but I rarely use it for designs with UARTs.

[Pier]

Thanks a lot for your comment,

as my design will need lot of trigonometric calculus, i thought to use cmod to take care of all external inputs readings, some calculus, data formatting before sending all data to zybo.

the requirement would be send array of 1024 16bits values and 14 channels of 16bits values at 22.05khz   but

 

https://forums.xilinx.com/t5/Vivado-TCL-Community/trim-and-stretch-function-implementation/m-p/1124607

i have to figure out how to implement this function to have a precise idea of real requirements.

if i can implement this serially a big numb is gone.

Pls help!

thx for your time

 

[zygot]

If your UART is running at a reasonable 921600 baud continuously, then you get a data transfer rate of about 90K bytes/s of data going both ways. At an update rate of 22KHz that doesn't allow for very many words of data per update period. This would suggest that a UART isn't a good option. Even if you implement, say 8 UARTs, you're in trouble.

I looked at your links and you don't provide enough information for me to understand exactly what it is that you need to do. It sounds like a student problem to solve using ingenuity rather than a brute force approach.

I can say, based on the sketchy impression that I have, based on very limited details, that your choice of implementation platform is likely a key to success. I suppose that you like the ZYNQ because of its NEON floating point extension for your doing lots of 'trigonometric calculations'.  In the old days of microprocessors there were no floating point and the processors ran at 2 MHz on a good day. I was doing embedded hardware and software for years before even a hard 8x8 multiplier showed up embedded processors. That doesn't mean the we didn't do applications using lots of complicated mathematical on-the-fly calculations... just not using brute force methods.

Your description of the problem is lacking crucial elements that need to be defined.

[Pier]

34 minutes ago, zygot said:

I looked at your links and you don't provide enough information for me to understand exactly what it is that you need to do. It sounds like a student problem to solve using ingenuity rather than a brute force approach.

Well,

Some details: in this design every operator will do calculations with an array of 1024 16bits values before passing the array to the next operator.

(It's easy to go over 20000 ticks considering all operations and external inputs)

Final wavetable array is used by a wavetable oscillator.

 

so problem shown in the video is :

given an array of 1024 16bits values, fill a new array of 1024 16bits values containing 2 cycles of original array, 3 cycles, 4 cycles and so on

 it does not sound like a student problem to me, but i'm not an expert of course, pls help me code that

 

[zygot]

@Pier,

Yeah, perhaps I'm just dense but your descriptions just aren't helping. You say that the original 1K array can be anything, including just noise, then you talk about using that data to create up to 10 new 1K arrays of data based on cycles....

Noise isn't cyclic. Even if you were doing spectral estimation you aren't saying anything about how the new data is created. Somewhere else you mention 14 channels of something unspecified. I am not able to comprehend what it is that you want to do. What is the source of the data? Where does the computed data go?

All I'm getting is that every 45 microseconds you need to read 2048 bytes of data and write up to 20480 bytes of processed data that eventually through some unspecified interface ends with a 16-bit DAC reading a LUT. Is that accurate? And your current plan is to use the CMOD for the output DAC interface and the ZYBO for data processing?

I didn't see any video, just your exchange on the Xilinix user's forum. It didn't seem that anyone reading that description quite grasped the problem either.

[Pier]

Thx zygot,

they grasped it.. the function i'm talking about is implemented in Touchdesigner and Houdini and etc.

i tried to explain it better, thx, anyway,

 

24 minutes ago, zygot said:

Noise isn't cyclic

I know, but it doesn't matter, if i reapet it now is cyclic noise.  ? or just a waveform

 

 

[zygot]

In my last post I was trying to ignore your algorithmic requirements. As I see it you need to write about 45 MB/s and read 1/10th that continuously. I don't see much chance of that happening using the platforms that you mentioned. 45 us is not much processing time for the ZYNQ PS to acquire from memory, process and write to memory that much data on the fly. Even a PS USB2.0 port will have a hard time keeping up.

[Pier]

Thx a lot for your evaluation