<gatecat>
essentially the rule is that site pips should only be used to access site resources; and not to be used for other, general routing
<tpb>
Title: Site PIPs - Pseudo PIPs represent "route through" paths for BELs - Google Zeichnungen (at docs.google.com)
<gatecat>
mithro: yes, both those cases in the doc are valid and legal possibilities (although in the current setup only the former applies)
<gatecat>
but for another arch that had FFs that could be routed through, the latter case would be fine too
<mithro>
@gatecat So when you use a pseudo pip, you end up "blocking" a bunch of bels
<gatecat>
mithro: correct, but that's not the problem to hand
<gatecat>
the problem we're dealing with at the moment would be the router using the router using *both* of those site PIPs to route through the whole site without touching any bels
<gatecat>
which isn't allowed in the interchange format - if the arch wants to support that too, it should provide a tile pseudo PIP (not a site PIP) that routes from site input to output
<mithro>
gatecat: So is Figure B1 illegal?
<gatecat>
mithro: correct, site PIPs can only be used to access bels in the site and not for routing through the entire site
citypw has quit [Ping timeout: 240 seconds]
<gatecat>
if instead of two site PIPs, it was a single *tile* pseudo PIP, it would be fine
<mithro>
@gatecat See Figure C ?
<gatecat>
'Figure C' would be legal if it was a tile pseudo PIP
<gatecat>
and it might make sense, depending on the routing graph, particularly if the design is congested it can open up extra routing options
<mithro>
@gatecat At the tile level is there any reference to bels?
<mithro>
@gatecat It seems like pseudo pips should be at the site level and not tile level?
<gatecat>
mithro: currently we have both, because of the requirement for site routing only to be used to access resources in the site
<gatecat>
they could be at site level only if we remove that constraint
<gatecat>
(it's a constraint of Vivado, aiui, which is how it crept into the interchange format contract too, but we can work around that in the dcp generation if needed)
maartenBE has quit [Ping timeout: 265 seconds]
<mithro>
gatecat: Do you have an exmaple?
<gatecat>
no, not to hand although I think the diagrams show it well enough
<gatecat>
what exactly do you want an example of?
<mithro>
@gatecat I think I understand now -- there is no reason "except Vivado" that the pseudo pips couldn't be just in the site level?
<gatecat>
not that I know of, but there could be a good reason that Vivado disallows use of site routing for anything other than to access bels
<gatecat>
for example some of the more obscure site types
<gatecat>
unfortunately the rationale behind this decision was never documented
<sf-slack1>
<acomodi> I think this was intended to allow the site router to use some additional site-routing constraints, which should not be exposed to the general router, which can only use the tile pseudo PIPs which "hide" the internal site connectivity
<gatecat>
acomodi: yes, this would make sense
<gatecat>
particularly if we wanted to support things like latches-to-legalise-carries in the future, it would be best if they were for the site router only and not exposed to the general router
<gatecat>
there may also be some complexity that I haven't thought of where alternative site types are involved
<sf-slack1>
<acomodi> Indeed, I think the various alt site types corresponding to the IOI tiles are part of this set. I think that in general, the internal site routing and the general router should be well separated, and using different kinds of psuedo PIPs
<gatecat>
oh, I hadn't thought of IOI tiles - they are a very interesting case of this too...
<jokus_malus>
nickoe: Sounds good!
<nickoe>
:)
gromero has quit [Read error: Connection reset by peer]