On 18/05/10 18:50, Johnathan Mantey wrote:
Sebastien and MM LM32 developers,
If you're finding specific tool/HDL/documentation errors I would
appreciate you sending any findings to [email protected] so
that we can make the environment better for everyone involved. We
can't fix what we don't know is broken.
I was under the impression that Lattice wasn't going to be fixing HDL
issues that occurred on other manufacturers' devices or synth tools?
As for the documentation issues, here's a list of all the gotchas I've
found in the LM32 Processor Reference Manual, July 2009 revision,
including the two Sebastien mentioned earlier:
Page 9, Table 4. EID is described as the LM32 Revision Number. Later
text describes this as the "Exception ID", which seems to fit better --
the LM32 Revision *is* accessible as part of the CFG CSR.
Page 12, Figure 8 and Table 7 (reported by Sebastien). CFG CSR. "X" and
"U" bits swapped -- bit 3 = 1 means Sign Extension is enabled, bit 4 = 1
indicates User Instructions are enabled.
Page 12, Table 7 (reported by Sebastien). CFG CSR. "U" bit is described
as "Reserved". This seems to fit in with the general "theme" of User
Instructions -- there's very little documentation to explain how to add
a UI to the lm32 core.
Page 13, Table 7. CFG CSR. "G" bit '1 = data cache is implemented'. This
is incorrect -- the G big actually indicates whether debug is implemented.
Page 35. Table 16. Verilog Configuration Options. Configuration options
have had the CFG_ prefix dropped with no note of this. Either prefix the
config options with CFG_, or make a note to this effect in the text.
Page 35. Table 16. Verilog Configuration Options. DIVIDE_ENABLED is
actually called MC_DIVIDE_ENABLED.
Page 37. Table 16. ICACHE_Associativity and DCACHE_Associativity do not
explain what is meant by "associativity" -- in this case, 1=Direct
Mapped, 2=two-way set-associative.
Page 50, Opcode Lookup Table. RAISE instruction (opcode 101011) is
listed in the Instruction Descriptions as "SCALL". There is no
indication which of these names is correct.
LSCC will, necessarily, evaluate all incoming requests, and
prioritize fixing issues reported. Obvious errors in the
documentation, or critical functional issues with the HDL and C/C++
development tools will get priority treatment.
The cache issue on the Xilinx XST synthesizer seems to be an issue with
XST. Basically, if you preset a parameter using a function call, the
value will not be set correctly. F.ex:
localparam buswid = clogb2(`CFG_DCACHE_LIMIT)
This is the soc-lm32 commit that claims to fix the above-mentioned
issues -- I haven't had a chance to try it:
<http://github.com/jbornschein/soc-lm32/commit/666a0f8b74e02a320a9f8f83b7170e34488a14fa>
And there's an interesting thread on it at:
http://www.edaboard.co.uk/edk-fsl-macros-defined-by-xilinx-are-wrong-t161406,start,3825.html
http://www.edaboard.co.uk/edk-fsl-macros-defined-by-xilinx-are-wrong-t161406,start,3840.html
The post by John McGrath at the end of the 1st page explains (in brief
terms) what's going wrong. I haven't seen any issues with anonymous
generate blocks, but the explanation for the cache issues seems plausible.
At this time I request that wholesale feature additions/submissions
be held back as LSCC is still evaluating our procedures for accepting
community submissions.
It would be nice to get that sorted out sooner rather than later --
ideally before we end up swimming in a sea of branched and forked
implementations of LM32, all with their own subtle differences and
incompatibilities...
The one thing that is annoying about LM32 as it is at the moment, is
that the forums seem to be essentially barren. There are plenty of
questions, but very few answers...
--
Phil.
[email protected]
http://www.philpem.me.uk/
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkym...@freenode
Webchat: www.milkymist.org/irc.html
Wiki: www.milkymist.org/wiki
