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
lekernel__ joined #milkymist
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
wolfspraul joined #milkymist
wolfspra1l joined #milkymist
yizhang joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
whitequark joined #milkymist
wolfspraul joined #milkymist
wolfspraul joined #milkymist
wolfspraul joined #milkymist
cocoadaemon joined #milkymist
Martoni joined #milkymist
azonenberg joined #milkymist
<xiangfu>
wpwrak, the DMX device will arrive today evening. good news. :) because I got a message yesterday. it said will delay ~5 days. :)
<xiangfu>
then I will upload some pictures
<xiangfu>
maybe I will got them in next 3 or 4 hours.
r33p joined #milkymist
wolfspra1l joined #milkymist
wolfspraul joined #milkymist
aeris joined #milkymist
wolfspraul joined #milkymist
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
xiangfu joined #milkymist
xiangfu joined #milkymist
<aw_>
xiangfu, http://dpaste.com/666344/ Does it show that 'lm32-rtems4.11' compiles well and boot.bin without err ?
wolfspraul joined #milkymist
<wpwrak>
looks good, yes
<wpwrak>
aw_: (fedex) thanks !!
<wpwrak>
aw_: what total declared value did you put ?
<aw_>
wpwrak, great. I've not put declared value yet. Don't tell me now. hehe ... one day let me figured it out. just want to confirm tool is okay. :)
<wpwrak>
no, i mean on the fedex shipment
<wpwrak>
or did you not declare the value of the shipment ?
<aw_>
ha ~ the fedex declared value I put USD 35 only. :)
wolfspraul joined #milkymist
<aw_>
reason: repair since the M1 looks a repair board. :)
<aw_>
do u think it's okay ?
<wpwrak>
hehe ;-))
<wpwrak>
let's see what happens
<wpwrak>
i usually try not to give them an excuse to stop it at customs and make me go there. but well, maybe it works.
<aw_>
i did mostly like that way. so hopefully it goes through
<aw_>
one question: how can I know mostly that compiler works well in linux environment ? just dig into each Makefile to see what they do ? or other way ?
wolfspraul joined #milkymist
wolfspra1l joined #milkymist
<aw_>
in the window IDE environment, I usually see the 'output windows' to see the results of compilation. And smart IDE tool with different color automatically to point err /or warn lines.
<aw_>
so in terminal, how should I focus on compiling ?
<aw_>
Are my questions stupid enough ? or don't ask in that way, and just _do_ it ?
wolfspraul joined #milkymist
<wpwrak>
aw_: if there's an error, it will tell you at the end :)
<wpwrak>
aw_: and soon, the compilations will be less chatty. then it will be MUCH easier to spot problems
<xiangfu>
aw_, but there is no image's CRC in this boot.bin
<aw_>
wpwrak, oah ~ see it now. I just intended to type wrong, compiled and understood your 'less' vs 'MUCH'. thanks ! I.e. all the results are in way of historical context.
<aw_>
xiangfu, oah ~ yes. Thanks ! I also saw a file 'append_crc_len.sh'. So does it work for it ?
<xiangfu>
aw_, yes. it works fine. it needs one parameter: IMAGES_DIR
<xiangfu>
aw_, this patch should contain all images.
<aw_>
xiangfu, I don't know them now. he. :)
<wpwrak>
aw_: (less/MUCH) ah, i meant something else: the patches xiangfu just posted will reduce the output during a normal compilation. so if there is any problem, the error message will be easy to spot
<xiangfu>
aw_, s/this patch/this path/
<aw_>
xiangfu, wpwrak ha ~ got it.
<xiangfu>
aw_, hmm... I will think about this boot.crc.bin. the release image don't have bios-rescue and splash-rescue.
<wpwrak>
(lemur) interesting. so that's where iCon got their idea for their USD 125 controller from :)
ab5tract joined #milkymist
<wpwrak>
lekernel__: btw, any comment on my fpvm.c cosmetic changes ? okay to proceed in this direction ?
<lekernel__>
wpwrak: still need to have a deeper look at it, but the idea was to make libfpvm relatively generic
<lekernel__>
that's why it works on equations and not patches
<lekernel__>
that's an attempt to limit spaghetti code and have clearer interfaces :)
<lekernel__>
do you think the fpvm equation parser could take over within a better/more conventional patch parser (I agree it could be improved) and read characters until some delimiter? (\n, ;, etc.)
<wpwrak>
stacking parsers inside parsers tends to be messy. but where do you need "naked" equations anyway ? the prologue and epilogue could be treated like regular patches as well - and look better than they do today
<lekernel__>
this is more an attempt to keep some modularity than anything else
<wpwrak>
if you really need "naked" equations, you can steer the grammar towards some special start state
<lekernel__>
I don't need naked equations... except for prologue/epilogue as you said
<lekernel__>
it's for keeping it modular
<wpwrak>
naw, just makes things complicated :) the language is pretty simple. breaking things up in the middle adds mainly complexity. worse, you have a lot of information that's shared between both sides (e.g., predefined variables)
<lekernel__>
libfpvm implements fast equations on the hw accelerator, with a clear interface
<wpwrak>
the most straightforward solution would be to move the whole parser into flickernoise :)
<lekernel__>
then you can build other stuff on top of this, like the patch parser
<wpwrak>
you could make the AST or something similar the interface. then you don't break up the language
<lekernel__>
that's a possibility, but then inserting the prologue/epilogue by manipulating the AST in C is messy
<wpwrak>
not at all. you'd just run it through the parser like the patch itself
<wpwrak>
so you build one AST or AST-like thing
<wpwrak>
bascially whatever you have right above dynamic register allocation and code generation makes a "clean" interface
<lekernel__>
yes, I agree with the AST interface solution
<wpwrak>
below all this, you have another "clean" interface (i.e., one the scheduler uses)
<lekernel__>
as long as prologue/epilogue aren't messy :)
<lekernel__>
btw, you can drop the demo firmware if you make large changes like this
<wpwrak>
i would hope to just have them in files :) or some long-string-embedded-in-C equivalent
<wpwrak>
right now, they're kinda hard to decipher anyway
<lekernel__>
nowhere near as hard as manual allocation of AST nodes :)
<wpwrak>
(demo) excellent, thanks !! i was worried about that one :)
<wpwrak>
you could write the prologue and epilogue in hand-optimized "assembler". then everybody would believe it's for performance ;-))
<wpwrak>
but i think it'll work just fine to turn this into a "program" that looks like a regular patch
<lekernel__>
not really, you need to take care of the single-use registers
<lekernel__>
and assembly wouldn't even be efficient
<lekernel__>
just run it through some parser like it's done now
<lekernel__>
that's the best solution
<wpwrak>
funny. the lemur is just how i pictured our touch screen should be. i'd just not use real multi-touch (need some buttons on the side, though) and would use less colors
sh4rm4 joined #milkymist
DJTachyon joined #milkymist
<wpwrak>
i have a few openmoko touch screens lying around. these would in theory be easy for prototyping. alas, they're tiny
<wpwrak>
i also have one or two P2P clones from HXD8. they're a little bigger. hmm...
<kristianpaul>
wow prety futuristic this lemur, well i guess for its born time
<wpwrak>
pity that we'll probably want to run algorithmic optimizations on the AST later. otherwise, the parser could just generate code directly
n0carri3r joined #milkymist
<azonenberg>
Hmm
<azonenberg>
The datasheet and timing analysis disagree
<azonenberg>
as to the high end of the BUFG clock range
<azonenberg>
I'm creating a PoC design (just a single LUT and a flipflop configured as a divide-by-two) that I want to clock as fast as I can
<azonenberg>
using a 100 Mhz input clock multiplied up by a PLL_ADV
<azonenberg>
The datasheet seems to suggest the global clock network runs up to 400 Mhz
<azonenberg>
But my design passes timing at a 5x multiplier
<azonenberg>
Any guesses as to which one to believe and how ot test this for sure?
<wpwrak>
are you saying it works beyond the guaranteed specs ? where's the problem then ?
wpwrak joined #milkymist
DJTachyon joined #milkymist
<wpwrak>
hmm, i wonder if variable names like "sin", "cos", etc., are valid in milkdrop. they would currently be in FNP, but that's not necessarily a nice feature.