Embedded Processors and Peripherals

[gusevv]

I also tried the second approach with PLB BRAM controller:

- One LMB connected BRAM 64K    (0x00000000-0x0000FFFF)

- One PLB connected BRAM 32K     (0x00010000-0x00017FFF)

Again, writing to address 0x00010000 via XMD and reading back from 0 returns the same written result. So, the PLB BRAM is ignored. The values are always mapped to the first 64K.

XMD% mrd 0x0 3
   0:   88008800
   4:   00000000
   8:   B8080C40


XMD% mrd 0x10000 3
   10000:   88008800
   10004:   00000000
   10008:   B8080C40

XMD% mwr 0x00010000 0x12312312

XMD% mrd 0x0 3
   0:   0x12312312
   4:   00000000
   8:   B8080C40


XMD% mrd 0x10000 3
   10000:   0x12312312
   10004:   00000000
   10008:   B8080C40

MHS snippet:

----------

BEGIN microblaze
 PARAMETER INSTANCE = microblaze_1
 PARAMETER HW_VER = 7.00.a
 PARAMETER C_DEBUG_ENABLED = 1
 PARAMETER C_FAMILY = virtex5
 PARAMETER C_INSTANCE = microblaze_1
 PARAMETER C_FSL_LINKS = 2
 BUS_INTERFACE IPLB = mb_plb_1
 BUS_INTERFACE DPLB = mb_plb_1
 BUS_INTERFACE SFSL0 = fsl_v20_2
 BUS_INTERFACE SFSL1 = fsl_v20_4
 BUS_INTERFACE DEBUG = debug_module_MBDEBUG_1
 BUS_INTERFACE DLMB = dlmb_1
 BUS_INTERFACE ILMB = ilmb_1
 BUS_INTERFACE MFSL0 = fsl_v20_1
 BUS_INTERFACE MFSL1 = fsl_v20_3
 PORT INTERRUPT = Interrupt_1
 PORT RESET = mb_reset
END

BEGIN bram_block
 PARAMETER INSTANCE = lmb_bram_1
 PARAMETER HW_VER = 1.00.a
 BUS_INTERFACE PORTB = dlmb_cntlr_1_BRAM_PORT
 BUS_INTERFACE PORTA = ilmb_cntlr_1_BRAM_PORT
END

BEGIN lmb_bram_if_cntlr
 PARAMETER INSTANCE = ilmb_cntlr_1
 PARAMETER HW_VER = 2.10.a
 PARAMETER C_BASEADDR = 0x00000000
 PARAMETER C_HIGHADDR = 0x0000FFFF
 BUS_INTERFACE SLMB = ilmb_1
 BUS_INTERFACE BRAM_PORT = ilmb_cntlr_1_BRAM_PORT
END

BEGIN lmb_bram_if_cntlr
 PARAMETER INSTANCE = dlmb_cntlr_1
 PARAMETER HW_VER = 2.10.a
 PARAMETER C_BASEADDR = 0x00000000
 PARAMETER C_HIGHADDR = 0x0000FFFF
 BUS_INTERFACE SLMB = dlmb_1
 BUS_INTERFACE BRAM_PORT = dlmb_cntlr_1_BRAM_PORT
END

BEGIN lmb_v10
 PARAMETER INSTANCE = ilmb_1
 PARAMETER HW_VER = 1.00.a
 PORT SYS_Rst = sys_bus_reset
 PORT LMB_Clk = sys_clk_s
END

BEGIN lmb_v10
 PARAMETER INSTANCE = dlmb_1
 PARAMETER HW_VER = 1.00.a
 PORT LMB_Clk = sys_clk_s
 PORT SYS_Rst = sys_bus_reset
END

BEGIN bram_block
 PARAMETER INSTANCE = bram_block_2
 PARAMETER HW_VER = 1.00.a
 BUS_INTERFACE PORTA = xps_bram_cntlr_2_PORTA
END

BEGIN xps_bram_if_cntlr
 PARAMETER INSTANCE = xps_bram_cntlr_2
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_BASEADDR = 0x00010000
 PARAMETER C_HIGHADDR = 0x00017FFF
 PARAMETER C_SPLB_NATIVE_DWIDTH = 32
 BUS_INTERFACE SPLB = mb_plb_1
 BUS_INTERFACE PORTA = xps_bram_cntlr_2_PORTA
END


[goran]

Hi,

That should work, LMB and LMB_BRAM controllers are using 32-bit addresses.

However you are using an old version EDK 9.2 (the latest is 13.2 and 13.3 is soon released).

There has been some issues with the C_MASK on the LMB BRAM controllers in the past.

The C_MASK value mask away all address bits that isn't needed for the address decoding logic.

The values is calculated by the tools and for some systems in the past, it has generated a wrong value.

Could you give the C_MASK values from the lmb bram controller wrappers in the /hdl directory?

Could you also attach the complete .mhs file?

Göran

[gusevv]

Hi Goran,

Here are the C_MASK values for my lmb_bram_if_cntlr controllers:
hdl/dlmb_cntlr_1_wrapper.vhd
  dlmb_cntlr_1 : lmb_bram_if_cntlr
    generic map (
      C_BASEADDR => X"00000000",
      C_HIGHADDR => X"0000FFFF",
      C_MASK => X"c0010000",    <-- Has the same mask as dml_cntlr_2!
      C_LMB_AWIDTH => 32,
      C_LMB_DWIDTH => 32
    )

   ...

hdl/dlmb_cntlr_1_wrapper.vhd:

  dlmb_cntlr_2 : lmb_bram_if_cntlr
    generic map (
      C_BASEADDR => X"00010000",
      C_HIGHADDR => X"00017FFF",
      C_MASK => X"c0010000",
      C_LMB_AWIDTH => 32,
      C_LMB_DWIDTH => 32
    )
   ...
Both controllers have the same mask! It does look like the problem appeared during the Platform Gen step. How can I fix this without changing the tool versions? I am stuck with EDK 9.2 for now due to a Linux kernel I am running on it.

-----
BEFORE I added the second LMB controller, I had the following statement in the system.log:
INFO:MDT - IPNAME:dlmb_cntlr_1 INSTANCE:lmb_bram_if_cntlr -
   /data/Xilinx/9.2i/edk/hw/XilinxProcessorIPLib/pcores/lmb_bram_if_cntlr_v2_10_
   a/data/lmb_bram_if_cntlr_v2_1_0.mpd line 43 - tcl is overriding PARAMETER
   C_MASK value to 0xc0000000

AFTER:
INFO:MDT - IPNAME:dlmb_cntlr_1 INSTANCE:lmb_bram_if_cntlr -
   /data/Xilinx/9.2i_2/edk/hw/XilinxProcessorIPLib/pcores/lmb_bram_if_cntlr_v2_1
   0_a/data/lmb_bram_if_cntlr_v2_1_0.mpd line 43 - tcl is overriding PARAMETER
   C_MASK value to 0xc0010000
INFO:MDT - IPNAME:dlmb_cntlr_2 INSTANCE:lmb_bram_if_cntlr -
   /data/Xilinx/9.2i_2/edk/hw/XilinxProcessorIPLib/pcores/lmb_bram_if_cntlr_v2_1
   0_a/data/lmb_bram_if_cntlr_v2_1_0.mpd line 43 - tcl is overriding PARAMETER
   C_MASK value to 0xc0010000

-----

For MHS with 2 LMB controllers on microblaze_1, see the system.mhs.2lmb_brams file attached to my 09-25-2011 06:06 PM  post.(THIS is the version I am primarily interested in, the 2LMB BRAMs rather than LMB+PLB).
For MHS with 1 LMB and 1 PLB BRAM controller on microblaze_1, see system.mhs.lmb_and_plb_brams file attached to this post (the code snippet in my previous post is from here).

Thanks,

Victor

[goran]

Hi,

The MASK tells which address bits are needed to distinquish LMB from PLB and also among LMB slaves if they are multiple on the same LMB bus.

So multiple LMB controllers can have the same MASK.

Didn't know that you had multiple MicroBlazes.

Are you sure that you have connected XMD to the 2nd MicroBlaze and not the 1st MicroBlaze?

The 1st MicroBlaze only has 8kbyte of LMB and it will wrap around the addresses you shown from XMD.

Next step is to have a simple assembler program that writes and reads to these addresses and simulate it.

In the waveform, you will be able to see what the issue is.

Göran

[gusevv]

Goran,

I doble checked to make sure I do not connect to the wrong microblaze from XMD. microblaze_0 with 8K wraps around 64K (confirmed), the microblaze_1 also wraps around 64K instead of reading further. HOWEVER, read below (I can access 64K+ if synthesized from within ISE!)

1) PROJECT 1: EDK 2 contiguous LMB, synthezied from within EDK (As described in the previous posts)

XMD% state

------------------------------------------------

System(0 ) - Hardware System on FPGA(Device 5) Targets:

------------------------------------------------

                Target(0) - MicroBlaze(1) Debug Target

                Target(1) - MDM Uart Channel Target

                Target(2) - MicroBlaze(2) Debug Target*

XMD% mrd 0 3

       0:   B8080050

       4:   00000000

       8:   B8080C40

XMD% mrd 0x10000 3

   10000:   B8080050  

   10004:   00000000

   10008:   B8080C40

XMD% mwr 0x0 0x23456789

XMD% mrd 0 3

       0:   23456789

       4:   00000000

       8:   B8080C40

XMD% mrd 0x10000 3

   10000:   23456789   <-- wrap around after 64K (not expected)

   10004:   00000000

   10008:   B8080C40

----------

2) PROJECT 2: As a part of another project (run on a different machine with supposedly the same tool versions ), the described EDK project is further encapsulated with a wrapper in ISE, with clock manager moved to the top level (that's it for hardware changes at EDK level). Similarly, there are 2 contiguous LMB slaving off the microblaze_1's bus. IN THIS CASE I CAN SEE all 96K in XMD!

Can it make a difference like that?

--------------------------------------------------------

System(0) - Hardware System on FPGA(Device 5) Targets:

--------------------------------------------------------

Stopped                               Target(0) - MicroBlaze(1) Debug Target

Stopped                               Target(2) - MicroBlaze(2) Debug Target*

XMD% mrd 0 3

       0:   B8080050

       4:   00000000

       8:   B8081584

XMD% mrd 0x10000 3

   10000:   00000000

   10004:   00000000

   10008:   00000000

XMD% mwr 0x10000 0x34343434

XMD% mrd 0x10000 3

   10000:   34343434    <-- Successfully written at 64K

   10004:   00000000

   10008:   00000000

XMD% mrd 0 3

       0:   B8080050    <-- 0x0 is still the same

       4:   00000000

       8:   B8081584

----------

3) For ISE+EDK, From 96K it wraps to 64K in debugger. It sounds as this is expected.

target 2                  

XMD% mrd 0 3

       0:   B8080050

       4:   00000000

       8:   B8081584

XMD% mrd 0x10000 3

   10000:   34343434

   10004:   00000000

   10008:   00000000

XMD% mrd 0x18000 3

   18000:   34343434  <-- wrap around after 96K back to 64K

   18004:   00000000

   18008:   00000000

----------

4) I did not check whether resynthesizing the same EDK PROJECT #1 on another machine makes a difference yet, but will do.

Thanks,

Victor

[goran]

Hi,

That is very weird.

I have never experienced something like this.

Have you done "clean hardware" on all these projects before reimplement them?

Sometimes stuff might be left over which maybe a causing this.

Next step would be to create to identical projects but one implemented in ISE and compare the EDK directories, especially the /hdl directory.

Göran

[gusevv]

Goran,

Good news!

1) After resynthesizing the hardware the problem is gone.

2) I double checked on the other mentioned machine as well with just the EDK without the top wrapper and it also worked.

So, it must have been some baggage from the previous HW generation. The only other reason I could think of is if I somehow still used the old bitstream, but I always try to check the timestams, so the former is more likely.

To confirm, it is 2 LMB controllers (64K + 32K) connected to the same shared LMB bus that works. I haven't tested the LMB + PLB BRAM option, but it likely didn't work for to the same reason.

Thank you for your support,

Victor

[thirdeye]

Yes, I have wasted hours, days, weeks due to EDK/ISE not rebuilding things that have been updated or should be rebuilt. I have learned to clean hardware everytime I change something of importance otherwise I cannot trust that the tools will rebuild it.

I typically work with ISE designs that have and EDK project as a source file. I almost always manually build the netlist in EDK, then clean everything in ISE and then rebuild in ISE in order to get ISE to rebuild the EDK project - otherwise I do not know if I am testing my changed design or the old one.

It is too bad I cannot trust the tools to know because it takes longer to build after a clean, but I have experienced this over and over, especially with EDK designs. I am not sure that ISE with an EDK source file is designed to recognize updates in the EDK project - I certainly have not experienced it knowing.

Sometimes I will manully go and delete the ISE or EDK implememntation file for the sources that I updated to ensure it will rebuild them. Sometimes this causes me errors so I clean all and start over.

Also, often, just opening EDK will cause me to have to rebuild my ISE design or it gives me software errors when trying to buid my software code into the bitstream. This makes no sense to me - especially when ISE rarely recognizes a hardware change in EDK that I want it to see, but it thinks there has been a change when there has not.

Clean always if you want to be sure.

Hope this helps someone.

Josh

[johnmcd]

EDK will cache generated netlists for cores. If the netlist is already present, EDK will just copy the cached version instead of re-synthesising. If you have a custom core, it would be nice if EDK re-synthesised if you modified the HDL for the core. Well this is possible.

For the custom core, edit the mpd file and add or modify it to contain the following line:

OPTION ARCH_SUPPORT_MAP = (others = DEVELOPMENT)

With the above line in the mpd of the core, EDK will add all the hdl for that core into the automatically generated system_include.make causing the core to re-synthesis anytime any of its hdl changes.

Refer to UG642 for a description of this option in the mpd file.

[thirdeye]

Ah yes, I have used OPTION ARCH_SUPPORT_MAP = (others = DEVELOPMENT). I found that very useful except that it rebuilds everytime when really I just want it to rebuild when it has changed. I undertsand the nature of cores and I think this actually operates appropriately.

My issue is not that EDK does not rebuild my custom pcore it is that ISE does not rebuild my EDK project even when it has changed and even when I have rebuilt the netlist in EDK. ISE caches the EDK project netlist and does not update it unless I manually delete the EDK cached files in the ISE directory or use 'cleanup project files' to delete everything.

FYI, I am using an EDK project as a source file in an ISE project.

It appears to me that sometimes ISE knows that the EDK project has changed and says it is out of date, but the majority of the time it is not aware of the EDK project changes. The behavior does not seem consistent or I would not have a problem.

To cover myself I assume that it is completely unaware and I clean and rebuild in EDK, then clean and rebuild in ISE to ensure that the modifications propogate through the pipeline of tools.

I appreciate your response.

Thank you,

Josh

---

johnmcd wrote:

EDK will cache generated netlists for cores. If the netlist is already present, EDK will just copy the cached version instead of re-synthesising. If you have a custom core, it would be nice if EDK re-synthesised if you modified the HDL for the core. Well this is possible.

For the custom core, edit the mpd file and add or modify it to contain the following line:

OPTION ARCH_SUPPORT_MAP = (others = DEVELOPMENT)

---