[openrisc] Re: OpenRISC eCos package

[Scott Furman <sfurman@rosum.com>]

[Re-sending as plain text message, since ecos-discuss rejects MIME 
multipart/alternative]

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




--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml