[vhdl-200x-ft] Comments on FT09 (sized bit string literals)

From: Peter Ashenden <peter@ashenden.com.au>
Date: Mon Nov 22 2004 - 21:42:15 PST

Folks,

I was reviewing FT09, and had a couple of questions. I raised them with
John Ries, who did the analysis. His responses attached.

In summary, I'd suggest the following:

1. Instead of having the size specifier being a primary, it should just be a
literal integer. This would ensure that a literal denotes a locally static
value, and that the value can be determined without depending on any
context.

2. Instead of a decimal bit string literal having a default size of 32 bits,
its default size should be the minimum number of bits needed to represent
the value in unsigned binary. I don't see any magic in the number 32 in
this context. Unlike Verilog, we're not dependent on the host simulator's
integer size here. Having the default size be a magic number instead of
depending on the decimal value makes an aspect of the model implicit rather
than manifest.

Comments?

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

attached mail follows:


Hi Peter,

I remember debating with myself on if the size should be a primary or
just a literal. I had thought having a primary gave an extra degree
of flexibility but I am not strongly attached to it. What I had thought
you could define constants in a package and have the literals change size
without any extra work.

For example
PACKAGE p IS

CONSTANT vector_size : INTEGER := 8;
SUBTYPE myvector IS std_logic_vector( vector_size-1 DOWNTO 0);
END PACKAGE;

USE p.all;
ARCHITECTURE arch OF e is

SIGNAL s1 : myvector := vector_size SX"Z"; -- initialize s1 to all Z;

...

The fact that the primary may not be locally static adds complexity that
I had not thought through. One would have literals that are no longer
locally static
and may not even be globally static. That change is more than I would want,
so we should change the production to take only a literal.

As for the lexer, I actually put the sized bit string literals into the
grammar.
The lexer only dealt with the unsized bit string literals. So it wasn't
really to
hard.

Regards,
   John

Peter Ashenden wrote:
> John,
>
> Looking further at FT09, I see that the length specifier for a sized bit
> string literal can be a primary. Is that really the intention? So I can
> write
>
> maximum(my_size, other_size, 42)SX"FF"
> p1'length B"0"
> my_non_static_fn(int_signal)B"1"
>
> Apart from the fact that such values are not "literals" (in the sense of
> literally denoting a value, since they need to be evaluated with arbitrary
> complexity), what are the implications for the lexer?
>
> This looks like a pretty radical conceptual change. Maybe it would be
> better to keep the size specifier as just a literal integer. The resize
> functions can be used for more complex cases. What do you think?
>
> 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
>

-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--

attached mail follows:


Hi Peter,

I did this for two reasons.

1) This is what Verilog does.

2) I thought it would be easy to understand if unsized decimal literals
didn't
    depend on there value for there size.

Neither reason is important to me. I just needed to start from some where.
If people want to change to use the minimum number of bits, no big deal.

Regards,
   John

Peter Ashenden wrote:
> John,
>
> I'm looking at the write up for FT09. For a decimal bit-string literal,
you
> say that the default size is 32 bits. For example, the bit-string literal
> D"17" would have the value 00000000000000000000000000010001. What was the
> rationale for choosing 32 bits? Why not the minimum number of bits needed
> to represent the value, namely, floor(log2 n)+1?
>
> 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
>

-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--
Received on Mon Nov 22 21:42:25 2004

This archive was generated by hypermail 2.1.8 : Mon Nov 22 2004 - 21:42:32 PST