Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorHow to freeze NIOS2 during sensitive measurement?
Hi community,
we currently design a device where we use logic in a Cyclone for very accurate measuring. Beside the logic for measuring, there is a NIOS II in the same FPGA to processing the results. We found that measurement results are affected by the amount of activity in the NIOS and evaluate various methods to slow down or freeze the NIOS while measuring. Measurement takes place at 20 kHz rate and takes the same amount of time as a handful of instructions would. 1. Attempts to simply gate the CPU clock had bad side effects such as missed interrupts. We didn't gate the clock of timers and other peripherals, because they have to keep running with exact timing. 2. Second idea was to generate an interrupt while measuring, so a handler could just make an NOP loop until the measurement is done. But calling the standard interrupt handler at 20 kHz would eat far too much CPU ressources. So a custom preamble code in the exception handler for this particular source would have to be written (we didn't try that yet). 3. Third idea could help to improve results if our problems were mostly caused by access to _external_ SRAM (e.g. for data): To gate the ACK signal from the tristate_bridge so that data access while measuring. E.g. by adding another "bridge" between CPU and avalon_tristate_bridge? 4. We could inject NOP opcode (or rather a branch -1) on data bus during measurement. But that would certainly cause huge problems with instruction caching. 5. Maybe a custom instruction could be used. But then again that would have to be triggered by an interrupt or the like. 6. Is there any other possibility to halt the processor from a source external to the core? Any further ideas, hints, tipps? Thanks in advance Kolja11 Replies
Altera_ForumHow about creating a custom hardware peripheral which asserts waitrequest during the measurement interval? The peripheral could contain a small counter which provides a fixed waitrequest interval, or it could base its waitrequest on an external signal which is active during the measurement (if that signal is available). You'd have the NiosII execute a non-cached data read or write to the peripheral during the measurement, and the niosII would stall until waitrequest is deasserted.
You didn't provide details on how the measurement is fired off, but if it's being controlled by a nios2-controlled peripheral, you might be able to build the waitrequest logic into the measurement peripheral itself. This seems more elegant. I'll assume that the measurement is triggered by one or more register writes to a peripheral - if so, simply change the hardware so that on the final register write, the peripheral asserts waitrequest until the measurement is complete.- Altera_Forum
<div class='quotetop'>QUOTE </div>
--- Quote Start --- asserts waitrequest during the measurement interval?[/b] --- Quote End --- Yes, that is probably the most promising plan. <div class='quotetop'>QUOTE </div> --- Quote Start --- [if] measurement is triggered by one or more register writes to a peripheral[/b] --- Quote End --- The measurement logic fires at 20 kHz on its own. The NIOS accesses the peripheral regularly but only at 1 kHz rate. Therefore my idea with the "blocking" bridge to SRAM (I wrote "To gate the ACK signal" but what you described is what I actually meant - to assert waitrequest).. SRAM is a peripheral that certainly has to be accessed more often. It wouldn't stop the NIOS executing from cache or onchip memory, but maybe it is already sufficient for us to reduce the communication with external components Maybe the bridge could be moved even nearer to the CPU, between instruction master of core and ALL other slaves? I can't image what side effects that would have... The software is based on embOS. If there was a real IDLE thread, it could continously access the peripheral and block when necessary, but actually we utilize the idle time for low priority data processing. Kolja - Altera_Forum
With what are you guys measuring? NIOS peripherals?
Time critical stuff is best done in HDL. Best option would be to perform the measurement in a custom peripheral that buffers the measurement in a FIFO, and if it's too much for M4Ks and you have external memory to spare, create an avalon master. Use an interrupt to get rid of busy-looping, unless it doesn't have any other tasks. Let the firmware assist the software, that's what SoPC is all about. Cheers, Roger - Altera_Forum--- Quote Start --- originally posted by rsteiner+aug 30 2006, 10:28 pm--><div class='quotetop'>quote (rsteiner @ aug 30 2006, 10:28 pm)</div>
--- quote start ---
with what are you guys measuring? nios peripherals?[/b]
--- quote end ---
<!--quotebegin-kawk the measurement logic fires at 20 khz on its own. the nios accesses the peripheral regularly but only at 1 khz rate. --- Quote End --- It is, as you guessed, a custom peripheral with FIFO and several control registers. Kolja
- Altera_Forum--- Quote Start --- originally posted by kawk+--><div class='quotetop'>quote (kawk)</div>
--- quote start ---
the measurement logic fires at 20 khz on its own. the nios accesses the peripheral regularly but only at 1 khz rate.[/b]
--- quote end ---
<!--quotebegin-kawk it is, as you guessed, a custom peripheral with fifo and several control registers. --- Quote End --- So what is creating hiccups, the accesses of NIOS to the custom peripheral or is NIOS not fast enough to process the results (FIFO overflow)? In what kind of memory is code and data located? Cheers, Roger
- Altera_Forum--- Quote Start --- originally posted by rsteiner@Aug 31 2006, 11:13 AM so what is creating hiccups --- Quote End --- No hiccups. There are definitely no "hard" errors or like values missing or read twice from a FIFO. It is simply an increased noise level in the measured values, related to the amount of irregular activity in the NIOS during measurement. Just little, but intolerable. We know that the same FPGA configuration on exactly the same board can deliver measurement results with half the standard deviation, if the NIOS remained idle in an endless loop and we read the values measured by the logic in the FPGA from outside of the FPGA, using an external CPU. Unfortunately I cannot explain the actual measurement procedure in more detail. Logic in FPGA and analog circuits outside the FPGA operate tightly connected. Kolja
- Altera_Forum--- Quote Start --- originally posted by kawk@Aug 31 2006, 12:50 PM it is simply an increased noise level in the measured values, related to the amount of irregular activity in the nios during measurement. just little, but intolerable. --- Quote End --- Ah okay, so your next easy fix would be stalling NIOS with the waitrequest trick as Kero suggested. But that will bring back your missed interrupts, even though it's anytime more elegant than gating the CPU clock. But then, does not have the same effect, some flops might still be toggling. What you didn't mention is where NIOS is getting its code and data from, external memory? Looks to me that you should consider a respin of your board. Cheers, Roger
- Altera_Forum
If possible, make sure your output pins are configured for slow-slew rate, and layout your board so the low-order address bus bits are as short as possible.
Slow-slew-rate is implemented in Quartus5.1 by selecting the Assignments\Pins menu. Then do: Select I/O features, and add the relevant pins (you can do just one under "To"). Choose Assignment Name "Current Strength", Value "Minimum Current", Enabled "Yes". (make sure this is compatible with the devices you're driving - check it with a 'scope) Select I/O timing, "Slow Slew Rate", "On", "Yes". (again make sure this is compatible to avoid double-triggering) We also used "Weak Pull-up Resistor" "Off" on the CLK input. Use a multilayer board, with ground planes. Can the SOPC+SRAM if possible, otherwise use EMI-fingers/gaskets between the board and a metal case. Make sure analogue and digital grounds are separate. Try using internal RAM/ROM for your tight loops, although the address bus will continue to sing. If you can borrow a spectrum analyser it would be an advantage; we have one in-house and it was very useful for establishing EMC. Lastly, you could put the analogue and digital circuitry on separate boards, and use a differential-input ADC such as the following as the input to the digital circuit: http://www.maxim-ic.com/appnotes.cfm/an_pk/1108 (http://www.maxim-ic.com/appnotes.cfm/an_pk/1108) http://www.analog.com/en/prod/0,,ad7450,00.html (http://www.analog.com/en/prod/0,,ad7450,00.html) http://ww1.microchip.com/downloads/en/appn...-input%20adc%22 (http://ww1.microchip.com/downloads/en/appnotes/00842a.pdf#search=%22differential-input%20adc%22) - Altera_Forum
Hi,
thanks for the very elaborate answer! I need to re-check if the slewrate/current settings are optimized as you suggest. Regarding layout, there isn't much room for improvement (I'm really confident you would agree on that after reviewing the board). Separating measurement logic and CPU is possible and would solve the problems, but we currently try hard to reduce the size and number of parts, therefore a single Cyclone has to do almost everything. At the moment, we specifically look for a software improvement (and "software" also includes FPGA configuration). The routing/placement/fitting of the measurement logic already has been manually optimized and "locked" for optimal results. Maybe we should spend some more weeks to optimize the fitting of the NIOS and its standard peripherals. Kolja - Altera_Forum
Hi:
It seems like noise coupling from the digital power supply to the analog power supply (and grounds). It's a very common source of errors in mixed signal systems. If you're sampling very slow signals like temperature, the problem could be solved using oversampling and filtering (FIR, IIR, average, etc.); but if high bandwidth analog signals are involved, the problem SHOULD be solved using careful PCB and decoupling design. First of all, isolate the power supplys and grounds, use ferrite inductors for joining the analog and digital ground-planes. And, try not to pass along digital signals like clocks inside the analog circuits area. Take into account something, there's a compromise relation between PCD size and crosstalk+noise coupling, the shorter the distance, the higher the coupling.
