azonenberg_work has quit [Ping timeout: 260 seconds]
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
pie__ has joined ##openfpga
<kc8apf>
things I learned at Apple that I would I could forget: at least a few non-printable characters are legal filenames in HFS+
<sorear>
i'm more surprised some aren't
<digshadow>
kc8apf: that sounds like good trivia. Please tell me beep is one of them
<kc8apf>
I mostly fan afoul of carriage return. Hack from Classic days to prevent files from being shown in Finder.
<kc8apf>
sorear: never exhaustively tried them
<digshadow>
like juicy_picture.jpg\nvirus.exe?
<digshadow>
or were their legit uses for this
<sorear>
you are presumably already aware that ntfs allows everything except \\ and \0
<awygle>
on ext3 it's literally only / and \0
<awygle>
dang sniped.
<digshadow>
sorear: does it allow COM1
<sorear>
i feel like that's far more widely known about linux than it is about ntfs
<sorear>
digshadow: yes, as long as you use \\?\ paths
<awygle>
doesn't ntfs allow arbitrary utf-16 but disallow "nul"?
<sorear>
doesn't even have to be utf-16, unpaired surrogates are allowed
<kc8apf>
digshadow: there was a common case of hiding a resource file. I can't find a link to anything that talks about classic Mac OS special filenames though
<kc8apf>
more or less the equivalent of dot files on unix
<digshadow>
gotcha
<qu1j0t3>
the amusing thing there is that a hidden flag dates back as far as MFS but I guess it was never respected by FInder?
<kc8apf>
qu1j0t3: no, it is. this was just a different method that existed for some reason.
<sorear>
finder definitely respected hidden
<qu1j0t3>
hm.......
<qu1j0t3>
so why was the hack ever needed?
<sorear>
long long ago i did _something_ to patch a system7 system so that hidden would be ignored
<kc8apf>
heck if I know
<qu1j0t3>
sorear: i'm talking pre-system7
<kc8apf>
I just know I had a code base that still had these wacky filenames in them.
<kc8apf>
CVS was fine with it. SVN exploded wonderfully.
<qu1j0t3>
kc8apf: yeah i remember there were filename hacks
<q3k>
please test and file bugs, there'll be plenty
rohitksingh has quit [Quit: Leaving.]
ondrej2 has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
<gruetzkopf>
*builds for arm64*
<q3k>
should probably work
<gruetzkopf>
ppc64big and sparc64 and mips64 boxes are hard-off and not near me, sadly ;)
<gruetzkopf>
was your bga touch sensor already built with this? :D
<q3k>
no, that was a stock ulx3s example bitstream
<q3k>
the ECP5 I have there is an -85f, so I need to first generate an empty base bitstream for it anyway (ie. ask daveshah how to do that / where the docs are)
<daveshah>
q3k: empty bitstreams are now included in trellis/misc
<q3k>
oh, cool, didn't notice
stefanct has quit [Quit: quit]
<clifford>
gruetzkopf, when building for big-endian you need to call "bbasm" with --b to create a big endian device database. Otherwise it will probably just crash. (Warning: bbasm --b is currently untested because I don't have a big endian machine.)
<q3k>
i can test it on the sparc64 at hswaw
<q3k>
if it's plugged in :P
<clifford>
I would assume there is a good way to handle this in the cmake config, but currently we don't, so you'd need to patch the bbasm calls in family.cmake.
<daveshah>
I believe CMake even has a built in endianness test module
azonenberg_work has quit [Ping timeout: 248 seconds]
rohitksingh has quit [Quit: Leaving.]
<Prf_Jakob>
q3k: Just to be nitpicky, writing "Copyright (C)" is like writing "CD Disk" you are basically saying copyright copyright so the (C) is not needed.
<azonenberg_work>
mithro / q3k: question re nextpnr
<azonenberg_work>
Does the pip implementation assume that *all* connections are one-hot?
<daveshah>
azonenberg_work: what exactly do you mean?
<azonenberg_work>
is it possible to do dense coded muxes with it?
<daveshah>
Yes
<azonenberg_work>
i'm wondering about the plausibility of using nextpnr on a CPLD
<azonenberg_work>
say, by using libgreenpak4 + nextpnr and modeling the interconnect as pips
<daveshah>
You can even apply constraints in the architecture like this pip is unavailable if this other pip is used
<daveshah>
The Arch API is very generic
<azonenberg_work>
nice
<azonenberg_work>
I'm seriously thinking about how hard it would be to get coolrunner and greenpak support in nextpnr
<daveshah>
You could even say that a pip is unavailable if a bel is used - e.g. to use a LUT as route through with a "virtual pip" available if the lut isn't used
<azonenberg_work>
greenpak probably easier since it's still a lut based fabric
<daveshah>
Yeah
<daveshah>
Very happy to support that
<azonenberg_work>
after the move, that might be my next priority
<azonenberg_work>
re openfpga stuff
<daveshah>
We have no assumptions on being LUT based afaik. The only thing that might be trouble is architectures that have internal tristate drivers, as we assume each net has only one driver in the netlist
<azonenberg_work>
Right now my priority is hanging the last few bits of insulation tonight after work before the inspector comes tomorrow :P
<azonenberg_work>
neither greenpak nor coolrunner have any of that
<azonenberg_work>
coolrunner in fact could be very nicely modeled as being pip based
<azonenberg_work>
since the fabric is all one hot
<daveshah>
I would be really interested to see that
<azonenberg_work>
Me too, a unified FPGA+CPLD PAR backend would be awesome
<azonenberg_work>
And your arch seems to handle some of the problems i had with libxbpar nicely
<azonenberg_work>
For example, i had problems handling things like "this voltage ref is attached to this analog comparator"
<azonenberg_work>
Can you also have dummy pips to support mutually exclusive bels?
<azonenberg_work>
example, this counter is unavailable if this lut is used
<daveshah>
You can have mutually exclusive bels
<daveshah>
No need for dummy pips
<azonenberg_work>
well i need a bitstream bit to specify which is used
<daveshah>
there is a function checkBelAvail that you implement in the Arch to do that check
<azonenberg_work>
so there is literally a pip for this :p
<daveshah>
Sure - that would depend on how you did bitstream gen - you could also just check which Bel is bound
<azonenberg_work>
Yeah i'd use my existing bitstream lib
<azonenberg_work>
Boat is docking, back in a few
<daveshah>
We build a different binary for each arch (to avoid virtual function overhead), so linking stuff like that should be easy
<sorear>
You also only do unidirectional pips, afaict?
<daveshah>
You can model bidir pips using two unidir pips in each direction
<balrog>
is there an IRC channel for this project, or is this where it is discussed?
azonenberg_work has quit [Ping timeout: 276 seconds]
<daveshah>
right now here or #yosys
<daveshah>
maybe we should create one
<sorear>
The timing model would also need to account for that, since joining two nets with a pass transistor makes a higher capacitance net
<sorear>
Right now you seem to be assuming delay is a property of individual wires, and I don’t think bidirectional architectures work that way
<daveshah>
We support delays on both pips and nets
<daveshah>
And there is no requirement for those delays to even be constant, the architecture can use any method it likes to obtain them
<sorear>
Thoughts on my comment in #yosys ?
<etrig>
nextpnr FindBoost is really needy :o) -> Boost version: 1.67.0, Could NOT find Boost, Could NOT find Boost, Could NOT find Boost, Boost version: 1.67.0
<daveshah>
etrig: did it find it in the end (we do need to supress this printing without hiding real errors somehow)? we have to try lots of times because each distro names boost-python 3 differently
<etrig>
daveshah: yeah, it found it to start with but kept searching
<etrig>
oh, I see, that one was missing python3 support or something
<daveshah>
yeah, that's the problem
<daveshah>
it has to try all python3 naming possibilities
<daveshah>
ubuntu, arch, gentoo and homebrew (iirc) have all had different naming conventions
<gruetzkopf>
:( ecp5 only has 2 bidi serdes, max
<daveshah>
gruetzkopf: 4 on the larger packages
<daveshah>
it's still not enough imo
<gruetzkopf>
okay, then the website is confusing
<daveshah>
8 would have been much better, to do both 10GbE and PCIe x4
<gruetzkopf>
^
<gruetzkopf>
XAUI+gen1 x4
<daveshah>
but it's also dirt cheap
<daveshah>
the ecp3 had up to 16
* gruetzkopf
proceeds to glue two of them back-to-back with a big parallel pipe
<daveshah>
yeah
<gruetzkopf>
yes, but you need to go to 672fpBGA to get 8 with ecp3
<daveshah>
the ecp3 is also very expensive, probably more than the equiv 7-series
<sorear>
Does a typical serdes have much latency?
<daveshah>
a few system clock cycles
azonenberg_work has joined ##openfpga
<daveshah>
there's certainly some pipelining, fifos, gearboxes, etc involved
<azonenberg_work>
Back
<azonenberg_work>
daveshah: sooo few toher questions
<daveshah>
sure
<azonenberg_work>
The timing model, from a quick glance, looks to be setup only? or does it model hold time too
<daveshah>
not yet, we may add that at some point
<azonenberg_work>
And is there any support for temp/voltage corners? example, silego parts have a 1.8 to 5V Vdd range
<daveshah>
right now sign-off timing isn't really a focus
<azonenberg_work>
and timing varies dramatically over that range
<daveshah>
yes, timing is just returned by arch functions
<daveshah>
so they can pick from corners or whatever
<azonenberg_work>
But you can't do simultaneous min/max yet
<azonenberg_work>
in terms of ensuring you meet hold time at the fast corner plus setup at the slow
<daveshah>
no, because we don't do hold time yet
<sorear>
sign-off timing means replacing icetime!
<sorear>
?
<daveshah>
yes, although icetime doesn't do hold either....
<azonenberg_work>
Well, that will probably be a big TODO for me
<azonenberg_work>
i want a good signoff quality timing engine
<azonenberg_work>
It doesnt have to run all the time
<azonenberg_work>
my thought is, run signoff-level timing at the end of the par
<azonenberg_work>
internally to nextpnr
<daveshah>
yeah, I'm interested that for ECP5 too
<azonenberg_work>
if it fails, then update some stuff and re-run
<azonenberg_work>
i.e. start doing hold fixing and other stuff only after the main par has run fast
<azonenberg_work>
but then switch to the full timing engine to make sure it passes
<azonenberg_work>
i hate when you have a design pass par's timing then fail the signoff check
<azonenberg_work>
like, how do you fix that? :p
<azonenberg_work>
And once i get the silego flow up and running i will be adding support for PTV corners
<daveshah>
i think in the end we may do signoff timing as somewhat separate, and integrated by linking or something
<azonenberg_work>
basically just add a PtvCorner object as an argument to the get-delay functions
<daveshah>
We already have that for cell timing
<azonenberg_work>
oh?
<daveshah>
It's up to the arch again
<azonenberg_work>
that should be easy to add to arcs too
<azonenberg_work>
yeah but your api has no way to provide it
<azonenberg_work>
and for multicorner analysis you cant just make one arch with two different corners
<daveshah>
afaik we do return that for pips actually too
<daveshah>
it's just for ice40 we implement min and max to be the same - but that's a per arch decision
<daveshah>
so I was wrong before
<azonenberg_work>
Or can you have the object be constructed as DelayInfo(PtvCorner)
<daveshah>
if you only need absolute min and max, DelayInfo already works
<azonenberg_work>
Yeah, the problem is that now you are trying to make timing at 1.8V while running at 5V
<daveshah>
we also have the option for separate rise and fall delays if you want a really fancy STA engine
<azonenberg_work>
or similar
<whitequark>
daveshah: Warning: port $abc$9712$auto$blifparse.cc:465:parse_blif$9927_LC.I1, connected to net '$abc$9712$n980', has negative timing budget of -0.706000ns
<whitequark>
what does this mean?
<daveshah>
whitequark: that means that you have used up all the timing slack with cell timings
<azonenberg_work>
daveshah: Ideally, i want to be able to pass the operating point and tolerances on the command line
<daveshah>
azonenberg_work: that is already doable if the arch wants to
<daveshah>
we have similar for ice40 to pick between HX and LP
<azonenberg_work>
like nextpnr --part slg46620 --vddmin 1.7 --vddmax 1.9
<daveshah>
yeah
<daveshah>
there's nothing in the arch api that prevents that, it's just up to the implementation
<azonenberg_work>
ah ok
<azonenberg_work>
that's less of an issue for the high performance stuff like xilinx with a narrow vdd range
<azonenberg_work>
but a lot of the cost/power-optimized parts have a wider range and variable timing
<azonenberg_work>
probably psoc too
<daveshah>
the only concern would be not doing too many calculations inside the get delay functions
<azonenberg_work>
Yeah
<daveshah>
but that might not be a problem for small parts only
<azonenberg_work>
Basically i just want to be able to pick a slow and fast corner
<azonenberg_work>
and return delays[bel][corner]
<daveshah>
sure, that would work
<azonenberg_work>
Thats how i do it in greenpak already for gp4par
<daveshah>
so any of the get delay functions must return a DelayInfo, which itself implements 6 methods for min/max rise/fall/either delay
<daveshah>
the implementation of those functions, and how the DelayInfo is created, is up to the arch
<whitequark>
daveshah: is it normal that icetime returns far more conservative results?
<daveshah>
Yes, there's no reason we can't have one
<daveshah>
ZipCPU was looking into algorithms
<azonenberg_work>
ignore the -1 ns, those are not-yet-measured numbers from years ago (this is an old screenshot)
<daveshah>
So you are actually measuring timings
<daveshah>
Interesting
<azonenberg_work>
But note that the rising edge delays for the east/west routes (XCONN_*) have significant variation
<azonenberg_work>
and yes i'm doing pin to pin derlays from an FPGA
<azonenberg_work>
calibrating out fpga io buffer and test fixture delays
<azonenberg_work>
calibrating out DUT io buffer delays
<azonenberg_work>
then anything left over is the internal net delay
<daveshah>
Neat
<azonenberg_work>
i have voltage control on the board
<azonenberg_work>
i have chips from 3 different foundry lots
<azonenberg_work>
(thanks to silego for giving me those)
<azonenberg_work>
And i have a peltier setup that i plan to use for temp control
<azonenberg_work>
i've been able to get from -40 to 85C with it
<azonenberg_work>
But until the move is done i can't gather more data
<daveshah>
That will be interesting
<daveshah>
It might be fun to do something similar with the iCE40 UltraPlus to see how far we can push it
<azonenberg_work>
thats the other thing, if i really wanted to
<daveshah>
ie how much we gain with a small overvoltage and lower temperature than 85deg
<azonenberg_work>
i could do speed grade binning of greenpaks :D
<daveshah>
The ECP5s with the 5G serdes are actually "officially" overvolted
<daveshah>
They run at 1.2V instead of 1.1V
<awygle>
yeah the marketing copy on the ECP5-5G is amazing
<daveshah>
The fabric is quite a bit faster too
<daveshah>
But they don't tell you that - just found that from the sdf
<awygle>
the contortions they go to to _imply_ it's a different chip without actually _saying_ it are awesome
<daveshah>
I mean all three are the same, just binned
<awygle>
i know, they just don't want to advertise that
<daveshah>
ISTR the 1.2V was actually a PCN
<daveshah>
I presume the 5G yield at 1.1V was too low
<awygle>
that plus getting a handle on process would explain the glut of 5G parts recently compared to the basic ones
<etrig>
I hastily made a pkgbuild for nextpnr (ice40 only) and if someone caring about aur packaging guidelines wants to submit it: https://paste.ee/r/hwdpf
<awygle>
oh hey daveshah can you point me to the sdf you're looking at for 5G vs vanilla timings? that's actually Relevant To My Interests atm
<daveshah>
let me do this somewhat properly with a bigger design
<azonenberg_work>
This is looking at eastbound (left half) vs westbound (right half) delays for fabric connections on a greenpak at 3.3V, before calibrating out pad driver delay
<azonenberg_work>
You can see a pretty distinct pattern of east faster than west (or vice versa, i forget which is which)
<azonenberg_work>
then some spikes where certain paths are consistently 200-400 ps slower than others
<azonenberg_work>
You can also see that dies 0/3 are pretty fast, dies 4/1 are slow, and 2 is in between
<azonenberg_work>
and for the most part this is fairly consistent
<azonenberg_work>
also interesting however that die 0 is so much slower on the right half than the left while die 3 is fast
<azonenberg_work>
This is enough info to do speed grade binning for sure
<azonenberg_work>
Doing it with ECP5 would be cool, but would take more work to get precise timing
<daveshah>
yeah, maybe one could do a business selling binned iCE40 UltraPluss
<azonenberg_work>
i think i can figure out how to do it
<daveshah>
whitequark would buy them for sure :D
<azonenberg_work>
lol yeah
<azonenberg_work>
set up a peltier and voltage variable test jig
<azonenberg_work>
Rather than selling binned ones i'd sell it as a testing service
<azonenberg_work>
That way you dont have to figure out what to do with the slow ones
<azonenberg_work>
i.e. customer sends you 30 chips, you respond with a speed file for each one
<azonenberg_work>
They can use that info as they see fit
<daveshah>
awygle: these are unique edges extracted from SDF files for both normal and 5G
<azonenberg_work>
also, the challenge would be getting higher performance
<azonenberg_work>
my current testing setup just uses 7 series iodelay and is good to maybe +/- 75 ps
<azonenberg_work>
The other fun part is to try to avoid going through io buffers which, for fast parts, will hurt your measurements
<azonenberg_work>
I also don't yet measure setup/hold timing
<daveshah>
IODELAY is interesting
<daveshah>
ECP5 has similar
<azonenberg_work>
Basically what i do now is, i send an edge through an OBUF
<azonenberg_work>
Sample through IBUF + IDELAY
<azonenberg_work>
Figure out approximately how many cycles of my internal 200 MHz clock that it takes for propagation
<azonenberg_work>
then fine tune by sweeping the IDELAY to find the exact toggle point
<azonenberg_work>
Then subtract the calibrated delays for test fixtures and DUT IOBs
<azonenberg_work>
to calculate the internal DUT net delay
<azonenberg_work>
i have a little linear equation solver that i plug paths into and it calculates the delay for each arc
<azonenberg_work>
given the set of arcs and the total delay for each
<azonenberg_work>
At one point i even measured the different delays through lut inputs
<azonenberg_work>
i forget if it was MSB or LSB but on greenpak there is a definitely visible gradient where one end of the lut is faster than the other
<azonenberg_work>
just because of going through less muxes
<daveshah>
so ice40 has different delays for different LUT inputs in the official timings
<daveshah>
ECP5 doesn't
<azonenberg_work>
well, i can assure you there are differences :)
<azonenberg_work>
We just have to measure them
<daveshah>
yeah, Lattice were clearly having a lazy day :P
<azonenberg_work>
not as lazy as silego
<azonenberg_work>
who doesnt even publish min/max values
<azonenberg_work>
only typ
<daveshah>
lool
<azonenberg_work>
why do you think i started doing this?
<azonenberg_work>
i wanted to do STA and the datasheet didnt have the info i needed
<azonenberg_work>
So i started characterizing :p
<azonenberg_work>
Developing a f/oss post silicon timing characterization platform will be really cool once i have time to actually do it
<azonenberg_work>
we could use it for lots of stuff
<daveshah>
it would be awesome
<daveshah>
we'll need it for the foss fpgas anyway
<azonenberg_work>
yes
<azonenberg_work>
My current thought is to use a really fast latching comparator and very fine PLL then basically do the same thing
<azonenberg_work>
if you can get noise low enough from lots of averages
<awygle>
daveshah: _wow_, there's a_lot_ of variance between ECP5 speed grades even before this 5G stuff
<azonenberg_work>
you should be able to reliably measure delays that are many times smaller than your iob rise time
<daveshah>
awygle: yeah
<azonenberg_work>
awygle: have you looked at a silego speed file? :p
<awygle>
azonenberg_work: no, i only look at real parts :p
<azonenberg_work>
Lol
<azonenberg_work>
example: rising edge delay on lut4
<rqou>
oh, it actually did get released
<awygle>
daveshah: at the risk of being rude, do you have this file for a -6?
<azonenberg_work>
19.44 ns @ 1.8V
<daveshah>
awygle: can make one
<azonenberg_work>
7.43 ns @ 3.3V
<azonenberg_work>
4.98 ns @ 5V
<awygle>
daveshah: could you please? it would help me out
<rqou>
q3k, daveshah, clifford: one of you people better set the record straight exactly wtf was going on
<azonenberg_work>
I find it hilarious that they publish typical timing numbers down to 10ps resolution with no idea of variance
<awygle>
azonenberg_work: well okay, almost triple the voltage lol
<sorear>
You don’t need a fast comparator if you just loop the signal through the DUT 100 times before measuring?
<azonenberg_work>
awygle: lol yes
<awygle>
triple my voltage, i'll run faster too
<azonenberg_work>
awygle: but the point is, i've seen 600 ps variation for *the same timing arc* at the same voltage between dies
<azonenberg_work>
on greenpak at 3.3V
<azonenberg_work>
they publish typical numbers down to 10ps :D
<azonenberg_work>
i have to wonder if they just measured one die and called it good, lol
<awygle>
lol probably
<azonenberg_work>
sorear: that isnt always possible, and i want to be able to measure individual routing segments
<azonenberg_work>
They may not all be the same
<azonenberg_work>
in greenpak for example i will preferentially use eastbound fabric net 0 over 2
<azonenberg_work>
sorear: also consider trying to measure setup/hold times that way
<daveshah>
^ non-5G -6 ECP5
<azonenberg_work>
Not going to work well :p
<azonenberg_work>
For that you need a PLL with really fine phase offsets\
<awygle>
daveshah: are these ps delays?
<daveshah>
awygle: yeah
<azonenberg_work>
then basically sweep clock relatiev to data until it goes metastable
<awygle>
cool
<daveshah>
there is no -6 5G afaics
<sorear>
I don’t think what I said is incompatible with measuring individual routing segments
<daveshah>
but imo the 5G parts are effectively all -9
<azonenberg_work>
sorear: can you sketch out the actual start/=end points of the measurement you propose?
<azonenberg_work>
start/end*
<awygle>
wow look at those clock nets
<awygle>
from 5700 to 1400
<daveshah>
awygle: they might not be the same thing (that's a quick grep and sort -u of an SDF)
rqou_ has joined ##openfpga
<sorear>
Remind me in a couple hours when I’m not on a phone on a bus
<awygle>
daveshah: i mean they all say "IOPATH CLKB DOA0"
<daveshah>
I'll do a proper cell timing importer soon that makes a JSON database and HTML report like icestorm
<daveshah>
awygle: oh yeah, they should be the same then
<daveshah>
that's a clock to output time
<azonenberg_work>
In my current greenpak setup i have fpga obuf -> traces and connectors -> greenpak ibuf -> [insert magic here] -> greenpak obuf -> traces and connectors -> fpga ibuf -> fpga idelay
<daveshah>
of a RAM
<azonenberg_work>
sorear: and i calibrate out all of that round trip delay to calculate the value of magic
rqou has quit [Ping timeout: 256 seconds]
rqou_ is now known as rqou
<sorear>
I agree setup/hold is harder since all you can really measure is “did it work?”
<openfpga-bot>
jtaghal/master 1c31775 Andrew Zonenberg: STM32Device: Implemented ClearReadLock()
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNo89
<azonenberg_work>
There are some arcs i probably will not be able to deconvolve
<azonenberg_work>
for example in greenpak net delay after the matrix and cell delay
<azonenberg_work>
i think i can only ever measure the sum of the two
<awygle>
tfw your board has a -8 and you're synthesizing for a -6 T_T
<azonenberg_work>
Derp
<awygle>
yup
<awygle>
it's okay, everybody else was using -8
<awygle>
explains some things though
<cpresser>
what products do you guys use for adding solder-resist to exisiting PCBs?
* cpresser
wants to do #reworkctf soon
<azonenberg_work>
cpresser: please dont
<azonenberg_work>
after my move is done i'll be working on reworkctf v0.2
rohitksingh has quit [Quit: Leaving.]
<azonenberg_work>
There are several (unintended) bugs in v0.1
<azonenberg_work>
one of the inner layer edits is way too easy, i put the short on the wrong layer
<azonenberg_work>
(i wanted to force a high aspect ratio drill)
<azonenberg_work>
the fpga auto-grader doesnt work on some challenges unless you load the xc3s200a instead of the 50a i originally planned to use (some pins are NC in the 50a)
<azonenberg_work>
and then one of the inner layer via shorts is shorting at both ends of the trace instead of just one
<azonenberg_work>
i mean, you're welcome to try anyway
<azonenberg_work>
Just know it's not really done :)
<azonenberg_work>
For both solder mask and base board repair, i use atom adhesives aa-bond f113 two part clear epoxy
<cpresser>
azonenberg_work: i already ordered the PCBs half a year ago
<azonenberg_work>
ah, ok
<azonenberg_work>
in that case let me know if you find any other bugs :)
<gruetzkopf>
(and again i scroll through the user list and see like half my ccc erfa here :D)
<azonenberg_work>
i mean its good practice even without the fpga autograding
<cpresser>
i just was to lazy to actually start doing it
<azonenberg_work>
comes in a little pre-measured pouch and you can squeeze them toegther, mix, then dispense
<cpresser>
ill try that stuff
<azonenberg_work>
You can also buy large containers and measure it out yourself but i am willing to pay for the convenience
<azonenberg_work>
i figure $6 for a bit of epoxy is no big deal compared to saving what would otherwsie be a $$$ pcb respin
<cpresser>
my plan is to bring ~5 reworkctf boards to EMF camp for random people
<azonenberg_work>
awesome
<cpresser>
but I want to do one myself first^^
<sorear>
azonenberg_work: I’ll draw a picture later if you want but I’m suggesting using the path under test + harness to make a *ring oscillator*, then dividing by 1000 and measuring the divided period
<cpresser>
if I spot anything, I will make a list of things to be improved
<azonenberg_work>
sorear: hmmm, that might work if you added an inverter
<cpresser>
the first one would be to add a BOM :)
<azonenberg_work>
cpresser: and yeah i want to try doing one with my new curie point iron (once i buy it and get the new lab set up)
<azonenberg_work>
see how it compares to the cheap aoyue
<sorear>
Separately measuring rise and fall is slightly trickier but I have an idea
<azonenberg_work>
And yes i didnt make a bom b/c i knew it needed work and i didnt want to encourage too much use until the bugs were fixed :)
<azonenberg_work>
sorear: and ring oscillator stuff also runs into problems when you oscillate toooo fast
<azonenberg_work>
because you dont get full amplitude
<cpresser>
I have a bom with digikey part numbers; I can make a pull-request if you like
<awygle>
"distributed RAM" refers to using the LUT bits as RAM, not the FFs in the slices, right?
<azonenberg_work>
so it might not give accurate switching waevforms
<azonenberg_work>
awygle: correct
<daveshah>
awygle: yeap
<awygle>
lol
<awygle>
i'm so correct!
<daveshah>
that's the thing with the mystery silicon bug in the ECP5
<azonenberg_work>
cpresser: go for it, but know that i wont merge until i've fixed my other bugs
<azonenberg_work>
probably wont be any component changes, just layout fixes and pin reassignment
<sorear>
azonenberg_work: hence a large delay line in the harness, which you can calibrate out
<daveshah>
I'll probably implement blockRAM for ECP5 in nextpnr before distRAM as a result
<awygle>
daveshah: what diamond version "fixed" that again?
<daveshah>
I think it was fixed in 3.7
<awygle>
or rather was it fixed by 3.9
<awygle>
okay, cool
<daveshah>
No, definitely before
<sorear>
Mystery bug?
<daveshah>
They mention a silicon bug with some packing/placement of dram. But they don't give details, just that it was fixed in 3.7
<awygle>
weird that the EBR in ECP5 goes from 4kx4 to 2kx9
<daveshah>
Yeah
<daveshah>
Well, I suppose the half bit can't do anything
<awygle>
yeah i suppose lol
<sorear>
Xilinx does the same thing no?
<sorear>
Or microchip when you go from 5 to 2
<azonenberg_work>
well
<azonenberg_work>
xilinx had a bug re fractured bram init in spartan6 :p
rohitksingh has joined ##openfpga
<azonenberg_work>
Oh, here's a fun task if anybody is up for it
<azonenberg_work>
Compare bitstreams generated with INIT_9K yes or no
<azonenberg_work>
And try to figure out the bug :p
<azonenberg_work>
i.e. look at the workaround and try to figure out how they fixed it
Ultrasauce_ has quit [Quit: Ultrasauce_]
Ultrasauce has joined ##openfpga
<sorear>
azonenberg_work: re. rise times, my idea is to make a fairly long (10us or so) *non-inverting* delay element in the harness, with some mechanism to inject a 5us long pulse, and then a mechanism to measure the frequency of rising/falling edges, which will be different
* awygle
starts visualizing slow-wave structures
<sorear>
azonenberg_work: since the rising and falling edges move at different speeds they will collide and stop oscillating; the period needs to be measured before that happens
<azonenberg_work>
Hmm
<azonenberg_work>
Well for greenpak direct measurement was definitely the easiest way
pie__ has joined ##openfpga
mumptai has left ##openfpga ["Verlassend"]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<sorear>
azonenberg_work: proposal #4: a ring oscillator consisting of a 100ns delay in the harness FPGA, an inverter, then *the DUT, bypassed by an AND gate*. on low-to-high transitions, the edge needs to propagate through the DUT, but high-to-low transitions bypass the DUT through the gate, so the frequency of the oscillator depends only on the rise time, not the fall time, of the DUT.
<sorear>
produces an indefinitely running, glitch-free, near 50%, not too fast signal which can be divided and measured with no funny business
<azonenberg_work>
how do you do a 100ns delay in an fpga?
pie___ has joined ##openfpga
<azonenberg_work>
of an arbitrary combinatorial signal?
<azonenberg_work>
(and how do you do that without introducing jitter that destroys the signal you're trying to measure?)
pie__ has quit [Read error: Connection reset by peer]
<sorear>
you find an element that can delay a signal by a small amount without introducing glitches, then repeat it a few dozen times and don't sweat the exact value because it just goes into the calibration constant
<sorear>
the only important things are (a) the delay is constant (b) the delay is long enough that you don't wind up with a 500mhz oscillator
rohitksingh has quit [Quit: Leaving.]
<sorear>
related: it'd be interesting to have data in one of our wikis on what glitch-free logic primitives exist on various architectures
<azonenberg_work>
That's my question
<azonenberg_work>
i legitimately do not know how to do a glitch-free delay element on a xilinx part other than an ODELAY
<azonenberg_work>
And those add enough jitter that i dont think they'd be useful if you cascaded several ns of them
<awygle>
why not just divide down a 500 MHz oscillator
<azonenberg_work>
xilinx stuff at least is very much intended for synchronous design
<awygle>
that's pretty easy to do with the PLL of your choice
<azonenberg_work>
well if you can guesstimate the frequency
<azonenberg_work>
the plls have lock constants that have to be chosen for the target operating frequency range
<azonenberg_work>
But dividing down can be done in fabric
<azonenberg_work>
Since you dont need phase alignment
s1dev has joined ##openfpga
<sorear>
azonenberg_work: the CLBs have latches, i think you can route a signal into a latch bypassing the LUTs and hold the latch's enable high
<azonenberg_work>
not sure that buys much delay beyond the routing itself?
<awygle>
just grab a frequency counter to get a rough frequency. i don't know how much drift we're talking about here though.
<sorear>
the routing itself is the point here, I think
<sorear>
if you bounce the signal back and forth across the chip a dozen times, it'll be slow enough that you can divide it in fabric
<s1dev>
azonenberg_work, I came across your repo due to some stuff at work. Did you ever end up implementing Population Annealing?
<sorear>
"sorear: and ring oscillator stuff also runs into problems when you oscillate toooo fast / because you dont get full amplitude"
<sorear>
the only purpose of the delay is to avoid ^
<azonenberg_work>
and realistically
<azonenberg_work>
i think IOB delay is probably enough to keep you to a sane frequency
<azonenberg_work>
at least in greenpak
<azonenberg_work>
Doing rising/falling delays separately will be fun using that technique though
<sorear>
i think you can use the async sets/resets as non-glitching AND/ORs
<awygle>
s1dev: to my knowledge no one has yet implemented population annealing in an fpga context. if you're familiar with the algorithm, i'd love to pick your brain on the subject
<s1dev>
awygle, very
<s1dev>
I've done some work on physics based optimization of Boolean optimization problems mainly with Population Annealing and Parallel Tempering
<awygle>
s1dev: on second thought, are you likely to hang out in this channel for a while? i'd like to take the time to review the papers i've saved and my notes on them so i can have a real conversation about this
<awygle>
which realistically can't happen until at least this evening
<s1dev>
sure. I might be in and out since I don't have a bouncer. Which papers are you looking at?
m_t has joined ##openfpga
<awygle>
i have "Population annealing: theory and application in spin glasses" by Wang, Machta and Katzgraber and "GPU accelerated population annealing algorithm" by Barash, Weigel, Borovsky, Janke, and Shchur
<awygle>
i think i remember not finding a good "population annealing for dummies" paper
<awygle>
if you have recommendations i'd welcome them
<s1dev>
Weigel's paper uses some tricks specific to spin glasses. I wouldn't bother looking at it personally
<sorear>
i just skimmed the Iba paper (first hit for Population Annealing) and it seemed more relevant to "I am trying to calculate thermodynamic quantities" than "I just want to find the ground state"
<s1dev>
Yeah, there's not much in the literature about using PA as a solver. Wang has an earlier paper where he demonstrates a speedup over simulation annealing by adding the resampling step
<s1dev>
for most of the papers, skip over the physics :)
<awygle>
sorear: i see a paper by Machta and Amey and another by Machta and Callaham, but nothing by an Iba?
<awygle>
okay i'll review all 6 of these and ping you again when i'm more prepared, s1dev . excited to have someone who knows what they're doing to talk to :)
<sorear>
assumption: SA PnR uses SA to move bels around, but does the routing using exact pathfinding approaches e.g. A*
<s1dev>
awygle, don't waste your time reading all of them. The useful stuff will be covered by almost any of them
<s1dev>
sorear, is that what's usually done? I know VPR does
<awygle>
sure, i plan to skim
<sorear>
s1dev: i don't know, that's why I'm asking
<sorear>
I meant to add "is this correct or incorrect?" at the end
<awygle>
sorear: my understanding is yes, but not usually A*. the Lee algorithm seems most common based on my survey.
<awygle>
sorear: not necessarily. all you need is a cost function to minimize. you need routing to produce a bitstream, but you can do placement without it.
<awygle>
of course, the ideal cost function would include the full cost of the routing, but that's (potentially) too slow to do on every SA tick.
<sorear>
awygle: it seems like you need to at least detect *unroutable* placements so that SA can avoid them?
<awygle>
arachne-pnr uses the sum of the "half-perimeter wire length" of each net as its cost function
<sorear>
or do you just assume that there's enough routing available that any placement will be routable (at some cost)?
<awygle>
i don't know how the commercial tools do it, but arachne does the latter, i'm pretty sure
<awygle>
there's an up-front packing step to make sure that carries are legally placed and that's about it
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNoMo
<openfpga-bot>
jtaghal/master f43c56a Andrew Zonenberg: Initial STM32 flash support
<daveshah>
we also do have the option in the arch API to do specific checks during placement
<daveshah>
In the ice40 this covers quite a bit
<azonenberg_work>
awygle: bel is the xilinx terminology for a single primitive within a tile (lut, ff, etc)
<daveshah>
Max 32 local tracks per tile, clock, ce and sr must the the same in a tile
<azonenberg_work>
not fpga related but my jtag tools can now enable/disable stm32 level 1 read protection (level 2 not fully supported as i dont want to brick my devkit yet)
<azonenberg_work>
bulk erase devices
<azonenberg_work>
and load new rom images
<azonenberg_work>
So far, supports jtag only (no swd) and only tested on stm32f411ve
<sorear>
does nextpnr placement prioritize nets which are on critical paths yet?
<daveshah>
Sort of
<daveshah>
We don't have an explicit criticality factor like VPR has I think
<daveshah>
Instead we assign net users a "budget"
<daveshah>
Based on how long the path that net is on, and how long the cell delays are
<daveshah>
Then use the slack - budget minus actual routing delay as a weighing during placement and routing
<daveshah>
This is all quite experimental still
Bike has quit [Ping timeout: 252 seconds]
<azonenberg_work>
whitequark: around?
<azonenberg_work>
awygle: hmmmm
<azonenberg_work>
So thinking again about sshd's for latentred
<azonenberg_work>
Rather than going with a massive cortex-a
<azonenberg_work>
What if i stuck with the spartan-7
<awygle>
azonenberg_work: keep talking but i have a meeting so response will be delayed
<azonenberg_work>
But instead of a zynq or sitara, i went with a stm32?
<azonenberg_work>
Which means that dropbear or something plus a basic CLI should work fine
<awygle>
azonenberg_work: i would not baseline nommu linux (but you might). i might baseline smoltcp, but you wouldn't lol
<awygle>
iirc rqou played with nommu at one point? but i could be wrong
<azonenberg_work>
stm32f7 actually seems to be able to run full linux with mmu
<azonenberg_work>
in the mainline kernel
<awygle>
there's no mmu in the part though
<sorear>
what, it's an A-core?
<awygle>
so that doesn't make sense
<awygle>
it's mainline, but it's nommu
<azonenberg_work>
it's a cortex-m7
<azonenberg_work>
does that not have a mmu?
* azonenberg_work
double checks
<daveshah>
MPU but no MMU I think
<awygle>
pretty sure that's the fundamental difference between m and a
<azonenberg_work>
hmm, ok
<sorear>
the higher M-cores have MPU (segments, basically) but no paging
<awygle>
right but even an msp430 has an mpu
* awygle
actually leaves
<azonenberg_work>
I think that would still be sufficient for my "run dropbear plus a basic app to bridge ssh to a uart"
<sorear>
the most fundamental difference between m and a is that A has mrc/mcr, M memory-maps all of the control registers
<sorear>
embedded C programmers hate inline asm and love this
<azonenberg_work>
And it'd be totally capable of running a bare bones tcp stack and sshd if this was available
<azonenberg_work>
and yes, having spent a lot of time reversing and writing jtag code for both
<azonenberg_work>
i find M to be muuuuch easier to wrap my head around
<sorear>
M has an interrupt mechanism which can directly call ordinary C functions, A has an interrupt mechanism that requires you to write asm entry code
<azonenberg_work>
sounds like A is much less friendly in all regards, lol
<azonenberg_work>
That was the impression i got in the past
<sorear>
R is the fun one, it's basically A in the major aspects but with M's MPU
<sorear>
and now riscv is doubling down on the classic/A approach and not even trying to make something reasonably usable from C (yes, there are IP complications)
<gruetzkopf>
nommu support has been upstream in linux for a while
<rqou>
nommu stm32 apparently has issues
<rqou>
nommu as a concept does work though
<rqou>
ask landley in #j-core and he can probably give you a nice rant about it
<rqou>
btw azonenberg_work i just tried switching flux to smd291 from chipquik and performance seems not any worse
<rqou>
it's significantly less sticky and the fumes seem to be less irritating, so those are plusses
<rqou>
sorear: i am not sure at this point
<azonenberg_work>
rqou: well sticky is good in terms of flux not getting everywhere, i dont want it to be super runny
<rqou>
nobody has given me a clear answer regarding the relationship between "SymbiFlow" and "SymbioticEDA"
<rqou>
azonenberg_work: er, it's much less sticky after soldering
<azonenberg_work>
i mean i ipa-swab no matter what
<rqou>
unlike the mg chemicals one that i used to use that you complained was a pain to clean
<rqou>
the chipquik flux seems to also clean better with IPA
* gruetzkopf
looks at his stash of ipa
<rqou>
so in general smd291 - works just as well, fumes less irritating, less difficult to clean, still tacky enough for use
azonenberg_work is now known as azonenberg
<gruetzkopf>
all illegal to use commercially, because it has the (superior) Black/orange "european" safety graphics instead of the overly generic ISO ones
<sorear>
ipa = CC(C)O?
azonenberg is now known as azonenberg_work
<azonenberg_work>
rqou: yeah i like it, although if the fumes are bothering you with any flux
<azonenberg_work>
it means that you dont have enough ventilation :p
s1dev has quit [Quit: Leaving]
Bike has joined ##openfpga
<awygle>
tinyfpga: did you stick with the 10mm ECP5 or did you go to the 17mm? what are the exterior dimensions of the EX?
<jn__>
rqou: safety warning: don't confuse Irish Pale Ale and Isopropyl Alcohol :P
* awygle
didn't find this info on twitter, hopes it isn't obviously there
<sorear>
jn__: that was precisely what I was thinking when I asked for clarification
<tinyfpga>
awygle: I’m still using the 10mm ECP5, it’s the only one that fits. The EX is slightly smaller than a stick of gum. 0.7” by 2.4”
<awygle>
guessing you're waiting on the final design and maybe some period of time after they go on sale to release the files?
<tinyfpga>
awygle: yeah, I want to release it close the the start of the Crowd Supply campaign
<awygle>
tinyfpga: any idea on roughly when that'll be? (i hope to use you to influence a decision at work, is why i'm asknig lol)
<tinyfpga>
awygle: it’s not really open hardware/software until the files are released under an OHS-compatible license
<tinyfpga>
awygle: I plan on having the crowd supply campaign this fall
<awygle>
perfect, thank you!
<tinyfpga>
awygle: hopefully start in a couple months
<tinyfpga>
awygle: I will have at least another run of prototypes before the production run.
<sorear>
have they been tested with nextpnr/prjtrellis yet?
<tinyfpga>
sorear: daveshah has a first gen prototype working with nextpnr/prjtrellis, as soon as I have time ill run the same demo on the latest prototypes
* azonenberg_work
is very excited to see prjxray + nextpnr
<azonenberg_work>
is anybody actively working on that?
<azonenberg_work>
Do you have a plausible timeline?
<tinyfpga>
azonenberg_work: daveshah is working on it a lot as far as I know
<azonenberg_work>
Nice
<tinyfpga>
azonenberg_work: he’s done almost all the work on prjtrellis
<azonenberg_work>
:D
<tinyfpga>
azonenberg_work: I’m super duper excited about it, once they get blockrams working it will start to be useful
<azonenberg_work>
Yeah
<azonenberg_work>
Is that a nextpnr issue or an xray issue?
<tinyfpga>
azonenberg_work: though I’m ultimately excited about ECP5 SERDES/PCS support
<azonenberg_work>
do we know what the bits do yet?
<azonenberg_work>
yes, a free toolchain with serdes support would be really awesome
<azonenberg_work>
What's the status of that?
<awygle>
needs lots of fuzzing, is my understanding
<tinyfpga>
azonenberg_work: I believe the blockrams need to be fuzzed still...but daveshah would know
<tinyfpga>
SERDES/PCS is probably near the bottom of the list
<azonenberg_work>
No 1mm package options for ecp5 though?
<azonenberg_work>
:'(
<azonenberg_work>
somebody needs to poke laen to offer a batch run with tighter specs suitable for 0.8mm bga
<azonenberg_work>
so many cool parts are off limits to me unless i want to spin a "real" board
<tinyfpga>
I’m using 0.5mm with 4/4mil traces/spacing and 0.2mm drill with 0.5mm total annular ring diameter
<tinyfpga>
it’s kind of crazy...but is working well so far
<azonenberg_work>
on oshpark??
<tinyfpga>
PCBWay
<azonenberg_work>
oh
<azonenberg_work>
i mean i've done 0.35mm WLCSP
<azonenberg_work>
But not on oshpark design rules :p
<tinyfpga>
But I have done the same on oshpark
<azonenberg_work>
my experiences with pcbway have not been great
<azonenberg_work>
i've only used their flex service so far but quality was not great
<tinyfpga>
You can do it on oshpark, but only 50% of the boards will have good enough alignment
<azonenberg_work>
Exactly
<tinyfpga>
I needed 6 layers for the EX, oshpark can’t do 6
<azonenberg_work>
I dont want to do 50% yield :p
<azonenberg_work>
heck, i normally use *restricted* design rules on oshpark
<azonenberg_work>
minimizing use of stuff that pushes their process limits, to increase the odds of it working
s1dev has joined ##openfpga
<tinyfpga>
I use PCBWay for almost everything now, I’m pretty happy with them. They use different PCB fabricators depending on your needs
<azonenberg_work>
Also the oshpark silkscreen...
* azonenberg_work
drool
<azonenberg_work>
i wish more fabs had lpi silk as standard
<azonenberg_work>
oh, not FPGA related exactly
<awygle>
tinyfpga: is the IC near the USB C on the side near Pin 1 the only switching IC on the board?
<awygle>
err, switching power supply IC
<azonenberg_work>
But what's the fastest wifi standard that you can do without MIMO?
<awygle>
azonenberg_work: 802.11g, 54 Mbps, iirc
<azonenberg_work>
So n/ac are not doable without MIMO?
<awygle>
one of the "1x1 MIMO" modes of n or ac might do better
<azonenberg_work>
1x1 mimo? that sounds like a contradiction
<awygle>
it is
<awygle>
it just means "we support mimo but you don't have enough antennas" basically
<awygle>
lol
<tinyfpga>
awygle: there’s a 5amp 1.2v switcher for vcore near pin 4, and a 600ma 3.3v switcher near pins 42/41
<azonenberg_work>
lol
<awygle>
wow that thing does _five amps_?
<awygle>
criminy
<tinyfpga>
awygle: the 3.3v switcher is tiny...about the size of an 0402 cap
<awygle>
oh yeah i see it now
<sorear>
afaik mimo requires antennas separated by O(λ); i'm pretty sure there are n/ac devices smaller than 6 cm
<azonenberg_work>
sorear: yeah that's the point, this is for a spatially constrained idea
<awygle>
yeah i'm reconsidering my answer since you can run AC in 160MHz mode without MIMO
<awygle>
and it supports higher QAM too
<azonenberg_work>
Which brings me to the other question, are there any f/oss friendly chipsets that support e.g AC in 1x1 mode?
<awygle>
so if you have clean spectrum you can probably do quite a bit more than 54 Mbps
<awygle>
there are no foss-friendly chipsets.
<azonenberg_work>
the esp32 comes close-ish
<awygle>
(depends what you mean by the term but imo)
<awygle>
tinyfpga: would you mind if i showed this to a colleague?
<azonenberg_work>
awygle: i'm thinking again about my crazy idea from before about adding wifi to LATENTRED
<tinyfpga>
awygle: go for it, it’s all public on twitter anyways XD
<sorear>
the advantage of the 17mm is that all four serdes are broken out?
<azonenberg_work>
And trying to figure out how much 802.11 you can cram in a SFP+
<awygle>
tinyfpga: true but i prefer to ask :) thanks!
<awygle>
sorear: and the design rules are less ~abusive~ strenuous
<awygle>
and you get more pins
<gruetzkopf>
you should be able to fit 2x2 AC into one
<tinyfpga>
I think I messed up the vout sense line for the 1.2v switcher...it’s running too high on the boards
<azonenberg_work>
gruetzkopf: basically the dream is a black box that looks like a SFP+
<azonenberg_work>
you stick into an ordinary layer 2 switch
<awygle>
tinyfpga: have you had any thermal issues with those terrifyingly small PSUs?
<azonenberg_work>
and it transparently bridges the wifi to whatever vlan that port is on
<azonenberg_work>
then you can use the i2c bus to configure ssid, psk, etc
<prpplague>
tinyfpga: side note, demo with the -Bx went super well, it was very well received, definetly keeping the tinyfpga stuff in my "tool box" for future proof-of-concept and demo stuff
<sorear>
would the ordinary layer 2 switch know to issue those i2c commands?
<azonenberg_work>
No
<azonenberg_work>
You'd either plug it into one of my switches with special firmware, or some kind of pc programming jig
<azonenberg_work>
containing say an ft232 and a sfp+ cage
<tinyfpga>
prpplague: yay! I’m so happy to hear that, thanks for sharing the news with me!!
<prpplague>
tinyfpga: and i got paid after the demo, which is even better news! hehehe
<prpplague>
i love it when they pay the same day i invoice
<tinyfpga>
awygle: not yet, but I’m not running anything serious on them. The 1.2v switcher is currently running at 1.3v...not great for thermals in the FPGA. I believe that’s a bug in my PCB design around the switcher
<gruetzkopf>
my 2nd-fav dongle is DB15 male (vga) to sfp-cage
<azonenberg_work>
looool
<azonenberg_work>
EDID -> SFP eeprom?
<gruetzkopf>
yup
<prpplague>
HA
<gruetzkopf>
i2c-dev ftw
<azonenberg_work>
What is #1?
<tinyfpga>
awygle: I’ll be testing larger designs soon. The switchers aren’t the real problem for heat, it’s the FPGA and the LDOs that are burning the energy
<gruetzkopf>
expresscard to pcie proper, ofc
<tinyfpga>
awygle: I have some tiny heat sinks for the FPGA just in case DD
<tinyfpga>
*XD
<awygle>
tinyfpga: sure, it just took me aback lol. 5 amps!
<gruetzkopf>
my shitty impl is now tested to 8GT/s
<tinyfpga>
prpplague: that’s super awesome!
<tinyfpga>
awygle: it’s an awesome switcher so far...super happy with it.
<azonenberg_work>
gruetzkopf: which direction
<azonenberg_work>
expresscard module to pcie mobo?
<azonenberg_work>
or pcie card to laptop?
<gruetzkopf>
2nd
<gruetzkopf>
my shitty diy build already made the rounds on twitter three times ;)
<awygle>
tinyfpga: based on experience i doubt the FPGA will need them unless it's because of the 5G SERDES
<zkms>
gruetzkopf: i tried doing something similarly cursed but with SATA and M.2 on my shitty laptop and it sorta worked but it wasn't actually reliable
<gruetzkopf>
ANY nvidia video card being present at boot turns off the intel iGPU..
<gruetzkopf>
no matter which pcie port
<gruetzkopf>
this is extremely stable
<gruetzkopf>
transfered 10s of gbytes over 10GE nic with this, as well as played through most of portal 2
<zkms>
nice
<zkms>
what model laptop?
<gruetzkopf>
dell e5430
<zkms>
ic ty
<gruetzkopf>
i assume the 6x30 series and the x530 15" models are also hit by that bug
<tinyfpga>
awygle: maybe...but I’m paranoid. The board itself is small, so there’s less copper to take and radiate the heat from the FPGA than a larger dev board
<tinyfpga>
Most use cases won’t need them
<awygle>
that's fair
<tinyfpga>
But a large design could become quite hot
<tinyfpga>
I might make the template project for the EX include the thermal sensor and automatic clock gating if a critical threshold is reached
<sorear>
is write endurance at all a problem with the tinyfpga bootloader approach?
<awygle>
i don't understand why complex ICs don't expose a thermal diode...
<tinyfpga>
sorear: I don’t see it to be any worse than programming a micro with built-in flash
<sorear>
my working assumption is "thermal diodes are analog IPs that you can't simulate, and the people who have proven thermal diodes for process X are charging extortionate prices for them"
<tinyfpga>
sorear: 100,000 cycles would be 3 years of development with 100 reprogrammmings of the board every day
<tinyfpga>
sorear, awygle: ECP5 has a nice thermal diode built in that is pretty easy to use