<rqou>
why does the i386 target use the x86_64 headers? is it supposed to do that?
<azonenberg>
rqou: They're the same compiler
amclain has quit [Quit: Leaving]
<azonenberg>
just -m32 or -m64
<azonenberg>
so, same libc installation
<azonenberg>
The files have x86_64 in the virtual path because I create the virtual path from the primary triplet of the compiler
<azonenberg>
So that if you had a different gcc version installed it would have its own virtual path in the include tree
<azonenberg>
The __sysinclude__ directory is a virtual path in the project root that contains headers from /usr/include etc found by the dependency scan
<azonenberg>
and is unified across whatever OS/platform you use on the build servers
<azonenberg>
So for example. if you compiled the same target for ARM you'd get a different set of headers
<azonenberg>
as that's not the same gcc
<rqou>
i'm surprised the libc headers are correct enough to use the same set either way
<rqou>
i thought there would be some weird bits.h differences or something
<azonenberg>
I'm still investigating
<azonenberg>
But right now its looking like that one gcc has the same header
<azonenberg>
It's also possible my scanner has a bug
<azonenberg>
Huh
<azonenberg>
Welp, you win
<azonenberg>
I wasn't passing -m32 to the preprocessor
m_w has joined ##openfpga
<azonenberg>
I literally just implemented the graph dumping code
<azonenberg>
you were right, i wasnt passing the -m32/-m64 flags
<azonenberg>
the majority of the headers are the same hash so got de-duplicated and defaulted to i386
<azonenberg>
but stubs-32/stubs-64 are different
m_w has joined ##openfpga
felix_ has quit [Ping timeout: 272 seconds]
amclain has quit [Read error: Connection reset by peer]
amclain has joined ##openfpga
forrestv has quit [Ping timeout: 255 seconds]
LoveMHz has quit [Ping timeout: 260 seconds]
felix___ has joined ##openfpga
mithro has quit [Ping timeout: 265 seconds]
the_real_bibor has quit [Ping timeout: 272 seconds]
m_w has quit [Quit: leaving]
cyrozap has quit [Ping timeout: 273 seconds]
SpaceCoaster has quit [Ping timeout: 260 seconds]
felix___ is now known as felix_
cyrozap-ZNC has joined ##openfpga
azonenberg has quit [Ping timeout: 255 seconds]
doomlord has quit [Ping timeout: 265 seconds]
Marex has quit [Ping timeout: 265 seconds]
azonenberg has joined ##openfpga
Marex has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 264 seconds]
balrog has quit [Ping timeout: 244 seconds]
eightdot has quit [Ping timeout: 265 seconds]
the_real_bibor has joined ##openfpga
eightdot has joined ##openfpga
forrestv has joined ##openfpga
balrog has joined ##openfpga
dingbat has quit [Ping timeout: 252 seconds]
_whitelogger has quit [Ping timeout: 272 seconds]
eightdot has quit [Ping timeout: 255 seconds]
azonenberg has quit [Ping timeout: 255 seconds]
felix_ has quit [Ping timeout: 240 seconds]
kmehall_ has quit [Ping timeout: 272 seconds]
cyrozap-ZNC has quit [Ping timeout: 252 seconds]
balrog has quit [Excess Flood]
Bike has quit [Ping timeout: 244 seconds]
cr1901_modern1 has quit [Ping timeout: 264 seconds]
_whitelogger_ has joined ##openfpga
dalias_ is now known as dalias
<azonenberg>
Is that freenode getting dos'd
<azonenberg>
or my connection flapping
kmehall has joined ##openfpga
<felix_>
probably freenode getting ddosd
<felix_>
again :/
balrog_ is now known as balrog
cyrozap has joined ##openfpga
<rvense>
why does freenode get dos'ed?
<qu1j0t3>
rvense: for a variety of reasons from simple pique to attempts to attack protocols to botnet related things to...
<rvense>
qu1j0t3: just seems odd
eightdot has joined ##openfpga
mithro has joined ##openfpga
<azonenberg>
felix_: reason i ask is, my cable line went down at the modem last night
Marex has quit [Ping timeout: 265 seconds]
felix_ has quit [Ping timeout: 244 seconds]
azonenberg has quit [Ping timeout: 255 seconds]
_whitelogger_ has quit [Read error: Connection reset by peer]
Bike_ has quit [Ping timeout: 255 seconds]
_whitelogger has joined ##openfpga
Marex has joined ##openfpga
_whitelogger has quit [Excess Flood]
eightdot has quit [Ping timeout: 264 seconds]
Marex has quit [Ping timeout: 264 seconds]
felix___ is now known as felix_
_whitelogger has joined ##openfpga
azonenberg1 has quit [Ping timeout: 272 seconds]
lain has quit [Read error: Connection reset by peer]
_whitelogger has joined ##openfpga
dingbat has joined ##openfpga
lain has joined ##openfpga
<lain>
azonenberg: freenode is getting dos'd
<lain>
(if no one has responded already)
<lain>
12:47 -- christel (christel@freenode/staff/exherbo.christel): [Global Notice] Hi all, it would appear that Christmas has come early and we're once more receiving a great deal of packets. We'll work with our brilliant sponsors to mitigate as best we can and apologise for the noise and disruption.
<azonenberg>
lain: I kinda figured that
<azonenberg>
when i saw HTTP still worked
<lain>
:3
<rqou>
running a bouncer on linode fremont seems to help make me not disconnect when freenode gets dos'd :P
<rqou>
linode fremont has great connectivity because it's in hurricane electric's datacenter
<azonenberg>
meanwhile my hurricane electric 6to4 tunnel has ~3x worse throughput than my cable connection does over native ipv4
<azonenberg>
i really need native ipv6 but comcast doesnt offer it in my area last i checked
<azonenberg>
at least, not with static IPs
<azonenberg>
is it so much to ask that I have a static /56 or something i can subnet as i see fit?
azonenberg has quit [Ping timeout: 272 seconds]
_whitelogger has quit [Ping timeout: 272 seconds]
kmehall has quit [Read error: Connection reset by peer]
_whitelogger has joined ##openfpga
<azonenberg>
and i think i can get a DHCP v6 allocation
<azonenberg>
but thats a snigle /64
<azonenberg>
i dont think i can get a static larger subnet
<rqou>
i used to be running a linux x86 box as a router because i got tired of the arm/mips ones
<rqou>
on resi you can use dhcpv6 to request a shorter prefix up to iirc /60
<azonenberg>
I may be able to get away from my tunnel soon
<rqou>
i remember reading somewhere that comcast is pretty huge in driving ipv6 adoption in the united states
<rqou>
apparently despite how much their customer support sucks, their technical side is competent
<azonenberg>
Well, i'll poke them again in a bit
<azonenberg>
I'll be happy once I can get a static allocation larger than a /64
<azonenberg>
as well as direct (delegated) control over reverse DNS for it
<azonenberg>
rather than having to email their support every time i spin up a new VM i need to put in DNS
forrestv has joined ##openfpga
dingbat has joined ##openfpga
<rqou>
in general nobody seems to have figured out reverse dns for ipv6
<rqou>
even linode doesn't give you a delegation
<rqou>
you have to poke their webpage
<rqou>
linode's default ipv6 setup is super weird anyways - they give you ONE address but the subnet mask is still /64
<rqou>
you can request a real /64 by filing a ticket
<azonenberg>
HE has it figured out
<azonenberg>
They give me a point to point routed subnet then delegate a /56 to there
<azonenberg>
I can divide the /56 as I see fit
<azonenberg>
then I supply them with addresses of DNS servers for rDNS
<azonenberg>
and they delegate to that
<azonenberg>
I already have the same server set up to host forward DNS
<azonenberg>
so its super convenient
<rqou>
maybe isps are trying to prevent stupid gimmicks like the guy that put an A record on <something>.in-addr.arpa
<rqou>
hey, that means you can also do stupid tricks like putting an A record in the reverse DNS :P
<azonenberg>
lol
<rqou>
blargh, I swear namecheap's website is getting worse and worse
<rqou>
i'm trying to figure out if they have ipv6 glue sorted out yet
<rqou>
but i can't even find the page that configures glue records
dingbat has quit [Ping timeout: 272 seconds]
dingbat has joined ##openfpga
<rqou>
and apparently namecheap still doesn't get ipv6 glue
<rqou>
it's pretty funny that the domain i have hosted with the shadiest-looking registrar (HKIRC) has the best ipv6 support :P
<cr1901_modern>
azonenberg: Is it possible to incrementally build a PCB in Kicad? I.e. do part of the schematic, examine the placement (without DRC having a stroke with missing connections), and then tweak the connections in the schematic and repeat?
<cr1901_modern>
Have I ever mentioned that I hate doing schematic capture :)?
<rqou>
last I tried kicad sucked at this
<rqou>
eagle works quite well this way though
<azonenberg>
cr1901_modern: I do it in kicad routinely
<azonenberg>
when i do, for example. pin swapping in FPGAs
<azonenberg>
typically i build the entire schematic first round, but not with final pinouts
<azonenberg>
then start layout and change pinouts
<azonenberg>
often i find bugs and have to tweak things, add decoupling caps/terminators, etc
<cr1901_modern>
kicad can renew design from schematic?
<cr1901_modern>
Part of the reason I hate schematic capture is that it's difficult to make wires look nice. I should prob use buses more
<rqou>
both eagle and kicad suck at busses imho
<cr1901_modern>
All of them do.
<cr1901_modern>
DipTrace is what I've used for the most part but for a variety of reasons I want to switch to Kicad
<azonenberg>
this is why i want to switch to verilog for pcb design
<azonenberg>
verilog -> yosys -> my scripts -> pcbnew
<azonenberg>
I just haven't had the time to fully finish writing the flow and give it a decent DRC etc
firebird has joined ##openfpga
<cr1901_modern>
Hmmm that might be a decent idea
<rqou>
aren't there possible some things that are still easier to express visually though?
firebird is now known as Guest14521
Guest14521 is now known as cosmobird
<cr1901_modern>
azonenberg: Would you be willing to look at my board for egregious errors before I send it off? (Not done yet). I'm just doing an FPGA interface to the YM2151, so I can have a synth to play with
* cr1901_modern
just remembered that he told you this already lol
doomlord has joined ##openfpga
<azonenberg>
cr1901_modern: I'm busy right now but maybe later
<azonenberg>
rqou: not a ton that i've found, at least for the kinds of boards i do
<azonenberg>
cr1901_modern: Did you see my pcb signoff checklist?
<azonenberg>
rqou: it actually reduces errors b/c you can use generate loops etc to make arrays of terminators, decoupling caps
<rqou>
parameterization doesn't directly require hdl though
<azonenberg>
No, but it's a lot easier to do i none
<rqou>
you can have a parameterizable schematic somehow
<azonenberg>
especially when you can have functions etc
<azonenberg>
hierarchial instantiation
<azonenberg>
it just seems like HDLs solve this problem already
<azonenberg>
all you need is a format translator
<azonenberg>
you dont even need PAR as that's done by hand
<azonenberg>
just synthesis to a structural netlist (no behavioral primitives for now, i may in the future support synthesis of behavioral logic to a CPLD/greenpak/74xx netlist though)
<rqou>
what about the fact that current HDLs have more footguns than schematics?
<azonenberg>
How so?
<rqou>
actually, nvm
<azonenberg>
a lot of the pitfalls i know of are things that are either easy to mitigate (mandate default_nettype none)
<azonenberg>
or only applicable t oRTL
<rqou>
most of the footguns are in the behavioral part, not structural
<azonenberg>
rather than structural design
<azonenberg>
Exactly
<azonenberg>
Structural verilog does not seem like a bad choice at all for this kind of stuff
<azonenberg>
sec, let me send you some of my PoCs from a while ago
<azonenberg>
I never took it to a full board, this was more a testbench for the project
<azonenberg>
It got tabled when i moved
<azonenberg>
i shut down a lot of projects at that time
<azonenberg>
and am slowly spinning them up now that i'm getting back to some semblance of normalcy
<rqou>
I didn't even know verilog could look like that :P
<azonenberg>
First step of that spin-up phase is to move stuff from my old redmine to github, and shut down redmine so i can stop maintaining it
<azonenberg>
Lol
<azonenberg>
as you can see, the majority of the complexity is in the IP core
<azonenberg>
and the usage is super simple
<azonenberg>
This is a fairly complex core too, a fully parameterizable multi-channel SMPS
<rqou>
why verilog though rather than a Python DSL (like MyHDL)
<rqou>
?
<rqou>
with Python I can then do things like "import scipy"
<azonenberg>
among other things, because i dont know python, i know yosys very well, and this will potentially allow full-board simulation with verilog-ams
<azonenberg>
imagine having one unified netlist containing your FPGA design, greenpak design, verilog-A models of passives etc
<azonenberg>
and the PCB
<azonenberg>
then simulate different parts in the analog or digital domain
_whitelogger has joined ##openfpga
<azonenberg>
Yes
<azonenberg>
I made a custom cosimulation framewkro for antikernel that right now only supports ISim (at least only tested with it)
<azonenberg>
ISim for ISE does not support VPI at all
<azonenberg>
So, i used two one-way named pipes
<azonenberg>
and $fread/$fwrite
<azonenberg>
to bridge the simulation's NoC interfaces via pipes then TCP sockets then JTAG to the actual FPGA
<rqou>
i have a duct-tape cosimulation thing that runs MyHDL with both Icarus and GHDL
<rqou>
i need to clean it up and bump it
<azonenberg>
I never really used it
<azonenberg>
it wasnt complete enough
forrestv has joined ##openfpga
<azonenberg>
Reviving it is part of the TODO during my year-long antikernel reboot project
<rqou>
ironically it uses VPI in GHDL as well :P
<azonenberg>
Step 1: get splash v0.2 on github working
<azonenberg>
step 2: build a decent subset of antikernel with it, and move that to github
<azonenberg>
then who knows
<rqou>
apparently GHDL people didn't bother to implement VHPI for real
_whitelogger has quit [Ping timeout: 272 seconds]
specing has quit [Ping timeout: 250 seconds]
Bike_ has quit [Ping timeout: 264 seconds]
wolfspraul has quit [Ping timeout: 250 seconds]
_whitelogger_ has joined ##openfpga
specing_ is now known as specing
zino has joined ##openfpga
azonenberg has joined ##openfpga
pointfree has joined ##openfpga
azonenberg has quit [Ping timeout: 272 seconds]
dingbat has quit [Ping timeout: 272 seconds]
_whitelogger_ has quit [Excess Flood]
_whitelogger has joined ##openfpga
azonenberg has joined ##openfpga
LeelooMinai has joined ##openfpga
forrestv has joined ##openfpga
Bike has joined ##openfpga
<cr1901_modern>
azonenberg: Why are the power rails for some parts hidden? For instance, I need a 74LS245, and VCC is hidden. And I plan to drive it with 3.3V, prob not what Kicad is expecting by default
dingbat has joined ##openfpga
<azonenberg>
cr1901_modern: it connects to the "vcc" net or "vdd" net, i forget which
<azonenberg>
it's a terrible design choice
<azonenberg>
and one of the reasons i do not use kicad 74xx symbols for anything
<rqou>
hey, it made sense in the 1980s :P
<azonenberg>
Modern designs, unlike when kicad was invented, are not 5V everywhere
<azonenberg>
i want to pass power around explicitly
<azonenberg>
The whole idea of power symbols etc is dumb too
<azonenberg>
What i do is i declare special versions of connector symbols
<azonenberg>
that have power outputs on certain pins
<azonenberg>
then simply use named nets
<rqou>
heh, my father had an amazing story about power symbols
<rqou>
at the startup that did networking equipment, the initial schematics were drawn by a combination of my father and one or two other engineers
<rqou>
using symbols that they had "obtained" from "various places"
<rqou>
but different sheets were drawn by different people using different symbol libraries
<rqou>
including the power symbols :P
<azonenberg>
lool
<rqou>
so on the "decoupling capacitor" sheet there was a wire that connected together all the variants of vcc/gnd
<azonenberg>
Looool
<azonenberg>
yeah for my boards i pretty much use my own sch symbols exclusively
<cr1901_modern>
I guess I'll just make a custom part for this and add it to my custom library
<cr1901_modern>
I need a 74LV245
<azonenberg>
Their libraries are not IPC compliant in several spots, making them compliant would brreak existing designs b/c of the braindead way they cache/dont cache some stuff
<azonenberg>
they pull footpritns from github in some cases and cache locally in some cases
<azonenberg>
basically libraries are the worst part of the project by far
<azonenberg>
That said, for all eda software i've ever used
<azonenberg>
i never trusted the stock library
<azonenberg>
got burned too many times
<azonenberg>
I do my own drawings off IPC designs
<azonenberg>
and/or component datasheets
<cr1901_modern>
azonenberg: That's great if you want to spend time doing that :D. I don't.
<cr1901_modern>
"they pull footpritns from github" Erm...
<azonenberg>
The alternative is constantly respinning boards
<azonenberg>
when library footprints turn out to be broken
<azonenberg>
I do not consider that to be an option
_whitelogger has joined ##openfpga
specing has joined ##openfpga
azonenberg has quit [Ping timeout: 272 seconds]
_whitelogger has quit [Excess Flood]
Bike has quit [Ping timeout: 272 seconds]
kmehall has quit [Ping timeout: 272 seconds]
_whitelogger has joined ##openfpga
mithro has quit [Ping timeout: 240 seconds]
_whitelogger has joined ##openfpga
mithro has joined ##openfpga
digshadow has quit [Ping timeout: 244 seconds]
<cr1901_modern>
azonenberg: Do you know of any literature for choosing bypass (or what you call decoupling I think?) capacitor values? Or do you just choose a nice round number?
digshadow has joined ##openfpga
<azonenberg>
I typically choose the largest value I can get in a given package size for voltage etc ratings
<azonenberg>
then choose several package sizes for a range of effective freqs
<rqou>
i remember reading an appnote saying that this approach works fine except for rf
<nats`>
and for ceramic always take at least a rated voltage of twice the expected dc voltage
<rqou>
rf decoupling is special
<cr1901_modern>
azonenberg: Range of effective freqs?
<cr1901_modern>
I'm working with 12MHz signals AT most here
<rqou>
capacitors have ESL
<rqou>
the ESL combined with the actual capacitance creates a V-like shape of impedance vs freq
<cr1901_modern>
I know that. I forgot until now that in SMD components, the package actually makes a difference for the freq response
<azonenberg>
Yeah in fact it matters more than capacitance in most cases
<azonenberg>
nats`: Look at the derating curve
<azonenberg>
they vary so much there is no way to tell without looking at the datasheet
<azonenberg>
i like samsung caps for this reason, nice easy to read curves
<nats`>
azonenberg, twice is a safety margin
<cr1901_modern>
I suppose larger values would be better for DC; the higher the capacitance, the higher the damping of transients.
<cr1901_modern>
Just seems like boards like 0.1uF/10uF or nice round numbers
<azonenberg>
More than twice is sometimes helpful
<azonenberg>
I like 0.47 uF 0402
<azonenberg>
4.7 0603
<azonenberg>
and 47-100 1206-1210
<azonenberg>
Depending on operating voltage etc
<azonenberg>
Depending on operating speed i may not use the entire trio
<cr1901_modern>
5V/3.3V/1.2V
<azonenberg>
5V is a little high for those package sizes in those cpaacitances
<azonenberg>
You might want to run bigger packages / smaller capacitance
<azonenberg>
3.3/1.2 they'll be fine
<azonenberg>
look at samsung datasheets on digikey
<azonenberg>
higher voltage rating does not necessarily mean any more capacitance at the same voltage
<azonenberg>
you'd be amazed how many 25V caps have like 10% of the rated capacitance at 8V
<azonenberg>
I typically try to stay at 60% or more of rated for my target voltage
<cr1901_modern>
So LESS than twice the rated as safety margin :P?
<azonenberg>
Read the datasheet
<azonenberg>
I will not ever give a rule of thumb for this
<azonenberg>
there's too much variation
<azonenberg>
I can say what caps i use from a specific samsung series for specific applications
<azonenberg>
but thats it
<nats`>
cr1901_modern, what chip are you working on ?
<nats`>
they often give minimum decoupling
<nats`>
xilinx does silabs does etc...
<cr1901_modern>
Lattice ICE40HX1K... I'll take a look
<cr1901_modern>
"azonenberg: Depending on operating speed i may not use the entire trio" You mean attach three different caps to the same chip as decoupling? Or use different packages at different parts of the circuit?
<nats`>
prety sure in layout guide or in some guide about designing pc for it it's given
<nats`>
I need to find back the doc saying many value is in fact pretty shitty
<cr1901_modern>
Their layout guide is for BGA; I'm not using a BGA part
<azonenberg>
Typically I use an 0.47 for each power/ground pair
<azonenberg>
or less if the chip specifically recommends less
<nats`>
cr1901_modern, but they don't talk about decoupling ?
<azonenberg>
a 4.7 for each large chip, i dont bother for a small thing like an eeprom
<azonenberg>
For really big like FPGAs, i use multiple 4.7s
<azonenberg>
Then at least one 47-100 on each rail for a large board