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> Somebody emulated an ARM on an Atmega... oh nevermind, we're talking about the same thing
<whitequark> it would probably take decades to build libreoffice on that
mumptai has joined #m-labs
<cr1901_modern> I may have to build Firefox from source. Not looking forward to that.
<rjo> i was very proud when my first ardour builds on mips took 9h and succeeded.
<whitequark> huh, mips
<whitequark> my first and almost only mips system was a video ad distributed in a magazine locally
<whitequark> i.e. you crack the paper magazine open and it starts playing some 30-sec clip about vodka or something
<whitequark> naturally, i ported linux to it
<cr1901_modern> That sounds "fun".
<whitequark> nah, just a boring mips board
<whitequark> soldering wires for an SD card to the LQFP with 0.3mm spacing was the hardest part
<whitequark> but it's doable
<cr1901_modern> I can't solder SMD components. At all.
<cr1901_modern> which is something I'm constantly worrying about since I want to start using CPLDs on the PCBs I make
<cr1901_modern> Someone recently made their own BGA ARM board and ported Linux to it, and posted the results on Reddit. They say Linux isn't difficult to port, but the current documentation on how to do it sucks.
<whitequark> meh. use the source
<cr1901_modern> I'd probably lose my patience wondering why the CPU is crashing in the bootstrap code if I tried a port lol
<whitequark> so get JTAG
<cr1901_modern> I should feel bad (and do) for not knowing that.
<cr1901_modern> Interesting, according to a quick Google search, MIPS actually documents its JTAG extensions
<whitequark> ARM does
<whitequark> well, most vendors do, really
<cr1901_modern> Except FPGA vendors, apparently
<whitequark> they also do.
<whitequark> bitstream, not always, but JTAG? sure
<cr1901_modern> I'll look harder for Xilinx documentation tomorrow (fatigue is hitting hard), and keep what you say in mind.
<cr1901_modern> There's a project (not OpenOCD) that is trying to create a JTAG programming/debugging library. It attempts to abstract away the various cables and bitstreams using clean separate interfaces.
<cr1901_modern> And I can't remember the name of it for the life of me
<cr1901_modern> Ah well, I'll look for it tomorrow
ylamarre1 has quit [Quit: ylamarre1]
<GitHub37> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vmqam
<GitHub37> artiq/new-py2llvm f417ef3 whitequark: Make binop coercion look through CoerceT nodes....
<GitHub39> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vmqAV
<GitHub39> artiq/new-py2llvm bdcb241 whitequark: Add basic IR generator.
<whitequark> actually no... i'll have to expand most expressions at IR level
<whitequark> lambdas and comprehensions have scopes, calls have to be lowered to invoke instructions
<whitequark> thankfully that is not actually more work than doing it at the LLVM level. more class definitions, perhaps
<mithro> Has anyone worked on / thought about DDR3 on a Spartan 6? The misoclib/mem/sdram/phy/s6ddrphy.py has a "S6DDRPHY only supports DDR, LPDDR and DDR2" comment
<sb0_> mithro, I would not recommend it
<sb0_> DDR3 requires fast and precise timings that are not very compatible with the crappy spartan6 iodelays
<sb0_> use 7series if you need ddr3
<mithro> sb0_: It seems to be working fine with the Xilinx generated MCB thingy
<sb0_> yes, using undocumented features and gross hacks
<mithro> :-/ - I have a board with a Spartan 6 and DDR3
<mithro> sb0_: so, what would be your suggestion as the best way to move forward? Try to add similar hacks into the S6DDRPHY, wrap the Xilinx MCB?
<sb0_> depends on your patience :)
<sb0_> wrapping the xilinx mcb is probably faster and less painful, but dirty
<sb0_> rewriting it requires understanding a number of weird, obscure and most certainly buggy spartan6 details
<sb0_> do you absolutely need that board?
<mithro> sb0_: yeah - its the board I was showing the other day
<mithro> sb0_: when you say *requires* does that mean "actually required to make the ram function" or "required to get DDR3 throughput be better then DDR2"? IE Would "under clocking" the ram work?
<sb0_> no, it would not, DDR3s have DLLs that can only operate in a small frequency region
<sb0_> disabling the DLLs makes the RAM extremely slow
<sb0_> (10MHz or so)
<sb0_> DDR3 on Spartan-6 is stupid, it is not faster (as the FPGA IO rate is the limiting factor for DDR2 already) but it is more complicated
<cr1901_modern> felix_: I think that might've been it; I remember that one of the developers of the project I'm thinking of managed to reverse-engineer the Digilent/Xilinx cables.
<mithro> Anyone know if there is a way to use the Xilinx JTAG cable as a virtual UART for initial testing?
<sb0_> with misoc? you'd have to develop a "UART" that uses the bscan primitive on one end, and drivers on the PC side
Gurty has joined #m-labs
Gurty has joined #m-labs
<mithro> Gah, I don't really have a good location to attach a temporary UART on this board - both my USB->UART devices don't support 1.5V signalling levels :/
tija has joined #m-labs
<cr1901_modern> mithro: I think rjo has a project trying to do just that
<cr1901_modern> i.e. UART to JTAG bridge
<cr1901_modern> But he can explain it better than I could lol
<mithro> what would be the quickest way to get a misoc bios to just echo out "a" on the uart every second?
ylamarre has joined #m-labs
ylamarre has quit [Client Quit]
<cr1901_modern> Looks like they managed to create an RPi clone superior to the RPi
<mithro> sb0_: Is there a way for a platform to arguments to bitgen?
<mithro> sb0_: there seems to be a bitgen_opt on the ISEToolchain object - but not really any "correct" way to modify it?
<sb0_> mithro, see the code that Robert asked for a review about
<sb0_> ysionneau, why did you add a QSplitter to the parameters?
<ysionneau> hum I'm not sure why now... I must say I'm a bit noob with Qt so maybe it serves no purpose
<ysionneau> I must have thought it was necessary to add the search box
<sb0_> it's not. can you remove it?
<ysionneau> ok
<ysionneau> (I can't access Qt doc today, seems down)
<sb0_> works here and it's just removing the qsplitter and adding the grid directly to self
<mithro> sb0_: is there a way to just rerun the bitgen stage of build-bitstream thing?
<ysionneau> ok
<sb0_> mithro, no (unless you patch migen)
<GitHub4> [artiq] fallen pushed 1 new commit to master: http://git.io/vm3t2
<GitHub4> artiq/master 6e3fd59 Yann Sionneau: gui: remove unnecessary QSplitter
<ysionneau> done, sorry for the useless piece of code
<sb0_> btw have you confirmed with qt gurus that there is no simpler way of handling left click than what you did?
<ysionneau> I asked the question several times on #qt ... no one bothered answering me
<ysionneau> about the gui, I also have a commit on my "gui" branch about the statusbar
<ysionneau> it seems that if you want to have some message stay in the statusbar, you need to put a "permanentWidget" in it
<ysionneau> because the showMessage() is only for temporary stuff
<ysionneau> and there is no way IIRC to prevent the hovering from changing the temporary message
<ysionneau> whitequark: ok the linux-64 llvmlite package is fixed
<ysionneau> now it contains the .so statically linked with llvm
<ysionneau> so, now let's fix the llvmlite patch, to split it a bit
<sb0_> bah, override showMessage? :)
<ysionneau> ah yes why not :)
<ysionneau> I wanted to just let the normal usage intact
<ysionneau> we won't be using at all the "show temporary message" feature?
<sb0_> i don't think so
<ysionneau> sb0_: I forced push this change (tested, it works) and took into account your comments on github
<mithro> gah, why won't this friken pin toggle :(
_florent_ has joined #m-labs
<sb0_> ysionneau, the text justification is wrong. it's shown on the right now...
<sb0_> and yes, GUI design is a royal PITA
<ysionneau> well, yes the position of the permanentWidget seems to be on the right
<ysionneau> not sure if I can change that
<GitHub187> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vm3R5
<GitHub187> artiq/master 84e7f55 Sebastien Bourdeauducq: gui: fix DDS class recognition
<GitHub187> artiq/master 1edeb5a Sebastien Bourdeauducq: sync_struct: docstring cleanup
<GitHub187> artiq/master 55cd414 Sebastien Bourdeauducq: gui/DictSync: better support of nested structs
<sb0_> not "seems". it is.
20WABOQAL has joined #m-labs
<20WABOQAL> m-labs/artiq#305 (master - 6e3fd59 : Yann Sionneau): The build is still failing.
20WABOQAL has left #m-labs [#m-labs]
<ysionneau> hu, weird nick
<ysionneau> rhaa, llvmlite issue
<ysionneau> ah I didn't test the py2llvm one ... only transform
<ysionneau> ah, I guess that's because I only build with target OR1K, so native target is not available
<GitHub180> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vm3Kh
<GitHub180> misoc/master 35250f5 Florent Kermarrec: bios: add romboot...
<ysionneau> the dlopen("libgcc_s.so") gives an OSError No such file or directory on my Deban Jessie x86 :o
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#306 (master - 21e8596 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<ysionneau> seems a bit weird to package the native target, only for one test to work
<whitequark> disable the test
ylamarre has joined #m-labs
<ysionneau> sb0_: OK to commit that: http://pastebin.com/7aygUCYt ?
tija has quit [Quit: Connection closed for inactivity]
<sb0_> meh
<sb0_> stekern_, why is or1k not merged upstream llvm?
<sb0_> that would have avoided all that drama
<sb0_> ysionneau, we want the tests to work easily, and disk space is cheap, so package the native target.
<ysionneau> all right
<sb0_> ysionneau, have you found a way to get the column widths to behave?
<sb0_> this is one of the most irritating gui quirks right now
<ysionneau> I didn't have a look at this item yet,
<ysionneau> which columns are you talking about?
<sb0_> e.g. the scheduler columns look like crap by default
<ysionneau> ah ok there is unused space?
<ysionneau> the QTableView does not take all available space
<sb0_> everything is wrong about them
<sb0_> unused space, no space for te text that needs it
<sb0_> *the
<sb0_> god is gui design annoying
<ysionneau> yes :/
<ysionneau> here is what I get: https://framapic.org/OCKUtWs9gH9B/xitG1fW1
<ysionneau> so at least I can read the column headers
<ysionneau> but still it does not take all available space
<sb0_> set a larger font/higher screen dpi and it will break
<ysionneau> arg
* ysionneau is not high dpi
<sb0_> more llvmlite drama coming https://github.com/m-labs/artiq/issues/70
<ysionneau> damn it, too many issues
<stekern_> sb0_: because llvm needs/requires a maintainer committed "full-time" to llvm work before they accept any ports upstream
<whitequark> "full-time" is a bit of exaggeration, but the bottom line is, breakage must be promptly fixed, and refactoring will generally be made without regards to the specific needs of your target
<GitHub65> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vms37
<GitHub65> artiq/master e20b260 Sebastien Bourdeauducq: gui: fix selections
<ysionneau> got to go
_florent_ has quit [Quit: Leaving]
<GitHub69> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/vmsc7
<GitHub69> migen/master ea8ffd8 Sebastien Bourdeauducq: platforms/kc705: style
<GitHub69> migen/master e56d80c numato: Adding support for Numato Lab Mimas V2 platform
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#55 (master - e56d80c : numato): The build passed.
travis-ci has left #m-labs [#m-labs]
<GitHub142> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vmsRc
<GitHub142> migen/master 52bdc29 Sebastien Bourdeauducq: mimasv2: style, consistency with other boards
<rjo> stekern_: what could be done to get to full-time support (or at the level whitequark defines it)? can we pool together (the ones commercially backing and using or1k) to do that?
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#56 (master - 52bdc29 : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#307 (master - e20b260 : Sebastien Bourdeauducq): The build is still failing.
travis-ci has left #m-labs [#m-labs]
<whitequark> rjo: there are no formal requirements to that
<whitequark> you can go and ask the core team to accept the merge of OR1K. be responsive enough during and after that.
<whitequark> if you abandon it, it'll get removed eventually. that is all
attie_ has joined #m-labs
kristian1aul has joined #m-labs
mumptai has quit [*.net *.split]
attie has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
aeris has quit [*.net *.split]
mithro has quit [*.net *.split]
aeris has joined #m-labs
ylamarre has quit [Quit: ylamarre]
ylamarre has joined #m-labs
attie_ is now known as attie
ylamarre1 has joined #m-labs
ylamarre has quit [Ping timeout: 265 seconds]
<GitHub68> [migen] jordens pushed 1 new commit to master: http://git.io/vms5y
<GitHub68> migen/master 6468fa3 Robert Jordens: xilinx: ensure we chdir() back after build
<rjo> whitequark: i know. i want to get that done.
<whitequark> rjo: ok. I can work on that once I finish the new py2llvm
<whitequark> already an LLVM committer, etc
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#57 (master - 6468fa3 : Robert Jordens): The build passed.
travis-ci has left #m-labs [#m-labs]
<rjo> fwiw m-labs/m-labs should not need to carry the entire load.
<whitequark> hm?
<rjo> well. if we can get other commercial users backers of or1k to chip in, you have more time to work on artiq!
* rjo has ise chugging away building 120 bscan_spi bitstreams.
<whitequark> ah, true
<whitequark> are there commercial users of or1k?
<sb0_> I assume that risc-v still sucks?
<sb0_> not upstream either. ha.
<sb0_> plus as i mentioned before, pick a kc705-sized cpu core or CPI >3. "we are, however, Berkeley" ...
<whitequark> is the pipelined verison so large or what?
<sb0_> yeah. and just pipelined, not even OOO
<sb0_> the CPI >3 version is a stupid fsm-based design that the author still managed to get larger than lm32
<whitequark> what do you think of lowrisc
<sb0_> that you put it through a synthesizer and it does not work?
<whitequark> harsh
<sb0_> and well, sure you can make CPI >3 FSM toy implementations or experiment with architectures that bloat the design to the extreme, but risc-v has zero usable implementation right now
<sb0_> though everyone likes to boast on the mailing list on how good their design is which will be released "soon"
<sb0_> smells like a nasty mix of opencores and academia
<whitequark> hah
mumptai has joined #m-labs
mithro has joined #m-labs
<GitHub179> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vmGpL
<GitHub179> migen/master 09b3334 numato: Removed drive strength constraints on VGA/Audio signals
ylamarre1 has quit [Quit: ylamarre1]
mumptai has quit [Quit: Verlassend]