about component made by user logic

[Altera_Forum]

hello, 

  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!

[Altera_Forum]

Could you give more specific information about the system you are having problems with.

[Altera_Forum]

Thanks 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?  Still

[Altera_Forum]

Are 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.  Cheers

[Altera_Forum]

I just used the S Core for my application. Just instruction cache be embedded on Nios's running. Anything wrong with such constructions?  

 Thanks.

[Altera_Forum]

Nope 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.

[Altera_Forum]

It 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?

[Altera_Forum]

You 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-luck

[Altera_Forum]

Perhaps 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.

[Altera_Forum]

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). 

 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.

[Altera_Forum]

>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.

[Altera_Forum]

Yes when you add your own hardware to an SOPC system you can have some negative effects on your timing (especially if you do a custom instruction). I would just set some fmax for your system to allow the compiler to route accordingly, also there are other settings that you can enable in Quartus that will slow down the compiler but it may give you better timing results. 

 It's possible that the timing that you have set for your custom interface is not enough for your custom hardware that you have added to your system. Another question I have is do you have an address space in your custom hardware or it just a simple read and write interface? (PIO may be what you want to use then). If you do have addresses out there then make sure you decode those properly to ensure that you are latching your data properly. To determine what is causing timing problems you look at the worst case paths and look at the source and destination points, and its usually enough information to determine the problem (since you are looking at the data path causing the problem).  There is another thing to keep in mind and that's multi-cycle registers. If you have logic that depends on data that Quartus can not anticipate properly (like external I/O for example), then it may be assuming that the register only has one clock cycle to latch whereas they may have two or more in reality. Before jumping the gun on that idea though make sure you understand that concept and read up on the multi-cycle settings for Quartus.  My last question: Is this a school project or is it for work? (i.e. do you have to keep most of this disclosed or can your design be shown, because if I saw the design I could probably figure out the problem)

[Altera_Forum]

Thanks for your information.  

 We finish the custom hardware with an address space for data transmission. And it works perfectly in accordance with the timing requirements on testing.   I use the default option for fMax setting but clear the default value. I think it will make the fMax equal to the system clk. Then I calculate the max worse delay from some important pins to others. And then setting the corresponding value for IUL and SRAMs thru .ptf file. It can wok now. Further verification will be tested soon.   Thanks.

[Altera_Forum]

Unfortunately, when I finished the settings mentioned above, another custom hardware could not work correctly. It always works well before. Can you give me some suggestion?

[Altera_Forum]

Are you using two seperate custom instructions, or one with functionality selection using the "n[7..0]" selector bits? Are you clearing fmax by a few MHz? I have seen jitter cause a NIOS to fail even though fmax was maintained (but I cleared it only by one or two MHz).

[Altera_Forum]

Yeah, I create two user logic to finish the special tasks. Then I read the results from fifo of IUL linking to them. I assign 100MHz to fMax. From the timing analysis report, some slacks are out of requirements. But I have no idea which one I should set the constraints. Can you give me some hints?

[Altera_Forum]

oh ok, then that's the cause of the problems. When you add additional hardware to the NIOS, sometimes (well often actually) you impact the timing of the NIOS as well. 

 First I would try to use some of the built in optimizations from Quartus to bring up the fmax.  Analysis & Synthesis Settings --> Optimization Technique --> Speed  |  ----> Synethesis Netlist Optimizations --> Perform WYSIWYG re-synthesis  Fitter Settings --> Standard Fit  |  ----> Physical Synthesis Optimizations --> Turn them all on   Those are a few to try (if you are just under the fmax you want you probably don't need all these turned on), just remember your compile time gets longer with some of these turned on.  Also you have set fmax to 100MHz in your timing options right? What are your negative slack times (the red ones), and associated frequencies of those (if any). Another question I have is, do you use the same system clock in your IUL hardware as the NIOS? (If you have multiple clock domains you need to be careful with your design).

[Altera_Forum]

Yeah, I have chosen all the possible optimizations for the project. Although the Nios and peripherals run in asynchoronizing mode, only one system clock be input here.  

 Yeah there are some worse slacks between such interfaces. How can I do some modifications? Some are not important because they are not run in synchoronizing mode, I think. Right? So which one is the first to be constrained?   Thanks

[Altera_Forum]

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

--- Quote Start ---  Yeah, I have chosen all the possible optimizations for the project. Although the Nios and peripherals run in asynchoronizing mode, only one system clock be input here.[/b]  --- Quote End ---    I&#39;m a little confused about that. So you don&#39;t run your custom hardware at the same clock? If that&#39;s the case then you need to synchronize the interface to your hardware so that the data gets across properly.  I will need some more information about the system now (NIOS and the custom hardware) because I&#39;m drawing at straws here.

[Altera_Forum]

The architecture is as follows 

 i) Custom Logic I -> FIFO -> IUL (Read) - Nios - IUL (Write) -> FIFO -> Custom Logic II  ii) A PLL provide a systme clk to such logic blocks respectively. They finished the information transmission thru FIFO.   I have no idea that the above is enough?

[Altera_Forum]

Ok, in your timing volations look at the source and destination to determine where these critical paths are (I&#39;m guessing it will be between the FIFO and IUL). 

 Also just to be sure all those blocks are driven with the clock from the PLL correct?  Have you tested these two combinations first to make sure they meet requirements? -- Custom Logic I -> FIFO -- FIFO -> Custom Logic II  But if I had to guess where the problem is it would most likely be a timing mismatch between the FIFOs and the IUL (but find out where the critical path is first before attempting a fix). Once you know the critical path then you can focus your efforts on the interface causing the problems. Also with the FIFOs make sure that the IUL timing is what your FIFO needs, take a look at the time diagrams for the IUL in SOPC builder and verify that will not break your FIFO (I usually use that timing information to simulate my external hardware before dropping the NIOS core into the system).