Re: [vhdl-200x] Request for Input

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, and is
believed to be clean.