zoobab has quit [Remote host closed the connection]
Gurty has joined #m-labs
<whitequark>
so, is there a non-obtuse way to get messages out of rtio_log?
<sb0>
explain
<whitequark>
I need something faster than RPC
<sb0>
without gtkwave/vcd?
<whitequark>
yes
<sb0>
you can hack-add a print() into analyzer.py
<whitequark>
haha no.
<whitequark>
there was a perfectly good print to corelog.
<sb0>
pretty sure most users would disagree with that
<sb0>
I'm also fine with adding corelog access to kernels for debugging purposes. but print() should be the python print.
<whitequark>
sb0: your analysis was incorrect
<whitequark>
dds_batch_enter/exit are called in correct sequence
<whitequark>
ah, hm, I think I see the problem
<whitequark>
sb0: is it possible that dds_batch_exit() itself raises RTIOUnderflow?
<sb0>
yes, in fact this is where it is typically raised
<whitequark>
yep, that's exactly what happens
<whitequark>
ok so and
<whitequark>
what do you want me to do?
<whitequark>
I instrumented the code and the enters/exits are sequenced correctly
<whitequark>
it goes like this: ...
<whitequark>
exit in
<whitequark>
exit out
<whitequark>
enter in
<whitequark>
enter out
<whitequark>
exit in
<whitequark>
underflow
<whitequark>
enter in
<whitequark>
and then it crashes with DDSBatchError
<sb0>
make this thing work. I hadn't researched it. from your analysis, I guess the solution is make the C code reset batch_mode in dds_batch_exit, no matter whether it raises it not
<sb0>
also, I want to understand why there was no underflow/collision exception raised when you used the TTL channel
<whitequark>
there was a corelog message btw
<whitequark>
Attempted to use invalid DDS bus
<sb0>
oh right, so it just squashed the writes
<sb0>
that should be an exception, not a corelog message. my bad.
<sb0>
probably DDSBatchError can be renamed DDSError, and the string indicates the error (batch, channel, ...)
hozer has quit [Ping timeout: 276 seconds]
<whitequark>
that test takes way too long.
<whitequark>
20s here.
<sb0>
yup. another fishy thing is why the DDSes take so long to program.
<whitequark>
it takes 7s if I start from 150us and nothing if I start from 200us
<whitequark>
ah, no, then result is wrong, I guess
<GitHub39>
[artiq] whitequark pushed 2 new commits to master: https://git.io/vaoMW
<GitHub39>
artiq/master f4ab507 whitequark: Bring back target print function.
<GitHub39>
artiq/master dbc0a89 whitequark: dds.c: turn off batch mode before an underflow can be raised....
<GitHub126>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vaoDs
<sb0>
"We are writing to let you know that with effect from 27 January 2016, the Slashdot Media business, which provides online services through various web sites including Slashdot.org and SourceForge.net (the "Slashdot Media Services") has been purchased by SourceForge Media LLC"
stekern has quit [Ping timeout: 250 seconds]
stekern has joined #m-labs
rohitksingh_work has joined #m-labs
<kyak>
i was under impression that SourceForge is slowly dying
<kyak>
if they acquire someone, things are not so bad?
rohitksingh_work has quit [Ping timeout: 252 seconds]
<sb0>
"able to offer a bundle program that is fully compliant with Google’s strictest policies"
<kyak>
so they will keep shipping crapware to inattentive users...
<kyak>
and what the hell is "Google's policies"..
<kyak>
Being monopolist is no good. 5 years back SF hosted pretty much every open source project, and was not able to fight the temptation to take advantage of that. From the other hand side, the "everything is on Github" current situation as becoming alarming as well
<GitHub78>
artiq/master d60eaa7 Robert Jordens: scanwidget: fix div by zero rubberband width (closes #335) (4b8fe1e)
robtaylor has joined #m-labs
mindrunner has quit [Remote host closed the connection]
mindrunner has joined #m-labs
fengling has quit [Quit: WeeChat 1.4]
<sb0>
anyone knows what the round sticker on new FMC connectors is for?
<rjo>
vacuum
<rjo>
pick and place
<rjo>
sb0: i put the three small changes into the branch. i am 100% behind the design as described.
<rjo>
the preferred adc/dac ratio in the lab is usually either around 1:0 _or_ 1:1 _or_ 0:1. There is little middle ground.
<sb0>
rjo, good.
<sb0>
re. upgrades, I wonder if the FPGAs might be even capable of loading themselves from the fiber ...
<sb0>
load a bootstrap bitstream that then overwrites the whole fabric. AFAIK most FPGA components, except the block RAMs, are double-buffered and such a thing would work.
<sb0>
maybe with some digging into undocumented bitstream commands ;)
<sb0>
hm. may be tricky to do cleanly. seems on 7-series you are sometimes supposed to disable interconnect globally while loading new configuration (to prevent contention), which would obviously kill the bootloader
<sb0>
so it'll most likely have to make a round trip to the flash.
<sb0>
(or some device simulating a flash if we really want hot-loading)
<sb0>
well, SPI SRAMs are very small
<sb0>
and there's no such thing as SPI PSRAM
<rjo>
yep. the bitstream swapping and that golden fallback bitstream thing seems reasonable easy. the other thing is usually done with a cpld and an sram iirc. faking bpi or spi.
<cr1901_modern>
Xilinx also sells special EEPROMs designed for bitstream swapping, IIRC
<sb0>
no, Xilinx-brand configuration memories don't have any advantage over modern SPI flash and are more expensive and harder to source
<sb0>
rjo, FWIW that worked fine on milkymist with a parallel NOR flash
<sb0>
and spartan 6
<rjo>
bootstrapping through a cpld?
<rjo>
by the way, mithro, sb0: for gsoc students i would propose a) bpi flash support in openocd and b) jtag for mor1kx in openocd. both would be very valuable additions to the SoC ecosystem.
<sb0>
rjo, no, the fpga reflashing/rebooting itself
<sb0>
I'm not sure about the CPLD. sounds complicated for what it brings compared to reflashing.
<sb0>
what would be the BPI for?
<mithro>
sb0: Series-7 FPGAs already have the ability to do multiple different boot modes, including multistage booting
<sb0>
mithro, yes, but can you have a bitstream load another full bitstream through the ICAP without killing itself?
<rjo>
that way you can boot from network. bpi is not needed. can also be spi.
<sb0>
rjo, I meant, BPI in OpenOCD.
<mithro>
sb0: kinda, IIRC you can basically load a bitstream which configured a bunch of register like things which will make the FPGA load a bitstream from a different location in the spi flash
<rjo>
that is not what we are talking about here.
<rjo>
sb0: to flash your milkymist or mixxeo things.
<rjo>
then urjtag can also go away.
<mithro>
so you load your bootloader into the SPI flash at address 0, you use that to get the second stage image from else where and push it into the SPI flash at an offset after the bootloader then tell the FPGA to load that
<rjo>
or even if we want to do the bitstream swapping with kc705. the spi flash is too small for two bitstreams.
<sb0>
okay, so if we have a CPLD, what kind of memory should it have to store the intermediate bitstream?
<sb0>
it should be rather large, so SRAM will be expensive. other options are SDRAM or PSRAM which is really just DRAM with special geometry and controller...
<rjo>
good old spi flash to store the bootload gateware and a sram for the final one that is retrieved by the bootloader gateware over network.
<sb0>
large SRAMs are surprisingly expensive
<rjo>
but from what i have seen on zynq. you can actually load a bitstream and than atomically swap everything. even without executing the "initial" register values.
<sb0>
or at least they were when I was trying to avoid writing sdram controllers ...
<rjo>
anyway. on zynq you can easily hot-swap the bitstream from within the bitstream itself.
<sb0>
actually, we could even use DRAM, and put the FPGA in slave mode to deal with the non-constant data rate due to refresh and swapping rows
<mithro>
rjo: oh yeah, I think pretty much all the options I saw required you to have flash size big enough to store multiple bitstreams
<sb0>
a stupid SDR SDRAM controller should be CPLD-compatible
FabM has quit [Quit: ChatZilla 0.9.92 [Iceweasel 38.7.0/20160308234001]]
<sb0>
rjo, from within the bitstream, or from the ARM?
<rjo>
from the arm, which is instantiated, configured, and wired up in the bitstream(s).
<sb0>
rjo, why is there the global interconnect disable/enable command on 7-series then?
<rjo>
i would expect the same trick to be possible through ICAP as well.
<rjo>
what is the global interconnect?
<sb0>
there seems to be some global signal in 7-series FPGA that disables all the interconnect switch at once
<sb0>
the configuration user guide says that signal should be asserted while loading configuration data, in order to avoid internal contention
<sb0>
also, if the bitstreams were double-buffered, there shouldn't be much contention
<rjo>
like GTS, GWE? dunno. but i would also think that loading from the huge shift register into the working registers is atomic and loading the shift register is a side channel.
<sb0>
there is no huge shift register. the granularity is one "frame"
<sb0>
if the bootloader could fit in one frame, it might work. but one frame is rather small...
<mithro>
rjo: Know any students who could do either of the projects you just suggested?
<rjo>
mithro: i am more at home in the pysics circles. rarely seen a student do gsoc there.
<rjo>
mithro: how many applicants did you get already?
<mithro>
Not many. I did a guest blog post for the open source blog about open hardware stuff which should be up in an hour or two - hopefully that might attract more
<sb0>
100 LUTs...
<mithro>
I'm pretty sure if the physicist can code they can participate.
<sb0>
unless the protocol is trivial and the transceiver can take care of itself, that won't work
<mithro>
Anyway, I should be asleep
<mithro>
Gnight!
<sb0>
whitequark, would you like to investigate why the DDS programming is so slow?
<sb0>
#316 is still open ...
<whitequark>
yes. 316 is still open. i'm working on it today