1. Home
  2. Field-Programmable Gate Arrays
  3. Post-Place & Route simulation with MicroBlaze

Post-Place & Route simulation with MicroBlaze

Hi all,

I have a design where MicroBlaze isn't the top level of it.

I have simulated the behavioral model with ModelSim SE 5.6f and it works fine but when I implement and download to the FGPA it doesn't work, so now I want to simulate the Post-Place & Route model too see if there's any timing wrong.

Due to my MicroBlaze desing isn't the top level, XPS doesn't allow me generate the behavioral model, so I have to do it manually. That's the way I have done the behavioral model simulation.

So I have a Project Navigator design with various components which one of them is the MicroBlaze designed in XPS. In the testbench I use a configuration block where I assign the code that needs to be inside the blockram of MicroBlaze. Since MicroBlaze isn't my top level this configuration block has the next aspect:

configuration testbench_conf of system_tb_system_vhd_tb is for behavior for uut1 : top_level for structure for uut2: mb_blaze for structure for all: instr_mem_wrapper use configuration work.instr_mem_conf; end for; end for; end for; end for; end for; end for; end testbench_conf;

The problem comes here. When I ask ISE to simulate the P&R model it generates a file called "top_level_timing.vhd" which hasn't got any hierarchy, so obvioulsy the configuration block generates some compilation errors.

Is there any other way to assign the contents of the instruction set to the blockram of MicroBlaze?

Any other idea to avoid this error?

I am not used to working with configuration blocks, so the solution might be obvious.

Thanks in advance,

Arkaitz.

Reply to
arkaitz
Loading thread data ...

If you ask XPS to generate the timing model for you, you can use their configuration to know what the hierarchical names of the BRAMs are (and their contents). When you synthesize this in PNav, chances are that the hierarchy will simply get flattened out by replacing (for example) "system/sub" with "system_sub". You can therefore retrace the instances in "top_level_timing.vhd" and "flatten" your configuration accordingly.

Take the appended code for example (pulled from an actual project). System_top is my my system wrapper, system is the timing model generated by XPS. My MBlaze was the top module, but I expect all this should change is that your blockRAMs would be called "mb_blaze_bram1_bram1..." instead of "bram1_bram1...". Good luck :)

--
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --

--------------------------------------------------------------------
library simprim;
use SIMPRIM.VCOMPONENTS.ALL;
use SIMPRIM.VPACKAGE.ALL;
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
library ddr_fsl_v1_00_a;
use ddr_fsl_v1_00_a.ddr_sdr_conf_pkg.all;

entity system_top is
end system_top;

architecture struct of system_top is

   component MT46V16M16
   (...)
   end component;

   component system
   (...)
   end component;

begin
   (...)
   inst_MT46V16M16: MT46V16M16
     port map(
     (...)
     ); --end MT46V16M16;

   inst_system: system
     port map(
     (...)
     ); --end system;
end struct;

configuration system_conf of system_top is
   for struct
     for inst_system : system
       use entity work.system(STRUCTURE);
       for STRUCTURE
         for bram1_bram1_ramb16_s4_s4_0 : x_ramb16_s4_s4
           use entity simprim.x_ramb16_s4_s4(x_ramb16_s4_s4_v)
           generic map(
             INIT_00 =>
             (...)
         end for;
           for bram1_bram1_ramb16_s4_s4_1 : x_ramb16_s4_s4
             use entity simprim.x_ramb16_s4_s4(x_ramb16_s4_s4_v)
             generic map(
             (...)
         end for;
       (multiple bram instances follow...)
       end for;
     end for;
   end for;
end system_conf;
Reply to
PO Laprise

Arkaitz,

If you're doing your top level development from ISE (which it sounds like you are), there is a fairly simple way to avoid the configuration statement in the testbench.

To do this, just add your executable.elf file to the ISE project as a source. When you do, ISE will ask you how you want the file assigned, you should choose the top level file (top_level I believe you called it). This will initialize the Block RAM in the .ncd file and therefore will be in the simulation model for the post-par simulation. This may not be convenient for future revisions of your software, as you have to rerun implementation for an update, but this will make your simulation much easier to set up as everything's all in one model.

I hope this helps.

Best regards, Ryan Laity Xil> Hi all,

Reply to
Ryan Laity

Hi,

I've tried this several times but it doesn't work. I don't know still why.

What I do is to configurate the CPU in XMDSTUB mode so that XMD can work, but I it fails when connecting.

Any ideas?

Regards,

Arkaitz.

Reply to
arkaitz

Arkaitz,

As a sanity check through this flow (only), you can simply open FPGA Editor and look at the contents of the i-side BRAM to make sure that some of them are non-zero. To do this, open the design in FPGA Editor, find instruction-side BRAM, view it (select then double-click on it), then hit the button that looks like "F=" and it'll bring up its attributes in the window. If they're all zero then something went wrong in updating the BRAM through implementation. If there are some init values that are non-zero then you've got some code in the BRAMs so you need to look elsewhere for another problem.

Since you're going to simulation, you can also check the init values for the BRAM in Modelsim. Just select the BRAM in the hierarchy window and look at the signals window for that BRAM. You should then see init values in the signal window - make sure some of them are non-zero as well.

As for XMDSTUB mode, I suggest that you make your life easier and use the MDM. If you do, you can then go through the flow for executable mode and still use the debugger when it's all said and done. That's just what I'd suggest from my experience, there may be compelling reasons that you're using xmdstub.

If you are still unable to get anything to happen in simulation and/or connect to XMD, it'd probably be a good idea to open a case with customer support.

Best regards, Ryan Laity Xil> Hi,

Reply to
Ryan Laity

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.