[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

Hi All,

Sorry this mail got a bit long the outline is:
 - Testing Efforts
 - Marocchino Pipeline
 - Proposal to Split Marocchino to new Repo

## Testing Efforts ##

Recently I have been working on adding FPU support to GCC.  The GCC
generated FPU code is working and running on the simulator, but I have
been taking extra time now to verify on iverilog and verilator
simulators of mor1kx.  This has gotten me a bit sidetracked to get a
CI environment for testing mor1kx cores.  What I have so far is:
   - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
   - Almost all tests are passing for mor1kx cappuccino pipeline
(multiply carry flag is not implemented, so there is one failure)
   - Most tests are failing for the Espresso pipeline (Issue with
>1clock instructions in delay slots)
   - Most tests are failing for the Marocchino pipeline (Its likely an
issue with how I implemented the monitor_* signals)

TODO
  - FPU tests are not run in or1k-tests
  - Document test coverage for each pipeline
  - CI - Automate testing for each commit/PR
  - Confirm debug capabilities, i.e. single-stepping
  - Synthesize with Xilinx/Altera toolchains to verify resource usage/budget

Not planning todo
  - GCC support for no-delay-slot code which would be needed for pronto espresso

## Marocchino Pipeline ##

Which brings us to Marocchino.  Andrey has been working on the
Marocchino implementation for a while.  This is a fork of the mor1kx
cappuccino pipeline that adds many advanced features like: out of
order instruction execution, simplify by reducing parameter options,
separate Wishbone and CPU clocks and 64-bit FPU operations via the
ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
In the end this has turned into a very different internal
architecture.

Currently the work is all stored in the marocchino_devel branch of mor1kx.

## Proposal to Split Marocchino to new Repo ##

As we discussed in a recent PR
(https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
share any code with the rest of mor1kx and even now has a separate top
level module (mor1kx_top_marocchino).

Andrey and I have proposed moving the code to a new repo
openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
pipeline swap any longer the name might be controversial.

Does anyone have a objection / suggestion for this?

-Stafford

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Olof Kindgren]

On Sun, Jan 27, 2019 at 11:12 AM Stafford Horne <shorne@gmail.com> wrote:

> Hi All,
>
> Sorry this mail got a bit long the outline is:
>  - Testing Efforts
>  - Marocchino Pipeline
>  - Proposal to Split Marocchino to new Repo
>
> ## Testing Efforts ##
>
> Recently I have been working on adding FPU support to GCC.  The GCC
> generated FPU code is working and running on the simulator, but I have
> been taking extra time now to verify on iverilog and verilator
> simulators of mor1kx.  This has gotten me a bit sidetracked to get a
> CI environment for testing mor1kx cores.  What I have so far is:
>    - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
>    - Almost all tests are passing for mor1kx cappuccino pipeline
> (multiply carry flag is not implemented, so there is one failure)
>    - Most tests are failing for the Espresso pipeline (Issue with
> >1clock instructions in delay slots)
>    - Most tests are failing for the Marocchino pipeline (Its likely an
> issue with how I implemented the monitor_* signals)
>
> TODO
>   - FPU tests are not run in or1k-tests
>   - Document test coverage for each pipeline
>   - CI - Automate testing for each commit/PR
>   - Confirm debug capabilities, i.e. single-stepping
>   - Synthesize with Xilinx/Altera toolchains to verify resource
> usage/budget
>
> Not planning todo
>   - GCC support for no-delay-slot code which would be needed for pronto
> espresso
>
>
Fantastic! Are you looking at resource usage for CI? In that case it might
be worth building with yosys instead to avoid a dependency on a commercial
EDA tool. Even if a synthesis with yosys would require more resources it
doesn't that much. I guess we are more interested in the varitation between
builds than any absolute number. It's on my TODO list to add support in the
Edalize backends for just doing synthesis without P&R. That could be
helpful in this case too.

And I think you do well in ignoring the or1k-nd versions for now. There are
likely problems all over the place with that. Would be cool to see if
espresso is any good though.


> ## Marocchino Pipeline ##
>
> Which brings us to Marocchino.  Andrey has been working on the
> Marocchino implementation for a while.  This is a fork of the mor1kx
> cappuccino pipeline that adds many advanced features like: out of
> order instruction execution, simplify by reducing parameter options,
> separate Wishbone and CPU clocks and 64-bit FPU operations via the
> ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
> In the end this has turned into a very different internal
> architecture.
>
> Currently the work is all stored in the marocchino_devel branch of mor1kx.
>
> ## Proposal to Split Marocchino to new Repo ##
>
> As we discussed in a recent PR
> (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
> share any code with the rest of mor1kx and even now has a separate top
> level module (mor1kx_top_marocchino).
>
> Andrey and I have proposed moving the code to a new repo
> openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
> pipeline swap any longer the name might be controversial.
>
> Does anyone have a objection / suggestion for this?
>
>
Exciting to see all the work on Marocchino! I'm fine with the move and
think it could make sense to drop the mor1kx name for the reasons you
cited, but I'd leave that up to Andrey.

//Olof

-Stafford
> _______________________________________________
> OpenRISC mailing list
> OpenRISC at lists.librecores.org
> https://lists.librecores.org/listinfo/openrisc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190130/350fadc2/attachment.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[BAndViG]

## Reused Sources ##

To be accurate, MAROCCHINO re-uses the following mor1kx sources:

    mor1kx_cfgrs.v
    mor1kx-sprs.v
    mor1kx-defines.v
    mor1kx_utils.vh

Is it normally to just copy them in new repo? As we change them rarely, I think it couldn’t be too hard to keep them synchronized with originals from “openrisc/mor1kx”.


## Prefix Replacement ##

I see there are reasons to remove “mor1kx_” prefix from MAROCHCHINO sources. I would prefer to replace it with someone suitable rather than to just drop it. What about “or1k_”? Or something other? 
Note 1. To keep consistency I think all mentioned above copies of shared sources should be renamed (in MAROCHCINO repo). Same to all MAROCCHINO modules. I’ll do that if we agree about new prefix.
Note 2. What about monitor? If I understand correctly Stafford renamed instance of mor1kx_cpu_marocchino from “u_cpu_marocchino” to “mor1kx_cpu” in MAROCCHINO top exactly to restore compatibility with mor1kx monitor. If we drop/replace “mor1kx_” prefix we will lose compatibility with or1k-tests suite again.

Andrey


From: Olof Kindgren 
Sent: Wednesday, January 30, 2019 12:56 PM
To: Stafford Horne 
Cc: Openrisc ; Philipp Wagner ; Julius Baxter ; BAndViG ; Stefan Wallentowitz 
Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo



On Sun, Jan 27, 2019 at 11:12 AM Stafford Horne <shorne@gmail.com> wrote:

  Hi All,

  Sorry this mail got a bit long the outline is:
  - Testing Efforts
  - Marocchino Pipeline
  - Proposal to Split Marocchino to new Repo

  ## Testing Efforts ##

  Recently I have been working on adding FPU support to GCC.  The GCC
  generated FPU code is working and running on the simulator, but I have
  been taking extra time now to verify on iverilog and verilator
  simulators of mor1kx.  This has gotten me a bit sidetracked to get a
  CI environment for testing mor1kx cores.  What I have so far is:
     - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
     - Almost all tests are passing for mor1kx cappuccino pipeline
  (multiply carry flag is not implemented, so there is one failure)
     - Most tests are failing for the Espresso pipeline (Issue with
  >1clock instructions in delay slots)
     - Most tests are failing for the Marocchino pipeline (Its likely an
  issue with how I implemented the monitor_* signals)

  TODO
    - FPU tests are not run in or1k-tests
    - Document test coverage for each pipeline
    - CI - Automate testing for each commit/PR
    - Confirm debug capabilities, i.e. single-stepping
    - Synthesize with Xilinx/Altera toolchains to verify resource usage/budget

  Not planning todo
    - GCC support for no-delay-slot code which would be needed for pronto espresso



Fantastic! Are you looking at resource usage for CI? In that case it might be worth building with yosys instead to avoid a dependency on a commercial EDA tool. Even if a synthesis with yosys would require more resources it doesn't that much. I guess we are more interested in the varitation between builds than any absolute number. It's on my TODO list to add support in the Edalize backends for just doing synthesis without P&R. That could be helpful in this case too.

And I think you do well in ignoring the or1k-nd versions for now. There are likely problems all over the place with that. Would be cool to see if espresso is any good though.


  ## Marocchino Pipeline ##

  Which brings us to Marocchino.  Andrey has been working on the
  Marocchino implementation for a while.  This is a fork of the mor1kx
  cappuccino pipeline that adds many advanced features like: out of
  order instruction execution, simplify by reducing parameter options,
  separate Wishbone and CPU clocks and 64-bit FPU operations via the
  ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
  In the end this has turned into a very different internal
  architecture.

  Currently the work is all stored in the marocchino_devel branch of mor1kx.

  ## Proposal to Split Marocchino to new Repo ##

  As we discussed in a recent PR
  (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
  share any code with the rest of mor1kx and even now has a separate top
  level module (mor1kx_top_marocchino).

  Andrey and I have proposed moving the code to a new repo
  openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
  pipeline swap any longer the name might be controversial.

  Does anyone have a objection / suggestion for this?



Exciting to see all the work on Marocchino! I'm fine with the move and think it could make sense to drop the mor1kx name for the reasons you cited, but I'd leave that up to Andrey.


//Olof

  -Stafford
  _______________________________________________
  OpenRISC mailing list
  OpenRISC at lists.librecores.org
  https://lists.librecores.org/listinfo/openrisc

WBR
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190131/a34270b6/attachment.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Julius Baxter]

On Sun, 27 Jan 2019 at 11:11, Stafford Horne <shorne@gmail.com> wrote:

> Hi All,
>
> Sorry this mail got a bit long the outline is:
>  - Testing Efforts
>  - Marocchino Pipeline
>  - Proposal to Split Marocchino to new Repo
>
> ## Testing Efforts ##
>
> Recently I have been working on adding FPU support to GCC.  The GCC
> generated FPU code is working and running on the simulator, but I have
> been taking extra time now to verify on iverilog and verilator
> simulators of mor1kx.  This has gotten me a bit sidetracked to get a
> CI environment for testing mor1kx cores.  What I have so far is:
>    - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
>    - Almost all tests are passing for mor1kx cappuccino pipeline
> (multiply carry flag is not implemented, so there is one failure)
>    - Most tests are failing for the Espresso pipeline (Issue with
> >1clock instructions in delay slots)
>    - Most tests are failing for the Marocchino pipeline (Its likely an
> issue with how I implemented the monitor_* signals)
>

Hi Stafford,

Great job - integrating this into a CI flow would be very nice indeed.


>
> TODO
>   - FPU tests are not run in or1k-tests
>   - Document test coverage for each pipeline
>   - CI - Automate testing for each commit/PR
>   - Confirm debug capabilities, i.e. single-stepping
>   - Synthesize with Xilinx/Altera toolchains to verify resource
> usage/budget
>
> Not planning todo
>   - GCC support for no-delay-slot code which would be needed for pronto
> espresso
>

Yep, fair enough.


>
> ## Marocchino Pipeline ##
>
> Which brings us to Marocchino.  Andrey has been working on the
> Marocchino implementation for a while.  This is a fork of the mor1kx
> cappuccino pipeline that adds many advanced features like: out of
> order instruction execution, simplify by reducing parameter options,
> separate Wishbone and CPU clocks and 64-bit FPU operations via the
> ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
> In the end this has turned into a very different internal
> architecture.
>
> Currently the work is all stored in the marocchino_devel branch of mor1kx.
>

This sounds great! Does CoreMark run on it yet? How much of a speedup have
you achieved so far?


>
> ## Proposal to Split Marocchino to new Repo ##
>
> As we discussed in a recent PR
> (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
> share any code with the rest of mor1kx and even now has a separate top
> level module (mor1kx_top_marocchino).
>
> Andrey and I have proposed moving the code to a new repo
> openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
> pipeline swap any longer the name might be controversial.
>
> Does anyone have a objection / suggestion for this?
>

I don't mind. If it's not intended to share any of the components with the
other pipelines then by all means do what's best for the development of
that core.

Looking forward to seeing where this goes!

Cheers,

Julius


>
> -Stafford
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190201/767f3834/attachment-0001.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Julius Baxter]

On Thu, 31 Jan 2019 at 19:52, BAndViG <bandvig@mail.ru> wrote:

> ## Reused Sources ##
>
> To be accurate, MAROCCHINO re-uses the following mor1kx sources:
>
>     mor1kx_cfgrs.v
>     mor1kx-sprs.v
>     mor1kx-defines.v
>     mor1kx_utils.vh
>
> Is it normally to just copy them in new repo? As we change them rarely, I
> think it couldn’t be too hard to keep them synchronized with originals
> from “openrisc/mor1kx”.
>

Agree, it's fine to maintain two copies of this stuff.


>
>
> ## Prefix Replacement ##
>
> I see there are reasons to remove “mor1kx_” prefix from MAROCHCHINO
> sources. I would prefer to replace it with someone suitable rather than to
> just drop it. What about “or1k_”? Or something other?
> Note 1. To keep consistency I think all mentioned above copies of shared
> sources should be renamed (in MAROCHCINO repo). Same to all MAROCCHINO
> modules. I’ll do that if we agree about new prefix.
> Note 2. What about monitor? If I understand correctly Stafford renamed
> instance of mor1kx_cpu_marocchino from “u_cpu_marocchino” to “mor1kx_cpu”
> in MAROCCHINO top exactly to restore compatibility with mor1kx monitor. If
> we drop/replace “mor1kx_” prefix we will lose compatibility with or1k-tests
> suite again.
>
> Andrey
>

I have no preference regarding name but it would be great if we could keep
the test infrastructure as generic as possible. Maybe there's a better way
to do this - ie. provide a file with the appropriate hierarchical paths to
various stuff the monitor will want which is CPU-specific? Then you can
change the internal hierarchy as much as you want. Just a thought.

Cheers,

Julius


>
>
> *From:* Olof Kindgren <olof.kindgren@gmail.com>
> *Sent:* Wednesday, January 30, 2019 12:56 PM
> *To:* Stafford Horne <shorne@gmail.com>
> *Cc:* Openrisc <openrisc@lists.librecores.org> ; Philipp Wagner
> <philipp.wagner@tum.de> ; Julius Baxter <juliusbaxter@gmail.com> ; BAndViG
> <bandvig@mail.ru> ; Stefan Wallentowitz <stefan@fossi-foundation.org>
> *Subject:* Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>
>
>
> On Sun, Jan 27, 2019 at 11:12 AM Stafford Horne <shorne@gmail.com> wrote:
>
>> Hi All,
>>
>> Sorry this mail got a bit long the outline is:
>> - Testing Efforts
>> - Marocchino Pipeline
>> - Proposal to Split Marocchino to new Repo
>>
>> ## Testing Efforts ##
>>
>> Recently I have been working on adding FPU support to GCC.  The GCC
>> generated FPU code is working and running on the simulator, but I have
>> been taking extra time now to verify on iverilog and verilator
>> simulators of mor1kx.  This has gotten me a bit sidetracked to get a
>> CI environment for testing mor1kx cores.  What I have so far is:
>>    - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
>>    - Almost all tests are passing for mor1kx cappuccino pipeline
>> (multiply carry flag is not implemented, so there is one failure)
>>    - Most tests are failing for the Espresso pipeline (Issue with
>> >1clock instructions in delay slots)
>>    - Most tests are failing for the Marocchino pipeline (Its likely an
>> issue with how I implemented the monitor_* signals)
>>
>> TODO
>>   - FPU tests are not run in or1k-tests
>>   - Document test coverage for each pipeline
>>   - CI - Automate testing for each commit/PR
>>   - Confirm debug capabilities, i.e. single-stepping
>>   - Synthesize with Xilinx/Altera toolchains to verify resource
>> usage/budget
>>
>> Not planning todo
>>   - GCC support for no-delay-slot code which would be needed for pronto
>> espresso
>>
>>
> Fantastic! Are you looking at resource usage for CI? In that case it might
> be worth building with yosys instead to avoid a dependency on a commercial
> EDA tool. Even if a synthesis with yosys would require more resources it
> doesn't that much. I guess we are more interested in the varitation between
> builds than any absolute number. It's on my TODO list to add support in the
> Edalize backends for just doing synthesis without P&R. That could be
> helpful in this case too.
>
> And I think you do well in ignoring the or1k-nd versions for now. There
> are likely problems all over the place with that. Would be cool to see if
> espresso is any good though.
>
>
>> ## Marocchino Pipeline ##
>>
>> Which brings us to Marocchino.  Andrey has been working on the
>> Marocchino implementation for a while.  This is a fork of the mor1kx
>> cappuccino pipeline that adds many advanced features like: out of
>> order instruction execution, simplify by reducing parameter options,
>> separate Wishbone and CPU clocks and 64-bit FPU operations via the
>> ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
>> In the end this has turned into a very different internal
>> architecture.
>>
>> Currently the work is all stored in the marocchino_devel branch of mor1kx.
>>
>> ## Proposal to Split Marocchino to new Repo ##
>>
>> As we discussed in a recent PR
>> (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
>> share any code with the rest of mor1kx and even now has a separate top
>> level module (mor1kx_top_marocchino).
>>
>> Andrey and I have proposed moving the code to a new repo
>> openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
>> pipeline swap any longer the name might be controversial.
>>
>> Does anyone have a objection / suggestion for this?
>>
>>
> Exciting to see all the work on Marocchino! I'm fine with the move and
> think it could make sense to drop the mor1kx name for the reasons you
> cited, but I'd leave that up to Andrey.
>
> //Olof
>
>
>> -Stafford
>> _______________________________________________
>> OpenRISC mailing list
>> OpenRISC at lists.librecores.org
>> https://lists.librecores.org/listinfo/openrisc
>>
> WBR
> Andrey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190201/9be1bfac/attachment-0001.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stefan Kristiansson]

I don't mind either, even if some code is taken from mor1kx, if it makes
more sense to have it in a separate repo, go ahead.

On Fri, Feb 1, 2019 at 12:51 PM Julius Baxter <juliusbaxter@gmail.com>
wrote:

>
>
> On Sun, 27 Jan 2019 at 11:11, Stafford Horne <shorne@gmail.com> wrote:
>
>> Hi All,
>>
>> Sorry this mail got a bit long the outline is:
>>  - Testing Efforts
>>  - Marocchino Pipeline
>>  - Proposal to Split Marocchino to new Repo
>>
>> ## Testing Efforts ##
>>
>> Recently I have been working on adding FPU support to GCC.  The GCC
>> generated FPU code is working and running on the simulator, but I have
>> been taking extra time now to verify on iverilog and verilator
>> simulators of mor1kx.  This has gotten me a bit sidetracked to get a
>> CI environment for testing mor1kx cores.  What I have so far is:
>>    - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
>>    - Almost all tests are passing for mor1kx cappuccino pipeline
>> (multiply carry flag is not implemented, so there is one failure)
>>    - Most tests are failing for the Espresso pipeline (Issue with
>> >1clock instructions in delay slots)
>>    - Most tests are failing for the Marocchino pipeline (Its likely an
>> issue with how I implemented the monitor_* signals)
>>
>
> Hi Stafford,
>
> Great job - integrating this into a CI flow would be very nice indeed.
>
>
>>
>> TODO
>>   - FPU tests are not run in or1k-tests
>>   - Document test coverage for each pipeline
>>   - CI - Automate testing for each commit/PR
>>   - Confirm debug capabilities, i.e. single-stepping
>>   - Synthesize with Xilinx/Altera toolchains to verify resource
>> usage/budget
>>
>> Not planning todo
>>   - GCC support for no-delay-slot code which would be needed for pronto
>> espresso
>>
>
> Yep, fair enough.
>
>
>>
>> ## Marocchino Pipeline ##
>>
>> Which brings us to Marocchino.  Andrey has been working on the
>> Marocchino implementation for a while.  This is a fork of the mor1kx
>> cappuccino pipeline that adds many advanced features like: out of
>> order instruction execution, simplify by reducing parameter options,
>> separate Wishbone and CPU clocks and 64-bit FPU operations via the
>> ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
>> In the end this has turned into a very different internal
>> architecture.
>>
>> Currently the work is all stored in the marocchino_devel branch of mor1kx.
>>
>
> This sounds great! Does CoreMark run on it yet? How much of a speedup have
> you achieved so far?
>
>
>>
>> ## Proposal to Split Marocchino to new Repo ##
>>
>> As we discussed in a recent PR
>> (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
>> share any code with the rest of mor1kx and even now has a separate top
>> level module (mor1kx_top_marocchino).
>>
>> Andrey and I have proposed moving the code to a new repo
>> openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
>> pipeline swap any longer the name might be controversial.
>>
>> Does anyone have a objection / suggestion for this?
>>
>
> I don't mind. If it's not intended to share any of the components with the
> other pipelines then by all means do what's best for the development of
> that core.
>
> Looking forward to seeing where this goes!
>
> Cheers,
>
> Julius
>
>
>>
>> -Stafford
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190201/ce136405/attachment.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

On Fri, Feb 01, 2019 at 12:09:22PM +0100, Julius Baxter wrote:
> On Thu, 31 Jan 2019 at 19:52, BAndViG <bandvig@mail.ru> wrote:
> 
> > ## Reused Sources ##
> >
> > To be accurate, MAROCCHINO re-uses the following mor1kx sources:
> >
> >     mor1kx_cfgrs.v
> >     mor1kx-sprs.v
> >     mor1kx-defines.v
> >     mor1kx_utils.vh
> >
> > Is it normally to just copy them in new repo? As we change them rarely, I
> > think it couldn’t be too hard to keep them synchronized with originals
> > from “openrisc/mor1kx”.
> >
> 
> Agree, it's fine to maintain two copies of this stuff.
> 
> 
> >
> >
> > ## Prefix Replacement ##
> >
> > I see there are reasons to remove “mor1kx_” prefix from MAROCHCHINO
> > sources. I would prefer to replace it with someone suitable rather than to
> > just drop it. What about “or1k_”? Or something other?
> > Note 1. To keep consistency I think all mentioned above copies of shared
> > sources should be renamed (in MAROCHCINO repo). Same to all MAROCCHINO
> > modules. I’ll do that if we agree about new prefix.
> > Note 2. What about monitor? If I understand correctly Stafford renamed
> > instance of mor1kx_cpu_marocchino from “u_cpu_marocchino” to “mor1kx_cpu”
> > in MAROCCHINO top exactly to restore compatibility with mor1kx monitor. If
> > we drop/replace “mor1kx_” prefix we will lose compatibility with or1k-tests
> > suite again.
> >
> > Andrey
> >
> 
> I have no preference regarding name but it would be great if we could keep
> the test infrastructure as generic as possible. Maybe there's a better way
> to do this - ie. provide a file with the appropriate hierarchical paths to
> various stuff the monitor will want which is CPU-specific? Then you can
> change the internal hierarchy as much as you want. Just a thought.

I changed the name of the instance to mor1kx_cpu to be able to use the
mor1x_monitor without any changes when switching core implementations during
testing.

I think the right way to do monitoring will be to use the new traceport_*
signals to monitor processor execution (there is already an implementation of
monitor that does that).  The traceport implementation will not require
inspecting internal signals as is done with the current mor1kx_monitor.

Its here:
  bench/verilog/mor1kx_monitor.v           - traditional monitor
  bench/verilog/mor1kx_traceport_monitor.v - traceport_based monitor

Also, since marocchino has out-of-order execution its a bit tricky to have a
monitor the way its done in cappuccino.  In cappuccino or espresso we can just
watch the input/output of the execution stage to see the executing instruction, pc
and result.   With marocchino we have multiple execution units that can all
be running at the same time.  I will need Andrey's help for how to generate the
traceport signals from the marocchino.

For illustration purposes these are the traceport signals and definitions.
These were introduced by Stefan Wallentowitz to use with the Open SoC debug
project.

   output        traceport_exec_valid;   - (sync) pc and insn are valid, if
                                           there is a register result this
                                           signal and `traceport_exec_wben`
                                           will be high at the same time.
   output [31:0] traceport_exec_pc;      - the executed pc
   output [31:0] traceport_exec_insn;    - the executed instruction
   output        traceport_exec_wben;    - (sync) register result is valid. If
                                           this signal is not high when
                                           `traceport_exec_valid` is high the
                                           instruction has no result.
                                           There is no interface to read
                                           arbitrary registers but this can be
                                           achieved by capturing results as they
                                           are returned by the traceport.
   output [31:0] traceport_exec_wbdata;  - the register contents
   output [5:0]  traceport_exec_wbreg;   - the register address

-Stafford

> 
> 
> >
> >
> > *From:* Olof Kindgren <olof.kindgren@gmail.com>
> > *Sent:* Wednesday, January 30, 2019 12:56 PM
> > *To:* Stafford Horne <shorne@gmail.com>
> > *Cc:* Openrisc <openrisc@lists.librecores.org> ; Philipp Wagner
> > <philipp.wagner@tum.de> ; Julius Baxter <juliusbaxter@gmail.com> ; BAndViG
> > <bandvig@mail.ru> ; Stefan Wallentowitz <stefan@fossi-foundation.org>
> > *Subject:* Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
> >
> >
> >
> > On Sun, Jan 27, 2019 at 11:12 AM Stafford Horne <shorne@gmail.com> wrote:
> >
> >> Hi All,
> >>
> >> Sorry this mail got a bit long the outline is:
> >> - Testing Efforts
> >> - Marocchino Pipeline
> >> - Proposal to Split Marocchino to new Repo
> >>
> >> ## Testing Efforts ##
> >>
> >> Recently I have been working on adding FPU support to GCC.  The GCC
> >> generated FPU code is working and running on the simulator, but I have
> >> been taking extra time now to verify on iverilog and verilator
> >> simulators of mor1kx.  This has gotten me a bit sidetracked to get a
> >> CI environment for testing mor1kx cores.  What I have so far is:
> >>    - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
> >>    - Almost all tests are passing for mor1kx cappuccino pipeline
> >> (multiply carry flag is not implemented, so there is one failure)
> >>    - Most tests are failing for the Espresso pipeline (Issue with
> >> >1clock instructions in delay slots)
> >>    - Most tests are failing for the Marocchino pipeline (Its likely an
> >> issue with how I implemented the monitor_* signals)
> >>
> >> TODO
> >>   - FPU tests are not run in or1k-tests
> >>   - Document test coverage for each pipeline
> >>   - CI - Automate testing for each commit/PR
> >>   - Confirm debug capabilities, i.e. single-stepping
> >>   - Synthesize with Xilinx/Altera toolchains to verify resource
> >> usage/budget
> >>
> >> Not planning todo
> >>   - GCC support for no-delay-slot code which would be needed for pronto
> >> espresso
> >>
> >>
> > Fantastic! Are you looking at resource usage for CI? In that case it might
> > be worth building with yosys instead to avoid a dependency on a commercial
> > EDA tool. Even if a synthesis with yosys would require more resources it
> > doesn't that much. I guess we are more interested in the varitation between
> > builds than any absolute number. It's on my TODO list to add support in the
> > Edalize backends for just doing synthesis without P&R. That could be
> > helpful in this case too.
> >
> > And I think you do well in ignoring the or1k-nd versions for now. There
> > are likely problems all over the place with that. Would be cool to see if
> > espresso is any good though.
> >
> >
> >> ## Marocchino Pipeline ##
> >>
> >> Which brings us to Marocchino.  Andrey has been working on the
> >> Marocchino implementation for a while.  This is a fork of the mor1kx
> >> cappuccino pipeline that adds many advanced features like: out of
> >> order instruction execution, simplify by reducing parameter options,
> >> separate Wishbone and CPU clocks and 64-bit FPU operations via the
> >> ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
> >> In the end this has turned into a very different internal
> >> architecture.
> >>
> >> Currently the work is all stored in the marocchino_devel branch of mor1kx.
> >>
> >> ## Proposal to Split Marocchino to new Repo ##
> >>
> >> As we discussed in a recent PR
> >> (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
> >> share any code with the rest of mor1kx and even now has a separate top
> >> level module (mor1kx_top_marocchino).
> >>
> >> Andrey and I have proposed moving the code to a new repo
> >> openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
> >> pipeline swap any longer the name might be controversial.
> >>
> >> Does anyone have a objection / suggestion for this?
> >>
> >>
> > Exciting to see all the work on Marocchino! I'm fine with the move and
> > think it could make sense to drop the mor1kx name for the reasons you
> > cited, but I'd leave that up to Andrey.
> >
> > //Olof
> >
> >
> >> -Stafford
> >> _______________________________________________
> >> OpenRISC mailing list
> >> OpenRISC at lists.librecores.org
> >> https://lists.librecores.org/listinfo/openrisc
> >>
> > WBR
> > Andrey
> >

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

Hi julius

On Fri, Feb 01, 2019 at 11:51:26AM +0100, Julius Baxter wrote:
> On Sun, 27 Jan 2019 at 11:11, Stafford Horne <shorne@gmail.com> wrote:
...
> > ## Marocchino Pipeline ##
> >
> > Which brings us to Marocchino.  Andrey has been working on the
> > Marocchino implementation for a while.  This is a fork of the mor1kx
> > cappuccino pipeline that adds many advanced features like: out of
> > order instruction execution, simplify by reducing parameter options,
> > separate Wishbone and CPU clocks and 64-bit FPU operations via the
> > ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
> > In the end this has turned into a very different internal
> > architecture.
> >
> > Currently the work is all stored in the marocchino_devel branch of mor1kx.
> >
> 
> This sounds great! Does CoreMark run on it yet? How much of a speedup have
> you achieved so far?

I have not run it yet as I am still trying to get the basic tests to pass.  Once
that is working ill move onto the bigger tests like coremark and testfloat.

Andrey might have some results.

> >
> > ## Proposal to Split Marocchino to new Repo ##
> >
> > As we discussed in a recent PR
> > (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
> > share any code with the rest of mor1kx and even now has a separate top
> > level module (mor1kx_top_marocchino).
> >
> > Andrey and I have proposed moving the code to a new repo
> > openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
> > pipeline swap any longer the name might be controversial.
> >
> > Does anyone have a objection / suggestion for this?
> >
> 
> I don't mind. If it's not intended to share any of the components with the
> other pipelines then by all means do what's best for the development of
> that core.
> 
> Looking forward to seeing where this goes!

Me too, this OOO core code quality and design is very nice and it will be good
to give it the proper exposure it deserves.

-Stafford

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

Hi Olof,

On Wed, Jan 30, 2019 at 10:56:42AM +0100, Olof Kindgren wrote:
> On Sun, Jan 27, 2019 at 11:12 AM Stafford Horne <shorne@gmail.com> wrote:
> 
> > Hi All,
> >
> > Sorry this mail got a bit long the outline is:
> >  - Testing Efforts
> >  - Marocchino Pipeline
> >  - Proposal to Split Marocchino to new Repo
> >
> > ## Testing Efforts ##
> >
> > Recently I have been working on adding FPU support to GCC.  The GCC
> > generated FPU code is working and running on the simulator, but I have
> > been taking extra time now to verify on iverilog and verilator
> > simulators of mor1kx.  This has gotten me a bit sidetracked to get a
> > CI environment for testing mor1kx cores.  What I have so far is:
> >    - Using mor1kx + mor1kx-generic + or1k-tests to run the tests
> >    - Almost all tests are passing for mor1kx cappuccino pipeline
> > (multiply carry flag is not implemented, so there is one failure)
> >    - Most tests are failing for the Espresso pipeline (Issue with
> > >1clock instructions in delay slots)
> >    - Most tests are failing for the Marocchino pipeline (Its likely an
> > issue with how I implemented the monitor_* signals)
> >
> > TODO
> >   - FPU tests are not run in or1k-tests
> >   - Document test coverage for each pipeline
> >   - CI - Automate testing for each commit/PR
> >   - Confirm debug capabilities, i.e. single-stepping
> >   - Synthesize with Xilinx/Altera toolchains to verify resource
> > usage/budget
> >
> > Not planning todo
> >   - GCC support for no-delay-slot code which would be needed for pronto
> > espresso
> >
> >
> Fantastic! Are you looking at resource usage for CI? In that case it might
> be worth building with yosys instead to avoid a dependency on a commercial
> EDA tool. Even if a synthesis with yosys would require more resources it
> doesn't that much. I guess we are more interested in the varitation between
> builds than any absolute number. It's on my TODO list to add support in the
> Edalize backends for just doing synthesis without P&R. That could be
> helpful in this case too.

Thats a good idea, I was thinking to do xilinx, altera and yosys to get relative
resource usages, but thats probably flying too close to the sun.  Yosys alone
should be good for now.

> And I think you do well in ignoring the or1k-nd versions for now. There are
> likely problems all over the place with that. Would be cool to see if
> espresso is any good though.

I have been having problems with espresso around delay slots.  It seems to not
be able to properly advance if the instruction in the delay slot takes more
than 1 clock.

-Stafford

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[BAndViG]

Thanks for good words, Stafford.

Before speaking about performance I should make two notes.

First, I had to to add additional stages in IFETCH and LSU and remove 
forwarding multiplexors at execution units inputs to achieve 100 MHz CPU clock 
on Spartan-6 LX45 (Atlys board). Additionally, pseudo clock domain crossing 
synchronizations were added between CPU and Wishbone clock domains. As a 
result, MAROCCHINO demonstrates higher "Iterations/Sec" with higher CPU clocks 
and lower "Iterations/1-million-clocks" ((Iterations/Sec)/CPU_clock_MHz).

Second. Initially, I implemented GPRs as set of four RAM-blocks to provide 
{rX,rX+1} access to 64-bit operands for ORFPX64A32 extension. However, to meet 
GCC9 ABI ({rX,rX+2} access for 64-bit operands) I had to replace RAM-blocks by 
set of Flip-Flop based register. MAROCCHINO had become much larger and only 75 
MHz CPU clock could be achieved now. The included 100 MHz Coremark results were 
measured on previous MAROCCHINO version (with RAM-based GPRs). Of course, 
particular GPRs implementation itself doesn't affect Coremark digits.

The Coremark results (CAPPUCCINO and MAROCCINO both configured with pipelined 
multiplier, serial divider, l.cmov, l.sra, l.ror and l.ffl1 enabled; toolchain 
is GCC-5.4.0 based, NewLIB compiled with support of all enabled hardware 
feature) are:

Iterations       : 2000

Compiler flags 
  : -O2 -funroll-loops -fgcse-sm -mboard=atlys -flto -DPERFORMANCE_RUN=1 -flto

                    Iterations/Sec    Iterations/1M-clocks
CAPPUCCINO  50MHz:     123.915737              2.47
MAROCCHINO  50MHz:      81.833061              1.63
MAROCCHINO  75MHz:     122.174706              1.62
MAROCCHINO 100MHz:     160.000000              1.60


Compiler flags   : -O2 -mboard=atlys -flto -DVALIDATION_RUN=1 -flto

                    Iterations/Sec    Iterations/1M-clocks
CAPPUCCINO  50MHz:     109.051254              2.18
MAROCCHINO  50MHz:      72.254333              1.44
MAROCCHINO  75MHz:     107.991356              1.43
MAROCCHINO 100MHz:     142.247513              1.42

Andrey


From: Stafford Horne
Sent: Saturday, February 02, 2019 2:06 AM
To: Julius Baxter
Cc: Philipp Wagner ; Openrisc ; BAndViG ; Stefan Wallentowitz
Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo

Hi julius

On Fri, Feb 01, 2019 at 11:51:26AM +0100, Julius Baxter wrote:
> On Sun, 27 Jan 2019 at 11:11, Stafford Horne <shorne@gmail.com> wrote:
...
> > ## Marocchino Pipeline ##
> >
> > Which brings us to Marocchino.  Andrey has been working on the
> > Marocchino implementation for a while.  This is a fork of the mor1kx
> > cappuccino pipeline that adds many advanced features like: out of
> > order instruction execution, simplify by reducing parameter options,
> > separate Wishbone and CPU clocks and 64-bit FPU operations via the
> > ORFPX64A32 (https://openrisc.io/proposals/orfpx64a32) specification.
> > In the end this has turned into a very different internal
> > architecture.
> >
> > Currently the work is all stored in the marocchino_devel branch of mor1kx.
> >
>
> This sounds great! Does CoreMark run on it yet? How much of a speedup have
> you achieved so far?

I have not run it yet as I am still trying to get the basic tests to pass. 
Once
that is working ill move onto the bigger tests like coremark and testfloat.

Andrey might have some results.

> >
> > ## Proposal to Split Marocchino to new Repo ##
> >
> > As we discussed in a recent PR
> > (https://github.com/openrisc/mor1kx/pull/72) marocchino doesn't really
> > share any code with the rest of mor1kx and even now has a separate top
> > level module (mor1kx_top_marocchino).
> >
> > Andrey and I have proposed moving the code to a new repo
> > openrisc/mor1kx_marocchino.  Though it's not really exactly a mor1kx
> > pipeline swap any longer the name might be controversial.
> >
> > Does anyone have a objection / suggestion for this?
> >
>
> I don't mind. If it's not intended to share any of the components with the
> other pipelines then by all means do what's best for the development of
> that core.
>
> Looking forward to seeing where this goes!

Me too, this OOO core code quality and design is very nice and it will be good
to give it the proper exposure it deserves.

-Stafford
_______________________________________________
OpenRISC mailing list
OpenRISC at lists.librecores.org
https://lists.librecores.org/listinfo/openrisc

WBR
Andrey 

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[BAndViG]

Hi all

I've created MAROCCHINO new repo under my GitHub account 
(https://github.com/bandvig/or1k_marocchino) as a demo version.
Pay attention that monitors still have "mor1kx_" prefix and or1k_marocchino_cpu 
instance still called "mor1kx_cpu" to maintain compatibility with current 
verification infrastructure.
Please, make comments and proposals.
I'm planning to continue development in the repo as its structure will be 
approved. Btw, I'm not sure that it should be forked into OR organization. I 
think it would be clearer to create new repo and fill it. I could do that by 
myself If I've got write access to OR organization account (not sure). Or 
anybody welcome to do that.

WBR
Andrey


From: Stafford Horne
Sent: Saturday, February 02, 2019 12:54 AM
To: Julius Baxter
Cc: BAndViG ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan Wallentowitz
Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo

I changed the name of the instance to mor1kx_cpu to be able to use the
mor1x_monitor without any changes when switching core implementations during
testing.

I think the right way to do monitoring will be to use the new traceport_*
signals to monitor processor execution (there is already an implementation of
monitor that does that).  The traceport implementation will not require
inspecting internal signals as is done with the current mor1kx_monitor.

Its here:
  bench/verilog/mor1kx_monitor.v           - traditional monitor
  bench/verilog/mor1kx_traceport_monitor.v - traceport_based monitor
...

-Stafford

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

Hello,



On Wed, Feb 27, 2019, 4:25 AM BAndViG <bandvig@mail.ru> wrote:

> Hi all
>
> I've created MAROCCHINO new repo under my GitHub account
> (https://github.com/bandvig/or1k_marocchino) as a demo version.
>

This looks good.

Pay attention that monitors still have "mor1kx_" prefix and
> or1k_marocchino_cpu
> instance still called "mor1kx_cpu" to maintain compatibility with current
> verification infrastructure.
>

I think we can change this now. As long as we have:

bench <https://github.com/bandvig/or1k_marocchino/tree/master/bench>/verilog
<https://github.com/bandvig/or1k_marocchino/tree/master/bench/verilog>/
mor1kx_monitor

We can define internals as we like.  Before we we're trying to share so we
needed to use the same name.


Please, make comments and proposals.
>

Some comments.
 - let's put a style guide in the readme
 - can we split modules to separate files? I.e. or1k_marocchino_execute.v
and or1k_marocchino_oman.v have some interesting modules I think would make
sense to be on their own for.  Not everything needs to be split , but at
least each execution unit and the RAT modules.
  - I created a diagram on the pipeline dependencies. You then explained
some things  more clearly.  I'll try to put it on the wiki or in the repo.

I'm planning to continue development in the repo as its structure will be
> approved. Btw, I'm not sure that it should be forked into OR organization.
> I
> think it would be clearer to create new repo and fill it. I could do that
> by
> myself If I've got write access to OR organization account (not sure). Or
> anybody welcome to do that.
>

I think having it the openrisc org repo would be good.  Let me see if I can
clone it in and give you access.  If not I'll ask for help.

-stafford


> WBR
> Andrey
>
>
> From: Stafford Horne
> Sent: Saturday, February 02, 2019 12:54 AM
> To: Julius Baxter
> Cc: BAndViG ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan
> Wallentowitz
> Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>
> I changed the name of the instance to mor1kx_cpu to be able to use the
> mor1x_monitor without any changes when switching core implementations
> during
> testing.
>
> I think the right way to do monitoring will be to use the new traceport_*
> signals to monitor processor execution (there is already an implementation
> of
> monitor that does that).  The traceport implementation will not require
> inspecting internal signals as is done with the current mor1kx_monitor.
>
> Its here:
>   bench/verilog/mor1kx_monitor.v           - traditional monitor
>   bench/verilog/mor1kx_traceport_monitor.v - traceport_based monitor
> ...
>
> -Stafford
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190301/084a9083/attachment.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

Hello,

I worked or1k_marocchino to the openrisc org.  You sold have access too.

-stafford

On Fri, Mar 1, 2019, 8:33 AM Stafford Horne <shorne@gmail.com> wrote:

> Hello,
>
>
>
> On Wed, Feb 27, 2019, 4:25 AM BAndViG <bandvig@mail.ru> wrote:
>
>> Hi all
>>
>> I've created MAROCCHINO new repo under my GitHub account
>> (https://github.com/bandvig/or1k_marocchino) as a demo version.
>>
>
> This looks good.
>
> Pay attention that monitors still have "mor1kx_" prefix and
>> or1k_marocchino_cpu
>> instance still called "mor1kx_cpu" to maintain compatibility with current
>> verification infrastructure.
>>
>
> I think we can change this now. As long as we have:
>
> bench <https://github.com/bandvig/or1k_marocchino/tree/master/bench>/
> verilog
> <https://github.com/bandvig/or1k_marocchino/tree/master/bench/verilog>/
> mor1kx_monitor
>
> We can define internals as we like.  Before we we're trying to share so we
> needed to use the same name.
>
>
> Please, make comments and proposals.
>>
>
> Some comments.
>  - let's put a style guide in the readme
>  - can we split modules to separate files? I.e. or1k_marocchino_execute.v
> and or1k_marocchino_oman.v have some interesting modules I think would make
> sense to be on their own for.  Not everything needs to be split , but at
> least each execution unit and the RAT modules.
>   - I created a diagram on the pipeline dependencies. You then explained
> some things  more clearly.  I'll try to put it on the wiki or in the repo.
>
> I'm planning to continue development in the repo as its structure will be
>> approved. Btw, I'm not sure that it should be forked into OR
>> organization. I
>> think it would be clearer to create new repo and fill it. I could do that
>> by
>> myself If I've got write access to OR organization account (not sure). Or
>> anybody welcome to do that.
>>
>
> I think having it the openrisc org repo would be good.  Let me see if I
> can clone it in and give you access.  If not I'll ask for help.
>
> -stafford
>
>
>> WBR
>> Andrey
>>
>>
>> From: Stafford Horne
>> Sent: Saturday, February 02, 2019 12:54 AM
>> To: Julius Baxter
>> Cc: BAndViG ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan
>> Wallentowitz
>> Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>>
>> I changed the name of the instance to mor1kx_cpu to be able to use the
>> mor1x_monitor without any changes when switching core implementations
>> during
>> testing.
>>
>> I think the right way to do monitoring will be to use the new traceport_*
>> signals to monitor processor execution (there is already an
>> implementation of
>> monitor that does that).  The traceport implementation will not require
>> inspecting internal signals as is done with the current mor1kx_monitor.
>>
>> Its here:
>>   bench/verilog/mor1kx_monitor.v           - traditional monitor
>>   bench/verilog/mor1kx_traceport_monitor.v - traceport_based monitor
>> ...
>>
>> -Stafford
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190302/a1fb737b/attachment.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[BAndViG]

I’ve prepared commit with extended Readme.md and extracting some modules into  separate files, but I haven’t got access to push it (permission denied).

-Andrey

From: Stafford Horne 
Sent: Saturday, March 02, 2019 11:36 AM
To: BAndViG 
Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan Wallentowitz 
Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo

Hello,  

I worked or1k_marocchino to the openrisc org.  You sold have access too.

-stafford

On Fri, Mar 1, 2019, 8:33 AM Stafford Horne <shorne@gmail.com> wrote:

  Hello, 




  On Wed, Feb 27, 2019, 4:25 AM BAndViG <bandvig@mail.ru> wrote:

    Hi all

    I've created MAROCCHINO new repo under my GitHub account 
    (https://github.com/bandvig/or1k_marocchino) as a demo version.


  This looks good.

    Pay attention that monitors still have "mor1kx_" prefix and or1k_marocchino_cpu 
    instance still called "mor1kx_cpu" to maintain compatibility with current 
    verification infrastructure.


  I think we can change this now. As long as we have:

  bench/verilog/mor1kx_monitor


  We can define internals as we like.  Before we we're trying to share so we needed to use the same name.


    Please, make comments and proposals.


  Some comments.
  - let's put a style guide in the readme
  - can we split modules to separate files? I.e. or1k_marocchino_execute.v and or1k_marocchino_oman.v have some interesting modules I think would make sense to be on their own for.  Not everything needs to be split , but at least each execution unit and the RAT modules.
    - I created a diagram on the pipeline dependencies. You then explained some things  more clearly.  I'll try to put it on the wiki or in the repo.

    I'm planning to continue development in the repo as its structure will be 
    approved. Btw, I'm not sure that it should be forked into OR organization. I 
    think it would be clearer to create new repo and fill it. I could do that by 
    myself If I've got write access to OR organization account (not sure). Or 
    anybody welcome to do that.


  I think having it the openrisc org repo would be good.  Let me see if I can clone it in and give you access.  If not I'll ask for help.

  -stafford
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190302/90df0aef/attachment.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

I think I fixed it.  Can you try again?

On Sun, Mar 3, 2019 at 12:29 AM BAndViG <bandvig@mail.ru> wrote:
>
> I’ve prepared commit with extended Readme.md and extracting some modules into  separate files, but I haven’t got access to push it (permission denied).
>
> -Andrey
>
> From: Stafford Horne
> Sent: Saturday, March 02, 2019 11:36 AM
> To: BAndViG
> Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan Wallentowitz
> Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>
> Hello,
>
> I worked or1k_marocchino to the openrisc org.  You sold have access too.
>
> -stafford
>
> On Fri, Mar 1, 2019, 8:33 AM Stafford Horne <shorne@gmail.com> wrote:
>>
>> Hello,
>>
>>
>>
>> On Wed, Feb 27, 2019, 4:25 AM BAndViG <bandvig@mail.ru> wrote:
>>>
>>> Hi all
>>>
>>> I've created MAROCCHINO new repo under my GitHub account
>>> (https://github.com/bandvig/or1k_marocchino) as a demo version.
>>
>>
>> This looks good.
>>
>>>
>>> Pay attention that monitors still have "mor1kx_" prefix and or1k_marocchino_cpu
>>> instance still called "mor1kx_cpu" to maintain compatibility with current
>>> verification infrastructure.
>>
>>
>> I think we can change this now. As long as we have:
>>
>> bench/verilog/mor1kx_monitor
>>
>> We can define internals as we like.  Before we we're trying to share so we needed to use the same name.
>>
>>
>>>
>>> Please, make comments and proposals.
>>
>>
>> Some comments.
>> - let's put a style guide in the readme
>> - can we split modules to separate files? I.e. or1k_marocchino_execute.v and or1k_marocchino_oman.v have some interesting modules I think would make sense to be on their own for.  Not everything needs to be split , but at least each execution unit and the RAT modules.
>>   - I created a diagram on the pipeline dependencies. You then explained some things  more clearly.  I'll try to put it on the wiki or in the repo.
>>
>>>
>>> I'm planning to continue development in the repo as its structure will be
>>> approved. Btw, I'm not sure that it should be forked into OR organization. I
>>> think it would be clearer to create new repo and fill it. I could do that by
>>> myself If I've got write access to OR organization account (not sure). Or
>>> anybody welcome to do that.
>>
>>
>> I think having it the openrisc org repo would be good.  Let me see if I can clone it in and give you access.  If not I'll ask for help.
>>
>> -stafford

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[BAndViG]

Thanks, Stafford. Now it works. I've pushed my update.

As I'm not familiar with ordinary OpenRISC verification environment I've left 
monitor related things for you.
I see that
`define CPU_WRAPPER `MOR1KX_INST.mor1kx_cpu
could be treated as internals, but MOR1KX_INST itself is obviously not.
As you find free time let's modify monitor in the way you planned.


From: Stafford Horne
Sent: Sunday, March 03, 2019 1:06 AM
To: BAndViG
Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan 
Wallentowitz
Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo

I think I fixed it.  Can you try again?

On Sun, Mar 3, 2019 at 12:29 AM BAndViG <bandvig@mail.ru> wrote:
>
> I’ve prepared commit with extended Readme.md and extracting some modules into 
> separate files, but I haven’t got access to push it (permission denied).
>
> -Andrey
>
> From: Stafford Horne
> Sent: Saturday, March 02, 2019 11:36 AM
> To: BAndViG
> Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan 
> Wallentowitz
> Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>
> Hello,
>
> I worked or1k_marocchino to the openrisc org.  You sold have access too.
>
> -stafford
>
> On Fri, Mar 1, 2019, 8:33 AM Stafford Horne <shorne@gmail.com> wrote:
>>
>> Hello,
>>
>>
>>
>> On Wed, Feb 27, 2019, 4:25 AM BAndViG <bandvig@mail.ru> wrote:
>>>
>>> Hi all
>>>
>>> I've created MAROCCHINO new repo under my GitHub account
>>> (https://github.com/bandvig/or1k_marocchino) as a demo version.
>>
>>
>> This looks good.
>>
>>>
>>> Pay attention that monitors still have "mor1kx_" prefix and 
>>> or1k_marocchino_cpu
>>> instance still called "mor1kx_cpu" to maintain compatibility with current
>>> verification infrastructure.
>>
>>
>> I think we can change this now. As long as we have:
>>
>> bench/verilog/mor1kx_monitor
>>
>> We can define internals as we like.  Before we we're trying to share so we 
>> needed to use the same name.
>>
>>
>>>
>>> Please, make comments and proposals.
>>
>>
>> Some comments.
>> - let's put a style guide in the readme
>> - can we split modules to separate files? I.e. or1k_marocchino_execute.v and 
>> or1k_marocchino_oman.v have some interesting modules I think would make 
>> sense to be on their own for.  Not everything needs to be split , but at 
>> least each execution unit and the RAT modules.
>>   - I created a diagram on the pipeline dependencies. You then explained 
>> some things  more clearly.  I'll try to put it on the wiki or in the repo.
>>
>>>
>>> I'm planning to continue development in the repo as its structure will be
>>> approved. Btw, I'm not sure that it should be forked into OR organization. 
>>> I
>>> think it would be clearer to create new repo and fill it. I could do that 
>>> by
>>> myself If I've got write access to OR organization account (not sure). Or
>>> anybody welcome to do that.
>>
>>
>> I think having it the openrisc org repo would be good.  Let me see if I can 
>> clone it in and give you access.  If not I'll ask for help.
>>
>> -stafford

WBR
Andrey 

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

Hello,

That looks good.

I will work on getting travis ci integrated to marocchino.  Then let's work
on the issues in the tool chain fpu support and get those patches into gcc
and binutils.

FYI, I finished the basic tests support in mor1kx.  So it should be easy to
get into marocchino.  You can see here.  I'll clean up the patches and make
a PR.

https://travis-ci.org/stffrdhrn/mor1kx

We do a few tests now including iterations where we disable
  - immu
  - icache
  - dmmu
  - dcache
  - debug unit
  - cmov instruction
  - ext instructions

Turning those flags off uncovered some bugs in the tests and mor1kx which I
have now fixed. The tests take about 10 minutes to run.

Espresso still has a few failures. Also there are more types of tests I
would like to add. I am hoping to get help on it.

-Stafford


On Sun, Mar 3, 2019, 4:06 PM BAndViG <bandvig@mail.ru> wrote:

> Thanks, Stafford. Now it works. I've pushed my update.
>
> As I'm not familiar with ordinary OpenRISC verification environment I've
> left
> monitor related things for you.
> I see that
> `define CPU_WRAPPER `MOR1KX_INST.mor1kx_cpu
> could be treated as internals, but MOR1KX_INST itself is obviously not.
> As you find free time let's modify monitor in the way you planned.
>
>
> From: Stafford Horne
> Sent: Sunday, March 03, 2019 1:06 AM
> To: BAndViG
> Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan
> Wallentowitz
> Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>
> I think I fixed it.  Can you try again?
>
> On Sun, Mar 3, 2019 at 12:29 AM BAndViG <bandvig@mail.ru> wrote:
> >
> > I’ve prepared commit with extended Readme.md and extracting some modules
> into
> > separate files, but I haven’t got access to push it (permission denied).
> >
> > -Andrey
> >
> > From: Stafford Horne
> > Sent: Saturday, March 02, 2019 11:36 AM
> > To: BAndViG
> > Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan
> > Wallentowitz
> > Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
> >
> > Hello,
> >
> > I worked or1k_marocchino to the openrisc org.  You sold have access too.
> >
> > -stafford
> >
> > On Fri, Mar 1, 2019, 8:33 AM Stafford Horne <shorne@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >>
> >>
> >> On Wed, Feb 27, 2019, 4:25 AM BAndViG <bandvig@mail.ru> wrote:
> >>>
> >>> Hi all
> >>>
> >>> I've created MAROCCHINO new repo under my GitHub account
> >>> (https://github.com/bandvig/or1k_marocchino) as a demo version.
> >>
> >>
> >> This looks good.
> >>
> >>>
> >>> Pay attention that monitors still have "mor1kx_" prefix and
> >>> or1k_marocchino_cpu
> >>> instance still called "mor1kx_cpu" to maintain compatibility with
> current
> >>> verification infrastructure.
> >>
> >>
> >> I think we can change this now. As long as we have:
> >>
> >> bench/verilog/mor1kx_monitor
> >>
> >> We can define internals as we like.  Before we we're trying to share so
> we
> >> needed to use the same name.
> >>
> >>
> >>>
> >>> Please, make comments and proposals.
> >>
> >>
> >> Some comments.
> >> - let's put a style guide in the readme
> >> - can we split modules to separate files? I.e.
> or1k_marocchino_execute.v and
> >> or1k_marocchino_oman.v have some interesting modules I think would make
> >> sense to be on their own for.  Not everything needs to be split , but
> at
> >> least each execution unit and the RAT modules.
> >>   - I created a diagram on the pipeline dependencies. You then
> explained
> >> some things  more clearly.  I'll try to put it on the wiki or in the
> repo.
> >>
> >>>
> >>> I'm planning to continue development in the repo as its structure will
> be
> >>> approved. Btw, I'm not sure that it should be forked into OR
> organization.
> >>> I
> >>> think it would be clearer to create new repo and fill it. I could do
> that
> >>> by
> >>> myself If I've got write access to OR organization account (not sure).
> Or
> >>> anybody welcome to do that.
> >>
> >>
> >> I think having it the openrisc org repo would be good.  Let me see if I
> can
> >> clone it in and give you access.  If not I'll ask for help.
> >>
> >> -stafford
>
> WBR
> Andrey
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20190306/a5ad6792/attachment.html>

[OpenRISC] [RFC] Splitting out Marocchino to new Repo

[Stafford Horne]

Hello,

A quick update, the CI for or1k_marocchino is now working.  You can
see the travis results here:
https://travis-ci.com/openrisc/or1k_marocchino/jobs/185460408
 (similar to what we see with mor1kx).

I started to compare my simulator (or1k-elf-run) results of the FPU vs
marocchino.  I saw an issue yesterday, but still working on figuring
out what it is.

-Stafford

On Wed, Mar 6, 2019 at 8:01 AM Stafford Horne <shorne@gmail.com> wrote:
>
> Hello,
>
> That looks good.
>
> I will work on getting travis ci integrated to marocchino.  Then let's work on the issues in the tool chain fpu support and get those patches into gcc and binutils.
>
> FYI, I finished the basic tests support in mor1kx.  So it should be easy to get into marocchino.  You can see here.  I'll clean up the patches and make a PR.
>
> https://travis-ci.org/stffrdhrn/mor1kx
>
> We do a few tests now including iterations where we disable
>   - immu
>   - icache
>   - dmmu
>   - dcache
>   - debug unit
>   - cmov instruction
>   - ext instructions
>
> Turning those flags off uncovered some bugs in the tests and mor1kx which I have now fixed. The tests take about 10 minutes to run.
>
> Espresso still has a few failures. Also there are more types of tests I would like to add. I am hoping to get help on it.
>
> -Stafford
>
>
> On Sun, Mar 3, 2019, 4:06 PM BAndViG <bandvig@mail.ru> wrote:
>>
>> Thanks, Stafford. Now it works. I've pushed my update.
>>
>> As I'm not familiar with ordinary OpenRISC verification environment I've left
>> monitor related things for you.
>> I see that
>> `define CPU_WRAPPER `MOR1KX_INST.mor1kx_cpu
>> could be treated as internals, but MOR1KX_INST itself is obviously not.
>> As you find free time let's modify monitor in the way you planned.
>>
>>
>> From: Stafford Horne
>> Sent: Sunday, March 03, 2019 1:06 AM
>> To: BAndViG
>> Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan
>> Wallentowitz
>> Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>>
>> I think I fixed it.  Can you try again?
>>
>> On Sun, Mar 3, 2019 at 12:29 AM BAndViG <bandvig@mail.ru> wrote:
>> >
>> > I’ve prepared commit with extended Readme.md and extracting some modules into
>> > separate files, but I haven’t got access to push it (permission denied).
>> >
>> > -Andrey
>> >
>> > From: Stafford Horne
>> > Sent: Saturday, March 02, 2019 11:36 AM
>> > To: BAndViG
>> > Cc: Julius Baxter ; Olof Kindgren ; Openrisc ; Philipp Wagner ; Stefan
>> > Wallentowitz
>> > Subject: Re: [OpenRISC] [RFC] Splitting out Marocchino to new Repo
>> >
>> > Hello,
>> >
>> > I worked or1k_marocchino to the openrisc org.  You sold have access too.
>> >
>> > -stafford
>> >
>> > On Fri, Mar 1, 2019, 8:33 AM Stafford Horne <shorne@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >>
>> >>
>> >> On Wed, Feb 27, 2019, 4:25 AM BAndViG <bandvig@mail.ru> wrote:
>> >>>
>> >>> Hi all
>> >>>
>> >>> I've created MAROCCHINO new repo under my GitHub account
>> >>> (https://github.com/bandvig/or1k_marocchino) as a demo version.
>> >>
>> >>
>> >> This looks good.
>> >>
>> >>>
>> >>> Pay attention that monitors still have "mor1kx_" prefix and
>> >>> or1k_marocchino_cpu
>> >>> instance still called "mor1kx_cpu" to maintain compatibility with current
>> >>> verification infrastructure.
>> >>
>> >>
>> >> I think we can change this now. As long as we have:
>> >>
>> >> bench/verilog/mor1kx_monitor
>> >>
>> >> We can define internals as we like.  Before we we're trying to share so we
>> >> needed to use the same name.
>> >>
>> >>
>> >>>
>> >>> Please, make comments and proposals.
>> >>
>> >>
>> >> Some comments.
>> >> - let's put a style guide in the readme
>> >> - can we split modules to separate files? I.e. or1k_marocchino_execute.v and
>> >> or1k_marocchino_oman.v have some interesting modules I think would make
>> >> sense to be on their own for.  Not everything needs to be split , but at
>> >> least each execution unit and the RAT modules.
>> >>   - I created a diagram on the pipeline dependencies. You then explained
>> >> some things  more clearly.  I'll try to put it on the wiki or in the repo.
>> >>
>> >>>
>> >>> I'm planning to continue development in the repo as its structure will be
>> >>> approved. Btw, I'm not sure that it should be forked into OR organization.
>> >>> I
>> >>> think it would be clearer to create new repo and fill it. I could do that
>> >>> by
>> >>> myself If I've got write access to OR organization account (not sure). Or
>> >>> anybody welcome to do that.
>> >>
>> >>
>> >> I think having it the openrisc org repo would be good.  Let me see if I can
>> >> clone it in and give you access.  If not I'll ask for help.
>> >>
>> >> -stafford
>>
>> WBR
>> Andrey
>>