ContributionsMost RecentMost LikesSolutionsRe: Cannot build smallC lib for Nios II with FPH2 I did some further tests: There seems to be a linker bug -> because if I just generate the newlib folder (empty) compilation runs through but at the first point it uses the newlib the processor reboots. This should not happen linker should throw an error that the newlib binaries are not available!! If I copy the newlib binaries from a 22.1 compile everything works fine! I then generated the hello world project (the normal one, not the small one) and it does not compile as well, it stops with the exact same error. So my conclusion is that there is a bug in compilation of the newlib (I use the floating point hardware 2 as well) and a bug in linker because it should throw an error if the binary is not available! @intel/Altera employees How to continue with that? This is a major blocker for my project! BR Erich Re: Cannot build smallC lib for Nios II with FPH2 Hi Minhlee, hi Aik Eu! I have exactly the same issue. The smallc newlib compiles fine with Quartus 22.1 but not with Quartus 23.1 Configure smallc newlib -> COMPLETE. Compiling newlib for a smallc C library... nios2-newlib-gen: Unable to Compile smallc newlib Makefile:803: recipe for target 'newlib' failed make[1]: *** [newlib] Error 1 I have Windows 10, WSL1 and Quartus 23.1 Standard (same behavior with 23.1.1) installed. It seems that my code does not use the newlib at all, because if the "newlib" folder is there (empty), make does not even try to compile the newlib and compile runs through without issues! This is a very strange behavior. I tried to disable in BSP Editor the following points: enable_reduced_device_drivers, enable_small_c_library, enable_lightweight_device_driver_api but it still compiles the newlib! BR Erich Re: LogicLock Arria10 issues with Platform Designer projects Hi Richard! Solution 2 seems to work: "*|*:calibration|*:adc|*" And I tried something similar than "*|*:calibration|*:dac|output[*]" and that worked as well! May it be that if one of the logic locks fails due to an error the others are failing as well? I changed the first few logic locks for testing reason and the warnings of the other logic locks vanished as well?! BR Erich Re: LogicLock Arria10 issues with Platform Designer projects Hi Richard! I'm using the Standard version! Do you have any information when there will be a solution? It seems that the Signal Tap Logic Analyzer has the same issue! I am working with Quartus 18.1 Standard because this is the last version which does not need Windows Subsystems for the NIOS generation. I really need a solution for that issue! BR Erich Re: LogicLock Arria10 issues with Platform Designer projects I need to push it up again, until now there was no suggestion to solve the problem. As this topic is now open for more than a month I request a proper reply from an Intel FPGA employee! BR Erich Re: LogicLock Arria10 issues with Platform Designer projects My experience is that if one directs the fitter with some logic locks for some parts of the design, especially those where timing violations occur randomly, the fitting result is much better and fitting is done faster! No it is my own IP for an high speed external ADC. I used this in a Cyclone V and Arria V and made good experience with LL there. Nevertheless even if it wouldn't be necessary this random naming of Platform Designer seems to "kill" the LL feature which is really bad in my opinion. LogicLock Arria10 issues with Platform Designer projects I'm having a big Platform Designer project with Quartus Prime 18.1 (there is a good reason why I use this version but should not be the topic of this issue) With an Arria10 the Platform Designer generates the hierarchy names with version number and random IDs (see snipped in the hierarchy.png). If I would like to have a logic lock now on the "ADC" module to locate it near the I/Os I would need to use wildcards because the random number (red marked in the image) changes with every Platform Designer generation. But if I use wildcards on the hierarchy the Logic Lock does not work and throws the warning: Warning (140116): One or more LogicLock region membership assignments are unused and Warning (140117): "*:calibration|*:adc" in region "calib" So now the question: how to overcome that? Re: BUG - Fir filter coefficient read mode Hi Chee Pin! Yes I have a concern regarding that topic! In real live there is always a valid address assigned to the input. If the filter has 256 coefficients there is then no invalid address possible because input width is exactly 8 bit! So in a real implementation the valid would be always high! By the way, you should not have negative addresses ;-) Best regards, Erich Re: BUG - Fir filter coefficient read mode Hi Chee Pin! No it is not just a documentation issue! If output is always valid (valid signal high) without a request I see that as an implementation issue/bug! Best regards, Erich Re: BUG - Fir filter coefficient read mode Hi Chee Pin! Really? Do I really need to explain it? First what you described here: https://forums.intel.com/s/question/0D70P000006INUJSA4 Valid is always high!!!!!!! Read request is not necessary! Why is there then a read request signal????????????????????????? Data changes one clock cycle after, the manual states 3!!!!!!! Reset signal seem not to be necessary for read The waveforms for reading in the manual shows a reset upfront!!!!!!!!!! Behavior between Quartus 15.1 and Quartus 17.1 is different but manual does not show any difference! Maybe even Quartus 18.1 behavior is different but there is no new document for that! Best regards, Erich