search

riscv / configuration-structure

RISC-V Configuration Structure
https://jira.riscv.org/browse/RVG-50
Creative Commons Attribution 4.0 International
36 stars 16 forks source link

Don't be too clever about hart IDs. #71

Closed timsifive closed 2 years ago

timsifive commented 2 years ago

Clever size: examples/debug_module.jer is 18B in UPER examples/example.jer is 79B in UPER

New size: examples/debug_module.jer is 18B in UPER examples/example.jer is 98B in UPER

changab commented 2 years ago

Why don't we use flexible size for the small value? This increases the size of CS.

timsifive commented 2 years ago

The consensus on this thread: https://lists.riscv.org/g/tech-config/topic/compact_hart_ids/88331290?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,88331290,previd=1642015376542336034,nextid=1632764771051557009&previd=1642015376542336034&nextid=1632764771051557009

seems to be that it's better to keep things easy to use than it is to save the extra bytes. (Somebody also emailed me with that opinion directly. I'm not sure why they didn't respond to the thread.) Another point that was brought up is that having the various sizes increases the size of the decoder a little.

changab commented 2 years ago

The consensus on this thread: https://lists.riscv.org/g/tech-config/topic/compact_hart_ids/88331290?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,88331290,previd=1642015376542336034,nextid=1632764771051557009&previd=1642015376542336034&nextid=1632764771051557009

seems to be that it's better to keep things easy to use than it is to save the extra bytes. (Somebody also emailed me with that opinion directly. I'm not sure why they didn't respond to the thread.) Another point that was brought up is that having the various sizes increases the size of the decoder a little.

There may have more and more values that occupied two bytes just for a small number, so the size is not just saved in 20B. A few bytes of code increased (case-switch) seems not a big deal. I think CS stays in the separate SPI ROM or NV storage other than the one that accommodates the code (decoder in FW). The lower capacity and cost of storage that can afford the optimized -size of CS seem important than spending the cost on the little code size increased as we discussed before. That is interesting that people don't quite care about the size of CS now. :)

timsifive commented 2 years ago

There may have more and more values that occupied two bytes just for a small number, so the size is not just saved in 20B.

That is true, but I think that systems where size matters will have at most 4 harts, so there really shouldn't be more than 4 hartIds listed. In really tiny systems with just a single hart the lists can even be empty and there is no benefit to the more complex encoding.

A few bytes of code increased (case-switch) seems not a big deal.

I agree, it's not the main reason for this change.

For me the main reason for this change is that it makes it easier to use the structure, both to write it and to parse it. ASN.1 tools will write parsers etc but those would still end up in separate structures. So people will have to manually think about/write code to deal with the possibility that the same data might show up in 4 different structures. We could write wrapper code to help with this, but we already don't have the resources to write the code we think is important.

changab commented 2 years ago

ok, we just keep it simple for now.

changab commented 2 years ago

We could write wrapper code to help with this, but we already don't have the resources to write the code we think is important.

That is for sure we will have the wrapper as the helper function in the firmware solution instead of using the code generated by ASN.1 directly. So the interface should just return an integer which doesn't matter to the number of bits declared in the CS.