Putting the mcu inside the fpga creates a larger complexity with development (fpga dev chains/compilers, tools, etc). Also it is quite difficult/laborious (!!) to create all those peripherals you may find easily in any standard mcu.
Of course it depends on the application, the datarate, and amount of data you want to process inside the mcu.
Putting the mcu inside the fpga creates a larger complexity with development (fpga dev chains/compilers, tools, etc). Also it is quite difficult/laborious (!!) to create all those peripherals you may find easily in any standard mcu.
Of course it depends on the application, the datarate, and amount of data you want to process inside the mcu.It depends in the device. Xilinx for example offers an MCU softcore with the full set of peripheral IPs for free, and includes intergrated toolchain & IDE with live debigging for software development which makes firmware development a breeze with zero HDL knowledge required (unless you want/need to implement some custom peripherals). It's actually much easier than using separate FPGA and MCU toolchain, because here it's all unified in a single package.
Thanks for clarifying. I'm not at all knowledgeable about the MicroBlaze core, but that certainly does look like an ideal (and extensible/scalable) solution. Just to confirm, is Vitis the software development platform you mention? I assume I can design both hardware and software in Vitis, or would I need to use Vivado for the hardware and Vitis for MicroBlaze?
I'm considering a particular application and would very much appreciated some thoughts and/or recommendations.
I've used a particular MCU on a number of projects, and am now looking at a slight variation on a previous design, for which I'm considering the addition of an FPGA. I need to measure (frequency, duty cycle, etc.) a number of input signals (12+), and perform deterministic timestamping of each input at a specified rate (i.e. 100Hz). I've achieved something similar using the MCU with high priority interrupts in the past, but the overhead of servicing these interrupts, as well as the jitter of the timestamping function make this approach unsuitable in this particular application. I also looked at using the Timer Counter (TC) functionality of the MCU, but despite having 12 16-bit counters, there are only three available external inputs, which obviously doesn't suffice.
As such, I'm considering an FPGA to receive these digital inputs. The FPGA would perform the required measurements on the inputs, and then timestamp the latest measurements (across all inputs) at a specified, deterministic frequency and present the timestamped results to the MCU for further processing. I'm not quite sure how best to approach the MCU-FPGA interface, and would be very open to recommendation. A simple SPI/QSPI interface would probably do, but perhaps an AHB master/slave arrangement could also work.
I have the Petalinux running on the ML-605 Virtex 6 board (the stock example). No idea how they did it with the ISE 13, it had to be pretty intense exercise, imho.. I ran my microblaze on Spartan 6 with some basic i/o (ISE 14.7) and it took me a month messing with all the missing information I needed to build a running version with some simple C code..
I'm considering a particular application and would very much appreciated some thoughts and/or recommendations.
I've used a particular MCU on a number of projects, and am now looking at a slight variation on a previous design, for which I'm considering the addition of an FPGA. I need to measure (frequency, duty cycle, etc.) a number of input signals (12+), and perform deterministic timestamping of each input at a specified rate (i.e. 100Hz). I've achieved something similar using the MCU with high priority interrupts in the past, but the overhead of servicing these interrupts, as well as the jitter of the timestamping function make this approach unsuitable in this particular application. I also looked at using the Timer Counter (TC) functionality of the MCU, but despite having 12 16-bit counters, there are only three available external inputs, which obviously doesn't suffice.What timing resolution and bits do you need to capture ? How many edges/second ?
You mention 100Hz, which suggests modest capture rates ? a HW capture module could be SW unloaded fine, at those rates.
As such, I'm considering an FPGA to receive these digital inputs. The FPGA would perform the required measurements on the inputs, and then timestamp the latest measurements (across all inputs) at a specified, deterministic frequency and present the timestamped results to the MCU for further processing. I'm not quite sure how best to approach the MCU-FPGA interface, and would be very open to recommendation. A simple SPI/QSPI interface would probably do, but perhaps an AHB master/slave arrangement could also work.That will depend on how much data needs to move. SPI will always be simplest, until it can no longer shift enough data.
I would look first for a MCU that can manage the captures, as the capture ability on MCUs is improving quite rapidly.
Even the PIO on the Pi PICO might be good enough ?
Addit: The examples I found for PIO suggest it can only wait on a single pin.
The Parallax P2 P2X8C4M64P (costs more in TQFP100), but it can wait on pin-pattern events to 180~250MHz sysclks.
I have the Petalinux running on the ML-605 Virtex 6 board (the stock example). No idea how they did it with the ISE 13, it had to be pretty intense exercise, imho.. I ran my microblaze on Spartan 6 with some basic i/o (ISE 14.7) and it took me a month messing with all the missing information I needed to build a running version with some simple C code..With Vivado/Vitis now it takes about 10-20 minutes (depending on your workstation's horsepower) to get a basic Microblaze system (DDR3, QSPI, UART, GPIO, timer, I2C) up and running if you know what are you doing.
I think the next step would be to purchase a Spartan- or Artix-based board and implement a MicroBlaze solution.
I'm still not clear on the process by which FPGA data (e.g. the input signal measurement data) is made available to the MCU, but I suppose that'll become clear when I start digging into the AXI platform.
The Parallax is actually a really interesting option. I've not used them before, but on paper they would certainly handle this particular task. Having not used that platform before, the assembly language is certainly a bit foreign!
100Hz is just an example in this case. I might see requirements orders of magnitude faster and slower than that depending on the particular implementation. Even if the logging rate is relatively slow, the input signals themselves might be relatively fast, so what I'm trying to avoid is having numerous (12 to 20+) inputs, all with 'relatively' high frequency (kHz+) having to be measured in ISRs within a single core MCU. Each rising and falling edge would need to be timestamped (if measuring duty cycle), which means multiple ISRs per channel, which can introduce a not insignificant amount of jitter in servicing the interrupts, timestamping, etc., as well as in servicing of the other MCU tasks (i.e. ADC result processing, non-DMA memory management, data staging, logging and transmission, etc.).
I'm considering a particular application and would very much appreciated some thoughts and/or recommendations.
I've used a particular MCU on a number of projects, and am now looking at a slight variation on a previous design, for which I'm considering the addition of an FPGA. I need to measure (frequency, duty cycle, etc.) a number of input signals (12+), and perform deterministic timestamping of each input at a specified rate (i.e. 100Hz). I've achieved something similar using the MCU with high priority interrupts in the past, but the overhead of servicing these interrupts, as well as the jitter of the timestamping function make this approach unsuitable in this particular application. I also looked at using the Timer Counter (TC) functionality of the MCU, but despite having 12 16-bit counters, there are only three available external inputs, which obviously doesn't suffice.What timing resolution and bits do you need to capture ? How many edges/second ?
You mention 100Hz, which suggests modest capture rates ? a HW capture module could be SW unloaded fine, at those rates.
100Hz is just an example in this case. I might see requirements orders of magnitude faster and slower than that depending on the particular implementation. Even if the logging rate is relatively slow, the input signals themselves might be relatively fast, so what I'm trying to avoid is having numerous (12 to 20+) inputs, all with 'relatively' high frequency (kHz+) having to be measured in ISRs within a single core MCU. Each rising and falling edge would need to be timestamped (if measuring duty cycle), which means multiple ISRs per channel, which can introduce a not insignificant amount of jitter in servicing the interrupts, timestamping, etc., as well as in servicing of the other MCU tasks (i.e. ADC result processing, non-DMA memory management, data staging, logging and transmission, etc.).
100Hz is just an example in this case. I might see requirements orders of magnitude faster and slower than that depending on the particular implementation. Even if the logging rate is relatively slow, the input signals themselves might be relatively fast, so what I'm trying to avoid is having numerous (12 to 20+) inputs, all with 'relatively' high frequency (kHz+) having to be measured in ISRs within a single core MCU. Each rising and falling edge would need to be timestamped (if measuring duty cycle), which means multiple ISRs per channel, which can introduce a not insignificant amount of jitter in servicing the interrupts, timestamping, etc., as well as in servicing of the other MCU tasks (i.e. ADC result processing, non-DMA memory management, data staging, logging and transmission, etc.).
...
The Parallax is actually a really interesting option. I've not used them before, but on paper they would certainly handle this particular task. Having not used that platform before, the assembly language is certainly a bit foreign!
XMOS xCORE.
XMOS xCORE.Why did I expect to see these exact words from this exact person? I hope you are getting a good commission for all that shilling.