[openrisc] Re: OpenRISC eCos package

[Scott Furman <sfurman@rosum.com>]

Title:

Robert Cragie wrote:
> 1) What's the best way to approach configuration for a 'soft' processor like
> this whose architecture can be configured? My thoughts are that you could
> either:
For those on the ecos-discuss mailing list that may not be familiar
with the issue, Robert is referring to the fact that the OpenRISC
processor is a "synthesizable soft-core" CPU.  It is distributed in the
form of code that can be customized and then compiled into hardware of
different types.  Cache size, number and width of registers, whether or
not MMUs are present or certain instructions are implemented,  are all
choices made available to the CPU designer.  In fact, there are dozens
of options permitted by the OpenRISC architecture document, not to
mention support for adding custom instructions and memory units.  That
creates, effectively, the potential for a near-infinite number of CPU
variants.

There are architecture-defined registers in the CPU that indicates how
CPU options/parameters have been customized, so theoretically one could
create a HAL architecture port that adapts at run time to the OpenRISC
processor HW, disabling support for CPU features that are
unimplemented.  That approach, however, would result in both some
inefficiency and code bloat, so it's more likely that support would be
compiled into eCos just for those CPU features/options that are
implemented in the target CPU.
> a) Include support for everything in the arch and have them selectable via
> cdl_packages/cdl_options
> b) Properly define variants and platforms and use cdl_interface to indicate
> the options variants/platforms export.
>
> (a) seems acceptable for now, but (b) seems to be the 'proper' solution
> based on the tenet of configurability promoted by eCos. However, given the
> configurability of the OpenRISC CPU, I guess (b) could potentially give you
> a large number of combinations - I'm not sure if this would be a problem.
I think the eCos variant system isn't as useful with a synthesizable
CPU architecture as with conventional architectures, where the menu of
CPU variants is comparitively small.  Rather than picking the single HAL
variant corresponding to the features of CPU model xyz, a developer
configuring eCos for OpenRISC must add a variant package for each
implemented hardware option (cache, floating point support, MMU, 64-bit
regs, etc.) and set the value of CDL parameters for each of those
variant packages, e.g. cache size, number of registers.  In this case,
the CPU "variants" are really just HAL architecture options that can be
mixed-and-matched almost arbitrarily.   So, I think the issue boils
down to whether or not the code for an option lives in a separate HAL
variant subdir or in the HAL's arch subdir.

As to whether model (a) or (b) is correct, I think we should lean
towards whatever is customary in the eCos codebase.  However, I also
think whether or not (a) or (b) is correct is partly a matter of
mindset: Should one think of the CPU architecture as a whole entity with
pieces that can be optionally disabled or as a small core logic ball
with pieces that can optionally be glommed on ?

For any particular CPU option, I would be more likely to segregate the
corresponding HAL code into its own variant subdir if:

• It represents a single choice among several different HW variants rather than merely disabling/enabling a HW option, e.g. one type of on-chip memory controller chosen from a menu of several possible memory controllers or,
  
• The code  can be cleanly separated out, e.g. without littering the architecture HAL code with numerous macro invocations or,
  
• It represents a HW extension not defined by the OpenRISC architecture document, and
  
• It's a non-trivial amount of code.
  

> 2) Looking at the ARM HAL, cache support is in the platform subdirectory,
> whereas for OpenRISC it is in the 'arch' subdirectory. Shouldn't it be in
> the platform subdirectory?
This all goes to the issue you raise above as to whether or not variant
subdirs are appropriate for OpenRISC, but the short answer is that,
since there was only one variant at the time I ported eCos, I didn't
make the effort to create a separate variant for the feature.  Also,

• Cache support is an option in the OpenRISC architecture HAL, so it can be turned off.
  
• If you accidentally enable eCos cache support on an OpenRISC CPU that doesn't have cache HW, it's innocuous. It's also only a few instructions worth of code, so it's not likely to be much of a bloat factor.

Maybe the right thing to do is to have the code read the CPU config
registers and disable cache support at run time if it's not supported by
the CPU HW.
> Out of interest, what template did you use for the port?
I picked out useful chunks mostly from MIPS and a little from PowerPC
and ARM..

-Scott