New Contributor
New ContributorHi steve_ht,
If the design fails to meet timing (i.e. negative slack) then it would be expected that the Nios processor would not run code and also not be able to use niosii-download to download a new FW image.
I would recommend reviewing the design to ensure it is completely constraint, that all cross clock domain crossings are handled correctly, and that only designs that close timing are used in HW. The Quartus Timing Analyzer Cookbook (https://docs.altera.com/r/docs/683081/current) may also be a useful resource for creating timing constraints.
New ContributorHi kbrunham,
Thanks for sharing the document. I am familiar with the basics of timing constraints but I really have no idea how to add constraints to such a complex official IP cores like the Altera UniPHY DDR RAM controller.
BTW, I added "Auto Global Clock" option to the fitter which made situation much better. Now timing seems to be OK. It is a bit surprising why this is OFF by default.
I still have some starting problems with NIOS. It seems to be some bootloader issue at this point. I found that using a hex file from another NIOS project to init the NIOS dedicated OC RAM improves the situation.
So should I generate my own bootloader regardless I download SW by nios2-download directly after downloading the FW? Or how should I handle this?
BR,
Istvan
New ContributorHi Steve_ht,
Could you review the Multi-Corner Timing Analysis table from the timing analyzer to see if you have any clocks currently failing timing? Ensuring your design closes timing as a first step will be critical.
The DDR IP includes the timing constraints it needs. You shouldn't need to create your own constraints if you are using Altera IP.
Global Auto Clock controls promotion of clocks that are not otherwise automatically on a global network. PLL outputs for example are automatically on global clocks.
There are many different bootloader options available for Nios. For example you can load from flash into RAM. Given that you are starting with an existing design I would suggest you just stay with what you currently have in your BSP. Can you review your BSP using the BSP Editor and let me know what it is? The most straightforward configuration is to execute code right from initialized block RAM.
New ContributorHi kbrunham_altera,
Here is the Multi-Corner Timing Analysis Summary of latest FW version:
It seems to be fine to me. Unfortunately, NIOS does not start with it, even with the previously working hex file included in the BRAM:
Currently I am using ByteBlaster cable to download FW/SW via JTAG. So I am not going to use any flash booting.
Here are BSP settings:
They seem to be OK too.
New ContributorHi steve_ht,
Agreed that your design looks timing clean to me. The BSP also looks ok, but can you share the "linker script" page?
Would I be correct that you are expecting output to the JTAG console? I cannot tell, but do you have the JTAG UART in your system?
Maybe the thing we need to do here is start from a known working system. I believe you have an existing design and you need to change that. Am I correct? Does that existing design work?
