EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

I'd rather switch than fight!

elektroda.net NewsGroups Forum Index - Verilog Language - I'd rather switch than fight!

Goto page Previous  1, 2, 3 ... 9, 10, 11

KJ
Guest

Wed May 12, 2010 2:59 pm   



Quote:
On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote:
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.

On May 12, 12:20 am, rickman <gnu...@gmail.com> wrote:
I know
of a few instances of when strong typing found bugs for me before they
turned into lab bug searches... which is one of the main reasons for
using such features.  The earlier in the process bugs are found, the
easier they are found and the smaller the impact.  

It seems you've already (re)discovered actual examples where type
checking can be useful

Quote:
Still, there is a
cost and the question is whether the cost is justified...


Depends strongly on the cost of a bug.

KJ

rickman
Guest

Thu May 13, 2010 8:17 am   



On May 12, 7:59 am, KJ <kkjenni...@sbcglobal.net> wrote:
Quote:
On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote:
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.
On May 12, 12:20 am, rickman <gnu...@gmail.com> wrote:
I know
of a few instances of when strong typing found bugs for me before they
turned into lab bug searches... which is one of the main reasons for
using such features.  The earlier in the process bugs are found, the
easier they are found and the smaller the impact.  

It seems you've already (re)discovered actual examples where type
checking can be useful

Still, there is a
cost and the question is whether the cost is justified...

Depends strongly on the cost of a bug.

Yep! Today we found the hardest bug to date on this project. It was
a configuration error... software setting up the hardware. No amount
of type checking would have helped to find that one. That is my
point. VHDL may help prevent some bugs, but there is a lot more to
minimizing bugs than what can be forced on you by tools. Effective
design is a holistic practice that has to take into account the unique
aspects of each design optimizing the process to match the risk
areas. I actually knew that the interface of my board to the rest of
the system was the high risk part of the design, both in terms of the
system itself and in terms of communicating the details. I failed to
give this risk factor enough attention. I tried taking a shortcut of
putting too much effort into the test bench and not doing bench
testing (not the same as test bench testing) before turning the design
over to the customer for integration.

It should be smooth sailing from here on. So at least I'll have more
time to post here and later look into the advantages of Verilog.

Rick

radarman
Guest

Fri May 21, 2010 1:06 am   



On Apr 15, 4:48 pm, Patrick Maupin <pmau...@gmail.com> wrote:
Quote:
On Apr 15, 4:31 pm, Muzaffer Kal <k...@dspia.com> wrote:



On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin

pmau...@gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown <da...@westcontrol.removethisbit.com
wrote:

Another famous contest involved a C and Ada comparison.  It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.

Well, this isn't at all the same then.  The Verilog teams got working
designs, and the VHDL teams didn't.

There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was  an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.

But it's mostly academic and FPGA people who think that VHDL might
have any future at all.  See, for example:

http://www.eetimes.com/news/design/columns/industry_gadfly/showArticl...

Regards,
Pat

Rumors of VHDL's impending death have been around for a while, usually
propagated by companies specializing in Verilog tools looking to sell
products. This article (from 2003) is little different. Seven years
later, and I see that Synopsys is still offering both VHDL and Verilog
compilers with their tools.

I've seen this claim for nearly the entire time I've been working in
the field, and yet I still see VHDL going along quite fine. If
anything, the language has been more stable than Verilog, though I
will give credit for maintaining backwards compatibility. I just don't
see System Verilog being crowned the winner. Perhaps it's just my
industry, but I don't see System Verilog much at all. (plenty of
Verilog, though)

Shoot, if anything; I see tools like Matlab and C-to-RTL tools
eventually taking mind-share away from both VHDL and Verilog. One of
my previous employers did all of their complex algorithmic work in
Matlab, only using VHDL to stitch the final code into a wrapper, or to
connect external RAM. While the performance wasn't as great as a
purely coded implementation, the design time was reduced dramatically.
If that's the extent of your language use, it really matters little
which RTL language you use.

Lastly, while I often see snarky opinions from ASIC guys about FPGA's
high cost per unit, it only takes one bad ASIC spin to pay for a whole
lot of Virtex or Stratix parts. The first time you get your new ASIC
back, and you find a bug, will be when you start to appreciate the
ability reprogram an FPGA in-system, or even remotely. I've even seen
ASIC guys have to stick an FPGA on the board to avoid respinning an
ASIC. Even if the ASIC vendors abandon VHDL entirely, I'm not going to
be all that worried for work.

With gate counts and core frequencies increasing all the time, all the
while $/gate is plummeting, the performance/size advantage is getting
thinner too. I've seen a lot of designs that might have once been done
in ASICs being shipped with FPGA's - not all of them low performance
of high cost, either. I'm not saying ASICs are going anywhere, as
there are definitely applications where the raw speed gain, or low
recurring cost, is vital - but for a lot of designs, FPGA's are a
realistic option.

In short, there is still plenty of room for VHDL, Verilog, Matlab,
etc. I think it's a bit premature to pick a "winner"

Alan Fitch
Guest

Thu Apr 28, 2011 8:26 am   



To: comp.lang.vhdl,comp.arch.
In-Reply-To: <i2vft5pq8j21d4olkjbbn8bqnaopdtreu4_at_4ax.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Ftedna68W9yfgEXWnZ2dnUVZ8n6dnZ2d_at_brightview.co.uk>
Lines: 57
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-krTvZPYnXrjRCDQ/9mxrUbAO1Nho6pPI1R7zpgLqbTlS3MP5Ii1XVFZZtzT9lNJAqr50OoUdZTIU0Dy!KYqBE3uUf0qmqgBRpCSqdDjlJtDNFIcjaBI9ertX/eUr0t/CXPjZcymhBppWA6Fh6uVkhhzjmpKO!YvjcTHDMTUg8yVSac9W6EaMpQA==
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Path: news.mccarragher.com!news.cambrium.nl!textnews.cambrium.nl!feeder2.cambriumusenet.nl!feed.tweaknews.nl!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
Xref: 127.0.0.1 comp.lang.vhdl:8696 comp.arch.fpga:21879 comp.lang.verilog:12622

On 28/04/2010 11:56, Brian Drummond wrote:
Quote:
On Tue, 27 Apr 2010 15:56:57 -0700 (PDT), rickman<gnuarm_at_gmail.com> wrote:

On Apr 27, 6:05 am, Brian Drummond<brian_drumm...@btconnect.com
wrote:

snip

I think you are referring to the ?: conditional operator inherited from C?

I just use VHDL's conditional signal assignments for that purpose. As it's
purely combinational, I have never found the need for an equivalent that I can
use inside a process.


Hi Brian,
just a little note - conditional signal assignment is allowed as a
sequential statement in VHDL 2008

<snip>
Quote:

If VHDL is to adopt a conditional operator I hope it can do better than that!
Something less surprising, and generalisable to other discrete types or at least
other enums.

And VHDL 2008 provides various matching operators that allow std_logic,
bit and so on to be interpreted as Boolean - see
http://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/

If you're interested in VHDL 2008, I recommend the book "VHDL 2008 -
Just the New Stuff" by Peter Ashenden and Jim Lewis.

Now if only the tools supported ...


regards
Alan

<snip>

--
Alan Fitch
Senior Consultant

Doulos u Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch_at_doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.

---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

Goto page Previous  1, 2, 3 ... 9, 10, 11

elektroda.net NewsGroups Forum Index - Verilog Language - I'd rather switch than fight!

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map Opony