Thursday, 2019-03-14

*** tpb has joined #symbiflow00:00
duck2hello, i have been trying to make a roi harness for cmod a700:30
duck2it has the exact same device xc7a35tcpg236-1 with a basys 3, so i guess i should be able to copy the XRAY_ROI_LARGE and XRAY_ROI_HCLK parts from basys3.sh00:32
duck2trouble is that all .sh files have 7 pins defined and allocated to switches on the board, but the cmod a7 doesn't have 7 switches, it only has two buttons00:35
duck2i think it will be fine to map to io pins instead?00:38
mithrolitghost: Take a look at this doc and see if anything it might be useful ->
tpbTitle: Google Docs - create and edit documents online, for free. (at
mithrolitghost: There is pyverilog - but I think that goes in the other direction00:55
tpbTitle: pyverilog · PyPI (at
litghostduck2: switches == buttons00:55
tpbTitle: GitHub - PyHDI/veriloggen: Veriloggen: A library for constructing a Verilog HDL source code in Python (at
mithro"A library for constructing a Verilog HDL source code in Python"00:56
litghostduck2: So XRAY_DIN_N_LARGE would be set to 2 (e.g. two buttons)00:56
litghostduck2: etc00:56
mithrolitghost: It might also be worth talking to whitequark about their approach with nmigen -- it uses Yosys to generate the Verilog00:57
litghostmithro: And we feed Yosys a JSON?00:57
mithrolitghost: It's unclear to me the nmigen->Yosys interface....00:58
litghostmithro: And we feed Yosys a JSON?00:58
litghostIgnore that00:58
mithrolitghost: If you just want to use a template approach, then please choose jinja2 as the templating engine01:00
mithrolitghost: We already have for generating the Xilinx compat headers.01:00
tpbTitle: symbiflow-arch-defs/ at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrolitghost: -- is the 'INOUT' new?01:02
tpbTitle: make on checkout fails due to missing zybo harness · Issue #448 · SymbiFlow/symbiflow-arch-defs · GitHub (at
duck2litghost: i was referring to `# For generating DB export XRAY_PIN_00=...` etc.01:04
mithrolitghost: whitequark can be found on #yosys and #m-labs and ##openfpga01:05
litghostmithro: INOUT is not supported generally speaking, where did it come from?01:06
litghostduck2: I think the PIN_xx are not used01:06
mithrolitghost: Seems to be in the zynq db01:06
mithrolitghost: Looks like it's in the PS7 site ->
tpbTitle: prjxray-db/site_type_PS7.json at b9c0324464e4b00f122ea2dc23b24ee2bad50fa7 · SymbiFlow/prjxray-db · GitHub (at
litghostmithro: Ya, that's not supported right now01:10
duck2thx^^ i think i have a harness of two leds and two buttons built now. the design.bit lights up both leds when loaded into the device.01:38
duck2where do you suggest to go from here? run fuzzers? try out a yosys->vtr->... flow?01:59
*** citypw has joined #symbiflow04:18
*** Bertl is now known as Bertl_zZ04:42
*** sxpert has quit IRC04:47
*** sxpert has joined #symbiflow04:47
*** nonlinear has quit IRC05:17
*** nonlinear has joined #symbiflow05:18
litghostduck2: Make a version of buttons for your project and make sure it works (e.g. switch -> LED)05:38
litghostduck2: That helps sanity check the roi.  I would also open the design.dcp file and make sure the harness looks good, in particular that the IO's enter the ROI once, rather than snake back and forth05:40
litghostduck2: If buttons looks good, I would add UART pins to your harness and try the DRAM test or the BRAM test05:40
litghostduck2: The counter test is worth running too05:40
*** citypw has quit IRC06:16
*** OmniMancer has joined #symbiflow06:38
*** GuzTech has joined #symbiflow07:56
xvilkaIs SymbiFlow part of new Chips Alliance by Linux Foundation?07:56
sf-slack1<mgielda> @xvilka no, there are 4 companies there as in the press release08:22
*** i8hantanu has joined #symbiflow09:14
*** i8hantanu has quit IRC11:43
xvilkasf-slack1: I see11:48
duck2oops, i also bumped into #448 while trying to build arch-defs to run tests12:57
*** Bertl_zZ is now known as Bertl14:04
*** citypw has joined #symbiflow14:51
litghostduck2: just build the targets for your harness14:52
*** citypw has quit IRC15:02
*** OmniMancer has quit IRC15:02
*** citypw has joined #symbiflow16:02
*** citypw has quit IRC16:42
*** proteusguy has quit IRC16:43
duck2that breaks in another way, generating pin_assignment.json fails with when i remove the zybo targets from the CMakeLists in xc7/17:20
duck2but i think i might have broken something while messing with 448 so i'm trying again on a clean clone17:21
litghostduck2: You shouldn't need to anything to avoid 448, just build the target specific to your board17:24
duck2so i don't need to run toplevel `make` to run the tests?17:26
litghostduck2: No, and I don't recommend that either17:26
litghostduck2: The all target will build for ice40, zybo, etc, etc.  Just build the target you want17:27
duck2i see, thought toplevel make was necessary to get yosys, vtr and other tools17:37
mithroThis change reduces the size of PicoRV32 in it's default configuration by 6% on iCE40: 1915 LUTs vs 1802 LUTs. (Feel free to track down where that difference comes from. I'm not spoiling it here. But I'll say this much: It's a really stupid QoR / miscompilation bug.)17:39
litghostmithro: ?17:40
tpbTitle: Improve handling of "full_case" attributes by cliffordwolf · Pull Request #872 · YosysHQ/yosys · GitHub (at
litghostmithro: Cool, we'll want to merge that once it is merged upstream17:47
*** proteusguy has joined #symbiflow18:28
*** proteusguy has quit IRC19:48
elmslitghost: There is nothing that precludes mapping a fasm feature to bits in different tiles. Do you have any thoughts on how to handle it? I'm inclined to expand the current DB structure to have an optional x_y for the the tile of a bit eg `6_3 !7_4 [email protected]_2` meaning 2nd bit of 2nd word for tile 5_2.20:40
litghostelms: That would never happen in a 7-series part.  Under what circumstance would it occur otherwise?20:54
elmsI fixed the IO for 8k ice40 and missed that 1k parts actually do have some input enables that the bits are in a different tile.
tpbTitle: Project IceStorm IO Tile Documentation (at
elmslitghost: ieren bits for tile 7 0 are in 6 0 and vis-versa20:56
litghostelms: ieren?   Anyways, I think it is a mistake to add that level of complexity to the database.  Rather than handle it in the database, that kind of logic belongs in the post-PnR tool20:57
elmsinput enable and pullup resistor enable20:57
elmsso a special case in the fasm2asc tool?20:58
elmslitghost: for now I think I'll just skip those features instead of the current assert. The IO will need to be revisited and should have more put in the synthesis step as we discussed.21:00
litghostelms: Sounds good21:00
elmsnevermind, looks like blink uses one of those IOs21:02
litghostelms: Can you explain in more details what is happening?  Is it a non-uniform feature set across IOs?21:06
litghostelms: If it's uniform, why not emit both features at the IO site?21:06
elmsIt's not uniform and the current feature is emitted based on a fasm_mux, which I think can only emit a single feature.21:09
litghostelms: Ya that sounds like something that should be handled in a patch up step, but maybe I'm missing something.21:11
elmslitghost: the fasm DB isn't really a spec at the moment. If we do intend to formalize it, I think it should support this. right now the tile coordinates are embedded in the feature name.21:11
litghostelms: But fasm DB currently has a stitch 1 <-> 1 relationship with tiles and no recurance checking is being enforced for 7-series bits.21:12
litghostelms: Enabling features that cross tile boundries seems like an extremely terrible idea, especially if it leads to aliasing21:12
elmsnot sure why it's a bad idea. Seems like a complication vs. generality trade-off21:14
litghostelms: I've never been sold on the value of having a unified database format, and it getting from here to there means making a fully generally bit database format, that complexity seems to dramatically outweigh the savings.21:16
elmslitghost: ok so I may fork from the format for ice40. It is only used internally.21:18

Generated by 2.13.1 by Marius Gedminas - find it at!