Interface of FPGA to Microcontroler IRQ, pooling or delay

[Altera_Forum]

Hi, all  

General question especial to experienced developers regarding CPU - FPGA interface.  I Would be very glad to receive any comments or thoughts share.    Say, there is some measurement that the FPGA has to perform, This measurement takes no more then 1ms which is 1% of Microprocessor usual task duration.  The measurement starts by Microprocessor writing to some write only register implemented in FPGA.   After FPGA completes the measurement, the result is written to read only register in FPGA.  The question rises, how does Microprocessor know that the measurement is over, and result is valid?   There are three main possibilities   1. No indication from FPGA is provided, but the spec defines minimum delay that Microprocessor has to wait after triggering the measurement and before fetching results.   2. Pooling: Some sort of indication - say, another register, that has to be read to check for measurement completion.   3. Interrupt request.   How are usually things implemented, is there any legitimacy to choose the first possibility (seems as if it introduces unnecessary coupling...), or maybe pooling is usually preferred to Interrupt request? What would you choose?   Any Comments are welcome.

[Altera_Forum]

--- Quote Start ---   There are three main possibilities   1. No indication from FPGA is provided, but the spec defines minimum delay that Microprocessor has to wait after triggering the measurement and before fetching results.   2. Pooling: Some sort of indication - say, another register, that has to be read to check for measurement completion.   3. Interrupt request.    --- Quote End ---  Implement the following;  1) An Avalon-MM slave set of registers with the following registers;  control register:  * enable   * mode = one-off, repeated  * interrupt enable  status register;  * done (for one-off mode)  repeated measurement period:  * a counter load value, eg. for 1ms repeat time conversion register: * a read-only register with the conversion result  2) Polled Mode:  You can implement polling by enabling one-shot mode, and reading the status register for the done bit. You then disable and re-enable the controller, and repeat.  3) IRQ Mode:  You can enable the interrupt, and when 'done' asserts, also have that status bit assert an IRQ on your processor. The processor IRQ can then disable/reenable the controller.  4) If you want more accurate time between measurements, then enable the controller in repeat mode, and set the logic up to give you an IRQ every conversion. The IRQ would just read the conversion, and leave it running.  If you were worried about losing conversion results, or you wanted to process blocks of conversions, then you can add a FIFO and have the hardware write results into the FIFO. Eg. think of how a serial port receiver operates.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Hi, all  General question especial to experienced developers regarding CPU - FPGA interface.   I Would be very glad to receive any comments or thoughts share.    Say, there is some measurement that the FPGA has to perform, This measurement takes no more then 1ms which is 1% of Microprocessor usual task duration.   The measurement starts by Microprocessor writing to some write only register implemented in FPGA.    After FPGA completes the measurement, the result is written to read only register in FPGA.   The question rises, how does Microprocessor know that the measurement is over, and result is valid?    There are three main possibilities    1. No indication from FPGA is provided, but the spec defines minimum delay that Microprocessor has to wait after triggering the measurement and before fetching results.    2. Pooling: Some sort of indication - say, another register, that has to be read to check for measurement completion.    3. Interrupt request.    How are usually things implemented, is there any legitimacy to choose the first possibility (seems as if it introduces unnecessary coupling...), or maybe pooling is usually preferred to Interrupt request? What would you choose?    Any Comments are welcome.  --- Quote End ---     - Presuming that this reading from the FPGA is not time sensitive thing then an interrupt would probably not be appropriate, regardless of the duration of time for the FPGA to complete the task. - If there are other reasons why the processor would need to query the status of something else in the FPGA for things that are again not time sensitive, then polling of these registers would be the best approach. - Setting a status bit to indicate completion of the task is the better approach. Otherwise the processor is required to keep track of the elapsed time...yes it certainly can do it, but ask yourself why should it? Then ask yourself how hard is it to set a status bit at the completion of the task that you are controlling anyway.   So# 2 is the best approach unless you have some time sensitive requirement that you haven't mentioned that might push you to# 3.   Kevin Jennings

[Altera_Forum]

Just my 2 cents: 

I agree with Kevin in the fact solution# 2 (polling) is the normal approach. But I think this is the simplest solution, not necessarily the best one. It's the simplest because it requires no additional hw and you easily implement the poll function in sw. Anyway, as Kevin remarked, this is not the best if your system is time critical, besides being rather inefficient, since your cpu task is forced 1ms busy in the polling loop.  This gets worse if your measurement has to be performed often. So, if you have strong requirements on cpu time for other tasks and you need frequent measurements, the irq solution should be privileged, at the expense of a bit more complex hardware. I'd exclude the fixed time solution# 1, since it has inherently the same defects of the polling as well as being hw dependent: whenever you change your fpga function you possibly must tune the delay time for optimal performance. In the case you choose the polling method, I'd suggest you implement the completion status signal as a microprocessor pio/flag-input rather than a status bit on a MM register: this will be faster and more energy efficient because your cpu doesn't need to access the bus on every poll.  Regards Cris

[Altera_Forum]

--- Quote Start ---  since your cpu task is forced 1ms busy in the polling loop.    --- Quote End ---     Actually I would not expect the CPU to be stuck in a polling loop for 1 ms churning away doing nothing. Rather I would expect the CPU to come back periodically as part of a larger polling cycle (i.e. maybe the processor wakes up once every XX ms to see if there is anything that needs attention).   Kevin Jennings

[Altera_Forum]

I'd definitely go for interrupt implementation. Then connect interrupt output to external interrupt input to cpu.