Design Notation VHDL or Verilog?

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. &#4294967295;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

Andy <jonesandy@comcast.net> writes:

> On Jan 31, 2:00&nbsp;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. 

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&sup1;.


//Petter
&sup1;http://www.deepchip.com/items/0494-07.html

-- 
.sig removed by request. 

Petter Gustad <newsmailcomp6@gustad.com> wrote:

>Andy <jonesandy@comcast.net> writes:
>
>> On Jan 31, 2:00&nbsp;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=.)
--------------------------------------------------------------

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. 

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=.)
--------------------------------------------------------------

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

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.

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

On Feb 3, 4:37=A0am, 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

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=.)
--------------------------------------------------------------