kuldeep has quit [Read error: Connection reset by peer]
futarisIRCcloud has joined ##openfpga
Miyu has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
lovepon has quit [Ping timeout: 252 seconds]
balrog has quit [Quit: Bye]
balrog has joined ##openfpga
emily has joined ##openfpga
<sorear>
o/
<Bob_Dole>
I'm surprised emily wasn't already familiar with this channel
<sorear>
no, she came from the other channel that wq's cannibalized
<sorear>
the prjtrellis need a lot more documents to explain exactly how they're supposed to be interpreted, but I'm not sure what that would look like
unixb0y has quit [Ping timeout: 246 seconds]
<sorear>
if nextpnr didn't exist, I couldn't write it from just the information on symbiflow.github.io
<rqou>
i believe you can
<rqou>
you probably have to have personally gone through the RE process for an (arbitrary) FPGA first though
unixb0y has joined ##openfpga
<sorear>
mmh
<cyrozap>
implr: I know they make silicon--my confusion mostly stems from the fact that this card isn't listed on their website at all, so I can't know for sure what chip it uses or who makes it until I buy one and take off the heatsink.
Patater has quit [Remote host closed the connection]
WilhelmVonWeiner has quit [Ping timeout: 245 seconds]
Patater has joined ##openfpga
WilhelmVonWeiner has joined ##openfpga
WilhelmVonWeiner is now known as Guest14767
<cr1901_modern>
>the other channel that wq's cannibalized
<cr1901_modern>
What _other_ channel? ##edef?
drawkula has quit [Ping timeout: 240 seconds]
<sorear>
yes
jn__ has quit [Ping timeout: 240 seconds]
jn__ has joined ##openfpga
lovepon has joined ##openfpga
drawkula has joined ##openfpga
rohitksingh_work has joined ##openfpga
azonenberg_work has joined ##openfpga
soylentyellow has joined ##openfpga
ZipCPU has quit [Ping timeout: 264 seconds]
_whitelogger has joined ##openfpga
flaviusb has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
emily has quit [Ping timeout: 252 seconds]
indy has quit [Read error: Connection reset by peer]
indy has joined ##openfpga
wbraun has joined ##openfpga
m4ssi has joined ##openfpga
wbraun has quit [Ping timeout: 246 seconds]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 240 seconds]
lovepon has quit [Ping timeout: 264 seconds]
<Bob_Dole>
At This Point In Time, specifically, is there a reason to go ice40hx8k over the 12k ecp5?
<SolraBizna>
principle!
<SolraBizna>
Bob_Dole tricked me into implementing an RV32I, and I refuse to let him trick me into doing it on an ECP5
<Bob_Dole>
I did NO such thing
<Bob_Dole>
I hoped to get you to implement a currently existing one tweaked to a custom board.
<sorear>
Bob_Dole: likely lower power; working timing analysis
<sensille>
isn't the exp5 cheaper per gate?
<sorear>
sensille: the 12F is cheaper in absolute terms than the hx8k
<Bob_Dole>
HX8k and ECP5's 12k variant are about the same price
<SolraBizna>
The working timing analysis is a big deal for me
<sensille>
also with ecp5 you have room for exansion, a whole family ahead of you
<Bob_Dole>
from the tweet about timing, I think that might be a thing that won't be a problem for long.. but is an issue affecting Now.
<SolraBizna>
I was well on my way to fitting a dual-core 1IPC RV32I into that iCE40, but after I added the CSR* instructions I passed the halfway point for PLBs used with just one core (acronym soup much?)
<SolraBizna>
(The counter logic bloated the core by 50%... I think I'm doing something wrong, or at least sub-optimal)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sensille>
it's nice to have a path for expansion
<azonenberg_work>
sensille: any idea where the 7 series work is? is that on hold now with ecp5 as the short term focus?
GuzTech has joined ##openfpga
<SolraBizna>
This is the illogical conclusion to a whole smegload of expansion I've already done
<SolraBizna>
All I wanted was parity logic and an address decoder for an SBC
<sorear>
there is definitely _some_ work being done on prjxray, but dependabot generates a tremendous amount of noise
<azonenberg_work>
sorear: i meant more P&R
<azonenberg_work>
it would be awesome to have P&R support even just for basic lut fabric and slow io
<azonenberg_work>
what's left to do for nextpnr to support it, plus bitstream generation on the back end?
<Bob_Dole>
SolraBizna, the thing is, when dropping the hard-cores, you've gone to a component reduction, simplifying hardware.
<azonenberg_work>
i.e. for the subset of the bitstream that is already known
<SolraBizna>
yeah, but now we have... *gasp*... BGAs on the board
<Bob_Dole>
we already had bgas on the board
<azonenberg_work>
so spoopy
<Bob_Dole>
also ecp5 will allow spi mram config memory, won't it?
<Bob_Dole>
instead of fram or flash
<SolraBizna>
We only started having BGAs because there wasn't a realistic alternative for an FPGA that had enough pins to watch the whole memory bus
<azonenberg_work>
SolraBizna: and?
<azonenberg_work>
bga is so much better than qfp
<azonenberg_work>
more space to fan out, higher assembly yield since the pins are further apart
<sorear>
ECP5 and ECP5-5G sysCONFIG Usage Guide has the details on what the SPI master expects
<Bob_Dole>
QFP is only good for drag soldering but I plan to oven it one way or another
<Bob_Dole>
bgas self align if you get it close enough and that's neat
<azonenberg_work>
qfp is awful
<azonenberg_work>
i've lost count of how many qfp's i've had to rework due to bridging during reflow
<azonenberg_work>
you know how many bgas i've had short? zero
<azonenberg_work>
ever
<rvense>
qfps are like... two minutes in the oven, then an hour of HATE
<azonenberg_work>
Lol exactly
<azonenberg_work>
i've had a small number, maybe two, bgas cold-solder due to insufficient heating (my oven doesnt quite get up to optimal profile temp for sac305)
<azonenberg_work>
trivially fixed by squirting flux under and reflowing a second profile a bit longer
<azonenberg_work>
didnt have to pull the chip or anything
<azonenberg_work>
and i had one 2x2 ball 0.35mm tombstone due to a bad paste print
<azonenberg_work>
tiny dab of flux, hot air, nudge with tweezers, and it was all set
<SolraBizna>
so a prototype-fab PCB and an improvised toaster-oven reflow oven will handle BGAs better than QFPs?
<azonenberg_work>
SolraBizna: yes, that's been my experience
<azonenberg_work>
qfps are super sensitive to misalignment and a tiny bit of excess solder will bridge them easily
<azonenberg_work>
excess solder in a bga just makes the ball bigger, it takes a LOT to make them short
<azonenberg_work>
and they self-align much better because of the higher pin area to mass ratio
<azonenberg_work>
a qfp144 barely self-aligns at all
<Bob_Dole>
I wanted QFPs before I comitted to oven because I COULD drag solder and solder-braid clean QFPs.. I wanted BGA the moment I decided I was going to mod a toaster oven.
<Bob_Dole>
because the self-alignment thing, super handy.
<azonenberg_work>
Yeah IMO there is only one reason to use a qfp, and that's an extremely cost sensitive application limited to 2 pcb layers
<azonenberg_work>
and even then, the area savings of a bga may make up for it
<azonenberg_work>
if you go 4L
<SolraBizna>
well, we were also originally limited to 2 PCB layers because I wanted to pretend I could (in theory) manufacture the PCB myself
<SolraBizna>
I have been dragged kicking and screaming into the 21st century all throughout this thing
<sensille>
:)
<rvense>
a qfp on a self-soldered pcb? without solder mask?
<azonenberg_work>
SolraBizna: lol
<azonenberg_work>
rvense: i
<azonenberg_work>
rvense: i've done 0.5mm tqfp on home etched pcbs
<azonenberg_work>
it's not fun, and it bridges up the wazoo, but it caaaan be done
<azonenberg_work>
vias were the main thing that made me give up on doing home pcb fab
<Bob_Dole>
I have experience with silk-screen stuff, though in the context of t-shirts
<azonenberg_work>
also it was way too labor intensive in general
<Bob_Dole>
I was thinking about vias because it seems like it should be possible to do vias with small pins..
<rvense>
azonenberg_work: yeah i'm going to get a new hobby after just thinking about that
<azonenberg_work>
easier to pay a few bucks, send the design out, and get it back a few weeks later
<sorear>
what, you don't have a numerical control drill in your garage
<azonenberg_work>
Bob_Dole: i've done vias on home pcbs, i've aligned multiple layers
<azonenberg_work>
the point is, most of the time there are better uses for my time
<azonenberg_work>
:p
<Bob_Dole>
they'd just be thick and not have great inductance control I'd think
<Bob_Dole>
my time is (presently) free :D
<azonenberg_work>
yeah see i have a job, side job, and spend the rest of my time working on the house
<azonenberg_work>
so my time is... not free
<azonenberg_work>
i value my time somewhere north of $100/hr when calculating if it makes sense to contract out work
<azonenberg_work>
although obviously if i particularly enjoy the work, i might do it myself even if it doesn't make strict financial sense to
<Bob_Dole>
because of Keeping My Medicaid, I can't earn much and normal work is risky, in that I have risk of getting infection, so my income is hard-limited, so I'd have more money by spending time instead of money, in general.
<Bob_Dole>
I was getting hopeful, and then trump got elected.
<Bob_Dole>
so my situation is a little odd
<azonenberg_work>
Yeah, the equivalence is always different from person to person and situation to situation
<sorear>
less so among the set of people who spend 24/7 posting on twitter and irc
<SolraBizna>
hey, I take breaks to sleep ;)
<Bob_Dole>
you only post on irc
<Bob_Dole>
not twitter and irc!
<sorear>
twitter and/or irc
<Bob_Dole>
SolraBizna doesn't have twitter so I've had to tweet at people to do what I came here to do on there.
<Bob_Dole>
hardly anyone I'd need to tweet at isn't here though. >.>
zino has quit [Ping timeout: 245 seconds]
<sorear>
suddenly occurs to me that the ecp5 I/O "programmable delay" could be quite relevant for SSO mitigation
<azonenberg_work>
sorear: interesting idea, basically adding a random phase delay to outputs to reduce peak switching current?
jhol has quit [Read error: Connection reset by peer]
<azonenberg_work>
it would work, as long as you didn't mind the associated eye shrinkage
zino has joined ##openfpga
<sorear>
well the idea is that I add the *same* delay on the transmitter and the receiver, so the eye only shrinks by the process variation in the delay cell, not by the absolute value of it
<daveshah>
That of course only works if you control the receiver
<azonenberg_work>
For chip to chip, that would work perfectly
<azonenberg_work>
or if the receiver has programmable skew
<daveshah>
But this is the kind of feature that the nextpnr Python API was designed for
<azonenberg_work>
Just not for talking to a device yo udont control
jhol has joined ##openfpga
<daveshah>
ad 7 series support in nextpnr. I think one of the main issues is the database structure
<daveshah>
You don't want a flattened db format for something like the Virtex parts
<daveshah>
This is something I think we'd like to get right early on. Even the location based deduplication used for the ecp5 isn't ideal for such a large variety of parts
<sorear>
has anyone tried deleting every file in a Vivado install not needed for synthesis+pnr+timing analysis and measuring the resulting size
<daveshah>
Clifford has quite a few ideas about basing the database structure on the 7 series tile structure, with the wire alias feature in nextpnr for fixed interconnect
<daveshah>
Maybe we will see something next year
<daveshah>
The other issue with 7 series support is packing, and the unit used for placement
<Flux42>
Nice to see discussion of 7 series.
<daveshah>
I don't have any time to work on it before next July, my focus is on my university masters project which is improving timing constraints and timing in general in nextpnr; and along with that getting the ECP5 support to a point it can do stuff like DDR3 interfaces
<sorear>
that specifically seems to have been worked on quite recently
<daveshah>
I don't know how much if any work others will put into 7 series in the mean time. But the ECP5 and 7 series have quite similar feature sets and challenges so hopefully the ecp5 work will clear the way a bit
<sorear>
I'm quite happy to see this being handled synergistically
jhol has quit [Read error: Connection reset by peer]
jhol has joined ##openfpga
<SolraBizna>
I should go to bed, but instead I'm just trying to find a better approach to implementing counter read/write
<SolraBizna>
I really feel like that feature should not have inflated my core by 50%
flaviusb has joined ##openfpga
<sensille>
so either you can try for 3 more hours or just go to sleep and wake up with the solution in mind
<SolraBizna>
hm... tough choice
pie_ has joined ##openfpga
ZipCPU has joined ##openfpga
futarisIRCcloud has joined ##openfpga
nickjohnson_ has quit [Ping timeout: 260 seconds]
nickjohnson_ has joined ##openfpga
jeandet has quit [Ping timeout: 260 seconds]
TD-Linux has quit [Ping timeout: 260 seconds]
specing_ has joined ##openfpga
dx- has joined ##openfpga
diamondman has quit [Ping timeout: 260 seconds]
florolf has quit [Ping timeout: 260 seconds]
specing has quit [Ping timeout: 260 seconds]
kmehall has quit [Ping timeout: 260 seconds]
dx has quit [Ping timeout: 260 seconds]
jeandet has joined ##openfpga
kmehall has joined ##openfpga
florolf has joined ##openfpga
specing_ is now known as specing
diamondman has joined ##openfpga
TD-Linux has joined ##openfpga
hackkitten has quit [Ping timeout: 264 seconds]
Guest14767 has quit [Quit: Reconnecting]
WilhelmVonWeiner has joined ##openfpga
WilhelmVonWeiner is now known as Guest93587
s_frit has quit [Remote host closed the connection]
Guest93587 has quit [Client Quit]
WilhelmV1nWeiner has joined ##openfpga
s_frit has joined ##openfpga
hackkitten has joined ##openfpga
WilhelmV1nWeiner has quit [Client Quit]
WilhelmV1nWeiner has joined ##openfpga
WilhelmV1nWeiner has left ##openfpga [##openfpga]
WilhelmVonWeiner has joined ##openfpga
lain__ has joined ##openfpga
lain has quit [Ping timeout: 252 seconds]
qualia has quit [Ping timeout: 250 seconds]
qualia has joined ##openfpga
lain__ is now known as lain
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
lain has quit [Ping timeout: 252 seconds]
lain has joined ##openfpga
Flux42 has quit [Quit: Patch.]
Flux42 has joined ##openfpga
Bike has quit [Disconnected by services]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
<openfpga-github>
libfx2/master 4cd7aac whitequark: Prefix bit definitions for EPIE, EPIRQ.
azonenberg_work has quit [Ping timeout: 240 seconds]
Miyu has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
wbraun has joined ##openfpga
<kc8apf>
daveshah: glad to see others recognizing that a flat database doesn't work for larger devices. Guess I was just a year too early in trying to push for a rethink.
<daveshah>
Yup
<daveshah>
It's a big argument against vpr imo
<daveshah>
Particularly as startup time is a nice feature of FOSS over vendor tools
<kc8apf>
fwiw, that's what led me to start gaffe. The main concept I want to demonstrate is a resource scheduler built on an object model.
m_w has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
* azonenberg_work
thinks about vivado taking minutes to compile "assign dout = din"
<daveshah>
People used to Vivado/Quartus are usually pretty shocked when they hear how fast the icestorm flow is
<daveshah>
I have measured 1.8 seconds from Verilog to *programmed FPGA CRAM*
<azonenberg_work>
daveshah: yeah
<azonenberg_work>
when i first started doing coolrunner stuff
<azonenberg_work>
i foolishly thought about REIng ISE
<azonenberg_work>
strace'd a build
<azonenberg_work>
it loaded and parsed over a megabyte of XML for *different chip famlies* as well as coolrunner stuff
<azonenberg_work>
before even calling open(2) on my netlist
<daveshah>
So not surprised
<azonenberg_work>
meanwhile vivado forks off a whole other vivado instance and jvm to do builds
<daveshah>
Ironically, Lattice Diamond is pretty quick (maybe 10 seconds minimum command line
<azonenberg_work>
i think this is probably so when a build segfaults it doesn't take out the gui
<daveshah>
because it is 1995-era technology
<awygle>
yeah diamond isn't bad honestly
<azonenberg_work>
I've still managed to crash the vivado gui :p
<awygle>
way better than icecube2
<daveshah>
yup, because it's older
<azonenberg_work>
my one attempt playing with VPI crashed xsim reliably
<daveshah>
not at all surprised
<azonenberg_work>
like the whole ui SIGSEGV'd
<daveshah>
Vivado would segfault on many Linux distributions with a newer libc unless you did some symlink magic for several years
<azonenberg_work>
Never had that problem
<awygle>
here's a dumb question - what *is* EDK
<azonenberg_work>
most likely because i run debian so "too new libraries" was never a problem :p
<azonenberg_work>
awygle: it's their microblaze/zynq system design tool i think
<azonenberg_work>
targeting software running on their parts
<awygle>
ah
<awygle>
it's infuriating
<daveshah>
EDK doesn't sound that useful
<daveshah>
Certainly when doing Zynq stuff previously I used buildroot with some custom scripts for the OS/software and tcl to build the gateware
<daveshah>
Pretty sure most of the stuff in EDK comes with the free Xilinx stuff anyway
<SolraBizna>
having an open-toolchains-only rule may restrict the parts I can use, but I'm *really* glad I'll never have to interact with the proprietary toolchains
<awygle>
i think edk is free for webpack parts?
<awygle>
hm daveshah is there like, an intermediate format from trellis i could import into diamond?
<daveshah>
no
<awygle>
or vice versa?
<daveshah>
ncl would be the best format
<daveshah>
that can be converted into an ncd that epic, if not diamond itself, can use
<awygle>
ah ok. i was thinking i might try building this huge ecp5 project and see how much of it works, but it uses SERDES so i know the answer isn't "all of it"
<daveshah>
SERDES support shouldn't actually be too hard in nextpnr
<daveshah>
the bitstream stuff for the SERDES is done already
<awygle>
lmao oh god it's so big, i forgot about this page
<daveshah>
there are a few prerequisites before SERDES support is really meaningful, like supporting the normal PLLs and also improving how nextpnr routes globals
<daveshah>
at the moment it isn't very good at picking the global entry DCC, so might pick a suboptimal one and add general routing onto the global, which is theoretically not good
<daveshah>
the algorithm for choosing the entry DCC should first check if any have dedicated routing from the source if it exists (e.g. for global input pins, PLL outputs, int oscillator, SERDES etc)
<awygle>
lol a nice description
<awygle>
i think this design uses every substantial ecp5 feature except the dsp's
<daveshah>
sounds like a good test in the future though!
<awygle>
yup :)
<daveshah>
interestingly, I believe Diamond will refuse to generate a bitstream if there is more than one tile's worth of general routing in a clock net
<daveshah>
I am not sure why, because I have successfully run an entire picorv32 reliably (albeit only tested at 25MHz, but that doesn't affect hold time slack anyway) without using any global routing at all during early trellis/nextpnr testing
<awygle>
huh, really? that's interesting, and might become relevant to me _night immediately_ lol
* awygle
checks schematic
<daveshah>
istr having pain with something like that a while ago with MachXO2
<daveshah>
not sure if I've actually tested it with ECP5, but I know I saw it in the ECP5 clocking document
<awygle>
hm i think i'm probably ok. it looks like the ECP5s have a _ton_ of clock routing, is that right?
<awygle>
like 14 clock nets? or maybe even 16?
<daveshah>
16 *per quadrant*
<awygle>
oh 16 _per quadrant_ even. yeah i'm fine lol
<daveshah>
with a full crossbar mux driving them
<daveshah>
btw the error does exist for ecp5, "ERROR - par: netcheck: Found more than 1 segment of general routing in clock path from "reg_1" to pin "CLK" in comp "SLICE_3"."
<daveshah>
not sure if there is a switch to override it
<awygle>
wonder if you can - yeah
<daveshah>
at post-par you can override anything - even shorts, antennae, etc
<awygle>
currently working on a Zynq design running 9 clocks entirely through fabric ^_^ fun times
<awygle>
(narrator: the times were not fun.)
<daveshah>
hehe
<daveshah>
I ran into horrible problems a while ago with two CSI-2 interfaces sharing a bank (IIRC) on a Virtex-6
<awygle>
last week's discovery was "if you try to use a LUT as a clock mux between two 100 MHz clocks, the resulting clock will have a ~20% duty cycle"
<daveshah>
One of them could use proper clocking, one of them couldn't
<daveshah>
The one that couldn't would glitch about every minute, and I never fixed that
<awygle>
compounded by the obvious implication that if you sample DDR with a 20% duty cycle clock things Do Not Work
<daveshah>
I can imagine...
lexano has quit [Ping timeout: 252 seconds]
lexano has joined ##openfpga
wbraun has quit [Quit: wbraun]
lexano_ has joined ##openfpga
wbraun has joined ##openfpga
lexano has quit [Ping timeout: 245 seconds]
mumptai has quit [Quit: Verlassend]
Bike has joined ##openfpga
<azonenberg_work>
awygle: why did you not use BUFG's?
<awygle>
azonenberg_work: because i didn't design this board
<awygle>
(na we ran out)
<azonenberg_work>
lol
<azonenberg_work>
i would have sent the dirty clock to a PLL/MMCM to clean it up
<awygle>
there's 9 independent dirty clocks
<awygle>
and they're not freerunning
<awygle>
and then there are 9 more clocks going the other way which are on BUFGs
<awygle>
which is why we ran out
<awygle>
since you can only have i think 12 unique global clocks per region
<SolraBizna>
"♪ Too many clocks... ♫"
<daveshah>
awygle: so ecp5 actually beats 7 series on that then with 16 per region!
<awygle>
daveshah: yup! also the ecp5 in this case is an endpoint not a hub so it'll only have like, four clocks total :p
<daveshah>
Much easier!
<awygle>
and also-also it's laid out so the clocks are on clock pins....
<SolraBizna>
heh
<daveshah>
Literally my only grudge with the ecp5 clocking arrangement is the lack of dynamic PLL configuration
<daveshah>
Everything else seems pretty nice
<awygle>
it's got plenty though so just swap between them as needed :p
<awygle>
that's what we do
<awygle>
we need to provide 1 of 4 different reference clocks and we just mux the outputs of one PLL, easy peasy
<daveshah>
It works, I suppose
<zkms>
:3
<daveshah>
But even the ice40 has some kind of dynamic PLL config
<daveshah>
There are some secret inputs to the PLL that are always tied low in the bitstream
<daveshah>
Maybe they do something "fun"
<awygle>
continuously vary the clock phase adjustment? :p
wbraun has quit [Quit: wbraun]
<awygle>
i... hope we're actually using the DCSC blocks to do this muxing...
<daveshah>
There are only two DCSCs I thinj
<daveshah>
*think
<awygle>
huh
<awygle>
well it seems to be working
<awygle>
but i should check how it's implemented
<awygle>
and scope the results to make sure
<reportingsjr>
anyone here have a fav flux for lead free solder?
<reportingsjr>
up in the air between kester 275 and kester 48 right now
<Bob_Dole>
I don't know Anything about formal verification, but SolraBizna is working on a risc-v core, so might be useful to him. Any resources for learning about that?
<awygle>
ZipCPU's blog
<awygle>
and ZipCPU generally, he seems very willing to help
<daveshah>
Beat me to it awygle!
<awygle>
i also know some things, and can answer some questions
<Bob_Dole>
what made me think about it is him saying <SolraBizna> assuming there are no bugs in my design so far, which is naturally a 100% safe assumption~
<ZipCPU>
Bob_Dole: Start small, start simple, work your way up to complex. Formally verifying a CPU is certainly possible, but not what I would recommend for a beginners first project.
<ZipCPU>
Anything in particular that you want to verify?
balrog has quit [Ping timeout: 252 seconds]
<Bob_Dole>
he's doing a design with 2 rv32 cores on an ice40
<ZipCPU>
Ok
<ZipCPU>
How about you?
<Bob_Dole>
I'm just soldering chips to the pcb. Logic is not within my repertoire of skills, presently.
balrog has joined ##openfpga
* ZipCPU
decides not to share that soldering is not within his repertoire of skills
<awygle>
soldering is a bummer, pcb design is great
<awygle>
i'm paying for assembly for the rest of my life thanks
<ZipCPU>
Never done it. Thought about it several times. Bought a book for it, but never tried it.
<Bob_Dole>
my background is fixing blown caps, fuses, voltage regulators, etc, mostly on guitar amps
<ZipCPU>
Wow. Let the smoke out and things stop working, huh?
<Bob_Dole>
and put a new Smoke Capsule and it starts working.
<Bob_Dole>
seems kinda like no one wants to get capacitor-plague afflicted caps replaced anymore.
<qu1j0t3>
:D
<qu1j0t3>
they don'tlast forever, plague or not
<Bob_Dole>
yeah, but the capacitor plague got a large volume of things needing fixed for a good while
<awygle>
any idea if you can get both a registered and a not-registered version of a signal from a Xilinx IOB?
<awygle>
ZipCPU: never tried PCB design, or never tried soldering?
<azonenberg_work>
awygle: i'm planning to set up a small smt line at my new lab
<azonenberg_work>
chinese pnp and nice stencil printer
<awygle>
yeah i thought about doing that
<azonenberg_work>
it will probably max out at 0402 passives and midsized ICs
<awygle>
but then i looked at prices
<awygle>
and at prices to get seeed to build shit for me
<awygle>
and was like
<awygle>
"nah"
<azonenberg_work>
but i have no problem with doing the smaller stuff mysel
<azonenberg_work>
myself*
<azonenberg_work>
awygle: well the turn time plus ability to debug, do last minute part swaps, etc is worth it for me
<awygle>
i mean i'll still have a rework station
<awygle>
and a soldering iron
<azonenberg_work>
If i get one, would you want to run designs on my line?
<awygle>
turn time is a valid argument
<awygle>
mmm maybe
<azonenberg_work>
i'd do it free or for a minimal charge to cover maintenance etc
<awygle>
i'd want to see the stencil thing
<awygle>
the hardest part for me is "put paste on board without smudging or overfilling"
<azonenberg_work>
the one i'm looking at was suggested by somebody in here, i think prp? it was meant to take un-framed (cost optimized) steel stencils
<awygle>
unless you're volunteering to do labor but i doubt i can afford you :p
<azonenberg_work>
you do have to pad them to a specific size
<azonenberg_work>
it looks likt its basically the same kind of thing as the "real" framed stencil printers i've used in the past
<azonenberg_work>
but with a clamp to hold a frameless stencil
<azonenberg_work>
Which costs way less to make/ship
<awygle>
sure
<SolraBizna>
I can do formal verification with my own tools; I exhaustively(!) tested a W65C02S simulator against a real part
<SolraBizna>
RISC-V is so simple, I expect most of my bugs to be the blatantly obvious kind
<awygle>
christ this is such a pain in the ass. azonenberg_work is there a picture somewhere that's like "HERE ARE THE LEGAL ROUTES INTO, INSIDE OF, AND OUT OF AN IO TILE" for 7-series?
<awygle>
i cannot find anything useful
<awygle>
even slightly
<azonenberg_work>
awygle: they generally do not document routing
<awygle>
but it fucking matters! i'm not talking about chip internals, i'm talking about what is legal verilog that works and what is legal verilog that doesn't!
<awygle>
okay. i have IOB-x->IDELAY-y->IDDR-z->. i want to use both Z and X, or both Z and Y. are either of those legal?
<digshadow>
awygle, azonenberg_work : ha funny conversation. I'm looking at this right onw
<digshadow>
now
<azonenberg_work>
digshadow: maybe you can help awygle then :p
<digshadow>
nah, I'm failing badly right now :P
<digshadow>
there is a WIP PR though to get some real info in the DB
<digshadow>
but its pretty minimal
<awygle>
that at least makes me feel slightly better lol
<azonenberg_work>
yeah there is no documentation
<digshadow>
what is an IOB18 vs IOB33?
<azonenberg_work>
like, mapping from bits in the bitstream to xilinx part names is useful but... knwoing what the bits DO is even better
<azonenberg_work>
digshadow: i think it's a HR io tile
<awygle>
digshadow: I/O standard. LVCMOS18 vs LVCMOS33
<azonenberg_work>
vs a HP
<digshadow>
ah gotcha, the voltage range
<azonenberg_work>
awygle: there's no iob25 etc
<awygle>
different buffers are used on-chip for those two standards, afaict
<azonenberg_work>
iob18 is 1.8v *max*
<digshadow>
right
<azonenberg_work>
iob33 is definitely HR
<azonenberg_work>
i dont know if iob18 is a separate low voltage buffer in a HR bank, or a HP buffer
<awygle>
neither do i
<digshadow>
anyway I was just trying to verify some info, I'm going back to bram for now
<digshadow>
although IOB will be soon
<awygle>
but i empirically am pretty sure that LVCMOS18 and LVCMOS33 are different physical buffers
<azonenberg_work>
awygle: oh i am almost certain of that
<azonenberg_work>
given the CFGBVS pin etc
<digshadow>
there is enough of 7 series bram documented though that you could write your own tool to rewrite bram content
<azonenberg_work>
awygle: have you tried writing a test bitstream and seeing if it builds?
<azonenberg_work>
thats generally the gold standard :p
<awygle>
azonenberg_work: waiting on it
<awygle>
takes forever
<awygle>
because it doesn't just... fail
<awygle>
wait this is infuriating
<awygle>
you can explicitly do this with the ISERDESE2
<awygle>
but apparently not with IDDR
<awygle>
but they're the same tile
<awygle>
why
<daveshah>
The ecp5 has three input buffers
<daveshah>
One powered by Vcc for 1.2V, one by Vccio for 1.5/1.8V and one by Vccaux for 2.5V/3.3V
<daveshah>
Plus differential as well
<awygle>
huh, that's surprising
<awygle>
i thought vccaux was just for termination voltage
<daveshah>
This means you can mix inputs on the same bank, particularly the top and bottom where the clamp can be turned off
<daveshah>
digshadow: very interested how IO for the 7series works out
<daveshah>
ECP5 IO is a mess, I'm still at the stage where the docs are just a table mapping IO type to config bits
<digshadow>
daveshah: the preliminary issue is that it may be hard to toy with them using verilog, but looks like its fairly clean with tcl
<daveshah>
I sort of ended up the other way round for the ecp5 IO
<daveshah>
Most things I fuzzed using the low level post PnR ncl interface, IO I fuzzed using verilog
<daveshah>
Because I just wanted a high level mapping for now
<daveshah>
The 7 series might be simpler because I believe it just has IO columns?
<daveshah>
The ecp5 has IO on all sides and is different for top, bottom, left and right
<TD-Linux>
are there any ecp5 packages that can be done with 6/6 rules
<azonenberg_work>
TD-Linux: 66/ is hard
<azonenberg_work>
5/5 oshpark rules you can do some, not all, 8.8mm bgas
<azonenberg_work>
0.8*
<digshadow>
daveshah: yeah its I/O columns. Possibly a limitation of their configuration architecture that would have made it difficult putting them at top and bottom
<digshadow>
there are several types at least though within theme
<azonenberg_work>
digshadow: not configuration, die layout
<azonenberg_work>
they have basically a premade gds block for each column
<azonenberg_work>
and then tile them in the final layout
<digshadow>
meh they are basically interchangable
<azonenberg_work>
anyway heading out, back in a bit
<digshadow>
they could have made a bunch of short addresses though for it, or could have cheated it into a row
<daveshah>
Obviously lattice cared at lot less with only three ECP5 dice