microCore-VHDL
commented
1 year ago Do you have any changes you want made to this design? Any wish list? Is it just perfect as is?
I have no changes. The development startet in 2001 and it definitely has matured. I modified the instruction set several times but the source code remained the same. Instruction changes have been hidden using appropriate macros or calls. The next big step would be a core with 16 bit instructions. That should result in a 5 times throughput increase. Personally, I have never reached the performance limit of uCore using it for embedded control systems, see uCore-Applications.pdf for a talk on projects I have done with it. uForth.pdf discusses some of the challenges of the cross-compiler.
My wish: Optimization of the instruction codes. As you will find out when you modify the instruction constants in architecture_pkg.vhd, the assignment of code-numbers to instructions has an influence on the synthesizer results and the number of logic blocks used. Therefore, I am still dreaming of an optimization suite that replaces the numbers by states of an 'instructions' type vector. Letting the state machine optimizer of the synthesizer work on this should produce an optimum opcode assignment for each instruction w.r.t. resource usage.
Also a link to your website from this repository would be helpful. Maybe there is one, but i did not see it. Is this you? https://microcore.org/
This WAS me. I let microcore.org expire. But mysteriously, it is still there showing a completely outdated design. After 20+ years I am unhappy with the name 'microCore'. For one thing, its not 'micro', it became high performance. I would like to rename it forthCore instead. Which is also a sort of misnomer, because after all it is a high performance processor that can efficiently execute almost every high-level language. The unusual requirement for a 'language' front-end is that uCore requires stack allocation rather than register allocation for efficiency.
You mention RS232. I do not have an RS232 cable. All of my cables are usb. Sure I can buy a converter, but it would be nice if your device supported USB. Maybe it does.
It does not. If you want to implement a serial usb transceiver on both sides (host and target): Go ahead. Good luck. A USB to RS232 converter from Prolific is perfect, because it does not introduce delays in the communication as most other USB converters do. And when you port uCore to another project, you just have to set aside one input and one output pin for the umbilical link that connects to the debugger on the host.
Some statement about what limits the clock speed would be interesting. What is the slowest module, aside from two clocks to read data?
I never took the time to analyze this, because I always had a concrete problem that needed to be solved. And - as I said above - uCore always outperformed my applications. Even if you can pinpoint a certain instruction to be the limiting factor: There is not much what you could do besides dividing up the functionality into two instructions, which will always be assembled using a macro.
Is anyone interested in a whole bunch of these running on an FPGA?
Not that I knew. I have the impression that this is an interesting research topic, but I don't see real applications let alone customers. At least in the field of embedded systems.
Personally I like the idea of lots of forth words implemented. But the mainstream world does not like that, they like lots of small instructions, so some defense of it would be most interesting to read.
It took me a long time to decide, which Forth instructions are really necessary. In the end I decided that everything that can be done in two instruction macros are not worthy of a single instruction. In uCore there are lots of 'small instructions' but also quite complex ones. Because we know from 50 years of using Forth that those are important. This is the type of know-how 'general purpose' machines can not build on. Usually, the utmost they do, are 'frame' / 'unframe' multi-cycle instructions, which are needed, because the damn thing has only one stack. This also produces a dissuasive runtime overhead for function calls. Btw: Poor_man's_compilers is a paper on why I love Forth.
A link to your microcore talks would be most interesting . I found this one. https://www.youtube.com/watch?v=KUem5EREkAI. Have you done any other talks in the past?
I have done a several talks on the monthly FIG and Forth2020 zoom conferences. Check youtube and search for 'schleisiek microcore'.
PythonLinks
This is a very interesting project. I am doing a master's program in digital design, and am planning on doing something with this. Not quite sure what. Add a few functions, turn it into a barrel processor, maybe write a python simulator, or convert to verilog. Maybe something else.
Do you have any changes you want made to this design? Any wish list? Is it just perfect as is?
Also a link to your website from this repository would be helpful. Maybe there is one, but i did not see it. Is this you? https://microcore.org/
You mention RS232. I do not have an RS202 cable. All of my cables are usb. Sure I can buy a converter, but it would be nice if your device supported USB. Maybe it does.
Some statement about what limits the clock speed would be interesting. What is the slowest module, aside from two clocks to read data?
Is anyone interested in a whole bunch of these running on an FPGA?
Personally I like the idea of lots of forth words implemented. But the mainstream world does not like that, they like lots of small instructions, so some defense of it would be most interesting to read.
A link to your microcore talks would be most interesting . I found this one. https://www.youtube.com/watch?v=KUem5EREkAI Have you done any other talks in the past? And if you are doing a talk at the German forth user group this week, a link to a youtube recording (with English Subtitles) after the event would be most wonderful.