#milkymist IRC log for Sunday, 2012-03-25

wpwrakthe french version of "World of Warcraft" ?01:23
Fallenouhehe01:50
FallenouI would say it's approximatively : "fuck"01:51
Fallenougn8!01:52
wolfsprauln801:55
wolfspraul:-)01:56
FallenouI am trying to modify my simulation bios to match real world example, like putting my ram at address 0x44000000, I created a boot_code section in linker script which is used for the crt0.S11:56
Fallenoubut I get a link error11:56
Fallenouhttp://pastebin.com/e8FKRieD11:58
Fallenouis this something like I am trying to to branch immediate with a giant offset ?11:58
FallenouI told gcc to put isr() function in boot_code with a gnu-style attribute, but it still complains about it11:59
Fallenouhum ok I put "boot_code" instead of ".boot_code" in the gcc attribute, so it's OK now for isr()12:02
Fallenouit still complains about main(), I guess about the too big offset ... I need to find a way to do a "long jump"12:03
Fallenouoh, using b instead of bi12:04
Fallenouok it linked :)12:05
Fallenoubios.bin is now 1.1 GB \o/12:24
kristianpaul0_o12:24
Fallenouyes I have exception handler vectors and setup code at address 0 and all the remaining code at 0x4400000012:25
Fallenouand a lot of padding :)12:25
Fallenouso the flat binary is kind of big12:25
Fallenoubbl12:29
FallenouISim does not like 2.4 GB ram.data files :)13:28
Fallenouit does not like it at all13:28
FallenouI should split address space in two mem files13:31
wpwrakFallenou: do you even need stuff at low addresses ? e.g., couldn't you just disable interrupts and reset the PC to where your code really lives ? (in the simulation)16:56
Fallenouoh you think I can make the lm32 boot at 0x4400000 address instead of 0x0 ?16:58
Fallenouthat would be nice16:58
wpwrakit can't be difficult :)17:07
lekernelyou can even map the interrupts to 0x4400000017:13
FallenouI am using two sram , one for boot_ram.data file containing crt0.S and one for program_ram.data file containing all the remaining code (main.c / dtlb_load_test.c)17:15
Fallenounow I can test the exact same mapping which is failing on the M117:15
FallenouOK I did as you suggested, everything is at address 0x44***** and lm32 is booting from 0x4400000017:39
Fallenoubad news is ISim seems to show mmu is behaving correctly17:39
Fallenoutranslating all the 0x44002xxx accesses to 0x44001xxx ones17:40
lekernelmaybe you need to add some memory latency?17:58
lekerneleg use $random on the ack signal :) this may tickle those hiding bugs...17:58
Fallenouhum ok !17:59
FallenouI even get my printf() outputs in Isim console now :)18:00
lekernelgreat!18:00
Fallenouprintf() just write chars to an unused memory address, which gets handlede with a $write() in soc.v :)18:00
Action: Fallenou pushed his changes18:05
Fallenoulike putting #$random() ack <= something; ?18:07
Fallenouin soc.v18:07
Fallenouhum compiler does not like18:08
Fallenouif you want to test the simulation in case you can spot something I didn't , you just have to do make in software/mmu-bios and cp the bios.bin in the simulation directory and do make clean && make and there you go18:27
Fallenou(but you would need the modified lm32-binutils which is on my github too :x)18:30
Fallenougoing to eat bbl18:32
lekernelFallenou: no, but at each cycle you can mask out the ack signal randomly18:36
lekerneleg https://github.com/milkymist/migen/blob/master/examples/wb_initiator.py#L4418:37
Fallenouoh like if ($random() %2) ack <= value; else ack <= 019:06
lekernelyes19:10
Fallenouok the stores are done randomly multiple times19:12
Fallenouso printf() output has a lot of multiple caracters19:13
Fallenourandom latency seems to be working19:13
Fallenouall tests are still passing19:13
Fallenouwill do it again a few times19:13
Fallenou21:18 < Fallenou> so printf() output has a lot of multiple caracters < a lot of duplicate characters19:14
lekernelwell, the store should still happen once19:15
lekernelonly when the CPU gets the ack19:15
Fallenouoh19:15
Fallenousince the beginning stores were done twice19:15
Fallenouand now that ack is random, it gets stored a random number of time19:15
lekernelso it's a bug19:15
Fallenouit's more a soc.v bug than a lm32 bug I think19:16
lekernelor maybe just your misunderstanding of wishbone :) the store signals should be kept constant until the ack19:16
lekernelbut that's only one store, even if it spans multiple cycles19:16
FallenouI'm just saying that the frag_we[] stays asserted during two cycles19:17
Fallenoufor each write19:17
Fallenouso the mem[] gets written twice in a row with the same value19:18
Fallenoubut it should not cause any problem19:18
Fallenoubut in the cpu there is only one store "event"19:18
Fallenouand one store transaction (in term of wishbone transaction)19:18
whitequarkhm, I just thought about it. Is there a way to adjust ISE simulator so that propagation delay would be visible on the waveform diagram?21:27
whitequarksometimes I really want to know which transition was earlier21:28
dvdkwhitequark: do a post-synthesis simulation :)21:46
wpwrakFallenou: what ? two stores ? writes to NOR or memory-mapped I/O aren't idempotent !22:31
FallenouI don't think I write to NOR22:32
wpwraki kinda wonder if it would make sense to feed verilog into spin. spin is a model checker that can verify a lot of properties.22:33
wpwrakFallenou: what i mean is that, if the memory controller does duplicate writes in real life, that would be a problem22:33
FallenouI just noticed that with my current simulation, using migen generated soc.v , when lm32 writes to sram through wishbone, sram gets written twice22:33
FallenouI mean, during two clock cycles22:33
FallenouI don't know if this is the case in the real SoC22:34
FallenouI just noticed this with soc.v from migen22:34
wpwrakwhere's a super-fast logic analyzer when you need one ? :)22:35
Fallenouhehe22:35
Fallenouit does not seem to be a problem though (writting twice) in my situation here22:36
Fallenouit just tells us that something somewhere is not totally optimized22:36
Fallenoumaybe it's just that frag_we stays asserted for one cycle and that's all22:37
Fallenounow I have a real printf() which is not printf(char *s) { puts(s); } (copy pasted from milkymist bios)22:48
Fallenouit works too in ISim22:48
Fallenouall tests "pass"22:48
FallenouTTOOOTTTAAAAAALLLL   ::    11155555/////111155          ssssuuuccccceeeesssssseesss  ||    00//11555  ffffaaiiiilluuuuurrrrrrreess22:48
Fallenou15/15 (only 15 tests :p)22:49
wpwrakthe TTOOO... is because of the multiple writes ?22:52
Fallenouyes22:52
Fallenouwhich happens all the time because of the if ($random() % 2) ack <= 1 else ack <= 022:52
Fallenouif I remove this randomization stuff, I get TTOOTTAALL  ::  etc, only two times each letter22:53
wpwrakheh :)22:53
wpwrakin any case, it's not what should go out to the bus. at least if this is on a CK edge each.  (maybe check if this is the case and that your printf sample clock isn't faster)22:59
FallenouI don't sample the bus data to check the writes23:02
FallenouI check each system clock23:02
Fallenouwell yes I sample the bus, but at the system clock :p23:03
Fallenouwpwrak: the problem is not what goes from lm32 to wishbone, the problem is what goes out from wishbone to sram module23:04
Fallenousram is seeing "write enable" asserted for two consecutive system clock cycles23:04
wpwrakbut how many memory clock cycles are that ?23:04
Fallenoubtw I just wrote a filter to filter off consecutive writes for the "uart" address in order to have a clean uart output in ISim :)23:04
wpwrakdon't do that :) yo23:05
Fallenouwpwrak: sram clock is the system clock23:05
wpwraku're hiding the problem instead of solving it23:05
FallenouI just have $display() for each system cycle with frag_we asserted don't worry23:05
wpwrak(same clock) ok23:05
FallenouI am still seeing consecutive writes23:05
Fallenoubut the uart output is clean :)23:05
FallenouTOTAL : 15/15 successes | 0/15 failures23:06
wpwrakdoes all this also happen on the original M1/LM32, without MMU ?23:06
FallenouI would say I think that this happens at least on the particular migen+milkymist-ng combo I am using23:07
FallenouI think it comes from the wishbone implementation of milkymist-ng23:07
wpwrakokay. let's see then what lekernel thinks about it. he would have to see it too, no ?23:08
FallenouI think yes23:08
Fallenoumaybe it's fixed now and I am still on an old version23:08
Fallenoumaybe it comes from my particular setup (two masters - one slave)23:08
wolfspraulgood morning everybody23:09
Fallenouhello :)23:09
Fallenoutime to go to sleep for me !23:09
wolfspraulsomething popped up in the computer section of my dreams: why can't m1 support so-dimm seated memory?23:09
wolfspraulFallenou: he :-) and my coffee is cooking now... how's it going? some weekend hacking? :-)23:10
Fallenouyes some week-end mmu hacking23:10
Fallenouit has been a busy week23:10
Fallenoubut now it's 1 AM here and I have to get up early to go to work tomorrow :"23:11
wpwrakdon't they use a wider bus ?23:11
Fallenouwpwrak: the good point here is that my simulation is starting to look more and more like the "real setup"23:12
Fallenouthe code execute is really close, the verilog code is exactly the same23:12
Fallenouexecuted*23:12
Fallenouram addresses are really alike23:12
wpwrakFallenou: that sounds good. nothing worse than changing bugs that only exist in a flawed simulation23:13
Fallenouhop pushed23:15
wolfspraulyeah sounds nice23:15
wolfspraulsleep well23:15
wolfspraulwpwrak: I don't know, I was curious to find out the reasons pro/con supporting them23:16
wolfspraul(so-dimms)23:16
wolfspraulso yeah, maybe too many pins?23:16
wpwrakyeha, seems they're all 64 bits wide23:16
wpwraknot sure if they would be any more troublesome when it comes to the electrical domain. probably yes.23:17
wolfspraulyou could plug a lot of memories in it which would be both good and bad. bad because we 'have to' support all sorts of stuff and good because it allows for exactly that type of development, if someone is interested23:17
wolfspraulthere must be a cost of the standard, for sure23:17
wpwrakhmm. there might be some reluctance to optimize and generalize the memory controller timing :)23:17
wolfsprauland that is perfectly fine23:17
wpwrakwe could of course select memories we trust. but then you have the problem that modules may change without you even being told23:18
wolfspraulhas the so-dimm connector been the same throughout the entire ddr1/2/3 path?23:18
wpwrakhttp://en.wikipedia.org/wiki/SO-DIMM says there are no less than four different ones23:18
wpwraknot sure how they map to speeds23:19
wpwrakthe wikipedia article links to a data sheet for 200 pins, DDR23:19
Fallenouhttps://github.com/fallen/milkymist-mmu-simulation/compare/44bf4184d2...eac97dc676 and https://github.com/fallen/milkymist-mmu/commit/f3e5eb29d1bab85b7603f45dafc3b4c56f41f9e323:19
wpwraki found one for 144 pin what looks like SDR23:19
Fallenouwpwrak: if you want to look at my recent modifications23:19
Fallenoueven briefly23:20
wpwrakhttp://www.google.com/url?q=http://www.datasheetcatalog.org/datasheet/infineon/1-HYS64V16220GDL.pdf&sa=U&ei=B6dvT8yfD6r40gG_jqHhBg&ved=0CEQQFjAM&usg=AFQjCNH01N1TSODLNHb3a7iB8j6NN8bq1A23:20
Fallenougood night !23:20
wolfsprauln823:20
wpwrakFallenou: so you have delay 0 = 50%, delay 1 = 25%, delay 2 = 12.5%, etc. good23:21
Fallenouwhat delay are you talking about ?23:22
wpwrakthe delay until cko_o is set23:23
wpwrakis set the first time23:23
wpwrakin 50% of all cases, the $random() will add no extra delay23:24
Fallenouyes23:24
wpwrakif the other 50%, it adds at least one cycle of delay23:24
wpwrakthen it's again 50/50. and so on23:24
Fallenouyep23:24
wpwrakso you get a wide variety of different values. of course, the maximum delay can be arbitrarily long23:25
wpwrakbut that's also limited by the PRNG. they usually have finite periods :)23:26
Fallenouusually it does not exceed 6 / 8 times23:26
Fallenouby experimenting23:26
Fallenoulike flipping a coin :'23:27
wpwrakyeah23:27
FallenouI really gotta go, see you tormorrow !23:28
Fallenoutomorrow*23:28
wpwraksweet, unrepeated dreams !23:29
Fallenouhehe hehe hehe hehe hehe hehe23:31
wpwrak:)23:31
--- Mon Mar 26 201200:00

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