-
Notifications
You must be signed in to change notification settings - Fork 416
How to express packing that introduces constant nets #654
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
Comments
Poke @vaughnbetz @kmurray |
Yes, this looks like a tricky one. When you say the clk needs to be set high on the clk pb_type pin, I think you mean that the one slice-wide clock must be set to vcc for any of the latches/FFs to be used as route throughs. Is that right? That constraint could probably be modeled as a mode that put the entire slice into a mode where you can only use the latches as route-throughs, but that doesn't seem very useful or worth the complexity. Before getting into the details of how to support that though, what is the goal / upside? Are you just trying to make FFs usable as route-throughs to gain a small amount of routability, or is there some functionality that requires this? If you're just trying to gain a small amount of routability I'd put this on the back burner, as route-throughs like this aren't nearly as important as general packing, placement and routing optimization quality. So adding complexity to try to leverage them is most likely to be counter-productive if you're just trying to obtain QoR, as it will take effort away from more important QoR tasks. |
I completely agree with this sentiment, however!
A QoR change in Yosys (e.g. synthesis change) is what brought this about. In particular, the CARRY4 primitive has 8 outputs (4 CO and 4 O). If those outputs are not registered (e.g. no FF directly at the output), then 8 ports are required. By default only 4 ports are available, unless the FF's are put into passthrough.
Your understanding is exactly correct, and exactly what Vivado does if more than 4 ports from a CARRY4 is required. |
I think in the short term, I'll see if I can make Yosys return a synthesis that doesn't require this feature, and we can delay support of it. |
Sounds good. If you want to flip the whole mode it's probably doable with an architecture file change. But it is quite rare for a design to need both the CO and O (sumout?) signals, except that the next bit of the carry chain needs the CO output, but that should be done with dedicated routing. |
This is the approach I'm taking. I can simply remove the CO output from the CARRY4 altogether, because as you said, you can always use the sumout as a CO. |
This issue has been inactive for a year and has been marked as stale. It will be closed in 15 days if it continues to be stale. If you believe this is still an issue, please add a comment. |
This issue has been marked stale for 15 days and has been automatically closed. |
I'm trying to express a packing behavior that I think cannot be easily expressed using the arch xml format, but maybe I just haven't thought about it right.
The feature that I want to express is FF pass through by leveraging the FF in latch mode. So presume that the FF bank supports a latch mode, something akin to a gated D latch. Logic table:

In order to treat the latch as a pass through, the CLK/gate line should be tied high, so that the latch remains passing the input to the output. However, in order for this to be true, it means that the CLK pb_type pin needs to be a specific value, e.g. high in this case. But as far as I know, there is no way to express "when using this packing, the following net must exist".
What is the recommended solution? Will this require a new feature in VPR to express such a construct?
Here is a reduced version of the pb_type for illustration:
The text was updated successfully, but these errors were encountered: