Pipelined units from data/components.json
#257
Replies: 6 comments
|
I think the assumption is that any sequential component is pipelined with an II of 1, but tagging people who may know @Carmine50 and @Jiahui17 to double-check. |
|
Yes, for our components, that's a common assumption. I'm not sure, though, if this will be applied in the future, too. |
|
Thanks! |
@lana555 and @lucas-rami, is this intentional and wise? I seem to recall that we discussed at some length the timing modelling of components and II is a pretty important parameter. Is it II = 1 by default if one does not specify it in the timing model (which then would be perfectly fine) or is it that there is no way to specify an II other than 1 (with 1 being then probably an implicit assumption in the code itself...). I cannot add Louis here, but I will forward this to him, as he might know something. |
I think we just never used any IPs with II > 1 (also in legacy Dynamatic) so everything is assumed to have II = 1. I think extending it is not hard; for instance, in the timing model file: "handshake.addf": {
"latency": {
"64": 9.0
},
+++ "II": {
+++ "64": 2.0
+++ },
Also, theoretically we know how to write constraints for pipelines with II > 1 (in FPGA '20). |
|
Thanks. Personally, I would add "II" or "initiation-interval" to the spec and use II = 1 only if the model does not specify otherwise. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I am working on a project which requires to know, at the handshake level, which long-latency components are pipelined (thus, which is their Initiation Interval).
I wonder if there's a way to get this information. AFAIK, the
latencyentry incomponents.jsonexpresses the amount of clock cycles required to obtain the result, but I can't see any other meaningful data. Is there any assumption we can make,related to the hardware components we have?All reactions