Design Notation VHDL or Verilog?

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)

The suggestion, which could be wrong, was that if scaled fixed point
is useful in an HDL, it should also be useful in non-HDL applications.

The designers of PL/I believed that it would be, but designers of
other languages don't seem to have believed in it enough to include.
Personally, I liked PL/I 40 years ago, and believe that it should
have done better than it did, and scaled fixed point was a feature
that I liked to use.

I have no idea what bearing a forty year old computer language has to
do with this issue.

As far as I know, currently if something can be done either with
an FPGA or a small microcontroller, or even DSP processor,
the choice is often for the processor. With the price of smaller
FPGAs coming down, that might change, but also there are more
people who know how to program such processors than HDL design.

Given that, I would expect some overlap between FPGA/HDL
applications and processor/software applications, depending
on the speed required at the time. Some applications might
initially be developed in software, debugged and tested, before
moving to an FPGA/HDL implementation.

Maybe the question isn't whether scaled fixed point is useful
in HDL, but why isn't it useful, enough that people ask for
it in an HLL, in software! Why no scaled fixed point datatype
in C or Java?

(snip)

Software is implemented on programmable hardware and for
the most part is designed for the most common platforms and does not
do a good job of utilizing unusual hardware effectively.  I don't see
how fixed point arithmetic would be of any value on conventional
integer oriented hardware.

Well, the designers of conventional hardware might argue that they
support scaled fixed point as long as you keep track of the radix
point yourself. It is, then, up to software to make it easier for
programmers by helping them keep track of the radix point.

I believe that in addition to PL/I that there are some other less
commonly used languages, maybe ADA, that support it.

(snip)

Again, I don't know why you are dragging high level languages into
this. What HLLs do has nothing to do with the utility of features of
HDLs.

As I said above, if for no other reason, then to test and debug
the applications that will later be implemented in scaled fixed
point VHDL.

Well, there are two applications that D. Knuth believes should
always be done in fixed point: finance and typesetting. As we know,
it is also often used in DSP, but Knuth likely didn't (doesn't)
do much DSP work. (It was some years ago he said that.)

(snip)

In the past, the tools would not synthesize division with a
non-constant divisor. If you generate the division logic yourself,
you can add in any pipelining needed. (I did one once, and not for
a systolic array.) With the hardware block multipliers in many FPGAs,
it may not be necessary to generate pipelined multipliers, but many
will want pipelined divide.

Oh, I see why you are talking about pipelining now. I don't think the
package provides pipelining. But that does not eliminate the utility
of the package. It may not be useful to you if it isn't pipelined,
but many other apps can use non-pipelined arithmetic just fine.

Maybe so. In the past, the cost and size kept people away from
using FPGAs when conventional processors would do. With the lower
prices of smaller (but not so small) FPGAs that might change.

(snip)

Yes, multiply generates a wide product, and most processors with
a multiply instruction supply all the bits. But most HLLs don't
provide a way to get those bits. For scaled fixed point, you
shift as appropriate to get the needed product bits out.

I have no interest in what HLLs do. I use HDLs to design hardware and
I determine how the HDL shifts or rounds or whatever it is that I
need.

Yes. If I determine the shifts and rounds, then I don't need VHDL
to do it for me. I can do it using integer arithmetic in C,
(easier if I can get all the product bits from multiply), and
in HDL.

(snip)

The point I didn't make very well was that floating point is still
not very usable in FPGA designs, as it is still too big. If a
design can be pipelined, then it has a chance to be fast enough
to be useful.

Whether floating point is too big depends on your app. Pipelining
does not reduce the size of a design and can only be used in apps that
can tolerate the pipeline latency. You speak as if your needs are the
same as everyone else's.

Well, the desire to run almost any computational problem faster
certainly isn't unique to me. But yes, I know the problems that
I work on better than those that I don't. But if you can't process
data faster than a medium sized conventional processor, there
won't be much demand, unless the cost (including amortized
development) is less.

Historically, FPGA based hardware to accelerate scientific
programming has not done very well in the marketplace. People
keep trying, though, and I would like to see someone succeed.

Scientific programming is not the only app for FPGAs and fixed or
floating point arithmetic. Fixed point arithmetic is widely used in
signal processing apps and floating point is often used when fixed
point is too limiting.

True, but for floating point number crunching, in the teraflop
or petaflop scale, it is scientific programming. With the size
and speed of floating point in an FPGA, one could instead
use really wide fixed point. Given the choice between 32 bit
floating point and 64 bit or more fixed point for DSP applications,
which one is more useful?

In general, fixed point is a better choice for quantities
with an absolute (not size dependent) uncertainty, floating
point for quantities with a relative uncertainty.

-- glen

 

[Petter Gustad]

Andy <jonesandy@comcast.net> writes:

On Jan 31, 2:00 pm, Petter Gustad <newsmailco...@gustad.com> wrote:
Andy <jonesa...@comcast.net> writes:
there is negligible advantage to using VHDL over verilog. It is at
higher levels of abstraction, where design productivity is maximized,
that VHDL shines.

It depends of the Verilog version in question and the type of design.
SystemVerilog has a much higher level of abstraction when it comes to
verification and testbench code. Especially when using libraries like
UVM etc.

//Petter

--
.sig removed by request.

AFAIK, the synthesizable subset of SV is pretty much plane old
verilog, with all its warts.

There are several nice features like interfaces (which are
bi-directional unlike record bundles in VHDL). There's also enum's,
always_comb, always_ff, always_latch to tell the synthesis tool what
you're trying to do, $left, $right, etc. similar to 'left, 'right in
VHDL.

For verification, SV is indeed really nice. However, a new open source
VHDL Verification Methodology (VVM) library of VHDL packages has
emerged that provides VHDL with some of the capabilities of SV with
OVM/UVM.

I took a link at some of the links posted here previously, it looks
nice and it's an improvement. But as far as I could tell it lacked
polymorphism and inheritance. However, I have to study VVM further.

//Petter
--
..sig removed by request.

 

[Petter Gustad]

Andy <jonesandy@comcast.net> writes:

know, and good for the industry. Which tools support these features (I
assume at least Synplify)? As soon as someone standardizes a library

Quite a few tools actually. DC, Synplify, and Quartus has pretty good
SV support. XST does not, but hopefully that will change with Rodinš.


//Petter
šhttp://www.deepchip.com/items/0494-07.html

--
..sig removed by request.

 

[Nico Coesel]

Petter Gustad <newsmailcomp6@gustad.com> wrote:

Andy <jonesandy@comcast.net> writes:

On Jan 31, 2:00 pm, Petter Gustad <newsmailco...@gustad.com> wrote:
Andy <jonesa...@comcast.net> writes:
there is negligible advantage to using VHDL over verilog. It is at
higher levels of abstraction, where design productivity is maximized,
that VHDL shines.

It depends of the Verilog version in question and the type of design.
SystemVerilog has a much higher level of abstraction when it comes to
verification and testbench code. Especially when using libraries like
UVM etc.

//Petter

--
.sig removed by request.

AFAIK, the synthesizable subset of SV is pretty much plane old
verilog, with all its warts.

There are several nice features like interfaces (which are
bi-directional unlike record bundles in VHDL). There's also enum's,

Record bundles can be bi-directional in VHDL!

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Petter Gustad]

nico@puntnl.niks (Nico Coesel) writes:

There are several nice features like interfaces (which are
bi-directional unlike record bundles in VHDL). There's also enum's,

Record bundles can be bi-directional in VHDL!

That's great news as I've always used one record type as input and
another one as output. Care to share some examples? And how do you
swap them like you do with modports in SV.

//Petter
--
..sig removed by request.

 

[Nico Coesel]

Petter Gustad <newsmailcomp6@gustad.com> wrote:

nico@puntnl.niks (Nico Coesel) writes:

There are several nice features like interfaces (which are
bi-directional unlike record bundles in VHDL). There's also enum's,

Record bundles can be bi-directional in VHDL!

That's great news as I've always used one record type as input and
another one as output.

Just declare the port as inout. Its simple as that.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Gabor]

glen herrmannsfeldt wrote:
[snip]

As far as I know, currently if something can be done either with
an FPGA or a small microcontroller, or even DSP processor,
the choice is often for the processor. With the price of smaller
FPGAs coming down, that might change, but also there are more
people who know how to program such processors than HDL design.

Given that, I would expect some overlap between FPGA/HDL
applications and processor/software applications, depending
on the speed required at the time. Some applications might
initially be developed in software, debugged and tested, before
moving to an FPGA/HDL implementation.

Maybe the question isn't whether scaled fixed point is useful
in HDL, but why isn't it useful, enough that people ask for
it in an HLL, in software! Why no scaled fixed point datatype
in C or Java?

You may as well ask why we're not using slide rules instead
of calculators. Once you have floating point arithmetic
with reasonable performance, fixed-point becomes of little
value. If you really want to keep track of your binary point
instead of letting the floating point package do it for you,
you can always use integer types. Anyone who has worked on
fixed point FFT logic knows just what a pain it can be to
keep track of scaling. I don't know many C or Java programmers
willing to take on that task. At my company, the only person
who ever wrote fixed point code for processing had a background
in microcoding and his whole job was just to create accellerated
image processing libraries.

Obviously for hardware floating point is a huge resource hog,
but when you're using a microprocessor that already has it
built in there's no big incentive not to use it.

-- Gabor

 

[Andy]

On Feb 3, 5:43 am, n...@puntnl.niks (Nico Coesel) wrote:

Record bundles can be bi-directional in VHDL!

That's the problem; every element of a VHDL bidirectional record port
is bidirectional. You have to use resolved types for each element, and
remember to assign benign driven values to elements you want to be
input only. It can be done, but it gets ugly.

Sometimes (especially testbenches) it is worth the work, but it would
be worth even more to be able to define custom record modes for record
port types (e.g. master, slave, observer, etc modes for a record port
representing a bus interface, each defining different individual in/
out/inout/etc modes on individual record elements).

Andy

 

[Andy]

On Feb 3, 4:37 am, Petter Gustad <newsmailco...@gustad.com> wrote:

Andy <jonesa...@comcast.net> writes:
For verification, SV is indeed really nice. However, a new open source
VHDL Verification Methodology (VVM) library of VHDL packages has
emerged that provides VHDL with some of the capabilities of SV with
OVM/UVM.

I took a link at some of the links posted here previously, it looks
nice and it's an improvement. But as far as I could tell it lacked
polymorphism and inheritance.

Actually, being built around VHDL protected types, it has some amount
of both. Not nearly as clean or capable as SV though.

Andy

 

[Nico Coesel]

Andy <jonesandy@comcast.net> wrote:

On Feb 3, 5:43=A0am, n...@puntnl.niks (Nico Coesel) wrote:
Record bundles can be bi-directional in VHDL!

That's the problem; every element of a VHDL bidirectional record port
is bidirectional. You have to use resolved types for each element, and
remember to assign benign driven values to elements you want to be
input only. It can be done, but it gets ugly.

I never had that problem when synthesizing for Xilinx devices.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Andy]

On Feb 7, 3:14 pm, n...@puntnl.niks (Nico Coesel) wrote:

I never had that problem when synthesizing for Xilinx devices.

Did you simulate your RTL using bidirectional ports? That's where the
default driver problem arises, on inout ports that are only read (from
the inside).

Synthesis can take a lot of liberty with your RTL description because
of the static nature of the analysis of the code, and the fact that
unknowns are don't cares in synthesis, which means the synthesis tool
can do as it pleases, which is usually what pleases the most customers
most of the time.

Andy

 

[Nico Coesel]

Andy <jonesandy@comcast.net> wrote:

On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
I never had that problem when synthesizing for Xilinx devices.

Did you simulate your RTL using bidirectional ports? That's where the
default driver problem arises, on inout ports that are only read (from
the inside).

I didn't simulate that particular code. It was back in the days that
simulation software wasn't available if you wanted to keep your arms
and legs.

Synthesis can take a lot of liberty with your RTL description because
of the static nature of the analysis of the code, and the fact that
unknowns are don't cares in synthesis, which means the synthesis tool
can do as it pleases, which is usually what pleases the most customers
most of the time.

AFAIK: for RTL to synthesize each signal needs one driver. Even if it
would drive the signal tristate. It probably depends on the tools. My
experience is limited to Xilinx.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Andy]

On Feb 9, 3:32 pm, n...@puntnl.niks (Nico Coesel) wrote:

Andy <jonesa...@comcast.net> wrote:
On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
I never had that problem when synthesizing for Xilinx devices.

Did you simulate your RTL using bidirectional ports? That's where the
default driver problem arises, on inout ports that are only read (from
the inside).

I didn't simulate that particular code. It was back in the days that
simulation software wasn't available if you wanted to keep your arms
and legs.

Synthesis can take a lot of liberty with your RTL description because
of the static nature of the analysis of the code, and the fact that
unknowns are don't cares in synthesis, which means the synthesis tool
can do as it pleases, which is usually what pleases the most customers
most of the time.

AFAIK: for RTL to synthesize each signal needs one driver. Even if it
would drive the signal tristate. It probably depends on the tools. My
experience is limited to Xilinx.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Most synthesis tools will convert multiple tri-state drivers on a
signal into multiplexers, since most FPGAs do not support internal tri-
state busses any more. They assume that the various tri-state enables
are mutually exlusive (how else would the tri-state bus have worked?),
so a prioritlyless multiplexer is constructed. This can be a handy way
of specifying a distributed priorityless mux.

Most synthesis tools will convert default 'U' drivers to
"undriven" (nothing), which is different behavior from the SL
resolution function in simulation (they issue a warning about that).

Andy

 

[Petter Gustad]

nico@puntnl.niks (Nico Coesel) writes:

Petter Gustad <newsmailcomp6@gustad.com> wrote:

nico@puntnl.niks (Nico Coesel) writes:

There are several nice features like interfaces (which are
bi-directional unlike record bundles in VHDL). There's also enum's,

Record bundles can be bi-directional in VHDL!

That's great news as I've always used one record type as input and
another one as output.

Just declare the port as inout. Its simple as that.

That might cause some problems. I've seen some tool which did not like
inouts other than at the top level (can't remember which, it might
have been some LSI or IBM tool). This is many years ago and might not
be the case in more recent versions. Also you'll miss the compile
static check of only one driving the signal.

//Petter


--
..sig removed by request.

 

[Nico Coesel]

Petter Gustad <newsmailcomp6@gustad.com> wrote:

nico@puntnl.niks (Nico Coesel) writes:

Petter Gustad <newsmailcomp6@gustad.com> wrote:

nico@puntnl.niks (Nico Coesel) writes:

There are several nice features like interfaces (which are
bi-directional unlike record bundles in VHDL). There's also enum's,

Record bundles can be bi-directional in VHDL!

That's great news as I've always used one record type as input and
another one as output.

Just declare the port as inout. Its simple as that.

be the case in more recent versions. Also you'll miss the compile
static check of only one driving the signal.

The synthesizer will most likely complain about that.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Petter Gustad]

nico@puntnl.niks (Nico Coesel) writes:

be the case in more recent versions. Also you'll miss the compile
static check of only one driving the signal.

The synthesizer will most likely complain about that.

I was thinking about simulator compile checks. Which typically can be
checked quickly, e.g. can be done from the editor and prior to
revision control commits etc. Synthesis usually takes longer.

//Petter

--
..sig removed by request.