[nnARM] RE: Preliminary investigation of nnARM soft core

[Clayton John-P26867 <John.Clayton@motorola.com>]

Hello,

I have been looking at the nnARM design for the past few days.  What I have found is that the design needs more preparation in order to become synthesizable using my tool (Xilinx Foundation 3.1), but it can be done.  Here is what I have done:

First, I loaded all of the .v files into Xilinx Foundation.  Then, I created one single include file called "include_all_defs.v" which, as the name implies, simply includes every single one of the "Def" files, as well as the timescale directive "timescalar.v" and "TestInstruction.v".   This worked very well (some of the modules were missing certain includes, and I didn't feel like trying to figure out exactly which ones were needed, so this "blanket" approach was very quick.)

Then, I went through the files, removing those which are what I call "extraneous" (i.e. not needed in the design, basically files which the author, ShengYu Shen must have been using for previous development and experimentation.)

The files which I found "extraneous" were:

CacheMemory.v
DataCacheMemory.v
CAM.v   (means Cache Associative Memory)
datac2.v
MemoryMux.v

I had to remove files that are not separate modules, like "mul.v" from my project.  This file is included into "ALUComb.v" so it is still part of the design, just not listed among the project files.
The file "system.v" is for simulation purposes, but could be used to create a synthesizable module which connects memory to the processor.

Then, I went ahead to synthesize the "ALUComb" module.  I noticed certain warnings and issues which my tool produced.  For instance, "BarrelShift.v" has an output "out_Carry" which is not being driven.  Can it be eliminated?  Also, in ALUComb.v, there is a default value of `WordZ for ALUCombResult, which produced an error in my tool.  I replaced it with 32'b0 in order to compile.  (I later saw that ALUShell handles putting a "Z" value onto the result bus anyway...)
Also, there was a latch inferred in ALUComb.v, which I eliminated by providing a default condition to the case statement, which simply output zero for all outputs as a default.  There may be other ways to do this.

RESULTS:  I was able to synthesize the ALUComb module!  Unfortunately, it took up 40% of my SpartanII XC2S200 part all by itself, and the number of IOBs was too great for my package size (which really isn't a problem, since the ALUComb module would never be used by itself -- but I wasn't able to see the max. frequency results because the Xilinx Place and Route gave up because of too many IOBs.)  Then, when I tried to synthesize for a Virtex V1000 part, I am embarrassed to say I ran out of memory.  Then, I just re-ran it for an XCV600 part, and it completed.  The utilization numbers were the same: 960 slices, total equivalent gate count of 13,128 gates.  The maximum speed was 11.64 MHz, although that certainly included extra delay from the IO pads inserted into the design.

REQUESTS:

I request that the design start using non-blocking assignments in all of the "always" blocks (use <= instead of = within the always blocks.)  This is important for synthesis.  Then, just clean up and try to reduce size, as always.  Also, I would recommend to use named association in all instantiations.

Until then, I am taking a break from further investigation of this design.
- John Clayton


--
To unsubscribe from nnarm mailing list please visit http://www.opencores.org/mailinglists.shtml