tecepe has quit [Remote host closed the connection]
tecepe has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 244 seconds]
digshadow has joined ##openfpga
digshadow1 has quit [Ping timeout: 260 seconds]
eightdot has quit [Ping timeout: 268 seconds]
<rqou>
offtopic: I'm catching up on the us presidential debates
<rqou>
i wonder how many facepalms will occur?
<balrog>
all too many
Marex has quit [Ping timeout: 265 seconds]
Marex has joined ##openfpga
tecepe has quit [Ping timeout: 250 seconds]
tecepe has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
eightdot has joined ##openfpga
amclain has quit [Quit: Leaving]
scrts has quit [Ping timeout: 252 seconds]
scrts has joined ##openfpga
doomlord has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 250 seconds]
landley__ has joined ##openfpga
<whitequark>
azonenberg: huh? i googled for pcbhdl
<whitequark>
zero relevant results
<whitequark>
not a single github hit either
<azonenberg>
whitequark: huh interesting
<azonenberg>
i thought i remember considering and rejecting that name
<azonenberg>
because it was i nuse
<cr1901_modern>
I still prefer v2pcb, but not worth bikeshedding over it.
<azonenberg>
well thats the current name
<azonenberg>
So it'll stay that way unless i can be bothered to get off my butt and change it (to something) :P
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
landley__ has quit [Ping timeout: 252 seconds]
azonenberg_work has quit [Ping timeout: 256 seconds]
azonenberg1 has joined ##openfpga
azonenberg has quit [Remote host closed the connection]
azonenberg1 has quit [Client Quit]
azonenberg_work has joined ##openfpga
azonenberg has joined ##openfpga
Bike has quit [Quit: late]
clifford has joined ##openfpga
MZPX has joined ##openfpga
kuldeep has quit [Ping timeout: 245 seconds]
MZPX has quit [Remote host closed the connection]
MZPX has joined ##openfpga
kuldeep has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<cr1901_modern>
whitequark: Did you have time to get started on v2pcb?
x01zz has joined ##openfpga
doomlord has joined ##openfpga
MZPX has quit [Ping timeout: 260 seconds]
x01zz has quit [Remote host closed the connection]
MZPX has joined ##openfpga
amclain has joined ##openfpga
tecepe has quit [Remote host closed the connection]
nurelin has joined ##openfpga
<whitequark>
cr1901_modern: yes
tecepe has joined ##openfpga
MZPX has quit [Remote host closed the connection]
<cr1901_modern>
whitequark: Do you have an overall idea how you're gonna architect the prototype? I have a simple board (only 4 components) that's similar to yours I'd like to try w/ the prototype. But I'd rather work in parallel w/ you/not otherwise interfere
<whitequark>
cr1901_modern: I'll push some skeleton stuff soon
<cr1901_modern>
whitequark: Ack. When you do, I'll take a look.
<whitequark>
cr1901_modern: what EDA package do you use? kicad?
<cr1901_modern>
whitequark: Diptrace, but switching to kicad b/c FOSS (and general lack of support in the hobbyist PCB ecosystem).
<cr1901_modern>
I'll have to read up on the PCB format
<cr1901_modern>
in kicad*
<cr1901_modern>
s/PCB/schematic/
<whitequark>
could probably export to diptrace, assuming that has an interchange format...
<whitequark>
no, not schematic
<whitequark>
I do not plan on exporting schematic, only layouts (with airwires)
<cr1901_modern>
Oh right. then PCB works. And yes, Diptrace has an ASCII format
<whitequark>
sure, could implement that as well
<whitequark>
I see no reason for keeping the number of postprocessors small
<cr1901_modern>
Okay then, cool. I'm def more familiar w/ Diptrace
<whitequark>
then I suggest you read up on that format, as well as specs for DIP packages
<whitequark>
I sure as heck don't care a lot about them. I'll add basic PTH support
<cr1901_modern>
Just did a quick search on the ASCII format. Undocumented :/. So I'll stick to Kicad for now. And ACK on the DIP formats.
<whitequark>
is kicad's format even documented?
<whitequark>
anyway eagle has a DTD but I don't care much for it
<cr1901_modern>
If it's not, then it's easy to RE b/c online "parts creators" exist
<cr1901_modern>
back in 15 minutes
<azonenberg>
whitequark: the kicad net format is not exactly well doc'd but its text based and easy to figure out
<azonenberg>
i wrote an exporter in a few minutes
m_w has joined ##openfpga
<cr1901_modern>
back
<cr1901_modern>
azonenberg: Well, you're a dev for it ;)
<cr1901_modern>
I assume the prototype is going to be: take yosys-json in, spit out something that pcbnew likes
<whitequark>
I'm not using yosys
<whitequark>
at least, not at first
<whitequark>
(but the more code I write, the less desirable verilog seems to me at all)
<cr1901_modern>
What's the input then?
<whitequark>
python
<whitequark>
just like in migen
m_w has quit [Ping timeout: 245 seconds]
<cr1901_modern>
I see. That's cool!
<azonenberg>
whitequark: well as long as the design is modular enough that inputting yosys json is an option
<azonenberg>
with the core erc etc logic shared
<azonenberg>
i dont care what you use in the prototype :p
<cr1901_modern>
whitequark: Could you relink the IPC spec?
<whitequark>
azonenberg: I see no reason you couldn't import schematics from verilog or even define packages in it
<azonenberg>
Yeah, makes sense
<whitequark>
but I think it will be overly awkward
<azonenberg>
Well, i'm excited to see your approach
<azonenberg>
at this point i want something better than schematic entry
<azonenberg>
and thats about my only hard-and-fast goal
<whitequark>
yup. I have no inherent objection to having verilog input other than "I don't think I want to use it at this point"
<cr1901_modern>
Drawing on a piece of paper, scanning it, and using OCR, is better than schematic entry
<whitequark>
lol
<azonenberg>
cr1901_modern: rubylith ftw
<cr1901_modern>
lmao
<openfpga-github>
[yosys] azonenberg pushed 13 new commits to master: https://git.io/vXctk
<cr1901_modern>
I'm assuming each pad is given it's own coordinate system, where origin is "distance of the center of the pad away from (0, 0)"?
landley__ has joined ##openfpga
<whitequark>
not really a coordinate system
<whitequark>
hrm
<whitequark>
origin should be called center, really
<azonenberg>
whitequark: so are you planning to generate pcb libraries in the same project to keep designs portable?
<azonenberg>
fwiw in kicad there's two files you'd have to generate
<whitequark>
azonenberg: exxactly, and more importantly because I don't want to ever muck with packages in eagle etc again
<azonenberg>
the netlist file (exported from schematic) that contains the connectivity and library part name for each refdes
<whitequark>
it's really obnoxious
<azonenberg>
and a library file that contains the set of footprints
<whitequark>
you have to write scripts to generate qfps
<whitequark>
sure
<azonenberg>
you'd then open the layout tool and import both
<whitequark>
eagle has the footprints inlined in .brd
<whitequark>
which is pretty clever.
<azonenberg>
kicad caches them in the board
<azonenberg>
But if you want to fit the model better you should still have the library
<whitequark>
ah so the same thing
<azonenberg>
they unfortunately do NOT do so in the schematic
<azonenberg>
so if you change a sch library it will retroactively break schematics
<whitequark>
sure, I see no problem with just generating a library on its own
<azonenberg>
this is on the list of thigns to fix during the upcoming sch refactoring
<azonenberg>
(pcb got a big facelift over the last ~3 years, sch was lower priority)
<whitequark>
but it's not a super high priority, I would like to get boards working first
<azonenberg>
but hey i'm fine with that
<azonenberg>
exactly
<whitequark>
ah
<azonenberg>
all of my kicad patches have been on layout
<azonenberg>
b/c i kinda planned to stop using sch entry one day :p
<cr1901_modern>
So "renew pcb from schematic" feature doesn't work? :P
<azonenberg>
cr1901_modern: the plan is, you'd re-run the hdl compiler
<azonenberg>
then re-import the netlist
<whitequark>
azonenberg: cr1901_modern: both invited to pcbhdl org
<azonenberg>
anyway gotta get going, have a dentist appt in 25 mins
<cr1901_modern>
I'll ask again about renewing later lol
<cr1901_modern>
and accepted invite
<whitequark>
... did you?
<whitequark>
not according to gh
<cr1901_modern>
Erm, NOW accepted
<cr1901_modern>
Okay, so now we need a hole class. Found the relevant standard for through-hole as well
<cr1901_modern>
whitequark: I'm adding a generic through-hole class now. It's based on the SMTPad class, with appropriate alterations. Not dealing with "circular hole, rectangular pad" at the moment.
rah has quit [Ping timeout: 250 seconds]
<whitequark>
cr1901_modern: erm
<whitequark>
I already wrote one
<cr1901_modern>
oh then nevermind then :P
<whitequark>
just couldn't push because uplink was down
<whitequark>
sec
<whitequark>
cr1901_modern: now I have a question for you actually
<cr1901_modern>
Okay, was redirected to IPC 2221 for annular ring dimensions
<cr1901_modern>
whitequark: land size depends on a number of factors: A = "drilled hole size, which depends on the lead size and hole plating", B = "Minimum annular ring tolerance, which varies in three levels as azonenberg eluded to", C = "fudge factor for process variation". A + 2*B + C
<whitequark>
cr1901_modern: okay
<cr1901_modern>
So I need to find some concrete numbers b/c I know that's what you asked for
<whitequark>
let's ignore C for now, just taking annular ring into account
<cr1901_modern>
For my own reference: Page 83 of IPC2221A
<pcbhdl-github>
pcbhdl/master c98858b whitequark: Reorganize things a bit.
digshadow has joined ##openfpga
digshadow1 has quit [Ping timeout: 260 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<cr1901_modern>
whitequark: IPC7251, page 18: "An oval padstack is considered the same as an oblong padstack."
<cr1901_modern>
is that the information you need?
<whitequark>
erm
<whitequark>
I meant dimensionally
<whitequark>
like, I need to compute the bbox to make part outlines
<whitequark>
I think they're like twice as long as they are wide
<whitequark>
but I have nfc
<whitequark>
lolsob
<whitequark>
so Eagle has a DTD in doc/...
<whitequark>
.... and this DTD is invalid
<cr1901_modern>
Any ratio is acceptable, but all the examples in the spec are "twice as long as is wide"
<whitequark>
whelp
<whitequark>
lol
<cr1901_modern>
I'm giving the best answers I can. This spec isn't easy to read :P. I am under the impression that through-hole isn't as clear-cut as SMD thanks to the hole
<whitequark>
oh, I'm laughing at Eagle
<cr1901_modern>
ahhh
<whitequark>
oh
<cr1901_modern>
You've prob seen the relevant SO q as well, but the IPC specs don't actually give dimensions. Just "given a specific component size, this is how much extra space you should give it".
<whitequark>
I was parsing it wrong
<whitequark>
ahh I see
<whitequark>
well you usually want to go for minimal extra space
<cr1901_modern>
Right, spec gives 3 different clearance recommendations
<cr1901_modern>
erm, sorry, 3 different "how much extra space sticks out from the component" profiles
Bike has joined ##openfpga
<cr1901_modern>
I can ask someone in kicad who maintains their own PCB library for feedback. JEDEC deals with DIP pin dimensions. Not sure if header pin widths are standardized (though their spacing certainly is).
<rqou>
i didn't even know the kernel had an fpga framework
<jhol>
it does - it's quite primitive at the moment, but there's cool stuff going in to it
<azonenberg_work>
i assume this is for embedded stuff
<jhol>
yeah mostly
<rqou>
i thought at best there would be a zynq-specific hack :P
<azonenberg_work>
and not like server accelerator cards
gsisig has left ##openfpga [##openfpga]
<jhol>
yeah the idea is that the FPGA would contain child devices the kernel would have drivers for, or devices you can only get access to through the FPGA fabric
<biot>
jhol: what's going into it? I haven't been keeping up on the plans for it
<jhol>
at the moment you can only program the FPGA through an internal kernel API
<jhol>
there's some patches coming which allow you to specify the firmware in devicetree
<rqou>
i really don't get the desire to cram absolutely everything into devicetree
<jhol>
well you've got to describe the hardware structure somehow
<jhol>
and the FPGA could be quite integral to your hardware
<biot>
if it's not discoverable, it's got to be static config :)
<jhol>
also there is some talk of adding patches for something like this: "cat firmware.bin > /dev/fpga0"
<jhol>
but I think a lot of kernel developers don't like that sort of thing
<rqou>
why is that any worse than embedding it in devicetree?
<rqou>
either way you have a file that contains firmware.bin
<rqou>
that you have to pair with the hardware and kernel
<jhol>
oh yeah - I think they don't like exposing the fpga as a character device
<azonenberg_work>
jhol: i'd make it a block device
<azonenberg_work>
with block size = bitstream size
<azonenberg_work>
but that doesnt allow partial reconfig
<azonenberg_work>
other option is to be a 100% ioctl device
<azonenberg_work>
as in, acts like /dev/null otherwise
<jhol>
yeah I don't know where the discussion got to there
<azonenberg_work>
idk if linux even has a concept of that
marcus_c has quit [Ping timeout: 260 seconds]
azonenberg_work has quit [Ping timeout: 265 seconds]