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 ContributorYes 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)Honored ContributorThanks 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.Honored ContributorUnfortunately, 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?
Honored ContributorAre 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).
Honored ContributorYeah, 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?
Honored Contributoroh 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).Honored ContributorYeah, 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? ThanksHonored Contributor<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'm a little confused about that. So you don't run your custom hardware at the same clock? If that'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'm drawing at straws here.Honored ContributorThe 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?Honored ContributorOk, in your timing volations look at the source and destination to determine where these critical paths are (I'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).
