I did not make my point clear now that kaz explained his understanding.
1. There are many processors used "because the design is too complex for conventional methods." OK, then comes an RTOS or whatever, interrupt handlers, shared memory, etc.
2. Much of the application is coded in C, but real time responses seem to tax the speed of the processor, so multi cores and parallel programming come into play. I feel that there are still shared resource issues. And these techniques are too complex to tuck away inside a chip.
3. SOPC builder has capability for multiple NIOS's, but they are expensive physically, and I think that would be over kill just to handle mainly the real time response for the peripherals.
4. The peripheral processor is to manage the control of peripherals as cheaply as possible, it is not to replace the peripheral by any means. It is a custom component used by SOPC builder, but it is programmable so the hardware is constant physically.
5. Here is a tough one. It is common knowledge that C source code has to be compiled to some intermediate language and then to the processor native language. Also the processor uses conventional von Neumann architecture and it takes several if not many machine instructions to execute a C statement. This does not apply to the CEngine because it is designed to handle C code directly. This is not my first cpu design.
6. The fewest clock cycles are used so it is fast, The C code to do the simple functions should be small and a few M9K blocks should do the job.
To summarize: Use SOPC builder, use existing peripherals, use NIOS and whatever OS, use HDL to design new things and if those new things are memory mapped IO, use CEngine to off load real time response functions when to build a system.
The term multi processor may imply shared memory for instruction storage, if so it does not apply. Distributed processors may or not be a better term. Hard to say.