<GitHub143>
artiq/sinara 44dc76e Florent Kermarrec: Add serial Wishbone bridge...
<sb0>
^ my files are those
<_florent_>
ok
<sb0>
_florent_, btw, if you have time, two pesky problems we are having right now is a) ethernet doesn't work b) flash writing with openocd doesn't work (the write enable latch bit is stuck at 0)
<sb0>
this breaks all existing mechanisms for loading artiq kernels into the boards
<_florent_>
sb0: I need a special cable to ethernet right?
<sb0>
_florent_, you need a media converter SFP to RJ45
<whitequark>
sb0: did you want peeking at incoming data in smoltcp? I implemented that recently
<whitequark>
let me rebase and push a few more things...
<sb0>
whitequark, yea, the current solution in ionpak is good enough
<sb0>
*but the
<sb0>
the first priority is to fix the bugs that make artiq and ionpak look really bad atm
<whitequark>
yes, I know, it was just something I noticed I could do while rewriting buffer handling
<whitequark>
zero effort
<sb0>
whitequark, so there was peeking, and also getting a zero-copy slice for transmitting without knowing its length before
<sb0>
smoltcp would give you the maximum possible slice, you fill all or parts of it, then trigger the transmission at the same time as you tell smoltcp how many bytes you wrote
<whitequark>
oh yeah I actually implemented that one too earlier, just forgot to expose
<whitequark>
it's already used internally during dispatch
<whitequark>
the combinatorial explosion of methods is a bit annoying but sure that's easy now too
<sb0>
I think you can remove the current zero-copy send method, the requirement to fill the whole slice makes it unusable for all practical purposes AFAICS
<sb0>
and it's a special case of the one I propose anyway
<sb0>
but unless you are writing a DoS bot, I don't see why you'd do that
<whitequark>
um, I don't think it's useless
<whitequark>
it's usable in any case where you know the length beforehand, e.g. in all cases of buffered writing
<whitequark>
and the method you want will have to take a closure
<whitequark>
that leads to nightmarish borrow checker issues in complex code, see also: the reason TxBuffer is sent on Drop
<whitequark>
I tried to write it with closures and I don't think that's possible at all
<sb0>
_florent_, also, can all the various connections be pushed into a single module? the user doesn't need to know about this "core <--> etherbone" connection, for example
<sb0>
or instantiate FIFOs themselves
<sb0>
SerdesSlaveInit can also likely be pushed into S7Serdes, or a module be provided with both of them inside
<GitHub51>
[migen] sbourdeauducq pushed 1 new commit to master: https://git.io/v5Umz
<sb0>
"Productivity Skyrockets with Xilinx's UltraScale Architecture", well IME the only thing that skyrockets with ultrascale is vivado RAM usage and CPU time
<sb0>
behavior on the board is consistent with the simulation result, writes complete (though i have no way to check if the rtm correctly received them), reads crash the CPU
<sb0>
also after integrating the bridge, SDRAM became fucked, probably thanks to some vivado magic
<sb0>
_florent_, why does it need a reset? can't it just keep scanning the phase detector?
<sb0>
and link going down can be detected e.g. by the correct framing character not being received in some period of time
<sb0>
what i see on the board is probably unrelated to the simulation. i have ready=0 and error=1 on the rtm, and reset doesn't change this
<sb0>
*on the amc
<sb0>
_florent_, can the AMC and RTM FPGAs be loaded in any order?
mumptai has quit [Remote host closed the connection]
<sb0>
seems so. well i don't know why it doesn't work, then