[sw] Goal of Nexysvideo

[tjaychen]

As many people know, the Nexysvideo is no longer big enough to accommodate the top_earlgrey design. For awhile, we have been hacking around this with an on-the-fly reduce script, but this has also reached its limits, and the Nexysvideo can now take so long to build that CI times out.

So this issue is asking the question, what do want to use Nexysvideo for?

CW305 is the vehicle for SCA, while CW310 is meant for the full design.

Should the Nexysvideo be used as a generic embedded development platform? (for example Tock). If that is the case, what are the components we need? At a glance...

• Ibex
• PLIC
• Timers
• GPIO
• UART
• Memories
• Flash
• Debug
• SPI device
• Any accelerators?
• Entropy?

Things we SHOULD NOT include

• otp_ctrl
• lc_ctrl
• keymgr
• memory scrambling
• flash scrambling
• alert handler?
• others?

[tjaychen]

@timothytrippel FYI (can't add as assignee for some reason) @dsandrs @domrizz0 FYI

[asb]

@timothytrippel FYI (can't add as assignee for some reason)

Should be able to now (or at least, as soon as Tim accepts the GH team invite).

[tjaychen]

@timothytrippel FYI (can't add as assignee for some reason)

Should be able to now (or at least, as soon as Tim accepts the GH team invite).

thanks Alex!

[tjaychen]

@timothytrippel FYI (can't add as assignee for some reason)

Should be able to now (or at least, as soon as Tim accepts the GH team invite).

would also like to hear your thoughts on this issue as well!

[timothytrippel]

@timothytrippel FYI (can't add as assignee for some reason)

Should be able to now (or at least, as soon as Tim accepts the GH team invite).

invite accepted.

[timothytrippel]

I'm of the opinion that a reduction in complexity is the best route forward given current timelines and constraints. Ideally, it would be nice if we just formally support one FPGA for the time being. This would have several benefits:

• Reduced build system and test infrastructure complexity
• Reduced build times/compute efforts for CI
• Reduced toplevel/pinmux configurations

That said, I understand the value-add (especially in the academic/adoptability domain) in having a stripped down design that can run on a readily available FPGA. So if we can't have just one FPGA, is there a reason we need 3, instead of 2 (i.e., Nexys and CW310)? This brings the question, is there a reason SCA cannot be done on the CW310? (sorry for my naivete)

To answer the other question about which IPs to include for the Nexys, should SPI be included? From an embedded perspective, being able to interface with SPI flash is typically desired.

[tjaychen]

o yes you're right spi device should be included, otherwise we can't even get code into the flash. To your question, the CW310 actually can be used for SCA, and @vogelpi is trying that out now (i think so far, if he uses the same design on CW305 / CW310, the results are very similar).

So I think long term it would be possible to deprecate CW305 in favor of CW310 (@moidx @vogelpi what do you think?) The CW305 i think is smaller and cheaper, and probably more favorable to academics and other open source communities though.

[msfschaffner]

For the SCA move to CW310, I believe there are still some evaluations ongoing to see how the noise levels behave. But in principle, I also think that it should be possible to move to the CW310 long term...

[msfschaffner]

One other reason why we kept the NexysVideo around for so long (besides its affordable price tag) is that the FPGA bitstream can be built with the free Vivado WebPack edition, which is convenient for SW development and the open-source community.

[moidx]

The CW305 i think is smaller and cheaper, and probably more favorable to academics and other open source communities though.

There is a lower cost variant of CW310 we can consider, not sure how it compares to CW305 in terms of cost. Also, need to ping @colinoflynn to check if that target is compatible with the webpack version of Vivado.

[msfschaffner]

Are you referring to the one with the Kintex 160T? I believe that FPGA would still be supported by the Vivado WebPack, yes.

[msfschaffner]

Just checked with my local WebPack installation and it looks like the 160T can be selected.

[dsandrs]

If we fix the tooling to allow the SW folks to modify the bitstream to insert their code in ROM/Flash, then individuals wouldn't need to build the FPGA at all (assuming no hw bugs :-). We could checkin the bitstream, right? But I agree the CWxxx cost is not good for academics

[timothytrippel]

Will license agreements allow us to check in a bitstream built with proprietary (paid) tooling? If so, this would greatly reduce the "getting started" effort for academics/open source SW communities.

[msfschaffner]

Yeah that's a good question.

If we are allowed to do that, we could make bitstreams available as release artifacts here (for example): https://github.com/lowRISC/opentitan/releases

[vogelpi]

For SCA, it's right that ultimately we would want to use Earl Grey on the big CW310 only. However, there is a lot of stuff running in the background on Earl Grey causing substantial power noise and complicating measurements. I am still in the process of isolating these sources but it's like looking for a needle in a hay stack.

As for supporting different FPGA boards: whether it's the CW305, the smaller version of the CW310 or the NexysVideo doesn't really matter. None of these requires a license. But all of them are too small for Earl Grey, meaning we require a different top level such as English Breakfast. And that's where some maintenance cost comes in. What's needed on top of what we have already today:

• Remove hardcoded references to top_earlgrey in the software sources.
• Cause the software build flow invoke topgen instead of relying on checked-in auto-generated sources under hw/top_earlgrey/sw.
• Provide a mechanism to distinguish different top levels at software compile time, e.g. if a top level doesn't have some IPs. We already have a mechanism to distinguish different chips/targets (Verilator sim, FPGA, chip-level DV), see sw/device/lib/arch/device_fpga_*.c.

It's clear that we want to focus our efforts on our main platform Earl Grey/CW310. So whatever we do for English Breakfast will be best effort: it's sufficient to provide a development boot ROM, hello world and some smoke tests.

If we support one additional or two additional boards doesn't really matter either. It's some CI run time but that can be parallelized. The only exception is when FPGA utilization is close to the capacity as on the NexysVideo right now. Then CI run time explodes. But we can avoid this with English Breakfast.

[imphil]

If we are allowed to do that, we could make bitstreams available as release artifacts here (for example):

All bitstreams we build in CI are already available as build artifact (and have been since the beginning of time).

[colinoflynn]

Some quick additional notes (sorry catching up now):

• CW310 w/ K160T should be much cheaper - the original goal was having similar price-point to CW305 (~$1500 or less). The FPGA cost is a substantial driver which was complicated by supply chain issues. In theory we have better pricing for the FPGAs in the future, but for current builds we needed to use Digikey pricing, and even then we ended up getting better speed/temp grades than required due to stock. The large FPGA for ref is $2K alone on these builds, and Xilinx had pushed a 25% price increase on Kintex parts back in ~March so it wasn't clear which pricing would apply.

• Xilinx pricing has very distinct tiers which are unlike any other parts in terms of % reduction. It's under NDA, but if you end up using > 1K parts the pricing becomes a fraction of "list price". Even at lower quantities it's relevant reductions - unfortunately right now it's moot due to lead time. We ordered parts under that pricing back in Jan/Feb, they may deliver in Oct but I'm not sure, so we had to use high-cost Digikey pricing for now.

• For most academics they would have access to Xilinx University Program, meaning they get full Vivado versions. So the webpack is still good to keep, but I wouldn't peg it as a "must have". The K160T was chosen specifically due to Webpack support.

Anyway hopefully makes sense on pricing - the current board price is more extreme than planned due to the supply chain issues. So the current prince/board is "delivering something in 2021 pricing". We haven't figured out what it will look like yet as pricing in general has become fluid on parts, but if it's of interest could open a more detailed discussion on options/plans there.

[mundaym]

We discussed this in the Software WG meeting today (2022-04-12):

The consensus was that there is no need to support Nexysvideo for software development use cases. Our recommendation is that support for Nexysvideo is dropped completely and that we instead focus on evaluating other platforms with bigger FPGAs (e.g. AWS F1) if we want to support a FPGA platform with a low barrier to entry for newcomers and hobbyists.

[tjaychen]

that sounds good to me. Then we are okay with removing nexysvideo completely from CI?