any possibilty to check the correct behaviour of SoftCore CPU ?

[andersm]

The integer division instructions never generate exceptions, so if you need to detect division by zero errors, it must be tested for in software. The two-operand format is normally a macro that inserts this test automatically. The three-operand version with zero as target is an assembler mnemonic that specifically bypasses the macro. The operation results (quotient and remainder) are always generated into the lo and hi registers.

The MIPS assembly language defines a relatively large number of macros, pseudo-instructions and "smart assembler" behaviour that unfortunately is not very well documented. The book "See MIPS Run" is the best resource I've encountered, but even there the information is not collected in one place.

[legacy]

@andersm
thank you, it's 100% clear to me now 

[legacy]

It's also much easier to test each component individually in the HDL of your choice that trying to write target programs to do the same thing. When you're satisfied the separate modules of your CPU work then you might want to run some compiled code. Just a suggestion.

yes, good advice, the Truth is that … the guy who has built this project hasn't tested it hardly, he said "yes" but it is a lie, i mean he has been working on such a SoC for 3 years so he has though that so long time is enough to be sure of his job. The Truth is … he has never tested so deeply, and he has never put a real complex application on, he has tested just a few parts with extremely simplified context, and this is the reason why he has has asked me to try his SoC with something from the real world, so i have putted a bit of real world routines on, and bang now we all know that the pipeline is buggy 

As i wrote, i am not good at HDL, i am just trying to help, and in order to do that, i am planning to split the testing activity into two+1 sub activities

1) asking an HDL friend of mine to hardly put everything on modelsim writing a lot of test-benches (i have to learn about it, i am not good at, i can't directly help)

2) asking an other friend to use his chip scope (Xilinx technology) in order to understand exactly what is wrong  using Spartan3E and Spartan6 boards

3) supporting them with testing application, such as assembly code with positive/negative test cases, etc

i hope that combining them will demystify things

as "firmware guy" as far as i have observed, i can say:
 
1) adding NOP after branches avoids unexpected behavior
2) adding NOP after load/store avoids unexpected behavior
 
the -O0 is the winning one, it has always had success with every kind of complex application i have putted on such a SoC: never seen any unexpected behavior with -00, i thing because it is working exactly this way: stuffing a lot of NOP in order to avoid hazards

but it also may be the real cause is related to collision to registers from/to the mux, or other things that i think may be clarified by the Chip-Scope.
 
I don't know very well this technology, but if i have understood right the "Chip-scope" is a Logic Analyzer from Xilinx, unfortunately it is not included in the ISE web pack that i have (ISE v10.1/linux, and ISE v14/windows), my friend has a full license so he could use it.

[legacy]

I am planning to buy this led stick in order to see the PC, or other registers

[legacy]

anybody experienced with such a problem/equipment ?

[nctnico]

IMHO the best approach is to simulate the MIPS1 core fully. First test each part/subsystem and document what it should do. Then simulate it as a whole.

[legacy]

with gHDL plus GTKwave ?

if my friend doesn't do it, i will do by myself
but … i have to learn about it (never done my life)

[nctnico]

One of the things you need to be aware of when using GHDL is that you can only have 1 clock signal for one clock. If you split a clock into multiple signals you get weird effects.

[bwat]

It's also much easier to test each component individually in the HDL of your choice that trying to write target programs to do the same thing. When you're satisfied the separate modules of your CPU work then you might want to run some compiled code. Just a suggestion.

yes, good advice, the Truth is that … the guy who has built this project hasn't tested it hardly, he said "yes" but it is a lie, i mean he has been working on such a SoC for 3 years so he has though that so long time is enough to be sure of his job. The Truth is … he has never tested so deeply, and he has never put a real complex application on, he has tested just a few parts with extremely simplified context, and this is the reason why he has has asked me to try his SoC with something from the real world, so i have putted a bit of real world routines on, and bang now we all know that the pipeline is buggy 

Every CPU design I've ever seen on the net has bugs. I only use my own designs these days. Checking someone else's takes as much time as checking your own. Writing your own from scratch isn't that difficult.

You may not have a working CPU but you're a lot wiser when it comes to people and their definitions of "tested". Good luck!

[legacy]

but i am not skilled enough to write such a complex design from scratches 

[nctnico]

Although the MIPS1 core is mighty interesting I suggest to use the Lattice Mico 32 core from Lattice. That design has been thouroughly tested and is useable in production designs.

[legacy]

the topic is related about how we could fix it, 'cause we have to fix it, that's all folks

[legacy]

if anyone want to collaborate, fix things, have fun with such a SoC, feel feel to contact me by PM 

[nctnico]

Then chop it up to parts and test each part 
What is the experience level of the author of the core? If it is a project for a thesis or internship you may be in for some nasty surprises. Another thing to look at is the level of documentation and comments. If the code is clearly commented it is easier to understand what it is supposed to do. Unfortunately I can only offer advice; I already have a large back log of hobby projects.

[legacy]

Then chop it up to parts and test each part 

it's easy for you, but … not for me, yet 

it's just a tiny SoC with {CPU - RAM/ROM - UART} and nothing else (so it is easy, isn't it ? i have seen much more complex projects, e.g. The OpenRisc-One), but it appears to me as the largest and most complex HDL project i have ever seen. I am not experienced about, and the biggest project i have done up today is around "tiny devices", i mean something like VHDL code for uart, SPI master, and little things like them, i have never realized/debugged a SoC, and never toyed with the HDL code of a SoftCore.

What is the experience level of the author of the core? If it is a project for a thesis or internship you may be in for some nasty surprises.

well, i got nasty surprises when i put -O2 firmware and i got unexpected behavior, i was thinking the SoftCore was stable because he said "tested" and "i have been working on it for 3 years", i think he got started by this project, of which he has reused a few ideas, working model and a some of tools.

Another thing to look at is the level of documentation and comments.

great mess, great deal, there is no documentation, and before me there was no firmware examples, no working toolchain. After fighting a bit with a lot of issues now it is possible to compile complex projects and to easily convert an elf into a memory model file to be used in the synthesis process.

The power of a toolchain plus its tools and libraries on your finger tips: just a script'call to build everything !

If the code is clearly commented it is easier to understand what it is supposed to do

Unfortunately there are still no comments in the VHDL code, but it seems written into an easy going way.

[nctnico]

I don't know where you are in your carreer but if you take this project on you'll learn a lot and it is definitely something to put on your CV. IMHO time well spend. 

[legacy]

before reinventing the wheel, i'd check if there is an assembly monitor for MIPS1, something extremely easy that eats a few bytes in order to provide the following features

- memory view, aka dump, something like "DM 1000.0000 100", let me see the first 100 bytes starting from 1000.0000
- memory fill
- load, … from SREC

the less it eats about byte code in iRam the better it is (i have 8Kbyte of BRAM for the total)

anything around ? if no, i will implement by myself

[nctnico]

Such a thing is not difficult to implement BUT it won't help you. What you need is a testbench (or better said: test vectors) for the MIPS1 processor to verify it's design at the simulation stage. If you are going to throw random code at it the chances are very high you won't discover all the bugs.

This might be interesting for testing the MIPS1:
http://probell.com/pubs/I223.PDF
I did not read it but the first page has all the right buzz-words.

[legacy]

A monitor helps me a lot!

Simulating is nothing if you don't know where to look for, i have told you several and several times that i have not so much resources, time, and skills to do a full simulation! So i need a boot loader monitor in the real fpga target in order to load real binaries in order to be helped about which part of the simulation it takes the most importance to be analyzed in details !

Also i prefer this way because my PC (intel dual core2, @1.6Ghz) takes more than 20 minutes to synthesize the whole SoC and it means that if you want to modify an assembly line it will take an other 20 minutes to let it checked out!

Altera has different way to load an elf inside the SoC ram, as far as i understand it seems to me that Xilinx has a very complicated tool which could be used to load an elf into BRAM, ad this (in case of spartan3e) may be possible only if you use their "b16-bram-model", so … i have written my own converter tool which loads and elf and converts it into a vhdl file that is putted in the synthesis tree.

caseA: without a boot loader, any changes to any assembly or c code causes a new vhdl file, that cause a new synthesis, that takes 20 minutes

caseB: with a boot loader, any changes to any assembly or c code cause a rebuild of the srec file, that cause a new target-reset + host-to-target download, that takes less than 1 second (at 115200bps, and it can be 4x faster)


btw, i have found nothing around, i have modified the actual "calculator" firmware in order to recycle a few code in order to arrange a tiny boot loader with SREC S3-ONLY. For such a purpose i have also forced objdump to provide 4 byte address ONLY elf-to srec-conversion.

The good news is that it works and i am able to upload whatever i want on the real fpga, the bad news is … this monitor eats 4Kbyte of BRAM, 50% of my planned resources 

[bwat]

A monitor helps me a lot!

You want to run a monitor on a broken CPU!

Simulating is nothing if you don't know where to look for, i have told you several and several times that i have not so much resources, time, and skills to do a full simulation!

And it has been suggested several times that you should break the whole into manageable parts and test these individually. After these have been shown to pass your tests, you start combining them into bigger blocks and test these - you might even just start testing the CPU on instruction streams at this point. You're trying to change the problem to suit your experience - change your experience to suit the problem instead!

How I test my multiplexers. I work in Verilog so you'll have to figure out how to do something similar to this in VHDL.

1) The test bench in Verilog (mux_tb.v):

Code: [Select]

module mux_tb;
   reg [15:0] A0, A1, A2, A3, A4, A5, A6, A7, A8;
   reg [15:0] A9, A10, A11, A12, A13, A14, A15;
   reg       S_2;
   reg       S1, S0;
   reg [2:0]  S_8;
   reg [3:0]  S_16;
   wire [15:0] X_2, X_4, X_8, X_16;
   
   integer     handle;
   
   multiplexer_2_1 dut2(X_2, A0, A1, S_2);
   multiplexer_4_1 dut4(X_4, A0, A1, A2, A3, S1, S0);
   multiplexer_8_1 dut8(X_8, A0, A1, A2, A3, A4, A5, A6, A7, S_8);
   multiplexer_16_1 dut16(X_16, A0, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, S_16);
   
   initial begin
      $dumpfile("mux.vcd");
      $dumpvars(0,dut2);
      $dumpvars(0,dut4);
      $dumpvars(0,dut8);
      $dumpvars(0,dut16);
      handle = $fopen("mux_tb.out");
      A0 <= 16'h0;
      A1 <= 16'h1;
      A2 <= 16'h2;
      A3 <= 16'h3;
      A4 <= 16'h4;
      A5 <= 16'h5;
      A6 <= 16'h6;
      A7 <= 16'h7;
      A8 <= 16'h8;
      A9 <= 16'h9;
      A10 <= 16'ha;
      A11 <= 16'hb;
      A12 <= 16'hc;
      A13 <= 16'hd;
      A14 <= 16'he;
      A15 <= 16'hf;

      S_2 <= 0;
      #1 $fdisplay(handle, "%d %d", X_2, S_2);
      S_2 <= 1;
      #1 $fdisplay(handle, "%d %d", X_2, S_2);

      S1 <= 0; S0 <= 0;
      #1 $fdisplay(handle, "%d %d", X_4, 0);
      S1 <= 0; S0 <= 1;
      #1 $fdisplay(handle, "%d %d", X_4, 1);
      S1 <= 1; S0 <= 0;
      #1 $fdisplay(handle, "%d %d", X_4, 2);
      S1 <= 1; S0 <= 1;
      #1 $fdisplay(handle, "%d %d", X_4, 3);

      S_8 <= 0;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);
      S_8 <= 1;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);
      S_8 <= 2;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);
      S_8 <= 3;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);
      S_8 <= 4;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);
      S_8 <= 5;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);
      S_8 <= 6;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);
      S_8 <= 7;
      #1 $fdisplay(handle, "%d %d", X_8, S_8);

      S_16 <= 0;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 1;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 2;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 3;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 4;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 5;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 6;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 7;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 8;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 9;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 10;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 11;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 12;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 13;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 14;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);
      S_16 <= 15;
      #1 $fdisplay(handle, "%d %d", X_16, S_16);

      #1 $finish;     
   end

endmodule

2) The generated output file (mux_tb.out) with the results

Code: [Select]

    0 0
    1 1
    0 0
    1  1
    2  2
    3  3
    0 0
    1 1
    2 2
    3 3
    4 4
    5 5
    6 6
    7 7
    0  0
    1  1
    2  2
    3  3
    4  4
    5  5
    6  6
    7  7
    8  8
    9  9
   10 10
   11 11
   12 12
   13 13
   14 14
   15 15

3) The program which checks the test results (mux_tb.c).

Code: [Select]

/* mux_tb.c */

#include <stdio.h>

/* #define DEBUG  */

int mux (void);

/*
 * Test the multiplexers.
 */
int main(int argc, char **argv)
{
  (void) argc;
  (void) argv;
 
  while(!feof(stdin))
    {
      if(!mux())
{
  return -1;
}
    }
  return 0;
}

/*
 * Read a line and make sure it is correct.
 * Return 0 on failure and 1 on success.
 */
int mux (void)
{
  int X;
  int S;

  if(scanf("%d %d\n", &X, &S) < 0)
    {
      fprintf(stderr, "Scan error\n");
      return 0;
    }

#ifdef DEBUG
  printf("Verifying %d %d\n", X, S);
#endif

  return X == S;
}

4) Part of the Makefile which creates and runs the mux test (mux.v is my Verilog file containg code for my multiplexers):

Code: [Select]

###
### MUX
###
test_mux: mux_tb mux.v tb/mux_tb.v
iverilog -o tb/mux mux.v tb/mux_tb.v
(cd tb; vvp mux)
(cd tb; ./mux_tb < mux_tb.out)

mux_tb: tb/mux_tb
(cd tb; ${CC} -o mux_tb mux_tb.c)


[legacy]

You want to run a monitor on a broken CPU!

i have written several and several time that it is not completely broken, if compiled with -O0 everything is working, while if  compiled with -O1/-O2 it is not, in fact the the monitor is written in C, recycling an other piece of C code, it has been compiled with -O0 and it is working: it passes all the internal tests, it loads srec, it dumps ram, and i am fine with it!

And it has been suggested several times that you should break the whole into manageable parts and test these individually

your example is for a mux, that is less 1% of the job you have to do to check a SoC which is much more complex (we are talking about 2000 lines of VHDL, just to summarize), so I will simulate, but the monitor will help me about what to put in the "to be watched" list with the highest priority, for example i suspect the bug is related to MUL, so i will consider this module for the first.

[bwat]

i have written several and several time that it is not completely broken, if compiled with -O0 everything is working,

You don't know that for sure as it's untested.

your example is for a mux, that is less 1% of the job you have to do to check a SoC which is much more complex (we are talking about 2000 lines of VHDL, just to summarize),

Of course it's just a fraction. It was given as an example of the type of test you should be creating.

I'm currently in the middle of a 16-bit microcoded CISC CPU implementation. I've written 1641 lines of Verilog for the CPU so far. As for the tests, I've written 3215 lines of Verilog and C. That's nearly double! The CPU implementation is 99% done so when I finish testing each instruction with each of the eight addressing modes I'll probably end up with 5 to 10 times as much test code as CPU implementation code.

Developing CPUs takes time and effort.

so I will simulate, but the monitor will help me about what to put in the "to be watched" list with the highest priority, for example i suspect the bug is related to MUL, so i will consider this module for the first.

I suspect you're in for a shock.

[legacy]

I'm currently in the middle of a 16-bit microcoded CISC CPU implementation

I am curious, which one ?
I do not have any 16-bit in my experiences

Developing CPUs takes time and effort.

Yes, i am understanding how hard it is X_X

[bwat]

1) in the instruction decode, my friends has missed a condition about branch, luckily the -00 flag has made code working only because such a condition was avoided by compiler (thanks gcc)

That's why I wrote that you didn't know everything worked with no compiler optimisations. But with every bug you find and fix, there's fewer to trip you up in the future. Slowly but surely you're getting there.

I'm currently in the middle of a 16-bit microcoded CISC CPU implementation

I am curious, which one ?
I do not have any 16-bit in my experiences

It's just a design from a book. I'm implementing it for more experience in microcoded control unit design. I've only implemented simple microcoded designs up to now: microcoded control unit example 1 microcoded control unit example 2.
I've got plans to implement a series of lambda calculus reduction engines in FPGA and they'll be easier with microcoded control units so what I'm doing now is good practice.
 

Developing CPUs takes time and effort.

Yes, i am understanding how hard it is X_X

Yep, but the harder it is, the more we learn. Keep on keeping on and good luck!

[legacy]

just googling around i have found this "Leon" SoftCore an i am impressed about it