1. Home
  2. Field-Programmable Gate Arrays
  3. Xilinx MPMC2 "External Ports" question

Xilinx MPMC2 "External Ports" question

Hi all,

Has anyone ever had success routing an NPI port of the MPMC2 controller to an External Port of a PPC based system component in EDK (i.e. I would like to route an NPI port to some custom logic...I use the flow where I use EDK simply to generate a component & I subsequently instantiate this in the top level of my VHDL design)? I am having a lot of problems doing this. Xilinx doesn't have a reference design available for this partuicular case; however, the documentation for MPMC2 implies that one can do this. Please keep in mind that I am an EDK newbie....I have been using Xilinx Alliance/ISE/etc. for many years though :)!

What I seem to be seeing is that MPMC2 declares the NPI interface to be a "transparent bus". Now, does this imply that I have to make some kind of "bus to pins" converter and subsequently declare this component in an MPD file, or is this completely useless? What I tried doing was modify the MPMC2 MPD generated by the GUI...I simply removed the "transparent bus" declaration from the MPD as well as all the labels on the ports that were part of this bus, but that did not seem to help. It almost seems like EDK is automatically recognizing the NPI bus as some sort of "bus" and is getting confused no matter what I comment out of the MPD.

I understand that my above description sounds rather stupid. However, I am just throwing this out there for discussion to see if anyone was successful doing this. Basically, my MPMC has 5 ports :

ISPLB DSPLB PLB (seems I need this so that I can add PLB slaves....if not added in the MPMC2, I recall seeing errors...all reference designs seem to have this as well). OPB (again, seems like I need this in the MPMC2 or else I get errors when adding OPB slaves to my EDK design...all reference designs seem to have this as well) NPI

All I really thought I would need would be the ISPLB and DSPLB so that the PowerPC would have fast access to the DDR DRAM. The NPI is basically intended as port for storing data that is streaming into the FPGA. I hope to use custom hardware to pop data from DRAM after the PowerPC does some processing on it.

If anyone has any tips, tricks, pointers, etc., it would be appreciated greatly! I filed a webcase on this, but I would have to imagine that someone out there has run into this situation before!

Thanks!

Ed

PS After re-reading this before posting, I realized that some of the errors or warnings I get are related to the block diagram generator getting confused about multiple busses and probably not able to place and route the block diagram...this might simply be a red herring & an actual physical implementation might be OK....I will post again if that is the case, but I am having problems with the PLB masters and slaves now not having matching bit widths...ugh...

Reply to
ed_h
Loading thread data ...

"ed_h" schrieb im Newsbeitrag news: snipped-for-privacy@80g2000cwy.googlegroups.com...

1) dont change the MPD 2) in EDK set port visible filter "all" you should see all ports of all cores, and you can make any of then exertnal

Antti

Reply to
Antti Lukats

HI Antti,

First and foremost, thank you for the reply!

I tried your suggestion at first, but when I go to build the netlist in EDK after connecting the ports using your suggested method, I get this error:

ERROR:MDT - mpmc2_ddr_idpon_100mhz_x16_mt46v16m16_6t (mpmc2_ddr_idpon_100mhz_x16_mt46v16m16_6t_0) - C:\projects\test_single_npi\system.mhs line 235 - transparent bus interface connector 'npi_4' is only referenced once!

That is why I started editing the MPD and started removing the transparent bus parameters and the like. I should have been a little clearer in my initial post, but just let me blame that on my inexperience with EDK :) .

When I remove the transparent bus types from the MPD, I get this warning when I generate the block diagram :

WARNING:MDT - Bridge mpmc2_ddr_idponn_100mhz_x16_mt46v16m16_6t_0 is connected to more than two busses WARNING:MDT - This condition is not handled by layout algorithm

Now I am starting to wonder if "layout" means layout of the block diagram.....for whatever stupid reason, I associated "layout" with "place and route" since I used to "layout" ASICs for a living a long, long time ago :)! If all this means is that my block diagram is incorrect (which it is after I remove the transparent bus), I can most definitely live with that...

Again, many thanks! I'll be sure to post the solution to my problem should I figure it out :)!

Ed

Antti Lukats wrote:

Reply to
ed_h

"ed_h" schrieb im Newsbeitrag news: snipped-for-privacy@l12g2000cwl.googlegroups.com...

hm.. if the direct port export realy isnt working you need to create a dummy wrap-export ip core that doesnt do anything except connects to NPI and export wires that can be used as external ports. this should work, and I would say its better than post modifying the MPMC2 generated MPD file

Antti

Reply to
Antti Lukats

Ed,

I haven't tried exporting MPMC2 ports, but I succeded in designing a NPI peripheral. If you really want to export the pins you probably have to do what Antti says, i.e. create a dummy peripheral. But then why not to do your whole custom thing as a peripheral?

/Mikhail

Reply to
MM

Ed,

What are you doing? Do not try to change anything of the MPMC2 core! If there is no connection to NPI port, just it coment it in MHS: # BUS_INTERFACE MPMC2_PIM_4 = npi

I created NPI peripherals with single write (64bits), 4 words (2x

64bits) cacheline write and 64 words write (the fastest xfer). The declaration of NPI port should look like in MPMC2 MPD.

The NPI port is very handy bus to connect peripherals that require fast and simple DMA access - huraa for the Xilinx MPMC2 team.

Cheers,

Guru

ed_h wrote:

Reply to
Guru

Mikhail,

What I am trying to do is "quickly" generate a memory interface where my custom logic loads DRAM with data and the PowerPC performs computations based on data I loaded into this area of memory. Chances are that as I gain more experience with EDK I will make all of my custom logic a peripheral....until then, I am simply getting started with MPMC2 and taking it from there. Without going into high level details of the design, I am using this approach to give software engineers the ability to test algorithms out on the data stored in DRAM while I migrate SW algorithms to hardware (if reasonably possible). Eventually, I might be able to fit everything in HW, but we will see. I am not expecting the software to run in real time, but we will be able to see results at lower than full rate.

Overall, it looks like I need to make an NPI set of wires to plug into the NPI port...I agree that modifying the generated MPD is not the way to do things :)! I already did this, but I must have some error in the files since EDK is not seeing my perhipheral :)! I'll fix this soon enough though.

After I get this running, I have a few more questions about MPMC2, but I will save those for later...my hope is that this (and related) thread can become a reference for future users of this logic. If I get permission from the powers that be where I work, I will post the resulting files to make this easier for users in the future. I also hope Xilinx can include the stub in a future release of MPMC2 for other users.

By the way, this MPMC2 is an outstanding piece of IP to offer to users for free....I am curious to see the performance! Although I am having headaches (and I am sure it is due to my inexperience with EDK), this should save me a lot of time nonetheless!!!!

Ed

Reply to
ed_h

Agreed. I am doing this now...I am making a Verilog file that wires directly to/from the NPI ports as well as the associated MPD. I am using the NPI PLB as a reference....I will hopefully have results later today. I started to do this earlier, but I cannot get EDK to see my "wires" peripheral...I am assuming that I have a bug somewhere in my new files...

Ed

Reply to
ed_h

I am not trying to change the core :)! I am only playing with the MPD right now. However, I am going to stop using that approach and create a component that will (hopefully) export the wires.

OK.

I agree 100% ... this core is a huge time saver and offers some nice flexibility. I am curious to see what performance is like :)!

exertnal

Reply to
ed_h

The performance benefit is amazing as you will found out. The only drawback is significant logic and BRAM consumption.

Cheers,

Guru

Reply to
Guru

I got this working today using the following configuration :

16 bit interface to DRAM (yes, I am using the ML403 right now, but I plan on migrating to a mini-module in the near future).

One PLB interface (I will split this out to ISPLB and DSPLB later...I had issues, but that is probably due to lack of experience with EDK).

One NPI interface. I created an NPI "wrapper" and connected this to the NPI port on the MPMC2. Just curious, I noticed that "transparent" busses are being depreciated according to some documentation I read...what is the replacement bus type going to be?

Everything looks good so far in terms of running in hardware. With this base configuration up and running, I'll have plenty of time/flexibility to experiment. The first thing I want to do is use the ISPLB/DSPLB interfaces for the performance increases. For now, I am simply running a memory test over the weekend.

Just curious, did anyone get this up and running using SRL16s as opposed to BRAM for the interface FIFOs? I cannot wait for the version of the core where you can trade off LUTs for BRAM since the ideal situation is a mix of memories....still, this is more than adequate for now :)!

Xilinx support has been very helpful as well as this group. Thanks! I hope to return the favor someday :)! I've been lurking way too long...

Ed

ed_h wrote:

Reply to
ed_h

Congratulations! You should feel good now! :) I am now trying to get MGTs running and don't feel even half as good as you probably are :(

/Mikhail

Reply to
MM

Mikhail,

Last year, I was three steps away from the funny farm when implementing a desgin with the x4 PCI Express core in a Virtex 4 FX (this used MGTs). What problems are you having?

Just to state the obvious, be sure that you are using the proper silicon stepping in the UCF, make sure you have obeyed any Xilinx reference clock specification (this changed from 125MHz to 150MHz for PCI Express), and insure your board is electrically sound (we had minor crosstalk issues on a early version of our custom board, but that was easy to fix...fortunately for us, it was not on lane zero of PCIe)...that's probably obvious to you, but these are some simple suggestions that I have found that others overlook :)! Also, on V4 FX, the MGT reference voltage is .1V lower than what the datasheet specifies if I am not mistaken...that .1V seemed to really matter too :) :) !!!! This might have changed now that V4FX is in (or close to) production, but double check this with Xilinx.

Is there a thread where you are discussing this?

Ed

MM wrote:

Reply to
ed_h

Ed,

I have started a thread but no one commented so far... Basically, I have 2 boards , which should talk to each other using basic Aurora simplex protocol. One board has V4FX20CES2 and the other V4FX60CES4. I am testing FX20 to FX60 transmit and the problem seems to be that the receiver's PLL doesn't lock and consequently neither LANE_UP, nor CHANNEL_UP signals come up... Unfortunately, my design doesn't lend itself very well to using Xilinx debug solutions. I can't use ChipScope with BERT because it wouldn't allow for selecting which transceivers to activate, but instead activates all available on chip. This kills my 1.1V/1.2V MGT power supply, which was designed to run only a few transceivers... Another mistake I did was not to use receivers and transmitters in the same transceiver. In other words I have all of my receivers on one side of the chip and all the transmitters on the other side. The reason for this was to have potentially different reference clocks. Now, it turned out that every single Xilinx sample design involving loopback expects both receiver and the transmitter to be a part of the same transceiver. Besides, generating TX only or RX only cores frequently leads to bugs. Another issue is of course silicon stepping. The CES2 is not supported by the latest Aurora core (v2.5), and the CES4 is not supported by the v2.4. This creates a mess... Add here all the mess with calibration blocks, such as Aurora v2.4 generates core with calblock 1.2.1 and Xilinx knowledge base states that this MUST be changed to 1.2.2. The latest RocketIO wizard on the other hand uses calblock 1.1.1 for the CES2 silicon... Perhaps I shouldn't be digging into this, but the thing doesn't work and I just don't know where to look...

Yeah, it should be 1.1V for CES2 and 1.2V for CES4....

Thanks, /Mikhail

Reply to
MM

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.