| *** tpb has joined #symbiflow | 00:00 | |
| duck2 | hello, i have been trying to make a roi harness for cmod a7 | 00:30 |
|---|---|---|
| duck2 | it 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.sh | 00:32 |
| duck2 | trouble 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 buttons | 00:35 |
| duck2 | i think it will be fine to map to io pins instead? | 00:38 |
| mithro | litghost: Take a look at this doc and see if anything it might be useful -> https://docs.google.com/document/d/1PqNvM5xu-Q6YjMaFy33hXRwzvAqaZqHiO8BQ_qIQV-Q/edit | 00:54 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 00:54 |
| mithro | litghost: There is pyverilog - https://pypi.org/project/pyverilog/ but I think that goes in the other direction | 00:55 |
| tpb | Title: pyverilog · PyPI (at pypi.org) | 00:55 |
| litghost | duck2: switches == buttons | 00:55 |
| mithro | https://github.com/PyHDI/veriloggen | 00:55 |
| tpb | Title: GitHub - PyHDI/veriloggen: Veriloggen: A library for constructing a Verilog HDL source code in Python (at github.com) | 00:55 |
| mithro | "A library for constructing a Verilog HDL source code in Python" | 00:56 |
| litghost | duck2: So XRAY_DIN_N_LARGE would be set to 2 (e.g. two buttons) | 00:56 |
| litghost | duck2: etc | 00:56 |
| mithro | litghost: It might also be worth talking to whitequark about their approach with nmigen -- it uses Yosys to generate the Verilog | 00:57 |
| litghost | mithro: And we feed Yosys a JSON? | 00:57 |
| mithro | litghost: It's unclear to me the nmigen->Yosys interface.... | 00:58 |
| litghost | mithro: And we feed Yosys a JSON? | 00:58 |
| litghost | Ignore that | 00:58 |
| mithro | litghost: If you just want to use a template approach, then please choose jinja2 as the templating engine | 01:00 |
| mithro | litghost: We already have https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/libraries/generate_verilog.py for generating the Xilinx compat headers. | 01:00 |
| tpb | Title: symbiflow-arch-defs/generate_verilog.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 01:00 |
| mithro | litghost: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/448 -- is the 'INOUT' new? | 01:02 |
| tpb | Title: make on checkout fails due to missing zybo harness · Issue #448 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 01:02 |
| duck2 | litghost: i was referring to `# For generating DB export XRAY_PIN_00=...` etc. | 01:04 |
| mithro | litghost: whitequark can be found on #yosys and #m-labs and ##openfpga | 01:05 |
| litghost | mithro: INOUT is not supported generally speaking, where did it come from? | 01:06 |
| litghost | duck2: I think the PIN_xx are not used | 01:06 |
| mithro | litghost: Seems to be in the zynq db | 01:06 |
| mithro | litghost: Looks like it's in the PS7 site -> https://github.com/SymbiFlow/prjxray-db/blob/b9c0324464e4b00f122ea2dc23b24ee2bad50fa7/zynq7/site_type_PS7.json#L2-L46 | 01:08 |
| tpb | Title: prjxray-db/site_type_PS7.json at b9c0324464e4b00f122ea2dc23b24ee2bad50fa7 · SymbiFlow/prjxray-db · GitHub (at github.com) | 01:08 |
| litghost | mithro: Ya, that's not supported right now | 01:10 |
| duck2 | thx^^ 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 |
| duck2 | where do you suggest to go from here? run fuzzers? try out a yosys->vtr->... flow? | 01:59 |
| *** citypw has joined #symbiflow | 04:18 | |
| *** Bertl is now known as Bertl_zZ | 04:42 | |
| *** sxpert has quit IRC | 04:47 | |
| *** sxpert has joined #symbiflow | 04:47 | |
| *** nonlinear has quit IRC | 05:17 | |
| *** nonlinear has joined #symbiflow | 05:18 | |
| litghost | duck2: Make a version of buttons for your project and make sure it works (e.g. switch -> LED) | 05:38 |
| litghost | duck2: 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 forth | 05:40 |
| litghost | duck2: If buttons looks good, I would add UART pins to your harness and try the DRAM test or the BRAM test | 05:40 |
| litghost | duck2: The counter test is worth running too | 05:40 |
| *** citypw has quit IRC | 06:16 | |
| *** OmniMancer has joined #symbiflow | 06:38 | |
| *** GuzTech has joined #symbiflow | 07:56 | |
| xvilka | Is 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 release | 08:22 |
| *** i8hantanu has joined #symbiflow | 09:14 | |
| *** i8hantanu has quit IRC | 11:43 | |
| xvilka | sf-slack1: I see | 11:48 |
| xvilka | err | 11:48 |
| xvilka | @mgielda | 11:48 |
| duck2 | oops, i also bumped into #448 while trying to build arch-defs to run tests | 12:57 |
| *** Bertl_zZ is now known as Bertl | 14:04 | |
| *** citypw has joined #symbiflow | 14:51 | |
| litghost | duck2: just build the targets for your harness | 14:52 |
| *** citypw has quit IRC | 15:02 | |
| *** OmniMancer has quit IRC | 15:02 | |
| *** citypw has joined #symbiflow | 16:02 | |
| *** citypw has quit IRC | 16:42 | |
| *** proteusguy has quit IRC | 16:43 | |
| duck2 | that breaks in another way, generating pin_assignment.json fails with https://pastebin.com/raw/ZB63ARMb when i remove the zybo targets from the CMakeLists in xc7/ | 17:20 |
| duck2 | but i think i might have broken something while messing with 448 so i'm trying again on a clean clone | 17:21 |
| litghost | duck2: You shouldn't need to anything to avoid 448, just build the target specific to your board | 17:24 |
| duck2 | so i don't need to run toplevel `make` to run the tests? | 17:26 |
| litghost | duck2: No, and I don't recommend that either | 17:26 |
| litghost | duck2: The all target will build for ice40, zybo, etc, etc. Just build the target you want | 17:27 |
| duck2 | i see, thought toplevel make was necessary to get yosys, vtr and other tools | 17:37 |
| mithro | This 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 |
| litghost | mithro: ? | 17:40 |
| mithro | https://github.com/YosysHQ/yosys/pull/872 | 17:41 |
| tpb | Title: Improve handling of "full_case" attributes by cliffordwolf · Pull Request #872 · YosysHQ/yosys · GitHub (at github.com) | 17:41 |
| litghost | mithro: Cool, we'll want to merge that once it is merged upstream | 17:47 |
| *** proteusguy has joined #symbiflow | 18:28 | |
| *** proteusguy has quit IRC | 19:48 | |
| elms | litghost: 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 !2_2@5_2` meaning 2nd bit of 2nd word for tile 5_2. | 20:40 |
| litghost | elms: That would never happen in a 7-series part. Under what circumstance would it occur otherwise? | 20:54 |
| elms | I 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. http://www.clifford.at/icestorm/io_tile.html | 20:55 |
| tpb | Title: Project IceStorm IO Tile Documentation (at www.clifford.at) | 20:55 |
| elms | litghost: ieren bits for tile 7 0 are in 6 0 and vis-versa | 20:56 |
| elms | s/vis/vice/ | 20:56 |
| litghost | elms: 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 tool | 20:57 |
| elms | input enable and pullup resistor enable | 20:57 |
| elms | so a special case in the fasm2asc tool? | 20:58 |
| elms | litghost: 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 |
| litghost | elms: Sounds good | 21:00 |
| elms | nevermind, looks like blink uses one of those IOs | 21:02 |
| litghost | elms: Can you explain in more details what is happening? Is it a non-uniform feature set across IOs? | 21:06 |
| litghost | elms: If it's uniform, why not emit both features at the IO site? | 21:06 |
| elms | It'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 |
| litghost | elms: Ya that sounds like something that should be handled in a patch up step, but maybe I'm missing something. | 21:11 |
| elms | litghost: 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 |
| litghost | elms: 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 |
| litghost | elms: Enabling features that cross tile boundries seems like an extremely terrible idea, especially if it leads to aliasing | 21:12 |
| elms | not sure why it's a bad idea. Seems like a complication vs. generality trade-off | 21:14 |
| litghost | elms: 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 |
| elms | litghost: ok so I may fork from the format for ice40. It is only used internally. | 21:18 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!