Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] A proposal for CSRs #2

Open
ghost opened this issue Sep 27, 2019 · 6 comments
Open

[Request] A proposal for CSRs #2

ghost opened this issue Sep 27, 2019 · 6 comments

Comments

@ghost
Copy link

ghost commented Sep 27, 2019

#1 Following the general ideas discussed, I have made a new abstraction for CSR objects in my fork (HarryMakes@ba5f354 fixed). An example script is given below, which will print all the fields and their properties in a CSR named "test". You might also test the slicing functionality using the format mycsr[beginbit:endbit], but please note that the upper boundary is exclusive.

from nmigen import *

from nmigen_soc.csr import *

if __name__ == "__main__":
    mycsr = CSRGeneric("test", size=64, access=ACCESS_R_W, desc="A R/W test register")
    mycsr.f += CSRField("enable", desc="Enable signal", enums=['OFF', 'ON'])
    mycsr.f += CSRField("is_writing", size=2, access=ACCESS_R, desc="Status signal of writing or not",
                        enums=[
                              ("YES", 1),
                              ("NO", 0),
                              ("UNDEFINED", 2)
                        ])
    mycsr.f += CSRField("is_reading", size=2, access=ACCESS_R, desc="Status signal of reading or not")
    mycsr.f.is_reading.e += [
        ("UNDEFINED", 2),
        ("YES", 1),
        ("NO", 0)
    ]
    mycsr.f += CSRField("is_busy", size=2, access=ACCESS_R_WONCE, desc="Busy signal",
                        enums=[
                              ("YES", 1),
                              ("NO", 0),
                              ("UNKNOWN", -1)
                        ])
    mycsr.f += [
        CSRField("misc_a", size=32),
        CSRField("misc_b"),
        CSRField("misc_c")
    ]
    mycsr.f.misc_a.e += [
        ("HOT", 100000000),
        ("COLD", -100000000),
        ("NEUTRAL", 0)
    ]
    #mycsr.f += CSRField("impossible", size=30, startbit=6)

    print("{} (size={}) is {} : {}".format(
            mycsr.name, 
            mycsr.size,
            mycsr.access,
            mycsr.desc))
    for x in mycsr._fields:
        print("    {} [{},{}] (size={}) is {}{}".format(
            mycsr._fields[x].name, 
            mycsr._fields[x].startbit,
            mycsr._fields[x].endbit, 
            mycsr._fields[x].size,
            mycsr._fields[x].access,
            (" : "+mycsr._fields[x].desc if mycsr._fields[x].desc is not None else "")))
@ghost
Copy link
Author

ghost commented Sep 27, 2019

For reference, here are the meanings of the access type Enums:

  • ACCESS_R : Read-only
  • ACCESS_W : Write-only
  • ACCESS_R_W : Both read and write are allowed
  • ACCESS_WONCE : Write-only, and only once per reset
  • ACCESS_R_WONCE : Both read and write are allowed, but only one write is allowed per reset

Please also refer to: http://www.keil.com/pack/doc/CMSIS/SVD/html/elem_special.html#elem_access

@whitequark
Copy link
Contributor

Thanks, I'll take a look soon.

@whitequark
Copy link
Contributor

Thank you for the proposal. I have in mind some ways to simplify the code in your branch. I'm going to sketch out an implementation I have in mind, and then ask you for feedback to make sure I didn't miss anything important.

@mithro
Copy link

mithro commented Apr 29, 2020

@xobs - FYI

@xobs
Copy link

xobs commented Apr 29, 2020

How does this work for don't care fields?

For example, in the SVD format you can specify x for values that should be marked "do not care".

@ghost
Copy link
Author

ghost commented May 10, 2020

Edit: my pull request has overlooked this specification where "don't care" exists within enumerated values themselves. This should be open for discussion.


@mithro @xobs My implementation is now a pull request in #7.

Each register has a Signal storing its whole value. The value of each of its fields are Slices of this signal, e.g. [ start_bit : end_bit+1 ]. Thus, while fields can be referred to either by name or bit locations, "don't care" bits can be referred to only by their bit locations. Take the following example:

image

The register write_only only has a field val on bits 2-3, whose value can be represented as any one of the following expressions:

  • write_only.f.val.s
  • write_only.f.val[:]
  • write_only[2:]

The bits 0-1 are not represented using any field name, but only as the following expression:

  • write_only[0:2]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants