Skip to content

Add asserts to br_cdc_bit_pulse and scrub some obsolete TODOs#653

Open
mgottscho wants to merge 4 commits intomainfrom
mgottscho/todo-scrub
Open

Add asserts to br_cdc_bit_pulse and scrub some obsolete TODOs#653
mgottscho wants to merge 4 commits intomainfrom
mgottscho/todo-scrub

Conversation

@mgottscho
Copy link
Copy Markdown
Contributor

No description provided.

@mgottscho mgottscho self-assigned this Apr 25, 2025
@mgottscho mgottscho changed the title Scrub some obsolete TODOs Add asserts to br_cdc_bit_pulse and scrub some obsolete TODOs Apr 25, 2025
@mgottscho mgottscho requested a review from zhemao-openai April 25, 2025 22:40
//------------------------------------------
// Relying on checks in br_cdc_bit_toggle

`BR_ASSERT_CR_INTG(src_pulse_high_then_low_a, src_pulse |=> !src_pulse, src_clk, src_rst)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't add these in my PR because I think this is too stringent. If the source clock is much slower than the destination clock, it would be perfectly fine to have two back to back pulses.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree: the purpose of the module is to transfer pulses. If you're saying you don't have to pulse on the sender side then it seems ill-defined?

Also "two back to back pulses" means there must be a falling edge between, no?

// Relying on checks in br_cdc_bit_toggle

`BR_ASSERT_CR_INTG(src_pulse_high_then_low_a, src_pulse |=> !src_pulse, src_clk, src_rst)
`BR_COVER_CR_INTG(back_to_back_src_pulse_c, src_pulse ##2 src_pulse, src_clk, src_rst)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conversely, if the source clock is much faster than the destination clock, it may not be safe to have pulses two cycles apart on the source clock.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose if this is true then you should probably use a 1-bit CDC FIFO?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you can guarantee that the pulses are sufficiently spaced on the source side, you don't need to use a FIFO. I think if you want to add this cover, you should have a parameter like MinPulseSeparation.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right so I only see two possibilities. Unless I'm missing something.

  1. If you want to guarantee no data loss - use a CDC FIFO.
  2. If you can guarantee the source pulses are far enough apart that they can be synchronized to destination - use this.

If 2, then shouldn't we have the source side assert MinPulseSeparation unconditionally? If it fails, the user should switch to CDC FIFO for their use case?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think have an assert that the pulses are minimum number of cycles apart and have the minimum be configurable.

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