wolfspraul | kristianpaul: I've just sold my last m1 | 00:12 |
---|---|---|
kristianpaul | wolfspraul: :D | 00:12 |
kristianpaul | panic mode now? ;) | 00:12 |
wolfspraul | yeah, great! | 00:12 |
wolfspraul | no, not at all | 00:12 |
wolfspraul | a little sad that I'm so slow with rc3 | 00:12 |
wolfspraul | but can only blame myself | 00:13 |
wolfspraul | I also have no more units now to send to reviewers, which will be a problem I need to think about. | 00:13 |
wolfspraul | chicken & egg problem... | 00:13 |
wolfspraul | if I want to prepare for a launch, I need to send something to an interested journalist/reviewer | 00:13 |
kristianpaul | I tought you owned a mm1? | 00:14 |
wolfspraul | yes sure, we still have units here and there, of course | 00:16 |
wolfspraul | but I don't have one just to admire it | 00:16 |
wolfspraul | anyway the last one for sale was sold, which is great | 00:17 |
kristianpaul | yes :-) | 00:17 |
kristianpaul | Are you aware of the stock from others distributors? | 00:17 |
wolfspraul | not really, just guessing | 00:18 |
wolfspraul | they are not a very talkative bunch | 00:18 |
wolfspraul | most of the time my emails to them get ignored unless I include some capitalized threats or so | 00:18 |
kristianpaul | he :-) | 00:19 |
wolfspraul | I think tuxbrain and others must still have a few units | 00:19 |
wolfspraul | but not sure | 00:19 |
wolfspraul | if they don't talk, I'm playing bad guy here and assume they are perfectly happy... | 00:20 |
kristianpaul | :-D | 00:20 |
wolfspraul | how is your gps-sdr project going? | 00:20 |
kristianpaul | I finished the core for reading sige data stream, in simulation "seems" to work, now writing software part | 00:21 |
wolfspraul | sounds good | 00:23 |
kristianpaul | no more news, and as wpwrak pointed this gps receivre dint get a fixed point ;-) (YET) | 00:23 |
kristianpaul | well that compared with some weeks ago, yes :-) | 00:23 |
Action: kristianpaul too lazy | 00:23 | |
wpwrak | wolfspraul: i think the trick with tuxbrain is peer pressure. of you copy victor, the chance of a response seems to increase | 00:35 |
wpwrak | s/of/if/ | 00:35 |
wolfspraul | he | 00:37 |
wpwrak | wolfspraul: when i pinged him about smt, he replied that he'll try to find time next week to go through the production process. so nothing bad has happened yet :) | 00:40 |
wolfspraul | he needs to schedule a date with the smt shop | 00:45 |
wolfspraul | I don't know that company but normally that will be 1-2 weeks out | 00:45 |
wpwrak | yeah. i asked him for that date. | 00:46 |
wolfspraul | with such a small job, they may squeeze it into the hickup of a larger job, if tuxbrain is flexible enough to handle that | 00:46 |
wolfspraul | say a phone call at 8 PM "do you want to have your run tomorrow morning at 9AM?" | 00:46 |
wolfspraul | for example because a larger job ran into a problem, the customer has to do some analysis, and there is something like a half day or day off in between | 00:47 |
wolfspraul | (before the larger job continues) | 00:47 |
wolfspraul | the factory will charge for that waiting time, but why not do a second little extra job in there as well :-) | 00:47 |
wolfspraul | if he has bad luck, he will get a date 4 or even more weeks out, and no opportunities to squeeze it in earlier emerge | 00:49 |
wolfspraul | but shouldn't be... | 00:49 |
wolfspraul | oh, we are in the wrong channel :-) | 00:49 |
wpwrak | yeah. depend a lot on how busy they are. | 00:50 |
wolfspraul | also how aggressive in pursuing every last penny | 00:50 |
wolfspraul | this is Spain... | 00:50 |
wolfspraul | :-) | 00:50 |
wolfspraul | the Chinese will be squeezing and squeezing and squeezing | 00:50 |
wolfspraul | you always find a spot to quickly do your thing, even if it's Saturday night | 00:51 |
wpwrak | ;-) | 00:52 |
wpwrak | i wouldn't be surprised of the fab in spain has a low duty cycle | 00:53 |
wpwrak | from their responses, they don't seem to see themselves just as a factory, but also do some basic consulting and such. basically what newbie customers like tuxbrain and me need. the hardened smt veterans can try their luck in china ;-) | 00:56 |
Action: kristianpaul just discovered the scripting capabillities of rtems by using the in-Memory File System | 02:19 | |
lekernel | azonenberg: because of lack of time to try other modes | 06:57 |
lekernel | yeah it has TMDS and same problem | 06:57 |
azonenberg | Btw, have any of you guys tried hand soldering 256-BGA at 1mm pitch? (like the xilinx fpga package) | 07:03 |
azonenberg | Hand meaning at home, not with an iron | 07:03 |
azonenberg | hot plate, toaster oven, etc | 07:03 |
azonenberg | and if so, did you get it to work? | 07:03 |
lekernel | no... btw, if you have it soldered professionally, the cost is usually in the $40 range for a prototype | 07:08 |
azonenberg | For a one-off unit? | 07:08 |
lekernel | decreases rapidly with volume | 07:08 |
lekernel | yes | 07:08 |
azonenberg | and is that for the entire board or a single large bga? | 07:08 |
lekernel | single bga, but I don't think the entire board would cost a lot more (except if you use automated pick and place, then you'll have to add the machine programming time) | 07:09 |
azonenberg | I'm doing a couple of FPGA designs right now that haven't left simulation but i'm going to have to move them to real hardware at some point | 07:09 |
azonenberg | I see | 07:09 |
azonenberg | I think i'll probably try my hand at homebrewing first, see if i can make it work | 07:09 |
azonenberg | if it fails, $30 down the drain | 07:09 |
azonenberg | and i go have it done right | 07:09 |
azonenberg | ($30 being the cost of the FPGA i'm gonna be using) | 07:09 |
azonenberg | Also, I have an interesting problem I'm working on, maybe you'll have some suggestions | 07:11 |
azonenberg | I'm trying to do counting in arbitrary base | 07:11 |
azonenberg | IOW i have a series of regs representing digits, and a value indicating the base of the arithmetic | 07:11 |
azonenberg | each cycle i add 1 to the rightmost one and if it exceeeds the base, wrap and bump the next one etc | 07:12 |
azonenberg | Do you think carry lookahead is feasible in, say, base 94? | 07:12 |
azonenberg | Or some other relatively large non-power-of-two base? | 07:12 |
azonenberg | Each digit i just use a normal synthesized CLA to increment, but i need to handle carry between digits myself | 07:13 |
wolfspraul | btw we sold our last Milkymist One, at least I don't have any one anymore | 07:13 |
wolfspraul | that's a fantastic result, unbelievable that we ended up selling 33 of the 40 we made only in rc2, our second run | 07:13 |
wolfspraul | some of the distributors may still have some, but I don't | 07:13 |
wolfspraul | now I need to really get my act together with rc3 and produce them asap :-) | 07:13 |
azonenberg | wolfspraul, lekernel: any ideas re the high-base counting? | 07:14 |
wolfspraul | not me, sorry | 07:14 |
lekernel | uhm, I don't know | 07:15 |
lekernel | what's the problem with that simple implementation you described? | 07:15 |
azonenberg | You mean ripple carry? | 07:16 |
azonenberg | I think it'll be too slow | 07:16 |
azonenberg | This will be running at 200-300 MHz on a spartan-6 | 07:16 |
azonenberg | and needs to generate a result every clock | 07:16 |
azonenberg | back of the envelope guess for 16 base-94 digits says 30+ gate delay | 07:16 |
lekernel | 16 base-94 digits? what do you need that for? | 07:17 |
azonenberg | well 8 is more likely, 16 is an extreme | 07:17 |
azonenberg | 8-10 is a realistic limit | 07:17 |
azonenberg | Cryptanalysis | 07:17 |
azonenberg | I'm generating candidate plaintexts | 07:17 |
azonenberg | starting at AAAAAA and going to ZZZZZ | 07:17 |
lekernel | then you can make your counter go slower when there is a carry | 07:18 |
azonenberg | the base depends on the character set chosen (lowercase letters, uppercase letters, alphanumeric, alnum with symbols, etc) | 07:18 |
azonenberg | The pipeline after this will expect a plaintext every cycle is the thing | 07:18 |
lekernel | just add a clock enable signal on it | 07:18 |
azonenberg | That slows it down | 07:18 |
lekernel | no, it doesn't | 07:18 |
azonenberg | No, i mean it skips a cycle | 07:18 |
lekernel | s6 registers has dedicated CEs | 07:18 |
azonenberg | which is a potentially significant slowdown | 07:19 |
azonenberg | i am trying to avoid needing that stall | 07:19 |
azonenberg | i'm trying to figure out if there's an efficient way to generate a plaintext every cycle, pipelining as deeply as necesssary in the input generation logic | 07:19 |
lekernel | in base 94, there is a carry every 94 cycle | 07:19 |
azonenberg | Yes, but what about base 26? | 07:19 |
azonenberg | or 10, for numeric only? | 07:19 |
azonenberg | I'll certainly consider your suggestion if that turns out to be the best way, but i want to look at all options | 07:20 |
azonenberg | In my CPU implementation i used ripple carry but if there's a more efficient way of doing things in hardware i'm hoping to do that | 07:21 |
azonenberg | I already figured out a block-RAM based method of converting from digits to ASCII text in a single cycle | 07:21 |
azonenberg | vs the relatively long delay i had with multiple data-dependent memory transactions in the CPU code | 07:21 |
azonenberg | i'll be using a dual ported block ROM to generate two characters, then cascade 8 of them side by side | 07:23 |
azonenberg | as long as i can keep the routing delays low, since nothing else will happen that clock cycle, i should be good | 07:23 |
lekernel | azonenberg: btw for the BGA you might ask Andrey from Elphel | 07:45 |
lekernel | he assembled a couple of camera PCBs by hand, I'm not sure how he did the BGA though | 07:45 |
azonenberg | i see | 07:45 |
wolfspraul | I would bet he went to a local shop in Salt Lake City | 07:45 |
wolfspraul | but who knows, ask is a good idea | 07:46 |
azonenberg | The one I'm looking at using is an XC6SLX16-FTG256 | 07:46 |
azonenberg | which is 16x16 full array, 1mm pitch | 07:46 |
azonenberg | not super fine | 07:46 |
azonenberg | i have another part that's available in either 64-TQFP, 100-TQFP, or 11x11 0.8mm BGA | 07:47 |
azonenberg | i'm not sure if i can pull off the 0.8mm without paying for a much more expensive process with tighter design rules | 07:47 |
lekernel | hi xiangfu | 08:47 |
wolfspraul | btw, excellent 05/09 snapshot | 08:48 |
xiangfu | lekernel: hi | 08:48 |
wolfspraul | I'm having a lot of fun - can click through the patches, F1 to see the title of the patch | 08:48 |
wolfspraul | very good! | 08:48 |
lekernel | yeah, i'd like to cut release 0.4 and have that ready for flashing the rc3's | 08:49 |
lekernel | I'm only waiting for xiangfu to clean up the keymap code ... | 08:49 |
xiangfu | oh | 08:49 |
wolfspraul | I assume adding video streaming to m1 will be really hard and/or take some time | 08:51 |
lekernel | yeah probably | 08:51 |
wolfspraul | so maybe we look for some vga grabber to take high quality videos? | 08:52 |
wolfspraul | I need to look into this soon (the vga grabber) | 08:52 |
lekernel | I have a friend who has one, in Paris suburbs ... | 08:52 |
lekernel | unfortunately that region has the crappiest transports of all western europe | 08:53 |
wolfspraul | I will look into it too, I'm still seeing what happens about video streaming, but my feeling is it will take several months, at least. | 08:53 |
wolfspraul | not the highest priority now actually, just for making videos/clips it would be nice ;-) | 08:53 |
wolfspraul | gotta run, bbl | 08:53 |
lekernel | same... demo time soon | 08:56 |
lekernel | especially given the time burden taken by the aforementioned transports | 08:57 |
kristianpaul | Fallenou: Is this a correct way for define a pointer in rtems, volatile unsigned int *point_buf = (volatile unsigned int *)0xb0000000; | 15:10 |
Fallenou | it seems ok for me | 15:15 |
Fallenou | you can have a look at bios code | 15:16 |
Fallenou | i'm roaming on my phone | 15:17 |
kristianpaul | ok | 15:17 |
kristianpaul | save traffic :-) | 15:17 |
Fallenou | well i waited 30 min | 15:21 |
kristianpaul | argh!, a mmu is kinda madness :S | 16:53 |
kristianpaul | may be i dont understand it well, yet ;) | 16:54 |
kristianpaul | rejon: hi, how is LGM going? | 22:28 |
kristianpaul | or was.. | 22:29 |
rejon | going well | 22:32 |
rejon | still in progress | 22:32 |
rejon | my talk went over very well | 22:32 |
kristianpaul | good | 22:32 |
kristianpaul | and mm1? | 22:32 |
kristianpaul | or your "freedom box", had people seening working? | 22:32 |
kristianpaul | somwhere.. between talks.. in a walll.. | 22:33 |
rejon | no one had heard of milkymist before | 22:34 |
Action: kristianpaul wonder how many milkymist one are in north america | 22:35 | |
lekernel | hi | 22:36 |
kristianpaul | hola :-) | 22:36 |
kristianpaul | Fallenou: you there? | 22:52 |
kristianpaul | I was about to find out the way to increse ramdisk size | 22:52 |
kristianpaul | or add another ramdisk.. | 22:52 |
kristianpaul | But i dont find a specif driver for mm1, so i guess this is something internal to rtems.. | 22:53 |
kristianpaul | There is a way to directly modify ramdisk number of blocks in flickernoise?.. | 22:54 |
kristianpaul | I mean not going to rtems-milkymist sources.. | 22:55 |
kristianpaul | I foudn this, http://wiki.rtems.org/wiki/index.php/Using_the_RTEMS_DOS_File_System#RAM_Disk | 22:55 |
kristianpaul | but seems to create a another ramdisk, but i dont think i need to do that at all.. | 22:55 |
Action: Fallenou is back | 23:26 | |
kristianpaul | Wellcome back ! | 23:29 |
Fallenou | strange | 23:37 |
Fallenou | I can see no "mount" for the /ramdisk in main.c | 23:37 |
kristianpaul | mkdir | 23:38 |
Fallenou | yes just that | 23:42 |
Fallenou | so the /ramdisk is just normal IMFS directory ? | 23:42 |
Fallenou | would make sense | 23:42 |
kristianpaul | ah, thats cheating :-) | 23:45 |
kristianpaul | so i should instead implement a proper ramdisk it seems | 23:45 |
Fallenou | well, what would be the difference ? | 23:45 |
Fallenou | IMFS is already a file system "in ram" | 23:45 |
Fallenou | "in memory file system" | 23:45 |
Fallenou | it sounds like a ramdisk to me | 23:45 |
kristianpaul | yup | 23:46 |
Fallenou | maybe I'm getting something wrong | 23:46 |
kristianpaul | not i think you got the point | 23:46 |
kristianpaul | (difference) well i need give around 64Mb size to /ramdisk | 23:48 |
Fallenou | ok | 23:48 |
kristianpaul | just to ramdisk? well | 23:48 |
Fallenou | so you may want to increase the IMFS size I guess | 23:48 |
kristianpaul | I think, i do | 23:48 |
kristianpaul | do want* | 23:48 |
Fallenou | kristianpaul: well there is something called "ramdisk" in rtems | 23:49 |
Fallenou | different than the IMFS | 23:50 |
Fallenou | but I am not sure if the /ramdisk of flickernoise *is* a RTEMS ramdisk (ramdisk driver) | 23:50 |
Fallenou | http://www.rtems.com/wiki/index.php/File_Systems#RAM_Disk | 23:50 |
Fallenou | since I can only see a mkdir | 23:50 |
kristianpaul | seems is not ramdisk | 23:50 |
kristianpaul | "The In Memory File Systems is always the root file system and uses the standard C library heap for storage" | 23:54 |
--- Sun May 15 2011 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!