plb_tft_cntlr_ref for an ML405 EDK Project

Dear all,

I am working with an ML405 and trying to put together a project of my own that uses the plb_tft_cntlr_ref IP from the example project. I tried to import the IP using the "Create or Import Peripheral" wizard but it complains that there are a bunch of signals missing that are needed by the PLB. I've taken a look at the source and it certainly appears to be the case (caveat: I'm very inexperienced with this and I don't pretend to understand the PLB). What do I need to do to get this IP up and running in my project in the exact same way it was in the example? What am I doing wrong? This is all in EDK 8.2i BTW.

Thanks in advance,

-- Peter

Reply to
Peter Mendham
Loading thread data ...

"Peter Mendham" wrote in message news:f01v8b$r5q$ snipped-for-privacy@dux.dundee.ac.uk...

You don't need to do that. All you need to do is drop the plb_tft_cntlr_ref pcore into the "pcores" directory in your project. Then (once you've closed and re-opened the project so XPS re-reads the directory) you'll see it in the peripheral repository and you can just add it to the project like any other piece of IP in the library.

Cheers,

-Ben-

Reply to
Ben Jones

Ben,

Thanks for your resp Performing Clock DRCs...

This application has discovered an exceptional condition from which it cannot recover. make: *** [implementation/ppc405_0_wrapper.ngc] Error 1

That's not a good thing, right? ;) Any ideas?

Thanks in advance,

-- Peter

Reply to
Peter Mendham

Hi Peter,

"Peter Mendham" wrote in message news:f02g32$9da$ snipped-for-privacy@dux.dundee.ac.uk...

Depends how much you like error messages I suppose :-)

The SYS_plbClk port on the TFT reference design needs to be connected to the same clock as the PLB bus (which is often called sys_clk_s if you're using a design that originated with Base System Builder). The SYS_dcrClk similarly needs to be connected to the clock signal of the DCR bus. Neither of these clocks should need to come from an external pin. In fact I have a feeling that the DCR clock isn't even really a clock in the true sense of the word.

In the reference design project I saw, the DCR bus connection on the TFT block was connected to the PowerPC processor by means of an OPB-to-DCR bridge, for some obscure reason. You can do that, or you can hook it up to the PowerPC's DCR master port directly. The only difference is the action the software has to perform when accessing the TFT's control registers, which you only need to do if you want to (a) turn the thing on and off or (b) change the base address of the frame buffer dynamically.

Good luck,

-Ben-

Reply to
Ben Jones

I was wondering whether the non-appearance of these ports in my project was something to with the unexplained nasty error. Since these have never appeared under ports, I've never connected them up. This is a naive guess based on the fact that the error occurred whilst doing something to do with clocks. What do you think? A red herring? Is there any way to persuade the "ports" display to show these so that I know they're connected to the correct clock?

I've duplicated the reference design for now with the whole OPB/DCR bridge thing. It's good to know that you can hook up the DCR directly. I'll try that if/when I ever get the thing working.

Thanks :|

-- Peter

Reply to
Peter Mendham

Hi Peter,

The EDK ports view has a "filter" setting which usually hides all the nets which have default connections. If the ports are hidden then that probably means they've been connected up already. Signals identified as clocks in the IP's MPD file are given special treatment, and when they're also identified as belonging to a bus interface, the tools should automatically hook them up to the appropriate clock source.

The filter settings are accessible via some sort of mouse-click near the top of the ports view; can't remember exactly what the button looks like and I think it varies from EDK version to EDK version, but it's definitely there.

Cheers,

-Ben-

Reply to
Ben Jones

They were indeed hidden as a "default connection" but they weren't connected to anything! Thank you for your help, it seems to be working OK now.

Thanks,

-- Peter

Reply to
Peter Mendham

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.