Friday, 2019-10-25

*** tpb has joined #symbiflow00:00
tpbTitle: murax_routing.log · GitHub (at
hackerfooAnd ~1200s to calculate the lookahead with a 4x4 grid.03:23
hackerfooI haven't profiled yet, though. I suspect std::unordered_map is a bottleneck.03:24
*** citypw has joined #symbiflow03:36
*** OmniMancer has joined #symbiflow04:24
*** Bertl_zZ is now known as Bertl06:02
*** OmniMancer has quit IRC07:47
*** Bertl is now known as Bertl_oO07:52
*** clacktronics has quit IRC09:02
*** freemint has joined #symbiflow09:58
*** OmniMancer has joined #symbiflow11:16
sf-slack<tmichalak> @litghost I have some initial thoughts on the INTERNAL_VREF FASM input and possible solutions ( All comments are welcome.12:09
tpbTitle: Google Docs - create and edit documents online, for free. (at
*** clacktronics has joined #symbiflow12:32
*** stzsch has quit IRC13:12
*** stzsch has joined #symbiflow13:17
*** kuldeep has quit IRC13:57
*** craigo has quit IRC15:44
*** citypw has quit IRC16:13
litghosthackerfoo: Is that at ?16:28
tpbTitle: parallelize connection box lookahead · HackerFoo/[email protected] · GitHub (at
litghosthackerfoo: 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 that16:31
hackerfooNo, I'm still trying some things; I think I can improve it quite a bit more.16:37
litghost1200 seconds for the 50T is approaching "good enough", the current lookahead code takes 1500 sec on the basys3 (1/5 50T)16:39
litghostIf 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 important16:40
litghostThe 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 concern16:42
*** OmniMancer has quit IRC17:19
litghostmkurc: The iterate_xml function is super useful, thanks!18:13
mithrotmichalak / litghost: I commented on your INTERNAL_VREF stuff and proposed the different solution18:20
litghostmithro: Ya that solution doesn't work at all :/18:20
mithrolitghost: Why?18:21
litghostbanks have no BELs18:21
litghostSo there is nothing to attach the parameter too18:21
mithrolitghost: So create one?18:21
litghostbitstream configuration is a similiar one18:21
litghostWhy would we intentionally break backwards compability with vendor tools?18:22
mithroNothing stops us from creating new bels?18:22
litghostSure, but that would mean Verilog would only work on our tools, which seems undesirable18:23
mithrolitghost: The idea would be that Yosys parses the xdc / sdc file and creates the bels as needed?18:24
litghostYa, 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?18:25
mithrolitghost: What do you mean it never uses?18:25
litghostThe reason no BEL exists for a  bank is it doesn't get any routing18:26
litghostThink about a BEL that might represent/hold bitstream configuration18:26
litghostThat BEL would have no input  and no output18:26
litghostjust parameters18:26
litghostBoth yosys and VPR would attempt to prune such a thing18:27
litghostSo we would need to make extra effort just to keep the BEL through the flow18:27
mithroThe IO tiles are part of an IO bank, right?18:27
litghostThis seems like a really really bad idea18:27
litghostNot really18:27
litghostThe connection between IO and banks is invisible to the router18:27
mithroHow are banks and io tiles related?18:27
litghostIt only exists in the hardware itself18:27
litghostIO tiles belong to a bank, but from a pack/place/route perspective they are unrelated18:28
mithroIf I try to pack two IO objects into a single bank which have different VREF requirements, it should fail, right?18:29
litghostYa, but that isn't something to enforce in VPR18:29
litghostWe eventually will need the idea of a DRC, which is where that check belongs18:29
mithroWhy not? If we could get better DDR performance by swapping the byte pins, that seems like something the placer should be allowed to do?18:30
litghostFor 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 time18:31
litghostIt isn't something that is solve in P&R18:31
tpbTitle: AR# 38913: DCI Cascading - Can there be more than one master bank in a column? (at
mithrolitghost: There are many cases where you can swap pins and it has no effect on the hardware side of things.18:33
litghostBank compatiblity and selection is not something that is solved for, it is specified18:34
litghoste.g. you knew that pins x/y/z all required VREF x (not VREF y), so you put them in banks together18:34
litghostIf you mess this up, the PCB is useless18:34
litghostKeep in mind that VREF requirements are a function of IOSTANDARD18:35
litghostWhat circumstances would IOSTANDARD be anything other than a constraint from the PCB, rather than a free variable18:35
tpbTitle: Artix-7 FGG484 DDR Planning - Google Sheets (at
litghostBut would moving the pin functions every change the IOSTANDARD / VREF?18:38
litghostThat's not what I asked18:40
litghostEven if two pins can swap functionality from a DDR, does the IOSTANDARD / VREF change?18:40
litghostMy 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?18:48
mithrolitghost: 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?18:48
mithrolitghost: The reason they should be presented in the EDA tools is so they can check your design is compatible with the PCB itself18:49
litghostYa, but neither Yosys nor VPR should be checking them.   They are ill suited to it18:49
mithrolitghost: 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>]`18:52
mithro/ Specifies a “HIGH” voltage for the VCCAUX_IO rail connected to this I/O18:53
mithro(* VCCAUX_IO = "HIGH" *) input ACT3,18:53
mithroLooking through -- about the only thing which doesn't seem to have a way to be set via Verilog parameters is the `INTERNAL_VREF`18:54
litghostI don't believe any of the bitstream parameters have vivado properties19:07
mithrolitghost: Looks like vivado calls these "configuration constraints" in
mithrolitghost: 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?19:19
litghostlitghost: It is a per bank setting19:19
mithrolitghost: 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...19:20
litghostmithro: But in that case you don't care about generating a bitstream19:22
mithrolitghost: 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?19:23
*** kuldeep has joined #symbiflow19:23
litghostIO compability requirements are listed in "Rules for Combining I/O Standards in the Same Bank" in "7 Series FPGAs SelectIO Resources User Guide"19:25
litghostSome IOSTANDARD's do not require a VREF at all19:26
mithrolitghost: Actually -- isn't it actually a property of that individual IO tile? IE If you use the IO tile as a VREF?19:27
mithroVREF - 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.19:27
litghostSorry, maybe we are getting our wires crossed19:29
litghostEach IO bank has an INTERNAL_VREF19:29
litghostIt is bank wide, and optional19:29
litghostFor IOSTANDARD's that require a Vref, you can either have the Vref come in via a pin, or use the internal VREF19:30
litghostThat configuration is what is all about19:30
tpbTitle: Google Docs - create and edit documents online, for free. (at
litghostFrom an IOSTANDARD compability standpoint, two IO standards with different Vref requirements cannot be placed in the same bank19:31
litghostThis is rule number 2 in "Rules for Combining I/O Standards in the Same Bank"19:31
litghost" Input standards with the same VCCO and VREF requirements can be combined in the same bank."19:31
tpbTitle: Google Drawings - create diagrams and charts, for free. (at
litghostmithro: Pretty much19:42
litghostmithro: But VPR doesn't have a way to enforce that the VREF's match the IOSTANDARD19:42
litghostmithro: There is a upcoming idea in VPR about placement constraints19:44
litghostmithro: I don't know a lot about them19:44
tpbTitle: Add Placement Constraints to VPR · Issue #932 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostOne thing on your diagram, I believe the choice is between a VREF pin and the internal VREF at various voltages19:47
litghostI don't believe a bank have more than 1 VREF pin choice?19:47
litghosthackerfoo/duck2: was merged upstream.  I'll be rebasing and
tpbTitle: Initial place matrix serialization/deserialization support. by litghost · Pull Request #989 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithrolitghost: 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?20:08
litghostmithro: I'm more thinking about bitstream configuration.  If there are two VREF's per bank, then that means we are missing some bitstream bits20:09
litghostmithro: I do agree it doesn't change the diagram20:09
litghosthackerfoo/duck2: I was able to cleanly rebase onto the new connection_box_serdes_merged_squashed with:20:13
litghost"git rebase --onto connection_box_serdes_merge_squashed upstream/connection_box_serdes_merge_squashed wip/lookahead_sampling"20:13
litghostMake that:20:14
litghostgit rebase --onto a56cb11fbff1eadac737f4a6edce341af333c1a6 a81d5eab19f179767210096f4441f22e1a5cff32 wip/lookahead_sampling20:14
litghostBecause your branch labels may be different than me20:14
litghosthackerfoo/duck2/acomodi: WIP branches that were affected (changed/closed) by upstream merges have been resolved.20:23
mithrolitghost: See IO Bank X I added to
tpbTitle: Google Drawings - create diagrams and charts, for free. (at
litghostmithro: Sorry, what are your trying to show and/or do?21:10
litghostmithro: I'm now confused21:10
mithrolitghost: 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.21:16
litghostmithro: But that doesn't remotely help enforce that VREF's must be consistent21:16
litghostVPR (and the router) don't care about what is on VREF itself21:17
litghostIt's just a net21:17
litghostthe requirement is that the VREF's match the IOSTANDARD, that's not something the router can do21:17
mithroBut you can't assign both the VREF_1V2 and VREF_3V3 nets to the Internal VREF black box?21:19
litghostHow does the packer know which  VREF to use?  You would need to explode the number of modes and root level pins on the IOPAD21:20
mithroI think there is a confusion in terminology here...21:23
litghostI agree?21:23
litghostAh, you want to try to put the INTERNAL_VREF in an IO tile21:27
litghostWon't work21:27
litghostmithro: That approach doesn't work for a couple reason21:33
mithroI added a bunch of extra text21:33
litghostmithro: If you need two IO banks, and are using two external VREFs, then the net layout is a function of placement21:33
litghostmithro: Two external VREFs of the same voltage *21:34
mithrolitghost: The issue being that placement doesn't know that certain placements will end up with impossible routing situations?21:35
litghostmithro: 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 net21:36
mithroThat is why VREF is a "IO placement constraint"?21:36
litghostThe placement constraints in seem like a better answer than trying to leverage the router21:36
tpbTitle: Add Placement Constraints to VPR · Issue #932 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostBut net's have nothing to do with it21:37
litghostI don't think you can easily express the underlying constraint in terms of a routing problem21:37
mithroAs the constraints come from what you can /actually/ route in hardware I don't think that is true?21:38
litghostThat is incorrect21:38
litghostIf you have two IO banks that share the same voltage (but potentially different VREF sources), the constraint cannot be net orientied21:38
mithrolitghost: You are configuring the IO voltage supplied to the top of the IO buffer transistors21:39
litghostBut the placement problem is only a function of "can this IOSTANDARD be placed in this bank without conflict"21:39
litghostthe IO placement problem*21:39
litghostYou are conflating how we configure the hardware, with what the placer/router are doing21:40
mithrolitghost: Which in the hardware is directly related to how you can route the voltage supply to the IO buffers21:40
litghostmithro: Incorrect21:40
mithrolitghost: Explain why that is incorrect21:40
litghostmithro: For example, if every INTERNAL_VREF in the chip is the same, there is no routing problem at all21:41
mithrolitghost: Voltage can't magically appear at the IO buffer21:41
litghostmithro: All IO pads are legal21:41
litghostmithro: 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 problem21:42
litghostmithro: But it isn't expressed as a per bank problem21:42
litghostmithro: It is a per VREF problem21:42
mithrolitghost: 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 buffers21:43
litghostmithro: 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 voltage21:44
mithrolitghost: That is the same as GND or VCC though?21:45
litghostmithro: That could be leveraged to work for INTERNAL_VREF, but not if the user has any external VREF's21:46
litghostmithro: Compability between external VREF's would be need to supplied somehow21:46
litghostmithro: Also we'd still have the placer not understanding valid placements21:49
litghostmithro: So the router could be handed an invalid placement that is impossible to route, and it would manifest as an overused rr node21:49
litghostmithro: Less than ideal21:49
mithroOkay, I'm starting to buy your argument...21:51
litghostmithro: This is not to say we should not teach VPR's placer about IO bank compability21:53
litghostmithro: And we could potentially optionally derive the INTERNAL_VREF from the IOSTANDARD's as placed21:54
mithroBTW Do you set INTERNAL_VREF to an actual voltage level?21:54
litghostmithro: Yes21:54
litghostmithro: It has 4 settings I believe?21:54
litghosthackerfoo: How goes the lookahead on your end?21:56
mithrolitghost: are there any more "whole bank parameters" other than vref?22:00
litghostmithro: Not to my immediate knowledge22:01
litghostmithro: VCCAUX_IO is bank wide, but can be set via Verilog as you said22:01
litghostmithro: There are bitstream wide parameters22:01
litghostSome of them show in the bitstream itself, some don't22:02
mithrolitghost: 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 wrote23:05
litghostmithro: But the parsing of xdc/sdc has nothing to do with understanding nets?23:06
mithrolitghost: Most of the xdc/sdc constraints are "placed" on nets / ports / blocks23:07
mithro`set_property SLEW FAST [get_ports ddram_dm[0]]`23:07
litghostBut those are top-level nets, and they don't get munged?23:07
mithro`set_io clk E3`23:07
litghostSo 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 stuff23:09
litghostClocks/set_false_path is a totally different story23:09
mithroMost 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 complicated23:09
litghostYa, core generators do get fuzzy23:09
mithroLike the MCB sets a whole bunch of properties on the ports of the memory core23:13

Generated by 2.13.1 by Marius Gedminas - find it at!