Required Nios components

[Altera_Forum]

Hello, 

I am trying to develop a very simple Nios cpu to run Hello world application. I have created a design:  http://i55.tinypic.com/a29isy.jpg  As You can see, I have inserted DDR2 memory to store required code. The whole system should run from altmemddr PLL. However, the EDS tool doesn't find neither sysid, nor timestamp. What is wrong with this design? I have tried to add timer, but that didn't help and afaik it is not required.  DDR2 pins are OK, I have taken them from a working example from development board CD.

[Altera_Forum]

Are the byte enable signals correctly connected to your 16-bits SRAM? Looking at your text again, it seem that on each 16-bit word is in fact the second byte repeated twice (I don't know if it is very clear, expressed like that). It could be that when the CPU is trying to do a 8-bit write to memory using byte enables, the memory write the same byte twice instead. 

It should be possible to test 8-bit writes using custom HDL or the system console tools.

[Altera_Forum]

Remember the nios will always do 32bit reads (with all 4 byte enables driven).

[Altera_Forum]

....im scared about it........ 

 which board you are using??????

[Altera_Forum]

I can't actually imagine that the cpu would run well enough to execute the memory test code at all if the memory was generating errors like those shown. 

Possibly that is some artifact of the JTAG uart interface itself, it ought to run happily at 50MHz without any pipeline bridges at all.

[Altera_Forum]

You need to constrain tck to run at at least 10MHz if you're using timequest (20MHz if you use the old timing analyser). The On-board USB-Blaster in the neek runs tck at upto 8MHz. 

 Also, there is probably little benefit to running the Avalon clock for the JTAG UART so slowly - I would run that at 20MHz or more (and check it meets timing)

[Altera_Forum]

--- Quote Start ---  I can't actually imagine that the cpu would run well enough to execute the memory test code at all if the memory was generating errors like those shown.  --- Quote End ---   The CPU only uses 32-bit reads to load the code, doesn't it? If there were a problem with byte enables as I suggested, it would mostly show up during I/O, but probably not before...

[Altera_Forum]

Here's another clue as to what might be happening... 

 When I program this:  int main() {  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz \n");   return 0; }   I get this:  Hello from Nios II! 1234567890abcdefghijklmnopqrttvvxxzz  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz  eell rrom Nios II! 1234567890abcdefghijklmnopqrstuvwxyz  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz  Hello from Nios II! 1234567890abcdefghijklmnpprrttvvxxzz  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz

[Altera_Forum]

I checked the signals on the JTAG port on my custom board. TCK is running around 6 MHz with the JTAG UART in Qsys running at 100 MHz. The Nios II CPU along with everything else in Qsys is also running at 100 MHz. No problems except this Nios II Console stuff.

[Altera_Forum]

Is the system running from on chip memory or external memory?

[Altera_Forum]

The Nios II software is running from external 516K x 16 SRAM. 

 I have an on-chip RAM block running as tightly coupled instruction memory in which I have configured the Nios II CPU to use for he reset and exception vectors.

[Altera_Forum]

I just tried running this: 

 int main() {  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 \n");   return 0; }    and got this:   Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 HHllooffoo iissII!!1133557799aacceeggiikkmmooqqssuuwwyy 2244668800  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz1133557799 HHllooffoo iissII!!1133557799aacceeggiikkmmooqqssuuwwyy 2244668800  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890 HHllooffoo iissII!!1133557799aacceeggiikkmmooqqssuuwwyy 2244668800  eell rrmmNNoo II 2244668800bbddffhhjjllnnpprrttvvxxzz1133557799 HHllooffoo iissII!!1133557799aacceeggiikkmmooqqssuuwwyy 2244668800

[Altera_Forum]

I just ran this: 

  int main() {  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");  printf("Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890123 \n");   return 0; }  and got this:   Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133  Hello from Nios II! 1234567890abcdefghijklmnopqrstuvwxyz 1234567890133   Notice the missing 2 and repeated 3 at the end of each line...

[Altera_Forum]

Run the whole design using only on-chip memory. That doesn't seem like frequency issue, more like RAM problems.

[Altera_Forum]

Ah ha! Problem solved (for now). I tried adding a data cache to the Nios II cpu and that fixed it. I added a tightly-coupled data master (already had a tightly-coupled instruction master) using on-chip memory. 

 The sample app Memory Test now works if I remove the byte/word section. I am not using the BHEn and BLEn pins on my SRAM to conserve pins, but will include them in the production version of the board. I didn't think that I would need these pins if I went with straight 16-bit accesses. Would I have had this problem if I had these lines implemented? I guess I won't know for sure until I test the next version of my board.  Anyway, many thanks to all of you who offered suggestions and insight into this issue that has been haunting me for weeks.

[Altera_Forum]

The data cache will mask those problems because it will always do 32-bit accesses. Without the cache (or if you do an access by bypassing the cache) all 8-bit writes will fail. I guess that 8-bit accesses can happen in I/O functions, but also possibly in all string-manipulating functions, so it could be a problem. 

According to this message by dsl (http://www.alteraforum.com/forum/showpost.php?p=123683&postcount=4), you will also run into problems with 16-bit accesses if you don't connect the byte enable lines, so you should keep the data cache for now, and avoid any cache bypassing.

[Altera_Forum]

--- Quote Start ---  The data cache will mask those problems because it will always do 32-bit accesses. Without the cache (or if you do an access by bypassing the cache) all 8-bit writes will fail. I guess that 8-bit accesses can happen in I/O functions, but also possibly in all string-manipulating functions, so it could be a problem. According to this message by dsl (http://www.alteraforum.com/forum/showpost.php?p=123683&postcount=4), you will also run into problems with 16-bit accesses if you don't connect the byte enable lines, so you should keep the data cache for now, and avoid any cache bypassing.  --- Quote End ---    I noticed when setting up the Nios II data cache in Qsys that we have a choice of "Data cache line size". I first tried setting it up as 16-bit and it worked. Then I changed it to 32-bit to see what would happen, and it still worked. Would it be best if I set it for 16-bit and enable burst transfers?

[Altera_Forum]

Those cache line sizes should be in bytes.

[Altera_Forum]

The memory interface might behave differently from the normal bus width adapter that SOPC adds for you. 

We certainly saw the PCIe slave bridge doing two 32bit transfers (one with no byte enables) when the external PCIe master requested a 32bit transfer.

[Altera_Forum]

sorry...missed that I was only on page one when I posted quick reply...nothing to see here, keep moving!

[Altera_Forum]

Burst transfers shouldn't make a big difference on an SRAM. As for the cache line size, as dsl says the size is in bytes and not bits. Each time a transfer is required between the cache and the main memory, a full line will be read/written. Whether 16 or 32 is better depends a lot on the application (both hardware and software). You can try both and see if one performs better than the other on your system.

[Altera_Forum]

--- Quote Start ---  Burst transfers shouldn't make a big difference on an SRAM. As for the cache line size, as dsl says the size is in bytes and not bits. Each time a transfer is required between the cache and the main memory, a full line will be read/written. Whether 16 or 32 is better depends a lot on the application (both hardware and software). You can try both and see if one performs better than the other on your system.  --- Quote End ---    Thanks for explaining this. My present application involves storing and retrieving 16-bit audio samples, so this will be an important consideration.