Non-contiguous port vector ranges???

[Mark McDougall]

Hi all,

I'm currently doing the top-level entity for an fpga and the idea is for
the port names to match the schematic names.

However, the schematic has non-contiguous indexes for a bunch of
signals. For example...

CTS has [1:5],[7] & [9:10]

I know you can't do...

entity blah is
port
(
cts : in std_logic_vector(10 downto 9);
cts : in std_logic_vector(7 downto 7);
cts : in std_logic_vector(5 downto 1);
...
};

but is there any way of using a range such as
cts : in std_logic_vector(10 downto 9, 7, 5 downto 1);
or something similar???

My only other thought is to use
cts10 : in std_logic;
cts9 : in std_logic;
cts7 : in std_logic; ... etc

Regards,

 

[Jonathan Bromley]

but is there any way of using a range such as
cts : in std_logic_vector(10 downto 9, 7, 5 downto 1);
or something similar???

No, but it may make sense to create a port with
the contiguous range:

cts: in std_logic_vector(10 downto 1);

and then wire up only those bits that you want - it's a bit
clunky because you need to tie-off the undriven inputs:

thingummy: widget port map (
cts(10 downto 9) => vec2,
cts(7) => sig,
cts(5 downto 1) => vec5,
cts(8) => '0',
cts(6) => '0' );

Synthesis will strip away the unused signals.

My only other thought is to use
cts10 : in std_logic;
cts9 : in std_logic;
cts7 : in std_logic; ... etc

Un-think that thought

If your signal's vector range is discontiguous, is that because
in reality it's a bunch of separate signals? If so, maybe

cts10_9: std_logic_vector(10 downto 9);
cts7 : std_logic_vector(7 downto 7);
cts5_1 : std_logic_vector(5 downto 1);

may be nearer to the design intent.

Finally, you could consider (and I only say "consider", it may be much
more trouble than it's worth) designing a new vector type, indexed
by an enumeration:

package sparse_slv_pkg is
type sparse_index is (i1, i2, i3, i4, i5, i7, i9, i10);
type sparse_slv is array(sparse_index range <>) of std_logic;
-- Also provide type conversions to/from std_logic_vector
function to_sparse(v: std_logic_vector) return sparse_slv;
function to_slv(s: sparse_slv) return std_logic_vector;
end;
......
use work.sparse_slv_pkg.all;
entity sparse_widget is
port ( cts: in sparse_slv(i10 downto i1) );
end;
......
sparse_thingummy: sparse_widget port map (
cts(i10 downto i9) => to_sparse(vec2),
cts(i7) => sig,
cts(i5 downto i1) => to_sparse(vec5) );

Like I said, probably more trouble than it's worth...
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jim Lewis]

Jonathan

No, but it may make sense to create a port with
the contiguous range:

cts: in std_logic_vector(10 downto 1);

and then wire up only those bits that you want - it's a bit
clunky because you need to tie-off the undriven inputs:

thingummy: widget port map (
cts(10 downto 9) => vec2,
cts(7) => sig,
cts(5 downto 1) => vec5,
cts(8) => '0',
cts(6) => '0' );

Synthesis will strip away the unused signals.

Anyone try this on Synopsys recently? Ages ago they
used to be bad at stripping away elements of an array.
The result was that arrays with unconnected elements
would get passed to the ASIC backend tools and they did
not seem to like it. Ironically all of the less expensive
FPGA based tools seem to be fairly accomplished at this.

Cheers,
Jim


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~