> How small do you think a xr16-opcode-compatible cpu could be if one didn't
> care about speed? Do you think it could get below 150 logic cells, maybe?

Let me take you on a tour of less through more drastic changes to xr16 to
save area. At some point it ceases to be xr16, but retains its character.
This is no problem because we are now adept at porting to similar
instruction sets, through small changes to our lcc .md file, or to the
assembler.

A non-pipelined, no-DMA xr[n] would save (at least) these resources:
Savings What
n LUTs A forwarding mux
2n FFs A, B operand registers
n LUTs PC register file
(n FFs) PC register
n FFs RETAD register
n FFs DOUT register
n FFs EXIR
-----
2n LUTs 4n FFs

Changing the memory interface to Harvard style would eliminate the need to
save the next instruction in NEXTIR in the event of a load/store instruction
(see 2nd Circuit Cellar article):
Savings What
n LUTs NEXTIR
-----
3n LUTs 4n FFs

Changing the way interrupts work, or cutting them entirely, would eliminate
any further need for IRMUX:
Savings What
n LUTs IRMUX
-----
4n LUTs 4n FFs

Changing the instruction set to 2-operand (no r3=r1 op r2, only r1=r1 op r2)
could save:
Savings What
n LUTs 2nd copy of register file
n FFs "
-----
5n LUTs 5n FFs

Move PC into the register file (say r13), so that each instruction needs an
ifetch sub-cycle and an execute sub-cycle. Here branch displacements would
be added via the IMM mux. All addresses would be available at the ADDSUB
output. Savings:
Savings What
n FFs PC
n LUTs PCINCR
8 LUTs PCDISP
n LUTs ADDRMUX
-----
7n+8 LUTs 6n FFs

Using the output register of a block RAM as the instruction register would
save:
Savings What
n FFs IR
-----
7n+8 LUTs 7n FFs

Halve the datapath into an 8-bit tall datapath and take 2 sub-sub-cycles per
sub-cycle.
Savings What
n/2 LUTs addsub
n/2 LUTs logic
n/2 FFs reg file output register
-----
8n+8 LUTs 7 1/2 n FFs

For n=16, we save 136 LUTs and 120 FFs, so we have a 4-cycle per instruction
RISC in about 165 LUTS => 165 logic cells. So 150 is not out of the
question, but you'd need to change the ISA further. Of course, this
exercise is a little strained because we are taking things away from
something substantial instead of building something simpler up from nothing.


> And, if I were to do one of these in VHDL would that violate the spirit of
> your no-commercial-use license?

The License Agreement speaks for itself and takes precedence over anything I
might write here. That said, one could interpret it to not permit any use
the work or any derivative work for any commercial purpose, and further to
not permit any distribution of a derivative work (except for a modification
to an excerpt).

So, are third party implementations of xr16 considered derivative works?
That depends upon how they are prepared. If one such implementation
contains any part of, or are a mere translation from, the XSOC Kit sources,
it's probably a derivative work.

I am contemplating cleaving the XSOC/xr16 project in two. Here's the
concept: The first part, the instruction set specifications, tests, and
tools, (except for the code covered by the lcc license), GR LLC would
relicense under some open source license that preserves the integrity of the
xr16/xr32 name. The second part, the implementation -- the schematics, HDL
code, and documentation related to that, GRLLC would continue to license
under the XSOC License Agreement. This action, *if taken*, might help
clarify the status of third party implementations based upon the xr specs
and tests and would permit non-derivative clean-room implementations to be
used without contamination with any XSOC-licensed works. It would also make
it easier for you "third parties" to enhance and redistribute changes to the
xr tools suite. If you strongly favor this, please let me know through
private email.

Jan Gray
Gray Research LLC