Wednesday, 2021-03-03

« Tuesday, 2021-03-02 Index Thursday, 2021-03-04 »
*** tpb has joined #symbiflow00:00
*** Tokamak has joined #symbiflow00:17
*** citypw has joined #symbiflow01:37
*** perillamint has quit IRC02:29
*** perillamint has joined #symbiflow02:33
*** Degi_ has joined #symbiflow03:15
*** Degi has quit IRC03:17
*** Degi_ is now known as Degi03:17
*** QDX45 has joined #symbiflow03:57
*** rvalles_ has joined #symbiflow04:00
*** rvalles has quit IRC04:00
*** TMM has quit IRC05:11
*** TMM has joined #symbiflow05:11
*** _whitelogger has quit IRC05:36
*** _whitelogger has joined #symbiflow05:38
*** Tokamak has quit IRC06:24
*** Tokamak has joined #symbiflow06:44
*** kraiskil has joined #symbiflow07:21
*** QDX45 has quit IRC07:23
*** smkz has quit IRC07:24
*** smkz has joined #symbiflow07:24
*** kraiskil has quit IRC08:06
*** craigo has quit IRC08:46
*** Tokamak has quit IRC09:02
*** citypw has quit IRC09:07
*** citypw has joined #symbiflow11:38
*** citypw has quit IRC11:51
*** citypw has joined #symbiflow11:56
*** kgugala has quit IRC12:28
*** gromero has joined #symbiflow13:14
*** gromero_ has quit IRC13:15
lambdaI must be doing something wrong, because while my microcontroller works almost perfectly, a test design that simply loops the arty's switch inputs back to the LEDs is completely broken13:33
sf-slack4<kgugala> do you have the desing published anywhere?13:44
sf-slack4<kgugala> with makefiles (and possibly with build output)13:45
*** citypw has quit IRC13:45
lambdait's not much of a design, here's the .il: https://misc.xiretza.xyz/repro/test.il13:46
lambdawith just the \switches and \leds wires, it works, but the added \other wire causes 3 of the LEDs to be constantly powered13:46
lambdamaybe it's just my FPGA, here's the bitstream in case anyone with an arty a7-35t wants to test: https://misc.xiretza.xyz/repro/test.bit13:47
sf-slack4<kgugala> do you have the whole design? I mean verilog/pcf/makefiles13:48
sf-slack4<kgugala> + logs?13:48
lambdaI'll pack it up, hold on13:48
*** tux3 has quit IRC13:57
*** tux3 has joined #symbiflow13:58
*** tux3 has joined #symbiflow13:59
lambdakgugala: https://misc.xiretza.xyz/repro/reproduce.tar.gz14:01
sf-slack4<kgugala> thanks14:01
lambdathis is 95% my fault either because I broke my hardware or because I broke the toolchain installation in new creative ways14:01
*** kgugala has joined #symbiflow14:37
*** tux3 has quit IRC14:47
*** tux3 has joined #symbiflow14:47
*** tux3 has quit IRC14:50
*** tux3 has joined #symbiflow14:50
*** tux3 has quit IRC15:02
*** kraiskil has joined #symbiflow15:07
*** tux3 has joined #symbiflow15:07
*** tux3 has quit IRC15:08
*** tux3 has joined #symbiflow15:09
*** tux3 has joined #symbiflow15:09
*** kraiskil has quit IRC15:20
*** acomodi has joined #symbiflow16:01
*** kraiskil has joined #symbiflow16:05
*** kraiskil has quit IRC16:10
*** kraiskil has joined #symbiflow16:23
*** kraiskil has quit IRC16:37
litghostLofty: What's up16:43
LoftyI got a reply from Alan Mishchenko; "look but don't touch" is actually a situation that ABC9 supports16:44
litghostAh, very good16:44
LoftySo I suspect it might be a case of waiting for Eddie to get back to ABC9 development to plumb in support on the Yosys side16:45
litghostOk16:45
LoftyThe email from Alan was, uh, concise16:45
LoftySo I have no idea how to do it myself16:45
litghostheh16:46
*** Degi has quit IRC16:50
*** Degi has joined #symbiflow16:51
litghostI think plumbing this feature from ABC9 up to yosys seems like a good feature to add in the general case, and once that feature is available, we can update the CARRY4_VPR annotation with the right attribute16:53
sf-slack4<kgugala> @lambda I see you're feeding yosys directly with rtlil - TBH I never tested the flow with this16:56
sf-slack4<kgugala> not sure if xdc plugin works with that one16:56
sf-slack4<kgugala> you can try providing sdc directly to VPR16:56
litghostXDC pluging should work as expect, because it operates directly on the RTLIL representation16:57
litghostIf it doesn't work, we should probably add a test and fix it, because there should be no differences to the plugin if different frontends are used16:57
sf-slack4<kgugala> mhm16:58
sf-slack4<kgugala> it seems it does work - I see LOCs in eblif16:59
*** kgugala has quit IRC17:01
*** epony has quit IRC17:01
*** microcolonel has quit IRC17:01
*** m_hackerfoo has quit IRC17:01
*** HackerFoo has quit IRC17:01
*** yeti has quit IRC17:01
*** Tokamak has joined #symbiflow17:03
*** kgugala has joined #symbiflow17:06
*** microcolonel has joined #symbiflow17:06
*** m_hackerfoo has joined #symbiflow17:06
*** HackerFoo has joined #symbiflow17:06
*** yeti has joined #symbiflow17:06
-_whitenotifier-5- [symbiflow-arch-defs] litghost opened issue #2068: Once yosys supports "look, don't touch" add annotation to CARRY4_VPR - https://git.io/JqvYI17:09
*** craigo has joined #symbiflow17:17
*** donjr2d has joined #symbiflow17:24
*** donjr2d has left #symbiflow17:34
*** TMM has quit IRC17:34
*** TMM has joined #symbiflow17:34
lambdakgugala: the sources for my actual bigger design contain vhdl, which I can't just feed to symbiflow_synth, so I bundle them all together in a separate yosys run, export the ilang and pass that to synth18:27
lambdathough I agree it'd be very surprising if yosys cared about the input file format18:28
lambdakgugala: do you have an arty to confirm that (1) the bitstream you built works and (2) my bitstream doesn't? alternatively, could you send me your bitstream so I can try to test (1)?18:45
litghostlambda: Couple things18:47
litghostlambda: Did you check the timing analysis from VPR?18:47
sf-slack4<kgugala> @litghost this is a simple design connecting inputs to outputs18:48
lambdayeah, there aren't even any clocks18:48
sf-slack4<kgugala> I don't think timings are any problem here18:48
litghostAh, ya that should work fine18:48
litghostAs a sanity check, take a look at the blif and make sure you I/OBUFs are on the right sites18:48
litghostEither way, given that this is just a wire design, use xc fasm2bels to run bitstream back into Vivado (or just the verilog) and make sure things look right18:49
litghostGiven that it is a wire design, just looking at the fasm2bels output verilog should be enough to debug if something is grossly wrong18:49
lambdawill do18:51
litghostThe recommended path here is to use the bitstream to generate the FASM and then run that FASM back into verilog and/or FPGA interchange18:52
litghostBoth outputs from fasm2bels can be feed into Vivado for simulation and/or timing analysis as needed18:52
litghostThe FPGA interchange outputs are generally faster, but the verilog outputs are easier to hand verify18:53
lambdawhat can I use for bit->fasm conversion?18:57
sf-slack4<kgugala> fasm2bels can eat bit file18:59
litghostRight18:59
sf-slack4<kgugala> you just need to point it to bitread binary18:59
sf-slack4<kgugala> bitread is a part of prjxray18:59
sf-slack4<kgugala> @litghost @lambda there is sth wrong with the bistream19:25
sf-slack4<kgugala> I ran it throgh fasm2bels19:25
sf-slack4<kgugala> and only switches[0] landed where it should19:25
*** kraiskil has joined #symbiflow19:26
sf-slack4<kgugala> switches[1] is constrained to C11 which should place it in LIOB33_X0Y123, but it landed in  LIOB33_X0Y2519:27
sf-slack4<kgugala> sorry, it landed in LIOB33_X0Y75 (still incorrect)19:28
lambdaconstraints.place contains this line for it: `switches[1]   2  28  0  # set_property LOC C11 [get_ports {switches[1]}]`19:29
*** craigo has quit IRC19:29
litghostkgugala/lambda: If I were to guess, this is a package mismatch?19:31
lambdavery possible19:31
litghostkgugala/lambda: If the wrong package data is used, then the package pin -> site map will be wrong19:31
sf-slack4<kgugala> yep, that is my first guess19:33
sf-slack4<kgugala> @lambda, can you check if the package is correct?19:33
lambdachip is XC7A35T/CSG324, which I assume corresponds to PART=xc7a35tcsg324-119:37
*** craigo has joined #symbiflow19:37
litghostYes19:38
litghostlambda: The PAD -> loc conversion happens here: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/098fe2e8e724bca3902b8121fb254caaed7cb5d3/xc/xc7/toolchain_wrappers/symbiflow_generate_constraints#L2719:43
litghostWhich is typically invoked from symbiflow_place19:43
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/098fe2e8e724bca3902b8121fb254caaed7cb5d3/xc/common/utils/prjxray_create_ioplace.py#L75-L8919:44
cr1901_modernDoes the testarch come w/ any tests I can run (for just playing around)?19:46
litghostIn arch-defs?19:47
cr1901_modernYes19:47
litghostYa, it just runs some really simple P&R tasks19:47
litghostThe GH actions CI runs them19:47
litghostOne second19:47
cr1901_modernI'd like some targets for ninja19:47
cr1901_moderndefine_arch is a little less overwhelming for the testarch19:47
litghost6-rot_dummy_testarch_4x4_dummy_route I think would work?19:49
litghostninja has bash completion, so try "ninja 6-rot_dummy_testarch_4x4_dummy<TAB>"19:49
cr1901_modernInteresting... it doesn't on my machine19:50
cr1901_modernAhhh that's because I built it from source and never added the file19:50
cr1901_modernto my .bashrc19:50
litghostYa "6-rot_dummy_testarch_4x4_dummy_route" will work19:51
cr1901_modernAwesome19:52
cr1901_modern"6-rot_dummy_testarch_4x4_dummy" by itself claims "no work to do", but the "_route" suffix works19:52
cr1901_modernI recently completed a nextpnr backend for machxo2. Moving on to symbiflow... I have a decent chunk of the CMakeLists.txt set up, but I'm still learning19:53
cr1901_modernthings such as "why does yosys need to be invoked w/ special tcl scripts"?19:54
litghostVPR does need a little more hand holding than nextpnr, and some of that lives in the tcl scripts19:54
litghostIt really depends on the complexity of the arch19:55
lambdakgugala: C11 should be IOB_X0Y124, right?20:02
litghostlambda: https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/xc7a35tcsg324-1/package_pins.csv20:04
litghostFYI20:04
sf-slack4<kgugala> yep and C11 is here https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/xc7a35tcsg324-1/package_pins.csv#L3920:04
lambdaalright, that seems to match up with my arch-defs pinmap.csv, as long as x=2,y=28 is also correct (can't find those kind of coordinates anywhere else)20:06
litghostThe pinmap.csv is per part, and is a translation of the prjxray-db file20:07
litghostSo should be right, unless something terrible has happened with the build system20:07
lambdaI wonder where it goes wrong then, XDC contains C11, .ioplace contains x=2,y=28 which should be equivalent, but then the bitstream/fasm contains something else20:09
lambdaoh, test.place has x=2,y=79 for some reason20:10
lambdavpr bug I guess, it's just ignoring the constraints and making up its own placement20:38
litghostAre you regenerating the place file after you create the placement?20:39
litghost*packing20:39
litghostQuestion, are you using the wrapper scripts?20:40
lambdaI am20:40
lambdasee the makefile here: https://misc.xiretza.xyz/repro/reproduce.tar.gz20:40
litghostSo you are just doing symbiflow_pack then symbiflow_place?20:40
lambdayes20:40
litghostIn that file, I don't see the pack or place result?20:43
litghostWhich VPR are you using?20:45
litghostconda or local build?20:46
lambdaah damn, they got eaten by make, sec20:46
lambdalocal build20:46
lambda8.1.0-dev+4acad0fb5-dirty20:46
litghostIf you use the VPR from conda, does it work as expected?20:46
lambdaI haven't been able to get conda to work20:47
cr1901_modernlitghost: Thanks for the info. Follow-up... why is BLIF required, and backends that emit BLIF for VPR require special options. Do you understand what they are for?20:48
* cr1901_modern is not all that familiar w/ BLIF as opposed to the JSON output format20:48
litghostVPR uses BLIF as it's input format, that's all20:48
cr1901_modernAnd unless certain options are passed, VPR will choke on yosys' output BLIF?20:49
litghosteblif adds some quality of life features, specifically around parameters on sub-circuits20:49
litghostI believe we use yosys's BLIF output20:49
cr1901_modernYou do, but...20:49
* cr1901_modern grabs a link brb20:49
cr1901_modernhttps://github.com/YosysHQ/yosys/blob/master/techlibs/machxo2/synth_machxo2.cc#L220-L225 I added this snippet based on other backends20:50
cr1901_modernbut I don't actually know what I'm doing lmao20:50
litghostSo couple things20:51
litghostVPR requires that constants be attached to a source, unless the graph only has LUTs as constant sources20:51
litghostThe "cname" thing is just for QoL20:52
litghostIf you don't use cname, VPR will invent it's own name for subcircuits, which complicates debugging20:52
litghostattr attributes are just for information20:53
litghostparam attributes are useful if you plan to use the VPR's genfasm to directly emit FASM20:53
*** kraiskil has quit IRC20:53
cr1901_modern>VPR requires that constants be attached to a source, is this what -conn does?20:54
litghostI actually don't remember what "-conn" does20:54
litghostThe VCC/GND stuff here is what I'm talking about20:54
cr1901_modernWhich part of what I highlighted handles that?20:54
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/098fe2e8e724bca3902b8121fb254caaed7cb5d3/xc/xc7/yosys/conv.tcl#L15-L1720:54
cr1901_modernPresumably the "opt -purge" is just to make VPR's job easier20:55
litghostI have little experience with "opt -purge""20:55
litghostThe xc7 TCL scripts are here https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/yosys/synth.tcl and here https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/yosys/conv.tcl#L15-L1720:56
cr1901_modernI'm pretty sure I copied it from the ECP5 backend20:56
litghostI don't I've seen an attempt at doing ECP5 on VPR20:56
litghostBut that doesn't mean it wasn't tried20:56
cr1901_modernYea, I copied it: https://github.com/YosysHQ/yosys/blob/master/techlibs/ecp5/synth_ecp5.cc#L390-L40520:57
cr1901_moderncc: gatecat Do you remember why BLIF generation is different between VPR and non-VPR mode?20:57
litghostI don't think ECP5 is the arch to use as an example here20:57
litghostxc7 would be the example to look at20:57
* cr1901_modern unfortunately knows little about series-7, but noted20:58
gatecatI last looked at this 3 years ago but I think the difference was originally for ice4020:58
gatecatarachne needed SB_LUT4 cells20:58
gatecatVPR needed BLIF .names20:58
gatecatThere might be differences around some of the eBLIF extensions too20:58
litghostThe ice40 VPR backend in arch defs is fairly close to the xc7 invocation https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/ice40/yosys/conv.tcl and https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/ice40/yosys/synth.tcl21:00
litghostBut it is worth noting that the ice40 VPR backend hasn't been actively developed in a long while21:00
litghostWe run the tests to make sure it hasn't exploded, but I don't believe it has been tested on hardware in months/years21:00
cr1901_modernHmm, I might get rid of the distinction between vpr and not-vpr mode at some point21:01
litghostYa, it's not clear at this point why it's there21:01
cr1901_modernI legitimately did it because the ECP5 backend did it21:02
cr1901_modernAnyways, all those options are non-standard according to yosys help21:03
cr1901_modernanyways, for the record, "-conn" means "do not generate buffers for connected wires. instead use the non-standard .conn statement."21:04
cr1901_modernIdk enough about BLIF yet to understand what that means; the tcl scripts in symbiflow don't use it21:04
litghostWe don't use that for the xc7 VPR flow21:04
litghostInstead we ask VPR to absorb LUT buffers21:04
litghostWe have had bugs around absorbing of LUT buffers in the past, so I could see that being a thing years ago21:05
litghostBut we rely on it in the current flows21:05
cr1901_modernabsorb? You mean "turn a 01010101010101... etc LUT into a straight-through connection"?21:05
litghostNo21:05
litghostWhenver a net is renamed (e.g. cross a module boundry) it gets a simple 1 input LUT declaration21:06
litghostOne second I'll find an example21:06
gatecatI think VPR mode only makes sense for iCE40 where there are hypothetically two blif consuming flows - arachne and vpr - even if neither flow is actively used21:06
gatecatFor everything else blif essentially implies vpr21:07
lambdalitghost: here's all the files btw https://misc.xiretza.xyz/repro/reproduce2.tar.gz21:07
litghost.names ser_rx scalable_proc.uart.ser_rx21:07
litghost1 121:07
litghost.names ser_tx scalable_proc.uart.ser_tx21:07
litghost1 121:07
litghostIf you don't have LUT absortion on, VPR will actually try to place those LUTs and consume resources21:08
lambdatest.ioplace has the correct x/y, as does constraints.place, but test.place is wrong21:08
litghostlambda: For testing, just manually fix test.place and run the rest of the flow21:08
litghostlambda: I suspect it will resolve the issue for now21:09
litghostlambda: The question is why did VPR not respect the constraint21:09
litghostThere has been upstream working around partitioning and there might be a regression21:09
cr1901_modernlitghost: Cool, thanks for the example. I'll play w/ BLIF a bit in one of my toy design21:10
cr1901_moderns*21:10
litghostlambda: Ya, switches[3:1] are messed up21:10
litghostlambda: I believe you have a reproducable test case21:10
litghostFile a bug on upstream VPR and @sfkhalid, they were in that code recently21:11
lambdawill do, thanks for all the help21:12
litghostWould you be willing to compile at b0223dc59?21:12
lambdasure21:12
litghostThat is what symbiflow examples is currently at21:12
litghostAnd I believe the bug won't be there21:12
litghostBut who knows21:12
cr1901_modernconv.tcl runs straight after synth.tcl?21:23
cr1901_modern(Looking at conv.tcl, it looks like a fragment of a larger script)21:24
cr1901_modernfor both the xc7 and ice40 backends21:24
*** phire has quit IRC21:25
*** phire has joined #symbiflow21:26
litghostSo between synth.tcl and conv.tcl is an IO splitter script to handle differential IO21:26
litghostIf you are only doing single ended IO, this doesn't matter21:27
litghostOne minute21:27
cr1901_modernDifferential I/O is not currently supported by the yosys backend for machxo221:27
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/098fe2e8e724bca3902b8121fb254caaed7cb5d3/xc/xc7/toolchain_wrappers/symbiflow_synth#L108-L11021:28
litghostSorry I mispoke21:28
litghostIt's about IO buffers21:28
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/098fe2e8e724bca3902b8121fb254caaed7cb5d3/utils/split_inouts.py#L221:28
cr1901_modernOkay, cool. Does conv stand for "convert" (bikeshed)?21:29
cr1901_modernsynth for "synthesis"21:29
litghostYep21:29
cr1901_modernAhh I see, so the flow is "synthesize normally w/ VPR-specific tailoring to JSON", "operate on the JSON as needed" (the I/O buffers), then "convert the JSON to BLIF".21:30
litghostThat is the current flow21:31
cr1901_modern(Where is utils.tcl imported?)21:31
litghostNot idea, but it does work21:31
litghostideal*21:31
cr1901_modernNot ideal is fine. I just need to understand it :P21:31
*** sf-slack4 has quit IRC21:33
*** rejser has quit IRC21:33
*** daf1 has quit IRC21:33
*** sf-slack4 has joined #symbiflow21:34
*** rejser has joined #symbiflow21:34
*** daf1 has joined #symbiflow21:34
cr1901_modernAFAICT, the CMake test targets don't actually use the symbiflow_synth script, but use define_arch() to call the relevant scripts directly?21:38
litghostSo the CMake system pre-exists the scripts21:39
litghostOne of the cleanup steps that is being doing will be to change the scripts to be arch indepedent, and to use them in the CMake invocation21:39
cr1901_modernahhh that's cool21:40
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/098fe2e8e724bca3902b8121fb254caaed7cb5d3/common/cmake/devices.cmake#L1406-L141521:40
*** Tokamak has quit IRC21:40
litghostThe CMake invocation is here21:40
cr1901_modernhttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/098fe2e8e724bca3902b8121fb254caaed7cb5d3/common/cmake/devices.cmake#L1385-L1399 Oh would you look at that, the CMake invocation almost matches the symbiflow_synth script21:41
cr1901_modernwhat a coincidence :o21:41
cr1901_modernlitghost: Thanks for the help. I think that's all the qs I have immediately. Talking to someone was immensely helpful compared to trying to figure it out on my own :P21:44
litghostFrankly there oaugth to be comments around this stuff21:44
litghostWe would happily accept some PR's with any comments/notes around here21:45
cr1901_modernI have my own set of dev notes. I can add to them this weekend using this chat as a guide21:45
cr1901_modernhttp://ix.io/2RAA21:45
cr1901_modernThese notes are mildly out of date, because I started adding primitives, but they're only muxes. So not much to talk about.21:47
litghostright21:48
cr1901_modern"Step 4." would be to add the yosys scripts, "Step 5." implement define_arch. And go from there21:48
*** Tokamak has joined #symbiflow22:07
*** acomodi has quit IRC22:11
*** Raito_Bezarius has joined #symbiflow23:11
*** craigo has quit IRC23:38
« Tuesday, 2021-03-02 Index Thursday, 2021-03-04 »

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!