<tpb>
Title: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<elms>
mithro: digshadow: I'm looking at running https://github.com/SymbiFlow/fpga-tool-perf again. I already have started running some locally. Any pointers on setting it up for regular automated runs in the cloud?
<digshadow>
elms: TBH the biggest issue was that it was a pain to get all of the tools licensed
<digshadow>
I made a token effort at trending type stuff, but I don't think it was really finished
<elms>
digshadow: ok I remember some discussion and thought that's sort of where it was left.
jevinskie has joined #symbiflow
<elms>
I think I'll try running all non-licensed and then start with licensed less often locally. The results for those shouldn't really change.
<sf-slack2>
<kgugala> @litghost: as @mkurc started working on the muxgen stuff @mithro wanted him to contribute to the #703
<mithro>
kgugala: Hrm?
<digshadow>
mithro: shared a gdoc with you about state of 2064 development. If at least the IOB bitstream question looks good I'll send that to ken for comment
<mithro>
digshadow: Mind if I put it in the SymbiFlow shared public folder?
<sf-slack2>
<kgugala> @mithro maybe I got wrong impression? You pinged as here yesterday and later @mkurc in the issue
<mithro>
kgugala: I send @mkurc an FYI that I was working on the routing mux FASM stuff
<sf-slack2>
<kgugala> Ah
<sf-slack2>
<kgugala> So can we help with it?
<sf-slack2>
<kgugala> Or you want to finish it yourself?
<mithro>
kgugala: I'm going to finish it off today
<litghost>
I believe mkurc had started on the FASM feature and FASM prefix stuff, and I was requesting additional design documentation on that
<litghost>
mkurc also had a little bit on the FASM LUT annotations
<sf-slack2>
<kgugala> @mithro: great
<mithro>
I was under the impression that mkurc was working on *other* FASM attribute stuff
<digshadow>
mithro: sure move it as you wish
<digshadow>
and I will delete mine if needed
<digshadow>
i'll stop editing
<sf-slack2>
<mkurc> I took task related to FASM support to V2X. And support for "fasm_mux" in interconnects was there. And i made a proposal how I see the solution.
<litghost>
mkurc: FYI, I do like the shape of your FASM_MUX solution
<litghost>
mkurc: However I do think there was some confusion that mithro was going to tackle that particular annotation
<tpb>
Title: Use v2x for XML generation Milestone · GitHub (at github.com)
<sf-slack2>
<mkurc> @litghost Thanks
<sf-slack2>
<mkurc> @mithro @litghost BTW I answered your comments in #685
<sf-slack2>
<mkurc> I am concerned about the solution proposed in #703. It requires having a pb_type with only `<interconnect>/<mux>` inside (no child pb_types). It is not clearly stated in the VPR doc but according to @acomodi findings this is illegal.
<sf-slack2>
<mkurc> If a pb_type does not have child pb_types then it is concidered as a leaf and cannot have the <interconnect> inside.
<sf-slack2>
<mkurc> @litghost Interesting. If it is legal than we can proceed with approach in #703
hzeller_ has quit [Ping timeout: 245 seconds]
kraiskil__ has quit [Ping timeout: 248 seconds]
kraiskil__ has joined #symbiflow
_whitelogger has joined #symbiflow
<mithro>
litghost / mkurc: Yes it is legal but not great, I'm just adding some code to v2x to "lower" routing muxes into the pb_type interconnect for now
<hackerfoo>
litghost: Do you think it would make sense to break the block RAMs in half the way we did with DPRAM32? There are two symetrical halves that only share the memory array.
<litghost>
hackerfoo: I don't think so. The routing graph actually treats them seperately
<litghost>
hackerfoo: You'd have to prove that the routing graph is the same for each black box
<litghost>
hackerfoo: Which would be exciting
<hackerfoo>
litghost: Okay. Maybe I'll think about that later.
<digshadow>
mithro: ken added comments to the XC2064 doc. So basically 1) IOB is incomplete 2) no bitstream to verilog support, although some (partial?) work was done on bitstream to netlist 3) no XC2018 support from ken
<digshadow>
which roughly matches my expectations
<mithro>
digshadow: Guess I was dreaming
<mithro>
digshadow: Ahh yeah - maybe it was bitstream to netlist (rather than bitstream to verilog)
<mithro>
might be worth poking cr1901_modern in ##openfpga
<hackerfoo>
I'm curious: why the XC2064? Because it's simple?
<mithro>
hackerfoo: Yeah
<mithro>
It's also real hardware
<hackerfoo>
It *was* real hardware.
<hackerfoo>
Although I see you can still get them, but not through DigiKey.
Bertl_oO is now known as Bertl_zZ
<hackerfoo>
Is there a test that infers dist. RAM? I want to test inferring RAM32X1D.
<hackerfoo>
Otherwise I'll write a quick ram_shifter test.
<litghost>
I want to say both murax and picosoc prefer RAM32X1D over RAM64X1D due to their register sizes