dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
davidlt has joined #fedora-riscv
davidlt_ has joined #fedora-riscv
davidlt has quit [Ping timeout: 255 seconds]
davidlt_ has quit [Ping timeout: 246 seconds]
jcajka has joined #fedora-riscv
davidlt_ has joined #fedora-riscv
jednorozec has quit [Remote host closed the connection]
jednorozec has joined #fedora-riscv
davidlt_ has quit [Ping timeout: 255 seconds]
jcajka has quit [Quit: Leaving]
davidlt_ has joined #fedora-riscv
<rwmjones> davidlt_: hey david, you mentioned something about t-head c920 having a hardware bug
<rwmjones> and sent me a reference
<rwmjones> do you happen to have that one? I've lost it ..
<rwmjones> also I just met david brash in person
<rwmjones> I think that might even be a different one
<rwmjones> ah yes that was it, thanks!
<davidlt_> there is also an issue with atomics
davidlt_ is now known as davidlt
<rwmjones> do you have a reference for that?
<davidlt> rwmjones, I feel like T-HEAD might have moved fast and might not have spend enough time in validation
<davidlt> I think that's the one sorear mentioned.
<rwmjones> yup I highlighted that concern internally here
<davidlt> There might be another issue too, but it's all in some email between me and some RH folks (incl. you).
<davidlt> rwmjones, there is SG2044 (next-year SoC) that seems to fix some (or all?) of these.
<davidlt> I think, it has not-yet-announced T-HEAD core IP. Something like C906 -> C908, just for C910/920 cores
<rwmjones> and maybe have more bugs?
<davidlt> Who knows, I would assume it's "growing pains".
<davidlt> T-HEAD/Alibaba have tons of money to semi-fail early.
<rwmjones> yup
<davidlt> It's not something you can afford as a startup.
<davidlt> I would assume validation is money/time issue. You could always pay for more simulation cycles.
<davidlt> Cooking something and testing in real life also works :)
<davidlt> SpaceX-style ;)
<rwmjones> :-)
<davidlt> Anyways I bet things will slowly improve as time goes (i.e. years).
<davidlt> rwmjones, I don't trust TH1520 and SG2042 building packages today.
<davidlt> It's still sad that 4 cores (FU740) -> 64 cores (C920) give me ~4-5 times lower compile times on GCC :(
<davidlt> I would prefer 1 cluster [4-cores] with some performance cores + 2-3 clusters of efficiency cores.
<davidlt> StarFive finally have their own core IP, it will be interesting how good/bad it is.
<sorear> awaiting updates on jh8110
<davidlt> The major issue for them is that ISA is different between two clusters.
* davidlt trying to find the article
<davidlt> Dubhe-80 (efficiency cores) support vector, but not Dubhe-90 (performance cores).
<davidlt> Oh, I missed that they have IOPMP listed.
<davidlt> The slides say that StarLink-500 (interconnect IP) ref design is 1.2GHz @ 12nm.
<davidlt> I bet they will be using 12nm processes again.
<davidlt> Aren't China banned from using TMSC 16nm and lower?
<davidlt> News: The ban will be primarily limited to 16nm, 14nm, or more advanced processes for logic ICs (such as FinFET or GAAFET), 18nm or more advanced processes for DRAM, and 128-layer or higher products for NAND Flash chips, TrendForce said.
<davidlt> So are these built at SMIC fabs?
<davidlt> News: SMIC moved its first-generation FinFET technology consisting of 14nm and 12nm process nodes to mass production in the fourth quarter of 2019.
<sorear> to me it seems quite reasonable to support instructions on a subset of cores with threads migrated and locked on an attempt to use differentiated instructions
davidlt has quit [Ping timeout: 248 seconds]
rpsene has quit [Read error: Connection reset by peer]
fuwei has quit [Ping timeout: 240 seconds]
fuwei has joined #fedora-riscv