Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
lekernel [lekernel!~lekernel@g225039244.adsl.alicedsl.de] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
fpgaminer [fpgaminer!181eaf8b@gateway/web/freenode/ip.24.30.175.139] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@221.217.224.207] has joined #milkymist
<kristianpaul>
ha, Virtex-7 dev kits prices are un-reacheable for us poor :-)
<kristianpaul>
s/Virtex-7/Xilinx 7
xiangfu [xiangfu!~xiangfu@125.34.161.244] has joined #milkymist
* fpgaminer
is waiting for a Kintex-7 devkit
* fpgaminer
maybe
* fpgaminer
so he can pine and wishes he had the money
<kristianpaul>
fpgaminer: Hi !
<fpgaminer>
kristianpaul: Hello!
<kristianpaul>
i havent seen you since months !
<kristianpaul>
fpgaminer: do you still using chipscope for comunicating with your miner core?
<fpgaminer>
Yeah, I've been trying to earn my wages! :P
<kristianpaul>
;-)
<fpgaminer>
kristianpaul: No, I moved on to using the JTAG core directly. :P
<kristianpaul>
;-)oh
<kristianpaul>
what commit was that.. let me update
<wolfspraul>
fpgaminer: hi there! ;-)
<fpgaminer>
wolfspraul: Hey :)
* wolfspraul
fpgaminder and self had some really inspiring private mail exchanges about Milkymist lately - thanks!
<wolfspraul>
and... fpgaminer is much more than just about (bitcoin) mining - the nick is misleading...
<kristianpaul>
i was checking ztex miner core, and wondering if it relly on external MCU for real mining
<kristianpaul>
was it pragmatic soemthing? (nick) :-)
<fpgaminer>
kristianpaul: I think it was back in Aug/Sep. I added it to the LX150_makomk_speed_Test variation.
<fpgaminer>
wolfspraul: Yeah, I hope I can help with the DVI/HDMI development in some way :) Like I said, I'll keep my eye on the mailing list
<kristianpaul>
fpgaminer: can you tell us a bit how to you end coding tha open source fpga miner? i read there was a common effort then break in many forks, so what you based your code on?
<kristianpaul>
C code? all from scratch?
<fpgaminer>
kristianpaul: I built my code from scratch after learning up how the algorithms worked
<fpgaminer>
kristianpaul: Then I published it on github and the Bitcoin forums and others jumped on to help improve it and port to other platforms
<kristianpaul>
nice !
<wolfspraul>
fpgaminer: the next board spin (called R4) will switch from our current VGA connector to a DVI-I connector
<wolfspraul>
so it will leave the analog path as-is (to keep the product functioning), and add new digital wires that are going directly into the fpga
<wolfspraul>
quite risky, a lot of unknowns for us in that
<wolfspraul>
like we have to route those wires all over the board to not disrupt the current layout, pin assignments, and so forth
<wolfspraul>
7cm...
<wolfspraul>
we also want to stick with our 6-layer board and not go to 8-layer just for those wires
<fpgaminer>
wolfspraul: As long as the AC characteristics are within the DVI spec, and they're routed to the right pins on the FPGA, you shouldn't have any issues.
<kristianpaul>
fpgaminer: i noticed you are experimenting with lm32 latelly ! :)
<wolfspraul>
the actual implementation of supporting HDMI will probably (I would think) use the migen stuff Sebastien is working on now (?)
<wolfspraul>
fpgaminer: good. If you can look over some of that at some point (schematics and partial layout), we would all take a deep sigh of relief here ;-))
<wolfspraul>
give it a few more weeks then it should be fully designed (sch+layout)
<wolfspraul>
it's moving...
<fpgaminer>
wolfspraul: I certainly will, though I don't normally deal with the schematic layer of DVI/HDMI
<fpgaminer>
kristianpaul: Yup, all thanks to Milkymist!
<kristianpaul>
:D
<kristianpaul>
see that lekernel ! ;-)
<fpgaminer>
kristianpaul: I've actually got ethernet working now :D
<kristianpaul>
You must be proud :-D
<fpgaminer>
kristianpaul: Now I'm just fighting RTEMS compilation so I can get that running. It really does _not_ like compiling on Windows.
<kristianpaul>
oh, you tried :)
<wolfspraul>
try a Linux virtual machine on Windows? ;-)
<wolfspraul>
that's just a big app, no?
<fpgaminer>
Yeah, I've more or less given up on a Windows compilation for now and just booted up Ubuntu in Virtualbox
<kristianpaul>
JTAG Atlantic core, what is that a IP thing?
<fpgaminer>
I can get the cross compilers to compile on Windows, but RTEMS throws up. Apparently Cygwin has some nasty fork bugs on Windows 7 64-bit.
<kristianpaul>
fpgaminer: so you dint like the idea of serializing data for reading/writing a miner core, or what lead you to implement the jtag interface?
<kristianpaul>
also i think i'll try your core soon my M1's lx45 fpga, as it seems can fit on it well ;)
<kristianpaul>
i had been reading bitcointalk forums latelly
<fpgaminer>
kristianpaul: Yeah JTAG Atlatnic is an Altera IP; JTAG-UART bridge. It's their only JTAG core that you can access from C/C++.
<kristianpaul>
trying to find a clean miner core base
<kristianpaul>
I see
<fpgaminer>
kristianpaul: I use the JTAG interface for development, because it means less wires running to the dev board :P And for production, it means a simple and cheap board.
<fpgaminer>
kristianpaul: The DE2_115_makomk_serial folder uses a UART for communication if you're looking for that. It's probably easy to port to Xilinx.
<kristianpaul>
oh
<kristianpaul>
looks similar to Icarus (from the module input output naming)
<kristianpaul>
wait
<kristianpaul>
also some parameters..
<fpgaminer>
Doesn't Icarus use my core?
<kristianpaul>
YES !
<fpgaminer>
I think ZTEX was the only one to use his own code
<kristianpaul>
ha ihavent looked at that folder of your before, too many ;)
<fpgaminer>
kristianpaul: Yeah, I have a lot of variations for such a small codebase :P
<kristianpaul>
if do LOOP_LOG2 bigger the core will use less resources?
<fpgaminer>
Correct
<fpgaminer>
LOOP_LOG2_CONFIG cuts the pipeline in half per increment
<fpgaminer>
so LOOP_LOG2_CONFIG=0 will fully unroll the pipeline and use the most resources
<fpgaminer>
1 will cut it in half, 2 down to a quarter, etc.
* kristianpaul
will try 5 later
<fpgaminer>
heh, yeah, that'll make it quite tiny :)
<kristianpaul>
this value is later overwriten for the sha256_transform core, os another separate parameter?
<kristianpaul>
and thats my last question :)
<kristianpaul>
I'm please you answer all this, i was holding a bit since past week :), plus i just get started to read about sha256 so still a way to understand all this !
<kristianpaul>
ah yes it is derived from there
<kristianpaul>
tought i need to understand that "ffset from the nonce"
<kristianpaul>
s/ffset/offet
<kristianpaul>
s/ffset/offset
<fpgaminer>
You mean the LOOP parameter? Yeah that just defines how much to divide the pipeline by using 2**LOOP_LOG2
<kristianpaul>
yes
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<fpgaminer>
Each setting of LOOP_LOG2 will result in a pipeline with a different length, which means that there is a different delay between the nonces going into the core, and the results coming out. GOLDEN_NONCE_OFFSET adjusts for that so that "Golden Nonces" returned by the core represent the nonce that went into the core to generate the successful hash.
<fpgaminer>
In other words, the data coming out of the mining core will always lag behind the data coming in. So when we want to report successful hashes to the outside world, we need to subtract the pipeline length.
<kristianpaul>
Yes, a bit slow but small pipe so less fpga resources :)
<wolfspraul>
fpgaminer: are your altera sources uploaded somwhere?
<kristianpaul>
that the only thing matters me now (fit :~))
<fpgaminer>
wolfspraul: It's mostly my own experimentation taking pieces of Milkymist and getting them running on Altera, but in the long run I'll try to reach full parity with Milkymist.
<fpgaminer>
Altera devkits like the DE2-115 have everything except the MIDI inputs I think, so I can probably get pretty close to a full Milkymist port.
<kristianpaul>
btw no minimac?
<fpgaminer>
kristianpaul: Haven't pushed to github in a few days. Code on my machine has minimac2
<fpgaminer>
I spent a day trying to get the timing constraints to work for my devkit's PHY :/
<kristianpaul>
yeah minimac have some clock domains to deal with..
<fpgaminer>
No kidding
<fpgaminer>
The 88E1111 phy is supposed to hang clock shifting on its own if you set the proper register
<fpgaminer>
but it wasn't working at 100Mbps; probably only works for 1000Mbps. So I just threw my hands in the air, shifted the clock by 90 degrees with a PLL, and called it a day.
<kristianpaul>
:)
<cladamw>
our M1R4 audio codec has AVDD rough 4.3V analog supply, with its recommend operating AVDD + 10% AVDD = 4.73V, within digi-key, we can sorting a varistor w/ 5.5V maximum, and 33pF@1KHz, 1 Vrms input, so this capacitance can let us reduce another extra 47pF on each audio path.
mwalle [mwalle!~mw@services.serverraum.org] has joined #milkymist
<cladamw>
there's two catacories: high speed and low speed, so followed 'low speed' to search.
<cladamw>
but digi-key didn't have that EZJP0V080DA, 33pF; so searched another brand AVR candidate.
<fpgaminer>
kristianpaul: Oh boy! They give a $1 discount if you buy over 100!!!
<wolfspraul>
fpgaminer: ah you are still there. Can I forward your HDMI comments you sent to me by mail to the milkymist list or the channel here?
<wpwrak>
cladamw: panasonic are rather generous: "dc voltage lines/high speed signal lines". seems universal :)
<cladamw>
wpwrak, we don't need to use much few capacitance @ low speed i think, regarding to panasonic introduction, we can select a 33pF, how do you think?
<wpwrak>
33 pF sounds fine to me
<cladamw>
wpwrak, yes, but scrolling down to see low speed, yeah !
<cladamw>
so i selected a compatible AVR in digi-key.
<wpwrak>
if you can find one with higher capacitance, maybe it can even act as a proper RF filter cap
<wolfspraul>
gotta run, bbiab
<cladamw>
wpwrak, want to more like 47pF?
<wpwrak>
more like 220 pF, i think :)
<fpgaminer>
wolfspraul: Sure ... just don't take anything I say as authoritative :P
<cladamw>
wpwrak, yuh... otherwise you're doing a bandwidth filter. ;-)
<cladamw>
wpwrak, yes, but the capacitance seems having rules on relying to varistor voltage and dc ratiing, so check like this: http://www.tdk.co.jp/tefe02/e9c11_avr.pdf
<cladamw>
although there's 40pF in 1005type (i.e. 0402 package) so according to WM9707 recommends spec. we should stick to a varitor voltage on 8V or 6.8V >= 4.73V (AVDD + 10%*AVDD),
<wpwrak>
hmm, capacitance goes up > 100 MHz. not much we can do about it, it seems
<wpwrak>
well, except picking an ultra-low-capcacitance varistor that will be good up to 1 GHz
<wpwrak>
but also 47 pF should serve us until ~300 MHz
<wpwrak>
so it should be fine at least for FM radio
<cladamw>
and also 'maximum continous voltage(rated voltage)' to 5.5V seems meet ours,
<cladamw>
oah~ yeah..a 47pF ~ reaching to FM. good analysis.
<cladamw>
wpwrak, so how do you think that sticking to p/n: AVR-M1005C080MTACB ? or search more candidate ?
<wpwrak>
yeah, to me it look okay. we should check with joerg, though.
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<stekern>
I'm a bit confused, looking at the datasheet for the ddr sdram I see that there should be one cycle from we going low to dqs going high, but when running simulations on hpdmc, I see two cycles between we_n and dqs
<stekern>
feels like I have misunderstood/missed something
<GitHub80>
[milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/qEgbYA
<GitHub80>
[milkymist-ng/master] uart: RX support - Sebastien Bourdeauducq
<lekernel>
yes, DQS goes high exactly one cycle after the DRAM registers the write command
<lekernel>
which is in the middle of the DQS spec (IIRC)
<lekernel>
verilog simulations can be confusing at times... remember that signal transitions happen *after* clock edges and on a clock edge, the value immediately *before* the edge is registered
<lekernel>
(rising edges usually)
<stekern>
yes, the problem is that we_n changes 100ns before sdram_clk_p
<stekern>
(although that could be a problem in my sim setup)
<lekernel>
mh?
<lekernel>
we_n changes synchronously with the clock, you should only have delta delay differences (the latter are not shown in gtkwave)
<lekernel>
and 100ns looks like a lot of time at the speed the clock is running :)
<stekern>
sorry, that should have been 100ps ;)
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<GitHub194>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/LzsiNw
<GitHub194>
[milkymist-ng/master] software: shell from original BIOS - Sebastien Bourdeauducq
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<GitHub131>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/x5aIaw
<GitHub131>
[milkymist-ng/master] libbase: blocking UART write if IRQs are enabled - Sebastien Bourdeauducq
<stekern>
ok, I have the same delay between sys_clk and sdram_clk_p, that probably explains it
<lekernel>
ah, that could be inside the ODDR2s?
<lekernel>
note that, in real life, the I/Os also have delays, which (hopefully) compensate for that of the ODDR2, with some margins
<stekern>
yes, sure, I'm pretty sure this is a simulation issue otherwise I wouldn't expect it to work at all
<stekern>
yes, it's the ODDR2s that generate that delay
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
* lekernel
is planning to submit a Migen paper to the Stockholm event
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
methril [methril!~methril@188.141.121.132] has joined #milkymist
<Fallenou>
MMU starts to work
<Fallenou>
memory loads seem to be working :)
<Fallenou>
at least it worked once :p
<whitequark>
oh, someone's working at MMU for M1? cool
<methril>
nice!!
<Fallenou>
It's gonna be tricky for memory stores
<Fallenou>
since LM32 caches are write through
<Fallenou>
Therefore it simultaneously writes to Data bus *and* to Dcache
<kristianpaul>
oh
<wpwrak>
seems that you need to pipeline that
<Fallenou>
it's a 1 clock cycle operation
<Fallenou>
I will try not to add latency
<wpwrak>
is memory write latency a problem, if pipelined ?
<Fallenou>
the thing is that ATM the DTLB is implemented in lm32_dcache.v module
<Fallenou>
and in case of stores (write through) it goes directly on D_ADR_O lines from lm32_load_stores.v
<Fallenou>
(and simultaneously to lm32_dcache to update cache line where it can be handled by DTLB)
<wpwrak>
yeah, i was thinking of potential conflicts when going from WT to WB
<wpwrak>
there could be some, it the memory interface is saturated and you don't want to add a delay in that case
<Fallenou>
I will have to add some code to lm32_load_store_unit.v too, in order not to put the virtual address on D_ADR_O in case of mem stores, and not adding a 1-cycle dtlb lookup latency
<wpwrak>
i.e., if you have a delayed write followed by a lot of reads, the reads could starve the write if they're prioritized
<Fallenou>
I will try not to delay any write
<Fallenou>
to keep the same lm32 timings
<Fallenou>
the less timing changes I have, the less bugs I can introduce
<wpwrak>
do you can translate virt->phys in the same cycle ?
<wpwrak>
(no changes) yeah :)
<Fallenou>
yep the lookup virt->phy is 1 cycle
<Fallenou>
so if I have the address presented the cycle before it has to be used, I can do the lookup for free
<wpwrak>
and do you have the address one cycle before the write ?
<Fallenou>
this I haven't looked yet :)
<Fallenou>
I just saw the first load work properly
<wpwrak>
hehe :)
<wpwrak>
the first step is usually the hardest L(
<wpwrak>
s/L(/:)/
mumptai [mumptai!~calle@brmn-4db70443.pool.mediaWays.net] has joined #milkymist
<Fallenou>
yep :)
<Fallenou>
I just realized it only works if physical address is already cached
<Fallenou>
damn 'X' state
<Fallenou>
they are almost everywhere
<Fallenou>
and it fucks simulation up sometimes
<Fallenou>
even if it does not exist in a real fpga
<Fallenou>
in simulation, non initialized sram contains "XXXXX" and not "0000" which makes some code fail :/
<Fallenou>
let's initialize it
xlq [xlq!~apropos@89-168-179-153.dynamic.dsl.as9105.com] has joined #milkymist
antgreen [antgreen!~user@bas3-toronto06-1177890738.dsl.bell.ca] has joined #milkymist
<Thihi>
Hmm, so is ther anything about the milkymist project (software & hardware) which isn't open source?
<wpwrak>
the synthesis tools ?
<larsc>
the FPGA itself is not
<kristianpaul>
the FPGA fabbing process* i think
<wpwrak>
also some of the underlying physics
<wpwrak>
much of them has been reverse-engineered, though
<larsc>
i've heard you can get faked universes in china these days ;)
<Thihi>
:)
<Thihi>
Thanks.
dvdk [dvdk!~dvdkhlng@g225042053.adsl.alicedsl.de] has joined #milkymist
<dvdk>
hi
<dvdk>
just tried to make qemu-lm32 work. segfaults on me :/
<dvdk>
ok, flterm seems to do the job. does it pass-through serial output after booting the device, or do I have to launch another gtk-term to see anything?
<dvdk>
BTW does the mm1 board have some (hidden?) reset button?
<dvdk>
currently pulling the DC cable for reset. hope the receptabel survives that
stekern [stekern!~stefan@nblzone-224-141.nblnetworks.fi] has joined #milkymist
<dvdk>
can I use the jtag interface via urjtag to reset the lm32 CPU (or the whole board for that matter)?