<kristianpaul>
wpwrak: (flip flop) some resistors and transitors, and thats it the 1 bit ADC
<kristianpaul>
ooops
<kristianpaul>
sorry
<terpstra>
it annoys me so much that the lm32 is missing a 'mulhi' instruction to retrieve the high 32-bits of a product.
<terpstra>
i would be able to perform division in software in ~26 cycles then without needing the bloated multicycle divider
<lekernel>
interesting... can't see how off the top of my head though *g*
<lekernel>
the multicycle divider isn't bloated, it's just slow
<wolfspraul>
lekernel: I did my 'Intel meeting', was quite nice
<wolfspraul>
I demoed Milkymist One and it worked perfectly! camera and all
<Fallenou>
:)
<Fallenou>
good !
<wolfspraul>
I highly doubt much, if anything, will come out of it, but I do believe I gave them a good show and they enjoyed it.
<wolfspraul>
they are part of a 80-person strong group whose exact role in the company I still don't understand after asking multiple questions about it and listening to detailed answers
<wolfspraul>
it's something about the unknown future, understanding people, finding new ways of life, etc.
<wolfspraul>
if they ever read this in the public log here, they will laugh. very nice people, definitely.
<wolfspraul>
I got a free lunch out of it, ha
<lekernel>
I should bring them to hackerspaces and squats in Paris... hahaha
<wolfspraul>
yes they go to all those places too
<wolfspraul>
the group is a sub-group of Intel Labs
<wolfspraul>
I showed them azonenberg's homecmos pictures too
<wolfspraul>
said we want to do an Intel 4004 replica, maybe they can find someone to support it
<lekernel>
ha, that would be awesome :)
<wolfspraul>
I think it was a good meeting. I enjoyed, I think they did. all fine.
<wolfspraul>
my expectations into what comes out of it are zero though, except for the free lunch, and knowing that Intel employs good people.
<wolfspraul>
the camera worked really nice, simple mode
<wolfspraul>
everything worked
<wolfspraul>
click through patches
<lekernel>
mine's been continuously running for 4 days now
<lekernel>
no more giant bugs it seems :) nice!
<terpstra>
lekernel, the multicycle divier makes my lm32 quite some LUTs bigger
<lekernel>
glancing at the code it should be only some 30-40 LUTs, no?
<terpstra>
i report back with hard #s
<terpstra>
it's not insignificant as that
<terpstra>
1481 ALUTs without divider (arria 2)
<terpstra>
1587 with
<terpstra>
(note that this is with all other options -- hardware watchpoints+breakpoints turned on so the lm32 is already relatively large)
<terpstra>
the nasty divider also takes 32 cycles to issue which impacts how responsive an interrupt handler can be
<Fallenou>
is division necessary in the interrupt handler ?
<terpstra>
no, but if you in the middle of a division, the CPU must finish it before your interrupt handler can run
<terpstra>
so the existence of a division anywhere in your program reduces the worst-case responsiveness of your controller by 31 cycles
<Fallenou>
oh ok
<terpstra>
so, with debug features disabled, the lm32 is ~1000 LUTs vs 1100, so 10% area needed to get the slow 32-cycle hardware divier
<Fallenou>
is it possible to make the divider pipelined , divided into 2 or 3 pipeline stages, and that the interrupt can occure between those pipeline stages ?
<terpstra>
i doubt adding a 'mulhi' would cost as much since the synthesis software already uses a dedicated multiplier block
<Fallenou>
or maybe the instruction HAS to be completed anyway :/
<terpstra>
the divider in the lm32 is not pipelined
<terpstra>
it's multi-cycle issue
<lekernel>
completely replace division instruction with 'mulhi'?
<lekernel>
and make the compiler use mulhi for division
<lekernel>
if it works as good as you say, it's less area and more speed
<terpstra>
you would need to add a division algorithm to libgcc.a that uses mulhi, but yes, that's what i would prefer
<lekernel>
screw libgcc.a, we'll use llvm now :)
<terpstra>
then your divider could be interrupted as normal code
<terpstra>
the assembler is definitely not as nice as gcc's. for example, it doesn't lift constant expressions from a loop.
<terpstra>
and it doesn't combine sequential basic blocks:
<terpstra>
bne      r2, r3, $BB0_2
<terpstra>
bi      $BB0_3
<terpstra>
$BB0_3:
<terpstra>
which is somewhat strange, as these are pretty basic optimizations i'd except llvm to support in the intermediate ssa optimizations
<lekernel>
could be because of missing bits in the llvm backend? I suggest you ask jpbonn about this...
<terpstra>
i'm reading the llvm clang documentation atm
<terpstra>
i have a feeling it's just missing some optimization passes being toggled on
<terpstra>
aha! the constant lifting thing is indeed an oversight in the mico32 backend
<terpstra>
the problem is it doesn't lift 32-bit constants out, thinking it can use a 'addi/cmpi/etc' where it is unable since the immediate is not 16-bit
<terpstra>
the arm&mips backends get it right. copy-paste time. =D
<lekernel>
run3 m1 pcb's are back. adam should send some pictures soon.
<lekernel>
bbl
<GitHub169>
[extras-m1] sbourdeauducq pushed 1 new commit to master: http://bit.ly/lF2M8h
<wpwrak>
lekernel: much better ! two issues: the formatting of the lower right corner of page 3 is confusing
<wpwrak>
lekernel: the line should go to "USB ports" but goes to "Like a computer". i'm not even sure where  "Create effects .." belongs. should this be a subtitle of the screenshot ?
<lekernel>
this text, the screenshot and the usb port legend should go together...
<wpwrak>
lekernel: hmm. they look very disconnected. also, all the other lines to features at the bottom have short descriptions. so one doesn't expect USB to have a long one.
<wpwrak>
lekernel: maybe just use "USB ports for mouse and keyboard" and format the text in a single column, under the screenshot ? the text talks about the GUI too, so it would fit.
<wpwrak>
lekernel: the second issue is the formatting inside the dashed boxes on page 4. there's no inner padding on the top, left, or right, and the interline spacing is very large. this looks odd.
<wpwrak>
lekernel: (not sure if people who haven't struggled with text formatting in their life would recognize this as odd, too. or if they'd find it an interesting new style.)
<wpwrak>
lekernel: what also makes the text on page 3 look more disconnected is the wide space between paragraphs. such space also suggests that things are meant to be separate.
<lekernel>
and ofc "To use an 18K block RAM instead, RAMB16BWER must be instantiated".... NO, they could not make their software turn initialized block RAMs into RAMB16MWER's ...
<mwalle>
larsc: is the linux mm framebuffer driver supposed to work?
<wpwrak>
lekernel: how would you describe the principal objective of the M1 project in one short sentence ?
<wpwrak>
lekernel: (for the characterization of qi-hw projects in my FISL slides)