<litghost>
hackerfoo: Assuming that was 1200s for the full 50T, and the lookahead works on both the basys3 and 50T graphs, let's start an integration run of that
<hackerfoo>
No, I'm still trying some things; I think I can improve it quite a bit more.
<litghost>
k
<litghost>
1200 seconds for the 50T is approaching "good enough", the current lookahead code takes 1500 sec on the basys3 (1/5 50T)
<litghost>
If there are still some low hanging fruit to bring the time on the 50T lower, that will improve iteration time, but once we are in the "get a coffee" time frame, quality of the lookahead starts to become more important
<litghost>
The current overall goal should be "full 50T on CI completing in ~2 hrs", so once we are at or better than the current basys3 lookahead time, the time to route murax/picosoc on that lookahead becomes the more dominate concern
OmniMancer has quit [Quit: Leaving.]
<litghost>
mkurc: The iterate_xml function is super useful, thanks!
<mithro>
tmichalak / litghost: I commented on your INTERNAL_VREF stuff and proposed the different solution
<litghost>
mithro: Ya that solution doesn't work at all :/
<mithro>
litghost: Why?
<litghost>
banks have no BELs
<litghost>
So there is nothing to attach the parameter too
<mithro>
litghost: So create one?
<litghost>
bitstream configuration is a similiar one
<litghost>
Why would we intentionally break backwards compability with vendor tools?
<mithro>
Nothing stops us from creating new bels?
<litghost>
Sure, but that would mean Verilog would only work on our tools, which seems undesirable
<mithro>
litghost: The idea would be that Yosys parses the xdc / sdc file and creates the bels as needed?
<litghost>
Ya, that is a really bad idea, because it means we are adding things to VPR that it never uses. What is the justification for doing such a thing?
<mithro>
litghost: What do you mean it never uses?
<litghost>
The reason no BEL exists for a bank is it doesn't get any routing
<litghost>
Think about a BEL that might represent/hold bitstream configuration
<litghost>
That BEL would have no input and no output
<litghost>
just parameters
<litghost>
Both yosys and VPR would attempt to prune such a thing
<litghost>
So we would need to make extra effort just to keep the BEL through the flow
<mithro>
The IO tiles are part of an IO bank, right?
<litghost>
This seems like a really really bad idea
<litghost>
No
<litghost>
Not really
<litghost>
The connection between IO and banks is invisible to the router
<mithro>
How are banks and io tiles related?
<litghost>
It only exists in the hardware itself
<litghost>
IO tiles belong to a bank, but from a pack/place/route perspective they are unrelated
<mithro>
If I try to pack two IO objects into a single bank which have different VREF requirements, it should fail, right?
<litghost>
Ya, but that isn't something to enforce in VPR
<litghost>
We eventually will need the idea of a DRC, which is where that check belongs
<mithro>
Why not? If we could get better DDR performance by swapping the byte pins, that seems like something the placer should be allowed to do?
<litghost>
For DCI reasons (which is also bankish), I believe the general design constraint is to port related pins like that in the same IO bank at PCB layout time
<litghost>
It isn't something that is solve in P&R
<litghost>
Even if two pins can swap functionality from a DDR, does the IOSTANDARD / VREF change?
<litghost>
My point is, even if we wanted to swap pins from a DDR (or other) functionality standpoint, IOSTANDARD and VREF are not generally free variables, and are rather fixed by the PCB itself. Given that they are fixed, why have them present in the EDA tools at all if no choices are to be made?
<mithro>
litghost: I /think/ the question you are actually asking is -- If I have a set of pins which have a compatible set of IOSTANDARD / VREF configurations, is there ever a scenario where swapping the pins around would result in an incompatible set of IOSTANDARD / VREF configurations?
<mithro>
litghost: The reason they should be presented in the EDA tools is so they can check your design is compatible with the PCB itself
<litghost>
Ya, but neither Yosys nor VPR should be checking them. They are ill suited to it
<mithro>
litghost: so in verilog you can do `(* IOSTANDARD = "value" *)` on a port to set the iostandard **or** you can do a `set_property IOSTANDARD <value> [get_ports <port>]`
<mithro>
/ Specifies a “HIGH” voltage for the VCCAUX_IO rail connected to this I/O
<mithro>
litghost: it seems a bit weird that INTERNAL_VREF is included in the I/O Constraints section when you seem to be right and it is a whole design thing?
<litghost>
litghost: It is a per bank setting
<mithro>
litghost: BTW There is a place and route mode were you let the IO pins locations be unconstrained and let PnR pick good choices which you then send to the PCB designer to make a reality...
<litghost>
mithro: But in that case you don't care about generating a bitstream
<mithro>
litghost: The pins you can use in an IO bank are restricted by if you have INTERNAL_VREF set right? It gives you one more free pin?
kuldeep has joined #symbiflow
<litghost>
IO compability requirements are listed in "Rules for Combining I/O Standards in the Same Bank" in "7 Series FPGAs SelectIO Resources User Guide"
<litghost>
Some IOSTANDARD's do not require a VREF at all
<mithro>
litghost: Actually -- isn't it actually a property of that individual IO tile? IE If you use the IO tile as a VREF?
<mithro>
VREF - Single-ended I/O standards with a differential input buffer require an input reference voltage (VREF). When VREF is required within an I/O bank, the two multi-function VREF pins for the bank must be used as VREF supply inputs.
<litghost>
Sorry, maybe we are getting our wires crossed
<litghost>
Each IO bank has an INTERNAL_VREF
<litghost>
It is bank wide, and optional
<litghost>
For IOSTANDARD's that require a Vref, you can either have the Vref come in via a pin, or use the internal VREF
<tpb>
Title: Initial place matrix serialization/deserialization support. by litghost · Pull Request #989 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<mithro>
litghost: it seemed some banks have two options for a vref in pin, but I'm not confident - but it doesn't really dramatically change the diagram?
<litghost>
mithro: I'm more thinking about bitstream configuration. If there are two VREF's per bank, then that means we are missing some bitstream bits
<litghost>
mithro: I do agree it doesn't change the diagram
<litghost>
hackerfoo/duck2: I was able to cleanly rebase onto the new connection_box_serdes_merged_squashed with:
<litghost>
"git rebase --onto connection_box_serdes_merge_squashed upstream/connection_box_serdes_merge_squashed wip/lookahead_sampling"
<litghost>
Make that:
<litghost>
git rebase --onto a56cb11fbff1eadac737f4a6edce341af333c1a6 a81d5eab19f179767210096f4441f22e1a5cff32 wip/lookahead_sampling
<litghost>
Because your branch labels may be different than me
<litghost>
hackerfoo/duck2/acomodi: WIP branches that were affected (changed/closed) by upstream merges have been resolved.
<tpb>
Title: Google Drawings - create diagrams and charts, for free. (at docs.google.com)
<litghost>
mithro: Sorry, what are your trying to show and/or do?
<litghost>
mithro: I'm now confused
<mithro>
litghost: VREF is a net which is produced by a special IO Tile. There are wires run connect the VREF from the special IO Tile to all IO tiles in a bank. An IO tile may or may not use the VREF net based on the IO configuration. The VREF net may be source from either -- the special internal VREF black box, or the IPIN.
<litghost>
mithro: But that doesn't remotely help enforce that VREF's must be consistent
<litghost>
VPR (and the router) don't care about what is on VREF itself
<litghost>
It's just a net
<litghost>
the requirement is that the VREF's match the IOSTANDARD, that's not something the router can do
<mithro>
But you can't assign both the VREF_1V2 and VREF_3V3 nets to the Internal VREF black box?
<litghost>
How does the packer know which VREF to use? You would need to explode the number of modes and root level pins on the IOPAD
<mithro>
I think there is a confusion in terminology here...
<litghost>
I agree?
<litghost>
Ah, you want to try to put the INTERNAL_VREF in an IO tile
<litghost>
Won't work
<litghost>
mithro: That approach doesn't work for a couple reason
<mithro>
I added a bunch of extra text
<litghost>
mithro: If you need two IO banks, and are using two external VREFs, then the net layout is a function of placement
<litghost>
mithro: Two external VREFs of the same voltage *
<mithro>
litghost: The issue being that placement doesn't know that certain placements will end up with impossible routing situations?
<litghost>
mithro: That, and you don't actually achieve the desired flexiblity, because once the placer understands the impossible routing, you are effectively limiting IO placement based on how you define your VREF net
<mithro>
That is why VREF is a "IO placement constraint"?
<litghost>
I don't think you can easily express the underlying constraint in terms of a routing problem
<mithro>
As the constraints come from what you can /actually/ route in hardware I don't think that is true?
<litghost>
That is incorrect
<litghost>
If you have two IO banks that share the same voltage (but potentially different VREF sources), the constraint cannot be net orientied
<mithro>
litghost: You are configuring the IO voltage supplied to the top of the IO buffer transistors
<litghost>
But the placement problem is only a function of "can this IOSTANDARD be placed in this bank without conflict"
<litghost>
the IO placement problem*
<litghost>
You are conflating how we configure the hardware, with what the placer/router are doing
<mithro>
litghost: Which in the hardware is directly related to how you can route the voltage supply to the IO buffers
<litghost>
mithro: Incorrect
<mithro>
litghost: Explain why that is incorrect
<litghost>
mithro: For example, if every INTERNAL_VREF in the chip is the same, there is no routing problem at all
<mithro>
litghost: Voltage can't magically appear at the IO buffer
<litghost>
mithro: All IO pads are legal
<litghost>
mithro: As as second example, if you require 2 different VREF's, but you need to split it among more than 1 bank each, that is a different problem
<litghost>
mithro: But it isn't expressed as a per bank problem
<litghost>
mithro: It is a per VREF problem
<mithro>
litghost: You can't supply both a 3V3 voltage and a 1V2 voltage to the top of the IO buffers in the same bank -- this is because of how internally inside the hardware the voltage supplies are routed to the IO buffers
<litghost>
mithro: Correct. But if you have 2 banks at 3V3 and 2 banks at 1V2, it is legal to move the buffers within each bank of that voltage
<mithro>
litghost: That is the same as GND or VCC though?
<litghost>
mithro: That could be leveraged to work for INTERNAL_VREF, but not if the user has any external VREF's
<litghost>
mithro: Compability between external VREF's would be need to supplied somehow
<litghost>
mithro: Also we'd still have the placer not understanding valid placements
<litghost>
mithro: So the router could be handed an invalid placement that is impossible to route, and it would manifest as an overused rr node
<litghost>
mithro: Less than ideal
<mithro>
Okay, I'm starting to buy your argument...
<litghost>
mithro: This is not to say we should not teach VPR's placer about IO bank compability
<litghost>
mithro: And we could potentially optionally derive the INTERNAL_VREF from the IOSTANDARD's as placed
<mithro>
BTW Do you set INTERNAL_VREF to an actual voltage level?
<litghost>
mithro: Yes
<litghost>
mithro: It has 4 settings I believe?
<litghost>
hackerfoo: How goes the lookahead on your end?
<mithro>
litghost: are there any more "whole bank parameters" other than vref?
<litghost>
mithro: Not to my immediate knowledge
<litghost>
mithro: VCCAUX_IO is bank wide, but can be set via Verilog as you said
<litghost>
mithro: There are bitstream wide parameters
<litghost>
e.g. BITSTREAM.GENERAL.DEBUGBITSTREAM
<litghost>
Some of them show in the bitstream itself, some don't
<mithro>
litghost: The big reason I think Yosys should be doing the constraint parsing is that only Yosys really has access to the same net names that a user knows / understand -- as things get optimized the netnames bare less and less connection to the Verilog the user wrote
<litghost>
mithro: But the parsing of xdc/sdc has nothing to do with understanding nets?
<mithro>
litghost: Most of the xdc/sdc constraints are "placed" on nets / ports / blocks
<mithro>
`set_property SLEW FAST [get_ports ddram_dm[0]]`
<litghost>
But those are top-level nets, and they don't get munged?
<mithro>
`set_io clk E3`
<litghost>
So I agree that ports and nets are present, but those names flow out of yosys, so there is nothing in particular that yosys needs to transform on the IO specific stuff
<litghost>
Clocks/set_false_path is a totally different story
<mithro>
Most IO constraints get applied to things like top level nets -- but things like timing and bel placement constraints are much more likely to be applied to things further inside the design. When you start getting into things like core generators which are connected to top level ports "through" a users top level things get even more complicated
<litghost>
Ya, core generators do get fuzzy
<mithro>
Like the MCB sets a whole bunch of properties on the ports of the memory core