Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21333 Discussions

EP3C120F780 FPGA Device max speed

Altera_Forum
Honored Contributor II
1,644 Views

I have a Cyclone III Development Board with the EP3C120F780C7N FPGA part# . The datasheet specs the part at 437.5 MHz for the "Clock Tree Performance". 

 

The development board has 50 MHz and 125 MHz oscillators available. When I use the 50 MHz oscillator and synthesize my clock through a PLL Megafunction I cannot get my designs to run with stability above 100 MHz. Even if I use the 125 MHz oscillator some parts of my design are not working even at 125 MHz. 

 

Is 100 MHz truly my limit with this device?
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
694 Views

 

--- Quote Start ---  

I have a Cyclone III Development Board with the EP3C120F780C7N FPGA part# . The datasheet specs the part at 437.5 MHz for the "Clock Tree Performance". 

 

Is 100 MHz truly my limit with this device? 

--- Quote End ---  

 

 

The performance you can achieve on any FPGA design is directly related to the depth of logic and the utilization of the device. 

 

If you have deep logic, your FMAX can be improved by pipelining the design. 

 

If your design is using a high percentage of the resources, timing suffers, because routing usually needs to increase to connected the LE's.  

 

I have several EP3C designs completed, and I regularly achieve design speeds of 160 MHz and above. However, I have some designs that have difficulty achieving 80 MHz, due to the above two issues. 

 

For the first case, just looking at the failing path, and adding register pipeline stages where possible to split the deep logic can solve the issue. 

 

For the second, going to a larger device, or using floor-planing to limit where timing critical logic can be placed is the way to go. 

 

Other issues that will show up as timing violations is multiple clock domain crossings. Make sure you properly cross the domains with synchronizers to avoid metastability, then you may be able to false path these errors. 

 

Regards, 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
694 Views

Thanks for the reply. OK, so I'm at least in the ballpark for the performance I should expect to get. I did not realize that there was such an art to laying out a design. The 437.5 MHz number in the data sheet is a bit misleading at face value. 

 

I don't know what clock domain crossings are...I'm running everything off of the one clock generated by the PLL. Is this something that I may encounter?
0 Kudos
Altera_Forum
Honored Contributor II
694 Views

Since you are running everything off of one clock, you should safe there. The timing tool will correct all setup and hold issues for that clock domain. 

 

When you have more than one system clock, when-ever data crosses from one clock to the other clock, timing closure is very difficult for the tool, especially if the two clocks are asynchronous from each other. Let's say you have a 25.000 MHz clock and a 25.100 MHz clock. Any data crossing from one clock to the other can not be guaranteed to always meet setup/hold requirements of the register in the other domain, because the timing between the two registers is also skewed and walking from clock edge to clock edge. 

 

When setup and hold is violated, a you don't really know what happens. Sometimes, you'll capture the data as expected, some times you'll miss the data, and sometimes you'll get into a state called metastability, that is neither a logic one or a logic zero for some period of time. 

 

To avoid this, any data crossing between two clock domains should use special synchronizing logic to insure that the data is capture properly, at least with a high MTBF, so that the system will perform as expected. This is especially important when transferring a bus across a clock domain. You always want to hold the data in the source clock domain, synchronize a single bit of control data across the clock domain then use that signal to capture the bus in the target domain. This is basically what happens when you use the FIFO megawizard functions from Altera, but it can be done without a fifo as well. 

 

But that's really a different discussion.. :) 

 

As far as the speed numbers being a bit misleading, I agree, but since they can not know what your target design is, they use some basic model that gives them a high number. It's probably listed somewhere as a sub-note on the 437.5 MHz number on how they determined that speed. 

 

It may be just a register to register transfer, or the maximum performance for a simple counter or some other minimalistic design. 

 

Pete
0 Kudos
Altera_Forum
Honored Contributor II
694 Views

 

--- Quote Start ---  

The 437.5 MHz number in the data sheet is a bit misleading at face value. 

--- Quote End ---  

 

It can be misleading if you don't think how synchronous logic works. If you read more than the title page of the Cyclone hardware manual, you'll find some information to estimate the achievable speed for different designs. Previous FPGA manuals, e.g. of Cyclone II have also speed overview tables for typical design entities, they are unfortunately missing with Cyclone III.
0 Kudos
Reply