Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

1S10 dev. board and MAX Freq.

Altera_Forum
Honored Contributor II
2,813 Views

Hello, 

 

I would like to know if we can increase the FMax of the board. I would like to reach the MAX frequency can support the board. How can I do it? 

 

The reference design has implemented a 50 MHz. Is that possible to increase it? 

 

Best regards 

 

Christian
0 Kudos
17 Replies
Altera_Forum
Honored Contributor II
919 Views

Yes it's a hardware change (increase the clock frequency, and re-build the NIOS with the new frequency)

0 Kudos
Altera_Forum
Honored Contributor II
919 Views

guess that wasn't enough info. 

 

Using a PLL on you're device, the input clock (50Mhz) can be scaled to many different frequencies. Don't expect something like 400MHz because that's just not possible, but 100Mhz is quite doable. 

 

G-luck
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

Thank you, 

 

I'll try to increase the PLL frequency to reach 100 MHz. 

 

Christian
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

I'm barely reaching an Fmax of 100MHz with the 1S10 (ES) NIOS development board using the "s" core, so you might want to target the "f" core if that's an option. With the 'f" core you can probably reach 125MHz easy if your surrounding logic doesn't not drag down the NIOS core. 

 

The 's' core is constricted to around 100MHz on the paths through the ALU (hardware multiply, shifting, etc....) 

 

Is there some Quartus optimization that I should try since my target is 100MHz, and I was able to make the "s" model keep up to the full one (I want to save 400LEs) 

 

Cheers
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

 

--- Quote Start ---  

originally posted by badomen@Aug 11 2004, 02:41 PM 

is there some quartus optimization that i should try since my target is 100mhz, and i was able to make the "s" model keep up to the full one (i want to save 400les) 

--- Quote End ---  

 

Turn on restructure multiplexers in analysis and synthesis settings. If it is set to 'Auto' it is probably turned off. It will save you a whole load of LE's, but there is a small risk of increasing f_max slightly (which is why it is off by default).
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

I thought increasing fmax was a typo, but it actually did improve it. Thanks you may have saved me a lot of LEs http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif  

 

Cheers
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

If you really need more fmax then /e is the way to go. The current issue of Alteras newsletter has a complete table of chips and NII cores and fmax&#39;s. 

 

They show the /e going 201MHz on Stratix II. For Stratix I they show 141MHz for /f, 130 for /s, and 144 for /e. 

 

For Cyclone I got NiosI going 140 all internal, 120 with SDRAM as data only, and 110 running out of SDRAM. 

 

Don&#39;t plan on these speeds in your real world app though. Once I added all the required peripherals to the Avalon bus (and complex firmware) I&#39;m down to 75. 

 

Ken
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

I&#39;m restricted to a system speed of 100Mhz, but I also need high performance out of the NIOS as well. I found very little difference in speed between the &#39;s&#39; and &#39;f&#39; models due to the nature of the design. The &#39;s&#39; model was used as an attempt to reduce the logic size since the overall design will be very busy. Right now the design is pretty light, just a NIOS and some surrounding logic, so I expected at least 110Mhz from the &#39;s&#39; core seeing as it&#39;s "suppose" to have an Fmax of 130 on stratix. 

 

So it&#39;s not that I want to increase my system past 100MHz, I just don&#39;t like the idea of a light system having an fmax of 100Mhz since it&#39;s going into a much larger design. This is also the first time I&#39;ve ever seen a NIOS having a low fmax due to internal logic (usually it&#39;s when you attach other hardware to the NIOS or put it into a busy design).
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

what are the few other little peripherals? 

If any are off chip, it will slow things down. 

What have you configured into the niosII? any debug?
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

It&#39;s a pretty plain system right now. Everything is contained within the FPGA. So their is logic added to do communication across the custom hardware interface, and I added a hardware divider that I created (since that core doesn&#39;t have one). The divider on it&#39;s own has an Fmax of 150, and after the timing analysis is complete is not part of any critical paths when used by the NIOS. The critical paths are all in the ALU, and I&#39;m finding the logic in the messages having names like MUL, pipeline, shift (if I remember correctly, I&#39;m re-building right now so that I can get the exact names). Also to rule out my divider, I&#39;ve put it into the &#39;f&#39; core and turned off the Altera provided one, and my timing and processing performance is not affected at all. 

 

When I use the &#39;f&#39; core then the NIOS is simply restricted in fmax by some of my surrounding logic (and the fmax is what I&#39;m expecting). So I have a perfectly fine system using the &#39;f&#39; core, but it&#39;s a bit overkill for what I need, and I&#39;m able to get almost identical performance out of the &#39;s&#39; core due to my design. But I&#39;m not going to trust my design running on the &#39;s&#39; core until that fmax is at least 10Mhz higher since this design will be dropped into a much larger design.  

 

Is it possible that the ALU has problems targetting the 1S10ES device? (NIOS development board). 

 

Thank-you for you&#39;re help and any additional insight you may have. 

 

*Edit* I&#39;ve been using the minimal debug capabilities to download code. I&#39;m starting a build without it to see what happens.
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

Sounds like you&#39;re progressing along just fine. If you are seeing > 100 with the /s core in Stratix (1s10es) and the critical path reports are in the ALU, you&#39;re pretty close to achieving maximum performance. The /f should give you some additional speed. 

 

Also, try the following quartus options to improve performance slightly (lengthens compile time) - in Quartus fitter settings, turn on the following: 

 

- Perform physical synthesis for combinational logic 

- Perform register duplication 

- Perform register retiming 

 

Also make sure you&#39;re not using the "fast fit" option (great for speedy compiles when you don&#39;t need max f-max, but should not be used for best clock speed). 

 

Finally, to extract the last few percent performance, try the Quartus "design space explorer" tool. This is an automated way of re-compiling a design over and over using different fitting tweaks to see which one is the best.
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

I removed the debug hardware and I see an increase. Now the rest of the optimization can be done to the surrounding hardware. The Fmax I&#39;m seeing now is what I&#39;m used to seeing with NIOS I (we are evaluating NIOS II to see if we can shrink our logic and retain the previous performance). 

 

So things are looking up for me since my savings using the &#39;s&#39; core (or to a lesser extent the &#39;f&#39; core) are quite good. 

 

Thank-you for the help Jesse and Kerri.
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

My experience is that the bad paths tend to be those to and from the hardware multiplier. 

The multiplier is also used for shifts and rotates. As an experiment, you can 

remove the hardware multiplier and see the effect on your Fmax. 

 

Just hand-edit your system PTF file and change remove_hardware_multipler from "0" to "1" 

and then regenerate your system in SOPC Builder. Make sure you aren&#39;t running SOPC builder 

while you hand-edit the system PTF. You should also recompile your application so that 

the compiler won&#39;t try to use multiply instructions. Your shift and rotate instructions will take more 

cycles now because they don&#39;t have the hardware multipler anymore to accelerate them. 

 

Here&#39;s another trick to reduce LE usage and sometimes increase Fmax. 

It uses a little known setting in Quartus. 

Go into the "More Settings" tab of the Fitter options and look for the register packing option. 

It defaults to auto. Change it to something like "Minimize with chains". 

I&#39;m doing this at home from memory so I might not have the names exact. 

 

What this option does is to make Quartus more aggressive about combining unrelated 

registers and lookup-tables into the same LE. They don&#39;t turn it on by default because 

it tends to use more routing resources. It is very rare for Stratix parts to run out of 

routing resources so you should be okay. 

 

BTW, my experiments during development suggested that the Nios II/s and Nios II/f have similar Fmax characteristics. 

Sounds like you are finding contrary results. I&#39;d like to know about your configuration if 

this is true.
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

 

--- Quote Start ---  

originally posted by badomen@Aug 11 2004, 05:02 PM 

i thought increasing fmax was a typo 

--- Quote End ---  

 

It was a typo. It increases f_max sometimes but occasionally decreases it, which is why it&#39;s disabled by default. 

 

Also, before people spend ages looking for this option, it is new in Quartus II 4.1.
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

Ya, it helped my NIOS a bit, but hindered the surrounding hardware so I&#39;m back to square one. Thanks to James, I had no idea that the multiplier could be removed (I kinda need it though so maybe it could become a custom instruction). What you said is pretty much what I&#39;m seeing in terms of critical paths. Unfortunately some of the Quartus tweaks are unavailable to me since I&#39;m just using the webpack for now (we got the NIOS II in the mail, but have not renewed yet since I&#39;m finding out if it&#39;s worth it or not). 

 

My configuration is some surrounding hardware attached to the custom interface, NIOS II/s, 512B of cache, and I added a hardware divider that I created (I probably re-invented the wheel of the one that comes with the NIOS). I&#39;ve done a build without my divider to see if that helps and it&#39;s not much of a change in fmax at all (probably just resources got moved around and the fmax was affected by that). 

 

When I go with the II/f core and ditch my divider (and just use the one supplied by altera), my fmax goes up around 20%. The results that you were seeing is what I would have expected as well. I&#39;m sure my fmax would have gone up more then 20% but some of my surrounding hardware limits the system to it&#39;s own fmax as expected. 

 

So I&#39;ll give you&#39;re suggestion of removing the multiplier a try (still not sure why it would be used for shift/roll functionality, I guess since it has it built in and doesn&#39;t require extra LEs). 

 

Cheers
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

shift_rotate_in_submodule is currently turned off, any know the affects of turning this on? 

 

Cheers
0 Kudos
Altera_Forum
Honored Contributor II
919 Views

Turning off the hardware multiply seem to help things fairly well. I still still a few paths that are pretty low which are localized to a few result bits, shift_rot, and av_ld_done. The destination of these are mostly the pipeline flush.

0 Kudos
Reply