The PLB address width is 32 bits. However, the way that all the bus signals are connected to the PLB IP is that they are concatenated together. So if you look at the MPD file for the PLB you will see that it defines the bus width to be 32 bits times the number of masters:
PORT M_ABus = M_ABus, DIR = I, VEC = [0: (C_PLB_NUM_MASTERS*C_PLB_AWIDTH)-1]
So the signal plb_M_ABUS is bit 30 of the second master. Look to see if your core has been assigned the second master slot on the PLB bus. Assuming that is the case, find what two sources are driving bit
30 of the address.
Assuming that you left the name of your EDK project as system.xmp, when you tell EDK to generate a netlist it will create a top level hdl file named either system.vhd or system.v depending on your tool settings. You can look at this file to see how EDK has connected the cores to the PLB.
It has been a while since I had to find a multi source signal, but I think that XST will produce a warning about it in its report and tell you what the multiple soures are. Look in the synthesis report file for the appropriate core and see if it tells you what the source of the problem is.
Since you are creating your own interface design instead of using the IPIF, are you using the bus functional models in your simulations? I use these, and they make the job much easier. I think it was not until EDK 8.1 that they were integrated into EDK itself, but I was able to use the CoreConnect tool kit directly from IBM in some of our early stuff. The bus monitors will tell you as soon as your core has done something wrong, so you do not have to track the source of the problem back from when the symptoms show up.
Where i could see the second master is who( power pc or custom peripheral ... etc)? I don't know where to check this.
I opened the system.vhd to see who connect to the plb_M_Abus. "PowerPC" have 2 ports and Custom peripheral has 1 port connect to the plb_M_ABus. Next step, I am going to find the XST report file to see who drive the plb_M_ABUS.
I didn't run the simulation of this platform. I heard the "bus functional model" before, but I don't understand how to use it. Would you like to give any information about this one?
In addition the error"NgdBuild 455", there are several warnings "SFF Primitive", i didn't find this on the Xilinx answer database.. maybe this warning has something to do with the error.
While there may be an easier way, you can just look at a PLB master signal that is not a vector. For example, if you look at plb_M_RNW in your system.vhd you will see that it is defined as:
signal plb_M_RNW : std_logic_vector(0 to 2)
The entire vector is an input to the plb_wrapper. plb_M_RNW(0) will go to PLB master 0, plb_M_RNW(1) will go to PLB master 1, etc.
No offense intended, but with just the PowerPC, and your new custom peripheral on the PLB bus the odds are that your peripheral is the source of the problem. Take a look at the synthesis report for it. In EDK, in the "Project Information Area" pane, and the Project tab, expand the "Report Files" selection. Find the one for your peripheral and look through it. I think there should be a warning about multiple sources driving a destination at this point. If you do not see it there, try looking through the implementation/xflow.log file in the "Log Files" section.
Take a look at:
formatting link
This link is for the EDK 6.3 version of the documentation, but you should have a more recent version in your EDK distribution at $EDK/doc/ bfm_simulation.pdf.
One of the main things that I like about using the bus functional models is that the bus monitors tell you when a error occurred in the simulation, and what the error was. This saves you the effort of having to search backwards from where the symptoms of the error show up to figure our what has gone wrong.
I check the synthesis report and I found something in implementation/ xflow.log file
ERROR:NgdBuild:455 - logical net 'plb_M_ABus' has multiple driver(s): pin G on block ppc405_0/XST_GND with type GND, pin G on block dma_mci_top_0/XST_GND with type GND, pin P on block ppc405_0/XST_VCC with type VCC, pin G on block plb2opb/XST_GND with type GND, pin O on block plb2opb/plb2opb/I_BGO_addrAck with type LUT4, pin G on block plb_bram_if_cntlr_1/XST_GND with type GND, pin P on block plb_bram_if_cntlr_1/XST_VCC with type VCC
There are 7 driver to drive this node and the dma_mci_top is the custom peripheral.
I have no idea about this situation. how come does it? I only import the custom peripheral and create a platform.
Does it any problem happend at the process of "Import Custom Peripheral" ? 'cause, during the import procedure, I need to set some bus parameter, like C_PLB_NUM_MASTER...etc. I try to find document on the Xilinx website, but I didn't find any tutorail about the Import procedure.
Would you like to give me any hints for solving this problem.
I used the import wizard just a few times to see what it did, then I started creating all my peripherals by hand, so I do not remember how it works very well. But, C_PLB_NUM_MASTER is a parameter/generic that needs to be set by EDK when it creates all the wrapper files for the PLB peripherals. Did you set it to a numeric value?
EDK includes the source code and support files for the cores that it comes with. Look through them for examples of how to create a PLB slave. If I remember correctly, the multi port memory controller reference design also has a PLB slave that is not based on the IPIF, and is simpler.
I set C_PLB_NUM_MASTER=2 in the verilog design. Does EDK change this parameter during creating platform?
I wil go to check the examples.
Besides, I saw an example that the custom peripheral is imported inot EDK without bus interface. How could I do this? I search several document, I don't see something to do with it.
EDK automatically sets the values of many parameters/generics when it creates the wrapper files. C_PLB_NUM_MASERS is one of the ones that EDK sets.
I would recomend that you read the "Platform Specification Format Reference Manual" which defines the contents of the data files that describes pcores to EDK. It is located in the EDK install directory at $EDK/doc/psf_rm.pdf. These files are being created for you by the import wizard. While reading this, look at some of the cores in EDK for examples. The EDK cores are located at $EDK/hw/ XilinxProcessorIPLib/pcores for the hardware parts, and at $EDK/hw/ XilinxProcessorIPLib/drivers for the software parts.
For what you are doing, you probably want to focus on examining the MPD file for your core. The MPD file contains the information that EDK uses to figure out how to connect a pcore to the rest of the system. It also defines the parameters/generics for a pcore.
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.