| kristianpaul | kvm :) | 01:40 |
|---|---|---|
| kristianpaul | wolfspraul: pragmatic and elaborate solution :) | 01:41 |
| kristianpaul | in theory jtag should be pushed in F16 repos in any moment?.. well bug still showing it wil.. | 01:42 |
| kristianpaul | lekernel: that migen logo remenber me a lot geda website :) | 01:56 |
| wolfspraul | installed xiangfu's jan22 daily build (that seems to be the last one), and with that I can get neither mouse nor keyboard to work | 10:19 |
| wolfspraul | yes, official one | 10:42 |
| wolfspraul | but all sorts of things can be wrong with those daily builds | 10:44 |
| wolfspraul | they regularly break, nobody is testing them, etc. | 10:44 |
| wpwrak | hmm. i don't remember if i ever tried that one. lemme see .. | 10:44 |
| wolfspraul | just some binary garbage essentially :-) | 10:44 |
| wpwrak | works for me (tm) ;-) | 10:47 |
| wolfspraul | keyboard and mouse works? | 10:48 |
| wolfspraul | how did you flash? | 10:48 |
| wpwrak | so, i mean the keyboard works for me | 10:48 |
| wpwrak | didn't change my system | 10:49 |
| wolfspraul | oh, sure | 10:49 |
| wolfspraul | :-) | 10:49 |
| wpwrak | lemme find the ingredients of my system ... | 10:50 |
| wpwrak | hmm. now my jtag board doesn't enumerate. interesting. | 11:01 |
| wpwrak | gone fragile. swapped cable, then it enumerated 2/3 times. | 11:07 |
| wolfspraul | is it coming back to life? you think something may have broken? | 11:12 |
| wpwrak | now it seems to work again. not sure what's up | 11:13 |
| wpwrak | and it boots. excellent ;-) | 11:15 |
| wpwrak | http://downloads.qi-hardware.com/people/werner/tmp/m1-20120125/ | 11:19 |
| wpwrak | download and then m1nor * should do the trick | 11:19 |
| wpwrak | in case you don't have m1nor yet, it's here: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/tools/m1nor | 11:20 |
| qi-bot | The Openwrt build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-01252012-1258/ | 12:57 |
| wpwrak | wolfspraul: so ... any more luck with my files ? | 13:37 |
| wolfspraul | haven'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/530ae74293cf9f74621ce323af159ac887469056 | 15:52 |
| GitHub71 | [milkymist/master] libfpvm: added operators for logical AND and OR (untested, WIP) - Werner Almesberger | 15:52 |
| wpwrak | do 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 though | 16:06 |
| lekernel_ | and the rtems rigmarole is much smaller than linux's | 16:06 |
| lekernel_ | :) | 16:06 |
| kristianpaul | if you figureout how use write command tell me :) | 16:10 |
| kristianpaul | i mean for writing values nigger than 32bits.. | 16:11 |
| kristianpaul | several* | 16:11 |
| wpwrak | lekernel_: still a bit excessive for the LED testing ... | 16:12 |
| lekernel_ | you can use mr/mw in the BIOS, too | 16:13 |
| lekernel_ | btw the BIOS has a framebuffer and USB keyboard support, just press ESC when booting ... | 16:13 |
| wpwrak | ah, easy then. thanks ! | 16:13 |
| wpwrak | yes yes, been there a number of times :) | 16:13 |
| lekernel_ | hardcoded german layout though :p | 16:13 |
| wpwrak | at least it's not french :) | 16:14 |
| larsc | hm, a 1920x1200 framebuffer console on a 80Mhz softcore feels worse than a remote console over dialup | 16:44 |
| wpwrak | now, add some beefy graphics acceleration ;-) | 16:45 |
| larsc | is my math wrong or is that actually 70MB pixeldata? | 16:47 |
| Fallenou | I get 6.5 MB (I think it's 24bpp) | 16:48 |
| larsc | ah right, 70 Mbit | 16:50 |
| larsc | but even at 80Mhz copying 6 MB should take several seconds, should it? | 16:52 |
| wpwrak | depends on how you do it ;-) | 16:56 |
| larsc | dd | 16:57 |
| wpwrak | volatile 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 |
| larsc | not for the milkymist ;) | 17:01 |
| wpwrak | hmm, 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 firmware | 17:02 |
| wpwrak | excellent, thanks | 17:02 |
| qi-bot | The 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/009ebd11067910c364522f18d46d45b26aacd3cc | 19:06 |
| GitHub120 | [migen/master] doc: refactor - Sebastien Bourdeauducq | 19:06 |
| kristianpaul | does 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/21f3def74b83064e5a46a428a18af7ae3d7fbe0b | 19:15 |
| GitHub0 | [migen/master] Remove duplicate logo - Sebastien Bourdeauducq | 19:15 |
| lekernel_ | kristianpaul: cleared after read is not possible on the CSR bus due to the absence of a read qualification signal | 19:15 |
| kristianpaul | could i add that qualification signal like the IDLE state but also for read | 19:22 |
| kristianpaul | or how you think this could be implemented | 19:22 |
| kristianpaul | ? | 19:22 |
| larsc | clear-on-read is one of the most stupid things you can do in interface design | 19:28 |
| larsc | especially on a fast bus | 19:28 |
| kristianpaul | larsc: do you like register work flow like in xburst? | 19:29 |
| kristianpaul | larsc: i was using a separate clear signal | 19:29 |
| larsc | kristianpaul: yes do that | 19:29 |
| kristianpaul | is it still not very good practice? | 19:29 |
| kristianpaul | or what do you suguest? | 19:29 |
| kristianpaul | good, no regrets then :) | 19:29 |
| larsc | make it clear-on-write | 19:29 |
| larsc | clear-on-read changes the semantics of read | 19:29 |
| larsc | of the read operation | 19:30 |
| wpwrak | larsc: (clear on read) what makes you think it's stupid ? e.g., with fifos, it saves you one bus cycle | 20:07 |
| larsc | wpwrak: fifos are imo the only legitimate usage of this scheme, because it has well defined syntax and it is not really 'clear' | 20:11 |
| larsc | but i also think you should avoid sticking fifos in the control interface of a core | 20:12 |
| wpwrak | i 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 |
| larsc | because you can't peak into the register anymore | 20:15 |
| kristianpaul | read with a clear anyway, yes | 20:15 |
| larsc | reading the register is the only possibility to get the value of the register | 20:17 |
| wpwrak | so ... ? once you've read it, you have a perfectly good copy of the value | 20:18 |
| larsc | if you make the read operation destructive you imply that nobody will ever want to read the value without clearing it | 20:18 |
| larsc | which is a pretty bold statement | 20:18 |
| wpwrak | doesn't seem very bold to me ;-) it's just the semantics of the interface | 20:19 |
| wpwrak | a registers may change with time anyway. so there's no guarantee that successive reads will produce anything meaningful (in general) | 20:19 |
| wpwrak | e.g., consider a watchdog counter | 20:20 |
| wpwrak | you 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 |
| larsc | i want to be able to read the watchdog counter without clearing it | 20:20 |
| wpwrak | maybe | 20:21 |
| larsc | what might work is have two different addresses for the value, one which is clear-on-read the other which is not | 20:21 |
| larsc | but i still dont like that | 20:21 |
| wpwrak | also, if the software explicitly clears the register, your read at t+1 will fail, too | 20:22 |
| wpwrak | yes, that's a possibility | 20:22 |
| larsc | clearing on read is imo similar to write on read | 20:23 |
| larsc | andin my opinion just not good design | 20:24 |
| wpwrak | ah, how about an event counter ? you do the lowest bits in hw, the rest in sw. and you want to poll periodically. | 20:24 |
| wpwrak | then an atomic clear-on-read makes perfect sense | 20:25 |
| larsc | unless you want to start to debug the whole thing | 20:27 |
| wpwrak | where's the problem with debugging it ? | 20:27 |
| kristianpaul | once read, never back :) | 20:27 |
| kristianpaul | ? | 20:27 |
| larsc | exactly | 20:27 |
| wpwrak | a read at t+1 may produce a result completely different from a read at time t anyway | 20:28 |
| wpwrak | due to the nature of the process | 20:28 |
| kristianpaul | perhaps wpwrak, in my case is a register in wich bit is an interupt flag | 20:28 |
| wpwrak | and you can always store the old value in a buffer if you really need it | 20:28 |
| larsc | but it will be >= the original value | 20:28 |
| kristianpaul | but yes i still know how many interupts where generated.. | 20:29 |
| kristianpaul | s/know/dont know | 20:29 |
| kristianpaul | wpwrak: store good catch :) | 20:29 |
| wpwrak | larsc: 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 |
| kristianpaul | oh well :) | 20:30 |
| larsc | wpwrak: no, but i assume that i don't want to modify the code read the register | 20:31 |
| wpwrak | larsc: but you have a debugger ? | 20:31 |
| larsc | maymbe | 20:32 |
| larsc | maby not | 20:32 |
| wpwrak | it seems they make you work with very unfriendly systems ;-) | 20:32 |
| larsc | wpwrak: yes, those whic have read on clear registers | 20:33 |
| wpwrak | the world is full of atomic transactions ... | 20:33 |
| larsc | read-on-clear should just not be one of them | 20:35 |
| wpwrak | i 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 |
| larsc | i can only repeat what i said before | 20:37 |
| wpwrak | maybe you just spent a lot of time on a system that didn't use clear-on-read correctly ? | 20:37 |
| larsc | maybe | 20:38 |
| wpwrak | kristianpaul: 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 retrieval | 20:40 |
| wpwrak | kristianpaul: of course, in the case of interrupts, often an explicit clear/ack register will do, too, and is simpler | 20:42 |
| larsc | wpwrak: actually my debug code wants to read the value before | 20:42 |
| wpwrak | no 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 |
| larsc | no. i want non-destructive read operations ;) | 20:47 |
| kristianpaul | wpwrak: yes i already have a explicit clear register, so wa thinking i wanted clear on read to save time ;) | 20:48 |
| larsc | wpwrak: 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 it | 20:53 |
| wpwrak | yeah, agreed. being able to monitor things non-destructively is often useful | 20:59 |
| Action: kristianpaul agree with non-destructively too | 21:00 | |
| larsc | and yes, it has been the case that with all systems i worked with which had clear-on-read there was no way to do this | 21:01 |
| wpwrak | what can also be galling are write-only registers | 21:03 |
| larsc | exactly | 21:03 |
| larsc | because you can't confirm that the value you though you wrote actually made it to the register | 21:03 |
| Action: kristianpaul hate write-only registers | 21:04 | |
| kristianpaul | cause 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 | |
| wpwrak | the value you or someone else wrote :) | 21:05 |
| wpwrak | lekernel_: btw, you have a bad link on http://milkymist.org/wp/for-developers/ | 21:06 |
| wpwrak | lekernel_: the master thesis leads to http://milkymist.org/wp/for-developers/milkymist.org/thesis/thesis.pdf | 21:06 |
| kristianpaul | (namuru), well i actually had read-after write and had lots ofwrite-only registers | 21:07 |
| kristianpaul | not anymore :) | 21:07 |
| mwalle | hi | 21:07 |
| kristianpaul | hello :) | 21:07 |
| mwalle | Fallenou: so youre starting a lm32 mmu project? nice :) | 21:08 |
| larsc | kristianpaul: also write-on-read registers? | 21:08 |
| wpwrak | and the thesis contains the following dead link: http://www.milkymist.org/doc/csr.pdf | 21:09 |
| mwalle | Fallenou: btw there are four (or five?) unused opcodes, two reserved ones and div/mod (there is only a divu and modu iirc) | 21:10 |
| wpwrak | how .. where is the description of the csr bus now ? | 21:10 |
| larsc | wpwrak: socdoc/csr.pdf | 21:10 |
| mwalle | s/doc/socdoc/ for all docs ;) | 21:11 |
| wpwrak | thanks ! | 21:11 |
| kristianpaul | s/read-after/clear-after/ | 21:20 |
| kristianpaul | larsc: nope | 21:21 |
| kristianpaul | or milkymist/doc/csr.tex | 21: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 it | 21:24 | |
| kristianpaul | gateware? | 21:31 |
| kristianpaul | ah yes | 21:32 |
| wpwrak | ;-) | 21:33 |
| kristianpaul | similar micosystem, wich already include some driver template code even :) | 21:34 |
| wpwrak | rule #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 |
| Fallenou | hey mwalle :) | 21:38 |
| Fallenou | yep I'm working on the MMU ! | 21:46 |
| Fallenou | mwalle: (unused opcodes) oh great ! I thought everything was used when looking at the opcode table in lm32_arch.pdf | 21:46 |
| Fallenou | I started to implement tlb management using CSR registers :x | 21:47 |
| mwalle | Fallenou: ah another remark, there are more than 7 csr registers, i guess you already found that ou | 21:56 |
| Fallenou | mwalle: they are 10 ? something like this ? | 22:19 |
| Fallenou | I count 10 in the datasheet | 22:19 |
| Fallenou | it depends on the configuration | 22:19 |
| wpwrak | kewl. so you can't pass an array slice in verilog ? or is that just xilinx braindamage ? | 22:37 |
| mwalle | Fallenou: there are at least 16 iirc see the debug registers | 22:37 |
| mwalle | Fallenou: but you may not use the csr index even if its not enabled in the configuration | 22:37 |
| larsc | wpwrak: you can. or what exactly do you mean? | 22:47 |
| wpwrak | e.g., i have this: reg [7:0] led [0:2][0:1][0:3] | 22:49 |
| wpwrak | and a task that takes reg [7:0] foo [0:3] | 22:49 |
| wpwrak | and then i try to pass led[x][y] | 22:50 |
| wpwrak | HDLCompiler is not amused | 22:50 |
| lekernel_ | wpwrak: you shouldn't use reg[...] unless you're inferring a RAM, and then, only unidimensional arrays are correctly supported | 22:52 |
| lekernel_ | wpwrak: use migen :p | 22:53 |
| mwalle | gn8 | 22:54 |
| wpwrak | hmm. 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 appropriate | 22:54 |
| lekernel_ | yes, but they do not work correctly in verilog | 22:55 |
| wpwrak | you mean it will mis-compile ? or just reject certain uses | 22:55 |
| wpwrak | (i got it past compilation now. i just calculate the index at a later point. mercifully, scoping works) | 22:56 |
| lekernel_ | mh? | 22:58 |
| lekernel_ | how do you calculate the index? and what is "scoping"? | 22:58 |
| wpwrak | for example, led[row][dir][col] <= ... | 22:58 |
| lekernel_ | and xst works with that? that must be pretty new... | 22:59 |
| wpwrak | before, i tried to pass led[row][dir] into a task and just access foo[col] | 22:59 |
| wpwrak | but it didn't like that | 22:59 |
| lekernel_ | if you used migen you could do this sort of thing :) | 22:59 |
| wpwrak | maybe they came back from lunch and started working on that compiler again ? ;-) | 23:00 |
| wpwrak | yeah, i realize that there's a lot of hard-coding i could probably avoid with migen :) | 23:00 |
| larsc | hmpf... phone, which I use as a internet modem, hard-locked, probably due to kernel crash, unpluged phone, kernel on laptop crashed.... | 23:00 |
| wpwrak | ah, 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 |
| larsc | it does, i think | 23:02 |
| wpwrak | reg foo; ... foo <= 0; /* what could possibly go wrong here ? */ | 23:02 |
| wpwrak | and 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 counter | 23:03 |
| wpwrak | which is precisely what i want :) | 23:04 |
| wpwrak | pity that i can't use bit <= x; | 23:05 |
| lekernel_ | you shouldn't quite use x ... it's not so well implemented | 23:06 |
| lekernel_ | there are some gotches | 23:06 |
| lekernel_ | gotchas | 23:06 |
| wpwrak | verilog feels a bit like a slightly retarded child that's already been in bad company. bad uncle pascal, for example. | 23:07 |
| wpwrak | i 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 |
| wpwrak | okay. the next run will use z :) | 23:09 |
| wpwrak | the 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 != tristate | 23:12 |
| lekernel_ | it's "undefined" | 23:12 |
| lekernel_ | if you send x on a I/O, it'll become 0 I think | 23:12 |
| wpwrak | in 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 x | 23:14 |
| wpwrak | hmm right, that was flash_do, not flash_d. something else | 23:15 |
| larsc | lekernel: http://metafoo.de/flow3.png i think that's what you call sequential and pipeline delay | 23:18 |
| wpwrak | very cool. the leds happily blink. in a completely nonsensical pattern. but something seems to happen ;-) | 23:18 |
| larsc | wasn't x supposed to be for simulation only anyway? | 23:20 |
| lekernel | larsc: what's * ? | 23:23 |
| lekernel | and no, x is synthesizable and allows for some optimization | 23:23 |
| lekernel | but it can cause simulation problems and synthesis/simulation mismatches, which are quite annoying | 23:23 |
| larsc | yes, the block with the * is a bit special. starts of with a token to give away at reset | 23:24 |
| lekernel | no but the sequential stuff means take an input token, process (without accepting/producing tokens) for N cycle, generate an output token | 23:24 |
| lekernel | it has nothing to do with reset/initial behaviour | 23:25 |
| lekernel | for 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 finished | 23:26 |
| larsc | thats just for the model | 23:27 |
| lekernel | by comparison the pipeline would also take N cycles, but would always be capable of accepting new tokens | 23:27 |
| larsc | so, yes that's what i wanted to represent in the figure | 23:28 |
| larsc | have you ever heared of petri-nets? | 23:29 |
| lekernel | remotely | 23:30 |
| larsc | thats kind of like petri-nets | 23:30 |
| larsc | transitions fire when all input places have a token | 23:31 |
| lekernel | ah, i see | 23:31 |
| wpwrak | i guess there's no easy way to zero-initialize an entire array ? | 23:32 |
| lekernel | so you have that "virtual" token that disables the internal pipeline until it has finished | 23:32 |
| lekernel | wpwrak: you can use a for loop (assuming it still works with multidimensional arrays) | 23:32 |
| wpwrak | oh ! loops !! :) | 23:33 |
| lekernel | wpwrak: 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 synthesizer | 23:33 |
| lekernel | wpwrak: plus the next SoC will use migen, so that would be one less bit of code to convert | 23:33 |
| wpwrak | it's a small bit of code :) | 23:33 |
| larsc | lekernel: yes | 23:35 |
| larsc | if you'd model the divider this way you'd end up with N small box in row, which would be the same | 23:36 |
| larsc | contain the same logic | 23:36 |
| larsc | what your divider implementation allready does is the timesharing | 23:37 |
| larsc | since we know that only one of the blocks will be in use at a time | 23:37 |
| larsc | the virtual token is replaced by a counter | 23:38 |
| larsc | so if you'd for example model a pipelined divider you'd use the same model except for the virtual token | 23:39 |
| wpwrak | wolfspraul: btw, any luck with the upgrade ? :) | 23:50 |
| wpwrak | wolfspraul: success should be within microns now ;-) | 23:51 |
| --- Thu Jan 26 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
