Hi, Le Fri, 24 Sep 2010 18:36:01 -0700, Kent Dahlgren <[email protected]> a écrit : > I'm willing to help by tracing through the code, but I do not have > time to get up to speed with your > architecture and design flow. So if you can port the design to the > Lattice board, I will help you bring it up.
Ok :) To explain a bit more: it won't be my Milkymist design, it will be the original LatticeMicoSystem with my USB core added. I want to see if the root cause of the problem is in the LM32 core or in the code that I added. > BTW We have our RapidIO IP ported to the Xilinx Spartan 6 platform as > well, and the clocking is > really screwed up. The Xilinx FAEs don't even want to deal with it. Yes, I had a lot of clocking issues with porting Milkymist too. The tools _always_ get the clock buffers wrong (nature + placement) and I got away with: * manually instantiating every clock buffer I needed (read carefully the Spartan6 clocking user guide, the S6 clocking infrastructure is full of gotchas and irregularities) * placing every clock buffer manually with a LOC constraint in the UCF file (FPGA Editor may help) * never using AUTOBUF (it creates more problems than it solves) > Also there are a bunch of issues with ISE 12.1 and 12.2 on Spartan 6. > I recommend getting ISE 12.3 > We got early access since XST in 12.1 and 12.2 had some major issues. It's most probably not a synthesis tool issue as I reproduced the problem by porting the Milkymist design to a Virtex-4 ML401 board and using Synplify synthesis. > >> I could also hook up the board to a Linux box and give you ssh > >> access so you can do remote debug. > >> > > Right now I cannot reproduce this bloody intermittent problem > > without running the GUI and clicking buttons, so you'd need to > > connect an IP KVM to it that can simulate an USB mouse. This is > > getting quite complicated :( > > > We do it all the time, but before we go there. > > 1) What is the problem that you are seeing? When using the Genode FX GUI on the board, random and strange things happen: the wrong buttons get clicked, when moving windows you can't release them, and in most cases the application totally freezes after about one minute of use. It is not a software bug, the same binary is stable in QEMU. I also ran several memory tests (it also sounded like a DRAM problem), all passed - though I still need to try the "high bandwidth with random addresses" test (see list archives...) > 2) Can you reproduce it in simulation? Or is it a hardware only > thing? It's extremely hard to reproduce (but still makes the software unusable) and so far I couldn't even get an automatic software routine that consistently triggers it. That's why I need the KVM, USB mouse and all that mess. Speaking about mess, you would need to add a USB Host connector to a 3.3V I/O expansion port of the Lattice board, with 68 ohm resistors in series with D+ and D- in order to connect the mouse. > I would suggest that before we start debugging things in hardware, we > first get the design to lint cleanly. > I know from experience that the Lattice Mico related IP is full of > weavels ;-) I don't have a lint license, but you're not the first one to talk about LM32-related lint problems. I'm only using the LM32 core and no other Lattice peripherals. What exactly are the lint issues you found? Thanks, S. _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkym...@freenode Twitter: www.twitter.com/milkymistvj
