It feels more redundant and bloated than ever. Every time you open a component, it has to refresh the entire "Component List" even if you didn't change anything! Why update the WHOLE list? And what is with the stupid 'knight rider' blue bar going back and forth all the time? Why does it have to validate my system every time I launch SOPC builder? Doesn't it get validated when it's generated? What then is the purpose of Analyzing the HDL file every time I open my component, too?? I have a Pentium 4 3 GHz with 2GB of RAM and it feels slower than ever to use.

I got a tip from Altera tech support that basically confirms that the new SOPC Builder interface sucks and 'things will be fixed in 7.2' Yeah right. Anyway, if you want to use the old style while still remaining in 7.1, add this to your Windows environment variables: SOPC_BUILDER_PREVIEW with a value of 0

Not only is the interface worse, we have confirmed bugs that prevent it from working properly. Things that work with Nios in 6.1 do NOT work in 7.1 I am going back to 6.1 and staying there until I have a darn good reason to upgrade.

rjackal, I can tell you are pretty frustrated, I was too till I dug around here are a couple of things that might help you out : The reason that you are seeing a slow up in speed is probably because SOPC Builder is looking and validating some components that you have that are considered legacy. If you update your components to follow the tcl flow, your SOPC Builder should actually be significantly faster than it has ever been. Have you noticed that you now have a save button etc ... that's becuase the underlying structure if I understand this correctly has gone from perl to java ... Here is a quick explaaination of the old componet style and what I think the tool is doing, you probably have some componnets that if you look in their directories have ptf extentions. Those need to supported so they must run the perl stuff translate into tcl stuff and then run the underlying java. The perl extra stuff is killing you ... Change your stuff to a tcl based system and you will be flying .... As far as the tip from tech guy, he does not know what he is talking about, SOPC Builder went from a FIAT to a LAMBORGHINI, not ony did they move from PERL to JAVA but they have added a lot to the Avalon switch fabric like all the streaming stuff (which used to be called Atlantic). As far as bugs, what are you seeing maybe I can help you, although I ran into some things that made me scratch my head a couple of times, for the most part I have all my systems working beautfully under 7.1 ... And my advice is go to 7.1 because moving forward everything will be built on that structure. I hope that helped your frustartion, if it hasn't let me know maybe there are more things that I can help with ? sattia

Sattia, thanks for your post. The SOPC system that I am working with right now is pretty simple: a Nios, on chip memory, JTAG UART, and one custom Avalon slave module. You mentioned components with .ptf extensions ... I think you either mis-typed or are confused. The whole SOPC system is saved as a .ptf file, individual components are saved with a _hw.tcl extension. As far as I know, SOPC systems are still created as .ptf files in 7.1. Is this the problem? My custom Avalon slave has been updated to the _hw.tcl, SOPC builder automatically does this when you generate in 7.1. So I don't understand what you're saying about legacy components. I am not using any legacy components that I am aware of. The major slowdowns that I am seeing are: when you open SOPC builder, it "validates" the system contents. The other is when I edit a custom module, it "refreshes the component list" I will try making a simple system from scratch in 7.1 -- without any custom peripherals -- and see if there is any change in speed.

rjackal, Good post, I need to elobrate some more: By legacy componets, I mean ones that were originally created by the old component editor prior to 7.1. If you have those they will slow you down, if you re-do the compnet importing under 7.1 then they dont have to do the ptf to tcl translation. A good question wold be once the new tcl is created why do they do the translation from ptf everytime you ropen SOPC Builder. I can almost imagine the debate in Engineering when they were trying to descide on this .... one group would be saying you can't assume this and that etc ... Regardrdless see if that helps you, that you had one custom component. Regarding the ptf yeah it still gets produced but it's an output file, it's not constantly parsed and redited as you are modifying your system. The main reason for it, is that you still need a file that you need to pass to the IDE to creat the BSP/HAL stuff ... I guess they could have used a new format even a binary one, that would make things a little faster, but I kinda like it since it readable. Hope that helped explain things a little better, let me know how your experiment went. For the system you described it should be screaming fast. sattia

[rant] SOPC Builder 7.1 sucks! | Altera Community

15 Replies

Altera_Forum
Honored Contributor
18 years ago
Hi Tom,

If you have an Altera Nios II kit development board, one idea you may want to try is to take one of the example designs that can with the Nios II kit and download that design to the board to make sure all the physical connections are working between the USB-blaster and the board. The example design already has a .SOF file provided so all you have to do is program the FPGA (this will eliminate the SOPC builder from the equation) and then run a simple program in the IDE.

Location of the Altera development board example designs:
C:\altera\71\nios2eds\examples\verilog
C:\altera\71\nios2eds\examples\vhdl

If the simple program fails then I would either suspect problem with the IDE's connection to the JTAG server to the board since the provided example SOF has already been tested on the development board by Altera.

If that works, then you can try downloading your design to the board next to see what happens.

If you get the failure with your downloaded hardware design, then you have an example design that you can pass to Altera support to replicate the problem and they can find a fix to the issue since they can take the design file you have and replicate the bug on their own development board.

If you have a custom board, it should be simple to test a portion of your design on one of their development boards to at least determine if it might be an issue of the JTAG connection (i.e. noise or ringing on the trace) on a custom board.

I hope this helps,

Regards,
-ATJ
Altera_Forum
Honored Contributor
18 years ago
--- Quote Start ---
OK, I have found out why my project wont download.

Simple project with:
CPU
OnchipMem
JTAG UART

Works fine. :)

Product Project with:
CPU
Onchipmem
JTAG
Tristate Bridge / FLASH & SDRAM
DM9000 Network interface
UARTS x9
IO
Watchdog etc.

No Worky :(

If I remove the Tristate bridge, the project works fine! Even in SOPC 7.1 with SP1 to get rid of the huge 'Java error' problem it fails to download.

I have also noticed a bug with the Tristate bridge wizard - about 50% of the time the initial screen which asks you if you want a registered or non registered interface will not render the Registered button, so the only option you see is Not registered.

So I can only guess my problem is with the new tristate bridge. Sadly I need to get a product out ASAP which needs it so I have been advised by my FAE to roll back to 7.0
--- Quote End ---

Hi Tom,

I just saw your new post, there is a software patch for a tri-state bridge bug in SOPC builder. You should download the patch to give it a try.

See my post in this topic:
"SOPC Builder 7.1 Problem with New Components"
http://www.alteraforum.com/forum/showthread.php?t=456
Altera_Forum
Honored Contributor
18 years ago
Hi there, Re: the communication problem rjackal described a few posts ago...
Using cable "USB-Blaster [USB-0]", device 1, instance 0x00
Pausing target processor: not responding.
Resetting and trying again: FAILED
Leaving target processor paused

There is a new support solution posted on Altera's web site that documents these errors. It links to a related solution that provides patches to fix a problem with the OpenCore Plus circuitry in version 7.1 and 7.1 SP1. Even with a full Quartus II license, you may see this problem if you don't have a full license for the Nios II core. Hope it helps!

http://www.altera.com/support/kdb/solutions/rd07272007_849.html (http://www.altera.com/support/kdb/solutions/rd07272007_849.html)
Altera_Forum
Honored Contributor
18 years ago
Thank you for that link, Stevie. I will give the patch a try soon.
Altera_Forum
Honored Contributor
18 years ago
I have just moved from V6.1 to V7.2 SP1 and it seems to me the slow response is still an issue. SOPC used to start in a few seconds, it now takes over 5 minutes for the 'upgraded' design.

I have also had various other bugs to work round but I cannot find a way to make SOPC quicker.

I have tried technical support they have added nothing useful so far.

I am thinking of rebuilding the processor from scratch under V7.2 but it is a dual processor design with 38 components many of which are user defined interfaces.

Can anyone tell me if I am likely to see a significant speed improvement by rebuilding the processor?

Alternatively, does anyone have any other recommendations for minimising the time I have to endure that annoying 'Knight Rider' graphic!

Forum Discussion

[rant] SOPC Builder 7.1 sucks!

15 Replies

Recent Discussions

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG

Is Quartus Prime Pro 22.4 Compatible with Stratix 10 NX Series Device?

Timing analysis - long combinational path

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer

Duplicate_hierarchy_depth / duplicate_register