Native Async reset support in RtlNetlist?

[jesseclin]

Dear @Nic30:

Do you consider adding native asynchronous reset support with hwtLib compatibility like this in RtlNetlist to make it more ASIC-friendly(IMHO)? Thanks.

[Nic30]

I propose following solution:

• Lets add asyncRst parameter to:
  • https://github.com/Nic30/hwt/blob/master/hwt/synthesizer/rtlLevel/netlist.py#L47
  • https://github.com/Nic30/hwt/blob/master/hwt/synthesizer/interfaceLevel/unitImplHelpers.py#L223
• Lets add IS_SYNC to reset interface classes https://github.com/Nic30/hwt/blob/master/hwt/interfaces/std.py#L113
• If sync/async reset is explicitly specified, get default reset and check if it async or not https://github.com/Nic30/hwt/blob/master/hwt/synthesizer/interfaceLevel/unitImplHelpers.py#L248

With this you will be using async reset on Units with async reset if you do not override reset in _reg() call. Would this be sufficient for your case?

I wish I know:

• Is it common to use sync and async resets for the same register?
• Should async reset and sync reset value be different?
• Is it common to use multiple async resets for the same register?
• Is async reset somehow associated with clock domain and could be the case that there are multiple clock domains which do have own async reset?

[jesseclin]

Hi @Nic30:

We prefer to reuse the classes defined in hwtLib for ASIC design without manually converting them to an async reset style. If your solution can provide that, it is very welcome. Thanks.

Also, here are my opinions about your questions for reference:

Is it common to use sync and async resets for the same register?

It is possible, but in our async-reset design style, we usually treat the sync reset as another data signal if needed.

Should the async reset and sync reset values be different?

IMHO, letting users choose either of the reset styles is enough in most cases.

Is it common to use multiple async resets for the same register?

No, we never saw that kind of register in ASIC's standard cell library.

Is async reset somehow associated with the clock domain? It could be the case that multiple clock domains have their own async reset.

Our coding rules for your reference:

• Different clocks: belong to different clock domain
• Same clocks but different async resets: belong to different clock domain
• Same clocks but different sync resets: belong to the same clock domain

[Nic30]

Hi @jesseclin ,

in this case, lets do this:

• lets add IS_SYNC to reset interfaces as I suggested earlier, but lets initialize it to NOT_SPECIFIED
• if reset type is not explicitly specified to True/False, lets query a platform object.
• Platform is passed to to_rtl* functions and should used to make decisions based on target device properties. Lets add something like defaultResetType = RESET_TYPE.SYNC / .ASYNC there

Example of use:

class Reg(Unit):
    def _config(self):
       self.rst_IS_SYNC = Param(NOT_SPECIFIED) 
    def _declr(self):
        addClkRst(self)
        self.rst.IS_SYNC = self.rst_IS_SYNC

        self.din = Signal()
        self.dout = Signal()._m()

    def _impl(self):
        internReg = self._reg("internReg", BIT, def_val=False)

        internReg(self.din)
        self.dout(internReg)

u = Reg()
print(to_rtl_str(u, rarget_platform=DummyPlatform(defaultResetType = RESET_TYPE.ASYNC)))
# internReg will have async reset as platform specifies

u = Reg()
print(to_rtl_str(u))
# internReg will have sync reset because it is default in DummyPlatform constructor and not overridden  

u = Reg()
u.rst_IS_SYNC = True
print(to_rtl_str(u, rarget_platform=DummyPlatform( defaultResetType = RESET_TYPE.ASYNC)))
# internReg will have sync reset because it uses default reset of component which is explicitly set to be synchronous

Do you see any issue with this approach?

[jesseclin]

Hi @Nic30:

Great, and it should be able to fulfill our needs; thanks.