Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
aw joined #milkymist
aw_ joined #milkymist
wolfspraul joined #milkymist
xiangfu joined #milkymist
DJTachyon joined #milkymist
rejon joined #milkymist
<aw_>
wolfspraul, here last one customer bought from Taipei she wanted me to prepare some video files for them. they are preparing to show this Milkymist One in next week in Brasil.
<wolfspraul>
don't understand
<wolfspraul>
:-)
<aw_>
so I need to prepare them firstly then cc to you. ;-)
<wolfspraul>
"prepare some video files"?
<wolfspraul>
sure sounds great
<aw_>
like retail box opening to understand how to use M1, this was done by Lekernel already. and some use case of applications we promoted.
<aw_>
so even Werner's great video yesterday. ;-)
<wolfspraul>
so you send them a collection of links to videos?
<aw_>
yes
<wolfspraul>
alright :-)
<aw_>
also includes our official site, she told me that if someone in the conference may ask to buy. ;-)
<wolfspraul>
ok
xiangfu_ joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
rejon joined #milkymist
rejon joined #milkymist
lekernel joined #milkymist
<wpwrak>
hmm, just did a cvs update and re-applied my quilt stack. the rtems folks don't seem to be in much of a hurry to fix those bugs. or is there a hidden branch where they keep all the goodies ?
<wpwrak>
lekernel: soc11_2.diff should also go on my stack, right ?
Martoni joined #milkymist
<lekernel>
yes
<wpwrak>
added, thanks !
<wpwrak>
by the way, how are we building rtems these days ? my approach is rtems cvs plus my patch stack. lekernel, xiangfu_, is what you use equivalent ?
<lekernel>
same
<wpwrak>
and a question about instrumenting the SoC for "exporting" signals: what do you use ? do you pass things through the hierarchy, do you use fpga_editor, something else ?
<lekernel>
I don't have a logic analyzer, so I don't usually do that
<wpwrak>
ah, i see. well, even with the scope it may be useful
<lekernel>
a good way to do it would be a little script that manipulates the FPGA using XDL to reroute any net to I/O
<wpwrak>
hmm. script sounds good. i was pondering the idea of a script that edits the sources. but hacking a later stage would have its advantages, too. with xdl, do you mean the file format or the program called xdl ?
<wpwrak>
"As far as I know, there's nothing public about the XDL format" :-(
<wpwrak>
and so the reverse engineering begins ... again ...
<lekernel>
nah but it's super simple
<lekernel>
and regarding the question in the forum, you unroute the net by removing all pip entries
<lekernel>
you add the pin of the I/O site
<lekernel>
and you run PAR again to re-establish the connections. it will also do the timing analysis on that modified net.
<wpwrak>
what does the last item on inpin/outpin mean ? C3, O, DOB4, ... ?
<lekernel>
it's the name of the pin within the site
<lekernel>
e.g. an IOB site has multiple pins for input, output, tristate enable, etc.
<wpwrak>
aaah, so it's always O. excellent :)
<lekernel>
I told you it was easy :)
<wpwrak>
does the order of things in the .xdl file matter ?
<lekernel>
what is a little annoying is finding the good configuration options for the IOB, but you can simply copy and paste from a working design
<lekernel>
not afaik
<wpwrak>
yeah, copy and paste rules :)
<wpwrak>
wonderful. about running par, if i just do it between system.ncd and system-routed.ncd, no extra par run should be necessary, correct ?
<lekernel>
there's better than that
<lekernel>
you modify system-routed.ncd and you unroute the only net you have modified
<lekernel>
then PAR will only route one net, which takes only a few seconds (most of them spent loading the bloated libraries)
r33p joined #milkymist
<lekernel>
in system.ncd there are no pips at all (everything's unrouted)
<wpwrak>
system.ncd just looks like a simple netlist
<wpwrak>
and what's a pip ? :)
<wpwrak>
hmm, the pips look more difficult. let's keep that for another day.
<wpwrak>
hmm. "inst" has a mysterious RIOB_X37Y124 (for dbg_rx_active going to G17). and i found another,
<wpwrak>
git dbg_rx_pending going to G16
<wpwrak>
maybe that's the N/P pairs ...
<wpwrak>
yeah.
<lekernel>
pips are programmable switches that establish the physical connections between the site pins, by jumping from wire to wire
<wpwrak>
eek. i won't touch these :)
<lekernel>
it's not hard
<lekernel>
remove all pips from the net
<lekernel>
and re-run PAR
<lekernel>
it will nicely generate a new set of pips that reconnects all the pins - including the IOB pin you added
<lekernel>
note that if you don't remove all pips before, it will still work (will grow from the existing routed net), but the solution can be sub-optimal
<lekernel>
(at least, I think so. probably depends on some par options, too)
<lekernel>
but the safe way to go is remove pips before
<lekernel>
btw, pip sets aren't even too hard to generate anyway, I have an implementation of the Lee algorithm that works (can be suboptimal timing-wise compared to the PAR algorithm, though)
rejon_ joined #milkymist
<wpwrak>
so you're ready to get rid of par ? :)
<xiangfu_>
wpwrak, (rtems patches) working on that now. :)
<xiangfu_>
now. the build script use the cvs, no patch at all.
<lekernel>
xiangfu_: working on what?
<lekernel>
adding wpwrak's patches to your build script?
<xiangfu_>
yes. create a "makefile' instead. what do you think?
<xiangfu_>
like make bios
<lekernel>
I don't care
<xiangfu_>
make bitstream
<xiangfu_>
ok. werner and me want that. :) hope I can finish that this weekend. then send a patch to mailing list.
<lekernel>
xiangfu_: btw, I fixed your DMX/MIDI/video-in detection yesterday. it was only working when the variables were used in the constant part of the patch (i.e. when written a constant value. when used read or write in per-frame or per-vertex equations it didn't work)
<xiangfu_>
thanks.
<xiangfu_>
I have a small patch on makefile about build 'softwareusb' 'libhal' 'bios' , sent to mailing list. just let you know.
<lekernel>
xiangfu_: btw, how do you feel about finding out why the RTEMS FTPd "root directory" option doesn't work?
<xiangfu_>
when modify softusb code. 'build_bios.sh' will not recompile the 'softusb', this small patch fix that.
<lekernel>
I'd like to set it to /ssd, and also hide non-ssd directories in the GUI
<xiangfu_>
lekernel, yes. working on that when finish the compile patch stuff.
* xiangfu_
want more Milkymist task :)
<xiangfu_>
lekernel, just finish the nanonote release. so will have more time working on milkymist one.
<xiangfu_>
lekernel, btw. Jon try to sale the first Milkymist one in China mainland, we see. if all goes fine. we will try to setup tomorrow.
<wolfspraul>
but it doesn't have a mini-din on one side
<lekernel>
As S-Video maintains the two as separate signals, but still encodes two colour-difference signals into one chroma subcarrier, such detrimental low-pass filtering for luminance is unnecessary, although the chrominance signal still has limited bandwidth, and the colour crosstalk problem is subdued. The infamous dot crawl is eliminated. This means that S-Video leaves more information from the original video intact and offers an improved
<lekernel>
image reproduction compared with composite video.
<lekernel>
I believe the left connector on the picture is mini-DIN, maybe male... it says "s-video" ...
<wpwrak>
maybe find out how much the cable is and if it's cheap but difficult to source outside of china, toss one in the box ?
<lekernel>
"This cable can be used in several ways: •Connecting standard consumer S-Video to Separate Y/C RCA Connections"
<lekernel>
this is exactly what we are doing
<wolfspraul>
ah true, when I zoom in I can see mini-din, looks like male indeed
<wolfspraul>
so you want male on the mini-din side, or female?
<lekernel>
male is fine imo, so it can plug directly into the other appliance without an extra cable
<wolfspraul>
ah ok, so the source (video camera etc) typically ends in a female mini-din?
<xiangfu>
is this ok? and I needs another two male - male RCA make it connect to M1.
<xiangfu>
it's S-video --> 4 RCAs.
<lekernel>
it's not S-Video, it's made for expansion ports of graphics cards
<xiangfu>
is that one for audio. other three for video? just want to understand.
<xiangfu>
lekernel, oh.
<lekernel>
no, it generates composite and component from the expansion port of a PC graphics card
<wpwrak>
the video dialog is getting complicated :)
<wpwrak>
hmm. there are more problems: with the ncd -> xdl -> ncd: ERROR:PhysDesignRules:764 - Slew rate not set. Since it is used for output and its IO standard is LVCMOS33, IOB comp phy_rx_data<0>.OUTBUF needs a slew rate to be set.
<wpwrak>
and the joke is not lost on me that this is actually in input
<wpwrak>
s/in/an/
<wpwrak>
the .xdl also says so
<wolfspraul>
lekernel: thanks for catching up with Don - and he replied! great!
<wolfspraul>
until he stops by here - Don said he enjoyed using Milkymist One on his travels and it worked well and he has videos and patches to share with us soon...
<wpwrak>
will be very interesting to hear how exactly he uses the M1
<wpwrak>
oh wait .. that's still from xdl. interesting.
<wpwrak>
(xdl -xdl2ncd)
<GitHub155>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/8SLDSw
<GitHub155>
[flickernoise/master] Keyboard shortcuts to switch between composite video sources: F1/F2/F3 to select green/blue/red inputs (respectively) - Sebastien Bourdeauducq
Alarm joined #milkymist
<GitHub102>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/kBYlmQ
<GitHub102>
[flickernoise/master] New patches - Sebastien Bourdeauducq
lekernel joined #milkymist
sh4rm4 joined #milkymist
<scrts>
hm... whats the currency on taobao?
sh4rm4 joined #milkymist
<wpwrak>
whee. the madness works ;-)
<mwalle>
wpwrak: hacking the xdl to tap signals?
<wpwrak>
yeah
<kristianpaul>
oh
<kristianpaul>
tell us, tell us :-)
<wpwrak>
let's see ... what shall i ask for in return ?