#milkymist IRC log for Wednesday, 2012-01-25

kristianpaulkvm :)01:40
kristianpaulwolfspraul: pragmatic and elaborate solution :)01:41
kristianpaulin theory jtag should be pushed in F16 repos in any moment?.. well bug still showing it wil..01:42
kristianpaullekernel: that migen logo remenber me a lot geda website :)01:56
wolfspraulinstalled xiangfu's jan22 daily build (that seems to be the last one), and with that I can get neither mouse nor keyboard to work10:19
wolfspraulyes, official one10:42
wolfspraulbut all sorts of things can be wrong with those daily builds10:44
wolfspraulthey regularly break, nobody is testing them, etc.10:44
wpwrakhmm. i don't remember if i ever tried that one. lemme see ..10:44
wolfsprauljust some binary garbage essentially :-)10:44
wpwrakworks for me (tm) ;-)10:47
wolfspraulkeyboard and mouse works?10:48
wolfspraulhow did you flash?10:48
wpwrakso, i mean the keyboard works for me10:48
wpwrakdidn't change my system10:49
wolfsprauloh, sure10:49
wpwraklemme find the ingredients of my system ...10:50
wpwrakhmm. now my jtag board doesn't enumerate. interesting.11:01
wpwrakgone fragile. swapped cable, then it enumerated 2/3 times.11:07
wolfspraulis it coming back to life? you think something may have broken?11:12
wpwraknow it seems to work again. not sure what's up11:13
wpwrakand it boots. excellent ;-)11:15
wpwrakdownload and then  m1nor *  should do the trick11:19
wpwrakin case you don't have m1nor yet, it's here: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/tools/m1nor11:20
qi-botThe Openwrt build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-01252012-1258/12:57
wpwrakwolfspraul: so ... any more luck with my files ?13:37
wolfspraulhaven't tried yet, need to do some shopping, post office etc.13:41
GitHub71[milkymist] wpwrak pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/530ae74293cf9f74621ce323af159ac88746905615:52
GitHub71[milkymist/master] libfpvm: added operators for logical AND and OR (untested, WIP) - Werner Almesberger15:52
wpwrakdo we have a place where flickernoise writes to registers directly ? i'm too lazy to do the whole rtems rigmarole :)15:54
lekernel_wpwrak: no, we don't... there might be some commands in the shell to read/write memory though16:06
lekernel_and the rtems rigmarole is much smaller than linux's16:06
kristianpaulif you figureout how use write command tell me :)16:10
kristianpauli mean for writing values nigger than 32bits..16:11
wpwraklekernel_: still a bit excessive for the LED testing ...16:12
lekernel_you can use mr/mw in the BIOS, too16:13
lekernel_btw the BIOS has a framebuffer and USB keyboard support, just press ESC when booting ...16:13
wpwrakah, easy then. thanks !16:13
wpwrakyes yes, been there a number of times :)16:13
lekernel_hardcoded german layout though :p16:13
wpwrakat least it's not french :)16:14
larschm, a 1920x1200  framebuffer console on a 80Mhz softcore feels worse than a remote console over dialup16:44
wpwraknow, add some beefy graphics acceleration ;-)16:45
larscis my math wrong or is that actually 70MB pixeldata?16:47
FallenouI get 6.5 MB (I think it's 24bpp)16:48
larscah right, 70 Mbit16:50
larscbut even at 80Mhz copying 6 MB should take several seconds, should it?16:52
wpwrakdepends on how you do it ;-)16:56
wpwrakvolatile int BPP; volatile unsigned char *fb; for (x = 0; x != XMAX*BPP; x++) for (y = 0; y != YMAX-1; y++) fb[y*XMAX*BPP+x] = fb[(y+1)*XMAX*BPP+x]; /* this will be a little slow :) */16:58
lekernel_larsc: you implemented 1920x1200?17:00
larscnot for the milkymist ;)17:01
wpwrakhmm, does anything depend on FMLMETER being around ?17:02
wpwrak(looking for something i can safely kick off the CSR bus)17:02
lekernel_wpwrak: no, it was only used in the demo firmware17:02
wpwrakexcellent, thanks17:02
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01252012-1656/17:44
GitHub120[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/009ebd11067910c364522f18d46d45b26aacd3cc19:06
GitHub120[migen/master] doc: refactor - Sebastien Bourdeauducq19:06
kristianpauldoes the sysctl have a cleared after read register? seems not..19:13
GitHub0[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/21f3def74b83064e5a46a428a18af7ae3d7fbe0b19:15
GitHub0[migen/master] Remove duplicate logo - Sebastien Bourdeauducq19:15
lekernel_kristianpaul: cleared after read is not possible on the CSR bus due to the absence of a read qualification signal19:15
kristianpaulcould i  add that qualification signal  like the IDLE state but also for read19:22
kristianpaulor how you think this could be implemented19:22
larscclear-on-read is one of the most stupid things you can do in interface design19:28
larscespecially on a fast bus19:28
kristianpaullarsc: do you like register work flow like in xburst?19:29
kristianpaullarsc: i was using a separate clear signal19:29
larsckristianpaul: yes do that19:29
kristianpaulis it still not very good practice?19:29
kristianpaulor what do you suguest?19:29
kristianpaulgood, no regrets then :)19:29
larscmake it clear-on-write19:29
larscclear-on-read changes the semantics of read19:29
larscof the read operation19:30
wpwraklarsc: (clear on read) what makes you think it's stupid ? e.g., with fifos, it saves you one bus cycle20:07
larscwpwrak: fifos are imo the only legitimate usage of this scheme, because it has well defined syntax and it is not really 'clear'20:11
larscbut i also think you should avoid sticking fifos in the control interface of a core20:12
wpwraki guess it depends on the sematics of what you're doing. if you'll always follow a read with a clear anyway, why not put them in the same bus cycle ?20:14
larscbecause you can't peak into the register anymore20:15
kristianpaulread with a clear anyway, yes20:15
larscreading the register is the only possibility to get the value of the register20:17
wpwrakso ... ? once you've read it, you have a perfectly good copy of the value20:18
larscif you make the read operation destructive you imply that nobody will ever want to read the value without clearing it20:18
larscwhich is a pretty bold statement20:18
wpwrakdoesn't seem very bold to me ;-) it's just the semantics of the interface20:19
wpwraka registers may change with time anyway. so there's no guarantee that successive reads will produce anything meaningful (in general)20:19
wpwrake.g., consider a watchdog counter20:20
wpwrakyou may want to know how close to expiration you are when you kick the dog. so that you can issue a warning if you're getting too close.20:20
larsci want to be able to read the watchdog counter without clearing it20:20
larscwhat might work is have two different addresses for the value, one which is clear-on-read the other which is not20:21
larscbut i still dont like that20:21
wpwrakalso, if the software explicitly clears the register, your read at t+1 will fail, too20:22
wpwrakyes, that's a possibility20:22
larscclearing on read is imo similar to write on read20:23
larscandin my opinion just not good design20:24
wpwrakah, how about an event counter ? you do the lowest bits in hw, the rest in sw. and you want to poll periodically.20:24
wpwrakthen an atomic clear-on-read makes perfect sense20:25
larscunless you want to start to debug the whole thing20:27
wpwrakwhere's the problem with debugging it ?20:27
kristianpaulonce read, never back :)20:27
wpwraka read at t+1 may produce a result completely different from a read at time t anyway20:28
wpwrakdue to the nature of the process20:28
kristianpaulperhaps wpwrak, in my case is a register in wich bit is an interupt flag20:28
wpwrakand you can always store the old value in a buffer if you really need it20:28
larscbut it will be >= the original value20:28
kristianpaulbut yes i still know how many interupts where generated..20:29
kristianpauls/know/dont know20:29
kristianpaulwpwrak: store good catch :)20:29
wpwraklarsc: sure. but why would it be hard for you to read it from memory instead ? do you assume you have no access to the code ?20:29
kristianpauloh well :)20:30
larscwpwrak: no, but i assume that i don't want to modify the code read the register20:31
wpwraklarsc: but you have a debugger ?20:31
larscmaby not20:32
wpwrakit seems they make you work with very unfriendly systems ;-)20:32
larscwpwrak: yes, those whic have read on clear registers20:33
wpwrakthe world is full of atomic transactions ...20:33
larscread-on-clear should just not be one of them20:35
wpwraki really don't see anything inherently wrong with clear on read. this basically gives you transactional semantics: after the read, you have retrieved the token and it's now whatever location you've read to.20:35
larsci can only repeat what i said before20:37
wpwrakmaybe you just spent a lot of time on a system that didn't use clear-on-read correctly ?20:37
wpwrakkristianpaul: btw, the backup plan for you would be to have a read-and-clear-on-write: you have a special write cycle that copies the internal "live" register to a bus-accessible buffer register and atomically clears the "live" register. then you can read the buffer. and lars-in-debug-mode can do, afterwards, too :) as long as you don't trigger another retrieval20:40
wpwrakkristianpaul: of course, in the case of interrupts, often an explicit clear/ack register will do, too, and is simpler20:42
larscwpwrak: actually my debug code wants to read the value before20:42
wpwrakno luck then. but maybe what you really want is a clock gate :)20:44
wpwrak"stop the world from spinning so quickly while i'm busy debugging it". it has a nice ring to it.20:44
larscno. i want non-destructive read operations ;)20:47
kristianpaulwpwrak: yes i already have a explicit clear register, so wa thinking i wanted clear on read to save time ;)20:48
larscwpwrak: thanks for the input, i guess i'm not completely against clear-on-read, but against having no way of reading a value without destroying it20:53
wpwrakyeah, agreed. being able to monitor things non-destructively is often useful20:59
Action: kristianpaul agree with non-destructively too21:00
larscand yes, it has been the case that with all systems i worked with which had clear-on-read there was no way to do this21:01
wpwrakwhat can also be galling are write-only registers21:03
larscbecause you can't confirm that the value you though you wrote actually made it to the register21:03
Action: kristianpaul hate write-only registers21:04
kristianpaulcause i cant debug, and verify what i wrote, afortunatly all is in HDL :)21:04
Action: kristianpaul dont feel bad about making those destitions with namuru core even if wroke upstream desing ;)21:05
wpwrakthe value you or someone else wrote :)21:05
wpwraklekernel_: btw, you have a bad link on http://milkymist.org/wp/for-developers/21:06
wpwraklekernel_: the master thesis leads to http://milkymist.org/wp/for-developers/milkymist.org/thesis/thesis.pdf21:06
kristianpaul(namuru), well i actually had read-after write and had lots ofwrite-only registers21:07
kristianpaulnot anymore :)21:07
kristianpaulhello :)21:07
mwalleFallenou: so youre starting a lm32 mmu project? nice :)21:08
larsckristianpaul: also write-on-read registers?21:08
wpwrakand the thesis contains the following dead link: http://www.milkymist.org/doc/csr.pdf21:09
mwalleFallenou: btw there are four (or five?) unused opcodes, two reserved ones and div/mod (there is only a divu and modu iirc)21:10
wpwrakhow .. where is the description of the csr bus now ?21:10
larscwpwrak: socdoc/csr.pdf21:10
mwalles/doc/socdoc/ for all docs ;)21:11
wpwrakthanks !21:11
kristianpaullarsc: nope21:21
kristianpaulor milkymist/doc/csr.tex21:22
Action: wpwrak wonders if it wouldn't be nice to move all the rtl/ under cores/ up one level. so that the gateware is the first thing you see, with things like tests and documentation subordinate to it21:24
kristianpaulah yes21:32
kristianpaulsimilar micosystem, wich already include some driver template code even :)21:34
wpwrakrule #6 of hiding projects in plain view: change project-specific terminology frequently so only the most active participants will know what you're talking about :)21:34
Fallenouhey mwalle :)21:38
Fallenouyep I'm working on the MMU !21:46
Fallenoumwalle: (unused opcodes) oh great ! I thought everything was used when looking at the opcode table in lm32_arch.pdf21:46
FallenouI started to implement tlb management using CSR registers :x21:47
mwalleFallenou: ah another remark, there are more than 7 csr registers, i guess you already found that ou21:56
Fallenoumwalle: they are 10 ? something like this ?22:19
FallenouI count 10 in the datasheet22:19
Fallenouit depends on the configuration22:19
wpwrakkewl. so you can't pass an array slice in verilog ? or is that just xilinx braindamage ?22:37
mwalleFallenou: there are at least 16 iirc see the debug registers22:37
mwalleFallenou: but you may not use the csr index even if its not enabled in the configuration22:37
larscwpwrak: you can. or what exactly do you mean?22:47
wpwrake.g., i have this: reg [7:0] led [0:2][0:1][0:3]22:49
wpwrakand a task that takes  reg [7:0] foo [0:3]22:49
wpwrakand then i try to pass  led[x][y]22:50
wpwrakHDLCompiler is not amused22:50
lekernel_wpwrak: you shouldn't use reg[...] unless you're inferring a RAM, and then, only unidimensional arrays are correctly supported22:52
lekernel_wpwrak: use migen :p22:53
wpwrakhmm. the led matrix has three dimensions: row, column, and the direction in a pair. i have a duty cycle value from 0-255 for each. so the three-dimensional array seems kinda appropriate22:54
lekernel_yes, but they do not work correctly in verilog22:55
wpwrakyou mean it will mis-compile ? or just reject certain uses22:55
wpwrak(i got it past compilation now. i just calculate the index at a later point. mercifully, scoping works)22:56
lekernel_how do you calculate the index? and what is "scoping"?22:58
wpwrakfor example, led[row][dir][col] <= ...22:58
lekernel_and xst works with that? that must be pretty new...22:59
wpwrakbefore, i tried to pass led[row][dir] into a task and just access foo[col]22:59
wpwrakbut it didn't like that22:59
lekernel_if you used migen you could do this sort of thing :)22:59
wpwrakmaybe they came back from lunch and started working on that compiler again ? ;-)23:00
wpwrakyeah, i realize that there's a lot of hard-coding i could probably avoid with migen :)23:00
larschmpf... phone, which I use as a internet modem, hard-locked, probably due to kernel crash, unpluged phone, kernel on laptop crashed....23:00
wpwrakah, and xst doesn't insist on me specifying the sizes of constants all the time. i take that as a good sign :)23:01
lekernel_doesn't it assume 32?23:01
larscit does, i think23:02
wpwrakreg foo; ... foo <= 0; /* what could possibly go wrong here ? */23:02
wpwrakand i also hope xst knows enough modulo arithmetic to avoid making a mess with  reg [7:0] foo;  ...  foo <= foo+1;23:03
lekernel_you get a plain 8 bit counter23:03
wpwrakwhich is precisely what i want :)23:04
wpwrakpity that i can't use  bit <= x;23:05
lekernel_you shouldn't quite use x ... it's not so well implemented23:06
lekernel_there are some gotches23:06
wpwrakverilog feels a bit like a slightly retarded child that's already been in bad company. bad uncle pascal, for example.23:07
wpwraki was about to say that i needed "x" for my tree-state lines. but then i realized that z will do nicely, too. too much looking at how NOR switches the direction, i guess ...23:08
wpwrakokay. the next run will use z :)23:09
wpwrakthe amount of warnings is frightening. and they completely obscure any diagnostics relevant to my code. i wonder how you ever got that to work ...23:11
lekernel_x != tristate23:12
lekernel_it's "undefined"23:12
lekernel_if you send x on a I/O, it'll become 0 I think23:12
wpwrakin NOR, you seem to use it switch the data lines to input. or maybe i misunderstood how that works.23:13
lekernel_assign flash_d = flash_oe_n ? flash_do : 16'bz;23:14
lekernel_it's z, not x23:14
wpwrakhmm right, that was flash_do, not flash_d. something else23:15
larsclekernel: http://metafoo.de/flow3.png i think that's what you call sequential and pipeline delay23:18
wpwrakvery cool. the leds happily blink. in a completely nonsensical pattern. but something seems to happen ;-)23:18
larscwasn't x supposed to be for simulation only anyway?23:20
lekernellarsc: what's * ?23:23
lekerneland no, x is synthesizable and allows for some optimization23:23
lekernelbut it can cause simulation problems and synthesis/simulation mismatches, which are quite annoying23:23
larscyes, the block with the * is a bit special. starts of with a token to give away at reset23:24
lekernelno but the sequential stuff means take an input token, process (without accepting/producing tokens) for N cycle, generate an output token23:24
lekernelit has nothing to do with reset/initial behaviour23:25
lekernelfor example, the divider uses the sequential model: it takes two N bits number in one token, then is busy computing quotient and remainder which takes N cycles (and it cannot start new computations during that time), and outputs a token with them when it's finished23:26
larscthats just for the model23:27
lekernelby comparison the pipeline would also take N cycles, but would always be capable of accepting new tokens23:27
larscso, yes that's what i wanted to represent in the figure23:28
larschave you ever heared of petri-nets?23:29
larscthats kind of like petri-nets23:30
larsctransitions fire when all input places have a token23:31
lekernelah, i see23:31
wpwraki guess there's no easy way to zero-initialize an entire array ?23:32
lekernelso you have that "virtual" token that disables the internal pipeline until it has finished23:32
lekernelwpwrak: you can use a for loop (assuming it still works with multidimensional arrays)23:32
wpwrakoh ! loops !! :)23:33
lekernelwpwrak: but why don't you use migen? you could generate a series of assignment statements very easily, which are guaranteed to work with the most stupid synthesizer23:33
lekernelwpwrak: plus the next SoC will use migen, so that would be one less bit of code to convert23:33
wpwrakit's a small bit of code :)23:33
larsclekernel: yes23:35
larscif you'd model the divider this way you'd end up with N small box in row, which would be the same23:36
larsccontain the same logic23:36
larscwhat your divider implementation allready does is the timesharing23:37
larscsince we know that only one of the blocks will be in use at a time23:37
larscthe virtual token is replaced by a counter23:38
larscso if you'd for example model a pipelined divider you'd use the same model except for the virtual token23:39
wpwrakwolfspraul: btw, any luck with the upgrade ? :)23:50
wpwrakwolfspraul: success should be within microns now ;-)23:51
--- Thu Jan 26 201200:00

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