Re: [oc] Interested in helping out

["Rehan Hameed" <rnhameed@crosswinds.net>]

David Kessner wrote:

> Tensilica is similar, but has significant differences.  To my knowledge,
> Tensilica allows you do design the core first, adding blocks that you
> would want, and then it configures the compiler/assembler to support
> that CPU.  What I proposed is the reverse:  write your code first then
> configure the core appropriately.
>
> 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 :(

They have defined a basic configurable architecture with a basic instruction
set. This instruction set contains some compulsary instructions and some
optional instructions. The design flow starts by defining the 'First
Instance' of your processor. Using a formal specification language you
specify the hardware configuration including parameters such as the size of
register file, width of ALU, size of memory, data formats supported in
calcultions etc. You also specify the instruction set using the same formal
specification language. The tool takes that specification and generates the
compiler, simulator and assembler for that specification. Now you take a set
of benchmark programs containing the typical routines used in your
application(s). These programs are compiled by the generated compiler into
the specified instruction set. These are analyzed by the MetaCore analyzer.
The analyzer gives you the frequency of each instruction used. Also it
indicates the instruction sequences found in those programs which could be
combined into single more complex instructions; or single instructions which
could be broken into smaller instructions. It also indicates the hardware
cost incurred and performance achieved by building a more complex
instruction or the cost saved and performance lost by braking into simpler
oerations. All this info helps the designer in refining the instruction set
in a way which results in best cost, performance pair for that particular
application. The process could be done in many iterations so that you keep
on trying different changes and see the result. When you finalize the
design, the HDL code, simulator, compiler and assembler are generated by the
MetaCore system

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.

> 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.