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