<wpwrak>
resistive probe, -eq is equivalent time with a nominal sample rate of 10 GSa/s. -rq is real time, 400 MSa/s.
<lekernel>
without the 24 ohm resistors?
<wpwrak>
without 24 ohm
<lekernel>
can you do eye diagrams?
<lekernel>
if you trigger on the clock you should be able to get 10 eyes on the screen. but not sure if you'd see much then.
<lekernel>
outputting the 10x clock on some SD card pin is also an option
<wpwrak>
ah, let's try
<lekernel>
you want to output the 10x clock?
<lekernel>
it's a painful mess with the S6 clock routing system but I can help
<wpwrak>
i actually tried to output the clock input. for that, i for the platform data inside clocking.py and send it to an MMC pin. strangely, this didn't work.
<wpwrak>
is it that such things that deep in the hierarchy would be ignored ? (i.e., picking an I/O pin)
<lekernel>
you can pick IO pins from anywhere in the hierarchy
<lekernel>
it was a different problem
<wpwrak>
for syncing with the clock, i'll try my luck with the 10 eyes
<lekernel>
so you used the full milkymist-ng clock?
<lekernel>
clock routing is one of the most horrible features of the S6, when you start using PLLs etc. it takes weeks to get things right if you're not used to it
<lekernel>
eg just "assign io_output = clock" in Verilog *never* works, you need to use a DDR register
<lekernel>
which in turn has restrictions on what you can connect to its *two* inputs (yes, you need an inverted clock as well to drive it)
<wpwrak>
sweet :)
<lekernel>
for example you can't connect the output of a BUFPLL, etc. etc. etc.
<lekernel>
and then there are restrictions on how many clock signals can enter some IO region
<wpwrak>
i guess i would have been foolish to expect that could work ;-)
<lekernel>
sometimes depending on where they come from
<wpwrak>
(actually, that was the next item on my list - compare clock in with pll clock out)
<wpwrak>
for the eye test, what would be a useful pattern to put on the screen ?
<lekernel>
and this silicon-level mess, of course, is seasoned with a hefty dose of the ISE bug sauce
<wpwrak>
so that data0n doesn't show too much chaos
<lekernel>
hmm, there will be chaos - 8b10b encoding picks different codes every time to achieve DC balance
<wpwrak>
:-(
<lekernel>
that was why there was analog-looking noise on the pictures when the shift register was wrong
<wpwrak>
one problem is of course that clock trigger jitter is close to of the pixel bit time ...
<lekernel>
could be why I had to add some jitter filtering in the FPGA ...
<lekernel>
maybe I can try to build you a demo bitstream with just the jitter filter + 10x multiplier?
<lekernel>
or one way to forward the clock in -ng is to use OSERDES with a 1010 pattern and the 20x IO clock
<lekernel>
there are already SERDESSTROBE and IOCLK for the sampling 20x ISERDES, so it should work without creating a clock routing mess
<wpwrak>
time and voltage magnified, no longer sampling the clock, so i get 2x the sample rate
<wpwrak>
try1 only had 200 MSa/s
<wpwrak>
nyquist frowns upon such experiments
<lekernel>
hm :)
<lekernel>
and that's 800x600 no?
<lekernel>
--mode 640x480 --refresh 60
<wpwrak>
heaven, no ! 640x480
<lekernel>
31.5MHz?
<wpwrak>
60 Hz, good point
<wpwrak>
was 72.8 Hz
[florian] has quit [Quit: leaving]
[florian] has joined #milkymist
[florian] has quit [Changing host]
[florian] has joined #milkymist
<kyak>
netbsd is going to run on MM - that's a good news
<kyak>
i was just wondering - why netbsd?
<kyak>
don't get me wrong, i'm not objecting, just asking :)
<wpwrak>
probably a difficult childhood
<kyak>
wpwrak: are you saying, you wouldn't choose netbsd ?
<wpwrak>
i think it would take me much longer to find my way around there than in linux
<kyak>
but do i remember correctly that linux is already ported to MM?
<wpwrak>
without mmu and i'm not sure how good the drivers are
<wpwrak>
i vaguely remember having heard of issues
<kyak>
i see
<lekernel>
Fallenou_, you're porting to legacy SoC, not ng?
<lekernel>
Mixxeo is ng only, and Wolfgang is MIA selling M 1, so...
<wpwrak>
does he have M1 orders queued up ?
<wpwrak>
btw, do you have the exact clock period for 640x480@60Hz ? i.e., is it precisely 1/25200000 s ?
<lekernel>
25.175MHz
<lekernel>
+/- imprecisions of your GPU
<wpwrak>
blargh. dot soup :-(
<wpwrak>
hmm. and of course,. since 400 MSa/s is not a multiple of a pixel on the scope screen, i get a bit of a sampling error when downloading. ah well ...
<Fallenou_>
lekernel: for now, yes. But porting to -ng will be trivial once legacy works
<Fallenou_>
so if I manage to get the first one working, I will definetely do both
<Fallenou_>
kyak: well, NetBSD is well known for being "super portable" and "running on toasters" etc. so why not trying to add another arch :)
<Fallenou_>
"it should be easy"
<Fallenou_>
I must say, I am very pleased by the fact that NetBSD (kernel) internals are really well documented
<Fallenou_>
you have man pages for kernel functions ... what a beauty :)
<Fallenou_>
so far I'm pleased with what I am discovering about NetBSD internals
<Fallenou_>
and since I'm not a hardcore linux kernel hacker, it was not "easier" for me to do a Linux port like wpwrak said
<Fallenou_>
so for now either Linux or something else, I don't care
<Fallenou_>
so that's just it, NetBSD (and BSD world in general) has a very good reputation about being clean and proper and well documented (not like GNU stuff) so I decided to give it a try :)
<Fallenou_>
bbl
<kyak>
Fallenou_: cool, thanks for explanation
<kyak>
and good luck, too :)
antgreen has quit [Ping timeout: 264 seconds]
<wpwrak>
Fallenou_: yeah, already knowing linux internals rather well makes a decision for linux easier, of course :)
<wpwrak>
hmm, it's interesting how the image badness varies. a short while ago, it was just a stream of noise. now it's stable enough that i can read what's on the screen.
<kyak>
wpwrak: are you sure it doesn't depend on observer? :)
<wpwrak>
hmm, i'm a relatively constant factor. but perhaps an imaginary invisible observer. kinda hard to track what these are doing.
<kyak>
a constant factor you say? get yourself a couple of beers and see if the image gets any better :)
<wpwrak>
there an idea !
* wpwrak
puts a few bottles in the fridge
<lekernel>
wpwrak, why not put those 22 ohm 0603 resistors in series?
<lekernel>
you can cut the traces near the connector, and solder one pin of the resistor on the connector pad and the other on the trace
<lekernel>
that's what I did, but with 0402 resistors (after unsucessfully inserting them on the other side between the pads and the connector pins - resistors broke after a few connector manipulations)
<lekernel>
the mystery is why the image looked good with the python script decoder and without the resistors
<lekernel>
maybe it's just more tolerant to errors than the gateware implementation, or there is some weird shit going on again (like FPGA tolerance to bad SI depending on the bitstream content ...)
<wpwrak>
hmm :)
<wpwrak>
adding termination may be a good idea, yes. but lemme see this in a simulation first. could also be that you're just shifting around another sort of problem.
<Fallenou_>
kyak: you're welcome :) if you want to help, the code is public (GitHub hosted)
<Fallenou_>
my e-mail already has a nice outcome: someone from the NetBSD community just offered me to help with the port !
<Fallenou_>
this re-enforces my feeling about how cool this community is :)
<Fallenou_>
lekernel: I talked a lot with khorben at EHSM, he really is a cool and smart guy!
<Fallenou_>
and he likes getting his hands dirty :)
<wpwrak>
that's the number of samples that went into the graph
<lekernel>
but what is the sample rate?
<wpwrak>
samping rate 400 MSa/s, converted to 500 MSa/s by an unknown algorithm in the scope
<lekernel>
meh :)
<wpwrak>
yeah :)
<wpwrak>
the clock frequency is that where i get the least blur. with so many samples, you can "zoom in" quite nicely. that's of course to be corrected for the accuracy of my scope.
<wpwrak>
it would seem that the patter is fairly stable. the resolution is too low to really say anything about the signal shape. it's barely high enough to identify individual bits.
<wpwrak>
ah, wait. each bit time should be ~2 pixels even. 25 MHz -> 40 ns per pixel -> 4 ns per bit -> 2 samples
<wpwrak>
so that pattern would be ... something like 111-00-1-0-1-00
<wpwrak>
now, is that a valid symbol ? :)
<larsc>
no
<larsc>
but you might be starting in the middle of the symbol
<wpwrak>
yes, there may be a slight offset
<larsc>
eg 1-0-1-00-111-00 is valid
<wpwrak>
ah, actually an unknown offset. lemme find out more about it ...
<wpwrak>
(i have the origin at the beginning of the scope's memory, many microseconds before the edge i triggered to)
<larsc>
I'd expect the symbol to start with a zero though
<wpwrak>
mmh, everything around the trigger looks different :-(
<larsc>
well what are you sending?
<larsc>
what's the pixel color?
<wpwrak>
i think that was mainly black
<larsc>
black would be 100000000
<larsc>
but would toggle very other pixel between 100000000 and 1011111111
<wpwrak>
hmm
<wpwrak>
gathering another sample. certainly all black now
kilae has joined #milkymist
<lekernel>
be careful of gamma/color/contrast/brightness adjustements your GPU may make
<wpwrak>
xsetroot -solid black ... after that, it's out of my hands :)
antgreen has joined #milkymist
ohama has quit [Read error: Operation timed out]
<lekernel>
yes. that's the problem
ohama has joined #milkymist
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
antgreen has quit [Ping timeout: 241 seconds]
<larsc>
0100111001 is 75
kilae has joined #milkymist
<wpwrak>
i don't see a common pattern of alternation. there is a certain high-low-high-low-... sequence, but there is frequently a high-high-low-... segment. thus, the high/low alternate
Martoni has quit [Read error: Connection reset by peer]
<larsc>
high-low-high-low-... is vsync/hsync
<wpwrak>
i mean just general pattern composition, i.e., predominantly high or predominantly low
<wpwrak>
no periodicity found until 42 pixel clock periods
<wpwrak>
picture when downloads.qi-hw is up again :(
<lekernel>
do you think it's going to be back at all?
<lekernel>
since march, sharism.cc must have been up for something like 5 days in total
<wpwrak>
sharism is very bad. qi-hw tends to work most of the time
mumptai has joined #milkymist
antgreen has joined #milkymist
bhamilton has quit [Quit: Leaving.]
iopluy has joined #milkymist
iopluy has quit [Client Quit]
iopluy has joined #milkymist
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
mumptai_ has joined #milkymist
mumptai has quit [Quit: Verlassend]
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
mumptai_ has quit [Quit: Verlassend]
mumptai has joined #milkymist
<Fallenou_>
lekernel: IIRC porting Milkymist SoC on the Nexys 3 board is a no-go because of the 16 bits datapath to the "PSRAM" instead of a 64 bits datapath like on the M1 as well as because it's PSRAM and not DDR SDRAM, right? What about porting Milkymist-ng on it? Using Migen and the new DDR SDRAM controller? would it work? or without the DDR SDRAM controller but replacing it with a few python lines to control the PSRAM?
<Fallenou_>
some hardcore NetBSD kernel hacker replied my in private to say he would offer his help with the NetBSD port :)
<Fallenou_>
he asked if he could make the Milkymist SoC run on his Nexys 3 board
<Fallenou_>
I am writting an answer to him
<Fallenou_>
if this is really a no-go, I can propose him to work using qemu ( mwalle ? is mmu functional with upstream qemu? on your tree ?)
<lekernel>
Fallenou_, it would work (if you put the gateware effort in). but PSRAM is slow.
<lekernel>
much easier to write a PSRAM controller than a SDRAM controller though
Alarm_ has joined #milkymist
<Fallenou_>
yes, since there is no bank stuff or refresh stuff
<Fallenou_>
it seems like an SRAM
<Fallenou_>
DRAM issues are hidden from you
<Fallenou_>
lekernel: I would not care about the performance, it would be just for development purposes for NetBSD kernel
<lekernel>
so easiest is to remove all the FML stuff and just connect the PSRAM to the wishbone bus
<Fallenou_>
if you tell me it's not very difficult I would do the gateware effort
<lekernel>
(or ASMI stuff if you use -ng)
<Fallenou_>
oh, ok so using the old SoC
<lekernel>
you can use either, but of course -ng is what I'm focusing on
<Fallenou_>
right, I guess I will play with python and migen ;)
<Fallenou_>
it's much more attractive than plain verilog
<Fallenou_>
and I don't want to waste too much time on this
<Fallenou_>
another issue is that I don't have the board
<Fallenou_>
anyone has this Nexys 3?
<Fallenou_>
that I could borrow
fpgaminer has quit []
<Fallenou_>
thanks for the insight
<lekernel>
and you would contribute a nexys3 definition file for mibuild too :)
<lekernel>
instead of just writing yet another ucf ...
<Fallenou_>
hehe yes that could be cool
<Fallenou_>
now I need to put my hands on a Nexys 3 board
azonenberg has joined #milkymist
<Fallenou_>
bbl
Alarm_ has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
<wpwrak>
that's a black screen (that is, the content is all black)
<lekernel>
so you can make eye diagrams with that scope? wow
<wpwrak>
not suspended
<wpwrak>
weeelll ... it's a little bit more complicated :)
<wpwrak>
the scope has deep memory. so i can capture a good amount of data. up to 1 MSamples.
<wpwrak>
then i can (awkwardly) download this to the PC
<wpwrak>
there, i can massage the data and finally generate this sort of image
<wpwrak>
the hardest part was actually finding the right clock frequency. i don't have a tool for that. so i took the frequency my scope reported, went a few steps below and above, and looked at the blurriness of the resulting image
<wpwrak>
picked the best, increased the number of samples, and repeated
<wpwrak>
lekernel: "a FPGA", "Slowtan", ... that looks like your style :)
<Fallenou_>
brb
<wpwrak>
what i don't like about these clips from "der untergang" is that i understand what they're saying, so two completely different streams of text are clashing in my head
<wpwrak>
and of course, turning off the sound would make it only half the fun
<Fallenou_>
nbjoerg: so basically we have qemu for simulation, gcc for C (C++ ? a little bit broken AFAIK), binutils (GAS) and such
<Fallenou_>
omg lekernel
<Fallenou_>
you just got mad
<Fallenou_>
've*
<Fallenou_>
lekernel: awesome video, I just cried laughing while looking at it
<Fallenou_>
nbjoerg: tools are working well enough to link a RTEMS binary or compile a working ucLinux kernel
<Fallenou_>
one thing that may be a problem is the relocations as I heard
<Fallenou_>
but I'm not there already :)
<Fallenou_>
I will focus on relocation and user space stuff when I will get a few lines of kernel booting
<Fallenou_>
and a proper virtual memory system working (you can have a look at pmap.9 functions which are implemented on my GitHub repository)
<nbjoerg>
just wondering as I would prefer to not get too many new binutils and gcc dependencies into the tree :)
<Fallenou_>
well, for now I'm using gcc and binutils of NetBSD tree
<Fallenou_>
and for now it seems to "work" well (... well ... I didn't have a chance to run anything, since it does not link yet)
<Fallenou_>
gcc from NetBSD tree should not be a problem since it's something like 4.5.2 / 4.5.3 which what we use here with lm32, so far so good :)
<Fallenou_>
I'm generating my tools using the build.sh
<nbjoerg>
4.5.3, IIRC
<Fallenou_>
yes something like that
<Fallenou_>
going to bed, see you later :)
<Fallenou_>
gn8 !
iopluy_ has joined #milkymist
iopluy has quit [Ping timeout: 248 seconds]
<wpwrak>
hmm. my period search doesn't yield very convincing results. seems that the data i captured has no real periodicity
<lekernel>
I don't think there is periodicity because of the DC balance algorithm
<lekernel>
or maybe with a very long period
<lekernel>
it really looked like noise, not a periodic pattern, when there was the shift register problem
<lekernel>
(and it was a logic problem, not an electrical one)
<wpwrak>
well, there is something that looks like sort of periodicity. you see that in the "eye pattern", which is several bits long.
<wpwrak>
so there are patterns that are mostly low and other patterns that are mostly high, but it seems to be difficult to predict which will appear
<wpwrak>
so it's basically symbol[rand() & 1], or something relatively close to that
<lekernel>
why do you need a period search? to determine the clock frequency without the clock?
<wpwrak>
things look somewhat orderly around 15872 ns (and multiples thereof), though
<wpwrak>
no, just to see if i can get a pattern where for a given t (mod period), there's only one dominant y value, not two
<wpwrak>
i.e., that "eye diagram" would become a square wave
<wpwrak>
alas, it's not so easy
<wpwrak>
anyway, chasing the pixel clock now. i'm curious how input signal and the fpga's perception of it are related. next will be the pll output. i'll try to just toggle a pin at the pixel clock.