Dear Ting,

A late Christmas present.

I could convince Steve Teal
to code a microprocessor in VHDL
that I had been carrying around for the last 25 years.

And eForth was implemented by Steve as well.

Together with many tools that Steve did in addition.

He did all of the work, I just supplied what I had from then.

A big THANK YOU to Steve.
See it all on github.

https://github.com/Steve-Teal/eforth-misc16?fbclid=IwAR3J4bW3B0UruEk-_k3J8uzhDp6uX20InJJesv545WFu-gVok14Dd65Nj8Q

misc16-eforth

This project implements eForth on the MISC16, a 16-bit minimal CPU which only has a single instruction 'mov'.
The resources included here:
• Python based MISC16 assembler and simulator
• C based MISC16 simulator
• MISC16 assembly eForth
• VHDL MISC16 CPU core

History of MISC16

The MISC16 project started with an article by Douglas W. Jones:
http://homepage.cs.uiowa.edu/~jones/arch/risc/
Juergen Pintaske saw the article and discussed the approach with his colleagues.
At the time he had visited ARM and ARC in the UK, and this design looked like a “low-cost” ARC,
where additional functions can be easily added memory mapped,
without influencing the rest.
The result was the original hardware version, tested on a CPLD board,
developed in VHDL by Harry Siebert and the Mixed Mode ASIC Design Team.
Some Forth people in Munich were involved later as well after the board was up and running,
mainly Bernd Paysan.
Later on, Juergen Pintaske found out, that this design had been slightly modified at FH Nuremberg
and there then even been implemented as ASIC,
manufactured by AMS as a student project.

Juergen asked Mixed Mode, if this Mixed Mode Design can be published and used elsewhere,
as nobody was using it,
which was granted.

MISC16 Architecture

The MISC16 has a 16-bit address bus,
memory locations 0x0010-0xFFFF can be used for RAM, ROM, and IO,
the first 16 locations are reserved for a memory mapped ALU and Program Counter which implement virtual instructions.
+---------+-------------+------------------+
| Address | Source | Destination |
+---------+-------------+------------------+
| 0x0000 | PC | PC |
| 0x0001 | PC+2 | PC if A < 0 |
| 0x0002 | PC+4 | PC if A = 0 |
| 0x0003 | PC+6 | - |
| 0x0004 | - | PC if C = 1 |
| 0x0005 | - | - |
| 0x0006 | - | - |
| 0x0007 | [A] | [A] |
| 0x0008 | A | A |
| 0x0009 | - | A = A - source |
| 0x000A | - | - |
| 0x000B | - | A = A + source | ADD
| 0x000C | - | A = A xor source | XOR
| 0x000D | - | A = A or source | OR
| 0x000E | - | A = A and source | AND
| 0x000F | - | A = source >> 1 | SHIFT Right
+---------+-------------+------------------+
Program execution begins at address 0x0010,
after which the program counter increments by 2 with each instruction
until it is modified by an instruction whose destination is the program counter (PC).
Reading PC yields the program counter while it’s still pointing to the address of the instruction doing the read,
PC+2 is the next instruction and so on for PC+4 and PC+6.
A is the accumulator which can be used as an index register for indirect addressing.
The accumulator is the destination of the arithmetic and logic operations
and can be used to conditionally load the program counter for conditional jumps.
The carry flag C is also used to conditionally load the PC,
it is modified by the add and subtract instructions, for subtract it becomes borrow.
The carry flag is used in the shift right instruction (0x000F),
here it has the least significant bit of the accumulator shifted into it and its old value shifted into the most significant bit.

Assembler

The Python script 'misc.py' implements a very simple MISC16 assembler; it only understands 5 keywords:
+-----+---------------------------------------+
| mov | Move instruction |
| equ | Assign a constant integer to a symbol |
| db | Define a byte |
| dw | Define a word |
| org | Change current assembler pointer |
+---------------------------------------------+
The assembler uses Python 3.

The following command line will assemble the eForth image,
generating a binary image,
an FPGA memory initialisation file
and a listing file.
python misc.py eforth.asm eforth.bin eforth.lst eforth.mif

The listing file can be viewed with a text editor
and used as an insight into the syntax of the assembly language.

The binary file can be used with the C based simulator
and the .MIF file for using to initialize FPGA block memory with Intel Quartus.
If you don't need all the output files these can be left off and they won't be generated.

Simulator

By not specifying any output files, misc.py will run the simulator after a successful assembly.
A version of the simulator written in C is included;
the source code resides in a single file and can easily be built by gcc or another C compiler.

When compiled, it is run by specifying the binary image on the command line..

misc eforth.bin

License
misc16-eforth is distributed under the terms of the MIT license.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Enjoy
Have a nice rest of the Festive Season
and All the Best for 2022.

Kind regards

Juergen Pintaske

On Monday, December 27, 2021 at 9:48:09 AM UTC-5, jpit...@gmail.com wrote:
> Dear Ting,
>
> A late Christmas present.
>
> I could convince Steve Teal
> to code a microprocessor in VHDL
> that I had been carrying around for the last 25 years.
>
> And eForth was implemented by Steve as well.
>
> Together with many tools that Steve did in addition.
>
> He did all of the work, I just supplied what I had from then.
>
> A big THANK YOU to Steve.
> See it all on github.
>
>
> https://github.com/Steve-Teal/eforth-misc16?fbclid=IwAR3J4bW3B0UruEk-_k3J8uzhDp6uX20InJJesv545WFu-gVok14Dd65Nj8Q
>
> misc16-eforth
>
> This project implements eForth on the MISC16, a 16-bit minimal CPU which only has a single instruction 'mov'.
> The resources included here:
> • Python based MISC16 assembler and simulator
> • C based MISC16 simulator
> • MISC16 assembly eForth
> • VHDL MISC16 CPU core
>
> History of MISC16
>
> The MISC16 project started with an article by Douglas W. Jones:
> http://homepage.cs.uiowa.edu/~jones/arch/risc/
> Juergen Pintaske saw the article and discussed the approach with his colleagues.
> At the time he had visited ARM and ARC in the UK, and this design looked like a “low-cost” ARC,
> where additional functions can be easily added memory mapped,
> without influencing the rest.
> The result was the original hardware version, tested on a CPLD board,
> developed in VHDL by Harry Siebert and the Mixed Mode ASIC Design Team.
> Some Forth people in Munich were involved later as well after the board was up and running,
> mainly Bernd Paysan.
> Later on, Juergen Pintaske found out, that this design had been slightly modified at FH Nuremberg
> and there then even been implemented as ASIC,
> manufactured by AMS as a student project.
>
> Juergen asked Mixed Mode, if this Mixed Mode Design can be published and used elsewhere,
> as nobody was using it,
> which was granted.
>
> MISC16 Architecture
>
> The MISC16 has a 16-bit address bus,
> memory locations 0x0010-0xFFFF can be used for RAM, ROM, and IO,
> the first 16 locations are reserved for a memory mapped ALU and Program Counter which implement virtual instructions.
> +---------+-------------+------------------+
> | Address | Source | Destination |
> +---------+-------------+------------------+
> | 0x0000 | PC | PC |
> | 0x0001 | PC+2 | PC if A < 0 |
> | 0x0002 | PC+4 | PC if A = 0 |
> | 0x0003 | PC+6 | - |
> | 0x0004 | - | PC if C = 1 |
> | 0x0005 | - | - |
> | 0x0006 | - | - |
> | 0x0007 | [A] | [A] |
> | 0x0008 | A | A |
> | 0x0009 | - | A = A - source |
> | 0x000A | - | - |
> | 0x000B | - | A = A + source | ADD
> | 0x000C | - | A = A xor source | XOR
> | 0x000D | - | A = A or source | OR
> | 0x000E | - | A = A and source | AND
> | 0x000F | - | A = source >> 1 | SHIFT Right
> +---------+-------------+------------------+
> Program execution begins at address 0x0010,
> after which the program counter increments by 2 with each instruction
> until it is modified by an instruction whose destination is the program counter (PC).
> Reading PC yields the program counter while it’s still pointing to the address of the instruction doing the read,
> PC+2 is the next instruction and so on for PC+4 and PC+6.
> A is the accumulator which can be used as an index register for indirect addressing.
> The accumulator is the destination of the arithmetic and logic operations
> and can be used to conditionally load the program counter for conditional jumps.
> The carry flag C is also used to conditionally load the PC,
> it is modified by the add and subtract instructions, for subtract it becomes borrow.
> The carry flag is used in the shift right instruction (0x000F),
> here it has the least significant bit of the accumulator shifted into it and its old value shifted into the most significant bit.
>
> Assembler
>
> The Python script 'misc.py' implements a very simple MISC16 assembler; it only understands 5 keywords:
> +-----+---------------------------------------+
> | mov | Move instruction |
> | equ | Assign a constant integer to a symbol |
> | db | Define a byte |
> | dw | Define a word |
> | org | Change current assembler pointer |
> +---------------------------------------------+
> The assembler uses Python 3.
>
> The following command line will assemble the eForth image,
> generating a binary image,
> an FPGA memory initialisation file
> and a listing file.
> python misc.py eforth.asm eforth.bin eforth.lst eforth.mif
>
> The listing file can be viewed with a text editor
> and used as an insight into the syntax of the assembly language.
>
> The binary file can be used with the C based simulator
> and the .MIF file for using to initialize FPGA block memory with Intel Quartus.
> If you don't need all the output files these can be left off and they won't be generated.
>
> Simulator
>
> By not specifying any output files, misc.py will run the simulator after a successful assembly.
> A version of the simulator written in C is included;
> the source code resides in a single file and can easily be built by gcc or another C compiler.
>
> When compiled, it is run by specifying the binary image on the command line.
>
> misc eforth.bin
>
> License
> misc16-eforth is distributed under the terms of the MIT license.
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Enjoy
> Have a nice rest of the Festive Season
> and All the Best for 2022.
>
> Kind regards

I have to admit I am getting lazy in my old age. So I'm not willing to do a lot of work to investigate YAMC (Yet Another MISC CPU) without having at least some idea of what this MISC does that the other sixteen thousand eight hundred 'n' twenty one MISC CPUs I've seen don't do or at least does a little bit better. Juergen's description doesn't indicate that and it doesn't provide enough detail to understand how it works. The link to github seems to provide the same text as above which is the readme.md file. I don't actually see a description of the MOV instruction, any indication of the instruction size or coding, word width or the addressable unit size (bytes? words?). It says the PC is incremented by 2 for each instruction, but is that 2 words, 2 bytes??? What exactly does the MOV instruction do?

All files in the repository other than the readme.md file are source code or the license. So I guess someone will need to reverse engineer these files and hopefully produce an architecture and instruction description. Or is all the needed information here and I simply missed it somehow?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Monday, 27 December 2021 at 21:26:07 UTC, gnuarm.del...@gmail.com wrote:
> On Monday, December 27, 2021 at 9:48:09 AM UTC-5, jpit...@gmail.com wrote:
> > Dear Ting,
> >
> > A late Christmas present.
> >
> > I could convince Steve Teal
> > to code a microprocessor in VHDL
> > that I had been carrying around for the last 25 years.
> >
> > And eForth was implemented by Steve as well.
> >
> > Together with many tools that Steve did in addition.
> >
> > He did all of the work, I just supplied what I had from then.
> >
> > A big THANK YOU to Steve.
> > See it all on github.
> >
> >
> > https://github.com/Steve-Teal/eforth-misc16?fbclid=IwAR3J4bW3B0UruEk-_k3J8uzhDp6uX20InJJesv545WFu-gVok14Dd65Nj8Q
> >
> > misc16-eforth
> >
> > This project implements eForth on the MISC16, a 16-bit minimal CPU which only has a single instruction 'mov'.
> > The resources included here:
> > • Python based MISC16 assembler and simulator
> > • C based MISC16 simulator
> > • MISC16 assembly eForth
> > • VHDL MISC16 CPU core
> >
> > History of MISC16
> >
> > The MISC16 project started with an article by Douglas W. Jones:
> > http://homepage.cs.uiowa.edu/~jones/arch/risc/
> > Juergen Pintaske saw the article and discussed the approach with his colleagues.
> > At the time he had visited ARM and ARC in the UK, and this design looked like a “low-cost” ARC,
> > where additional functions can be easily added memory mapped,
> > without influencing the rest.
> > The result was the original hardware version, tested on a CPLD board,
> > developed in VHDL by Harry Siebert and the Mixed Mode ASIC Design Team.
> > Some Forth people in Munich were involved later as well after the board was up and running,
> > mainly Bernd Paysan.
> > Later on, Juergen Pintaske found out, that this design had been slightly modified at FH Nuremberg
> > and there then even been implemented as ASIC,
> > manufactured by AMS as a student project.
> >
> > Juergen asked Mixed Mode, if this Mixed Mode Design can be published and used elsewhere,
> > as nobody was using it,
> > which was granted.
> >
> > MISC16 Architecture
> >
> > The MISC16 has a 16-bit address bus,
> > memory locations 0x0010-0xFFFF can be used for RAM, ROM, and IO,
> > the first 16 locations are reserved for a memory mapped ALU and Program Counter which implement virtual instructions.
> > +---------+-------------+------------------+
> > | Address | Source | Destination |
> > +---------+-------------+------------------+
> > | 0x0000 | PC | PC |
> > | 0x0001 | PC+2 | PC if A < 0 |
> > | 0x0002 | PC+4 | PC if A = 0 |
> > | 0x0003 | PC+6 | - |
> > | 0x0004 | - | PC if C = 1 |
> > | 0x0005 | - | - |
> > | 0x0006 | - | - |
> > | 0x0007 | [A] | [A] |
> > | 0x0008 | A | A |
> > | 0x0009 | - | A = A - source |
> > | 0x000A | - | - |
> > | 0x000B | - | A = A + source | ADD
> > | 0x000C | - | A = A xor source | XOR
> > | 0x000D | - | A = A or source | OR
> > | 0x000E | - | A = A and source | AND
> > | 0x000F | - | A = source >> 1 | SHIFT Right
> > +---------+-------------+------------------+
> > Program execution begins at address 0x0010,
> > after which the program counter increments by 2 with each instruction
> > until it is modified by an instruction whose destination is the program counter (PC).
> > Reading PC yields the program counter while it’s still pointing to the address of the instruction doing the read,
> > PC+2 is the next instruction and so on for PC+4 and PC+6.
> > A is the accumulator which can be used as an index register for indirect addressing.
> > The accumulator is the destination of the arithmetic and logic operations
> > and can be used to conditionally load the program counter for conditional jumps.
> > The carry flag C is also used to conditionally load the PC,
> > it is modified by the add and subtract instructions, for subtract it becomes borrow.
> > The carry flag is used in the shift right instruction (0x000F),
> > here it has the least significant bit of the accumulator shifted into it and its old value shifted into the most significant bit.
> >
> > Assembler
> >
> > The Python script 'misc.py' implements a very simple MISC16 assembler; it only understands 5 keywords:
> > +-----+---------------------------------------+
> > | mov | Move instruction |
> > | equ | Assign a constant integer to a symbol |
> > | db | Define a byte |
> > | dw | Define a word |
> > | org | Change current assembler pointer |
> > +---------------------------------------------+
> > The assembler uses Python 3.
> >
> > The following command line will assemble the eForth image,
> > generating a binary image,
> > an FPGA memory initialisation file
> > and a listing file.
> > python misc.py eforth.asm eforth.bin eforth.lst eforth.mif
> >
> > The listing file can be viewed with a text editor
> > and used as an insight into the syntax of the assembly language.
> >
> > The binary file can be used with the C based simulator
> > and the .MIF file for using to initialize FPGA block memory with Intel Quartus.
> > If you don't need all the output files these can be left off and they won't be generated.
> >
> > Simulator
> >
> > By not specifying any output files, misc.py will run the simulator after a successful assembly.
> > A version of the simulator written in C is included;
> > the source code resides in a single file and can easily be built by gcc or another C compiler.
> >
> > When compiled, it is run by specifying the binary image on the command line.
> >
> > misc eforth.bin
> >
> > License
> > misc16-eforth is distributed under the terms of the MIT license.
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Enjoy
> > Have a nice rest of the Festive Season
> > and All the Best for 2022.
> >
> > Kind regards
> I have to admit I am getting lazy in my old age. So I'm not willing to do a lot of work to investigate YAMC (Yet Another MISC CPU) without having at least some idea of what this MISC does that the other sixteen thousand eight hundred 'n' twenty one MISC CPUs I've seen don't do or at least does a little bit better. Juergen's description doesn't indicate that and it doesn't provide enough detail to understand how it works. The link to github seems to provide the same text as above which is the readme.md file. I don't actually see a description of the MOV instruction, any indication of the instruction size or coding, word width or the addressable unit size (bytes? words?). It says the PC is incremented by 2 for each instruction, but is that 2 words, 2 bytes??? What exactly does the MOV instruction do?
>
> All files in the repository other than the readme.md file are source code or the license. So I guess someone will need to reverse engineer these files and hopefully produce an architecture and instruction description. Or is all the needed information here and I simply missed it somehow?
>
> --
>
> Rick C.
>
> - Get 1,000 miles of free Supercharging
> - Tesla referral code - https://ts.la/richard11209

LOL LOL LOL LOL LOL LOL LOL LOL LOL LOL

You are really getting oldas you say.
And your eyes are getting worse as well, so you cannot follow the link to the original Article
Where it is described and as well links to other implementations..

Does it matter?
Not really, as you cannot even read/grasp that this email had been addressed sent toTing.

This was NOT addressed to you.

PLEASE DUMP YOUR SHIT ELSEWHERE and stay out of my posts.

> You are really getting oldas you say.

Not only him.

/ The result was the original hardware version, tested on a CPLD board,
/ developed in VHDL by Harry Siebert and the Mixed Mode ASIC
/ Design Team. Some Forth people in Munich were involved
/ later as well after the board was up and running, mainly
/ Bernd Paysan.

Text gave no indication that this was quite some
time ago: 1997 in Munich.
The german Forth-journal VD is still around.
The archive is online:
https://wiki.forth-ev.de/doku.php/vd-archiv

Paysan did an article ( in german ) then:
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
Paysan "Gforth auf MISC portiert" <Gforth ported to MISC>

The Mixed Mode board with the Forth on it was on the Forth e.V.
booth on (small) industry trade fairs like "Echtzeit" and "embedded" then.

On page 38 is a photo of the monthly meeting of the Munich Group
with Paysan:
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
I have none with Pintaske who showed up there sometimes then.

So then: in 1997 FPGAs were smaller, putting a CPU on them was new.
The M in MISC was "minimum RISC", it was low performance.
It did not have much of real world practicality. The Jones-CPU had
no connection to Forth, and only a cross-assembler for software.
Pintaske did sales at Mixed Mode, this was a publicity stunt for the
company. He contacted Forth e.V. to get a HLL for it. Decent software
seemed necessary if it would ever move to the real world.

MfG JRD

On Tuesday, 28 December 2021 at 09:20:56 UTC, Rafael Deliano wrote:
> > You are really getting old as you say.
> Not only him.
>
> / The result was the original hardware version, tested on a CPLD board,
> / developed in VHDL by Harry Siebert and the Mixed Mode ASIC
> / Design Team. Some Forth people in Munich were involved
> / later as well after the board was up and running, mainly
> / Bernd Paysan.
>
> Text gave no indication that this was quite some
> time ago: 1997 in Munich.
> The German Forth-journal VD is still around.
> The archive is online:
> https://wiki.forth-ev.de/doku.php/vd-archiv
>
> Paysan did an article ( in German ) then:
> https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
> Paysan "Gforth auf MISC portiert" <Gforth ported to MISC>
>
> The Mixed Mode board with the Forth on it was on the Forth e.V.
> booth on (small) industry trade fairs like "Echtzeit" and "embedded" then.
>
> On page 38 is a photo of the monthly meeting of the Munich Group
> with Paysan:
> https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
> I have none with Pintaske who showed up there sometimes then.
>
> So then: in 1997 FPGAs were smaller, putting a CPU on them was new.
> The M in MISC was "minimum RISC", it was low performance.
> It did not have much of real world practicality. The Jones-CPU had
> no connection to Forth, and only a cross-assembler for software.
> Pintaske did sales at Mixed Mode, this was a publicity stunt for the
> company. He contacted Forth e.V. to get a HLL for it. Decent software
> seemed necessary if it would ever move to the real world.
>
> MfG JRD

Thank you very much for the additional information, Rafael.
Some of this I had not seen before.
So next week it will be the 25th year then from the first implementation.

And the board was shown on Embedded 97. Brings back nice memories.
This was shortly before I left MM and went to the UK.
There I did a completely different job - so MISC was in the background.

Only 2 slight corrections:

I did not contact contact Forth eV,
but was then part of the Munich Forth Group, and Bernd was there as well.
Actually, if you not not look too closely - it nearly looks like me then.
The guy on the right.
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
page 38

This MISC Project was not just a Publicity Stunt.
We used this project to show/discuss the Mixed Mode capabilities to customers for
----VHDL-Design
----PCB design and
----Software design, with the Assembler as example
To discuss this with our customers
who were interested in IP, and the other design services we provided;
and it nearly made it into ASIC projects at Fraunhofer Stuttgart.
They actually re-wrote the VHDL.

As well I assume that many customers I showed it to,
were a bit too experienced to see it as a publicity stunt.
From then:
Marketing, Market Introduction,
Sales, Contract Design, ASIC Design,
Embedded Software development
for companies in Germany/Austria/Switzerland like:
Ericsson, Infineon, Siemens, SciWorx, TRW ...

On Tuesday, 28 December 2021 at 11:49:28 UTC, Jurgen Pitaske wrote:
> On Tuesday, 28 December 2021 at 09:20:56 UTC, Rafael Deliano wrote:
> > > You are really getting old as you say.
> > Not only him.
> >
> > / The result was the original hardware version, tested on a CPLD board,
> > / developed in VHDL by Harry Siebert and the Mixed Mode ASIC
> > / Design Team. Some Forth people in Munich were involved
> > / later as well after the board was up and running, mainly
> > / Bernd Paysan.
> >
> > Text gave no indication that this was quite some
> > time ago: 1997 in Munich.
> > The German Forth-journal VD is still around.
> > The archive is online:
> > https://wiki.forth-ev.de/doku.php/vd-archiv
> >
> > Paysan did an article ( in German ) then:
> > https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
> > Paysan "Gforth auf MISC portiert" <Gforth ported to MISC>
> >
> > The Mixed Mode board with the Forth on it was on the Forth e.V.
> > booth on (small) industry trade fairs like "Echtzeit" and "embedded" then.
> >
> > On page 38 is a photo of the monthly meeting of the Munich Group
> > with Paysan:
> > https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
> > I have none with Pintaske who showed up there sometimes then.
> >
> > So then: in 1997 FPGAs were smaller, putting a CPU on them was new.
> > The M in MISC was "minimum RISC", it was low performance.
> > It did not have much of real world practicality. The Jones-CPU had
> > no connection to Forth, and only a cross-assembler for software.
> > Pintaske did sales at Mixed Mode, this was a publicity stunt for the
> > company. He contacted Forth e.V. to get a HLL for it. Decent software
> > seemed necessary if it would ever move to the real world.
> >
> > MfG JRD
> Thank you very much for the additional information, Rafael.
> Some of this I had not seen before.
> So next week it will be the 25th year then from the first implementation.
>
> And the board was shown on Embedded 97. Brings back nice memories.
> This was shortly before I left MM and went to the UK.
> There I did a completely different job - so MISC was in the background.
>
> Only 2 slight corrections:
>
> I did not contact contact Forth eV,
> but was then part of the Munich Forth Group, and Bernd was there as well.
> Actually, if you not not look too closely - it nearly looks like me then.
> The guy on the right.
> https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
> page 38
>
> This MISC Project was not just a Publicity Stunt.
> We used this project to show/discuss the Mixed Mode capabilities to customers for
> ----VHDL-Design
> ----PCB design and
> ----Software design, with the Assembler as example
> To discuss this with our customers
> who were interested in IP, and the other design services we provided;
> and it nearly made it into ASIC projects at Fraunhofer Stuttgart.
> They actually re-wrote the VHDL.
>
> As well I assume that many customers I showed it to,
> were a bit too experienced to see it as a publicity stunt.
> From then:
> Marketing, Market Introduction,
> Sales, Contract Design, ASIC Design,
> Embedded Software development
> for companies in Germany/Austria/Switzerland like:
> Ericsson, Infineon, Siemens, SciWorx, TRW ...

By the way, this project was never planned to attack Intel - neither then nor now.
So performance does not matter really - just is it fast enough for where it is used.
It is an interesting design exercise - and I am happy it is there now;
how small a CPU can be to do something useful
- here actually to run FORTH - another publicity stunt according to the mind set of some people here?

I had posted this MISC information here as it might be of interest to some
- and especially as a Thank You to Steve and Ting.
Without them it would not have been possible.

And it is the second joint activity after The FIG FORTH Manual,
where Steve designed a reduced feature CDP1802 to run the Forth successfully.
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM
And this link to the Forth books is definitely a promotional activity ...

On Tuesday, December 28, 2021 at 4:20:56 AM UTC-5, Rafael Deliano wrote:
> > You are really getting oldas you say.
> Not only him.
>
> / The result was the original hardware version, tested on a CPLD board,
> / developed in VHDL by Harry Siebert and the Mixed Mode ASIC
> / Design Team. Some Forth people in Munich were involved
> / later as well after the board was up and running, mainly
> / Bernd Paysan.
>
> Text gave no indication that this was quite some
> time ago: 1997 in Munich.
> The german Forth-journal VD is still around.
> The archive is online:
> https://wiki.forth-ev.de/doku.php/vd-archiv
>
> Paysan did an article ( in german ) then:
> https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
> Paysan "Gforth auf MISC portiert" <Gforth ported to MISC>
>
> The Mixed Mode board with the Forth on it was on the Forth e.V.
> booth on (small) industry trade fairs like "Echtzeit" and "embedded" then..
>
> On page 38 is a photo of the monthly meeting of the Munich Group
> with Paysan:
> https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
> I have none with Pintaske who showed up there sometimes then.
>
> So then: in 1997 FPGAs were smaller, putting a CPU on them was new.
> The M in MISC was "minimum RISC", it was low performance.
> It did not have much of real world practicality. The Jones-CPU had
> no connection to Forth, and only a cross-assembler for software.
> Pintaske did sales at Mixed Mode, this was a publicity stunt for the
> company. He contacted Forth e.V. to get a HLL for it. Decent software
> seemed necessary if it would ever move to the real world.

So did you find any info on the processor architecture like instruction format?

From what is provided, I agree that this CPU seems to have no particular connection to Forth. It is not stack oriented. The only "feature" I can see is that it might be smaller than some other designs. It must have some such advantages because it would be exceedingly slow. I have looked at other such one instruction designs and they require many instructions to accomplish what other designs do in a single instruction.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On Tuesday, 28 December 2021 at 14:27:30 UTC, gnuarm.del...@gmail.com wrote:
> On Tuesday, December 28, 2021 at 4:20:56 AM UTC-5, Rafael Deliano wrote:
> > > You are really getting oldas you say.
> > Not only him.
> >
> > / The result was the original hardware version, tested on a CPLD board,
> > / developed in VHDL by Harry Siebert and the Mixed Mode ASIC
> > / Design Team. Some Forth people in Munich were involved
> > / later as well after the board was up and running, mainly
> > / Bernd Paysan.
> >
> > Text gave no indication that this was quite some
> > time ago: 1997 in Munich.
> > The german Forth-journal VD is still around.
> > The archive is online:
> > https://wiki.forth-ev.de/doku.php/vd-archiv
> >
> > Paysan did an article ( in german ) then:
> > https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
> > Paysan "Gforth auf MISC portiert" <Gforth ported to MISC>
> >
> > The Mixed Mode board with the Forth on it was on the Forth e.V.
> > booth on (small) industry trade fairs like "Echtzeit" and "embedded" then.
> >
> > On page 38 is a photo of the monthly meeting of the Munich Group
> > with Paysan:
> > https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
> > I have none with Pintaske who showed up there sometimes then.
> >
> > So then: in 1997 FPGAs were smaller, putting a CPU on them was new.
> > The M in MISC was "minimum RISC", it was low performance.
> > It did not have much of real world practicality. The Jones-CPU had
> > no connection to Forth, and only a cross-assembler for software.
> > Pintaske did sales at Mixed Mode, this was a publicity stunt for the
> > company. He contacted Forth e.V. to get a HLL for it. Decent software
> > seemed necessary if it would ever move to the real world.
> So did you find any info on the processor architecture like instruction format?
>
> From what is provided, I agree that this CPU seems to have no particular connection to Forth. It is not stack oriented. The only "feature" I can see is that it might be smaller than some other designs. It must have some such advantages because it would be exceedingly slow. I have looked at other such one instruction designs and they require many instructions to accomplish what other designs do in a single instruction.
>
> --
>
> Rick C.
>
> + Get 1,000 miles of free Supercharging
> + Tesla referral code - https://ts.la/richard11209

+------- --+-------------+------------------+
| Address | Source | Destination |
+------- --+-------------+------------------+
| 0x0000 | ---PC----- | PC------------- |
| 0x0001 | PC+2---- | PC if A < 0 -| DECISIONS
| 0x0002 | PC+4---- | PC if A = 0 -| DECISIONS
| 0x0003 | PC+6---- | - --------------|
| 0x0004 | - ------------|- PC if C = 1 | DECOSIONS
| 0x0005 | - ----------| - --------------|
| 0x0006 | - | - |
| 0x0007 | [A] | [A] |
| 0x0008 | A | A |
| 0x0009 | - ------------| A = A - source --- |
| 0x000A | - -----------| - -------------------------|
| 0x000B | - -----------| A = A + source | ADD
| 0x000C | - -----------| A = A xor source | XOR
| 0x000D | - -----------| A = A or source | OR
| 0x000E | - -----------| A = A and source | AND
| 0x000F | - -----------| A = source >> 1 | SHIFT Right
+-------------+-----------+-----------------------------+

This is all you have.
It was the simplicity that was interesting at the time.
A Microprocessor IP that was easy to build and to explain - a Lattice 1016 or 1032 at the time - now FPGA.
The VHDL code here fits onto 4 pages of paper. Copied it from github
OK, UART and IO not includeed.
Performance was secondary.
At the time in 1997 we called it UPS processor
This 16 bit processor just shifts 16 bit data packages from address A to address B. Or into the ALU.
All of the instructions are here in this list
The ALU is memory mapped as well as you can see.

BUT:
Use 4 of these blocks in parallel, and you have a 64 Bit wide Processor
- address range as required in the application
Add any IO or other functionality - the processor just needs to know the addresses of the memory map.
Or have a few of these small processors on the same FPGA, until you run out of ressources.

And read more here as given in the post above http://homepage.cs.uiowa.edu/~jones/arch/risc/
Example code is there as well.

> So did you find any info on the processor architecture like instruction format?

"Hard" information on a "soft" CPU is always tricky. Paysan states in
the article he got from Mixed Mode a simulator "with the then currently
used instruction set". So MixedMode hadn't finalized.
Together with Jens Wilke he did a 3 day(&night) port over the weekend
and sent the Intel-Hex to MixedMode.
They first did a 20 primitive version but came to the conclusion
that even on a Pentium that was to slow. In the article he lists the
47 primitives that were used.

> it would be exceedingly slow.

Paysans Forth is big and was intended for PCs. So it might not be ideal.
On the other hand their usual demo was as fas as i can remember
Tetris VT220 terminal style. Thats what visitors on the
trade fair got to see. It had no serious speed problem.

MfG JRD

> By the way, this project was never planned to attack Intel - neither then nor now.

Neither was RTX2000 chosen by Harris to be the fastest RISC. But
with its ASIC-Bus intended for combination with application specific
IO in standard cell design.
The same thing was assumed for FPGA-CPUs: they could never compete on
performance with real CPUs or controllers, but could more tightly couple
to IO. And then be competitive in an narrow application.
It did not turn out that way. FPGAs got bigger, people invented
more complex pseudo-RTX CPUs. Without much thought what would
be a reasonable application for the new toy.

> So performance does not matter really - just is it fast enough for where it is used.

This year the old dutch/german/UK "Elector" magazine had their 60th
anniversary. They fondly remembered their projects with the old
ROM-based Intel 8051 BASIC-controllers. These were slow. Didn't
much bother the people that used them. They were cheap & easy
to use, thats what was relevant.

One could probably exhume the MISC16 for magazines like (the german)
MAKE: or Elector in combination with an application like "multiple motor
controller for robot programmable in HLL language" that is implemented
on the same FPGA.

MfG JRD

On Tuesday, December 28, 2021 at 11:00:42 AM UTC-5, Rafael Deliano wrote:
> > So did you find any info on the processor architecture like instruction format?
> "Hard" information on a "soft" CPU is always tricky. Paysan states in
> the article he got from Mixed Mode a simulator "with the then currently
> used instruction set". So MixedMode hadn't finalized.
> Together with Jens Wilke he did a 3 day(&night) port over the weekend
> and sent the Intel-Hex to MixedMode.
> They first did a 20 primitive version but came to the conclusion
> that even on a Pentium that was to slow. In the article he lists the
> 47 primitives that were used.
> > it would be exceedingly slow.
> Paysans Forth is big and was intended for PCs. So it might not be ideal.
> On the other hand their usual demo was as fas as i can remember
> Tetris VT220 terminal style. Thats what visitors on the
> trade fair got to see. It had no serious speed problem.

Lol. I don't know what it takes to run Tetris. I would not use such a demo to evaluate a soft CPU in an FPGA. I use soft CPU cores for management of operations on a chip which is high speed, real time. Responding to a key press is not the sort of application I would be looking for a soft core to handle. No offense intended.

J. seems to think the table in the documentation of the functions connected to the first 16 locations in memory are adequate documentation. But these locations are accessed by the MOV command which is not documented at all that I can see. Do you know how the MOV command is structured? With a 16 bit address it would seem cumbersome to include a source and destination, but maybe that's all the instruction is, a pair of addresses?

Who knows? Without basic info like I've already pointed out is lacking (like data word size and whether the address is byte or word oriented) it's hard to know how this thing works.

I'm curious, but not enough to put a bunch of effort into reverse engineering it. I'm certainly not going to try to get J. to calm down enough to discuss it. I have no idea why he has to fly off the handle so easily. He really comes across as a loon when he is like that. The worst is when he's arguing with Hugh or that Peter Forth guy whatever his real name is. Talk about loons, that guy really takes the cake!

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

On Tuesday, 28 December 2021 at 16:45:29 UTC, gnuarm.del...@gmail.com wrote:
> On Tuesday, December 28, 2021 at 11:00:42 AM UTC-5, Rafael Deliano wrote:
> > > So did you find any info on the processor architecture like instruction format?
> > "Hard" information on a "soft" CPU is always tricky. Paysan states in
> > the article he got from Mixed Mode a simulator "with the then currently
> > used instruction set". So MixedMode hadn't finalized.
> > Together with Jens Wilke he did a 3 day(&night) port over the weekend
> > and sent the Intel-Hex to MixedMode.
> > They first did a 20 primitive version but came to the conclusion
> > that even on a Pentium that was to slow. In the article he lists the
> > 47 primitives that were used.
> > > it would be exceedingly slow.
> > Paysans Forth is big and was intended for PCs. So it might not be ideal..
> > On the other hand their usual demo was as fas as i can remember
> > Tetris VT220 terminal style. Thats what visitors on the
> > trade fair got to see. It had no serious speed problem.
> Lol. I don't know what it takes to run Tetris. I would not use such a demo to evaluate a soft CPU in an FPGA. I use soft CPU cores for management of operations on a chip which is high speed, real time. Responding to a key press is not the sort of application I would be looking for a soft core to handle. No offense intended.
>
> J. seems to think the table in the documentation of the functions connected to the first 16 locations in memory are adequate documentation. But these locations are accessed by the MOV command which is not documented at all that I can see. Do you know how the MOV command is structured? With a 16 bit address it would seem cumbersome to include a source and destination, but maybe that's all the instruction is, a pair of addresses?
>
> Who knows? Without basic info like I've already pointed out is lacking (like data word size and whether the address is byte or word oriented) it's hard to know how this thing works.
>
> I'm curious, but not enough to put a bunch of effort into reverse engineering it. I'm certainly not going to try to get J. to calm down enough to discuss it. I have no idea why he has to fly off the handle so easily. He really comes across as a loon when he is like that. The worst is when he's arguing with Hugh or that Peter Forth guy whatever his real name is. Talk about loons, that guy really takes the cake!
>
> --
>
> Rick C.
>
> -- Get 1,000 miles of free Supercharging
> -- Tesla referral code - https://ts.la/richard11209

As I said higher up
- read tghe fucking documentation and SW examples - else please keep your mouth shut and dump elsewhere.

On Tuesday, December 28, 2021 at 11:42:50 AM UTC-5, Rafael Deliano wrote:
> > By the way, this project was never planned to attack Intel - neither then nor now.
> Neither was RTX2000 chosen by Harris to be the fastest RISC. But
> with its ASIC-Bus intended for combination with application specific
> IO in standard cell design.
> The same thing was assumed for FPGA-CPUs: they could never compete on
> performance with real CPUs or controllers, but could more tightly couple
> to IO.

Not sure what that means. FPGA based CPUs can run very fast. More importantly, they can be designed to run as fast as required and not faster wasting resources. They are typically much less expensive than a separate CPU as they are mostly used when an FPGA is already in the design. The other advantage is they can be added in whatever quantity might work best. I have assigned an entire CPU to one task to make sure it meets the timing requirements.

> And then be competitive in an narrow application.
> It did not turn out that way. FPGAs got bigger, people invented
> more complex pseudo-RTX CPUs. Without much thought what would
> be a reasonable application for the new toy.
> > So performance does not matter really - just is it fast enough for where it is used.

That is absolutely true. But if you have a slower design it suits fewer design applications.

> This year the old dutch/german/UK "Elector" magazine had their 60th
> anniversary. They fondly remembered their projects with the old
> ROM-based Intel 8051 BASIC-controllers. These were slow. Didn't
> much bother the people that used them. They were cheap & easy
> to use, thats what was relevant.

Yup. They were used for many things. Soft cores in FPGAs don't necessarily need to be "fast", just fast enough. But that's a moving target and if your only advantage is size but a much faster design is only slightly larger, which design do you think will fit more applications? If you are going to the effort of designing a soft core CPU, why spend time messing with a design that will only be optimal in a small number of apps? That sounds like the GA144 approach. Do one thing really well and see if anyone finds a use for it.

This design hasn't been measured for size has it? How many 4 input LUTs and FFs does it use?

> One could probably exhume the MISC16 for magazines like (the german)
> MAKE: or Elector in combination with an application like "multiple motor
> controller for robot programmable in HLL language" that is implemented
> on the same FPGA.

Ok

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

On Tuesday, 28 December 2021 at 16:00:42 UTC, Rafael Deliano wrote:
> > So did you find any info on the processor architecture like instruction format?
> "Hard" information on a "soft" CPU is always tricky.

Paysan states in
> the article he got from Mixed Mode a simulator "with the then currently
> used instruction set". So MixedMode hadn't finalized.

This is wrong and you should know it if you were involved
- otherwise you just try to interpret the article

> Together with Jens Wilke he did a 3 day(&night) port over the weekend
> and sent the Intel-Hex to MixedMode.

This whole port activity had nothing to do with the original design and with Mixed Mode.
The port of Forth was never used / demonstrated later,
as long as I worked there.
So it was a private student exercise who wanted to know if they can replicate what worked already..

How well it worked and how many bugs might have been still in there - nobody knows.
But it was not relevant.

> They first did a 20 primitive version but came to the conclusion
> that even on a Pentium that was to slow. In the article he lists the
> 47 primitives that were used.
> > it would be exceedingly slow.
> Paysans Forth is big and was intended for PCs. So it might not be ideal.

Why do you not say it: it was too bloated for such a little processor.
So, a bad choice on Bernd's side to start with this package in the first place.
Funnily enough, It now seems to run eForth well enough as the video shows.

> On the other hand their usual demo was as fas as i can remember
> Tetris VT220 terminal style. Thats what visitors on the
> trade fair got to see.

> It had no serious speed problem.

Either there were speed problems or not
- or are you making this up after 25 years to make MM look bad??

As a summary: I do not like your negativity.
Mixed Mode and the 2 other companies were about 30 SW and HW designers at the time
- they knew what they were doing.
And finished the design as far as needed for this IP Demo Project.

Now to say that a couple of students - using a language that nobody at MM had experience with -
did not work as it should is a bit far fetched.
>
> MfG JRD

On Tuesday, December 28, 2021 at 5:42:50 PM UTC+1, Rafael Deliano wrote:
> Neither was RTX2000 chosen by Harris to be the fastest RISC.

Well, at the time I was a student still, and I remember quite vividly that
I believed (for some reason) that the RTX2000 was the fastest processor
around. I bought a development board but was not impressed.
Of course, in that before-the-internet era it was very difficult to get
essential documentation and access critical benchmarks. We had to make
do with Jeff Fox's interpretations of CM's personal communications.
Of course, all that has radically changed for the good.

-marcel

>> he got from Mixed Mode a simulator "with the then currently
>> used instruction set". So MixedMode hadn't finalized.

> This is wrong and you should know it if you were involved
> - otherwise you just try to interpret the article

I stated whats written in the article and how Paysan saw it then.

> The port of Forth was never used / demonstrated later,
> as long as I worked there.

It was unpaid, semiofficial. I, Wilke and Paysan did a visit
to MixedMode to say hello to the R&D staff there and have a short
meeting about what to do. The board/HW was loaned by the company
and later returned. The top brass of the company wasn't involved.

>> Paysans Forth is big and was intended for PCs.
> Why do you not say it: it was too bloated for such a little processor.

Paysan was by then probably working at the university at his own
stackprocessor-project and therefore interested enough to do
a port. Since it was unpaid you had to take what was on offer.
And since you got results fast and good enough to demo there
is no reason to complain.

>> Tetris ... It had no serious speed problem.
> Either there were speed problems or not
> - or are you making this up after 25 years to make MM look bad??

There were obviously no detailed requirements by MixedMode on
performance. For Paysan as soon as Tetris was running decently
he considered a port stable and the job done.

> As a summary: I do not like your negativity.
> Mixed Mode and the 2 other companies were about 30 SW and HW designers at the time
> - they knew what they were doing.
> And finished the design as far as needed for this IP Demo Project.

It was your pet-project and may have had some backing with the R&D staff
at MixedMode. It had much less backing from the bean-counters at the top
of the company as it was unclear how ever to earn money with it.
I am not making this up: your words then before you left for UK.
I have a bloody good memory.

Much as Rick now i had then problems understanding how that thing works.
Paysan had to explain it me and i have long since forgotten.
So Paysans Forth may have been the high point concerning software
then. There was never any talk of MixedMode doing a C-compiler.
It is highly unreasonable to expect a customer micro-coding in assembler
with that instructions set any real world
application. Even if some sort of macro-assembler would have
been available: there is a tradeoff in size of the CPU and
code-density. Usually a very unfavourable one.

MfG JRD

On Tuesday, 28 December 2021 at 19:41:37 UTC, Rafael Deliano wrote:
> >> he got from Mixed Mode a simulator "with the then currently
> >> used instruction set". So MixedMode hadn't finalized.
>
> > This is wrong and you should know it if you were involved
> > - otherwise you just try to interpret the article
> I stated whats written in the article and how Paysan saw it then.
> > The port of Forth was never used / demonstrated later,
> > as long as I worked there.
> It was unpaid, semiofficial. I, Wilke and Paysan did a visit
> to MixedMode to say hello to the R&D staff there and have a short
> meeting about what to do. The board/HW was loaned by the company
> and later returned. The top brass of the company wasn't involved.
> >> Paysans Forth is big and was intended for PCs.
> > Why do you not say it: it was too bloated for such a little processor.
> Paysan was by then probably working at the university at his own
> stackprocessor-project and therefore interested enough to do
> a port. Since it was unpaid you had to take what was on offer.
> And since you got results fast and good enough to demo there
> is no reason to complain.
>
> >> Tetris ... It had no serious speed problem.
> > Either there were speed problems or not
> > - or are you making this up after 25 years to make MM look bad??
> There were obviously no detailed requirements by MixedMode on
> performance. For Paysan as soon as Tetris was running decently
> he considered a port stable and the job done.
> > As a summary: I do not like your negativity.
> > Mixed Mode and the 2 other companies were about 30 SW and HW designers at the time
> > - they knew what they were doing.
> > And finished the design as far as needed for this IP Demo Project.
> It was your pet-project and may have had some backing with the R&D staff
> at MixedMode. It had much less backing from the bean-counters at the top
> of the company as it was unclear how ever to earn money with it.
> I am not making this up: your words then before you left for UK.
> I have a bloody good memory.
>
> Much as Rick now i had then problems understanding how that thing works.
> Paysan had to explain it me and i have long since forgotten.
> So Paysans Forth may have been the high point concerning software
> then. There was never any talk of MixedMode doing a C-compiler.
> It is highly unreasonable to expect a customer micro-coding in assembler
> with that instructions set any real world
> application. Even if some sort of macro-assembler would have
> been available: there is a tradeoff in size of the CPU and
> code-density. Usually a very unfavourable one.
>
> MfG JRD

As it seems you know the MM organisation better than me - I give up.
And it actually does not matter.
And if you do not understand this processor, this does not matter either.
This project has achieved what was planned then.
It would have been nice to achieve more then - but there we are.

Steve seems to understand the processor very well
and as well knows what he is doing
in rebuilding the VHDL
and adapting the eForth to run.
And an Assembler.
You might not know - but Assembler is still used nowadays where required.

Success in all areas - but I am sure you find negative aspects here as well.
I am grateful for all of Steve's efforts to bring this processor back to life.
Basically the second processor he coded in VHDL for me.
How useful is MISC now?
We will find out over time.
This is not for money or business.
This is for fun - and this has been achieved.
Actually 2 times - then and now.

On Tuesday, 28 December 2021 at 21:16:20 UTC, Jurgen Pitaske wrote:
> On Tuesday, 28 December 2021 at 19:41:37 UTC, Rafael Deliano wrote:
> > >> he got from Mixed Mode a simulator "with the then currently
> > >> used instruction set". So MixedMode hadn't finalized.
> >
> > > This is wrong and you should know it if you were involved
> > > - otherwise you just try to interpret the article
> > I stated whats written in the article and how Paysan saw it then.
> > > The port of Forth was never used / demonstrated later,
> > > as long as I worked there.
> > It was unpaid, semiofficial. I, Wilke and Paysan did a visit
> > to MixedMode to say hello to the R&D staff there and have a short
> > meeting about what to do. The board/HW was loaned by the company
> > and later returned. The top brass of the company wasn't involved.
> > >> Paysans Forth is big and was intended for PCs.
> > > Why do you not say it: it was too bloated for such a little processor.
> > Paysan was by then probably working at the university at his own
> > stackprocessor-project and therefore interested enough to do
> > a port. Since it was unpaid you had to take what was on offer.
> > And since you got results fast and good enough to demo there
> > is no reason to complain.
> >
> > >> Tetris ... It had no serious speed problem.
> > > Either there were speed problems or not
> > > - or are you making this up after 25 years to make MM look bad??
> > There were obviously no detailed requirements by MixedMode on
> > performance. For Paysan as soon as Tetris was running decently
> > he considered a port stable and the job done.
> > > As a summary: I do not like your negativity.
> > > Mixed Mode and the 2 other companies were about 30 SW and HW designers at the time
> > > - they knew what they were doing.
> > > And finished the design as far as needed for this IP Demo Project.
> > It was your pet-project and may have had some backing with the R&D staff
> > at MixedMode. It had much less backing from the bean-counters at the top
> > of the company as it was unclear how ever to earn money with it.
> > I am not making this up: your words then before you left for UK.
> > I have a bloody good memory.
> >
> > Much as Rick now i had then problems understanding how that thing works.
> > Paysan had to explain it me and i have long since forgotten.
> > So Paysans Forth may have been the high point concerning software
> > then. There was never any talk of MixedMode doing a C-compiler.
> > It is highly unreasonable to expect a customer micro-coding in assembler
> > with that instructions set any real world
> > application. Even if some sort of macro-assembler would have
> > been available: there is a tradeoff in size of the CPU and
> > code-density. Usually a very unfavourable one.
> >
> > MfG JRD
> As it seems you know the MM organisation better than me - I give up.
> And it actually does not matter.
> And if you do not understand this processor, this does not matter either.
> This project has achieved what was planned then.
> It would have been nice to achieve more then - but there we are.
>
> Steve seems to understand the processor very well
> and as well knows what he is doing
> in rebuilding the VHDL
> and adapting the eForth to run.
> And an Assembler.
> You might not know - but Assembler is still used nowadays where required.
>
> Success in all areas - but I am sure you find negative aspects here as well.
> I am grateful for all of Steve's efforts to bring this processor back to life.
> Basically the second processor he coded in VHDL for me.
> How useful is MISC now?
> We will find out over time.
> This is not for money or business.
> This is for fun - and this has been achieved.
> Actually 2 times - then and now.

It seems Professor Emeritus Douglas Jones
who wrote the article in the first place,
did like the implementation Steve did,
and added a comment in his article based on my email to him.

https://homepage.cs.uiowa.edu/~jones/arch/risc/

In late December 2021,
Juergen Pintaske pointed me at Steve Teal's VHDL implementation
of Juergen's MISC16 variant on the Ulitmate RISC.
This has a slightly closer coupling between the move engine and the ALU,
enough that you can just call the two of them a CPU,
and it has been manufactured as an ASIC.
An eForth interpreter has been written for it,
so it can actually be used with an (arguably) high-level language.
The whole project, including VHDL code,
the eForth interpreter in assembly,
a cross assembler writtein in Python
and a C emulator for MISC16
is available on Github.

On Saturday, January 1, 2022 at 2:37:21 AM UTC-5, jpit...@gmail.com wrote:
> It seems Professor Emeritus Douglas Jones
> who wrote the article in the first place,
> did like the implementation Steve did,
> and added a comment in his article based on my email to him.
>
> https://homepage.cs.uiowa.edu/~jones/arch/risc/
>
> In late December 2021,
> Juergen Pintaske pointed me at Steve Teal's VHDL implementation
> of Juergen's MISC16 variant on the Ulitmate RISC.
> This has a slightly closer coupling between the move engine and the ALU,
> enough that you can just call the two of them a CPU,
> and it has been manufactured as an ASIC.
> An eForth interpreter has been written for it,
> so it can actually be used with an (arguably) high-level language.
> The whole project, including VHDL code,
> the eForth interpreter in assembly,
> a cross assembler writtein in Python
> and a C emulator for MISC16
> is available on Github.

Sounds great. Now to get significant numbers of people to adopt it just requires appropriate documentation. That was a big failure of the GA144. Tools were written, but with little documentation.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Sunday, 2 January 2022 at 01:54:02 UTC, gnuarm.del...@gmail.com wrote:
> On Saturday, January 1, 2022 at 2:37:21 AM UTC-5, jpit...@gmail.com wrote:
> > It seems Professor Emeritus Douglas Jones
> > who wrote the article in the first place,
> > did like the implementation Steve did,
> > and added a comment in his article based on my email to him.
> >
> > https://homepage.cs.uiowa.edu/~jones/arch/risc/
> >
> > In late December 2021,
> > Juergen Pintaske pointed me at Steve Teal's VHDL implementation
> > of Juergen's MISC16 variant on the Ulitmate RISC.
> > This has a slightly closer coupling between the move engine and the ALU,
> > enough that you can just call the two of them a CPU,
> > and it has been manufactured as an ASIC.
> > An eForth interpreter has been written for it,
> > so it can actually be used with an (arguably) high-level language.
> > The whole project, including VHDL code,
> > the eForth interpreter in assembly,
> > a cross assembler writtein in Python
> > and a C emulator for MISC16
> > is available on Github.

> Sounds great.
Now to get significant numbers of people to adopt it
just requires appropriate documentation.
That was a big failure of the GA144.
Tools were written, but with little documentation.
>
> --
>
> Rick C.
>
> - Get 1,000 miles of free Supercharging
> - Tesla referral code - https://ts.la/richard11209

The project for 2022.

On Sunday, January 2, 2022 at 2:59:51 AM UTC-5, jpit...@gmail.com wrote:
> On Sunday, 2 January 2022 at 01:54:02 UTC, gnuarm.del...@gmail.com wrote:
> > On Saturday, January 1, 2022 at 2:37:21 AM UTC-5, jpit...@gmail.com wrote:
> > > It seems Professor Emeritus Douglas Jones
> > > who wrote the article in the first place,
> > > did like the implementation Steve did,
> > > and added a comment in his article based on my email to him.
> > >
> > > https://homepage.cs.uiowa.edu/~jones/arch/risc/
> > >
> > > In late December 2021,
> > > Juergen Pintaske pointed me at Steve Teal's VHDL implementation
> > > of Juergen's MISC16 variant on the Ulitmate RISC.
> > > This has a slightly closer coupling between the move engine and the ALU,
> > > enough that you can just call the two of them a CPU,
> > > and it has been manufactured as an ASIC.
> > > An eForth interpreter has been written for it,
> > > so it can actually be used with an (arguably) high-level language.
> > > The whole project, including VHDL code,
> > > the eForth interpreter in assembly,
> > > a cross assembler writtein in Python
> > > and a C emulator for MISC16
> > > is available on Github.
>
> > Sounds great.
> Now to get significant numbers of people to adopt it
> just requires appropriate documentation.
> That was a big failure of the GA144.
> Tools were written, but with little documentation.
> >
> > --
> >
> > Rick C.
> >
> > - Get 1,000 miles of free Supercharging
> > - Tesla referral code - https://ts.la/richard11209
> The project for 2022.

Ok. Great. What is the purpose of this MISC CPU? I don't recall just how small it is. Is there a LUT4 count? We can provide it to Jim Brakefield to add to his data on soft CPUs. He doesn't require source code, but I think he is willing to evaluate designs if they are provided. I'm not sure if he does any testing other than compiling to see how many LUTs it uses and likely looks at the code to see the clocks/instruction, etc., but I'm not sure. I didn't look. Does this design have a test bench?

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On Sunday, January 2, 2022 at 3:34:59 AM UTC-6, gnuarm.del...@gmail.com wrote:
> On Sunday, January 2, 2022 at 2:59:51 AM UTC-5, jpit...@gmail.com wrote:
> > On Sunday, 2 January 2022 at 01:54:02 UTC, gnuarm.del...@gmail.com wrote:
> > > On Saturday, January 1, 2022 at 2:37:21 AM UTC-5, jpit...@gmail.com wrote:
> > > > It seems Professor Emeritus Douglas Jones
> > > > who wrote the article in the first place,
> > > > did like the implementation Steve did,
> > > > and added a comment in his article based on my email to him.
> > > >
> > > > https://homepage.cs.uiowa.edu/~jones/arch/risc/
> > > >
> > > > In late December 2021,
> > > > Juergen Pintaske pointed me at Steve Teal's VHDL implementation
> > > > of Juergen's MISC16 variant on the Ulitmate RISC.
> > > > This has a slightly closer coupling between the move engine and the ALU,
> > > > enough that you can just call the two of them a CPU,
> > > > and it has been manufactured as an ASIC.
> > > > An eForth interpreter has been written for it,
> > > > so it can actually be used with an (arguably) high-level language.
> > > > The whole project, including VHDL code,
> > > > the eForth interpreter in assembly,
> > > > a cross assembler writtein in Python
> > > > and a C emulator for MISC16
> > > > is available on Github.
> >
> > > Sounds great.
> > Now to get significant numbers of people to adopt it
> > just requires appropriate documentation.
> > That was a big failure of the GA144.
> > Tools were written, but with little documentation.
> > >
> > > --
> > >
> > > Rick C.
> > >
> > > - Get 1,000 miles of free Supercharging
> > > - Tesla referral code - https://ts.la/richard11209
> > The project for 2022.
> Ok. Great. What is the purpose of this MISC CPU? I don't recall just how small it is. Is there a LUT4 count? We can provide it to Jim Brakefield to add to his data on soft CPUs. He doesn't require source code, but I think he is willing to evaluate designs if they are provided. I'm not sure if he does any testing other than compiling to see how many LUTs it uses and likely looks at the code to see the clocks/instruction, etc., but I'm not sure. I didn't look. Does this design have a test bench?
>
> --
>
> Rick C.
>
> + Get 1,000 miles of free Supercharging
> + Tesla referral code - https://ts.la/richard11209
Move processors are rare. This one has only 10 move operations
(conditional branches counted as one instruction).

Ugh, the design is a bare core: no block RAM for memory.

I used Vivado and the fastest part with free tools: xczu3cg-sfvc784-2-e
And added a clock constraint file.
Will place and route with a clock speed greater than 500MHz.
Uses ~197 LUT6 and ~78 DFF.
Normal MIPS/instruction for 16-biitter is 0.67.
In this case reduced MIPS/inst to 0.22 yielding a KIPS/LUT of 558.
(a move processor requires many loads and stores than normal cpu)

Steve Teal in his 1802-pico-basic design included the block RAM,
so, would encourage him to do likewise here.
Would result in a more meaningful Fmax.

On Sunday, 2 January 2022 at 18:29:16 UTC, James Brakefield wrote:
> On Sunday, January 2, 2022 at 3:34:59 AM UTC-6, gnuarm.del...@gmail.com wrote:
> > On Sunday, January 2, 2022 at 2:59:51 AM UTC-5, jpit...@gmail.com wrote:
> > > On Sunday, 2 January 2022 at 01:54:02 UTC, gnuarm.del...@gmail.com wrote:
> > > > On Saturday, January 1, 2022 at 2:37:21 AM UTC-5, jpit...@gmail.com wrote:
> > > > > It seems Professor Emeritus Douglas Jones
> > > > > who wrote the article in the first place,
> > > > > did like the implementation Steve did,
> > > > > and added a comment in his article based on my email to him.
> > > > >
> > > > > https://homepage.cs.uiowa.edu/~jones/arch/risc/
> > > > >
> > > > > In late December 2021,
> > > > > Juergen Pintaske pointed me at Steve Teal's VHDL implementation
> > > > > of Juergen's MISC16 variant on the Ulitmate RISC.
> > > > > This has a slightly closer coupling between the move engine and the ALU,
> > > > > enough that you can just call the two of them a CPU,
> > > > > and it has been manufactured as an ASIC.
> > > > > An eForth interpreter has been written for it,
> > > > > so it can actually be used with an (arguably) high-level language..
> > > > > The whole project, including VHDL code,
> > > > > the eForth interpreter in assembly,
> > > > > a cross assembler writtein in Python
> > > > > and a C emulator for MISC16
> > > > > is available on Github.
> > >
> > > > Sounds great.
> > > Now to get significant numbers of people to adopt it
> > > just requires appropriate documentation.
> > > That was a big failure of the GA144.
> > > Tools were written, but with little documentation.
> > > >
> > > > --
> > > >
> > > > Rick C.
> > > >
> > > > - Get 1,000 miles of free Supercharging
> > > > - Tesla referral code - https://ts.la/richard11209
> > > The project for 2022.
> > Ok. Great. What is the purpose of this MISC CPU? I don't recall just how small it is. Is there a LUT4 count? We can provide it to Jim Brakefield to add to his data on soft CPUs. He doesn't require source code, but I think he is willing to evaluate designs if they are provided. I'm not sure if he does any testing other than compiling to see how many LUTs it uses and likely looks at the code to see the clocks/instruction, etc., but I'm not sure.. I didn't look. Does this design have a test bench?
> >
> > --
> >
> > Rick C.
> >
> > + Get 1,000 miles of free Supercharging
> > + Tesla referral code - https://ts.la/richard11209

> Move processors are rare. This one has only 10 move operations
> (conditional branches counted as one instruction).
>
> Ugh, the design is a bare core: no block RAM for memory.
>
> I used Vivado and the fastest part with free tools: xczu3cg-sfvc784-2-e
> And added a clock constraint file.
> Will place and route with a clock speed greater than 500MHz.
> Uses ~197 LUT6 and ~78 DFF.
> Normal MIPS/instruction for 16-biitter is 0.67.
> In this case reduced MIPS/inst to 0.22 yielding a KIPS/LUT of 558.
> (a move processor requires many loads and stores than normal cpu)
>
> Steve Teal in his 1802-pico-basic design included the block RAM,
> so, would encourage him to do likewise here.
> Would result in a more meaningful Fmax.

Thank you very much for your testing and feedback, I will forward to Steve.
I started this MISC16 as a fun project again to see what can be achieved now.
Steve kindly helped to bring it back to life again and now in FPGA.
As said before, where it ends and how useful it is we will see.
Probably depends on the application.
As said as well, it is a fun project - so actual performance is secondary.
And I only posted it here,
as Steve went through the work
to adapt an eForth with all of the coding details on github for people who are interested.
As Steve has proven, this core is fast enough to run a Forth.
Or the other way around: this eForth could be adapted to run on a custom microprocessor
with very minimal ressources, as you stated:
> Uses ~197 LUT6 and ~78 DFF.

> Ugh, the design is a bare core: no block RAM for memory.
>
> I used Vivado and the fastest part with free tools: xczu3cg-sfvc784-2-e
> And added a clock constraint file.
> Will place and route with a clock speed greater than 500MHz.
> Uses ~197 LUT6 and ~78 DFF.
> Normal MIPS/instruction for 16-biitter is 0.67.
> In this case reduced MIPS/inst to 0.22 yielding a KIPS/LUT of 558.
> (a move processor requires many loads and stores than normal cpu)
>
> Steve Teal in his 1802-pico-basic design included the block RAM,
> so, would encourage him to do likewise here.
> Would result in a more meaningful Fmax.

It seems almost everything has gone due to synthesizer optimization.
Nothing unusual for newbies. 78 DFFs means almost all register were collapsed
because they are unused at all with current schematic. Block RAM is required, and
second port is required too. 500 MHz is non-realistic.

Zynq UltraScale+ is a large FPGA with 100k+ cells. What do you expect to achieve with
0.5% of resources used? :)

On Sunday, January 2, 2022 at 2:26:54 PM UTC-6, Ilya Tarasov wrote:
> > Ugh, the design is a bare core: no block RAM for memory.
> >
> > I used Vivado and the fastest part with free tools: xczu3cg-sfvc784-2-e
> > And added a clock constraint file.
> > Will place and route with a clock speed greater than 500MHz.
> > Uses ~197 LUT6 and ~78 DFF.
> > Normal MIPS/instruction for 16-biitter is 0.67.
> > In this case reduced MIPS/inst to 0.22 yielding a KIPS/LUT of 558.
> > (a move processor requires many loads and stores than normal cpu)
> >
> > Steve Teal in his 1802-pico-basic design included the block RAM,
> > so, would encourage him to do likewise here.
> > Would result in a more meaningful Fmax.
> It seems almost everything has gone due to synthesizer optimization.
> Nothing unusual for newbies. 78 DFFs means almost all register were collapsed
> because they are unused at all with current schematic. Block RAM is required, and
> second port is required too. 500 MHz is non-realistic.
>
> Zynq UltraScale+ is a large FPGA with 100k+ cells. What do you expect to achieve with
> 0.5% of resources used? :)

Ran Steve Teal's other design: pumpkin.
It has program and instruction memory.
For small programs Vivado will use LUT RAM instead of block RAM.
For hello_world_top as top, result was 166 LUTs and 67 DFF.
With myco as top, Vivado still preferred LUT RAM
So forced use of block RAM giving 230 LUTs, 131 DFF and half of a block RAM.
hello_world came in at 625 MHz and myco came in at 450 MHz.

mrisc16 and pumpkin both have small instruction sets which typically results in great Fmax.
For larger designs and larger ISAs and additional memory address modes
these numbers will shrink considerably, to say nothing of adding IO or SOC IP.

I run Zynq UltraScale+ because high Fmax is more fun.
(and am trying to rerun all the designs to get a more uniform comparison)
Artix-7 and Spartan-7 are much more affordable. And will use about the same
numbers of DFF and LUTs for a given design.
Expect Fmax to be 33% lower, after all Artix is 28nm and UltraScale is 16nm.

Arria-2 is the fastest Intel family with free tools.
Intel Cyclone V also has free tools and also has the equivalent of 6LUTs.
LUT4 families typically use 50% more LUTs than LUT6 devices.

Using modern FPGA family parts 200MHz operation should be possible.
Coding style and design complexity have a big influence on Fmax.
Also, DFF numbers should be taken with a grain of salt.
The tools will use additional DFF to improve timing by relaying signals closer to their loads.
In other cases a family will not support LUT RAM due to set/reset operation and
will convert small RAMs to a mass of DFF and multiplexers.

I started this project to find the best or most efficient processors.
At 1K LUTs to the dollar and with many designs using less than 1K LUTs,
and with operation at, say, 200MHz there is considerable opportunity
for small memory custom processors.