<litghost>
kgugala: Why do you believe the values are in picoseconds versus nanoseconds?
<litghost>
kgugala: Also, I'm trying to find T_setup for D w.r.t. CLK, and I don't see it
<litghost>
kgugala: I believe the speed model in question would be bel_d_reg_init_ff_setup_din_clk, but I don't see it in our output SDF. Did I missing ?
<tpb>
Title: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
proteusguy has joined #symbiflow
<mithro>
What is still not working is pack_pattern and mode interaction
jevinskie has joined #symbiflow
citypw has quit [Ping timeout: 258 seconds]
citypw has joined #symbiflow
citypw has quit [Ping timeout: 258 seconds]
citypw has joined #symbiflow
OmniMancer has joined #symbiflow
<sf-slack2>
<kgugala> @litghost indeed those timings look like ns - this is an easy fix. I'll do that
<sf-slack2>
<kgugala> @litghost the bel_d_reg_init_ff_setup_din_clk is dumped from the design, but it is not emitted to json from which the sdf is created
<sf-slack2>
<kgugala> @litghost this looks like a bug, I'll check it
citypw has quit [Ping timeout: 258 seconds]
Bertl_zZ is now known as Bertl
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tpb>
Title: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro>
<pb_type> 'ff' timing-annotation/<model> mismatch on port 'Q' of model 'dff', port is a sequential output but has neither min nor max T_clock_to_Q specified
<litghost>
Ya, you need to have T_clock_to_Q and T_setup at a minimum
<litghost>
T_hold is pretty much always required for a modelling standpoint, but not from VPR standpoint
<tpb>
Title: WIP - utils/vlog: More tests from timing tutorial. by mithro · Pull Request #645 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack2>
<kgugala> also, the eblif, does not use any $dffs
<mithro>
litghost: Previously with the cmake stuff, only files had directory information in the target name. The `get_rel_target` makes the other targets follow the same pattern as the file targets and include the directory information. This means if you have something called "omux" under the xc7 directory and something called "omux" under the ice40 directory the target names won't conflict.
<sf-slack2>
<kgugala> so the circuit it implements want's to connect inbuf directly to dsp_combinational
<sf-slack2>
<kgugala> s/it//
<sf-slack2>
<kgugala> this connection is not feasible in the arch generated from the verilog in this test
<mithro>
kgugala: So the actual issue is that you need multiple leaf elements to fill in a tile
<sf-slack2>
<kgugala> @mithro multiple elements + top level (which is not taken into account now)
<mithro>
kgugala: You don't need a top level
<mithro>
kgugala: You just need enough .subckt parts to cross a tile
<sf-slack2>
<kgugala> @mithro: but what about top level ports? And their connections to the leafs?
<sf-slack2>
<kgugala> like in the above example clk input is defined in the top pb_type
<sf-slack2>
<kgugala> and then connected to leafs
<sf-slack2>
<kgugala> as direct connections in the top pb_type
<sf-slack2>
<kgugala> which returns the first found pb_type with eblif attribute
<mithro>
kgugala: Yes
<sf-slack2>
<kgugala> so this one is invalid -- we should include all the leafs there
<sf-slack2>
<kgugala> + info how they are connected
<sf-slack2>
<kgugala> potencially the top level may instantiate other non leaf pb_types
<mithro>
kgugala: Once we have found a leaf, we should walk outward adding extra models as needed to get to the top level pins
<sf-slack2>
<kgugala> @mithro: yes
<sf-slack2>
<kgugala> and we should do that for all the found leaf pb_types
<mithro>
kgugala: I think that is potentially a more exhaustive test
<mithro>
kgugala: This test was just to check that vpr would accept the pb_type.xml in some form
<sf-slack2>
<kgugala> @mithro: dsp_in_registered has two leaf pb_types - dff and dsp_combinational
<sf-slack2>
<kgugala> and it is not very complicated test
<mithro>
kgugala: Yes, but dsp_mode has a *whole* bunch -- I think in that case we just want to test one?
jevinskie has joined #symbiflow
jevinskie has quit [Client Quit]
<sf-slack2>
<kgugala> @mithro: yes, dsp_mode is even more complicated, it instantiates non leaf pb_types which instantiates leafs. Solving this would solve our issues here
<litghost>
mithro: I highly recommend further splitting your PR, because I think some changes are closer to being ready to merge. For example, I'm pretty sure the XML sort stuff is fine, it just needs some tests and documentation. Where as the FASM MUX stuff might need more iterations
<mithro>
litghost: Yeah, I'm splitting xslt stuff into it's own pull request with some tests
adjtm has joined #symbiflow
adjtm_ has quit [Ping timeout: 258 seconds]
jevinskie has joined #symbiflow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Bertl is now known as Bertl_oO
jevinskie has joined #symbiflow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mithro>
litghost: Do you know if you can decompose the timing information in the carry block into muxcy / xorcy components?
<litghost>
mithro: That's actually exactly the opposite of what we want to do
<tpb>
Title: [xc7] CARRY4 timing model requires 1 black box · Issue #729 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro>
litghost: for the basic additive model they should be isomorphic, right?
<litghost>
mithro: But they aren't additive, take a look at the timing values
<litghost>
mithro: How do you draw a path from DI0 to CO3 with decompistion
<litghost>
mithro: I don't think you can
<mithro>
DI0 -> CO3= DI0 → MUXCY A → MUXCY B → MUXCY C → MUXCY D → CO3
<mithro>
?
<litghost>
mithro: But looks at the actual values
<litghost>
mithro: How do you decompose the delay values to reconstitute that path
<litghost>
mithro: I don't believe you can
<mithro>
litghost: You might be right, but I haven't seen proof either way at the moment?
<litghost>
mithro: Why do I need to prove to you why it cannot be done? Don't you actually need to engage with the problem and see if your suggestion can work here?
<litghost>
mithro: To be clear, I already considered why it can be done in a decompisitional way, and I don't believe it can
<mithro>
litghost: More I haven't looked at the problem close enough to have a good enough understanding to prove to myself that decomposition won't work and haven't yet seen a good example of how it wouldn't work (but don't currently have time to find that example)
<litghost>
mithro: Then why don't you take my word that I did consider it, and don't believe that avenue is worth considering
<mithro>
litghost: It would be good to have an understandable explanation of they the decomposition doesn't work (for future reference)
<mithro>
litghost: Like, I'm 75% sure you are right, I just don't understand why you are right yet and it would be good to document why you are?
<litghost>
mithro: I don't agree. We always consider alternatives, and prune those choices based on judgement. We don't exhaustively prove every avenue that doesn't work, in fact doesn't work
<litghost>
mithro: I'm open to a decomposition approach, but I don't see how to get from here to there, and I don't see why it matters one way or another. And I definitely don't see a reason to prove that decomposition doesn't work
<litghost>
mithro: In fact, the real problems has to do with approximating the change in delay caused by the DI mux, which is totally immaterial to the MUXCY decomposition problem
<mithro>
litghost: Well, could it be done via adding an extra delay when the mode has the flip flop enabled?
<litghost>
mithro: But is specifically long the AX -> output path, so a straight delay is definitely wrong
<litghost>
mithro: Approximating the delay as an input delay is reasonable per the spreadsheet
<litghost>
mithro: To provide clarity, the S -> FF path delay is not affected by the fanout on the AX -> FF or AX -> ??? path
<litghost>
mithro: So adding an additional delay from the CARRY blackbox to the FF will result in the wrong value
<mithro>
litghost: If you were able to decompose it horizontally, you could have a <mode "CO0 output"> / <mode "CO0 to FF"> / <mode "CO0 to FF and output"> with different timing?
<litghost>
mithro: I don't think VPR supports routing based modes with a change in blackbox
<litghost>
*without a change in blackbox
<litghost>
mithro: Also the mode would depend on an input routing mux in addition to two output routing muxes
<mithro>
litghost: The first mode would not have a FF black box, the second mode would not have a CO0 to output pathway and the last mode would have both?
<litghost>
mithro: But the FF isn't part of the carry, it is downstream of the FF input MUX
<litghost>
mithro: So you cannot include the FF inside the mode, without a fairly dramatic mode explosion
<mithro>
litghost: I think some whiteboarding might help but I'm going back to the thing I'm suppose to be trying to finish :-P
Jon_ has quit [Quit: Page closed]
Bertl_oO is now known as Bertl_zZ
<hackerfoo>
From looking at RAM36E1, it looks like there are 4 ports, AU, AL, BU, and BL, where U/L share cascade and ECC logic. There are four sets of 15 bit addresses. Maybe it's possible to build a dual-read, dual-write 36K block RAM.
<litghost>
hackerfoo: Unless I'm missing something, that is what the Xilinx documentation explicitly says?
<litghost>
hackerfoo: That is what they mean by "true dual port"
<hackerfoo>
I think that's slightly different than two RAM18E1s in SDP mode.
<litghost>
hackerfoo: But it's the same as RAM18E1 in TDP, with double the underlying memory
<hackerfoo>
TDP is any combination of two ports, read or write, and SDP is one read + one write, but at twice the width.
<litghost>
hackerfoo: Agreed? And?
<litghost>
hackerfoo: Actually maybe not. TDP is two read ports and two write ports
<hackerfoo>
What I'm suggesting is similar to two RAM18E1s in SDP mode, but sharing the same address space.
<hackerfoo>
I'm 50/50 on whether it will work or not.
<litghost>
hackerfoo: I think you are just describing normal RAM36E1 TDP mode
<litghost>
hackerfoo: How is it different?
<hackerfoo>
There aren't enough address lines for TDP to do 2 independent reads and 2 independent writes at the same time.
<litghost>
hackerfoo: But each port can do a read or a write (or read/write)
<litghost>
hackerfoo: I don't think what you are thinking works, because AU and AL access a disjoint space
<hackerfoo>
There are 4 sets of address lines in a RAM36E1, which makes sense because they are somehow composed out of two RAM18E1s, each of which have 2 sets of address lines.
<litghost>
hackerfoo: Right, but AU simply accesses the upper half, and AL accesses the lower half
<litghost>
hackerfoo: I don't believe AU can access the lower half of the space
<litghost>
hackerfoo: The high address pins are simply selecting which half gets accessed
<hackerfoo>
That's the question I have, since I didn't see any documentation on the U/L ports.
<hackerfoo>
That makes sense, because it's similar to how it works with distributed RAM.
<hackerfoo>
Do all the U/L corresponding pins just get tied together, then?
<hackerfoo>
It looks like it.
<hackerfoo>
Is it better to do that in the tech map or the pb_type? Probably the pb_type.
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow
<hackerfoo>
No, I guess not, because all these pins still need to be routed.