Re: [committed] RISC-V: XVentanaCondops support

[Jeff Law <jeffreyalaw@gmail.com>]

On 4/26/23 15:42, Palmer Dabbelt wrote:
> We had the various RISC-V port maintainers and long-term contributors in 
> FSF toolchain land (ie, binutils/GCC/glibc) agree on something posted to 
> the mailing list.
> 
> Philipp and I certainly talked about it, but there's no private 
> agreements or anything like that -- it's just what we discuss on the 
> mailing lists.  Unfortunately he has along history of misrepresenting 
> things, but that's really why we're so careful about making sure that 
> all the decisions are talked about on the lists.
I wasn't implying any private communications.  It was more a reflection 
that you and Philipp seemed to be the principals in the overall discussion.

My recollection from the discussion back in Nov/Dec was that the only 
thing we were still waiting on for xventanacondops to move forward was 
an announcement of the chip.  My understanding was the chip didn't need 
to actually be available yet.  Maybe I'm mis-remembering, and if so, 
I've got no problem pulling this out.

Perhaps the requirements should be posted somewhere so that gcc, 
binutils, gdb, glibc, etc can all refer to and follow the same 
procedures for accepting vendor specific bits.

> 
> The idea was to have some sort of timeline around availability of the 
> hardware -- essentially the goal is to avoid being stuck supporting 
> stuff that doesn't actually make it out of the lab.  I can't find 
> anything that actually says that, but then also I'm pretty much allergic 
> to chip company marketing material these days so I sort of stay out of 
> it ;)
I don't recall a timeline in the requirements.  But again, it's been 
months since we kicked this stuff around.  I can't speak to timelines 
other than "we're waiting on hardware to start bring-up".


> 
> The best I've been able to find is this "Veyron V1 is Highest 
> Performance RISC-V Processor running at 3.6GHz in 5nm" [1].  The 
> big-ticket ones like an SDK and dev board don't seem to exist anywhere 
> outside of press releases, though (there's a github [2], but no SDK).
I don't think we've released our SDK to anyone except partners.  So no 
surprise you can't find an SDK :)

> 
> I know it's kind of pedantic, but we've had a lot of issues in the past 
> with RISC-V folks making stuff up and trying to push around upstream. 
> I'm not saying you're doing that, you've been around long enough that if 
> you say you have a chip I believe you.  The goal is to be fair to 
> everyone, though -- essentially the same as what happened for the GCC 
> patches.
No worries.  As I've noted in the past, I'm keenly aware of the desire 
to avoid even the appearance of unfairness or someone taking advantage 
of their position in the communities.  It's something that's been 
important to me personally for decades in the GCC space, so you don't 
ever have to worry about explaining it to me or offending me by being 
pedantic in this space.

I'm not going to lose any sleep if we need to delay bits for veyron-v1, 
I just want to make sure we have an agreed upon process so that we know 
when things can go forward across the various tools.  I'm actually more 
concerned about this for gcc than binutils/gdb as we have scheduler 
models, costing models, etc that I'd like to get submitted.  I've held 
off doing that for the duration of the gcc-13 cycle, but very much want 
to see those things move forward in the gcc-14 cycle.

So in summary, let's get the agreement/policy posted in a easily found 
location.  I'll suggest the GCC wiki, but I'm certainly not wed to that 
idea.

jeff