<pie__>
* azonenberg finds it funny that people complain about nuke waste
<pie__>
<azonenberg> while also banning reprocessing that would turn 98% or so of it back into usable fuel :p
<pie__>
hopefully solid nuke storage gets turned into a superfund site before 100,000 years is up
<Ultrasauce>
I think the short answer is if it were easy they'd be doing it
<azonenberg>
Ultrasauce: reprocessing in general is politically difficult
<rqou>
but but but but terroristsssssssss :P
<azonenberg>
people are worried that transporting / doing anything to waste could cause environmental issues, increase risk of it being stolen by terrorists, etc
<rqou>
also the potential of an arab nuclear reactor? :P
<rqou>
gotta get your tech from north korea instead :P :P
<rqou>
does Best Korea have reprocessing? :P
<rqou>
they do right? hence the failed stuxnet attempt on them?
<rqou>
(failed because they had almost no connection with the outside world, unlike iran)
<rqou>
azonenberg: when are you building that ultracentrifuge? :P
<azonenberg>
rqou: lol
<azonenberg>
gas diffusion might be a fun way to make booze too
<whitequark>
awygle: nice story
<awygle>
whitequark: yeah I liked it
<rqou>
amazingly, it's apparently _not_ a reference to nuclear weapons
<rqou>
just "traditional" warfare
<rqou>
well, "modern" but pre-nuclear
diadatp has quit [Ping timeout: 265 seconds]
<Bike>
warsaw and manila got it worse right
<awygle>
did anyone get pissed by that MOAB reporting a while back?
<rqou>
MOAB?
<awygle>
Mother of All Bombs
<Bike>
"daisycutter" sounds better
<azonenberg>
awygle: apparently the proper name now is "massive ordnance air blast"
<azonenberg>
of course i'm sure nobody in the service uses that unless they're on camera :P
<awygle>
The point is it's 11 tons, which makes it 500 times less powerful than Little Boy, but it was reported as like a dangerous escalation in the potential of warfare
<awygle>
"the biggest non nuclear explosion" but no context on what that means
<Bike>
i can see that making sense. i mean, the military is way less likely to deploy a nuclear weapon
<whitequark>
it also produces a volumetric explosion
<Bike>
but then it's more like, measuring war-ness by tons of TNT kind of sucks
<Bike>
warocity
<whitequark>
which is significantly more damaging afaik
<Bike>
what is a volumetric explosion?
<awygle>
it's true that damage doesn't scale linearly with yield
<whitequark>
instead of having this chunk of fuel+oxidizer that quickly increases in volume and becomes gas, it spreads fuel over a large volume and ignites it, which creates more of a pressure differential or something like that
<whitequark>
the bottom line is that you don't get shredded by fragments, your innards get liquefied by the shockwave
<whitequark>
also if you get it into a building it exhausts oxygen in the building as the products take less volume than the reagents after they cool down a bit
<whitequark>
and the building folds onto itself
<whitequark>
at least, i think that's what happens, i might be wrong
<rqou>
wow
<Bike>
i'm gonna be honest, both options re: my innards sound unfortunate
<rqou>
we've certainly come a long way since "yellow dyes" :P
<Bike>
"escalation" makes me think less technical things like altering the RoE or increasing deployment into new areas or suchlike
<whitequark>
i don't think it's a paradigm shift either
<whitequark>
it's just a pretty nasty weapon
<awygle>
"fuel air bomb" is the term of art
<rqou>
<ha ha only serious> which company's stock will go up/down once one of these weapons actually gets used?
<rqou>
i.e. who is profiting from developing these?
<whitequark>
rqou: MOAB is Air Force's internal development
<Bike>
that's what i thought a fuel air explosive was
<Bike>
introducing the new Second Cousin of All Bombs, which is actually a recoilless rifle
<whitequark>
"Another Defense Intelligence Agency document speculates that because the "shock and pressure waves cause minimal damage to brain tissue…it is possible that victims of FAEs are not rendered unconscious by the blast, but instead suffer for several seconds or minutes while they suffocate"."
<rqou>
whitequark: i don't have a link handy, but iirc somebody back in the day managed to figure out that the "secret new material" used in thermonuclear weapons was lithium
<rqou>
solely by looking at stock data
<whitequark>
rqou: yup
<Bike>
you know, today i saw the headline ««Is curing patients a sustainable business model?» Goldman Sachs analysts ask» but i think you managed to top that, as far as impersonal reports go
<whitequark>
even worse
<whitequark>
rqou: USAF decided to check if a few rando physics students can develop a functional nuke just from open materials, hired a few, and they did a good job
<Bike>
i did not, though i've heard of PLUTO and the churchill crocodile
<Bike>
i like how wwii had all these nuts engineering projects but their results were uh, equivocal
<Bike>
pluto didn't take over from tankers, mulberry harbors didn't last very long
<awygle>
Woo boards
<Bike>
the nazis had all kind of sci-fi bullshit that did them very little good
<Bike>
bombsights were considered so important they were mounted with self-destructs (who knew anyone's actually ever done that) but the nazis had the tech already anyway
<awygle>
Yeah but also radar lol
<awygle>
The nuts projects are only more nuts than the ones that worked with the benefit of hindsight
<Bike>
fair
<Bike>
oh yeah, and that brother? of JFK who died in a prototype drone bomber
<Bike>
controlled by television
<awygle>
Skinner wanted to put pigeons in missiles. Did we ever try that?
<Bike>
never deployed, it seems
<Bike>
«Project Pigeon was revived by the Navy in 1948 as "Project Orcon"» hey nice
<Bike>
the "static flame trap" in the PWD article is exactly like half life two. that's kind of weird, honestly
<Bike>
whitequark: wtf, the "harvey flamethrower" looks even shittier than a farming flamethrower
diadatp has joined ##openfpga
<sorear>
3 mg/m^3
diadatp has quit [Ping timeout: 264 seconds]
<sorear>
How far does zeolite tech need to advance before this is an interesting number
<sorear>
How long do we have until then
<awygle>
sorear: huh?
<sorear>
awygle: natU in seawater.
<awygle>
ahhh
<awygle>
TIL about zeolites, incidentally
<whitequark>
zeolites are super neat.
<whitequark>
I use them to make absolute EtOH
Xark has quit [Ping timeout: 245 seconds]
pie__ has quit [Ping timeout: 264 seconds]
Xark has joined ##openfpga
diadatp has joined ##openfpga
<rqou>
oh wheee, apparently the dorito in chief decided to have some "fun"
<rqou>
i take a nap and this happens
<whitequark>
azonenberg: awygle: should I route 1V2 over one of the signal layers, or over the inner 3V3 plane?
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
Lord_Nig- has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 265 seconds]
Lord_Nig- is now known as Lord_Nightmare
<awygle>
whitequark: whatever is easiest. signal is marginally better probably.
<whitequark>
alright
<awygle>
just because you don't want to route stuff directly over a split in the 3v3 plane
<awygle>
If it's on the adjacent signal layer
digshadow has quit [Ping timeout: 268 seconds]
eric_ has quit [Read error: Connection reset by peer]
digshadow has joined ##openfpga
<cr1901_modern>
How many layers is this board ._.?
kmehall has joined ##openfpga
<awygle>
4
<awygle>
cr1901_modern: i goofed up pretty bad by not reading the fine print.... or the normal size print as the case may be
<awygle>
so i have a controleo kit... and no oven
<cr1901_modern>
awygle: Yes you have to buy the oven separately
<cr1901_modern>
they have a "reference oven" to buy that's $30
<awygle>
yes but i got the convection oven kit (and i really want a convection oven)
<cr1901_modern>
I've considered buying the one azonenberg uses tho (which implies the bigger kit)
<cr1901_modern>
I never seem to be in a position where I'm comfortable spending $300 on a hobbyist endeavor with a real risk of failure...
<cr1901_modern>
(in a position financially*)
<awygle>
yeah i hear you
<cr1901_modern>
(not that the inside of a toaster oven is complicated. Just I have a knack for making things worse when I open them)
<cr1901_modern>
s/them/anything/
<awygle>
i'm a little skeptical myself but i'm kind of pot-committed lol
<awygle>
anyway i'll keep you updated, oven arrives tomorrow
<cr1901_modern>
I appreciate that :). And "should I route 1V2 over one of the signal layers". There's more than two signal layers?
<awygle>
i think whitequark meant "as traces on a signal layer, or as a cut-out section of the power plane"
<awygle>
rather than "on top of" an additional signal layer
<whitequark>
yup
<whitequark>
wtf
<whitequark>
while I was laying out the board, one of the capacitors sold out at mouser
<awygle>
ugh hate when that happens
<awygle>
this cap shortage is for the birds
<awygle>
oh actually i didn't fuck up the micrel symbol/footprint as badly as i thought i did. there are actual reasons for everything, i didn't just.... fail.
<azonenberg>
some nand flash i never ended up using
<azonenberg>
awygle: that was around the time i started using 0.x version numbering for prototypes
<azonenberg>
from then on, 1.0 is the first release i consider ready for general consumption
<azonenberg>
i.e. by someone not getting handholding from me
<azonenberg>
0.1 is the first fabbed design
<whitequark>
awygle: this reminds me
<whitequark>
should we add polyfuses and testpoints
<azonenberg>
whitequark: test points are never a bad thing
<azonenberg>
and overcurrent protection of some sort
<awygle>
testpoints are a good, and we have lots of room
<whitequark>
i feel like testpoints are kinda pointless on this design because you can route out any signals you want on the external headers
<whitequark>
and, importantly, that doesn't require soldering to the board
<azonenberg>
my rule is to use polyfuses or active overcurrent protection for things that i expect may pull excessive current during normal, but incorrect, operation
<azonenberg>
and smt soldered fuses for things that should never, barring a pcb malfunction/design bug, blow
<whitequark>
azonenberg: "normal, but incorrect"
<awygle>
whitequark: buy that huge bag of pogo pins, no soldering required :p
<azonenberg>
So for example, power suppleid to an external device may short due to no fault of your own
<azonenberg>
you dont want to blow a fuse if that happens
<azonenberg>
But if your fpga vcore rail pulls too much power the S has HTF
<azonenberg>
amd ot
<azonenberg>
oops
<azonenberg>
and it's perfectly ok to require rework to reuse the board
<azonenberg>
because odds are something else is wrong too :p
<whitequark>
hmm
<whitequark>
so glasgow doesn't need a polyfuse, i think, since the current drawn by the target is limited by the Vtg LDOs
<azonenberg>
Often i dont have protection on individual rails
<whitequark>
at 100mA or so
<azonenberg>
And i just have something on the input rail before regulators
<azonenberg>
If you have active limiting, great
<azonenberg>
Figure out how much current the whole board should draw worst case with all limiting active
<azonenberg>
then put a single 0402 fuse on the input rail sized for decently more than that
<azonenberg>
say 500 mA?
* whitequark
whispers "0603"
<azonenberg>
fiiine
<azonenberg>
but my point is, i use soldered-in fuses for last ditch protection against "the board needs rework anyway" level malfunctions
<azonenberg>
i.e. there should never be a way to make that fuse blow from external interfaces only
<azonenberg>
internal component failure, solder short, etc should be the only things that can trip it
<whitequark>
afaict even if I force contention on every possible bus the device has it still won't exceed 500mA input
<azonenberg>
yeah
<azonenberg>
So if you ever do hit 500 mA something is really wrong
<azonenberg>
like a dead short from power to ground
<whitequark>
i guess just guarding against solder shorts
<azonenberg>
basically, that fuse is there to keep the board from going up in flames if all else fails
<cr1901_modern>
floorplan level? Well at least your checklist can accomodate interleaving
<azonenberg>
yeah i see 0402 sized fuses at 500 mA down to 27 cents
<awygle>
whitequark: lgtm!
<azonenberg>
on digikey
<azonenberg>
in qty 1
<whitequark>
azonenberg: now, where do I put the fuse exactly
<azonenberg>
cr1901_modern: basically, i just sketch out on paper where major connectors and chips will be
<azonenberg>
then figure out what banks go where
<whitequark>
between Vusb and 5V plane?
<whitequark>
between 5V plane and Vreg?
<azonenberg>
whitequark: i'd put it immediately after the power connector before it touches anything else
<azonenberg>
Since your goal is to protect against the greatest possible number of faults
<azonenberg>
Safety systems should be designed to be as simple and broad as possible
<azonenberg>
an actual melting-wire fuse is about as simple as it gets, and putting it as far upstream as possible maximizes coverage
<cr1901_modern>
azonenberg: Why on paper? Why not (assuming the footprints exist) fire up pcbnew and just draw the basic layout without connections there?
<azonenberg>
cr1901_modern: Because more often than not, the footprints don't exist yet :p
<azonenberg>
And i dont even start making them until the sch has hit first-pass completion
<azonenberg>
There's often some iteration
<azonenberg>
but i dont start layout until my first attempt of the schematic has passed review because there's often major changes during that phase
<cr1901_modern>
Seems like tedious (nevermind duplicated) work to draw to-scale layout on paper
<azonenberg>
once i start layout changes are usually small, like adding a test point or indicator LED or swapping fpga pins
<awygle>
yeah that's a good plan, you often realize pretty late in the game you really need the two-output DAC
<azonenberg>
lol you're reading way too much into it
<cr1901_modern>
Not judging you/saying you're wrong :P
<azonenberg>
i dont do a scale drawing
<azonenberg>
this is more like a toddler's sketch
<azonenberg>
"ethernet over there"
<azonenberg>
"power in there"
<azonenberg>
"fpga somewhere in the middle"
<awygle>
a sketch preserving relative orientations is sufficient for bank-level planning, typically
<azonenberg>
Yeah
<cr1901_modern>
ahhh okay.
<azonenberg>
Ok, transcievers have to go to the SFP connector
<azonenberg>
so that means pin 1 is to the top left
<awygle>
sometimes, if you're being clever, you might want to sketch actual circuits
<azonenberg>
then bank 30 goes to blah
<azonenberg>
etc
<awygle>
just to make sure you're not being an idiot (often more useful with analog, you can do the math on your drawing)
<azonenberg>
awygle: that happens during schematic capture
<azonenberg>
i often include calculaitons in descriptive text in the sch
<azonenberg>
But basically at this level of the floorplan design process i want to know what the major components are, what voltage they run at
<cr1901_modern>
awygle: Well I have a failed (currently anyway) project to do an ice40 board, and I discovered that my layout was insufficient while doing the schematic; I decided I needed a new part that wasn't there before.
<azonenberg>
how many pins they need
<awygle>
azonenberg: i do too, but i often start with a napkin to figure out if i'm clever or "clever"
<azonenberg>
And if there's any special requirements like transceivers or "must be on front panel because it talks to the outside world"
<azonenberg>
etc
<awygle>
azonenberg: also you barely do analog :p
<cr1901_modern>
That kinda put a dent in the original layout and actually kinda ballooned the board size b/c now I needed all 4 sides of the FPGA lol
<azonenberg>
:p
<azonenberg>
anyway, thats about all of the pcb that i do until sch has hit the signoff review milestone
<azonenberg>
Once the sch has passed review, then i make all of the footprints, do a more detailed rough placement in pcbnew that's actually to scale
<azonenberg>
just major ICs plus estimated space around each for passives and routing
<azonenberg>
Then i start routing
<azonenberg>
Typically at this point i have the pcb open on my main monitor and the sch on the side so i can easily go between them and swap pins etc
<awygle>
i usually do block diagram, major component selection, detailed block diagram, schematic, layout with some trips back to the schematic, then send the layout to the best PCB layout guy i know (kbaker) to get a second opinion
<azonenberg>
awygle: btw does kevin irc at all?
<awygle>
azonenberg: not afaik
<azonenberg>
he's missing out lol
<awygle>
lol yup
<azonenberg>
oh also... When making new footprints/symbols, I first create the design
<azonenberg>
then before i even close the editor, i go back and double check every dimension or pin name/number against the datasheet
<azonenberg>
then during the review, unless it's a part i've used on a board previously, i go back and do it again
<azonenberg>
This has saved my butt sooo many times its not even funny
<awygle>
i wish EDA tools didn't conflate "symbol" and "component". altium gets this right with their "component libraries" but almost no one else does (including altium's lower level products).
<azonenberg>
awygle: at least kicad doesnt attach footprints to sch symbols
<azonenberg>
like eagle
<awygle>
yeah i always go check footprints on ICs again before fab. typically layout takes long enough that my cache has been flushed and i can actually _see_ the footprints/symbols again.
<azonenberg>
for me, connectors dominate screwups
<azonenberg>
either pin numbering or pitch or something
<awygle>
connectors are ICs, change my mind :p
<azonenberg>
IC packages tend to be pretty regular
<azonenberg>
esp bgas
<azonenberg>
basically the only thing you can do wrong with a normal bga is have wrong pad size, wrong pin pitch, or REALLY screw up the numbering
<awygle>
yeah you're right, connectors are worse. but at least it's hard to screw up "edge mount SMA" and "100-mil header" which are what i mostly use
<azonenberg>
And kicad's new pin numbering tool largely eliminates that
<azonenberg>
tell that to my self from 5 years ago
<azonenberg>
i made the mistake of using kicad's library footprint for 0.1" headers
<azonenberg>
The drill pitch was too small for my header
<azonenberg>
drill diametr*
<awygle>
i once specifically picked a through-hole USB so that if i got the footprint wrong i could just put it on the other side of the board lol
<cr1901_modern>
YUP! Been there
<azonenberg>
so my pins didn't fit
<awygle>
yeah me too lol. everybody does that once.
<awygle>
60/40 for lyfe
<azonenberg>
awygle: i've also been using sac305 since i got my own hardware lab in 2010
<azonenberg>
So i'm used to it :p
<awygle>
azonenberg: i meant 60 mil pad 40 mil hole for the 100-mil headers :p 63/37 is the superior leaded solder
<azonenberg>
... oh
<azonenberg>
lol
<azonenberg>
when i hear 60/40 i think non-eutectic solder
<awygle>
i still don't like SAC305 btw. i'll get used to it eventually i suppose
<azonenberg>
i keep a bit of 63/37 around for reworking non-RoHS boards
<azonenberg>
But honestly? i almost never use it
<azonenberg>
i understand how SAC acts now
<azonenberg>
and snpb confuses me :p
<awygle>
i want to do a comparative x-ray imaging study of SAC305, 60/40 and 63/37
<awygle>
just cuz it'd be cool
<awygle>
okay, time for fetch and then bed
<awygle>
goodnight moon
<azonenberg>
the one difference i do notice is that, while slightly more viscous, sac has higher surface tension
<azonenberg>
and holds parts to the board better in 2-sided reflow
<whitequark>
azonenberg: how much starshipraider costs again?
<awygle>
whitequark: you could always set fine delay from the host to avoid that
<azonenberg>
whitequark: The full version, or the scaled down prototype?
<cr1901_modern>
(assuming I understand correctly)
<azonenberg>
and for the host board or with i/o cards?
<awygle>
you don't have to do full delay calibration/tuning. But the two banks thing is a deal breaker.
<whitequark>
full version host board plus a few i/o cards
<azonenberg>
whitequark: well it doesnt exist yet so i can only give estimates
<whitequark>
maybe one or two
<whitequark>
sure
<azonenberg>
and the minimum load is four digital i/o cards
<azonenberg>
if you want to make it fully usable
<azonenberg>
i mean you can always only load half and have only 16 channels instead of 32
<whitequark>
let's go with four
<azonenberg>
So, the base board for the single-io-card scaled down prototype was $213.95 BOM plus $40 for the PCB (oshpark qty 3 price, $117 per 3 bare boards)
<azonenberg>
That includes an xc7a100t as the FPGA, until i finish firmware i won't know if that's overkill or not
<azonenberg>
(The FPGA is over half the bom cost there)
<azonenberg>
The full version will tentatively have a kintex7 since i wanted to do 10GbE
<azonenberg>
Assuming the 7k70t that's going to be the same ballpark price as the artix, maybe a bit more so say $250 so far, then i think the DDR3 is about the same price as the hyperram but a lot bigger capacity
<azonenberg>
Probably no more than $300 BOM for the host but the PCB will be ~6 layers and cost a lot more in low volume
<azonenberg>
maybe $350 worst case since q-strip's are not cheap
<azonenberg>
As far as i/o cards, let' see
<whitequark>
$350 per PCB?
<azonenberg>
no, $350 BOM in qty 1
<whitequark>
ah
<azonenberg>
Plus PCB
<azonenberg>
Dimensions unknown, the big bga drives the stackup to 6-8 layers with a goal of 6
<azonenberg>
The io cards will be targeting oshpark 4 layer process
<azonenberg>
So, the 8-bit digital io card will have four 2-channel high speed comparators, estimating about $10 a pop so $40 so far
<cr1901_modern>
whitequark/awygle: I'm not seeing how you can get away sampling a 50MHz signal at 50Mbps (or 200Mbps with "oversample and discard") at get a usable real-time signal dump in return.
<azonenberg>
Two level shifters per lane for 1.2-3.3 and 3.3-5V ranges, assuming i buy in digikey qty 100 is about 40 cents each is another $6.40
<whitequark>
Msps*
<whitequark>
cr1901_modern: well consider it like this
<cr1901_modern>
yes, sorry
<whitequark>
if the SPI master is driving the bus at 50 MHz
<whitequark>
the slave is sampling it at 50 MHz
<whitequark>
so I can do that too and get all the data
diadatp has quit [Ping timeout: 260 seconds]
<azonenberg>
whitequark: then a variable LDO for VCCO, a DAC for Vt, an ADC for optionally tracking an external Vref
<azonenberg>
some mosfets and passives
<azonenberg>
and the PCB
<whitequark>
but I'll need to do it at two clock edges simultaneously
<azonenberg>
You should be looking at less than $100 per io card
<whitequark>
so ~$1k total?
<azonenberg>
Under 1K for an assembled system with four io cards is my goal
<azonenberg>
But the specs have changed over time, for the better
<azonenberg>
my new io card design is slightly cheaper, smaller pcb area, and better bandwidth than the old one (in theory)
<azonenberg>
but has yet to be hardware proven
<azonenberg>
I still have a lot of work to do, like for example designing a mechanical standard for io cards so i can attach them to the host board without them colliding with the adjacent one
<azonenberg>
i've defined the connector and pinout but have to think about how big i want to let them be
<cr1901_modern>
Okay, starting to make sense
<cr1901_modern>
But SPI samples during one clock edge for both components and shifts during the other.
<cr1901_modern>
>but I'll need to do it at two clock edges simultaneously
<cr1901_modern>
for both master/slave*
<whitequark>
if you're trying to output data as for an LA you need to return two samples for each actual sample
<cr1901_modern>
So you don't _need_ both edges, just the one which is being used to sample?
<whitequark>
is what I mean
<cr1901_modern>
And you're doing it at 4x's
<cr1901_modern>
(for extra insurance I imagine)
<whitequark>
no, just to make sure I have setup/hold margin
<azonenberg>
whitequark: Then the FPGA i'm using will have probably four GTXes
<azonenberg>
I'll be using one for 10GbE
<azonenberg>
(in addition to a RGMII or SGMII PHY for 1000baseT)
<whitequark>
since I cannot actually like, have that many clock domains
<whitequark>
well I mean I can but it seems like a recipe for pain
<azonenberg>
The other three will tentatively be brought out to an expansion header
<azonenberg>
But i have yet to define the pinout, functionality, etc
<azonenberg>
The other option is to bring out all four GTXes to a QSFP+
<azonenberg>
And give you 40GbE to the host system, or four lanes of 10GbE to different hosts, or one lane to the host and three to other instrumentation, etc
<azonenberg>
Yet another option is to put all four GTXes on an expansion header and require use of an addon card if you wanted 10GbE
bitd has joined ##openfpga
<azonenberg>
whitequark: oh, the other thing is that starshipraider's modular io design, while it increases the cost a bit
<azonenberg>
also lets you swap things out for other than single ended digital GPIO
<azonenberg>
you can do LVDS, or CAN, or ADC/DAC
<azonenberg>
etc
<azonenberg>
CAN in particular is one i expect to use at work moderately often
<cr1901_modern>
whitequark: So by sampling at 200MHz you essentially sample on the edges of your logic analyzer clock when the 50MHz clock is _not_ transitioning (either posedge/negedge)?
<awygle>
whitequark: sync pin is a great idea
<whitequark>
awygle: yep gonna add that
<whitequark>
still unsure about routing i2c to fpga
<whitequark>
it might be useful for e.g. FT232 compatibility mode?
<whitequark>
switching between MPSSE and UART mode
<whitequark>
good thing that I only have open-drain pins left and all I have is also open-drain tasks
<awygle>
I have no idea what I'd use it for honestly
<awygle>
I just like connecting things to things
<whitequark>
lol
<awygle>
arright actual sleep now
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
diadatp has joined ##openfpga
genii has quit [Remote host closed the connection]
diadatp has quit [Ping timeout: 240 seconds]
diadatp has joined ##openfpga
diadatp has quit [Ping timeout: 260 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
DrLuke has quit [Remote host closed the connection]
DrLuke has joined ##openfpga
diadatp has joined ##openfpga
Zorix has quit [Ping timeout: 276 seconds]
diadatp has quit [Ping timeout: 240 seconds]
diadatp has joined ##openfpga
Zorix has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
GenTooMan has joined ##openfpga
diadatp has quit [Ping timeout: 256 seconds]
pie__ has joined ##openfpga
rohitksingh has joined ##openfpga
X-Scale has joined ##openfpga
Bike has quit [Quit: Lost terminal]
diadatp has joined ##openfpga
eduardo has joined ##openfpga
<whitequark>
rqou: why the f does broadcom make outdoor sign LEDs
<marcan>
whitequark: btw, Glasgow is pretty much a scaled down version of something I've been designing in my head
<marcan>
that is to say, I'm interested, and may wind up stealing some ideas :)
<whitequark>
marcan: so do you want a board or
<daveshah>
AFAIK Avago bought Broadcom, but rebranded everything including their opto stuff to Broadcom
<marcan>
I do :)
<whitequark>
one?
<marcan>
yeah, I think one should be fine assuming I don't destroy it somehow
<whitequark>
it's supposed to be hard to destroy
<marcan>
yeah, I like that
<marcan>
16 pins is barely enough to PoC some of the things I want to try, but I've had tons of uses for something with low pin count over the years (e.g. all the twlfpga abuse)
<marcan>
I'm interested in how well those level shifters work, and I can find out with one
<whitequark>
marcan: you could get two and sync them!
<marcan>
I could, though that would be... somewhat inconvenient :P
<marcan>
for anything active anyway
<marcan>
passive sniffing, sure
<whitequark>
I do wonder how much can I paper it over in software
<whitequark>
it's one of those things that is harder than it seems
<marcan>
the problem is triggering. if you can get the clocks synced then plain old sniffing is not a problem
<marcan>
but anything smarter complicates things
<whitequark>
the SYNC pin is supposed to be a bidirectional trigger pin
<whitequark>
the first device that triggers, also triggers all the others
<marcan>
yeah, the issue is if you need conditions that span across multiple units :)
<marcan>
same basic idea with a lot more I/O (sometimes broken out with extraneous use cases that we never used; should've just been numbered pin headers)
<marcan>
and no level shifters
<marcan>
(but it does have configurable bank voltage)
<marcan>
oh, do you have any LEDs? because you want LEDs :P
<whitequark>
not currently
<whitequark>
I was actually looking at LEDs right now
<whitequark>
the FPGA doesn't have any free pins for LEDs, the Cypress chip has some
<marcan>
hm, pushing the FPGA quite a bit, eh
<marcan>
that's kind of unfortunate
<marcan>
how are you doing FPGA configuration?
<whitequark>
the Cypress chip configures it via slave SPI
<whitequark>
it then reuses those pins for communication
<marcan>
one of the neat things about the twlfpga is we could use the FTDI in bitbang mode to blast the config via an 8-bit parallel bus, took less than a second (no configuration memory, it was always loaded via usb)
<whitequark>
it takes 0.8s currently
<marcan>
sounds good
<whitequark>
there is configuration memory in case you want it to emulate something on powerup
<whitequark>
like a bus blaster
<marcan>
ah, that's what U2 and U3 are
<whitequark>
U2 also stores USB VID/PID and board revision/serial
<whitequark>
U3 can be DNP on a hypothetical low-cost model
<marcan>
so U2 is a config EEPROM and U3 is more like flash?
<whitequark>
they're both I2C EEPROMs and they hold code and bitstream respectively
<marcan>
gotcha
<whitequark>
but U2 also holds some configuration data
<marcan>
sounds like it'll be useful for a lot of stuff
<whitequark>
marcan: yeah this is like only a little bit higher end than what i'm building
<whitequark>
i wonder if we could even reuse software?
<marcan>
quite possibly
<marcan>
what are you planning for the firmware/HDL/host software?
<whitequark>
HDL: migen, ship the entire Yosys toolchain to be able to build bitstreams on the fly
<whitequark>
lil bit heavy but for a very versatile debug tool? I'll take it
<whitequark>
firmware: boring old cypress stuff written in sdcc
<whitequark>
compiled with*
<whitequark>
its only responsibility after initial bringup is basically to poke all the shit on the I2C bus
<marcan>
migen was my plan too
<whitequark>
so, FPGA (not enough pins... there is only one GPIO and it is multiplexed with a FIFO flag)
<whitequark>
FPGA sits on I2C too and exposes user-writable registers for slow out-of-band configuration in case you don't want to stuff it all in-band into USB bulk pipes
<whitequark>
then, ADCs and DACs
<marcan>
ah, that's different from what we did for OV3 (which is what I was going to base the USB bit on)
<marcan>
that one has a framing protocol for config/data over the single pipe
<whitequark>
sure, you *can* do that
<whitequark>
doesn't mean you *have* to
<marcan>
of course
<marcan>
having out of band I2C sounds like a handy option
<whitequark>
for example, if I'm emulating FTDI, I need to communicate selection of alternate interface modes to the FPGA
<marcan>
ah, yeah, if you're emulating higher level stuff you kind of want that
<whitequark>
the FPGA even has an I2C hard IP... which is totally useless because it's written to be put on wishbone
<marcan>
the framing is easy when the host side deals with it all
<whitequark>
probably will be less slices to implement I2C than to interact with that thing
<whitequark>
so, DACs are just stupid DACs that drive an LDO
<daveshah>
whitequark: yep definitely from my experience
<daveshah>
also easier to write an i2c core than get the Lattice one working for a given application
<daveshah>
even moreso for spi
<whitequark>
lol
<whitequark>
why even *have* an spi core
<whitequark>
it's spi goddamnit
<whitequark>
what a waste of silicon
<whitequark>
ADCs have alert capability and are routed to an interrupt-capable pin on the Cypress chip
<daveshah>
it's not even that fast, 45MHz max
<daveshah>
I think a SPI core in fabric could go a bit faster than that...
<marcan>
what does an SPI core even *do*
<marcan>
I mean if you have a CPU, sure, you can implement the register side interface
<marcan>
but in an FPGA? what?
<daveshah>
it's obviously intended for a cpu
<daveshah>
there's no other way you could use it - the state machine to control it would be bigger than the i2c/spi state machine
<marcan>
exactly
<whitequark>
so, as soon as ADCs go into alert, the Cypress chip kills the IO buffer OE and tristates the LDO
<whitequark>
actually, I think I can even hardwire ADC alert to LDO disable
<marcan>
ADCs for the current sense?
<whitequark>
nope
<whitequark>
Vtarget sense
<marcan>
ah
<marcan>
yeah, that makes sense
<whitequark>
the current is limited by design by the LDO
<marcan>
though you always want to have an override for this stuff, because sometimes you *do* want to shoot yourself in the foot
<whitequark>
the alert functionality is controllable in software
<marcan>
cool
<whitequark>
the ADC can continuously sample by itself
<whitequark>
so I don't really care about having the FPGA do it
<whitequark>
which is convenient
<marcan>
yeah, anything that makes the FPGA design simpler is a good idea
<marcan>
less crap to worry about
<marcan>
my udeaplan is to have a scaffolding
<marcan>
EEARLYRETURN
<marcan>
my idea was to have a scaffolding to make it trivial to write little blocks of functionality for a given project
<whitequark>
yep same here
<whitequark>
you'd have a template for having one bidirectional USB pipe and doing whatever you want with all 16 pins
<whitequark>
or, having two bidirectional pipes, and being able to set one such module to serve the A port and another for B port
<marcan>
yeah, or several framed together with a register interface and such for more complex projects
<whitequark>
yep
<whitequark>
similarly, the idea is to have something like CSR system in migen that automatically exposes registers via I2C
<whitequark>
then on the host side, it would use the same numbering to let you issue control requests using register names
<openfpga-github>
Glasgow-JTAG/master 922e576 whitequark: Voltage translator has a ~OE pin, not OE, oops.
<awygle>
Morning!
<marcan>
since you're further ahead than I am how does this sound. I'm going to mess with some preliminary stuff and use my OV3 as a PoC platform for the SDRAM side of things, since that really needs testing for viability before I commit to a design
<whitequark>
awygle: hi
<marcan>
and probably by the time I know what I want to do you'll have hardware and I can base it off of that :)
<whitequark>
sure that seems fin
<whitequark>
*fine
<whitequark>
SDRAM in my case is an explicit non-goal, it would hugely increase complexity of the design
<marcan>
oh I agree
<marcan>
it makes no sense on something that small
<marcan>
and with trivial compression and the RAM inside the ice40 you should be able to do realtime streaming of all but the most pathological inputs
<whitequark>
it's almost not necessary
<whitequark>
i can do realtime streaming of 7 channels period
<marcan>
at 50MHz?
<whitequark>
yes
<marcan>
that sounds just about what I got on the FTDI
<whitequark>
it's basically limited by USB at this point
<marcan>
42MB/s was the highest I've gotten out of it IIRC, with an xHCI host controller (which is slightly more efficient than EHCI)
<whitequark>
the Cypress<>FPGA interface is 384 Mbps
<whitequark>
but Cypress could only get around 360 Mbps out of it
<whitequark>
or at least they say so in their appnote
<marcan>
yeah, that's the ballpark
<marcan>
of the FTDI
<whitequark>
and I'm probably not going to beat Cypress using their own chip lol
<marcan>
the FTDI actually has a 480mbps interface but that's overkill obviously
<whitequark>
the Cypress also has one.
<whitequark>
well, a 768 Mbps one, actually
<whitequark>
16-bit bus
<marcan>
ah
<whitequark>
but the FPGA doesn't have enough pins.
<marcan>
nah, FTDI just runs the 8-bit bus at 60MHz
<whitequark>
but it doesn't really make any sense because of USB protocol overhead.