digshadow has left ##openfpga [##openfpga]
<whitequark> who the hell came up with "ip pseudo header"
<whitequark> this is dreadful
<azonenberg_hk> lol
<lain> never look into dns
<azonenberg_hk> breaks layering so bad
<lain> dns is a real sausage factory under the hood
<lain> when you actually compile together all the RFCs that make it up
<lain> the original RFCs left wayyyyy too much to implementation
digshadow has joined ##openfpga
azonenberg_hk has quit [Remote host closed the connection]
azonenberg_hk has joined ##openfpga
azonenberg_hk has quit [Remote host closed the connection]
azonenberg_hk has joined ##openfpga
azonenberg_hk has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
azonenberg_hk has joined ##openfpga
<azonenberg_hk> whitequark: pseudoheaders for checksums do seem silly
<azonenberg_hk> that is something that is supposed to be handled by the lower level protocol
<azonenberg_hk> having UDP's checksum include values from below layers is dumb
<azonenberg_hk> re "open fpga" was that the giant 74xx lut array?
<whitequark> azonenberg_hk: haven't watched the video because i hate videos, and they dont seem to have verilog in the open
<whitequark> so i dont know
<azonenberg_hk> ah
<azonenberg_hk> there's a guy on hackaday that made like a 10x10cm board as one fpga tile
<azonenberg_hk> containing like a lut3, a dff, and some routing
<azonenberg_hk> that connected via 2.54mm headers to adjacent tiles
<whitequark> oh, no
<whitequark> these people actually taped out an asic
<azonenberg_hk> oh awesome
<whitequark> its an uni project
<azonenberg_hk> PM the link to my main nick or something
<azonenberg_hk> i'll look when i get back
<azonenberg_hk> this is something i want to follow up on lol
<whitequark> done
<felix_> azonenberg_hk: the code part of the ME blob residing in the spi flash can be decompressed (see http://io.netgarage.org/me/ and the de-lzma the lzma compressed modules). the code calls into parts of the on chip rom though (it contains the code running before the code from the flash and the standard library), which as far as i know noone was able to dump yet (either need to decap the chip or get arbitrary
<felix_> code execution on the ME)
<rqou> is this recent?
<rqou> i seem to remember reading about this
<felix_> works for the me versions before the skylake generation
<felix_> iirc on skylake intel moved from arc to a different microarchitecture
<felix_> some newer atom stuff has a sparc core (the txe)
<felix_> skylake and newer might have some small x86 core as ME
<lain> yeah
<lain> the latest are Minute x86
<lain> which is the same x86 core used in those ... Quark? I think
<whitequark> what
<felix_> oh, and there's also the pcu in the uncore of non-ancient intel cpus, which does e.g. the power, clock and thermal management. first core i generation that was some custom 16 bit core; since sandy bridge it's some 32 bit core; i'd suspect arc
<felix_> yeah, could be the core used in the quark soc
<lain> hm, I think that responsibility shifted to TXE on the latest chips
<felix_> what respronsibility?
<lain> pcu
<felix_> for the atoms. i was speaking of the core i processors
<lain> I know for example the latest generation, the TXE/ME is capable of doing microcode update before the cpu ever executes any code
<lain> ah
<felix_> oh and the pcu gets firmware patches via the microcode blob
<lain> inb4 intel devs get even sloppier now that they can patch microcode pre-bios
<lain> the errata lists are truly special.
<lain> :P
<felix_> yep
<lain> I'm glad they don't tell me much about ME, I can't keep my mouth shut
<lain> (NDA)
<lain> it'll be interesting to play with some of the pin straps if/when I ever finish this motherboard
<felix_> on the non-engineering sample chips most interesting debug stuff is fused off sadly (like the rom bypass thing)
<lain> sad times
<cr1901_modern> felix_: The ME core is an ARC processor. Did they change it?
<felix_> but taht's not selected by pin straps, but by some bits in the flash descriptor
<lain> cr1901_modern: it changes often
<felix_> (the romb thing)
<felix_> cr1901_modern: on skylake nad newer it's no longer arc
<lain> felix_: the processor I am working with has a pin for rom bypass
<felix_> nice
* felix_ hasn't looked much at the atom series
<cr1901_modern> Well, if ARC lost their contract, that can't be good for their business :(
<lain> the docs don't mention anything about disabling it on non-ES, but the docs aren't exactly thorough either, so who knows
<lain> this is a Pentium N4200, which is literally the next-gen Atom x7, it is an Atom core rebranded as Pentium
<felix_> cr1901_modern: arc is synopsys and not only intel uses synopsys stuff
<lain> the internal docs say Minute x86 is now used to "unify the code"
<felix_> usb3 on intel is btw. also synopsys with some glue logic
<lain> interesting
<cr1901_modern> (10:48:33 PM) lain: it'll be interesting to play with some of the pin straps if/when I ever finish this motherboard <-- wait, you're making your own motherboard? o.0;
<lain> cr1901_modern: indeed
<lain> I'm almost done with the schematics
<lain> and I have full permission from intel to open source the whole thing, as long as I'm not sharing any NDA'd docs verbatim
<pie_> man freenode is dead tonight..
<lain> so that's nice
<felix_> wow, nice
<cr1901_modern> I wish I could convince myself to do anything high-speed, but I don't have an rf background
<pie_> anyone here up to par on their electromagnetism problems? :/
<felix_> didn't expect that
<cr1901_modern> And getting boards made isn't cheap, so it's not like I can go through a bunch of prototypes
<cr1901_modern> (cheap is relative)
<lain> I was originally targeting atom x7-z8700, but then I moved to the new apollo lake / pentium n4200... it's higher power at max performance, but contains much better IO for what I'm doing, and the package is sparse for an easier layout
<lain> the atom x7 was in a very dense 17x17mm package: https://i.imgur.com/1XxVj9U.png
<cr1901_modern> I'm sorry, how the hell are you supposed to route that within hobbyist design tolerances (I'm guessing the answer is "you don't")
<lain> the pentium n4200 is 24x31mm, and has fewer pins
<lain> yeah, "you don't"
<lain> the atom x7-z8700 is aimed at 8L or 10L pcb with several layers of microvias
<pie_> inb4 intel atom breakout board
<lain> the apollo lake can be routed out on 4L or 6L
<lain> without microvias at all
<rqou> i have an old d945gsejt, it's 6L
<rqou> no idea about microvias
<lain> but I'm using a fair bit of 0.4 and 0.5mm pitch components and want this thing to be small so I may end up with 6 or 8L in the end. hoping to avoid HDI stackup because $$$
<rqou> is this board for a company or ?
<rqou> you somehow just decided to do it?
<cr1901_modern> lain wouldn't be the first person I know who decided to do a motherboard like this, but she'd be the first who is doing an Intel one.
<lain> rqou: I've just always wanted to make an intel mobo :3
<cr1901_modern> Actually, second*. But I never followed up on the former.
<rqou> former = novena?
<pie_> motherboard experiments lain
<lain> haha
<felix_> hehe
<lain> if it works well, I'd like to sell some batches in case anyone wants one, like via groupgets or whatever. I have no intention of ever holding inventory of it
<pie_> man this physics problem really has me stumped >.<
<rqou> get oout, this isn't #anime :P
<lain> my end goal with this design is a small/handheld computer, we'll see how far I get lol
<lain> I'm stealing the screen from a phablet, haven't decided which one yet
<whitequark> rqou: pretty sure it is
<lain> it has 4x usb type-c ports, two of them are capable of displayport alternate function, it can charge from any of them. I'm connecting an fpga via pcie x2
<lain> hoping to get 8GB lpddr3 but I don't know if micron can get me the part I need, if not it'll only be 4GB :(
<lain> 64GB eMMC storage
<rqou> screen: LP097QX1 ?
<felix_> the ipad displays are quite good and have an edp interface
<lain> yeah, that's a possibility
<lain> :)
<cr1901_modern> rqou: Did somebody say #anime :D?
* cr1901_modern just introduced lain to School Days. I'm so proud of myself
<lain> haha
Neuron1k has quit [Ping timeout: 268 seconds]
<azonenberg_hk> lol
Neuron1k has joined ##openfpga
<azonenberg_hk> lain: Sooo...
<azonenberg_hk> Are you gonna use a greenpak in laintop?
<azonenberg_hk> ;)
<lain> haha
<lain> so far I haven't needed to
<azonenberg_hk> You know you wanna
<lain> but it's definitely on my mind in case I need it :P
<azonenberg_hk> even just as an io expander or something
<lain> yeah
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 252 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg_hk> So for the DCMP/PWM block
<azonenberg_hk> There is a shared mux
<azonenberg_hk> four constant 8-bit inputs
<azonenberg_hk> (bitstream configured)
<azonenberg_hk> and a 2-bit fabric selector
<azonenberg_hk> Do you think this should be a separate primitive?
<azonenberg_hk> it seems like it'd make the rest of the design simple
<azonenberg_hk> GP_DCMPMUX or something
<azonenberg_hk> whitequark lain DocScrutinizer05: ideas?
<azonenberg_hk> e.g. figure 94 and 95 of slg46620 datasheet
<azonenberg_hk> the mux switched by matrix1[84:83]
<azonenberg_hk> That seems like it belongs as a primitive
<lain> it does sound like it would make things simpler
<azonenberg_hk> Since it's shared
<azonenberg_hk> Then i have to work out all of the fun mux routing
<azonenberg_hk> Since the DCMPs are very much not isomorphic with one another
<azonenberg_hk> the DCMPMUX can drive DCMP0's + or DCMP1's - input
<azonenberg_hk> oh boy
<azonenberg_hk> it gets better
<azonenberg_hk> There's four 8-bit values
<azonenberg_hk> reg0 ... reg3
<azonenberg_hk> Those values are muxed by the DCMPMUX
<azonenberg_hk> But ALSO they are usable directly :P
<azonenberg_hk> DCMP0 can have reg0 as the negative input for example
<azonenberg_hk> DCMP1 can have reg1 as the positive input
<azonenberg_hk> Sooo what might make more sense
<azonenberg_hk> is if i had a GP_DCMPREF or something block
<azonenberg_hk> that outputs an 8-bit constant signal
<azonenberg_hk> Then the DCMP can take an input from either the DCMPREF or four DCMPREF's through a DCMPMUX
<azonenberg_hk> What a pain in the butt, lol
<azonenberg_hk> inferring "dcmpout = (foo == 8'hCC)" to this is going to be a chore
<azonenberg_hk> But let's start with primitive support and see what happens from that
<azonenberg_hk> Good news is, it seems (from a casual glance) that the SLG46140 DCMP is basically the same
<azonenberg_hk> So once i code this up once i should have support for dcmp in all devices
<DocScrutinizer05> wait, let's see...
<DocScrutinizer05> ./getsilego 46620
<DocScrutinizer05> :-)
<lain> nice™
<azonenberg_hk> DocScrutinizer05: you have a datasheet downloader?
<DocScrutinizer05> hehe yep
<azonenberg_hk> Do any of the old datasheets still exist on their server?
<azonenberg_hk> i have archives of many old versions which are handy for looking at now-undocumented features
<DocScrutinizer05> some do, when you know what's their name
<DocScrutinizer05> they are not listed in index though, which sucks big time
<azonenberg_hk> Yeah
<DocScrutinizer05> jr@saturn:~/Dokumente/Neo900/projbin/neo900-proj/ee/hw> cat ./getsilego
<DocScrutinizer05> #!/bin/sh
<DocScrutinizer05> echo -n $(wget -q http://www.silego.com/softdoc/datasheet.html?filterPN=${1} -O -|sed -n "s%.*href\=\"\([^ ]*${1}[^ ]*pdf\)\".*%\1%;T;p;q" )
<DocScrutinizer05> enjoy ;-)
<DocScrutinizer05> re your original question, this is above my payment class ;-)
pie_ has quit [Ping timeout: 258 seconds]
<DocScrutinizer05> if I had to guess, my completely irrelevant and uneducated notion would be "a dedicated primitive sounds like the right thing"
<DocScrutinizer05> but as mentioned, I have no clue how this stuff you're doing works, really
<DocScrutinizer05> I'd probably expect that I can either use a (set of) config blocks to build the DCMP, mutually exclusive or use another (set of) config blocks (you call them 'primitives'?) to build the PWM or whatever
<DocScrutinizer05> ask wpwrak, he might have a way better idea about this topic
<DocScrutinizer05> azonenberg_hk: (datasheet downloader) you might want to look into the way more complex/comprehensive datasheet downloader in neo900's eeshow: ... :-/ our git is "empty" :-o
doomlord has joined ##openfpga
<azonenberg_hk> lol
pie_ has joined ##openfpga
<cr1901_modern> azonenberg: Why did you say a 4-layer board w/ two power planes is a poor capacitor?
<cr1901_modern> B/c not enough material between the two power planes?
<cr1901_modern> azonenberg_hk: ^^ Whoops :P
firebird_ has joined ##openfpga
<azonenberg_hk> No, too much material
<azonenberg_hk> plates too far apart
<cr1901_modern> Then why does a 6-layer board solve the problem?
<azonenberg_hk> depending on how your stackup is done
<azonenberg_hk> you can have basically two very closely spaced layer pairs
<azonenberg_hk> with thicker gaps between them
<azonenberg_hk> My usual 6L stackup does *not* solve that
<azonenberg_hk> I have sig-ground-sig [space] sig-power-space
<azonenberg_hk> i.e. i go from 4 to 6 layers to get more routing, not more power
<azonenberg_hk> if i wanted more power planes i'd go 8
<azonenberg_hk> and have the same stackup but with the space replaced with [space]power-gnd[space]
<cr1901_modern> Oh, so there's effectively two capacitors then at 8 layers?
<azonenberg_hk> No
<azonenberg_hk> well
<azonenberg_hk> there's only one inter-plane capacitor
<azonenberg_hk> between layers 4 and 5
<azonenberg_hk> 1/3 are signal coupled to 2 reference
<azonenberg_hk> 6/8 are signal coupled to 7 reference
<cr1901_modern> So why isn't there sig-power-[space]-gnd-sig in 4 layer?
<cr1901_modern> that [space] looks like a cap to me :3
<azonenberg_hk> The point is that its a large space
<azonenberg_hk> like 1mm or so
<azonenberg_hk> capacitance is directly proportional to plane area
<azonenberg_hk> and *inversely* to plane spacing
<azonenberg_hk> As you move the plates further apart the capacitance drops off massively
<cr1901_modern> So why can't we make [space] in te 4 layer board smaller?
<azonenberg_hk> You can
<azonenberg_hk> But the standard 4-layer stackup is a 2-layer board
<azonenberg_hk> slightly thinner than normal
<cr1901_modern> also: You said: sig-gnd-sig-[space]-power-gnd-[space]-sig-power-space?
<azonenberg_hk> with an additional layer stuck on either side
<azonenberg_hk> yes
<azonenberg_hk> thats what i'd use for 8L
<azonenberg_hk> well
<azonenberg_hk> sig-power-sig
<azonenberg_hk> for the last
<cr1901_modern> that's what I was gonna say :P
<cr1901_modern> Okay, so because the 4 layer stackup is a slightly thinner 2-layer, the space between pwr and gnd ends up too big to be effective?
<azonenberg_hk> This gives you two pairs of signal layers each coupled to a ref plane
<azonenberg_hk> Yeah
<azonenberg_hk> You can make a 4L that's different
<azonenberg_hk> two thin 2L boards with a very thin gap between them
<azonenberg_hk> but now you lose coupling between signals and reference plane
<azonenberg_hk> Achieving all of this in 4L is impossible, you have to trade off one for the other
<azonenberg_hk> Doing it in 6 can be done, but now you have 4 power planes and 2 signal layers which is usually hard to justify cost-wise
<azonenberg_hk> 8 gives you 4 signal layers plus both strong coupling to ref planes and inter-plane capacitance
<azonenberg_hk> So it's the *minimum* if you want to have your cake and eat it too
<cr1901_modern> Erm... I can't visualize this. Why can't you put "two thin 2L boards" together where the bottom of one is a gnd plane, and the top of another is a power plane?
<cr1901_modern> What is a reference plane in the context of a 4 layer board then?
<azonenberg_hk> You can do this
<azonenberg_hk> the problem is now you dont have the signals coupling well to te adjacent power or ground plane
<azonenberg_hk> So you have problems with impedance matching etc
<azonenberg_hk> ideally you want signals close to a power or ground plane
<azonenberg_hk> power and ground close to each other
<azonenberg_hk> and yet still have enough material to make the board mechanically sturdy
<cr1901_modern> "(2:22:25 AM) azonenberg_hk: the problem is now you dont have the signals coupling well to te adjacent power or ground plane" Why not? B/c the 2L boards are too thick to provide sufficient coupling?
<azonenberg_hk> Either that, or too weak to support their own weight
<azonenberg_hk> You cant have both signal-plane and plane-plane space be thin
<cr1901_modern> Okay, one problem at a time XD
<azonenberg_hk> or the board will be a flex pcb :p
digshadow has joined ##openfpga
<cr1901_modern> Can you humor me and ignore mechanical problems for a moment while I digest what you said?
<azonenberg_hk> If you ignore mechanical issues
<azonenberg_hk> Then i think there's no reason it wouldn't work
<azonenberg_hk> But real PCBs have to obey the laws of physics :)
<cr1901_modern> Okay. B/c I didn't think mechanical sturdiness would affect signal coupling unless it starts to flex :D
<cr1901_modern> So you can't have your cake an eat it too for 4L b/c if all the layers were close, you'd have mechanical problems.
<lain> yeah
<cr1901_modern> So one solution would be to make the sig-gnd and pwr-sig parts of "sig-gnd-pwr-sig" thick
<lain> half-thickness 4L isn't too bad, 0.8mm thick vs. the usual 1.6mm
<cr1901_modern> But that reduces coupling
<cr1901_modern> from what I remember coupling means capacitive coupling in this context?
<azonenberg_hk> Yes
pie_ has quit [Ping timeout: 240 seconds]
<azonenberg_hk> You want capacitive coupling between signal and reference plane to provide a consistent impedance
<azonenberg_hk> Smaller spacing means you can have smaller traces for the same impedance
<azonenberg_hk> which is normally a good thing, you can make your boards denser that way (and have better noise immunity)
<azonenberg_hk> Since you are coupling more strongly to ground than to noise sources
<cr1901_modern> I forget... I think high coupling means lower capacitance, correct?
<cr1901_modern> thus quicker to react
<azonenberg_hk> high coupling means higher capacitance
<azonenberg_hk> And lower impedance
<cr1901_modern> Oh right, it's 1/(j*C*w)
<lain> exactly
<azonenberg_hk> Higher impedance lines will switch faster but have less tolerance to noise
<azonenberg_hk> because it takes less energy to flip their state
<lain> for a lossless line, Z0=sqrt(L/C), so higher C means lower Z0, but it's sqrt() so it's not linear
<azonenberg_hk> Then you want capacitance between power and ground such that they are shorted together at AC
<lain> which is a weird concept :3
<cr1901_modern> Right, a lone capacitance ultimately looks like a short at high freqs.
<azonenberg_hk> Well any AC waveform between them gets superimposed on your signals
<azonenberg_hk> Which is doubleplus ungood
<azonenberg_hk> Anyway, so you're right
<azonenberg_hk> mechanical considerations aside, i cant think of a reason why you cant have everything in 4L
<azonenberg_hk> Actually no wait, there is
<cr1901_modern> I hate how complicated PCBs are...
<azonenberg_hk> If you dont design things carefully you can get power return currents mixed up with signal paths
<azonenberg_hk> and have voltage drops across the ground plane
<azonenberg_hk> that mess with your signals
<azonenberg_hk> But in theory if yo udidnt care about making the board small
<azonenberg_hk> i think its doable
<cr1901_modern> It's like the absolute most horrifying form of electromagnetics in a tiny package
<cr1901_modern> (well classical electromagnetics)
<azonenberg_hk> Lol
<lain> I like the challenge
<lain> :D
<cr1901_modern> None of the simplifications you use when doing a schematic apply. Most importantly, that a piece of metal attached to GND is, well... gonna be uniformly at ground
<azonenberg_hk> lain: Says the nutcase designing an intel mobo for fun
<lain> :>
<lain> http://www.ultracad.com/article_outline.htm <- this is a fantastic set of articles on transmission lines, from a down-to-earth perspective
<cr1901_modern> I have trouble visualizing how a solid copper plane can have a voltage difference across it even if return currents decide to creep onto the signal layer b/c the copper plane is quite wide (low resistance)
<azonenberg_hk> cr1901_modern: Low is not zero
<azonenberg_hk> also, at AC signals have propagation delays
<azonenberg_hk> So if you have voltage at point X it takes time to reach point Y
<azonenberg_hk> So the further the metal is from a straight line between source and dest, the less it contributes to the propagation of an AC signal
<cr1901_modern> If I could draw a picture, I could explain why I'm still confused...
<cr1901_modern> So the further the metal is from a straight line between source and dest, the less it contributes to the propagation of an AC signal <-- except, aren't electrons ideally support to well, follow their traces, even if they're NOT a straight line?
<cr1901_modern> s/electrons/AC signal/
<lain> the return current from a trace will tend to "bunch up" under the trace on the plane below (assuming there is a plane) due to the coupling
amclain has quit [Quit: Leaving]
<cr1901_modern> Why would that be so? I mean, if an AC signal goes through an IC package, to the other side, the return current would be all on the other side of the IC, no :)?
<cr1901_modern> What does "return current" mean in this context?
<lain> in this context I mean the current that completes the loop, so like when chip A is outputting a voltage to chip B, they must share a ground and whatever current goes out chip A, through the trace, into chip B, must have a corresponding return current through the ground plane for example
<lain> or whichever direction the current may be
<lain> we know it always has to be in a loop, and part of that loop is generally going to be through a reference plane of some sort
<cr1901_modern> Right, "bunch up" *under the trace* was what confused me
<lain> and if the trace is near (coupled to) a reference plane, it turns out that the least impedance path for that return current is right under the trace
<lain> this is actually also what determines how close you want to get traces
<cr1901_modern> 1. If a trace goes into chip A, I would expect that current to exit on a separate trace :P
<lain> :)
<cr1901_modern> 2. If you only give a trace a single path to the reference plane, wouldn't that be the only path the current could go anyway (assuming reasonably that the current didn't decide to use the PCB material as a return path)
massi has joined ##openfpga
<lain> right, but I mean like this: http://www.sigcon.com/images/news/v8_08_5.jpg
<lain> the current density on the reference plane will be highest right under the trace, corresponding to its return current
<cr1901_modern> Oh... interesting
<lain> and actually this is why it's generally a Bad Thing™ to have slots in your reference plane, it forces the return current to take a longer path: http://www.aerospacepal.com/wp-content/uploads/2014/12/Return-Current-Loop1.png
<cr1901_modern> I suppose that's b/c of the capacitive coupling that determines that path
<lain> yep, precisely :3
* cr1901_modern errors out with ENEEDSMOREPICTURES
<lain> (the reason a longer return path vs. signal path is a bad thing is twofold: 1/ the impedance changes due to the change in coupling where the plane abruptly stops, and 2/ the overall signal length loop is now larger than it may appear, it may be quite large in fact, and that constitutes a loop antenna)
<lain> I mean, all current loops constitute a loop antenna, but that's just another reason to keep trace-to-plane distance low: reducing the loop area, which reduces radiative emissions *and* coupled noise
<cr1901_modern> The impedance change causes reflections?
<lain> aye
<cr1901_modern> (2:32:41 AM) azonenberg_hk: You want capacitive coupling between signal and reference plane to provide a consistent impedance <-- consistent impedance wrt a single current loop, or consistent impedances between traces?
<DocScrutinizer05> at which frequencies this effect gets relevant?
<lain> DocScrutinizer05: it's hard to make a rule of thumb, but I tend to consider it above 50MHz unless I don't care if a design fails / requires tweaking, then maybe 100MHz :P
<DocScrutinizer05> ta :-)
<lain> cr1901_modern: each trace for which impedance matters will have some desired impedance, to match the transmitter and receiver at either end
<lain> and then it's just a matter of keeping the traces far apart enough that they don't meaningfully couple with each other
<cr1901_modern> Oh, this is basically only relevant for high speed stuff?
<lain> yeah
<lain> I mean, it applies to everything of course, but high speed is where it becomes necessary to consider this in a design
<lain> even if you're only dealing with 1MHz signals, a large current loop is still an antenna, and that might be a problem ;) but usually it only matters at high speeds, where you have less and less time to allow signals to settle
<cr1901_modern> The problem with the gnd plane in that example is the *abrupt* impedance change, correct? Not necessarily that the return path got longer?
<lain> correct, in that situation you would want to route the trace around that opening in the plane so it more closely matches the return path
<lain> re: reflections -- I like to visualize it as a water pipe. you have to imagine it's always full of water (conductors are always full of electrons, you're just pushing them around). with high speed, what you're doing in the water analogy is akin to sending a pressure wave down the pipe, like if one end of the pipe has a rubber diaphragm and you smack that real good :P
<lain> if the pipe diameter steps down suddenly somewhere along its length, some of the pressure wave will hit the wall where it steps down, that will reflect back to the source
<lain> depending on conditions (source impedance, transmission line loss, etc), the reflection might again reflect off the source and continue down toward the receiver, and so on
<cr1901_modern> Well, if you're not actually matching Z_0, I seem to recall that if you make your transmission line some specific fraction of the wavelength of the frequency of interest, there will be no reflections
<cr1901_modern> I know this is a bad idea, but I do remember something about impedance seen by a transmission line being dependent on length
<lain> ah
<lain> you're probably thinking of "critical length"
<cr1901_modern> Nah it's not that
<lain> the idea with critical length is to keep the propagation delay of your transmission line to less than half the rise time of the signal
<lain> that way any reflections that occur will get back to the transmitter while the signal is still rising
<lain> and it will most likely have settled by the time the receiver samples it
<cr1901_modern> This is for length > wavelength :D
<lain> oh
<cr1901_modern> But I don't remember the details
<lain> well, above a certain frequency the transmission line stops behaving like a normal current-carrying trace and starts behaving like a waveguide
<lain> then stuff gets all manner of fucked :D
<cr1901_modern> Yea I never got that far
<cr1901_modern> (2:43:16 AM) azonenberg_hk: So the further the metal is from a straight line between source and dest, the less it contributes to the propagation of an AC signal <--- still mulling this over. lain's picture suggest that the return current will follow the trace, not a straight line from src to dst.
<cr1901_modern> I still don't quite visualize under what conditions you'd see the GND plane have potential differences wrt GND
<lain> mainly the water analogy thing
<lain> you're only going to get sustained voltage differences in a gnd plane with very high currents, by ohm's law
<lain> but high-speed is mostly just little pressure waves
<lain> where pressure == voltage in this context
<lain> every time a signal rises or falls, that's a pressure wave through the trace and the corresponding return path in the plane
<lain> it spreads out a bit, I forget but I think it's a hyperbolic function or something goofy, so the effective "width" of the pulse in the plane is a bit wider than the trace
<cr1901_modern> What did azonenberg mean by a straight line from src to dest then, considering the picture you showd me :P? http://www.sigcon.com/images/news/v8_08_5.jpg
<lain> I don't know :D
<lain> I'm having trouble parsing his statement :P
<cr1901_modern> I'll ask him tomorrow then. I'm kinda... saturated tonight lol
<lain> hehe
<cr1901_modern> Maybe I'll be able to design a high-speed PCB after all... maybe...
* lain cheers you on :P
<azonenberg_hk> What i meant was
<azonenberg_hk> the further you get from under the trace
<azonenberg_hk> the smaller the contribution of the plane to the impedance is
<azonenberg_hk> since the coupling is less etc
<lain> ahhh
<lain> height above plane
<lain> also! the higher the trace is above the plane, the more the return current spreads, so the further away other traces must be if they are to avoid crossing the streams
<cr1901_modern> Well, I suppose yes that would be a straight line in that context of measuring impedance between two points in the GND plane
<cr1901_modern> actually scrap that
<cr1901_modern> azonenberg: What DID you mean by straight line :D?
<azonenberg_hk> cr1901_modern: i was assuming a linear trace
<azonenberg_hk> as you spread horizontally away from the path from source to sink
<azonenberg_hk> the current density drops off
<cr1901_modern> okay, that makes sense. I'll mull over the GND plane voltage differences and get back to you :P
<cr1901_modern> b/c I still don't get it, but I'm saturated tonight
<cr1901_modern> Can only parse so much at once
<cr1901_modern> You notice how I drilled you two? There's a reason. NONE of this was explained to me in Uni*, and tbh, modeling PCBs as transmission lines, current sheets, etc in my head only took me so far. I'm "too stupid" to account for every possible thing that can go wrong.
<cr1901_modern> *We only discussed transmission lines in the context of, well... cables :P.
<azonenberg_hk> Lol
<cr1901_modern> Much easier to derive resistance/capacitance of a circular infinitely long 1D cable than a 3D PCB
<azonenberg_hk> And i studied computer science
<azonenberg_hk> never even took a basic E&M class
<azonenberg_hk> i picked this all up in my spare time
<cr1901_modern> Can you derive the resistance of a coaxial cable :)?
<lain> w2aew on youtube also has some excellent vids on practical transmission line stuff
<cr1901_modern> Yes, I've seen him before.
<cr1901_modern> azonenberg_hk: RF electronics and PCB design was offerred as an elective. I never took it, regrettably, and found by the time I wanted to know that info, I forgot the basics. I don't doubt there are good references online for characteristic impedance and stuff like that, but I was never pleased with the ones I saw
<lain> the doug brooks articles I linked earlier are what first cemented it in my mind
<lain> nothing else made sense, but those clicked with me for whatever reason
firebird_ has quit [Ping timeout: 256 seconds]
Bike has quit [Quit: leaving]
azonenberg_hk has quit [Remote host closed the connection]
firebird_ has joined ##openfpga
marcus_c has quit [Remote host closed the connection]
marcus_c has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
maaku has quit [Ping timeout: 260 seconds]
maaku has joined ##openfpga
maaku has quit [Ping timeout: 260 seconds]
maaku has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
doomlord has joined ##openfpga
digshadow has quit [Quit: Leaving.]
firebird_ has quit [Ping timeout: 258 seconds]
SalvorH_ has joined ##openfpga
SalvorH has quit [Ping timeout: 250 seconds]
azonenberg_hk has joined ##openfpga
pie__ has quit [Ping timeout: 268 seconds]
amclain has joined ##openfpga
firebird_ has joined ##openfpga
m_w has joined ##openfpga
digshadow has joined ##openfpga
Bike has joined ##openfpga
digshadow has quit [Quit: Leaving.]
massi has quit [Quit: Leaving]
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
pie_ has joined ##openfpga
kuldeep has joined ##openfpga
jhol has quit [Quit: Coyote finally caught me]
jhol has joined ##openfpga
carl0s has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
SalvorH_ is now known as DjSalvorH
carl0s has quit [Ping timeout: 258 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 258 seconds]
mifune has quit [Ping timeout: 268 seconds]
<lain> "hashed passwords (using MD5)"
<azonenberg_hk> ..
uwe__ has quit [Ping timeout: 258 seconds]
uwe__ has joined ##openfpga
<azonenberg_hk> lain: Did you see my comments about the GP_DCMP a while ago>
<azonenberg_hk> ?
<lain> azonenberg_hk: I was distracted
<azonenberg_hk> ah
<azonenberg_hk> i was wondering about the input mux to the DCMP being a primtiive
<azonenberg_hk> the mux of four constant values
<azonenberg_hk> and the constants driven by another primitive
<azonenberg_hk> it seems a bit awkward but the best way to ensure things work right
<azonenberg_hk> b/c there are multiple input paths that can be driven by the same constant
<azonenberg_hk> like, same bitstream bits
<azonenberg_hk> and i have to keep them consistent
<azonenberg_hk> So i'm making a GP_DCMPREF block that just drives an 8-bit constant from a parameter to a wire
<lain> hmmmmm
<lain> yeah
<lain> that sounds reasonable given the constraints
<azonenberg_hk> Eventually i plan to infer them where tractable
<azonenberg_hk> but for the first iteration 100% instantiation of everything
<azonenberg_hk> mind you, you dont always need the DCMPREF and DCMPMUX instantiated
<azonenberg_hk> if you're e.g. comparing the ADC value against the SPI value or something
* lain nods
<azonenberg_hk> b/c the second stage input mux is separate for each DCMP
firebird_ has quit [Ping timeout: 264 seconds]