#milkymist IRC log for Wednesday, 2012-06-20

GitHub120[board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/11305082b6aeafe281cf1c87a2e39ab9ba4ab9e202:33
GitHub120[board-m1/master] Power_Tree.sch: added new sheet for power tree - Adam Wang02:33
GitHub110[scripts] xiangfu pushed 2 new commits to master: http://git.io/jG-k9w06:42
GitHub110[scripts/master] build jansson lib - Xiangfu Liu06:42
GitHub110[scripts/master] reflash_m1.sh : fix typo - Xiangfu Liu06:42
cladamwAnyone knows what's sample rate settings for current ADV7181 coder ? "CVBS input sampling at 54 MHz" or "Graphics RGB sampling at 75 MHz", i supposed it's a rate at 54 MHz for CVBS.07:01
cladamwand also what's the frequency setting for VGA RGB encoder ? 140 or 240 MHz ?07:21
Fallenousince we use cvbs input I think we are using the 54 MHz sampling rate07:43
cladamwFallenou, yeah ... i think so. but I don't know if someone will apply RGB sampling for test ? :)07:59
cladamwFallenou, since a RGB sampling analog current is about 1.67 * cvbs sampling, i am checking. :-)08:01
Fallenouby rgb you mean using the 3 inputs in parallel ?08:07
Fallenouwith component input ?08:07
FallenouI'm not sure if it's supported08:07
cladamwyeah... i am not sure who tested this condition before ?08:07
Fallenouno clue sorry08:08
Fallenouask lekernel :)08:08
cladamwno problem, tks.08:08
cladamwoh, yeah08:08
cladamwlekernel, have you tried component video input ( w/ three video inputs) in the same time ? also what's the frequency input for ADV7125?08:10
um4Hi Guys. New Milkymist one proud user.08:40
lekernelcongratulations!08:41
lekernelcladamw: I have tried with the luminance part only, and it did the right thing (B&W video). I have no device to generate the other 2 signals, but since the electrical connection is ok and the chip appears to be programmed correctly, there's no reason it wouldn't work08:42
Fallenouhave fun um4 :)08:43
lekernelcladamw: the B chip we have now doesn't support RGB sampling08:44
cladamwlekernel, i see, since i'm checking m1r4 with C version, so there's RGB sampling. :-)08:46
cladamwlekernel, btw, do you know VGA_CLK's frequency for ADV7125 ? 140 MHz or ?08:47
lekernelit depends on the video mode08:48
lekernel640x480 is 25MHz, 1024x768 is 65MHz (iirc)08:48
um4Lekernel- thanks for http://lekernel.net. Thank you all for your work. Don´t know too much about chips and programming but have large experience with discreet software and professional postproduction. If you need something just ask& happy to help08:49
cladamwlekernel, i see, so max. supported now is 65MHz, but if I'd like to identify what's max. would be in m1 platform, so rough would be just based on datasheet said  a 140 MHz even it's nonsense though. :-)08:52
lekernel_with the proper FPGA design there's no reason 140MHz would not work... but there are two problems (1) lack of FPGA developers (2) the memory bandwidth needed to do serious things at those resolutions08:56
Last message repeated 1 time(s).08:58
cladamwlekernel, okay, so for a power tree sheet, i could note a 140MHz base. (i.e. : Digital Supply Current, 9mA@fCLK = 50 MHz, 15mA@140MHz) :-) tks.!09:07
wolfspraulcladamw: only mention numbers that we know actually work09:20
wolfspraulI don't like wishful thinking culture to infiltrate our documentation everywhere09:20
wolfspraulthen we can also just write 5ghz, so we are 'future proof'09:20
wpwraki would also put the theoretical maximum values somewhere. since you've calculated them already anyway ...09:21
wolfspraulwhich 'theory'?09:21
wolfspraulthat is wrong imho09:21
wolfspraulmaybe with some as-of-yet unknown theory we can imply some doubling or tripling?09:22
wolfspraulI mean09:22
wolfspraulit's all just a little 'development', right?09:22
wolfspraulwe should only talk about numbers we have seen, tested, measured, we know are working, etc.09:22
cladamwwolfspraul, i would like to note datasheet's said , almost theory value. :-)09:22
wolfspraulotherwise we create no value for anyone09:22
wpwrakno no. it's for assessing whether components are sufficiently dimensioned09:22
wpwraknot everything is marketing ;-)09:22
wolfspraulI think about the reader of any number09:22
wolfsprauldo we help the reader?09:22
wolfspraulof yes: use the number09:22
wolfspraulif no: don't use the number09:23
wolfspraulthat's my guideline09:23
wpwrakif a chip/subsystem has a peak current X in a valid mode of operation, we should mention X09:23
wolfspraulyou can always put a lot of arguments behind pretty much any number09:23
wolfspraulif that helps the reader in the context, yes09:23
wpwrakif our usage scenario has load Y, then we should mention that as well09:24
wolfspraulthink about the reader and what kind of 'takeaway' the reader has from that number09:24
wolfspraulthat's the key09:24
wolfspraulyou don't want to fool or mislead your readers09:24
wolfspraulbecause quick enough you won't have any left :-)09:24
wpwrakwe basically have the following values: 1) tested load, 2) peak consumption of subsystem, 3) designed maximum output of supply09:25
wpwrak1, 2, and 3 may also employ different types of parameters09:25
wpwrake.g., some may be I(typ) while others may be I(max). and some may be known exactly while others are estimates.09:25
wpwrakbut such is life :-)09:25
wpwrakit's for the schematics. the readers are expected to be able to tolerate a bit of suffering :)09:26
wpwrakah, one more set of parameters: load(s) in standard configuration(s). particularly if that's well below the tested load09:28
wolfspraulif we mention a performance value of a chip in context with our board, someone may think the performance applies to the chip *on our board*09:28
wolfspraulafter all it's soldered there09:28
wolfspraulbut have we tested any of those performance values?09:28
wolfspraulI would assume not09:28
wolfspraulcan we rule out signal integrity or emi issues?09:29
wpwrakif the chip on our board can be configured to have that consumption, this would be a a correct assumption09:29
wpwrakthat's why we'd indicate tested and max values separately09:29
wolfspraulin other words - do we want to mentioned that 'performance' in the context of our board at all, if we have never demonstrated the chip running at that level?09:29
wolfspraulI mean if *we* don't even do it, how can we expect any reader who is looking at it from the outside to not feel misled if they later find out the truth?09:29
wpwrakit all depends on what the reader is looking for09:29
wolfsprauland what do you think the reader is looking for :-)09:30
wolfspraulwhen reading the m1 schematics?09:30
wolfspraulhe wants to know the performance of a chip if that chip would be on another board?09:30
wpwrakif i want to find a nice solar panel to feed my m1, i'll look at the "typical values for standard operation"09:30
wolfspraulprobably not09:30
wpwrakif i want to check whether the hardware of the 4.3 V rail is properly dimensioned (no chokes going up in smoke and such), then i'll look for max values09:31
wpwrakif i want to know whether to expect trouble before embarking on a HDTV project, i'll compare tested with max values09:31
wolfspraulsounds quite hypothetical, but ok09:32
wolfspraulI made my point09:32
wolfspraulthere is little value in all sorts of theoretical calculations09:32
wpwrakif i want to hook something up to a rail (e.g., 3.3 V or 5 V), then i;ll compare I(max)consumers and I(max)supply09:32
wolfspraulif those modes have never been shown to work at all, we must assume them to not work09:32
wolfsprauland then we don't need to inlude them in max power calculations either09:32
wolfspraulinclude09:32
wpwrakthis is an engineering document09:33
wolfspraulexactly09:34
wolfspraulso it should leave wishful thinking out09:34
wpwrakif the engineers who made your car never left the city and thus never drive it at more than, say, 80 km/h, would you be happy if the engineering documentation didn't mention anything abuot brake performance at, say, highway speeds ? :)09:34
wolfspraulof course09:34
wolfspraulthink about this case more09:34
wolfspraulif they really never drove it to more than 80 km/h, they better make damn sure that it always stays in that range09:34
wolfspraulI don't care what crazy dreams they have at night about their 150km/h highway racing09:34
wolfspraulit makes no sense09:35
wolfspraulif you run into some unknown project09:35
wolfspraulyou peek into the schematics09:35
wolfspraulyou read09:35
wolfspraulthen you are building up your hopes and expectations09:35
wpwrakbut we don't have any provisions to make sure the chip can't draw more power09:35
wolfspraulyou read something about performance here and there09:35
wolfsprauland you assume that this may work on this board!09:35
wolfspraulautomatically09:35
wolfspraulthen later you find out that nobody, not even the makers of the board, have ever actually tried that09:35
wolfspraulnot once09:35
wolfspraulthat is not nice09:35
wpwrakif you set it to 140 MHz, will a choke blow ? even if a parameter is not tested, you still have the designed value09:35
wolfspraulyou will feel misled, guaranteed09:35
wolfspraulthe correct thing is the other way round09:36
wolfspraulwhat is the max performance 'supported' on our board?09:36
wpwrakthere are things that don't get tested intentionally. think of the crush depth of a submarine.09:36
wolfspraulthen everything is designed around that09:36
wpwrakas a captain, you'd rather want to know how much it is, wouldn't you ? :)09:36
wolfspraulthere is no point in having some 'peaks' of wishful thinking sticking out somewhere09:36
wolfspraulno, I want it all to be consistent09:36
wolfspraulwhen the chip is soldered to our board, it's "max" performance changes09:37
wolfspraulthat is normal09:37
wolfspraulthat needs to be documented09:37
wolfspraulimho09:37
wpwrakimagine it's a military sub, they're throwing waterbombs at you. you need to make a decision how deep you can go. go too deep and you die. stay too high and you may die too. and you have to decide quickly :)09:37
wpwrakif the chip's max performance is limited by hardware, then yes, we don't need to document values outside those bounds09:38
wpwrakbut in the case of the video code, afaik, it's simply a question of sending a different set of parameters09:39
wolfspraulyou don't know whether it's limited by hardware unless you test it09:40
wolfspraulthere may well be signal integrity issues at higher speeds, or emi issues/crosstalk09:41
wolfspraulwho knows09:41
wolfspraulwe haven't even tried it once, so we should not talk about it, i.e. document only the known-working (and known-not-working) cases09:41
wolfspraula case that has never been shown to run, not even once, is known-not-working09:42
lekernelor there may well be publicity/marketing issues that makes no one give a shit anyway09:42
wolfspraulagain, imo only09:42
wolfspraulsure agreed. something that disappoints people typically doesn't scale too well :-)09:42
wpwrakthe purpose is not to document what will or may work09:42
wolfsprauldinner, brb09:42
wolfspraulyou guys can write what you want, I just shared my thoughts09:43
wolfspraulluckily as sebastien pointed out not many people are reading those numbers anyway09:43
wpwrakthe purpose is to document what maximum load that subsystem may place on its supply09:43
lekernelit's not a problem of disappointing - they don't try it in the first place09:43
wolfspraulso the harm is contained09:43
lekernelno it is not09:43
lekernelthis is the worst situation possible09:43
wpwrak;-)09:43
wolfspraulthe worst situation possible is that I use my sledgehammer on the board09:43
wolfspraulan engineering document should not use numbers that nobody has even seen running or measured09:44
lekernelmost M1s are sitting in drawers, never powered up - or just once, look at the default effects, and back in the drawer09:44
wolfspraulbut my opinion is in the logs... :-)09:44
wpwrakit's nice to have three people talking about the same topic ... and end up with three different worst case scenarios ;-)09:44
wolfspraulcan't add much more09:44
lekernelthis 140MHz detail, which most probably works anyway and I'm willing to bet on that, is just completely irrelevant09:45
wpwrakwolfspraul: if you look at data sheets, you'll find lots of numbers nobody has seen in real life. just read the fine print. "based on simulation". "characterization obtained from similar parts". and so on.09:45
wpwrakand then they put a big "PRELIMINARY" on top of everything to make sure nobody can nail them down on any details :)09:47
wpwrakmakes the legal department happy09:47
lekernelyeah, exactly. be too careful = be stuck.09:47
wpwrakand us engineers get to curse a little - and hope the values are still honest and accurate enough09:48
wpwrakin the car example, i actually had it backwards: the interesting parameter would be engine/transmission output. so the motor engineers only test that new ferrari up to 80 km/h. and they put this in the docs. then the brake designers come along and design brakes for, say, twice the top speed (healthy engineering tolerance). so if you go above 160 km/h, things will go bad. but they only followed the specs.09:50
wpwraklegal puts a note in the manual that you should NEVER drive at excessive speeds09:50
wpwrakthe car doesn't get a permission for germany, so it won't be used on highways where you would be allowed to drive at 160 km/h. all are happy.09:51
wpwrakuntil, of course, the first owner takes the car on a little joy ride ...09:51
wolfspraulit's not irrelevant. had I known earlier that the number is pure wishful thinking, it would not be on the box, for example.09:52
wpwrakthe box is marketing :)09:52
wolfspraulyou should talk about successful and unsuccessful companies after you have seen a few from inside09:53
wpwrakand yes, i'd agree that the number shouldn't be on the box09:53
wolfspraulfrom that experience, I can tell you the successful ones would *not* let engineers copy/paste wishful numbers around09:53
lekernelme too, for a different reason: no one cares about pixel clocks09:53
wpwrakthe maximum current consumption is not a "wishful" number09:53
wolfspraulif an engineer would do this, he would be reminded about why he is employed and paid as an 'engineer' at the company09:53
wolfspraulor maybe he wants to apply for a different position?09:53
wolfspraulthat's what the successful ones would do, yes09:54
wolfsprauloh at Apple that engineer would be fired09:54
wolfspraulah sorry, pc correct 'let go'09:54
lekernelit's not wishful thinking09:54
wolfspraulit was never measured or seen running09:54
wpwraki don't care if apply keep or fire their good engineers09:54
wolfsprauljust saying, it's a fact09:54
wolfspraulan engineer who willing copies numbers without having tested/measured/seen it himself/herself is not real09:55
wolfspraulimho09:55
wpwrakif they only keep the ones who can stay in tough with job's ghost in the morning ouija session, that's fine with me :)09:55
wpwraknonsense09:55
wolfspraulbut now I know that 140 mhz number is fluke09:55
wpwrakwe copy numbers from trusted sources all the time09:55
wolfspraulif I get the chance to remove it I will, next box print run :-)09:55
wolfspraulno you don't, your examples just showed that if you do that, you will add a note09:56
wpwrakagain, we're talking about the schematics. not the box.09:56
wolfspraulthat is fair09:56
lekernelyou can perhaps measure the internal FPGA delays yourself, even ... :)09:56
wolfspraul"characterization from similar parts"09:56
wpwrakschematics = engineering. different mindset. different requirements. different way of using those numbers. box = marketing09:56
lekernelFYI Xilinx made some mistakes with that in early ISE versions, even09:56
lekernelfor the S609:57
wpwraksee ;-)09:57
wolfspraulgood thing that we learn from other peoples mistakes by thinking that allows us to make the same mistakes09:57
wolfspraulurgh09:57
wolfspraul:-)09:57
wolfspraulso anyway09:57
wolfspraulI would never relay any number as 'my own' if I had not seen/measured it, or with a disclaimer as Werner pointed out09:57
wolfspraulif you don't do that, and you imply that it's "your" number then you better be ready for the fallout one day09:57
wolfspraulif you are - fine09:57
lekernelif you think that will help, by all means do - but I wouldn't consider this is what causes most problems here09:58
lekernelthe M1 works, you said it yourself :)09:58
wpwraki'm not saying you should claim the number "as your own"09:58
wpwrakcall it "theoretical maximum" if you want09:58
lekernelbut sure, strict testing can be good... but expensive09:59
wolfspraulmaximum blindly copy/pasted from part datasheet09:59
wpwrakwhat's wrong with that ?09:59
wolfspraulnothing, if you make it clear09:59
wolfspraulbut keep in mind the chip is soldered onto our board09:59
wolfspraulreaders will assume we have at least run through these numbers10:00
wolfspraulotherwise we would not relay those numbers10:00
wolfspraulcladamw: long discussion :-)10:00
wolfspraulsorry about that10:00
wolfspraul:-)10:00
wpwrakduh. put a little disclaimer then. "warning: max/designed numbers based on calculation, not actual tests"10:01
wpwrakthen send your lawyers back to their lair ;-)10:01
wolfspraulum4: we sold a m1 today - TO YOU?! :-)10:02
wolfspraulif so - thanks a lot!10:02
wolfspraulwe work very hard to make this a really unique and amazing and powerful thing10:02
wolfsprauland eventually we get there. now you are on board our ship, whether you like or not ;-)10:02
wpwrakoh, poor um4. what a horrible welcome. sorry :)10:03
wolfspraulwerner will give you the cream cake now10:03
wpwrakcustard pie fight ! (-:C10:03
wolfspraulis um1 the buyer? I'm actually not sure10:03
wolfspraulif he is, great first step to coming here10:04
um4:)  yes, wolfspraul, it´s me. Pablo, from Spain.10:07
wolfspraulexcellent10:08
wolfspraulTHANK YOU!10:08
um4I´m trying to learn& amazing world for me. Real time fx  8) . Congrats for your work.10:19
cladamwum4, THANK YOU! I'll send you a tracking in maybe 20 minutes. :-)10:19
um4Thanks cladamw.10:22
cladamwum4, you're welcome!10:37
Fallenouum4: have you subscribed to the Milkymist mailing list ?12:33
Fallenouit's mostly development stuff / new experimental features / releases related12:33
Fallenoubut since you are now a M1 owner you might be interested in such emails :)12:33
um4Right now. Thank you very much.12:45
wpwrakah, a call for review from adam. only saw it now.13:33
Fallenoulekernel: I'm investigating a bug in ITLB in the simulation environment, I won't integrate ITLB work into the mmu branch untill it's behaving a little bit better so don't wait for my commits to integrate mmu branch into milkymist-ng13:43
Fallenouit could take a while13:43
cladamwwpwrak, you can review or later, i just found the qfp land pattern is not good enough, I'll change it again. Btw, there're valuable tasks could be added to improve modules. btw, also not now for rush.14:06
wpwrakwhat valuable tasks ?14:06
cladamwwpwrak, at least I associated all parts to relevant modules.14:07
cladamw(meet IPC work)14:07
wpwrakah, you mean that it would be good if someone would review the associations. yes, agreed14:08
wpwraki14:08
cladamwthey are valuable to do correctly once, then always being happy in the future.14:08
wpwrak'll make a footprint catalog first. then it;ll be easier14:08
wpwrakbut probably not today. need to debug something else.14:09
cladamwbut sorry that I was not smart on math/even coding 'art' to optimize fped codes.14:09
wpwrakthe ones i saw looked pretty clean14:10
cladamwyes, i guessed that once someone wants to reuse modules, one day he can debug or optimize them (i meant "artistically" combine couples variants in one .fpd) :-)14:11
wpwrakah, i see. yes, perhaps we need to work a bit more on that14:12
wpwrakalso names will need a second look14:12
cladamwso far now, i felt they not pretty 'beautiful' on codes. :-) But if you liked, then at least my first work on fped which is not bad. :-)14:13
cladamwthe most problems are naming on the works of module name in the future. so a second look is good.14:14
GitHub88[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/7d0e179a035e4f9d8517250d4737d5dce169647b14:37
GitHub88[migen/master] actorlib: structuring (untested) - Sebastien Bourdeauducq14:37
GitHub75[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/6fac3f027fc9c5bd779ee47e566b8065f865935616:27
GitHub75[migen/master] examples/dataflow: structuring test - Sebastien Bourdeauducq16:27
GitHub76[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/9a38c47048b2f7de0883d95342704587a228098f16:31
GitHub76[migen/master] examples/dataflow/structuring: test Cast - Sebastien Bourdeauducq16:31
Fallenouhum why initial statement does not work in ISim ? =(17:38
lekernelit should...have you tried on a simple example?17:38
Fallenousys_rst value is 1'bx during one clock period at startup17:38
Fallenoueven with initial begin sys_rst <= 1'b1; end in m1reset.v17:39
lekernelthat's not a simple example, that's thousands of lines of verilog code17:40
FallenouI replaced initial begin sys_rst <= 1'b1; end by "reg sys_rst = 1'b1;" and it works now17:41
lekernelis the rest of your testbench code in another initial block?17:42
lekernelit could be that it waits for your testbench to complete to execute sys_rst <= 1'b117:42
Fallenouit's not really a testbench it's a migen generated soc.v17:42
Fallenoubut not up to date migen, old migen17:43
lekerneler, it won't simulate alone anyway17:43
Fallenouis it OK if I use this kind of initialization reg XX = value; ?17:44
Fallenoujust for the reset17:45
Fallenouother regs (in lm32 cpu) are initialized upon reset17:45
lekernelshould be ok... but the initial statement should also work17:46
Fallenouyes I think too17:48
Fallenouok so my problem is not reset related ^^17:50
FallenouI'm accessing the data cache blockram with index 000, , next clock the data_out is "XXXX"17:52
Fallenouwhy the hell address 000 of the blockram is not initialized ...17:52
Fallenoustrange thing is I just flushed I and D caches17:54
Fallenouso it should clearly have a value17:54
lekerneli'd rather elucidate this initial statement problem17:56
Fallenouok :)17:56
lekernelespecially if you notice strange X's before17:56
lekernelverilog bugs like to hide under such discrepancies17:56
Fallenouwell now I don't have any X any more at system startup which is great17:57
Fallenouat least I know the state of all my modules should be correct17:57
Fallenouall FSM should start with the correct state17:57
Fallenouhum maybe it's important to have afew nops right after each cache invalidation18:00
Fallenouhum ok it never enters the flush state18:15
Fallenouok tags get written to during a flush, but data does not get written to , which explains the cache flush does not prevent me from XXX18:20
Fallenoutoo bad there is no pattern search in ISim18:42
Fallenouto search for a specific combination of wire/reg value18:42
Fallenouor a trigger or something18:42
Fallenouit's quite painful to scroll in all this mess18:42
wpwrakand the joy of closed source is that you can't just add such a thing18:54
Fallenouhehe true19:38
kristianpaulso not get used to it! :)19:46
GitHub163[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/34d8ae3c11eeb366320544a3ecdfc1479a9c93f920:01
GitHub163[migen/master] flow: perftools - Sebastien Bourdeauducq20:01
mwalleFallenou: is there any documentation about your mmu design yet?21:23
GitHub110[migen] sbourdeauducq pushed 4 new commits to master: https://github.com/milkymist/migen/compare/34d8ae3c11ee...956d1257c2bf22:46
GitHub110[migen/master] actorlib/structuring/Pack: drive busy signal - Sebastien Bourdeauducq22:47
GitHub110[migen/master] actorlib/sim/SimActor: remove dead time between transactions - Sebastien Bourdeauducq22:47
GitHub110[migen/master] flow/perftool: fix cpt equation - Sebastien Bourdeauducq22:47
--- Thu Jun 21 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!