Description

General Description: How does EDIF2NGD handle embedded ranged

strings in array names?

Solution

EDIF2NGD 1.4 doesn't handle embedded ranged strings in array names

appropriately. The signal is recognized as 1-bit wide instead

of a vector.

When EDIF2NGD 1.5 expands an array construct, it *always* uses

parenthesis. The delimiters used in the range part of the

array name have no effect on the actual expansion.

EDIF2NGD 1.5 will attempt to match the array name to the following

array_name pattern:

array_name := base_name range_suffix

base_name := one or more valid characters for EDIF name

range_suffix := '[' boundA ':' boundB ']' |

'<' boundA ':' boundB '>' |

'(' boundA ':' boundB ')'

boundA := integer

boundB := integer

Consider these 3 EDIF snippets:

Ex 1:

(port (array (rename q_out "Q_OUT[9:0]") 10) (direction OUTPUT))

Ex 2:

(port (array (rename q_out "Q_OUT<9:0>") 10) (direction OUTPUT))

Ex 3:

(port (array (rename q_out "Q_OUT(9:0)") 10) (direction OUTPUT))

EDIF2NGD will handle array constructs with embedded ranges. Once the

bus index has been determined, the scalar port or net name will be

constructed as follows:

base_name '(' index ')'

This bus-expansion syntax is one of the standard ones recognized by

NGDBUILD for Xilinx primitives that are defined to have bussed ports.

(Currently, only the Virtex block RAM primitives are so defined.) It is

also recognized by the Xilinx HDL writers when reconstructing bussed

ports on user entities.

After bus-expansion, all 3 of our examples will have the pattern,

base_name '(' index ')'

The original bus-notation will not be retained.

Note that in M2.1, many of these issues should go away, because

NGDBUILD will know how to juggle the delimiters to make pins

match.