I'd rather switch than fight!

On Apr 15, 3:23=A0pm, Andy <jonesa...@comcast.net> wrote:
> The benefits of a "strongly typed" language, with bounds checks, etc.
> are somewhat different between the first time you write/use the code,
> and the Nth time reuse and revise it. Strong typeing and bounds
> checking let you know quickly the possibly hidden side effects of
> making changes in the code, especially when it may have been a few
> days/weeks/months since the last time you worked with it.
>
> A long time ago there was a famous contest for designing a simple
> circuit in verilog vs. vhdl to see which language was better. The
> requirements were provided on paper, and the contestents were given an
> hour or two (don't remember how long, but it was certainly not even a
> day), and whoever got the fastest and the smallest (two winners)
> correct synthesized circuit, their chosen language won. Verilog won
> both, and I don't think vhdl even finished.

Maybe this was repeated, but the first time they tried this *NO ONE*
finished in time which is likely much more realistic compared to real
assignments in the real world.  If you think it will take a couple of
hours, allocate a couple of days!

Rick

rickman wrote:
> People say that strong typing catches bugs, but I've never seen any
> real proof of that.  There are all sorts of anecdotal evidence, but
> nothing concrete.

My practical experience is that strong typing creates another class of bugs, 
simply by making things more complicated.  I've last seen VHDL in use more 
than 10 years ago, but the typical pattern was that a designer wanted a bit 
vector, and created a subranged integer instead.  Seems to be identical, but 
isn't.  If you increment the subranged integer, it will stop simulation on 
overflow, if you increment the bit vector, it will wrap around.  My coworker 
who did this subranged integer stuff quite a lot ended up with code like

if foo = 15 then foo <= 0 else foo <= foo + 1 endif;

And certainly, all those lines had started out as

foo <= foo + 1;

and were only "fixed" later when the simulation crashed.

The good news is that the synthesis tool really generates the bitvector 
logic for both, so all those simulator crashes were only false alarms.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(snip, I wrote)
>> Seatbelts may save lives, but statistically many other safety
>> improvements don't. ?When people know that their car has air bags,
>> they compensate and drive less safely. ?(Corner a little faster, etc.)
>> Enough to mostly remove the life saving effect of the air bags.
 
> Are you making this up?  I have never heard that any of the other
> added safety features don't save lives overall.  I have heard that
> driving a sportier car does allow you to drive more aggressively, but
> this is likely not actually the result of any real analysis, but just
> an urban myth.  Where did you hear that air bags don't save lives
> after considering all?

I believe that they still do save lives, but by a smaller
factor than one might expect.  I believe the one that I saw
was not quoting air bags, but anti-lock brakes.  

The case for air bags was mentioned by someone else -- that some
believe that they don't need seat belts if they have air bags.
Without seat belts, though, you can be too close to the air bag
when it deploys, and get hurt by the air bag itself.  For that 
reason, they now use slower air bags than they used to.

The action of anti-lock breaks has a more immediate feel while
driving, and it seems likely that many will take that into account
while driving.  I believe that there is still a net gain, but
much smaller than would be expected.

-- glen

On Apr 16, 5:38=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> Secondly, a testbench does not check everything. =A0It is only as good as
> the work put into it, and can be flawed in the same way as the code
> itself. =A0

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!  I queried him on this a bit and he seemed to think
that you just needed to have a "good enough" test bench.  I was
incredulous about this for a long time.  Now I realize he was just a
moron^H^H^H^H^H^H^H ill informed!

Rick

In comp.arch.fpga rickman <gnuarm@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!  I queried him on this a bit and he seemed to think
> that you just needed to have a "good enough" test bench.  I was
> incredulous about this for a long time.  Now 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).  With static timing analysis, there
are many things that you don't need to check with the test bench.

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

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.

-- glen

Andy wrote:
> IMHO, they missed the point. Any design that can be completed in a
> couple of hours will necessarily favor the language with the least
> overhead. Unfortunately, two-hour-solvable designs are not
> representative of real life designs, and neither was the contest's
> declared winner.

Well, we pretty much know that the number of errors people make in 
programming languages basically depends on how much code they have to write 
- a language which has less overhead and is more terse is being written 
faster and has less bugs.  And it goes non-linear, i.e. a program with 10k 
lines of code will have less bugs per 1000 lines than a program with 100k 
lines of code.  So the larger the project, the better the more terse 
language is.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

glen herrmannsfeldt wrote:
> 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.

And then there are some corner cases where neither static timing analysis 
nor digital simulation helps - like signals crossing asynchronous clock 
boundaries (there *will* be a setup or hold violation, but a robust clock 
boundary crossing circuit will work in practice).

Example: We had a counter running on a different clock (actually a VCO, 
where the voltage was an analog input), and to sample it robust in the 
normal digital clock domain, I grey-encoded it.  There will be one bit which 
is either this or that when sampling at a setup or hold violation condition, 
but this is only just one bit, and it's either in the state before the 
increment or after.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

> 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.  Why provide such a general framework when
all you really want is the "clocked process" anyway.  VHDL, Verilog
and MyHDL all let you make the same mistake over and over again.

Cheers,
Andy

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.

On Apr 17, 5:40=A0am, "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.

The context of the "clocked process" paradigm is synthesizable RTL
code.
For many engineers working on complex projects, writing such code is
only
a fraction of their work. For high-level modeling and verification,
you can
use the power of the language in its full generality.

For powerful HDLs such as VHDL/Verilog/MyHDL, the synthesis coding
constraints are imposed by synthesis technology, not by the language.
It is easy to design a "fully synthesizable" HDL that incorporates
such
constraints in the language definition itself. It just seems that the
market
doesn't want those. I certainly don't. You are of course free to
ignore
that observation.

Jan

P.S not all latches are "unwanted" :-)