Re: [vhdl-200x] Request for Input

Daniel,
*z <= x**2 / y; --where "/" is an internal function (I think it's in the
std library - not too sure)
*
*instead of writing:*
*q<=x**2;*
*divider0: entity work.div32(rtl) port map(a=>q, b=>y, res=>z,
remainder=>remainder);*
Behavioral synthesis would accept "z <= x**2 / y;"
To have a function return an instantiation is not a good idea since we have
in both VHDL and SystemVerilog the module instantiation concept.

I never used behavioral synthesis; however, below is a SystemVerilog model
where the assignment to z occurs after 10 clock cycles if "go" is enabled.
 The ## is a clock cycle delay.
I am not necessarily suggesting this for VHDL. I am just showing how
SystemVerilog can handle in clock delays using a notation.
Of course, there are other ways to express this delay.
module f;
   int x, y, z;
   logic clk, clk_dsp, go;

   default clocking default_clk @ (posedge clk_dsp); endclocking

   always @ (posedge clk)
         if(go) ##10 z <= x**2 / y;

endmodule : f

On Thu, Dec 30, 2010 at 10:12 PM, Daniel Kho <daniel.kho@gmail.com> wrote:

> Hi all,
> There have been some discussions and suggestions (here and in separate
> email threads - such as "Strong Timing" as first suggested by Jonathan, as
> well as OO and others) on the next revision of VHDL.
>
> I decided (finally) to ask a few questions to the reflector. These could
> appear as suggestions or "request for suggestions" and may stir up some
> inspiration from the SG on new ideas for the next revision.
>
> I have found it troublesome to do certain things in HDL-based digital
> design. I believe these apply to both VHDL and SystemVerilog.
>
> First, on VHDL "functions". All functions synthesize to regular
> (combinatorial) logic (muxes, gates) and never to clocked/registered logic.
> Meanwhile, if you were to design a clocked circuit, you will most definitely
> need to use "processes", or alternately, concurrent statements sensitive to
> a clock signal.
>
> I find it really troublesome to have to describe a simple algorithmic (or
> DSP) design as separate "entities" and connect those entities "structurally"
> as a synchronous circuit. For example, say I need to use a divider for my
> current design. If I want a clocked arithmetic divider (I would want this
> since it uses much less logic resources, and I can afford many clock cycles
> for the computation), I would have to describe it separately as another
> entity (say we name it "div32") with a clocked process in its architecture.
> I would then have to connect that div32 block to my design structurally,
> i.e. using port maps to internal signals in my design. Writing the process
> into the top-level design works too, but this unnecessarily makes the
> top-level design larger, and look less modular and more complex.
>
> I would really like to stick to the "function" way of describing this, as
> it is much less verbose, though I would also like to have a way for
> functions to be able to be clocked. So, in my design, I can just stick to
> something like:
> z <= x**2 / y; --where "/" is an internal function (I think it's in the
> std library - not too sure)
> instead of writing:
> q<=x**2;
> divider0: entity work.div32(rtl) port map(a=>q, b=>y, res=>z,
> remainder=>remainder);
>
> and creating a separate entity to perform the division.
>
> Perhaps we can think of a way for functions to access clocked processes? Or
> maybe a link between a function and an entity-architecture? Something like
> accessing an entity's process from within a function, like below?
> function "/"({parameter_list})
> begin
> return entityName.architectureName.processName({parameter_list});
> end function "/";
> where parameter_list is just the inputs to the process (no outputs in
> parameter_list), and the output (or return value) of the process is
> automatically mapped to the function caller. This would mean that by
> specifying it this way, we allow the process to drive only a single output
> (since the function has only a single return value):
> z <= a / b;
> In this case, "a" and "b" are both inputs to the function (and the
> process), and the process is checked to have only a single output, which is
> mapped to "z".
> I'm not too sure, hopefully we can brainstorm more ideas.
>
> Another thing I found troublesome was type conversions or type casting.
> Also, that certain library functions only support a limited set of types.
> One example mentioned earlier was in the use of literals. The following
> statement is invalid (not supported) at the moment:
> signal a:integer:=x"1a2b";
>
> though ironically this is supported:
> signal a:integer:=16#1a2b#;
>
> Also, one example regarding certain library functions only supporting a
> limited set of datatypes is the arithmetic shift operations: sra, sla.
> The arithmetic shifts only support the bit_vector type, and doesn't support
> std_logic_vector or unsigned/signed. And up till now, since I haven't been
> using a lot of bit_vectors, I am still in the dark on how to convert
> bit_vectors to say, std_logic_vectors?
>
> Comments and ideas, anyone?
>
> Regards,
> Daniel Kho
> On Tue, Dec 21, 2010 at 12:58 AM, Evan Lavelle <eml-vhdl-200x@cyconix.com>wrote:
>
>> +1
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.