craigo has quit [Read error: Connection reset by peer]
craigo has joined #symbiflow
craigo has quit [Quit: leaving]
craigo has joined #symbiflow
craigo has quit [Client Quit]
craigo has joined #symbiflow
craigo has quit [Quit: leaving]
craigo has joined #symbiflow
proteusguy has joined #symbiflow
<sf-slack3>
<mkurc> @hackerfoo Well, it works for me. I started with a clean build directory.
craigo has quit [Quit: leaving]
craigo has joined #symbiflow
craigo has quit [Remote host closed the connection]
craigo has joined #symbiflow
Bertl_zZ is now known as Bertl
<sf-slack3>
<acomodi> I have successfully routed and created a bitstream using the BUFG and BUFHCE primitives. The only problem now is that it does not run on HW
<sf-slack3>
<acomodi> The test I have been doing is `counter_basys3`. What happens is that some random leds are switched on (and they are not supposed to be) and there is no blinking happening.
<sf-slack3>
<acomodi> My thought is that there is an issue when generating the frames as maybe the roi_harness is overlapped with the generated FASM, hence the strange behavior of the leds.
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #symbiflow
<sf-slack3>
<mkurc> @hackerfoo: I'm currently working on making prjxray_tile_import.py import all sites and generate correct fasm prefixes for them. I'll try to finish by the end of the day.
adjtm has quit [Ping timeout: 245 seconds]
adjtm has joined #symbiflow
<sf-slack3>
<mkurc> @hackerfoo: I've pushed my changes. The import works except for the inner_pins which is broken now (interconnect generation)
<hackerfoo>
mkurc: Why did you decide to un-split (Y0/Y1) IOPAD? My understanding (from talking to litghost) is that this will make it difficult to select between the two pads in an IOPAD.
Bertl is now known as Bertl_zZ
citypw has quit [Ping timeout: 246 seconds]
freemint has joined #symbiflow
filt3r has quit [Quit: x]
<litghost>
acomodi: I would definitely run bit2verilog on your results and see what is going on
<litghost>
hackerfoo: Did you resolve you packing issue?
<hackerfoo>
litghost: No
<hackerfoo>
mkurc: Adding back "SELECT_Y 1" fixes the build.
<litghost>
hackerfoo: Which packing step is failing? wire.eblif?
<hackerfoo>
Yes.
<litghost>
hackerfoo: So wire.eblif assumes that "assign out = in" will work. We can simulate that same way we support a passthrough ILOGIC, with a mode that defaults to a straight wire
<hackerfoo>
I plan to add a script to generate the map at some later point.
<hackerfoo>
From tileconn.json + channels.db
<litghost>
hackerfoo: There shouldn't be a need to use tileconn.json at all
<litghost>
hackerfoo: The nodes are present in channels.db
<hackerfoo>
It is, but it's elaborated *too* much, there are nodes for every IOI<->IOB tile edge. I only need one.
<hackerfoo>
I could still write a query, even if it's slow. Or maybe pick an arbitrary pair of tiles.
<hackerfoo>
It might be worth splitting nodes by direction, and precomputing for each tile pair, at least when they only cross the tile in one direction.
<hackerfoo>
Not now, though.
<hackerfoo>
*tile type pair
<litghost>
> there are nodes for every IOI<->IOB tile edge. I only need one.
<litghost>
I'm not sure your conclusion is valid. For any given site pin on an IOB or IOI, how do you know if it connects to another site pin?
<hackerfoo>
Don't IOBs and IOIs always connect the same way, at least on the same side of the chip?
<litghost>
hackerfoo: The whole exercise is to not assume a structure, but infer the right thing from the underlying data
<litghost>
hackerfoo: Consider that there may be variation across other chips
<hackerfoo>
The same structure is in the DB, in tileconn.json
<litghost>
hackerfoo: There is also some form of variation within the chip, with the TTERMBYTE, etc
<hackerfoo>
Yeah, but that's a different tile-type pair.
<litghost>
hackerfoo: tileconn.json only provides adjacent tile information, if there is every an intermediate tile, then tileconn is unsuitable for the query you want
<hackerfoo>
At least, nodes-per-tile-type pair would have been exactly what I need for this task.
<hackerfoo>
I can just pick a tile pair, though. That should work, since they will all be the same.,
freemint has quit [Remote host closed the connection]
freemint has joined #symbiflow
adjtm has quit [Ping timeout: 276 seconds]
kraiskil has joined #symbiflow
mkru has quit [Remote host closed the connection]
<sf-slack3>
<mkurc> @hackerfoo: I did the un-split because in the end we will need to use both IOBs and they have to be in the same tile. Unless we want to merge IOB+IOI and then split the resulting tile horizontally...
<sf-slack3>
<mkurc> setting SELECT_Y fixes the build because when on there is only one site of each kind
freemint has quit [Ping timeout: 245 seconds]
kraiskil has quit [Read error: Connection reset by peer]
emily has quit [Excess Flood]
emily has joined #symbiflow
adjtm has joined #symbiflow
craigo has quit [Ping timeout: 240 seconds]
hzeller[m] has quit [Remote host closed the connection]
nrossi has quit [Remote host closed the connection]
mrhat2010[m] has quit [Read error: Connection reset by peer]
zeigren has quit [Read error: Connection reset by peer]
xobs has quit [Read error: Connection reset by peer]
alexhw[m] has quit [Remote host closed the connection]
freemint has joined #symbiflow
<litghost>
mkurc: I don't believe for differential IO we want 1 cluster
<litghost>
mkurc: I believe we want two clusters that share a relationship, either via place macro (e.g. direct inter-tile connection) or via placement io constraints
xobs has joined #symbiflow
Bertl_zZ is now known as Bertl
<hackerfoo>
mkurc: My intention was to use SELECT_Y to make IOPAD_Y0 and IOPAD_Y1, and then we can make those tiles equivalent.
<hackerfoo>
But for now to just work on one of them.
nrossi has joined #symbiflow
alexhw[m] has joined #symbiflow
zeigren has joined #symbiflow
hzeller[m] has joined #symbiflow
mrhat2010[m] has joined #symbiflow
<hackerfoo>
litghost: Do you know where I should look to get Yosys to infer IBUF/OBUFs?