sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<_florent_>
rjo/sb0: the jesd core is here: https://github.com/m-labs/jesd204 (I put it there but maybe you want to integrate it in artiq?, feel free to do what you want)
<_florent_>
rjo/sb0: the digital path and outputs are configured in my ad9154 setup, but CGS pass, ILAs too and data seems to be transmitted correctly
<_florent_>
rjo: the core should be easy to use: set enable to 0, configure the ad9154, set enable to 1, look at the ready signal
<_florent_>
rjo: to send data, use jesd_core.transport.sink.converter0 to converter3
<_florent_>
rjo: converterX is 32bits, LSB if the first sample, MSB the second one
<_florent_>
rjo: feel free to ping me when you'll be integrating it or testing it
<sb0>
did you test the migen version?
<_florent_>
not on board but the simulations are passing
<sb0>
rjo, why did you write ad9154_read & friends in C instead of ARTIQ-Python?
<sb0>
what about putting the jesd core into misoc? that's one package less to take care of
<sb0>
artiq would be too specific, there are other uses for this core
<whitequark>
sb0: I also want to kick I2C into ARTIQ Python
<whitequark>
instead of Rust
<sb0>
whitequark, ok. i propose doing those things after the basic rust port works and background rpcs are done
<sb0>
can the rust runtime keep using the C versions of i2c and dds until background rpcs are done?
<sb0>
what I'd propose is: get the rust runtime to work possibly keeping C parts, background RPCs + #560, finalize the rust runtime, in that order
<whitequark>
yes
<whitequark>
that's exactly what I'm doing
<whitequark>
well, I would like to do TMPU as early as possible because stack overflows have proved to be extremely obnoxious to debug
<whitequark>
(on comms CPU)
<whitequark>
sb0: I have a weird problem with lwip
<whitequark>
I'm trying to transmit a large file via TCP and lwip appears to simply drop some packets at random
<whitequark>
ok, now it is just stuck entirely...
<sb0>
again? does it happen with the old C runtime too?
<whitequark>
no idea, the C runtime doesn't have that code
<sb0>
it baffles me so many people seem happy with lwip. it's been a consistent shit show since we started using it
<whitequark>
I'm trying to add a self-update functionality to the Rust runtime because the UART speed is shit
<whitequark>
and the openocd scripting is unreliable
<sb0>
use tftp netboot?
<whitequark>
but when I transmit 380kB of runtime, only 260 or so come back
<whitequark>
bah, that's even worse.
<sb0>
it's faster than uart
<whitequark>
hrm
<whitequark>
how do I use that?
<sb0>
the BIOS supports it. the IPs are hardcoded though so you need to rebuild it
<sb0>
then you can reset the board with openocd (which is reliable AFAICT)
<whitequark>
I'll just try to fix this lwip junk instead
<whitequark>
it's reliable on its own
<whitequark>
it's not reliable when used via ssh
<sb0>
works fine for me
<sb0>
what problem are you having via ssh?
<whitequark>
that's because you don't have a crappy ADSL link
<sb0>
reset is only one command btw
<whitequark>
yes, and after that command I have enough latency that the invocation of flterm misses the cookie
<sb0>
speaking of crappy links, are you also having problems with the lab wlan?
<whitequark>
nope
<whitequark>
what sort of problem?
<sb0>
it has regular random periods of several seconds during which all packets are dropped
<whitequark>
haven't hit that once
<whitequark>
so it seems like an issue with your STA. what wifi card and what does dmesg say?
<sb0>
on client side, nothing in dmesg, works fine on other networks. but it's some crappy obscure broadcom chip. i'll do more testing with another card...
<whitequark>
so lwip used to just miss some packets. now what happens is that it accepts like fifteen and then stops getting any input forever
<whitequark>
bah. whatever. I already wasted more time on this than I would have saved with faster boot
<whitequark>
if this breaks RPCs at some point I'll simply write a TCP/IP stack that's less shitty
<whitequark>
which will probably also be faster than fixing lwip.;
<sb0>
what about picotcp?
<whitequark>
no idea, is that less bad?
<sb0>
never tried it
<cr1901_modern>
Any idea why lwip is breaking so badly?
<whitequark>
Adam Dunkels wrote it
<cr1901_modern>
I don't know who he his, but I do notice another project by him (Contiki) that you dislike
<whitequark>
I dunno about the guy but all his code is atrocious.
* whitequark
shrugs
<whitequark>
one of the best features Rust has yet is its macro system
<whitequark>
not only it is hygienic but also it lets you define function- or even block-local macros, and refer to identifiers from outer scope with proper lexical rules
<cyrozap>
In Migen, what's the purpose of the "_connectors" array? I can't access any of the connectors from "platform.request(connector)".
<sb0>
cyrozap, look at the examples in artiq
<cr1901_modern>
cyrozap: Also look at the mercury platform
<cr1901_modern>
I have "helper functions" that use the "_connectors" array
<cr1901_modern>
I confess I don't really understand hygeine well, but why isn't "refer to identifiers from outer scope with proper lexical rules" a side effect of a hygenic macro system in and of itself?
<cyrozap>
sb0, cr1901_modern: Thanks, I'll check those out.
<whitequark>
well, as far as I understand, a basic hygienic macro system would only prevent the macro scope and the non-macro scope from interacting
<whitequark>
I haven't expected it to actually take up identifiers from outer scopes when defined within functions etc
<whitequark>
it was a really nice discovery (although it is of course trivial to implement witin the framework that rust uses for hygiene)
<cyrozap>
Also, can someone please tell me what the acronym "CSR" means? Search engines are giving me a lot of different answers and I can't find it documented anywhere in MiSoC/Migen.
<sb0>
configuration/status register
<cr1901_modern>
whitequark: So the gist is Rust lets you refer to variables outside the scope of a macro, but also will ensure that names that conflict in and out-of-macro scopes don't interact with each other?
<cyrozap>
sb0: Thanks!
<whitequark>
cr1901_modern: yup
<cr1901_modern>
cyrozap: It's not well-documented how it works IMO. To make life easy, subclass from AutoCSR and add your CSR registers as submodules. MiSoC will use introspection to automatically generate the correct Verilog code
<mithro>
sb0: I still have half written stuff here, it is on my TODO list
<cr1901_modern>
mithro: That was NOT a slight at you :P. I didn't know someone was working on it.
<cr1901_modern>
cyrozap: I screwed up. Don't add CSR Registers as submodules. Just add them as member variables.The AutoCSR implementation in MiSoC will by default recurse into submodules looking for members with the CSRStatus/CSRStorage type.
<mithro>
I even have a post-it note on my wall with that task on it :-P
<cyrozap>
cr1901_modern: I was just wondering what the term meant, but I'm still pretty clueless as to what it is or what it's used for.
rohitksingh_work has joined #m-labs
<cyrozap>
Aaaand I still can't figure out how to use connectors...
<sb0>
you define new IOs (via extensions) that use pin names that correspond to connector pin names instead of FPGA pin names
<sb0>
this way you can have a single definition for a FMC card that you use for different FPGA boards
<whitequark>
ok, basic two-way RPCs work...
<whitequark>
now to implement the rest of the types
<cyrozap>
sb0: Oh, I see. Thanks again!
<rjo>
_florent_: ack.
<rjo>
_florent_: i'll give it a try
<rjo>
_florent_: but it's not using the QPLL yet, right? 6.6G max?
<rjo>
sb0: that would have been more code to write.
<sb0>
really?
<sb0>
but it would be good to keep the runtime and number of syscalls small
mumptai has quit [Remote host closed the connection]
<rjo>
sb0: sure. but the number of syscalls would increase. there would be more functions to expose.
<sb0>
in the short term maybe, but not after every SPI chip ever used in ARTIQ is implemented there
<sb0>
and wasn't the DAC SPI supposed to be connected to RTIO?
<rjo>
with the current way the csr access functions are generated, the code size would increase with ever bus.
<rjo>
*every
<rjo>
yes. over rtio it wouldn't be any code. but i'd like to roll this without rtio first. switching later is not much work.
<rjo>
we'd have to write a bus mux in the runtime if there are many buses and they are accessed through non-RTIO.
<sb0>
how many buses would there be in a typical system?
<sb0>
I can see the problem of many different chips as the number of supported boards increases, but the problem of lots of buses?
<rjo>
non-rtio spi busses? don't know.
<rjo>
if they are rtio, it's not a problem at all.
<rjo>
_florent_: while i integrate this i am noticing a few things that i'd like to discuss. ok to file issues at that repository?
key2 has joined #m-labs
<rjo>
_florent_: you get a few hours of sleep ;) i'll just plow ahead.
<_florent_>
rjo: yes sure, you can create issues in the repository
bentley` has quit [Ping timeout: 272 seconds]
<rjo>
_florent_: anything wrong with using the refclk undivided (not the IBUFDS_GTE ODIV2 output but the O, always assuming i am changing the other signals approriately)?
<GitHub8>
[artiq] whitequark pushed 4 new commits to master: https://git.io/vPcbp
<GitHub8>
artiq/master 3362887 whitequark: Rust: implement receiving for all RPC types.
<rjo>
sure. that's one way of harvesting/tapping. but if you rely on that you could just as well do power-line-communication.
<whitequark>
I'm not fond of PLC
<rjo>
it's horrible. it polutes the spectrum.
<whitequark>
it probably works in model environment, but not when there's a cheap fridge nearby
<whitequark>
much less a welder or something worse
<whitequark>
that too.
<rjo>
but if you harvest by temperature diff or solar or vibration, you save a bunch of cables, you can measure things without any wires etc. for physics labs, harvesting IoT stuff would be an absolute killer application.
<whitequark>
mostly I'm thinking of esp8266 now because it's clearly kind of crappy (e.g. no docs for wifi part, blobs) but at the cost and size of it, even if espressif dies tomorrow, it's still worth the miniscule amount you're spending
<whitequark>
some operational cost since a serious org wouldn't want that on its network, sure.
<rjo>
... you can just sprinkle these devices in your lab.
<whitequark>
sure, so a separate network for them and all's golden
<whitequark>
there's some issue with the way #[cfg]s are handled
<whitequark>
but I've planned look into this a bit later, yes
<whitequark>
I'm very unhappy with how the current CSR system is built to work with a cpp-style conditional compilation, such as branching over presence of individual registers
<rjo>
ok. i had the impression that that part should be done more like moninj plugins anyway.
<whitequark>
moninj is currently always built in
<whitequark>
did you mean the analyzer?
<rjo>
i think it appears in both.
<whitequark>
hm
<whitequark>
I'm not sure what you mean
<rjo>
maybe analyzer. don't remember exactly. there was a dds ftws vector somewhere.
<whitequark>
that was moninj, and the rust port will currently also fail to compile
<rjo>
what i mean is moving the dds specific stuff out of moninj and have the later be agnostic to the data and the channel type.
<rjo>
same for analyzer i guess.
<whitequark>
seems tricky as it is currently quite ad hoc
<rjo>
exactly.
<whitequark>
but the problem isn't the coupling to dds per se but that what i expect to work in conditional compilation clauses, doesn't
<rjo>
yes. those seem to be two somewhat different problems.
<whitequark>
ysionneau: can you briefly explain how your flash storage works?
<GitHub183>
[artiq] jordens pushed 5 new commits to phaser: https://git.io/vPC2H
<GitHub183>
artiq/phaser 4d87f0e Robert Jordens: phaser: instantiate jesd204b core, wire up
<GitHub183>
artiq/phaser 1193ba4 Robert Jordens: ad9154: merge csr spaces
<GitHub183>
artiq/phaser f62d600 Robert Jordens: README_PHASER: update
<ysionneau>
whitequark: its a key/value storage, do you want to know the record layout?
rohitksingh has quit [Read error: Connection reset by peer]
<whitequark>
yes
<whitequark>
I'm going to reimplement it in Rust probably
<ysionneau>
first field is the record size, if it's all 0xFFFFFFFF then it means there is no more records
<ysionneau>
next field is the key, its a NULL termiated string
<ysionneau>
all the remaining bytes is the stored value
rohitksingh1 has joined #m-labs
<whitequark>
I see, thanks
<ysionneau>
to modify an already exiting key you can add a new record with the same key name
<ysionneau>
to delete a key, you can add a new record with the same key name but record len of 0
<ysionneau>
when the flash sector is full, this is detected and there is a try to flush duplicates and remove empty records