<ZirconiumX>
Well, personal things suggest that's unlikely to be the case, but that's besides the point
<clay_1>
Oh, there always hope though
<ZirconiumX>
I've got a couple of things in mind to work on Yosys, but I think you mentioned you wanted to work on nextpnr?
<clay_1>
No, I am interested in project Xray
<clay_1>
I needed help in understanding what they have documented about the bitstream because I dont really get it
<clay_1>
looking at previous conversation here, hackerfoo I saw that he stated the following " think it's very confusing from the outside. The output of Project X-Ray and symbiflow-arch-defs is mostly data that can be used by other tools, such as VPR and Yosys. So users will never really see them in the end"
<clay_1>
so maybe thats why I dont get it ?
<ZirconiumX>
Maybe if you explain what you're looking for someone can help
<clay_1>
Thats a good idea ZirconiumX:)
<clay_1>
In a paper with the title Extract LUT Logics from a Downloaded Bitstream Data in FPGA
<clay_1>
the authors expalin how the lut values are documented on a vivado created bitstream
<clay_1>
I have not found any similar form of information in project xray
<clay_1>
what I am currently interested in is how interconnect is represented on a bitstream
<ZirconiumX>
So, the term for an interconnect here is a PIP, for a "Programmable Interconnect Point"
<ZirconiumX>
If you look at the fuzzers you can see a bunch of them that begin with "pip-"
<ZirconiumX>
These are in charge of fuzzing interconnects
<clay_1>
but it does it have them documented ? For example, if I set some given bits to a specific value it will connect a specific lut output to a specific registrer
<clay_1>
?
<ZirconiumX>
That's..a different problem entirely
<OmniMancer>
Lut output to register within one CLB is usually a mux and not considered interconnect
<clay_1>
OmniMancer do s pip would be lut to lut connection? If yes does it matter if the two luts are in the same clb or not ?
<ZirconiumX>
Pips would be LUT to LUT
<ZirconiumX>
Or rather, CLB to CLB
<OmniMancer>
I do not know much about the xilinx specifics in architecture, but there are usually inputs and outputs of the CLB, and then pips that let you connect the outputs to some set of things, including inter tile interconnect wires, and then pips that let you connect various wires as sources to the inputs
<clay_1>
i see so every connection inside a clb is not considered a pip
<ZirconiumX>
PIPs are external interconnects
<ZirconiumX>
Internal interconnect generally behaves very differently and thus is treated as such
<clay_1>
how we call the internal ones then ?
<ZirconiumX>
Muxes, generally
<OmniMancer>
The intra CLB config usually has very limited settings
<OmniMancer>
Wherase the inter CLB switchboxes are usually quite wide in what connections they allow
<clay_1>
in the frame entry here, it states "The 50th payload word is an EEC"
<clay_1>
what is EEC ? is it a typo for ECC ?
<ZirconiumX>
Possibly.
<clay_1>
(y)
Jihad has quit [Remote host closed the connection]
<ZirconiumX>
clay_1: going back to earlier, a PIP is generally like a programmable on/off switch between two wires. This means that a single wire can connect to a lot of other wires, forming a one to many relationship along the wires
<ZirconiumX>
However inside a CLB you have muxes instead, and these are always connected, but only connect to a single target.
<ZirconiumX>
Thus we consider them to be separate to PIPs
<clay_1>
so the muxes are always there
<ZirconiumX>
Yes, they're part of the CLB itself
<clay_1>
hmm I see
<clay_1>
probably thats why I have such a routing in this example ?
<clay_1>
I mean If i havent forced anything, the lut content would be stored on the lowest register but since I asked for a different one it had to make that feedback looking thing
VitiminV has joined #symbiflow
<litghost>
clay_1: There are 2/3 types of "features" that are documented. The first is pips, which are used to connect the routing fabric together. PIPs generally generate features that look like <tile>.<dest>.<src>. The other type of feature is site configuration features. Site feature are generated <tile>.<site index>.<feature>
<litghost>
In your example, you'd see some LUT features for the LUT INIT parameter, a feature for the B FF in MUX, and that's about it
<litghost>
FYI, for an Vivado design that prjxray fully understands, you can run bit2fasm to convert the bitstream from the binary format into individual FASM features
<clay_1>
in case i had more luts and ffs would i know what is connected to what ?
<litghost>
prjxray can be thought of the exercise on how to convert bitstreams from binary to some text format and back, along with timing information and graph
<clay_1>
thanks, i will the bit2fasm
<litghost>
So once sites are configured (e.g. SLICE_L), PIPs are used to configure the generate interconnect to connect sites to each other
<clay_1>
so in my screenshot, a pip is used to create that conection between the clb output and input ?
<litghost>
Yes, some out and you'll see them
<litghost>
zoom out/8
VitiminV has quit [Remote host closed the connection]
<clay_1>
yes I have seen them
<clay_1>
but if I havent done tha, it would connect to the botom register, in that case no PIP would be used, right ? because it would be handled by the site configuration features ?
<litghost>
clay_1: Sorry, can you rephrase. I don't understand your question.
<clay_1>
sure. in the picture I attached, the use of this register for storing has been forced. If I havent done that, the tool would pick the bottom one. If it picked that it would get the d value straight from the lut without making that loop
<clay_1>
so I assume that no pip will be used for that
<clay_1>
but the information for that connectio will be included in what you called "site configuration features"
shivam_potdar has joined #symbiflow
shivam_potdar has quit [Remote host closed the connection]
<litghost>
clay_1: You are correct that if the FF was in the A FF position, the interconnect based loopback would not be required
<litghost>
clay_1: In both the A FF and B FF position, there would be site configuration features to configure the FF in MUX to select the O6 -> FF path
<clay_1>
but would that also mean that no pip would be set ?
<litghost>
clay_1: In the B FF position there are additional features to configure the interconnect to loop from the SLICE_M A output back to the SLICE_M BX input
<litghost>
clay_1: In the A FF position, no additional PIP's would be required
<clay_1>
and this is needed because the internal interconnect is so to say fixed, right ?
<clay_1>
because it is expected to store Alut to Aff
citypw_ has quit [Ping timeout: 258 seconds]
clay_1 has quit [Remote host closed the connection]
Vonter_ has quit [Ping timeout: 245 seconds]
Vonter has joined #symbiflow
kgugala has quit [Ping timeout: 240 seconds]
proteusguy has quit [Ping timeout: 265 seconds]
kgugala has joined #symbiflow
<_whitenotifier-3>
[prjtrellis] gojimmypi opened issue #122: PyTrellis.cpp crashes c++: internal compiler error: Killed (program cc1plus) - Out of memory - https://git.io/Jva81
blackhat has joined #symbiflow
blackhat has left #symbiflow [#symbiflow]
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #symbiflow
Vonter_ has joined #symbiflow
Vonter_ has quit [Max SendQ exceeded]
Vonter has quit [Read error: Connection reset by peer]