On 18/10/2011, at 4:03 PM, KIMURA Masaru wrote:
>
> you already filed a bug w/ my source code at https://gna.org/bugs/?18810
> of course, you can use my code for what ever you want to.
Thanks. I only thought of permission after I retired for the night, sorry. I
put it in after demonstrating Christophe's example wasn't extensive enough to
demonstrate the problem.
Where in ghdl is the Bug?
In OISC_SUBLEQ.vhd I took the commented out generate statement starting at line
208 and uncommented the line 208 and 269 giving:
G_2W3R_DMEM : if (LVT_DMEM = false) generate
-- lots of comments in between
end generate G_2W3R_DMEM;
which analyzed and ran. I uncommented the first type declaration on line 239:
type tDMEM is array (0 to 2**log2DADDR-1) of std_logic_vector(DW-1
downto 0);
that demonstrated the need for the begin statement when a
block_declarative_part (a block_declarative_item in VHDL-93 9.7 Generate
statements: --std=93c "which means VHDL-93 accepting VHDL-87 syntax") is
present so I uncommented line 241:
begin
the code then analyzed and ran (the code enfolded by LVT_DMEM = false not being
used anyway, this is a syntax issue).
I uncommented line 240:
shared variable aDMEM : tDMEM := (0 to 2**log2DADDR-1 => (DW-1 downto 0
=> '0'));
and got our old friend :
parse_declarative_part(2): cannot handle IIR_KIND_GENERATE_STATEMENT
(vhdl/OISC_SUBLEQ.vhd:208:16)
******************** GHDL Bug occured ****************************
...
It's the share variable declaration that's causing a problem,
parse_declarative_part(2), the 2 does sound like it means second declarative
part.
if you search for the first occurrence of Iir_Kind_Generate_Statement in
parse.adb you'll actually find the place we're dealing with with the If
generation scheme in the function Parse_Generate_Statement. Right above the
function declaration you'll find the comments:
-- [ ยง9.7 ]
-- generation_scheme ::=
-- FOR GENERATE_parameter_specification
-- | IF condition
--
-- FIXME: block_declarative item.
Where section 9.7 is valid for IEEE Std 1076-2000 and previous, but most
noteworthy is the legend FIXME. If you search for FIXME you'll find it
liberally sprinkled through parse.adb. We have a general unawareness as ghdl
users of where the shortcoming in VHDL compliance are, we aren't using the
right tool environment to notice. The "FIXME: block_declarative item" will
point us to the present bug. Also notice FIXME gets character background
highlighted in gedit, part of the message about tool environments.
Someone fixing all this stuff is either going to require some good
implementation verification (test suites, which happen to all be proprietary)
or a hard audit against the VHDL standard.
I found I had difficulty searching through the Ada source, wrongly relying on
OS X's Spotlight when a recent Xcode update had deprecated indexing Ada source
in it's mdimporter. We are seeing both a need for IDE tools as demonstrated
by the parser being 6000 lines long due to the package nature of Ada and it's
verbosity. Being written in Ada means we need a good tool environment to deal
with ghdl, or understand the limits of the tools we do have.
There's also the idea-expression distance in describing VHDL either in
specifications or implementations. The VHDL standard appears to inherit it's
structure from demonstrating distinguishing features from Ada (VHDL 7.2
Language Reference Manual from Intermetrics, 1986, Translation of VHDL to Ada,
Carl F. Schaefer, also of Intermetrics ). The first VHDL implementations were
preprocessors reminiscent of WATFIV or WATFOR adding case statements and
For/While loops to Fortran. The structure of the standard doesn't lend itself
to resolving semantic restrictions to language syntax nor are there any
aftermarket publications aimed at VHDL tool implementers. Mind you there was
a Sense of the VASG which dealt with interpreting language definition
ambiguities at one time.
Compare the standard's organizations to say Ada, Verilog, the distinction
between describing distinguishing features and tool flow. You could
contemplate that the restrictions on mentioning implementation dependencies
preserve the ability to create a VHDL preprocessor for Ada today except the
syntax hasn't kept pace with Ada's. The story being VHDL is relatively hard
whether or not it is written in Ada, considering an analyzer and simulator are
only about as complex as a medium sized FPGA these days.
This particular bug could be better classed as an un-implemented feature, and
there are plenty of FIXME's sprinkled around if we could but see the forest
for the trees.
Now if there were only a market for a book aimed at VHDL tool implementers...
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
