<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>
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
<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
<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