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

Synchronously de-assert asynchronous reset #428

Merged
merged 1 commit into from
Nov 23, 2018

Conversation

christiaanb
Copy link
Member

@christiaanb christiaanb commented Nov 23, 2018

We can only model a synchronous deassertion of an asynchronous reset. This manifests itself when we use a reset synchronizer:

When we do a synchronous deassertion of the reset, the HDL simulation and Clash simulation would differ; where the HDL simulation corresponds to how the actual circuit would behave. i.e. the Clash simulation was wrong!

The reason for this is that we modeled a register with an asynchronous reset as if its reset line was always asynchronously deasserted. Given that we can only create synchronous systems in Clash, it made no sense that the model of the register behaved like this.

We now model a register with an asynchronous reset as if its reset line is always synchronously deasserted, and the HDL primitive for the asyncResetGen is updated accordingly (i.e. it deasserts synchronously), so that the Clash and HDL simulation agree.

We can only model a synchronous deassertion of an asynchronous
reset. This manifests itself when we use a reset synchronizer:

When we do a synchronous deassertion of the reset, the HDL simulation
and Clash simulation would differ; where the HDL simulation
corresponds to how the actual circuit would behave. i.e. the
Clash simulation was wrong!

The reason for this is that we modeled a register with an
asynchronous reset as if its reset line was always asynchronously
deasserted. Given that we can only create synchronous systems in
Clash, it made no sense that the model of the register behaved
like this.

We now model a register with an asynchronous reset as if its
reset line is always synchronously deasserted, and the HDL
primitive for the `asyncResetGen` is updated accordingly
(i.e. it deasserts synchronously), so that the Clash and HDL
simulation agree.
@martijnbastiaan martijnbastiaan merged commit b94a43a into master Nov 23, 2018
@martijnbastiaan martijnbastiaan deleted the synchronous-deassertion branch November 23, 2018 14:01
martijnbastiaan pushed a commit that referenced this pull request Nov 28, 2018
We can only model a synchronous deassertion of an asynchronous
reset. This manifests itself when we use a reset synchronizer:

When we do a synchronous deassertion of the reset, the HDL simulation
and Clash simulation would differ; where the HDL simulation
corresponds to how the actual circuit would behave. i.e. the
Clash simulation was wrong!

The reason for this is that we modeled a register with an
asynchronous reset as if its reset line was always asynchronously
deasserted. Given that we can only create synchronous systems in
Clash, it made no sense that the model of the register behaved
like this.

We now model a register with an asynchronous reset as if its
reset line is always synchronously deasserted, and the HDL
primitive for the `asyncResetGen` is updated accordingly
(i.e. it deasserts synchronously), so that the Clash and HDL
simulation agree.
martijnbastiaan added a commit that referenced this pull request Jun 6, 2019
PR #428 does this for `assert`, but didn't account for
`assertBitVector`.
martijnbastiaan added a commit that referenced this pull request Jun 6, 2019
PR #428 does this for `assert`, but didn't account for
`assertBitVector`.
martijnbastiaan added a commit that referenced this pull request Jun 6, 2019
PR #428 does this for `assert`, but didn't account for
`assertBitVector`. Also updates verilog/systemverilog
blackboxes.
martijnbastiaan added a commit that referenced this pull request Jun 6, 2019
PR #428 does this for `assert`, but didn't account for
`assertBitVector`. Also updates verilog/systemverilog
blackboxes.
martijnbastiaan added a commit that referenced this pull request Jun 7, 2019
PR #428 does this for `assert`, but didn't account for
`assertBitVector`. Also updates verilog/systemverilog
blackboxes.
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

Successfully merging this pull request may close these issues.

2 participants