Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamwa [cladamwa!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cwoodall [cwoodall!~cwoodall@comm575-0301-dhcp011.bu.edu] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<cladamwa>
kristianpaul, in your edk version, IO_L29P_GCLK3_2 (pin: W12) or IO_L30N_GCLK0_USERCCLK_2 (pin: AB13) are still un-used pins. so if we add these two to be as clk-in/clk-out would be good idea. ;-)
<kristianpaul>
good !
<wpwrak>
i would bring out two, e.g., L40P/L40N (differential pair)
<kristianpaul>
what about bufg connectibity check so avoid later conflict
<kristianpaul>
back in some minutes
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<kristianpaul>
ahh, i'm confusing BUFIO2 with BUFG
<kristianpaul>
how many clk signal are been used right now in bank2?
<cladamw>
temporarily current sch, see fpga page, the names of each pins of J22, we can rename them later. ;-)
<cladamw>
although No L40P/L40N, but just added other few differential pairs.
<cladamw>
wpwrak, kristianpaul I'll run out in 20 minutes, if you both have good idea or different thinkings, or else etc. just let me know, and i can modify them later. ;-)
<cladamw>
the hot plug pin (pin-16) of the dvi-i connector has not been added. ;-)
<cladamw>
the L40P/L40N in bank 1 I also added. ;-)
<cladamw>
let's think more about the arrangements of J22. tks !
<cladamw>
btw, the 9*2 pins sockets may be hard to source. the 8*2 pins sockets seems that more easy to source. but I still temporarily added 9*2 pins for J22/J21
<wpwrak>
how about 10*2 ?
<cladamw>
10*2 i checked , it's seems to be likely as 9*2.
<kristianpaul>
J22, oh well, wpwrak ? :)
<cladamw>
so 6*2 seems more easy.
<kristianpaul>
dvi-i yeah... that will go two bank to as well?
<wpwrak>
maybe we can reassign HW_VER_3 and then use L29N instead of L30N ?
<cladamw>
but i've not checked more vendors from webs. so we can determine later.
<wpwrak>
making it smaller than 9*2 would further reduce compatibility with rc2/rc3
<cladamw>
wpwrak, are you meaning that wanting to use L29P/L29N in bank 2?
<wpwrak>
i think having all signals from differential pairs would be nicer than having a mix
<cladamw>
wpwrak, yeah...reduce compatibility. we can still use 9*2 or 10*2.
<cladamw>
okay...but I don't know in s/w sides if easy to make confused to identify r2/r3/r4?
<cladamw>
although HW_VER_3 is currently no actually impact to the 8th time version. ;-)
<wpwrak>
we could use HW_VER_2 as a "switch" than enabled some further HW_VER_n pins. seems that we have quite a few spares on U22D. shouldn't matter in this case that they're in the 2V5 domain
<wpwrak>
(HW_VER_3) yup :)
<cladamw>
hmm....but i got your ideas on all let them differential pairs as must.
<wpwrak>
it's not "must". just "would seem nice" :)
<cladamw>
i don't know if using U22D is good or not. yeah..it's 2.5V
<kristianpaul>
also hope route nice ;)
<cladamw>
i run out now...
<cladamw>
later I see backlog.
<cladamw>
you both can just give me more feedbacks then i change them directly if things are easy to make sure. ;-)
<cladamw>
if not sure , then we ask lekernel . ;-)
<kristianpaul>
pairs indeed
kyak [kyak!~kyak@unaffiliated/kyak] has joined #milkymist
<kyak>
guys, just wondering, why did you decide on lm32 and not microblaze? Are there reasons other than microblaze is not free?
<kyak>
do you think that having an MMU (in microblaze) is worth it?
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<kyak>
lol, russian wikipedia works while the english one doesn't :)
<kyak>
investigating it further, there are LEON and OpenCores - both free. So why lm32?
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<kyak>
lekernel: the evaluation results seem to be obvious, don't they?
<kyak>
though it's probably not quite fair to compare MMU and MMU-less configurations...
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
mwalle [mwalle!~mw@services.serverraum.org] has joined #milkymist
<wolfspra1l>
kyak: thanks for starting to wrap you head around it. I'm a learner too on those things, please also check the IRC and mailing list backlog if it's easy, sometimes Sebastien is a little tired repeating the same questions many times :-)
<wolfspra1l>
from what I understand, one big advantage of lm32 is that it's so small
<wolfspra1l>
Milkymist SoC is not eternally bound to LM32, whether the core (or cores) is LM32 or something else is (theoretically) open
<wolfspra1l>
if you look at size of code, the Milkymist SoC is about 45,000 lines of code, the LM32 core about 8,000, that is 20-20% of the total, and sinking.
<wolfspra1l>
so the key achievement of the Milkymist SoC is not the core, but architecting an entire functioning SoC
mumptai [mumptai!~calle@brmn-4d0ae114.pool.mediaWays.net] has joined #milkymist
<kyak>
wolfspra1l: ok, thanks for information! yeah, the mailing list archive is a good source of information, and i found previous discussions about MMU as well
<wolfspra1l>
from the cores you listed, with the little I know I think LEON is the most interesting
<wolfspra1l>
ah great, I cannot check wikipedia real quick about microblaze :-)
<kyak>
i tricked the wikipedia by the way
<wolfspra1l>
kyak: but you can be sure that Sebastien and others are aware of and compared all of those you listed (and more), and so far everybody is still happy with the LM32 core
<kyak>
you noticed that it actually loads the page and then forwards you to this blackout page? i can press "stop" button in your browser at the right moment :)
<kyak>
i mean, you can press
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<kyak>
wolfspra1l: don't get me wrong, i'm not even thinking about changing the core :) just trying to get information
<wolfspra1l>
oh sure, I understand. everybody who starts to think about Milkymist runs into these questions.
<wolfspra1l>
literally, *everybody*
<wolfspra1l>
"why don't you use openrisc?"
<wolfspra1l>
I must have been asked dozens of times by now :-)
<wolfspra1l>
and that's perfectly fine because someone comes from outside and starts thinking. and I knew about openrisc before I knew about milkymist (and lm32) as well.
<cladamw>
wolfspra1l, I'll copy usb sch for intenal board in hour maybe.
<cladamw>
there's still some details like will be openly discuss later after I send email to list:
<cladamw>
1) specify how consumption for U-Shape daughter board
<cladamw>
2) if need to add current limit protection for U-Shape
<cladamw>
3) if need to add varistors for U-Shape fpga pins and decoupling cap. on M1 instead of daughter board design on user-side.
<cladamw>
4) if using dvi-i hot plug detect
<cladamw>
wolfspra1l, above I think let's to be as discussions after email, how do you think?
<wpwrak>
2) hmm, what happens if we short 3V3 to GND ?
<cladamw>
wpwrak, wow...you still here. ;-)
<wpwrak>
3) i'd keep things simple :) an extension board should be considered an "internal" device. at some point, you just have to be careful
<wolfspra1l>
yes
<wolfspra1l>
hot-plugging is not needed imho
<cladamw>
wpwrak, upon you just said then the question now will be then we must to add protection. ;-)
<wpwrak>
for 3), something we could perhaps consider is a jumper for the 5V supply on J21. that way, one can keep away the "dangerous" 5V (and avoid frying the FPGA's clamping diodes by accident)
<wolfspra1l>
but if it's easy, sure why not. maybe useful at some point in the future.
<wolfspra1l>
I trust werner in making some good balanced proposals there.
<Fallenou>
kyak: the choice of the cpu is described in lekernel masters thesis
<wpwrak>
("upon ....") hmm, can't parse that :) what do you mean ?
<Fallenou>
it compares leon/lm32 and others
<Fallenou>
and why he chosed lm32
<wpwrak>
i don't know DVI hot-plug yet. is this something you need to be able to connect DVI while M1 is running ? or something more exotic ?
<wpwrak>
cladamw: (still here_ i actually slept for a few hours :)
<cladamw>
(DVI hot-plug) I've not found very clear specified details on actions while hot-plug.
<wpwrak>
hmm :)
<wpwrak>
what does it mean on the hardware side ?
<kyak>
Fallenou: ok, thanks.. i'll read it
<cladamw>
so this(hot-plug) is opening now... I tried to search from webs. not fully understood its behaviour now.
<cladamw>
wpwrak, the current all LEDs I used pins in bank 3 (i.e. 2.5V) and active low from driving by 2.5V.
<Fallenou>
I can't find anymore lekernel thesis on the wiki or milkymist website, I don't know where it is hosted biw
<cladamw>
since some un-used pins in bank2 I'll use them as another two internal usb ports supported.
<cladamw>
you mentioned this with Werner, so is that usb shrouded socket for use? right?
<wolfspra1l>
no
<wolfspra1l>
we don't want that
<wolfspra1l>
I just posted it for comparison
<wolfspra1l>
I think we still want the totally old-school 100mil 2*5 male header
<wolfspra1l>
but let's see. which one do you like better?
<cladamw>
i'd like shrouded one but problem is not this. Problem is the user or we can easiler to get usb cable to connect to M1 firstly. then see how much it will be or popular in markets.
<cladamw>
but it's okay that i go for drawing 2*5 firstly. ;-)
<wpwrak>
i think what we want the most is keyed. shrouded would be a further feature.
<wpwrak>
keyed = pin 9 is cut/removed. you can also do this with a wire cutter. takes something like half a second :)
<cladamw>
yeah...the shrouded can against user to connect reversely.
<wpwrak>
and the shrouds sometimes can get in the way
<wpwrak>
if you look at the shrouded connector carefully, you'll see there's a black hole where one of the pins should be
<wpwrak>
this is because the pin is not equipped. the matching connector has plastic at that position. so it's also protected against reversing (but not against shifting)
<wpwrak>
and of course, if you connect a single cable with a 4x1 connector, you have no protection at all
<cladamw>
aha...understood now. tks ! pin 9 is not wquipped there. ;-)
<cladamw>
s/wquipped/equipped
<kyak>
Fallenou: (aemb) - interesting!
lekernel_ [lekernel_!~lekernel@g226056211.adsl.alicedsl.de] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<cladamw>
lekernel_, i'd like move HW_VER0~3 pins from bank2 to bank3, will this influence codes management a lot?
<wpwrak>
if we already use them, then we shouldn't move all of them. if we don't use them yet, we could move the whole gang to some previously unused pins
<cladamw>
i already can imagine added usb c/d/e/f ports parallel routes needs that area. ;-)
<cladamw>
wpwrak, do you mean that this intended 'moves' will influencely unbelivable tasks in codes managements?
<wpwrak>
well, it all depends on whether we already use those pins. if yes, we need some algorithm that still produces correct results
<wpwrak>
but yes, maybe you can move them all. e.g., if HW_NEW_x = { 0, Z, Z, ... } -> use old HW_VER_y
<wpwrak>
assuming HW_NEW_x is unconnected in rc2, rc3
<wpwrak>
it would mean that software written for rc2/rc3 may get the version wrong on rc4 or later, but i wouldn't see this as a bit issue. i mean, who would try to run the 2010-07 binary on, say, M1r4 ? :)
<cladamw>
hmm...since those four pins are to recognize Rn, so seems that I'd better not to move them after your explanations.
<wpwrak>
a new firmware could just tests the new ones first. then ignore the old ones if the new ones are not all Z.
<wpwrak>
or you could have a mixed approach. keep some, move others.
<cladamw>
likes you suggested me like HW_VER_3 from L29N to L30N once let HW_VER_2 be as a 'switch' to check?
<wpwrak>
yes, that's one possibility. but now that i've been thinking a bit about it, there may be easier solutions. even moving everything, as you suggested, may be okay.
<cladamw>
since we've not been reached (0x04, HW_VER_3:0)?
<wpwrak>
yup. that was my reasoning :)
<wpwrak>
actually no, the limit would be 0x02 :)
<wpwrak>
if we use HW_VER_2 as a switch, the logic would be like this
<cladamw>
so then under this conditions, f/w will just added very few tasks, right?
<wpwrak>
version = HW_VER_[0...2];
<cladamw>
oah. i see
<wpwrak>
if (version >= 0x2) version |= HW_NEW_[0...whatever] * 4;
<cladamw>
i tried to move HW_VER_3 is because to get differential pairs, okay.
<wpwrak>
yup
<wpwrak>
differential seems to get more and more popular, so i think it's good if we have as many of them as possible
<cladamw>
well...now I know your algorithm. ;-) so at best I shouldn't move them then reducing user to read sch though. phew~
<lekernel_>
moving only HW_VER_3, or removing it entirely, is OK
<lekernel_>
because we're not using it atm
<cladamw>
wow~ break bitstream compatibility. get worse not only f/w. :(
<cladamw>
aha...okay...great answers for me. this may be an important option if house want me to move. then I'd best to move them entirely to bank3 then.
<wpwrak>
well, if you use them as anything but GPIOs, you'll have a custom bistream anyway
<wpwrak>
so you can just add a few switches, if compatibility matters at all in the respective use case
<lekernel_>
cladamw: you have a problem with HW_VER_3 alone, right?
<cladamw>
i currently just 'moved' HW_VER_3 pin ONLY, all others are just added. ;-)
wolfspraul [wolfspraul!~wolfsprau@p5B0AF4E4.dip.t-dialin.net] has joined #milkymist
<wpwrak>
lekernel_: do we do anything with the hw version pins at the moment, besides printing their values ?
<cladamw>
lekernel_, yes, currently i think this pin only. but as your words above, I'll directly change myself if 'entirely' move them to bank3 when I cowork with house later.
<cladamw>
but I just need to know the worse case I must have to know.
<lekernel_>
wpwrak: no
<wpwrak>
cladamw: okay, so we could even (re)move all of them without major loss of functionality, if really necessary
<wpwrak>
lots of choices ;-)
<lekernel_>
yes, but what happens if the new bitstream tries to use them?
<cladamw>
alright, as long as house tell me for routing usb c~f ports, they indeedly want to move HW_VER_x resistors/fpga pins, then I know the best place now is bank3. (i.e. nearby C73 )
<lekernel_>
c~f ?
<wpwrak>
lekernel_: then it/the sw should first check the hw revision, and only then enable the new feature
<lekernel_>
wpwrak: you can't change I/O standards dynamically
<wpwrak>
lekernel_: and the bitsteam may well be something customized. e.g., kristianpaul's GPS critter
<cladamw>
lekernel_, i currently named extra usb ports as C/D...etc.
<wpwrak>
hmm, but the worst case would be that you drive the existing pins with something that doesn't make sense
<lekernel_>
cladamw: so we have 6 USB ports?!?
<lekernel_>
wpwrak: yes, and no problem with the 1K resistors?
<wpwrak>
(changing I/O standard) taht's actually a bit suckish. e.g., if we had multiple modules, using different I/O standards. ah well, something to worry about when it happens, i guess
<cladamw>
lekernel_, yes, firstly added 6 USB ports, if house tell me a strong said "NO", then I give up. ;-) And down to 4 ports.
<lekernel_>
wpwrak: you can change it at bitstream build time, or experimentally with partial reconfiguration - but I don't feel like working on the second option
<lekernel_>
especially since it has an appreciable Murphy potential
<lekernel_>
6 USB ports is too many
<wpwrak>
lekernel_: the only problem would be if the bitstream uses things as input and gets hopelessly confused about the levels it find, crashing the whole system. i think the correct answer to this is "don't do that" ;-)
<lekernel_>
4 is already on the 'high count' side. 3 is the maximum for the regular use case 'midi+keyboard+mouse'
<wpwrak>
lekernel_: 6 USB = 4 external + 2 internal
<lekernel_>
use the expansion connector for all internal stuff
<lekernel_>
that's what it's for
<wpwrak>
lekernel_: it's unlikely that all will be populated
<lekernel_>
no need to mess with additional USB transceivers
<wpwrak>
naw, internal could be RF keyboard -> you'd want this in parallel to any extension boards
<lekernel_>
there aren't any extension boards
<wpwrak>
i mean once someone makes a board :)
<lekernel_>
cladamw: what do you need the HW_VER pins for?
<wpwrak>
i don't think we want to see, say, GPS boards that also have a USB pass-through connector :)
<lekernel_>
no no
<lekernel_>
4 USB is already a lot
<cladamw>
lekernel_, i see the routes for USB C/D ports will use current those four H/W control resistors. so I ask if I can move HW_VER with less codes managments.
<lekernel_>
cladamw: alright
<lekernel_>
cladamw: so far we're using only HW_VER_0 and HW_VER_1, right?
<wpwrak>
4 USB in total is probably quite sufficient. but since we can't turn internal into external or vice versa (well, unless we get into jumper games), we may have cases with all 4 external ones populated (and no internal) or 1-2 external plus 1-2 internal
<cladamw>
lekernel_, yes. from R1 ~ R3 now, we only used HW_VER_0~1
<lekernel_>
cladamw: then move all HW_VER_* pins to currently unused pins possibly on another bank, and connect stuff to the current HW_VER_0,1 pins that go in the FPGA->USB direction
<lekernel_>
and hopefully which is driven high most of the time, so we do not dissipate power for nothing in the resistors that might already be there
<cladamw>
lekernel_ wpwrak , good. so now I can move all HW_VER_* pins to bank3 and make note to request move four resistors to other area. tks !
<lekernel_>
cladamw: also connect FPGA _outputs_ to HW_VER0,1
<lekernel_>
and possibly those driven high most of the time... what about the power switches for example? (I don't remember if we used the active-high or active-low version?)
<lekernel_>
hmm active-low, no?
<lekernel_>
meh
<cladamw>
now, active-low for usb power switch.
<lekernel_>
yes
<lekernel_>
so I quite don't know what to connect to HW_VER0,1
<lekernel_>
cladamw: connect SPD of USB C/D. then we can easily modify the code to set SPD high when no peripheral is detected.
<cladamw>
seems the best routes on pins of HW_VER0~2 can be used for extra USB ports. And I don't want the routes to cross like dram and flash routes, that's why i asked to if move HW_VER_* pins away.
<lekernel_>
cladamw: summary: use the current locations for HW_VER0,1 for SPD of USB C/D, and then move HW_VER_* wherever you want
<lekernel_>
cladamw: or better - OE#. no code change then
<cladamw>
lekernel_, ha... great hint on SPD of USB C/D. or OE#.
<lekernel_>
scratch SPD
<lekernel_>
we use OE#
<lekernel_>
OE# is always high (transceiver in receive mode) when no USB device is detected - so there will be no current through the resistors to 3.3V which are there on R2/R3 boards
<cladamw>
(OE#) good. okay
<lekernel_>
and we use the same bitstream on all boards. only it'll display "pre-R4" on R2/R3 boards ...
<cladamw>
okay.
<wpwrak>
(what to do with old HW_VER_{0,1}) maybe we could connect LEDs. they would be active-low
<cladamw>
another task: for 14 * LEDs near to each connector. I currently used also bank3 (i.e. 2.5V for all common anode to LEDs), i'd like to act all LEDs in active-low, is that okay to you?
<lekernel_>
wpwrak: I thought those pins were needed for USB? not LEDs...
<lekernel_>
cladamw: it doesn't matter if LEDs are active low or high
<wpwrak>
lekernel_: the only pin we really want is HW_VER_3, for the expansion header
<lekernel_>
wpwrak: adam said USB?
<Fallenou>
is it not difficult to respect usb timings at the moment with navre with only 2 usb ports ? I guess it will be even more difficult with 4 ports isn't it ?
<wpwrak>
lekernel_: Ron(L) is often a little lower than Ron(H). also, Imax(GND) is often higher than Imax(VDD). so active-low is a safe choice
<lekernel_>
cladamw: to be consistent with the existing LEDs, make them active high
<wpwrak>
lekernel_: (usb)we're talking about many things in parallel ;-)
<lekernel_>
wpwrak: the FPGA has a tunable drive strength whose maximum is superior to the LED current, so it really doesn't matter
<lekernel_>
it's not regular CMOS I/Os
<wpwrak>
Fallenou: the whole USB subsystem needs a massive overhaul anyway. it's tricky because the host CPU is so slow, but we'd still want more flexibility
<lekernel_>
cladamw: if you only want HW_VER_3, then simply remove that pin altogether
<wpwrak>
lekernel_: how about per-bank or per-device Imax ?
<cladamw>
lekernel_, okay, I'll change all added LEDs to be active high with 2.5V in bank3.
<lekernel_>
wpwrak: if you have many LEDs you should check the datasheet... but iirc it's not specified to depend on current direction
<lekernel_>
cladamw: I'd rather not touch bank3, because that's where the quite timing sensitive SDRAM is
<lekernel_>
cladamw: I'd skip adding the LEDs altogether
<lekernel_>
cladamw: and if you can only remove HW_VER_3 instead of moving HW_VER_*, it's much better
<wpwrak>
lekernel_: do you foresee needing more 2.5 V pins in the future ?
<lekernel_>
wpwrak: no
<lekernel_>
I told you the only big thing I foresee for Milkymist is a major performance improvement and minority report style UI :)
<lekernel_>
this won't happen on M1
<wpwrak>
okay :)
<lekernel_>
though it's a nice platform for prototyping things like migen
<wpwrak>
one step after the other :)
<lekernel_>
or render algos
<wpwrak>
see, it has its uses ;-)
<cladamw>
Moving ONLY HW_VER_3 instead of moving all HW_VER_* is that I don't know yet. But now I know this rule now. ;-)
<lekernel_>
cladamw: I said remove, not move
<lekernel_>
you simply delete HW_VER_3
<wpwrak>
if we envision needing versions > 7, then you could also allocate a new pin. and make that the new HW_VER_3. even easier than the algorithm i described before
<wpwrak>
a pin that's NC in rc2rc3
<lekernel>
chances are either version 8 will not happen or we'll have moved those pins again before then
<lekernel>
and yes
<cladamw>
lekernel, oah...sorry that I confused. yeah...I remove HW_VER_3 to different pin now. But I'll eventually know result if entirely moving all to bank3 when after coworking with house.
<cladamw>
Regarding to not touch bank 3 about SDRAM, I'll reallocate LEDs to un-used pins on other banks. phew~ now I'd leave these LEDs to be the last. :)
<wpwrak>
yeah, version 8 seems a very long way out. too long for expecting nothing major will have to change.
<lekernel>
and yes, as wpwrak pointed out, there are per-bank current and dissipation limits
<cladamw>
okay
ab5tract [ab5tract!~ab5tract@82-169-134-17.ip.telfort.nl] has joined #milkymist
Gurty [Gurty!~princess@78.250.162.185] has joined #milkymist
<wolfspraul>
wow there's a lot of things mixed
<wolfspraul>
usb, hwver, leds, m2
<wolfspraul>
is it all settled now?
<wolfspraul>
if we are moving hwver pins, I agree it is not necessary that older firmwares can detect newer board revisions
<wolfspraul>
so if we can overlap them with other pins in smart ways - go for it
<wolfspraul>
as long as the revisioning still works, that is our latest firmware can detect and run on all hw revisions
<wolfspraul>
lekernel: about the major speed improvements - can you tell us what you think might get us there?
<wolfspraul>
because even if something will not happen in an m1 revision, we should try to prepare m1 for maximum reusability towards m2
<lekernel>
more memory bandwidth, better memory architecture, ddr3, more graphics acceleration (like several TMU's), faster FPGA
<lekernel>
having an ASIC CPU, too, as far as software alone is concerned
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<wolfspraul>
you mean combine the fpga with an asic cpu, or those new fpga+asic combo chips?
<lekernel>
either
<wolfspraul>
he, that's what I hear for 2 years from others, but so far you always dismissed it :-)
<lekernel>
I don't know. it depends if we actually need fast execution of pure software to make a popular product or not.
<wolfspraul>
there's a lot of value in a cheap high-performance chip
<lekernel>
we don't need that for FN, but FN is a commercial failure
<wpwrak>
i think also FN could benefit from a faster CPU
<wpwrak>
and i think it's way too early to call FN a failure. we haven't even really started yet :)
<wolfspraul>
sure, totally not a failure.
<wolfspraul>
it's not driven by marketing needs, but that was the case since day 1
<wolfspraul>
but thinking about a high-performance asic cpu is definitely good
<wolfspraul>
in fact I did that all along, because I was told often enough that that's completely wrong with Milkymist/M1
<wolfspraul>
and until today I only heard sebastien dismissing asic cpus, but now seems not :-)
<wolfspraul>
good
<lekernel>
it's not wrong, it's just relatively slower
<lekernel>
but then they're proprietary, we depend on a single supplier, we are subject to part obsolescence
<lekernel>
they increase board cost
<lekernel>
they have tons of disadvantages
<lekernel>
I won't consider this option unless we do need fast execution of pure software
<wolfspraul>
yes, I personally think the all-fpga approach is right, especially if we include our own capability later to tape-out chips
<wolfspraul>
without which I would never think for 1 minute that any fpga activity can be commercially viable
<wolfspraul>
on the other hand we need to acknowledge just *HOW MUCH* value there is in a high-performance low-cost chip
<wolfspraul>
it's scary
<wolfspraul>
so Milkymist SoC has an uphill battle against that value
<wolfspraul>
I don't currently think we need an asic cpu, or those fpga-arm combo chips
<wolfspraul>
they won't make a big difference in improving the product
<lekernel>
new memory architecture + faster fpga + migen-flow will likely outperform those chips if there are hw-accelerable tasks
<wolfspraul>
instead, they would be a multi-year distraction that simply you won't find anybody investing for
<wolfspraul>
yes!
<wolfspraul>
my current thinking (and I am really trying to listen, because everybody else seems to know more) is that we are on the right path with the fpga-only solution
<wolfspraul>
and migen, and llhdl
<wolfspraul>
ddr3, artix or other fpgas
<wolfspraul>
find 10 million USD investment
<wolfspraul>
that path
<wolfspraul>
crank up M1 and support the m1 users
<wolfspraul>
do not tell our m1 userbase that they are a 'failure' :-)
<wpwrak>
i sometimes notice small delays that look like the CPU falling behind. they're not a problem now. but systems always grow more complex, never simpler, so ... :)
<wolfspraul>
yes, same. I see those delays too.
<wolfspraul>
I think our strategy (for the long-term, any serious investor) must include fabbing.
<wolfspraul>
and that's why the arm-fpga combos or combining with asics is a costly detour, not much more
<wolfspraul>
and I personally don't even believe that detour will increase sales, it's just a desperate catch-up move that will not work (fail to catch up)
<wolfspraul>
but keep thinking...
<lekernel>
yes, definitely not in the current state
<wolfspraul>
I think our path is correct
<lekernel>
but I do not have a clear picture of what would make a popular Milkymist product, so I cannot think yet about precise technical choices
<wolfspraul>
but it must include tape-out of non-fpga chips later, whcih is something we always had in mind, when making technology decisions
<wolfspraul>
afaik
<wolfspraul>
lekernel: yes, I understand and feel the same
<wolfspraul>
so for the time being we have to be patient and invest in the base until we have something that truly can scale
<wolfspraul>
and then we need to be in a position technically that we can in fact scale
<wolfspraul>
and with 'scale' I mean making a product in 10k, 100k or more units
<wolfspraul>
and you will not pay 100k*40 = 4 million USD to Xilinx
<lekernel>
naw, FPGAs are cheaper in such volumes
<lekernel>
but anyway, I see your point
<wolfspraul>
sure, but my point is that you need to decide first which IP value you believe in
<wolfspraul>
either the Milkymist SoC as such is valuable or not
<wolfspraul>
so when you scale, you know which part you want to invest in, and which part you want to outsource
<wolfspraul>
you better be very clear about that
<lekernel>
oh, it certainly is. at least in a few big science labs *g*
<wolfspraul>
what I have heard several times is people saying we should outsource the CPU to an existing asic
<wolfspraul>
and move only 'special' tasks into the fpga
<wolfspraul>
like most everybody else does
<lekernel>
but regarding the open source community (again I'm talking about the people who are _not_ here) or making a popular product... er...
<wolfspraul>
don't be too impatient
<wolfspraul>
Milkymist is really treated very fairly
<wolfspraul>
if you can zoom out your mind and look at it from the distance, you will see what a stretch it is to ask someone to be excited and jump in today
<wolfspraul>
it's really exotic stuff, really really exotic. Maybe just some geeky nonsense that will go away when the geeks get kids.
<wolfspraul>
9x% of people will see it like that without a chance to get them to think more.
<wolfspraul>
I cannot complain or ask for more, just need to slowly make the Milkymist case stronger.
<wolfspraul>
about those upcoming wave of fpga-asic combo chips, it will be very interesting to see how many products start using them, and their pricepoint
<wolfspraul>
if some really take off, we shouldn't be too proud to accept that it is better to bite into a large part of proprietary IP, if we cannot get the free IP (running in pure FPGA fabric) to do any good, even by our own measurement
<wolfspraul>
that's a problem though, it will essentially devalue to an expensive overhyped devel board
<wolfspraul>
devalue M1 to...
<wolfspraul>
we see :-)
<wpwrak>
i think the cave owners must have felt pretty much the same when some early humans started to build houses ;-)
<wolfspraul>
?
<wolfspraul>
don't get it :-)
<wpwrak>
"damn, if this catches on, it'll devalue our caves" :)
<Fallenou>
=)
<wolfspraul>
it's all just products
<wolfspraul>
the fpga-arm combo chips are at least 1 year out I think
<wolfspraul>
and there has been a wave/hype for such chips about 10 years ago, which faded out a few years later
<wolfspraul>
so we have to see how volume and pricepoint develop, whether this combination does make sense economically or not
<lekernel>
yeah, altera even no longer manufactures their first ARM/FPGA chip afaik
<wolfspraul>
there's absolutely no need for us to accelerate adoption of such chips today, for the same reason that we have no strong forecasts either way
<wpwrak>
maybe it's just a recurring fad. like video telephony. (well, at least that exists to some extent now.)
<wolfspraul>
yeah, and now they try again, why not
<wolfspraul>
this time they want to make them look like arm, boot like arm and all, and have the fpga fabric around for 'acceleration'
<wolfspraul>
I think it's good that they try
<wpwrak>
and then xi-lin.cn will make a super low-cost MIPS plus FPGA ? :-)
<wolfspraul>
what I believe in for the future of Milkymist right now I listed above: migen, ddr3, artix/other latest-gen fpgas, include tape-out/asic in our forecast and business plan
<wolfspraul>
no need for the new combo chips or putting a separate asic cpu next to an fpga
<wolfspraul>
those paths look messy to me, I don't understand where the valuable IP is, so wouldn't know how to invest or how to tell an investment story to a 3rd party
<wolfspraul>
but if those paths lead to better products in shorter time-to-market, we may have to compromise
<lekernel>
yup. it's an option to keep if we can't have enough investment for an ASIC, and if we are strongly convinced that having fast traditional software capability will make the product successful.
<wolfspraul>
you have to decide first what you believe someone should invest into
<wpwrak>
i see this as a more viable path mid-term than making our own chips
<wolfspraul>
if you tell an investor you are not sure, that won't work
<wolfspraul>
wpwrak: you mean we should try fpga-arm combo chips or putting a separate asic cpu on m1/m2 ?
<lekernel>
wpwrak: but on the long term, it increases a lot the work to make those chips
<wpwrak>
it's not as if you'd just have to call up the guys in the asic building on the qi-hw campus ;-)
<lekernel>
you could probably put the current MM SoC design in a few months if you had the money
<lekernel>
software compatible and everything
<wolfspraul>
from what I've learnt so far asic is easy, relatively easy
<wolfspraul>
give me 1 million USD and I am pretty sure I can pull it off
<wpwrak>
wolfspraul: dunno what's better. would depend on how well they're integrated, etc. in general, integration should help. but depends on what they have to offer and how deep this would get us into proprietary land
<wolfspraul>
even less, but the point is that I don't see any 'impossible' barriers right now
<lekernel>
wpwrak: then you'd have to either buy licenses from ARM or switch back to LM32
<wolfspraul>
and I do believe the Milkymist SoC as a tape-out candidate gets stronger every month
<lekernel>
with the risks of doing errors, in both cases
<wolfspraul>
I think the all-fpga approach right now, even if a bit radical, will open the doors to the best integration and optimization for future products, for ourselves and others
<wpwrak>
lekernel: i would be more worried about the fpga-to-cpu "glue". wouldn't be nice to have to use deeply proprietary IP blocks for that
<wolfspraul>
the fpga-arm combo guys will not integrate any interesting chips either, there are too many things you can do with electronics and they cannot make a swiss-army-knife chip
<wpwrak>
lekernel: i.e., it would undermine your llhdl work
<wolfspraul>
I remember senior HP people telling me years ago how worried they are about the whole 'feature guessing game'
<wolfspraul>
sorry TI
<wpwrak>
it's their job ;-)
<wolfspraul>
yeah but they may not feel comfortable that a decision about which feature the market wants x years later is something they can be good at
<wolfspraul>
maybe ask the fortune teller on the way to the office?
<wolfspraul>
do you really want to bet a large sum on that?
<wolfspraul>
the fpga-arm guys will have terrible trouble deciding which features to include in their chips and which to keep out
<Fallenou>
If there is a free verilog 32-bits MIPS clone with good (better than lm32) performance and not too much LUT (fpga occupation) would it be candidate to replace LM32 ?
<wolfspraul>
for one MIPS is a patent minefield
<Fallenou>
yes
<wolfspraul>
just saying
<Fallenou>
but not MIPS, just a few instructions
<wolfspraul>
at the very least you would *never* want to say MIPS anywhere
<Fallenou>
non-aligned store/load
<Fallenou>
would be called MINM ? MINM Is Not a MIPS :)
<lekernel>
I can't see much point in switching to MIPS from LM32
<wolfspraul>
so why can't we upgrade m1 to ddr3+artix ? that looks like the way to go. we should make one small increment after another, without giving up control in any of the key technologies that define our destiny (which in our case is open because it's open tech :-))
<wolfspraul>
not upgrade now, maybe call it m2, but that's the cheapest and most immediate path I see right now
<Fallenou>
just if it has better performances
<wolfspraul>
and carry forward as much as possible from what we have now
<lekernel>
it won't
<Fallenou>
the point would be a better toolchain and easier linux support
<lekernel>
at least not by more than 10%
<lekernel>
the lack of linux support is a mere consequence of the M1 unpopularity. people are _rushing_ to port their stuff to more successful projects like rpi ...
<wolfspraul>
but yeah, the cpu in m1 needs to get faster ;-)
<wolfspraul>
how?
<lekernel>
does it? I'm not sure.
<wolfspraul>
seems that sentiment comes up once in a while
<wolfspraul>
well I don't want to add confusion, I love our priorities. migen, memory controller, all that.
<wolfspraul>
I am loaded with work that I feel very good about, so I don't need a faster CPU now.
* Fallenou
just talking about mips because of his recent experiments in making a mips core, too early to tell how good performances will be, it will end up as a toy or a lawsuite I guess
<lekernel>
Fallenou: why don't you design a LM32 MMU instead?
<wolfspraul>
why don't you join m1 full power? :-) lots of great tasks there to help with our big goals.
<lekernel>
yes :)
<lekernel>
don't reinvent the wheel, we already got this part right
<Fallenou>
lekernel: well maybe afterward, I am doing the mips core to learn about cpu design and verilog and so on, maybe after this is done or more advanced I will switch to something else :)
<wolfspraul>
come on switch now! you are already part of this community
<Fallenou>
well the benefit is that after a month working on my mips core I now understand when I read lm32 source code
<lekernel>
doesn't seem like they have much of a problem so far
<Fallenou>
so if I want to add an MMU to lm32 I would need to understand lm32 source code :)
<wolfspraul>
and the way to get it cheap is to radically invest and integrate, including tape-out and bypassing the fpga tax.
<Fallenou>
So I guess my start with this project is not that wrong
<wolfspraul>
Fallenou: jump jump!
<Fallenou>
but I get your point
<wolfspraul>
jump into the cold water, join m1 now
<wolfspraul>
you even talked about it what, 1 year ago now? :-)
<wolfspraul>
I mean you gave a presentation
<wolfspraul>
we need you
<Fallenou>
yep in London on april
<wolfspraul>
maybe one day you will enjoy talking about our death
<wolfspraul>
sigh
<wolfspraul>
:-)
<wolfspraul>
join!
<Fallenou>
ahah no I really like this project
<Fallenou>
don't want it to die :)
<wolfspraul>
then join
<wolfspraul>
help contribute back
<Fallenou>
I read every conversation here even if I don't write
<wolfspraul>
every little thing helps and matters
<wolfspraul>
better documentation
<wpwrak>
lekernel: (no problem so far) yeah, that's what the Neanderthals must have thought about those little groups of skinny homo sapiens, too ;-)
<wolfspraul>
discussoin
<wolfspraul>
insights
<wolfspraul>
patches
<Fallenou>
wolfspraul: if I feel like I have the time/skill for a contribution I will not hesitate one second
<wolfspraul>
:-)
<wolfspraul>
sounds like an excuse :-)
<Fallenou>
I feel really much moreconfident now about verilog/fpga dev
<wolfspraul>
nobody could be less qualified than I am
<Fallenou>
so maybe I will start mmu project :)
<lekernel>
Fallenou: so, you have time to reinvent the softcore CPU wheel, but not design a MMU?
<wolfspraul>
so what the heck do I do here?
<Fallenou>
lekernel: well for example I knew where to start for the cpu, for the MMU I didn't know
<lekernel>
then ask
<Fallenou>
now I know a little bit better, but need to document more as well
<wolfspraul>
Fallenou: seriously, let me tell you this. By joining m1 now, and contributing now, no matter how immature you think your knowledge is, you help the project the most.
<Fallenou>
and anyway I reall wanted to understand better cpu design for me, I did it to understand better, don't make me feel guilty of working on things to improve my skills ;)
<Fallenou>
wolfspraul: I know i know
<lekernel>
but designing that MMU _will_ improve your skills
<wolfspraul>
that's because you will ask the typical type of newbie questions that will pave the way for so many other newbies to follow you
<Fallenou>
I started by what I feeled would be a nice start
<Fallenou>
maybe I was wrong
<lekernel>
besides, you will get the right to ask me questions about it. but those regarding MIPS design I won't answer.
<wolfspraul>
:-)
<Fallenou>
:)
<Fallenou>
notice I didn't asked one yet :p
<Fallenou>
but ok, I will seriously think about it
<Fallenou>
prepare for some questions :)
kristianpaul [kristianpaul!~kristianp@2001:0:53aa:64c:2430:4cb2:415a:74c5] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #milkymist
<Fallenou>
MMU will surely help having a nice Linux up and running, but for FN, what's the benefit ?
<wpwrak>
maybe FN2 will run under linux, enjoying all the drivers you can find there ? :)
<larsc>
kristianpaul: wpwrak wants to enjoy all the drivers
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
antgreen [antgreen!~user@bas3-toronto06-1177890396.dsl.bell.ca] has joined #milkymist
lekernel [lekernel!~lekernel@g226056211.adsl.alicedsl.de] has joined #milkymist
<wolfspraul>
lekernel: are you aware of anything specific you do right now in the Milkymist SoC that makes fabbing them later difficult?
<wolfspraul>
(just asking out of curiosity so we are clear, not that I plan something along that soon)
<wpwrak>
(meme generator) ah, now i get it ! first, i thought someone had actually drawn that thing before, for some perplexingly unfathomable reason ;-)
<lekernel>
no, everything is pretty much portable
<lekernel>
except things like DDR I/O and clock generators
<lekernel>
but Synopsys is always happy to sell layouts for these things
<lekernel>
(those are generally designed at the transistor level, i.e. no Verilog)
<wolfspraul>
ok, good! we should keep that perspective open and well documented
<wolfspraul>
I think the only reason to justify the existance of a product-quality free Milkymist SoC is if you at least have fabbing in your roadmap/future plans
<wolfspraul>
if we exclude that for good, it would be better to get an ASIC CPU and focus our energy on those parts we really believe in
<wolfspraul>
but I think we should keep that open, definitely
<Fallenou>
how many products manufactured is it worth it to spend a lot of money in an ASIC ?
<Fallenou>
when does it become profitable ? asic cost vs fpga cost
<wolfspraul>
I think that's very difficult to answer because the two technologies are so different
<wolfspraul>
in some cases the reprogrammability of an fpga may be a feature you really want on some product
<wolfspraul>
especially if you imagine that things like reconfigurability become really easy and useful
<wolfspraul>
then there are options on the side of the fpga vendors, for example Xilinx and Lattice supposedly have programs that allow you to buy chips at 50-80% discounts, where those chips are guaranteed only to work with a specific bitstream that you give them in advance
<wolfspraul>
Altera had or has something called HardCopy
<wolfspraul>
then there are structured ASIC vendors, basically piles of proprietary tools and technologies to reduce the need for custom masks
<wolfspraul>
on the ASIC side, there are huge differences between making something in a 500um process, or a 90nm, or a 28nm process
<wolfspraul>
and so on
<wolfspraul>
each of those paths has different economical dynamics
<wolfspraul>
I believe the ability to integrate and optimize is what makes a great product, so we need to keep those parts open (that is, under our control) that are relevant towards that goal.
<wolfspraul>
as a rule of thumb, in China they say "do asic above 10k units"
<wolfspraul>
but that's a very very rough rule of thumb, and like this only really applies to china where IP is always just simplified to 0 cost, because you can just steal it if you like
<wolfspraul>
but if we do the math for milkymist one, for example, the 10k number prooves to be not too far off
<wolfspraul>
10k slx45 chips at 40 USD = 400,000 USD
<wolfspraul>
at 10k you can expect bigger discounts, don't ask me how much
<wolfspraul>
let's say 30 USD, so 300,000 USD
<wolfspraul>
if you are willing to loose reprogrammability, maybe xilinx can sell you chips at a discount that are tested only against one specific bitstream
<wolfspraul>
that might bring the costs of those chips to 150,000 USD, if such a program is already available at 10k units (I doubt it)
<wolfspraul>
now, on the other side. If you try to tape-out the Milkymist One SoC in M1 in a 180nm process, could it compete performance-wise with the fpga? probably
<wolfspraul>
how much would you need to see it all through the 180nm process? again a bit hard to say, but 150,000 USD is a lot of money at that size
<wolfspraul>
the masks are expensive
<wolfspraul>
if you make mistakes and need several go-arounds, that's expensive
<wolfspraul>
Milkymist One is 'unproven' on the asic side, that's the biggest problem
<wolfspraul>
unproven = risk = cost
<wpwrak>
i don't see so much of a point in going to an ASIC for lowering cost. much more for gaining speed. now, we know our core is very slow. but how are we doing on the graphics ?
<wolfspraul>
yes yes, me neither
<wolfspraul>
I just try to describe what I've learnt so far
<wolfspraul>
since Fallenou asked
<wpwrak>
there, the bottleneck seems to be memory bandwidth. but is that limited by the memory technology we have or the fpga ?
<wolfspraul>
I believe we should maximize the reprogrammability
<wolfspraul>
do that first
<wolfspraul>
first get volume up, then think about cost (and the consequences)
<wpwrak>
from the geek side, i see reprogrammability as the M1's main feature
<wolfspraul>
I do want to learn more about the practical steps, risks and costs of > 130nm fabbing though
<wolfspraul>
not because I want to do that now, or because I think that's what will drive M1 volume up
<wolfspraul>
but so that we have a clearer long-term roadmap, a realistic and thoughtful one
<wolfspraul>
I think the hardware we have on m1 right now is just lovely. We can make our free tech shine on that.
<wolfspraul>
big time
<wolfspraul>
and if it doesn't shine, we fix that first
<wpwrak>
okay, knowledge is power :)
<wolfspraul>
Fallenou: did the above text block answer your question somewhat?
<wolfspraul>
I was hoping some reflection time would help ;-)
<wpwrak>
you need to zoom a little because fped auto-scales the labels
<wolfspraul>
there are many options post-fpga, but all of those options have pros and cons. everything else would be a surprise of course, since we are not the first ones thinking about this...
<wolfspraul>
wpwrak: knowledge is power, but the question is which knowledge :-)
<wolfspraul>
sometimes a very small piece of knowledge can be very powerful, sometimes a very large piece of knowledge almost worthless
<wolfspraul>
welcome to real life
* Fallenou
reading
<Fallenou>
(50-80% discount on Xilinx/Lattice fpga for single design chip) wooow nice, I didn't know about it !
<wolfspraul>
I've only read about it, no specifics. Maybe such programs are only available to select customers, though I can imagine yield being a major issue in fpga making, so it depends on how many non-100% chips they have...
<wolfspraul>
and the customer looses reprogrammability
<wpwrak>
almost a faustian deal :)
<wolfspraul>
come on this is manufacturing, everybody tries to find use for every last breadcrumb :-)
<wolfspraul>
no waste!
<wolfspraul>
a customer who doesn't value reprogrammability is at high-risk to be lost to direct asic fabbing anyway
<wpwrak>
yeah, save a cent on every unit but spend millions on making one that's 1% different because nothing can be reused ;-)
<wolfspraul>
so it may not even cannibalize their 100% working fpga sales
<wpwrak>
oh, sure. for fpga makers it makes a lot of sense
<wolfspraul>
Altera has a program called HardCopy, I don't know much about it either. Some similar deal for Altera to avoid loosing customers to asic.
<wolfspraul>
all the way to 28nm, at least on the website :-)
<wolfspraul>
they won't stop you trying :-)
<wolfspraul>
I would like to try fab something interesting, at some point in the future, on a cheap 180nm or so process in China. but the actual product opportunity needs to emerge first, i.e. volume.
<wolfspraul>
could be Taiwan or so as well of course, wherever the fab is.
<wpwrak>
okay, ffs ;-)
<wolfspraul>
i don't see milkymist suddenly jumping into a very high-end process though, nobody will take the multi-million USD risk
<wolfspraul>
so that means we may be better off on high-end fpgas for the time being
<wpwrak>
it's still incomplete. need to draw a side view, too.
<wolfspraul>
not really yet, no
<wolfspraul>
but it's on my screen here
<wpwrak>
good :)
<wolfspraul>
on the right side is the acrylic?
<wpwrak>
yes
<wolfspraul>
dinner, bbiab then I look at it more
<wpwrak>
enjoy ! (the dinner :)
<Fallenou>
20:06 < wolfspraul> Fallenou: did the above text block answer your question somewhat? < it gives me some clues I didn't have, thanks :)
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<Fallenou>
I wanted an approx about N when this equation becomes true : Making_mask_price + N*asic_unit_price < N*fpga_unit_price
kyak [kyak!~kyak@unaffiliated/kyak] has joined #milkymist
<wolfspraul>
ok but any serious calculation will need to include many more numbers
<wolfspraul>
there are IP licensing cost, past and future investments into IP, sales forecast, price elasticity of the product you are selling, and so on
<wolfspraul>
then there are different degrees of risk that a particular run (or mask) needs to be discarded
<wolfspraul>
say the masks cost 1 million USD :-) so if the throw-away risk is 5%, that's 50k USD, if it's 80%, it's 800k USD
<wolfspraul>
why is the clearance to the wall specified?
<wolfspraul>
it would be good if the legend you have in the email could be in the ps/pdf
<wolfspraul>
how about tolerances?
<wolfspraul>
are the outer dimensions of the pcb designed in such a way that they easily multiply to some larger panel? maybe compatible with some popular online pcb makers?
<wolfspraul>
are components on the bottom of the daughterboard pcb allowed?
<wpwrak>
(wall) you mean FB ? or the 2.46 mm between board edge and wall ?
<wolfspraul>
2.46
<wolfspraul>
I'm just looking and thinking and writing
<wolfspraul>
so the male headers are at the bottom side, hmm
<wolfspraul>
what if someone wants to make a 1-layer pcb?
<wpwrak>
(legend) i'll probably have to redraw the whole thing with xfig, to make it look right. fped isn't good at handling text
<wolfspraul>
then the other components would need to be on the bottom side as well
<wolfspraul>
and then we would need to specify a maximum height for that
<Fallenou>
ok thanks for the intel wolfspraul :)
<wpwrak>
(tolerances) yes, the wall has some tolerances. that still needs doing
<wolfspraul>
wall?
<wolfspraul>
right now you say the pcb max size is 42.86 by 85.08
<wpwrak>
(bottom side) yes. bottom clearance would be in the side view/
<wolfspraul>
how do we come up with these numbers?
<wpwrak>
(wall) the acrylic front wall of M1
<wolfspraul>
and there are no tolerances
<wolfspraul>
you don't say 42.86 +-.5mm
<wpwrak>
these are maxima. they have no tolerance
<wolfspraul>
that's not very practical or usual, no?
<wpwrak>
if you process is +/- 0.5 mm, design for 42.36 mm ;-)
<wolfspraul>
whenever you do anything in physical reality, there will be tolerances
<wolfspraul>
sure but we want the spec to be easily readable
<wolfspraul>
I'm giving feedback...
<wpwrak>
again, it's a maximum. you can invent a tolerance but it does not correspond to reality
<wpwrak>
e.g., if you write 42.76 +/- 0.1, you imply that an accuracy of 0.1 mm is needed, but we don't care. you can be off by 1 mm as long as you respect the maximum
<wolfspraul>
are the sizes designed such that they multiply easily into panels or some 'standard' maybe at batchpcb or whereever?
<wpwrak>
no. they reflect the internal spaces of M1
<wpwrak>
i don't think you can usefully optimize for panels
<wolfspraul>
well yes, ok. my mechanical experience is less than yours. I think everything has tolerances. so you are better off defining the middle point and giving a 'tolerance' as a criteria for QA
<wpwrak>
each pcb fab will have a set of board sizes, the distance between boards will vary, and so on
<wpwrak>
also, this is a maximum size. if you want to optimize in general, you make it as small as you can. and if you want to optimize for a given fab, you pick a size that corresponds to their process and that stays below the maxima
<wpwrak>
(tolerance) there is no "middle point" :)
<wpwrak>
you're not obliged to make the board that big
<wpwrak>
the only things that can have meaningful tolerances are: B, FB, and FW.
<wpwrak>
HL and HW specify characteristics of the header in general. but the tolerances you see would come from the header you buy (and they will be very small anyway)
<wpwrak>
there's also an implicit tolerance, the vertical offset between the headers. it's zero by design, but you could of course shift the header by a few um, even intentionally :)
<wpwrak>
you're also not obliged to make a rectangular board. it just has to fit into the maximum area
<wolfspraul>
ok, I think in most mechanical drawings you have tolerances
<wolfspraul>
so you have a dimension, and a tolerance. the dimension is what you tell your tool, and the tolerance defines the yield
<wolfspraul>
'maximum' is not something we can even provide on the other, m1, side
<wolfspraul>
but my thinking may be wrong, you are making the most mechanical stuff ;-)
<wpwrak>
but of course we can provide the maximum !
<wolfspraul>
alright
<wolfspraul>
not very organic...
<wolfspraul>
but it doesn't matter, it's a detail
<wpwrak>
we can design M1 such that there is no obstacle within this area (taking into account the tolerances of out own process)
<wolfspraul>
overall it looks great
<wolfspraul>
so a 1-layer pcb with components on the bottom side would be supported?
<wolfspraul>
not sure how many people would want that...
<wolfspraul>
can we explain the genesis of those numbers a little?
<wolfspraul>
it would make people who are doing derivative work feel more comfortable in making changes
<wpwrak>
1 layer should be possible. you have a certain clearance
<wpwrak>
(genesis) it's basically guesses of when you start hitting other components :)
<wpwrak>
also not that the maximum board is not centered. that's in part because the VGA connector is in the way. that'll change anyway, but it'll probably get worse (DVI being larger than VGA)
<wpwrak>
these maximum values are basically an assurance: we make sure that this area is clear for you, and we'll continue to make sure it stays clear.
<wpwrak>
someone who chooses to exceed the limits may be able to get away with it, but at the risk of, say, M1r5 putting a conflicting obstacle
<wolfspraul>
sure
<wolfspraul>
but we should explain those things along with the numbers
<wolfspraul>
that's my point
<wolfspraul>
that will make it much easier in the future, rather than carrying unknown golden values around
<wolfspraul>
just the way you answer here is perfect, that's the missing bit for me when I look at the numbers
<wolfspraul>
some values are rounded to 1mm, some not. why?
<wpwrak>
oh sure, this needs explanatory text. also needs electrical parameters, and so on
<wpwrak>
i picked design values of multiples of 1 mm. the exception being the headers with a 100 mil raster
<wpwrak>
so the "odd" values are just combinations of my 1 mm values plus something the headers add
<wolfspraul>
ah ok, yes
<wolfspraul>
the golden numbers are coming from the golden connector
<wpwrak>
;-)
<wolfspraul>
ok those are all questions I can come up with right now
<wolfspraul>
yes it all makes sense
<wpwrak>
so all documentation issues. the physical properties look reasonable then ?
<wolfspraul>
4x8 seems like a nice size
<wolfspraul>
physical properties, huh
<wolfspraul>
that's tough
<wpwrak>
some people will find it small, but there's no pleasing everybody :)
<wolfspraul>
I cannot really predict layout preferences, chip sizes, pcb antennae, etc.
<wolfspraul>
not small
<wpwrak>
we should make a dummy circuit, though. to see if any of the clearances cause layout issues
<wolfspraul>
I like it because it's squarely in the hand-held/mobile size range
<wpwrak>
ah, what was the thickness tolerance for the acrylic again ?
<wolfspraul>
need to search irclogs, I think it was 10 or even 20%
<wolfspraul>
tolerance = cost
<wolfspraul>
I can get you any tolerance you want if you let me throw away (but still pay for) all the ones that don't meet your tolerance
<wolfspraul>
assuming we are not down to where measuring becomes difficult
<wpwrak>
(any tolerance i want) heh ;-)
<wolfspraul>
that's why I think talking about tolerances is important, so people get a quick feeling where expensive/wasteful precision is needed
<wolfspraul>
it's like in math, the difference between 1 and 1.00
<wolfspraul>
otherwise someone may take a quick look at such a drawing and automatically assume the worst
<wpwrak>
sure. but you have to understand that many of the values have no tolerances. they already are extremes. it's like a bridge. when it says that your car's maximum height can be 2.00 m, and your car is 2.10 m, the risk is all yours
<wolfspraul>
understood, but that doesn't come across on the drawing at first sight
<wolfspraul>
and you are asking for feedback, so there it is :-)
<wpwrak>
on the other hand, if you car is exactly 2.00 m, and you still get stuck, then you have a good chance of being able to get a bit of money from whoever mis-labeled that bridge
<wpwrak>
that's in the text of the mail :)
<wolfspraul>
I have seen enough mechanical people and when they see a number without tolerance, they worry
<wpwrak>
oh yes. if it's a "typical" value, you wonder what the extremes are
<wpwrak>
because you need to design with them. same for, say, resistors in electronics
<wolfspraul>
yes
<wpwrak>
but these are already the extremes. there's no tolerance on top of them. there's a bit of safety margin we allocate for ourselves, but that's not part of the "published spec" (we should still write it down, of course. but it's a different part of the document)
<wpwrak>
e.g., the "M1 main PCB design" section could say to keep an area of 50 x 90 free from major obstructions
<wpwrak>
50 x 90 mm
<wolfspraul>
especially if it's adjacent to large connectors
<wpwrak>
again, that would be an extremal value. so no tolerance
<wolfspraul>
the pcb itself is quite tight, but connectors are like skyscrapers standing on the 5mil structures
<wpwrak>
yeah. the main troublemaker there would be VGA. we also have a few other tall components, but some of them should vanish.
<wpwrak>
i don't know how the DVI connector will change things. have we already selected a part ?
<wolfspraul>
not to my knowledge
<wolfspraul>
let's ask Adam tomorrow, maybe he can squeeze it in before his vacation
<wolfspraul>
and maybe not
<wpwrak>
heh :) well, also a rough idea would be useful. then i could check the parameters more closely
<wolfspraul>
rough idea is - let's look whether molex has a dvi-i
<wolfspraul>
they have the most oustanding mechanical drawings
<wolfspraul>
so they become the source of a lot of copying :-)
<wpwrak>
heh ;-)
<wpwrak>
let's see what our mounting choices are
<wolfspraul>
wow they are expensive, 4-5 USD at digikey
<wolfspraul>
but there's a good chance to find a clone with very similar mechanical size