<whitequark>
sb0: why does the accept callback accept a err parameter?
<whitequark>
cr1901_modern: well, they're not wrong. happened in AU
<cr1901_modern>
whitequark: I don't actually have a clear stance on gun control. I do assert that most American gun zealots are not people I want to be around, and the fears of a government takeover are not helping my opinion of them.
<whitequark>
sb0: looks like it will call you with ERR_MEM.
<whitequark>
seems completely pointless but whatever
<whitequark>
#define tcp_accepted(pcb) /* compatibility define, not needed any more */
<whitequark>
of course, the docs aren't updated...
<whitequark>
Same as tcp_listen, but limits the number of outstanding connections in the listen queue to the value specified by the backlog argument.
<whitequark>
of course, it doesn't mention that it has a SYN RECEIVED backlog, which is not the same as ESTABLISHED backlog
<whitequark>
this is almost bad enough to motivate me to write a TCP stack
<cr1901_modern>
It's not nearly as fun as it sounds, but judging from your reactions: How bad could it be to write your own?
<whitequark>
well, that's a lot of work that needs to go into verification
<cr1901_modern>
True... your experience with lwip reminds me of how I feel when I use radare2, tbh. Very little goes right, but I know damn well it's pointless to write my own
<whitequark>
I don't think it's pointless, I just don't want to do it right now
<whitequark>
>The number of bytes available in the output queue can be retrieved with the tcp_sndbuf() function.
<whitequark>
so now I have to dissect the TCP PCB in Rust...'
<whitequark>
*obviously* the size of that struct depends on configuration flags...
<whitequark>
though at least it
<whitequark>
it's constant-size before the field I need
<whitequark>
... but the tcpwnd_size_t isn't
<cr1901_modern>
Is PCB a generic term for "data structure which stores all the information associated with sending/recving data"?
fengling has quit [Ping timeout: 240 seconds]
<sb0>
whitequark, why don't you just create a helper function in C that just calls the macro?
<sb0>
there's also maybe the "rump kernel" stuff as a lwip alternative. don't know how good that is.
<sb0>
and lwip sees a lot of real-world use but is still lousy with obscure bugs; the verification of a NIH stack does sound difficult.
<whitequark>
sb0: I wouldn't classify it as NIH; memory safety is a very good reason to write a TCP/IP stack from scratch
<whitequark>
sb0: if we went the rump kernel route then we could probably run unmodified rust std
<whitequark>
(whereas I currently run only rust core+alloc+collections, basically the OS-independent parts of the stdlib, and roughly shim the OS-dependent parts, like std::time; it's annoying)
<whitequark>
netbsd likely has fewer bugs than lwip, but this is a lot of code to introduce
<whitequark>
sb0: re helper function in C: yes, but I thought the idea was to write less C code, not more :)
<sb0>
well, 2 lines of C code (that may be mergeable upstream) vs. a complicated "dissection" in rust that may have future compatibility issues ...
fengling has joined #m-labs
<whitequark>
sb0: maybe we could make a braindead tcp stack
<rjo>
sb0: should we put the AD9154 SPI onto RTIO or on regular CSR like I2C? i'd like to do the latter.
<rjo>
sb0: for running the ad9154-fmc-ebz we need a clock on j1, 1 ghz or 2 ghz. i guess the simplest thing would be to get 1 ghz from the kc705.
<rjo>
should actually be sinusoidal, 3dBm. but i think we can cope with "square".
<rjo>
na. doesn't matter. square and any frequency is fine and 3.4 Vpp max. we can do the rest with the pll for testing.
<rjo>
and do not plug the ad9154-fmc-ebz usb cable in.
<rjo>
and preferrably get a scope onto a few of the dac output channels.
<rjo>
whitequark: could you -- in the next couple of days before you leave -- mount the ad9154-fmc-ebz board onto the "second" kc705, the HPC fmc
<whitequark>
yes
<whitequark>
already discussed with sb0
<rjo>
whitequark: thx. will also need a clock connection (fmc-kc705) and preferrably the scope.
<whitequark>
rjo: please elaborate
<rjo>
whitequark: the scope connected to at least two of the DAC outputs at the edge of the board (J17 and J4)
<rjo>
whitequark: with a 50ohm termination at the scope is possible (don't know whether the scope has that or whether you have that separate). but it doesn't matter much.
<whitequark>
so sb0's scope has that
<whitequark>
but I don't know the interface.
<whitequark>
my scope doesn't, and I don't know how to add termination...
<rjo>
whitequark: and the clock input of the board J1 connected to something on the KC705 (still figuring out what's best there).
<rjo>
no termination is fine. if your scope is the one i was playing with remotely, then i'd perfer that.
<whitequark>
rjo: how long do you need that?
<whitequark>
for how long*
<rjo>
also: JP3 closed on the board
<sb0>
rjo, regular csr. we may even recycle/improve the mini-drtio i2c sequencer for that.
<rjo>
sb0: i'd do that in the cpu (startup/idle kernel). that config would fluctuate a lot afaict.
<rjo>
whitequark: if it's ok, while you are gone and then maybe once or twice after i am back on the 18th.
<rjo>
whitequark: nothing connected to the USB connector on the board
<whitequark>
rjo: ack.
<sb0>
rjo, but the sayma does not need a cpu so far.
<rjo>
sb0: i guess the bitstream on the second kc705 is still either nist_clock or your drtio-mini?
<rjo>
sb0: ack. then the sequencer. but for the jesd204b demo there is a cpu.
<sb0>
rjo, it is possible to edit bitstreams quickly to edit bram contents
<sb0>
I didn't touch the flash, it stil has the xilinx demo design afaik
<rjo>
sb0: ack. but there is runtime reconfig if somebody wants to tweak any dac datapath setting.
<rjo>
sb0: ack the bitstream.
<rjo>
sb0: did that board see the VADJ 2.5->3.3 V change?
<sb0>
what settings are you thinking about? wouldn't other parts of the bitstream be changed with a dac datapath change?
<sb0>
no. requires some annoying windows tool so I didn't do it.
<sb0>
rjo, can one generate 1GHz from the KC705?
<sb0>
there is a SynthNV in the lab too
<sb0>
its firmware is crappy, but it should get the job done
fengling has quit [Ping timeout: 240 seconds]
<cr1901_modern>
sb0: Discovered this by accident today, but... what is a MultiCycle path in the context of FPGAs/Xilinx if you know?
<rjo>
sb0: settings like iq vs independent, nco, coarse modulation. they would all not require a bitstream change for the datapath on the fpga.
<rjo>
sb0: ack VADJ
<sb0>
if your FF output only changes every N cycles, and what it is connected to looks at it (after comb logic) only at those same cycles, then you can relax the timing constraint and specify a N-cycle multicycle path
<sb0>
but there are enough problems with the xilinx timing analyzer when you are not using such advanced features, so I make pipelines instead
<cr1901_modern>
sb0: Cool thanks. Context is that I'm trying to learn (as opposed to just ripping code out) how to create a multicycle multiplier.
<sb0>
bah, make a pipelined one
<cr1901_modern>
Wouldn't I need to do the former before I can do the latter ;)?
<rjo>
sb0: we can do any clock from the fpga. does USER_SMA_CLOCK_P from the KC705 (J11) also work as an output? i would think so.
<sb0>
or if you want to save resources, make it sequential
<sb0>
and what FPA
<sb0>
and what FPGA are you using that does not have multiplier hardblocks?
<cr1901_modern>
Lattice of course :P
<sb0>
this is one of the few FPGA hard blocks that is justified and properly designed (synthesis tools infer them transparently from the * operator and push registers into them)
<rjo>
whitequark: J1 on the FMC to J11 on the KC705 with an SMA cable.
<sb0>
rjo, yes, but the IOBs have a maximum switching frequency
<cr1901_modern>
Yes, and I sorely miss them, but hindsight is 20/20 (this is related to the IIR filter problems I was having)
<cr1901_modern>
I think I am creating a sequential multiplier now that I think about it as well; Migen doesn't have a Multiplier analogue to the Divider class.
<cr1901_modern>
Prob b/c I guess b/c most FPGAs have hard IP
<sb0>
some 700MHz I think
<sb0>
rjo, then those settings would need to be changed by the metlino. i propose csr controlled by drtio non-realtime bandwidth
<sb0>
or rtio-spi, since the overhead is small and the code is already there
<rjo>
sb0: we have to use the clock divider/pll chip anyway. then i'd prefer a clock output from the fpga.
<rjo>
sb0: yes. both would work. but it seems that we need non-rtio csr for other stuff anyway.
<sb0>
rjo, is the lower frequency fine?
<rjo>
i think i'll do non-rtio csr for the spi. the code is pretty much there apart from the runtime/kernel interface.
<sb0>
cr1901_modern, yes, because multipliers in fabric rarely make sense.
<rjo>
sb0: it's a pll chip.
<sb0>
yes, but it has limits on m/d values
<rjo>
sb0: you said a few days back that we would have to use the dac's pll. and i agreed. i can't remember why. that seems wrong to me.
<sb0>
rjo, because the clock chip on the FMC card cannot go to 2.4GHz
<sb0>
and yes, it's wrong. makes synchronization difficult if not impossible.
<sb0>
now we have to also rely on a proper design of that PLL to allow for synchronization, haven't looked at that but I doubt it
<sb0>
proper design _and_ absence of bugs. if it's anything like the ad9914, all sorts of crazy things can happen.
<rjo>
sb0: the ratio would be integer and < 32. input freq is even spec'd for < 1MHz and the m/d registers are 14 bit wide.
<rjo>
we can do 1GHz output. that's fine for now.
<rjo>
1 GHz DAC clock
<rjo>
2x interpolation, 125 MHz REFIN from the KC705. 500 MHz f_DATA
* sb0
is nostalgic of the days the pentium fdiv bug was major news
<rjo>
sb0: no. we can use the pll chip for 2.4 GHz dac clock without the dac's pll.
<sb0>
really?
<rjo>
they lvpecl outputs do direct-to-output and up to 2.95 GHz.
<sb0>
"The LVPECL outputs operate to 1.6 GHz, the LVDS outputs operate to 800 MHz, and the CMOS outputs operate to 250 MHz."
<rjo>
sb0: -1
<sb0>
rjo, hm, -1 has only slightly better performance than -0. it seems the key is "VCO direct to output mode". but it's very surprising they are not touting the higher frequencies...
<sb0>
ah, the swing drops at higher frequencies, probably they didn't want to call that a LVPECL output
sb0 has quit [Quit: Leaving]
acathla has quit [Read error: Connection reset by peer]
acathla has joined #m-labs
acathla has quit [Read error: Connection reset by peer]
acathla` has joined #m-labs
acathla has joined #m-labs
acathla` has quit [Read error: Connection reset by peer]