lekernel changed the topic of #milkymist to: Mixxeo, Migen, MiSoC & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
antgreen has quit [Ping timeout: 252 seconds]
antgreen has joined #milkymist
mumptai has quit [Ping timeout: 245 seconds]
antgreen has quit [Ping timeout: 272 seconds]
antgreen has joined #milkymist
jaeckel has quit [Remote host closed the connection]
lekernel has joined #milkymist
Alarm has joined #milkymist
kilae has joined #milkymist
kilae__ has joined #milkymist
kilae has quit [Ping timeout: 240 seconds]
xiangfu has joined #milkymist
mumptai has joined #milkymist
<wpwrak> so that plus a placer/router plus wolfgang's tools would be a complete synthesis suite ?
<lekernel> if it works... trying to compile it atm
<lekernel> hmm, it didn't crash and produced a convicing netlist for softusb_rx
<wpwrak> neat ! :)
<larsc> 'it didn't crash' - ah, better than the xilinx tools already ;)
<lekernel> ah, it doesn't support verilog parameters
<lekernel> well at least not with the syntax module_name #(...) instance_name
<lekernel> ah, no, the problem is float parameters
<lekernel> which means you can't use e.g. PLLs
<lekernel> it also chokes on byte-wide BRAM write enables (e.g. mem[minisoc_adr][7:0] <= minisoc_dat_w[7:0];)
<wpwrak> details, details ...
<lekernel> yeah, they should have used Migen FHDL as representation instead of wasting time on pesky and often pointless verilog details :)
<lekernel> still looks relatively good tho
<lekernel> ah, and of course, the famous lm32 clog2 also stops it
<lekernel> as well as "case" within a generate statement
<lekernel> generate + if + assign is also a problem
<ysionneau> aouch, lots of problems
<lekernel> seems there are no more though
<lekernel> I think misoc has a chance to compile after those details are fixed
<lekernel> also produces a netlist for navre :)
<ysionneau> doesn't iverilog produce netlist as well?
* ysionneau is lost about what's missing for open source toolchain
<lekernel> no, it's full of bugs, incomplete, and unusable
mumptai has quit [Quit: Verlassend]
<lekernel> so, planahead can implement that netlist, gives 74MHz and 1679 LUTs
<lekernel> getting the Xst hard numbers atm, but iirc they were like 85MHz and 1200 LUTs
<lekernel> Xst: 83MHz / 980 LUTs
<larsc> almost half
<ysionneau> pretty cool it works :)
<larsc> is it possible that xst uses more specialized cells for some of the logic?
<ysionneau> ah maybe yes, like multipliers
<lekernel> maybe it uses the FF CE/RST signals better
<lekernel> there is no multiplier in navre
<lekernel> but yes, yosys does not use the carry chains
<lekernel> I can imagine this accounts for a fair bit of the bloat and slowdown
<wpwrak> how's the run time ?
xiangfu has quit [Ping timeout: 246 seconds]
<lekernel> yosys seems slightly faster (haven't measured)
<larsc> navre seems to be one of his testcases https://github.com/cliffordwolf/yosys-bigsim/tree/master/softusb_navre
<larsc> so no wonder it is working ;)
<ysionneau> ahah
<larsc> and he also has a zed board
<lekernel> compiled a led blinker design with yosys, it does the right thing on the board
<lekernel> output signal names are like "$auto$iopadmap.cc:163:execute$129" ...
<larsc> yea, I noticed that too
<larsc> so, as far as I can see the xilinx module only has support for simple flipflops and simple luts
<lekernel> no RAMs?
<larsc> It should I guess
<larsc> but I don't see them
<larsc> you used the synth_xilinx command right?
<lekernel> yes
<larsc> I really like the tab completion
<larsc> it seems to map memory to a big mux
<larsc> hm, abc stumbles over the verilog generated by the tool
<larsc> ah, no, it's the blif file
<lekernel> ...where "B" stands for "Berkeley". pretty usual behaviour from academic software :)
playthatbeat has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
Alarm has quit [Ping timeout: 252 seconds]
wpwrak has quit [Ping timeout: 252 seconds]
sh4rm4 has quit [*.net *.split]
sh4rm4 has joined #milkymist
sh4rm4 has quit [Quit: sh4rm4]
sh4rm4 has joined #milkymist
wpwrak has joined #milkymist
<larsc> the blif standard doesn't seem to specify how to handle conflicts in the lut table, those are the best standards I guess
<lekernel> what's a conflict in the lut table?
<larsc> 1x = 1, x1 = 0
<larsc> what is 11?
<larsc> what is the output for 11
<lekernel> wouldn't it be an error to have "1x = 1, x1 = 0" ?
<larsc> it does not specify whether this is an error, or whether the first line or the last line takes precedence
<larsc> I think it is useful to be able to overwrite a more generic setting
<larsc> e.g. if you have n inputs and for all but one combination the output is 0, you could write xxxx = 0, 0001 = 1
<larsc> instead of having to specify every possible combination
<larsc> on the other hand, maybe 0001 = 1 is enough
<larsc> and it will assume that everything else should be 0
<larsc> hm, it looks as if there are problems inferring the clock for memories
antgreen has quit [Read error: Connection reset by peer]
<larsc> and why would I get a mux which muxes between const 0 and const 1
<larsc> lekernel: have you been able to infer ram?
<lekernel> haven't tried
<lekernel> just saw it failed to parse the byte-wide WE and didn't try further
<larsc> ok
Scopeuk-AFK is now known as Scopeuk
kilae__ has quit [Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]]
Scopeuk is now known as Scopeuk-AFK
lekernel has quit [Ping timeout: 272 seconds]
lekernel has joined #milkymist
lekernel has quit [Quit: Leaving]