I am asking for comments on my project. It is a custom component used with SOPC builder, its purpose is to allow many more time critical functions to be programmed in C. When these functions are done in HDL, the verification is more complex than if done in a processor which should be reusable once verified. A program is used to parse the C code and generate content for memory blocks that hold the data and controls for the processor. The processor is designed to minimize the number of clock intervals to execute the C code. The Current size is 151 logic cells, 43 logic registers and fmax about 140 MHz. The bulk of the hardware is counted but some decoders and glue logic do have to be added. The final size should be such that multiples can be used according to the time critical function needs. SOPC Builder can have multiple Nios's but I think too expensive, also there will be advantages from reducing the number of functions in one processor, but I don't have a good handle on the inter-process communication traffic. Thanks, I appreciate your time. I am attaching a cycle log that shows the activity for a few C statements.

Hi SimKnutt, I believe you mean designing custom processors from fpga logic and memory. i.e. designer decides that their work is too complicated and slow for HDL and that software(nios...) is too slow for it. So they decide to go for custom oriented processors inside fpga. The problem is getting new tools and compilers to move from C to your custom processor level. So it needs a real industrial weight. Hope you are well. kaz

--- Quote Start --- Hi SimKnutt, I believe you mean designing custom processors from fpga logic and memory. i.e. designer decides that their work is too complicated and slow for HDL and that software(nios...) is too slow for it. So they decide to go for custom oriented processors inside fpga. The problem is getting new tools and compilers to move from C to your custom processor level. So it needs a real industrial weight. Hope you are well. kaz --- Quote End --- The file attachment was generated by the software that takes C code input, generates the memory contents, and simulates the hardware. I believe that the word 'compiler' generally means: Parse, generate assembly code or some other intermediate language, then generate machine language which everyone assumes is just one of many instruction sets which only differ slightly. The point is that C statements are either assignments or statements that are essentially test a condition/relation then do one of two things. Also the number of cpu registers is very important and a lot of effort is spent allocating registers. All registers are in a ram block in this design so the access time is the same as if in dedicated hardware. There can be as many "registers" as the application needs. Probably the C++ question will come up. The point is what you described above. We are talking about the situation when doing a function in HDL is difficult, but time constraints do not permit a software implementation. Therefore, I contend that C++ support is not required and that a subset of the C standard is all that's necessary. We are trying to make things a bit easier than HDL. As an aside, my program uses objects and clocking like the actual hardware operates. I run in debug mode to see what the hardware does at each clock. With an understanding of the design, a user can see what the hardware is doing at each clock at a functional level. This is part of the package because I had to have it in order to design the thing. Thanks, kaz I am well and appreciate the comment. Be well also.

Hi SimKnutt, Thanks for your comments. Your thinking is certainly valid and interesting. However, the trend of the new generation industry is towards automating complex functionality to higher levels like C or just blocks(simulink) then the converting the work from the high level functionality down to HDL or direct to fpga bitstream bypassing HDL. There is heavy investment in that area between Mathworks,Xilinx and Altera...etc This approach maintains the speed of direct hardwiring. The new generation engineers have yet to prove that these tools work practically...

I have a lot of trouble understanding how a designer can ever comprehend the complexities being created. multicore and parallel programming are full speed ahead with very little explanation of how well it will work. Here's my take on multicore, Intel saw maybe half the processor cucle were spent waiting so dual core came along and improved performance(how much?). Well if 2 is good, many, many will be better. But what if two used up all the cycles, did 3 and 4 steal cycles from 1 and 2 causing them to slow down? I have read in some forum that multicore actually does run slower for unknown reasons. Sure parallel programming is a part of supercomputers, but look at the number of processors. In the case you mentioned if something doesn't work quite right, does the designer have to use timing simulation to debug logic never before seen? While I wish them luck, I fear it may just be an academic exercise. There was a Microsoft research into why FPGAs are so fast compared to a processor and they found the processor spent a lot of time fetching instructions. They missed the point that you mentioned, parallelism in the FPGA. My design uses that parallelism very much because several rams, counters, etc are used in parallel. Please think about the demo code running in 48 cycles and maybe just guess at what it would take in HDL. That is the margin of performance to be gained at whatever cost. My design could be put to use quickly while that research could continue in parllel. Thanks again, I enjoy a good discussion.

I just reread your reply. I am not talking about designing a new processor for each case. but I am talking about scaling one design according to the size of the code and number of variables/constants. Probably, it would become a megafunction that would also be a custom component in SOPC builder. The "customizing" would be to set the ram and counter parameters and load the rams with data, which I think is similar to adding an Nios as a peripheral controller, but it is much smaller.

A new processor | Altera Community

14 Replies

Altera_Forum
Honored Contributor
15 years ago
Are you willing to show/share the design so it can be discussed more directly?
Altera_Forum
Honored Contributor
15 years ago
Hi SimKnutt and BuGless,

May I take the freedom to answer the question since Simknutt already had explained that and also responded to the other thread about schematics and referred to me - many thanks.

The idea of Simknutt is quite simply this - as I understood it last year:
use mutiple parallel simplified mini-processors to implement the FPGA design instead of hdl or anything else.

FPGAs are rich in memory and if softwrare takes say "n" clock cycles then using "n" parallel processors will result in equivalent functionality of hardwiring !!

The concept is not new but seems sensible as any mutiple processor system, but surely altera or xilinx or somebody else would have quite easily gone that way if it was worth it. It will need substantial supporting tools before the field designer is told to steer away from hdl by their bosses.

Already there are tools that translate C to HDL or C to bitstream and surely they will exploit parallelism. None has the attraction of handcrafting available to the hardwirer.
Altera_Forum
Honored Contributor
15 years ago
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.
Altera_Forum
Honored Contributor
15 years ago
Hi I posted a reply, then deleted because I expected it to go to the other forum.
Anyway, I am willing to share and have some downloads on a website. Also tried to do a CEngine project on Google but dont know enough to manage a repository.
http://mysite.verizon.net/vzeosqt4/embeddedcengine has an .exe and demo test case for download. Hope it works, I am a novice at site building.

Forum Discussion

A new processor

14 Replies

Recent Discussions

NIOS SDK SBOM/FOSS info

JTAG_UART stuck in printf

Recommended Quartus Prime Standard Edition for Nios V Development on MAX 10 FPGA (10M25DAF4817G)

University Program IP for NiosV

NiosV µC/OS-II