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
azonenberg_hk has quit [Read error: Connection reset by peer]
mumptai has quit [Quit: Verlassend]
azonenberg_hk has joined #m-labs
<azonenberg_hk>
sb0: So whitequark tells me you have a USB host core suitable for embedded keyboard/mouse
<azonenberg_hk>
I assume this is GPL?
<GitHub180>
[artiq] cjbe opened issue #648: Absolute imports of repository modules https://git.io/v1ds8
<cr1901_modern>
whitequark: Did you deal with "File too big" errors when building clang 3.9 for Windoze? I know a workaround is to enable -bigobj, but I'm under the impression that clang is *supposed* to buildable without it.
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Client Quit]
sandeepkr has joined #m-labs
<sb0>
azonenberg_hk, yes, it's in milkymist (softusb), maybe can be relicensed if you want
<azonenberg_hk>
sb0: Yeah i was wondering if you might consider 3-clause BSD
<sb0>
what do you need that for?
<azonenberg_hk>
Because the rest of the project is 3-clause BSD and i dont want to add GPL to the bitstreams
<azonenberg_hk>
Project is going to be a displayport output, TCP offload engine, USB keyboard/mouse host, and basic VNC implementation
<azonenberg_hk>
pretty much a minimalistic thin client
azonenberg_hk has quit [Ping timeout: 260 seconds]
sandeepkr_ has joined #m-labs
sandeepkr__ has joined #m-labs
cr1901_modern has quit [Ping timeout: 260 seconds]
sandeepkr__ has quit [Read error: Connection reset by peer]
sandeepkr has quit [Remote host closed the connection]
sandeepkr_ has quit [Remote host closed the connection]
sandeepkr has joined #m-labs
azonenberg_hk has joined #m-labs
cr1901_modern has joined #m-labs
<sb0>
azonenberg_hk, if there are no other authors of the code you're taking, go ahead
<sb0>
what TCP offload engine?
<azonenberg_hk>
sb0: a refactoring of the one i wrote for antikernel a while ago
<azonenberg_hk>
going to clean up the output fifos to use main system ram instead of block ram
<azonenberg_hk>
and share some resources
<sb0>
so it's 100% of TCP in gateware?
<azonenberg_hk>
Yes, the current code is server only so i will have to add client support
<azonenberg_hk>
I have to add ICMP neighbor discovery client support (right now I respond to incoming NDP queries but can't send them) and then allow the stack to send SYNs
<azonenberg_hk>
shouldnt need much else changed
<azonenberg_hk>
although i'll probably spend some time cleaning up and optimizing it
<azonenberg_hk>
gate count was a bit higher than i wanted
<cr1901_modern>
azonenberg_hk: Is this for starship raider?
<azonenberg_hk>
cr1901_modern: That is going to use something closer to the current version of the stack
<azonenberg_hk>
b/c i wont have to implement client support
<azonenberg_hk>
that's a server application
<azonenberg_hk>
And it won't need a usb keyboard/mouse
<azonenberg_hk>
This is for a thin client i can make a bunch of around my lab and use instead of a full x86 PC
<azonenberg_hk>
on each bench
<sb0>
nice, how clean/reusable/complete is it?
<sb0>
compared to e.g. red tin
<azonenberg_hk>
have you not seen the current red tin? it's quite complete and reusable, all you'd have to do (if you didn't want to use the antikernel NoC) is to replace the NoC wrapper around the core module with something for wishbone or axi or something
<azonenberg_hk>
sure, i want to add more features some day
<azonenberg_hk>
but it works
<azonenberg_hk>
The TCP stack is a bit more dependent on the antikernel noc right now, since each layer of the stack is a separate ip core and they talk via the noc
<sb0>
no hardwired list of inputs/outputs, no BRAM instantiation, usable with just 2 UART pins?
<azonenberg_hk>
Dynamic reconfiguration of which signals you probe is very nontrivial in a xilinx flow
<azonenberg_hk>
it basically would mean reversing the ncd file format and poking it
<azonenberg_hk>
or doing massive tcl scripting in vivado
<azonenberg_hk>
All of the ram in any of my recent projects has been inferred via a wrapper
<azonenberg_hk>
that takes lut or block and a size as parameters
<azonenberg_hk>
the wrapper has only been tested on ise xst but could be easily updated to do proper inference for any synth tool it doesnt play well with now
<azonenberg_hk>
there's no uart wrapper right now but that's simply because i never had a need for one
<azonenberg_hk>
jtag gives you 10+ Mbps of throughput, uart is a lot slower
<azonenberg_hk>
and doesnt give you access to any other on-chip resources
<azonenberg_hk>
so why would i want a slower interface that needs extra pins on the chip and has less capabilities?
<sb0>
because then one doesn't need to mess with BSCAN_* primitives (or equivalent) and incompatible JTAG software
<sb0>
sure, in a perfect world JTAG is a technically superior solution
<sb0>
but the real world is more like snafu
<azonenberg_hk>
sb0: I had to write my own jtag interface code and use a ftdi dongle b/c the xilinx platform cable doesn't have a public api
<azonenberg_hk>
But once i got that working it performed significantly better
<azonenberg_hk>
in any case it'd take about an hour to write a uart wrapper instead of a noc wrapper
<azonenberg_hk>
the wrapper for the NoC is 453 lines with whitespace and comments
<azonenberg_hk>
and the first 180 lines of that is just instantiating the NoC interfaces
<sb0>
sure. "own jtag interface code" is an example of what I mean by "incompatible JTAG software".
<azonenberg_hk>
sb0: yeah but this code exists now
<azonenberg_hk>
And it's easily extensible, add one class to support a new programmer (or bridge to e.g. openocd)
<sb0>
assuming that $BOARD has a UART, that it shows up as a regular serial port on the PC, and that it has TX/RX pins connected straight to the FPGA is a lot more pragmatic
<azonenberg_hk>
So what happens when you want to debug more than one piece of logic at a time?
<sb0>
what do you mean?
<azonenberg_hk>
Or when you want a deep capture and 115 Kbps takes forever to move it?
<azonenberg_hk>
If you want more than one LA core
<azonenberg_hk>
to, say, capture in two clock domains
<sb0>
how is that different with UART than with JTAG?
<azonenberg_hk>
Because the infrastructure for using jtag for packet-switched networking already exists
<azonenberg_hk>
and you can hang as many LAs etc off that network as you want
<azonenberg_hk>
i mean sure you could make a uart bridge for it too i guess
<azonenberg_hk>
but it doesnt exist
<azonenberg_hk>
If i were to make another interface it'd probably be gig or 10gig ethernet
<azonenberg_hk>
For when jtag has insufficient bandwidth
<azonenberg_hk>
for say instruction traces or something
<sb0>
does packet switched networking bring you a real advantage compared to putting those components on a old-fashioned bus?
<azonenberg_hk>
Not moving in the opposite direction to uart
<azonenberg_hk>
it makes it nice and easy to separate virtual circuits on the far end when you have multiple PC-based test applications talking to different IP on the SoC
<azonenberg_hk>
From a security perspective having origin tagging on each packet is nice
<sb0>
if you JTAG the chip, then you own it, and security is irrelevant
<azonenberg_hk>
In the case of a current gen FPGA, yes
<azonenberg_hk>
But in a future antikernel-based ASIC, not necessarily
<azonenberg_hk>
Or an antikernel-based system with jtag fused off using a different interface for debug
<azonenberg_hk>
this is the core interconnect for the entire SoC in my model, replacing axi/wishbone/whatever
<azonenberg_hk>
its not just used for debug
<azonenberg_hk>
The debug interface is literally a layer-2 VPN that encapsulates NoC frames inside JTAG
<azonenberg_hk>
I set IR=USER1
<azonenberg_hk>
jump into SHIFT-DR
<azonenberg_hk>
then free-run TCK
<azonenberg_hk>
then whenever the host or FPGA sees a 55 55 55 D5 they know that's the start of a packet
<azonenberg_hk>
Nothing stops you from running that same framing over a uart, if you kept the noc fabric internally it would be a very minor code change
<azonenberg_hk>
again, there was just never a reason to do it
<azonenberg_hk>
it seemed inferior in all regards
<GitHub186>
[artiq] sbourdeauducq pushed 3 new commits to master: https://git.io/v1dao
<GitHub186>
artiq/master 161025e Sebastien Bourdeauducq: korad_ka3005p: use ProactorEventLoop on windows
azonenberg_hk has quit [Read error: Connection reset by peer]
key2 has joined #m-labs
azonenberg_hk has joined #m-labs
key2 has quit [Ping timeout: 260 seconds]
sb0 has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
<sb0>
whitequark, what is the proper way to have the trace! calls output something in the runtime?
<sb0>
rjo, and no. it's not drtio's fault. the kernel CPU crashes in attribute_writeback() when it's dealing with a startup kernel
<sb0>
or maybe any pre-compiled kernel, let me try
<whitequark>
sb0: trace! calls go into the core log
<whitequark>
if they go to UART then that slows the runtime down way too much
<whitequark>
if you want UART output use debug
<whitequark>
as for the attribute writeback, that's odd, I've fixed that already...
<sb0>
yup, pre-compiled kernels also crash
<whitequark>
I know where that crashes...
<whitequark>
hm, is it "firmware" now? ok
<GitHub193>
[artiq] sbourdeauducq commented on issue #641: This is not specific to startup kernels. The kernel CPU crashes in ``attribute_writeback`` and this happens with any kernel compiled with ``artiq_compile``. You can reproduce the problem with ``artiq_run some_kernel.elf``. https://github.com/m-labs/artiq/issues/641#issuecomment-267958528
<sb0>
firmware/runtime, and there will be firmware/satmanager (or something like that) as well
<whitequark>
ok
<sb0>
the "firmware" folder is for anything other than kernels that gets executed on a soft CPU
<GitHub32>
[artiq] whitequark closed issue #641: startup_kernels hang https://git.io/v1yyv
<GitHub33>
[artiq] whitequark pushed 1 new commit to master: https://git.io/v1dAv
<whitequark>
rjo: we've discussed this specific bug a few months ago didn't we?
<whitequark>
either I or you have committed the fix. not sure what happened to it
<whitequark>
s/months/weeks/
<sb0>
git merge fuckup?
<whitequark>
possibly
<sb0>
yeah that's why I dislike branches
fengling has joined #m-labs
<sb0>
the previous fix was 4df7941a9797542f461ed11730ad222c88faef81
<sb0>
where did that go?
<sb0>
okay, so if you checkout the next commit (fec34d605e1db98968eaed019b4341fac1f5e95a), then the fix is gone, but "git show fec34d605e1db98968eaed019b4341fac1f5e95a" doesn't show the fix being deleted
<whitequark>
sb0: it looks like you've removed it in 9967dfc
<sb0>
let me look at gitk
<whitequark>
hm, no, it was removed earlier
<whitequark>
sb0: correction. you've removed it in 88ad054ab
<mithro>
so it looks like nobody has used the spiflash module with single width spiflash recently (ever?)
sandeepkr has quit [Quit: Leaving]
sandeepkr has joined #m-labs
Neuron1k has quit [Ping timeout: 248 seconds]
Neuron1k has joined #m-labs
key2 has quit [Ping timeout: 258 seconds]
<rjo>
mithro: why are you asking?
<mithro>
rjo: Because I'm trying to use it with a spiflash module which is only connected in a 1x mode, I've currently disabled "with_bitbang" and added a "dq"
<mithro>
rjo: On an unrelated note, _florent_ was suggesting that you may have done some migen/misoc stuff on a Zynq chip and maybe an AXI<->WB bridge