azonenberg_work has quit [Ping timeout: 240 seconds]
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 260 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
<gruetzkopf>
today in cursed communications: currently dumping a ti cc2351 with a local cc-debugger which is connected via spice-usb to a windows vm running around'100km away behind my home dsl
<whitequark>
nice
<whitequark>
oh, do you still need glasgow debugger for it?
<gruetzkopf>
i haven't yet managed to get the ccdebugger to attach in debug mode..
<whitequark>
oh hm
<whitequark>
so, any cc2531 board works?
<gruetzkopf>
i'll be documenting the usb protocol though
<gruetzkopf>
yeah, the cheapest usb sticks you can find are identical to the CC2531 eval thing
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 268 seconds]
Hoernchen_ has joined ##openfpga
azonenberg_work has joined ##openfpga
Hoernchen_ has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
mumptai_ has joined ##openfpga
Bird|ghosted has joined ##openfpga
mumptai has quit [Ping timeout: 240 seconds]
Bird|otherbox has quit [Ping timeout: 268 seconds]
mumptai_ has quit [Read error: Connection reset by peer]
mumptai_ has joined ##openfpga
Hoernchen has quit [Ping timeout: 260 seconds]
Hoernchen has joined ##openfpga
Jybz has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
indy has quit [Ping timeout: 240 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
jn__ has quit [Ping timeout: 252 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Bike has joined ##openfpga
Hoernchen has joined ##openfpga
unkraut has quit [Quit: leaving]
ym has quit [Remote host closed the connection]
ym has joined ##openfpga
ovf has quit []
ovf has joined ##openfpga
esden has quit []
esden has joined ##openfpga
mumptai_ has quit [Read error: Connection reset by peer]
mumptai_ has joined ##openfpga
<mwk>
daveshah: to follow up on the json issue yesterday: Claire agreed with just always emitting bitstrings in yosys, but convinced me to add a -compat-int option to restore the old behavior in case some old parsers are relying on it (though they shouldn't)
<mwk>
now... our other json emitter (in nextpnr) still emits ints
<daveshah>
Might be worth patching that too
<mwk>
it cannot trigger the bug because it always emits values in [-2**31, 2**31)
<mwk>
but maybe we should patch that anyway for consistency?
<daveshah>
Yup
<daveshah>
As there is a risk of silent behaviour, I think a warning to update Yosys if the nextpnr JSON parser sees an int might be sensible?
<daveshah>
*silent misbehaviour
<mwk>
that'd cause a lot of annoyance in benign cases
<mwk>
since people don't always update yosys and nextpnr in lockstep
<mwk>
would be better if we only did it for cases that actually break stuff
<mwk>
we could detect INT_MIN values in the parse tree, but that's a rather crap solution
<mwk>
or we could actually fix the issue in json11, but it's a bit tricky
<mwk>
because both json11 and the way we use it are wrong
<mwk>
first, json11 makes a JsonInt node instead of JsonDouble
<mwk>
that can be fixed, but then we have a JsonDouble node and call int_value() on it
<mwk>
and run into the exact same issue again
marble has joined ##openfpga
<marble>
Hello
<mwk>
the json11 api doesn't seem to allow you to ask whether a node is JsonInt or JsonDouble
<mwk>
so we'd have to call number_value() to get the double value and see if it's in a sane range...
<mwk>
(*and* fix the underlying issue in the first place)
edmoore has quit []
<daveshah>
I think let's leave that then. It will be at least a month or two before anything using LUT5s is upstream (hypothetically someone could be using nextpnr-generic for LUT5+ arches, but that is unlikely)
edmoore has joined ##openfpga
Zorix has quit [Quit: Leaving]
<mwk>
I'm also investigating the idea of checking for an INT_MIN value in json11 output, but it turns out...
<mwk>
the atoi manual kind of seems to imply it should return LONG_MAX instead (implied by reference to strtol behavior)
<mwk>
cplusplus.com says it's actually UB
Zorix has joined ##openfpga
Hoernchen has quit [Ping timeout: 268 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
jn__ has joined ##openfpga
unkraut has joined ##openfpga
<TD-Linux>
tnt, I got an email and it says feb 20. so I guess that's for new orders and yours might actually appear
swetland has quit []
swetland has joined ##openfpga
eddyb[legacy] has quit []
eddyb[legacy] has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
<mwk>
daveshah: I did end up writing validation after all
<mwk>
have a PR :)
<daveshah>
Thanks, merged
<marble>
I'm currently learning to use openocd. If I want to use the B interface on my FT2232, I have to put `ftdi_channel 1` into the config, right?
<marble>
* ftdi_channel 2
freemint has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
elms has quit []
elms has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Maya-sama has joined ##openfpga
hackkitten has quit [Ping timeout: 246 seconds]
Maya-sama is now known as Miyu
freemint has quit [Ping timeout: 260 seconds]
Miyu is now known as hackkitten
Hoernchen has quit [Ping timeout: 265 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
<kc8apf>
json11 doesn't have a bug after all. I ran a test case verifying parsing behavior of JSON numbers from std::numeric_limits<int>::min() to std::numeric_limits<int>::max() by checking against Json::int_value(). It returns correct values for all *signed* 32-bit integers regardless of whether it internally uses JsonInt or JsonDouble to store them.
<kc8apf>
yosys is ok in emitting a 32-bit *unsigned* int. The only but is nextpnr assuming the JSON numbers will be *signed* and calling int_value().
<kc8apf>
s/only but/only bug/
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 260 seconds]
Hoernchen has joined ##openfpga
<hackerfoo>
Which is what I said, a cast from double to int. I don't see what it has to do with atoi.
<hackerfoo>
I'd expect it to use something like strtol, or that json11 rolled their own, instead of using atoi.
<hackerfoo>
*strod
<hackerfoo>
Argh, strtod
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 240 seconds]
Hoernchen has joined ##openfpga
<kc8apf>
hackerfoo: they opted to use std::numeric_limits<int>::digits10 to ensure that atoi() is only called with in-range values. That is conservative since digits10 is the longest string of base-10 digits that is guaranteed to convert to/from int without change. In practice, it doesn't matter because it's only being used to decide whether to internally store JSON numbers as JsonInt or JsonDouble.
<kc8apf>
Both of those include an int_value() method and the double being cast to an int works fine up to 53-bits.
<kc8apf>
so there's a tiny performance penalty by doing a float->int conversion for JSON numbers longer than 9 digits but it still provides correct results
<kc8apf>
It'd be easy to add an unsigned_int_value() method to json11 so it works the way mwk wants but that isn't a bug.
<hackerfoo>
For int64_t, right? I can't remember if int is 32 bits on a 64 bit machine.
<kc8apf>
depends on the OS
<kc8apf>
most systems are LP64 now so int remains 32-bit
<hackerfoo>
So `int x = n.int_value()` would overflow for UINT_MAX, while not being obviously wrong.
<kc8apf>
if n is a json11::Json, yes
<hackerfoo>
Even though it's not a bug in json11.
<kc8apf>
correct
<kc8apf>
in general, that will be true for all JSON parsers unless they go out of their way to provide you an error indicating the overflow
<hackerfoo>
Furthermore, it's only a bug on some OSes. Fun. I think it should at least be called `integer_value()`
<kc8apf>
if it were integer_value(), it'd be more confusing. int_value() tells you exactly what it does: provide the JSON number as a native 'int'
<hackerfoo>
Not an int64_t? Then it needs a way to signal overflow.
<hackerfoo>
It seems like JSON is badly specified for numbers anyway, which is why I mentioned using a schema.
<kc8apf>
JSON is horribly bad at numbers.
<kc8apf>
they are effectively arbitrary precision floats
<kc8apf>
it's up to the implementation to decide what to do with that.
<kc8apf>
for performance, most assume double and opportunistically use int
<hackerfoo>
I made it when I was working on the WSDL specification for fixed point numbers.
<kc8apf>
neat
<kc8apf>
I'm much more inclined to use CBOR when I care about exact binary representations and data type sizes
<kc8apf>
Still plenty of gotchas such as signed and unsigned integers are encoded differently (good) which both use a scheme that encodes minimum number of bytes depending on encoded value. Still up to the application to enforce data type size limits.
<kc8apf>
it has an encoding for raw byte sequences though so you escape the mess of using base64 needed for JSON
knielsen has quit [Remote host closed the connection]
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
Hoernchen has quit [Ping timeout: 248 seconds]
Hoernchen has joined ##openfpga
knielsen has joined ##openfpga
freemint has joined ##openfpga
Hoernchen has quit [Ping timeout: 268 seconds]
Hoernchen has joined ##openfpga
indy has joined ##openfpga
Hoernchen has quit [Ping timeout: 256 seconds]
Hoernchen has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]