Ask a question - edaboard.com
elektroda.net NewsGroups Forum Index - FPGA - Design Notation VHDL or Verilog?
Goto page Previous 1, 2, 3 Next
Mark Curry
Guest
Guest
Wed Feb 01, 2012 7:38 pm
In article <5a603ea6-876d-4f20-a35f-79dcfe6ebd1e_at_h3g2000yqe.googlegroups.com>,
Andy <jonesandy_at_comcast.net> wrote:
Quote:
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.
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.
Nope. SV synthesis is quite powerful. Arrays, and structs are first class
citizens in SV and can be members of ports. Further most tools handle
interfaces now pretty well in synthesis. There's quite a benefit to using
these in your RTL.
Trying to resist making this a language war, but I see little advantage
one or the other with regard to a "higher level of abstraction". You can
probably achieve the same with either language.
--Mark
Kim Enkovaara
Guest
Guest
Thu Feb 02, 2012 8:03 am
On 1.2.2012 17:20, glen herrmannsfeldt wrote:
Quote:
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.
is useful in an HDL, it should also be useful in non-HDL applications.
It is very useful in some applications, for example in DSP processing.
There are DSP processors that support fixed point arithmetic. Also many
"fixed" FPGA based DSP algorithms use different resolution fixed point
numbers all around. Standard package to help that kind of design is
very welcome. Previously they have been proprietary packages.
Quote:
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.
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.
Floating point might be too heavy in many applications, but on the
other hand if the number range and operators are limited to what is
needed it is not that big anymore, when comparing to the leading edge
FPGA sizes. For example leading edge FPGA can support ~2000 single
precision floating point multipliers.
Quote:
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.
programming has not done very well in the marketplace. People
keep trying, though, and I would like to see someone succeed.
You are fixed to quite narrow band of FPGA applications. FPGAs
are almost everywhere, for example they are very popular in mobile
network basestations. And also telecom equipment use some forms of
floating/fixed point arithmetic often in policing and shaping
for example.
--Kim
rickman
Guest
Guest
Thu Feb 02, 2012 9:59 am
On Feb 1, 10:20 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
Quote:
rickman <gnu...@gmail.com> wrote:
(snip, I wrote)
If it is useful in ASIC/FPGA designs, wouldn't it also be even more
useful in software running on commonly (or not so commonly) available
processors? Yet none have bothered to implement it.
It could be done in software, but none of the popular languages
have any support for fixed point non-integer arithmetic.
It was one of the fun things I did in PL/I so many years ago, though.
I don't really follow your reasoning here. The idea of the fixed
point package is to allow a user to work with fixed point values in
VHDL without having to manually deal with all the details. You seem
to be saying that fixed point arithmetic is of no value because it is
not implemented in software. I don't see how software has anything to
do with it.
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.
(snip, I wrote)
If it is useful in ASIC/FPGA designs, wouldn't it also be even more
useful in software running on commonly (or not so commonly) available
processors? Yet none have bothered to implement it.
It could be done in software, but none of the popular languages
have any support for fixed point non-integer arithmetic.
It was one of the fun things I did in PL/I so many years ago, though.
I don't really follow your reasoning here. The idea of the fixed
point package is to allow a user to work with fixed point values in
VHDL without having to manually deal with all the details. You seem
to be saying that fixed point arithmetic is of no value because it is
not implemented in software. I don't see how software has anything to
do with it.
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.
Quote:
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.
It can be done in languages like Pascal and C, TeX and Metafont do it.
Multiplication is complicated, though, because most HLL's don't supply
the high half of the product in multiply, or allow a double length
dividend in division. Knuth wrote the Pascal routines for TeX and MF
to do it, and suggests that implementations rewrite them in assembler
for higher performance.
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.
It can be done in languages like Pascal and C, TeX and Metafont do it.
Multiplication is complicated, though, because most HLL's don't supply
the high half of the product in multiply, or allow a double length
dividend in division. Knuth wrote the Pascal routines for TeX and MF
to do it, and suggests that implementations rewrite them in assembler
for higher performance.
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.
Quote:
Yes you can do fixed point with different positions of the radix
point, PL/I and a small number of other languages do, but on hardware
that doesn't keep track of the radix point.
You seem to be thinking only of CPU designs. HDL is used for a lot
more than CPU designs.
Well, more than CPU designs, I work on systolic arrays, but even
there so, it doesn't seem likely to help much. Will it generate
pipelined arithmetic units? Of all the things that I have to think
about in logic design, the position of the binary point is one of
the smallest.
Asking about pipelining with fixed point numbers is like asking if
boxes help your car. Sure, if you want to carry oranges in a car you
can use boxes, but you don't have to. If your systolic arrays use
fixed point arithmetic then the fixed point package will help your
systolic arrays. If you don't care about the precision of your
calculations then don't bother using the fixed point package.
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.
point, PL/I and a small number of other languages do, but on hardware
that doesn't keep track of the radix point.
You seem to be thinking only of CPU designs. HDL is used for a lot
more than CPU designs.
Well, more than CPU designs, I work on systolic arrays, but even
there so, it doesn't seem likely to help much. Will it generate
pipelined arithmetic units? Of all the things that I have to think
about in logic design, the position of the binary point is one of
the smallest.
Asking about pipelining with fixed point numbers is like asking if
boxes help your car. Sure, if you want to carry oranges in a car you
can use boxes, but you don't have to. If your systolic arrays use
fixed point arithmetic then the fixed point package will help your
systolic arrays. If you don't care about the precision of your
calculations then don't bother using the fixed point package.
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.
Quote:
And I don't expect the processor to help me figure out which
ones those are.
What processor? You have lost me here. A multiply provides a result
with as many bits as the sum of the bits in the inputs. But this many
bits are seldom needed. The fixed point package makes it a little
easier to work with the variety of formats that typically are used in
a case like this. No, the package does not figure out what you want
to do. You have to know that, but it does help hide some of the
details.
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.
ones those are.
What processor? You have lost me here. A multiply provides a result
with as many bits as the sum of the bits in the inputs. But this many
bits are seldom needed. The fixed point package makes it a little
easier to work with the variety of formats that typically are used in
a case like this. No, the package does not figure out what you want
to do. You have to know that, but it does help hide some of the
details.
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.
Quote:
Similarly, VHDL also has a floating point package that handles
arbitrary sizes of data and exponent.
And that is synthesizable by anyone?
I haven't looked at the floating point package, but if it is described
in terms of basic operators in VHDL it should be synthesizable in
every tool. That is the point of overloading. You can define a
multiply operator for real data in terms of the basic building blocks
and this is now a part of the language. VHDL is extensible that way.
Again, does it synthesize pipelined arithmetic units? If not, then
they aren't much use to anything I would work on. If I do it in
an FPGA that is because normal processors aren't fast enough.
But the big problem with floating point is that it takes too much logic.
The barrel shifter for pre/post normalization for an adder is huge.
(The actual addition, not so huge.)
Nope, the fixed point package does not design pipelines, it isn't a
pipeline package. Yup, the barrel shifter is as large as a
multiplier. So what is your point? The purpose of the package is to
allow you to design floating point arithmetic without designing all
the details of the logic. It isn't going to reduce the size of the
logic.
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.
arbitrary sizes of data and exponent.
And that is synthesizable by anyone?
I haven't looked at the floating point package, but if it is described
in terms of basic operators in VHDL it should be synthesizable in
every tool. That is the point of overloading. You can define a
multiply operator for real data in terms of the basic building blocks
and this is now a part of the language. VHDL is extensible that way.
Again, does it synthesize pipelined arithmetic units? If not, then
they aren't much use to anything I would work on. If I do it in
an FPGA that is because normal processors aren't fast enough.
But the big problem with floating point is that it takes too much logic.
The barrel shifter for pre/post normalization for an adder is huge.
(The actual addition, not so huge.)
Nope, the fixed point package does not design pipelines, it isn't a
pipeline package. Yup, the barrel shifter is as large as a
multiplier. So what is your point? The purpose of the package is to
allow you to design floating point arithmetic without designing all
the details of the logic. It isn't going to reduce the size of the
logic.
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.
Quote:
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.
-- glen
programming has not done very well in the marketplace. People
keep trying, though, and I would like to see someone succeed.
-- glen
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.
Rick
Andy
Guest
Guest
Thu Feb 02, 2012 5:14 pm
On Feb 1, 11:38 am, gtw...@sonic.net (Mark Curry) wrote:>
Quote:
Nope. SV synthesis is quite powerful. Arrays, and structs are first class
citizens in SV and can be members of ports. Further most tools handle
interfaces now pretty well in synthesis. There's quite a benefit to using
these in your RTL.
Trying to resist making this a language war, but I see little advantage
one or the other with regard to a "higher level of abstraction". You can
probably achieve the same with either language.
--Mark- Hide quoted text -
- Show quoted text -
citizens in SV and can be members of ports. Further most tools handle
interfaces now pretty well in synthesis. There's quite a benefit to using
these in your RTL.
Trying to resist making this a language war, but I see little advantage
one or the other with regard to a "higher level of abstraction". You can
probably achieve the same with either language.
--Mark- Hide quoted text -
- Show quoted text -
Mark,
Sounds like SV synthesis has improved quite a bit, which is good to
know, and good for the industry. Which tools support these features (I
assume at least Synplify)? As soon as someone standardizes a library
to do fixed point in SV, then it will be able to do what VHDL does :)
I'm not that familiar with SV or SV interfaces in particular. There's
one thing I wish VHDL would do, and that is allow an interface (a
record port with different directionality associated with each element
of the record) on a component/entity/subprogram.
From the abstraction point of view, I think you are right, SV and VHDL
synthesis are pretty close, with specific features being edges in
each's favor.
However, I (and I believe the OP) was not considering SV as just a
version of verilog though. Perhaps that is something that is beginning
to change (the realization that there is another viable choice besides
vanilla verilog and vhdl for synthesis.)
Andy
Mark Curry
Guest
Guest
Thu Feb 02, 2012 7:17 pm
In article <315bd1eb-26b4-4164-b503-9e2146ea7499_at_l14g2000vbe.googlegroups.com>,
Andy <jonesandy_at_comcast.net> wrote:
Quote:
On Feb 1, 11:38 am, gtw...@sonic.net (Mark Curry) wrote:
Nope. SV synthesis is quite powerful. Arrays, and structs are first class
citizens in SV and can be members of ports. Further most tools handle
interfaces now pretty well in synthesis. There's quite a benefit to using
these in your RTL.
Trying to resist making this a language war, but I see little advantage
one or the other with regard to a "higher level of abstraction". You can
probably achieve the same with either language.
--Mark- Hide quoted text -
- Show quoted text -
Mark,
Sounds like SV synthesis has improved quite a bit, which is good to
know, and good for the industry. Which tools support these features (I
assume at least Synplify)? As soon as someone standardizes a library
to do fixed point in SV, then it will be able to do what VHDL does
Nope. SV synthesis is quite powerful. Arrays, and structs are first class
citizens in SV and can be members of ports. Further most tools handle
interfaces now pretty well in synthesis. There's quite a benefit to using
these in your RTL.
Trying to resist making this a language war, but I see little advantage
one or the other with regard to a "higher level of abstraction". You can
probably achieve the same with either language.
--Mark- Hide quoted text -
- Show quoted text -
Mark,
Sounds like SV synthesis has improved quite a bit, which is good to
know, and good for the industry. Which tools support these features (I
assume at least Synplify)? As soon as someone standardizes a library
to do fixed point in SV, then it will be able to do what VHDL does
I've used Mentor Precision (for FPGAs), and am currently eval'ing Synplify.
Synopsys has supported SV for a while now for ASICs.
I've followed this thread some with some confusion as to what this
"fixed point library" is and/or does. I do all kinds of DSP math
apps in verilog, with variable precision. Yes, you need
to pay attention scaling along the data path. I'm unsure how
a library can really help this.
Although I tend to want to be very precise - drawing out
my data path with all truncation/rounding/etc specifically
called out. I suppose if some library somehow standardized
this... Hmm, need to think about it. Can't see how it'd offer
much benefit.
--Mark
glen herrmannsfeldt
Guest
Guest
Thu Feb 02, 2012 8:36 pm
rickman <gnuarm_at_gmail.com> wrote:
(snip, I wrote)
Quote:
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.
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)
Quote:
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.
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)
Quote:
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.
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)
Quote:
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.
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)
Quote:
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.
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)
Quote:
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.
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.
Quote:
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.
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
Guest
Guest
Fri Feb 03, 2012 11:37 am
Andy <jonesandy_at_comcast.net> writes:
Quote:
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.
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.
Quote:
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.
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
Guest
Guest
Fri Feb 03, 2012 11:45 am
Andy <jonesandy_at_comcast.net> writes:
Quote:
know, and good for the industry. Which tools support these features (I
assume at least Synplify)? As soon as someone standardizes a library
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
Guest
Guest
Fri Feb 03, 2012 12:43 pm
Petter Gustad <newsmailcomp6_at_gustad.com> wrote:
Quote:
Andy <jonesandy_at_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,
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_at_nctdevpuntnl (punt=.)
--------------------------------------------------------------
Petter Gustad
Guest
Guest
Fri Feb 03, 2012 1:53 pm
nico_at_puntnl.niks (Nico Coesel) writes:
Quote:
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!
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
Guest
Guest
Fri Feb 03, 2012 2:38 pm
Petter Gustad <newsmailcomp6_at_gustad.com> wrote:
Quote:
nico_at_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.
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_at_nctdevpuntnl (punt=.)
--------------------------------------------------------------
Gabor
Guest
Guest
Fri Feb 03, 2012 3:18 pm
glen herrmannsfeldt wrote:
[snip]
Quote:
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?
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
Guest
Guest
Tue Feb 07, 2012 6:22 pm
On Feb 3, 5:43 am, n...@puntnl.niks (Nico Coesel) wrote:
Quote:
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
Guest
Guest
Tue Feb 07, 2012 6:45 pm
On Feb 3, 4:37 am, Petter Gustad <newsmailco...@gustad.com> wrote:
Quote:
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.
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
Guest
Guest
Tue Feb 07, 2012 10:14 pm
Andy <jonesandy_at_comcast.net> wrote:
Quote:
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.
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_at_nctdevpuntnl (punt=.)
--------------------------------------------------------------
elektroda.net NewsGroups Forum Index - FPGA - Design Notation VHDL or Verilog?
