| wpwrak | wolfspraul: hmm, a bit tricky then. not very expensive but still. | 01:36 |
|---|---|---|
| wpwrak | one consideration would also be how many of those already made would actually be sellable. e.g., if you're thinking of making a new revision, some of the boards in stock may actually have zero commercial value. | 01:54 |
| wpwrak | (and could be used to sweeten the current M1 offer, my declaring them as a free extra for early adopters) | 01:55 |
| wpwrak | if you can lower the price of the whole system in the future, dropping the jtag would also justify that change to existing customers. | 01:56 |
| wolfspraul | jtag-serial is included with every m1 for the time being | 02:13 |
| wolfspraul | we need to learn much more about who buys it, where, etc. before optimizing this | 02:13 |
| wpwrak | good. so we're on the same page :) | 02:14 |
| wpwrak | btw, did you try to plant M1 at any other news outlet than The Reg ? | 02:18 |
| wolfspraul | no | 02:19 |
| wolfspraul | overloaded | 02:19 |
| wolfspraul | but I work on all this, and of course will continue | 02:19 |
| wpwrak | (overload) hmm. so this also means ... november news then ? :) | 02:21 |
| wolfspraul | ha ha | 02:26 |
| wolfspraul | :-) | 02:26 |
| wolfspraul | you do want to push me into the cemetery faster... | 02:26 |
| kristianpaul | bien, igual .... -_- | 02:26 |
| kristianpaul | oops | 02:26 |
| wolfspraul | yes I am late on that too | 02:26 |
| wolfspraul | I am sitting here explaining m1 to our new China sales person :-) | 02:26 |
| wpwrak | heh, great ! :) | 02:27 |
| wpwrak | (the sales person, not the cemetery :) | 02:27 |
| wolfspraul | the plan is to get it into one reference club, then work with that club to polish the product, in parallel sell that club's success story to other clubs | 02:27 |
| wolfspraul | the sale into the first club is 'almost' a done deal | 02:27 |
| wolfspraul | but I want to see cold hard cash first... | 02:27 |
| wpwrak | reference customers sound like a good idea | 02:28 |
| wpwrak | ;-) | 02:28 |
| wpwrak | they should consider the value of all the free support they're getting. priority access to the product's development team of a globally acting enterprise. where do you find that without putting a six-figure sum on the table ? ;-) | 02:29 |
| wolfspraul | that's the club http://www.acupuncture-records.com/club/lantern-club/?lang=en | 02:30 |
| wpwrak | no pictures ? | 02:36 |
| wpwrak | description sounds good, though. avantgarde, just the right fit | 02:37 |
| wolfspraul | just opened 2 weeks ago | 03:08 |
| wpwrak | hmmm. i locked the usual suspect yet i see this "Checking : flickernoise.fbi(rescue)(CRC) CRC failed". looking forward to a deeper analysis of what happened to my lock bits ... | 05:14 |
| wpwrak | s/suspect/suspects/ | 05:14 |
| kristianpaul | http://cdn.opencores.org/downloads/opencores_coding_guidelines.pdf not bad | 05:19 |
| wolfspraul | kristianpaul: very nice! (downloading, haven't read yet) | 05:33 |
| wolfspraul | kristianpaul: oh my :-) | 05:34 |
| wolfspraul | just look at the usage restrictions on page 2 :-) | 05:34 |
| wolfspraul | opencores, ha ha | 05:34 |
| wolfspraul | some people really always have it backwards | 05:34 |
| wpwrak | and where are the remaining 200 pages of fine print ? there are LOTS of cases they don't cover :) | 05:36 |
| stekern | http://opencores.org/websvn,filedetails?repname=common&path=%2Fcommon%2Ftrunk%2Fopencores_coding_guidelines.pdf | 05:45 |
| stekern | that is the version before the restrictions were added... | 05:46 |
| wolfspraul | seriously? they were *added* at some point? | 05:46 |
| wolfspraul | my god | 05:46 |
| wolfspraul | I mean we all learn, adapt, etc. we see what works and what doesn't work. but the motivation of someone adding this to an existing document must be the weirdest thing I can imagine. | 05:47 |
| wolfspraul | I am 100% sure they did not have cases where those restrictions actually made a difference. So they must have added them just for the heck of it :-) | 05:47 |
| wolfspraul | stekern: ok but that version has no copyright information at all, and with the very specific information on later version I'd hesitate to reuse the older one as a starting point | 05:50 |
| wolfspraul | it seems they don't want to be built upon... | 05:50 |
| stekern | well, "they" are different "theys" in the different versions | 05:51 |
| stekern | also, compare: http://cdn.opencores.org/downloads/wbspec_b3.pdf vs http://cdn.opencores.org/downloads/wbspec_b4.pdf | 05:52 |
| sb0 | do not read any opencores guidelines. they lead to the results we know too well. | 07:11 |
| sb0 | http://www.ohwr.org/documents/24 | 07:19 |
| stekern | I think the opencores guidelines are fairly good, a bit outdated in parts perhaps though | 07:25 |
| stekern | the ohwr ones are good too | 07:26 |
| sb0 | cheap fpga board with sdram and usb: http://www.xess.com/prods/prod048.php | 07:35 |
| kristianpaul | wolfspraul: yeah license is a shame :-/ | 11:15 |
| kristianpaul | stekern: nice memory ;) | 11:17 |
| kristianpaul | i agree with stekern | 11:18 |
| kristianpaul | also opencores is the nearest thing we have to an upstream (for some glue stuff like wishbone, ethernet cores?) :) and yes there is ohwr :-) | 11:20 |
| kristianpaul | http://www.ohwr.org/companies/milky-mist | 11:34 |
| wpwrak | hmm, no hw development, no hw commercialization, no sw development ? | 12:07 |
| wpwrak | hmm, a question about the bitstream format: our standby bitstream ends in ... 00 b0 04 00 ... ff ff ... | 12:43 |
| wpwrak | i understand the 00 b0 and the ff ff but not the 04 00. ff ff is simply uninitialized NOR. | 12:43 |
| wpwrak | 00 b0 must be the DESYNC WORD from table 5-50 page 102 of ug380. i.e., 0x000d, bit-swapped | 12:44 |
| wpwrak | but where does the 04 00 come from ? (or 0x2000, bit-swapped) | 12:45 |
| xiangfu | wpwrak, 0400 bit-swapped is 2000 which is is NOOP, seems there are two many NOOP at the end of bitstream | 13:03 |
| wpwrak | aah, they never introduce it in the document but they use the NOOP at a few places. thanks ! | 13:14 |
| wpwrak | i think the trailing NOOPs in standby.fpd that don't get flashed into the NOR are a mismatch between the file and what urtag expects | 13:14 |
| wpwrak | urtag seems to expect file data to be a multiple of a certain size, maybe N*16 bytes. anything that's not such a multiple is ignored | 13:15 |
| wpwrak | and the file doesn't have such padding | 13:15 |
| wpwrak | i guess urtag should either do the padding itself or complain if it's given a file with an unaligned size | 13:16 |
| xiangfu | wpwrak, yes. | 13:17 |
| xiangfu | needs to read more document and the urjtag code :) | 13:18 |
| wpwrak | hmm, http://www.milkymist.org seems to have troubles | 15:35 |
| kristianpaul | ah still | 15:35 |
| wpwrak | apparently some database backend not responding | 15:35 |
| mwalle | wpwrak: the bitstream loading code? | 20:14 |
| mwalle | (padding, multiple of N) | 20:14 |
| wpwrak | yes | 20:14 |
| wpwrak | well, the bitstream flashing code | 20:15 |
| mwalle | mh? | 20:15 |
| mwalle | fjmem ? | 20:15 |
| wpwrak | file -> NOR. somewhere along the path, something seems to go wrong with unpadded files | 20:15 |
| mwalle | mh, ok no code from me expect the fjmem core ;) | 20:16 |
| wpwrak | hehe :) | 20:17 |
| --- Wed Oct 12 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!