wpwrak has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
genii has quit [Remote host closed the connection]
wpwrak has joined ##openfpga
<fseidel>
it's a stretch, but do any of you have experience throwing out the prepackaged OS on an LPC4088 and doing bare metal dev?
X-Scale has quit [Ping timeout: 240 seconds]
unixb0y has quit [Ping timeout: 246 seconds]
dj_pi has joined ##openfpga
unixb0y has joined ##openfpga
Maylay has joined ##openfpga
gsi__ has joined ##openfpga
dj_pi has quit [Ping timeout: 250 seconds]
gsi_ has quit [Ping timeout: 240 seconds]
emeb has quit [Quit: Leaving.]
Flea86 has joined ##openfpga
mumptai_ has joined ##openfpga
X-Scale has joined ##openfpga
mumptai has quit [Ping timeout: 244 seconds]
soylentyellow__ has quit [Remote host closed the connection]
soylentyellow has joined ##openfpga
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 268 seconds]
pie__ has quit [Ping timeout: 268 seconds]
wpwrak has quit [Remote host closed the connection]
Miyu has quit [Ping timeout: 246 seconds]
pie_ has joined ##openfpga
Bike has quit [Quit: Lost terminal]
pie_ has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
Hamilton has joined ##openfpga
rohitksingh has quit [Ping timeout: 272 seconds]
<kc8apf>
does (family, die, package) uniquely identify any PLD?
<sorear>
if (die, package) doesn't uniquely identify any packaged chip whatsoever I'm interested to know more
<kc8apf>
I'm wanting to define something similar to a gnu target triple for plds
rohitksingh has joined ##openfpga
<catplant>
sorear, kc8apf: speed grade?
<kc8apf>
hmm, that would change timing wouldn't it
<sorear>
I guess that might not always be included in die specs
<catplant>
also iirc some fpgas with serdes silicon that doesn't work are sold as serdes-less ICs (same die, perhaps diferent bonds)
<sorear>
yeah ecp5
<kc8apf>
aren't those different packages though?
<kc8apf>
I guess it doesn't need to be
<sorear>
according to lattice marketing, it's the same packages but different dies
<sorear>
(it's actually the same die)
<kc8apf>
hmm
<kc8apf>
so (family, die, bondout, package, speed)?
<sorear>
what if we just used mfg part numbers
<kc8apf>
hard to map back to families
<sorear>
we don't care about the temperature range but everything else
<kc8apf>
xc7a and xc7k use the same tile library but xc2c and xc2s don't
<kc8apf>
I want to know how similar devices are in dimensions that EDA tools care about
<tnt>
kc8apf: well, we'd need a mapping list somewhere anyway right ? because users will want to input the pn and not some obscure internal spec ?
<kc8apf>
maybe?
<kc8apf>
no one types in their CPU model # to compile for it
<tnt>
well no, I use march=native and gcc looks it up because its running on it :p
<sorear>
no, they type in "-march=native" because it can be probed
<kc8apf>
or they use a target triple
<kc8apf>
to target all compatible devices
<sorear>
ok, quick quiz
<sorear>
what hardware is supported by a binary output by rustc --target i686-unknown-linux-gnu
<kc8apf>
anything that supports Linux on a 32-bit x86
<kc8apf>
vendor was a terrible idea in gnu triples
<sorear>
the correct answer is "Pentium 4 or higher" because they depend on SSE2 for floating point semantics
<kc8apf>
which is why it isn't practically used
<kc8apf>
hahah. who decided that was sane
Flea86 has quit [Ping timeout: 250 seconds]
<tnt>
kc8apf: also even if the same die, different mnfg pn will yield different bitstream and one can't be loaded as/is in another device AFAIK, the device are fused to only accept bitstream with their own ID.
<sorear>
gnu target names are at best loosely standardized between projects :(
<kc8apf>
yes. a specific device needs to be targeted for a bitstream
<kc8apf>
there are other points in the toolchain where the specific device is irrelevant
<kc8apf>
sorear: well, they are _gnu_ target names
<sorear>
gnu gcc has a bunch of build-time and run-time options that change the ABI without changing the triple
<kc8apf>
what does that have to do with plds?
<sorear>
it mostly has to do with my personal anger against triples
<sorear>
they're almost fit for purpose, but not quite, and worse is that I don't actually know how to fix them
<sorear>
i feel like it doesn't make sense to talk about abstractions of FPGA parts without making very clear what you can abstract, why, and for how long
<sorear>
there's some relationship between gcc "you can only build a gcc for one --target (but it may still have a -march option)" and nextpnr's per-family binaries
<kc8apf>
then there's llvm's single build for all targets model
<sorear>
yeah, with LLVM_TARGETS_TO_BUILD, which I much prefer
<kc8apf>
Assume I have a partial design implemented for xc7a35t and another for xc7a50t that do not overlap in tile usage. How can I know that I can combine them into a single design?
<sorear>
partial design, you mean in a partial reconfig sense?
gsi_ has joined ##openfpga
<kc8apf>
sure, if that helps
gsi__ has quit [Ping timeout: 246 seconds]
Flea86 has joined ##openfpga
<daveshah>
FYI, the SERDES and non SERDES ECP5 are not strictly bitstream compatible even ignoring the IDCODE
<daveshah>
Because the 5G SERDES variant runs at 1.2V Vcc rather than 1.1V for the others
<daveshah>
so it has substantially different fabric timing
<kc8apf>
ugh
<daveshah>
It's effectively speed grade 9 (with the other parts being 6-8)
<daveshah>
But Lattice still sell it as grade 8
<daveshah>
In some cases it's more than a speed grades difference even (BRAM clock to out being almost 3x faster at 1.2V)
* sorear
doesn't follow what a "partial design" means then. verilog, blif, post-pnr?
<daveshah>
also afaik there isn't actually a bond out difference between the SERDES and non SERDES parts
<daveshah>
the only difference is what is tested/guaranteed at the factory, and the idcode
<daveshah>
with the 5G devices being binned for 1.2V because they couldn't get the yields for 5G SERDES at 1.1V...
* kc8apf
goes back to working on easy problems like a container format for bitstreams