[OpenRISC] [OR1200][Bug]

There is no declaration of du_flush_pipe in or1200_top.v

Olof Kindgren

2014-09-16 07:13:28 UTC

Post by Matthew Hicks
There is no declaration of du_flush_pipe in or1200_top.v
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

Thanks. Fixed in rev 868

Have you considered trying mor1kx, btw? That's where we currently are
putting all our development efforts

//Olof

Matthew Hicks

2014-09-16 14:34:05 UTC

I have lots of time invested in the OR1200 and many of my research projects
use it. I have seen how mor1kx has taken off in the last couple of years.

Post by Olof Kindgren

Post by Matthew Hicks
There is no declaration of du_flush_pipe in or1200_top.v
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

Thanks. Fixed in rev 868
Have you considered trying mor1kx, btw? That's where we currently are
putting all our development efforts
//Olof

Sébastien Bourdeauducq

2014-09-16 15:47:53 UTC

Post by Matthew Hicks
I have lots of time invested in the OR1200 and many of my research
projects use it.

That's puzzling to me, considering how bad OR1200 is compared to LM32 or
more recently mor1kx.

Matthew Hicks

2014-09-16 16:05:09 UTC

I think what I said actually supports your point..I spent LOTS of time to
master the OR1200---including bug finding and patching. For one of my
current projects, we are going to fab. the OR1200 in <45nm process. I
don't think that I want to gamble on something new.

For future projects, I am developing an ARM Cortex-M compatible core for
research systems. That way you get software and tool development for free
(as it fits into the ARM ecosystem).

Post by Matthew Hicks
I have lots of time invested in the OR1200 and many of my research
projects use it.

That's puzzling to me, considering how bad OR1200 is compared to LM32 or
more recently mor1kx.
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

Olof Kindgren

2014-09-16 16:20:37 UTC

Post by Matthew Hicks
I think what I said actually supports your point..I spent LOTS of time to
master the OR1200---including bug finding and patching. For one of my
current projects, we are going to fab. the OR1200 in <45nm process. I don't
think that I want to gamble on something new.

Please let us know how things go with the ASIC. It's always fun to
hear about OpenRISC in new places.

Post by Matthew Hicks
For future projects, I am developing an ARM Cortex-M compatible core for
research systems. That way you get software and tool development for free
(as it fits into the ARM ecosystem).

Sorry to hear that OpenRISC doesn't fit your needs. Your input and bug
reports (although many of them still not fixed :/ ) have been valuable
to the project
If you grow tired of ARM and want to give OpenRISC another shot in the
future, I'm sure you will have a bit more pleasant experience.

//Olof

Peter Gavin

2014-09-16 20:16:32 UTC

I thought I'd suggest taking a look at RISC-V (http://riscv.org/). They've
come a long way and they have a decent amount of compiler infrastructure
set up as well (e.g. both GCC and LLVM ports). I suggest this because if
OpenRISC doesn't do what you need, RISC-V might (the ISA has a lot of cool
features), and you won't have to worry about the potential patent licensing
issues you would probably have with ARM--especially if you're going for
Cortex-M compatibility.

-Pete

Sébastien Bourdeauducq

2014-09-17 00:42:19 UTC

Post by Peter Gavin
I thought I'd suggest taking a look at RISC-V (http://riscv.org/).
They've come a long way and they have a decent amount of compiler
infrastructure set up as well (e.g. both GCC and LLVM ports).

Is the source code for that core available somewhere?

Post by Peter Gavin
you won't have to worry about the potential patent licensing issues
you would probably have with ARM--especially if you're going for
Cortex-M compatibility.

Yeah. To continue the ecosystem analogy, choose carefully where you want
to be in the food chain.

Sébastien

Peter Gavin

2014-09-17 08:11:12 UTC

Post by SÃ©bastien Bourdeauducq
Is the source code for that core available somewhere?

There's a 6-stage here: http://riscv.org/download.html#tab_rocket

They use a generator language called Chisel. But it should dump some
Verilog/VHDL for you.

-Pete

Sébastien Bourdeauducq

2014-09-17 08:12:25 UTC

Post by SÃ©bastien Bourdeauducq
Is the source code for that core available somewhere?
There's a 6-stage here: http://riscv.org/download.html#tab_rocket

No, there is only this:
"We plan to open-source our Rocket core generator written in Chisel in
the near future. We are currently in the process of cleaning up the
repository. Please stay tuned."
from https://github.com/ucb-bar/rocket linked from your page.

Peter Gavin

2014-09-17 08:20:07 UTC

Post by SÃ©bastien Bourdeauducq
Is the source code for that core available somewhere?
There's a 6-stage here: http://riscv.org/download.html#tab_rocket

"We plan to open-source our Rocket core generator written in Chisel in
the near future. We are currently in the process of cleaning up the
repository. Please stay tuned."
from https://github.com/ucb-bar/rocket linked from your page.

There are some other cores here: https://github.com/ucb-bar/riscv-sodor

-Pete

Sébastien Bourdeauducq

2014-09-17 08:35:16 UTC

Post by Peter Gavin
There are some other cores here: https://github.com/ucb-bar/riscv-sodor

Simulation only - another typical problem with academic projects...
Has anyone tried synthesizing this?

Sébastien

Stefan Kristiansson

2014-09-17 09:34:30 UTC

Post by Peter Gavin
There are some other cores here: https://github.com/ucb-bar/riscv-sodor

Simulation only - another typical problem with academic projects...
Has anyone tried synthesizing this?

I tried to build https://github.com/ucb-bar/fpga-zynq, but I didn't
have the same Vivado version as they had used so it failed because of
that.
I didn't spend much time trying to investigate what needed to be done
to get it to build with my version, the Xilinx cores needed to be
upgraded iirc.

Stefan

Alex Bradbury

2014-09-23 14:19:21 UTC

Post by Peter Gavin
There are some other cores here: https://github.com/ucb-bar/riscv-sodor

Simulation only - another typical problem with academic projects...
Has anyone tried synthesizing this?

The Rocket generator will be open sourced soon. The Rocket core has
manufactured at 45nm and the team at Berkeley have tape-outs every few
months these days
http://www.hotchips.org/wp-content/uploads/hc_archives/hc25/HC25-posters/HC25.26.p70-RISC-V-Warterman-UCB.pdf

Alex

Matthew Hicks

2014-09-23 15:08:20 UTC

Seems very similar to the OR1200 without some of the instruction bloat
(e.g., MAC) and the dreaded delay slot.

Post by Alex Bradbury

Post by Peter Gavin
There are some other cores here: https://github.com/ucb-bar/riscv-sodor

Simulation only - another typical problem with academic projects...
Has anyone tried synthesizing this?

Matthew Hicks

2014-09-16 22:01:17 UTC

For a research project, I needed to generate a lot of exceptions. For
this, I repurposed the illegal instruction exception. I found a bug where
the EPCR was loaded with the wrong address. The patch below fixes this
problem and has serviced over 1 billion exceptions both with Linux and in
bare metal.

At a higher level, is there any reason why different exceptions should have
different EPCR values? It seems like having a single EPCR selection logic
would simplify things and probably eliminate subtle (hard to detect and
correct) bugs. Note that the patch I submitted matches (coincidentally)
the range exception.

Index: or1200_except.v
===================================================================
--- or1200_except.v (revision 868)
+++ or1200_except.v (working copy)
@@ -518,7 +518,9 @@
except_type <= `OR1200_EXCEPT_ILLEGAL;
eear <= ex_pc;
epcr <= ex_dslot ?
- wb_pc : ex_pc;
+ wb_pc : delayed1_ex_dslot ?
+ dl_pc : delayed2_ex_dslot ?
+ id_pc : ex_pc;
dsx <= ex_dslot;
end
`endif

Peter Gavin

2014-09-16 22:06:33 UTC

On traps/syscalls, EPCR is the instruction after the syscall instruction.
Otherwise when the syscall completes, you'd have to read out EPCR,
increment it, write it back, then rfe. For other exceptions it's just the
current instruction.

If an instruction in a delay slot raises an exception, EPCR must be set to
the PC of the branch, because otherwise when execution is resumed the
branch won't get executed, and you'll just start executing at the delay
slot, then whatever instructions follow it sequentially.

-Pete

Post by Matthew Hicks
For a research project, I needed to generate a lot of exceptions. For
this, I repurposed the illegal instruction exception. I found a bug where
the EPCR was loaded with the wrong address. The patch below fixes this
problem and has serviced over 1 billion exceptions both with Linux and in
bare metal.
At a higher level, is there any reason why different exceptions should
have different EPCR values? It seems like having a single EPCR selection
logic would simplify things and probably eliminate subtle (hard to detect
and correct) bugs. Note that the patch I submitted matches
(coincidentally) the range exception.
Index: or1200_except.v
===================================================================
--- or1200_except.v (revision 868)
+++ or1200_except.v (working copy)
@@ -518,7 +518,9 @@
except_type <= `OR1200_EXCEPT_ILLEGAL;
eear <= ex_pc;
epcr <= ex_dslot ?
- wb_pc : ex_pc;
+ wb_pc : delayed1_ex_dslot ?
+ dl_pc : delayed2_ex_dslot ?
+ id_pc : ex_pc;
dsx <= ex_dslot;
end
`endif
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

Matthew Hicks

2014-09-16 23:59:52 UTC

Post by Peter Gavin
On traps/syscalls, EPCR is the instruction after the syscall instruction.
Otherwise when the syscall completes, you'd have to read out EPCR,
increment it, write it back, then rfe. For other exceptions it's just the
current instruction.

Makes sense. So there really should be only two version of EPCR selection
code (not the current menagerie)?

Post by Peter Gavin
If an instruction in a delay slot raises an exception, EPCR must be set to
the PC of the branch, because otherwise when execution is resumed the
branch won't get executed, and you'll just start executing at the delay
slot, then whatever instructions follow it sequentially.

Unfortunately, it is more complicated than that on the OR1200---re: my
patch---and I had to find out the hard way.

Post by Peter Gavin
-Pete

Stefan Kristiansson

2014-09-17 02:47:11 UTC

Post by Peter Gavin
On traps/syscalls, EPCR is the instruction after the syscall instruction.
Otherwise when the syscall completes, you'd have to read out EPCR, increment
it, write it back, then rfe. For other exceptions it's just the current
instruction.

I've several times cursed over this choice though, saving 2-3
instructions in the syscall exception handler at the cost of the added
hardware complexity is just silly.

Stefan

Matt Thomas

2014-09-17 06:54:16 UTC

Post by Peter Gavin
On traps/syscalls, EPCR is the instruction after the syscall instruction.
Otherwise when the syscall completes, you'd have to read out EPCR, increment
it, write it back, then rfe. For other exceptions it's just the current
instruction.

I've several times cursed over this choice though, saving 2-3
instructions in the syscall exception handler at the cost of the added
hardware complexity is just silly.

I agree. I keep hearing the voice of the Grail Knight in IJATLC saying "He chose poorly." when I look at the design of OpenRISC. I feel that openrisc made been the victim of poor design decisions.

Olof Kindgren

2014-09-17 08:18:42 UTC

Post by Matt Thomas

Post by Peter Gavin
On traps/syscalls, EPCR is the instruction after the syscall instruction.
Otherwise when the syscall completes, you'd have to read out EPCR, increment
it, write it back, then rfe. For other exceptions it's just the current
instruction.

I've several times cursed over this choice though, saving 2-3
instructions in the syscall exception handler at the cost of the added
hardware complexity is just silly.

I agree. I keep hearing the voice of the Grail Knight in IJATLC saying "He chose poorly." when I look at the design of OpenRISC. I feel that openrisc made been the victim of poor design decisions.
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

So does this mean that the patch is invalid?

//Olof

Matthew Hicks

2014-09-17 11:17:35 UTC

The patch is valid, but we should also discuss a more comprehensive
cleaning of epcr update logic in or1200_except.

Post by Peter Gavin

On Sep 16, 2014, at 7:47 PM, Stefan Kristiansson <

Post by Peter Gavin
On traps/syscalls, EPCR is the instruction after the syscall

instruction.

Post by Peter Gavin
Otherwise when the syscall completes, you'd have to read out EPCR,

increment

Post by Peter Gavin
it, write it back, then rfe. For other exceptions it's just the

current