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

adding more RST_ASYNC_G support #1068

Merged
merged 38 commits into from
Apr 24, 2023
Merged

adding more RST_ASYNC_G support #1068

merged 38 commits into from
Apr 24, 2023

Conversation

ruck314
Copy link
Contributor

@ruck314 ruck314 commented Apr 7, 2023

Description

  • Required for ASIC digital designs that are fundamentally ASYNC resets for all FFs

@ruck314 ruck314 marked this pull request as ready for review April 8, 2023 04:11
Copy link
Contributor

@cbakalis-slac cbakalis-slac left a comment

Choose a reason for hiding this comment

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

Hi,
I reviewed the changes, and found some points that potentially need addressing.
If you disagree or have any further comments, please let me know, otherwise I will just proceed and push changes (unless the protocol is different - it has been a while since I have done a review). I am actually unsure about a couple of these points myself.

Comments on files and specific lines:

axi/axi-stream/rtl/AxiStreamFifo.vhd
L416: do we want to apply the RST_ASYNC_G here?

axi/axi-stream/rtl/AxiStreamFifoV2.vhd
L302: add fifoValidInt in sens list

axi/axi-stream/rtl/AxiStreamRingBuffer.vhd
L307:
pretty sure it should be:
if ( RST_ASYNC_G = false and (dataRst = '1' or bufferClearSync = '1') ) then

base/crc/rtl/CRC32Rtl.vhd
L105: add CRCRESET in sens list

base/crc/rtl/Crc32.vhd
L114: do we need to add a check for RST_ASYNC_G = false here?
also, on a general note, is it proper to have the async process be reset by crcReset and the sync process to be reset by 'crcPwrOnRst'?

base/crc/rtl/Crc32Parallel.vhd
L124: do we need to add a check for RST_ASYNC_G = false here?
also, like in Crc32.vhd, the same comment about different resets applies here too.

base/delay/rtl/SlvDelay.vhd
L92: add check for RST_ASYNC_G = false here
L104: add 'if (RST_ASYNC_G and rst = RST_POLARITY_G) then'
(unless we do not want to reset these regs)
L112: add rst to sens list

base/delay/rtl/SlvDelayFifo.vhd
L33: justify

base/sync/rtl/SyncMinMax.vhd
L167: pretty sure it should be:
if ( RST_ASYNC_G = false and (wrRst = '1' or resetStat = '1') ) then

base/sync/rtl/SyncTrigPeriod.vhd
L129: pretty sure it should be:
if ( RST_ASYNC_G = false and (locRst = '1' or resetStat = '1') ) then

base/sync/rtl/SynchronizerOneShot.vhd
L120: it should be:
if (RST_ASYNC_G = false and rst = RST_POLARITY_G) then

dsp/fixed/FirFilterTap.vhd
L25: justify leftmost colon

protocols/ssi/rtl/SsiCmdMasterPulser.vhd
L52: need to add locRst to sensitivity list

protocols/ssi/rtl/SsiPrbsRateGen.vhd
L163: need to add localRst to sens list (look @L229)

maybe set all default values of ASYNC_RST_G to false for consistency. Files that need changes include:

axi/axi-lite/rtl/AxiLiteFifoPushPop.vhd
axi/axi-lite/rtl/AxiLiteFifoPop.vhd
axi/axi-lite/rtl/AxiLiteFifoPush.vhd
protocols/line-codes/rtl/Encoder8b10b.vhd
protocols/line-codes/rtl/Encoder10b12b.vhd
protocols/line-codes/rtl/Decoder10b12b.vhd
protocols/sugoi/rtl/SugoiSubordinateFsm.vhd
protocols/sugoi/rtl/SugoiSubordinateCore.vhd
protocols/ssp/rtl/SspDeframer.vhd
protocols/ssp/rtl/SspDecoder10b12b.vhd
protocols/ssp/rtl/SspDecoder8b10b.vhd
protocols/ssp/rtl/SspEncoder8b10b.vhd
protocols/ssp/rtl/SspEncoder12b14b.vhd
protocols/ssp/rtl/SspEncoder10b12b.vhd
protocols/ssp/rtl/SspDecoder12b14b.vhd
protocols/ssp/rtl/SspFramer.vhd
protocols/ssp/tb/SspDecoder8b10bTb.vhd
protocols/ssp/tb/SspEncoder8b10bTb.vhd
protocols/ssp/tb/Ssp12b14bTb.vhd
protocols/ssp/tb/Ssp10b12bTb.vhd

@ruck314
Copy link
Contributor Author

ruck314 commented Apr 14, 2023

@cbakalis-slac I have applied your recommendations in the following comment:

base/crc/rtl/Crc32.vhd
L114: do we need to add a check for RST_ASYNC_G = false here?
also, on a general note, is it proper to have the async process be reset by crcReset and the sync process to be reset by 'crcPwrOnRst'?

base/crc/rtl/Crc32Parallel.vhd
L124: do we need to add a check for RST_ASYNC_G = false here?
also, like in Crc32.vhd, the same comment about different resets applies here too.

Crc32.vhd and Crc32Parallel.vhd implements combinational logic after the reset is asserted in the comb process. This is why the crcPwrOnRst input port was added to these two modules

base/delay/rtl/SlvDelay.vhd
L104: add 'if (RST_ASYNC_G and rst = RST_POLARITY_G) then'
(unless we do not want to reset these regs)

These recommendations would not infer into a SRL privative. So not applied.

@ruck314
Copy link
Contributor Author

ruck314 commented Apr 14, 2023

@bengineerd What are your thoughts about this review recommendation below? My concern is that ASIC designers will need to be notified that they can't use the defaults on those module generics.

maybe set all default values of ASYNC_RST_G to false for consistency. Files that need changes include:
protocols/line-codes/rtl/Encoder8b10b.vhd
protocols/line-codes/rtl/Encoder10b12b.vhd
protocols/line-codes/rtl/Decoder10b12b.vhd
protocols/ssp/rtl/SspDeframer.vhd
protocols/ssp/rtl/SspDecoder10b12b.vhd
protocols/ssp/rtl/SspDecoder8b10b.vhd
protocols/ssp/rtl/SspEncoder8b10b.vhd
protocols/ssp/rtl/SspEncoder12b14b.vhd
protocols/ssp/rtl/SspEncoder10b12b.vhd
protocols/ssp/rtl/SspDecoder12b14b.vhd
protocols/ssp/rtl/SspFramer.vhd
protocols/ssp/tb/SspDecoder8b10bTb.vhd
protocols/ssp/tb/SspEncoder8b10bTb.vhd
protocols/ssp/tb/Ssp12b14bTb.vhd
protocols/ssp/tb/Ssp10b12bTb.vhd

Copy link
Contributor

@cbakalis-slac cbakalis-slac left a comment

Choose a reason for hiding this comment

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

Thanks for implementing the changes I commented on.

Approved on my end.

(the default-to-false comment can go through if Ben agrees on it too)

@bengineerd bengineerd self-requested a review April 24, 2023 17:29
@ruck314 ruck314 merged commit 07dafda into pre-release Apr 24, 2023
@ruck314 ruck314 deleted the ESCORE-782 branch April 24, 2023 17:54
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.

3 participants