QSYS fails to generate SS_n export correctly for SPI interface?

[Altera_Forum]

I have been tearing my hair out over this and have concluded that the SOPC generation of an SPI peripheral is broken somehow in QSYS (yet worked fine with SOPC Builder). 

 I have an SPI master in my SOPC design and specify the number of slaves to be 3.   The SOPC module generated by QSYS declares the SS_n signal as:   output wire spi_0_SS_n   yet it connects it to an SPI instance where .SS_n is declared as   output [2:0] SS_n   so only a single one of my chip-selects ever gets asserted and thus I can only communicate with one of the SPI devices now instead of all three.   Anyone else seen this? Any work-around suggestions?   I have tried removing the SPI device and re-adding it in QSYS but (predictably) it is consistently wrong.   Thanks, -dave

[Altera_Forum]

I just tried it out and see the same thing. I doubt you can easily work around this so assuming you are not generating your system often then I would hack the output HDL file to make the exported ss_n signal wider. I'm filling a bug for this one but if you want to explore other workarounds you can file a service request here: http://www.altera.com/mysupport 

 If you do manage to find a cleaner workaround please post it on the wiki so that others can benefit as well: http://www.alterawiki.com/wiki/new_qsys_issues

[Altera_Forum]

--- Quote Start ---  ... hack the output HDL file to make the exported ss_n signal wider.  --- Quote End ---     I should have noted that that was the first thing I did. The compile process regenerates that file each time. Or it did in my environment. I was equally surprised. It seems that 'generation' of the SOPC is run for every compile. Or from this wicked-green-novice it appears to be that way.   Thanks for your reply. -dave

[Altera_Forum]

That file should only be updated if you click the generate button in Qsys. So if you leave the system alone between Quartus II compiles your hand modifications should remain intact. There is another flow that isn't documented that could result in the behavior you are reporting, if you are using that flow I recommend sticking to the normal flow that SOPC Builder used as well (generate the files then compile).

[Altera_Forum]

--- Quote Start ---   There is another flow that isn't documented that could result in the behavior you are reporting, if you are using that flow I recommend sticking to the normal flow that SOPC Builder used as well (generate the files then compile).  --- Quote End ---     I am not even sure what that means (another flow). I had a working QII 10.1sp1 project with an .sopc file based design. I updated my tools to QII 11.0 and opened the project, let QSYS upgrade it, etc.   I did not do anything that I am aware of that tells Quartus to do 'some other flow' undocumented or otherwise.  But thanks, you have given me some hope and plenty of homework!   -dave

[Altera_Forum]

Ok, I was being cryptic about the other flow just in case someone told you how to use it (I didn't want to give specifics since I don't want to see others trying to use the 'other flow' at this time). 

 So you are using the standard flow and as long as you don't click the generate button your changes should stick.

[Altera_Forum]

Forgive my ignorance. 

 I would expect then that if I had never run "Generate" and had grabbed my project from an archive (I actually have it captured in a source control system) where the ./db/... folder and other generated intermediate files had never been generated, and I pressed the green > compile button, that the compile would fail because the SOPC had never been generated.   Yet it does not fail (like it did with 10.1 if the SOPC had never been generated). Instead, it seems that QII runs all sorts of machinery to generate the SOPC creating a folder ./db/<sopc_name>/ or something similar - exactly the files I would like to patch.   So is QII 11.0 wicked smart and knows that the absense of these files means it should fire up whatever happens in QSYS when generate is pressed or am I actually seeing that it always generates the SOPC on every compile?   Thanks. Trying to learn. -dave

[Altera_Forum]

now that I think about it (not infront of the system at present) that compile button is purple :)

[Altera_Forum]

I cannot reproduce this behavior. Sorry for the dumb question. 

-dave

[Altera_Forum]

Ok. I think I figured out my detour into the unexpected 'regeneration' of the SOPC when I compile and sorry if this exposes the 'other flow' (perhaps it does not). 

 I had the .QSYS file listed among my project files. Being completely new to this QII stuff it seemed like a logical choice when my original design would not compile complaining it could not find the SOPC module to be instantiated in my top level verilog file.   When I do that, the QSYS SOPC appears to be rebuilt each time I compile the design.   Now I downloaded the recently update for v11 niosII_ethernet_standard_3c25 and noted that it does not have the .QSYS file listed in the project files but instead lists the ./<sopcname>/synthesis/<sopcname>.qip in the project files. And this being where the 'generate' step of the QSYS places the output files must have been what was suggested as the files to manually edit.   So, having now learned lots about this tool, I will not add a .QSYS file to my project files unless I really want that behavior (which would be fine if it just worked!)   I am reasonbly certain I have this figured out.   Thanks for your patience and help. -dave

[Altera_Forum]

Ah you stumbled into that 'other' flow I was talking about :) The only you should include is the .qip file generated by Qsys.

[Altera_Forum]

I have the same problem: QSYS fails to generate SS_n export.  

The ss_n port on the symbol block in my .bdf file has only 1 dimension instead of 2.  How can fix it? I have to modify the HDL file as you said previously? After editing the file i just compile again my project? Thank you.

[Altera_Forum]

You would have to edit the HDL and the symbol file since it is getting generated with a single bit ss_n signal. I have never modified a symbol file directly but it's probably possible with a text editor. 

 If you used Quartus II to generate a new symbol based on the edited HDL you'll end up with a symbol that doesn't look anything like what Qsys is generating (but that's an alternative to hacking up a symbol directly).

[Altera_Forum]

Have you tried this with Quartus 11.1 SP1? (I think that is the latest). 

 IIRC when I tried this with the latest version of QSYS it seemed to work now.

[Altera_Forum]

Yes I spoke to an Altera support representative and he confirmed that this problem has been fixed in Quartus 11.1