Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
My application requires fairly high speed data acquisition (4Gb/s). To do this in absence of some integrated solution, we use FPGAs. This gives us basically Cortex A9, Xilinx Microblaze, or Altera NIOS as possible processors. The market is not huge. Perhaps a few 10Ks/year. However, if I don't ask, I can assure not possible support.
Probably FreeRTOS works as well as anything. Currently I've a Microblaze, and the current setup probably won't work, because it hasn't enough RAM to support any RTOS at all + app (128K total memory). So, any of the three would ultimately be acceptable. I've verified that (at least on Xilinx A9) I can port. I haven't tried porting to Altera. Probably, your best solution would be the A9 since it is common to both the Altera and Xilinx community.
My problem is that we have data paths that are MUCH faster than can easily be supported by any processor system (sort of 4Gb/sec minimum per active channel; 4 channels max). This means we always have an FPGA (or an ASIC). And, preference is always to have the data memory inside the address space of the processor to avoid weird data access problems.
On rethinking this slightly, it is likely that I can make a Microblaze work using Execute in Place out of programming flash. Clearly, some form of cache would be useful for that. I haven't data on Altera's XiP capabilities, but suspect this might be a solution there as well. This also reduces the RAM overhead on the A9 solutions, probably meaning that the L2 cache can provide enough RAM for the true variables (and maybe for commonly used code as well).
IF this actually is feasible (I don't see this getting tested soon, so let's assume it works), than any of the solutions (A9, Microblaze or NIOS) is viable.