Added CV32E40P example constraints #545
Conversation
Signed-off-by: Arjan Bink <[email protected]>
constraints/cv32e40p_core.sdc
Outdated
| set out_delay_data_we [expr $clock_period * 0.57] | ||
| set out_delay_data_be [expr $clock_period * 0.57] | ||
| set out_delay_data_addr [expr $clock_period * 0.57] | ||
| set out_delay_data_wdata [expr $clock_period * 0.57] |
There was a problem hiding this comment.
Why cannot we assume that output and input delay from/to memories are the same?
These numbers (0.83 and 0.57) look very specific to a given technology
There was a problem hiding this comment.
Hi @davideschiavone I want to convey that memory related output come out roughly midway through the cycle and that memory related inputs are expected to arrive late. The numbers will always be tech specific, which is why there is a comment at the top about that. Would it be okay if I just round the numbers: 0.57 -> 0.6, 0.83 -> 0.8. I do not really care about the actual numbers as long as the signals arriving from memory are assumed to arrive later than that we will guarantee the availability of the signals towards memory (this will assure there are no dis-allowed combinatorial paths inside the core for the OBI interfaces. If you have other nrs in mind, please let me know.
There was a problem hiding this comment.
0.6 and 0.8 with the comments look ok.
Is there a specific reason why we are saying that we leave inside the core 40% to go out (1-0.6) and we have only 20% (1-0.8) from the response? why not , for example, 30% each?
There was a problem hiding this comment.
The numbers are based on what is possible plus what is expected from the environment. In particular the OBI inputs are expected to arrive very late in the cycle if you are building a system without wait states.
There was a problem hiding this comment.
Yes I understand the number per se, I don't understand why it's different between input and output
constraints/cv32e40p_core.sdc
Outdated
|
|
||
| # I/O delays for non RISC-V Bus Interface ports | ||
| set in_delay_other [expr $clock_period * 0.10] | ||
| set out_delay_other [expr $clock_period * 0.57] |
There was a problem hiding this comment.
Okay to just round 0.57 to 0.6?
|
Thanks for this PR @Silabs-ArjanB. Having synthesis constraints adds credibility to this project. Couldl you add the "SPDX" license tag to the header? I hate to nag about this, but it is important. Thanks. |
Hi @MikeOpenHWGroup The above is just our standard license file. I just looked at the latest commit in core-v-verif and it looks the same to me, see https://github.com/MikeOpenHWGroup/core-v-verif/blob/1c36bde284a0e9971dc02cf2fa7c1c3940cf2d08/cv32/env/uvme_cv32/uvme_cv32_tdefs.sv |
You are right about that. I have an action item from the Eclipse Foundation to add the SPDX line to all files in core-v-verif. Sounds like fun doesn't it? Just trying to save you the same hassle. |
I propose that somebody writes a script and fixes all files in this repos as opposed to do ad-hoc single fixes. |
I agree that would be the best (well, at least the fastest) approach. However, for core-v-verif at least, I need to ensure that the original contributor of the code signs off on any changes to the copyright header. Painful. |
Yes, sounds like fun indeed. For now I stick to the header that my company approved though. |
Signed-off-by: Arjan Bink <[email protected]>
Hi @davideschiavone Can you please review these example constraints?
Could you also close/reject the following as I think we should not be adding tool/technology specific flows in this repos (that could be done in core-v-mcu if we have the need for it)
Signed-off-by: Arjan Bink [email protected]