[rant] SOPC Builder 7.1 sucks!

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

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

Ok, I just updated to 7.1 SP1 (another 400+ MB download!) and created a new project from scratch. In SOPC builder, I have a Nios, onchip_mem, JTAG UART, and one simple slave peripheral that turns on a LED when a button is pushed. I created the slave peripheral in 7.1, so it should not be considered 'legacy'.

I compile, download, and create a simple "hello world" C project in Nios IDE, and it fails to recognize the processor. I get this message:

Using cable "USB-Blaster [USB-0]", device 1, instance 0x00

Pausing target processor: not responding.

Resetting and trying again: FAILED

Leaving target processor paused

This is what I was referring to earlier when I said that things do not work in 7.1 This same exercise works in 6.1

On another note, even though I do not have legacy components in my system, when I generate the SOPC system, I noticed this message:

Info: simple_slave_0: Generating module simple_slave_0

"c:/altera/71/quartus//bin/jre/bin/java.exe" -Xmx256M -classpath "c:/altera/71/quartus//sopc_builder/bin/sopc_builder.jar;c:/altera/71/quartus//sopc_builder/bin/PinAssigner.jar;c:/altera/71/quartus//sopc_builder/bin/sopc_wizard.jar;c:/altera/71/quartus//sopc_builder/bin/jptf.jar" sopc_builder.sopc_builder -d"c:/altera/71/quartus//sopc_builder" -projectnametop.qpf -projectpathC:/altera/71/qdesigns/simple_nios --no_splash --refresh C:/altera/71/qdesigns/simple_nios/simple_nios_sopc.v --quartus_dir="c:/altera/71/quartus/" --sopc_perl="c:/altera/71/quartus//bin/perl" --sopc_lib_path="C:\altera\71\ip\pci_express_compiler\lib\sopc_builder+C:\altera\71\ip\ddr2_high_perf\lib\sopc_builder+C:\altera\71\ip\ddr_high_perf\lib\sopc_builder+C:\altera\71\ip\sopc_builder_ip+C:\altera\71\ip\nios2_ip+C:\altera\71\ip\triple_speed_ethernet\lib\sopc_builder+C:\altera\71\ip\pci_compiler\lib\sopc_builder+C:\altera\71\ip\ddr_ddr2_sdram\lib\sopc_builder+C:\altera\61\ip\sopc_builder_ip+C:\altera\61\ip\nios2_ip+C:\altera\61\ip\pci_compiler\lib\sopc_builder+C:\altera\61\ip\ddr_ddr2_sdram\lib\sopc_builder+c:\altera\megacore\pci_compiler-v4.1.1\lib\sopc_builder+C:\altera\megacore\ddr_ddr2_sdram-v3.4.0\lib\sopc_builder+c:\altera\71\quartus\common\librarian\factories+c:\altera\71\quartus\sopc_builder\model\lib+c:\altera\71\ip\pci_compiler\lib\ip_toolbench+c:\altera\71\ip\pci_express_compiler\lib\ip_toolbench+c:\altera\71\ip\rapidio\lib\ip_toolbench+c:\altera\71\ip\ddr2_high_perf\lib\ip_toolbench+c:\altera\71\ip\ddr_high_perf\lib\ip_toolbench+C:\altera\71\qdesigns\simple_nios+c:\altera\71\ip\triple_speed_ethernet\lib\ip_toolbench+"

Executing: c:/altera/71/quartus//sopc_builder/bin/sopc_builder --legacy --generate C:/altera/71/qdesigns/simple_nios/simple_nios_sopc.ptf

Info: Starting generation...

See that stuff in there about Perl and the third-to-last line that has a "--legacy" switch? What is that all about?

And if I edit my custom component and click Finish, this dialog box pops up about "Refresh Component List" and it has about 500 lines that say things like:

Debug: librarian info: search path is set to c:\altera\71\quartus\common\librarian\factories,C:\altera\71\qdesigns\simple_nios,C:\altera\71\qdesigns\simple_nios\.sopc_builder,C:\altera\71\qdesigns\simple_nios\db,C:\altera\71\qdesigns\simple_nios\simple_nios_sopc_sim,C:\altera\71\qdesigns\simple_nios\software,c:\altera\71\quartus\sopc_builder\model\lib,C:\altera\71\ip\pci_express_compiler\lib\sopc_builder,C:\altera\71\ip\pci_express_compiler\lib\sopc_builder\altera_avalon_pcie_compiler,C:\altera\71\ip\pci_express_compiler\lib\sopc_builder\altera_avalon_pcie_compiler_adapter,C:\altera\71\ip\ddr2_high_perf\lib\sopc_builder,C:\altera\71\ip\ddr2_high_perf\lib\sopc_builder\ddr2_high_perf,C:\altera\71\ip\ddr_high_perf\lib\sopc_builder,C:\altera\71\ip\ddr_high_perf\lib\sopc_builder\ddr_high_perf,C:\altera\71\ip\sopc_builder_ip,C:\altera\71\ip\nios2_ip,C:\altera\71\ip\triple_speed_ethernet\lib\sopc_builder,C:\altera\71\ip\triple_speed_ethernet\lib\sopc_builder\altera_triple_speed_ethernet,C:\altera\71\ip\pci_compiler\lib\sopc_builder,C:\altera\71\ip\pci_compiler\lib\sopc_builder\altera_avalon_pci_compiler,C:\altera\71\ip\pci_compiler\lib\sopc_builder\altera_avalon_pci_compiler_adapter,C:\altera\71\ip\ddr_ddr2_sdram\lib\sopc_builder,C:\altera\71\ip\ddr_ddr2_sdram\lib\sopc_builder\ddr2_sdram_component,C:\altera\71\ip\ddr_ddr2_sdram\lib\sopc_builder\ddr_sdram_component,C:\altera\61\ip\sopc_builder_ip,C:\altera\61\ip\nios2_ip,C:\altera\61\ip\pci_compiler\lib\sopc_builder,C:\altera\61\ip\pci_compiler\lib\sopc_builder\altera_avalon_pci_compiler,C:\altera\61\ip\pci_compiler\lib\sopc_builder\altera_avalon_pci_compiler_adapter,C:\altera\61\ip\ddr_ddr2_sdram\lib\sopc_builder,C:\altera\61\ip\ddr_ddr2_sdram\lib\sopc_builder\ddr2_sdram_component,C:\altera\61\ip\ddr_ddr2_sdram\lib\sopc_builder\ddr_sdram_component,c:\altera\megacore\pci_compiler-v4.1.1\lib\sopc_builder,c:\altera\megacore\pci_compiler-v4.1.1\lib\sopc_builder\altera_avalon_pci_compiler,C:\altera\megacore\ddr_ddr2_sdram-v3.4.0\lib\sopc_builder,C:\altera\megacore\ddr_ddr2_sdram-v3.4.0\lib\sopc_builder\ddr2_sdram_component,C:\altera\megacore\ddr_ddr2_sdram-v3.4.0\lib\sopc_builder\ddr_sdram_component,c:\altera\megacore\ddr_ddr2_sdram-v3.4.0\lib\sopc_builder\n,C:\altera\61\ip\nios2_ip\altera_nios2,c:\altera\71\ip,c:\altera\71\quartus\sopc_builder\model\lib,c:\altera\71\quartus\libraries\megafunctions,

Debug: librarian info: project file list is set to null

Debug: librarian info: librarian root directory is set to c:\altera\71\quartus\common\librarian

Debug: librarian warning: librarian cache directory is set to null

So I still have my original complaints. SOPC Builder 7.1 is slow where there is a custom peripheral in the system, and Nios IDE can't find my processor in 7.1.

Yep I agree it sucks!

I have yet to get any pre 7.1 projects to work correctly, and I currently can't get any new projects to work in it.

I also have a simple project with a NIOS II/F created in 7.1 sp1 SOPC builder and the JTAG DOES NOT WORK! Even though I have a NIOS II/F core with debugger level 2, and I can see the JTAG interface in the PTF file, NIOS IDE refuses to 'see' it at all and claims I don't have a debugger interface!

Any ideas?

Tom: I assume you have a paid version of debugger level 2?

My only advice is go back to v. 6.1 of everything if you have it available.

I'm not sure about 7.0; that may also work.

After much messing (basically a total reinstall) I managed to get the JTAG to appear in the IDE :)

However I now get the far too familiar:

Using cable "USB-Blaster [USB-0]", device 1, instance 0x00

Pausing target processor: not responding.

Resetting and trying again: FAILED

Leaving target processor paused

Using 7.1sp1 Full seat :(

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