Allow optional soft reset option to be passed into deassert_risc_reset_at_core

[abhullar-tt]

Issue

#287

Description

Metal needed ability to deassert only the second risc on BH ethernet cores

List of the changes

Added an optional parameter to deassert_risc_reset_at_core API

Testing

Will be opening up a PR in Metal on top of this branch and will run post commit and BH post commit.
Metal post commit
Metal Blackhole post commit

API Changes

This PR has non-breaking API changes:

• tt_metal approved PR pointing to this branch
• tt_debuda approved PR pointing to this branch: link -- is this needed if it is not breaking?

[broskoTT]

Regarding comment in the PR:
This PR has API changes, but due to default value, no breaking API changes.
No need for PR links to any repo.

Any idea how could we maybe unit test this behavior in UMD?
Maybe at least add a very simple example to api_chip_test (we're trying to add any api to tests/api which we touch, and end up with all the APIs being touched).

[abhullar-tt]

ple example to api_chip_test (we're trying to add any api to tests/api which we touch, and end up with all the APIs being touched).

we're

How about:

• test that asserts reset, deasserts with legal value, then reads back reset reg to make sure the deassert goes through and
• test that asserts reset, deasserts with some illegal value, then reads back reset reg to make sure its in a legal state?

[broskoTT]

@abhullar-tt Thanks for the tests! Just take a look on why aren't they passing on remote chips...