This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: OpenRISC eCos package


[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





--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]