HDL topics

[zygot]

A recent interchange prompted an odd, but not necessarily useless discussion about VHDL type integer. Always the optimistic pessimist, I decided to open a topic where questions about HDL usage could be discussed.

[edit] I should add that I don't a favorite HDL. I use whatever is appropriate, convenient, or gets the job done with the least amount of fuss. If I have the time, I'll learn something new about how to use an HDL that isn't my preference. 

This thread isn't meant to be a place for MMA matches; just a place to discuss issues relevant to any HDL as it relates to synthesis or simulation using popular FPGA vendor tools. That probably means Quartus or Viviado as there aren't a lot of free tool versions available.

Edited July 28, 2023 by zygot

[D@n]

Sounds like the editor wars.

From my humble position, I'd just note there's more open source support for Verilog than for VHDL.

Dan

[zygot]

So, what's the deal with VHDL type integer? Can I use type integer with a range that's greater than signed 32-bits for logic synthesis?

In the interests of clarity and precision, here's one answer.

For any programmable logic vendor tools that I've used, type integer is limited to 32 bits ( signed ). That means that it can't hold a 32-bit unsigned value.

If you want to know what your version of Vivado support for VHDL, there's a User Guide for that: UG901.

It states:"The integer type is a predefined VHDL type. Vivado synthesis implements an integer on 32 bits by default. For a more compact implementation, define the exact range of applicable values, where type MSB is range 8 to 15. "

Integer, signed and unsigned are all pre-defined VHDL types. In general they are irrelevant to logic synthesis, and to a restricted usage in simulation. For synthesis the I.E.E.E. added the library IEEE. Within this libraries are subtypes like numeric, std_logic_1164, etc. It's these VHDL types that are relevant to logic design, and logic simulation. Even though VHDL was designed as a simulation language, the effort to use it as a way to describe logic designs for programmable logic synthesis came more recently.

If you are interested, Vivado installs the relevant VHDL source files that it uses for synthesis in the install folder under /data/vhdl. There are similar source files for Verilog and other supported HDL languages.

According to Peter Ashenden's 'The Designer's Guide to VHDL' the pre-defined VHDL type integer can be larger than (-2^32)+1 to (2^31)-1, but specific implementations do not have to.

I'd be happy to have anyone who is unhappy with this answer provide a function.vhd that uses 64-bit integer and can be synthesized and simulated with either Quartus or VIvado tools and and testbench_function.vhd that can be simulated to test function.vhd. Put your money where you mouth is...

@reddish Here's your chance to be precise.

Edited July 27, 2023 by zygot

[zygot]

16 minutes ago, D@n said:

From my humble position, I'd just note there's more open source support for Verilog than for VHDL.

I'd just say that these days strongly types languages like ADA, VHDL etc just aren't that popular.

 

20 minutes ago, D@n said:

Sounds like the editor wars.

Well the exchange that prompted this thread seemed to me to be more like a sports team rivalry. No logic there. People who get their favorite NFL team's logo tatooed onto a prominent part of their body ( I know a few ) love their team even if they are perennially losers. On the other hand fans who love a team that's a perennial winner hate them when the magic goes away. Same with editors, sports, and a lot of other stupid arguments usually done in a bar and having little to do with what's being discussed.

But there really are useful discussions about HDLs that might be made.... (that's the optimist talking...)

[Guest]

> Integer, signed and unsigned are all pre-defined VHDL types.

This is incorrect. Only "integer" is a pre-defined VHDL type. "signed" and "unsigned" are not predefined VHDL types. They are subtypes implemented in the standard library (thus, unlike the integer type, only available after a use clause that imports them) with extended semantics relative to a bit vector type. Specifically, these subtypes are defined as follows in terms of the language primitives:

type STD_ULOGIC is ( 'U', 'X', '0', '1', 'Z', 'W', 'L', 'H', '-' );

type UNRESOLVED_UNSIGNED is array (NATURAL range <>) of STD_ULOGIC;
type UNRESOLVED_SIGNED is array (NATURAL range <>) of STD_ULOGIC;

subtype UNSIGNED is (resolved) UNRESOLVED_UNSIGNED;
subtype SIGNED is (resolved) UNRESOLVED_SIGNED;

And then, of course, a lot of functionality is added to be able to do arithmetic with them.

> In general they are irrelevant to logic synthesis, and to a restricted usage in simulation.

It is unclear what makes you say that. Both the primitive integer type, and the library-defined signed, and unsigned types work fine both for synthesis and simulation in the Vivado toolset and VHDL simulators I've worked with.

> Put your money where you mouth is...

Now you're just being an ass. I never made the claim that any vendor tool supported a 64-bit native integer. It was instead you who made the incorrect claim that VHDL was restricted to 32-bit integers. The statement "vendor VHDL tools exist that implement a 64 bit integers" is not implied by pointing out that the assertion that VHDL (the language) is limited to 32-bit integers is wrong. I'd urge you to refrain from these rhetorical antics because I have little patience for that.

The proper way to represent n-bit signals, variables, or expressions in your design, in case you need arithmetic, is to use the 'signed' and 'unsigned' types provided by the standard library; that's what they are for (unlike the integer type and its subtypes, the intended use of which is loop variables, array indexes, and so on, for which the mandated minimum range corresponding approximately to 32-bit signed integers is plenty). You can have 64-bit integer semantics using signed and unsigned, or 1000-bit integers if you'd want them, and they work fine in Vivado and Quartus. You can try for yourself if you don't believe it.

Edited July 28, 2023 by reddish

[zygot]

7 hours ago, reddish said:

> Integer, signed and unsigned are all pre-defined VHDL types.

This is incorrect. Only "integer" is a pre-defined VHDL type. "signed" and "unsigned" are not predefined VHDL types.

Yes, this was incorrect. VHDL, absent IEEE libraries, have integer literal and real literal types. Natural and positive are sub-types of integer literal. All integer literal values and sub-types can be limited to signed 32-bit values. You still haven't presented us with any programmable logic vendor tool that supports integer literal values greater than 32-bit signed values.

Any language that allows for integers to be limited to 32-bit signed values is dated to my mind. Unfortunately, this is what every programmable logic vendor that I know of does.

So, what's the point? Well, for logic simulation it's nice to be able to print larger std_ulogic array sub-types to a file as the simulation progresses. VHDL has provisions for character literal so that you can do this. Unfortunately, because VHDL is a strongly types language there is no way to convert a 32-bit ieee.std_logic_unsigned std_logic_vector, or larger to something that lets you print it's contents to a file. Perhaps I am wrong about that as well.

Most people who want to design logic that can be synthesized and implemented in an FPGA really don't care about features of an HDL that either they can't use or makes their work harder to do. Perhaps that's why Verilog is more popular. Productivity and simple is what people are drawn to. Perhaps this is why C is more popular than Pascal among software developers.

 

Edited July 28, 2023 by zygot

[zygot]

6 hours ago, reddish said:

I never made the claim that any vendor tool supported a 64-bit native integer. It was instead you who made the incorrect claim that VHDL was restricted to 32-bit integers. The statement "vendor VHDL tools exist that implement a 64 bit integers" is not implied by pointing out that the assertion that VHDL (the language) is limited to 32-bit integers is wrong. I'd urge you to refrain from these rhetorical antics because I have little patience for that.

Wow, you really are context challenged aren't you. 

[Guest]

> You still haven't presented us with any programmable logic vendor tool that supports integer literal values greater than 32-bit signed values.

Nor will I, as I have not claimed that they exist, and you know that by now. Also, a very nice goalpost-shift to "integer literal values" there: again a nasty if somewhat obvious rhetorical sleight-of-hand.

Since you're being deliberately obtuse and non-constructive, I'll bail out of this discussion; I have a pretty low tolerance for that kind of behavior.

[zygot]

2 hours ago, reddish said:

I'll bail out of this discussion

Great! I was trying to have a productive discussion. I can only speculate as to what you've been trying to do. Most human communication depends heavily on context in order to understand what is being said. Some people have difficulty with context. Some people just want to scream and brawl and talk about imaginary assertions that no one is making. Evidently, you can't have a productive discussion with some people...

Moving on. In the sources that I've published in this forum there is at least one instance where I show how to log the state of std_logic_vector signals to a file from the Vivado simulator. Aside from breaking things like library ieee : numeric : unsigned into to slices that are 31 bits or shorter. The testbench code that I've presented can't support printing values of ieee sub-types than exceed the range of integer as supported by FPGA or Simulator tools.

Anyone care to solve the puzzle with a simple source file that can be synthesized, and a simple testbench that can be simulated in Vivado ISIM and writes the state of a 36-bit unsigned std_logic_vector ( any ieee variant ) to a file during simulation? It would be useful to use an enable to limit printing to a manageable level.

I've seen how trivial this is to do in System Verilog.     

Edited July 28, 2023 by zygot

[zygot]

5 hours ago, Ben Jonson said:

Keeping the conversation respectful and collaborative will likely encourage more engagement.

I agree. Not always possible. So far this thread is pretty disappointing in that regard.

Even though the HDL design flow seems to be getting depreciated by current versions of the tools, I'm pretty sure that there are plenty of people using it and interested in, as you say, "practical solutions" to issues that they face. More importantly, people just starting out might be informed by a healthy discussion.

Interestingly, after all of the posts have been made, no one is suggesting that, in the context of FPGA development, VHDL supports integers larger than signed 32-bit or positive integers larger than 32-bit. As to whether this is an indication that VHDL 2008 hasn't been updated with the needs of current users; that's always going to be merely opinion. On the other hand, people who really do want to know if learning Verilog or System Verilog or VHDL is where they want to start might find a rational discussion enlightening.

Honestly, my only intention for posting on a website like this is to throw some light, rather than shade, on topics relevant to people interested in learning how to use programmable logic. Not everyone who comments on my opinions share this view.

Edited August 2, 2023 by zygot

[zygot]

Most of the time when I read content on a site like the Digilent Forums, my browser has most scripting blocked. Most people are aware of the cat and mouse game involved in monetizing the internet as we know it.

Unfortunately, some websites are not completely friendly places to visit. For the this one, unfortunately, posts are presented either in an order that reflects how conversations evolve over time or something else that is loosely referred to as "by vote" I don't know what by vote means, particularly when a thread has no "votes". What I do know is that it's possible to influence how people understand what it is that they are reading by changing the context. It might be innocent.. it might not be.

I always choose to read threads having a lot of posts, especially where there is some back and forth, in chronological order as I believe that it pushes comprehension toward being more informative. Unfortunately, for Digilent's Forums posts are not presented by default in chronological order; in fact in some browsers with scripting blocked you can only see posts is the other format... whatever that is supposed to be doing.

Edited August 2, 2023 by zygot

[JColvin]

Off topic to the purpose of this thread, but regrettably, I have never been able to find a setting to force the Forum to present the replies on an individual thread in chronological order by default. I've also asked Invision Community (who makes the software this Forum is hosted on) about adding/changing this a couple of different times over the years, but to no avail.

[zygot]

6 hours ago, JColvin said:

Off topic to the purpose of this thread

I disagree given the odd interchange on this thread and the one that precipitated it. But I understand why you might disagree with me. The comment by @Ben Jonsonreminded me of that sad episode.

Should I put it into a new thread? I don't see a way to delete this one or move it.

[JColvin]

Sorry, I had meant that my post that I had then proceeded to type was off topic to the thread at large; I did not have an objection to how the thread had progressed conversation wise.