Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Design Notation VHDL or Verilog?
60 views
Skip to first unread message
vsh
Jan 28, 2012, 7:04:43 PM1/28/12
to
any comments on either VHDL or Verilog?
KJ
Jan 28, 2012, 9:34:17 PM1/28/12
to
On Jan 28, 7:04 pm, vsh <henry.val.sc...@gmail.com> wrote:
> any comments on either VHDL or Verilog?
VHDL
> any comments on either VHDL or Verilog?
Martin Thompson
Jan 30, 2012, 6:25:31 AM1/30/12
to
Yes, *both* languages have comments!
Traditionally, VHDL uses two dashes (--) to signify comments. The
newer-fangled VHDL-2008 syntax also allows the use of C-style multi-line
comments enclosed in /* */ pairs.
As in so many other ways, Verilog uses c style syntax - both /* */ and
// are valid.
Does that help?
Cheers,
Martin
--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
Traditionally, VHDL uses two dashes (--) to signify comments. The
newer-fangled VHDL-2008 syntax also allows the use of C-style multi-line
comments enclosed in /* */ pairs.
As in so many other ways, Verilog uses c style syntax - both /* */ and
// are valid.
Does that help?
Cheers,
Martin
--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
davew
Jan 30, 2012, 6:32:53 AM1/30/12
to
On Jan 29, 12:04 am, vsh <henry.val.sc...@gmail.com> wrote:
> any comments on either VHDL or Verilog?
Can't comment on VHDL other than to say it always strikes me as
> any comments on either VHDL or Verilog?
difficult to decipher and untidy looking. I'd be interested to know
if there's anything useful that you can do in VHDL that you can't in
Verilog.
I'm a Verilog user and like the straight-forward syntax. Like
anything you can make a mess if you don't try hard enough not to.
RCIngham
Jan 30, 2012, 8:08:17 AM1/30/12
to
>any comments on either VHDL or Verilog?
>
A competent designer could use either to implement a digital logic system.
>
---------------------------------------
Posted through http://www.FPGARelated.com
Andy
Jan 30, 2012, 12:28:53 PM1/30/12
to
point arithmetic of arbitrary precision and binary point location. The
arithmetic operators and types are defined to automatically handle
mixed precision/point arithmetic for you. To the best of my knowledge,
the Verilog language in its current form cannot support this
capability at all.
Similarly, VHDL also has a floating point package that handles
arbitrary sizes of data and exponent.
The fixed and floating point packages were demonstrated prior to 2008
with no changes to the language required (that's the power of VHDL
types and overloading), and the only 2008 features that the current
packages use are package generics, to allow user specification of
operator behaviors for rounding, saturation, guard bits, etc. This
highlights VHDL's inherent extensible capabilities that are completely
lacking in Verilog.
If all you use is std_logic, std_logic_vector, or arrays of same,
there is negligible advantage to using VHDL over verilog. It is at
higher levels of abstraction, where design productivity is maximized,
that VHDL shines.
Untidy is in the eye of the beholder.
Andy
glen herrmannsfeldt
Jan 30, 2012, 1:42:03 PM1/30/12
to
Andy <jone...@comcast.net> wrote:
(snip)
hardware has support for this, so it seems strange that an HDL
would need it.
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.
For multiply, you do need to keep all the product digits, so that
you can select the right ones based on the position of the product
radix point.
> Similarly, VHDL also has a floating point package that handles
> arbitrary sizes of data and exponent.
And that is synthesizable by anyone?
> The fixed and floating point packages were demonstrated prior to 2008
> with no changes to the language required (that's the power of VHDL
> types and overloading), and the only 2008 features that the current
> packages use are package generics, to allow user specification of
> operator behaviors for rounding, saturation, guard bits, etc. This
> highlights VHDL's inherent extensible capabilities that are completely
> lacking in Verilog.
I suppose higher level of abstraction is nice, but does it really
help design real systems?
> If all you use is std_logic, std_logic_vector, or arrays of same,
> there is negligible advantage to using VHDL over verilog.
And maybe a slight disadvantage. It is a lot wordier to say
the same thing, more places to get it wrong.
> It is at higher levels of abstraction, where design
> productivity is maximized, that VHDL shines.
Probaby depends on what kind of systems you design.
Is it easier to design something like a pentium with a language that
has support for floating point? For real floating point systems, it
is usual to actually design the logic in the HDL.
> Untidy is in the eye of the beholder.
-- glen
(snip)
>> > any comments on either VHDL or Verilog?
(snip)
> With the 2008 fixed point package, VHDL allows synthesizable fixed
> point arithmetic of arbitrary precision and binary point location. The
> arithmetic operators and types are defined to automatically handle
> mixed precision/point arithmetic for you. To the best of my knowledge,
> the Verilog language in its current form cannot support this
> capability at all.
An interesting idea, but note that, as far as I know, no computer
> point arithmetic of arbitrary precision and binary point location. The
> arithmetic operators and types are defined to automatically handle
> mixed precision/point arithmetic for you. To the best of my knowledge,
> the Verilog language in its current form cannot support this
> capability at all.
hardware has support for this, so it seems strange that an HDL
would need it.
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.
For multiply, you do need to keep all the product digits, so that
you can select the right ones based on the position of the product
radix point.
> Similarly, VHDL also has a floating point package that handles
> arbitrary sizes of data and exponent.
> The fixed and floating point packages were demonstrated prior to 2008
> with no changes to the language required (that's the power of VHDL
> types and overloading), and the only 2008 features that the current
> packages use are package generics, to allow user specification of
> operator behaviors for rounding, saturation, guard bits, etc. This
> highlights VHDL's inherent extensible capabilities that are completely
> lacking in Verilog.
help design real systems?
> If all you use is std_logic, std_logic_vector, or arrays of same,
> there is negligible advantage to using VHDL over verilog.
the same thing, more places to get it wrong.
> It is at higher levels of abstraction, where design
> productivity is maximized, that VHDL shines.
Is it easier to design something like a pentium with a language that
has support for floating point? For real floating point systems, it
is usual to actually design the logic in the HDL.
> Untidy is in the eye of the beholder.
rickman
Jan 30, 2012, 4:06:02 PM1/30/12
to
On Jan 30, 1:42 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be
very useful in an HDL design. If you are just passing data and
controlling timing then maybe not. But signal processing often has to
deal with the results of varying precision in operations.
> 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.
> For multiply, you do need to keep all the product digits, so that
> you can select the right ones based on the position of the product
> radix point.
Actually you need to keep the bits that are important to your
application. That will vary.
> > 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.
> > The fixed and floating point packages were demonstrated prior to 2008
> > with no changes to the language required (that's the power of VHDL
> > types and overloading), and the only 2008 features that the current
> > packages use are package generics, to allow user specification of
> > operator behaviors for rounding, saturation, guard bits, etc. This
> > highlights VHDL's inherent extensible capabilities that are completely
> > lacking in Verilog.
>
> I suppose higher level of abstraction is nice, but does it really
> help design real systems?
Not if you refuse to consider it.
> > If all you use is std_logic, std_logic_vector, or arrays of same,
> > there is negligible advantage to using VHDL over verilog.
>
> And maybe a slight disadvantage. It is a lot wordier to say
> the same thing, more places to get it wrong.
Yes, VHDL is definitely wordier. But then I never use
std_logic_vector or std_logic. I use signed and unsigned which
provide so much more functionality... also provided by the
extensibility of VHDL I believe.
> > It is at higher levels of abstraction, where design
> > productivity is maximized, that VHDL shines.
>
> Probaby depends on what kind of systems you design.
>
> Is it easier to design something like a pentium with a language that
> has support for floating point? For real floating point systems, it
> is usual to actually design the logic in the HDL.
You seem to be very CPU focused. For every Pentium type design done
in HDL there are what, thousands of other designs?
> > Untidy is in the eye of the beholder.
>
> -- glen
Rick
> Andy <jonesa...@comcast.net> wrote:
>
> (snip)
>
> >> > any comments on either VHDL or Verilog?
>
> (snip)
>
> > With the 2008 fixed point package, VHDL allows synthesizable fixed
> > point arithmetic of arbitrary precision and binary point location. The
> > arithmetic operators and types are defined to automatically handle
> > mixed precision/point arithmetic for you. To the best of my knowledge,
> > the Verilog language in its current form cannot support this
> > capability at all.
>
> An interesting idea, but note that, as far as I know, no computer
> hardware has support for this, so it seems strange that an HDL
> would need it.
Whaaaatttt??? What does your computer capabilities have to do with
>
> (snip)
>
> >> > any comments on either VHDL or Verilog?
>
> (snip)
>
> > With the 2008 fixed point package, VHDL allows synthesizable fixed
> > point arithmetic of arbitrary precision and binary point location. The
> > arithmetic operators and types are defined to automatically handle
> > mixed precision/point arithmetic for you. To the best of my knowledge,
> > the Verilog language in its current form cannot support this
> > capability at all.
>
> An interesting idea, but note that, as far as I know, no computer
> hardware has support for this, so it seems strange that an HDL
> would need it.
your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be
very useful in an HDL design. If you are just passing data and
controlling timing then maybe not. But signal processing often has to
deal with the results of varying precision in operations.
> 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.
more than CPU designs.
> For multiply, you do need to keep all the product digits, so that
> you can select the right ones based on the position of the product
> radix point.
application. That will vary.
> > Similarly, VHDL also has a floating point package that handles
> > arbitrary sizes of data and exponent.
>
> And that is synthesizable by anyone?
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.
> > The fixed and floating point packages were demonstrated prior to 2008
> > with no changes to the language required (that's the power of VHDL
> > types and overloading), and the only 2008 features that the current
> > packages use are package generics, to allow user specification of
> > operator behaviors for rounding, saturation, guard bits, etc. This
> > highlights VHDL's inherent extensible capabilities that are completely
> > lacking in Verilog.
>
> I suppose higher level of abstraction is nice, but does it really
> help design real systems?
> > If all you use is std_logic, std_logic_vector, or arrays of same,
> > there is negligible advantage to using VHDL over verilog.
>
> And maybe a slight disadvantage. It is a lot wordier to say
> the same thing, more places to get it wrong.
std_logic_vector or std_logic. I use signed and unsigned which
provide so much more functionality... also provided by the
extensibility of VHDL I believe.
> > It is at higher levels of abstraction, where design
> > productivity is maximized, that VHDL shines.
>
> Probaby depends on what kind of systems you design.
>
> Is it easier to design something like a pentium with a language that
> has support for floating point? For real floating point systems, it
> is usual to actually design the logic in the HDL.
in HDL there are what, thousands of other designs?
> > Untidy is in the eye of the beholder.
>
> -- glen
glen herrmannsfeldt
Jan 30, 2012, 6:16:19 PM1/30/12
to
rickman <gnu...@gmail.com> wrote:
(snip, someone wrote)
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.
>> 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.
>> For multiply, you do need to keep all the product digits, so that
>> you can select the right ones based on the position of the product
>> radix point.
> Actually you need to keep the bits that are important to your
> application. That will vary.
And I don't expect the processor to help me figure out which
ones those are.
>> > 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.)
(snip)
-- glen
(snip, someone wrote)
>> > With the 2008 fixed point package, VHDL allows synthesizable fixed
>> > point arithmetic of arbitrary precision and binary point location.
(snip, I wrote)
>> > point arithmetic of arbitrary precision and binary point location.
>> An interesting idea, but note that, as far as I know, no computer
>> hardware has support for this, so it seems strange that an HDL
>> would need it.
> Whaaaatttt??? What does your computer capabilities have to do with
> your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be
> very useful in an HDL design. If you are just passing data and
> controlling timing then maybe not. But signal processing often has to
> deal with the results of varying precision in operations.
If it is useful in ASIC/FPGA designs, wouldn't it also be even more
>> hardware has support for this, so it seems strange that an HDL
>> would need it.
> Whaaaatttt??? What does your computer capabilities have to do with
> your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be
> very useful in an HDL design. If you are just passing data and
> controlling timing then maybe not. But signal processing often has to
> deal with the results of varying precision in operations.
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.
>> 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.
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.
>> For multiply, you do need to keep all the product digits, so that
>> you can select the right ones based on the position of the product
>> radix point.
> Actually you need to keep the bits that are important to your
> application. That will vary.
ones those are.
>> > 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.
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.)
(snip)
>> I suppose higher level of abstraction is nice, but does it really
>> help design real systems?
> Not if you refuse to consider it.
(snip)
>> help design real systems?
> Not if you refuse to consider it.
> You seem to be very CPU focused. For every Pentium type design done
> in HDL there are what, thousands of other designs?
Well, it was supposed to be an example....
> in HDL there are what, thousands of other designs?
-- glen
Nico Coesel
Jan 30, 2012, 6:57:17 PM1/30/12
to
davew <david...@gmail.com> wrote:
>On Jan 29, 12:04=A0am, vsh <henry.val.sc...@gmail.com> wrote:
>> any comments on either VHDL or =A0Verilog?
what it should do. VHDL has been good to me but it did take reading
some books and experimenting for me to unleash its real power. If you
overcome the stage where you describe hardware (thinking in 74' logic
chips) and start describing what a piece of logic should do you can do
a lot with just a few lines of VHDL by using functions, records, etc.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
>On Jan 29, 12:04=A0am, vsh <henry.val.sc...@gmail.com> wrote:
>> any comments on either VHDL or =A0Verilog?
>
>Can't comment on VHDL other than to say it always strikes me as
>difficult to decipher and untidy looking. I'd be interested to know
>if there's anything useful that you can do in VHDL that you can't in
>Verilog.
>
>I'm a Verilog user and like the straight-forward syntax. Like
>anything you can make a mess if you don't try hard enough not to.
IMHO Verilog is about describing hardware and VHDL is about describing
>Can't comment on VHDL other than to say it always strikes me as
>difficult to decipher and untidy looking. I'd be interested to know
>if there's anything useful that you can do in VHDL that you can't in
>Verilog.
>
>I'm a Verilog user and like the straight-forward syntax. Like
>anything you can make a mess if you don't try hard enough not to.
what it should do. VHDL has been good to me but it did take reading
some books and experimenting for me to unleash its real power. If you
overcome the stage where you describe hardware (thinking in 74' logic
chips) and start describing what a piece of logic should do you can do
a lot with just a few lines of VHDL by using functions, records, etc.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Andy
Jan 31, 2012, 8:57:54 AM1/31/12
to
Glen,
The point of optimizing HW arithmetic to the task at hand is that
avoiding excess precision saves resources (= $).
In SW, running on a majority of platforms that support double
precision floating point (already paid for whether it is used or not)
there is no incentive to optimize, so few computer programming
languages support it. Many older programming languages, conceived
before HW floating point support was ubiquitous, supported fixed point
arithmetic because the SW could be optimized to provide only the
precision required, thus consuming only the CPU cycles required.
CPUs have to be optimized for the universe of applications that may be
run on them, so the flexibility of floating point is worth the cost,
especially because only one or two floating point ALUs are typically
required by a CPU core.
Most ASIC/FPGA designs are much more task specific, and do not need
the flexibility of floating point, especially when considering how
many arithmetic units (multiply/add) may be employed by a typical
design, and thus how many times one would have to pay for the
resources consumed by that unneeded flexibility.
Sure, you can design fixed point arithmetic HW in verilog, but you
have to keep track of the binary point yourself, with no help from the
compiler. These VHDL packages allow you to define the width and binary
point at critical stages, and the compiler takes care of the rest.
Most synthesis tools support retiming, which can be used to pipeline
arithmetic operators over a limited number of clock cycles by simply
inserting empty clock cycles in RTL before or after the operator, and
letting the retiming spread out the operator logic into those clock
cycles. With most modern FPGA families, multiplies and multiply/adds
are implemented using available DSP blocks anyway, so intra-operator
pipelining is not often needed uness you have a really wide data path.
And of course, just like verilog, you are in charge of pipelining
multiple operations by the way you describe the behavior (number of
clock cycles it takes to get from input to output). Note that I use
the term clock cycles as opposed to registers. It's an abstraction...
And yes, both the floating and fixed point packages are completely
synthesizable.
Andy
The point of optimizing HW arithmetic to the task at hand is that
avoiding excess precision saves resources (= $).
In SW, running on a majority of platforms that support double
precision floating point (already paid for whether it is used or not)
there is no incentive to optimize, so few computer programming
languages support it. Many older programming languages, conceived
before HW floating point support was ubiquitous, supported fixed point
arithmetic because the SW could be optimized to provide only the
precision required, thus consuming only the CPU cycles required.
CPUs have to be optimized for the universe of applications that may be
run on them, so the flexibility of floating point is worth the cost,
especially because only one or two floating point ALUs are typically
required by a CPU core.
Most ASIC/FPGA designs are much more task specific, and do not need
the flexibility of floating point, especially when considering how
many arithmetic units (multiply/add) may be employed by a typical
design, and thus how many times one would have to pay for the
resources consumed by that unneeded flexibility.
Sure, you can design fixed point arithmetic HW in verilog, but you
have to keep track of the binary point yourself, with no help from the
compiler. These VHDL packages allow you to define the width and binary
point at critical stages, and the compiler takes care of the rest.
Most synthesis tools support retiming, which can be used to pipeline
arithmetic operators over a limited number of clock cycles by simply
inserting empty clock cycles in RTL before or after the operator, and
letting the retiming spread out the operator logic into those clock
cycles. With most modern FPGA families, multiplies and multiply/adds
are implemented using available DSP blocks anyway, so intra-operator
pipelining is not often needed uness you have a really wide data path.
And of course, just like verilog, you are in charge of pipelining
multiple operations by the way you describe the behavior (number of
clock cycles it takes to get from input to output). Note that I use
the term clock cycles as opposed to registers. It's an abstraction...
And yes, both the floating and fixed point packages are completely
synthesizable.
Andy
Petter Gustad
Jan 31, 2012, 3:00:45 PM1/31/12
to
Andy <jone...@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.
> there is negligible advantage to using VHDL over verilog. It is at
> higher levels of abstraction, where design productivity is maximized,
> that VHDL shines.
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.
rickman
Feb 1, 2012, 1:49:02 AM2/1/12
to
On Jan 30, 6:16 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, someone wrote)
>
> >> > With the 2008 fixed point package, VHDL allows synthesizable fixed
> >> > point arithmetic of arbitrary precision and binary point location.
>
> (snip, I wrote)
>
> >> An interesting idea, but note that, as far as I know, no computer
> >> hardware has support for this, so it seems strange that an HDL
> >> would need it.
> > Whaaaatttt??? What does your computer capabilities have to do with
> > your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be
> > very useful in an HDL design. If you are just passing data and
> > controlling timing then maybe not. But signal processing often has to
> > deal with the results of varying precision in operations.
>
> 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
> rickman <gnu...@gmail.com> wrote:
>
> (snip, someone wrote)
>
> >> > With the 2008 fixed point package, VHDL allows synthesizable fixed
> >> > point arithmetic of arbitrary precision and binary point location.
>
> (snip, I wrote)
>
> >> An interesting idea, but note that, as far as I know, no computer
> >> hardware has support for this, so it seems strange that an HDL
> >> would need it.
> > Whaaaatttt??? What does your computer capabilities have to do with
> > your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be
> > very useful in an HDL design. If you are just passing data and
> > controlling timing then maybe not. But signal processing often has to
> > deal with the results of varying precision in operations.
>
> 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.
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. 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.
> >> 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.
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.
> >> For multiply, you do need to keep all the product digits, so that
> >> you can select the right ones based on the position of the product
> >> radix point.
> > Actually you need to keep the bits that are important to your
> > application. That will vary.
>
> And I don't expect the processor to help me figure out which
> ones those are.
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.
> >> > 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.)
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.
> >> I suppose higher level of abstraction is nice, but does it really
> >> help design real systems?
> > Not if you refuse to consider it.
>
> (snip)
>
> > You seem to be very CPU focused. For every Pentium type design done
> > in HDL there are what, thousands of other designs?
>
> Well, it was supposed to be an example....
>
> -- glen
fixed point package does not mean it is not useful. I really don't
see your points.
Rick
Andy
Feb 1, 2012, 8:31:10 AM2/1/12
to
On Jan 31, 2:00 pm, Petter Gustad <newsmailco...@gustad.com> wrote:
AFAIK, the synthesizable subset of SV is pretty much plane old
verilog, with all its warts.
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.
Andy
verilog, with all its warts.
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.
Andy
glen herrmannsfeldt
Feb 1, 2012, 10:20:49 AM2/1/12
to
rickman <gnu...@gmail.com> wrote:
(snip, I wrote)
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.
> 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.
>> >> 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.
(snip)
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.
>> >> > 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.
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
(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
>> 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.
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.
> 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.
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.
>> >> 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.
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.
(snip)
>> 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
>> 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.
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.
>> >> > 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.
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.
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
Mark Curry
Feb 1, 2012, 12:38:04 PM2/1/12
to
In article <5a603ea6-876d-4f20...@h3g2000yqe.googlegroups.com>,
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
Andy <jone...@comcast.net> wrote:
>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.
Nope. SV synthesis is quite powerful. Arrays, and structs are first class
>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.
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
Feb 2, 2012, 2:03:55 AM2/2/12
to
On 1.2.2012 17:20, glen herrmannsfeldt 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.
It is very useful in some applications, for example in DSP processing.
> 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.
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.
> 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.
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.
> 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.
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
Feb 2, 2012, 2:59:23 AM2/2/12
to
On Feb 1, 10:20 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> 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.
I have no idea what bearing a forty year old computer language has to
> 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.
do with this issue.
> > 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.
this. What HLLs do has nothing to do with the utility of features of
HDLs.
> >> >> 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.
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.
> >> 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.
I determine how the HDL shifts or rounds or whatever it is that I
need.
> >> >> > 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.
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.
> 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
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
Feb 2, 2012, 10:14:45 AM2/2/12
to
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 -
> 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.
>
>
> - 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
Feb 2, 2012, 12:17:17 PM2/2/12
to
In article <315bd1eb-26b4-4164...@l14g2000vbe.googlegroups.com>,
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
Andy <jone...@comcast.net> wrote:
>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 :)
I've used Mentor Precision (for FPGAs), and am currently eval'ing Synplify.
>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 :)
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
Feb 2, 2012, 1:36:38 PM2/2/12
to
>> 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
>> 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.
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)
>> > 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.
> 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
> this. What HLLs do has nothing to do with the utility of features of
> HDLs.
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
>> 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.
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
>> 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.
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
>> 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.
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
> 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.
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
rickman
Feb 2, 2012, 11:21:36 PM2/2/12
to
connect HDL in an FPGA to an HLL in a processor by the vehicle of
fixed point arithmetic. I don't see it. Apps in an FPGA are seldom
capable of being done on a processor. So what is the point of your
comparison? No, I take that back, I don't wish to continue to belabor
this point.
> >> > 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.)
the fixed point library in VHDL. I see no utility of dragging HLLs and
processors into this.
> >> 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.
point. Do you not work with FPGAs? Do you not see apps that are
better suited to FPGAs?
> >> 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.
you can do your work in a processor, why are you talking about the
fixed point package in VHDL on an FPGA?
> >> 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.
considered that an FPGA can do dozens or even hundreds of operations
in a single clock cycle.
> >> 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.
point and the fixed point package have their uses.
Rick
Petter Gustad
Feb 3, 2012, 5:37:48 AM2/3/12
to
Andy <jone...@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
> 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.
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.
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 Gustad
Feb 3, 2012, 5:45:07 AM2/3/12
to
Andy <jone...@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
> know, and good for the industry. Which tools support these features (I
> assume at least Synplify)? As soon as someone standardizes a library
SV support. XST does not, but hopefully that will change with Rodin¹.
//Petter
¹http://www.deepchip.com/items/0494-07.html
Nico Coesel
Feb 3, 2012, 6:43:59 AM2/3/12
to
Petter Gustad <newsma...@gustad.com> wrote:
>Andy <jone...@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!
>Andy <jone...@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,
Petter Gustad
Feb 3, 2012, 7:53:44 AM2/3/12
to
ni...@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
>>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!
another one as output. Care to share some examples? And how do you
swap them like you do with modports in SV.
Nico Coesel
Feb 3, 2012, 8:38:34 AM2/3/12
to
Petter Gustad <newsma...@gustad.com> wrote:
>ni...@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.
>ni...@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.
Gabor
Feb 3, 2012, 9:18:00 AM2/3/12
to
glen herrmannsfeldt wrote:
[snip]
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
[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
> 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?
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
Feb 7, 2012, 11:22:19 AM2/7/12
to
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
> Record bundles can be bi-directional in VHDL!
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
Feb 7, 2012, 11:45:14 AM2/7/12
to
of both. Not nearly as clean or capable as SV though.
Andy
Nico Coesel
Feb 7, 2012, 4:14:07 PM2/7/12
to
Andy <jone...@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.
>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.
Andy
Feb 9, 2012, 2:42:17 PM2/9/12
to
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
> I never had that problem when synthesizing for Xilinx devices.
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
Feb 9, 2012, 4:32:46 PM2/9/12
to
Andy <jone...@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.
>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).
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.
would drive the signal tristate. It probably depends on the tools. My
experience is limited to Xilinx.
Andy
Feb 10, 2012, 9:29:01 AM2/10/12
to
On Feb 9, 3:32 pm, n...@puntnl.niks (Nico Coesel) wrote:
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
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
Feb 12, 2012, 11:24:26 AM2/12/12
to
ni...@puntnl.niks (Nico Coesel) writes:
> Petter Gustad <newsma...@gustad.com> wrote:
>
>>ni...@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
> Petter Gustad <newsma...@gustad.com> wrote:
>
>>ni...@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.
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.
Nico Coesel
Feb 12, 2012, 4:35:17 PM2/12/12
to
Petter Gustad <newsma...@gustad.com> wrote:
>ni...@puntnl.niks (Nico Coesel) writes:
>
>> Petter Gustad <newsma...@gustad.com> wrote:
>>
>>>ni...@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.
>
>ni...@puntnl.niks (Nico Coesel) writes:
>
>> Petter Gustad <newsma...@gustad.com> wrote:
>>
>>>ni...@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.
>static check of only one driving the signal.
Petter Gustad
Feb 12, 2012, 5:21:47 PM2/12/12
to
ni...@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
>>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.
checked quickly, e.g. can be done from the editor and prior to
revision control commits etc. Synthesis usually takes longer.
0 new messages