Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12409 Discussions

SOPC Builder Warning (Tightly Coupled Memory)

Honored Contributor II



I'am building a NIOS System using SOPC Builder ( Quartus Version 10.0 SP1 ) 


I'm stumped with this warning: 




CPU: Generating non-optimal logic for tightly_coupled_instruction_master_0 due to memory map overlap with instruction_master (0xffffffff - 0x0c101fff) 


CPU: Generating non-optimal logic for tightly_coupled_data_master_0 due to memory map overlap with data_master (0xffffffff - 0x0c101fff) 


I have checked the Address map. I think it's all ok. 

Auto Assign Base Addresses doesen't fix this warning. 


Looking someone about this warning 


0 Kudos
5 Replies
Honored Contributor II

Please note that SOPC builder will generate the system even if this warning is present. 

Anyway the "non-optimal logic" message means that the system could be simplified if you define such addresses that the decoding logic is limited to one bit. 

For example, it would happen when your instruction master spans addresses 0 to 0xfffffff and you place TCM base address to 0x10000000; in this configuration the processor decoder needs to test only bit 12 in order to decide if it must access to main bus or TCM. 

The aim is to reduce required logic and consequently improve timing.
Honored Contributor II

I also think there is a fubar in the test within the sopc builder for these overlapped addresses. 

I found that warning output whenever I put tightly coupled memory at low addresses. Trying to decode the error message led be to believe (IIRC) that the script was trying to find the low-high bounds of all the tightly coupled memory areas, but has a signed v unsigned compare error (or similar) when trying to find the low bound (I bet the range starts low=~0u, high=0 and the 'low' doesn't decrease!) 


Didn't seem to stop our system working. 

We have several tightly coupled memory blocks below 128k, some IO just above 128k and 16M of SDRAM at 16M. 


The sopc builder won't let us alias the non-SDRAM every 256k, nor alias the IO (say each item into 256 bytes, and the whole lot every 8k). 

Adding such 'don't care' bits into the address assignments would save logic and speed up the address select logic - which it what you'd do if laying out a physical board. 


I even remember reading soemwhere in the Altera docs a suggestion that 

you use single address bits to select logic - ie A8 high selects 'A', A9 selects 'B' etc (and both A8 and A9 high being illegal with undefined effects - possibly including the emition of 'magic smoke')
Honored Contributor II

Hello Chris72 


Yes, i know, that SOPC Builder will generate the system even if this warning is present. 

I'am working with this design and its running without problems. 

And i know too, the reason to reduce or simplify the address decoder logic. 


But i think this warning is a software bug from SOPC builder. 


The Nios II address range is 0x00000000 - 0xffffffff (32 bit) 

i have a 64 MByte SDR-Memory at 0x08000000 to 0x0fffffff ( 128 MByte ). 

Data Master and Instruction Master is connected to this memory. 


The warning says,  


"Generating non-optimal logic for tightly_coupled_data_master_0 due to memory map overlap with data_master (0xffffffff - 0x0c101fff)" 


Non optimal is ok. The Address for the TCD-Master in my design is 0x01011000. This could be optimized. 

But i don't understand the overlap. 


If this warning is real there must be an address overlap from 0x0c101fff to 0x0fffffff with the SDR-Memory. 


If this overlap is real, SOPC Builder has to generate an error. 


Is that right ?
Honored Contributor II

Read what I said! 

The give-away is that (0xffffffff - 0x0c101fff) isn't a valid range. 


Does beg the question about why it has remainded broken for so many releases!
Honored Contributor II

Hi dsl, 


thank you very much for your answer. You have helped me a lot. 

Sorry, i had not yet received your message, as I wrote chris72.