On 16/10/2011, at 5:11 AM, Christophe CURIS wrote:
> Hello,
>
> This usually means that your are using a rare VHDL construct that is probably
> legal, but not yet supported by GHDL.
>
> However, looking at the current case, I would say it comes from the use of a
> "begin" keyword after the "generate" which is not legal because you have no
> declarative statement before.
That would indicate the error occurred in the generate statement that is found
at line 183 (which has a following begin statement but no intervening
declaration) and not the one at line 208. In other words the parser got
derailed in the first generate statement. It would sort of sound like it got
confused encountering the second generate statement.
9.7 Generate statements (VHDL-93)
A generate statement provides a mechanism for iterative or conditional
elaboration of a portion of a description.
generate_statement ::=
generate_label :
generation_scheme generate
[ { block_declarative_item }
begin ]
{ concurrent_statement }
end generate [ generate_label ] ;
generation_scheme ::=
for generate_parameter_specification
| if condition
label ::= identifier
If a label appears at the end of a generate statement, it must repeat the
generate label.
For a generate statement with a for generation scheme, the generate parameter
specification is the declaration of the generate parameter with the given
identifier. The generate parameter is a constant object whose type is the base
type of the discrete range of the generate parameter specification.
The discrete range in a generation scheme of the first form must be a static
discrete range; similarly, the condition in a generation scheme of the second
form must be a static expression.
The elaboration of a generate statement is described in 12.4.2 .
----
Clause 9.7 would be normative.
The BNF shows ( 0.2.1 Syntactic description ):
e. Square brackets enclose optional items on the right-hand side of a
production; thus the two following productions are equivalent:
return_statement ::= return [ expression ] ;
return_statement ::= return ; | return expression ;
f. Braces enclose a repeated item or items on the right-hand side of a
production. The items may appear zero or more times; the repetitions occur from
left to right as with an equivalent left-recursive rule. Thus, the following
two productions are equivalent:
term ::= factor { multiplying_operator factor }
term ::= factor | term multiplying_operator factor
---
that the block_declarative_item and begin key word are optional (and that if
there is a declarative item that the key word is required). The braces say
zero or more times, meaning the key word begin isn't only associated with a
block declarative item here. Clause 0.2.1 is also normative.
I'd tend to think that you would have run instead into the end generate at line
206 and barfed there if the previous generate statement was parsed incorrectly.
Note the subsequent warning at line 239 is present. In general parsing VHDL is
implemented as a single pass and line 239 is subsequent to line 208.
Commenting out the begin key word on line 184 generates the same error location
but a different stack traceback.
In other words your supposition appears invalid that the problem was cause by a
begin without a preceding declarative item. (And we are looking for an
implementation error in ghdl).
The two generate statements at lines 183 and 208 (labels G_LVT_DMEM and
G_2W3R_DMEM) form the equivalent of an if-else using the true-false state of
LVT_DMEM to either instantiate a component (DMEM) or a purportedly equivalent
block processes (P_DMEM_D and P_DMEM_WRITE_BACK).
LVT_DMEM is true ( a generic) which should yield a component instantiation.
Let's look closer at the expression in an if iteration scheme in a generate
statement. We know from the last quoted paragraph of Clause 9.7 above that the
condition in the if generate scheme must be a static expression, and from
context it's globally static (it's a generic, it can be configured).
I'd hold from the warning statements (shown below from the original post) that
the problem occurred at line 239 (which has a warning) or following and if I
had to hazard a guess would think the shared variable declaration at line 240:
shared variable aDMEM : tDMEM := (0 to 2**log2DADDR-1 => (DW-1
downto 0 => '0'));
If you note aDMEM is accessed by generated processes P_DMEM_D and
P_DMEM_WRITE_BACK and
4.3.1.3 Variable declarations
A variable declaration declares a variable of the specified type. Such a
variable is an explicitly declared variable.
variable_declaration ::=
[ shared ] variable identifier_list : subtype_indication [ :=
expression ] ;
A variable declaration that includes the reserved word shared is a shared
variable declaration. A shared variable declaration declares a shared variable.
Shared variables are a subclass of the variable class of objects. More than one
process may access a given shared variable; however,if more than one process
accesses a given shared variable during the same simulation cycle (see 12.6.4
), neither the value of the shared variable after the access nor the value read
from the shared variable is defined by the language. A description is erroneous
if it depends on whether or how an implementation sequentializes access to
shared variables.
---
and the two processes have different clocks in their sensitivity list to avoid
the mutex issue fixed in VHDL 2002 with protected types. If you were to
operate the model with iDCLK and iCLK occurring in the same simulation cycle
the results would be undefined.
The error message
>> parse_declarative_part(2): cannot handle IIR_KIND_GENERATE_STATEMENT
>> (vhdl/OISC_SUBLEQ.vhd:208:16)
sounds like ghdl doesn't want a shared variable in a generate statement, or
doesn't want the shared variable to be accessed in two different processes.
It could be the shared variable declaration from the "parse_declarative_part(2)
where 2 may indicate the second declaration. (Understanding the ghdl parser do
not I currently). That statement is likely derived from parse.adb and would
need to be traced.
Because it's not used, I'd suggest commenting out the second generate statement
(and you can't tell that it isn't used normally until elaboration time, that
there is no further declaration of LVT_DMEM through configuration). ( created
an RCS subdirectory in vhdl and ci -l *.vhd). This actually worked but doesn't
tell us what's wrong with the generate statement starting at 208. One could
also try to change the contents of the two processes and see what happens.
(It then runs):
make
== analyze vhdl/OISC_SUBLEQ
for f in vhdl/OISC_SUBLEQ.vhd vhdl/DMEM.analyzed ; do case $f in *.vhd) ghdl -a
--work=work --workdir=./work --std=93c --no-vital-checks --warn-binding
--warn-reserved --warn-library --warn-no-vital-generic --warn-no-delayed-checks
--warn-no-body --warn-specs --warn-unused $f ;; esac ; done ;
vhdl/OISC_SUBLEQ.vhd:157:39:warning: universal integer bound must be numeric
literal or attribute
touch vhdl/OISC_SUBLEQ.analyzed
== analyze bench/BENCH_OISC_SUBLEQ
for f in bench/BENCH_OISC_SUBLEQ.vhd vhdl/OISC_SUBLEQ.analyzed ; do case $f in
*.vhd) ghdl -a --work=work --workdir=./work --std=93c --no-vital-checks
--warn-binding --warn-reserved --warn-library --warn-no-vital-generic
--warn-no-delayed-checks --warn-no-body --warn-specs --warn-unused $f ;; esac ;
done ;
touch bench/BENCH_OISC_SUBLEQ.analyzed
== elaborate bench/BENCH_OISC_SUBLEQ
ghdl -e --work=work --workdir=./work --std=93c --no-vital-checks --warn-binding
--warn-reserved --warn-library --warn-no-vital-generic --warn-no-delayed-checks
--warn-no-body --warn-specs --warn-unused -o bench/BENCH_OISC_SUBLEQ
BENCH_OISC_SUBLEQ
touch bench/BENCH_OISC_SUBLEQ.elaborated
== run bench/BENCH_OISC_SUBLEQ
if [[ -x bench/BENCH_OISC_SUBLEQ ]] ; \
then \
bench/BENCH_OISC_SUBLEQ \
--disp-time --disp-tree=inst --stop-time=200ns
--wave=bench/BENCH_OISC_SUBLEQ.ghw ; \
else \
ghdl -r --work=work --workdir=./work --std=93c
--no-vital-checks --warn-binding --warn-reserved --warn-library
--warn-no-vital-generic --warn-no-delayed-checks --warn-no-body --warn-specs
--warn-unused BENCH_OISC_SUBLEQ \
--disp-time --disp-tree=inst --stop-time=200ns
--wave=bench/BENCH_OISC_SUBLEQ.ghw ; \
fi ;
bench_oisc_subleq [entity]
`-bench [arch]
+-b_stim [block]
`-u_oisc_subleq [instance]
`-oisc_subleq [entity]
`-tp [arch]
+-b_blob [block]
| `-g_lvt_dmem [if-generate true]
| `-u_dmem [instance]
| `-dmem [entity]
| `-rtl [arch]
| +-u_dmem_prim_d [instance]
| | `-dmem_prim [entity]
| | `-rtl [arch]
| `-u_dmem_prim_b [instance]
| `-dmem_prim [entity]
| `-rtl [arch]
+-g_async [if-generate false]
`-g_sync [if-generate true]
std.standard [package]
ieee.std_logic_1164 [package]
ieee.numeric_std [package]
work.dmem_prim_pkg [package]
work.dmem_pkg [package]
work.oisc_subleq_pkg [package]
../../../../libraries/ieee/numeric_std-body.v93:2098:7:@0ms:(assertion
warning): NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
../../../../libraries/ieee/numeric_std-body.v93:2098:7:@0ms:(assertion
warning): NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
../../../../libraries/ieee/numeric_std-body.v93:2098:7:@0ms:(assertion
warning): NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
Now is 0ms +0
Now is 0ms +1
Now is 2ns +0
Now is 2ns +1
Now is 2ns +2
Now is 2ns +3
Now is 2ns +4
Now is 2ns +5
Now is 2500ps +0
Now is 2500ps +1
Now is 2500ps +2
Now is 3333333fs +0
Now is 3333333fs +1
...
Now is 198ns +0
Now is 198ns +1
Now is 199999980fs +0
Now is 199999980fs +1
Now is 200ns +0
Now is 200ns +1
ghdl:info: simulation stopped by --stop-time
touch bench/BENCH_OISC_SUBLEQ.ran
---
This is an example of using generate statements to deal with tool differences,
something you could also do with a preprocessor. You could argue it would be
better with a preprocessor because the un-used code doesn't have to parse wtih
a tool that doesn't use it, in this case because LVT_DMEM is globally static -
has meaning at elaboration time rather than being known at analysis time.
Conditional compilation (a preprocessor) operates at analysis time and is a
lexical process (requires no understanding of the semantics or configuration).
You can try to make code work conditionally for particular tools using generate
statements and fail because the non-unused code must parse. Regardless as to
whether ghdl uses the second generate statement or not it is required to
analyze it when using the if-else successive generate statements. Conditional
compilation (conditional text) would remove that requirement. Note that no
vendors offer conditional compilation today and that the use of generate
statements doesn't offer a solution for parse incompatibilities across versions
of VHDL.
There isn't a gtkwave sav file present, and I didn't try to construct one from
the modelsim do file. And ya, I apologize for being verbose. I didn't look at
the above assertion warnings, either.
In the mean time Mr. Masaru please file a bug on gna
(https://gna.org/support/?group=ghdl&func=additem) (and yes the certificate is
wonky, it's okay). It'd be worth archiving the oisc test case for inclusion,
too. It may not be available on bitbucket by the time someone takes it
seriously.
I take it this a Xilinx dual port memory?
> Christophe.
>
> On Saturday 15 October 2011 07:18, KIMURA Masaru wrote:
>> Hi,
>>
>> anyone can tell me what it is?
>>
...
>> == analyze vhdl/OISC_SUBLEQ
>> for f in vhdl/OISC_SUBLEQ.vhd vhdl/DMEM.analyzed ; do case $f in
>> *.vhd) ghdl -a --work=work --workdir=./work --std=93c
>> --no-vital-checks --warn-binding --warn-reserved --warn-library
>> --warn-no-vital-generic --warn-no-delayed-checks --warn-no-body
>> --warn-specs --warn-unused $f ;; esac ; done ;
>> vhdl/OISC_SUBLEQ.vhd:157:39:warning: universal integer bound must be
>> numeric literal or attribute
>> vhdl/OISC_SUBLEQ.vhd:239:47:warning: universal integer bound must be
>> numeric literal or attribute
>> parse_declarative_part(2): cannot handle IIR_KIND_GENERATE_STATEMENT
>> (vhdl/OISC_SUBLEQ.vhd:208:16)
>>
>> ******************** GHDL Bug occured ****************************
>> Please report this bug on http://gna.org/projects/ghdl
>> GHDL release: GHDL 0.29 (20100109) [Sokcho edition]
>> Compiled with GNAT Version: GPL 2009 (20090519)
>> In directory: CURRENT_DIRECTORY
>> Command line:
>> C:\GHDL\bin\ghdl.exe -a --work=work --workdir=./work --std=93c
>> --no-vital-checks --warn-binding --warn-reserved --warn-library
>> --warn-no-vital-generic --warn-no-delayed-checks --warn-no-body
>> --warn-specs --warn-unused vhdl/OISC_SUBLEQ.vhd
>> Exception TYPES.INTERNAL_ERROR raised
>> Exception information:
>> Exception name: TYPES.INTERNAL_ERROR
>> Message: errorout.adb:71
>> ******************************************************************
>>
...
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
