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
<GitHub138>
[artiq] sbourdeauducq closed pull request #109: new ddb.pyon argument comment; use to put labels in GUI for TTL and DDS (master...master) http://git.io/vsdQP
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
<sb0>
ysionneau, have you fixed the windows failing tests?
kristianpaul has quit [Remote host closed the connection]
<GitHub60>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vsFbd
<whitequark>
^ no attributes yet, will push in a moment
<cr1901_modern>
I wonder if there's a good open alternative to PicoBlaze...
fengling has quit [Read error: Connection reset by peer]
fengling has joined #m-labs
<sb0>
cr1901_modern, unless you are using a particularly small fpga, lm32 should fit
<sb0>
there's also lm8, but the compiler looked bad last time I checked, and I'm unsure of the license
<sb0>
and there's my avr clone "navre" in milkymist/softusb
fengling_ has joined #m-labs
fengling has quit [Ping timeout: 245 seconds]
aeris_ has joined #m-labs
<GitHub45>
[artiq] fallen pushed 1 new commit to master: http://git.io/vsb9x
<GitHub45>
artiq/master 92390cf Yann Sionneau: py2llvm: allow the unit test to run on Windows
kyak has quit [Ping timeout: 260 seconds]
FabM has quit [Remote host closed the connection]
FabM has joined #m-labs
<cr1901_modern>
sb0: lm32 will work, but I REALLY need to trim it for this project. Does MiSoC provide a way to update lm32's config file programmatically, or will I need to supply my own cfg file?
<cr1901_modern>
Note that lm32, with its default settings does not fit on a XCS3200 (target FPGA)
<sb0>
it doesn't. a problem with lm32 is its preprocessor-based config makes it hard to configure.
<cr1901_modern>
What's the problem with using Python to spit out a config file with the proper directives before calling build()?
<cr1901_modern>
(Yes, am willing to implement this if doable)
<sb0>
multiple cpus, integration with mibuild, hacks, etc.
<sb0>
well tested support on altera/xilinx/lattice
<sb0>
(not that we have good tests right now, but the more complexity, the more bugs)
<cr1901_modern>
point taken with the multiple CPUs. I presume by integration with mibuild, you mean "the default config provided in MiSoC will work for most FPGAs"?
<cr1901_modern>
"Alter it yourself if it doesn't."
<sb0>
cr1901_modern, the default config is good enough for the projects I'm working on
<sb0>
cr1901_modern, if you are willing to do extensive testing, you may change that.
<sb0>
the perfect solution though, would be to get rid of the lm32 verilog and rewrite it with migen
<cr1901_modern>
sb0: well, yes. Or create a new compatible CPU so some poor bastard doesn't have to port GCC and LLVM
<sb0>
i'd recommend following closely the lm32 verilog implementation. this is the most efficient softcore I know, even compared to proprietary ones
<sb0>
most open CPU projects produce unusable/slow/bloated cores, see risc-v (they might have a decent one since recently, though)
<cr1901_modern>
yes, I'm aware how you feel about risc-v :P
<cr1901_modern>
I bring up changing LM32 b/c I wanted to add a miniature configuration for smaller projects. LM32 in a microcontroller configuration. Remove certain things like cache and maybe the barrel shift or multiplier (log(n) software multiplication)
<ysionneau>
whitequark There is *one* testcase failing in py2llvm.py on Windows, could you have a look? http://pastebin.com/4TWJ3TH5
<ysionneau>
I printed the LLVM IR and did a side-by-side comparison between Linux (OK) and Windows (KO) and it's the same
<ysionneau>
I guess the issue is in the backend?
<ysionneau>
FYI the number returned by is_prime_c() changes each time I run the unit test
<ysionneau>
I wanted to print the generated target assembly but I didn't understand how to do it
<GitHub80>
[artiq] fallen pushed 1 new commit to master: http://git.io/vsNyv
<GitHub80>
artiq/master 7b0b1d6 Yann Sionneau: manual: Windows (32 and 64-bit) users should install 32-bit miniconda/anaconda
<whitequark>
ysionneau: that means UB is invoked
<whitequark>
... hm
<whitequark>
no, nevermind, wrong conclusion
<whitequark>
it looks more like an ABI mismatch
<whitequark>
ysionneau: in either case it doesn't matter, we don't JIT anything. comment it out or ignore in any other way. spending time on it is pointless.
ylamarre has joined #m-labs
<ysionneau>
ok I can just skip the test on Windows then
ylamarre has quit [Client Quit]
ylamarre has joined #m-labs
<whitequark>
yes
<GitHub193>
[artiq] sbourdeauducq pushed 5 new commits to master: http://git.io/vsNFT
<GitHub193>
artiq/master b790fb0 Joe Britton: add ping() to novatech driver
<sb0>
ysionneau, why is that one test failing on windows? do the other ones work?
<ysionneau>
the other ones work
<ysionneau>
and I have really no idea
<ysionneau>
whitequark: do you have any idea why only this particular one would fail?
<ysionneau>
I think one would need to compare the generated assembly code to understand
<sb0>
ysionneau, the other problem is switching the asyncio event loop to proactor like on the master, which should be trivial
<ysionneau>
yes, I'll fix that also
<ysionneau>
right now I'm refactoring the asyncio patch
<mumptai>
has there been effort spend to add a vhdl back-end to migen?
<sb0>
yeah, look for peteut on github. his backend is incomplete and lousy with bugs though
<mumptai>
i'll have a look
<mumptai>
is the cause of the trouble inherent to migen, or more the branches implementation?
<mumptai>
ah, found the branch, 3 years old
ylamarre has quit [Quit: ylamarre]
<whitequark>
ysionneau: reasonably certain the code is invoked incorrectly
<whitequark>
like it's a ctypes issue
<ysionneau>
so it means it works "by chance" on linux?
<whitequark>
no, more like the other tests work "by chance" on windows
<whitequark>
JIT on linux is solid, if it weren't, numpy and artiq alike would fail in bizarre ways
<ysionneau>
So either we fix this, which ... we don't need for the project (do we?) or we skip entirely all py2llvm tests for Windows?
<whitequark>
well, if someone wants to run ARTIQ tests on Windows, that might be a problem
<ysionneau>
yes, I'm just wondering if testing py2llvm on Windows is really interesting, compared to testing on Linux
<ysionneau>
since it should really work the same way on both
fengling_ has quit [Ping timeout: 245 seconds]
_florent_ has joined #m-labs
<cr1901_modern>
_florent_: You and sb0 worked on this, so hopefully one of you has an answer >>
<cr1901_modern>
I'm trying to use the AutoCSR class right now. From reading the code for AutoCSR, it appears only attributes of the class that inherits from AutoCSR are considered for candidates to have a get_csr method. Is this correct?
<cr1901_modern>
Damnit, I messed up my description... h/o :/
<_florent_>
hmm, that's probably better to declare your csrbankarray in a that instanciates YMScope and not at the same level
<_florent_>
in a class
<cr1901_modern>
Actually, I was wrong. SoC does NOT inherit from AutoCSR
<cr1901_modern>
LiteScope however, does inherit from both SoC and AutoCSR
<cr1901_modern>
(And yes, you're probably right. I'm just confused by the behavior I'm seeing)
<cr1901_modern>
when LiteScope's do_finalize method, inherited from SoC, is called, I suspect that thee get_csrs method that LiteScope inherited from AutoCSR won't actually be called. Let's find out
<_florent_>
AutoCSR inheritance in Litescope is in fact not needed, I'm cleaning this
<cr1901_modern>
Can confirm :P. Now my question is: was BankArray meant to check whether the object passed in has a get_csrs function and doesn't anymore, and now only checks whether it attributes have a get_csrs method
<cr1901_modern>
or you thought AutoCSR would be needed for something else, but doesn't
<_florent_>
don't remember exactly
ylamarre has joined #m-labs
<GitHub176>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vspAN
<GitHub176>
misoc/master a4808ac Florent Kermarrec: litecores: remove unneeded AutoCSR inheritance in example designs (thanks William D. Jones)