Add Baremetal IDE support #1534

T-K-233 · 2023-06-27T17:48:50Z

This PR adds an integrated environment for compiling baremetal code for both simulation and post-silicon chips.

Different from the simple test code from /tests folder, this environment also includes the complete initialization procedure of the memory layout, global, stack, and frame pointers, and other C run-time requirements.

With additional Microsoft Visual Studio Code plugins, users can launch interactive JTAG GDB debug sessions.

~~Additionally, this PR provides an example chip config that is generated from the GUI interface, which can both run in simulation and on Arty FPGA (FPGA support added in another PR).~~

Related PRs / Issues:
#194
#1046

Type of change:

Bug fix
New feature
Other enhancement

Impact:

RTL change
Software change (RISC-V software)
Build system change
Other

Contributor Checklist:

Did you set main as the base branch?
Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
Did you state the type-of-change/impact?
Did you delete any extraneous prints/debugging code?
Did you mark the PR with a changelog: label?
(If applicable) Did you update the conda .conda-lock.yml file if you updated the conda requirements file?
(If applicable) Did you add documentation for the feature?
(If applicable) Did you add a test demonstrating the PR?
(If applicable) Did you mark the PR as Please Backport?

…into baremetal-ide

jerryz123 · 2023-06-27T21:14:08Z

generators/chipyard/src/main/scala/config/ChipConfigs.scala

+  * Chip Config generated by the GUI
+  */
+class ExampleChipConfig extends Config(
+  // ==================================


Can this be merged into ChipLikeRocketConfig?

Where is the ChipLikeRocketConfig defined...?

Actualy I forgot, hasn't been merged yet, after #1484 I change ChipLikeQuadRocket to ChipLikeRocket

There should be only 1 basic ChipConfig ... this should be merged into ChipLikeRocketConfig above. Is there anything here that should not be merged into that?

The ExampleChipConfig is generated by the GUI interface. It lists every Config fragment in the chip explicitly within this class.

The idea is that this gives the user a clearer view of what components are included inside a chip, what Config fragment can be swapped with what else etc., and therefore can be used as a good teaching material for getting started tutorials (tutorials coming soon).

Listing Config fragments out in a single class also helps resolve the "what is overridden by what" problem. For example, for a tapeout chip, instead of overriding WithXXXPunchthrough with WithXXXIOBinder, the user will replace and switch between these two fragments for simulation vs. tapeout.

I'll try to merge this to the ChipLikeRocketConfig in future PR, but since this ExampleChipConfig is subject to user change (GUI will auto-generate the ChipConfigs.scala based on user configuration), and the scope can expand beyond using rocket cores, I suggest giving the class a more versatile name.

At one point, AbstractConfig did not exist, and every single example config included every single relevant config fragment, as you describe. I fought for this model for quite some time, until it became untenable to maintain so many 50-line configs.

My perspective on "tapeout configs" is that they should be as explicit as possible, and will often require careful hand-edits/bespoke-configs. With that in mind, removing AbstractConfig from the ChipLike configs is a move I would support.

However, I'm not sure that using GUI-configs as "tapeout configs" is the right direction, given that the GUI will only be able to support a smaller design space than what the full system is capable of.

I'd also prefer to consolidate any "ChipLike" example config into the ChipLikeRocketConfig, as currently there is CI/regressions around that Config that test many features, including a regression that builds and tests the FPGA bringup harness.

A proposal based on the above points:

Expand ChipLikeRocketConfig to not override AbstractConfig.

Have GUI dump configs into a separate file. Since I expect users will often want to edit ChipConfigs.scala by hand, this also prevents edit conflicts. One idea... user specifies a name in the GUI... GUI dumps the file into configs/GUI_<user_config_name>.scala.

Make GUI flexible enough to support generating the exact same design (and exact same config text) as the ChipLikeRocketConfig.

jerryz123 · 2023-06-28T00:24:08Z

Is the GUI going to be part of this PR?

T-K-233 · 2023-07-02T20:52:24Z

Is the GUI going to be part of this PR?

It's on a separate branch of this submodule. There's still some work to do before it can be published.

jerryz123 · 2023-07-03T06:57:46Z

Will GUI be part of submodule? Is it possible to included it upstream?

jerryz123 · 2023-09-04T21:58:43Z

generators/chipyard/src/main/scala/config/ChipConfigs.scala

+  * Chip Config generated by the GUI
+  */
+class ExampleChipConfig extends Config(
+  // ==================================


There should be only 1 basic ChipConfig ... this should be merged into ChipLikeRocketConfig above. Is there anything here that should not be merged into that?

jerryz123 · 2023-09-04T21:59:33Z

generators/chipyard/src/main/scala/config/ChipConfigs.scala

+  new chipyard.iobinders.WithAXI4MMIOPunchthrough ++
+  new chipyard.iobinders.WithTLMemPunchthrough ++
+  new chipyard.iobinders.WithL2FBusAXI4Punchthrough ++
+  new chipyard.iobinders.WithBlockDeviceIOPunchthrough ++


The "Punchthrough" IOBinders should not be included in any "Chip" configs, since they are not intended to be taped outl.

The idea is to make the default example a simulation-only setting. These Config fragments are directly extracted from chipyard.config.AbstractConfig.

jerryz123 · 2023-09-04T22:00:12Z

generators/chipyard/src/main/scala/config/ChipConfigs.scala

+  // ==================================
+  // External memory section
+  new testchipip.WithSerialTLClientIdBits(4) ++                     // support up to 1 << 4 simultaneous requests from serialTL port
+  new testchipip.WithSerialTLWidth(32) ++                           // fatten the serialTL interface to improve testing performance


This is wider than what we usually build (1-4 bits)

jerryz123 · 2023-09-04T22:00:22Z

generators/chipyard/src/main/scala/config/ChipConfigs.scala

+  // Debug settings
+  new chipyard.config.WithJTAGDTMKey(idcodeVersion = 2, partNum = 0x000, manufId = 0x489, debugIdleCycles = 5) ++
+  new freechips.rocketchip.subsystem.WithNBreakpoints(2) ++
+  new freechips.rocketchip.subsystem.WithNBreakpoints(2) ++


jerryz123 · 2023-09-04T22:02:28Z

generators/chipyard/src/main/scala/config/fragments/PeripheralFragments.scala

@@ -29,7 +29,7 @@ import chipyard.{ExtTLMem}
  * @param hang the power-on reset vector, i.e. the program counter will be set to this value on reset
  * @param contentFileName the path to the BootROM image
  */
-class WithBootROM(address: BigInt = 0x10000, size: Int = 0x10000, hang: BigInt = 0x10040) extends Config((site, here, up) => {
+class WithBootROM(address: BigInt = 0x10000, size: Int = 0x10000, hang: BigInt = 0x10000) extends Config((site, here, up) => {


If this is changed, then we need to change the testchipip bootrom as well. Does this PR have a corresponding testchipip PR that changes that?

Also, what is the motivation for this change?

jerryz123

I think this needs to be split into 3 PRs... I see three orthogonal changes here

BootROM changes... we can change this, but we'd have to check that all the tests pass. It looks like there are some failures related to this currently, so this may take some time to debug. Moving these to a separate PR would prevent them from blocking the other changes.
GUI-generated Configs. We ought to have a longer discussion on how these configs are generated+presented, so its clear what the differences are between the included configs, the GUI-generated configs, and the example Chip config. The GUI should be added to chipyard, not a submodule, since we would need to keep the GUI up-to-date with the SoC configuration.
IDE support. I think there's a strong argument for inlining this into Chipyard, rather than maintaining a separate submodule. Docs and regression tests should also be included with this.

T-K-233 · 2023-09-08T06:16:40Z

I think this needs to be split into 3 PRs... I see three orthogonal changes here

BootROM changes... we can change this, but we'd have to check that all the tests pass. It looks like there are some failures related to this currently, so this may take some time to debug. Moving these to a separate PR would prevent them from blocking the other changes.

GUI-generated Configs. We ought to have a longer discussion on how these configs are generated+presented, so its clear what the differences are between the included configs, the GUI-generated configs, and the example Chip config. The GUI should be added to chipyard, not a submodule, since we would need to keep the GUI up-to-date with the SoC configuration.

IDE support. I think there's a strong argument for inlining this into Chipyard, rather than maintaining a separate submodule. Docs and regression tests should also be included with this.

I see. I'll make the BootROM change a separate PR.

As for the IDE support, my design idea for the IDE is that it will be a standalone environment for firmware development, with the folder workspace being the working directory. To create multiple projects, user would clone multiple instance of the IDE repository. I'm not sure if inlining into Chipyard main repo would be optimal, since this would create a huge overhead for repo cloning and maintenance for those who just want to work on firmware/software development.

jerryz123 · 2023-09-08T22:38:17Z

As for the IDE support, my design idea for the IDE is that it will be a standalone environment for firmware development, with the folder workspace being the working directory. To create multiple projects, user would clone multiple instance of the IDE repository. I'm not sure if inlining into Chipyard main repo would be optimal, since this would create a huge overhead for repo cloning and maintenance for those who just want to work on firmware/software development.

Ok. That sounds reasonable to me. In that case, I think we should add regressions to chipyard that test that the default IDE configurations match the default chipyard configuration. Tests should check out the IDE, compile some simple hello-world that may access some devices (UART/GPIOs/SPI), and run them on the chipyard chip configuration.

T-K-233 · 2024-01-07T02:00:35Z

I think we can add regression tests at another PR.

I would like to add the submodule to Chipyard first to get the Lab 1 flow working for now.

jerryz123 · 2024-01-07T02:30:12Z

I've merged this to unblock lab development.
Please add a documentation link from the Chipyard docs at your earliest convenience.

T-K-233 added 5 commits June 15, 2023 13:16

ADD: add baremetal-ide to software

cd96f21

ADD: add chipyard-gui generated example config

83ab06e

ADD: add scratchpad

35266b4

ADD: change bootreg address

c19799b

Merge branch 'change-bootrom' of https://github.com/ucb-bar/chipyard …

b5e4b3f

…into baremetal-ide

T-K-233 requested review from abejgonzalez and jerryz123 June 27, 2023 17:48

T-K-233 added the changelog:added label Jun 27, 2023

jerryz123 reviewed Jun 27, 2023

View reviewed changes

T-K-233 added 4 commits August 21, 2023 14:17

ADD: add working examplechip in htif

c3c92cf

ADD: version bump of baremetal-ide

ef3c9b3

Merge branch 'main' of github.com:ucb-bar/chipyard into baremetal-ide

d61f0aa

ADD: bump baremetal-ide

c8c5c19

T-K-233 marked this pull request as ready for review September 3, 2023 16:24

jerryz123 requested changes Sep 4, 2023

View reviewed changes

T-K-233 added 2 commits September 4, 2023 22:48

FIX: fix typo and config

ce50550

Merge branch 'main' of github.com:ucb-bar/chipyard into baremetal-ide

c7e8032

T-K-233 mentioned this pull request Sep 5, 2023

Refactor: Adjust bootrom reset vector address ucb-bar/testchipip#196

Merged

jerryz123 requested changes Sep 5, 2023

View reviewed changes

T-K-233 added 5 commits September 8, 2023 23:39

REVERT: revert ChipConfig changes

1629579

REVERT: revert testchipip changes

a73129a

Merge branch 'main' of github.com:ucb-bar/chipyard into baremetal-ide

c05cbde

FIX: using updated main changes

d7923cd

FIX: fix missing newline

b27004d

T-K-233 self-assigned this Sep 27, 2023

T-K-233 added 2 commits October 28, 2023 16:38

Merge branch 'main' into baremetal-ide

a4c03e9

Merge branch 'main' into baremetal-ide

b46d0f8

T-K-233 requested a review from jerryz123 January 7, 2024 01:58

jerryz123 approved these changes Jan 7, 2024

View reviewed changes

jerryz123 merged commit ba56000 into main Jan 7, 2024
33 checks passed

jerryz123 deleted the baremetal-ide branch January 7, 2024 02:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Baremetal IDE support #1534

Add Baremetal IDE support #1534

T-K-233 commented Jun 27, 2023 •

edited

Loading

jerryz123 Jun 27, 2023

T-K-233 Jun 28, 2023

jerryz123 Jun 28, 2023

jerryz123 Sep 4, 2023

T-K-233 Sep 5, 2023

jerryz123 Sep 5, 2023

jerryz123 commented Jun 28, 2023

T-K-233 commented Jul 2, 2023 •

edited

Loading

jerryz123 commented Jul 3, 2023

jerryz123 Sep 4, 2023

jerryz123 Sep 4, 2023

T-K-233 Sep 5, 2023

jerryz123 Sep 4, 2023

jerryz123 Sep 4, 2023

jerryz123 Sep 4, 2023

jerryz123 left a comment

T-K-233 commented Sep 8, 2023

jerryz123 commented Sep 8, 2023

T-K-233 commented Jan 7, 2024

jerryz123 commented Jan 7, 2024

Add Baremetal IDE support #1534

Add Baremetal IDE support #1534

Conversation

T-K-233 commented Jun 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerryz123 commented Jun 28, 2023

T-K-233 commented Jul 2, 2023 • edited Loading

jerryz123 commented Jul 3, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerryz123 left a comment

Choose a reason for hiding this comment

T-K-233 commented Sep 8, 2023

jerryz123 commented Sep 8, 2023

T-K-233 commented Jan 7, 2024

jerryz123 commented Jan 7, 2024

T-K-233 commented Jun 27, 2023 •

edited

Loading

T-K-233 commented Jul 2, 2023 •

edited

Loading