[vhdl-200x-mp] Re: FW: New Issue.

Wow, this has gained alot of momentum faster than I
anticipated. I was hoping that Steve would
assign it to a group first. However, it seems to
belong in MP, so lets move the discussion to the
MP reflector.

Tim, if you want to own the proposal/LCS, then great.
I would say it is a separate issue from interfaces.

> The problem of circular dependencies is potentially challenging as well.
I think simulators have already solved problems like this.
Currently with delta time, if delta time advances past a
limit then simulators currently stop.
Practically speaking, there is an upper bound to the number
of dependencies through which a generic will expand.
If it goes beyond this limit stop.

Cheers,
Jim

Tim Davis wrote:

> This is a persistant problem in my design world. I've wanted a solution
> for a long time.
>
> I coined the phrase, "Function constrains downward, physics constrains
> upwards" to express the inevitable conflict that occurs between top-down
> and bottom-up design methodologies. The current VHDL implementation of
> generics supports the top-down flow of design constraints. An "out" mode
> generic would support bottom up construction.
>
> I appreciate Peter's desire to utilize existing language mechanisms to
> solve problems before inventing new solutions. The method below appears
> to be quite awkward however. I'd like to come up with something better.
>
> The problem of circular dependencies is potentially challenging as well.
> Consider an outward generic value that ultimately causes a generate
> statement to eliminate the instance of the component with the generic!
>
> So, the solution may have a few hidden land mines to work around but I
> believe "outward" generics would be a valuable and much used addition to
> VHDL. I'd be happy to lead the effort in investigating "outnerics" with
> the goal of generating a proposal. This could be a seperate WG effort or
> be included as part of my other deep interest in interfaces.
> --
> Aspen Logic, Inc.
> By: Tim Davis, President
>
> Bailey, Stephen wrote:
>
>>Tim,
>>
>>You provided me with a good description for why OUT mode generics are needed in VHDL. Can you reply to Peter's question?
>>
>>-Steve Bailey
>>
>>-----Original Message-----
>>From: Peter Ashenden [mailto:peter@ashenden.com.au]
>>Sent: Friday, April 23, 2004 2:24 AM
>>To: Bailey, Stephen
>>Subject: RE: New Issue.
>>
>>
>>Folks,
>>
>>What's the underlying modeling requirement that these ideas are trying to
>>address? My understanding of the scenario is that we're trying to derive a
>>value for a property of a design unit from the actual generics of a design
>>unit, so that we can use the property value elsewhere in the model that
>>instantiates the design unit. For example, if we instantiate a memory with
>>generics for the address and data sizes, we might want to derive an access
>>delay property. We then might want to use that access delay in a testbench
>>that samples data outputs after changing address inputs. Am I on the right
>>track?
>>
>>What I was trying to suggest in my reference to packages was to think of the
>>design context in which the design unit model is developed and provided to
>>users. The units provided could be not just the entity and architecture(s),
>>but also a package that provides functions for calculating dependent
>>properties. So, in the case of the memory model, the provider could provide
>>
>>entity memory is
>> generic ( addr_width, data_width : positive;
>> use_super_duper_version : boolean );
>> port ( ... );
>>end entity memory;
>>
>>architecture a of memory is
>> ...
>>begin
>> ordinary : if not use_super_duper_version generate
>> ... -- instantiate boring old cells
>> end generate ordinary;
>> super_duper : if use_super_duper_version generate
>> ... -- instantiate super duper cells
>> end generate super_duper;
>>end architecture a;
>>
>>package memory_pkg is
>> function calc_access_delay ( addr_width, data_width : positive;
>> use_super_duper_version : boolean )
>> return delay_length;
>>end package memory_pkg;
>>
>>package body memory_pkg is
>> function calc_access_delay ( addr_width, data_width : positive;
>> use_super_duper_version : boolean )
>> return delay_length is
>> begin
>> if use_super_duper_version then
>> return ...
>> else
>> return ...
>> end if;
>> end function calc_access_delay;
>>end package body memory_pkg;
>>
>>Then, in the test bench, the user of the memory model could do something
>>like
>>
>>architecture mybench of system is
>> constant addr_width : positive := 10;
>> constant data_width : positive := 8;
>> constant super_duper : boolean := false;
>> constant mem_delay : delay_length is
>> work.memory_pkg.calc_access_delay(addr_width, data_width, super_duper);
>> ...
>>begin
>> dut : entity work.memory(a)
>> generic map(addr_width, data_width, super_duper)
>> port map ( ... );
>>
>> addr_gen : process is
>> ...
>> end process addr_gen;
>>
>> mem_monitor : process is
>> begin
>> wait on addr;
>> wait for mem_delay;
>> ... -- verify correct memory read
>> end process mem_monitor;
>>end architecture mybench;
>>
>>In other words (if I understand the underlying design context correctly), I
>>was advocating meeting the requirement through a use case of the existing
>>language rather than a significant change to the language.
>>
>>Cheers,
>>
>>PA
>>
>>--
>>Dr. Peter J. Ashenden peter@ashenden.com.au
>>Ashenden Designs Pty. Ltd. www.ashenden.com.au
>>PO Box 640 Ph: +61 8 8339 7532
>>Stirling, SA 5152 Fax: +61 8 8339 2616
>>Australia Mobile: +61 414 70 9106
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Bailey, Stephen [mailto:SBailey@model.com]
>>>Sent: Friday, 23 April 2004 16:21
>>>To: 'Peter Ashenden'; 'Jim Lewis'; 'vhdl-200x-sc'
>>>Subject: RE: New Issue.
>>>
>>>
>>>All,
>>>
>>>The need for an OUT mode generic has been around for some
>>>time. The language issue is what Peter lays out below: the
>>>potential for circular dependency while elaborating a design.
>>> Today, VHDL has no such cycles during elaboration and this
>>>makes life reasonable for implementers, keeps tool
>>>development costs down and VHDL language enhancers (members
>>>of this WG) sane.
>>>
>>>Here's something for the minds in this WG that are sharper
>>>than mine to consider:
>>>
>>> - We define a new class of object, call it "genericout" or
>>>perhaps "postponed constant" for now.
>>>
>>> - The genericout objects would not be globally static.
>>>Therefore, they could not be used in calculating the value of
>>>a globally static object. This would avoid the potential for
>>>an elaboration dependency cycle as the genericout object
>>>could not be used in the specification of a generic or
>>>constant value expression.
>>>
>>> - However, the genericout would otherwise be treated as
>>>constant at the end of elaboration. That is, its value could
>>>not be changed.
>>>
>>>Would this satisfy the user requirement while avoiding
>>>elaboration cyclic dependencies?
>>>
>>>Another option: Allow shared variables to be specified in a
>>>port interface. No signaling semantics would be implied. It
>>>would still be a shared variable. It just provides a means
>>>for connecting shared variables through the hierarchy. If
>>>you can do that, then a shared variable can be used to
>>>propagate a value up the hierarchy.
>>>
>>>Both options have the limitation that the object is not
>>>static and cannot be used in contexts requiring a static
>>>expression. The example (determining a delay) does not
>>>require a static expression in the use of the delay (signal
>>>assignment). The difference between the two options is
>>>whether the value can be changed after elaboration. In fact,
>>>the two proposals are not mutually exclusive.
>>>
>>>-Steve Bailey
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>Jim,
>>>>
>>>>Some thoughts that immediately spring to mind...
>>>>
>>>>What would be the actual for such a generic. Obviously it
>>>>
>>>>
>>>could be an
>>>
>>>
>>>>output generic of the enclosing block, but what about at
>>>>
>>>>
>>>the top level
>>>
>>>
>>>>of a subhierarchy? Would it be a constant? If so, then
>>>>
>>>>
>>>the semantics
>>>
>>>
>>>>for initialization of a constant would have to be extended to allow
>>>>initialization via association with an output generic instead
>>>>of via an
>>>>initial value expression. That would then have implications
>>>>on order of
>>>>elaboration, since you'd want the constant to be initialized before
>>>>elaborating things that use its value. This would get very
>>>>messy and not
>>>>soluble in general.
>>>>
>>>>An alternative approach would be for the developer of the
>>>>design unit to
>>>>provide a package that included functions for calculating values of
>>>>dependent parameters based on values of independent
>>>>parameters. These could
>>>>be used where the design is instantiated to calculate values
>>>>for feeding to
>>>>other instantiated units. It's a different design
>>>>discipline, but one that
>>>>still provides for separation of concerns while working with
>>>>the language as
>>>>it stands.
>>>>
>>>>End $0.02
>>>>
>>>>Cheers,
>>>>
>>>>PA
>>>>
>>>>--
>>>>Dr. Peter J. Ashenden peter@ashenden.com.au
>>>>Ashenden Designs Pty. Ltd. www.ashenden.com.au
>>>>PO Box 640 Ph: +61 8 8339 7532
>>>>Stirling, SA 5152 Fax: +61 8 8339 2616
>>>>Australia Mobile: +61 414 70 9106
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: owner-vhdl-200x-sc@eda.org
>>>>>[mailto:owner-vhdl-200x-sc@eda.org] On Behalf Of Jim Lewis
>>>>>Sent: Friday, 23 April 2004 10:21
>>>>>To: vhdl-200x-sc
>>>>>Subject: New Issue.
>>>>>
>>>>>
>>>>>Issue Summary:
>>>>>Generic Output:
>>>>>Block A uses generic inputs and/or constants
>>>>>to calculate a constant output value. This
>>>>>constant output is used as the input to another
>>>>>block as a generic input.
>>>>>
>>>>>Algorithms to create the constant output generic
>>>>>may change as the design changes so it would be
>>>>>most convenient to calculate it in the design block.
>>>>>
>>>>>Cheers,
>>>>>Jim
>>>>>
>>>>>
>>>>>
>>>>>-------- Original Message --------
>>>>>Subject: VHDL-200X Inquiry
>>>>>Date: Wed, 21 Apr 2004 20:02:34 -0600
>>>>>From: ryan.w.hinton@L-3com.com
>>>>>To: Jim@SynthWorks.com
>>>>>
>>>>>
>>>>>One modelling improvement I have wished for in VHDL is an
>>>>>output of class CONSTANT--i.e. an OUT GENERIC. The main
>>>>>example I can think of is when I need to pipeline an external
>>>>>signal to match the latency through a given block, it would
>>>>>great to give the latency through the block as an output.
>>>>>This is particularly useful when the latency through the
>>>>>block is dependent on GENERIC inputs.
>>>>>
>>>>>Incidentally, I once tried creating an output port of type
>>>>>INTEGER and only initializing the signal attached to the
>>>>>output, but my synthesis tool routed all 32 bits and didn't
>>>>>optimize any logic. This type of output should really be
>>>>>CONSTANT class since it depends only on CONSTANT class inputs.
>>>>>
>>>>>Please let me know if you have any questions.
>>>>>
>>>>>---
>>>>>Ryan Hinton
>>>>>L-3 Communications / Communication Systems - West
>>>>>ryan.w.hinton@L-3com.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>Jim Lewis
>>>>>Director of Training mailto:Jim@SynthWorks.com
>>>>>SynthWorks Design Inc. http://www.SynthWorks.com
>>>>>1-503-590-4787
>>>>>
>>>>>Expert VHDL Training for Hardware Design and Verification
>>>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~