Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

What is the processing speed limitation of Cyclone IV E with speed grade C7?

Hi everyone,

Does anyone know, what is the maximum processing speed of Cyclone IV E (with speed grade of C7) within the FPGA fabric?

Knowing that PLL on Cyclone IV E can generate up to 1.3 GHz, does it mean the FPGA fabric will process up to that speed too?

And where can i find out more on these information? I am trying to receive and process high speed LVDS data streams from a high speed and high resolution ADC for ultrasound application.

Thanks in advance!

Regards,

Michael

15 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Michael,

    --- Quote Start ---

    I just happens to see your latest post when i check back all my previous post, i am not sure why i didn't get a notification via email.

    Anyway, thanks for all these information, its very helpful.

    --- Quote End ---

    Hopefully you'll read this reply :)

    --- Quote Start ---

    This is our college senior design project, i am majoring in Electrical engineering in a bachelor degree, but our professor just choose an extremely challenging project for us, personally i haven't have much experience on FPGA, we only have 2 classes with CPLD.

    This AFE5808 from TI will be used on a pig's heart for researching in Shearwave Dispersion Ultrasound Vibrometry (SDUV) imaging.

    --- Quote End ---

    Perhaps your professor gave you a hard project because he felt you were up to the challenge. Lets prove him right.

    --- Quote Start ---

    I have a new question, and this is quite critical and urgent, i would be really grateful if someone shed some light for me.... alright here's the scenario;

    A LVDS stream(12 bit * 60 MHz = 720Mbps) is coming to my FPGA from an ADC, since it is in 12 bits and it is transmitted throught 2 wires (which means 1 channel? am i right), how can i ultilize the ALTLVDS_RX megacore provided by Altera (since the maximum deserialization factor selectable is just 10) to do deserialization ?? should i use 2 channel(in the parameterized core settings) and input HSMC_RX_D_P[0] to one of the pin while, HSMC_RX_D_N[0] to the other input?? or is there a trick of doing this? If i have to write my own shift register code, how should i address differential signalling in verilog? should i just consider " HSMC_RX_D_P[0]" and never have to consider "HSMC_RX_D_N[0]", since they are just 180 degree out of phase or the inverse of each other.

    --- Quote End ---

    Your ADC will be sampling at 12-bits at 60MHz clock and then serializing the data to give you a 720Mbps serial data stream (which is within the 740Mbps LVDS limit of your FPGA). The altlvds_rx component can be configured for deserialization rates of 1 through 10. You can use any of these rates to capture your data, and then inside the FPGA you have to reconstruct the LVDS received bits to your ADC 12-bit data. The logical choice (minimum effort) given that demux-by-12 does not exist is to use demux-by-6. This means that internal to your FPGA, you will be getting 6-bits at 120MHz. You can write that to a dual-ported RAM, where the RAM is configured with one side written at 6-bits at 120MHz clock, and the other side read as 12-bits at 60MHz.

    While in theory this sounds simple, it will be complicated by one fact. Where in the 720Mbps serial stream does the receiver start serial-to-parallel conversion of the data? If the receiver is not aligned to start 'unpacking' bits in the order the ADC 'packed' them, then you have a problem. The LVDS receivers operate with an external 'frame clock', where this frame clock is used to tell the receiver where a data frame starts and ends. In your case, since the 60MHz ADC serializes the 12-bits into a 720Mbps stream, the 60MHz clock is the frame clock, the question will be what is the timing of the 60MHz clock relative to the data. To understand what I am talking about, go and setup a modelsim simulation with; a fake ADC that serializes data to 720Mbps (eg., your simulation can write 12-bit data to dual ported RAM, that gets read at 6-bits, and then sent to an altlvds_tx channel), and then capture that data. You can put in delays on the frame clock and see how your received data gets messed up.

    Even if your 60MHz data is aligned perfectly with your 12-bit ADC data, you'll have to work out how to pack your 6-bit data into the recovered ADC 12-bit samples. One way I can think of is that your 120MHz receive clock can use the 60MHz frame clock, eg., the 12-bit data will be 2 x 6-bits of data, and the first 6-bit value will occur when the frame clock is high, and the second when the frame clock is low (relative to the 120MHz receive clock). Actually, with this scheme, you would not use dual-ported RAM with different port widths to capture data, you'd just use a 12-bit receive register clocked at 120MHz; the frame clock would be used as a low/high 6-bit enable, and at every high clock (after a complete 12-bits was updated in the register), you would write to a 12-bit dual-clock FIFO. The FIFO would be clocked at 120MHz on one side, and be written every second clock with 12-bits, while the other side of the FIFO would be clocked at 60MHz and read every clock.

    If the ADC has a test-pattern mode, then you can always consider using that to initialize the system.

    Try to figure this out. If it gets too overwhelming, let me know, and if I have time, I can write an example in VHDL.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Dave,

    --- Quote Start ---

    Even if your 60MHz data is aligned perfectly with your 12-bit ADC data, you'll have to work out how to pack your 6-bit data into the recovered ADC 12-bit samples. One way I can think of is that your 120MHz receive clock can use the 60MHz frame clock, eg., the 12-bit data will be 2 x 6-bits of data, and the first 6-bit value will occur when the frame clock is high, and the second when the frame clock is low (relative to the 120MHz receive clock). Actually, with this scheme, you would not use dual-ported RAM with different port widths to capture data, you'd just use a 12-bit receive register clocked at 120MHz; the frame clock would be used as a low/high 6-bit enable, and at every high clock (after a complete 12-bits was updated in the register), you would write to a 12-bit dual-clock FIFO. The FIFO would be clocked at 120MHz on one side, and be written every second clock with 12-bits, while the other side of the FIFO would be clocked at 60MHz and read every clock.

    --- Quote End ---

    My eyes just went numb from this point, anyway. Thank you very much, this is very helpful. I will try my best to understand it, and if i get stuck again, i will post some questions here.

    Thanks!

    Michael
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Michael,

    --- Quote Start ---

    My eyes just went numb from this point

    --- Quote End ---

    Ha!

    A picture is worth a thousand words ...

    http://www.ovro.caltech.edu/~dwh/carma_board/digitizer_tests.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/digitizer_tests.pdf)

    p64: the top trace is the 'frame clock' the bottom is serialized data.

    p71 and on explain the receiver deserializer and framing.

    Try to redraw the figures on p73 and 74 for your case. For example, for every period of your 60MHz frame clock, you diagrams would have 12-bits of serialized data. However, since the LVDS receiver would be configured in 6-bit mode, you would get a parallel output word every half frame clock (my diagrams don't show the parallel data inside the FPGA, but yours could).

    Once you can draw a figure, your eyes will become less numb :)

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Hi Michael,

    Ha!

    A picture is worth a thousand words ...

    http://www.ovro.caltech.edu/~dwh/carma_board/digitizer_tests.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/digitizer_tests.pdf)

    p64: the top trace is the 'frame clock' the bottom is serialized data.

    p71 and on explain the receiver deserializer and framing.

    Try to redraw the figures on p73 and 74 for your case. For example, for every period of your 60MHz frame clock, you diagrams would have 12-bits of serialized data. However, since the LVDS receiver would be configured in 6-bit mode, you would get a parallel output word every half frame clock (my diagrams don't show the parallel data inside the FPGA, but yours could).

    Once you can draw a figure, your eyes will become less numb :)

    Cheers,

    Dave

    --- Quote End ---

    Wow.... that CARMA board is really impressive.. you just gave me a thousand more words to read. I will try to read your material as my main reading material for the rest of my summer holiday, and hope to understand maybe 20-40 % of it.

    Thanks for your help, i really appreciate it.:-P

    Michael
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Wow.... that CARMA board is really impressive..

    --- Quote End ---

    Thanks :)

    --- Quote Start ---

    I will try to read your material as my main reading material for the rest of my summer holiday, and hope to understand maybe 20-40 % of it.

    --- Quote End ---

    Make sure to both read and write some code. If you can understand how to create a simulation that generates and captures your serial data, you will have a good chance of getting it working in hardware. Don't forget that with a loopback from TX-to-RX your 'simulation' can also be tested in hardware.

    --- Quote Start ---

    Thanks for your help, i really appreciate it.:-P

    --- Quote End ---

    No problem! Keep asking questions. Welcome to engineering, its a lot of fun!

    Cheers,

    Dave