CPU design

Walter Banks wrote:

> 
> Jim Granville wrote:
> 
> 
>>The tiniest CPUs do not need a stack, and interupts do not need to be
>>re-entrant, so a faster context switch is to re-map the Registers, Flags
>>(and even PC ? ) onto a different area in BRAM.
>>You can share this resource by INTs re-map top-down, and calls re-map
>>bottom up - with a hardware trap when they collide :)
> 
> 
> Once you get into seeing clearly the relationship between features and
> cost a lot can be removed.
> 
> Interrupts can be removed at extremely low cost to applications. Both the
>   Microchip PIC12  and Freescale RS08 do not have interrupts. In the
>   RS08 C compiler we developed some software IP to where possible
>   go into a power down mode and launch execution threads that compiled as
>   execution to completion.
> 
>   The threads are typically short and a as a side effect run to completion
>   makes local re-use easy
> 
> C compilers implemented for small processors work well with out either
> a data or subroutine return stack. Two of the processors we have written
> compilers for in the last couple years both used an assessable return
> register. Flow control analysis in the compiler make nested subroutines
> user transparent.
> 
> The instruction set reduction in the RS08 from the S08 parent had a
> 4-6% impact on application performance.
> 
> Walter..

Hi Walter,
  Have you ever thought about doing a Compiler+FPGA_CPU (+Sim+Debug?) 
bundle ?

-jg

Frank Buss wrote:
> PeteS wrote:
>
> > Do you want a processor you can simply instantiate, or are you willing
> > to tweak so you get the features you want? If so, you could take one of
> > the less ambitious cores and adjust the instruction set to optimise it
> > for your application.
>
> Adjusting the instruction set to the problem domain is a good idea. I'll
> try to write the functions, first, maybe using domain specific instructions
> (like a block copy command), and then I'll implement the core for it.
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de

I did exactly this in a previous job. Picoblaze was nice, but there
were things it did not have, and conversely things I would never use.

So I did the code (pseudocode first) and then designed the device to do
the necessary functions at the microcode level. Because my problem
domain was very constrained, I needed only 16 instructions (I like it
when I get nice numbers like that as a solution) to do what I needed.

Then I wrote (well, I changed :) an assembler to program it.

Worked very well, and took about half the space of a picoblaze,
including a DMAC engine (excluding the memory interface which was there
anyway).

Cheers

PeteS

PeteS wrote:
> Frank Buss wrote:
> > PeteS wrote:
> >
> > > Do you want a processor you can simply instantiate, or are you willing
> > > to tweak so you get the features you want? If so, you could take one of
> > > the less ambitious cores and adjust the instruction set to optimise it
> > > for your application.
> >
> > Adjusting the instruction set to the problem domain is a good idea. I'll
> > try to write the functions, first, maybe using domain specific instructions
> > (like a block copy command), and then I'll implement the core for it.
> >
> > --
> > Frank Buss, fb@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de
>
> I did exactly this in a previous job. Picoblaze was nice, but there
> were things it did not have, and conversely things I would never use.
>
> So I did the code (pseudocode first) and then designed the device to do
> the necessary functions at the microcode level. Because my problem
> domain was very constrained, I needed only 16 instructions (I like it
> when I get nice numbers like that as a solution) to do what I needed.
>
> Then I wrote (well, I changed :) an assembler to program it.
>
> Worked very well, and took about half the space of a picoblaze,
> including a DMAC engine (excluding the memory interface which was there
> anyway).
>
> Cheers
>
> PeteS

AHDL for a two register NOP, INC, DEC, WRITE unit

http://indi.joox.net link to quartus II files, BIREGU.bdf

good for interruptable stack pointers

jacko wrote:

> AHDL for a two register NOP, INC, DEC, WRITE unit
> 
> http://indi.joox.net link to quartus II files, BIREGU.bdf
> 
> good for interruptable stack pointers

This looks like a net list or something like this. I have only ISE WebPack
installed and I don't know how to display it. Do you have a picture of it?

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Jim,

We have certainly thought about it. Byte Craft has done quite a bit of
instruction design work on embedded commercial processors. Internally
for every C compiler we create an instruction set simulator  with a lot of
performance instrumentation.

I expect the next round of processors will move towards multiple processor
solutions to applications. Compilers and other HLL tools will be focused on
application work division.

w..



Jim Granville wrote:

> Walter Banks wrote:
>
> >
> > Interrupts can be removed at extremely low cost to applications. Both the
> >   Microchip PIC12  and Freescale RS08 do not have interrupts. In the
> >   RS08 C compiler we developed some software IP to where possible
> >   go into a power down mode and launch execution threads that compiled as
> >   execution to completion.
> >
> >   The threads are typically short and a as a side effect run to completion
> >   makes local re-use easy
> >
> > C compilers implemented for small processors work well with out either
> > a data or subroutine return stack. Two of the processors we have written
> > compilers for in the last couple years both used an assessable return
> > register. Flow control analysis in the compiler make nested subroutines
> > user transparent.
> >
> > The instruction set reduction in the RS08 from the S08 parent had a
> > 4-6% impact on application performance.
> >
> > Walter..
>
> Hi Walter,
>   Have you ever thought about doing a Compiler+FPGA_CPU (+Sim+Debug?)
> bundle ?
>
> -jg

Walter Banks wrote:
> Jim,
> 
> We have certainly thought about it. Byte Craft has done quite a bit of
> instruction design work on embedded commercial processors. Internally
> for every C compiler we create an instruction set simulator  with a lot of
> performance instrumentation.
> 
> I expect the next round of processors will move towards multiple processor
> solutions to applications. Compilers and other HLL tools will be focused on
> application work division.
> 
> w..

Sounds promising. What about debug pathways ?

-jg

Jim,

The automotive processors use a separate communication link (most are on board packet switched virtual links) to each processor brought out through a interface on the chip. (Nexus) There are support standards for this.

The asian processors that we have created support for were lockstepped simulation and hardware to extract more information for the developers.

Most of the current processors that I am seeing are using asynchronous background  BDM or JTAG brought out through a limited number of pins.

Watch this space later in the year for information on the consumer products multiprocessor debug support.

w..


Jim Granville wrote:

> Walter Banks wrote:
> > Jim,
> >
> > We have certainly thought about it. Byte Craft has done quite a bit of
> > instruction design work on embedded commercial processors. Internally
> > for every C compiler we create an instruction set simulator  with a lot of
> > performance instrumentation.
> >
> > I expect the next round of processors will move towards multiple processor
> > solutions to applications. Compilers and other HLL tools will be focused on
> > application work division.
> >
> > w..
>
> Sounds promising. What about debug pathways ?
>
> -jg

Frank Buss wrote:
> jacko wrote:
>
> >
> > http://indi.joox.net link to quartus II files
>
> This looks like a net list or something like this. I have only ISE WebPack
> installed and I don't know how to display it. Do you have a picture of it?

i think ahdl custom to altera. there tool is web downloaded. could
notget the xilinx tool to download after 5 attempts.

website more specific.

the zip file is current project design files in quartus II version 6,
but still have to design instruction sequencing unit. thought of using
an 8 cycle simple instruction execution, for a very compact IP core.
also decided that modular forth in instancable blocks would be most
flexible.

it is going to evolve as a 16n design, as all carry can happen along
multiple instances to make any 16*n word size, but i have to decide how
the program word width may or may not expand to the word size.

i hope to get wishbone and avalon bus interfaces too, but this is not
my immediate priority.

i intend a serial bus standard to allow connected multicore designs,
each core having 128KB memory.

does anyone know how to export a quartus project as VHDL?

cheesr

jacko

jacko schrieb:

> Frank Buss wrote:
> > jacko wrote:
> >
> > >
> > > http://indi.joox.net link to quartus II files
> >
> > This looks like a net list or something like this. I have only ISE WebPack
> > installed and I don't know how to display it. Do you have a picture of it?
>
> i think ahdl custom to altera. there tool is web downloaded. could
> notget the xilinx tool to download after 5 attempts.
>
> website more specific.
>
> the zip file is current project design files in quartus II version 6,
> but still have to design instruction sequencing unit. thought of using
> an 8 cycle simple instruction execution, for a very compact IP core.
> also decided that modular forth in instancable blocks would be most
> flexible.
>
> it is going to evolve as a 16n design, as all carry can happen along
> multiple instances to make any 16*n word size, but i have to decide how
> the program word width may or may not expand to the word size.
>
> i hope to get wishbone and avalon bus interfaces too, but this is not
> my immediate priority.
>
> i intend a serial bus standard to allow connected multicore designs,
> each core having 128KB memory.
>
> does anyone know how to export a quartus project as VHDL?
>
> cheesr
>
> jacko

Jacko,

you possible have to handconvert the AHDL to VHDL :(
thats the reason I suggested using non-vendor HDL in the first place.

Antti