<tpb>
Title: GSoC Proposal: Optimization of VPR File Formats - Google Docs (at docs.google.com)
Bertl_zZ is now known as Bertl
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
proteusguy has quit [Ping timeout: 250 seconds]
<sf-slack>
<risto.pejasinovic> I had to re-evaluate my time and unfortunately I will not apply for GSoC. I will prioritize finishing exams and bachelor thesis, also probably will be in full time position during summer. I don't want to get myself in situation to fail any of these activities. However I am still going to work on proposed project on my spare time, so your help won't be in vain. Thanks to all for help.
citypw has quit [Ping timeout: 245 seconds]
analognoise has joined #symbiflow
analognoise has quit [Read error: Connection reset by peer]
<tpb>
Title: GSoC19 Project proposal: Convert the Verilog to Routing test runner from Perl to Python - Google Docs (at docs.google.com)
<sf-slack>
<arora.prayas> I still have 3 hours left before the deadline. Any feedback would highly appreciated :slightly_smiling_face:
Islam has joined #symbiflow
<Islam>
JOIN
proteusguy has joined #symbiflow
Islam has quit [Ping timeout: 256 seconds]
analognoise has quit [Ping timeout: 250 seconds]
OmniMancer has quit [Quit: Leaving.]
<mithro>
Morning
auto-autocrat has joined #symbiflow
<kgugala>
Morning
<sf-slack>
<mkurc> @litghost So I guess we can talk about the foreign keys on the IRC
<litghost>
mkurc: Indded
<sf-slack>
<mkurc> First of all I am not very familiar with the SQL, but I know the concept of primary keys and foreign keys.
<sf-slack>
<mkurc> The reason I didn't use them is that I wanted to have a grid location map which is separate from the tile table
<litghost>
mkurc: A general priniciple of normalized data is to not repeat data
<litghost>
mkurc: If you want to relate two tables, foreign keys are how you do it
<sf-slack>
<mkurc> Yes, I know
<litghost>
mkurc: In a 1:1 or 1:many relationship, you would typically embedded the foreign key in the "1" table
<litghost>
mkurc: Given that tile remapping is actually a many:many relationship, having a seperate table for the map makes the most sense
<litghost>
mkurc: And because there is a many to many relationship, foreign keys are less ambiguous than coordinates
<sf-slack>
<mkurc> Yes, but i was thinking: what if there is a location when there is no tile and you still want to know where that location maps to.
<sf-slack>
<mkurc> *where
<litghost>
mkurc: All tiles, even empty tiles, should have a row in either the phy_tile or tile table
<litghost>
mkurc: I guess I should clarify
<sf-slack>
<mkurc> Ok, so there will never be any "holes" in the grid ?
<litghost>
mkurc: NULL tiles which have no fly over wires or pips don't need to be represented
<litghost>
mkurc: This is because nothing would ever refer to them
<litghost>
mkurc: However VBRK tiles should have an entry, because there are pips and wires in those tiles, but no sites
<sf-slack>
<mkurc> mhm
<litghost>
mkurc: No, both vivado and VPR have no holes in their grid
<litghost>
mkurc: Vivado has "NULL" and VPR has "EMPTY"
<litghost>
mkurc: Whether we choose to have a row in the database for those tiles is up to us
<sf-slack>
<mkurc> Ok, so I guess that it solves my concern about using foreign keys.
<sf-slack>
<mkurc> I will implement the solution you propose.
<litghost>
mkurc: How did you represent the pip VPR -> Vivado lookup?
<litghost>
e.g. reverse lookup
<sf-slack>
<mkurc> Haven't yet done it
<litghost>
mkurc: Okay
<sf-slack>
<mkurc> I have only location mapping which allows to change location of tiles. Nothing more for now
<litghost>
mkurc: Okay, good start. I recommend starting to think about how you want to handle the pip and site split
<sf-slack>
<mkurc> The issue I am having right now is that once I integrated the location mapping with your change which introduced the constant network, the VPR fails to route to those constants in some cases.
<sf-slack>
<mkurc> For example: When I shift the whole grid east by eg. 10 locations (by generating appropriate map) then routing to consts fails.
<sf-slack>
<mkurc> However, when I shift the whole grid north by 10 location is succeeds.
<sf-slack>
<mkurc> And I am puzzled because I think I identified all places when the location mapping occurs. All stuff related to creating the const. network operates on tiles which have the new locations.
<litghost>
mkurc: I'll take a look and see if I can find something
<sf-slack>
<mkurc> @litghost Right now it shifts the whole grid to the east by 2 tiles.
<litghost>
mkurc: ok
<sf-slack>
<mkurc> @litghost I have a question: I've seen in the VPR gui that the synthetic VCC and GND tiles have OPIN facing north. But channels for the constant are formed as vertical (CHANY) tracks for every column (I presume) and there is one CHANX at the very top of the grid (north). Shouldn't the OPIN be facing east or west ?
<litghost>
mkurc: Possible, but I believe an error is generated if the VCC/GND tile cannot be connected
<sf-slack>
<acomodi> update on equivalent tiles: finally with some other workarounds I could get to the end of VPR flow. I need to slightly rethink how the pin mapping is accessed, but right now I have a clearer idea on what was the issue
<sf-slack>
<acomodi> Basically the application of the mapping has to be extended to some utility functions in VPR and there is the need to have also a bidarectional map to come back from the pin of the equivalent type to the pin of the original type
<duck2>
so this project gets xdl to dump all connections and pips(rr_graph+arch.xml?) and compresses it into some form of tileconn.json, and then it can use that tileconn to route?
<tpb>
Title: Home - The Haskell Tool Stack (at docs.haskellstack.org)
<hackerfoo>
The consumer of infinite RAM and disk space.
<hackerfoo>
This is what happens when language-specific packaging tools don't cooperate. It seems to insist on building a special version of GHC and all dependencies for each project.
<hackerfoo>
Even with the correct version of GHC installed globally.
auto-autocrat has quit [Remote host closed the connection]