tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow
ASHR has joined #symbiflow
xtro has quit [Ping timeout: 264 seconds]
xtro has joined #symbiflow
vup2 is now known as vup
citypw has joined #symbiflow
bjorkint0sh has joined #symbiflow
bjorkintosh has quit [Ping timeout: 260 seconds]
citypw has quit [Ping timeout: 268 seconds]
citypw_ has joined #symbiflow
Degi_ has joined #symbiflow
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
ASHR has quit [Ping timeout: 240 seconds]
ym has quit [Ping timeout: 264 seconds]
ym has joined #symbiflow
ASHR has joined #symbiflow
hansfbaier has joined #symbiflow
QDX45 has quit [Ping timeout: 265 seconds]
drawkula has joined #symbiflow
yeti has quit [Ping timeout: 256 seconds]
drawkula is now known as yeti
ASHR has quit [Quit: Leaving]
xtro has quit [Ping timeout: 265 seconds]
citypw_ has quit [Ping timeout: 268 seconds]
ovf has quit [*.net *.split]
ovf has joined #symbiflow
unrznbl[m] has quit [Ping timeout: 246 seconds]
xobs has quit [Ping timeout: 268 seconds]
Niklas[m]2 has quit [Ping timeout: 244 seconds]
abeljj[m] has quit [Ping timeout: 244 seconds]
promach3 has quit [Ping timeout: 240 seconds]
hansfbaier has quit [Read error: Connection reset by peer]
SmutLord^ has quit [Remote host closed the connection]
SmutLord^ has joined #symbiflow
abeljj[m] has joined #symbiflow
mkru has joined #symbiflow
mkru has quit [Quit: Leaving]
promach3 has joined #symbiflow
xobs has joined #symbiflow
unrznbl[m] has joined #symbiflow
Niklas[m]1 has joined #symbiflow
sadoon_albader has joined #symbiflow
sadoon_albader has quit [Remote host closed the connection]
gromero has quit [Read error: Connection reset by peer]
gromero has joined #symbiflow
gromero_ has joined #symbiflow
gromero has quit [Read error: Connection reset by peer]
ym_ has joined #symbiflow
gromero has joined #symbiflow
ym has quit [Ping timeout: 240 seconds]
gromero_ has quit [Ping timeout: 272 seconds]
infinite_recursi has joined #symbiflow
<infinite_recursi> Is there a difference between iceprog and iceprogduino wrt hx8k olimex board
<infinite_recursi> ?
<infinite_recursi> I do have iceprog in my installed icestorm but do not have iceprogduino. The makefile has command, iceprogduino
infinite_recursi has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
gromero_ has joined #symbiflow
gromero has quit [Ping timeout: 240 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 240 seconds]
<lambda> turns out arch-defs takes a pretty insane amount of RAM to build, I guess I'll have to use binaries :p are there any more canonical download links for the tarballs mentioned in https://symbiflow-examples.readthedocs.io/en/latest/getting-symbiflow.html#toolchain-installation?
<tpb> Title: Getting SymbiFlow SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io)
<sf-slack> <acomodi> lambda: there are latest valid links, generated only if all CIs went green
<tpb> Title: Google Cloud Platform (at console.cloud.google.com)
<lambda> acomodi: interesting, is it possible to get at that information without a google account though?
<sf-slack> <acomodi> I think that using GCS APIs should let you get there
<sf-slack> <acomodi> even without an account
<lambda> no, doesn't look like unauthorized requests can get you anything - and those files don't have public URLs either way
<litghost> The URL in that file should also be fully public, but might not be?
<lambda> yeah that works, how did you get that URL? https://console.cloud.google.com/storage/browser/_details/symbiflow-arch-defs-gha/symbiflow-xc7a50t_test-latest shows "Public URL: Not applicable"
<tpb> Title: Google Cloud Platform (at console.cloud.google.com)
<litghost> There is a "Public URL" and an "Authenticated URL"
<litghost> From the GCP bucket display
<litghost> If the documentation is pointing to the "Authenticated URL", that is a mistake
<litghost> For reference the "Authenticated URL" for that same file is https://storage.cloud.google.com/symbiflow-arch-defs-gha/symbiflow-xc7a50t_test-latest?authuser=0
<tpb> Title: Sign in - Google Accounts (at storage.cloud.google.com)
<lambda> right, I was looking at the GCP bucket, but it's not showing me any public URLs
<litghost> So the bucket was intented to expose public URLs, but if that isn't what is happening, that is problematic
<litghost> Yay debugging
<_whitenotifier> [symbiflow-docs] litghost opened issue #429: Documentation should provide directions to get latest arch-defs? - https://git.io/Jt3ob
xtro has joined #symbiflow
ayazar1 has joined #symbiflow
ayazar1 has quit [Quit: ayazar1]
ayazar1 has joined #symbiflow
ayazar1 has quit [Quit: ayazar1]
kraiskil has joined #symbiflow
alexhw has quit [Ping timeout: 268 seconds]
<lambda> where does prjxray-config come from (https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/toolchain_wrappers/symbiflow_synth#L93)? I can't find it in prjxray or prjxray-db.
<litghost> It's a way for packaging to provide the path to prjxray-db, one minute
<lambda> oh, that's fairly straightforward :p
tpb has quit [Disconnected by services]
tpb has joined #symbiflow
xtro has quit [Quit: Lost terminal]
nickoe has joined #symbiflow
<nickoe> hello
kraiskil has quit [Ping timeout: 246 seconds]
<nickoe> Why does the symbiflow-examples and symbiflow-arch-defs have different ways to "init" the dependenceis, as far as I can see both use conda stuff. The examples project uses miniconda directly while the arch-defs project has "make env" and does magic in there.
<nickoe> can't the examples and arch-defs use the same shared install env?
<litghost> They are the same under the hood in the sense that it downloads miniconda and creates an environment
<litghost> You don't have to use the wrappers for setting up the env, and the other parts of the build system doesn't actually care how the environment is created
<litghost> If you invoke cmake (for arch-defs) within an environment with the right dependencies, it should just "work"
<litghost> Same more or less for symbiflow-examples
<nickoe> I am just slightly confused by the simarilatires yet differences
<nickoe> I am trying to see if I can get an example working for the basys3
<litghost> If you want to simplest example, I would just follow the instructions from symbiflow-examples
<litghost> That should work, we actually test those instructions in CI
<litghost> If you want to try re-use a conda env, you might get off the beaten path a bit
<litghost> But you should be able to re-use the environment if you wanted too
<nickoe> running TARGET="basys3" make -C counter_test now
<nickoe> yay, there is a counter runnig
<tpb> Title: Building example designs SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io)
<nickoe> oh the gpio sutf is for another board
<nickoe> Is the litex demo too big for the basys3 board os it just becasue it has no ethrenet?
<nickoe> litghost: Do you know anything about the picosoc example? Can one build c firmware for it?
<nickoe> I don't see any c file in the example
<litghost> The idea in symbiflow-examples was to side step the firmware side to focus on the P&R side
<litghost> I believe the litex demo is just the ethernet port
<litghost> the arty and basys both use a similiar size fabric
<nickoe> litghost: ah, pretty cool I was wondering a moment about that array in that progmem.v, but I guesssed it was some rom code.
<nickoe> so in principle the litex exsample should aslo work wiht uart console?
SmutLord^ has quit [Remote host closed the connection]
SmutLord^ has joined #symbiflow
<litghost> I also believe the arty has DDR, and the basys3 doesn't
<litghost> But don't quote me on that
<nickoe> probably
<litghost> Ya, I just double checked
<litghost> The whole idea behind the LiteX Linux SoC really relies on external DRAM
<litghost> I bet you could finagle the Litex Linux SoC demo on the basys3, but you'd run out of BRAM really fast
<nickoe> anyway, it looks like I could figure outhow to run the examples. I guess next step is to figoure out how to properly simulate the counter example and get the logic analyzer plots. Is it only gtk wave people use?
<litghost> gtk wave only shows outputs I believe
<litghost> verilator or iverilog is required to generate the waveforms
<nickoe> litghost: I am pretty new to FPGA, although it was years back I learned some
<nickoe> So first I need to get used to the workflow and actually plot some veriflog bits together.
<nickoe> the examples site does not describe simulation
<litghost> So pre-synthesis simulation definitely works. Post-synthesis and post-place and route simulation is hit or miss. We have an issue to improve the situation
<nickoe> mmm, I have no idea if I want pre or post synth sim
<nickoe> I just want to know if I verilog is any good :S
<litghost> Pre-synthesis simulation is probably fine then
<nickoe> Can you please remind me what the real difference is? Do you get timging skew with post synth or something? I guess post synth must add some more details to the sim?
<litghost> Pre-synthesis is in the abstract verilog machine, post-synthesis everything has been lowered to real FPGA primitivies
QDX45 has joined #symbiflow
<nickoe> Some friends made some small modules they test with verilator tb
<nickoe> so my idea was to try to plot those in a proper project
<litghost> Post-place and route typically includes actually delays, but you can do without too
<nickoe> actually wanted to do it in vivdo, but then I saw that vivado prjects were a mess in git, so I though I might just try symbiflow and see how far I can get.
<litghost> Great, let us know how it goes!
<litghost> FYI, vivado projects aren't too awful in git, but we are always excited to have people try out the toolchain
<litghost> The key is to just re-create the project in tcl everytime
<nickoe> yeah, that I also figured by some of the top hits on google, but just exporting it and such gave absolute paths to the verilog files and I sorta just gave up
<nickoe> But just given tht symbiflow is fater to install,... if it works it works :D
<litghost> :D
<nickoe> and is FOSS sooo +++
<litghost> Word of warning, QoR from symbiflow is going to be worse than Vivado, so don't push the critical path if you can avoid it
<nickoe> This is for an SDR transmit only radio, I don't think that will be that demanding to the artix, but I don't reeallly know as I have littel experince with it.
<litghost> Good luck!
<nickoe> But the plan is just to pump stuff to an external DAC and get it to do what we want as a start.
<litghost> That should definitely be doable
<nickoe> but as I understand the toolchain, I could use the vivado pnr stuff if needed?
<litghost> So we use yosys on for synthesis, and you can have yosys output an edif for consumption with Vivado PnR
<nickoe> great
<nickoe> it is getting late here, but I will try to give it a stab tomorrow agian