clifford_ has quit [Ping timeout: 265 seconds]
MZPX has quit [Read error: Connection reset by peer]
m_w has quit [Quit: leaving]
azonenberg_work has quit [Ping timeout: 258 seconds]
Lord_Nightmare has quit [Ping timeout: 246 seconds]
Lord_Nightmare has joined ##openfpga
digshadow1 has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 248 seconds]
Lord_Nightmare has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 258 seconds]
digshadow has quit [Quit: Leaving.]
Lord_Nightmare has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 258 seconds]
Lord_Nightmare has joined ##openfpga
tecepe has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
Lord_Nightmare has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
Lord_Nightmare has joined ##openfpga
amclain has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
Lord_Nightmare has quit [Ping timeout: 268 seconds]
Lord_Nightmare has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
<azonenberg> digshadow1: So who's in the bay area?
<azonenberg> I'll be in town next week for a vmware con
<azonenberg> palo alto to be specific
<azonenberg> diamondman i know you are
Bike has quit [Quit: leaving]
digshadow has quit [Ping timeout: 260 seconds]
<rqou> i am obviously
<azonenberg> you interested in meeting up for dinner or something in the palo alto area?
<rqou> sure
* rqou budgets 2 hrs of driving time :P
<azonenberg> i'm flying in to SFO mid afternoon on the 15th
<azonenberg> Will be in town both that night and after the con ends on the 16th
<azonenberg> then home to SEA morning o 17th
<azonenberg> of*
<rqou> is this vmworld?
<azonenberg> moosecon
<rqou> hmm haven't heard of it
<azonenberg> it's vmware's internal security con
<azonenberg> tl;dr flying the entire eng team to DC/BH/REcon is too pricey
<azonenberg> So they fly the speakers in to HQ instead
<rqou> shouldn't vmware be raking in the cloud money? :P
<azonenberg> no idea, lol
<rqou> how much have they cleaned up svga? :P
<rqou> the virtual 3d thingy
landley__ has joined ##openfpga
massi has joined ##openfpga
<azonenberg> no idea
digshadow1 has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
<cyrozap> Random question: What in this image indicates the ball size, and how large should the pads be? https://i.imgur.com/N1BJexy.png
<rqou> is there not a "recommended land pattern?" :P
<cyrozap> Not on this part, unfortunately :/
cr1901_modern has quit [Read error: Connection reset by peer]
<rqou> i think the "0.30/0.20" thing is the ball size??
<rqou> no idea how large pads should be
<azonenberg> TI has a wiki page somewhere
<azonenberg> that has recommended land sizes for each ball size
<azonenberg> i dont remember if IPC has a spec ofr this, i assume they do
<rqou> i should get some proper mech-eng training
cr1901_modern has joined ##openfpga
digshadow has joined ##openfpga
azonenberg_work has joined ##openfpga
<cyrozap> Looking at IPC-7351, since the pitch is 0.4mm, the ball size is probably 0.25mm, meaning I should go with 0.2mm pads.
<rqou> er, azonenberg, your notes about pcb fabs and undercut might be relevant here?
<cyrozap> Also, the wiki page azonenberg mentioned is here: http://processors.wiki.ti.com/index.php/General_hardware_design/BGA_PCB_design
<azonenberg> Yes, thats the one
<azonenberg> Do not assume anything about ball size given pitch
<azonenberg> i have seen multiple ball sizes for any given pitch
<azonenberg> But you can calculate the land size accurately given the ball diametr
<cyrozap> I'm making an educated guess since the "0.30/0.20" measurement was there
<cyrozap> Maybe it's max/min
<azonenberg> That sounds plausible
<cyrozap> Worst case, I order the chips and use my calipers to measure the balls myself
<azonenberg> lol
<rqou> i personally try to avoid WLCSP-type packages
<rqou> seems quite difficult to use them on hobby-grade fabs
<azonenberg> rqou: I avoid them when doing a quick prototype on e.g. oshpark
<azonenberg> but if i am doing a high end design with a large FPGA or something
<azonenberg> i am probably using 6+ layers and ViP anyway
<azonenberg> at that point, finer traces cost next to nothing
<rqou> i don't want to pay for ViP :P
<cyrozap> rqou: I would, too, but this is one of the only chips I found that will give me an easy positive and negative 5V.
<azonenberg> also, BGA in general is easier to work with than an equivalent or smaller pitch QFN/QFP IMO
<rqou> oh, 1mm BGA is afaik doable
<azonenberg> 1mm is massive
<azonenberg> rqou: this is a board i made a while ago that i never had a chance to write firmware for (research project for work that kinda got killed before completion)
<azonenberg> that's mini USB bottom left for scale
<azonenberg> every chip on there is basically as small as it could b
<azonenberg> be*
<rqou> i thought for oshpark and you officially can't get traces between vias at 0.8mm pitch
<azonenberg> Correct
<azonenberg> 1mm is doable on oshpark
<rqou> can you cheat on trace width reliably?
<azonenberg> 0.8 you can do in some cases, like dram, where it's depopulated and you don't need to escape between vais
<azonenberg> vias*
<azonenberg> the bigger thing you cannot cheat on is annular ring
<azonenberg> oshpark overdrills sometimes
<azonenberg> the minimum is a hard min and in fact i prefer to go larger when possible to boost yield
<rqou> yeah, i noticed when i sent a board with undersized annular ring by accident
<azonenberg> I prefer Multech PCB (in Shenzhen) for high-end stuff
<rqou> iirc somebody sent a trace width test and oshpark can do better than advertised
<azonenberg> that's who did this board
<rqou> yeah, you mentioned that a while back
<azonenberg> 4 layers w/ ViP and BGA down to 0.35mm 2x2 WLCSP / 0.5mm depopulated / 0.8mm full array
<azonenberg> passives down to 0201
<azonenberg> actually i think i have some smaller 0.5mm full array chips on the underside
<azonenberg> There's bgas bot hsides of that board
<azonenberg> My densest design yet in terms of components per mm^2
<azonenberg> Also, yes they probably can do better than advertised on trace width
<azonenberg> but here's the thing
<rqou> opinions on this guy cheating on trace width? http://blog.kevmod.com/2014/07/playing-with-osh-park-tolerances/
<azonenberg> Can they do it reliably, consistently, every time?
<azonenberg> If i am spending $150 on the FPGA, another $50 on other parts, and $100+ on the PCB
<azonenberg> it has to work the first time
<azonenberg> Most of the time if i am doing a large-scale project (as in, something where slightly smaller trace width would actually matter)
<azonenberg> i have a big FPGA on it
<azonenberg> And it will take me months to do the schematic, PCB, and firmware
<rqou> yeah, i have a bunch of lower end stuff where I plan to only have a low end FPGA and a DRAM thing
<azonenberg> So, going from say a $400 project to a $600 project budget over 6 months is $33 a month
<azonenberg> increase in budget
<azonenberg> Totally worth it, given that the alternative is losing several hundred dollars of parts, doing an expensive pcb respin, and waiting a few weeks for more boards and parts
<azonenberg> For lower-end stuff, target oshpark design rules, stick with them religiously, and you should be ok
<rqou> random question: what's the deal with the xilinx "hard macro" for DDR sdram?
<rqou> is it really a hard macro?
<azonenberg> on what, spartan6?
<azonenberg> yes, its hard IP
<rqou> s6 and 7-series also look totally different
<azonenberg> on 7 series they have hard IP for some clocking and serialization logic
<azonenberg> but the controller is soft
<rqou> s6 doesn't have a "phy only" mode
<azonenberg> Correct
<azonenberg> 6 series was trying to save fabric logic by hardening the whole controller
<azonenberg> Got bit by errata
<azonenberg> 7 series they changed things up, did the performance critical, hard-to-get-wrong PHY stuff in hard IP
<azonenberg> then the rest is soft
<rqou> why aren't the primitives documented?
<rqou> (for 7 series)
<azonenberg> Two reasons
<azonenberg> First, writing docs takes time and money
<azonenberg> they provided you a working IP core and expect you to use it
<azonenberg> second, their engineers didn't test the hard IP in any config other than what their generated code produces
<azonenberg> and there's no guarantee it will work :p
<rqou> ah
<rqou> typical vendor things :P
<azonenberg> Also re oshpark
<cr1901_modern> azonenberg: But you can calculate the land size accurately given the ball diametr <-- Will diameter be given on the datasheet?
<azonenberg> cr1901_modern: should be
<azonenberg> rqou: here's an example of what i was able to do on it
* cr1901_modern isn't really around
<rqou> so theoretically it should be possible to RE it and do some kind of weird delay-shifting-hack-thing, right?
<azonenberg> rqou: it should be possible to write a f/oss ram controller on top of the xilinx PHY primitives, or with slightly worse performance using the selectio resources directly
<azonenberg> bypassing the hard IP
<rqou> yeah, i know bypassing the hard IP is possible
<rqou> i was thinking leveraging the hard IP for a crazy hack of some kind
<azonenberg> That was like my last board using LDOs
<azonenberg> as primary fpga core reg
<azonenberg> before i got over my fear of smps's
<azonenberg> The LDO on the DDR1 power rail got... HOT... when in use
<azonenberg> i respun the board to use a TO-220 reg since i didnt have space to fit a smps in there
<azonenberg> and put a bigger fpga on for lulz (same footprint, just higher gate count)
<azonenberg> and fixed some other bugs while i was at it
<azonenberg> bad footprint on an i2c sensor i think
<azonenberg> That was also using a microchip 10/100 ethernet controller with crypto accel etc
<azonenberg> now? i'd just use a 1gbase-X PHY
<azonenberg> 1gbase-T*
<rqou> what connector are the unpopulated P1/P2/P5 supposed to be?
<azonenberg> FFC ribbon headers
<rqou> ah ok
<rqou> another question: is the xilinx pcie block actually a hard macro?
<rqou> i know the serdes are
<rqou> but i don't see why the rest of it should be
<azonenberg> I believe it's a hard macro that does some low level stuff then presents a PIPE interface to fpga fabric
<azonenberg> with some wrappers around it for resets, workarounds for silicon bugs, etc in LUT fabric
<rqou> there's no real reason to need that though, right?
<azonenberg> Other than leaving more silicon for LUT fabric? no
<azonenberg> you could do it yourself on top of the GTP
<rqou> so it's just "customer said they want this"
<azonenberg> here's a closeup of another oshpark design
<azonenberg> this is a power distribution switch for 5V DC, SNMP management to query V/I for each load
<azonenberg> remote switching
<azonenberg> overcurrent shutdown with programmable threshold and microsecond-level response time
<rqou> yeah i've seen this project on your blog
<azonenberg> It's now redundant
<azonenberg> or obsolete, i should say
<azonenberg> i'm moving to 12V
<azonenberg> which it was supposed to handle, but due to some bugs didnt
<azonenberg> also switching from discrete cables to a backplane architecture
<azonenberg> to save space and ease maintenance
<azonenberg> one connector instead of a bazillion
<rqou> why do you use 6-series so much rather than a low-end 7-series?
<azonenberg> These boards all predated 7
<rqou> ah
<azonenberg> I've done a lot of 7 series work on my ac701
<azonenberg> as well as one 7 series custom PCB
<azonenberg> But that was a kintex :p
<azonenberg> Then i have this one http://thanatos.virtual.drawersteak.com/unlisted/switch-108.png in the pipeline, on hold due to higher priority stuff
<rqou> ah the time travel TDR :P
<azonenberg> that's a 7a200t in ffg1156
<azonenberg> so... not exactly low end 7 series :p
<azonenberg> i'll probably do a massive re-layout of that when i get around to finishing
<azonenberg> aaand look at that, 1:30 in the morning again
<rqou> yup
* azonenberg goes off to sleep before he misses his 10 am client call
<azonenberg> :p
landley__ has quit [Ping timeout: 245 seconds]
<felix_> azonenberg: since artix7 (well, the high range io banks of all 7series devices) don't have oddelay blocks, that's probably not so easy or possible at all
<felix_> the only documentation i've seen for the primitives used for ddr2/3 memory phy are the code generated by the mig and maybe 3 xilinx patents
<rqou> link for patents?
<felix_> uh, i don't have the links right now, since the browser crashed maybe a month ago
<felix_> i used google patents and had a look at the xilinx patents
<felix_> searched for patents filed by xilinx and "phaser" as keyword
MZPX has joined ##openfpga
diamondman has quit [Ping timeout: 256 seconds]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
tecepe has quit [Ping timeout: 250 seconds]
tecepe has joined ##openfpga
clifford_ has joined ##openfpga
<pointfree> azonenberg: I'm also in the Bay Area (San Mateo)
<balrog> pointfree, anything going on with psoc? I've been kinda out of the loop lately
Bike has joined ##openfpga
<pointfree> balrog: eric_j found some info on the coordinate numbering of UDBs in the .route file https://www.reddit.com/r/PSoC/comments/576in6/psoc_5lp_udb_placement_cheatsheet/
<pointfree> I updated the digital system map accordingly and then figured out the DSI numbering from that. https://rawgit.com/wiki/azonenberg/openfpga/images/udb-banks-and-routing.svg
<pointfree> I think the routing fabric registers combine to form a bitmap according to the .route file numbering.
<pointfree> From the route file you can see that the coordinates zig-zag because it's routing on a grid.
<pointfree> Still walking through some of the supposed bitmap and confirming what registers correspond to what lines in the .route file.
<pointfree> The debit tool http://www.fabienm.eu/flf/wp-content/uploads/2014/11/Note2008.pdf could be extended to support Cypress PSoC config.hex and .route file. The paper describes the .bit and .xdl file. Those would correspond to the config.hex and the .route with the PSoC's, respectively.
amclain has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 245 seconds]
Lord_Nightmare has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare has joined ##openfpga
m_w has joined ##openfpga
_whitelogger has joined ##openfpga
<jhol> clifford_: did you get my test instructions for the ice40 driver?
tecepe has quit [Remote host closed the connection]
kuldeep has quit [Ping timeout: 252 seconds]
<clifford_> jhol, yes, but I will not get to it before I return from the US on nov. 21st.
tecepe has joined ##openfpga
digshadow has quit [Quit: Leaving.]
diamondman has joined ##openfpga
diamondman has quit [Ping timeout: 244 seconds]
diamondman has joined ##openfpga
<jhol> clifford_: no worries - that's good to know.
<jhol> having you test it is definitely worth having
massi has quit [Remote host closed the connection]
<jhol> - would anyone else here like to help test a kernel driver for the ice40?
scrts has quit [Ping timeout: 268 seconds]
digshadow has joined ##openfpga
scrts has joined ##openfpga
digshadow-s has joined ##openfpga
digshadow-s has quit [Quit: Lost terminal]
digshadow-s has joined ##openfpga
digshadow has left ##openfpga [##openfpga]
kuldeep has joined ##openfpga
kuldeep has quit [Max SendQ exceeded]
kuldeep has joined ##openfpga
<felix_> jhol: i have an icoboard and a raspberry; so i probably could do some testing. i'm quite busy with other stuff at the moment though :/
<jhol> felix_: well you have the necessary gear. you would probably need to spend ~3-hours on the task
<jhol> I wont take your time if you're too busy
<felix_> 3h sounds good. i might have time for that on sunday
<jhol> ok... one sec - let me publish the instructions
<jhol> it will be quicker if you get a clone of the kernel downloaded before you start
<jhol> and it will save even more if you get the build done before you start
<felix_> ok. i'm too tired to do that right now; will ask you again on sunday
<jhol> felix_: can you send me your email, and I'll forward you the instructions
<felix_> done
<jhol> thanks!
<jhol> felix_: there - sent
m_w has quit [Quit: leaving]
<felix_> had a brief look at it and it doesn't sound too complicated. can you send me some test design for the fpga? i'm not a verilog person and not really motivated to install another vendor toolchain...
<jhol> are you testing on the icoboard?
<felix_> well, the icoboard is the only ice40 board i have at the moment
<jhol> I have a test firmware for the ice40-hx8k-evn board which does some blinkenlights
<jhol> IIRC the icoboard doesn't have any LED
<jhol> but I can still wiggle all the PMOD lines I suppose
<felix_> iirc it has two leds
<jhol> oh ok - well that's enough
<jhol> I'll try and make something that works - you'll need to test it works with icoprog first
<felix_> thx
<felix_> will do that
<jhol> if it doesn't you'll need to rebuild with yosys/arachne-pnr/icebox
<felix_> yeah, changing some constraint should be easy
<felix_> for the pin mapping
<felix_> anyway, i need to get some sleep now. good night.
<jhol> ok - have a nice rest!
<rqou> ok i just discovered gnome-terminal is doing something totally totally insane
<rqou> try opening gnome-terminal
<rqou> then do "Xnest :111 &"
<rqou> "DISPLAY=:111 gnome-terminal &"
<rqou> then kill Xnest
<rqou> both terminals die
<whitequark> I think it launches another terminal in-process
<rqou> wtf why?
<whitequark> dunno. memory usage if you have twenty open terminals?
<rqou> when has this even been a problem ever?
<whitequark> I haven't a faintest clue
<whitequark> kde also does this for some reason
<rqou> so this is probably how they managed to introduce the bug where it manages to copy to the clipboard of the wrong x display if you have multiple
<whitequark> yep
<rqou> but it pastes from the correct one
<rqou> consistency!
kuldeep_ has joined ##openfpga
kuldeep has quit [Ping timeout: 258 seconds]