lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
balrog has joined #m-labs
zumbi has quit [Ping timeout: 248 seconds]
zumbi has joined #m-labs
kmehall has quit [Ping timeout: 276 seconds]
kmehall has joined #m-labs
sh4rm4 has quit [Ping timeout: 252 seconds]
ohama has quit [Read error: Operation timed out]
ohama has joined #m-labs
xiangfu has joined #m-labs
lekernel has joined #m-labs
ohama has quit [Read error: Operation timed out]
ohama has joined #m-labs
<stekern> lekernel: the sluggishness you are referring to is bound to one of the openrisc implementations (or1200). fwiw, the 6-stage pipelined mor1kx cappuccino outperforms lm32 in the coremark testbench (but lm32 is still smaller).
<lekernel> how big is mor1kx?
<stekern> ...and it's not by huge numbers it outperforms it
<stekern> I don't have any numbers with me here, but it's not very small. Smaller than or1200 though.
sh4rm4 has joined #m-labs
<lekernel> yeah, but or1200 is super-bloated :-)
<lekernel> let me check ...
<lekernel> 3200 LUTs...
<lekernel> and 75MHz
<lekernel> LM32 is 2400 LUTs and 83MHz
<lekernel> the 75MHz is more of a problem, since it's going to slow down the complete system (SDRAM controller, DMA peripherals, etc.)
<lekernel> and clock domain transfers introduce latency (and complexity) and further kill the CPU performance
<lekernel> so, LM32 is still better :)
<stekern> 75MHz is with the MMU, there is a critical path going through that that needs untangling
<stekern> I've ran it at 83Mhz in the legacy milkymist soc without mmu
<stekern> but LM32 is a good implementation, I'm not going to deny that ;)
<stekern> I just wanted to point out that we have made progress and there's more to openrisc than or1200 nowadays
<stekern> correctiion, it was in milkymist-ng I ran it at 83MHz
playthatbeat has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
playthatbeat has joined #m-labs
playthatbeat has quit [Remote host closed the connection]
<lekernel> hmm, that was without MMU, but I didn't try to play with the timing constraints
playthatbeat has joined #m-labs
playthatbeat has quit [Remote host closed the connection]
playthatbeat has joined #m-labs
playthatbeat has quit [Client Quit]
playthatbeat has joined #m-labs
<stekern> ah, ok you did some tests of your own. Admittedly, the 83Mhz result I got was a while ago: https://github.com/skristiansson/milkymist-ng-mor1kx
playthatbeat has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
<lekernel> but good to see it's making progress. I won't make compromises on speed, but if it can be brought within ~15% of the LM32 area and has excellent software support, I will consider switching.
lekernel has quit [Ping timeout: 252 seconds]
lekernel has joined #m-labs
playthatbeat has joined #m-labs
<ysionneau> software support is an incredible pain to do
<ysionneau> hacking on libc ... gcc ... binutils gdb etc is incredibly time consuming
<ysionneau> so indeed if openrisc keeps improving perf and diminish bloatness, then switching to it would be very good :)
<stekern> painful and time consuming, but fun ;)
<ysionneau> hehe yes
<ysionneau> I would very much like to improve my skills in this domain
<ysionneau> but the fact that it takes time is really, if not a stopper, a big "slower"
<ysionneau> I find it hard to make progress when I don't have 2 or 3 hours straight
<ysionneau> but with usual daywork, I don't have 3 hours straight in the evening when back home
<ysionneau> so I make very very few progress in my personal projects involving toolchain stuff, libc, netbsd kernel etc
<ysionneau> the good thing is that since the 1st of january my dayjob involves such low level software hacking :)
<stekern> I don't know, I find you usually make most progress when you don't sit in front of the computer
<stekern> or most of the break-throughs are made away from it
<stekern> ... and yeah, I saw that, congrats ysionneau! =)
<ysionneau> thanks :)
<ysionneau> 14:21 < stekern> I don't know, I find you usually make most progress when you don't sit in front of the computer < you mean by reading books? Attending to conferences? talking to other developers?
<kristianpaul> Geting inspired i bet ;)
<ysionneau> smoking pot ? :p
<ysionneau> no seriously it's a real question, usually I make progress by reading the code and trying to understand how it works
<ysionneau> so it involves a lot of vim+grep -R
<ysionneau> but it's usually ... in front of the computer :)
<larsc> If I can't make any progress I just switch to a different project
<ysionneau> that's what I end up doing usually
<larsc> then a couple of months later the solution hits me
<kristianpaul> ysionneau: i was talking seriouslly, as larsc said, some things just get you hired after a bit. Something dont have in front of the computer usually
<ysionneau> I don't understand what you mean
<larsc> the eureka moment
<ysionneau> ah I was understanding "getting hired" like "a company hires you"
<ysionneau> ok got it :)
<larsc> s/hired/hits/
<ysionneau> I agree that sometimes the solution of a problem you are trying to solve comes while thinking about it
<ysionneau> but I meant that sometimes you don't even have the time to get the "big picture" about some piece of code
<ysionneau> then if you didn't even have the time to "enter" the code's logic, then you can't "think about" the problem while not being in front of a computer
<ysionneau> you just don't have the problem in head
<ysionneau> you don't even have the piece of code in head
<ysionneau> you need at least to spend these hours straight to enter the problem
<ysionneau> and past that, then you can think about it "offline"
kristianpaul has quit [Quit: leaving]
kristianpaul has joined #m-labs
<stekern> ysionneau: no, I mean that most solutions come to you when you are doing other normal stuff, like sitting on the bus, putting dishes into the dishwasher, taking the kids to fotball practice, that sort of things ;)
<stekern> but I agree, you have to have a problem to solve a problem
<ysionneau> ok I think we both agree about both of those things then :)
<larsc> just got a SOCFPGA board, lets see how that compares to ZYNQ
<ysionneau> Altera stuff ?
<larsc> yes
<ysionneau> nice :)
* ysionneau has a DE3 near his desk at the office
<larsc> it's probably not that different than the ZYNQ, both use a dual core cortex a9
<larsc> I just hope they don't have a hardware AXI to $ALTERA_BUS bridge
<ysionneau> you want to implement AXI bus yourself then ?
<ysionneau> I guess if then did such a bridge then let the user bypass it and talk directly to AXI
<ysionneau> I hope :)
<ysionneau> then they*
<larsc> Xilinx uses the AXI bus and all my cores have a AXI interface
<lekernel> larsc, how's the mixxeo?
<larsc> lekernel: hadn't had too much time to play with it yet
<lekernel> but the proprietary altera cpu, yes :)
<larsc> I'm paid for that
<lekernel> well, I have a couple customers who use misoc/lm32. wouldn't be possible for you?
<larsc> maybe
<lekernel> you know, even opencores managed to sell or1200, so you're brave enough for that
<larsc> I'm not a sales person ;)
<stekern> larsc: it's AXI, all bus conversions to avalon are "soft"
<larsc> good
xiangfu has quit [Remote host closed the connection]
<larsc> lekernel: I guess one day when I have enough financial saftey I'll take a year off and see what can be done with opensource HDL development
<lekernel> you can also argue with your boss
<lekernel> instead of just using whatever ARM chip they suggest
<larsc> no ;)
<larsc> It might make sense to use lm32 as a replacement for nios or microblaze
<larsc> but not for a dual core ARM running at 1GHz
<lekernel> depends on the software
<larsc> yep
<ysionneau> my company uses 3 lm32 as co-processors for LTE, but indeed we would not replace out current ARMs ou MIPSs by lm32
<ysionneau> "my"
<lekernel> yeah well, there can be lots of reasons for that, for example when you buy a PC it still uses one of the shittiest architectures ever (x86) and ARM, while technically better, is only used on a minority of netbooks today
mrueg has quit [Remote host closed the connection]
mrueg has joined #m-labs
<larsc> stekern: do you know the SOCFPGA well? Do you know if there is some kind of hardmacro DMA?
<larsc> ah, the pl330, how convenient, the same as in the ZYNQ
Alarm has joined #m-labs
<kristianpaul> ysionneau: 3 !
<kristianpaul> perhaps if lm32 have instructions for easy DSP this will be different.. or..
<stekern> larsc: I know it fairly well, I haven't explored the ARM side of it _that_ much though, but it's a pretty complete SoC
<stekern> I got mine at one of those $99 workshops arrow arranged, so I've felt obligated to play with it to some extent at least. I threw in an openrisc cpu, built a synthesizer and used the ARMs to run Linux and act as a usb-midi gadget
<stekern> now, that's what those 1GHz ARM cores are built for ;)
Alarm has quit [Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]]
<GitHub133> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/kmnPjw
<GitHub133> migen/master 90f0dfa Sebastien Bourdeauducq: Add 'passive' simulation functions that are not taken into account while determining when to stop the simulator
<GitHub41> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/21QM9A
<GitHub41> migen/master 2ab939e Sebastien Bourdeauducq: fix SimActor TB terminations
lekernel has quit [Quit: Leaving]
Hawk777_ has joined #m-labs
kristian1aul has joined #m-labs
Hawk777 has quit [Ping timeout: 272 seconds]
kristianpaul has quit [Remote host closed the connection]