<azonenberg_work>
Or you could read each density's datasheet
<azonenberg_work>
i dont think they started publishing family overviews till later
<rqou>
what's your opinion on *ahem* "hidden" packages?
<rqou>
like DI44?
<rqou>
don't support those?
<azonenberg_work>
Nope
<azonenberg_work>
Cant buy it = doesnt exist
<azonenberg_work>
DI44 is most likely bare die
<azonenberg_work>
You can always build a design for e.g. QFG32 and constrain to those pin numbers then run the bitfile on a bare die :p
<rqou>
yeah almost certainly
<rqou>
and obsolete packages like PC44?
<davidc___>
azonenberg_work: .... not just an xacto? :P
<azonenberg_work>
You can do that if its all you have, and i did use it to clean up the edges a bit
<azonenberg_work>
but milling is almost mandatory for inner layer edits
<azonenberg_work>
and if you have it, why not use it?
<azonenberg_work>
rqou: forget those too
<rqou>
they're still in the datasheet
<azonenberg_work>
yeah but if EOL
<azonenberg_work>
we dont support it
<rqou>
meh, it's not actually that much extra effort
<rqou>
i still have to transcribe the rest of the pin table
<davidc___>
azonenberg_work: yup. what RPM? usually you need to be crazy high to get any kind of a clean cut with a tiny endmill like that
<rqou>
ah i see siliconpr0n has a dump of valid part combinations
<azonenberg_work>
davidc___: dont know what rpm, the drill doesnt show a scale
<azonenberg_work>
but... high :p
<azonenberg_work>
and its actually a ball mill, not anendmill
<azonenberg_work>
Sounds like its in the tens of Krpm
<azonenberg_work>
but i cant be more specific
<rqou>
why do non-Pb-free parts still exist (at least in the ordering tables) for coolrunner-ii?
<rqou>
also the 256 has a ridiculous number of package options
<azonenberg_work>
Good question
<azonenberg_work>
maybe aerospace?
<rqou>
is dipping pb-free parts in leaded solder not sufficient?
<azonenberg_work>
That i dont know
<azonenberg_work>
for BGA, you'd have to reball
<azonenberg_work>
xilinx will not warranty a reballed part
<rqou>
do C and I variants have different timing for coolrunner-ii?
<azonenberg_work>
No
<azonenberg_work>
neither do Pb/non-Pb
<rqou>
some of the FPGAs do vary with C and I versions
<azonenberg_work>
they just are guaranteed to meet spec over a wider temp range
<rqou>
thanks silicon lottery :P
<rqou>
er, or maybe only different speed grades were available depending on choice of C or I
<rqou>
hmm coolrunner-ii does have that
<rqou>
I has fewer speed grades available
<azonenberg_work>
Yes that is more typical
<azonenberg_work>
a -2 is a -2
<azonenberg_work>
but you may not have a -3 in max temp
<azonenberg_work>
etc
<rqou>
although iirc s6 had the weird -1L grade or something
<rqou>
where it was binned for lower power?
ZipCPU|Laptop has joined ##openfpga
<rqou>
iirc s6 binning was particularly bad
<rqou>
azonenberg_work: so i'm refactoring xc2bit's error handling right now
<rqou>
how detailed do you expect errors to be?
<cyrozap>
rqou: Not sure if you're aware of Tabula, but I've found it to be incredibly useful for semi-automating PDF table extraction: http://tabula.technology/
<cyrozap>
It's really handy for dumping pin mappings to CSV, and then you can use the CSV to generate a KiCad symbol (or whatever else you need).
manderbrot has quit [Ping timeout: 260 seconds]
<openfpga-github>
[openfpga] rqou pushed 5 new commits to master: https://git.io/vH1mv
<openfpga-github>
openfpga/master 6cc0701 Robert Ou: xc2bit: Move process_jed into the bitstream module...
<openfpga-github>
openfpga/master a9611c2 Robert Ou: xc2bit: Add table of valid parts
<openfpga-github>
openfpga/master 72ec963 Robert Ou: xc2bit: Replace strings with enums for referring to parts
<azonenberg>
rqou: the more the merrier
<azonenberg>
:p
<azonenberg>
rqou: and 7 series has 2L binning too i think
<rqou>
Rust error handling is great btw
<azonenberg>
rqou: so i am going to be making some breaking changes to the netlist classes in the near future, jfyi
<rqou>
:(
<azonenberg>
i'll ensure they work with the C++ code but you may have to tweak a bit
<rqou>
yeah probably
<azonenberg>
in particular, Greenpak4Netlist and company are going to get renamed to sometrhing more generic
<azonenberg>
and moved into xbpar where they should have been all along
<azonenberg>
There's other refactoring coming but that's the main one i can think of that might break things
<azonenberg>
I won't be doing any restructuring of the data layout or anything
<azonenberg>
so a simple sed should fix anything that broke in your code
<rqou>
yeah, i don't actually use the Greenpak4* classes
<azonenberg>
oh ok then no problem
<azonenberg>
But yeah, as long as the version number is 0.1
<azonenberg>
you can expect the API/ABI to not be exactly stable :p
<azonenberg>
once i start adding gpak5 support, and your coolrunner stuff gets a bit more mature
<azonenberg>
i think we'll hit a stable setup pretty soon
<azonenberg>
but right now we dont really know what wont work yet
<azonenberg>
and a lot of major refactoring has to happen
<rqou>
so according to the rust versioning scheme, 0.<anything> isn't api stable
<azonenberg>
Yes
<rqou>
also, ABI stable is pretty impossible with the languages we're using
<rqou>
:P
<azonenberg>
I havent even reached a point where i'd want to be 0.2 yet
<azonenberg>
the 0.1 official release would likely be once i had full support for one chip
<azonenberg>
say the slg46620
fouric has joined ##openfpga
mfgmfg has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 258 seconds]
digshadow has joined ##openfpga
massi has joined ##openfpga
<openfpga-github>
[openfpga] rqou pushed 9 new commits to master: https://git.io/vH1sm
<openfpga-github>
openfpga/master 9ccd593 Robert Ou: xc2bit: Begin plumbing for 64-macrocell support
<openfpga-github>
openfpga/master 3f35cc5 Robert Ou: xc2bit: Add 64-macrocell ZIA encoding
<openfpga-github>
openfpga/master 845888c Robert Ou: xc2bit: Insert deliberately-incorrect ZIA data for 64 macrocell devices
<openfpga-github>
[openfpga] rqou opened issue #100: Need ZIA map for >32 macrocell devices https://git.io/vH1nE
<azonenberg>
also i emailed my contact at silego earlier today
<azonenberg>
i'm getting samples of the newest greenpak5 part, the one with the four 150 mA LDOs
<azonenberg>
rqou: they're not parallel-able per se, however they also make SKUs with two 300 or one 600 mA so presumably same die with internal parallelling
<rqou>
wtf what's the point of that?
<azonenberg>
maybe bondout change or maybe you just parallel on the pcb and set a bit in the bitstream... i havent looked into that
<azonenberg>
i'll look into it
<rqou>
i wonder how many datasheet typos you will find?
<azonenberg>
Quite a few, i imagine
<azonenberg>
lol
<azonenberg>
Anyway, i also asked for samples of one of the more general greenpak5 parts
<azonenberg>
as well as samples of the slg46620 from multiple wafers/fab runs to let me characterize process variation
<azonenberg>
They're working on that last bit, it cant go through the usual sampling process so may take a bit
<azonenberg>
So at this point, i need to design a bunch more boards
<azonenberg>
i have to do the board with the level shifters and stuff for talking to the gpak devkit at non-3.3V levels
<rqou>
i'm surprised how nice silego has been to you
<azonenberg>
i have to do a solderable breakout with a thermal and current sensor
<azonenberg>
that has a stqfn-20 footprint
<azonenberg>
And i already sent out the pmod-to-mmcx but that has another ~2 weeks at fab before it comes in
<azonenberg>
And they're being super helpful
<azonenberg>
"How many parts do you need for this effort, and we can also give you any necessary hardware?"
<azonenberg>
in general they are totally embracing the project
<azonenberg>
Which is one of the reasons i pushed my focus to their parts vs xilinx's
<azonenberg>
I don't want to just make a f/oss toolchain
<rqou>
i wonder if xilinx knows about us yet?
<azonenberg>
i want to set a precedent
<rqou>
:P
<azonenberg>
Good question
<rqou>
maybe since this is a cpld they don't really care
<rqou>
let's do a ultrascale+ next :P
<azonenberg>
Lol
<azonenberg>
now that would get their attention :p
<azonenberg>
but seriously i picked coolrunner because
<azonenberg>
modern-ish process but not so small as to be super hard to image/deprocess
<azonenberg>
and old enough (and from a basically-dead product line) that they'd be unlikely to care
<rqou>
oh yeah earlier i built a xc9500xl bitstream for lulz and had no idea what was happening
<rqou>
the comments really help :P
<azonenberg>
more to the point, they support all cplds in webpack free
<azonenberg>
so they cant argue i'm cutting into toolchain revenue
<rqou>
ah
<rqou>
even the 512 is available in the free version? :P
<azonenberg>
makes it at lot harder internally to make a case to sue, should there be any leg to stand on
<azonenberg>
Yes
<azonenberg>
all CPLDs
<azonenberg>
Supporting 9500xl would be nice in a perfect world
<azonenberg>
but coolrunner can do almost everything 9500 can except 5V tolerance
<azonenberg>
and greenpak can do that
<rqou>
oh yeah apparently 9500 and 9500xl are different
<rqou>
for some reason
<azonenberg>
the narrow niche for 9500xl is 5V tolerance at high speeds
<rqou>
what about xpla3? too slow?
<azonenberg>
when power isnt important
<azonenberg>
I dont remember the voltage range on xpla3
<rqou>
xpla3 seems like it should be easy, but meh
<azonenberg>
that might be easier to support than 9500
<rqou>
it's 3.3v core 5v tolerant
<azonenberg>
its architecutally similar to coolrunner
<azonenberg>
is the bitfile commented? did you check?
<rqou>
it is
<azonenberg>
But honestly i dont see it being worthwhile
<azonenberg>
We both have limited time
<rqou>
but i want to get par more working for xc2 first
<rqou>
xpla3 should be pretty easy to plug in after that if anybody cares
<azonenberg>
Yeah
<azonenberg>
but i mena
<azonenberg>
if you find yourself with more time to work on stuff
<azonenberg>
greenpak could always use another dev :p
<rqou>
7-series? :P
<azonenberg>
and thats a more contemporarily valuable target
<rqou>
look into writing a VPR-based PAR?
<azonenberg>
artix7 would be a very nice target down the road but its super complex by comparison
<rqou>
recruit somebody new to implement xpla3? :P
<azonenberg>
i'd actually consider spartan3a as a potential target for initial R&D
<rqou>
meh
<azonenberg>
it's cheap enouhg you dont care about killing it, and more importantly
<azonenberg>
it's a clear architectural ancestor of modern xilinx parts
<azonenberg>
doesn't have much hard ip
<azonenberg>
simple lut fabric
<azonenberg>
still sold, relatively inexpensive
<azonenberg>
I wouldn't consider it *useful* necessarily
<rqou>
apparently pointfree pointed out that somebody finished up the s6 bitstream RE
<rqou>
so why not that?
<azonenberg>
wait what?
<azonenberg>
s6 bitstream format is known now?
<azonenberg>
like, all of it?
<rqou>
i didn't look how "all" is all
<azonenberg>
that is huge, from our perspective... RE is the most time consuming and legally dubious part
<rqou>
but apparently a good amount of it
<azonenberg>
if we can focus on synthesis and par we could make much faster progress
<azonenberg>
But i don't want to get spread too thin
<azonenberg>
Let's focus on getting the CPLDs well supported and solid
<azonenberg>
before we even think of doing an FPGA
<azonenberg>
I'd rather have one working toolchain for one part than five half-baked ones
<rqou>
you don't like my "totally busted techmapping; returns the right answer 10% of the time" cpld toolchain? :P
<azonenberg>
Lol
<azonenberg>
let me put it this way, my current greenpak toolchain is actually usable, reliably, as long as you don't use the handful of device features i don't support
<azonenberg>
in which case it just complains you used a nonexistent keyword or something
<rqou>
yeah, i was amazed that it "just worked" on ppc
<azonenberg>
or errors out during par complaining about an invalid configuration
<rqou>
on a machine that probably predates silego existing :P
<azonenberg>
lol
<azonenberg>
If you ever find a case of it producing a wrong result
<azonenberg>
i.e. bitstream is not logically equivalent to HDL
<azonenberg>
that is a critical bug
<rqou>
i expected a weird endianness issue to exist :P
<azonenberg>
the bitstream is a bool[]
<rqou>
yosys-abc might actually have one; i didn't test
<azonenberg>
there's no endianness to worry about
<azonenberg>
Next highest priority: failing to PAR a design that should fit in the device
<rqou>
oh one observation from when i was working on xc2par
<azonenberg>
Lowest priority: HDL cannot express a feature the silicon has because i never implemented it
<rqou>
there's no way to tell the par "these nodes need to move together"
<azonenberg>
Correct
<azonenberg>
That would be a nice feature to add
<rqou>
it kept trying to move components of the macrocell and then wondering "why can't i connect these?"
<azonenberg>
right now for example a vref and acmp in greenpak
<azonenberg>
have one edge between them
<azonenberg>
So it will detect the design is unroutable if you have one acmp going to a different vref
<azonenberg>
but it doesnt "understand" this
<azonenberg>
so it just bounces them around in the annealer until the two end up together
<azonenberg>
at which point it's happy :p
<azonenberg>
Doing this in larger gate count devices probably wont work
<azonenberg>
So being able to constrain nodes to pairs/groups somehow would be nice
<azonenberg>
Make a ticket we can use to discuss/comment on this
<rqou>
yeah, which is why it only returned the right answer when the rust hashtable nondeterminism made them do so :P
<azonenberg>
welll
<azonenberg>
in greenpak, at least
<azonenberg>
it will eventually converge to the right answer
<azonenberg>
it just takes a while to do so
<azonenberg>
if you're not converging, something else may be wrong
<rqou>
i think it just exhausts the iteration count
<azonenberg>
Could be that
<rqou>
because the scoring function is also garbage
<azonenberg>
That would be an issue
<rqou>
so it doesn't realize it's improving
<azonenberg>
lol
<azonenberg>
i need to redo the scoring function for greenpak once i add in-par timing
<rqou>
i just wrote the most trivial scoring function that returns an answer at all
<azonenberg>
have to figure out how to balance timing failures against unroutability etc
<azonenberg>
But hey, active development is a good step :)
<rqou>
yeah, i might work on adding 128 support next. not for the sake of having 128 support but for finding "needs refactor" points
<azonenberg>
That's kinda why i wanted greenpak5 samples
<azonenberg>
not because i needed gp5, but because it's architectuarally different enough from 4 that i'll find those issues
<rqou>
i also need to at some point manually black-box out the zia encoding for the 256+ parts
<azonenberg>
We may also want to consider a multilevel dir structure in src/
<azonenberg>
rather than just having src/$THING
<azonenberg>
have src/greenpak/$THING
<azonenberg>
src/coolrunner/$THING
<azonenberg>
etc
<rqou>
meh, there aren't that many things yet
<azonenberg>
i was about to say
<azonenberg>
let's hold off until that becomes an issue
<rqou>
i also need to write a lot more tests
<rqou>
so do you :P
<rqou>
the tests also need to be less hard to run
<azonenberg>
So, the HIL tests are fully scripted and run on the devkit
<azonenberg>
i just dont have enough of them yet
<rqou>
but a) i only have one and b) i don't even have all the different parts
<azonenberg>
i also dont have enough devkits :p
<azonenberg>
And that
<azonenberg>
My eventual goal is to get a build farm with one devkit per supported chip
<azonenberg>
plus another devkit for myself to test on
<rqou>
you should just ask silego to send you some
<rqou>
anyways, i was thinking something like unit tests rather than HIL tests
<azonenberg>
I asked for another devkit with the latest batch of samples and stuff
<azonenberg>
So what i want to do at some point in the not too distant future
<rqou>
you need a "framework" :P
<azonenberg>
is create some simple par test cases that constrain various things to fixed locations
<rqou>
(in case i didn't make it clear in the past, i hate "frameworks")
<azonenberg>
then verify bitstream match to ground-truthed files
<rqou>
rust testing is great because the framework is very "get out of your way"
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vH1CY
<openfpga-github>
openfpga/master 567ff4a Andrew Zonenberg: Merge branch 'master' of github.com:azonenberg/openfpga
<openfpga-github>
openfpga/master 9068590 Andrew Zonenberg: Updated README
<azonenberg>
Also, its 1am and i have work tomorrow
<azonenberg>
back later ;p
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
egg|work|egg has joined ##openfpga
<egg|work|egg>
rqou: random question: when unavailable, do you think zh-Hans-TW should fall back to zh-Hant-TW or zh-Hans-CN?
pie_ has quit [Ping timeout: 240 seconds]
ZipCPU|Laptop has quit [Quit: Transitioning to a lower energy state]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
seu has quit [Read error: Connection reset by peer]
seu has joined ##openfpga
m_t has joined ##openfpga
X-Scale has joined ##openfpga
massi has quit [Ping timeout: 260 seconds]
massi has joined ##openfpga
massi has quit [Ping timeout: 240 seconds]
massi has joined ##openfpga
nicdev has quit [Remote host closed the connection]
nicdev has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work>
rqou: Is there a rust compiler in the debian repos yet?
<azonenberg_work>
(For the upcoming version)
<azonenberg_work>
also i reproduced your gp4par hang
<azonenberg_work>
on my work laptop
<azonenberg_work>
it doesn't hang for all bitfiles so i dont think its related to timing analysis per se
<azonenberg_work>
the missing timing data file i mean
<azonenberg_work>
i think its a legitimate bug in the STA algorithm
<openfpga-github>
[openfpga] azonenberg commented on issue #94: Seems specific to the Blinky test and happens even if you have the timing data file. Investigating... https://git.io/vHM3p
<azonenberg_work>
it only supports a subset of the 46620 right now
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHMZ9
<openfpga-github>
openfpga/master 48edca9 Andrew Zonenberg: BUGFIX: Static timing analysis no longer goes into infinite recursion when we have a combinatorial loop. Report combinatorial loops as PAR warnings. Skip timing analysis if we have no timing data file. Reduced warning spam when timing data is incomplete from one message per path to one message total
<openfpga-github>
[openfpga] azonenberg commented on issue #94: Fixed in 48edca9 https://git.io/vHMZH
amclain has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
massi has quit [Remote host closed the connection]
<rqou>
egg|work|egg: zh-Hans-TW is completely useless (geopolitically inappropriate) and should not exist
<rqou>
there should only be zh-Hant-TW
<rqou>
in general I wouldn't enable any fallbacks at all
<rqou>
er, zh-Hant-<Chinese diaspora countries> maaaybe could fall back to zh-Hans-TW
<rqou>
and zh-Hans-<Chinese diaspora countries> can fall back to zh-Hans-CN
<rqou>
azonenberg_work: Rust does not recommend using compilers packaged in distribution repos because there's a new version every six weeks
<rqou>
azonenberg: the standard way to install Rust is to use the rustup script
<rqou>
you can have stable/beta/nightly all installed simultaneously, and the script doesn't need root
<rqou>
(rqou) azonenberg_work: Rust does not recommend using compilers packaged in distribution repos because there's a new version every six weeks
<rqou>
(rqou) azonenberg: the standard way to install Rust is to use the rustup script
<rqou>
(rqou) you can have stable/beta/nightly all installed simultaneously, and the script doesn't need root
<azonenberg_work>
So what you're saying is
<azonenberg_work>
they do not have a stable release? :P
<azonenberg_work>
"stable" defined as "no known bugs, and won't change for a year or so"
<azonenberg_work>
Will make reproducibility more of a pain in the butt
<azonenberg_work>
if compiling the same code a month apart can produce different results
<rqou>
you can still install old stable versions
<rqou>
new features get added, but they try not to break any existing code
<azonenberg_work>
yeah but that doesnt mean hash-identical binaries
<azonenberg_work>
Which is what you need for reproduicibility
<rqou>
but overall Rust is on a train model
<azonenberg_work>
?
<jn__>
linux is, too, but it has long-term support branches
<rqou>
everything that is ready when the release ships is in the release
<rqou>
everything that is late isn't and is in a future release
<rqou>
every release cycle, nightly becomes beta and beta becomes stable
<rqou>
Linux is also kinda on a train, yes
<jn__>
right, the details are a little different
<rqou>
I believe Rust is the fastest release cycle I've seen for a programming language
<azonenberg_work>
Which is nice for R&D but not so good for a product-type thing
<jn__>
what's the release cycle of V8 or Spidermonkey? ;)
<azonenberg_work>
that is actually a major factor to consider in antikernel down the road
<azonenberg_work>
if i want to use rust for userland apps
<rqou>
you can still use and old stable
<rqou>
there's just no official LTS branch
<azonenberg_work>
Yeah thats what i meant
<azonenberg_work>
something that will still get bug fixes etc
<azonenberg_work>
but otherwise not change
<rqou>
SpiderMonkey is also on a 6-week train
<rqou>
I don't know about V8
<azonenberg_work>
I'm holding off on doing much with rust until they have risc-v support and, ideally, some formal verification tools
<rqou>
apparently JavaScript the spec has switched to a yearly release cycle
<azonenberg_work>
it may take more time but i'd trust formally verified C above unverified rust
<rqou>
oh I would love Rust formal
<rqou>
I've never seen a C formal tool that was actually easy to use
<azonenberg_work>
also did you test my bug fix?
<azonenberg_work>
i havent tried any
<rqou>
I haven't yet, I just got up
<azonenberg_work>
yosys-smtbmc is my main experience with formal stuff
<azonenberg_work>
so the tl;dr is that i was stack overflowing any time i saw a combinatorial loop
<azonenberg_work>
looking for an io buffer at the other end
<rqou>
from the talks (haven't tried it yet) I believe yosys-smtbmc is one of the easiest formal tools
<azonenberg_work>
Right now i give false-positive warnings on any stateful logic because my analyzer doesn't understand that flipflops are not combinatorial blocks
<azonenberg_work>
so it tries to trace right through them
<azonenberg_work>
and multicycle paths with state it thinks are loops
<azonenberg_work>
But it doesn't segfault anymore which is progress
<azonenberg_work>
And it gives correct results for all pin-to-pin paths without stateful elements in them
<rqou>
why does blinky have a combinatorial loop?
pie_ has quit [Changing host]
pie_ has joined ##openfpga
eduardo_ has quit [Quit: Ex-Chat]
<azonenberg_work>
it doesnt
<azonenberg_work>
it has a stateful feedback loop in a fabric-based (vs hard IP) counter
<rqou>
ah ok
<azonenberg_work>
but my timing analyzer thinks everything is combinatorial right now :p
<azonenberg_work>
it tries to trace D to Q combinatorially
<rqou>
anyways, no crash
<rqou>
but i haven't downloaded the data file, so no data either
<azonenberg_work>
Like i said it isnt finished :p
<azonenberg_work>
Sooo
<azonenberg_work>
if you don't haev the data file the entire code path that crashed is bypassed
<azonenberg_work>
So that doesnt confirm fixed
<rqou>
last time it wasn't bypassed
<azonenberg_work>
It is now
<azonenberg_work>
:p
<azonenberg_work>
the alternative was to spew warnings about missing timing data constantly if you didnt have the file
<azonenberg_work>
now i just warn once and skip the whole analysis
<rqou>
also wtf is ../../.. ?
<azonenberg_work>
where?
<rqou>
Loading timing data file "../../../timing.json"
<azonenberg_work>
That's the relative path from the dir the test runs in to the build/ directory
<rqou>
wtf
<azonenberg_work>
i havent bothered to do a proper path resolution mechanism yet
<azonenberg_work>
this is very much a WIP ;p
<azonenberg_work>
i don't have any process set up for actually installing the timing data file in a sane location yet
<azonenberg_work>
or anything
<azonenberg_work>
for that matter i havent even finished writing the code to generate the timing file :P
<rqou>
ok, with the data file it spews several pages of warnings but completes
<azonenberg_work>
the one i have now is specific to a single die at whatever the ambient temp on my desk was two nights ago
<azonenberg_work>
and covers a subset of the supported device features
<azonenberg_work>
yeah it's warning on every stateful loop
<azonenberg_work>
This is intentional, i want to make it abundantly clear that the timing analyzer isnt done and shouldnt be relied on
<azonenberg_work>
In case the 0.x version number didn't make it clear enough lol
mifune has joined ##openfpga
m_w has joined ##openfpga
<rqou>
hey azonenberg_work: why is json-c not vendor-ed?
<rqou>
with the hidapi change that becomes the only external dependency, which is a bit silly
<rqou>
also you should test the no-udev rewrite
<azonenberg_work>
rqou: i generally prefer using distro binaries when possible
<azonenberg_work>
if you're shipping a debian package etc you want to take advantages of updates to those libraries
<azonenberg_work>
vendoring it and dynamically linking is stupid
<rqou>
unless it's full of crap like hidapi? :P
<azonenberg_work>
vendoring and statically linking means maintenance is on you
<azonenberg_work>
You didn't vendor hidapi
<azonenberg_work>
You forked it
<azonenberg_work>
and vendored the fork
<azonenberg_work>
that's a difference :p
<azonenberg_work>
and i'll test when i get home
<azonenberg_work>
At work now
<rqou>
hmm azonenberg_work: we need to sort out out debug/release/etc. builds
<rqou>
they're kinda a mess right now
<rqou>
(AKA "it just isn't possible to build a release build")
<azonenberg_work>
Make a ticket :)
<azonenberg_work>
There's a reason this is still version 0.1
<azonenberg_work>
that was all on the "work on once i have full-ish support for at least one target device" list
<openfpga-github>
[openfpga] rqou opened issue #101: Correctly sort out debug/release/etc. build variants https://git.io/vHMwf
<oeuf>
rqou: well, if somebody asks me to serve zh-Hans-TW, I have to fall back to *something*, so that's going to be either zh-Hant-TW or zh-Hans-CN
<rqou>
hmm i would pick zh-Hant-TW in that case
<rqou>
also, wtf are you doing?
* oeuf
works in YouTube i18n :-p
<rqou>
ooooh shit
<rqou>
now you really need to watch the geopolitical minefields :P
<oeuf>
yeah I mean I'm getting crap data from buggy clients as well as well-formed things like that, so :-p
<oeuf>
following the CLDR parent relation would mean falling back to zh-Hans (and make my code slightly simpler), but apparently the current (and correct?) behaviour is that zh-Hans-TW falls back to zh-TW
<rqou>
taiwan and the mainland have differences in preferred vocabulary/slang/etc
<rqou>
*certain* people might have very strong opinions that taiwanese chinese should be different from "mainland" chinese
<oeuf>
rqou: aha, and I gather people requesting zh-Hans-TW are more likely to know Hant than to want Hans-CN?
<azonenberg_work>
cr1901_modern: interesting
<rqou>
so simplified chinese is (essentially) a PRC invention
<azonenberg_work>
So, formal tools in rust are in the works
<rqou>
taiwan still uses traditional characters everywhere
<oeuf>
rqou: yeah, I'm aware; I don't know who even sends us that language code :-p
<azonenberg_work>
I give it another 6-12 months before it will be to the point i want to try using it
<rqou>
which is why i said that zh-Hans-TW is just broken to start
<oeuf>
makes sense
<cr1901_modern>
azonenberg_work: riscv doesn't seem interested in an llvm port atm (and this is prob my biggest gripe w/ Rust; adding a port is annoying)
<rqou>
for maximum brokenness, you now get to decide what zh-Hant-US should resolve to :P
<rqou>
there is no good answer in this case
<oeuf>
oh that is clear, it goes to parent :-p
<rqou>
which is?
<oeuf>
zh-Hant-Us -> zh-Hant -> zh -> root
<oeuf>
CLDR :-p
<rqou>
but what is zh-Hant?
<rqou>
zh-Hant-TW and zh-Hant-HK would (should?) be different
<oeuf>
that then reexpands to zh-Hant-TW because reasons I think?
<cr1901_modern>
azonenberg_work: Also, this may be hard to believe, but I've found the Rust build process less well-behaved than gcc. It _just_ doesn't want to compile on my living room Ubuntu LTS machine
<rqou>
is it mandarin? formal cantonese? colloquial/spoken cantonese?
<rqou>
these are different :P
<oeuf>
rqou: I mean, if you send broken things it's kinda best-effort :-p
<oeuf>
we get zh-CH too
<rqou>
the reason zh-Hant-US is so much fun is because what you optimally want depends on which diaspora group the user belongs to
<rqou>
people from taiwan? or people from guangzhou?
<oeuf>
yeah but I'm not getting that because people mean it, generally :-p
<oeuf>
rqou: zh-Hans-TW might even just be a bug or a pile of bugs; I get some really stupid codes in that field
<rqou>
CJKV is full of bugs and geopolitical minefields
<oeuf>
like, I get random Unicode in the language code sometimes
<rqou>
this doesn't work for google, but for a small project with finite resources, i would have three chinese localizations:
<oeuf>
rqou: and yeah, YouTube does have zh for HK, TW, and CN
<rqou>
"country-neutral shibboleth-avoiding" mandarin, traditional characters
<rqou>
and "reasonably-formal" cantonese, traditional characters
<rqou>
so what happens in singapore?
<rqou>
you get CN?
<oeuf>
dunno
<oeuf>
rqou: it's not location-based
<oeuf>
you get the one you ask for, of the three
<oeuf>
it's just that sometimes weird applications send weird language codes
<rqou>
wait so zh-Hant-SG will give you TW and zh-Hans-SG will give you CN?
<rqou>
that seems weird
<oeuf>
yup, by parenting til supported, you get that I think
<rqou>
a fun problem is that there are two axes here: simplified vs traditional characters, and cantonese vs mandarin (and other dialects too)
<oeuf>
neither will give you zh-Hant-HK which might be an issue
<rqou>
that might be ok for SG
<rqou>
but if somebody actually in e.g. the US sends zh-Hant-US, they _might_ want zh-Hant-HK
<rqou>
but they _might_ also want zh-Hant-TW
<oeuf>
rqou: but then YouTube doesn't have cantonese as a site language
<rqou>
you're just screwed in that case
<whitequark>
cr1901_modern: ever tried to cross-compile gcc+glibc manually?
<rqou>
ah, so it goes for the "could be valid as either mandarin or formal cantonese" option
<whitequark>
if you did, now do it with musl :p
<oeuf>
rqou: maybe? :-p
* oeuf
doesn't know
* oeuf
food
<rqou>
that's pretty common
oeuf is now known as egg|nomz|egg
<rqou>
CJKV is a huge mess
<rqou>
why doesn't europe have this problem?
<rqou>
egg|nomz|egg: one shibboleth to try is to look up the translation for "computer"
<cr1901_modern>
whitequark: Yes I have compiled gcc/glibc manually, but I followed insns, so it doesn't count
<whitequark>
no, cross-compile.
<cr1901_modern>
Yes, it was a cross compile
<rqou>
egg|nomz|egg: if computer is "计算机" this is CN
<cr1901_modern>
I followed insns* from someone who did it before. I didn't have any problems.
<rqou>
if computer is "电脑" it's either TW or HK
<egg|nomz|egg>
rqou: well that's kind of a separate issue from CJKV, it's the zh macrolanguage mess :-p
<rqou>
er, i've actually heard "计算机" in cantonese as well
<egg|nomz|egg>
also I like that you remember the V
<cr1901_modern>
whitequark: As for musl, dalias found a way to avoid having to compile gcc twice by using an internal Makefile target in the gcc tree, so I think it's actually *easier* w/ musl now
<rqou>
so "计算机" -> CN or HK
<rqou>
yeah, zh is a giant mess
<rqou>
hmm according to the dictionary i'm using "计算机" is computer in CN but calculator (e.g. those four function things) in TW
<rqou>
for extra fun
<rqou>
calculator in CN would be "计算器" instead
<rqou>
so yeah, this is why CN and TW need to be different localizations
<egg|nomz|egg>
:D
<egg|nomz|egg>
i18n is fun \o/ \o/ \o/
<egg|nomz|egg>
anyway, nomz
<rqou>
HK often gets the shafted though
<rqou>
not as bad as macau though :P
<whitequark>
cr1901_modern: yeah. it's a tradeoff. a process that works most of the time but covers everything vs the process that works always but if your use case is not the default you're hosed unless someone would chew the instructions for you
<rqou>
i18n really is "fun"
mifune has quit [Ping timeout: 240 seconds]
<azonenberg_work>
rqou: everything is CP1252 right? :P
<azonenberg_work>
Problem solved :p
<rqou>
it is in vhdl
<rqou>
kinda
<rqou>
vhdl is latin-1 without the windows extensions
<cr1901_modern>
whitequark: This is probably a case of "Rust is newer and they haven't sorted out all the fail cases yet". My Rust build fails w/ cannot find "panic_#hash" from the git tree, when the git HEAD is pointing to 1.18, and an external llvm whose git HEAD pointed to the tip of 3.9 branch
<whitequark>
cr1901_modern: that seems really odd, have you reported it?
<rqou>
i don't have any data on character encoding problems among cjkv languages
<rqou>
IME chinese works ok and tends to be utf-8 nowadays
<rqou>
unlike japan which might still have shift-jis holdouts?
<cr1901_modern>
whitequark: No, but I should. Just been preoccupied. Steve suggested I ask in #rust-internals as well.
* cr1901_modern
is eating and then will go ahead and do that
<rqou>
people didn't seem to like me using "i pirate a lot of weeb material" as a justification of why shitting raw bytes into filenames should still be allowed :P
<rqou>
with many round-trips between shift-jis, cp1252, and utf-8 involved
<whitequark>
TIL shift-jis includes cyrillic
<rqou>
yeah, the chinese legacy codepages do too
<rqou>
i think the chinese legacy codepages have kana too
<rqou>
yeah, gbk has latin, greek, cyrillic, and kana
<rqou>
for extra fun breaking software, encode japanese into gbk or chinese into shift-jis :P :P
<rqou>
btw, the latter has almost certainly happened at least once
<rqou>
consider: japanese academics discussing classical chinese literature
<rqou>
have fun with your language/charset detection :P
<rqou>
"Pali written with Thai alphabet" is also a really fun i18n stress test :P
<rqou>
there have legitimately been bugs in libthai related to this
<rqou>
huh TIL shanghainese has more speakers than cantonese (80 million vs 60 million)
<rqou>
egg|nomz|egg: so that's another thing to add to the zh mess
<rqou>
there's also the persistent "why is Zhuang still not in unicode" political battle
<whitequark>
wow, 16m people
<rqou>
i can't be bothered to dig it up, but i remember reading an email sent to the unicode list where somebody asked "why do we have a f*ckton of emoji but not Zhuang?"
<rqou>
and the answer was essentially "because NTT/SoftBank/KDDI have a lot of time/money, and the PRC government doesn't/doesn't want to allocate it this way"
<rqou>
on a slightly more on-topic note, i noticed the other day that yosys is not easily localizable
<rqou>
*hint* *hint* at a way you can contribute egg|nomz|egg :P :P
* egg|nomz|egg
hides under a PCB
<egg|nomz|egg>
rqou: you don't have anything that needs numerical analysis or something fun like that :-p
<egg|nomz|egg>
s/:-p/? :-p/
<egg|nomz|egg>
anyway, I should stop offtopicing this channel into a copy of #kspacademia
<egg|nomz|egg>
rqou: how's the grammar going?
<rqou>
the vhdl grammar was working a while ago
<rqou>
but I've been stalled out on semantic analysis
<rqou>
I'm taking a break to work on Coolrunner-II tooling
<rqou>
vhdl generics are absurdly powerful
<rqou>
but also gimped because it doesn't have type inferencing
<egg|nomz|egg>
bit like Ada generics from the sounds of it :-p
<egg|nomz|egg>
you need to explicitly instantiate, right?
<rqou>
right, but it effectively has type-level integers
<rqou>
fortunately nothing can change "kind" by instantiating generics
<rqou>
but it took a while for me to understand what was actually possible
<egg|nomz|egg>
rqou: you don't have explicit specialization or something like that though, so it's not Turing complete (in Ada at least)
<egg|nomz|egg>
s/ explicit//
* egg|nomz|egg
inserts random words
<egg|nomz|egg>
rqou: what do you mean change kind?
<rqou>
e.g. a signal can't magically turn into a package
<rqou>
it'll always be a signal
<rqou>
yeah, it's definitely not turing complete
<rqou>
still hard to deal with
Hootch has quit [Quit: Leaving]
DocScrutinizer05 has quit [Ping timeout: 246 seconds]
<openfpga-github>
[openfpga] azonenberg opened issue #102: Ethernet test fails to route (using 110% eastbound cross-connections) https://git.io/vHDIH
<lain>
110% guarantee or your money back
<openfpga-github>
[openfpga] azonenberg commented on issue #102: Reports congestion score of 0 which is obviously wrong, then doesn't try to optimize further https://git.io/vHDIh
DocScrutinizer05 has joined ##openfpga
m_t has quit [Quit: Leaving]
pie_ has quit [Ping timeout: 240 seconds]
<cr1901_modern>
whitequark: Asked on #rust-internals. So it turns out I was compiling Rust wrong (TM) so my complaints are invalid for the time being
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]