<whitequark>
I mean, you could probably fix it too, but it requires years of effort
<sb0_>
there are no alternatives
<sb0_>
gtk is also crappy
<whitequark>
the alternative is writing it in C++, or rather a mixture of C++ and Qt's QML
<sb0_>
not really
<whitequark>
unlike pyqt, C++ has methods and tools of combating this kind of breakage
<whitequark>
e.g. you actually get type safety, shared_ptr, and so on. and if you do screw up, you have valgrind...
<whitequark>
whereas with pyqt you have no documentation that outlines the invariants you have to maintain, and no tools to show when they're broken
<whitequark>
the applets will have to be written primarily with qt quick, which is probably the largest problem with this plan
<sb0_>
plus reimplementing all the artiq protocols in c++
fengling has joined #m-labs
<sb0_>
another pyon parser, all that stuff
<whitequark>
yes. you're getting off quite easy, since you already have the pyon layer.
<sb0_>
if pyqt's memory management wasn't absolutely lousy with bugs, that would not be a problem
<whitequark>
this is a fundamental problem with binding qt to dynlangs
<whitequark>
every binding in existence, or at least that i'm aware of, exhibits it
<whitequark>
maybe except qml. but qml is deeply integrated into qt.
<whitequark>
(qt, or gtk for that matter...)
<sb0_>
2016, the GUI situation is still complete crap
<sb0_>
look at what atom editor are doing... phew
<sb0_>
plus all the nodejs desktop programs
<cr1901_modern>
Sad part is... I like Atom :/
<cr1901_modern>
I don't think command line editors are much better. vi keybindings are a pain, emacs keybindings are horrendous.
<whitequark>
sublime gets GUIs right
<whitequark>
it "simply" had to develop its own GUI library, which presumably doesn't suck
<whitequark>
of course, the moment it would be released as opensource and bound to shitty dynlangs it will start sucking
<cr1901_modern>
It's also not free
<whitequark>
it's proprietary, yes
<sb0_>
yes, get a bag of pixels using Gtk because dealing with X is another clusterfuck, and then NIH everything like it's MSDOS
<whitequark>
well, sublime works quite well
<cr1901_modern>
sb0_: Is that seriously what they did? XD
<sb0_>
yes
<whitequark>
usually, NIH solutions don't, which is the main problem with them
<whitequark>
so like, if we actually had resources to develop a good GUI library, sure, why not? but we don't
<cr1901_modern>
There's a fine line between NIH and "dependencies we don't actually need" :/
<whitequark>
Sublime uses GTK for input methods
<whitequark>
as well as menus and interaction with the WM
<whitequark>
it's a perfectly reasonable use of GTK, especially the input method part. which you may not appreciate, not using an input method other than english.
<sb0_>
coolmy X server just stopped rendering fonts
<cr1901_modern>
Fair enough. Yes, I would not appreciate it. I would not be a good fit for a project like that
<sb0_>
speaking of crap UI
<sb0_>
bbl
sb0_ has quit [Quit: Leaving]
<whitequark>
anyway, it's not like there's a Linux system which has a GUI but not GTK installed
<whitequark>
so I don't see the problem. it's a dependency you already have. that's like complaining about requiring libc.
<cr1901_modern>
If GTK just providess the canvas, and the input, what other WM interaction does GTK provide?
sb0 has joined #m-labs
<whitequark>
like setting all the NETWM flags for menus, tool windows, etc
<whitequark>
it also handles keyboard accelerators
<whitequark>
file open dialogs
<whitequark>
especially homebrewn file open dialogs are usually really shitty
<cr1901_modern>
Yes indeed.
FelixVi has joined #m-labs
<cr1901_modern>
In any case, Atom does what I want for now. It has better tags support than my previous editor did, and I get a command prompt embeded so I don't have to swap between windows
<cr1901_modern>
A TWM would be an alternative solution to this, but... Windows :/
fengling has quit [Ping timeout: 240 seconds]
<GitHub186>
[artiq] sbourdeauducq pushed 1 new commit to release-1: https://git.io/vVqht
<GitHub186>
artiq/release-1 06e6260 Sebastien Bourdeauducq: gui: setParent(None) before deleteLater() to remove dock appears unnecessary and causes memory corruption on Windows. Closes #362
<GitHub144>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vVqhs
<GitHub144>
artiq/master deb9a60 Sebastien Bourdeauducq: gui: setParent(None) before deleteLater() to remove dock appears unnecessary and causes memory corruption on Windows. Closes #362
<cr1901_modern>
rjo: https://gist.github.com/cr1901/077b0bf15bd373f425f4c7a908e063d5 I spent some time studying both the MiSoC core and ARTIQ SPI core and put my thoughts on merging the two at the end of this document. If you have any major feedback, let me know
FelixVi has quit [Remote host closed the connection]
sandeepkr has joined #m-labs
sandeepkr has quit [Ping timeout: 260 seconds]
mumptai has joined #m-labs
sandeepkr has joined #m-labs
fengling has joined #m-labs
sandeepkr has quit [Ping timeout: 246 seconds]
mumptai has quit [Remote host closed the connection]
sb0 has joined #m-labs
FabM has joined #m-labs
Gurty has joined #m-labs
_rht has quit [Quit: Connection closed for inactivity]
sb0 has quit [Quit: Leaving]
sandeepkr has joined #m-labs
<rjo>
cr1901_modern: unless there are pressing design issues, do not change the artiq/wishbone interface at all. that's been thought through.
<rjo>
especially don't use csr there. do it as i said. wrap the spimachine in a an AutoCSR (instead of and in parallel to the wishbone wrapper).
<rjo>
artiq's spimaster does support variable transfer length between transfers. just update the xfer register.
sb0 has joined #m-labs
evilspirit has joined #m-labs
key2 has joined #m-labs
evilspirit has quit [Ping timeout: 244 seconds]
evilspirit has joined #m-labs
<whitequark>
\o/ 3.7 port is done except for testing
<whitequark>
(which will likely discover a few typos, as it was with 3.6 port)
<sb0>
rjo, what about 4 DACs/ADCs instead of 8 each, per DSP card?
<sb0>
putting 16 coaxial connectors on a FMC will use a lot of space, plus you need parts and front panel connectors for those 16 channels
<sb0>
and with two FMCs, there isn't space left on the AMC for any TTLs or maybe even the clock input
<sb0>
even for 8 channels, a card larger than FMC sounds like a good idea
<sb0>
just for the front panel connectors
<sb0>
maybe a NIH mezzanine with a 2.54 header + 8x coaxial that uses at least 2/3 of the AMC front panel is a good idea.
fengling has quit [Ping timeout: 240 seconds]
<cr1901_modern>
rjo: Ack. I won't mess with the artiq/wishbone interface. Indeed it says wrapper, so I misread the issue. So, for instance, one solution could be: ARTIQ should subclass SPIMachine from MiSoC and just add the wishbone code, and on the MiSoC end, the CSR interface and the actual functionality is implemented?
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
_rht has joined #m-labs
<rjo>
sb0: yes. i also see the front panel real estate as a constraint.
<rjo>
sb0: please no 2.54mm headers. any of the predominant solutions that look like they will be around for a while is better. that connector that e.g. the usrp hw uses (and many of others) seemed fine and has been around for a long time.
<sb0>
what about 2mm?
<rjo>
40 pins at 2mm need 40mm width in two rows. isn't that about as much as an fmc connector?
<sb0>
fmc is thicker
<rjo>
and it is so nice to have clean differential matched signals going up to the rf card. there are so many things you can do with them.
<rjo>
that thickness thing is another question. with usual fmc you put the mezzanine components towards the carrier and nothing on the "underside" (which is towards the next carriers "underside").
<rjo>
so there you want more thickness.
<sb0>
I meant, wider
<rjo>
yes. the connector or the card?
<sb0>
the connector
<sb0>
and more difficult to probe during debugging
<rjo>
you would just get any of the prototyping fmcs and probe on them.
<rjo>
but all this should be constrained from the other end. if there is no way to fit 16 sma and a clock and potentially another sfp in the frontpanel, that has to be resolved. the choice of the connector is a bit secondary.
<rjo>
(... the mezzaine connector)
<sb0>
but you cannot put both the prototyping fmc and your RF daughtercard at the same time
<sb0>
16 SMAs - more like 8-10, no?
<rjo>
maybe we can do two columns of smas.
<rjo>
that old board-to-board connector is PMC. looks like that will be around for many years.
<sb0>
for 16? or for 8?
<sb0>
what's wrong with reducing the channel count per AMC?
<rjo>
if 16 turns out to be cost effective enough to push for it, it would need two columns afaict. 8 could be done in one.
<sb0>
AMC are too small -> put less stuff on them. makes sense *g*
<rjo>
sure. completely agree. but if cost is dominated by fpga+circuitry+design+pcb then doing more channels helps.
ylamarre has joined #m-labs
sandeepkr has quit [Ping timeout: 268 seconds]
<rjo>
pmc is 8mm height as well. can the smp things even stack that short?
FelixVi has joined #m-labs
sandeepkr has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
sandeepkr has quit [Ping timeout: 244 seconds]
evilspirit has quit [Ping timeout: 252 seconds]
<sb0>
rjo, do your additions to value_bits_sign() match the behavior of the verilog output?
Gurty has quit [Read error: Connection reset by peer]
<sb0>
or rather, the other way around - since it's generally better to make the verilog output more sensible
<rjo>
sb0: i believe so. i did some testing but certainly not exhaustive.
<sb0>
the general rule is, operations on migen signals should always behave exactly as if they were integers
<sb0>
verilog does *not* do that
<rjo>
i did the former.
Gurty has joined #m-labs
<rjo>
but there is still a simulator bug that i have a tough time chasing. the vcd does not match what i read in the simulation generators.
<rjo>
there is wrong behavior in there. already before my additions.
<sb0>
ok, one by one
<sb0>
the unary minus should be fine I guess? how does it work in verilog?
<sb0>
and do we want to even bother with it and its potential idiosyncrasies, or just have the verilog converter turn it into a binary minus?
FelixVi has quit [Remote host closed the connection]
<rjo>
feel free to refactor that. but you would still have to handle it in fhdl the same.
<rjo>
and the verilog becomes a bit less readable
<sb0>
the mux also looks ok
sb0 has quit [Ping timeout: 276 seconds]
sb0 has joined #m-labs
ylamarre has quit [Ping timeout: 268 seconds]
ylamarre has joined #m-labs
sandeepkr has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<GitHub189>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vVO4f
<rjo>
the first estimate is that a DAC channel on the artiq hardware will be around 27000 LUTs, 13% of a xc7k325t.
<rjo>
sb0: ^
<rjo>
that's with 150 MHz clock, 8-parallel, 1248 MHz 16 bit samples output.
<sb0>
with what signal generation features?
<rjo>
two dc splines, two cordics, each amplitude and phase/frequency spline modulated
<rjo>
i would really like to make the cordic smarter.
<rjo>
not the cordic
<rjo>
but the usage of the I/Q outputs.
<rjo>
each channel pair could make use of two cordics, with a crossbar switch from the two cordic i,q to the two channels.
<sb0>
ok, so the 325t would actually be a nice choice on a 4-DAC card
<rjo>
that allows all physics combinations that are relevant to optimally use resources.
<sb0>
we use 52%, then there will be the drtio logic, adc, sdram controller
<rjo>
yes
<sb0>
jesd phy
<larsc>
have you started working on that yet?
<rjo>
i would guess that such a "smart channel pair" would be 17% of the kc705. makeing them crossbar switches also significantly reduces data rate for those that do iq mixing later on. then two smart pairs, 4 channels, would do 35 % of the kc705, plus another 30% for the rest of the logic.
<rjo>
plus a cpu
<rjo>
it would likely also work fine for the xc7a200t. but 8 full channels is unlikely.