<FFY00>
python packages are not usually problematic
<FFY00>
I never used nix but the packaging seems pretty easy
<FFY00>
but why do you need shell.nix in the upstream repo?
citypw has joined #symbiflow
az0re has joined #symbiflow
<hackerfoo>
So others can use it.
<hackerfoo>
I don't think it'd really be useful in nixpkgs yet.
adjtm has quit [Remote host closed the connection]
adjtm has joined #symbiflow
proteus-like has quit [Ping timeout: 240 seconds]
<FFY00>
okay
<FFY00>
I guess there's nothing like the AUR in arch right?
<FFY00>
if you want to start packaging, go for it :D
<FFY00>
just keep in mind the headaches
adjtm has quit [Remote host closed the connection]
adjtm has joined #symbiflow
citypw has quit [Write error: Broken pipe]
az0re has quit [Write error: Connection reset by peer]
tcal has joined #symbiflow
az0re has joined #symbiflow
OmniMancer1 has joined #symbiflow
OmniMancer has quit [Ping timeout: 264 seconds]
<hackerfoo>
As far as I can tell, all users of VPR are also hacking on it.
<hackerfoo>
So there's no reason to package it up yet. The shell.nix gives you a stable cross-platform setup for development.
<hackerfoo>
So Nix is still useful before sending a PR to nixpkgs.
ramin_r348 has quit [Ping timeout: 240 seconds]
OmniMancer1 has quit [Read error: Connection reset by peer]
OmniMancer has joined #symbiflow
proteusguy has joined #symbiflow
kraiskil has joined #symbiflow
futarisIRCcloud has joined #symbiflow
adjtm has quit [Remote host closed the connection]
adjtm has joined #symbiflow
<daniellimws>
Hi, I'm hoping to contribute to symbiflow-arch-defs by adding testbenches, starting with the muxes under vpr/ (https://github.com/symbiflow/symbiflow-arch-defs/tree/master/vpr/muxes/logic) as I see there's an example for mux2. May I know where can I find the steps to run the test (for example, vpr/muxes/logic/mux2)? Is it necessary for me to build every submodule in "third_party" for this?
adjtm has quit [Remote host closed the connection]
adjtm has joined #symbiflow
adjtm has quit [Remote host closed the connection]
adjtm has joined #symbiflow
adjtm has quit [Remote host closed the connection]
adjtm has joined #symbiflow
wavedrom has quit [Ping timeout: 265 seconds]
kraiskil has quit [Ping timeout: 246 seconds]
Vonter has quit [Quit: WeeChat 2.7.1]
Vonter has joined #symbiflow
kraiskil has joined #symbiflow
az0re has quit [Remote host closed the connection]
CMP1 has joined #symbiflow
Bertl_zZ is now known as Bertl
OmniMancer1 has joined #symbiflow
OmniMancer has quit [Ping timeout: 265 seconds]
proteus-guy has joined #symbiflow
<CMP1>
Hello, I am looking at the `segbits_clbll_l` for every mux, only one connection can be established, right ? But what will happen if thats not the case ? Will the configuration be aborted ?
kraiskil has quit [Ping timeout: 252 seconds]
_whitelogger has joined #symbiflow
<litghost>
CMP1: Are you asking from the perspective of the FASM assembler (e.g. fasm2frames) or the hardware itself?
<daveshah>
CMP1: no, there is no error checking for stuff like that, you could actually create a short circuit
<daveshah>
(I was assuming "configuration be aborted" was referring to the hardware config FSM)
<mithro>
CMP1: A lot of the configuration bits are set up to make it very hard to create shorts
<mithro>
CMP1: but I do believe there are cases where it is possible
<CMP1>
Thank you and yes I am talking about the hardware config FSM
<CMP1>
mithro isnt it very easy to do it in the muxes case for example?
<CMP1>
So in the case of a short it would act like an or gate ?
luaraneda has left #symbiflow ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<mithro>
CMP1: possibly, I didn't look at your specific example
<daveshah>
No, a short would be a short, but I'm not sure if any of the muxes in `segbits_clbll_l` would be short-circuit-able
<CMP1>
what I was thinking is something like that `CLBLL_L.SLICEL_X0.AFFMUX.AX !30_00 !30_02 !30_03 30_01CLBLL_L.SLICEL_X0.AFFMUX.CY !30_01 !30_03 30_00 30_02CLBLL_L.SLICEL_X0.AFFMUX.F7 !30_02 !30_03 30_00 30_01CLBLL_L.SLICEL_X0.AFFMUX.O5 !30_01 !30_02 30_00 30_03CLBLL_L.SLICEL_X0.AFFMUX.O6 !30_00 !30_01 !30_02 30_03CLBLL_L.SLICEL_X0.AFFMUX.XOR !30_00
<CMP1>
!30_01 !30_03 30_02`
<CMP1>
and I was thinking what would happen if I enable both `CLBLL_L.SLICEL_X0.AFFMUX.O6` and `CLBLL_L.SLICEL_X0.AFFMUX.O5` for example
<daveshah>
Ultimately it depends how it is implemented in hardware
<daveshah>
the interconnect muxes are based on pass transistors, followed by buffers in some cases, so generally can create shorts
<daveshah>
I don't know what the SLICE muxes look like though
<daveshah>
In this case, O6 is a subset of the O5 bits
<daveshah>
so enabling both would be the same as the O5 pattern
<CMP1>
when you talk about interconnect muxes you mean something pip related that cant be seen in the vivado view ?
<daveshah>
By interconnect muxes I mean pips in INT_ tiles
<daveshah>
as opposed to being inside slices
<CMP1>
I see
<CMP1>
so generally setting wierd combinations like that may lead to shorts
<mithro>
CMP1: adding DRC checking to some of the tooling to prevent things like that could be a good task
<daveshah>
But if you want to destroy the chip, filling it with ring oscillators will probably be just as destructive and easily possible without any bitstream hackery
<daveshah>
From what I've heard from people in the industry, the failure mode from shorts on a modern FPGA is likely to be thermal
<mithro>
CMP1 / daveshah: See the work from Derek and Imperial College if you want to really know how to do damage
<CMP1>
mithro Nice! but one has to first find actual problems because as daveshah pointed my example was pretty much stupid
<CMP1>
@daveshah I dont want to destroy the FPGA, on the contrary I want to see how many silly things I can do on the bitstream without risking to dammage it
<mithro>
CMP1: We aim to never generate a bitstream that Vivado wouldn't also generate
<daveshah>
Your FPGA is probably more likely to be destroyed by a lightning strike than by open source tooling
<daveshah>
Across 1000s of icestorm and trellis users there have been no reports of damage
<CMP1>
I see, I havent really dug into your bitstream generating tools, I am currently focused on the XRay so I try to explore any manual modification as well
<CMP1>
daveshah Its not the tool I am afraid of but the what ifs in my brain :P
<daveshah>
A single short like this isn't going to cause immediate damage
<CMP1>
can it lead in unexpected behavior ?
<hackerfoo>
Xilinx's documentation on partial reconfiguration warns about mismatched bitstreams, saying that there could be damage over a period of time.
<hackerfoo>
So this means, even if you have random stuff next to each other, they still don't expect immediate damage.
<CMP1>
also do you have a link of Derek's thesis ?
<daveshah>
Someone from Intel suggested that a probable failure mode for a bitstream full of short circuits would be the FPGA desoldering itself from the board
<daveshah>
CMP1: yes, because two inputs to the mux are now connected together this could cause odd things to happen
<CMP1>
daveshah now that sounds fun haha
<daveshah>
I think azonenberg managed to kill a Xilinx CPLD that way through some kind of internal failure, but it took 30 minutes
<CMP1>
those odd things would not be forseeable by the one that created that short though, right ?
<daveshah>
Chances are if you have created the short it is deliberate
<CMP1>
yes but will the effect of it be deterministic ?
<CMP1>
(I might have started saying stupid things now )
<daveshah>
No, because it would depend on things like drive buffer strength and input sensitivity, which could vary chip-to-chip and across temperatures
<tpb>
Title: Data Flow in SymbiFlow Arch Defs for Xilinx Series 7 Testing + Verification - Google Drawings (at docs.google.com)
<tpb>
Title: SymbiFlow Bitstream Verification Process - Google Drawings (at docs.google.com)
<daniellimws>
Oh so if it hasn't been worked on for quite some time, should I still work on adding testbench code for those modules? Would they be useful?
<mithro>
daniellimws: I would love to see that stuff working again
<mithro>
daniellimws: I hadn't actually realized we had merged it...
<daniellimws>
You mean from elmsfu's branch?
<mithro>
daniellimws: Yeah
miek has joined #symbiflow
<daniellimws>
And some changes has been made to the build system too, i.e. the cocotb Makefile was removed and replaced with a CMakeLists.txt but I'm unsure how to use it
<tpb>
Title: Using the return objects from custom_target to generate names of another custom_target · Issue #3175 · mesonbuild/meson · GitHub (at github.com)
<FFY00>
nevermind
lromor[m] has joined #symbiflow
sean has joined #symbiflow
sean has quit [Remote host closed the connection]
sean has joined #symbiflow
CMP150 has quit [Remote host closed the connection]
sean is now known as Guest46259
Guest46259 has quit [Remote host closed the connection]
promach3 has joined #symbiflow
bunnie[m] has joined #symbiflow
nrossi has joined #symbiflow
abeljj[m] has joined #symbiflow
xobs has joined #symbiflow
hzeller[m] has joined #symbiflow
wavedrom has quit [Ping timeout: 256 seconds]
<brent>
Been generating lots of BRAM tests for our BRAM bitstream patching project. Found, for the xc7a50 part, that some INIT bits are missing for certain BRAM locations on the chip (based on the .fasm file generated by bit2fasm). Have hundreds of successful test cases, seems to be working for all but 2 tiles (?). Have a miminal test case to exhibit issue. Would like to track down and fix, would appreciate an expert's input
<brent>
and insights at this point...
<litghost>
Any chance you are using BRAM36 with ECC enables?
<brent>
No, pretty basic
<brent>
Inferring memories using Verilog always blocks...
<litghost>
Best make an issue then
<brent>
That's what I thought...
<daveshah>
Hi brent, btw, good to see you around!
<brent>
Hi dave, long time no see. Been working behind the scenes for a while, this is the first I have interacted on the channel. Looking forward to much more...
<brent>
Hi daveshah, long time no see. Been working behind the scenes for a while, this is the first I have interacted on the channel. Looking forward to much more...
<_whitenotifier-3>
[prjxray] nelsobe opened issue #1285: Missing INIT string data in FASM for selected BRAM sites - https://git.io/Jv7Nm
OmniMancer has joined #symbiflow
Bertl is now known as Bertl_oO
OmniMancer1 has joined #symbiflow
OmniMancer has quit [Ping timeout: 256 seconds]
lromor[m] has quit [Quit: Idle for 30+ days]
tcal has quit [Ping timeout: 252 seconds]
tcal has joined #symbiflow
tcal has quit [Ping timeout: 240 seconds]
adjtm_ has joined #symbiflow
adjtm has quit [Ping timeout: 250 seconds]
tcal has joined #symbiflow
hzeller[m] has left #symbiflow ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
kraiskil has quit [Ping timeout: 258 seconds]
kraiskil has joined #symbiflow
tcal has quit [Ping timeout: 256 seconds]
tcal has joined #symbiflow
QDX45 has quit [Remote host closed the connection]