<cyrozap>
It's not finished yet, but it can already run simple programs.
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<shapr>
wow
<kc8apf>
Heh. That's fantastic
jeanthom has quit [Ping timeout: 246 seconds]
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined ##openfpga
<omnitechnomancer>
Now you are closer to running linux on an 8051 :D
Richard_Simmons has quit [Ping timeout: 264 seconds]
Bob_Dole has joined ##openfpga
<whitequark>
azonenberg: are you aware that your implementation of $display for yosys is wrong?
<whitequark>
granted, that was in 2015, so you probably no longer remember
<azonenberg>
I dont recall having ever implemented it
<azonenberg>
i recall making a feature request to do so
<azonenberg>
but i thought claire actually implemented it
<azonenberg>
What about it is wrong?
<whitequark>
you implemented it according to git blame
<whitequark>
well, it doesn't follow the verilog spec (and claire's additions made it even more noncompliant)
<whitequark>
the thing is that width/padding in veirlog %-format specifiers don't work like in C
<whitequark>
%d has enough width (and is padded with spaces) for the entire value, %0d *disables* the padding
<azonenberg>
oh, ok i guess i forgot. well if someone wants to fix it, go ahead
<azonenberg>
i dont think i had a copy of the LRM handy
<whitequark>
:/
<whitequark>
i don't *want* to fix it but i'll probably *have* to
<whitequark>
the worst thing is that LRM doesn't even say what %10d does
<azonenberg>
Yay undefined behavior
jeanthom has joined ##openfpga
<whitequark>
okay, they specified that part in 1800-2009
<daveshah>
Oops, I've actually relied on the Yosys broken behaviour as well
<daveshah>
Because Lattice use C literals in strings for many parameters these days, the Nexus support needs $sformatf to interoperate with Radiant
<whitequark>
:/
<daveshah>
Luckily its all in tree, so if you do fix it then I can fix the Nexus stuff in the PR too
<whitequark>
mwk: here? i'd like to propose some improvements here
<whitequark>
but it's kind of a largeish refactor
<whitequark>
basically the idea is to normalize all this... stuff... to a C-like format string (I can't believe saying that the legacy C format would be a major improvement here, but it is), and then map it to/from Verilog at the boundary
<whitequark>
this way, CXXRTL could consume, and nMigen could produce, a format that is actually sane and well-specified
<whitequark>
and presumably gHDL might join at some point
<daveshah>
Hmm, I'm not sure if C-like is the best description of the IL you want here
<whitequark>
well
<daveshah>
Because presumably it would be based on arbitrary precision values
<whitequark>
i want: explicit radix (always), explicit signedness (always; I'm not sure if Verilog even supports signed values there?), explicit padding width and character (always)
<daveshah>
That seems very reasonable
<whitequark>
so it'd read "%h" in Verilog and turn it into something like "%010hu" internally
<whitequark>
that's one half, which I expect to be less contentious
<whitequark>
the other half is actually encoding it in the cell
<whitequark>
this is... aggravating
<daveshah>
Seems like the convention is using %d with a signed value gets you a signed print
<daveshah>
Unclear if that is actually specified behaviour
<whitequark>
I can't find anything specifying signedness in 1800-2017
<whitequark>
so, I can see two potential encodings of the cell
<whitequark>
the first one is to completely break down the format string into (format,width,value) tuples, where one parameter is concatenated formats, another is concatenated widths (something like "16 32 32"), and a third one is concatenated values
<whitequark>
so all of the literal parts, like foo and bar in "foo%dbar", would be like %s-substititions with "foo" and "bar" as parameters
<whitequark>
this is easy to work with and is a good normalization, but it's completely unreadable in RTLIL
<whitequark>
the second one is to use the Python/Rust f-string/format! substitutions and reencode "foo%dbar" into something like "foo{16: 5du}bar"
<whitequark>
this is harder to work with (every backend has to parse the format string), but it's readable in RTLIL, and it also means it's not necessary to figure out how to escape the space that is legal as a padding character in the format string
<daveshah>
Personally, I think the latter is probably the nicer of the two solutions
<daveshah>
mainly because of the readability
<whitequark>
I'm leaning towards it as well
Asu has joined ##openfpga
<scientes>
how do i get started on the litefury?
<scientes>
Xilinx is giving me "We cannot fulfill your request as your account has failed export compliance verification."
<tnt>
daveshah: So, AFAIK in a .pcf you can't specify the package with the official tools. However would it be acceptable to add that to nextpnr ? When supporting multi-board, having the package as CLI is annoying :/
<daveshah>
Given that the PCF already has a non-standard clock constraint command, a non-standard set_package command doesn't seem like the end of the world
<tnt>
ack
<daveshah>
It will need to be the first command in the PCF, without some significant rework of the PCF parser
<daveshah>
as it looks up pin->bel mappings when it hits a set_io comamnd
<tnt>
yeah, that's not much of a problem I think.
jeanthom has quit [Ping timeout: 246 seconds]
jeanthom has joined ##openfpga
<q3k>
scientes: it did that to me on some IP addresses
<scientes>
q3k, yeah its because I am Georgia (the country)
<q3k>
scientes: (assuming you didn't fill out the form as "i'm in iran and going to use this to make nuclear weapons")
<scientes>
which is supposedly on the D or E list of "terrorist" countries, et cetera
<scientes>
the E list is the "axis of evil"
<q3k>
you might have to make up some other presence in another country then
<scientes>
I just found a torrent
<q3k>
or that :)
<scientes>
easier than using my US VPS as proxy
<scientes>
even through I already have it set up with wireguard for my android
Bike has joined ##openfpga
jeanthom has quit [Ping timeout: 265 seconds]
<mwk>
whitequark: here
<mwk>
*reads backlog*
<mwk>
whitequark: right, that sounds reasonable
<mwk>
so you're running into the same old "RTLIL cannot describe complex structures in parameters" problem that $macc or $mem have bumped against in the past
<mwk>
I'd say we want to implement a helper class (like kernel/mem.h or kernel/macc.h) for the $display cell either way, to avoid the parsing code duplication in backends
<whitequark>
yep
<whitequark>
and yep
<whitequark>
already started kernel/format.h
<mwk>
ah, good
<mwk>
beyond that... cannot really say which RTLIL representation would be better
<mwk>
I'm leaning towards string to have some inspectability
<mwk>
in .il files
<whitequark>
yeah, seems like everyone likes the string
<whitequark>
the downside is that you need to at least parse the {}-string... but it's not really that bad
peepsalot has quit [Ping timeout: 260 seconds]
peepsalot has joined ##openfpga
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
kristianpaul has quit [Read error: Connection reset by peer]
jeanthom has joined ##openfpga
kristianpaul has joined ##openfpga
jeanthom has quit [Ping timeout: 265 seconds]
emeb has joined ##openfpga
Bob_Dole has quit [Ping timeout: 260 seconds]
Bob_Dole has joined ##openfpga
jeanthom has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
lexano has quit [Ping timeout: 264 seconds]
lexano has joined ##openfpga
laintoo has quit [Ping timeout: 246 seconds]
<kc8apf>
cyrozap: Dmitry (of uM23) said: "this......is beautiful" about rv51
<cyrozap>
kc8apf: Heh, glad to hear he likes it, especially since his project is partly what inspired me to do this.
laintoo has joined ##openfpga
<azonenberg>
whitequark: oh, any updates on the glscopeclient GDK_SCALE fix?
<azonenberg>
I believe it's fixed on my end and want to close it once you confirm