Now this design have full ARMv4T support.and its interface is wishbone compatible.
Because I am still working on half word transfer instruction, so I will release the two feather in the next version
For test bench about MULL and MLAL, see testbench page, the last item of testbench list is MULL. that is it.
I have just release nnARM v1.22 that eleminate all tri-state signals.
Because some ASIC process and FPGA device do not support tri-state signal, so I replace them with mux.
All testbench run correctly
I have just release nnARM v1.21 that support Wishbone. Between the nnARMCore and Wishbone bus I add two Bus2Core module, one for Instruction stream, the other one for data stream.
All test bench run correctly. So now the nnARM is ready to goto chip
I have just release nnARM v1.20 that support LDM/STM, it can run the two type of instructions in both ARM and Thumb state. I re-run all testbench and do not find any problem.
I have also release the new test bench for v1.20, it contain a testbench called "tblock", this program can run LDM/STM under Thumb.
I have just release nnARM v1.19 that support LDM/STM, it can run the two type of instructions in ARM state. but have minor problem with LDM that run in Thumb state and load to PC.In this case, it can not align to the correct half word return address.
I have also release the new test bench for LDM/STM instructions, in the "asm" subdictionary, you can find a "block" dictionary, it is a program that hold many LDM/STM instructions.
nnARM is a 4 stage simple RISC, it can not satisfy some high performance application's require. So I am thinking about design a brand new version of nnARM,I call it nnARM II. Following is some of my idea:
First, it must be a configurable design, it run a basic simple instructions set, and any extension on this basic instruction set will be describe in a high level form
Second, a pipeline layout will be describe by designer, it describe how many stage in pipeline, what to do in every pipeline stage
Third, the description of instruction set extension and pipeline layout will be compile by a tools set to produce RTL code of that core, at the same time , GNU tools chain and core simulator will also be produce.the designer can immediatly enjoy the whole new core.
Fourth, the information come from back end tools(such as synthesis , place and route tools)can be back annotate to core simulator, this make it possible for designer to learn how fast can that core run, how much power does it consume.
these idea reside only in my mind now, I am refining it.any advice is welcome
I have just release the new version that support Thumb instruction set and interrupt. At the same time, the documentation is also released, any one want to modify the nnARM code please first look at this documentation, if still have problem in understand nnARM, please do not hesitate to mail me.
I have just add the support of interrupt(FIQ and IRQ). I am still fight with my SDT 2.5 to write a assembly source that contain a interrupt service roution. So I can not release the new version now.
At the same time, I plan to write a new version of documentation, in this version I will describ the overall core in a greater more detail. this will make it more easy for peoples who interest in nnARM to join
I used an evaluation version of ISE from Xilinx to synthesize nnARM, into a Virtex II 10000, with 10 million gates. :-). The result is very slow. Following is the timing summary given by ISE:
Timing summary:
---------------
Timing errors: 0 Score: 0
Constraints cover 974591225 paths, 0 nets, and 34344 connections (96.1% coverage)
Design statistics:
Minimum period: 62.794ns (Maximum frequency: 15.925MHz)
Maximum combinational path delay: 23.097ns
Minimum input arrival time before clock: 34.618ns
Maximum output required time before clock: 28.395ns
Analysis completed Tue Jul 24 17:33:21 2001
--------------------------------------------------------------------------------
You can see that the combinational delay consumes only about 35% of the overall delay. I will perform a floorplan to make it run even faster.
I have release the new nnARM version v1.16 that supports all Thumb instructions.
NOTE: This version only supports all thumb instructions, meaning it can correctly decode all thumb instructions into ARM instructions. Then, all these decoded ARM instructions must be fed through the normal ARM pipeline to execute. So because some types of ARM instructions (notably: LDM/STM, SWP, half word access and coprocessor instructions) are still not supported, the compressed versions of these instructions also can not run on nnARM. But I am working on them now.
At the same time, I also released the new testbench. It contains a program in the thumbsub directory. This program switches into Thumb state and executes some ALU instructions, then runs a long branch with link and then returns back. After all that is done it switches back to ARM state and ends.
I have released a new version v1.15 that supports most of Thumb instructions except long branch with link.
The decoder of thumb instructions is written by Mian Yousaf from Pakistan. For more detail concerning him, please refer to the People page of this site.
At the same time, I also released the new testbench. It contains a program in the thumbsub directory which contains thumb instructions.
But that program contains a long branch with link, so only part of that program runs correctly. I will find a way to support this instruction soon.
John Clayton has corrected MANY MANY MANY grammatical errors in it, this makes it easier for native speakers of English to understand.
I corrected some errors in ALUComb, mainly in the BarrelShifter.
At the same time, this is the first version that contains a synthesizable top level module--nnARMCore in nnARMCore.v. Several people have asked for this module at different times.
For more information concerning various files, please refer to the README.txt file in the source code directory.
A new page has been added that describes how to build and install GNU Tools for ARM so that every one can join this project, even if they do not have the SDT or ADS from ARM Inc.
Now it can support the SWI instruction.
At the same time, I am working on a GCC port for nnARM, because I want to support a new compressed instruction set of my own other than TDMI. This instruction set will not affect the internal structures of nnARM, and a new expand function will be performed in the instruction prefetch buffer to expand the compressed instructions into normal ARM instructions.
corrects an error that caused ALU instructions without the S bit to write CPSR.
Please visit it in the documentation section or click here
In the last 3 days, I tried to make nnARM run a fixedpoint FFT program written in C language. But it failed, because the C compiler generated an ELF binary that contains some unsupported instructions, such as SWI and LDM/STM.
In simulation,nnARM successfully ran through 2 loops each containing 1024 iterations, the two loop are used to generate the vectors and matrix used in the FFT, but finally it was stopped by an SWI that invoked some unknown system call.
In this process, I found about ten bugs, mainly in the Data Cache Controller. It is the first time that nnARM ran so many load/store instructions. The cache is busy write back dirty operand and reading in new operands. I think I did obtain some good results from the three days of hard work.
I corrected all these errors and released a new version 1.11
Thanks a lot to Miha Lampret and Damjan Lampret, I have just been given a mailing list for nnARM from them. Any discussion should go to nnARM mail list
I have just got this account, and I will try to learn how to use CVS and other rules and policies of Opencores.
Now it is more convenient for anyone interested in this project to take part in it. Please refer to the Introduction page for what type of help we need.
Because I will be busy in the next 2 weeks for other things, I can not find time to write full documentation. However, I think a partial documentation is better than no documentation.
The full version will be released later.
The memory and cache system of my design are not very well suited for this processor. Because I want to devote myself to the design of the processor itself, I used a VERY SIMPLE model of cache and memory.
Whoever can help me to develop a better model pleasecontact me
I obtained this assembly source code using the ARM SDT 2.5. It runs very well and produced good results. For more details, please refer to TestBench
Because the PC is not a general register, when the instruction reaches the EXE and MEM stage, the current processor PC is ahead of the PC of the current instruction by 8 or 12 bytes. So it can not be used directly in the EXE stage as a general register. Therefore I read it at decoder stage and then adjust it for the ahead amount, and at last send it to the EXE stage as an immediate value.
For the case of a write to the PC, it is treated as a Branch instruction.
These two instructions can do multiply and multiply and then add operations
These two instructions change the PC, and the latter can write the next instruction address to R14 for return from subrutine.
These two instructions write CPSR/SPSR to and from general registers.
The two registers (actually six registers, including cpsr spsr_fiq spsr_und spsr_svc spsr_irq spsr_abt) can now be read/written. And the pipeline can use the condition code from cpsr to decide if an instruction can be executed.
Since the last update a month ago, I am working hard to change the architecture of nnARM, the main reason is described as follows:
When I started to develop this soft core, I thought that the ARM instruction set is very similar to that of the typical RISC machine such as DLX and MIPS. So I think I can develop a RISC core to run various risc instruction sets. This idea is not wrong for the typical RISC, but it is wrong for ARM. When I pushed forward with the development, I found that the ARM instruction set is very different from that of the typical RISC machine. It is difficult to run the ARM instruction set on it efficently. So I designed a brand new architecture for ARM. And all functions that have been supported by the old architecture are also supported by the new architecture.
At the same time, I added support for load and store instructions.
A new Full Function ALU has been released, it can support all ALU operantions in the ARM instruction set. Its documentation is online now.
I have written documentation for the first release of this synthesable soft core in the last week. Now, the documentation has been finished. I started to push forword with this project again tonight. I have written a new barrel shifter (in BarrelShift.v) and its test bench (in tb_BarrelShift.v). New documentation sections concerning the new Barrel Shifter are also online now.
After 2 weeks hard work,the processor now can run ADD instructions, but I know that it does have some limitations:
FIRST:the tomasulo structure still can not tell the decoder that an instruction has completed, so that the decoder can clear the register usage record.
SECOND:the ALUWraper still can not read from the write bus, so it can only get results from within ALUWraper, only from other entries.
Except for the above two limitation, it runs fairly well,