lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
bentley` has quit [Ping timeout: 255 seconds]
xiangfu has joined #m-labs
xiangfu has quit [Ping timeout: 255 seconds]
bentley` has joined #m-labs
xiangfu has joined #m-labs
_florent_ has joined #m-labs
xiangfu has quit [Remote host closed the connection]
<ysionneau>
sb0 < the dqs "timing" is aligned with the dq one during the init sequence? because in my simulation I see that the DQS should be shifter by half of its period in order to correctly sample the DQ at rising edge
<ysionneau>
be shifted*
<ysionneau>
maybe let me put a screenshot online
<sb0>
simulating (and using) S6 SERDES is a mess. fortunately this is fixed in the 7 series. if it starts breaking, I suggest you don't touch that further because likely that will take you months.
<ysionneau>
so far it seems to work (ODDR2/OSERDES2) but it has just some timing I would not expect
<ysionneau>
so you think this is a simulation error? or maybe this is the case also in real life but the init sequence fixes it?
<sb0>
the init sequence doesn't touch the dqs timing
<ysionneau>
ok
<ysionneau>
but if it touches the dq timing, then it can put the dq a little bit earlier so that it would match the dqs rising edge
<sb0>
it doesn't touch any timing
<ysionneau>
ok
<sb0>
does everything work OK on papilio pro? including 8-, 16- and 32-bit writes?
<sb0>
oh btw, one of the spartan6 serdes features is that ISE will randomly misconfigure them. you might have just hit that case, perhaps.
<ysionneau>
selecting from parameters?
<sb0>
no, writes of that width from LM32, which use the wishbone sel signal
<sb0>
and/or several words in the downconverter
<ysionneau>
selecting wrong parameters*
<ysionneau>
for papilio pro let me redo some tests with 8- and 16-bit writes
<sb0>
I don't exactly know what that crapware is doing, just that sometimes when changing a completely unrelated part of the code the serdes break (and ISE says it passes timing)
<ysionneau>
ok :/
<ysionneau>
that's a mess
<ysionneau>
oh wait
<ysionneau>
I'm stupid
<sb0>
s6 is one of the worst fpgas imo... they did fix their mess in the 7 series afaict
<ysionneau>
ISE is telling me that pllout2 does not meet timing
<ysionneau>
.CLKOUT2(pllout2), /* < x2 270 clock for DQS, memory address and control signals */
<ysionneau>
so ...
<ysionneau>
that might well be my problem!
<sb0>
by how much does it fail timing?
<ysionneau>
7.121 ns of period, instead of 6 ns
<sb0>
ah, that's a fair bit. yes, that's probably why it doesn't work.
_florent_ has quit [Quit: Leaving]
kristianpaul has quit [Ping timeout: 260 seconds]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
<ysionneau>
there seem to have issues with byte writes on papilio, tracking it down right now
<ysionneau>
I think I need to modify the way the DownConverter handles the "sel"
<ysionneau>
it seems to be passing sel "as is" from wb_i to wb_o
<ysionneau>
so if on my 32 bit wb bus I do a write with sel = 4'b0001 then I get 2 accesses on the 16 bits wb bus with both sel = 2'b01
<ysionneau>
but I think it should be 2'b01 and 2'b00
xiangfu has joined #m-labs
playthatbeat has quit [Remote host closed the connection]
<rjo>
ysionneau: i'll give the labbrick thing a run now. but i'll propbably rewrite it to use pywinusb because then i can reuse it for something else and it's connected to a windows box currently.
<ysionneau>
arg :(
<ysionneau>
well, I can try to provide a windows version tororrow
<ysionneau>
it's just a matter of compiling the hidapi.dll
<ysionneau>
in theory
<ysionneau>
tomorrow*
<zyp>
python and ctypes for hidapi on windows? I've done that before
<ysionneau>
here I call hidapi from cffi
<ysionneau>
I'm glad someone else managed to make hidapi work on windows :)
<ysionneau>
zyp: did you compile the DLL yourself or is it provided somewhere?
<ysionneau>
to know if I will have to install Visual Studio :p
<zyp>
I think I compiled it myself
<zyp>
I can probably dig it up for you if you want to avoid having to do it yourself
<ysionneau>
yes it can be helpful I think, so that I can still use it if I have temporary troubles to compile it :)
<ysionneau>
thanks!
<rjo>
ysionneau: na that's ok. i'll just whip it up. should not be more than two function calls.
<ysionneau>
rjo: yes I guess
<rjo>
pywinusb seems nice to me.
<ysionneau>
yes it seems nice, but I think we wanted to have something portable, right?