<Xark>
(I have never seen stroke or pet in real code...)
<whitequark>
rqou: AHA
<whitequark>
-mllvm -stack-size-section
<whitequark>
The section simply contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128).
<awygle>
:-( okayyyy
<whitequark>
rqou: there's also -warn-stack-size
<whitequark>
I think
<whitequark>
yeah
* awygle
pets watchcats
noobineer has joined ##openfpga
<rqou>
awygle: watchcats will just shove your code off of the edge of ram and make it crash faster :P
noobineer has quit [Ping timeout: 245 seconds]
<rqou>
ugh, i hate how max v has essentially "lower" and "upper" parts of tiles that have limited ways to connect between them
<gruetzkopf>
>pcie multicast
<gruetzkopf>
cursed technology
<rqou>
dafuq?
<gruetzkopf>
new fun stuff from the pcie as generic system to system fabric fraction
<gruetzkopf>
multi-root pcie switches are *fun*
<rqou>
i didn't even know that was allowed
<gruetzkopf>
only with these specialty switches
<gruetzkopf>
and nontransparent bridges which can do address translation and stuff like that
<gruetzkopf>
(did i ever tell you the fun things you can do with a firewire link and the iommu page fault handler?
<sorear>
somehow i did not realize PCIe NAT was a thing
<pointfree>
21:09 <balrog> pointfree: I'm curious, anything new on the PSoC side of things?
<pointfree>
05:29 <rqou> pointfree: current status of psoc?
<pointfree>
Not recently, except for some improvements to the docs on psoctools.org and familiarizing myself with yosys, etc code a bit more. I'm currently busy acquiring equipment I need for my lab-in-a-storage-locker.
<gruetzkopf>
plx-avago-broadcom has BIG switches with 24ports@16lanes and address translation tables for each of them
<gruetzkopf>
for top-of-rack pcie switches
<rqou>
pointfree: is every bit understood at this point?
scrts has quit [Ping timeout: 264 seconds]
<kc8apf>
I built a PCIe system fabric with NTBs a few years ago. 8 machines booting off a single NIC split with virtual functions was trippy
<rqou>
ooh right, virtual functions exist
<rqou>
SR-IOV is a pretty neat idea
<rqou>
whee, my tool no longer reports any left-going R4 wires as "unknown"
<rqou>
meaning (assuming no bugs) the tool has encountered at least one bitstream with each left-going R4 used
<kc8apf>
NTBs + SR-IOV == faux MR-IOV
<rqou>
max v seems to have a very annoying balance of "how come this cannot be connected to that?" and "oh wait, most real designs will be route-able"
<gruetzkopf>
VFs on nics can be very useful but also very annoying (in case the nic does not provide a mac per VF and therby confuses the next switch)
<feuerrot>
gruetzkopf: firewire + iommu? -v
<gruetzkopf>
okay. suppose you have a device and want to connect it to your laptop. the power usage and form factor were not conductive to being used with The AdapterTM. so you hack up your linux kernel to forward PIO writes and reads via fw dma. this gets you up to enumeration
<gruetzkopf>
now, interrupts are interesting. you catch them in the device you're hosting the card in, then DMA into iommu-unmapped address space of the laptop. in the iommu page fault handler, you can now fake your interrupt
<gruetzkopf>
similarly for PCI device originated DMA, you point it to unmapped space, and catch that in the page fault handler of the hosting box
<gruetzkopf>
it's *extremely* slow, but works
<rqou>
wtf
<gruetzkopf>
all that hax because we don't have a nice, coherent laptop<->big box interface
<gruetzkopf>
i want the multi-gigabyte-per-second 2-fiber optical fabric they promised me in 200x
rohitksingh has joined ##openfpga
<feuerrot>
rqou: justgruetzkopfthings
<rqou>
lol
<feuerrot>
who else would connect a railway control center via wireguard and some fancy SPS hardware to dn42?
scrts has joined ##openfpga
<rqou>
oh wut i hope this isn't a bug
<rqou>
some down wires from the top io cells seem to only stretch one tile?
<rqou>
or at least according to the coordinates
<rqou>
then again it might just be fucky coordinates
<rqou>
hmm, seems the wires really are short
rohitksingh has quit [Quit: Leaving.]
bitd has joined ##openfpga
rohitksingh has joined ##openfpga
pie_ has joined ##openfpga
ZipCPU_ has quit [Ping timeout: 264 seconds]
bitd has quit [Ping timeout: 245 seconds]
<pie_>
something something mathematics is the only way
<pie_>
<rqou> the problems mostly seem to be of the form "frameworks are very hard and tend to make 90% of tasks easy and the remaining 10% impossible"
<mithro>
cr1901_modern: Have you had any luck with the lm32 on the ice40?
<cr1901_modern>
No, and I haven't touched it this week tbh, due to a number of other things needing attending that I put off. I'll try my last few options either this weekend or early next week.
<cr1901_modern>
mithro: ^
<mithro>
cr1901_modern: It might be good to get it into a state that someone else can repo
<cr1901_modern>
repo as in reproduce?
<mithro>
cr1901_modern: Yes
<mithro>
cr1901_modern: Get other people to look at it
<cr1901_modern>
daveshah was able to reproduce on ice5k board
<daveshah>
yeap
<cr1901_modern>
tinyfpga said he'd look at it on his end when he has time; I pointed him to a repo of my findings
<cr1901_modern>
mithro: I have one last thing to try on my end (litescope probing). I have the wires set up, I just haven't built the bitstream yet
<cr1901_modern>
daveshah: Is it possible you could make a PR for migen for the ice5k board?
<cr1901_modern>
and litex*
<daveshah>
cr1901_modern: sure, quite busy right now but might have time over the weekend
<cr1901_modern>
daveshah: Understood, I'd do it myself, but I don't like to make PRs for boards I don't personally have
<cr1901_modern>
just in case I missed something
<daveshah>
cr1901_modern: yeah, I agree with that too. Just can't guarantee a time right now
<mithro>
cr1901_modern: Do I need to send you a up5k board now too? :-P
<mithro>
cr1901_modern: Didn't I send you a tinyfpga?
<cr1901_modern>
mithro: Yes to tinyfpga, (poe's law) no need for up5k
<mithro>
cr1901_modern: Oh, wait I forget that has an 8k not an 5k
<cr1901_modern>
right, so we've determined that: * crash can be dup'd on 5k and 8k, dup'd across toolchains (icestorm and icecube)
<cr1901_modern>
But I don't remember if the SPI flash bus activity is the same
<mithro>
Wow
<cr1901_modern>
on 5k and 8k
<cr1901_modern>
I could reasonably file a tech issue w/ lattice :P
<mithro>
cr1901_modern: Well, if the lm32 doesn't work in icecube on the up5k that would actually be interesting :-P
<daveshah>
the 5k issue was skipping over branch instructions, not following them
<cr1901_modern>
daveshah: Right, and _if_ I make a specific change to the output verilog for tinyfpga, I can duplicate that behavior
<cr1901_modern>
w/ the default arachne-pnr seed, the CPU crashes b/c it decodes an invalid address range that goes nowhere. If I force this address range to go to SPI flash, the CPU continues at the normal location
<cr1901_modern>
but skips over branches
<ZombieChicken>
I have 2 questions: 1) Can you load code to an FPGA w/o having the FPGA save the code over reboots? 2) How long does it take to load code to an FPGA?
<mithro>
ZombieChicken: (1) Yes - that is normally how you do it, (2) seconds -- depends on the method though
<cr1901_modern>
daveshah: What's the name of the 5k board you use? Is it esden's board?
<daveshah>
cr1901_modern: yeah, icebreaker
<ZombieChicken>
mithro: Good to know. I was looking at FPGAs and most seem to have some nonvolatile storage and I just wanted to be sure that wasn't the only option available
<mithro>
ZombieChicken: Some boards have the programmer connected to the flash rather than the FPGA -- these boards are silly
<mithro>
ZombieChicken: For the tinyfpga it's require because of the fact it uses the FPGA *as* the programmer
<ZombieChicken>
never heard of tinyfpga
<ZombieChicken>
until today
<cr1901_modern>
these boards are silly <-- I mean, there's no choice on ice40 arch I don't think. No JTAG
<ZombieChicken>
cr1901_modern: You mean you have to load code into flash on ice40's?
<cr1901_modern>
yes
<ZombieChicken>
That's a shame
<cr1901_modern>
well, that's not strictly true
<cr1901_modern>
ice40 can read a bitstream directly from a host PC, but it can only do it on reset
<ZombieChicken>
on chip reset?
<cr1901_modern>
on FPGA reset yes
<ZombieChicken>
guess that makes sense
<ZombieChicken>
reset -> reload doesn't sound too bad
<ZombieChicken>
unless the reset takes forever
<cr1901_modern>
Nah, it's as fast as the SPI-enabled microcontroller/FTDI chip can talk to the FPGA
<ZombieChicken>
Well, given I don't know too much about electronics and ICs, that doesn't mean too much to me
* cr1901_modern
goes and pretends to be a productive member of society
<awygle>
on the order of a hundred milliseconds (so, not less than 10 ms, not more than 1000 ms)
<awygle>
except it can be arbitrarily slow if you make it be, of course. that's assuming best effort for speed
rohitksingh has quit [Quit: Leaving.]
<ZombieChicken>
ok, ty
ZombieChicken has quit [Quit: Have a nice day]
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
rohitksingh has joined ##openfpga
Miyu has joined ##openfpga
ZipCPU has joined ##openfpga
<rqou>
whitequark: how can I actually pass mllvm flags to rust?
<rqou>
putting it in RUSTFLAGS just gives "unrecognized option m"
<rqou>
and there seems to be no documentation at all about this
rohitksingh has quit [Quit: Leaving.]
DocScrutinizer05 has quit [Remote host closed the connection]
DocScrutinizer05 has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<rqou>
ugh rust is just not _quite_ good enough at having minimal copying of data around
<qu1j0t3>
rqou: from a friend
<qu1j0t3>
| -C llvm-arg
<qu1j0t3>
| -C llvm-arg=foo
<qu1j0t3>
hth
<rqou>
wut
<rqou>
and where do i pass that?
<rqou>
e.g. `xargo build --release -C llvm-args=-stack-size-section` --> found argument -C which wasn't expected
<rqou>
same with `rustc` instead of `build`
<rqou>
and `RUSTFLAGS="-C llvm-args=-stack-size-section" xargo build --release` --> unknown command line argument '-stack-size-section'
<rqou>
whitequark?
<qu1j0t3>
yeah, it was RUSTFLAGS)
<rqou>
well, that doesn't work either
j`ey has joined ##openfpga
<j`ey>
what flag are you trying?
<qu1j0t3>
rqou | and `RUSTFLAGS="-C llvm-args=-stack-size-section" xargo build --release` --> unknown command line argument
<qu1j0t3>
| '-stack-size-section'
<qu1j0t3>
looks like it might be a -- option?
<qu1j0t3>
(long opt)
<rqou>
nope
<j`ey>
rqou: rust's version of LLVM doesn't have that flag yet
<rqou>
lol ok
<rqou>
thanks a lot whitequark /s
<j`ey>
rqou: I think it's only a few days out too :/
<qu1j0t3>
j`ey++
j`ey has left ##openfpga [##openfpga]
<rqou>
ugh rusr really really is lacking in "plz no copy"