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.

[jpeyron]

Hi @GreatGBL,

I'm not sure where the data loss is occuring but if you could post your basys 3 project and I will try to get it to work on the Zedboard for you. Also what version of Vivado are you using?

cheers,

Jon

[D@n]

@GreatGBL,

Glad to hear you got it going.  Let me know if you ever do need help getting a real communications system running between two boards.    I might just happen to know a thing or two on the topic ...

Dan

[jpeyron]

Hi @GreatGBL,

Glad to hear you were able to get your project running with an exceptable amount of data loss!

cheers,

Jon

[GreatGBL]

On 2017/3/4 at 5:34 PM, D@n said:

@GreatGBL,

The LFSR doesn't solve the issues, it reveals them.

As for a solution, I think I wrote earlier that, "Sadder still is that a "good" communications system between two FPGA boards could easily be a master's project in it's own right, and I think you've got another research topic in mind."  Were this my own project, I would get rid of the clock line and embed the clock and the data in the same line--but that's just me.

Dan

 

Hello, I solve it, the problem is not the communication...

The Microphone output the negative voltage and the ADC can't convert it, so all the negative voltage data lost, and at that time I did not know that..

After support +5V DC voltage on each microphone, the negative voltage issue solved, and I test the data transmission again, only 3% data lost , it is acceptable.

Thanks for your help during those time !!!!

[D@n]

@GreatGBL,

The LFSR doesn't solve the issues, it reveals them.

As for a solution, I think I wrote earlier that, "Sadder still is that a "good" communications system between two FPGA boards could easily be a master's project in it's own right, and I think you've got another research topic in mind."  Were this my own project, I would get rid of the clock line and embed the clock and the data in the same line--but that's just me.

Dan

[GreatGBL]

16 minutes ago, D@n said:

@GreatGBL,

Look at the probability of two bits in a sequence being identical.  You want that probability to be 1/2--equally random.

How are you recovering your clock?  Have you looked into the possibility that the clock arrives earlier or later than the data?  At low speeds this doesn't matter, but at higher speeds this phenomena becomes more difficult to deal with.

Dan

 

 

But how LFSR solve those issues? LFSR just generate a sequence of Pseudo-random code

[D@n]

@GreatGBL,

Look at the probability of two bits in a sequence being identical.  You want that probability to be 1/2--equally random.

How are you recovering your clock?  Have you looked into the possibility that the clock arrives earlier or later than the data?  At low speeds this doesn't matter, but at higher speeds this phenomena becomes more difficult to deal with.

Dan

[GreatGBL]

47 minutes ago, D@n said:

@GreatGBL,

I don't recall mentioning Gray codes.  I was discussing scramblers, and in particular scramblers implemented via linear feedback shift registers.

Dan

 

 

 

Hello, I want to know why I can't use the counter in the test, my understand is that a bit of counter may be chaned in the communication.

For example , a 8-bit counter send

0000 0000

0000 0001

0000 0010

0000 0011

0000 0100  (4)

While a noise interfere the MSB, the receiver got   1000 0100   (132)

and I will say, Aha, there are  132-4 = 128 data lost

 

It is like that issue ?

 

 

[GreatGBL]

3 minutes ago, D@n said:

@GreatGBL,

I don't recall mentioning Gray codes.  I was discussing scramblers, and in particular scramblers implemented via linear feedback shift registers.

Dan

 

OK, thanks for your help, I go to using LFSR test it again. Sorry for my ignorance in high frequency communication

[D@n]

@GreatGBL,

I don't recall mentioning Gray codes.  I was discussing scramblers, and in particular scramblers implemented via linear feedback shift registers.

Dan

[GreatGBL]

On 2017/3/3 at 3:37 AM, D@n said:

@GreatGBL,

Yes, counters are easier to read and generate.  They are easier to measure the success or failure of.  They also produce a misleading measure, biasing your error rate so that the bit error rate you measure is lower than the actual error rate of the channel.  (Incidentally, you quantified a number of errors above, not a "bit error rate" or even a "bit error ratio"--as a result, your measures don't mean much--you never told us how many bits you sent in total.  Further, word error rates are separate and different from bit error rate, and are more difficult to compare between systems.)

Wikipedia has a discussion regarding scramblers here.

What your counter is not telling you is ... how well can you read/decode high frequency bit transitions?  You'd like to create a high speed link and measure its performance.  A counter that is 16 bits of zero followed by 8 bits of something else is spending 2/3rds of its time (15/(15+8)) sending a low frequency signal.  It's only rarely measuring any higher speed transitions.  This is why I said that your actual bit error rate will probably be higher than your estimate.  This is probably also why you didn't see a great difference between your measures.

Moving on, communications channels are often measured in terms of bit error rates.  Every real communication system, such as radios, hard drives and networks devices, have bit error rates.  The job of the engineer is to design a communications system with a "low enough" bit error rate for his/her purpose.  Two things you may wish to look into for this purpose are forward error encoders/decoders (parity is a simple example) and checksum's of which my favorite are the CRCs.  The former will help you recover from an error you might come across, the latter will help you recognize any errors that weren't recovered.

Sadly, this is probably more information than you are looking for to communicate your data from one device to another.  Sadder still is that a "good" communications system between two FPGA boards could easily be a master's project in it's own right, and I think you've got another research topic in mind.

Dan

 

OK, your means using Gray code is much better ? I go to try

[D@n]

@GreatGBL,

Yes, counters are easier to read and generate.  They are easier to measure the success or failure of.  They also produce a misleading measure, biasing your error rate so that the bit error rate you measure is lower than the actual error rate of the channel.  (Incidentally, you quantified a number of errors above, not a "bit error rate" or even a "bit error ratio"--as a result, your measures don't mean much--you never told us how many bits you sent in total.  Further, word error rates are separate and different from bit error rate, and are more difficult to compare between systems.)

Wikipedia has a discussion regarding scramblers here.

What your counter is not telling you is ... how well can you read/decode high frequency bit transitions?  You'd like to create a high speed link and measure its performance.  A counter that is 16 bits of zero followed by 8 bits of something else is spending 2/3rds of its time (15/(15+8)) sending a low frequency signal.  It's only rarely measuring any higher speed transitions.  This is why I said that your actual bit error rate will probably be higher than your estimate.  This is probably also why you didn't see a great difference between your measures.

Moving on, communications channels are often measured in terms of bit error rates.  Every real communication system, such as radios, hard drives and networks devices, have bit error rates.  The job of the engineer is to design a communications system with a "low enough" bit error rate for his/her purpose.  Two things you may wish to look into for this purpose are forward error encoders/decoders (parity is a simple example) and checksum's of which my favorite are the CRCs.  The former will help you recover from an error you might come across, the latter will help you recognize any errors that weren't recovered.

Sadly, this is probably more information than you are looking for to communicate your data from one device to another.  Sadder still is that a "good" communications system between two FPGA boards could easily be a master's project in it's own right, and I think you've got another research topic in mind.

Dan

[GreatGBL]

3 hours ago, D@n said:

@GreatGBL,

Much as I hate to say it, counters really don't make good test signals--there's just too many constant bits in them to really tell if you have received them properly.  Worse, the polynomial you chose (and commented out) will only ever generate a repeating 24'bit string of ... what looks like all ones--again, not very random.  The end result of this is that your test is undercounting the errors you are receiving.

What you need is a primitive polynomial, something like the code attached.  You may need to regenerate the sequence on to compare against it, or alternatively apply the annihilating polynomial to determine how good your BER is.

Dan

 

vtest.v

 

 

Thanks for your code, but I dont understand why a counter is not a good test signal? It is much readable and easy to generate, the value of counter send to Zedboard by binary and send to PC by decimal.

[GreatGBL]

3 hours ago, jpeyron said:

Hi @GreatGBL,

I'm not sure where the data loss is occuring but if you could post your basys 3 project and I will try to get it to work on the Zedboard for you. Also what version of Vivado are you using?

cheers,

Jon

2

Vivado 2016.1

 

See the counter example, the received data should be 0,1,2,3,4,5,6....

 

[D@n]

@GreatGBL,

Much as I hate to say it, counters really don't make good test signals--there's just too many constant bits in them to really tell if you have received them properly.  Worse, the polynomial you chose (and commented out) will only ever generate a repeating 24'bit string of ... what looks like all ones--again, not very random.  The end result of this is that your test is undercounting the errors you are receiving.

What you need is a primitive polynomial, something like the code attached.  You may need to regenerate the sequence on to compare against it, or alternatively apply the annihilating polynomial to determine how good your BER is.

Dan

 

vtest.v

[GreatGBL]

On 2017/2/28 at 2:44 AM, D@n said:

You might wish to compare against this board:

https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-es2-g.html

Dan

 

 

 

 

 

 

Hello, I tested it today. For easy read the data, I use the counter to generate the data, and transmit it to Zedboard in 100MHZ, 50MHZ and 25MHZ respectively. 

The Zedboard read the GPIO continually, save it into DDR3 memory if the current data is not same as the previous one.

Then, the Zedboard use UART way  transmit all the data to PC, because I used DD3 memory, so there is no any data lost by UART.

The result shows below..

 

Ideal: Zedboard will receive :

1 2 3 4 5 6 7 8 9 .....

 

 100MHZ : Sorry I forgot to copy the raw data , but I remember there are 128 data lost between each received data.

 50MHz:

-Read the data from memory, numbers: 135776 -- 21  83  145  222  269  331  392  453  515  577  638  702  761  822  884  945  1007

There are approximatly 62 data lost between each received data.

 

25MHZ:

--Read the data from memory, numbers: 101621 -- 8406774  8390342  8390390  8406774  8390342  8406774

There are approximatly 48 data lost between each received data.

 

[D@n]

You might wish to compare against this board:

https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-es2-g.html

Dan

[GreatGBL]

41 minutes ago, D@n said:

Sure!  And shame on Vivado if it gives you a hassle! 

Dan

 

BTW

 

 

 

[D@n]

Sure!  And shame on Vivado if it gives you a hassle! 

Dan

[GreatGBL]

25 minutes ago, D@n said:

Why not program in SystemVerilog on the ZedBoard?

Dan

 

 

 

Because when I first touch the Zedboard, I build the IP core and AXI interface, I found there are using Verilog language. It is ok to mix the Verilog language and SystemVerilog language together and run on Zedboard ?

But it doesn't matter, I will go to try LFSR to check whether data  losts. The other problem is the data lost on the channel between ADC and Basys3 due to other reason.

[GreatGBL]

2 minutes ago, D@n said:

But to your question, why is data arriving corrupted, the way to answer this question is to send a known and often pseudo-random pattern.  Linear Feedback Shift Registers (LFSRs) can often be used for this purpose with only a minimum amount of logic required.  Place some type of scope within the ZedBoard PS that communicates with the PL, and trigger that scope off of the first erroneous bit.  Then dig into the circumstances before and after that bit to find your problem.

Dan

 

Ok, it is a good idea, I will test it during this week!

[D@n]

Why not program in SystemVerilog on the ZedBoard?

Dan

[D@n]

But to your question, why is data arriving corrupted, the way to answer this question is to send a known and often pseudo-random pattern.  Linear Feedback Shift Registers (LFSRs) can often be used for this purpose with only a minimum amount of logic required.  Place some type of scope within the ZedBoard PS that communicates with the PL, and trigger that scope off of the first erroneous bit.  Then dig into the circumstances before and after that bit to find your problem.

Dan

[GreatGBL]

2 minutes ago, D@n said:

As I undestand your problem, the ADC is a PMod, right?  If so ... why do you need the Basys3 at all?  Why not just use one of the PMods on the Zedboard?

Dan

 

AHa, because the Zedboard using Verilog language while I only know the SystemVerilog language which using on Basys3, I can't write complex code like SPI protocol on the Verilog language.

[D@n]

As I undestand your problem, the ADC is a PMod, right?  If so ... why do you need the Basys3 at all?  Why not just use one of the PMods on the Zedboard?

Dan