I spoke with Tim this even and agreed to help get the Xilinx FPGA setup up. I am going to work on getting an ISE project setup an configured so that it will produce an image for the FPGA. I'll document the steps that we go through on the wiki so that someone else can reproduce it if the want.

I'm not sure that I'm willing to take on the formal role of maintainer yet, but I'll certainly help get us to the point where we have working images for the boards.

Patrick M


Timothy Normand Miller wrote:
I've spoken with Howard about this.  In the short term (whilst he's
very much occupied chasing multiple deadlines at work), he's willing
to take firmware (FPGA and BIOS) images and try them out where he
boots the system with a PCI analyzer.  We can then examine the PCI
traces that he sends us and use them for debugging.  Somewhere along
the line, I wrote a Ruby script that converts analyzer traces into
Verilog code that we can drop into a simulation.

At least within the US and maybe Canada, we can get free Lattice
tools.  So it shouldn't be too hard to get a volunteer for that.  What
we need is an official maintainer.  Howard and I can help them get
their build environment (constraint files, synthesis options, etc.)
configured right.

Next, there's the issue of the Xilinx FPGA.  To do a proper job, we
need the full commercial version.  Through rep contacts, I've been
able to get it really cheap in the past.  And once again, we really
need someone to take over maintenance of this.

On Thu, Nov 5, 2009 at 9:46 AM, Timothy Normand Miller
<[email protected]> wrote:
It's good that you bring this up.  OGD1 is currently IN production,
and we're going to need a working set of FPGA images to load onto it!
Unfortunately, what Howard has working and what's in the repo differ.
The hardware is mostly the same, but the BIOS and HQ microcode are
different, and the ones in the repo don't work.  We need some
community help getting it working.  Howard is barely able to find time
to work on getting stuff together for making the boards.  And I have
two conference paper deadlines coming up fast.  So we could really use
some community help on this!

On Thu, Nov 5, 2009 at 5:57 AM, Mark Marshall
<[email protected]> wrote:
Hi.

I've recently been working on OGD1 again, and I would like to ask for some
help.

For a number of reasons I would like to be able to remake the XP10 FPGA
image.  I'm adding a couple of very small features and tidying up some
others.  I recently found out that the free version of ispLever now supports
the XP10 FPGA (I'm sure it didn't last time I looked a year ago).
I need to get my build environment properly set up.  But also, it
would be useful if some others tried to replicate that so that we can
work out little corner issues.  I hate it when someone checks
something into a repo because it "works for them", but it doesn't work
for me.  Anyone else want to volunteer to download ISP Lever and try
to build OGD1's XP10 component?

Anyone else have access to the commercial version of Xilinx ISE?

So the first question is has anyone built this image successfully with the
free tools?  Do I need anything that isn't checked in?  How much work should
it be?


The second question is can someone please explain to me the clocks related
to the XP10.  As I understand it there are two clock inputs to the XP10, the
PCI (pci_clock) and the 156 MHz (ref_ck).  The PCI clock is easy, and I'm
happy with it - it's used to clock the PCI block in the PCI clock domain.
I believe it is 156MHz.

Does the second clock run at 156 MHz on the input to the FPGA - things seem
to imply this, but It's hard to find it written down anywhere?  The PLL
settings seem to be a bit muddeled (bridge_pll).  From my reading of the
data sheet and the parameters this PLL divides this clock by 2, so
bridge_clock_tx_i is running at 78 MHz.  I thought this clock was faster?
 Also from my understanding of the data sheet the VCO is only running at 312
MHz.  This is below the spec limit - is this a problem? Is there a chance
that this PLL will fail to lock? (CLKOP should be 8 to make the VCO run at
624 MHz).  Is there something here that I don't know?
I think Howard underclocked it because once all the logic was put
together, routing pressure prevented it from meeting timing.
Eventually, we might try to fix whatever is making the critical path
too long, but the short-term objective was simply to make it work.

I'm also a bit confused by the parameters to this PLL.  There are three sets
of numbers possibly controlling it, and I don't know which ones to trust.
 Which ones are the "good" values.  The three sets are:
 defparam bridge_pll.XXX_DIV = "x"
 /* synthesis XXX_DIV="2" */
 /* synthesis FREQUENCY_PIN_XXX="200.0" */

It seems that these are different ways of setting the PLL, and we should
only be using one - which one.
Good question.  Howard might be able to answer this.

The other thing I've been looking at is a way to program the XP10 from
Linux.  I've got UrJTag to work.  There was a post a long time ago from
Petter Urkedal where he said that he was struggling with this tool, but it
had enough info in it to help me along.  He said that the ID code command
was producing the wrong number, well it turns out that that was the correct
number, just big endian octets in little endian order.  I mamanged to get
the same result using a Lattice parallel cable.

Knowing that it was now talking to the device I had a fiddle with the detect
routin, and I neede to add another tap_reset and tap_capture_dr sequence
into the middle of it.  This then meant that UrJTag seems to work with the
XP10 ion the OGD1.  I have no idea why these extra lines are needed (or what
they do).  I've attached the diffs.

Did anyone else manage to program the XP10 from Linux using free tools?


I think that I have managed to program the XP10 now with an image built by
me, but I'm not 100% sure.  I will build a new image tonight that I can
clearly identify, and try again tomorrow.  (For boring reasons I'm building
images at work and testing them at home).
Mark, we need to get you some help on this.  We just need a few people
who are willing to install synthesis tools and set up debug
environments.


--
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)

Reply via email to