generic outputs ?

[Pontus Stenstrom]

Subcomponents have the GENERIC "input" port to enable parametrisation
of
the component itself, however this might also require some changes of
the instantiating part.
It would be nice to have a GENERIC "ouput" so that the instatiating
component could take care of some of the requirements induced by the
current parametrisation. Is there a method for this?

Example:
At reset you want to restart from a given state, and to get into this
state might take some time, FFs with async reset immidiatly go to
there
reset state, but what about deep chains of FFs without async reset, or
shift registers, or block RAMs etc. It may take a number of clocks
to clear all.
So a shift register with depth of 10 would need 10 cycles, etc.
The block generating reset would need to know the requirements off all
subcomponents and then select the largest value.
Then it can release reset, and all components will be fully reset.

Handshake is one solution, but that is not solving the problem at
compile-time (synt).

/Pontus

 

[Nicolas Matringe]

Pontus Stenstrom a écrit :

Subcomponents have the GENERIC "input" port to enable parametrisation
of
the component itself, however this might also require some changes of
the instantiating part.
It would be nice to have a GENERIC "ouput" so that the instatiating
component could take care of some of the requirements induced by the
current parametrisation. Is there a method for this?

Hello
Parameters all go "downwards". Instead of trying to make a
generic-dependent parameter go upwards, why don't you compute it
everywhere you need it, based on the top level parameter?

 

[Paul Uiterlinden]

Subcomponents have the GENERIC "input" port to enable
parametrisation of
the component itself, however this might also require some changes
of the instantiating part.
It would be nice to have a GENERIC "ouput" so that the instatiating
component could take care of some of the requirements induced by the
current parametrisation. Is there a method for this?

What's wrong with using an ordinary output? Just assign a constant
value to this output. The value would be derived from one or more
generics. Because it is a constant, the issue is solved during
synthesis.

Paul.

 

[Pontus Stenstrom]

What's wrong with using an ordinary output? Just assign a constant
value to this output. The value would be derived from one or more
generics. Because it is a constant, the issue is solved during
synthesis.

Paul.

So, for the case of determening the lenght of the reset pulse, I could
e.g. use an integer signal with a resoltion function determining the maximum
value of all drivers, throughout the hierachy of the design, to set the lenght
of the reset pulse in the "reset" component of the design?
This signal would only have dependencies on constants or generics, and so
be static (is that the word?), and therefore be usable in a counter
expression in the reset block.
I will have to try this ...

Thanks /Pontus

 

[Paul Uiterlinden]

So, for the case of determening the lenght of the reset pulse, I
could e.g. use an integer signal with a resoltion function
determining the maximum value of all drivers, throughout the
hierachy of the design, to set the lenght of the reset pulse in the
"reset" component of the design?

That certainly would work in simulation. I have no idea whether it is
synthesizable though (I mainly use VHDL in verification, I don'y do
synthesis).

If it is only simulation you're after, you could put the integer
signal in a package and create a global signal through you're design
by making that signal visible by USE clauses. No outputs needed then,
just assign directly to that signal.

Paul.

 

[Pontus Stenstrom]

That certainly would work in simulation. I have no idea whether it is
synthesizable though (I mainly use VHDL in verification, I don'y do
synthesis).

If it is only simulation you're after, you could put the integer
signal in a package and create a global signal through you're design
by making that signal visible by USE clauses. No outputs needed then,
just assign directly to that signal.

Paul.

I tried it. It works in Modelsim and it does synt (symplify 7.3).
But I don't really believe it.
I don't understand how synthesis will infer logic for a maximum value
resolved function. Also symplify complains if I put two drivers in the same
architecture, but not if thay are in different entities.

I'm amazed over VHDLs ability to make me produce many lines of code.
Writing the code for the idea above, with a minimalistic tb, ended
up in about 200 lines of code! (therefore i didn't include it here,
if any ones intrested ...)

/Pontus

 

[Jonathan Bromley]

I don't understand how synthesis will infer logic for a maximum value
resolved function. Also symplify complains if I put two drivers in the same
architecture, but not if thay are in different entities.

I think I agree with you. Most synthesis tools will choke on
custom resolution functions, with good reason.

Unfortunately (?), what you are trying to do is inherently quite
sensible - trying to make a centralised module in a design
have characteristics that are determined by the arbitrary
number of distributed modules in the design.

I think I would try to do this differently - perhaps by using a
script to write a configuration that sets various generics?

I'm amazed over VHDLs ability to make me produce many lines of code.
Writing the code for the idea above, with a minimalistic tb, ended
up in about 200 lines of code!

Sounds rather a lot to me. Lessee now...

~~~~~~~~~~ stuff that needs to appear just once ~~~~~~~~
(in a package)
type int_array is array (natural range <>) of integer;
function resolved (values: int_array) return integer;
subtype maximising_int is resolved integer;

(in the package body)
function resolved (values: int_array) return integer is
variable max: integer := integer'low;
begin
for i in values'range loop
if values(i) > max then
max := values(i);
end if;
end loop;
return max;
end;

(in the top level architecture)
signal reset_length: maximising_int;

~~~~~~~~~~ stuff that needs to appear once per item ~~~~~~~
(in port list of each entity that needs to provide a value)
rst_len: out maximising_int;

(in architecture of each such entity)
rst_len <= some_constant_value;

(instantiation of each of those entities)
port map (... rst_len => reset_length, ....);

That's 14 lines of code appearing once, plus three lines
for each of the "slave" entities. And then you use the
value on reset_length as a count limit in a reset generator
somewhere. That's a lot fewer than 200 lines additional code
to add this interesting feature.

But I certainly take your point, that attempting to make
something very general can sometimes give rise to apparently
rather verbose code.

I would be intrigued to know how you might do such a thing
in Verilog. A top level module can reach into a lower level
module to find out about constants (parameters) inside it, but
there is no way you can do that for an *arbitrary* number of
modules - unless you use the PLI (and that would cost you
MUCH more than 200 lines of code!).

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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