[Open-graphics] Re: Some small changes

Mon Nov 8 21:00:25 EST 2010

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 <mark.marshall at csr.com>
>>> *To:* open-graphics at duskglow.com
>>> *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
>>> Open-graphics at duskglow.com <mailto:Open-graphics at duskglow.com>
>>> 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
>> Open-graphics at duskglow.com
>> http://lists.duskglow.com/mailman/listinfo/open-graphics
>> List service provided by Duskglow Consulting, LLC (www.duskglow.com)
>>
>
> _______________________________________________
> Open-graphics mailing list
> Open-graphics at duskglow.com
> http://lists.duskglow.com/mailman/listinfo/open-graphics
> List service provided by Duskglow Consulting, LLC (www.duskglow.com)
>