A list of SOPC problems

1) can be solved very easy if you call the signals as altera recomments them. if you do so, you will not need to manualy change signal and interfaces again. belive me i was luckily surprised too when i found that out a couple of days ago.

the method of naming is more than simple and starts with :

gls (GLobal Signal)

avs (Avalon Valid Slave)

avm (Avalon Valid Master)

now a "_" followed by tha name of the interface

registerslave

writemaster

jackdaniels

(what ever you would like to your interfaces (register is not allowed as it is a valid word in verilog)

now a "_" followed by the signal

readdata

read

address

int

waitrequest

if you have an avalon slave that you would like to call registerslave then all signals for that interface must be called like :

avs_registerslave_readdata

avs_registerslave_address

avs_registerslave_read .....

global signals like clk and reset should be called

gls_clk

gls_reset

for a master :

avm_mymaster_waitrequest

now something about exporting signals that leave the nios to be connected outside

avs_myslave_export_signalnameoutside

recognised _export_ ???

if you follow these simple rules you will never reedit the interface again if you change a hdl (well at least this works perfect for me)

2) i have requested such a garbage collection feature more than once when contacting altera ..... as long as their resources do more importante thing a can live with this server space wasting dead files.

but ... use the quartus archieve function to create a *.qar file that hold everything remove all files and unpack qar again :-)

5) yes this realy sucks :-( i add this file to a quartus project and do the analyze there until is does not mention any error or warning then i go back to the sopc ....

6) YES i would greatly call this a MUST HAVE !!!

we design a platform system and do not want to reedit or reenter a complete nios sopc into a new project and keep an eye on both projects. image dozens of nios sopc project all nearly the same (address, int, timer, core).

i would love to have the possability to create a basic set that is include in a famlily of nios sops projects and they differ only in a few thing .... but each family project member will get the modification made in other members of this design family (like changig the int of the timer f.e.)

7) how should such a fifo behave ?

8.) there is even no simple sram sopc modul to tell the sopc that we want to have 8/16/32Bit sram outside with xyz addressbits ...

9.) there is no external memory model to implement a external tristate bus to connect external devices

10.) one very big problem with the avalon : the avalon is not capable to have an external 8bit device connected that handles the external device as a memory (not registered) that there is no gap in the occupied space from nios software view AND (and that is the problem) read only these bytes from the external 8 bit component that the software has accessed (meaning reading only 8 bit should lead to only 1 external byte access instead of reading all 32 bit)

Why ? tell me one profibuschip that allows that byte locations are read that are not needed. (spc31, spc4, spc41, spc42, vpc3+c interprete a read from a register and reset according bits) but to gain performance you want to have the profibus memory inside the profibuschip as a memory window for memcopy() memset() ...

so nios with avalon is currently not capable to have any known profibus chip (infineon, profichip) as an external 8bit memory device. (memory not register !) you wont get the certified stacks running !

Regards

Michael Schmitt

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

1) can be solved very easy if you call the signals as altera recomments them[/b]

--- Quote End ---

Thanks for the naming. I can&#39;t believe I worked without knowing this, and it&#39;s right there in the docs http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif

I also needed &#39;ats&#39; for addressing external memory chip. Gladly this is a 16 bits (actually 18) device. I&#39;m using the tri-state-bridge component with it as well. Can that solve your 8 bit memory mode problem?

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

5) ... i add this file to a quartus project and do the analyze there until is does not mention any error or warning then i go back to the sopc[/b]

--- Quote End ---

I have Xilinx tools installed as well and easy to verify HDL in there.

6) Too bad that a SOPC system doesn&#39;t generate a SOPC component. Difficult to do that manually too because of the lack of proper prefixes.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

7) how should such a fifo behave ?[/b]

--- Quote End ---

Such a FIFO should be configurable much like the MegaWizard for lpm_fifo_*. Width, depth, synchronization/clocks, and status output to a slave control port. Interrupt to signal an under-/overflow and it could do avalon handshake to pause input when it&#39;s full.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

9) there is no external memory model to implement a external tristate bus to connect external devices[/b]

--- Quote End ---

tri-state-bridge can be used for external memories I think.

11) and how to get the base addresses for slave interfaces in some other HDL file instead of system.h? I could parse the pts file and output some HDL code for it...

12) Component Editor HDL analysis hangs on global (gls_*) signals ending with "clk"

1) Yes like most of the stuff it is there in the docs but ... there must be a reason why we both didn&#39;t find it ....

I could think of the sopc editor mentioning to use these recommend syntax if it find signal named not that way ... just as a hint.

no it can&#39;t be used because, avalon description says clearly a read master MUST always enable all byteenable lines to read the full 32bit. and therefor all modules comming from altera will always read full 32bit. we have a custom modul that reads and writes only those bytes that are selected by the byteenable[3..0]

as long as we do not have a clever solution for this, tristate bridge for normal external devices is a different than the one for those external device that do not like those read cycles that come from the must always read 32bit.

9) yes the tristate bridge can handle them if you connect a propper sopc modul to the tri state bridge

11) hmmm .. open the ptf ... search for the settings ... and manually edit the custom design tools. i wish there was a file like system.h created by sopc generate and not by the ide as we do not use the ide. we use euros.

12) well here it works with gls_clk (no need to name the interface)

13) more to follow but it is late and i had 15hours today quartus and protel dxp searching for a bug somewhere on a avalon master but at the end only disabling the datacache solved it a(for now).... hopefully MySoppurt will be back from holiday as soon as possible and help me to solve my request about a definitly not writing avalon master that sets all signals properly (well it does write to external sram but not sdram)

14) yes one comes into my mind ... during sopc generation if some java errors are reported ... what is the reason for them ... only a error won&#39;t help a lot

15) "the_{instance_name}.vhd" (generated) does not include avalon signals in port list. Only gls_* signals were in there. Weird stuff http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif

16) NumberFormatException: For input string: "N/A" during system generation.