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
<cr1901_modern>
Well this is embarrassing... I kept using 30'b1, thinking it was 30 bits of ones for the inout port direction... that's why nothing worked
<sb0>
ysionneau, can you add anaconda to the artiq manual and clearly mark it as the preferred method?
<sb0>
i also notice that you did not update the flashing instructions on the website.
<sb0>
ysionneau, "artiq_flash.sh -h" doesn't say what it does by default.
<sb0>
ah, it does, sorry
<cr1901_modern>
sb0, in Verilog, a = a + 1 always adds one to the "rightmost" bit regardless of the direction you actually declare the bus a, correct?
<sb0>
cr1901_modern, I don't care for such verilog idiosyncrasies. use migen :)
<sb0>
the bus direction in verilog seems totally useless and bug-inducing, and I don't know how it works
<GitHub31>
[artiq] whitequark pushed 5 new commits to new-py2llvm: http://git.io/vI1bd
<GitHub31>
artiq/new-py2llvm 9953302 whitequark: Move old py2llvm code to artiq/py2llvm_old.
<GitHub31>
artiq/new-py2llvm ba9a7d0 whitequark: Add support for IfExp.
<GitHub31>
artiq/new-py2llvm b8ce3f8 whitequark: Refactor error reporting in _unify to factor out custom notes.
<sb0>
rjo, do we still care about fire-and-forget RPC? in that case it might also make sense to optimize a bit the inter-CPU comms
<sb0>
I'm wondering about the best arch for the SoC, either 2x CPU with L1 direct to DRAM, or with a large shared L2 cache
<sb0>
#2 is actually a bit easier to develop, and has faster inter-CPU comms for small transfers
<sb0>
whitequark, do you actually like super()?
<whitequark>
sb0: it's not the best design but since py3 it's composable, so it's ok
<sb0>
whitequark, do you mind not using it?
<sb0>
I find its behaviour rather obscure and confusing so I tend to avoid it, but you may have good reasons for using it...
<whitequark>
sb0: I do, actually
<whitequark>
(the Python docs for super list my reasons for using it well enough)
<whitequark>
I also disagree that it's obscure, because __mro__ is also used for getattr() and friends
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#201 (new-py2llvm - e18ea0d : whitequark): The build is still failing.
<cr1901_modern>
sb0: Good answer (use Migen) in most cases XD. But I'm currently porting my own board over to mibuild, and there's a few weird things I haven't implemented yet in mibuild. This Verilog code I'm writing uses those weird features.
<cr1901_modern>
I just figured since Migen does it right- and I don't :P- you figured out how it works at some point.
<GitHub48>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vIM1A
<GitHub48>
artiq/master f84c51f Sebastien Bourdeauducq: gui: do not use broken pyqtgraph addLabel method
<sb0>
cr1901_modern, what weird features?
<cr1901_modern>
On my board, SRAM is in fact multiplexed with GPIO.
<cr1901_modern>
I were, to implement, say LM32 on my board, GPIO and SRAM could coexist- I would map them to two different addr ranges.
<cr1901_modern>
But AFAICT, I can't tell mibuild: "Okay, these FPGA pins have two different purposes, don't remove them from the queue of available pins when I call request"
<cr1901_modern>
(Minor correction: GPIO and SRAM can coexist as long as I don't try to access them simultaneously, which I'm unlikely to do with any soft-core)
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#203 (master - f84c51f : Sebastien Bourdeauducq): The build has errored.
<cr1901_modern>
In any case, it looks like a cool offering. SuperH could use a bit more love IMO
<whitequark>
what's good about sh?
<cr1901_modern>
whitequark: I'm biased as a result of SuperH being used in a lot of older consoles/designs.
<cr1901_modern>
I couldn't tell you the merits of eg, SuperH vs ARM, other than the former seems relegated to a small subset of embedded designs
<cr1901_modern>
If this project yields a SuperH for me to play around with in dev board form factor, I consider it a good thing that enriches my CPU offerings while giving me a warm fuzzy feeling for CPUs past :3
<sb0>
I don't see why multiplexed SRAM/GPIO would be a problem
<sb0>
except that you can crash the CPU by connecting crap on the GPIO
<sb0>
and as far as migen/mibuild is concerned, just define a special set of pins for your board - you need a special core to handle the multiplexing anyway
<cr1901_modern>
Makes sense. And when I put LM32 on it, I can just make a board-specific wishbone bridge that controls the multiplexer based on address range.
<cr1901_modern>
GenericPlatform's constructor has arguments for io, and connectors. What is the main difference between them?
<ysionneau>
sb0: OK to mark anaconda as the preferred method only for linux-64? since we don't do regular builds for linux32 and win32
<sb0>
ysionneau, no, we should have build for all. just mention that the other ones may not be up to date.
<sb0>
*builds
<ysionneau>
we have builds but indeed they are not up to date
<ysionneau>
really too bad travis-ci does not allow windows / linux32 containers
<sb0>
of course, chinese vacuum pumps have no protection whatsoever against oil backflow
<sb0>
fortunately it made a funny noise and I could break the vacuum before it made a big mess
<cr1901_modern>
sb0: Does MiSoC (sic) have any examples of board-specific peripherals?
<cr1901_modern>
Because what I'm trying to make- a glorified mux- is unfortunately really only applicable to this board.
<sb0>
cr1901_modern, there is no difference between a board-specific and another peripheral.
<whitequark>
sb0: yeah
<whitequark>
recently dunked my turbo in oil as well
<whitequark>
thankfully the extent to which I did did not affect its performance
<whitequark>
I suggest getting an 1/4" NPT pneumatic valve with 220V rated coil at Amazon and fitting it instead
<whitequark>
or at least, 1/4" NPT is what's threaded in the case of my pump. naturally these valves go for way less than KF ones
<sb0>
I actually have a KF25 valve with a 220V coil, but it's at electrolab right now...
<cr1901_modern>
Awesome, that's what I needed to know. Thanks for the help.
<whitequark>
wow, I got /so/ ripped off on aliexpress
<whitequark>
bought three valves, each was shipped as if it weighs a kg. it weighs 100g at /most/
<whitequark>
$98 in shipping for less than a kilo, wtf
<whitequark>
the valves seem quite sweet though, decent build quality and such. they better be, $45 apiece
<sb0>
whitequark, i had a similar experience on ajvs.com. they compute shipping as if each item is shipped separately ...
<sb0>
I wish I knew about taobao then
<whitequark>
I'm just going to complain to the seller next time
<sb0>
oh, i complained. the answer was "this is just how we work".
<whitequark>
ahah
<sb0>
they also shipped me a non-working oil mist filter, which after a lot of arguing they accepted to repair, and then the German customs made me pay VAT a second time on it after a couple hours of queuing
<whitequark>
well, at least they released it at all.
<sb0>
vacuum work in the west is such a major pain in the ass compared to HK
<whitequark>
the US secondary market is sweet. but otherwise, yeah