midas is overdependent on rocketchip about midas

[davidbiancolin]

I will not approve PR to master that would remove this dependency unless you can find someone else that would also support this idea. If you want to create a branch that's totally ok. I thought the solution we talked about yesterday would suffice.

We continue to use junctions when we should really use the AXI4 implementation in rocket-chip.
Most of the interconnect generation that happens during host mapping depends on these standard interfaces and in the future will be subsumed by diplomacy. When i write RTL i always look at rocketchip first to see if a library exists before implementing it myself. Often it does and is better than the thing i would have written. MIDAS doesn't need to depend on rocket-chip-the-target, but it should depend on rocket-chip-the-library-of-chisel-utilities-and-standard-IF-definitions.

Submodule-ing rocketchip is not that painful.

git submodule update --init
(cd rocket-chip; git submodule update --init)
(cd <my-other-recursive-submodule>; git submodule update --init <--recursive>)
...

You provide a setup script, which you write once, and you never have to do it again.
Once you've compiled the RC sources, you never have to compile them again; unless you blow away your targets/, or are changing FIRRTL Compiler src/Chisel/RC code.

Having multiple definitions of classes in projects that do use rocket-chip as a target is going to be messy and error prone. We're going to have to cast things from midas.package to rocketchip., and then manage annoyances when they stop being compatible. This worked with nasti because RC just removed the code altogether and it's a hardware interface not a software one like config.

We should talk about this at the midas-dev meeting where we can work out a compromise that works better for most people.

[donggyukim]

I will not approve PR to master that would remove this dependency unless you can find someone else that would also support this idea. If you want to create a branch that's totally ok. I thought the solution we talked about yesterday would suffice.

Unfortunately, that was not sufficient. I noticed that not using rocketchip is very painful with the current midas. And does that mean I should go in my own way afterwards? If you think I'm just trolling,
I'll stop it immediately. However, I'll be very likely to branch off forever in the future specifically after my graduation.

We continue to use junctions when we should really use the AXI4 implementation in rocket-chip.

Can you convince me more?

When i write RTL i always look at rocketchip first to see if a library exists before implementing it myself. Often it does and is better than the thing i would have written.

This is I believe the only reason to import rocketchip here. As shown before, code sharing is less than 1% of the total rocketchip code. As a result, we have a huge overhead on project maintenance. The right solution is moving useful utils in rocketchip to chisel, not importing the whole rocketchip.

Submodule-ing rocketchip is not that painful.

git submodule update --init
(cd rocket-chip; git submodule update --init)
(cd ; git submodule update --init <--recursive>)
...

Oops, should I do this whenever I have a new project? Who's gonna write this script? And what about build.sbt? What if I want to use some other chisel version than that in rocketchip?

You provide a setup script, which you write once, and you never have to do it again.
Once you've compiled the RC sources, you never have to compile them again; unless you blow away your targets/, or are changing FIRRTL Compiler src/Chisel/RC code.

In reality, I had to compile rocketchip multiple times. We should compile it whenever we have a fresh clone.

Having multiple definitions of classes in projects that do use rocket-chip as a target is going to be messy and error prone. We're going to have to cast things from midas.package to rocketchip., and then manage annoyances when they stop being compatible. This worked with nasti because RC just removed the code altogether and it's a hardware interface not a software one like config.

To me, this is a view of 'rocketchip is the entire world'. We don't need to cast anything from midas to rocketchip. No body is going to use utils in midas outside midas, and we don't need mix midas configs with rocketchip configs.

We should talk about this at the midas-dev meeting where we can work out a compromise that works better for most people.

I know nobody will agree with me in this meeting because rocketchip is imported by default for the guys in the meeting. And I believe nobody will cares unless midas is going to break firesim.

[davidbiancolin]

You're right that most stakeholders use RC as a target.

The main opportunity talking about this at the meeting offers is the chance for us to brainstorm a way to manage this more intelligently than simply copying the code directly into MIDAS. Maybe other developers who have large multi-project repositories have some insight they can offer.

[donggyukim]

Sure, this shouldn't be done right away, but I want to draw some attention to this issue even though I just suggest a short term solution.

Also, if you can convince me more for diplomacy and tilelink in the future so that we can tolerate importing the whole rocketchip even for other projects, I will change my mind. In this case, we don't have to worry about code duplication any more.