Signed, Unsigned syntax issues. Please help, I'm stumped

N

nitrogenocide

I'm still a little new to Xilinx so I'm working through some syntax
issues. I'm working with ISE 10.1



After running "check syntax", I get the following errors.



ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 114. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED



here are the lines being referred to:



Line 92: if setup_sample = "1111111" then

Line 114: curval <= countupstuff when setup_sample = "1111110";

Line 145: elsif apnea_count = "1101001101010101100100000" then



The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned



(these are lines 39 through 47)


architecture Behavioral of SS08 is

signal countupstuff, curval, sample, count_1khz : unsigned (15 downto
0);
signal apnea_reset, alarm_out, clock1k, clock1k_int, inc_apnea_count,
inc_not_apnea, clock32x, clock32x_int, settozero : std_logic;
signal apnea_count, not_apnea : unsigned (24 downto 0);
signal count_1Mhz : unsigned (4 downto 0);
signal setup_sample : unsigned (6 downto 0);

begin


Interesting note, I was previously running this code on ISE 9.1 and it
didn't have a problem with it.


Can any one shed some light on why I'm getting these errors? It would
be very much appreciated. Let me know if you need any more
information.



Thanks,



Jeff
 
K

KJ

After running "check syntax", I get the following errors.

ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 114. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED


here are the lines being referred to:

Line 92: if setup_sample = "1111111" then

Line 114: curval <= countupstuff when setup_sample = "1111110";

Line 145: elsif apnea_count = "1101001101010101100100000" then


The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned

But the thing you're comparing them to (i.e. "1111111" and "1111110" are
ambiguous). You need to tell it if it is signed or unsigned like this

unsigned'("1111110")

Note the tick mark.

KJ
 
M

Mike Treseler

ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
Line 145: elsif apnea_count = "1101001101010101100100000" then
The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned

Declare the constants also:
architecture Behavioral of SS08 is
subtype cnt25_t is unsigned(24 downto 0);
signal apnea_count, not_apnea : cnt25_t;
constant cnt25_c :: cnt25_t := "1101001101010101100100000";
....
etc.

Put this at the top:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;


-- Mike Treseler
 
K

KJ

Jonathan Bromley said:
On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:


Intriguingly, this exact issue came up here only a couple
of days ago.

A regular conspiracy going on ;)
It's almost certainly because you are accepting the goofy
Xilinx default VHDL code template which has, inter alia,

USE IEEE.STD_LOGIC_ARITH.all;

No-one can explain why Xilinx (and others too) continue
to recommend in this way the use of a package that was
superseded by the better, more complete, properly
standardised IEEE.NUMERIC_STD over a decade ago.

That would bring them up to the 90s now wouldn't it....only 15 or so years
behind the standards.
The less satisfactory fix (hack) is to make the type
of your constants explicit:

if setup_sample = UNSIGNED'("1111111") then

This is known as a "type qualification"; note the
apostrophe between the type name and the opening
parenthesis.

If for some reason you reeeeeally didn't want to properly define a constant
to do the job, I think using the type qualifier is better (not a hack)
since, even if the compiler has no ambiguity, the reader may and having the
type qualifier makes it explicit to the reader as to the intended
type...documentation comes in all forms.

Kevin Jennings
 
A

Andy Peters

A regular conspiracy going on ;)




That would bring them up to the 90s now wouldn't it....only 15 or so years
behind the standards.

I opened up a Web Case about this. Let's see if they give a shit.

Oh, yeah, in that same Web Case, I suggested that their templates use:

if rising_edge(clk) then

instead of

if (clk'event and clk = '1') then

It's almost halfway through 2008 ...

=-a
 
R

rickman

After running "check syntax", I get the following errors.
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED [etc]
Line 92: if setup_sample = "1111111" then
[etc]

The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned

Intriguingly, this exact issue came up here only a couple
of days ago.

It's almost certainly because you are accepting the goofy
Xilinx default VHDL code template which has, inter alia,

USE IEEE.STD_LOGIC_ARITH.all;

No-one can explain why Xilinx (and others too) continue
to recommend in this way the use of a package that was
superseded by the better, more complete, properly
standardised IEEE.NUMERIC_STD over a decade ago.

The specific issue is that STD_LOGIC_ARITH provides
definitions of the "=" operator for all the following
combinations of types:

UNSIGNED = UNSIGNED
UNSIGNED = SIGNED
SIGNED = UNSIGNED
SIGNED = SIGNED

If the things on the opposite sides of the "=" are
simple variables or signals, that's fine - but if they
are expressions, or literals like your "111111", there
is a type ambiguity because the literal might be either
SIGNED or UNSIGNED, and VHDL can't work out which it is.

The preferred fix is to replace STD_LOGIC_ARITH with
NUMERIC_STD. This will fix the type ambiguity issue, but
it may give you a few other compile errors because the
conversion functions' names have changed: conv_integer()
is now to_integer, and conv_unsigned() is now called
to_unsigned(). Obviously, those will be rather easy
to deal with. This is by far the most satisfactory
solution. NUMERIC_STD defines equality for
UNSIGNED=UNSIGNED and for SIGNED=SIGNED, but not
for combinations of the two - so, in your comparison,
there is only one possible interpretation of the
constant and VHDL will get it right automatically.

I can't sat that Numemric_std is a panacea. VHDL is still a tough
language to master in terms of the strong typing. It is hard to even
figure out what the true nature of the problem is in many cases. Here
is one that I am currently dealing with. I just changed a number of
slvs to unsigned and now I get this error.

if (CTPCurCmd(VER_RNG) = '1') and (DataOutReg /= CTPCurCmd(DAT_RNG))
then

---No matching overload for "/="---

DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
types were "closely related" which means I don't have to use
conversions to intermix them. I also get errors when trying to
concatenate slv with unsigned. What exactly is wrong with either of
these? I guess it doesn't know what type to make the result of a
concatenation, but the equality comparison shouldn't have that
problem.

Rick
 
M

Mike Treseler

rickman said:
---No matching overload for "/="---

DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
types were "closely related" which means I don't have to use
conversions to intermix them.

No, closely related means I can use
a cast instead of a conversion as in:

unsigned(DataOutReg) /= CTPCurCmd(DAT_RNG)

Let's look up the "/=" functions available
in the numeric_std source here:

http://www.cs.umbc.edu/help/VHDL/packages/numeric_std.vhd

function "/=" (L,R: UNSIGNED ) return BOOLEAN;
function "/=" ( L,R: SIGNED) return BOOLEAN;
function "/=" ( L: NATURAL; R: UNSIGNED) return BOOLEAN;
function "/=" ( L: INTEGER; R: SIGNED) return BOOLEAN;
function "/=" ( L: UNSIGNED; R: NATURAL) return BOOLEAN;
function "/=" ( L: SIGNED; R: INTEGER) return BOOLEAN;

For your example, a cast is needed to match the first signature.

-- Mike Treseler
 
A

Andy

After running "check syntax", I get the following errors.
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED [etc]
Line 92: if setup_sample = "1111111" then
The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned
Intriguingly, this exact issue came up here only a couple
of days ago.
It's almost certainly because you are accepting the goofy
Xilinx default VHDL code template which has, inter alia,
USE IEEE.STD_LOGIC_ARITH.all;
No-one can explain why Xilinx (and others too) continue
to recommend in this way the use of a package that was
superseded by the better, more complete, properly
standardised IEEE.NUMERIC_STD over a decade ago.
The specific issue is that STD_LOGIC_ARITH provides
definitions of the "=" operator for all the following
combinations of types:
UNSIGNED = UNSIGNED
UNSIGNED = SIGNED
SIGNED = UNSIGNED
SIGNED = SIGNED
If the things on the opposite sides of the "=" are
simple variables or signals, that's fine - but if they
are expressions, or literals like your "111111", there
is a type ambiguity because the literal might be either
SIGNED or UNSIGNED, and VHDL can't work out which it is.
The preferred fix is to replace STD_LOGIC_ARITH with
NUMERIC_STD. This will fix the type ambiguity issue, but
it may give you a few other compile errors because the
conversion functions' names have changed: conv_integer()
is now to_integer, and conv_unsigned() is now called
to_unsigned(). Obviously, those will be rather easy
to deal with. This is by far the most satisfactory
solution. NUMERIC_STD defines equality for
UNSIGNED=UNSIGNED and for SIGNED=SIGNED, but not
for combinations of the two - so, in your comparison,
there is only one possible interpretation of the
constant and VHDL will get it right automatically.

I can't sat that Numemric_std is a panacea. VHDL is still a tough
language to master in terms of the strong typing. It is hard to even
figure out what the true nature of the problem is in many cases. Here
is one that I am currently dealing with. I just changed a number of
slvs to unsigned and now I get this error.

if (CTPCurCmd(VER_RNG) = '1') and (DataOutReg /= CTPCurCmd(DAT_RNG))
then

---No matching overload for "/="---

DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
types were "closely related" which means I don't have to use
conversions to intermix them. I also get errors when trying to
concatenate slv with unsigned. What exactly is wrong with either of
these? I guess it doesn't know what type to make the result of a
concatenation, but the equality comparison shouldn't have that
problem.

Rick

"closely related" types only means you don't have to write a
conversion function between them, but you still have to use one. It is
invoked as the name of the type you are converting to.

if unsigned(my_slf) < my_unsigned then...

Andy
 
R

rickman

No, closely related means I can use
a cast instead of a conversion as in:

unsigned(DataOutReg) /= CTPCurCmd(DAT_RNG)

Let's look up the "/=" functions available
in the numeric_std source here:

http://www.cs.umbc.edu/help/VHDL/packages/numeric_std.vhd

function "/=" (L,R: UNSIGNED ) return BOOLEAN;
function "/=" ( L,R: SIGNED) return BOOLEAN;
function "/=" ( L: NATURAL; R: UNSIGNED) return BOOLEAN;
function "/=" ( L: INTEGER; R: SIGNED) return BOOLEAN;
function "/=" ( L: UNSIGNED; R: NATURAL) return BOOLEAN;
function "/=" ( L: SIGNED; R: INTEGER) return BOOLEAN;

For your example, a cast is needed to match the first signature.

-- Mike Treseler

I have seen to_unsigned(), unsigned() and unsigned'. I understand
that the first to are conversion and type casting respectively. What
is the third called? I expect this is only for use where a literal or
expression can be interpreted more than one way and explains to the
tool what is intended, right?

I read back a bit and see that it is a "type qualification". I think
I got all that now. So even when types are closely related, you still
have to explicitly tell the tool to change the interpretation.

I think I wish I had started with Verilog instead of VHDL. At least
now if I start coding in Verilog, it will be an informed decision.
The little Verilog I have coded was very easy to do and I did it with
*no* additional training. I just picked up a little from a book and
the rest came pretty easy.

Does Verilog support user libraries in a similar manner to VHDL?

Rick
 
M

Mike Treseler

rickman said:
I have seen to_unsigned(), unsigned() and unsigned'. I understand
that the first to are conversion and type casting respectively. What
is the third called? I expect this is only for use where a literal or
expression can be interpreted more than one way and explains to the
tool what is intended, right?

That's it.
I read back a bit and see that it is a "type qualification". I think
I got all that now. So even when types are closely related, you still
have to explicitly tell the tool to change the interpretation.

Yes, but keep in mind that I don't need *any* of these
functions if I declare my variable and constant
vectors correctly in the first place.
Here's an example of how I do this using subtypes:
http://mysite.verizon.net/miketreseler/sync_template.vhd

And don't leave home without your cheat sheets:
http://www.vhdl.org/rassp/vhdl/guidelines/vhdlqrc.pdf
http://www.vhdl.org/rassp/vhdl/guidelines/1164qrc.pdf
I think I wish I had started with Verilog instead of VHDL. At least
now if I start coding in Verilog, it will be an informed decision.

I expect that it would take longer
to learn verilog well than to learn
the vhdl numeric libraries.
If Andy were here, he would remind you
that integer ranges also work fine for synthesis
and require no libraries.
The little Verilog I have coded was very easy to do and I did it with
*no* additional training. I just picked up a little from a book and
the rest came pretty easy.

It's a rose for easy projects, but just thorns for debugging
complicated modules with signed and unsigned math.
Does Verilog support user libraries in a similar manner to VHDL?

No.


-- Mike Treseler
 
A

Andy

I have seen to_unsigned(), unsigned() and unsigned'. I understand
that the first to are conversion and type casting respectively. What
is the third called? I expect this is only for use where a literal or
expression can be interpreted more than one way and explains to the
tool what is intended, right?

I read back a bit and see that it is a "type qualification". I think
I got all that now. So even when types are closely related, you still
have to explicitly tell the tool to change the interpretation.

I think I wish I had started with Verilog instead of VHDL. At least
now if I start coding in Verilog, it will be an informed decision.
The little Verilog I have coded was very easy to do and I did it with
*no* additional training. I just picked up a little from a book and
the rest came pretty easy.

Does Verilog support user libraries in a similar manner to VHDL?

Rick

A long time ago there was a live design/coding contest between being
Verilog and VHDL to code a small module that had a few strange
requirements, but was otherwise pretty straight forward. Verilog
trounced VHDL. But if you stopped there, and assumed Verilog was
better than VHDL for most digital design, you missed the point.
Anything that can be converted from spec to synthesized gates in an
hour or two will almost necessarily be the easiest/quickest to design
in the simplest, most constrained language capable of doing that
simple job, namely verilog. Is that the basis upon which you want to
choose your development language?

To keep Mike an honest man: VHDL synthesis tools support arithmetic
for integers without additional libraries. However, bit-wise logic
operations on integers are not supported without custom libraries, and
standard ranges for integers limit data widths to 31 bits unsigned and
32 bit signed.

One more point: just try to design a fixed or floating point
arithmetic design with verilog!

Andy
 
R

rickman

A long time ago there was a live design/coding contest between being
Verilog and VHDL to code a small module that had a few strange
requirements, but was otherwise pretty straight forward. Verilog
trounced VHDL. But if you stopped there, and assumed Verilog was
better than VHDL for most digital design, you missed the point.
Anything that can be converted from spec to synthesized gates in an
hour or two will almost necessarily be the easiest/quickest to design
in the simplest, most constrained language capable of doing that
simple job, namely verilog. Is that the basis upon which you want to
choose your development language?

I recall that competition and I seem to recall that it was *very*
inconclusive. Although the Verilog teams seemed to be further along,
not one team produced working code in the time alloted. I guess this
could be a different contest though.

To keep Mike an honest man: VHDL synthesis tools support arithmetic
for integers without additional libraries. However, bit-wise logic
operations on integers are not supported without custom libraries, and
standard ranges for integers limit data widths to 31 bits unsigned and
32 bit signed.

I don't care if libraries are required for various features. I was
asking about support for user libraries in Verilog. I believe the
answer was no. Is that still valid?

One more point: just try to design a fixed or floating point
arithmetic design with verilog!

Is that a point? What was the point? Are you trying to say that
users don't design arithmetic circuits in Verilog??? I am pretty sure
that the limited work I have done in Verilog has included arithmetic.
I must be missing your point.


BTW, here is one of the reasons I am getting tried of using VHDL. I
have coded FPGAs in VHDL off and on for some 10 years. Every time I
start a new design (sometimes as long as 18 months since the last one)
I have to pick up all of my books again to remember the details and to
read my notes on the various shortcuts to efficient use. I typically
find that the shortcuts are not very short and look for new ones. The
notation is just so verbose for simple things. Here is an example.

CTPBitCnt is an unsigned.

What I mean...
CTPBitCnt <= 1;

What I have to write...
CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);

Doesn't that seem a bit wordy? I guess this example goes back to the
inability to overload the assignment operator which someone has
indicated may be changed in the next revision of the language.

Rick
 
K

KJ

notation is just so verbose for simple things.  Here is an example.

CTPBitCnt is an unsigned.

What I mean...
  CTPBitCnt <= 1;

What I have to write...
  CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);

Doesn't that seem a bit wordy?  I guess this example goes back to the
inability to overload the assignment operator which someone has
indicated may be changed in the next revision of the language.

I agree it is too wordy and also prone to error (like if you get
sloppy and type "8" instead of "CTPBitCnt'length" and then later
change the range of "CTPBitCnt")

If this were legal...

CTPBitCnt <= to_unsigned(1)

I wouldn't think it to be too wordy since it is specifying a type
conversion and having explicit type conversions is preferrable (to
me).

In the meantime one could create a procedure like the following and
put it into a package of commonly used VHDL shortcuts...

procedure set(L: out unsigned; R: in integer) is
begin
L := to_unsigned(R, L'length);
end procedure set;

which could then be used like this...
set(Test_Set, 1);

But then you'd need to overload it so you could pass signals instead
of variables...and hope that the name 'set' (or whatever you come up
with) sticks in your mind as to be clear about what it's purpose
is....sigh

Kevin Jennings
 
M

Mike Treseler

rickman said:
What I mean...
CTPBitCnt <= 1;

What I have to write...
CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);

Doesn't that seem a bit wordy?

Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.

CTPBitCnt <= x"0001";

-- Mike Treseler
 
K

KJ

Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.

He did declare it as unsigned.
    CTPBitCnt <=  x"0001";

Doesn't work though if the length of CTPBitCnt is anything other than
a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));

KJ
 
R

rickman

He did declare it as unsigned.

This works with signed, unsigned and SLV!
Doesn't work though if the length of CTPBitCnt is anything other than
a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));

Worse, I have to hard code the width of the signal which I try to
avoid. That is why I want to assign it a value from an integer and
not specify every bit in the vector. For example, all of my address
values are currently 8 bits. My customer may decide to change the
protocol to use 6 bits since that is plenty enough. I would hate to
have to go through the entire body of code changing 8 bit constants to
6 bits.

VHDL just makes life hard in some ways.

Rick
 
K

KJ

On Jun 11, 11:52 am, rickman <[email protected]> wrote:
In the meantime one could create a procedure like the following and
put it into a package of commonly used VHDL shortcuts...

procedure set(L: out unsigned; R: in integer) is
begin
  L := to_unsigned(R, L'length);
end procedure set;

which could then be used like this...
set(Test_Set, 1);

But then you'd need to overload it so you could pass signals instead
of variables...and hope that the name 'set' (or whatever you come up
with) sticks in your mind as to be clear about what it's purpose
is....sigh

Slight correction to the previous. You can't overload the 'set'
function to have one that works with signals and another that works
with variables, you'd need to have two distinctly named functions
(i.e. 'setsig' and 'setvar')...all for the lack of being able to
overload the assignment operators....

KJ
 
M

Mike Treseler

rickman said:
This works with signed, unsigned and SLV!

Yes sorry, I didn't read your post carefully.

That is annoying,
and that is why I declare a subtype for vector constants:

subtype vec_t is unsigned(vec_len-1 downto 0);

constant vec_zero_c : vec_t := (others => '0');
constant vec_one_c : vec_t := vec_init_c + 1;
constant vec_load_c : vec_t := vec_init_c + 42;

CTPBitCnt <= vec_one_c;

VHDL just makes life hard in some ways.

And easy in other ways ;)

-- Mike Treseler
 
K

KJ

Jim Lewis said:
Jonathan just submitted a language feature request WRT to overloading
assignment, however, the standard is already at the balloting point so
it will not make the 2008 revision.

What has been added is a decimal notation for bit string literals
and a sizing indication.

signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
. . .
-- Representing 1 as a 15 bit object in either hex or decimal

CTPBitCnt <= 15D"1" ; -- Decimal notation
CTPBitCnt <= 15X"1" ; -- Hex notation

The type of syntax only a mother could love. Let's compare the approaches
A: CTPBitCnt <= 1;
B: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
C: CTPBitCnt <= to_unsigned(1);
D: set(CTPBitCnt, "<=", 1)
E: CTPBitCnt <= CTPBitCnt'lengthD"1" ; or CTPBitCnt <= CTPBitCnt'lengthX"1"
??
F: CTPBitCnt <= 8D"1" ; or CTPBitCnt <= 8X"1"

'A' is illegal, but represents what is intended. Violates strong type
checking which is a 'good' thing about VHDL (in my opinion).

'B' has been valid since VHDL'93 but is overly wordy and prone to error if
you inadvertnatly take the 'length of something other than the left side of
the statement. Has an issue that you would need separately names procedures
if the thing being assigned to is a signal or a variable. Jim, is there
anything on the table about being able to overload procedures when
parameters differ by class so that a single name could be used? If not,
maybe I'll submit it for consideration.

'C' is illegal, but represents what is intended and conforms nicely with the
strong type checking of VHDL. Requires acceptance of overloading of the
"<=" and ":=" operators as Jonathon has proposed.

'D' is valid VHDL where 'set' is a procedure that implements the syntax of
'B'. No chance for the possible user error mentioned above for 'B'. The
second parameter "<=" is not used in the procedure it is there simply to aid
the user of the procedure.

'E' may be valid VHDL'2008 (not sure if the bit width specification needs to
be a hard coded can be replaced with something that will be maintainable if
'CTPBitCnt' is subject to size changes ....ummm, kind of at a loss to say
anything that I like about that syntax.
'F' is valid VHDL'2008 but again can't say what there may be to like about
it from the perspective of someone looking at the code or writing it.

If I were to rank them by personal preference the ordering would be
1. C (clear and consise)
2. D (kinda kludgy but does the trick)
3. B (it's legal after all)
4. A (I'd almost rather have less strong type checking then 'E' or 'F').
5. E or F....the designer's intent has been completely lost.....to me
BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
if your vendors were looking out for your interests, they would
have already should implemented these.

Make sure to submit these as bug/enhancement requests. This is important
as this is what lets them know the VHDL community wants the new features.

I'll wait for one I like to see first.

Kevin Jennings
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top