<wolfspraul>
kristianpaul: I've just sold my last m1
<kristianpaul>
wolfspraul: :D
<kristianpaul>
panic mode now? ;)
<wolfspraul>
yeah, great!
<wolfspraul>
no, not at all
<wolfspraul>
a little sad that I'm so slow with rc3
<wolfspraul>
but can only blame myself
<wolfspraul>
I also have no more units now to send to reviewers, which will be a problem I need to think about.
<wolfspraul>
chicken & egg problem...
<wolfspraul>
if I want to prepare for a launch, I need to send something to an interested journalist/reviewer
<kristianpaul>
I tought you owned a mm1?
<wolfspraul>
yes sure, we still have units here and there, of course
<wolfspraul>
but I don't have one just to admire it
<wolfspraul>
anyway the last one for sale was sold, which is great
<kristianpaul>
yes :-)
<kristianpaul>
Are you aware of the stock from others distributors?
<wolfspraul>
not really, just guessing
<wolfspraul>
they are not a very talkative bunch
<wolfspraul>
most of the time my emails to them get ignored unless I include some capitalized threats or so
<kristianpaul>
he :-)
<wolfspraul>
I think tuxbrain and others must still have a few units
<wolfspraul>
but not sure
<wolfspraul>
if they don't talk, I'm playing bad guy here and assume they are perfectly happy...
<kristianpaul>
:-D
<wolfspraul>
how is your gps-sdr project going?
<kristianpaul>
I finished the core for reading sige data stream, in simulation "seems" to work, now writing software part
<wolfspraul>
sounds good
<kristianpaul>
no more news, and as wpwrak pointed this gps receivre dint get a fixed point ;-) (YET)
<kristianpaul>
well that compared with some weeks ago, yes :-)
<kristianpaul>
too lazy
<wpwrak>
wolfspraul: i think the trick with tuxbrain is peer pressure. of you copy victor, the chance of a response seems to increase
<wpwrak>
s/of/if/
<wolfspraul>
he
<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 :)
<wolfspraul>
he needs to schedule a date with the smt shop
<wolfspraul>
I don't know that company but normally that will be 1-2 weeks out
<wpwrak>
yeah. i asked him for that date.
<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
<wolfspraul>
say a phone call at 8 PM "do you want to have your run tomorrow morning at 9AM?"
<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
<wolfspraul>
(before the larger job continues)
<wolfspraul>
the factory will charge for that waiting time, but why not do a second little extra job in there as well :-)
<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
<wolfspraul>
but shouldn't be...
<wolfspraul>
oh, we are in the wrong channel :-)
<wpwrak>
yeah. depend a lot on how busy they are.
<wolfspraul>
also how aggressive in pursuing every last penny
<wolfspraul>
this is Spain...
<wolfspraul>
:-)
<wolfspraul>
the Chinese will be squeezing and squeezing and squeezing
<wolfspraul>
you always find a spot to quickly do your thing, even if it's Saturday night
<wpwrak>
;-)
<wpwrak>
i wouldn't be surprised of the fab in spain has a low duty cycle
<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 ;-)
<kristianpaul>
just discovered the scripting capabillities of rtems by using the in-Memory File System
<lekernel>
azonenberg: because of lack of time to try other modes
<lekernel>
yeah it has TMDS and same problem
<azonenberg>
Btw, have any of you guys tried hand soldering 256-BGA at 1mm pitch? (like the xilinx fpga package)
<azonenberg>
Hand meaning at home, not with an iron
<azonenberg>
hot plate, toaster oven, etc
<azonenberg>
and if so, did you get it to work?
<lekernel>
no... btw, if you have it soldered professionally, the cost is usually in the $40 range for a prototype
<azonenberg>
For a one-off unit?
<lekernel>
decreases rapidly with volume
<lekernel>
yes
<azonenberg>
and is that for the entire board or a single large bga?
<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)
<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
<azonenberg>
I see
<azonenberg>
I think i'll probably try my hand at homebrewing first, see if i can make it work
<azonenberg>
if it fails, $30 down the drain
<azonenberg>
and i go have it done right
<azonenberg>
($30 being the cost of the FPGA i'm gonna be using)
<azonenberg>
Also, I have an interesting problem I'm working on, maybe you'll have some suggestions
<azonenberg>
I'm trying to do counting in arbitrary base
<azonenberg>
IOW i have a series of regs representing digits, and a value indicating the base of the arithmetic
<azonenberg>
each cycle i add 1 to the rightmost one and if it exceeeds the base, wrap and bump the next one etc
<azonenberg>
Do you think carry lookahead is feasible in, say, base 94?
<azonenberg>
Or some other relatively large non-power-of-two base?
<azonenberg>
Each digit i just use a normal synthesized CLA to increment, but i need to handle carry between digits myself
<wolfspraul>
btw we sold our last Milkymist One, at least I don't have any one anymore
<wolfspraul>
that's a fantastic result, unbelievable that we ended up selling 33 of the 40 we made only in rc2, our second run
<wolfspraul>
some of the distributors may still have some, but I don't
<wolfspraul>
now I need to really get my act together with rc3 and produce them asap :-)
<azonenberg>
wolfspraul, lekernel: any ideas re the high-base counting?
<wolfspraul>
not me, sorry
<lekernel>
uhm, I don't know
<lekernel>
what's the problem with that simple implementation you described?
<azonenberg>
You mean ripple carry?
<azonenberg>
I think it'll be too slow
<azonenberg>
This will be running at 200-300 MHz on a spartan-6
<azonenberg>
and needs to generate a result every clock
<azonenberg>
back of the envelope guess for 16 base-94 digits says 30+ gate delay
<lekernel>
16 base-94 digits? what do you need that for?
<azonenberg>
well 8 is more likely, 16 is an extreme
<azonenberg>
8-10 is a realistic limit
<azonenberg>
Cryptanalysis
<azonenberg>
I'm generating candidate plaintexts
<azonenberg>
starting at AAAAAA and going to ZZZZZ
<lekernel>
then you can make your counter go slower when there is a carry
<azonenberg>
the base depends on the character set chosen (lowercase letters, uppercase letters, alphanumeric, alnum with symbols, etc)
<azonenberg>
The pipeline after this will expect a plaintext every cycle is the thing
<lekernel>
just add a clock enable signal on it
<azonenberg>
That slows it down
<lekernel>
no, it doesn't
<azonenberg>
No, i mean it skips a cycle
<lekernel>
s6 registers has dedicated CEs
<azonenberg>
which is a potentially significant slowdown
<azonenberg>
i am trying to avoid needing that stall
<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
<lekernel>
in base 94, there is a carry every 94 cycle
<azonenberg>
Yes, but what about base 26?
<azonenberg>
or 10, for numeric only?
<azonenberg>
I'll certainly consider your suggestion if that turns out to be the best way, but i want to look at all options
<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
<azonenberg>
I already figured out a block-RAM based method of converting from digits to ASCII text in a single cycle
<azonenberg>
vs the relatively long delay i had with multiple data-dependent memory transactions in the CPU code
<azonenberg>
i'll be using a dual ported block ROM to generate two characters, then cascade 8 of them side by side
<azonenberg>
as long as i can keep the routing delays low, since nothing else will happen that clock cycle, i should be good
<lekernel>
azonenberg: btw for the BGA you might ask Andrey from Elphel
<lekernel>
he assembled a couple of camera PCBs by hand, I'm not sure how he did the BGA though
<azonenberg>
i see
<wolfspraul>
I would bet he went to a local shop in Salt Lake City
<wolfspraul>
but who knows, ask is a good idea
<azonenberg>
The one I'm looking at using is an XC6SLX16-FTG256
<azonenberg>
which is 16x16 full array, 1mm pitch
<azonenberg>
not super fine
<azonenberg>
i have another part that's available in either 64-TQFP, 100-TQFP, or 11x11 0.8mm BGA
<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
<lekernel>
hi xiangfu
<wolfspraul>
btw, excellent 05/09 snapshot
<xiangfu>
lekernel: hi
<wolfspraul>
I'm having a lot of fun - can click through the patches, F1 to see the title of the patch
<wolfspraul>
very good!
<lekernel>
yeah, i'd like to cut release 0.4 and have that ready for flashing the rc3's
<lekernel>
I'm only waiting for xiangfu to clean up the keymap code ...
<xiangfu>
oh
<wolfspraul>
I assume adding video streaming to m1 will be really hard and/or take some time
<lekernel>
yeah probably
<wolfspraul>
so maybe we look for some vga grabber to take high quality videos?
<wolfspraul>
I need to look into this soon (the vga grabber)
<lekernel>
I have a friend who has one, in Paris suburbs ...
<lekernel>
unfortunately that region has the crappiest transports of all western europe
<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.
<wolfspraul>
not the highest priority now actually, just for making videos/clips it would be nice ;-)
<wolfspraul>
gotta run, bbl
<lekernel>
same... demo time soon
<lekernel>
especially given the time burden taken by the aforementioned transports
<kristianpaul>
Fallenou: Is this a correct way for define a pointer in rtems, volatile unsigned int *point_buf = (volatile unsigned int *)0xb0000000;
<Fallenou>
it seems ok for me
<Fallenou>
you can have a look at bios code
<Fallenou>
i'm roaming on my phone
<kristianpaul>
ok
<kristianpaul>
save traffic :-)
<Fallenou>
well i waited 30 min
<kristianpaul>
argh!, a mmu is kinda madness :S
<kristianpaul>
may be i dont understand it well, yet ;)
<kristianpaul>
rejon: hi, how is LGM going?
<kristianpaul>
or was..
<rejon>
going well
<rejon>
still in progress
<rejon>
my talk went over very well
<kristianpaul>
good
<kristianpaul>
and mm1?
<kristianpaul>
or your "freedom box", had people seening working?
<kristianpaul>
somwhere.. between talks.. in a walll..
<rejon>
no one had heard of milkymist before
<kristianpaul>
wonder how many milkymist one are in north america
<lekernel>
hi
<kristianpaul>
hola :-)
<kristianpaul>
Fallenou: you there?
<kristianpaul>
I was about to find out the way to increse ramdisk size
<kristianpaul>
or add another ramdisk..
<kristianpaul>
But i dont find a specif driver for mm1, so i guess this is something internal to rtems..
<kristianpaul>
There is a way to directly modify ramdisk number of blocks in flickernoise?..
<kristianpaul>
I mean not going to rtems-milkymist sources..