X-Scale has quit [Read error: Connection reset by peer]
GuzTech has joined #yosys
promach has quit [Quit: WeeChat 2.1-dev]
X-Scale has joined #yosys
promach has joined #yosys
proteusguy has joined #yosys
pie_ has joined #yosys
leviathan has joined #yosys
pie_ has quit [Ping timeout: 240 seconds]
leviathan has quit [Read error: Connection reset by peer]
leviathan has joined #yosys
eduardo_ has joined #yosys
xerpi has quit [Ping timeout: 240 seconds]
eduardo__ has quit [Ping timeout: 256 seconds]
cemerick has joined #yosys
cemerick has quit [Ping timeout: 268 seconds]
AlexDaniel has joined #yosys
xerpi has joined #yosys
ralu has quit [Ping timeout: 256 seconds]
ralu has joined #yosys
kerel has quit [Remote host closed the connection]
xerpi has quit [Quit: Leaving]
kerel has joined #yosys
promach2 has joined #yosys
seldridge has joined #yosys
* shapr
hops quietly
* ZipCPU
wonders if shapr likes "hip hop"
<shapr>
well, I like hop
<shapr>
howdy ZipCPU! How you doin?
<ZipCPU>
Frustrated.
<ZipCPU>
I spent all yesterday trying to figure out how to reconfigure a Cyclone-V FPGA.
<shapr>
that does sound frustrating
<ZipCPU>
The interface that's well documented no longer exists, and Linux doesn't like my attempts at building device tree overlays
<ZipCPU>
(I've never built them before, so ... this is a new thing for me as well.)
<shapr>
new things are good
<ZipCPU>
While device tree overlays are the wave of the future for reconfiguring FPGA's without taking the O/S down, Linux didn't accept any of my attempts. As a result, I'm fruitless searching the Linux kernel for clues as to what I'm doing wrong.
proteusguy has quit [Ping timeout: 240 seconds]
<shapr>
sadly, I know nothing about that
<ZipCPU>
Lol ... yeah, that's my problem: neither do I :P
<shapr>
did you ask on twitter?
<shapr>
lots of FPGA people connected to you
<shapr>
that's what I do when I'm stuck on a problem
<ZipCPU>
No. I complained on twitter.
<shapr>
I got a good answer when asking whether murmurhash3 or siphash was better for a bloom filter.
<daveshah>
Must say it's a lot easier on a Zynq, you just `cat` the new bitstream into a device node
<ZipCPU>
You mean like, cat configuration.bin > /dev/fpga0 ?
<ZipCPU>
That interface has been deprecated in the Linux kernel, and that's part of what I'm struggling with.
<awygle>
DTOs are awesome but they're pretty new, do you have a recent kernel? 4.x?
<daveshah>
Yes, that's how I did it when I was doing Zynq stuff. Didn't know it had been deprecated. Have always found device tree stuff a bit of a pain tbh
<shapr>
what's better about the device tree?
<ZipCPU>
Well ... the idea is that the device tree captures some of the dependencies required by loading
<ZipCPU>
For the Cyclone-V part, you need to turn off the bus "bridges" to the FPGA before you can reload the configuration
<ZipCPU>
And the device tree is supposed to help encapsulate that process
<awygle>
device trees are a great idea - describe the PCB to the kernel so it knows what's physically attached - but yes the implementation is a bit hair-pulling
<ZipCPU>
Especially when it's not well documented.
<shapr>
oh, the tree describes what devices are attached to what?
<ZipCPU>
So, a bit of history ...
<awygle>
i find that Beaglebone has the best documentation for this kind of thing, or did ~1yr ago
<ZipCPU>
Device trees were invented primarily because of ARM. ARM was selling a CPU in terms of IP, and every chip maker was adding their own devices to it
<ZipCPU>
To deal with this, Linus invented the device tree--something that tells Linux what devices are available to it and where they are found in the memory map
<daveshah>
In general my problem hasn't been the device tree system itself, but the vendor documentation for it
<daveshah>
I agree in theory it is a good idea
<ZipCPU>
daveshah: What, you've struggled with this as well?
<shapr>
ZipCPU: sounds good so far
<daveshah>
Various previous projects, mostly doing slightly weird stuff on a Zynq
<q3k>
and before DT we had ARM machine/board IDs
<q3k>
*shudder*
<awygle>
device trees would be easier to use if they were attached to better subsystems.... ;)
<daveshah>
I remember a project I did with the iMX233 using 2.6
<ZipCPU>
shapr: So, the next step was a "device tree overlay". This was supposed to support hardware reconfiguration
<daveshah>
With a hardcoded C file doing init
<awygle>
i tried to do GPIO stuff recently, that got _complicated_
<ZipCPU>
With a device tree overlay, you can "add hardware" to running Linux system, and keep the kernel informed of what's there.
<shapr>
sounds useful?
<q3k>
daveshah: did that for some OMAPs, that was, uh, fun
<ZipCPU>
shapr: However, the overlay must match the current kernel in enough detail in order to be understood. That's where I seem to be failing.
<q3k>
and then there's some vendors (*cough* allwinner *cough*) that ship their own clone of DT because why not
<mjo-uk_>
I think it's the case that not all device tree subsystems support loading stuff dynamically. I hit this problem about a year ago trying to reconfigure the LED subsystem on a Raspberry Pi. So it works if you load it at boot but you can't unload it and load it again on a live system.
<ZipCPU>
mjo-uk_: Thanks for the insight. This might be my problem.
<mjo-uk_>
ZipCPU: A pleasure. By the way, I've really enjoyed reading your many fine articles about FPGA design. Thank you so much for posting them.
<ZipCPU>
Thank you!
promach2 has quit [Ping timeout: 264 seconds]
emeb has joined #yosys
<mattvenn>
just continuing on this DTO thread, recent beaglebone stuff has done away with the dynamic loading of overlays
<mattvenn>
it's never worked properly - have to set it up at boot
<mattvenn>
there are some very useful people on the #beagle channel
sklv has quit [Quit: quit]
sklv has joined #yosys
janrinze has joined #yosys
<janrinze>
hi people here
<sorear>
hi
<janrinze>
are there people here who are willing to teach me some tricks on timing analysys?
<janrinze>
hi sorear
<awygle>
janrinze: unless you are specifically talking about "icetime", i suspect this will not be the most productive channel for you, you may wish to try ##fpga
<janrinze>
icetime indeed
<janrinze>
I'm not yet familiar with what it can do for me to find slowest path and such
<awygle>
ah, yes. that's a known problem with abc eating net names...
<awygle>
one moment, i have something for you to try...
<awygle>
so there's an ABC command called "dress" which supposedly can recover some net names
<awygle>
i'm not entirely sure how to use it but it looks like you need a pre-synthesis netlist for comparison
<awygle>
so i guess you'd give "abc dress" your pre-synthesis and post-par netlists, it would recover names in the post-par list, then you'd run icetime on that?
<janrinze>
just add 'dress' to abc? (I use abc2)
<janrinze>
yosys -p 'synth_ice40 -abc2 -top top -blif $@' $<
<janrinze>
I was assuming there should be some kind of config for abc that I need to change
<awygle>
i think you might need to call dress from abc directly rather than through yosys, but i'm not sure
<janrinze>
the documentation is not quite clear on how to add abc flags in yosys
<awygle>
i have not actually tried the dress command so you'd be charting new territory :) you might get better names out of icetime if you pass -noabc instead of -abc2, but you'll get worse results as well, so probably not helpful if you're trying to figure out why you're not meeting timing
<janrinze>
yes.. abc2 yields best result for my design. switching that off surely will generate a lot worse timings, i agree
<janrinze>
synth_ice40 seems to be a reference to a script but i cannot find it. it is probably compiled-in in yosys.