Prev: OpenSPARC T1 or T2 on Altera EP2S60 or EP2S90
Next: Where to find source code for Xilinx ML507 board demos?
From: Nico Coesel on 5 Sep 2009 11:15
Jonathan Bromley <jonathan.bromley(a)MYCOMPANY.com> wrote:

>On Sat, 5 Sep 2009 06:28:28 -0700 (PDT), Andy wrote:
>
>>I've been pining for what seems like forever to bring to VHDL a
>>primitive yet powerful sort of interface that would be completely at
>>home in RTL: user definable, custom port modes for record data
>>types.
>
>Didn't they put something a bit like that into VHDL-2008?
>Shame on me, I've not yet got fully up-to-speed with that.
>
>>If we had a way to define custom modes for record types, on an element
>>by element basis, this perverse use of resolved types and default
>>driven values would not be necessary. Of course, a way to define more
>>than one custom mode for most types will be necessary (e.g. master vs
>>slave endpoints on a bus). But once the modes were defined, you could
>>implement records with any data types you wanted (integer, enum,
>>boolean, etc.), even other record types (with their own defined custom
>>modes).
>
>All this is true, and it's one of the things that SV interfaces
>and modports do reasonably well. However, the real power of
>interfaces comes from their ability to import and export
>functionality (subprograms) to/from their connected modules.
>I'm not aware of any move towards that sort of thing in VHDL.
>It doesn't really work quite right in SV either, but at least
>they had a shot at it.
>
>>The task of "hooking up" large structures with complex interfaces
>>would be simplified tremendously, as would the ability to plumb these
>>complex interfaces through multiple levels of hierarchy via "conduits"
>>through which we can virtually pull any kind of cable or fiber we
>>might want, and even change our mind without massive rework.
>
>Absolutely. One of my ultimate goals is the creation of
>bus-agnostic peripherals: here's my DMA device; if I connect
>it to a Wishbone interface, it automatically inherits a
>Wishbone bus control state machine from that interface;

That is probably why *both* VHDL and Verilog need to be dropped and
replaced by something else. Like C# is replacing C/C++.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
From: Mike Treseler on 5 Sep 2009 15:08
Jon wrote:
> Sure, VHDL is better for a new user. Writing the same thing again and
> again and again and again helps you remember it.

I will admit that most vhdl users do not
use functions and procedures for this,
but it is possible -- both for synthesis
and simulation code.

-- Mike Treseler
From: Andy on 5 Sep 2009 22:11
On Sep 5, 9:40 am, Jon <j...(a)beniston.com> wrote:
> Sure, VHDL is better for a new user. Writing the same thing again and
> again and again and again helps you remember it.
>
> Jon

To what are you referring that you must write over and over again?

Andy
From: Kolja on 6 Sep 2009 03:03
On 4 Sep., 09:19, "HT-Lab" <han...(a)ht-lab.com> wrote:
> "glen herrmannsfeldt" <g...(a)ugcs.caltech.edu> wrote in message
>
> news:h7p82b$mgn$1(a)naig.caltech.edu...
>
>
>
> > Andy <jonesa...(a)comcast.net> wrote:
> > (snip on verilog and VHDL)
>
> > < (Other than my personal bias) : Given the differences between coding
> > < for SW and coding for HW, VHDL is better at keeping a new user from
> > < making some ignorant mistakes. A new designer with a SW background is
> > < more likely to make typical "SW" mistakes in a language that looks
> > < more like the SW he is used to. Sometimes keeping the syntax apart
> > < helps in this regard. On the other hand, if one's SW background is in
> > < ada, you could make exactly the same argument in favor of verilog ;^)
>
> > I don't agree, but I believe it could be personal preference.
> > For one, I did some logic design with TTL gates before learning
> > verilog, so I know how to think in terms of logic.
>
> > Verilog isn't really that much like C.  There are people using
> > C as an HDL, and I completely agree that is a bad idea.
>
> Don't be too quick to dismiss C for HDL, there are lots of companies that
> develop algorithms in Matlab/C/C++/SC and then pass it on to a poor engineer to
> "quickly" translate into VHDL/Verilog. Then a month later they require the same
> algorithm but 5 times faster or with a "subtle change" which normally results
> (requires) a costly redesign. For those applications you really want to use an
> untimed language like C/C++ and use a tool (CatapultC/BlueSpec/
> Forte/Synfora/etc...) to do all the design exploration (resource mapping/adding
> pipelines/concurrency/etc) for you.
>
> Given the progress these tools are making (most can now also handle control path
> as well) and the amount of money companies like Intel/AMD are pouring into
> sequential to concurrent research I wouldn't be surprise if the future of RTL is
> neither VHDL nor Verilog.....

There are very good reasons to use imperative languages for rapid
prototyping and
synthesizing complex algorithms to hardware.
BUT:
We in the world would anyone want to use a language with as many side
effects
as C (or even worse C++) for that purpose????? If you like C syntax
that much use Java or C#-.
Siemens was doing Java to netlist before the System-C hype but they
were approached
with stupid arguments like "the AWT is sooo slow" which is completely
irrelevant as
for hardware prototyping one uses none of the APIs that usually come
with the language
and also does not use the garbage collector.
IIRC C does not even have a formal memory model, how is one supposed
to do
formal verification on C code?

Kolja
From: HT-Lab on 6 Sep 2009 07:44

"Kolja" <ksulimma(a)googlemail.com> wrote in message
news:63b90383-9f00-4df2-a320-60b832e94382(a)g19g2000yqo.googlegroups.com...
On 4 Sep., 09:19, "HT-Lab" <han...(a)ht-lab.com> wrote:
> "glen herrmannsfeldt" <g...(a)ugcs.caltech.edu> wrote in message
>
> news:h7p82b$mgn$1(a)naig.caltech.edu...
>
...snip
> Given the progress these tools are making (most can now also handle control
> path
> as well) and the amount of money companies like Intel/AMD are pouring into
> sequential to concurrent research I wouldn't be surprise if the future of RTL
> is
> neither VHDL nor Verilog.....
>
>There are very good reasons to use imperative languages for rapid
>prototyping and
>synthesizing complex algorithms to hardware.
>BUT:
>We in the world would anyone want to use a language with as many side
>effects
>as C (or even worse C++) for that purpose????? If you like C syntax
>that much use Java or C#-.

I don't understand this statement.

>
>Siemens was doing Java to netlist before the System-C hype but they
>were approached
>with stupid arguments like "the AWT is sooo slow" which is completely
>irrelevant as
>for hardware prototyping one uses none of the APIs that usually come
>with the language
>and also does not use the garbage collector.
>IIRC C does not even have a formal memory model, how is one supposed
>to do formal verification on C code?

Formal verification (ACE) for C is nothing new, however, I suspect that throwing
a bunch of assertions at VHDL/Verilog is a lot easier than doing the same for C
code.

Hans
www.ht-lab.com




First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: OpenSPARC T1 or T2 on Altera EP2S60 or EP2S90
Next: Where to find source code for Xilinx ML507 board demos?