<ramin_r348>
Hi All, I am a PhD student, working on FPGA architectures (Designing LE, DSPs, Routing) targeting ML applications. I was wondering to find a task here which I can handle and help the SymbiFlow. Also, I want to submit a GSoC application, as well. Could you please help me and tell me about the architectural works here? I have a few published works
<ramin_r348>
about LE/DSPs. I hope to be helpful.
<ramin_r348>
Thanks
citypw has joined #symbiflow
citypw has quit [Quit: Leaving]
citypw has joined #symbiflow
citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
citypw_ has joined #symbiflow
citypw_ has quit [Remote host closed the connection]
sth0R__ has joined #symbiflow
citypw has quit [Client Quit]
sth0R__ has quit [Remote host closed the connection]
citypw has joined #symbiflow
_whitelogger has joined #symbiflow
_whitelogger has joined #symbiflow
ramin_r348 has quit [Ping timeout: 240 seconds]
Bertl_oO is now known as Bertl_zZ
_whitelogger has joined #symbiflow
tcal has quit [Ping timeout: 265 seconds]
clay_1 has joined #symbiflow
clay_1 has quit [Remote host closed the connection]
kraiskil has joined #symbiflow
zeen has joined #symbiflow
zeen has quit [Remote host closed the connection]
CMP1 has joined #symbiflow
<CMP1>
Hello, I have moved into reading about PIPs and comparing it to what I can visually see in vivado. So far I have understood that to create a wire, you have to define the connection between two `pip junctions` from what is shown in vivado.
<CMP1>
If my understanding regarding that is correct, I am getting confused by the `<tile_type>.<destination_wire>.<source_wire>.` format
<CMP1>
shouldnt it be a destination/source pip junction instead ? since in each such line one wire/connection is defined
<daveshah>
In reality, pip junctions are just a wire that has pips on it
<CMP1>
so what is actually a pip, from its name I understand its a point, so to define a wire you need two pips, is that right ?
<daveshah>
A pip is a programmable connection between wires
<daveshah>
Wires are not defined by pips, it is more the other way round
<daveshah>
wires can also be connected to site pins, or other wires (a set of permanently-connected is called a node) as well as pips
<daveshah>
* a set of permanently-connected wires
<CMP1>
so, nodes are always active ?
<daveshah>
A node is a set of wires - wires are always contained within a single tile, nodes contain connected wires across tiles
<daveshah>
For example, the node INT_L_X32Y217/SL1BEG2 that covers two wires contains the wires INT_L_X32Y216/SL1END2 and INT_L_X32Y217/SL1BEG2 - these two wires are permanently connected (physically just a single bit of metal)
<CMP1>
hmm
<CMP1>
I am a bit confused
<CMP1>
pips are only connections inside a swithchbox
<CMP1>
while nodes are outside
<CMP1>
and the outside is wires
<CMP1>
is that correct ?
<daveshah>
The key difference is that pips can (with a few exceptions) be turned on or off, and generally have bitstream bits associated with them. Pips connect two wires.
<daveshah>
Wires are local to a tile
<daveshah>
Nodes represent the fact that multiple wires (possibly in different tiles) are permanently connected together
<CMP1>
that permenently, is always there or will happen after the programming ?
<daveshah>
In practice all of the wires in the node are physically a single piece of metal
<daveshah>
the reason the node is split into different wires is purely a software thing
<daveshah>
there is no way for the different wires in a node to not be connected together
<CMP1>
probably that is confusing me because in vivado as a node they mean a single wire
<CMP1>
but lets get back to the basics to see if I have at least understood pips
<daveshah>
Yes, in practice a node is multiple wires
<CMP1>
CLBLL_L_A6.CLBLL_IMUX5 this means a pip will get activated to connect the wire clbll_L_A6 with the wire IMUX5, right ?
<daveshah>
Yes, pips are almost always directional so this means that CLBLL_L_A6 is driven by CLBLL_IMUX5
<CMP1>
great
<daveshah>
If you want to see all the wires in a node, you can do it with Tcl, run `get_wires -of_objects [get_nodes $node]`
<CMP1>
is there a way to highlight the results of that in the view
<CMP1>
?
<daveshah>
No, normally you could use show_objects but that doesn't work for wires
<CMP1>
I see
citypw has quit [Remote host closed the connection]
<daveshah>
Vivado somewhat hides the existence of wires
<daveshah>
the GUI is mostly based on nodes
<daveshah>
the only place where it shows wires separate from their nodes is "pip junctions"
<CMP1>
you mean if you look at the junction name ? because graphicaly a junction is just a circle
<daveshah>
Yes, the junction name is actually a wire
<daveshah>
If you look at a node in Vivado, the section of each node in a specific tile is effectively a wire too
<CMP1>
great so graphically every wire i see outside of switchboxes are wires
<CMP1>
(but if I look at its name it will give me the node name that it contaits it)
<CMP1>
and to see the actual wire name i will have to see at the name of its associated pip junction
<CMP1>
also how do pips connect the wires together ?
citypw has joined #symbiflow
<daveshah>
Pips boil down to one or two transistors controlled by some bitstream bits (and in some cases a decoder on some of those bits)
<daveshah>
often that is followed by a buffer
<CMP1>
I see, so abstractly I can imagine them like a select switch controlled by the bitstream values ?
<daveshah>
Yeah
<CMP1>
thank you for the clarifications !
Bertl_zZ is now known as Bertl
OmniMancer has quit [Quit: Leaving.]
<CMP1>
is both `hint` and `always` indicating a fake pip that is always active ?
citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
<daveshah>
always is a fake pip that is always active
<daveshah>
hint is for route throughs, etc, that are not conventional pips but are not always enabled either
<daveshah>
For example a hint pip from LUT input to output routes through the LUT by setting the LUT value accordingly
<CMP1>
Doesnt a roit through depend on the LUT init values ?
<CMP1>
oh I think I get it. The hint means that depending on the logic in the lut, this connection may happen ?
<CMP1>
So all "CLBLL_L.CLBLL_L_D.CLBLL_L_D1 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D2 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D3 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D4 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D5 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D6 hint"
<CMP1>
show that any of the inputs of LUT D can by forwarded to output CLBLL_L_D
<CMP1>
correct ?
<FFY00>
daveshah, do you have any particular reason why you don't want meson?
<daveshah>
FFY00: the support burden of changing
<FFY00>
but changing now
<daveshah>
CMP1: yes, that's correct, any of those inputs could be routed through each setting a different LUT value
<FFY00>
not in the future, right?
<daveshah>
At any time
<CMP1>
daveshah thanks
<FFY00>
so, as you can probably see looking at the code, it is incredibly simple
<FFY00>
I almost just have definitions
<daveshah>
Yes, but that doesn't mean it won't cause problems
<FFY00>
which kinds of problems?
<daveshah>
Well, all the usual build system problems
<FFY00>
I have been using in production for several projects and never had any major issues
<FFY00>
only some really minor bugs
<FFY00>
and that was in a project with 600+ line build script
<FFY00>
not the case of trellis
<daveshah>
The reality is that anything in Trellis is something that I need to be able to support
<FFY00>
but meson can be updated with pip
<FFY00>
so, that would solve the issues there
<FFY00>
daveshah, right, but I am offering to help
<FFY00>
and to help you become conformable with it
<daveshah>
Yes, but I've had people offer to help with things like this before and disappear. No personal offence but I'm very wary of accepting stuff like this
<FFY00>
I am offering to provide support until you don't need me anymore
<daveshah>
Particularly when I'll inevitably be on the receiving end of complaints when stuff breaks for people
<FFY00>
well, right
<FFY00>
you would need to believe in me :)
<FFY00>
all I can say is that I am willing to commit
<FFY00>
would you please at least consider doing a test run?
<FFY00>
like I mentioned
<FFY00>
keep both build systems for now, if any issues arise with meson, just remove it
<daveshah>
No, because once people half start using it then it's even more of a problem
<FFY00>
so, you really really want to keep cmake?
<daveshah>
No, but at the current state of Trellis it's the best option
<FFY00>
because a lot of things are broken
<FFY00>
and my biggest issue is that it can break systems
<daveshah>
They don't seem to be affecting people on the whole
<daveshah>
No one has reported Trellis breaking their system to me before now
<FFY00>
or maybe people are not reporting it to you
<FFY00>
ah
<FFY00>
the thing about breaking systems is that most people wont really is trellis fault
<FFY00>
*wont realize
<FFY00>
daveshah, is there anything I can day to convince you to trust me? that I will provide support?
<daveshah>
No, there isn't
<FFY00>
I am packaging this for archlinux so I am already committed there
<daveshah>
But I am effectively _contractually_ commited to supporting Trellis for people
<daveshah>
I simply can't take something on that I don't know how much trouble it will cause
proteus-like has joined #symbiflow
<FFY00>
and what about you personally looking into meson and spending time time learning it
<FFY00>
and experimenting
<FFY00>
and once you are comfortable, bringing it to trellis?
proteus-dude has quit [Ping timeout: 258 seconds]
<daveshah>
I just don't have the time right now
<FFY00>
I would say that the time invested there is much less than the time you will spend fixing cmake
<FFY00>
right, I am not saying it needs to be right now
<daveshah>
I doubt that in practice
<FFY00>
I have had experience with both cmake and meson, as well with interacting with a lot of upstreams (because packaging) and I can tell you from my experience it is definitely true
<FFY00>
but you could always have a different experience
<FFY00>
is there anything in the project I could help with for you to be able to take time off to experiment with meson?
<daveshah>
To be honest I am not spending any significant time on Trellis itself atm
<daveshah>
All my time is on generic nextpnr stuff (mostly routing), nextpnr-xilinx and some currently non-OSS projects
<FFY00>
okay
<daveshah>
I don't know anything I could point you at in particular
<FFY00>
anything I can help with there?
<FFY00>
okay
<daveshah>
You could take a peek at nextpnr issues but I don't know if that will significantly reduce my burden
<daveshah>
A lot of what I am working on is pretty much "single thread" atm
<FFY00>
ack
<FFY00>
just some final comment
<daveshah>
If you are really keen on meson, then your best bet at getting it merged will be to make sure that it actually works properly for Windows and OS X
<daveshah>
and a good couple of common linux distros
<FFY00>
if you are contractually committed to support it, you could still keep cmake for that purpose
<FFY00>
while we test meson
<FFY00>
okay, right
<daveshah>
(Windows = mingw and cygwin ideally)
<FFY00>
okay
<daveshah>
Yes, in the short term. But long term I'd want to avoid that
<daveshah>
I can't guarantee a merge immediately even with those tests but it would make me happier about it
<FFY00>
yes, optimally you would in time get comfortable enough with meson to replace cmake entirely
<FFY00>
also, nextpnr also suffers from the same issues in the build system, I assume your position is the same there, right?
<FFY00>
daveshah, ack
<daveshah>
nextpnr is much more complicated so that's not changing
<FFY00>
complicated in what way?
<daveshah>
Many more configurations, some non public forks that also rely on sub cmake files, some cmake based dependencies
<daveshah>
The testing burden would simply be too high
<FFY00>
meson can generate cmake dependencies
<FFY00>
but sure
<FFY00>
just keep in mind, if you want this to actually be adopted, the build system will need to work properly
citypw has quit [Ping timeout: 240 seconds]
_whitelogger has joined #symbiflow
CMP1 has quit [Remote host closed the connection]
adjtm has quit [Ping timeout: 250 seconds]
adjtm has joined #symbiflow
kraiskil has quit [Ping timeout: 258 seconds]
<mithro>
FFY00: At the moment most of the SymbiFlow related tools are all cmake based -- having everything use the same system, even if it is less than idea is important
kraiskil has joined #symbiflow
<Degi>
At summer of code, is "infrastructure" the right tag for a PCIe interface?
<Degi>
Okay I've submitted it (since it can be changed later)
<FFY00>
mithro, meson can identify cmake dependencies
<FFY00>
is there any other issue?
kraiskil has quit [Ping timeout: 264 seconds]
OmniMancer has joined #symbiflow
QDX45 has joined #symbiflow
tcal has joined #symbiflow
tcal has quit [Ping timeout: 256 seconds]
tcal has joined #symbiflow
Renga has joined #symbiflow
OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined #symbiflow
Renga has quit [Remote host closed the connection]
lambda has quit [Ping timeout: 246 seconds]
titanbiscuit has quit [Quit: ZNC 1.7.4 - https://znc.in]
titanbiscuit has joined #symbiflow
lambda has joined #symbiflow
wavedrom has joined #symbiflow
wavedrom has quit [Client Quit]
wavedrom has joined #symbiflow
<mithro>
Degi: I'll take a look at it shortly
tcal has quit [Ping timeout: 256 seconds]
<mithro>
FFY00: For consistency reasons should be cmake *or* meson -- converting everything from cmake to meson is a big task