Be careful with stacking PLLs. Each one adds jitter, and jitter can lead to timing violations.
On Tue, Nov 9, 2010 at 7:53 AM, Mark Marshall <[email protected]> wrote: > Hi. > > Thanks for the pointers. I got this working and > it seems to have removed the corruption I was > seeing on the screen. > > The only slight problem is that the clock into the S3 > is now also at the wrong frequency, so all my code > needs ot have slightly different values for the dividers. > > I think what I'll try (when I get time) is adding another > PLL to the XP10 (there are 2 free) and converting the 156.25 > to 125.0. I can then use the 125 in the same way as everyone > else uses the raw input, and I can feed the 125 back out to > the S3. > > MM > > > >> -----Original Message----- >> From: Patrick McNamara [mailto:[email protected]] >> Sent: 09 November 2010 02:00 >> To: Mark Marshall >> Cc: [email protected] >> Subject: Re: [Open-graphics] Re: Some small changes >> >> >> There are two ways to update the PLL dividers. You can >> update the HDL, >> or you can edit the PLL settings after PAR. The former is >> obviously not >> required every time, but the latter will let you test >> different settings >> with having to re-route the entire device. As currently set, the >> bridge_clk PLL outputs 62.5MHz based on a 125MHz input. I >> know this is >> quite slow compared to the 80MHz target, but it is stable. >> Gotta make >> it work then we make it work fast. Using a 156.25MHz clock, set >> CLKI_DIV=5 and CLKFB_DIV=2. CLK_OP stays at 12. >> >> To play around with the settings, fire up ispLEVER and start the >> IPexpress tool. Under Architecture_Modules is PLL. Give it >> a temp file >> to save the generated code to and it will bring up a rather >> handy tool >> for figuring out what the valid dividers are. The current code takes >> its output from CLK_OP, not CLK_OK. You can get slightly >> more granular >> frequencies using CLK_OK, but not much. The XP10 PLLs are >> not nearly as >> flexible as the Xilinx ones. >> >> Patrick M >> >> On 11/08/2010 07:52 AM, Patrick McNamara wrote: >> > On 11/08/2010 05:41 AM, Mark Marshall wrote: >> >> On 05/11/2010 18:29, Patrick McNamara wrote: >> >>> I think I may have asked this before, but I'll ask it >> again, just in >> >>> case. One your board, to the lower left of the S3 are two >> >>> oscillators. One will be 133MHz, and the other is what? >> >> >> >> Hi. >> >> >> >> You're spot on. The top one (Y2) is 133M33000, the bottom one (Y3) >> >> is 156M25000. >> >> >> >> I'll have a look at the verilog and see if I can work out how to >> >> change the PLL so that by clocks are running at the same >> frequency as >> >> yours. I suspect that if I can find a matching xtal I can get a >> >> friend here to swap it (my soldering skills are a bit ropey, but I >> >> work with some masters). >> > >> > The change is in XP10_top_level. You will need to modify >> the divider >> > settings for bridge_pll. The easiest way I have found is >> to load up >> > the PLL tool in ispLEVER and plug in the numbers your want >> then have >> > it do the calculations. I'll send you better/more detailed >> > instructions later. I'm running out the door for work now. >> > >> >> >> >> One of the things that I was going to add locally was a counter >> >> connected to each clock, just to check this sort of thing. >> >> >> >> Thanks for the tip. >> >> >> >> MM >> >> >> >>> >> >>> I suspect your memory errors are, as you say, actually bridge >> >>> errors. I also suspect you have a faster clock for the >> input to the >> >>> bridge clock generator. This would mean that the XP10 >> image I build, >> >>> which was built for a 125MHz clock, would actually run >> the bridge at >> >>> a faster speed. If this is the case, there are likely >> some signals >> >>> that are violating setup timing do to the faster clock. >> >>> >> >>> Patrick M >> >>> >> >>> >> -------------------------------------------------------------------- >> >>> ---- >> >>> >> >>> *From:* Mark Marshall <[email protected]> >> >>> *To:* [email protected] >> >>> *Sent:* Fri, November 5, 2010 1:14:15 PM >> >>> *Subject:* [Open-graphics] Re: Some small changes >> >>> >> >>> On 03/11/2010 02:44, Patrick McNamara wrote: >> >>> > On 11/02/2010 07:13 AM, Mark Marshall wrote: >> >>> >> Hi. >> >>> >> >> >>> >> First some good news. I've managed to produce images for both >> >>> FPGA's. >> >>> >> For the XP10 I've used "ispLever Starter FPGA >> 8.1.00.34.21.10". >> >>> >> For the S3 I used version 12.[123].00 of the xilinx tools (I >> >>> >> forget >> >>> which >> >>> >> I chose, we seem to have every version from 9.1 to >> 12.3 installed >> >>> >> at work?). >> >>> > >> >>> > Very cool. What timing errors did you get on the XP10? Assuming >> >>> that you >> >>> > used the constraints from the repo, you likely got >> errors on the >> >>> > bridge_ad signals. >> >>> >> >>> I've not really used my S3 image - I've stuck with yours >> and tried >> >>> to not break compatability. I've made a number of XP10 >> ima ges and >> >>> they all seem to have broadly worked. I have to admit >> that I find it >> >>> very hard to >> >>> find the significant errors amongst the noise, and I also >> struggle to >> >>> understand what they mean. I can send a log if you are >> interested, but >> >>> they are quite boring! >> >>> >> >>> I do get some errors somewhere, but I don't know if this >> is because >> >>> I'm running on a pre-production part? At the moment I see quite >> >>> obvious errors when the HQ code reads the text buffer while doing >> >>> text-convert. I get spurious '$' and '(' characters all over the >> >>> screen (actually there are a set of places where such a character >> >>> might appear, and then I randomly get or don't get it at those >> >>> locations - I assume the locations are where the address is some >> >>> multiple of something?) >> >>> >> >>> The intersting thing is that the font data is read back >> from the S3 >> >>> perfectly (as far as I can tell) as the characters themselves are >> >>> always perfect. Maybe it is only the last word of a read that is >> >>> corrupted? It could also be a bug in the HQ code. >> >>> >> >>> memtest fails with a minimum of 7000 erros or so, and I can see a >> >>> definate pattern to them. I think all of the errors are >> in the S3 -> >> >>> XP10 stage, and are not really memory errors. I'm not sure how to >> >>> test that. >> >>> >> >>> MM >> >>> >> >>> _______________________________________________ >> >>> Open-graphics mailing list >> >>> [email protected] <mailto:[email protected]> >> >>> http://lists.duskglow.com/mailman/listinfo/open-graphics >> >>> List service provided by Duskglow Consulting, LLC > (www.duskglow.com >>>> <http://www.duskglow.com>) >>>> >>> >>> >>> _______________________________________________ >>> Open-graphics mailing list >>> [email protected] >>> http://lists.duskglow.com/mailman/listinfo/open-graphics >>> List service provided by Duskglow Consulting, LLC (www.duskglow.com) >>> >> >> _______________________________________________ >> Open-graphics mailing list >> [email protected] >> http://lists.duskglow.com/mailman/listinfo/open-graphics >> List service provided by Duskglow Consulting, LLC (www.duskglow.com) >> > > > > To report this email as spam click > https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== > kyvBrIOUlCmbqR1Bxe5g5Vkjc3yNY2GdwGBchKRB0KEKw== . > > > Member of the CSR plc group of companies. CSR plc registered in England and > Wales, registered number 4187346, registered office Churchill House, > Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
