* awygle
can't even remember what he was planning to document with this
<mithro>
Ha lol
<azonenberg>
cyrozap: what about cortex-m?
<cyrozap>
azonenberg: Ok, so those aren't consistent, but with enough products a 12-bit identifier is going to lose it's numerological significance eventually :P
<azonenberg>
Lol yeah
<pie__>
<sorear> cad is a mess for the same reasons fpga toolchains are a mess
<pie__>
what is that
kuldeep has quit [Read error: Connection reset by peer]
ironsteel has joined ##openfpga
soylentyellow__ has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 240 seconds]
<rqou>
azonenberg: ping?
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
<azonenberg>
rqou: ack
<rqou>
so, my pcb needs two voltages routed throughout, 1.8v and 3.3v
<rqou>
how should i design the planes?
<rqou>
(this is a 4 layer board)
<azonenberg>
In general, I do S-G [core] P-S
<azonenberg>
as my stackup for oshpark 4 layer
<azonenberg>
If i have multiple power rails i route them in the single power layer
<rqou>
right, that's what i'm doing so far
<azonenberg>
using small pours on one of the signal layers to jumper as needed if the graph is nonplanar
<rqou>
but what shape should the power planes be in?
<azonenberg>
for example, on my ethernet switch line card
<rqou>
and yes, there will be (a lot of) pin swapping done on the center chip
<pie__>
azonenberg, arguably that argument doesnt always work :P "better isnt always more popular"
<rqou>
which is just a ginormous mux
<pie__>
and hardware sounds like an industry that would be very loving of its tools :p
<pie__>
azonenberg, im not even an EE i wouldnt know x'D im sorry
<azonenberg>
rqou: sounds kinda like my coolrunner monster board
<rqou>
it's exactly inspired by that
<rqou>
but with fewer issues hopefully :P
<azonenberg>
Lol
<pie__>
rqou, "get off my lawn" :PP
<azonenberg>
so the things at about the 3 o'clock position are dip switches?
<azonenberg>
for config?
<rqou>
yes
<azonenberg>
That's a low speed signal so SI is a non-issue with them
<azonenberg>
hmm
<azonenberg>
and the FTDI is at 9:00?
<rqou>
yes
<rqou>
along with the ginormous HC49
<azonenberg>
And it has no paths to any of the other chips
<rqou>
HC49 really sucks :P
<azonenberg>
everything goes through the mux?
<rqou>
only to the mux
<azonenberg>
in that case i'd have an H-shaped 1.8V pour
<azonenberg>
(rotated H)
<azonenberg>
and have the io from each fpga to the mux simply avoid crossing it on the back layer
<azonenberg>
Should be pretty easy
<rqou>
and also move the SMAs appropriately?
<azonenberg>
Yeah
<rqou>
also, why is my board so _huge_?
<azonenberg>
a ring of 1.8V would be annoying since you'd have to route the pmod stuff over it
<azonenberg>
not that pmods are exactly high speed connectors
<azonenberg>
but this wouldnt help
<azonenberg>
Because pmods
<azonenberg>
my preferred connector for higher density / speed is samtec q-strip
<rqou>
yeah, well, these aren't exactly high-speed parts
<azonenberg>
a QTH-030 is about the size of a pmod but gives you a ground plane and 60 matched 50-ohm signals
<azonenberg>
or 20 diffpairs
<rqou>
btw, what's the proper way to fan out a clock tree?
<azonenberg>
But its also $10 per connector (not per mating pair) :p
<rqou>
i just copied your 49.9 ohm source termination for now
<azonenberg>
That works fine for point to point
<rqou>
i need point to multi-point though
<azonenberg>
for fanout, the easy option is to echo it through an fpga and accept a bit of skeqw
<azonenberg>
skew*
<rqou>
this seems to be what you did on the coolrunner board :P
<azonenberg>
using the fpga as a buffer
<rqou>
skew doesn't matter, but the center FPGA has zero remaining IOs
<azonenberg>
did i? that must have been me being derpy then
<azonenberg>
other option is to drop a few cents on a clock buffer chip
<rqou>
i've seen some weird triangles built out of resistors or something
<azonenberg>
50 ohm series termination on a multi-drop bus would be problematic
<azonenberg>
but at the speeds on the coolrunner board i probably didnt care :p
<azonenberg>
and personally i'd just buffer it
<rqou>
so i do care, because unlike you i have both a fast clock and a slow clock
<azonenberg>
this is what i do on the ethernet line card
<rqou>
2.048 MHz CLK2 and 40 MHz CLK3
<azonenberg>
i have a single 25 MHz osc and eight port buffer
<rqou>
can i just use a resistor wye?
<rqou>
actually, half-serious: can i just make 4 50-ohm traces that gradually taper into one :P
<azonenberg>
i know passive techniques exist but i'm pretty sure you lose amplitude
<rqou>
but i don't care that much
<azonenberg>
a dumb 2:1 impedance matched splitter loses 3 dB
<rqou>
what about tapering in four traces into one?
<azonenberg>
i dont know
<azonenberg>
i'm not an E&M guru
<azonenberg>
i tend to go with simple, conservative designs that i know will work
<rqou>
apparently that actually works for RF (at least sometimes)
<azonenberg>
rather than trying to minimize cost
<rqou>
but then i have to go find a clock buffer chip
<azonenberg>
so?
<rqou>
unless you mean to just stick in some 74HCxxx thing :P
<azonenberg>
no i mean an actual clock buffer
<azonenberg>
silabs etc makes plenty of them
<azonenberg>
And i tend to build one-off designs where NRE on the PCB/stencil, plus design time and the major IC (FPGA etc) is the big expense
<rqou>
yeah, i used one of those at BRCM
<azonenberg>
so trying to penny pinch $10 per board on passives or support components isnt worth it
<rqou>
it's nice and fancy, but not really necessary
<azonenberg>
Other question
<azonenberg>
do you actually need phase alignment on these clocks?
<rqou>
no
<azonenberg>
oscillators are cheap and small... :p
<rqou>
lol
<azonenberg>
you could just throw down several :p
<azonenberg>
say one at top and one at bottom, betwee nthe fpgas
<azonenberg>
and have a < 1/10 wavelength trace between them
<rqou>
so multiple app notes i've seen say that carefully-shaped t-junctions work
<rqou>
i'll probably just use that
<azonenberg>
yeah i'm not saying it wont work
<pie__>
i might give working on some pcbhdl a shot in the near future, goto -> ##pcbhdl :D
<azonenberg>
i'm just saying, a buffer (with everything point to point) is the lowest risk, lowest effort solution
<pie__>
exam season over today, im freee
<rqou>
anyways, i specifically added a 40 MHz clock so that i can do cool VGA demos too
<rqou>
because apparently those are all the rage
<azonenberg>
> 2018
<azonenberg>
> "VGA" and "cool" in same sentence
<rqou>
40 MHz is supposedly the "proper" dotclock for 800x600x60Hz
<rqou>
apparently people go nuts over sprite engines or whatever in FPGAs
<rqou>
which is weird to me, because sprite engines are pretty simple
<rqou>
heck, i bet you could fit "mode7" logic into a larger max v
<rqou>
azonenberg: what do you think?
<azonenberg>
whats mode7?
<rqou>
weird name for the technique where, given a 2d tile engine that can perform affine transformations of a layer, you alter the transform matrix on each scanline to simulate 3d
<azonenberg>
no idea
<pie__>
rqou, ugh i saw that the other day
<pie__>
rqou, and i cant remember
<azonenberg>
my only "GPU" to date was a very simple 2D thing for rendering on a 128x32 oled
<azonenberg>
if i ever do a "real" one it will probably implement opengl ES or something in hardware :p
<pie__>
no shitty intermediate compilers right
<rqou>
azonenberg: basically the general algorithm is: for each screen pixel, use affine transform to get a "background layer" pixel, then perform the usual 2d tile fetching logic and display the resulting pixel
<rqou>
so the hardest part is multiplying
kuldeep has joined ##openfpga
<rqou>
azonenberg: wat, kicad planes don't auto-avoid each other?
<azonenberg>
no, the DRC isnt that advanced yet - would be nice
<azonenberg>
it does DRC fail
<azonenberg>
but it wont auto avoid
<rqou>
apparently it does
<rqou>
there's a "zone priority" setting
<rqou>
you just have to go on the forums to figure it out :P
<azonenberg>
lol
<rqou>
i love how kicad is the best piece of crap we've got :P
<azonenberg>
personally, i dont worry about planes at this point though
<azonenberg>
i start by drawing normal min-sized tracks for power
<azonenberg>
get a complete netlist
<azonenberg>
Then do the copper pours as a near-final step once i have a netlist-complete layout and am optimziing the geometry
<azonenberg>
pours take more work to redo than a trace if you move something
<rqou>
huh
<rqou>
i'm used to doing power first on 2-layer boards
<rqou>
combined with the part where i'm not too familiar with 4 layer :P
<rqou>
wtf how come a bunch of program suddenly won't start on my machine
<rqou>
just linux things
<rqou>
azonenberg: how do you place decoupling for QFPs?
<rqou>
azonenberg: also, what trace width/space do you use for usb, and what size vias do you use for bga fanout?
<azonenberg>
its been a while since i've done usb so i dont have design rules handy
<azonenberg>
245 um trace / 250 space is 100 zdiff on oshpark so you'll want slightly wider traces to get 90 zdiff on the same process
<azonenberg>
(usb1/2 is weird and doesnt use 100 zdiff like every other differential iostandard on the planet)
<azonenberg>
for decoupling, generally either on the top side right between the pins
<azonenberg>
or on the back side
<azonenberg>
If on the back what i do is, have one of the power/ground vias go out and the other go in under the chip
<azonenberg>
then have the cap kinda straddle the vias
<rqou>
er what?
<azonenberg>
you can also have them fan out on the top layer in a bit of a V-shape and put the cap on that
<rqou>
so i'm trying to put all decoupling on the bottom
<azonenberg>
yes, thats what i normally do
<rqou>
but i seem to recall people saying that your power trace is supposed to hit the capacitor first
<azonenberg>
forget that
<rqou>
but that's not really possible in this case?
<azonenberg>
thats hogwash
<rqou>
so that only applies to 2-layer?
<azonenberg>
you want a low impedance path to both the plane and the cap
<rqou>
oldschool long power/gnd wires among 74xx chips
<azonenberg>
this means, via goes directly to the plane
<azonenberg>
trace from via to qfp pin is as short as possible within fanout routability constraints
<azonenberg>
trace from via to cap is as short as possible
<azonenberg>
ideally you want kind of a []8 shape
<azonenberg>
where the cap has one via to the side of each pad
<azonenberg>
and the annular ring is tangent to the cap so there's basically no trace
<azonenberg>
you can't make the ring overlap the cap pad or you might get solder wicking into the via (oshpark tents vias decently but you dont want to rely on it)
<rqou>
so where does the "trace should hit capacitor first" advice come from?
<azonenberg>
Probably old school no-plane designs
<azonenberg>
and misguided attempts to minimize impedance from cap to the IC
<azonenberg>
The goal is to minimize inductance from the cap to the die
<azonenberg>
in-package stuff is fixed and unavoidable
<rqou>
so for my "iz cheap" 2 layer stuff i usually put a ground plane on the bottom
<azonenberg>
Optimal: cap on component side right between pins (but with anything finer pitch than a SOIC this is almost impossible)
<rqou>
and then route power as a star on the top
<rqou>
is this bad?
<rqou>
er, not quite a star
<rqou>
usually i route power as a ring, and then tap off of it
<azonenberg>
Next best: cap on back side with low inductance mounting to plane
<azonenberg>
sorry i meant, next best: cap on back side with via in pad
<azonenberg>
followed by optimized vias
<azonenberg>
least good is long traces anywhere
<azonenberg>
For 2L getting good signal integrity is near impossible, i dont have any strategies to recommend since i just dont do fast stuff on 2L
<azonenberg>
star topology power works ok-ish as long as you have good decoupling local to each chip (higher idnuctance than a plane)
<azonenberg>
and as long as you have all of your signals referenced to ground
<rqou>
i mean, my 2l stuff isn't particularly fast
<azonenberg>
you cant use power as a ref plane obvs
<azonenberg>
if you dont have a power plane
<rqou>
i'm not @bml_khubbard
<azonenberg>
lol
<azonenberg>
yeah hes nuts
<azonenberg>
smart but a little insane
<azonenberg>
i forget what pcb tool he uses... diptrace? expresspcb? something totally not meant for fast work
<rqou>
so i would describe my 2l style as a "oldschool design with modern influences" style
<rqou>
but either way, it's 2l so signal integrity isn't that good no matter what
<azonenberg>
yeah
<azonenberg>
i value my time enough that it's not worth wasting debugging flaky 2L designs
<azonenberg>
if i was mass producing i'd consider cost optimizing
<azonenberg>
but for a one-off i prefer to minimize risk
<azonenberg>
even if the cost is slightly higher
<rqou>
zomgwtf
<rqou>
i just noticed all my pmod pinouts are fucked up
<rqou>
i hate how inconsistent kicad is with everything
<azonenberg>
how so? pin numbering confusion?
<rqou>
yeah
<daveshah>
pmod has a really odd numbering system
<daveshah>
Because it was originally only one row
<azonenberg>
yeah i have a connector footprint specifically for pmods
<rqou>
azonenberg: now i get why you do pcb layout and schematic simultaneously for fpga designs
<azonenberg>
that uses the weird numbering
<azonenberg>
rqou: its not simultaneous so much as a phased approach
<azonenberg>
start with initial schematic capture to define the first round netlist
<azonenberg>
do schematic review
<azonenberg>
then adjust the pin assignments as you do layout
<azonenberg>
then double check the final pin assignments and review the layout
<azonenberg>
so... turbulent waterfall model? :p
<azonenberg>
i.e. directional but with some mixing
<azonenberg>
there's definitely a "figure out all of the connectors, major subsystems, # of caps, PSU, etc" phase that should happen first
<azonenberg>
or you risk doing layout that has to be undone
<azonenberg>
but the pin assignments do have to change a lot to optimize for layout
<azonenberg>
especially since sch symbols normally have pins in die-pad order
<azonenberg>
which may not be the same as package pin order, depending on the package
bitd has joined ##openfpga
<rqou>
pmod is officially the worst spec
ZombieChicken has quit [Remote host closed the connection]
rohitksingh_work has quit [Read error: Connection reset by peer]
<gruetzkopf>
i really need to do a proper implementation of all the terrible things i did to pcie
<awygle>
ugh how does _everyone_ somehow learn that "trace hit cap first" thing?
<awygle>
rqou: if you're being cheap/lazy and don't want a clock buffer, the next best thing is source-series termination with fly-by routing
<awygle>
your board looks next to impossible to route fly-by though
scrts has joined ##openfpga
<awygle>
a real impedance-matched power divider is a pain in the ass to get right, if you're planning to go that route i wouldn't even bother and just do Terrible T Junctions and accept slow edge rates
<awygle>
(like... potentially very slow)
<awygle>
pie__: lmao
scrts has quit [Ping timeout: 264 seconds]
<awygle>
rqou: as for the hugeness, i recommend rotating your DIPs, crunching in slightly in all dimensions, fitting in 100mmx100mm, and going with seeed or dirtypcbs or one of those. although apparently if you go with JLCPCB/EasyEDA you don't even have to bother shrinking it to get decent prices.
<awygle>
<subjective>(or just don't use DIP switches as they are the worst)</subjective>
<kc8apf>
mithro, awygle: wavedrom's bitfield tool can be run locally as well. 'npm install -g bit-field' and bitfield will be in your PATH
<rqou>
awygle: actually, fly-by is possible because the center chip doesn't need the clock
<rqou>
so you can go around the edge
<awygle>
that does make it more achievable (honestly i can't tell where the clock is coming from though)
<rqou>
i mean, it comes from a 4-pin oscillator that can go anywhere
<awygle>
ah
<rqou>
also, does the "trace hits cap first" thing have any truth at all?
<rqou>
only for shitty 2 layer?
<awygle>
the rule the "trace hits cap first" thing is trying to proxy for is "minimize inductance of the loop"
<daveshah>
It might for RF power feeds to MMICs and stuff
<awygle>
on any board with planes, "trace hits cap first" is probably _not_ the minimum-inductance solution, unless you're using microvias or something
<rqou>
what about on 2 layers?
<awygle>
it depends on a lot of things, and most of the time it doesn't matter, but i'm of the opinion we shoudl just teach about loop inductance properly in the first place
<awygle>
rqou: on 2 layers, it still doesn't actually matter 90% of the time, because the critical dimension is cap-to-pin. where the power pour is is ~irrelevant.
<awygle>
(unless you're under-decoupled in which case you have other problems)
<rqou>
but i usually don't use a pour for power, just for ground
<awygle>
sometimes trace lenth is used to add inductance for complex filtering/impedance games in the RF case but that's another story (you have a complex impedance target, you're not just trying to minimize like in the power case)
<awygle>
rqou: if your power delivery trace has significant inductance that can be more complicated. usually you can fix that by just decoupling moar though.
<rqou>
yeah, i usually make sure there's sufficient decoupling
<awygle>
if you're in a scenario where you're well decoupled from the rest of the PDN, then you just want to minimize the pin-to-cap-to-pin loop. do whatever gives you the best result for that.
m_t has quit [Quit: Leaving]
<rqou>
hrm, so purposely routing around to get the power trace to hit the cap first can be worse?
<awygle>
yup
<awygle>
i really would like to know where that belief comes from. i somehow absorbed it too even though i don't remember ever being actually taught it, and had to un-learn it later.
<rqou>
I've seen multiple articles recommending it
<awygle>
next time you come across one toss it my way
<rqou>
which supposedly comed from some vendor, but the stackexchange question now has higher search rank than whatever vendor note it came from
<pie__>
gotta love it when ppl dont list references
<awygle>
the first response to that second post is pretty good
<rqou>
but it's missing a "tldr do this"
<awygle>
that's why it's good :p
<awygle>
but also why it's less useful yes
<awygle>
okay so a 6 mil trace on 62-mil 2L FR4 is 20.4 nH/in, while a 10/20 via in same is 1.3 nH. so (to first order) if your trace is less than 64 mils, it's better than a single via in those circumstances.
<rqou>
single via for what?
<awygle>
on the oshpark 4l stackup a via to the adjacent plane is 0.0676 nH and a trace is 9.8 nH/in, so breakeven is ~7mil
<rqou>
how are you getting these?
<awygle>
Saturn PCB toolkit
<awygle>
or the calculator of your choice
<awygle>
that's just the one i use
<rqou>
does this cost $$$?
<awygle>
na
<awygle>
it is cost-free
<rqou>
so what exactly is the shape you're referring to by "single via" vs a trace?
<awygle>
i hadn't expanded out to actual decoupling geometries, just getting some basic numbers
<awygle>
i don't have time to do a real analysis (even a halfassed one) right now
<awygle>
but if you want to see one ping me tomorrow, i'm easily nerd-sniped into this kind of thing -_-
<mithro>
daveshah: Oh - that might explain what whitequark was trying to explain to me in their ice40 viewer thingy...
<daveshah>
Exactly, that used the rectangular ones too
<mithro>
So `(* FOO=1 *)(* BAR=1 *)` should actually be `(* FOO=1, BAR=1 *)` ?
<daveshah>
mithro: yeah, I think that works
<daveshah>
For some reason you don't see it so often
<mithro>
Should the first one also work?
<daveshah>
Definitely
<daveshah>
More than one attribute is quite rare, so you don't see either often
<daveshah>
Definitely seen the first though
<daveshah>
And the latter at least once
mkal has joined ##openfpga
<mkal>
first time here.
<daveshah>
mkal: welcome
<azonenberg>
o/ mkal
<azonenberg>
are you @dsponfpga?
<mkal>
yes
<azonenberg>
So yeah, i would love to make an FPGA from scratch for that MPW
<azonenberg>
Do you have experience doing ASIC backend work?
<mkal>
yes, I probably taped-out more than a dozen small test chips; mostly with commercial tools though. need to catch up with f/oss toolset; also probably need to get permission for f/oss contributions from work
<mkal>
we actually met at one of the pwn meets a couple of months back
<azonenberg>
oh cool
<azonenberg>
So yeah, i made a cycle-accurate / bitstream-accurate coolrunner-2 emulator in verilog
<azonenberg>
to run on a 7-series FPGA
<azonenberg>
but i'd love to try my hand at a from-scratch new architecture
<azonenberg>
I think LUT6s might be the way to go because that means we can do more logic with less interconnect, might allow higher density in a very space constrained environment
<mkal>
sounds great. we can put down an architecture and code it in RTL or gates
<mkal>
yes, LUT6 makes sense.
<azonenberg>
My thought was to start with a pure simulatable RTL design
<azonenberg>
maybe have some of the other folks here get a VPR-based P&R working for it
<mkal>
absolutely; that's the easiest/fastest way to get started.
<azonenberg>
then make a second version of the design with more customized direct primitive instantiation, verify equivalence
<azonenberg>
And then do custom tile-based layout
<mkal>
we can always look at the generated logic and see if we dont like anything about it.
<azonenberg>
yeah we could stay full synthesized logic and then just do hand placement off that
<azonenberg>
Do you think 8x8 LUT6s is a reasonable target?
<azonenberg>
if we use two adjacent blocks
<mkal>
yep, sounds good
<azonenberg>
have each tile be about 2:1 aspect ratio
<azonenberg>
interconnect then lgoci
<azonenberg>
logic*
<azonenberg>
So the array will be logically square but physically 2:1
<sorear>
it seems to me that the optimal LUT size is a function of the total chip size
<azonenberg>
sorear: why do you say that?
<azonenberg>
in general i am seeing a trend toward coarser grained logic elements
<azonenberg>
to reduce interconnect penalty
<azonenberg>
lut6 vs lut4, larger block rams
<sorear>
because as the chip gets bigger, the typical length of a routing path between two LUTs increases, which means you need more interconnect per LUT
<azonenberg>
The other thing is, as you shrink to leading-edge nodes
<mkal>
for large chips, one can do hierarchical interconnect
<sorear>
so if you want to keep the interconnect area/LUT area ratio constant, the LUTs also need to get biggee
<azonenberg>
ram gets denser faster than fpga logic does
<azonenberg>
So the amount of bram you can fit in a CLB-sized space grows
<sorear>
in a tiny FPGA, interconnect is cheap, so you have less pressure to make coarse-grained elements
<azonenberg>
For this project i'm thinking of having a single block ram sitting in the shared space, seems like they were talking about doing that
<mkal>
do we have an sram compiler for the process we're considering? that's one of the critical pieces of IP
<azonenberg>
it sounds like they are using UMC 180nm
<azonenberg>
I can always take measurements off a coolrunner in the SEM :P (only half kidding)
<azonenberg>
but i assume they can get access to one
<mkal>
f/oss sram compiler exist? probably not.
<azonenberg>
for the FPGA though, we cant use a normal sram compiler
<sorear>
assuming that user designs roughly follow Rent's rule, the amount of interconnect you need is a superlinear function of the LUT count
<azonenberg>
we need single cells so we can route to all of the config bits separately
<sorear>
if user designs are fundamentally 2-dimensional and don't have long wires the story is different
<azonenberg>
LUTs are not going to be 64x1 SPRAM
<mkal>
that's true; regular sram compilers have a minimum size limitation
<azonenberg>
They're going to be 64 DFF/latch elements and a bnuch of muxes
<azonenberg>
This is how actual FPGA dies are implemented, i've seen them :)
<mkal>
but not looking forward to doing custom sram cells either :-(
<azonenberg>
why use sram at all?
<azonenberg>
whats wrong with a d latch?
<azonenberg>
have a shift register along the edge of the chip
<azonenberg>
shift in one column of bits
<mkal>
yes, latches are probably good enough for what we want.
<azonenberg>
then strobe LE for that column of config bits
<sorear>
sram is 6 transistors, latches are like 10
<azonenberg>
yes, but its more complex write logic then
<azonenberg>
coolrunner is heavily optimized
<azonenberg>
they have three different 6T SRAM cells in the chip, at least
<azonenberg>
tuned for different shaped places on the die
* sorear
suddenly wonders if anyone has done a DRAM FPGA
<azonenberg>
there's a single bit |[ shaped cell
<mkal>
refresh is an issue
<azonenberg>
There's a back to back ]H[ shaped one
<azonenberg>
sorry i meant |[]|
<mkal>
need to logout & get on an airplane. will be in redmond tonight
<azonenberg>
Then there's a _-_ shaped one used in the ZIA
<azonenberg>
So yeah we wont be at optimal packing density, but that's totally fine
<azonenberg>
this is a PoC and tech demo, from my perspective
<azonenberg>
it wont be big enough to use anyway
bitd has joined ##openfpga
mkal has quit [Ping timeout: 252 seconds]
Bike has quit [Ping timeout: 252 seconds]
bitd has quit [Ping timeout: 245 seconds]
bitd has joined ##openfpga
noobineer has quit [Remote host closed the connection]
bitd has quit [Ping timeout: 265 seconds]
bitd has joined ##openfpga
bitd has quit [Read error: Connection reset by peer]
<mithro>
azonenberg: I'm interested in new FPGA developments :-)
<azonenberg>
mithro: tl;dr we're in tweet discussions with onchip about making a f/oss embedded FPGA on 180nm UMC as part of a multiproject wafer they're doing using free tooling
<mithro>
azonenberg: Poke me in 30 minutes
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 256 seconds]
Bike has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 264 seconds]
bitd has joined ##openfpga
bitd has quit [Quit: Leaving]
bitd has joined ##openfpga
bitd has quit [Quit: Leaving]
Miyu has joined ##openfpga
<rqou>
azonenberg: your proposed arch superficially sounds like an altera arch :P
<kc8apf>
azonenberg: is the symbol exported or private? If it's private, you just get a copy per library. If exported, you get the linker-dependent behaviors previously described.
genii has quit [Remote host closed the connection]