lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
jimmythehorn has quit [Ping timeout: 268 seconds]
jimmythehorn has joined #milkymist
fpgaminer has quit [Ping timeout: 240 seconds]
__del__ has joined #milkymist
__del__ has left #milkymist [#milkymist]
fpgaminer has joined #milkymist
froggyto1d has quit [Ping timeout: 245 seconds]
froggyto1d has joined #milkymist
Martoni has joined #milkymist
mwalle has quit [Ping timeout: 245 seconds]
mwalle has joined #milkymist
fpgaminer has quit [Ping timeout: 245 seconds]
lekernel has joined #milkymist
fpgaminer has joined #milkymist
bhamilton has joined #milkymist
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
bhamilton has joined #milkymist
lekernel has quit [Ping timeout: 245 seconds]
lekernel has joined #milkymist
__del__ has joined #milkymist
antgreen has joined #milkymist
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
antgreen has quit [Ping timeout: 245 seconds]
<Fallenou_>
lekernel: do you think going from speed grade -2 to -3 will allow to increase lm32 clock frequency ?
<lekernel>
alone yes, but here it's mostly about gaining back the original frequency with the dual DVI sampler and my sanity
<wpwrak>
(sanity) ah, feeling experimental ;-)
qi-bot4 has joined #milkymist
playthatbeat|2 has joined #milkymist
kyak_ has joined #milkymist
kyak_ has joined #milkymist
fpgaminer has quit [*.net *.split]
kyak has quit [*.net *.split]
playthatbeat has quit [*.net *.split]
qi-bot has quit [*.net *.split]
Padawan- has quit [*.net *.split]
qi-bot4 is now known as qi-bot
fpgaminer has joined #milkymist
Padawan- has joined #milkymist
<Fallenou_>
lekernel: about the 700 EUR/board, the M1R4 bom seems to be ~ $212 , so all the remaining is PCB price?
<Fallenou_>
that's expensive isn't it?
<Fallenou_>
pcb + mounting components
<lekernel>
that's for 6 pcs
<wpwrak>
pcb and smt usually have significant fixed costs. so if the number of units is low, each has to cover a large share of that
<lekernel>
including pcb and assembly
<wpwrak>
Fallenou_: also, you have yield to consider. you can't expect 100% of all boards to just work. some may need minor fixing, some may just be writeoffs
<wpwrak>
lekernel: so to get 6, you'd fab at least 8, right ?
<lekernel>
I fab 6 + number of preorders... it's not *that* bad, all 5 first M1 we made worked in the end, after rework
<larsc>
I think I'll take one
<wpwrak>
depends on how good your fab is ... for a first run, you shouldn't expect > 95% yield for this kind of board
<wpwrak>
for comparison, atben had 100%, atusb had about 97.7%
<lekernel>
from what I have seen and the "samples" I have on my desk, they seem pretty good
kyak_ is now known as kyak
<lekernel>
they also noticed immediately the M1 PCB Altium files were a messed up PADS conversion... ahem
<wpwrak>
;-) did you get the original files from wolfgang ?
<lekernel>
no
<wpwrak>
:-(
<wpwrak>
so what will you do ?
<wpwrak>
switch to kicad ? :)
<lekernel>
email went to the trap, so I'm paying them extra for fixing the altium files
<wpwrak>
argh
<wpwrak>
this seems like the perfect moment to leave the ugly world of proprietary tools and formats behind.
<wpwrak>
what you're doing now is basically paying to get your prison cell repainted ...
<lekernel>
in a couple years the slowtan6 will be completely obsolete, and then I'll have to redo a complete board anyway
<lekernel>
hopefully kicad will have improved by then
<lekernel>
*that* would be the perfect moment to switch
<wpwrak>
kicad is constantly improving. what you're saying sounds a bit like "oh, i won't buy a PC just now. i'll rather wait until the technology is mature and doesn't change all the time."
<lekernel>
except that the extra is a lot less than a complete redesign
<lekernel>
right now I just want to have a first version out to get market feedback asap - can be a tougher beast than most technical problems
<wpwrak>
we're kinda 60% there when it comes to a redesign. we have compelete schematics in kicad, most of the footprints, all that's missing is the layout
<Fallenou_>
layout is not the easiest thing :)
stekern has quit [Ping timeout: 256 seconds]
__del__ has quit [Quit: Leaving.]
<wpwrak>
that's why i allocate a generous 40% :)
<wpwrak>
we already have: 1) high-level design (with component selection, all sorts of calculations, etc.), 2) schematics symbols, 3) schematics, 4) schematics review, 5) most of the footprints
<wpwrak>
for mixxeo, we'd need to redo part of the schematics, but it would be mainly an exercise in copy and trim. so relatively little new work.
<wpwrak>
and yes, it's still a lot. but unless you ride out and slay that darn dragon, the villagers will always live in fear :)
<lekernel>
right, and then we fab that, then the SDRAM doesn't work because of SI, and then what?
<lekernel>
can kicad even route differential pairs for the HDMI?
<wpwrak>
yes, you have to expect one failed run
<lekernel>
in any other way than manually?
<wpwrak>
depends on the skills of the one doing the routing :)
<wpwrak>
afaik, there still no autorouting i'd want to use. there's an external non-open router, though
antgreen has joined #milkymist
<wpwrak>
what i do when i need some feature that's not in kicad is usually to write an external tool that provides it for me. that tends to be easier than mess with C++ and GUI. so for differential traces, i'd make a tool that calculates the length of a given net (selected by name)
<wpwrak>
add a "compare and complain if delta > X" mode and you have a nicely automated sanity checking pass
<lekernel>
not quite the "get the goddamn board out asap" way
<wpwrak>
yes, but you'll always have that problem. sometimes, you have to invest a bit into the future.
<lekernel>
I'll do that when I have a good reason, such as switching to a better fpga
<lekernel>
combined with real demand for the device
<wpwrak>
yeah, let's see how this goes
<wpwrak>
your announcement is a little obscure, so unless you want to limit this to people who already follow your day to day work, you may want to explain this in a bit more detail. also, are you sure everyone understands what a "Slowtan6" is ? :)
* Fallenou_
agrees
<lekernel>
since this is a first "for-developers" prototype, the audience is still quite limited for now, yes... what points are obscure?
<Fallenou_>
well, if we want to diminish the price (and then have more people involved and then diminish the price etc etc) we need more people buying it, and then a good explanation of what it is, what it can/could do
<Fallenou_>
what's the goal of the device
<Fallenou_>
what's on it/ not on it
<Fallenou_>
etc
<Fallenou_>
maybe a picture, a video of you using it
<Fallenou_>
something that helps convince someone to buy one
<Fallenou_>
if I get the dual dvi pcb one day, I could try doing such a video
<Fallenou_>
(the one you sent to Alarm)
<Fallenou_>
I will try to arrange a meeting with him about the assembly
<lekernel>
sure, but that's coming later...
<lekernel>
along with a case, complete with built in controls, etc.
<lekernel>
I just need that proto to move forward with the development
<wpwrak>
(obscure) the slowtan, for example. also, the purpose of the board isn't quite clear. is it intended only for co-developing the HDMI mixer ? does it have uses independent from what you're doing ?
<lekernel>
I think most FPGA developers understand "slowtan" ;)
<Fallenou_>
=)
<wpwrak>
also, the user interface is a unclear. does "no knobs" mean that the pots are there, just without knobs on them ? or if not, are the adcs ?
<lekernel>
it's just bare FPGA IO - we may want optical pots instead, still undecided
<wpwrak>
in most languages "slowtan" sounds structurally different from "spartan". so even if you're very familiar with the chip family's slowness, it's a bit of a leap
<wpwrak>
besides, it's already included in "spartan": "practicing great self-denial"
<wpwrak>
maybe you could make a diagram of things that you'll include and things the user would typically add. that way, you can show the overall concept but also make clear what parts are left out.
<wpwrak>
actually, dict is great. under "spartan": "do something for no other reason than that you would rather not do it" -- William James
<wpwrak>
somewhat surprisingly, the thesaurus doesn't make the connection to "masochistic", though
<larsc>
from fpga-developer?
<lekernel>
yes and I want to develop the product/design/UI aspects with people who have good experience with that, who aren't on the MM list yet, and I'm leaving those out of the first proto phase purposefully
<lekernel>
s/those/those aspects/
<lekernel>
so that's why there is just a bare FPGA IO connector, without pots (how many? what type? where? I don't know yet), screen(s), etc.
<larsc>
there is still ethernet right?
<lekernel>
for now yes
<wpwrak>
pity that you're scrapping USB. there's a ton of USB-MIDI equipment with all sorts of pots and such you could use. well, you can still do it over ethernet, with a laptop acting as gateway.
<lekernel>
I still want to be able to pull off TFTP transfers if the HDMI decoder is giving me trouble again
<lekernel>
just put that on the IO connectors
<lekernel>
and there is still no good USB software, and debugging USB is a major PITA as I have discovered
<larsc>
pop quiz - which website is he talking about: "The only reason I'm slightly reticent is that they're website is rather nasty. It feels like it's run by a company, and projects just get shoved in a big list."
<wpwrak>
larsc: too many sites ? :)
<larsc>
it's somewhat on topic
<wpwrak>
must be opencores
<larsc>
hehe
<wpwrak>
at least that's the impression i vaguely recall getting when i briefly looked at it some years ago. haven't paid much attention to it since :)
antgreen has quit [Ping timeout: 276 seconds]
<Fallenou_>
lekernel: even if it's a pain, work has been done so that some stuff work (usb midi
<Fallenou_>
I imagine you don't care about mouse and keyboard anymore
<Fallenou_>
but usb midi is really cool/nice/useful
<Fallenou_>
I really enjoyed the M1 + USB midi experience when I tried
<Fallenou_>
using the nanoKontroller
<Fallenou_>
I think it was the most fun I had with it :)
<lekernel>
it'll be a support and UI pain... maybe as an unsupported hacker extension
stekern has joined #milkymist
<lekernel>
the mouse I bought 2 months ago, for example, still tickles M1 USB bugs. oh well...
<Fallenou_>
well, you don't have to give support, you say USB is there for those who want to spend their time figuring out how it works on their own
<lekernel>
I have a different way of doing things now
<lekernel>
any connector protruding out of the case must work perfectly
<Fallenou_>
but it can be nice to have it, since some device already work *today* without hacks
<Fallenou_>
hum ok
<Fallenou_>
if there is an expansion port where I can plug a "usb daughter board" then it's OK I guess :)
<lekernel>
there is, but my involvement is pretty much reviewing patches and merging those that don't introduce any regression into the codebase
<wpwrak>
you could design the board such that you can mount daughterboards as "bridges" over the main circuit
<wpwrak>
later on, add a split sidewall and you can have make custom covers with relative ease.
<wpwrak>
s/have make/make/
<wpwrak>
kicad now has python scripting support in pcbnew. that ought to help with things like differential lines
<lekernel>
I hear you wpwrak
<lekernel>
next board with kintex-7 I'll give it a try...
Martoni_ has joined #milkymist
larsc_ has joined #milkymist
larsc has quit [Disconnected by services]
larsc_ is now known as larsc
<wpwrak>
(just thinking aloud while catching up with the last few months of the kicad lists :)
kristian1aul has joined #milkymist
Martoni has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
davidc___ has joined #milkymist
ohama has quit [Disconnected by services]
ohama has joined #milkymist
Hawk777 has joined #milkymist
aeris- has joined #milkymist
Hawk777` has quit [*.net *.split]
aeris has quit [*.net *.split]
proppy_ has quit [*.net *.split]
davidc__ has quit [*.net *.split]
aeris has joined #milkymist
playthatbeat has joined #milkymist
aeris- has quit [*.net *.split]
playthatbeat|2 has quit [*.net *.split]
kilae has joined #milkymist
bhamilton1 has joined #milkymist
bhamilton has quit [Read error: Connection reset by peer]
bhamilton1 has quit [Quit: Leaving.]
bhamilton has joined #milkymist
Martoni_ has quit [Read error: Connection reset by peer]
antgreen has joined #milkymist
proppy__ has joined #milkymist
mumptai has joined #milkymist
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
Alarm has joined #milkymist
Alarm has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
antgreen has quit [Ping timeout: 252 seconds]
<wpwrak>
lekernel: actually, since you're already making a PCB + SMT run, that would be a good moment to sneak in a a kicad-based board design. should be much cheaper than setting up a separate run. and the BOM is identical anyway.
<lekernel>
the problem is the cost of making the kicad design in the first place, plus the risk of getting things wrong as opposed to basing on the already tested M1 layout
<lekernel>
as you noted, those boards are expensive, so I really want to avoid respins
<lekernel>
and how would you "sneak" another design? you have to redo PCB masks, stencils, reprogram the pick and place machine, etc.
<lekernel>
and that's where the money is going
<wpwrak>
you panelize the PCB anyway, so instead of one panel with N PADS-based designs, you have one with N-1 PADS plus one kicad
<wpwrak>
the P&P, yes, you need an extra set of positions. but you don;t need to load new parts. so that should be a lot cheaper.
<wpwrak>
and yes, you can't avoid the risk per se, or the cost of making the conversion. i suggested a saving, not a free lunch ;-)
<lekernel>
still sounds like a lot of hassle
<lekernel>
I'd rather focus on, say, make a good pixel shader architecture :-)
<lekernel>
PCB and stuff like that, people take for granted
<lekernel>
debugging USB is in the same category
<wpwrak>
;-) i was more thinking of it in term of finally liberating yourself from proprietary tools and file formats
<lekernel>
next board
<lekernel>
and aren't panelized boards all exposed from the same mask anyway?
<lekernel>
I saw only one mask for the M1 ...
<wpwrak>
i don't know how they expose the panelized board. i would have thought they make a board-sized mask. actually, i'm not even sure if they still make a mask nowadays or if they just plot directly on the board
<lekernel>
the M1 had masks
<wpwrak>
there are companies that aggregate multiple designs on a single PCB, to keep the cost low. that would suggest that there is considerable saving in doing that.
<wpwrak>
but perhaps you can ask them how the price calculation would change.
bhamilton has quit [Quit: bhamilton]
<wpwrak>
also, those recovered PADS files, will they actually be fully editable, with DRC information and all that ? because if they aren't you'll have just the same set of troubles if you make another board revision.
kyak has quit [Ping timeout: 245 seconds]
<lekernel>
nothing will be in PADS anymore
<lekernel>
they take the current altium file converted from PADS and fix the problems that the conversion introduced
<lekernel>
then we can forget about PADS
<wpwrak>
so you'll have fully editable altium ?
<lekernel>
the big bad wolf ate the original PADS files anyway
<lekernel>
yes
<wpwrak>
must be why he seems so sleepy now ;-)
<lekernel>
and edited to add HDMI etc.
<lekernel>
in altium
<wpwrak>
hmm. i'm kinda curious how that will go. i'm rather sceptical about conversions between complex formats.
<lekernel>
well the PCB guy seemed pretty sure of himself...
<wpwrak>
yeah. it's rather interesting that botched PADS conversions would be "business as usual" for a PCB house :)
<davidc___>
lekernel: if you want me to look at the altium files / fix anything up, I have a full Altium license
<wpwrak>
hmm, rules for differential traces: roughly the same length for sure. then i think it already gets design-specific. constant distance from each other ? bend radius ? what happens if the circuit is asymmetric, e.g., one has a test point added, either in-line or with a T trace ?
<wpwrak>
then, how do vias enter the equation. let's say the + trace has to cross the - trace, so one goes under the other. does the length then become len(layer1)+len(layer2)+2*Z(layer1, layer2) ?
<wpwrak>
then, one output, two inputs, so you get a Y. let's call the output A, the inputs B and C, and the branching point Y. is the rule (A+B+) == (A-B-) && (A+C+) == (A-C-) or do also the AY have to match ?
<davidc___>
wpwrak: you can't really do a 'Y' with a diff pair
<davidc___>
wpwrak: [well, unless you do controlled impedance tricks and your receivers don't care about the halved amplitude]
<davidc___>
wpwrak: or you double the characteristic impedance + termination on each leg of the Y
<wpwrak>
i mean splitting + and -. that should still give you the full amplitude.
<wpwrak>
well, almost full. not sure how much the termination eats.
<davidc___>
wpwrak: simulate it in a spice that supports transmission lines; you'll be horrified by the output waveform ;)
<wpwrak>
;-)
<wpwrak>
so you're saying this sort of topology is something i don't have to worry about. good. that simplifies things :)
<wpwrak>
i guess the T would be similar. if the T was normally unterminated (i.e., just for probing), would the test point be in-line or with a short trace branching off the (half-pair) differential line ?
<davidc___>
The T is troublesome reflection-wise [if unterminated]
<wpwrak>
also if inline ?
<davidc___>
depends on your probe. and your rise time :)
<wpwrak>
yeah :)
<wpwrak>
so you're saying it's either don't care or it becomes another Y, which we've already elimiated
<wpwrak>
excellent. killing all the oddball cases helps :)
<davidc___>
wpwrak: well; if your probe input impedance is 1Mohm, then thats OK :)
<wpwrak>
the probe would usually be high-Z, yes
<davidc___>
wpwrak: I'll try and dig out my SI books tonight + recommend you some [or some PDFs ;)]
<wpwrak>
any intuition about the X ?
<wpwrak>
(+ and - crossing)
<wpwrak>
apart from probably being undesirable. but sometimes you have no choice
<davidc___>
oh that? Eh, it'll introduce a slight discontinuity
<davidc___>
Also, how well you need to length match depends on your driver rise-time. You might have tons of skew to play with depending on what you're using
<wpwrak>
yup, that's clear (limit on how precisely you have to match the length)
<wpwrak>
the discontinuity ... you mean length ? or reflections (from trace-via-trace-via-trace)
<davidc___>
wpwrak: impedance discontinuity causing reflections.. Anyhow - what are you trying to route?
<davidc___>
wpwrak: [also, lots of diff standards; especially when running into an FPGA, can just be inverted]. PCIE for example allows inversion for easier routing
<davidc___>
and you can just flip it in FPGA logic
<wpwrak>
i'm trying to come up with a set of things you have to know to handle common differential configurations
<wpwrak>
i.e., is it usually sufficient to know the total length of the net ? or do you need the lengths of all paths ? etc.
lekernel has quit [Quit: Leaving]
<wpwrak>
if T and Y are to be avoided, the total net seems to be sufficient
<davidc___>
wpwrak: ideally, total-length-of-net should be end-to-end length
<wpwrak>
yup. with Y and T gone, it's the same :)
<davidc___>
wpwrak: they don't _need_ to be avoided; it just falls into the "you better check your work" category ;)
<davidc___>
and also talks about skew budgets / etc
<wpwrak>
heh, page 2 ;-)
<davidc___>
And its corrolary - "Anything said by Xilinx should be assumed to be a lie; unless proven by volume-purchasable, working hardware"
<wpwrak>
yeha, xilinx seem to be pretty close to the bleeding edge :)
<wpwrak>
i wonder how altera, lattice, etc., are doing in that regard
<wpwrak>
interesting math for the trace widths and separation
<wpwrak>
i wonder if there's a calculator for that somewhere
<wpwrak>
(open source, of course)
<davidc___>
wpwrak: There are, but there are a ton of formulae that disagree. I've used some of the Polar products before and had good results at MFG time
<davidc___>
wpwrak: really; talk to your board fab :)
<wpwrak>
grmbl :)
<davidc___>
wpwrak: What kind of signals are you trying to route?
<davidc___>
wpwrak: because for short-enough runs at slow-enough risetimes, it just doesnt matter
<wpwrak>
the question i'm trying to answer is "what is the minimum set of features that should be put into or around kicad in order to be able to usefully route differential signals ?"
<wpwrak>
so yes, my conclusion so far is that it gets very very complex when working with very high speeds, etc.
<davidc___>
Oh, gotcha. Yeah, start with just "draw two lines in parallel at a specified spacing"
<davidc___>
That takes care of 90% of the pain.
<wpwrak>
while for more relaxed (and hopefully more common for a while) cases, little more than parallelism and perhaps rough length matching would be needed
<davidc___>
The rest can be tweaked by hand; especially if there is a net query tool
<davidc___>
[better yet, the ability to have a DRC rule that says abs(len(x) - len(y)) shall not exceed n
<wpwrak>
net query = length ?
<davidc___>
yeah, sorry. I haven't used KiCAD in a long time
<wpwrak>
having it in DRC would be great. just having it available for manual checking may already be useful enough in many cases
<wpwrak>
good. so my initial assumption that measuring the length of a net is the main item we need still stands.
<wpwrak>
now, let's see if they've added something like this since the last time i checked ...
<wpwrak>
besides, length is also useful for synchronous buses, differential or not
<wpwrak>
e.g., for making the serpentines not only visually pleasing :)
mumptai has quit [Ping timeout: 245 seconds]
sh4rm4 has quit [Ping timeout: 252 seconds]
<wpwrak>
okay, we have track length. that's the same as net length in the point-to-point case