DesignStart Eval on Terasic DE10-Standard Board

Hello,

For my bachelor thesis I have to implement the RTL-Code of the Cortex-M3 in the DE-10 Standard Board.
The FPGA on the Terasic DE-10 Standard is the Cyclone V  5CSXFC6D6F31C6.

If I try to compile the ".sof" file of the Eval package in Quartus Prime file, I get the error that there are not enough i/os (430 required, 288 available).

If I try it on the  Terasic DE2-115 with the Cyclone IV EP4CE115F29C7N I get the error "can't place all RAM cells in design".

My questions:
Is it possible to adapt the design to the I/O and/or the RAM-structure?
Do I have to do that manually in Quartus Prime?

Is there another way to compile the RTL-Code on the board than in Quartus Prime?
I read the documentation of the DesignStart Eval, but couldn't find something about this subject.

Thank you in advance.
Parents
  • Hi Sieg,

    This is expected that a design for one FPGA won't 'just work' if you change the device. There is nothing that fundamentally stops you doing this, but there are several things to be aware of. It is not a process which we support, but I'd encourage you to share your top level files, scripts and results if you can. Note that only a limited set of files are OK to redistribute though.

    The Cortex-M3 DesignStart Eval RTL Customization Guide has a few pointers, but here are a few thoughts that your question touches:

    • Cortex-M3 DesignStart includes several peripherals which match the MPS-2 development platform. These account for a good proportion of the large I/O count, and include the large external memories. Your board has DDR3 RAM and maybe FLASH which you might want to use, as well as other peripherals.
    • You will need to modify the RTL and the pin locations in AN511_SMM_CM3DS.qsf, then re-compile the project. You may need to edit the verilog source code to achieve this.
    • The design uses FPGA block-ram for code and internal ram regions. Your device ought to have capacity for these.
    • You can compile the verilog in a simulator (scripts are included). In order to generate a bitfile for the FPGA, you do need to use the Quartus tool. Given the amount of change you need to make, I expect you should be using simulation for debug.
    • You need to provide a mechanism for downloading a software image to the eventual design. This can either be by implementing a debug interface (Serial-wire debug and a probe like ULINK2 or DIP-DAP), pre-loading the block-ram instances as part of the FPGA bitstream, or using a secondary processor on the board to copy from SD card (as is implemented on the MPS2).
    • Even if you implement a hardware mechanism to pre-load the code image, you may want to implement debug for the ARM core, otherwise bringup will be hard.

    I hope this gives you some useful ideas.

    Sean

Reply
  • Hi Sieg,

    This is expected that a design for one FPGA won't 'just work' if you change the device. There is nothing that fundamentally stops you doing this, but there are several things to be aware of. It is not a process which we support, but I'd encourage you to share your top level files, scripts and results if you can. Note that only a limited set of files are OK to redistribute though.

    The Cortex-M3 DesignStart Eval RTL Customization Guide has a few pointers, but here are a few thoughts that your question touches:

    • Cortex-M3 DesignStart includes several peripherals which match the MPS-2 development platform. These account for a good proportion of the large I/O count, and include the large external memories. Your board has DDR3 RAM and maybe FLASH which you might want to use, as well as other peripherals.
    • You will need to modify the RTL and the pin locations in AN511_SMM_CM3DS.qsf, then re-compile the project. You may need to edit the verilog source code to achieve this.
    • The design uses FPGA block-ram for code and internal ram regions. Your device ought to have capacity for these.
    • You can compile the verilog in a simulator (scripts are included). In order to generate a bitfile for the FPGA, you do need to use the Quartus tool. Given the amount of change you need to make, I expect you should be using simulation for debug.
    • You need to provide a mechanism for downloading a software image to the eventual design. This can either be by implementing a debug interface (Serial-wire debug and a probe like ULINK2 or DIP-DAP), pre-loading the block-ram instances as part of the FPGA bitstream, or using a secondary processor on the board to copy from SD card (as is implemented on the MPS2).
    • Even if you implement a hardware mechanism to pre-load the code image, you may want to implement debug for the ARM core, otherwise bringup will be hard.

    I hope this gives you some useful ideas.

    Sean

Children