| GitHub120 | [board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/11305082b6aeafe281cf1c87a2e39ab9ba4ab9e2 | 02:33 |
|---|---|---|
| GitHub120 | [board-m1/master] Power_Tree.sch: added new sheet for power tree - Adam Wang | 02:33 |
| GitHub110 | [scripts] xiangfu pushed 2 new commits to master: http://git.io/jG-k9w | 06:42 |
| GitHub110 | [scripts/master] build jansson lib - Xiangfu Liu | 06:42 |
| GitHub110 | [scripts/master] reflash_m1.sh : fix typo - Xiangfu Liu | 06:42 |
| cladamw | Anyone 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 |
| cladamw | and also what's the frequency setting for VGA RGB encoder ? 140 or 240 MHz ? | 07:21 |
| Fallenou | since we use cvbs input I think we are using the 54 MHz sampling rate | 07:43 |
| cladamw | Fallenou, yeah ... i think so. but I don't know if someone will apply RGB sampling for test ? :) | 07:59 |
| cladamw | Fallenou, since a RGB sampling analog current is about 1.67 * cvbs sampling, i am checking. :-) | 08:01 |
| Fallenou | by rgb you mean using the 3 inputs in parallel ? | 08:07 |
| Fallenou | with component input ? | 08:07 |
| Fallenou | I'm not sure if it's supported | 08:07 |
| cladamw | yeah... i am not sure who tested this condition before ? | 08:07 |
| Fallenou | no clue sorry | 08:08 |
| Fallenou | ask lekernel :) | 08:08 |
| cladamw | no problem, tks. | 08:08 |
| cladamw | oh, yeah | 08:08 |
| cladamw | lekernel, have you tried component video input ( w/ three video inputs) in the same time ? also what's the frequency input for ADV7125? | 08:10 |
| um4 | Hi Guys. New Milkymist one proud user. | 08:40 |
| lekernel | congratulations! | 08:41 |
| lekernel | cladamw: 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 work | 08:42 |
| Fallenou | have fun um4 :) | 08:43 |
| lekernel | cladamw: the B chip we have now doesn't support RGB sampling | 08:44 |
| cladamw | lekernel, i see, since i'm checking m1r4 with C version, so there's RGB sampling. :-) | 08:46 |
| cladamw | lekernel, btw, do you know VGA_CLK's frequency for ADV7125 ? 140 MHz or ? | 08:47 |
| lekernel | it depends on the video mode | 08:48 |
| lekernel | 640x480 is 25MHz, 1024x768 is 65MHz (iirc) | 08:48 |
| um4 | Lekernel- 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 help | 08:49 |
| cladamw | lekernel, 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 resolutions | 08:56 |
| Last message repeated 1 time(s). | 08:58 | |
| cladamw | lekernel, 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 |
| wolfspraul | cladamw: only mention numbers that we know actually work | 09:20 |
| wolfspraul | I don't like wishful thinking culture to infiltrate our documentation everywhere | 09:20 |
| wolfspraul | then we can also just write 5ghz, so we are 'future proof' | 09:20 |
| wpwrak | i would also put the theoretical maximum values somewhere. since you've calculated them already anyway ... | 09:21 |
| wolfspraul | which 'theory'? | 09:21 |
| wolfspraul | that is wrong imho | 09:21 |
| wolfspraul | maybe with some as-of-yet unknown theory we can imply some doubling or tripling? | 09:22 |
| wolfspraul | I mean | 09:22 |
| wolfspraul | it's all just a little 'development', right? | 09:22 |
| wolfspraul | we should only talk about numbers we have seen, tested, measured, we know are working, etc. | 09:22 |
| cladamw | wolfspraul, i would like to note datasheet's said , almost theory value. :-) | 09:22 |
| wolfspraul | otherwise we create no value for anyone | 09:22 |
| wpwrak | no no. it's for assessing whether components are sufficiently dimensioned | 09:22 |
| wpwrak | not everything is marketing ;-) | 09:22 |
| wolfspraul | I think about the reader of any number | 09:22 |
| wolfspraul | do we help the reader? | 09:22 |
| wolfspraul | of yes: use the number | 09:22 |
| wolfspraul | if no: don't use the number | 09:23 |
| wolfspraul | that's my guideline | 09:23 |
| wpwrak | if a chip/subsystem has a peak current X in a valid mode of operation, we should mention X | 09:23 |
| wolfspraul | you can always put a lot of arguments behind pretty much any number | 09:23 |
| wolfspraul | if that helps the reader in the context, yes | 09:23 |
| wpwrak | if our usage scenario has load Y, then we should mention that as well | 09:24 |
| wolfspraul | think about the reader and what kind of 'takeaway' the reader has from that number | 09:24 |
| wolfspraul | that's the key | 09:24 |
| wolfspraul | you don't want to fool or mislead your readers | 09:24 |
| wolfspraul | because quick enough you won't have any left :-) | 09:24 |
| wpwrak | we basically have the following values: 1) tested load, 2) peak consumption of subsystem, 3) designed maximum output of supply | 09:25 |
| wpwrak | 1, 2, and 3 may also employ different types of parameters | 09:25 |
| wpwrak | e.g., some may be I(typ) while others may be I(max). and some may be known exactly while others are estimates. | 09:25 |
| wpwrak | but such is life :-) | 09:25 |
| wpwrak | it's for the schematics. the readers are expected to be able to tolerate a bit of suffering :) | 09:26 |
| wpwrak | ah, one more set of parameters: load(s) in standard configuration(s). particularly if that's well below the tested load | 09:28 |
| wolfspraul | if 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 |
| wolfspraul | after all it's soldered there | 09:28 |
| wolfspraul | but have we tested any of those performance values? | 09:28 |
| wolfspraul | I would assume not | 09:28 |
| wolfspraul | can we rule out signal integrity or emi issues? | 09:29 |
| wpwrak | if the chip on our board can be configured to have that consumption, this would be a a correct assumption | 09:29 |
| wpwrak | that's why we'd indicate tested and max values separately | 09:29 |
| wolfspraul | in 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 |
| wolfspraul | I 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 |
| wpwrak | it all depends on what the reader is looking for | 09:29 |
| wolfspraul | and what do you think the reader is looking for :-) | 09:30 |
| wolfspraul | when reading the m1 schematics? | 09:30 |
| wolfspraul | he wants to know the performance of a chip if that chip would be on another board? | 09:30 |
| wpwrak | if i want to find a nice solar panel to feed my m1, i'll look at the "typical values for standard operation" | 09:30 |
| wolfspraul | probably not | 09:30 |
| wpwrak | if 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 values | 09:31 |
| wpwrak | if i want to know whether to expect trouble before embarking on a HDTV project, i'll compare tested with max values | 09:31 |
| wolfspraul | sounds quite hypothetical, but ok | 09:32 |
| wolfspraul | I made my point | 09:32 |
| wolfspraul | there is little value in all sorts of theoretical calculations | 09:32 |
| wpwrak | if 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)supply | 09:32 |
| wolfspraul | if those modes have never been shown to work at all, we must assume them to not work | 09:32 |
| wolfspraul | and then we don't need to inlude them in max power calculations either | 09:32 |
| wolfspraul | include | 09:32 |
| wpwrak | this is an engineering document | 09:33 |
| wolfspraul | exactly | 09:34 |
| wolfspraul | so it should leave wishful thinking out | 09:34 |
| wpwrak | if 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 |
| wolfspraul | of course | 09:34 |
| wolfspraul | think about this case more | 09:34 |
| wolfspraul | if they really never drove it to more than 80 km/h, they better make damn sure that it always stays in that range | 09:34 |
| wolfspraul | I don't care what crazy dreams they have at night about their 150km/h highway racing | 09:34 |
| wolfspraul | it makes no sense | 09:35 |
| wolfspraul | if you run into some unknown project | 09:35 |
| wolfspraul | you peek into the schematics | 09:35 |
| wolfspraul | you read | 09:35 |
| wolfspraul | then you are building up your hopes and expectations | 09:35 |
| wpwrak | but we don't have any provisions to make sure the chip can't draw more power | 09:35 |
| wolfspraul | you read something about performance here and there | 09:35 |
| wolfspraul | and you assume that this may work on this board! | 09:35 |
| wolfspraul | automatically | 09:35 |
| wolfspraul | then later you find out that nobody, not even the makers of the board, have ever actually tried that | 09:35 |
| wolfspraul | not once | 09:35 |
| wolfspraul | that is not nice | 09:35 |
| wpwrak | if you set it to 140 MHz, will a choke blow ? even if a parameter is not tested, you still have the designed value | 09:35 |
| wolfspraul | you will feel misled, guaranteed | 09:35 |
| wolfspraul | the correct thing is the other way round | 09:36 |
| wolfspraul | what is the max performance 'supported' on our board? | 09:36 |
| wpwrak | there are things that don't get tested intentionally. think of the crush depth of a submarine. | 09:36 |
| wolfspraul | then everything is designed around that | 09:36 |
| wpwrak | as a captain, you'd rather want to know how much it is, wouldn't you ? :) | 09:36 |
| wolfspraul | there is no point in having some 'peaks' of wishful thinking sticking out somewhere | 09:36 |
| wolfspraul | no, I want it all to be consistent | 09:36 |
| wolfspraul | when the chip is soldered to our board, it's "max" performance changes | 09:37 |
| wolfspraul | that is normal | 09:37 |
| wolfspraul | that needs to be documented | 09:37 |
| wolfspraul | imho | 09:37 |
| wpwrak | imagine 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 |
| wpwrak | if the chip's max performance is limited by hardware, then yes, we don't need to document values outside those bounds | 09:38 |
| wpwrak | but in the case of the video code, afaik, it's simply a question of sending a different set of parameters | 09:39 |
| wolfspraul | you don't know whether it's limited by hardware unless you test it | 09:40 |
| wolfspraul | there may well be signal integrity issues at higher speeds, or emi issues/crosstalk | 09:41 |
| wolfspraul | who knows | 09:41 |
| wolfspraul | we haven't even tried it once, so we should not talk about it, i.e. document only the known-working (and known-not-working) cases | 09:41 |
| wolfspraul | a case that has never been shown to run, not even once, is known-not-working | 09:42 |
| lekernel | or there may well be publicity/marketing issues that makes no one give a shit anyway | 09:42 |
| wolfspraul | again, imo only | 09:42 |
| wolfspraul | sure agreed. something that disappoints people typically doesn't scale too well :-) | 09:42 |
| wpwrak | the purpose is not to document what will or may work | 09:42 |
| wolfspraul | dinner, brb | 09:42 |
| wolfspraul | you guys can write what you want, I just shared my thoughts | 09:43 |
| wolfspraul | luckily as sebastien pointed out not many people are reading those numbers anyway | 09:43 |
| wpwrak | the purpose is to document what maximum load that subsystem may place on its supply | 09:43 |
| lekernel | it's not a problem of disappointing - they don't try it in the first place | 09:43 |
| wolfspraul | so the harm is contained | 09:43 |
| lekernel | no it is not | 09:43 |
| lekernel | this is the worst situation possible | 09:43 |
| wpwrak | ;-) | 09:43 |
| wolfspraul | the worst situation possible is that I use my sledgehammer on the board | 09:43 |
| wolfspraul | an engineering document should not use numbers that nobody has even seen running or measured | 09:44 |
| lekernel | most M1s are sitting in drawers, never powered up - or just once, look at the default effects, and back in the drawer | 09:44 |
| wolfspraul | but my opinion is in the logs... :-) | 09:44 |
| wpwrak | it's nice to have three people talking about the same topic ... and end up with three different worst case scenarios ;-) | 09:44 |
| wolfspraul | can't add much more | 09:44 |
| lekernel | this 140MHz detail, which most probably works anyway and I'm willing to bet on that, is just completely irrelevant | 09:45 |
| wpwrak | wolfspraul: 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 |
| wpwrak | and then they put a big "PRELIMINARY" on top of everything to make sure nobody can nail them down on any details :) | 09:47 |
| wpwrak | makes the legal department happy | 09:47 |
| lekernel | yeah, exactly. be too careful = be stuck. | 09:47 |
| wpwrak | and us engineers get to curse a little - and hope the values are still honest and accurate enough | 09:48 |
| wpwrak | in 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 |
| wpwrak | legal puts a note in the manual that you should NEVER drive at excessive speeds | 09:50 |
| wpwrak | the 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 |
| wpwrak | until, of course, the first owner takes the car on a little joy ride ... | 09:51 |
| wolfspraul | it'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 |
| wpwrak | the box is marketing :) | 09:52 |
| wolfspraul | you should talk about successful and unsuccessful companies after you have seen a few from inside | 09:53 |
| wpwrak | and yes, i'd agree that the number shouldn't be on the box | 09:53 |
| wolfspraul | from that experience, I can tell you the successful ones would *not* let engineers copy/paste wishful numbers around | 09:53 |
| lekernel | me too, for a different reason: no one cares about pixel clocks | 09:53 |
| wpwrak | the maximum current consumption is not a "wishful" number | 09:53 |
| wolfspraul | if an engineer would do this, he would be reminded about why he is employed and paid as an 'engineer' at the company | 09:53 |
| wolfspraul | or maybe he wants to apply for a different position? | 09:53 |
| wolfspraul | that's what the successful ones would do, yes | 09:54 |
| wolfspraul | oh at Apple that engineer would be fired | 09:54 |
| wolfspraul | ah sorry, pc correct 'let go' | 09:54 |
| lekernel | it's not wishful thinking | 09:54 |
| wolfspraul | it was never measured or seen running | 09:54 |
| wpwrak | i don't care if apply keep or fire their good engineers | 09:54 |
| wolfspraul | just saying, it's a fact | 09:54 |
| wolfspraul | an engineer who willing copies numbers without having tested/measured/seen it himself/herself is not real | 09:55 |
| wolfspraul | imho | 09:55 |
| wpwrak | if 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 |
| wpwrak | nonsense | 09:55 |
| wolfspraul | but now I know that 140 mhz number is fluke | 09:55 |
| wpwrak | we copy numbers from trusted sources all the time | 09:55 |
| wolfspraul | if I get the chance to remove it I will, next box print run :-) | 09:55 |
| wolfspraul | no you don't, your examples just showed that if you do that, you will add a note | 09:56 |
| wpwrak | again, we're talking about the schematics. not the box. | 09:56 |
| wolfspraul | that is fair | 09:56 |
| lekernel | you can perhaps measure the internal FPGA delays yourself, even ... :) | 09:56 |
| wolfspraul | "characterization from similar parts" | 09:56 |
| wpwrak | schematics = engineering. different mindset. different requirements. different way of using those numbers. box = marketing | 09:56 |
| lekernel | FYI Xilinx made some mistakes with that in early ISE versions, even | 09:56 |
| lekernel | for the S6 | 09:57 |
| wpwrak | see ;-) | 09:57 |
| wolfspraul | good thing that we learn from other peoples mistakes by thinking that allows us to make the same mistakes | 09:57 |
| wolfspraul | urgh | 09:57 |
| wolfspraul | :-) | 09:57 |
| wolfspraul | so anyway | 09:57 |
| wolfspraul | I would never relay any number as 'my own' if I had not seen/measured it, or with a disclaimer as Werner pointed out | 09:57 |
| wolfspraul | if you don't do that, and you imply that it's "your" number then you better be ready for the fallout one day | 09:57 |
| wolfspraul | if you are - fine | 09:57 |
| lekernel | if you think that will help, by all means do - but I wouldn't consider this is what causes most problems here | 09:58 |
| lekernel | the M1 works, you said it yourself :) | 09:58 |
| wpwrak | i'm not saying you should claim the number "as your own" | 09:58 |
| wpwrak | call it "theoretical maximum" if you want | 09:58 |
| lekernel | but sure, strict testing can be good... but expensive | 09:59 |
| wolfspraul | maximum blindly copy/pasted from part datasheet | 09:59 |
| wpwrak | what's wrong with that ? | 09:59 |
| wolfspraul | nothing, if you make it clear | 09:59 |
| wolfspraul | but keep in mind the chip is soldered onto our board | 09:59 |
| wolfspraul | readers will assume we have at least run through these numbers | 10:00 |
| wolfspraul | otherwise we would not relay those numbers | 10:00 |
| wolfspraul | cladamw: long discussion :-) | 10:00 |
| wolfspraul | sorry about that | 10:00 |
| wolfspraul | :-) | 10:00 |
| wpwrak | duh. put a little disclaimer then. "warning: max/designed numbers based on calculation, not actual tests" | 10:01 |
| wpwrak | then send your lawyers back to their lair ;-) | 10:01 |
| wolfspraul | um4: we sold a m1 today - TO YOU?! :-) | 10:02 |
| wolfspraul | if so - thanks a lot! | 10:02 |
| wolfspraul | we work very hard to make this a really unique and amazing and powerful thing | 10:02 |
| wolfspraul | and eventually we get there. now you are on board our ship, whether you like or not ;-) | 10:02 |
| wpwrak | oh, poor um4. what a horrible welcome. sorry :) | 10:03 |
| wolfspraul | werner will give you the cream cake now | 10:03 |
| wpwrak | custard pie fight ! (-:C | 10:03 |
| wolfspraul | is um1 the buyer? I'm actually not sure | 10:03 |
| wolfspraul | if he is, great first step to coming here | 10:04 |
| um4 | :) yes, wolfspraul, it´s me. Pablo, from Spain. | 10:07 |
| wolfspraul | excellent | 10:08 |
| wolfspraul | THANK YOU! | 10:08 |
| um4 | I´m trying to learn& amazing world for me. Real time fx 8) . Congrats for your work. | 10:19 |
| cladamw | um4, THANK YOU! I'll send you a tracking in maybe 20 minutes. :-) | 10:19 |
| um4 | Thanks cladamw. | 10:22 |
| cladamw | um4, you're welcome! | 10:37 |
| Fallenou | um4: have you subscribed to the Milkymist mailing list ? | 12:33 |
| Fallenou | it's mostly development stuff / new experimental features / releases related | 12:33 |
| Fallenou | but since you are now a M1 owner you might be interested in such emails :) | 12:33 |
| um4 | Right now. Thank you very much. | 12:45 |
| wpwrak | ah, a call for review from adam. only saw it now. | 13:33 |
| Fallenou | lekernel: 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-ng | 13:43 |
| Fallenou | it could take a while | 13:43 |
| cladamw | wpwrak, 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 |
| wpwrak | what valuable tasks ? | 14:06 |
| cladamw | wpwrak, at least I associated all parts to relevant modules. | 14:07 |
| cladamw | (meet IPC work) | 14:07 |
| wpwrak | ah, you mean that it would be good if someone would review the associations. yes, agreed | 14:08 |
| wpwrak | i | 14:08 |
| cladamw | they 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 easier | 14:08 |
| wpwrak | but probably not today. need to debug something else. | 14:09 |
| cladamw | but sorry that I was not smart on math/even coding 'art' to optimize fped codes. | 14:09 |
| wpwrak | the ones i saw looked pretty clean | 14:10 |
| cladamw | yes, 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 |
| wpwrak | ah, i see. yes, perhaps we need to work a bit more on that | 14:12 |
| wpwrak | also names will need a second look | 14:12 |
| cladamw | so 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 |
| cladamw | the 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/7d0e179a035e4f9d8517250d4737d5dce169647b | 14:37 |
| GitHub88 | [migen/master] actorlib: structuring (untested) - Sebastien Bourdeauducq | 14:37 |
| GitHub75 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/6fac3f027fc9c5bd779ee47e566b8065f8659356 | 16:27 |
| GitHub75 | [migen/master] examples/dataflow: structuring test - Sebastien Bourdeauducq | 16:27 |
| GitHub76 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/9a38c47048b2f7de0883d95342704587a228098f | 16:31 |
| GitHub76 | [migen/master] examples/dataflow/structuring: test Cast - Sebastien Bourdeauducq | 16:31 |
| Fallenou | hum why initial statement does not work in ISim ? =( | 17:38 |
| lekernel | it should...have you tried on a simple example? | 17:38 |
| Fallenou | sys_rst value is 1'bx during one clock period at startup | 17:38 |
| Fallenou | even with initial begin sys_rst <= 1'b1; end in m1reset.v | 17:39 |
| lekernel | that's not a simple example, that's thousands of lines of verilog code | 17:40 |
| Fallenou | I replaced initial begin sys_rst <= 1'b1; end by "reg sys_rst = 1'b1;" and it works now | 17:41 |
| lekernel | is the rest of your testbench code in another initial block? | 17:42 |
| lekernel | it could be that it waits for your testbench to complete to execute sys_rst <= 1'b1 | 17:42 |
| Fallenou | it's not really a testbench it's a migen generated soc.v | 17:42 |
| Fallenou | but not up to date migen, old migen | 17:43 |
| lekernel | er, it won't simulate alone anyway | 17:43 |
| Fallenou | is it OK if I use this kind of initialization reg XX = value; ? | 17:44 |
| Fallenou | just for the reset | 17:45 |
| Fallenou | other regs (in lm32 cpu) are initialized upon reset | 17:45 |
| lekernel | should be ok... but the initial statement should also work | 17:46 |
| Fallenou | yes I think too | 17:48 |
| Fallenou | ok so my problem is not reset related ^^ | 17:50 |
| Fallenou | I'm accessing the data cache blockram with index 000, , next clock the data_out is "XXXX" | 17:52 |
| Fallenou | why the hell address 000 of the blockram is not initialized ... | 17:52 |
| Fallenou | strange thing is I just flushed I and D caches | 17:54 |
| Fallenou | so it should clearly have a value | 17:54 |
| lekernel | i'd rather elucidate this initial statement problem | 17:56 |
| Fallenou | ok :) | 17:56 |
| lekernel | especially if you notice strange X's before | 17:56 |
| lekernel | verilog bugs like to hide under such discrepancies | 17:56 |
| Fallenou | well now I don't have any X any more at system startup which is great | 17:57 |
| Fallenou | at least I know the state of all my modules should be correct | 17:57 |
| Fallenou | all FSM should start with the correct state | 17:57 |
| Fallenou | hum maybe it's important to have afew nops right after each cache invalidation | 18:00 |
| Fallenou | hum ok it never enters the flush state | 18:15 |
| Fallenou | ok tags get written to during a flush, but data does not get written to , which explains the cache flush does not prevent me from XXX | 18:20 |
| Fallenou | too bad there is no pattern search in ISim | 18:42 |
| Fallenou | to search for a specific combination of wire/reg value | 18:42 |
| Fallenou | or a trigger or something | 18:42 |
| Fallenou | it's quite painful to scroll in all this mess | 18:42 |
| wpwrak | and the joy of closed source is that you can't just add such a thing | 18:54 |
| Fallenou | hehe true | 19:38 |
| kristianpaul | so not get used to it! :) | 19:46 |
| GitHub163 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/34d8ae3c11eeb366320544a3ecdfc1479a9c93f9 | 20:01 |
| GitHub163 | [migen/master] flow: perftools - Sebastien Bourdeauducq | 20:01 |
| mwalle | Fallenou: 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...956d1257c2bf | 22:46 |
| GitHub110 | [migen/master] actorlib/structuring/Pack: drive busy signal - Sebastien Bourdeauducq | 22:47 |
| GitHub110 | [migen/master] actorlib/sim/SimActor: remove dead time between transactions - Sebastien Bourdeauducq | 22:47 |
| GitHub110 | [migen/master] flow/perftool: fix cpt equation - Sebastien Bourdeauducq | 22:47 |
| --- Thu Jun 21 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!