Highest CPU-Frequency for Cyclone I

[Altera_Forum]

Good morning. I`m new in this forum. 

 I hope u will be able to answer my questions.  The first should be rather trivial.  What is the highest frequncy clock for a cyclone I?  In my analysis were 75 MHz the highest mark.  Are higher possible? Why, if not???  Looking forward to read your answers...

[Altera_Forum]

Hi, 

 if you are talking about NIOSII it depends mostly on the number of peripherals you add. I am having the same Problem at the moment, a small system with only SDRAM or SRAM controller and some custom logic gets to about 100MHz. If I add more peripherals, the system gets slower, especially with the other tristate avalon devices of the Devboard(1c20) and the DMA controller. Then fmax drops to about 60 MHz, which I am not really happy with.  Has someone else any experience on possible fmax of NIOS systems on Cyclone?

[Altera_Forum]

http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/biggrin.gif funny, exactly my configuration. 

 Besides I use a DMA-Controller. Maybe thatswhy the processor wasn`t able to work with 100 MHz. 87,5 MHz didn`t work as well.  Does anybody know, if on Altera`s HP exists a listing, that describes the maximum Frequencies?

[Altera_Forum]

It&#39;s impossible to obtain such a listing, becdause Fmax depends on so many factors, from the peripherals you include, to configuration options, to placement of pins, to PLL usage etc. etc... there is no physical way they could tabulate all this data.

[Altera_Forum]

The comments here are pretty accurate. There is one feature in SOPC Builder that can help. Certain slave interfaces will slow things down substantially -- the tri-state bridge if many masters connect to it, and many slaves are driven by it, as an example. You could place this on its own clock domain (a separate, slower clock input will be generated from the SOPC Builder system that you must drive), and keep things like the CPU, SDRAM, and faster peripherals on the fast clock domain. 

 The clock crossing logic isn&#39;t the most optimal at the moment, though, so this approach makes sense only for peripherals you can live with slower access to (flash memory is a great example). Also, the clock crossing generates additional logic for each clock domain crossing.. for this reason, its best to be selective with its use.. however, in these circumstances such as the above, it can help you maintain a significantly higher CPU frequency.

[Altera_Forum]

--- Quote Start ---  originally posted by jesse@Mar 7 2006, 06:27 PM the comments here are pretty accurate. there is one feature in sopc builder that can help. certain slave interfaces will slow things down substantially -- the tri-state bridge if many masters connect to it, and many slaves are driven by it, as an example. you could place this on its own clock domain (a separate, slower clock input will be generated from the sopc builder system that you must drive), and keep things like the cpu, sdram, and faster peripherals on the fast clock domain.  the clock crossing logic isn&#39;t the most optimal at the moment, though, so this approach makes sense only for peripherals you can live with slower access to (flash memory is a great example). also, the clock crossing generates additional logic for each clock domain crossing.. for this reason, its best to be selective with its use.. however, in these circumstances such as the above, it can help you maintain a significantly higher cpu frequency. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13195)  --- quote end ---    --- Quote End ---     So the SOPC Builder generates the clock crossing logic on its own? Thanks for the tip, I&#39;ll give this a try.