Hi all,

The OR1200 RTL and spec have been updated. The news page has details, and the OR1200 page also has some information.

The main work was in the addition of an FPU (all ORFPX32 instructions except lf.madd.s and lf.rem.s are supported) and adding the option of write-back mode for the data cache, which was previously strictly write-through.

The Actel FPGA target in the defines is no longer used, instead if is replaced with a generic target, which only really effects the RAM instantiations.

The pipeline now has a mechanism which allows for indefinite stalling. This made it a lot easier to implement the FPU and also the SPRS for cache flushing, which can take a variable amount of time.

A bug with the register file and single stepping was also fixed.

The OR1200 spec has received a tidy up, too, but is still not entirely in line with the OR1200 RTL. More work needs to be done on this, and if anyone wishes to go through the spec and and check out things like the registers and instructions that are mentioned in the spec really are in the OR1200 RTL, it would be appreciated.

The default configuration is noted on the OR1200 page.

Enjoy.

Hi all,

I do a minor patch of or1200 for the flip-flops of active low reset. There's defined symbol 'OR1200_RST_ACT_LOW' on file or1200_define.v. Uncomment it to use active low reset for flip-flops.

//
// Reset active low
//
//`define OR1200_RST_ACT_LOW

Thanks for this.

Is this compatible with the very latest OR1200 in the repository?

If so I'll apply it to the committed version.

Yes, it's compatible with the very latest OR1200 in the repository but or1200_mult_mac.v. The file or1200_mult_mac just check-in one hour ago, so I did the patch again. By the way, I had test the patch by Verilator on the orpsocv2 environment, it pass all of the test.

Fantastic, I'll apply run it over the code now and see how it goes.

All RTL and cycle-accurate model tests pass, so I've just committed revision 358 which includes your patch in the OR1200 project and ORPSoCv2.

Thanks again.

Dear all,

sorry to ask this stupid question, but why don't you simple invert your reset in your toplevel?

I have the same with my boards, there I simplay have something like this:

`ifdef ACTIVE_LOW
assign reset = ~rst_i;
`else
assign reset = rst_i;
`endif

Seems quite easier to me. Correct me if I'm wrong..

Bye,
Stefan

Yes but the actual sensitivity on the logic remains the same, and for synthesis reasons perhaps it's good to have it configurable.

Sorry, but I can't agree on this. It just messes up the code. The user itself should care about the correct signal level, that the processor expects. Otherwise, _all_ other IP blocks also need to be touched, what is inefficient and inflexible. It makes the future design error prone and is in fact not a nice coding style.

I propose reverting r358 and either adding a simple solution in or1200_defines.v or1200_top.v (I would provide a patch) or just keep it out of an IP block and give it to the platform designer to generate expected signals.

Sorry for the strong opinion, but I don't get the point.

Bye,
Stefan

I fail to understand the problem here.

The patch made the reset level configurable - meaning you can have it either active high or low. If your design uses all active-high resets then no problem, but if your design uses all active low then just flick the define and feed it the same reset as the rest of the define, no need to invert it anywhere.

It makes code complex und hard to read, is prone to add additional errors. Why solve a problem with a touch on every single FF in the design instead of my proposed max. six lines of code?

The code quality should always have a very high priority. This includes solving stuff as easy and flexible as possible.

Point taken about code readability, but still, if someone wishes every flop in a design to be sensitive to a certain reset level (for synthesis purposes) then that was not possible in the OR1200 previously, and it is now.

I am trying to run Nc-verilog RTL simulation with the latest orp_socv2 release and getting following error message.

*** No rule to make target `ncverilog', needed by `rtl-test'. Stop.

I have used the command
make rtl-tests SIMULATOR=ncverilog TESTS="or1200-simple"

I think the Makefile does not support for Nc-verilog simulator.

How do i run the Nc-verilog simulation with latest orp_socv2 environment.

This isn't the thread to be bringing up ORPSoCv2 build issues.

Anyway, ORPSoCv2 is undergoing some updates this weekend. I haven't tested with NC-verilog yet.

You can roll back to a previous revision , r347 was last check-in before I started the upgrade work.

I'll be doing an update of the ORPSoCv2 page on this site when it's all done, but that may be a couple of days yet. That will include instructions on how to run with the various RTL simulators.

The systhesis tool reports the signal 'muxout' as latch cell on the file 'or1200_wbmux.v'. It's a incomplete assignment on the case statement.