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
<mindrunner>
rjo, byte crap at the beginning of the stream are not my problem. the occur randomly. somethimes the first '0'-byte comes after 700MB of data transfer, sometimes its within the first kilobytes. its totally weird.
<mindrunner>
how do I know what the ground plane is? and what exactly to stitch together? I've never done this before
<rjo>
yes. there you also get a nice fifo mode for data transfer.
<mindrunner>
whats the difference to the data transfer on the ppro?
<mindrunner>
isnt this kind of functionality implemented in the bitstream?
<rjo>
yes. but if there are no wires the best bitstream won't help you.
<mindrunner>
yeah sure.
<mindrunner>
looking good. and it has SD card. Lots of more opportunities then. However, I need it fast and i am in australia, :/ Dont know if I can get it that quickly here...
<mindrunner>
ah, is the big difference the ChannelB wiring of the USB? ppro is wired to JTAG and pipistrello is wired for serial async FIFO?
<rjo>
ppro is wired to jtag and uart over ftdi, pipistrello is wired to jtag and (uart or parallel 8 bit fifo with handshaking) over ftdi.
<rjo>
or does florent's stuff do both? the easier of the two is ok.
<mindrunner>
cool, thx rjo
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
balrog has quit [Ping timeout: 245 seconds]
<mindrunner>
how do I know which parts of the groundplane I have to patch? Im gonna open a beer if someone reveals this secret for me! :)
balrog has joined #m-labs
aeris_ has quit [Quit: en a pas]
<sb0>
rjo, there's a second problem beside the races: since the DDS bus is shared between all channels, writing to one channel from the override may clash with the writes to another channel from the kernel
<sb0>
I don't like this DDS override very much. reliable readout should be doable otoh by analyzing all the signals including FUD with dedicated gateware
<sb0>
rjo, we're probably going to use lwip in the end (uip is too incomplete, e.g. it cannot have more than one outstanding TCP packet data at any given time, which makes comms slow when sending to computers that use delayed acks, i.e. most of them)
<sb0>
the latest lwip release is v4, git is dual-stack
rjo_ has joined #m-labs
<rjo_>
sb0: ack. you would like to do the override at the rtlink level, right?
<rjo_>
na at that "Interface" level.
<sb0>
yes
<sb0>
but by "DDS bus" I mean the wires, here
<rjo_>
yes i see the problem. let's not do partial overrides of shared busses then.
<rjo_>
i am wondering what the complexity of a soft override would be: at kernel compile time or with some ddb trickery.
<rjo_>
right now the ttl override and readback stuff would be requests through the master, worker, comm_* to the core device comm-cpu. the soft overrides could modify the ddb and would become active on the next experiment compilation. but we don't have a ddb modification protocol yet, iirc.
<sb0>
I'd make that direct TCP to the core device
<sb0>
with a different client than the normal GUI
<sb0>
we can also handle the DDS overrides in the runtime, controlled with the same auxiliary TCP connection, with the understanding that any overrides will only take effect after kernel switches
<rjo_>
the worker would not "own" the core device?
<rjo_>
to have that override in the runtime, the comm-cpu would have to do a lot of tricky poking around in the kernel-cpu space, right?
<rjo_>
or would you do that through the mailbox?
<rjo_>
ah. the worker can't own the core device because of the suspending thing.
<rjo_>
but if you have something like the GUI client talk directly to the core device, that would require the core device to have broad visibility and exposure.
<sb0>
rjo_, the override registers would be exposed to the comms-CPU, not the kernel-CPU
<sb0>
rjo_, the kernel-CPU is busy running the kernel and cannot check the mailbox.
<sb0>
the worker would "own" the kernel-loading part of the core device. but TCP supports several simultaneous connections...
<rjo_>
BTW: "echo -e" is portable and debian/ubuntu having /bin/sh as dash breaks it, let me change it to printf.
<rjo_>
yes.
<rjo_>
but it sounded like you wanted to connect to the core device (comms-cpu) directly from the override-client/gui.
<sb0>
yes. why go through all the intermediate layers?
<rjo_>
can the core device handle a reasonably busy LAN?
<sb0>
adding code and complexity in each of them
<GitHub131>
[artiq] jordens pushed 1 new commit to master: http://git.io/vvr80
<GitHub131>
artiq/master a5ea404 Robert Jordens: runtime/Makefile: use printf instead of non-portable echo -e
<rjo_>
can it handle a portscanner from NIST ITAC hammering it?
<sb0>
do we really need to reinvent TCP port forwarding?
<sb0>
also, yes, from the cursory testing I've done it seems lwip holds pretty well
<sb0>
e.g. ping -f doesn't noticeably slow down the echo server
<rjo_>
reverse NAT? omg.
<sb0>
not NAT, port forwarding e.g. with ssh is much easier to set up
<sb0>
with encryption as a bonus
<rjo_>
yes. a nice thing. except that it needs setting up...
<sb0>
how much background LAN traffic do you have anyway?
<sb0>
if it's less than a single ping -f produces, I guess it should be OK
<sb0>
maybe SYN floods to the open port are more of an issue
<rjo_>
i have seen the itac scanners brute forcing telnet on random open ports they find.
<rjo_>
they might just open a few hundred tcp connections.
<sb0>
the core device would drop the connection it it doesn't speak the right protocol
<sb0>
with all the RAM we have, i don't think a few hundred garbage connections should be a problem
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#119 (master - a5ea404 : Robert Jordens): The build passed.
<rjo_>
looks like about 20 packets/s noise during quiet hours, a few times that when busy.
<sb0>
well, the main purpose of the comm-CPU is precisely to deal with that noise...
<rjo_>
i am not against exposing the thing. it just comes at the price of having to ensure that it behaves well.
<sb0>
so, separate override/debug client + handle DDS overrides in the runtime?
<sb0>
and delayed DDS overrides, i.e. only the new commands put into the RTIO FIFO are affected by the override
<sb0>
in other words, the override of a channel will only be effective after all commands to all channels have been executed
<sb0>
and after a kernel has finished
<rjo_>
but the core device would still speak "just one protoocol", the worker and the override-client would just use it for different purposes, right?
<sb0>
I'm more thinking of two ports + two protocols
<sb0>
it separates things better
<rjo_>
hmm how/why? but that is a minor detail.
<rjo_>
ack to the override design. as a sidequestion: do we have a way to empty/flush the fifos e.g. when we want to abort a kernel?
<sb0>
two server sockets, each handled by separate code modules in the runtime
<rjo_>
ok one socket for the kernel stuff, one for overrides etc?
<sb0>
yes
<sb0>
makes protocol decoders smaller
<sb0>
and it's C, so doing pluggable protocols is a PITA :p
<rjo_>
ack fine.
<sb0>
you can reset the whole RTIO core including the timestamp counter and PHY states, but not just reset the FIFOs
<sb0>
(PHY states == things like the OE register)
fengling has quit [Quit: WeeChat 1.1.1]
<sb0>
we may actually want to disconnect the PHY states from the reset...
<sb0>
since all this can do is produce glitches afaict
<rjo_>
oh. i'll be gone the next two weeks. the first one probably without "the internet". maybe even the second. could you let me know if there is stuff that i forgot to do that urgent things depend on? i'll get the pdq2 stuff into acceptable shape...
<rjo_>
ok. that reset sounds good.
<sb0>
with or without PHY reset?
<rjo_>
yep keeping phy state accross reset sounds good.
fengling has joined #m-labs
cr1901_modern has quit [Ping timeout: 276 seconds]
fengling has quit [Ping timeout: 245 seconds]
<GitHub52>
[artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vvrDj
mumptai has quit [Remote host closed the connection]
mindrunner_off is now known as mindrunner
_florent_ has joined #m-labs
fengling has quit [Ping timeout: 265 seconds]
uuhimhere has joined #m-labs
<uuhimhere>
can the fpga on the milkysoc bu used to implement the SNES board?
<uuhimhere>
can the entire linux kernel be implemented in logic gates?
<ysionneau>
to implement linux kernel in logic gates ? this does not make any sense to me
<uuhimhere>
is there a VHDL compiler for the linux kernel XD
<ysionneau>
no there is not
<ysionneau>
it would not make any sense to do that
<uuhimhere>
why not
<ysionneau>
it would take so many logic gates ...
<ysionneau>
take for example just the TCP/IP stack from Linux, it's just one part of Linux amongst a lot of others
<ysionneau>
and just implementing this in full hardware would take a huge number of logic elements
<uuhimhere>
whatabout a microkernel like MACH
<ysionneau>
usually, here is how it works : you put everything in software, except when there is a very high timing constraint (like you don't software bit bang an HDMI connection)
<ysionneau>
and when you identify one small part of software, which is slowing down the other parts *and* which is hardware friendly enough : you can put some software bit in the hardware, to "boost"/accelerate the system
<ysionneau>
but you don't "compile" a software down into hardware
<whitequark>
well, you sort of can
<whitequark>
there are C-to-verilog compilers. but these are really only useful for the cases where you have a complex sequential algorithm and you don't want to translate it by hand
<whitequark>
kernels and FPGAs have a fundamental mismatch in how they allocate resources
<larsc>
that's the reason why we have hardware and software in the first place
<larsc>
in the good old days there was only hardware
<ysionneau>
+ the fact that most consumer electronic product don't use fpga but ASIC, and if all software was burned into ASIC logic, then you would not be able to update it
<uuhimhere>
ysionneau, well most android phones dont get more than 1 update before theyre obsolete enyways
<uuhimhere>
and that seems to be the ASIC way
<uuhimhere>
at least for SoC systems
<uuhimhere>
besides not talking about *all software(i.e. an OS) just the kernel
<uuhimhere>
Kernel on Chip
<uuhimhere>
XD
<uuhimhere>
so instead of selling ARM chips youd be selling linux/mach/minix chips
<ysionneau>
you have several releases of Linux per year
<ysionneau>
and a lot of patches, security patches etc
<larsc>
no android phone ever see those though ;)
<ysionneau>
my samsung phone received several official updates :p
<ysionneau>
I think ... 3 or 4
<GitHub151>
[misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/vvKBk
<sb0>
uuhimhere, it all depends how many processing units you need and can operate in parallel. the idea of CPUs is that code and data are relatively static and sequential (and so can be stored efficiently in RAM) and that many logic operations can use the same hardware (the ALU)
uuhimhere has quit [Quit: Leaving]
_florent_ has quit [Quit: Leaving]
sh[4]rm4 has quit [Remote host closed the connection]
sh[4]rm4 has joined #m-labs
mindrunner is now known as mindrunner_off
<GitHub38>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vv6mh
<GitHub38>
artiq/master 6a5f58e Sebastien Bourdeauducq: runtime: support test mode on AMP
FabM has joined #m-labs
aeris_ has quit [Ping timeout: 245 seconds]
aeris_ has joined #m-labs
aeris- has joined #m-labs
aeris_ has quit [Ping timeout: 256 seconds]
mumptai has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.91.1 [Firefox 37.0.1/20150402191859]]
<GitHub89>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vvixM
<GitHub7>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/vv1Wd
<GitHub7>
migen/master 083d371 Florent Kermarrec: mibuild: add support for libraries, move .replace("\\", "/") to generic_platform.py and execute it only on Windows machines....
SturmFlut has joined #m-labs
<GitHub34>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/vv12X