MIPSFpga Floating Point Support

This topic contains 6 replies, has 3 voices, and was last updated by  Ronobir 2 years, 2 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #49688

    Ronobir
    Member

    I haven’t had the chance to the see the gold reference version of MIPSFpga that just released but have been looking at the RTL that may be a few months older.

    As far as I remember this was a strictly Integer limited Inorder processor

    My question is if we made architectural changes by developing the appropriate coprocessor that supports all the Floating Point instructions/FMA (as of MIPS V compliance), what would we need to do to the MIPS SDK backend for GCC to enable support of the newly enabled instructions?

    I haven’t had a chance to see the newly available tools yet so I may be completely offpoint with the new iteration of the design, so I apologize if this is no longer applicable.

    #49700

    Dear Ronobir
    I moved your post to the right forum.
    This question is one for our Codescape MIPS SDK Essentials team to answer.

    For your information:
    – The latest revisions are of the materials. We are trying to make them ultra-clear and accurate.
    – The core has not changed since initial release. It’s a standard UP configuration running R3 ISA. There is not a DSP or Floating-Point unit present to ensure the core is easy to understand and small in size.
    – The Linux / SoC package called “Advanced” will be the same core, and comes with all the FPGA defined peripheral blocks to support Linux, plus a large amount of documentation. Due Q4’15

    Don’t forget the workshops that are coming: Europe, Russia, Japan, China and Israel are all in plan. More to follow. Flyer attached.

    We wish you success with your project.

    MIPSfpga-architecture-v2

    Attachments:
    You must be logged in to view attached files.
    #49705

    Ronobir
    Member

    Thank you!

    I’ll revise my question

    #49706

    Ronobir
    Member

    Wait it seems I can’t edit any of my replies! I’ll just append it here.

    I was wondering from an architectural perspective since the raw RTL is available for MIPSFpga, that if someone was to architect in Coprocessor 2 following the ISA or similarly added in Vector Operation support either directly to the core or a separate SIMD coprocessor and wanted to enable the functionality compiler side, what are the necessary steps to take.

    I thought editing the LLVM compiler toolchain to include the appropriate backend modifications would be the easiest and compiling from source. One would only have to edit everything post IR and frontend to work on the backend flow, primarily the assembler and beyond. However that would lose the functionality of the Codescape SDK. To maintain SDK integrity I’m guessing you would have to edit the GCC toolchain which is far far harder.

    My goal is to work on the uArch of the core and I wanted to go beyond simply editing the assembler tags and calling the ASM(ADDVV.D) or ASM(MUL.D F#, F#, F#) in C since I wanted to include a full C based benchmark suite.

    There a simplified toolflow for doing so in LLVM, under 6 months for execution from start to finish. I can’t imagine how long for GCC but probably far more.

    But the SDK probably already has support for the higher functionailty series of MIPS processor that can execute vector ops and floating point.

    I wondering how difficult it is to enable that functionality for MIPSFpga.
    like this: http://jonathan2251.github.io/lbd/_images/18.png or http://jonathan2251.github.io/lbd/_images/1.png

    I essentially want to extend the core, and run a benchmark to then test the core through c. Doing so through CLANG and LLVM is trivial. How would I do that in the current MIPS toolflow, if at all.

    By the way I’m sorry if this is a preposterous question. I’m a VLSI student, architecture is as high as I’ve ever gone in the flow, so I don’t know too many systems things.
    I also only have this idea because of this extensively well documented book http://jonathan2251.github.io/lbd/index.html that uses a vague CPU0 architecture.

    #49708

    Dear Ronobir
    I have highlighted your questions about the SDK and GCC to our experts. I’d expect some advice from them soon.
    Regarding the rest of your questions: we are afraid this is beyond the level of support we can provide here.
    Getting together with some of the people who have done this kind of activity would probably be the best way to progress.

    #49711

    Hi Robobir,

    This sounds like a really interesting project, I have a few questions for you prior to making any suggestion about what you should do in the tools.

    You commented on implementing a MIPS V FPU but the base architecture for MIPSfpga is MIPS32R3. Standard GCC and LLVM support for an FPU will utilise all FPU instructions that relate to the base architecture. In order to target a MIPS V FPU without any changes to GCC internals then you would need to configure a toolchain that targets MIPS V integer and FPU. Since MIPS V is a 64-bit architecture you would also have to use the 32-bit subset of MIPS V which is supported in the source. The resulting code would work on MIPSfpga.

    The binary releases of the Codescape GNU tools will not include MIPS V 32-bit libraries as our minimum supported architecture is MIPS32R2 for the product. You can however take the source release and build a 32-bit MIPS V cross compiler. It is also relatively simple in GCC to change the backend to define a processor that is MIPS32R2 for integer and MIPS V for FPU. You will almost certainly find GCC is more flexible in this respect than LLVM as it supports a rich set of unusual MIPS architectures. Almost all the changes you would need to make would be #define ISA_HAS_<SOMETHING> and set them appropriately.

    If at all possible I would suggest implementing the few additional instructions to get to MIPS32R2 compatible FPU so that you can just use the Codescape binary toolchain release where that configuration is our primary supported architecture.

    All this is possible in LLVM but you will almost certainly need to do more work to create the configuration you need as it doesn’t yet have support for any architectures that are not 100% arch compliant.

    Are the additional instructions in MIPS32R2 vs MIPS V too complex for you to implement?

    Thanks,
    Matthew

    #49719

    Ronobir
    Member

    I should have double check with the updated ISA, I knew it was a microaptiv core but didn’t connect that it was MIPS32 compliant. I don’t particularly care to reintroduce MIPS V, simply the reference manual I had read was a MIPS V one where I checked the FP support. It was harder to get the programmers reference manuals for MIPS32 since when I go on the programmers page, it says my account cannot download the ISA. So I had to stick to using google. But I should clarify, I don’t care about the ISA support per se, I’d like to enable floating point capabilities on the MIPSFpga and then test on C, so I’d like to work towards that end. I was incorrect to think of MIPS V and thanks for letting me know it was MIPS32 release 3.

    I’m glad there is extensive support. And it seems that there is almost preconfigured support in that case for the entire MIPS32 ISA.

    So I’ll go through my flow:

    I architected CP1 (MIPS32 floating point coprocessor?) with the .fmt instructions defined in the ISA. I go through my verification flow of CP1, through a BFM and then finally test connected to the main processor for a full validation. Everything works as expected.

    Now, I want to go into C and use

    float a = 1234.567;
    float b = 3.333333;
    float sum;
    int main (void)
    {
    sum = a + b
    printf(“Your floating point value is: %4.2f \n”, sum);
    }

    I make the makefile, debug the file, then compile. And it should work as expected?

    There are no other intermediary steps to take, and the current GCC toolchain will work instantly?

    That would be fantastic!

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.