| *** tpb has joined #symbiflow | 00:00 | |
| *** freemint has joined #symbiflow | 00:10 | |
| *** freemint has quit IRC | 00:10 | |
| *** bjorkintosh has joined #symbiflow | 00:36 | |
| *** _whitelogger has quit IRC | 02:00 | |
| *** _whitelogger has joined #symbiflow | 02:02 | |
| *** bjorkintosh has quit IRC | 02:17 | |
| *** bjorkintosh has joined #symbiflow | 02:22 | |
| *** proteusguy has quit IRC | 02:34 | |
| hackerfoo | I got the site->site interconnect working in IOPAD. I'm trying to get IBUF/OBUF techmapped, but got stuck on a "Can not find any logic block that can implement molecule" error: https://github.com/SymbiFlow/symbiflow-arch-defs/commit/b3e82269317da9fe8c2c9f547e3d074ee7cdfddf | 03:14 |
|---|---|---|
| tpb | Title: WIP techmap IBUF/OBUF primitives · SymbiFlow/symbiflow-arch-defs@b3e8226 · GitHub (at github.com) | 03:14 |
| hackerfoo | Any idea what I'm doing wrong? | 03:15 |
| *** craigo has joined #symbiflow | 03:34 | |
| *** mkru has joined #symbiflow | 04:28 | |
| *** Bertl_oO is now known as Bertl_zZ | 06:07 | |
| *** craigo has quit IRC | 06:52 | |
| *** craigo has joined #symbiflow | 06:52 | |
| *** craigo has quit IRC | 07:12 | |
| *** craigo has joined #symbiflow | 07:12 | |
| *** craigo has quit IRC | 07:14 | |
| *** craigo has joined #symbiflow | 07:14 | |
| *** craigo has quit IRC | 07:20 | |
| *** craigo has joined #symbiflow | 07:22 | |
| *** proteusguy has joined #symbiflow | 08:24 | |
| sf-slack3 | <mkurc> @hackerfoo Well, it works for me. I started with a clean build directory. | 08:46 |
| *** craigo has quit IRC | 09:13 | |
| *** craigo has joined #symbiflow | 09:14 | |
| *** craigo has quit IRC | 09:23 | |
| *** craigo has joined #symbiflow | 09:24 | |
| *** Bertl_zZ is now known as Bertl | 11:14 | |
| 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 | 13:28 |
| 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. | 13:29 |
| 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. | 13:30 |
| *** Vonter has quit IRC | 13:43 | |
| *** Vonter has joined #symbiflow | 13:49 | |
| 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. | 13:59 |
| *** adjtm has quit IRC | 14:56 | |
| *** adjtm has joined #symbiflow | 15:23 | |
| sf-slack3 | <mkurc> @hackerfoo: I've pushed my changes. The import works except for the inner_pins which is broken now (interconnect generation) | 15:47 |
| 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. | 17:28 |
| *** Bertl is now known as Bertl_zZ | 17:28 | |
| *** citypw has quit IRC | 17:36 | |
| *** freemint has joined #symbiflow | 17:56 | |
| *** filt3r has quit IRC | 18:04 | |
| litghost | acomodi: I would definitely run bit2verilog on your results and see what is going on | 18:07 |
| litghost | hackerfoo: Did you resolve you packing issue? | 18:07 |
| hackerfoo | litghost: No | 18:07 |
| hackerfoo | mkurc: Adding back "SELECT_Y 1" fixes the build. | 18:09 |
| litghost | hackerfoo: Which packing step is failing? wire.eblif? | 18:09 |
| hackerfoo | Yes. | 18:10 |
| 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 | 18:11 |
| litghost | hackerfoo: Does that make sense? | 18:11 |
| *** filt3r has joined #symbiflow | 18:12 | |
| hackerfoo | I changed wire.eblif, though (commented out right now): https://github.com/SymbiFlow/symbiflow-arch-defs/commit/b3e82269317da9fe8c2c9f547e3d074ee7cdfddf | 18:12 |
| tpb | Title: WIP techmap IBUF/OBUF primitives · SymbiFlow/symbiflow-arch-defs@b3e8226 · GitHub (at github.com) | 18:12 |
| litghost | so the out pad of the IOPAD is IOI3 routing interface <OLOGIC mode passthrough/ODDR/OSERDES> <OBUF mode passthrough/OBUFT>, etc | 18:13 |
| litghost | hackerfoo: Changing wire.eblif will break non-7-series (e.g. testarch and ice40), so that is not a great long term solution | 18:13 |
| hackerfoo | So I should add a mode without IBUF/OBUF? | 18:14 |
| hackerfoo | That should work. | 18:14 |
| litghost | hackerfoo: It might not hurt, and but it will need to emit FASM as if there was an IBUF/OBUF | 18:15 |
| hackerfoo | I have the interconnect working between {I,O}LOGIC and IOB33M now. | 18:15 |
| hackerfoo | Yeah | 18:15 |
| litghost | hackerfoo: E.g. the prjxray_tile_import is making the connections? | 18:15 |
| hackerfoo | Yes | 18:16 |
| hackerfoo | Just using a predefined map for now. | 18:16 |
| hackerfoo | https://github.com/SymbiFlow/symbiflow-arch-defs/commit/ad4560c04b5ce1f96c632f2575af5d726b7882df | 18:17 |
| tpb | Title: add IOPAD site->site interconnect to prjxray_tile_import.py · SymbiFlow/symbiflow-arch-defs@ad4560c · GitHub (at github.com) | 18:17 |
| hackerfoo | I plan to add a script to generate the map at some later point. | 18:18 |
| hackerfoo | From tileconn.json + channels.db | 18:18 |
| litghost | hackerfoo: There shouldn't be a need to use tileconn.json at all | 18:20 |
| litghost | hackerfoo: The nodes are present in channels.db | 18:20 |
| hackerfoo | It is, but it's elaborated *too* much, there are nodes for every IOI<->IOB tile edge. I only need one. | 18:21 |
| hackerfoo | I could still write a query, even if it's slow. Or maybe pick an arbitrary pair of tiles. | 18:22 |
| 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. | 18:24 |
| hackerfoo | Not now, though. | 18:24 |
| hackerfoo | *tile type pair | 18:24 |
| litghost | > there are nodes for every IOI<->IOB tile edge. I only need one. | 18:24 |
| 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? | 18:24 |
| hackerfoo | Don't IOBs and IOIs always connect the same way, at least on the same side of the chip? | 18:26 |
| litghost | hackerfoo: The whole exercise is to not assume a structure, but infer the right thing from the underlying data | 18:26 |
| litghost | hackerfoo: Consider that there may be variation across other chips | 18:27 |
| hackerfoo | The same structure is in the DB, in tileconn.json | 18:27 |
| litghost | hackerfoo: There is also some form of variation within the chip, with the TTERMBYTE, etc | 18:27 |
| hackerfoo | Yeah, but that's a different tile-type pair. | 18:27 |
| 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 | 18:28 |
| litghost | ever* | 18:28 |
| hackerfoo | Sure, but you can then join the nodes if there's a passthough wire. It would just speed things up, maybe. | 18:29 |
| hackerfoo | At least, nodes-per-tile-type pair would have been exactly what I need for this task. | 18:30 |
| hackerfoo | I can just pick a tile pair, though. That should work, since they will all be the same., | 18:31 |
| *** freemint has quit IRC | 18:35 | |
| *** freemint has joined #symbiflow | 18:35 | |
| *** adjtm has quit IRC | 18:51 | |
| *** kraiskil has joined #symbiflow | 18:56 | |
| *** mkru has quit IRC | 19:21 | |
| 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... | 19:33 |
| sf-slack3 | <mkurc> setting SELECT_Y fixes the build because when on there is only one site of each kind | 19:34 |
| *** freemint has quit IRC | 19:36 | |
| *** kraiskil has quit IRC | 19:43 | |
| *** emily has quit IRC | 20:02 | |
| *** emily has joined #symbiflow | 20:03 | |
| *** adjtm has joined #symbiflow | 20:37 | |
| *** craigo has quit IRC | 20:38 | |
| *** hzeller[m] has quit IRC | 20:42 | |
| *** nrossi has quit IRC | 20:42 | |
| *** mrhat2010[m] has quit IRC | 20:42 | |
| *** zeigren has quit IRC | 20:42 | |
| *** xobs has quit IRC | 20:42 | |
| *** alexhw[m] has quit IRC | 20:42 | |
| *** freemint has joined #symbiflow | 20:42 | |
| litghost | mkurc: I don't believe for differential IO we want 1 cluster | 20:43 |
| 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 | 20:43 |
| *** xobs has joined #symbiflow | 20:52 | |
| *** Bertl_zZ is now known as Bertl | 21:15 | |
| hackerfoo | mkurc: My intention was to use SELECT_Y to make IOPAD_Y0 and IOPAD_Y1, and then we can make those tiles equivalent. | 21:18 |
| hackerfoo | But for now to just work on one of them. | 21:19 |
| *** nrossi has joined #symbiflow | 21:28 | |
| *** alexhw[m] has joined #symbiflow | 21:28 | |
| *** zeigren has joined #symbiflow | 21:28 | |
| *** hzeller[m] has joined #symbiflow | 21:28 | |
| *** mrhat2010[m] has joined #symbiflow | 21:28 | |
| hackerfoo | litghost: Do you know where I should look to get Yosys to infer IBUF/OBUFs? | 23:17 |
| litghost | hackerfoo: http://www.clifford.at/yosys/files/yosys_manual.pdf write_blif "-buf <cell-type> <in-port> <out-port>" is the way I know off the top of my head | 23:18 |
| litghost | hackerfoo: It is unclear how to tell yosys "use this if not that" | 23:19 |
| litghost | hackerfoo: I think the way to do it may be "emit IBUF/OBUF always, and then merge doubled buffers" | 23:19 |
| litghost | hackerfoo: But that is a good question for #yosys | 23:19 |
| litghost | hackerfoo: I'm no expert on this particular aspect | 23:19 |
| hackerfoo | litghost: Thanks | 23:19 |
| hackerfoo | litghost: Do you know what this means? | 23:22 |
| hackerfoo | Net '$true' is impossible to route within proposed BLK-TL-IOPAD cluster | 23:22 |
| hackerfoo | Or rather, how to fix it. | 23:22 |
| hackerfoo | Oh, I have to route those through the IOLOGIC sites, I think. | 23:23 |
| hackerfoo | I'm just removing them for now. | 23:25 |
| litghost | That error was likely complaining that there was no route to the cluster sink to the top level cluster pin | 23:26 |
| litghost | But without more details, hard to say | 23:26 |
| hackerfoo | I think I fixed that, now I'm at this error: Message: IO block inbuf location was not specified in the pad file. | 23:29 |
| litghost | hackerfoo: Not totally certain, but I believe this is something I was warning you about earlier | 23:30 |
| * hackerfoo sent a long message: < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/xMlBDXOTwyQkJClRQkEYwgzt > | 23:30 | |
| litghost | hackerfoo: The placement IO file specifies cluster names, not net names | 23:30 |
| litghost | hackerfoo: If there is now more than one net per IO cluster, than the net name may not be equal to the net | 23:30 |
| litghost | hackerfoo: Check the ".net" file and see what the cluster names are now | 23:31 |
| hackerfoo | Are clusters <block>'s in the .net file? | 23:43 |
| litghost | hackerfoo: Let me check | 23:44 |
| hackerfoo | I tried changing the IBUF name to "in", but got: ERROR: Re-definition of cell `\in' | 23:46 |
| litghost | that's a new one | 23:47 |
| litghost | ya, block name is what you are looking for: https://docs.verilogtorouting.org/en/latest/vpr/file_formats/#packed-netlist-format-net | 23:48 |
| hackerfoo | And I can't change in -> inbuf in the .pcf, so how do I change the block name? | 23:48 |
| litghost | hackerfoo: I think you need to consume the .net and .pcf and generate the ioplace | 23:49 |
| litghost | hackerfoo: e.g. find .pcf constraint in .net, output ioplace for that toplevel cluster | 23:49 |
| hackerfoo | Is that prjxray_create_ioplace.py? | 23:50 |
| litghost | hackerfoo: Yes | 23:50 |
| litghost | hackerfoo: Currently it doesn't consume the .net file, but that was because it didn't need too | 23:50 |
| litghost | hackerfoo: Another alturnative is to modify VPR to do the mapping for us | 23:51 |
| litghost | hackerfoo: VPR really oaught to be able to constrain toplevel ports at placement locations, rather than by cluster name | 23:51 |
| litghost | hackerfoo: But I think it will be faster to parse the .net potentially than updating VPR | 23:52 |
| hackerfoo | Yeah. I'm just trying to hack it together for now. | 23:52 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!