regarding "posedge"

On 03/18/2011 04:18 PM, rickman wrote:

I think there is little value to looking at HDLs as general
programming languages or even as "programming languages" at all. They
really aren't intended to be programming languages. They are
"Hardware Desciption Languages". If you want to ignore the hardware
aspect of them then I feel you are tossing the baby out with the bath
water.
This is just a bunch of clichés, as misleading and boring
as clichés can be.

Many HDLs have been proposed. Most were in the "close to hardware"
camp. They are mostly forgotten. The market clearly prefers
the "outsiders" that look more like "programming languages".

Of course, the market may be (temporarily) wrong, but to back that
up you better come up with very strong arguments and fresh ideas.

Programming is of course about languages, compilers and methodolgies.
However, a point frequently missed by hardware designers is that
there is a wide variety of sub-discplines and application domains,
with very different characteristics and constraints. The best
programmers know their application domain very well, they master
the coding patterns that work well for their purpose, and they
understand what they can expect from their compilers.

A good HDL designer should of course do exactly the same. He
should understand hardware design very well. But he should also
understand what kind of coding patterns are efficiently
handled by his compiler (synthesis tool). Focussing on
"describing hardware" is counter-productive, because it tends
to make designers blind for useful coding patterns.

Interpreting HDL design as a specific software discpline has
a tremendous advantage: you benefit from all advances in tools
and methodologies from the overall software world. The best
talent that gives us real breakthroughs is there - that is
just a matter of numbers.

We hardware designers are much less special than we often
like to think. By realizing that, we can reduce our development
costs and increase our productivity.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
 
On 03/19/2011 02:32 AM, Muzaffer Kal wrote:
On Fri, 18 Mar 2011 08:18:29 -0700 (PDT), rickman<gnuarm@gmail.com
wrote:

...
I think there is little value to looking at HDLs as general
programming languages or even as "programming languages" at all. They
really aren't intended to be programming languages. They are
"Hardware Desciption Languages".
...
I would like as much capability in the HDL as possible that
facilitates my work.

...
When I am doing RTL simulation I want to verify that my design is
correct. (FULL STOP)

In my humble opinion these statements are not self-consistent in the
sense that you're not only using HDL to develop hardware but you're
using it to verify your design.
A language which only/strictly allows you to describe hardware is no
where nearly good enough as a verification language. To verify well,
quickly and with high coverage you need a much more capable language
than an HDL you describe. You need a complete programming language to
describe all the verification tasks you need to accomplish. Remember
that you'll spend a lot more time in that verification language than
in the description language so make sure that verification language is
as sophisticated as possible to save you time and sometime even make
it possible to say what you want for verification.
No need to be humble here - that is exacly right and well put.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
 
On 03/19/2011 03:33 PM, rickman wrote:
On Mar 18, 9:32 pm, Muzaffer Kal<k...@dspia.com> wrote:
On Fri, 18 Mar 2011 08:18:29 -0700 (PDT), rickman<gnu...@gmail.com
wrote:

...

I think there is little value to looking at HDLs as general
programming languages or even as "programming languages" at all. They
really aren't intended to be programming languages. They are
"Hardware Desciption Languages".
...
I would like as much capability in the HDL as possible that
facilitates my work.

...

When I am doing RTL simulation I want to verify that my design is
correct. (FULL STOP)

In my humble opinion these statements are not self-consistent in the
sense that you're not only using HDL to develop hardware but you're
using it to verify your design.
A language which only/strictly allows you to describe hardware is no
where nearly good enough as a verification language. To verify well,
quickly and with high coverage you need a much more capable language
than an HDL you describe. You need a complete programming language to
describe all the verification tasks you need to accomplish. Remember
that you'll spend a lot more time in that verification language than
in the description language so make sure that verification language is
as sophisticated as possible to save you time and sometime even make
it possible to say what you want for verification.

I don't agree that the language can't do both. It is doing both now,
just not a great job of the hardware description part. There is
nothing wrong with a language having programming capabilities. I'm
trying to point out that some suggest that by being as flexible in the
language as possible, you don't need the language to deal directly
with aspects of hardware. But the two are not incompatible. We
shouldn't make excuses for limitations in the hardware description
aspects by saying you can program around these limitations.
Then finally come up with something concrete how that should
look like. Some technical starting point, no matter how small,
that we could analyze and criticize in a meaningful way.

Even though I have argued, with arguments open to anyone's
criticism, that the concept goes into the wrong direction,
I have made 2 concrete suggestions: Verilog instantiations
and AHDL. A good start would be to tell us what is wrong
or right with those approaches for your purposes.

Just stop misrepresenting synthesis and the cheap talk.

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
 

Welcome to EDABoard.com

Sponsor

Back
Top