<ysionneau>
just clone misoc and then do "git submodule update --init"
<kristianpaul>
ah...
<ysionneau>
it will clone the dependencies
<kristianpaul>
:okay:
<kristianpaul>
lol i had manually pulled lm32 :/
<ysionneau>
lm32 is also a submodule yes :)
<ysionneau>
submodule are useful to "freeze"/track the version of your dependencies
<ysionneau>
mor1kx is a submodule also
<ysionneau>
(misoc supports mor1kx also, I don't know if you are aware of that)
<kristianpaul>
I do remenber something, dint knew mor1kx was finally merged
<kristianpaul>
interesting
<kristianpaul>
any advantajes over lm32?
<ysionneau>
a bit more performance
<ysionneau>
at the cost of being much much bigger (in term of FPGA resources)
<ysionneau>
a bit less than 4 times bigger I think(??)
<ysionneau>
17:05 < kristianpaul> any advantajes over lm32? < plus stronger/better software support (toolchains gcc, llvm, binutils, linux port, working mmu)
<kristianpaul>
yeah
<kristianpaul>
toolchain is a plus
<ysionneau>
a very big plus
<kristianpaul>
but does linux runs on misoc using mor1kx?
<ysionneau>
I don't think anyone did the work to have it working
<ysionneau>
but it would be a matter of having misoc uart work in the mor1kx linux port
<ysionneau>
(which is using device tree afaik)
<kristianpaul>
misoc uart is the same uart from legacy m1?
<ysionneau>
no, it has been rewritten, it's in Migen (python) now
<ysionneau>
but the sw interface (memory mapped registers) are very similar if not the same
_florent_ has joined #m-labs
<ysionneau>
except the extra baudrate frequency tuning word
<kristianpaul>
alright, need to read a bit about misoc
<ysionneau>
go ahead, don't hesitate to ask :)
<kristianpaul>
will not
<kristianpaul>
yo know me lol
<ysionneau>
;)
<kristianpaul>
ISE should be fine right?
<kristianpaul>
i got 14.6 installed
<sb0>
ysionneau, performance is the same, it's 2x larger than lm32, the isa is messy. the only advantage is there is a decent llvm backend.
<_florent_>
hi and happy new year everyone
<_florent_>
last time I've done a comparison it got between LM32 and mor1kx I got:
<_florent_>
LM32: 2514 regs / 3068 luts
<_florent_>
mor1kx: 2771 regs / 3828 luts
<_florent_>
so it's only ~ +250 regs / +750 luts
<_florent_>
(with the same functionnalities, ie no store buffer)
<kristianpaul>
just llvm is decent? though gcc was aceptable as well.. :(
<ysionneau>
lm32 is supported by gcc 4.9 now, but I had some issues to compile it a while back but I didn't try so hard so it might be an issue on my side
<ysionneau>
happy new year _florent_ :)
<_florent_>
thanks
<ysionneau>
kristianpaul: ISE 14.6 is fine (I'm using 14.7)
<sb0>
_florent_, I get more like 1500 LUTs for lm32
<kristianpaul>
Feliz año _florent_
<kristianpaul>
:D
<_florent_>
sb0: IIRC store buffer is not disabled for mor1kx in misoc and the lm32 does not implement it
<_florent_>
disabling it give more than 500 luts IIRC
sb0 has quit [Quit: Leaving]
<ysionneau>
ok so pylibnidaqmx seems to be unusable as-is since it uses the nidaqmx API and not the nidaqmxBase one
<ysionneau>
and I've read that the old nidaqmx does not work anymore on recent distributions
<ysionneau>
and so far I have some troubles with pydaqmx as soon as I import it in my python interpreter that I'm investigating
<ysionneau>
that seems to be an error upon loading a shared library with CDLL
<ysionneau>
hum , stracing python shows that those error messages are printed upon a failed open('/dev/nipalk')
<ysionneau>
which might just be because I just don't have the HW yet :)
<ysionneau>
so let's keep faith in pydaqmx!
<ysionneau>
win 68
<rjo>
ysionneau: are there binary only kernel modules? or do they do binary-blob + shim?
<ysionneau>
I haven't looked at what they provide exactly yet
<ysionneau>
but since it asks for kernel sources+headers to be installed, I guess it's some binary + wrapper
<ysionneau>
and you just compile the wrapper against your kernel tree
<rjo>
10:03 < ysionneau> ok so pylibnidaqmx seems to be unusable as-is since it uses the nidaqmx API
<rjo>
you mean pylibnidaqmx uses nidaqmxbase?
<ysionneau>
pylibnidaqmx uses libnidaqmx which is the old library
<ysionneau>
the new one is libnidaqmxbase
<ysionneau>
and the function name changed also (there is 'Base' in the name now)
<ysionneau>
names*
<rjo>
making py*nidaqmx* portable win/lin might be harder than two implementations, one for nidaqmx/win and the other for comedi/lin
<rjo>
so the *base is newer? weird.
<ysionneau>
that's what I understood
<rjo>
is there an *Advanced as well?
<ysionneau>
there is ni-DAQmx and ni-DAQmxBase
<ysionneau>
the ni-DAQmx does not work anymore on newer linux distros (I didn't test, but I read that)
<rjo>
i see.
<ysionneau>
so for modern Linux you are stuck with ni-DAQmxBase
<ysionneau>
(14.0)
<ysionneau>
same for Mac OS
<ysionneau>
but we don't care
<ysionneau>
problem is pylibnidaqmx was designed to interface with the non-base stuff
<ysionneau>
it can maybe be hacked into interfacing with the base one
<ysionneau>
but it does not seem trivial, because some function does not seem to exist in the -base
<ysionneau>
it's not just a rename of functions with 'Base' in the names
<ysionneau>
19:03 < rjo> making py*nidaqmx* portable win/lin might be harder than two implementations < well, it seems pylibnidaqmx supports both Windows and Linux
<ysionneau>
but maybe it's broken as well on Windows? I don't know