What the frequency of Zedboard read the GPIO?

[GreatGBL]

Hello, my project has a high frequency operation on the GPIO on the Zedboard. I want to ask how the Zedborad (Or general FPGA board)  read the value from the GPIO ? On the every rising clock? I found that the Zedboard system clock is 667MHz, it means in 1 second the Zedborad read the GPIO value 667M times? Thanks for your help.

[GreatGBL]

1 hour ago, D@n said:

Yeah, ahm, the Zedboard can't handle an input data rate from GPIO of 667MHz into the PS.  Look through that specification, the fastest they promised was 1MHz.  I think I even commented about that number that your mileage might vary--getting that speed can be very difficult to accomplish.

Common problems associated with what you are trying to do are 1) metastability, solved via proper clock domain crossings, 2) clock synchronization, interrupts, cache measurements, DDR3 slow-downs, and more.  Other problems might include transmission loss, interference over the cable, I could go on.  This is one of the reasons people purchase boards with programming logic (PL) instead of PS.  Either way, you aren't working on an easy problem.  I very much doubt that you will be able to fix this problem with forum requests for help and assistance--it's just too hard.

Just for the sake of the record, can you tell me in MHz terms what speeds you are trying to achieve between these two boards?

Dan

P.S. If you want to chat about this in real time, look me up on freenode on the "#digilent-fpga" channel.

 

 

 

That is the flow diagram of my project

 

The ADC has 10Mhz as system clock, if the Basys3 needs receive 24bits data, it need 24*(1/10M) second. Then the Basys3 send the data to Zedboard immediately. So the frequency between two  board is 1/(24*(1/10M))=416,667 Hz = 0.416MHz. .Theoretically if the frequency of Zedboard transmites the data from PL to PS Is 1MHz, it is enough. While there are approximately 20% data lost.  I dont know the reason.

 

 

Ok, I find a method, How aboult add a FIFO buffer in the BASYS3.  the FIFO can save 8 data inside. When the Zedboard has been read one data, the read SP of FIFO buffer add 1, but how the Basys3 know the Zedboard has been read is a problem...

[D@n]

Yeah, ahm, the Zedboard can't handle an input data rate from GPIO of 667MHz into the PS.  Look through that specification, the fastest they promised was 1MHz.  I think I even commented about that number that your mileage might vary--getting that speed can be very difficult to accomplish.

Common problems associated with what you are trying to do are 1) metastability, solved via proper clock domain crossings, 2) clock synchronization, interrupts, cache measurements, DDR3 slow-downs, and more.  Other problems might include transmission loss, interference over the cable, I could go on.  This is one of the reasons people purchase boards with programming logic (PL) instead of PS.  Either way, you aren't working on an easy problem.  I very much doubt that you will be able to fix this problem with forum requests for help and assistance--it's just too hard.

Just for the sake of the record, can you tell me in MHz terms what speeds you are trying to achieve between these two boards?

Dan

P.S. If you want to chat about this in real time, look me up on freenode on the "#digilent-fpga" channel.

[GreatGBL]

10 hours ago, D@n said:

@GreatGBL,

The GPIO speed depends upon how you are reading GPIO's.  Are you trying to read them within the processing side (PS, or Arm) of the Zynq, or the programming logic (PL, or FPGA) side? 

The difference is very important as, on the PS side, your software will need to spend a clock to read an instruction, a clock to read the GPIO, a clock to store the GPIO value, a clock to update the pointer to the GPIO value to store, a clock to check whether enough values have been written, etc, etc.  Making matters worse, these routines are often encapsulated into procedures to handle GPIO, and these will suffer pipeline stalls as the subroutine jump will often cost you a cache miss, several pipeline stalls, etc.  In other words, doing this within the PS side is *very* inefficient, and the actual speed you will achieve is hard to describe in a data sheet.    Sometimes you can use the statements of others (I got this to work  at xMbps), but even then it is often application dependent.  A processor clock speed of 667 MHz should really be thought of as only 667 MIPS (Meaningless Indicator of Processor Speed) --- there's just too much going on to draw conclusions from just the one number.  In the auto industry, they say "Your mileage might vary."

I think I recall from other posts you've made, that you are trying to interface two video streams tot he Zedboard.  If that's the case, you'd want to use the PL side of the Zynq, 'cause I doubt the PS side would ever keep up.

Answering your question then leads you to the AC switching Spec for the Zynq, found here.  There it specifies that PS GPIO can only go up to 1MHz, however it looks like 200MHz would be a (fairly) comfortable speed to use for the PL.  The chip may be able to go faster depending upon how you build your circuit.  Indeed, it might not even go this fast--depending upon other parts of your camera to Zynq interface: i.e., whether you are using serial vs parallel communications, etc.

Hope this helps, but if not ... you might find the answer is *very* application dependent, meaning that it depends upon the hardware you are using and interfacing to, how you are doing that interface, etc.  The high speed end really isn't a simple number that can be quoted independent of everything else.

Dan

 

 

4

Yes, I used the PS layer to read the GPIO (at Pmod) on the Zeboard.  I use another FPGA board, Basys3, connect to the Zedboard Pmod pins.  The Basys3 will send approximate 1024*8*4*24 bits to the Zedboard at every 240 rising of the system clock (Note the Basys3 system clock frequency is 100MHz). Then, I checked the Zedboard, it successfully receive only 800*8*4*24 bits, in other words, there are 20% of data lost.. On the other hand, sometime it can successfully receive 1000*8*4*24 bits so there are only 3% data lost, but it only happen few times.....

 

Then, a enable signal never be received by Zedobard, it sent by Basys3 at every 240 rising of the system clock, but the duration of it only a 1 clock of the Basys3 system clock, I guess the reason of why Zedboard can't receive that is the duration of the signal is small. But Theoretically , If Zedboard has 667Mhz to read the GPIO, it should to receive that.

So what should I do to reduce the lost data percentage? 20% is too lager really for my project..

Thanks for your help,

Kind regards,

GreatGBL

[D@n]

@GreatGBL,

The GPIO speed depends upon how you are reading GPIO's.  Are you trying to read them within the processing side (PS, or Arm) of the Zynq, or the programming logic (PL, or FPGA) side? 

The difference is very important as, on the PS side, your software will need to spend a clock to read an instruction, a clock to read the GPIO, a clock to store the GPIO value, a clock to update the pointer to the GPIO value to store, a clock to check whether enough values have been written, etc, etc.  Making matters worse, these routines are often encapsulated into procedures to handle GPIO, and these will suffer pipeline stalls as the subroutine jump will often cost you a cache miss, several pipeline stalls, etc.  In other words, doing this within the PS side is *very* inefficient, and the actual speed you will achieve is hard to describe in a data sheet.    Sometimes you can use the statements of others (I got this to work  at xMbps), but even then it is often application dependent.  A processor clock speed of 667 MHz should really be thought of as only 667 MIPS (Meaningless Indicator of Processor Speed) --- there's just too much going on to draw conclusions from just the one number.  In the auto industry, they say "Your mileage might vary."

I think I recall from other posts you've made, that you are trying to interface two video streams tot he Zedboard.  If that's the case, you'd want to use the PL side of the Zynq, 'cause I doubt the PS side would ever keep up.

Answering your question then leads you to the AC switching Spec for the Zynq, found here.  There it specifies that PS GPIO can only go up to 1MHz, however it looks like 200MHz would be a (fairly) comfortable speed to use for the PL.  The chip may be able to go faster depending upon how you build your circuit.  Indeed, it might not even go this fast--depending upon other parts of your camera to Zynq interface: i.e., whether you are using serial vs parallel communications, etc.

Hope this helps, but if not ... you might find the answer is *very* application dependent, meaning that it depends upon the hardware you are using and interfacing to, how you are doing that interface, etc.  The high speed end really isn't a simple number that can be quoted independent of everything else.

Dan