Honored Contributorhello,
anyone encounter this problem that a component made by user logic can't run with nios system that has comprised ram and flash and so on? who can give me some suggestion? thank you!
Honored ContributorCould you give more specific information about the system you are having problems with.
Honored ContributorThanks in advance
We create a Nios II Core which includes ssram/flash/on-chip ram. It runs well. Then we expand a peripheral handling baseband signals. After we structure a IUL linking the peripheral and Nios, Nios refuses to work and the programs could not run on it. Why? StillHonored ContributorAre you using data cache by any chance (f core)? If so, when you do your read/write to it you need to bypass the data cache. If you read or write without doing this the data may get cached and the next access may come straight from the cache instead of the external logic that you made.
IOWR_32DIRECT(base, offset, data) // to write bypassing cache int IORD_32DIRECT(base, offset) // to read bypassing cache And if that's not the cause let us know. CheersHonored ContributorI just used the S Core for my application. Just instruction cache be embedded on Nios's running. Anything wrong with such constructions?
Thanks.Honored ContributorNope that's fine, so my next question is did you create a HAL driver for it or are you simply reading and writing using pointers?
If you are using pointers make sure you declare them as volatile to make sure they are not being synthesized away at compile time. Also put your compiler into debug mode with -O0 optimization just to make sure it's not simply the compiler causing this. If your code is not too big you may also want to use the debugger to step through your code where you perform reads/writes to this custom peripheral to find out when it actually breaks (could be that it's fine and a bug somewhere else is the cause). Cheers.Honored ContributorIt seems to me that the user logic that was added to the design might not allow it to meet timing, or it's making it fail somehow else. Can you run a very simple program (i. e. HelloWorld) on your design after you add your user logic? Do you get timing errors/warnings while compiling your design?
Honored ContributorYou beat me to that, but I would check the software stuff that I suggested first, then check the hardware timing. Another thing you can do is remove your custom hardware and reads/writes to it in your software just to make sure it's not something in the custom user interface causing it (I doubt it would cause that since I've based many designs off it without problems). But do these steps one at a time so that in the end if it gets fixed you know how you went about doing it.
Another thing worth checking is the address space for that interface. I've seen SOPC builder once take an address space of 16 bytes and bring it down to 4 bytes and that caused some nasty problems (mainly because I didn't expect that to be a cause). Good-luckHonored ContributorPerhaps I should describe the problem clearly.
Firstly, the Nios could run well before I create a peripheral. Secondly, the Nios could run well also when I add an IUL which is used to link the Nios and peripheral. Now the peripheral is not embedded on synthesis. Timing is correct. However, the Nios runs down if I compile the Nios and peripheral togather. No response when I debug/run the program on Nios. Even "hello world" could not be run on it. I launch FS2 console window and find such instructions of "ldhio gp -16536" at the beginning. I think the point must break down. I use IDE to debug the codes. Need I make a file of changing the debug options? Thanks.Honored ContributorTo change the debug options just open the software projects you have created and modify that from there. To change the level of the debug module you have to do that in the NIOS II core itself (double click it in the GUI).
But I think the first thing is to determine whether it's software or hardware causing this (depending on what you do, just blame the other hehe). Are you able to build the hardware with your custom peripheral and run lets say "hello world"? (if this doesn't work then I believe your problem is a hardware issue). In the case it is hardware related check out the results from the timing analysis (fmax and slack times). I've managed to have designs fail that barely clear fmax due to signal jitter, maybe this could be a problem with your design. Unfortunately I'm not sure if I can think of anything else unless you find more information that you can provide.Honored Contributor>To change the debug options just open the software projects you have created and modify that from >there. To change the level of the debug module you have to do that in the NIOS II core itself (double click it >in the GUI).
I have thought you mean that I could modify the dubug makefile to get more information. I know two methods you mentioned above. However, it can only change a few conditions. >But I think the first thing is to determine whether it's software or hardware causing this (depending on >what you do, just blame the other hehe). Are you able to build the hardware with your custom peripheral >and run lets say "hello world"? (if this doesn't work then I believe your problem is a hardware issue). Yeah, even "hello world" could not run. Surely it is a hardware problem. >In the case it is hardware related check out the results from the timing analysis (fmax and slack times). I've >managed to have designs fail that barely clear fmax due to signal jitter, maybe this could be a problem >with your design. I clear fmax value on timing settings. I looked up the timing analyses result and found many difference between only Nios version and Nios with customer peripheral embedded version. I have no idea which are important factors. How can I assign tsu/th/tco/tpd values and which one I should set. >Unfortunately I'm not sure if I can think of anything else unless you find more information that you can >provide. Please give me some hints which kind of information should be provided. I am wondering.
