<duck2> hello, i have been trying to make a roi harness for cmod a7
<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
<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
<duck2> i think it will be fine to map to io pins instead?
<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
<tpb> Title: Google Docs - create and edit documents online, for free. (at docs.google.com)
<mithro> litghost: There is pyverilog - https://pypi.org/project/pyverilog/ but I think that goes in the other direction
<tpb> Title: pyverilog · PyPI (at pypi.org)
<litghost> duck2: switches == buttons
<tpb> Title: GitHub - PyHDI/veriloggen: Veriloggen: A library for constructing a Verilog HDL source code in Python (at github.com)
<mithro> "A library for constructing a Verilog HDL source code in Python"
<litghost> duck2: So XRAY_DIN_N_LARGE would be set to 2 (e.g. two buttons)
<litghost> duck2: etc
<mithro> litghost: It might also be worth talking to whitequark about their approach with nmigen -- it uses Yosys to generate the Verilog
<litghost> mithro: And we feed Yosys a JSON?
<mithro> litghost: It's unclear to me the nmigen->Yosys interface....
<litghost> mithro: And we feed Yosys a JSON?
<litghost> Ignore that
<mithro> litghost: If you just want to use a template approach, then please choose jinja2 as the templating engine
<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.
<tpb> Title: symbiflow-arch-defs/generate_verilog.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro> litghost: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/448 -- is the 'INOUT' new?
<tpb> Title: make on checkout fails due to missing zybo harness · Issue #448 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<duck2> litghost: i was referring to `# For generating DB export XRAY_PIN_00=...` etc.
<mithro> litghost: whitequark can be found on #yosys and #m-labs and ##openfpga
<litghost> mithro: INOUT is not supported generally speaking, where did it come from?
<litghost> duck2: I think the PIN_xx are not used
<mithro> litghost: Seems to be in the zynq db
<tpb> Title: prjxray-db/site_type_PS7.json at b9c0324464e4b00f122ea2dc23b24ee2bad50fa7 · SymbiFlow/prjxray-db · GitHub (at github.com)
<litghost> mithro: Ya, that's not supported right now
<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.
<duck2> where do you suggest to go from here? run fuzzers? try out a yosys->vtr->... flow?
citypw has joined #symbiflow
Bertl is now known as Bertl_zZ
sxpert has quit [Ping timeout: 255 seconds]
sxpert has joined #symbiflow
nonlinear has quit [Quit: The Lounge - https://thelounge.github.io]
nonlinear has joined #symbiflow
<litghost> duck2: Make a version of buttons for your project and make sure it works (e.g. switch -> LED)
<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
<litghost> duck2: If buttons looks good, I would add UART pins to your harness and try the DRAM test or the BRAM test
<litghost> duck2: The counter test is worth running too
citypw has quit [Ping timeout: 244 seconds]
OmniMancer has joined #symbiflow
GuzTech has joined #symbiflow
<xvilka> Is SymbiFlow part of new Chips Alliance by Linux Foundation?
<sf-slack1> <mgielda> @xvilka no, there are 4 companies there as in the press release
i8hantanu has joined #symbiflow
i8hantanu has quit [Quit: Connection closed for inactivity]
<xvilka> sf-slack1: I see
<xvilka> err
<xvilka> @mgielda
<duck2> oops, i also bumped into #448 while trying to build arch-defs to run tests
Bertl_zZ is now known as Bertl
citypw has joined #symbiflow
<litghost> duck2: just build the targets for your harness
citypw has quit [Ping timeout: 245 seconds]
OmniMancer has quit [Quit: Leaving.]
citypw has joined #symbiflow
citypw has quit [Ping timeout: 272 seconds]
proteusguy has quit [Ping timeout: 252 seconds]
<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/
<duck2> but i think i might have broken something while messing with 448 so i'm trying again on a clean clone
<litghost> duck2: You shouldn't need to anything to avoid 448, just build the target specific to your board
<duck2> so i don't need to run toplevel `make` to run the tests?
<litghost> duck2: No, and I don't recommend that either
<litghost> duck2: The all target will build for ice40, zybo, etc, etc. Just build the target you want
<duck2> i see, thought toplevel make was necessary to get yosys, vtr and other tools
<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.)
<litghost> mithro: ?
<tpb> Title: Improve handling of "full_case" attributes by cliffordwolf · Pull Request #872 · YosysHQ/yosys · GitHub (at github.com)
<litghost> mithro: Cool, we'll want to merge that once it is merged upstream
proteusguy has joined #symbiflow
proteusguy has quit [Ping timeout: 252 seconds]
<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.
<litghost> elms: That would never happen in a 7-series part. Under what circumstance would it occur otherwise?
<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
<tpb> Title: Project IceStorm IO Tile Documentation (at www.clifford.at)
<elms> litghost: ieren bits for tile 7 0 are in 6 0 and vis-versa
<elms> s/vis/vice/
<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
<elms> input enable and pullup resistor enable
<elms> so a special case in the fasm2asc tool?
<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.
<litghost> elms: Sounds good
<elms> nevermind, looks like blink uses one of those IOs
<litghost> elms: Can you explain in more details what is happening? Is it a non-uniform feature set across IOs?
<litghost> elms: If it's uniform, why not emit both features at the IO site?
<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.
<litghost> elms: Ya that sounds like something that should be handled in a patch up step, but maybe I'm missing something.
<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.
<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.
<litghost> elms: Enabling features that cross tile boundries seems like an extremely terrible idea, especially if it leads to aliasing
<elms> not sure why it's a bad idea. Seems like a complication vs. generality trade-off
<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.
<elms> litghost: ok so I may fork from the format for ice40. It is only used internally.
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow