From: glen herrmannsfeldt on
In comp.arch.fpga rickman <gnuarm(a)gmail.com> wrote:
(snip on test benches)

>> I suppose so, but consider it the other way around.

>> If your test bench is good enough then it will catch all static
>> timing failures (eventually). ?With static timing analysis, there
>> are many things that you don't need to check with the test bench.

> I don't follow what you are saying. This first sentence seems to be
> saying that a timing simulation *is* a good place to find timing
> problems, or are you talking about real world test benches? The point
> is that static timing is enough to catch all timing failures given
> that your timing constraints cover the design properly... and I agree
> that is a big given. Your second sentence seems to be agreeing with
> my previous statement.

Yes, I was describing real world (hardware) test benches.

Depending on how close you are to a setup/hold violation,
it may take a long time for a failure to actually occur.

>> Also, you can't do static timing analysis on the implemented logic.
>> (That is, given an actual built circuit and a logic analyzer.)

> So?

>> Now, setup and hold violations are easy to test with static
>> analysis, but much harder to check in actual logic. ?Among others,
>> you would want to check all possible clock skew failures, which is
>> normally not possible. ?With the right test bench and logic
>> implementation (including programmable delays on each FF clock)
>> it might be possible, though.

> In twenty years of designing with FPGAs I have never found a clock
> skew problem. I always write my code to allow the clock trees to
> deliver the clocks and I believe the tools guaranty that there will
> not be a skew problem. Static timing actually does cover clock skew,
> at least the tools I use.

Yes, I was trying to cover the case of not using static timing
analysis but only testing actual hardware. For ASICs, it is
usually necessary to test the actual chips, though they should
have already passed static timing.

> BTW, how do you design a "right test bench"? Static timing analysis
> will at least give you the coverage level although one of my
> complaints is that they don't provide any tools for analyzing if your
> constraints are correct. But I have no idea how to verify that my
> test bench is testing the timing adequately.

If you only have one clock, it isn't so hard. As you add more,
with different frequencies and/or phases, it gets much harder,
I agree. It would be nice to get as much help as possible
from the tools.

-- glen
From: Paul Uiterlinden on
Andrew FPGA wrote:

> Interesting in the discussion on myHdl/testbenches, no-one raised
> SystemVerilog. SystemVerilog raises the level of abstraction(like
> myHdl), but more importantly it introduces constrained random
> verification. For writing testbenches, SV is a better choice than
> MyHdl/VHDL/Verilog, assuming tool availablility.

And assuming availability of financial means to buy licenses.
And assuming availability of time to rewrite existing verification
components, all of course written in VHDL.
And assuming availability of time to learn SV.
And assuming availability of time to learn OVM.
And ...

Oh man, is it because of the seasonal change that I'm feeling so tired, or
is it something else? ;-)

> It would seem that SV does not bring much to the table in terms of RTL
> design - its just a catchup to get verilog up to the capabilities that
> VHDL already has.

Indeed.

I agree that SV seems to give most room for growth in the verification side.
VHDL is becoming too restrictive when you want to create really reusable
verification parts (reuse verification code from block level at chip
level). More often than not, the language is working against you in that
case. Most of the time because it is strongly typed. In general I prefer
prefer strongly typed over weakly typed. But sometimes it just gets in your
way.

For design I too do not see much advantage of SV over VHDL, especially when
you already are using VHDL. So then a mix would be preferable: VHDL for
design, SV/OVM for verification.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
From: Andy on
On Apr 14, 3:23 pm, Jan Decaluwe <j...(a)jandecaluwe.com> wrote:
>
> Seriously, that's why conversion to VHDL/Verilog gets so much
> attention. It allows you to view MyHDL simply as a more effective
> or fun way to create your trusted VHDL/Verilog design.
>
> Therefore, no need to ask nor tell anyone. If you're intrigued,
> just do it, and do it as a good engineer: start with a simple
> but relevant module, not with a whole design. After conversion,
> few will be able to tell (you may even get praise for the
> code quality :-)).


And do what? Be forced into a design/coding paradigm that is the least
common denominator of verilog and vhdl?

No thanks, I don't need or want another code generator.

Code conversion is only applicable if you never have to read it or
maintain it in its converted form. I can't rely on myhdl in order to
maintain the source.

Andy
From: Jan Decaluwe on
On Apr 19, 7:18 pm, Andy <jonesa...(a)comcast.net> wrote:
> On Apr 14, 3:23 pm, Jan Decaluwe <j...(a)jandecaluwe.com> wrote:
>
> > Seriously, that's why conversion to VHDL/Verilog gets so much
> > attention. It allows you to view MyHDL simply as a more effective
> > or fun way to create your trusted VHDL/Verilog design.
>
> > Therefore, no need to ask nor tell anyone. If you're intrigued,
> > just do it, and do it as a good engineer: start with a simple
> > but relevant module, not with a whole design. After conversion,
> > few will be able to tell (you may even get praise for the
> > code quality :-)).
>
> And do what? Be forced into a design/coding paradigm that is the least
> common denominator of verilog and vhdl?

Not necessarily, because conversion happens after elaboration
by the Python interpreter, and because MyHDL's type system
for RTL is at a more abstract level.

> No thanks, I don't need or want another code generator.

Sure, don't bother if it doesn't solve a real problem
for you. Just let it be an informed decision.

Please: don't call it code generation. It's essentially a
powerful HDL with strong conversion capabilities.

Also, last time I forgot to mention that there actually is
commercial support (though it may not be expensive enough
to impress you :-))

http://www.myhdl.org/doku.php/support

> Code conversion is only applicable if you never have to read it or
> maintain it in its converted form. I can't rely on myhdl in order to
> maintain the source.

I wouldn't know why not. You can even maintain equivalent VHDL and
Verilog simultanuously. What other technology can do that?

Jan

From: Andy on
All the abstraction is gone when you convert to VHDL/Verilog, rather
than trying to represent the abstraction intact as much as possible in
the copnverted code (significant in VHDL, not so much in Verilog).

Without a proven, supported tool chain I cannot depend on maintaining
code in the MyHDL domain. Therefore, I have to use it only as a code
generator, and be able to maintain the generated VHDL/Verilog code in
case said tool goes away (with all the limitations inherent in the
converted code). If I started out in VHDL, the VHDL would be much more
maintainable. I'll look into the support link you provided, but until
a major synthesis tool supports it directly, I can't say that it would
make any difference.

Your definition of maintaining equivalent VHDL and Verilog is only
through the as-yet-unsupported language. That's not maintenance in my
book. It may work for commercial products that are here and gone in a
year or two, but in my business, support is measured in decades.

All this said, I am attracted to MyHDL as an academic exercise (even
though I hate some of the syntactic baggage, especially ".next"), not
as a useable tool in my professional environment. At least not yet...

Andy