Re: [oc] Interested in helping out

[David Kessner <davidk@free-ip.com>]

Rehan Hameed wrote:
> David Kessner wrote:
> > My approach potentially has better efficiency, since the decision to cut
> > blocks out is made based on the real software and not what the engineer
> > thinks might be needed sometime in the future.  Engineers will routinely
> > make the CPU more featureful than what is really needed, and the
> > granularity of the pruning process won't be as fine.
> 
> To a certain extent the idea seems a bit similar to MetaCore DSP development
> system developed by KAIST, Korea. Their paper, presented in design
> automation conference 19998, could be obtained from
> 
> http://www.acm.org/pubs/citations/proceedings/dac/277044/p800-yang/
> 
> However to acces it u either need to be a member of ACM digital library or
> you need to pay :(

I won't claim to be the original inventor of this concept.  If I were,
I would have patented by now, and living a good life off of the
royalties!
Just kidding...   

The first place that I saw this was in a DSP core.  It looked nice
but needed a lot of refining.  I have not seen it applied to a simple
8-bit RISC uC.


> The basic idea is same -- to configure your hardware based on the written
> programs. However here the system acts as a tool to help you in figuring out
> the best solution.

Sounds cool.  A little overkill for a 8-Bit RISC, perhaps, but cool 
none the less.  

The concept of having an optimizing C compiler also optimize the
VHDL source is interesting!  


> > Take a barrel shifter, for example.  With Tensilica you decide to
> > include or not include the entire shifter.  With my approach, software
> > will determine that you only ever shift right by 1, 4, and 7 bits so
> > the unused portions could be safely removed.
> 
> Such information is often not available until runtime. For example a common
> operation in DSP applications is to find the number of redundant sign bits
> of a number and then shift it by that number (normalization). Here the
> amount of shift required depends purely on the real time data.

You're right, but...  (there's always a but, isn't there?)

In a typical uC application it is common to only shift by fixed 
amounts.  Shifting by variable amounts is sometimes used, but 
it isn't the norm (it's done, perhaps, 30% of the time).

Now, the MIPS processor has different opcodes for shifting a
fixed amount and shifting based on the contents of a register.
If you used the register based shift, then obviously you cannot
remove parts of the barrel shifter since you don't have aprioi 
knowledge of the shift amounts.

The barrel shifter is just one item.  There are other things that
could be optimized out, of course.  Multipliers/dividers are obvious,
but the part that handles signed multiplies/divides are another non-
obvious candidate.  I'm sure there are more, but it's early in the 
morning and I'm not quite awake...


I think that an 8-bit RISC uC that uses this technique would be
fairly simple to design and turn into a good core.  An engineer
that has designed CPU's before and has C++ knowledge could design
the CPU and simple assembler in about a week (full time)-- so it's
not an unreasonable project for Opencores or Free-IP.  I would do it
but I have other fires burning at the moment.

Something more complex, like the example that you gave, would 
probably be overkill.  It might even turn into one of those projects
that just never seems to end.  It's the kind of thing that you 
form a company out of, rather than just work at on your free time.
Perhaps someone who is lurking on this mailing list is just itching
to throw some VC money at a new startup!  :)


David Kessner
davidk@free-ip.com