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.
