lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sb0 has joined #m-labs
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #m-labs
nicksydney has quit [Remote host closed the connection]
xiangfu has joined #m-labs
stekern has quit [Ping timeout: 255 seconds]
stekern has joined #m-labs
sb0 has quit [Ping timeout: 244 seconds]
sb0 has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<xiangfu>
sb0: Hi
<xiangfu>
Just asking. if you need the xilinx license. we have bought a virtex-7 dev kit. so we have a license for vivado.
<sb0>
xiangfu, thanks! I answered you by email - didn't get it?
<sb0>
I also have the license that came with the kc705 devkit. it works now, it was just hassle to set up...
<xiangfu>
sb0: No. I didn't get it. try this one xiangfu@openmobilefree.net
<xiangfu>
our is kc707 devkit.
<sb0>
ah yes, I see... I sent it to @sharism.cc
<xiangfu>
have to go. bbl.
<sb0>
do you have any news from Wolfgang btw?
_florent_ has joined #m-labs
<sb0>
_florent_, hi
<_florent_>
hi
<sb0>
what's the clock frequency you're operating ddr3 at on the kc705?
<sb0>
(on CK/CK#)
<_florent_>
200MHz
<sb0>
and the DLL is enabled?
<sb0>
it's spec'd for >= 333MHz operation afaict
<_florent_>
yes I know that the frequency is under what is spec'd
<_florent_>
I don't remember if I tested without the DLL
<sb0>
your init sequence keeps the DLL enabled...
<sb0>
btw, your phy does not work on my kc705
<_florent_>
but when you disable the DLL, the DDR3 memory has a different behaviour
<_florent_>
"However running a DDR memory in “DLL Off” mode makes significant changes to the way in which the device responds to the latency parameters (CAS Latency & Additive Latency) programmed into its mode registers"
<_florent_>
what are you testing?
<_florent_>
test_ddr3.py?
<sb0>
just compiled and downloaded your misoc-kc705 design. sdram seems completely unresponsive to read commands...
<sb0>
or the phy is not sampling data
<sb0>
running the DLL outside specs surely has adverse effects too
<_florent_>
the bios does not initialize the phy correctly, I use test_ddr3.py for that for now, but I want to completely rework the phy since read leveling with the current phy is a real pain
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<sb0>
haha, I see, with the DLL off the clock/DQS timing spec (tDQSCK) goes from +/- hundreds of ps to 1-10ns
<sb0>
so there's no way of escaping the DLL, and its minimum period spec, unless we run at dozens of MHz.
<sb0>
or use DQS
<sb0>
*maximum period spec
<_florent_>
last year I had a design working at 300MHz, so we are not so far
<_florent_>
and Elphel's phy is running at 400MHz IIRC
pabs3 has quit [Ping timeout: 255 seconds]
pabs3 has joined #m-labs
<sb0>
this CL-dependent clock period spec is very annoying. and I don't understand where it comes from...
<sb0>
hmm, at 1000Mbps, without DQS, the timing window is still ~500ps with the high-grade chips on the kc705
<sb0>
and that's within the DLL range for CL 6, 7 and 8
nicksydney has joined #m-labs
xiangfu has quit [Remote host closed the connection]
Alain has joined #m-labs
_florent_ has quit [Quit: Page closed]
siruf has joined #m-labs
MY123 has joined #m-labs
PunIntended is now known as MY123
<MY123>
rjo : Asked the question before but there was a timezone problem
<sb0>
MY123, now that there is no more timezone problem, what was the question? can't find it in the logs ...
<MY123>
sb0: The question was about Why Navré has an inaccurate cycle timing
<sb0>
what do you mean, inaccurate cycle timing?
<MY123>
sb0: The load/store takes an high time in my FPGA
<sb0>
instructions do not execute in exactly the same time as in the original AVR? maybe. that has never been a design goal.
<sb0>
?
<MY123>
sb0: The memory operations takes a long time on SRAM
<sb0>
huh=
<sb0>
no they don't
<MY123>
sb0: Does produce that in a Lattice FPGA, at least ( or it may be my SRAM ).
<sb0>
your design doesnt meet timing?
<MY123>
sb0: Yes. Need it to have a 30us latency max. (a ATmega works fine )
<sb0>
?????
<MY123>
(of course with some processing)
<sb0>
clock frequency is something like 80MHz on spartan6
<sb0>
much faster than the original atmega
<MY123>
sb0: On my FPGA, (180 nm) not so fast at all.
<MY123>
May have to try newer HW
<sb0>
and that's not what I meant by "does not meet timing". and why do you say it's coming from the memory?
<MY123>
sb0: Working with the registers only is 4 times faster . But expected it to only be 2 times ...
<MY123>
May be a stupidity in my design
<MY123>
as it is faster by IPC on the real thing
<sb0>
idk, look at the verilog for load/stores and see how many cycles that takes
<sb0>
I wrote that 4 years ago, don't remember everything
<sb0>
also, that problem is independent from what fpga vendor you are targeting
MY123 has quit [Quit: Connection closed for inactivity]