Bump TestChipIp to improve default serial_tl behavior

[jerryz123]

Previously, a special config fragment was necessary to prevent the chip from generating serial_tl packets during reset. Additionally, this was done using AsyncQueues, instead of just BlockDuringReset.

This changes all designs to block serial_tl while under reset

Related PRs / Issues:

Type of change:

• Bug fix
• New feature
• Other enhancement

Impact:

• RTL change
• Software change (RISC-V software)
• Build system change
• Other

Contributor Checklist:

• Did you set main as the base branch?
• Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
• Did you state the type-of-change/impact?
• Did you delete any extraneous prints/debugging code?
• Did you mark the PR with a changelog: label?
• (If applicable) Did you update the conda .conda-lock.yml file if you updated the conda requirements file?
• (If applicable) Did you add documentation for the feature?
• (If applicable) Did you add a test demonstrating the PR?

• (If applicable) Did you mark the PR as Please Backport?

[T-K-233]

Is it possible to change the chip config order to:

class ChipLikeQuadRocketConfig extends Config(
  // Set up TestHarness
  
  // Set up I/O

  // Set up tiles

  // Set up clock./reset
)

(io go after tiles)?

This way is cleaner, such that periphery devices (backing mem, uart, spi etc) are added after the core.

[jerryz123]

Is it possible to change the chip config order to:

class ChipLikeQuadRocketConfig extends Config(
  // Set up TestHarness
  
  // Set up I/O

  // Set up tiles

  // Set up clock./reset
)

(io go after tiles)?

This way is cleaner, such that periphery devices (backing mem, uart, spi etc) are added after the core.

I think that should be fine, if you do it in another PR.
Is this just for code hygiene, or is there a functional difference due to the order of peripherals w.r.t. cores that you are seeing?