I'd rather switch than fight!

On Apr 16, 2:45=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga rickman <gnu...@gmail.com> wrote:
> (snip)
>
> > I was listening to a lecture by a college once who indicated that you
> > don't need to use static timing analysis since you can use a timing
> > based simulation! =A0I queried him on this a bit and he seemed to think
> > that you just needed to have a "good enough" test bench. =A0I was
> > incredulous about this for a long time. =A0Now I realize he was just a
> > moron^H^H^H^H^H^H^H ill informed!
>
> 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). =A0With 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.


> 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. =A0Among others,
> you would want to check all possible clock skew failures, which is
> normally not possible. =A0With 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.

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.

Rick

On Apr 17, 2:21=A0am, Paul <pault...@googlemail.com> wrote:
> On 17 Apr, 04:40, "evilkid...@googlemail.com"
>
> <evilkid...@googlemail.com> wrote:
> > > For example, with MyHDL you will also have to learn about latch
> > > inference and how to avoid "unwanted latches". However, just like in
> > > VHDL/Verilog there is a much better solution for this than using a
> > > limited HDL: use a clocked process template by default.
>
> > I don't agree with this. =A0Why provide such a general framework when
> > all you really want is the "clocked process" anyway. =A0VHDL, Verilog
> > and MyHDL all let you make the same mistake over and over again.
>
> AFAIK, to avoid latch inference you need a non-sequential language,
> and most don't want that.

I'm not clear on what either of you are saying.  I don't seem to have
a problem with latch inferrence mainly because I know what causes
inferred latches.  It has nothing to do with sequential or non-
sequential languages.  VHDL has non-sequential capabilities and I can
infer a latch using that.

a <=3D b when (c =3D '1');  -- use "c" as a latch enable

What am I missing?

Rick

In comp.arch.fpga rickman <gnuarm@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

On Apr 14, 3:23=A0pm, Jan Decaluwe <j...@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

On Apr 19, 7:18=A0pm, Andy <jonesa...@comcast.net> wrote:
> On Apr 14, 3:23=A0pm, Jan Decaluwe <j...@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

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

On Apr 17, 7:17=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga rickman <gnu...@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. =A0This 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? =A0The poin=
t
> > 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. =A0Your 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.

That is the point.  Finding timing violations in a simulation is hard,
finding them in physical hardware is not possible to do with any
certainty.  A timing violation depends on the actual delays on a chip
and that will vary with temperature, power supply voltage and process
variations between chips.  I had to work on a problem design once
because the timing analyzer did not work or the constraints did not
cover (I firmly believe it was the tools, not the constraints since it
failed on a number of different designs).  We tried finding the chip
that failed at the lowest temperature and then used that at an
elevated temperature for our "final" timing verification.  Even with
that, I had little confidence that the design would never have a
problem from timing.  Of course on top of that the chip was being used
at 90% capacity.  This design is the reason I don't work for that
company anymore.  The section head knew about all of these problems
before he assigned the task and then expected us to work 70 hour work
weeks.  At least we got them to buy us $100 worth of dinner each
evening!

The point is that if you don't do static timing analysis (or have an
analyzer that is broken) timing verification is nearly impossible.


> >> 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. =A0I 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. =A0Static 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. =A0For ASICs, it is
> usually necessary to test the actual chips, though they should
> have already passed static timing. =A0

If you find a timing bug in the ASIC chip, isn't that a little too
late?  Do you test at elevated temperature?  Do you generate special
test vectors?  How is this different from just testing the logic?


> > BTW, how do you design a "right test bench"? =A0Static 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. =A0But 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. =A0As you add more,
> with different frequencies and/or phases, it gets much harder,
> I agree. =A0It would be nice to get as much help as possible
> from the tools.

The number of clocks is irrelevant.  I don't consider timing issues of
crossing clock domains to be "timing" problems.  There you can only
solve the problem with proper logic design, so it is a logic
problem.

Rick

On Apr 16, 4:38=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

> The old joke about Ada is that when you get your code to compile, it's
> ready to ship. =A0I certainly wouldn't go that far, but testing is
> something you do in cooperation with static checking, not as an alternati=
ve.

GOOD static checking tools are great (and IMHO part of a testbench).
I certainly hope you're not trying to imply that the typechecking
built into VHDL is a substitute for a good model checker!

Regards,
Pat

On Apr 10, 8:21=A0pm, Jan Decaluwe <jandecal...@gmail.com> wrote:
> On Apr 9, 6:53=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
>
>
>
> > On Apr 9, 9:07=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > I think I have about had it with VHDL. =A0I've been using the
> > > numeric_std library and eventually learned how to get around the
> > > issues created by strong typing although it can be very arcane at
> > > times. =A0I have read about a few suggestions people are making to he=
lp
> > > with some aspects of the language, like a selection operator like
> > > Verilog has. =A0But it just seems like I am always fighting some aspe=
ct
> > > of the VHDL language.
>
> > > I guess part of my frustration is that I have yet to see where strong
> > > typing has made a real difference in my work... at least an
> > > improvement. =A0My customer uses Verilog and has mentioned several ti=
mes
> > > how he had tried using VHDL and found it too arcane to bother with.
> > > He works on a much more practical level than I often do and it seems
> > > to work well for him.
>
> > > One of my goals over the summer is to teach myself Verilog so that I
> > > can use it as well as I currently use VHDL. =A0Then I can make a full=
y
> > > informed decision about which I will continue to use. =A0I'd apprecia=
te
> > > pointers on good references, web or printed.
>
> > > Without starting a major argument, anyone care to share their feeling=
s
> > > on the differences in the two languages?
>
> > > Rick
>
> > The best online references are the Sutherland Verilog references.
> > There is an online HTML reference for Verilog 95 (excellent), and a
> > PDF for Verilog 2001 (good):
>
> >http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.h...=
...
>
> > Cliff Cummings has a lot of good papers on Verilog at his site:
>
> >http://sunburst-design.com/papers/
>
> > In particular, if you read and carefully grok his paper about non-
> > blocking vs. blocking assignments, you will be well on your way to
> > being a Verilog wizard:
>
> >http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
>
> The infamous Guideline #5 bans variable semantics from always blocks
> with sequential logic. It must be the Worst Guideline ever for RTL
> designers.
> The result is not wizardry but ignorance.
>
> How are we supposed to "raise the abstraction level" if Verilog RTL
> designers
> can't even use variables?

I didn't notice this post until today.  I think you are completely
misreading the guidelines if you think they mean "Verilog RTL
designers can't even use variables"

Regards,
Pat

In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
> On Apr 17, 7:17?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
 (snip on test benches)

>> 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.
 
> That is the point.  Finding timing violations in a simulation is hard,
> finding them in physical hardware is not possible to do with any
> certainty.  A timing violation depends on the actual delays on a chip
> and that will vary with temperature, power supply voltage and process
> variations between chips.  

But they have to be done for ASICs, and all other chips as
part of the fabrication process.  For FPGAs you mostly don't
have to do such, relying on the specifications and that the chips
were tested appropriately in the factory.

> I had to work on a problem design once
> because the timing analyzer did not work or the constraints did not
> cover (I firmly believe it was the tools, not the constraints since it
> failed on a number of different designs).  We tried finding the chip
> that failed at the lowest temperature and then used that at an
> elevated temperature for our "final" timing verification.  Even with
> that, I had little confidence that the design would never have a
> problem from timing.  Of course on top of that the chip was being used
> at 90% capacity.  This design is the reason I don't work for that
> company anymore.  The section head knew about all of these problems
> before he assigned the task and then expected us to work 70 hour work
> weeks.  At least we got them to buy us $100 worth of dinner each
> evening!

One that I worked with, though not at all at that level, was
a programmable ASIC (for a systolic array processor).  For some
reason that I never knew the timing was just a little bit off
regarding to writes to the internal RAM.  The solution was to use
two successive writes, which seemed to work.  In the usual operation
mode, the RAM was initialized once, so the extra cycle wasn't much
of a problem.  There were also some modes where the RAM had to
be written while processing data, such that the extra cycle meant
that the processor ran that much slower.  
 
> The point is that if you don't do static timing analysis (or have an
> analyzer that is broken) timing verification is nearly impossible.

And even if you do, the device might still have timing problems.
 
(snip)
>> 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. ?
 
> If you find a timing bug in the ASIC chip, isn't that a little too
> late?  Do you test at elevated temperature?  Do you generate special
> test vectors?  How is this different from just testing the logic?

It might be that it works at a lower clock rate, or other workarounds
can be used.  Yes, it is part of testing the logic. 
 
(snip)

>> 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.
 
> The number of clocks is irrelevant.  I don't consider timing issues of
> crossing clock domains to be "timing" problems.  There you can only
> solve the problem with proper logic design, so it is a logic
> problem.

Yes, there is nothing to do about asynchronous clocks.  It just has
to work in all cases.  But in the case of supposedly related
clocks, you have to verify it.  There are designs that have one
clock a multiple of the other clock frequency, or multiple phases
with specified timing relationship.   Or even single clocks with
specified duty cycle.  (I still remember the 8086 with its 33% duty
cycle clock.)  

With one clock you can run combinations of voltage, temperature,
and clock rate, not so hard but still a lot of combinations.
With related clocks, you have to verify that the timing between
the clocks works.  

-- glen