1. posterid:1782663
  2. Proposal v2: Intro to the Spec and Profiles

Re: Proposal v2: Intro to the Spec and Profiles

Tim Newsome
 

In configuration-structure we have struggled with this problem a little as well. So far we're using YAML/JSON5. It doesn't matter to me which of these (or equivalent) formats is used, but a user-writable tree seems reasonable. https://github.com/riscv/configuration-structure/blob/master/binary/descriptions/example.yaml is an example of some work in progress.

I do feel strongly that the description should be in terms of functionality (e.g. F extension is implemented) instead of in terms of CSR (e.g. bit 5 in CSR 0x301 is set).

Tim


On Mon, Oct 26, 2020 at 6:37 AM Mark Himelstein <markhimelstein@...> wrote:
one of the reasons profiles and configs are part of the profiles and platform group is because there were too many formats. some have inherited formats but many are ours that are homegrown.

I suggest you pick one. I will help propagate it.

- new isa ml
- input to arch tests yaml
- config
- formal model & spec (has to be in sync)
- device tree (has to be in sync)

I suggest something with an industry standard parser.

my hope is that we can consolidate some of the duplicate info.

Mark

On Mon, Oct 26, 2020 at 2:04 AM Andrew Jones <drjones@...> wrote:
On Mon, Oct 26, 2020 at 12:00:49AM -0400, Sean Anderson wrote:
> The tuple is an awful format and I sincerely suggest that you
> reconsider some other representation.
>

Named fields help those of us with bad memories. How about using yaml?

profile:
  user: linux
  firmware: uefi
  supervisor: opensbi
  hardware: rackmount
  processor: rv64gc
  boot: uefi
  enumeration: acpi
  secondary-boot-loader: grub2

If this form is too verbose or otherwise inconvenient, then one can
just create a short-named alias for it local to their artifact.

Thanks,
drew
Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.