EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

upside down generics or so

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - upside down generics or so

Goto page 1, 2, 3  Next

Ilya Kalistru
Guest

Thu Aug 11, 2016 4:55 pm   



Sometimes I design complex pipeline which splits on several pipelines at some point and then these branch pipelines are joined in one pipeline again.

| root pipeline
|
|\
|\\
||| branch pipelines
|// joint point
|

At the pipeline joint point data from different branches have to be aligned relatively to each other, so sometimes I have to add shift registers to shorter branch pipelines. Branch pipelines usually consist of several modules and added delays depends on the latencies of each module. As long as modules can be changed and their latency can be changed, I have to adjust delays.

Is there a way to set latency of the module as some “property” in it, so that a top module could read it and adjust delay lines? Something like reversed generics – generics pass parameter to a module but I need to pass it from the module.

Any ideas?

KJ
Guest

Thu Aug 11, 2016 6:30 pm   



On Thursday, August 11, 2016 at 10:55:20 AM UTC-4, Ilya Kalistru wrote:
Quote:

Is there a way to set latency of the module as some “property” in it, so
that a top module could read it and adjust delay lines? Something like
reversed generics – generics pass parameter to a module but I need to pass
it from the module.

Presumably, the amount of latency of a particular module is either fixed or is a function of the generic inputs to that module. Since those generics are available to the top level module as well, then a function can be created that calculates the latency of all of the modules and then uses those latencies to define the amount of latency required at the top.


Kevin Jennings

Ilya Kalistru
Guest

Thu Aug 11, 2016 10:53 pm   



On Thursday, August 11, 2016 at 7:30:20 PM UTC+3, KJ wrote:
Quote:
On Thursday, August 11, 2016 at 10:55:20 AM UTC-4, Ilya Kalistru wrote:

Is there a way to set latency of the module as some “property” in it, so
that a top module could read it and adjust delay lines? Something like
reversed generics – generics pass parameter to a module but I need to pass
it from the module.

Presumably, the amount of latency of a particular module is either fixed or is a function of the generic inputs to that module. Since those generics are available to the top level module as well, then a function can be created that calculates the latency of all of the modules and then uses those latencies to define the amount of latency required at the top.

Kevin Jennings


I don't think so. Latency depends on algorithms, how they are implemented and how well the module is optimized. All that could (and will) change during product development.

rickman
Guest

Thu Aug 11, 2016 10:55 pm   



On 8/11/2016 10:55 AM, Ilya Kalistru wrote:
Quote:
Sometimes I design complex pipeline which splits on several pipelines at some point and then these branch pipelines are joined in one pipeline again.

| root pipeline
|
|\
|\\
||| branch pipelines
|// joint point
|

At the pipeline joint point data from different branches have to be aligned relatively to each other, so sometimes I have to add shift registers to shorter branch pipelines. Branch pipelines usually consist of several modules and added delays depends on the latencies of each module. As long as modules can be changed and their latency can be changed, I have to adjust delays.

Is there a way to set latency of the module as some “property” in it, so that a top module could read it and adjust delay lines? Something like reversed generics – generics pass parameter to a module but I need to pass it from the module.

Any ideas?


A module passes signals in and out. You can create a constant integer
output signal. Nothing fancy needed. Add up all the delays and
subtract from the longest to get the additional pipeline stages needed.

These values will only be used in generate statements so it won't create
any logic. You may get warnings of signals that are deleted for having
no source and/or no destination. Personally I hate that. A design
should be synthesized without warnings.

--

Rick C

Ilya Kalistru
Guest

Thu Aug 11, 2016 11:16 pm   



On Thursday, August 11, 2016 at 7:55:11 PM UTC+3, rickman wrote:
Quote:
On 8/11/2016 10:55 AM, Ilya Kalistru wrote:
Sometimes I design complex pipeline which splits on several pipelines at some point and then these branch pipelines are joined in one pipeline again.

| root pipeline
|
|\
|\\
||| branch pipelines
|// joint point
|

At the pipeline joint point data from different branches have to be aligned relatively to each other, so sometimes I have to add shift registers to shorter branch pipelines. Branch pipelines usually consist of several modules and added delays depends on the latencies of each module. As long as modules can be changed and their latency can be changed, I have to adjust delays.

Is there a way to set latency of the module as some “property” in it, so that a top module could read it and adjust delay lines? Something like reversed generics – generics pass parameter to a module but I need to pass it from the module.

Any ideas?

A module passes signals in and out. You can create a constant integer
output signal. Nothing fancy needed. Add up all the delays and
subtract from the longest to get the additional pipeline stages needed.

These values will only be used in generate statements so it won't create
any logic. You may get warnings of signals that are deleted for having
no source and/or no destination. Personally I hate that. A design
should be synthesized without warnings.

--

Rick C


With constant signal outputs you can neither define signals like
signal DelayLine : std_logic_vector(DelayFromTheModule downto 0);
nor use generate statements with this parameters.

The only way to use them (that I see) is to make excessively long delay lines and multiplexers from each stage of it, controlled by that constant signal. Then we have to hope that synthesizer will optimize it properly, remove unnecessary multiplexer and will be able to infer built-in shift registers there.
It's not very elegant solution and it has very limited use because we cannot use signals everywhere we want (but can use constants and generics).

Or I miss something?

I've seen that it's possible to define some objects inside entity declaration. I hope that there is something exotic like that which will allow to do what I want...

Jim Lewis
Guest

Fri Aug 12, 2016 4:39 pm   



I would put a constant in a package that is associated with a particular entity. As you do your detailed design and update the pipeline in a particular block, simply update the corresponding constant in the package - even better would be to use that constant to define the number of pipeline stages in the block.

Then any design that references the package can see the constant.

Ilya Kalistru
Guest

Fri Aug 12, 2016 7:12 pm   



On Friday, August 12, 2016 at 5:39:36 PM UTC+3, Jim Lewis wrote:
Quote:
I would put a constant in a package that is associated with a particular entity. As you do your detailed design and update the pipeline in a particular block, simply update the corresponding constant in the package - even better would be to use that constant to define the number of pipeline stages in the block.

Then any design that references the package can see the constant.


That's exactly what I've done. But when you are modifying the module you have to remember that somewhere in a different file (package) there is a constant you have to adjust according to you changes.

rickman
Guest

Sat Aug 13, 2016 7:30 am   



On 8/13/2016 12:58 AM, Allan Herriman wrote:
Quote:
On Fri, 12 Aug 2016 23:28:13 -0400, rickman wrote:

On 8/12/2016 11:09 PM, Allan Herriman wrote:
On Fri, 12 Aug 2016 10:12:40 -0700, Ilya Kalistru wrote:

On Friday, August 12, 2016 at 5:39:36 PM UTC+3, Jim Lewis wrote:
I would put a constant in a package that is associated with a
particular entity. As you do your detailed design and update the
pipeline in a particular block, simply update the corresponding
constant in the package - even better would be to use that constant
to define the number of pipeline stages in the block.

Then any design that references the package can see the constant.

That's exactly what I've done. But when you are modifying the module
you have to remember that somewhere in a different file (package)
there is a constant you have to adjust according to you changes.


I contend that you *don't* have to remember to adjust that, as long as
you:

1. Write an assert statement inside your module that checks that the
package constant has the value that matches your design. I suggest a
higher severity level on the assertion, e.g. failure.

2. You remember to simulate your design (so that the assertion can be
checked). I wouldn't rely on a synthesiser to check an assertion, but
all simulators should work properly.


(In any reasonable development process) you'll already be required to
simulate your testbench before committing your code change.
The only new thing you have to do is add the 1 line of assertion
statement in your module.

So when a change is made to the pipeline depth a change will need to be
made for adjusting the delay pipeline in two places.


A change is need in two places: the pipeline depth inside the module and
the constant in the package.

The assert statement checks one against the other and won't need to be
changed. You're doing something wrong if you need to change the assert
statement as well, because then you're not checking the constant in the
package directly against the thing it's meant to track.


Not sure what you are saying about "pipeline depth". The module has
functionality that uses some number of logic pipeline stages. This has
to be noted in the module as a constant to use in the assert statement,
otherwise it is not needed in the module. This value also must be noted
as a constant in the package to correspond to the module. These two
values must be kept in sync and also aligned with the design of the module.

Maybe this is not as big issue as I am thinking since it is not likely
the modules will change pipeline depths. Rather modules will be added
or replaced by other modules. But in addition to keeping the two
constants in sync with the module design, the use of the module has to
be kept in sync with the corresponding constant being passed into the
module as well as the use in defining the delay pipeline.

This sounds like a lot of work to me and potentially error prone which
is what it is trying to prevent. It also ends up being a bit verbose
which is one of the problems with VHDL. The use of various tools has
made design of VHDL code a bit easier, but I know I get tired of all the
typing I have to do when making changes which end up being manual mostly.


Quote:
One to check the
other. I guess that's one way to make this work.

Are you implying you have a better way (that works with the current
language and tools)? Please tell - I'm always happy to learn new
techniques.


My opinion is to not do it at all. The documentation of the module can
provide the logic pipeline depth used and the designer can work it out
in the unit using the module. I think that would be easier and less
error prone in real usage. I can't tell how many times I have gone to
lengths to try to prevent errors only to find I have done more work that
is useful. Sometimes simpler is better.

--

Rick C

Allan Herriman
Guest

Sat Aug 13, 2016 7:30 am   



On Fri, 12 Aug 2016 23:28:13 -0400, rickman wrote:

Quote:
On 8/12/2016 11:09 PM, Allan Herriman wrote:
On Fri, 12 Aug 2016 10:12:40 -0700, Ilya Kalistru wrote:

On Friday, August 12, 2016 at 5:39:36 PM UTC+3, Jim Lewis wrote:
I would put a constant in a package that is associated with a
particular entity. As you do your detailed design and update the
pipeline in a particular block, simply update the corresponding
constant in the package - even better would be to use that constant
to define the number of pipeline stages in the block.

Then any design that references the package can see the constant.

That's exactly what I've done. But when you are modifying the module
you have to remember that somewhere in a different file (package)
there is a constant you have to adjust according to you changes.


I contend that you *don't* have to remember to adjust that, as long as
you:

1. Write an assert statement inside your module that checks that the
package constant has the value that matches your design. I suggest a
higher severity level on the assertion, e.g. failure.

2. You remember to simulate your design (so that the assertion can be
checked). I wouldn't rely on a synthesiser to check an assertion, but
all simulators should work properly.


(In any reasonable development process) you'll already be required to
simulate your testbench before committing your code change.
The only new thing you have to do is add the 1 line of assertion
statement in your module.

So when a change is made to the pipeline depth a change will need to be
made for adjusting the delay pipeline in two places.


A change is need in two places: the pipeline depth inside the module and
the constant in the package.

The assert statement checks one against the other and won't need to be
changed. You're doing something wrong if you need to change the assert
statement as well, because then you're not checking the constant in the
package directly against the thing it's meant to track.


Quote:
One to check the
other. I guess that's one way to make this work.


Are you implying you have a better way (that works with the current
language and tools)? Please tell - I'm always happy to learn new
techniques.

Allan

rickman
Guest

Sat Aug 13, 2016 7:30 am   



On 8/12/2016 11:09 PM, Allan Herriman wrote:
Quote:
On Fri, 12 Aug 2016 10:12:40 -0700, Ilya Kalistru wrote:

On Friday, August 12, 2016 at 5:39:36 PM UTC+3, Jim Lewis wrote:
I would put a constant in a package that is associated with a
particular entity. As you do your detailed design and update the
pipeline in a particular block, simply update the corresponding
constant in the package - even better would be to use that constant to
define the number of pipeline stages in the block.

Then any design that references the package can see the constant.

That's exactly what I've done. But when you are modifying the module you
have to remember that somewhere in a different file (package) there is a
constant you have to adjust according to you changes.


I contend that you *don't* have to remember to adjust that, as long as
you:

1. Write an assert statement inside your module that checks that the
package constant has the value that matches your design. I suggest a
higher severity level on the assertion, e.g. failure.

2. You remember to simulate your design (so that the assertion can be
checked). I wouldn't rely on a synthesiser to check an assertion, but
all simulators should work properly.


(In any reasonable development process) you'll already be required to
simulate your testbench before committing your code change.
The only new thing you have to do is add the 1 line of assertion
statement in your module.


So when a change is made to the pipeline depth a change will need to be
made for adjusting the delay pipeline in two places. One to check the
other. I guess that's one way to make this work.

--

Rick C

Allan Herriman
Guest

Sat Aug 13, 2016 7:30 am   



On Fri, 12 Aug 2016 10:12:40 -0700, Ilya Kalistru wrote:

Quote:
On Friday, August 12, 2016 at 5:39:36 PM UTC+3, Jim Lewis wrote:
I would put a constant in a package that is associated with a
particular entity. As you do your detailed design and update the
pipeline in a particular block, simply update the corresponding
constant in the package - even better would be to use that constant to
define the number of pipeline stages in the block.

Then any design that references the package can see the constant.

That's exactly what I've done. But when you are modifying the module you
have to remember that somewhere in a different file (package) there is a
constant you have to adjust according to you changes.


I contend that you *don't* have to remember to adjust that, as long as
you:

1. Write an assert statement inside your module that checks that the
package constant has the value that matches your design. I suggest a
higher severity level on the assertion, e.g. failure.

2. You remember to simulate your design (so that the assertion can be
checked). I wouldn't rely on a synthesiser to check an assertion, but
all simulators should work properly.


(In any reasonable development process) you'll already be required to
simulate your testbench before committing your code change.
The only new thing you have to do is add the 1 line of assertion
statement in your module.


Regards,
Allan

Ilya Kalistru
Guest

Sat Aug 13, 2016 6:45 pm   



On Saturday, August 13, 2016 at 8:33:15 AM UTC+3, rickman wrote:
Quote:
On 8/13/2016 12:58 AM, Allan Herriman wrote:
On Fri, 12 Aug 2016 23:28:13 -0400, rickman wrote:

On 8/12/2016 11:09 PM, Allan Herriman wrote:
On Fri, 12 Aug 2016 10:12:40 -0700, Ilya Kalistru wrote:

On Friday, August 12, 2016 at 5:39:36 PM UTC+3, Jim Lewis wrote:
I would put a constant in a package that is associated with a
particular entity. As you do your detailed design and update the
pipeline in a particular block, simply update the corresponding
constant in the package - even better would be to use that constant
to define the number of pipeline stages in the block.

Then any design that references the package can see the constant.

That's exactly what I've done. But when you are modifying the module
you have to remember that somewhere in a different file (package)
there is a constant you have to adjust according to you changes.


I contend that you *don't* have to remember to adjust that, as long as
you:

1. Write an assert statement inside your module that checks that the
package constant has the value that matches your design. I suggest a
higher severity level on the assertion, e.g. failure.

2. You remember to simulate your design (so that the assertion can be
checked). I wouldn't rely on a synthesiser to check an assertion, but
all simulators should work properly.


(In any reasonable development process) you'll already be required to
simulate your testbench before committing your code change.
The only new thing you have to do is add the 1 line of assertion
statement in your module.

So when a change is made to the pipeline depth a change will need to be
made for adjusting the delay pipeline in two places.


A change is need in two places: the pipeline depth inside the module and
the constant in the package.

The assert statement checks one against the other and won't need to be
changed. You're doing something wrong if you need to change the assert
statement as well, because then you're not checking the constant in the
package directly against the thing it's meant to track.

Not sure what you are saying about "pipeline depth". The module has
functionality that uses some number of logic pipeline stages. This has
to be noted in the module as a constant to use in the assert statement,
otherwise it is not needed in the module. This value also must be noted
as a constant in the package to correspond to the module. These two
values must be kept in sync and also aligned with the design of the module.

Maybe this is not as big issue as I am thinking since it is not likely
the modules will change pipeline depths. Rather modules will be added
or replaced by other modules. But in addition to keeping the two
constants in sync with the module design, the use of the module has to
be kept in sync with the corresponding constant being passed into the
module as well as the use in defining the delay pipeline.

This sounds like a lot of work to me and potentially error prone which
is what it is trying to prevent. It also ends up being a bit verbose
which is one of the problems with VHDL. The use of various tools has
made design of VHDL code a bit easier, but I know I get tired of all the
typing I have to do when making changes which end up being manual mostly.


One to check the
other. I guess that's one way to make this work.

Are you implying you have a better way (that works with the current
language and tools)? Please tell - I'm always happy to learn new
techniques.

My opinion is to not do it at all. The documentation of the module can
provide the logic pipeline depth used and the designer can work it out
in the unit using the module. I think that would be easier and less
error prone in real usage. I can't tell how many times I have gone to
lengths to try to prevent errors only to find I have done more work that
is useful. Sometimes simpler is better.

--

Rick C


hm... It's sad that there is no such thing like output generic. It would make a lot of things much easier.

BTW when it comes to simulation, I have a method I use to check correctness of pipelines length:
There is usually something like Data.Valid signal or Data.EndOfPacket signal or something like that. When you merge two pipelines you usually really need only one of them from one of the pipelines, but I make an assert to check that both of them are aligned.
Sometimes I even add such a signal just for debugging purposes.
Unfortunately, it's not always possible.

Lars Asplund
Guest

Sun Aug 14, 2016 12:02 am   



Often when I design a pipelined module I use the globally available latency property/constant to specify the signals holding the pipeline registers, for example to create the delayline/std_logic_vector between an input and an output data valid signal. If there is no data valid and the property isn't used elsewhere in the module's design it should still be used in the testbench for the module to check that the expected output is present latency clock cycles after the test input is applied. If you forget to update the property when changing the pipeline depth you will find out when running your testbench and not when someone starts using your module *and* your latency constant.

I would not like to maintain the same latency number at multiple places as that would violate the DRY principle (Don't Repeat Yourself). Note that the DRY principle applies to documentation as well. If the latency changes you have to update the documentation as well as all copies of that number made by users of that module after reading the documents (unless the docs points to the constant).

When talking about properties I think it's worth mentioning user-defined attributes. They are not well-supported by tools and I think the purpose was to use them as tools directives rather than within the VHDL model itself. Still, you can define a latency attribute and use that to decorate an entity with a latency value that can be accessed by other modules. With that approach there is no need to create a package in order to export this property.

Allan Herriman
Guest

Sun Aug 14, 2016 7:30 am   



On Sat, 13 Aug 2016 15:02:22 -0700, Lars Asplund wrote:

Quote:
Often when I design a pipelined module I use the globally available
latency property/constant to specify the signals holding the pipeline
registers, for example to create the delayline/std_logic_vector between
an input and an output data valid signal. If there is no data valid and
the property isn't used elsewhere in the module's design it should still
be used in the testbench for the module to check that the expected
output is present latency clock cycles after the test input is applied.
If you forget to update the property when changing the pipeline depth
you will find out when running your testbench and not when someone
starts using your module *and* your latency constant.

I would not like to maintain the same latency number at multiple places
as that would violate the DRY principle (Don't Repeat Yourself). Note
that the DRY principle applies to documentation as well. If the latency
changes you have to update the documentation as well as all copies of
that number made by users of that module after reading the documents
(unless the docs points to the constant).

When talking about properties I think it's worth mentioning user-defined
attributes. They are not well-supported by tools and I think the purpose
was to use them as tools directives rather than within the VHDL model
itself. Still, you can define a latency attribute and use that to
decorate an entity with a latency value that can be accessed by other
modules. With that approach there is no need to create a package in
order to export this property.


I don't have a copy of the LRM handy to check this, but I thought (and
hopefully I am wrong here) that a user defined attribute associated with
an entity could only be used inside that entity or architectures of that
entity, and not in an architecture that instantiates that entity (which
is where we want it).

For example, I *wouldn't* be able to say:

my_label : work.my_entity
generic map ( ... )
port map ( ... );

report some_type'image(my_label'my_attribute);


I'd be very happy to be proven wrong on this.

Thanks,
Allan


Guest

Sun Aug 14, 2016 8:59 am   



You will have to do

report some_type'image(work.my_entity'my_attribute);

Your report statement would report the attribute for the instance label which would work if it was specified for that label. Not what we want in this case though.

/Lars

Goto page 1, 2, 3  Next

elektroda.net NewsGroups Forum Index - VHDL Language - upside down generics or so

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map