Fuses and registers are cousins?

[info-rchitect]

All of these things can be accessed with an address and contain bit fields. Should they use a common base object?

[coreyeng]

I think so, but I'm not sure that any of us have experimented with OO in Rust. I tried at first but its easy to get burned by the borrower checker if you're not careful. Possible though.

To add on a bit, I think we should have a base dict-like or list-like structure. I'm going to build on #21 after its merged, but I think we should aim for anything accessible like that to share a common interface. This would include pins, registers, memory maps, parameters, etc. I'd also like to see some generics components for miscellaneous things. I used the equivalent in O1 for toolchain drivers and scan components.

FWIW, this was my intention with Componentable in O1. I bit off more than I could chew with that though and it never went beyond just generic components.

I wouldn't mind signing up for this though once we get pins, registers, and memory maps a bit further along.

[info-rchitect]

👍

[ginty]

What info/functionality would a fuse need over and above a register?
Why could a register not be used to model a fuse?

[info-rchitect]

@ginty I think the register model could be used. How would we work around the lack of method/function aliases?

[info-rchitect]

I think so, but I'm not sure that any of us have experimented with OO in Rust. I tried at first but its easy to get burned by the borrower checker if you're not careful. Possible though.
To add on a bit, I think we should have a base dict-like or list-like structure. I'm going to build on #21 after its merged, but I think we should aim for anything accessible like that to share a common interface. This would include pins, registers, memory maps, parameters, etc. I'd also like to see some generics components for miscellaneous things. I used the equivalent in O1 for toolchain drivers and scan components.
FWIW, this was my intention with Componentable in O1. I bit off more than I could chew with that though and it never went beyond just generic components.
I wouldn't mind signing up for this though once we get pins, registers, and memory maps a bit further along.

BTW, I ended up using Componentable for our internal fuse modeling

[ginty]

@ginty I think the register model could be used. How would we work around the lack of method/function aliases?

For example?
Are we just talking about a preference of using my_fuse.program(0x1234) instead of my_fuse.write(0x1234) or something more?

[info-rchitect]

@ginty I thought I read a post somewhere in the o2 area that Python doesn't support method aliases. I was thinking of how can we make this equivalence while using the same Rust infrastructure?

dut.add_reg == dut.add_fuse

[ginty]

I'm not sure if does support an equivalent of Ruby's alias_method or not, but at the very least you can do:

def add_fuse(self, *args, **kwargs):
  return self.add_reg(*args, **kwargs)

I can imagine that we would support fuses.py in the blocks/ dir which would implement methods like SimpleFuse and Fuse like their reg equivalents, but these would just instantiate reg objects internally.

[info-rchitect]

I'm not sure if does support an equivalent of Ruby's alias_method or not, but at the very least you can do:
def add_fuse(self, *args, **kwargs):
return self.add_reg(*args, **kwargs)
I can imagine that we would support fuses.py in the blocks/ dir which would implement methods like SimpleFuse and Fuse like their reg equivalents, but these would just instantiate reg objects internally.

Works for me, thx!