00:02 <cr1901_modern> Very old Digilent Spartan3 board which I don't use, Altera board that's not mine/need to give back, and http://www.micro-nova.com/mercury/, the 200k model

00:03 <cr1901_modern> I mainly have it b/c of all the 5V tolerant I/O

00:04 <cr1901_modern> If I were to get another one, I'd probably get miniSpartan6

00:04 <_florent_> if you get one, choose the LX25 version

00:06 <cr1901_modern> Yea, that seems to be the best choice. Would have to add the support to Migen though (seems only lx9 is supported)

00:07 <_florent_> no, both are supported

00:07 <cr1901_modern> oh, well that makes my life easier.

00:08 <cr1901_modern> I suppose the default device just targets the lx9 version

00:08 <_florent_> yes but you can change that with -Op device xc6slx25 IIRC

00:09 <_florent_> but the DRAM is not fast enough on this board to do interesting things with the hdmi ports

00:09 <cr1901_modern> Define "interesting"... is it enough to do 30fps video?

00:12 <_florent_> depends what you want to do

00:12 <_florent_> you will be able to write and read a 1024x768@30fps to/from the DDR, not more

00:12 <_florent_> (or not a lot more)

00:13 <_florent_> DDR/SDR...

00:14 <cr1901_modern> Although that is technically enough for my intended usage for anything video related, that's still... ouch

00:14 <cr1901_modern> sounds like a design decision that wasn't thought through

00:16 <_florent_> that's often the case with small FPGA boards

00:16 <_florent_> don't know what you are going to do with a spartan6 LX9 and hdmi ports...

00:17 <_florent_> do a loopback... :)

00:18 <_florent_> time to sleep, bye

00:18 <cr1901_modern> later

00:18 <cr1901_modern> HDMI on FPGA == premium price

07:06 <mithro> cr1901_modern: You should get an Opsis board :P

07:06 <mithro> cr1901_modern: or if you do a bunch of work on the HDMI2USB.tv firmware, you might find you get sent an Opsis board for free :P

07:07 <cr1901_modern> Why do I sense subliminal advertising?

07:08 <mithro> cr1901_modern: its not subliminal if I outright tell you to buy something :P

07:09 <cr1901_modern> It's out of my price range for now, unfortunately. And while doing HDMI work sounds appealing, I'm not in a positing to start doing that right now

07:14 <mithro> cr1901_modern: no worries, but if you do end up with time and want to work on it there are plenty of tasks, specially for someone who knows migen :)

07:15 <cr1901_modern> Noted, especially since doing an HDMI controller is a bucket list idea

15:17 <GitHub83> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/vZYl5

15:17 <GitHub83> misoc/master 12f5858 Tim 'mithro' Ansell: Allow installing tools to a prefix....

17:00 <rjo> sb0_: yes. there is a one liner for misoc that uses get_constants().

17:01 <rjo> sb0_: operators and eq don't do any checking or mangling or their arguments so far. doing it for constants would be inconsistent.

17:03 <rjo> sb0_: having CSRConstant inherit from Constant seemed natural. it also makes swapping real python variables and CSRconstants possible. I would consider having CSRStatus and Storage inherit from Signal as well and then have self be storage/status

17:04 <rjo> ... while stuff is being rewritten.

17:07 <rjo> and something that regularly bothers me about CSR: there is "atomic_write" (write form the bus/cpu perspective) but "w", "r", "we", and "re" are from the gateware perspective. The orientation of the later seems the wrong one to me.

17:22 <rjo> afaict reads and writes are usually from the perspective of the initiator of the transaction. and since the csr-holding gateware is not the bus master, r/w should be flipped.

17:26 <_florent_> rjo: I agree on that (even if that's not problematic, the orientation is not natural for me)

18:13 <sb0__> can you file an issue?

18:14 <sb0__> i'm working on migen new-branch now, will get to misoc later after I'm done with it (including the new simulator)

18:15 <sb0__> now is a good time for breaking Migen APIs, btw

18:17 <sb0__> _florent_, what's this? https://github.com/m-labs/migen/blob/master/mibuild/sim/verilator.py#L126

18:17 <sb0__> sim_path ...

19:59 <mithro> ysionneau: You were doing conda stuff right?

19:59 <ysionneau> yes

19:59 <ysionneau> I'm packaging artiq + its dependencies using conda

20:00 <mithro> ysionneau: so you have conda packages for gcc-lm32 and binutils-lm32?

20:01 <ysionneau> for artiq we use mor1kx and not lm32

20:01 <ysionneau> (misoc can use either one or the other, you can chose with a cmd line switch)

20:01 <mithro> ysionneau: ahh - how hard would it be to do lm32 conda packages?

20:01 <ysionneau> but we packaged binutils-or1k yes

20:01 <ysionneau> for linux packages very easy I would say

20:01 <ysionneau> it's just a build.sh

20:01 <ysionneau> so you just put the configure make make install in a build.sh

20:02 <ysionneau> plus your patches

20:02 <ysionneau> and voila

20:02 <mithro> well, I have zero patches :P

20:02 <ysionneau> too easy then ;)

20:02 <ysionneau> https://github.com/m-labs/artiq/blob/master/conda/binutils-or1k-linux/build.sh

20:02 <ysionneau> for instance

20:03 <mithro> ysionneau: what would you recommend for "getting started with conda" for something like artiq packaging?

20:04 <ysionneau> the official conda documentation is pretty OK

20:04 <ysionneau> http://conda.pydata.org/docs/building/build.html

20:06 <ysionneau> the getting started for users is there: http://conda.pydata.org/docs/get-started.html (my previous link was about building+creating your own packages)

20:14 <mithro> ysionneau: thanks - I'll give it a go

20:14 <ysionneau> don't hesitate if you have any question

20:19 <mithro> ysionneau: does it make sense we should just be building binutils/gcc at the misoc rather then artiq/hdmi2usb level?

20:20 <ysionneau> not sure what you mean by "at the XX level"

20:20 <ysionneau> if there is no software to build in hdmi2usb then you don't need binutils/gcc as a dependency

20:21 <ysionneau> and indeed you need those to build the bios in miso

20:21 <ysionneau> misoc*

20:21 <ysionneau> for artiq, there is a payload (runtime) which needs binutils/clang

20:22 <ysionneau> why are you talking about artiq may I ask? Will you use artiq? :o

20:23 <mithro> ysionneau: because artiq already has the CI stuff set up we want for HDMI2USB too :)

20:28 <ysionneau> hehe

20:33 <mithro> ysionneau: you don't use gcc for artiq?

20:42 <mithro> ysionneau: are you suppose to bump the build: number on every build too?

20:43 <ysionneau> clang is used to build misoc bios (at least in artiq project)

20:44 <ysionneau> the makefile allows using either clang or gcc

20:45 <mithro> ysionneau: interesting - didn't know you could do clang building of your misoc code

20:47 <ysionneau> actually, we use clang for or1k and gcc for lm32 : https://github.com/m-labs/misoc/blob/master/misoclib/soc/cpuif.py#L5

20:48 <ysionneau> https://github.com/m-labs/misoc/blob/master/software/common.mak#L7

20:49 <ysionneau> first link generates a makefile (which is included), second link is the makefile which tests for CLANG variable value and uses one compiler or the other, according to CLANG value

21:56 <ysionneau> gn8!

21:59 <_florent_> sb0: about sim_path is used to know where we can find the dut_tb.cpp template

22:00 <_florent_> I don't know if it's possible to package this file directly with migen?

22:53 <mithro> ysionneau: I don't really understand how conda handles build-dependencies? You put things in "build:" section but it still seems to be using your system environment and mangling it somehow....

22:54 <mithro> ysionneau: the exact same commands which work outside conda are dieing with;

22:54 <mithro> checking for x86_64-unknown-linux-gnu-gcc... /home/tansell/conda/conda-bld/work/gcc-4.9.3/build/./gcc/xgcc -B/home/tansell/conda/conda-bld/work/gcc-4.9.3/build/./gcc/ -B/x86_64-unknown-linux-gnu/bin/ -B/x86_64-unknown-linux-gnu/lib/ -isystem /x86_64-unknown-linux-gnu/include -isystem /x86_64-unknown-linux-gnu/sys-include