-
Notifications
You must be signed in to change notification settings - Fork 75
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
synchronizers implemented as synthesizable flops #51
Comments
there is a simple way to replace synchronizers with special cells: you can redefine rvsyncss module to instantiate specialized synchronizer cells in design/libs/beh_lib.sv or have it's description in separate module and include the file in flist file for synthesis and simulation. Yes, dbg module should be rewritten to use the rvsyncss with parameter of 2. |
Further to this topic; 2 FF synchronizers are not considered compliant for some teams and foundry technologies. Our default policy/methodology defines 2 DFF synchronization for a single bit signal will be reported as violation. Accordingly, dmi_jtag_to_core_sync.v is considered a non-compliant synchronizer. |
Hi. Please take a look at #56. It allows substituting a custom technology-specific cells for synchronizers. |
Synchronizers need special handling and are usually hardened cells that include both the flops and have much better MTBF.
Using dedicated cells also helps in keeping the data delay between the two flops to minimum that further helps in improving MTBF.
Its a generally accepted practice for reusable IPs to use a dedicated module for synchronizers that can be replaced by integrators with their custom cells.
VeeR core has such synchronizers at below places, I would suggest replacing them with a module which is defined at a place that integrators can replace with their own implementations.
dmi_jtag_to_core_sync.v and (el2_dbg.sv, line 277) has behavioral code for flops acting as synchronizers.
The text was updated successfully, but these errors were encountered: