Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Incorrect printline by using different memory segments

Hi!

I have a system with NIOS and several memory blocks, 2 x On-Chip, SDRAM and SRAM. All of them work well, as long as I use same memory for all segments (.heap, .data, .stack....). As soon as I link my .heap to memory A and everything else to memory B, I get some € and [] (this quads, see picture). I use Quartus 12.0sp2 and NIOS IDE for eclipse and my C-Code is 


int main(){ 
   int i = 0;
   int range;
   char* src_ptr;
   range = 542;
   char one = 1;
   src_ptr = calloc (range, sizeof(char));
   while (i< range) { 
       *(src_ptr + i) = one;   
        one = ~one;     
        printf(" %i, ", (int)*(src_ptr+i)); 
        i++;
   }  
   while (1);
   return 0; 
}

So.......why?

The onchip_memory2_1 and SRAM are 8 bit width, the rest 32. I use this 4 memorys, NIOS II/e, one custom peripheral, sys-id-component and jtag.

Hope it was enough information and someone know where my fault is.

Regards!

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Does your FPGA meet all timing specs?

    Have you tried running the Memory tests on the different segments?

    There should be nothing wrong with what your are doing. But i've see memory failures do odd things.

    Pete
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hi!

    Thank you, Sir, for the quick reply.

    I'm very beginner, so sorry if my questions are stupid.

    --- Quote Start ---

    Does your FPGA meet all timing specs?

    --- Quote End ---

    How can I find it out? Do I have to use TimeQuestAnalyzer? Never used it to be honest. I even get this critical warning

    Critical Warning (332168): The following clock transfers have no clock uncertainty assignment. For more accurate results, apply clock uncertainty assignments or use the derive_clock_uncertainty command.

    and I read something about how to solve it but I don't know where to use the derive_clock_uncertainty command.

    --- Quote Start ---

    Have you tried running the Memory tests on the different segments?

    --- Quote End ---

    You mean this Memory Test template in the Eclipse IDE? Realy no idea how things work, totaly beginner, sorry once more.:oops:

    Regards.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hi. Not problem being new to this. We all are learning new things everyday!!

    So for FPGA's Quartus goes through the logic, optimizes it, then places it in various places in the physical chip, and routes it all together. If the design is very fast, or very large, it may or may not be able to meet the timing requirement's of the design, so the TimeQuestAnalyzer checks your designs actual timing against a desired timing required by the constraints file (.SDC file) to make sure it meets specs. Quartus is pretty smart in that if you define a PLL it usually gets the basic PLL timings in the design for you based on the PLL settings, but it's not ALWAYS correct.

    So Understanding the tool and the constraints file is critical for a stable design. I would focus a bit of working with this tool and understanding it. Especially around IO timing (The trickiest part). Make sure all you clocks are defined, and they have reasonable frequencies. Note: cross clock domain signals will almost ALWAYS fail timing, unless the clocks are handled with care and have related frequencies. So special logic must be used here to insure proper functionality (Fifos, Flancter circuits, etc)

    The Timing warning is stating that you don't have any clock uncertainty applied. Clock uncertainty is that due to jitter and other effects, you are not exactly certain when the clock edge will occur, so you need some margin to handle this. The derive_clock_uncertainty is a command that will use ALTERA's recommend uncertainty values for their internal clock trees and PLL's so it's an easy way to apply it to all clocks, and it will work for ALTERA FPGA's.

    On the Memory Test Template: Yes I was talking about the one in the Eclipse IDE. I typically target this initially to run in an internal SRAM segment so I can test the rest of the memories. (The only problem being your internal segment must be large enough to hold all the code space).

    The default test pattern is ok, but not the best. I usually modify it for my specific needs. Especially to track down board issues like open/shorts.

    Hope this helps point you in the right direction anyway..

    Pete
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Allright, thank you once more, Pete.

    Guess I'll need some days to get through all this stuff. But that was very helpfull anyway. I'll reply when I have problems to get through it or finaly sove my problem.

    Thanks.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    At a guess it is running out of heap space.

    It might be that you aren't getting exactly the memory assignments you expect.

    I don't know how much heap that code needs, but if it is below 16kB I'll eat my hat.

    Possibly the code survives over-allocating from the heap because the data cache holds the data for long enough.

    FWIW you really don't want to use anything other that 32bit memory (or IO) unless really forced to do so.

    Also use tightly coupled memory for all internal memory blocks.