Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 04/01/13 02:11, Rui Maciel wrote:
> Tim Wescott wrote:
>
>> I have to admit, the biggest problem that I have as a C++ programmer when
>> writing in either VHDL or Verilog is envy: in both (IIRC) VHDL or Verilog,
>> when you have a module with a bazzilion input and output signals, you can
>> invoke it with a syntax something like
>>
>> module_name(module_signal_name = local_signal_name, ...)
>>
>> In C++, when, for reasons of utility, you are forced to design a class
>> whose constructor has a bazzilion inputs, you have to hold your breath,
>> close your eyes, cross your fingers, and hope that whoever uses that
>> constructor call gets all the right things in all the right places: I'd
>> Much Rather be able to invoke the syntax above and have it all self-
>> document.
>
> There's no need to hold your breath. You can still do that, and more, with
> C++, by employing the named parameter idiom.
>
> http://www.parashift.com/c++-faq/named-parameter-idiom.html
>
>
> Rui Maciel
>
I'm with Tim on this one...
C and C++ programmers who have experience with other programming
languages and know what named parameters are, /will/ hold their breaths
and hope that they get implemented properly in the languages. (C would
need support for C++ - style default parameters first, of course.)
The link you gave illustrates the problem perfectly. Here there is an
"OpenFile" class with lots of inline member functions to act as pretend
named parameters. It's a lot of mess for no good reason - if named
parameters were part of the language, then it would all be implemented
in a single simple constructor:
OpenFile::OpenFile(std::string const& filename, readonly = false,
createIfNotExist = false, blockSize = 4096u) ...
And it would be called with something like:
f = OpenFile("foo.txt", blockSize = 1024);
This would be much easier to write, much easier to use, and much more
efficient - it is just syntactic sugar for normal function calling as
the compiler would re-arrange the parameters in the correct non-named order.
In fact, the OpenFile class would not be needed at all - it is just an
artificial class to get pseudo named parameters for an OpenFile
/function/ (or method of the main File class).
One of the strengths of C++ is that you can add a lot of features to the
language by using templates, classes, and the pre-processor (just look
at boost for examples). And the standards committee is rightly
reluctant to add new features to the basic language if the same
functionality can be implemented using the existing language. But a big
weakness of C++ is that this philosophy is sometimes used as an excuse
not to fill in gaps in the language. /Real/ named parameters would be
easy to add to the language specifications, and a simple matter to
implement for compiler developers. But instead we have got this "named
parameter idiom" rather than proper support.
mvh.,
David
Article: 154751On 03/01/13 23:50, Martin Schoeberl wrote: > Christopher Felton <abc@def.org> wrote: >> On 1/2/13 8:35 PM, Martin Schoeberl wrote: >>> Christopher Felton <abc@def.org> wrote: >>>> On 12/30/12 4:42 PM, Jon Elson wrote: >>>>> Martin Schoeberl wrote: >>>>> >>>>>> Jon Elson <elson@pico-systems.com> wrote: >>>>>>> Martin Schoeberl wrote: >>>>>>> >>>>>>> >>>>>>>> A good comparison would be to do one HW design, e.g. a standard MIPS >>>>>>>> pipeline, in all languages and compare the efficiency of the language >>>>>>>> and the efficiency of the resulting HW implementation. >>>>>>> >>>>>>> MAN, that would be a landmark achievement! You might even go down >>>>>>> in history as the author of "the Schoeberl paper". Even if it wouldn't >>>>>>> change the (horrible) way I do designs now, it would sure be an >>>>>>> interesting read. >>>>>>> >>>>>>> Jon >>>>>> >>>>>> Maybe I should tone this done. Yes, it would be nice to have this example. >>>>>> It would also be nice to have this comparison in a paper. Let's see where >>>>>> this leads. >>>>>> >>>>>> I will start on a smaller scale with simpler examples. Maybe up to a very >>>>>> simple processor that I already have in VHDL. Will keep you informed along >>>>>> the >>>>>> path. If anybody would like to join this effort we can setup a repository. >>>>> Great, and thanks for putting in the effort! >>>>> Even a VERY simple example of the same function in several languages >>>>> could be quite instructive. But, a somewhat larger project would >>>>> be more likely to expose some of the deficiencies of this or that >>>>> language. >>>>> >>>>> Jon >>>>> >>>> >>>> You might be interested in this rebuttal to a >>>> paper that compared a couple non-traditional HDLs. >>>> >>>> http://thread.gmane.org/gmane.comp.python.myhdl/2701 >>>> >>>> Regards, >>>> Chris >>> >>> This is definitely interesting, but the link is dead :-( >>> >>> Do you have the title of that paper so I can try to Google it. >>> >>> Cheers, >>> Martin >>> >> >> I believe this is the original paper: >> http://referaat.cs.utwente.nl/conference/17/paper/7344/comparing-hardware-description-languages.pdf >> >> But note the objections in the previous thread I posted. The comparisons >> are incomplete (comparing non-working HDL, the author(s) didn't learn >> enough of the languages). >> >> Regards, >> Chris > > Thanks for pointing me to the paper. It is not a very exciting one and I > agree on all critics. I did not look into all details, but I think the FIFO > example is also broken. There is only one pointer, but one would need a > read and a write pointer. > > Untested code and no synthesis results. Ok, it is just a student > conference. > > With this paper as reference it should be easy to do better ;-) > > Cheers, > Martin > It is also worth noting that this "paper" seems to be just a student exercise that has somehow "escaped" into public domain - it makes no claims about trying to compare a realistic choice of languages. A HDL language comparison that doesn't even include Verilog cannot be taken seriously. I'm sure the student gave a good answer to the question his teacher posed, but don't read more into it than that.Article: 154752
David Brown wrote:
> C and C++ programmers who have experience with other programming
> languages and know what named parameters are, /will/ hold their breaths
> and hope that they get implemented properly in the languages. (C would
> need support for C++ - style default parameters first, of course.)
C, since C99, has designated initializers for aggregate types, which helps
pull off this syntactic sugar.
<code>
#include <stdio.h>
struct test_parameter
{
int a;
float b;
};
void test(struct test_parameter p)
{
printf("testing a: %d, b: %f\n", p.a, p.b);
}
int main(void)
{
test((struct test_parameter){.a = 1, .b = 2.0f});
test((struct test_parameter){.b = 5.0f, .a = 4});
return 0;
}
</code>
C++ doesn't support C's designated initializers, so this trick can't be
pulled with it. Nevertheless, as I've mentioned previously, the named
parameter idiom can be used for the exact same effect.
This means that it isn't true that C++ forces anyone to design a class with
a bazzilion parameters. If having to pass more than a couple of parameters
to a constructor becomes a problem, there are plenty of ways to avoid that.
For example, it is also possible to use Boost's ad-hoc implementation of
named parameters:
http://www.boost.org/doc/libs/1_44_0/libs/parameter/doc/html/index.html
What I tend to use to avoid having to define multiple versions of the same
constructor or a constructor with a bazzilion parameters is to use a named
parameter idiom to define a parameter class for the constructor, such as:
<code>
#include <iostream>
class Foo
{
int a;
float b;
public:
struct Parameters
{
int a;
float b;
Parameters & length(int const l) {a = l; return
*this;} ;
Parameters & frequency(float const f) {b = f; return
*this;};
};
Foo(Parameters const ¶m): a(param.a), b(param.b) { std::cout <<
"a: " << a << ", b: " << b << std::endl;}
};
int main(void)
{
Foo( Foo::Parameters().length(2).frequency(4));
Foo( Foo::Parameters().frequency(6).length(3));
return 0;
}
</code>
> The link you gave illustrates the problem perfectly. Here there is an
> "OpenFile" class with lots of inline member functions to act as pretend
> named parameters. It's a lot of mess for no good reason
The member functions don't need to be inline. The only requirement is that
they return a reference to the named parameter object.
If you believe that having to deal with more than a couple of parameters
represents a problem then providing a solution to this problem is a good
reason to use them. And the "lot of mess" comment is at best unreasonable.
> - if named
> parameters were part of the language, then it would all be implemented
> in a single simple constructor:
>
> OpenFile::OpenFile(std::string const& filename, readonly = false,
> createIfNotExist = false, blockSize = 4096u) ...
>
> And it would be called with something like:
> f = OpenFile("foo.txt", blockSize = 1024);
>
> This would be much easier to write, much easier to use, and much more
> efficient - it is just syntactic sugar for normal function calling as
> the compiler would re-arrange the parameters in the correct non-named
> order.
Adding support in the core language for named parameters would only make
them easier to write because there would be no need to define a named
parameter idiom class. Yet, they aren't hard to define to begin with.
Named parameters in the core language aren't any easier to use than a named
parameter idiom class. For example:
f = OpenFile("foo.txt", blockSize = 1024);
vs
f = OpenFile("foo.txt", OpenFile::Param().blockSize(1024) );
or
f = OpenFile(OpenFile::Param().file("foo.txt").blockSize(1024) );
In addition, the named parameter idiom makes it possible to define methods
which operate on multiple parameters. For example, in the above example,
it's possible to define the following member function:
OpenFile::Param &OpenFile::Param::defaultFile(std::string &file) {
/*stuff*/}
This would mean that the following examples would be equivalent:
f = OpenFile(OpenFile::Param().file("foo.txt").blockSize(1024) );
f = OpenFile(OpenFile::Param().defaultFile("foo.txt") );
You can't do that with named parameters.
> In fact, the OpenFile class would not be needed at all - it is just an
> artificial class to get pseudo named parameters for an OpenFile
> /function/ (or method of the main File class).
There is no way to be sure about that. For example, OpenFile might be an
implementation of a strategy pattern.
> One of the strengths of C++ is that you can add a lot of features to the
> language by using templates, classes, and the pre-processor (just look
> at boost for examples). And the standards committee is rightly
> reluctant to add new features to the basic language if the same
> functionality can be implemented using the existing language. But a big
> weakness of C++ is that this philosophy is sometimes used as an excuse
> not to fill in gaps in the language.
I don't know if the C++ standard committee is reluctant to add new features.
If I'm not mistaken, the only instance where new features stopped being
considered was near the end of C++0x's standardization process, and even
then these suggestions were only postponed so that C++11 could be finally
published without any further delay.
In addition, if the C++ standard committee was reluctant to add new features
then they wouldn't be opened to new proposals:
http://isocpp.org/std/submit-a-proposal
> /Real/ named parameters would be
> easy to add to the language specifications, and a simple matter to
> implement for compiler developers.
I really doubt that named parameters would be easy to add to the language,
considering C++'s support for function overloading. Take, for example, the
following class:
<code>
struct Bar
{
void baz(int a, float b) { /* nothing happens */ }
void baz(float b, int a) { /* the enter key blows up */ }
};
int main(void)
{
Bar bar;
bar.baz( a = 10, b = 20 );
return 0;
}
</code>
What member function do you expect to be called?
> But instead we have got this "named
> parameter idiom" rather than proper support.
C++ doesn't support named parameters in the core language, but to go from
there and claim that the named parameter idiom isn't "proper support" is a
bit of a stretch. The only claim that you can really make is that named
parameters aren't supported directly in the core language, or that C++ isn't
exactly like, say, Python. Yet, none of those complains are valid or
reasonable.
Rui Maciel
Article: 154753On 2013-01-04, David Brown <david@westcontrol.removethisbit.com> sent: |-----------------------------------------------------------------------| |"[. . .] | | | |It is also worth noting that this "paper" seems to be just a student | |exercise that has somehow "escaped" into public domain - it makes no | |claims about trying to compare a realistic choice of languages. A HDL | |language comparison that doesn't even include Verilog cannot be taken | |seriously. I'm sure the student gave a good answer to the question his| |teacher posed, but don't read more into it than that." | |-----------------------------------------------------------------------| Verilog is ignored in many publications produced by a lot of so-called research in Europe. Yours sincerely, Colin Paul GlosterArticle: 154754
On 1/4/2013 2:56 AM, David Brown wrote: > On 03/01/13 23:50, Martin Schoeberl wrote: >> Christopher Felton <abc@def.org> wrote: >>> On 1/2/13 8:35 PM, Martin Schoeberl wrote: >>>> Christopher Felton <abc@def.org> wrote: >>>>> On 12/30/12 4:42 PM, Jon Elson wrote: >>>>>> Martin Schoeberl wrote: >>>>>> >>>>>>> Jon Elson <elson@pico-systems.com> wrote: >>>>>>>> Martin Schoeberl wrote: >>>>>>>> >>>>>>>> >>>>>>>>> A good comparison would be to do one HW design, e.g. a standard MIPS >>>>>>>>> pipeline, in all languages and compare the efficiency of the language >>>>>>>>> and the efficiency of the resulting HW implementation. >>>>>>>> >>>>>>>> MAN, that would be a landmark achievement! You might even go down >>>>>>>> in history as the author of "the Schoeberl paper". Even if it wouldn't >>>>>>>> change the (horrible) way I do designs now, it would sure be an >>>>>>>> interesting read. >>>>>>>> >>>>>>>> Jon >>>>>>> >>>>>>> Maybe I should tone this done. Yes, it would be nice to have this example. >>>>>>> It would also be nice to have this comparison in a paper. Let's see where >>>>>>> this leads. >>>>>>> >>>>>>> I will start on a smaller scale with simpler examples. Maybe up to a very >>>>>>> simple processor that I already have in VHDL. Will keep you informed along >>>>>>> the >>>>>>> path. If anybody would like to join this effort we can setup a repository. >>>>>> Great, and thanks for putting in the effort! >>>>>> Even a VERY simple example of the same function in several languages >>>>>> could be quite instructive. But, a somewhat larger project would >>>>>> be more likely to expose some of the deficiencies of this or that >>>>>> language. >>>>>> >>>>>> Jon >>>>>> >>>>> >>>>> You might be interested in this rebuttal to a >>>>> paper that compared a couple non-traditional HDLs. >>>>> >>>>> http://thread.gmane.org/gmane.comp.python.myhdl/2701 >>>>> >>>>> Regards, >>>>> Chris >>>> >>>> This is definitely interesting, but the link is dead :-( >>>> >>>> Do you have the title of that paper so I can try to Google it. >>>> >>>> Cheers, >>>> Martin >>>> >>> >>> I believe this is the original paper: >>> http://referaat.cs.utwente.nl/conference/17/paper/7344/comparing-hardware-description-languages.pdf >>> >>> But note the objections in the previous thread I posted. The comparisons >>> are incomplete (comparing non-working HDL, the author(s) didn't learn >>> enough of the languages). >>> >>> Regards, >>> Chris >> >> Thanks for pointing me to the paper. It is not a very exciting one and I >> agree on all critics. I did not look into all details, but I think the FIFO >> example is also broken. There is only one pointer, but one would need a >> read and a write pointer. >> >> Untested code and no synthesis results. Ok, it is just a student >> conference. >> >> With this paper as reference it should be easy to do better ;-) >> >> Cheers, >> Martin >> > > It is also worth noting that this "paper" seems to be just a student > exercise that has somehow "escaped" into public domain - it makes no > claims about trying to compare a realistic choice of languages. A HDL > language comparison that doesn't even include Verilog cannot be taken > seriously. I'm sure the student gave a good answer to the question his > teacher posed, but don't read more into it than that. > > As you note, student paper escaped. But I do think it would be reasonable to use only VHDL or Verilog when comparing the plethora of alternative HDLs. I believe the author was trying to explore non-traditional HDLs (i.e. other than V*). I don't think many would simply accept the conclusions but it is a starting point for a conversation: how to compare HDLs? How would one objectively quantify different HDLs. What is being determined: speed of design entry, maintenance, QoR, testabilty, ... ? Regards, ChrisArticle: 154755
Martin Schoeberl <martin@jopdesign.com> wrote: >"garyr" <garyr@fidalgo.net> wrote: >> "Martin Schoeberl" <martin@jopdesign.com> wrote in message >> news:1621424063378432030.694310martin-jopdesign.com@reader.albasani.net... >>> Hi all, >>> >>> started to look into alternatives to Verilog and VHDL and >>> stumbled over chisel from UCB: >>> http://chisel.eecs.berkeley.edu/ >>> >>> Any experiences and comment on this language? >>> >>> Looks like some challenge for me as it involves practically >>> learning 3 new languages at once: chisel itself, Scala on which >>> it is based, and Verilog, which is produced (I'm used to VHDL). >>> >>> Cheers, >>> Martin >>> >>> PS: I was *very* long absent from this group ;-) >>> >> >> You might find this interesting: http://www.myhdl.org > >Thanks for pointing this out, although it was not the 'real' answer to >my question ;-) > >I'm already looking at MyHDL and some other projects. chisel just lookes >most promising at the moment. Maybe I change my mind. > >A good comparison would be to do one HW design, e.g. a standard MIPS >pipeline, in all languages and compare the efficiency of the language and >the efficiency of the resulting HW implementation. The problem with that approach is that you need to be proficient in all the languages you try. Usually this isn't the case so language comparisons are mostly useless. I'd stick to VHDL and learn how to use it more efficiently. IMHO very few people are using the full potential VHDL is offering. A lot of people still think in gates and counters and produce netlists instead of an abstract description of what they want to implement. My prediction: The only HDL which will replace VDHL and Verilog has to be based on a C style syntax. Look at C#, Java, PHP. All these languages have gained a lot of popularity because it is based on what people already know. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 154756
(I think we are getting way off topic here, and I also doubt that we'll
get very far in convincing each other of our point of view. So if you
don't want to bother writing more here, I will not feel snubbed - and if
you /do/ want to carry on, then perhaps we should re-start the thread in
comp.lang.c++).
On 04/01/13 14:36, Rui Maciel wrote:
> David Brown wrote:
>
>> C and C++ programmers who have experience with other programming
>> languages and know what named parameters are, /will/ hold their breaths
>> and hope that they get implemented properly in the languages. (C would
>> need support for C++ - style default parameters first, of course.)
>
> C, since C99, has designated initializers for aggregate types, which helps
> pull off this syntactic sugar.
>
> <code>
> #include <stdio.h>
>
> struct test_parameter
> {
> int a;
> float b;
> };
>
> void test(struct test_parameter p)
> {
> printf("testing a: %d, b: %f\n", p.a, p.b);
> }
>
>
> int main(void)
> {
> test((struct test_parameter){.a = 1, .b = 2.0f});
> test((struct test_parameter){.b = 5.0f, .a = 4});
> return 0;
> }
> </code>
>
> C++ doesn't support C's designated initializers, so this trick can't be
> pulled with it. Nevertheless, as I've mentioned previously, the named
> parameter idiom can be used for the exact same effect.
The named parameter idiom can give a /similar/ effect - but might be
less efficient (code space and run-time speed), and is certainly
massively less compact and elegant in the source code.
The use of C structs with designated initialisers gives a much more
elegant solution than the C++ "named parameter idiom". But it is still
far from ideal - as well as requiring a bit more unnecessary coding, you
might get a less efficient implementation (depending on the compiler and
the target, passing a struct is likely to be less efficient than passing
arguments directly, and it limits the compiler's optimiser).
And as you note, C++ doesn't support designated initialisers for
structs. I can't see any rational reason why it should not, but I
suppose the C++ standards people have some reason (other than to annoy
people who want to write code that works as C and C++).
>
> This means that it isn't true that C++ forces anyone to design a class with
> a bazzilion parameters. If having to pass more than a couple of parameters
> to a constructor becomes a problem, there are plenty of ways to avoid that.
> For example, it is also possible to use Boost's ad-hoc implementation of
> named parameters:
>
> http://www.boost.org/doc/libs/1_44_0/libs/parameter/doc/html/index.html
>
> What I tend to use to avoid having to define multiple versions of the same
> constructor or a constructor with a bazzilion parameters is to use a named
> parameter idiom to define a parameter class for the constructor, such as:
>
> <code>
> #include <iostream>
>
> class Foo
> {
> int a;
> float b;
>
> public:
> struct Parameters
> {
> int a;
> float b;
> Parameters & length(int const l) {a = l; return
> *this;} ;
> Parameters & frequency(float const f) {b = f; return
> *this;};
> };
>
> Foo(Parameters const ¶m): a(param.a), b(param.b) { std::cout <<
> "a: " << a << ", b: " << b << std::endl;}
> };
>
>
> int main(void)
> {
> Foo( Foo::Parameters().length(2).frequency(4));
> Foo( Foo::Parameters().frequency(6).length(3));
> return 0;
> }
> </code>
>
I can see how this all works - and I can see how the named parameter
idiom (or related solutions) can sometimes be better than nothing.
But I /cannot/ see why anyone would prefer a solution above instead of:
class Foo
{
int a;
float b;
public:
Foo(int length, float frequency) : a(length), b(frequency) { }
};
int main(void) {
Foo(length = 2, frequency = 4);
Foo(frequency = 5, length = 3);
}
Is there any good reason why that syntax is not supported by C++ (and C,
though it is much more useful if support for default parameters were added)?
I suppose it might be argued that "Foo(.length = 2, .frequency = 4);"
would be more consistent with C's designated initialisers for structs -
I think most users would be happy either way.
>
>> The link you gave illustrates the problem perfectly. Here there is an
>> "OpenFile" class with lots of inline member functions to act as pretend
>> named parameters. It's a lot of mess for no good reason
>
> The member functions don't need to be inline. The only requirement is that
> they return a reference to the named parameter object.
>
> If you believe that having to deal with more than a couple of parameters
> represents a problem then providing a solution to this problem is a good
> reason to use them. And the "lot of mess" comment is at best unreasonable.
>
Look above at your "Foo" class, and my "Foo" class. Every character
that you wrote, but that I did not write, fills the source code
unnecessarily. In my suggested code, /nothing/ extra needs to be added
to support designated parameters - they are totally free to the
programmer (both in the source code, and in generated code space and
time). So I think a "lot of mess" is justified - your solution uses
more lines of code to implement the named parameters than to implement
the class (though clearly the relative impact would be less in real
code). As always, extra code like this means less readability and more
effort in programming.
>
>> - if named
>> parameters were part of the language, then it would all be implemented
>> in a single simple constructor:
>>
>> OpenFile::OpenFile(std::string const& filename, readonly = false,
>> createIfNotExist = false, blockSize = 4096u) ...
>>
>> And it would be called with something like:
>> f = OpenFile("foo.txt", blockSize = 1024);
>>
>> This would be much easier to write, much easier to use, and much more
>> efficient - it is just syntactic sugar for normal function calling as
>> the compiler would re-arrange the parameters in the correct non-named
>> order.
>
> Adding support in the core language for named parameters would only make
> them easier to write because there would be no need to define a named
> parameter idiom class. Yet, they aren't hard to define to begin with.
>
> Named parameters in the core language aren't any easier to use than a named
> parameter idiom class. For example:
>
> f = OpenFile("foo.txt", blockSize = 1024);
>
> vs
>
> f = OpenFile("foo.txt", OpenFile::Param().blockSize(1024) );
>
> or
>
> f = OpenFile(OpenFile::Param().file("foo.txt").blockSize(1024) );
>
Can't you see that my suggestion is shorter and clearer? You could
argue that it is not /much/ shorter, or not /much/ clearer - that's a
question of taste and experience.
Can't you see that my suggestion is completely /free/ for the programmer
- they get the benefits of named parameters for /every/ function and
method, without any changes or additions to the source code? Clearly,
adding named parameter idiom classes to a significant number of
functions in your code would overwhelm your code with "bookkeeping" code
to enable the idiom.
I can well agree that the current named parameter idiom has some uses,
where the clarity for the caller over normal positional parameters
justifies the effort of implementing it. But adding it to the core
language would be far better.
>
> In addition, the named parameter idiom makes it possible to define methods
> which operate on multiple parameters. For example, in the above example,
> it's possible to define the following member function:
>
> OpenFile::Param &OpenFile::Param::defaultFile(std::string &file) {
> /*stuff*/}
>
>
> This would mean that the following examples would be equivalent:
>
> f = OpenFile(OpenFile::Param().file("foo.txt").blockSize(1024) );
> f = OpenFile(OpenFile::Param().defaultFile("foo.txt") );
>
> You can't do that with named parameters.
>
I don't quite get your example here, but I can certainly see that there
are times you might still want to use the idiom. Perhaps setting the
parameter would have other side-effects, or perhaps you want multiple
arguments in the parameter function.
But obviously there is nothing in my suggested language change that
would limit the use of named parameter idiom classes. Simple named
parameters would cover 99% of the use cases - and you can still use the
old idiom classes for the remaining 1%.
>
>> In fact, the OpenFile class would not be needed at all - it is just an
>> artificial class to get pseudo named parameters for an OpenFile
>> /function/ (or method of the main File class).
>
> There is no way to be sure about that. For example, OpenFile might be an
> implementation of a strategy pattern.
>
>
>> One of the strengths of C++ is that you can add a lot of features to the
>> language by using templates, classes, and the pre-processor (just look
>> at boost for examples). And the standards committee is rightly
>> reluctant to add new features to the basic language if the same
>> functionality can be implemented using the existing language. But a big
>> weakness of C++ is that this philosophy is sometimes used as an excuse
>> not to fill in gaps in the language.
>
> I don't know if the C++ standard committee is reluctant to add new features.
> If I'm not mistaken, the only instance where new features stopped being
> considered was near the end of C++0x's standardization process, and even
> then these suggestions were only postponed so that C++11 could be finally
> published without any further delay.
>
> In addition, if the C++ standard committee was reluctant to add new features
> then they wouldn't be opened to new proposals:
>
> http://isocpp.org/std/submit-a-proposal
They /are/ reluctant to add new features to the core language - and that
is normally a good thing, as the language is complicated enough as it
is. They will add new features if they feel they need to - such as
lambdas and new reference types in C++11. But they insist on a lot of
justification.
Perhaps no one has submitted a proposal for named parameters to the
committee - I know /I/ certainly have not done so. Maybe everyone
thinks it is such an obvious, cost-free and useful feature that someone
else must have submitted it already.
>
>
>> /Real/ named parameters would be
>> easy to add to the language specifications, and a simple matter to
>> implement for compiler developers.
>
> I really doubt that named parameters would be easy to add to the language,
> considering C++'s support for function overloading. Take, for example, the
> following class:
>
> <code>
> struct Bar
> {
> void baz(int a, float b) { /* nothing happens */ }
> void baz(float b, int a) { /* the enter key blows up */ }
> };
>
> int main(void)
> {
> Bar bar;
> bar.baz( a = 10, b = 20 );
> return 0;
> }
> </code>
>
> What member function do you expect to be called?
Code like that is already broken - which member function should be
called for bar.baz(10, 20)? (Even if the answer is well-defined in C++
at the moment, it is still wrong IMHO because the code is unclear.)
But you are certainly right here - there will be complications in the
face of function overloading, that will make it harder to implement than
I first imagined. I can't see it being an impossible problem, however -
but there will be some cases (like that example) when the only decent
thing the compiler can do is issue an error about ambiguous overloads.
>
>
>
>> But instead we have got this "named
>> parameter idiom" rather than proper support.
>
> C++ doesn't support named parameters in the core language, but to go from
> there and claim that the named parameter idiom isn't "proper support" is a
> bit of a stretch. The only claim that you can really make is that named
> parameters aren't supported directly in the core language, or that C++ isn't
> exactly like, say, Python. Yet, none of those complains are valid or
> reasonable.
Well, I think the second and third claims here /are/ valid and
reasonable - named parameters are clearly not supported in the core C++
language, and the way you make named parameters work in today's C++ is
clearly not the same as in Python.
And as for my main claim that the named parameter idiom is not "proper
support" for named parameters - that's a matter of opinion, and our
opinions obviously differ here.
mvh.,
David
>
>
> Rui Maciel
>
Article: 154757Hello, I'm new in FPGA world. I read some VHDL books and I can create not much advanced, but working projects. Most of my designs I tested on Spartan3. And the only constraints I always use are LOC to assign pins. It works, but I know that in more advanced projects it is necessary to use other constraints. I read Xilinx tutorials, but don't feel it from them. I'm trying to find something where it is explained on some real examples, maybe some examples with growing level of difficulty. Do you know some book, pdf, website? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154758
>Hello, > >I'm new in FPGA world. I read some VHDL books and I can create not much >advanced, but working projects. Most of my designs I tested on Spartan3. >And the only constraints I always use are LOC to assign pins. >It works, but I know that in more advanced projects it is necessary to use >other constraints. I read Xilinx tutorials, but don't feel it from them. > >I'm trying to find something where it is explained on some real examples, >maybe some examples with growing level of difficulty. >Do you know some book, pdf, website? > > > >--------------------------------------- >Posted through http://www.FPGARelated.com > I checked on Linux and Windows, on different browsers and see that my post's lines aren't wrapped. Sorry for that, don't know why. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154759
On Fri, 04 Jan 2013 16:35:14 +0100, David Brown wrote:
> (I think we are getting way off topic here, and I also doubt that we'll
> get very far in convincing each other of our point of view. So if you
> don't want to bother writing more here, I will not feel snubbed - and if
> you /do/ want to carry on, then perhaps we should re-start the thread in
> comp.lang.c++).
>
> On 04/01/13 14:36, Rui Maciel wrote:
>> David Brown wrote:
>>
>>> C and C++ programmers who have experience with other programming
>>> languages and know what named parameters are, /will/ hold their
>>> breaths and hope that they get implemented properly in the languages.
>>> (C would need support for C++ - style default parameters first, of
>>> course.)
>>
>> C, since C99, has designated initializers for aggregate types, which
>> helps pull off this syntactic sugar.
>>
>> <code>
>> #include <stdio.h>
>>
>> struct test_parameter {
>> int a;
>> float b;
>> };
>>
>> void test(struct test_parameter p)
>> {
>> printf("testing a: %d, b: %f\n", p.a, p.b);
>> }
>>
>>
>> int main(void)
>> {
>> test((struct test_parameter){.a = 1, .b = 2.0f});
>> test((struct test_parameter){.b = 5.0f, .a = 4});
>> return 0;
>> }
>> </code>
>>
>> C++ doesn't support C's designated initializers, so this trick can't be
>> pulled with it. Nevertheless, as I've mentioned previously, the named
>> parameter idiom can be used for the exact same effect.
>
> The named parameter idiom can give a /similar/ effect - but might be
> less efficient (code space and run-time speed), and is certainly
> massively less compact and elegant in the source code.
>
> The use of C structs with designated initialisers gives a much more
> elegant solution than the C++ "named parameter idiom". But it is still
> far from ideal - as well as requiring a bit more unnecessary coding, you
> might get a less efficient implementation (depending on the compiler and
> the target, passing a struct is likely to be less efficient than passing
> arguments directly, and it limits the compiler's optimiser).
>
> And as you note, C++ doesn't support designated initialisers for
> structs. I can't see any rational reason why it should not, but I
> suppose the C++ standards people have some reason (other than to annoy
> people who want to write code that works as C and C++).
>
>
>
>> This means that it isn't true that C++ forces anyone to design a class
>> with a bazzilion parameters. If having to pass more than a couple of
>> parameters to a constructor becomes a problem, there are plenty of ways
>> to avoid that. For example, it is also possible to use Boost's ad-hoc
>> implementation of named parameters:
>>
>> http://www.boost.org/doc/libs/1_44_0/libs/parameter/doc/html/index.html
>>
>> What I tend to use to avoid having to define multiple versions of the
>> same constructor or a constructor with a bazzilion parameters is to use
>> a named parameter idiom to define a parameter class for the
>> constructor, such as:
>>
>> <code>
>> #include <iostream>
>>
>> class Foo {
>> int a;
>> float b;
>>
>> public:
>> struct Parameters {
>> int a;
>> float b;
>> Parameters & length(int const l) {a = l; return
>> *this;} ;
>> Parameters & frequency(float const f) {b = f; return
>> *this;};
>> };
>>
>> Foo(Parameters const ¶m): a(param.a), b(param.b) {
>> std::cout <<
>> "a: " << a << ", b: " << b << std::endl;}
>> };
>>
>>
>> int main(void)
>> {
>> Foo( Foo::Parameters().length(2).frequency(4));
>> Foo( Foo::Parameters().frequency(6).length(3));
>> return 0;
>> }
>> </code>
>>
>>
> I can see how this all works - and I can see how the named parameter
> idiom (or related solutions) can sometimes be better than nothing.
>
> But I /cannot/ see why anyone would prefer a solution above instead of:
>
> class Foo {
> int a;
> float b;
> public:
> Foo(int length, float frequency) : a(length), b(frequency) { }
> };
>
> int main(void) {
> Foo(length = 2, frequency = 4);
> Foo(frequency = 5, length = 3);
> }
>
>
> Is there any good reason why that syntax is not supported by C++ (and C,
> though it is much more useful if support for default parameters were
> added)?
>
> I suppose it might be argued that "Foo(.length = 2, .frequency = 4);"
> would be more consistent with C's designated initialisers for structs -
> I think most users would be happy either way.
>
>
>
>
>
>>> The link you gave illustrates the problem perfectly. Here there is an
>>> "OpenFile" class with lots of inline member functions to act as
>>> pretend named parameters. It's a lot of mess for no good reason
>>
>> The member functions don't need to be inline. The only requirement is
>> that they return a reference to the named parameter object.
>>
>> If you believe that having to deal with more than a couple of
>> parameters represents a problem then providing a solution to this
>> problem is a good reason to use them. And the "lot of mess" comment is
>> at best unreasonable.
>>
>>
> Look above at your "Foo" class, and my "Foo" class. Every character
> that you wrote, but that I did not write, fills the source code
> unnecessarily. In my suggested code, /nothing/ extra needs to be added
> to support designated parameters - they are totally free to the
> programmer (both in the source code, and in generated code space and
> time). So I think a "lot of mess" is justified - your solution uses
> more lines of code to implement the named parameters than to implement
> the class (though clearly the relative impact would be less in real
> code). As always, extra code like this means less readability and more
> effort in programming.
>
>
>>> - if named parameters were part of the language, then it would all be
>>> implemented in a single simple constructor:
>>>
>>> OpenFile::OpenFile(std::string const& filename, readonly = false,
>>> createIfNotExist = false, blockSize = 4096u) ...
>>>
>>> And it would be called with something like:
>>> f = OpenFile("foo.txt", blockSize = 1024);
>>>
>>> This would be much easier to write, much easier to use, and much more
>>> efficient - it is just syntactic sugar for normal function calling as
>>> the compiler would re-arrange the parameters in the correct non-named
>>> order.
>>
>> Adding support in the core language for named parameters would only
>> make them easier to write because there would be no need to define a
>> named parameter idiom class. Yet, they aren't hard to define to begin
>> with.
>>
>> Named parameters in the core language aren't any easier to use than a
>> named parameter idiom class. For example:
>>
>> f = OpenFile("foo.txt", blockSize = 1024);
>>
>> vs
>>
>> f = OpenFile("foo.txt", OpenFile::Param().blockSize(1024) );
>>
>> or
>>
>> f = OpenFile(OpenFile::Param().file("foo.txt").blockSize(1024) );
>>
>>
> Can't you see that my suggestion is shorter and clearer? You could
> argue that it is not /much/ shorter, or not /much/ clearer - that's a
> question of taste and experience.
>
> Can't you see that my suggestion is completely /free/ for the programmer
> - they get the benefits of named parameters for /every/ function and
> method, without any changes or additions to the source code? Clearly,
> adding named parameter idiom classes to a significant number of
> functions in your code would overwhelm your code with "bookkeeping" code
> to enable the idiom.
>
>
> I can well agree that the current named parameter idiom has some uses,
> where the clarity for the caller over normal positional parameters
> justifies the effort of implementing it. But adding it to the core
> language would be far better.
>
>
>> In addition, the named parameter idiom makes it possible to define
>> methods which operate on multiple parameters. For example, in the
>> above example, it's possible to define the following member function:
>>
>> OpenFile::Param &OpenFile::Param::defaultFile(std::string &file) {
>> /*stuff*/}
>>
>>
>> This would mean that the following examples would be equivalent:
>>
>> f = OpenFile(OpenFile::Param().file("foo.txt").blockSize(1024) );
>> f = OpenFile(OpenFile::Param().defaultFile("foo.txt") );
>>
>> You can't do that with named parameters.
>>
>>
> I don't quite get your example here, but I can certainly see that there
> are times you might still want to use the idiom. Perhaps setting the
> parameter would have other side-effects, or perhaps you want multiple
> arguments in the parameter function.
>
> But obviously there is nothing in my suggested language change that
> would limit the use of named parameter idiom classes. Simple named
> parameters would cover 99% of the use cases - and you can still use the
> old idiom classes for the remaining 1%.
>
>
>
>>> In fact, the OpenFile class would not be needed at all - it is just an
>>> artificial class to get pseudo named parameters for an OpenFile
>>> /function/ (or method of the main File class).
>>
>> There is no way to be sure about that. For example, OpenFile might be
>> an implementation of a strategy pattern.
>>
>>
>>> One of the strengths of C++ is that you can add a lot of features to
>>> the language by using templates, classes, and the pre-processor (just
>>> look at boost for examples). And the standards committee is rightly
>>> reluctant to add new features to the basic language if the same
>>> functionality can be implemented using the existing language. But a
>>> big weakness of C++ is that this philosophy is sometimes used as an
>>> excuse not to fill in gaps in the language.
>>
>> I don't know if the C++ standard committee is reluctant to add new
>> features.
>> If I'm not mistaken, the only instance where new features stopped being
>> considered was near the end of C++0x's standardization process, and
>> even then these suggestions were only postponed so that C++11 could be
>> finally published without any further delay.
>>
>> In addition, if the C++ standard committee was reluctant to add new
>> features then they wouldn't be opened to new proposals:
>>
>> http://isocpp.org/std/submit-a-proposal
>
> They /are/ reluctant to add new features to the core language - and that
> is normally a good thing, as the language is complicated enough as it
> is. They will add new features if they feel they need to - such as
> lambdas and new reference types in C++11. But they insist on a lot of
> justification.
>
> Perhaps no one has submitted a proposal for named parameters to the
> committee - I know /I/ certainly have not done so. Maybe everyone
> thinks it is such an obvious, cost-free and useful feature that someone
> else must have submitted it already.
>
>
>>
>>> /Real/ named parameters would be easy to add to the language
>>> specifications, and a simple matter to implement for compiler
>>> developers.
>>
>> I really doubt that named parameters would be easy to add to the
>> language, considering C++'s support for function overloading. Take,
>> for example, the following class:
>>
>> <code>
>> struct Bar {
>> void baz(int a, float b) { /* nothing happens */ }
>> void baz(float b, int a) { /* the enter key blows up */ }
>> };
>>
>> int main(void)
>> {
>> Bar bar;
>> bar.baz( a = 10, b = 20 );
>> return 0;
>> }
>> </code>
>>
>> What member function do you expect to be called?
>
> Code like that is already broken - which member function should be
> called for bar.baz(10, 20)? (Even if the answer is well-defined in C++
> at the moment, it is still wrong IMHO because the code is unclear.)
>
> But you are certainly right here - there will be complications in the
> face of function overloading, that will make it harder to implement than
> I first imagined. I can't see it being an impossible problem, however -
> but there will be some cases (like that example) when the only decent
> thing the compiler can do is issue an error about ambiguous overloads.
>
>
>
>>
>>
>>> But instead we have got this "named parameter idiom" rather than
>>> proper support.
>>
>> C++ doesn't support named parameters in the core language, but to go
>> from there and claim that the named parameter idiom isn't "proper
>> support" is a bit of a stretch. The only claim that you can really
>> make is that named parameters aren't supported directly in the core
>> language, or that C++ isn't exactly like, say, Python. Yet, none of
>> those complains are valid or reasonable.
>
> Well, I think the second and third claims here /are/ valid and
> reasonable - named parameters are clearly not supported in the core C++
> language, and the way you make named parameters work in today's C++ is
> clearly not the same as in Python.
>
> And as for my main claim that the named parameter idiom is not "proper
> support" for named parameters - that's a matter of opinion, and our
> opinions obviously differ here.
I agree. I do embedded programming. I can't afford to bloat my code, or
slow down my execution, with workarounds like this.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Article: 154760On 1/4/2013 9:19 AM, Nico Coesel wrote: > Martin Schoeberl <martin@jopdesign.com> wrote: > >> "garyr" <garyr@fidalgo.net> wrote: >>> "Martin Schoeberl" <martin@jopdesign.com> wrote in message >>> news:1621424063378432030.694310martin-jopdesign.com@reader.albasani.net... >>>> Hi all, >>>> >>>> started to look into alternatives to Verilog and VHDL and >>>> stumbled over chisel from UCB: >>>> http://chisel.eecs.berkeley.edu/ >>>> >>>> Any experiences and comment on this language? >>>> >>>> Looks like some challenge for me as it involves practically >>>> learning 3 new languages at once: chisel itself, Scala on which >>>> it is based, and Verilog, which is produced (I'm used to VHDL). >>>> >>>> Cheers, >>>> Martin >>>> >>>> PS: I was *very* long absent from this group ;-) >>>> >>> >>> You might find this interesting: http://www.myhdl.org >> >> Thanks for pointing this out, although it was not the 'real' answer to >> my question ;-) >> >> I'm already looking at MyHDL and some other projects. chisel just lookes >> most promising at the moment. Maybe I change my mind. >> >> A good comparison would be to do one HW design, e.g. a standard MIPS >> pipeline, in all languages and compare the efficiency of the language and >> the efficiency of the resulting HW implementation. > > The problem with that approach is that you need to be proficient in > all the languages you try. Usually this isn't the case so language > comparisons are mostly useless. I'd stick to VHDL and learn how to use > it more efficiently. IMHO very few people are using the full potential > VHDL is offering. A lot of people still think in gates and counters > and produce netlists instead of an abstract description of what they > want to implement. > > My prediction: The only HDL which will replace VDHL and Verilog has to > be based on a C style syntax. Look at C#, Java, PHP. All these > languages have gained a lot of popularity because it is based on what > people already know. > I always struggle with the "C" HDL replacements. It seems like you are going the wrong direction in abstraction and ease of use language. But your argument is: There are many "C" programmers and/or folks that feel comfortable with "C" style programming. If someone can create a magical "C" like HDL language many will jump aboard ... hmmmmm Regards, ChrisArticle: 154761
David Brown <david@westcontrol.removethisbit.com> wrote: (snip) > The named parameter idiom can give a /similar/ effect - but might be > less efficient (code space and run-time speed), and is certainly > massively less compact and elegant in the source code. (snip) > Foo(length = 2, frequency = 4); > Foo(frequency = 5, length = 3); > } > Is there any good reason why that syntax is not supported by C++ (and C, > though it is much more useful if support for default parameters were added)? Because it already has a different meaning in C. Remember that = is an operator with a value, so the above assigns the value 2 to length, 4 to frequency, then passes (2, 4) to Foo. > I suppose it might be argued that "Foo(.length = 2, .frequency = 4);" > would be more consistent with C's designated initialisers for structs - > I think most users would be happy either way. This might work. Someone should post to comp.lang.c to see what they say about it. -- glenArticle: 154762
Nico Coesel <nico@puntnl.niks> wrote: > Martin Schoeberl <martin@jopdesign.com> wrote: (snip) >>A good comparison would be to do one HW design, e.g. a standard MIPS >>pipeline, in all languages and compare the efficiency of the language and >>the efficiency of the resulting HW implementation. > The problem with that approach is that you need to be proficient in > all the languages you try. Usually this isn't the case so language > comparisons are mostly useless. I'd stick to VHDL and learn how to use > it more efficiently. IMHO very few people are using the full potential > VHDL is offering. A lot of people still think in gates and counters > and produce netlists instead of an abstract description of what they > want to implement. My belief for some time has been that you have to think in terms of gates and counters or you write lousy HDL code. > My prediction: The only HDL which will replace VDHL and Verilog has to > be based on a C style syntax. Look at C#, Java, PHP. All these > languages have gained a lot of popularity because it is based on what > people already know. I suppose it depends somewhat on what type of designs you are working on. For most of what I am interested in, making it look too much like C might give people the idea that you could port a C algorithm without any thought, but the algorithms that I am interested in are completely different in systolic array hardware than in loops over arrays. -- glenArticle: 154763
Christopher Felton <nospam@nowhere.com> wrote: (snip) > I always struggle with the "C" HDL replacements. It seems like you are > going the wrong direction in abstraction and ease of use language. > But your argument is: There are many "C" programmers and/or folks that > feel comfortable with "C" style programming. If someone can create a > magical "C" like HDL language many will jump aboard ... hmmmmm Verilog isn't quite as C-like as I might think it could be. I learned many years ago the difference between Pascal (semicolon is a statement separator) and most other languages such as PL/I and C (semicolon is a statement terminator). Seems to me that verilog could have done its semicolon rules a little differently to make it more obvious to C programmers. -- glenArticle: 154764
Christopher Felton <nospam@nowhere.com> wrote: > On 1/4/2013 2:56 AM, David Brown wrote: >> On 03/01/13 23:50, Martin Schoeberl wrote: >>> Christopher Felton <abc@def.org> wrote: >>>> On 1/2/13 8:35 PM, Martin Schoeberl wrote: >>>>> Christopher Felton <abc@def.org> wrote: >>>>>> On 12/30/12 4:42 PM, Jon Elson wrote: >>>>>>> Martin Schoeberl wrote: >>>>>>> >>>>>>>> Jon Elson <elson@pico-systems.com> wrote: >>>>>>>>> Martin Schoeberl wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> A good comparison would be to do one HW design, e.g. a standard MIPS >>>>>>>>>> pipeline, in all languages and compare the efficiency of the language >>>>>>>>>> and the efficiency of the resulting HW implementation. >>>>>>>>> >>>>>>>>> MAN, that would be a landmark achievement! You might even go down >>>>>>>>> in history as the author of "the Schoeberl paper". Even if it wouldn't >>>>>>>>> change the (horrible) way I do designs now, it would sure be an >>>>>>>>> interesting read. >>>>>>>>> >>>>>>>>> Jon >>>>>>>> >>>>>>>> Maybe I should tone this done. Yes, it would be nice to have this example. >>>>>>>> It would also be nice to have this comparison in a paper. Let's see where >>>>>>>> this leads. >>>>>>>> >>>>>>>> I will start on a smaller scale with simpler examples. Maybe up to a very >>>>>>>> simple processor that I already have in VHDL. Will keep you informed along >>>>>>>> the >>>>>>>> path. If anybody would like to join this effort we can setup a repository. >>>>>>> Great, and thanks for putting in the effort! >>>>>>> Even a VERY simple example of the same function in several languages >>>>>>> could be quite instructive. But, a somewhat larger project would >>>>>>> be more likely to expose some of the deficiencies of this or that >>>>>>> language. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>> >>>>>> You might be interested in this rebuttal to a >>>>>> paper that compared a couple non-traditional HDLs. >>>>>> >>>>>> http://thread.gmane.org/gmane.comp.python.myhdl/2701 >>>>>> >>>>>> Regards, >>>>>> Chris >>>>> >>>>> This is definitely interesting, but the link is dead :-( >>>>> >>>>> Do you have the title of that paper so I can try to Google it. >>>>> >>>>> Cheers, >>>>> Martin >>>>> >>>> >>>> I believe this is the original paper: >>>> http://referaat.cs.utwente.nl/conference/17/paper/7344/comparing-hardware-description-languages.pdf >>>> >>>> But note the objections in the previous thread I posted. The comparisons >>>> are incomplete (comparing non-working HDL, the author(s) didn't learn >>>> enough of the languages). >>>> >>>> Regards, >>>> Chris >>> >>> Thanks for pointing me to the paper. It is not a very exciting one and I >>> agree on all critics. I did not look into all details, but I think the FIFO >>> example is also broken. There is only one pointer, but one would need a >>> read and a write pointer. >>> >>> Untested code and no synthesis results. Ok, it is just a student >>> conference. >>> >>> With this paper as reference it should be easy to do better ;-) >>> >>> Cheers, >>> Martin >>> >> >> It is also worth noting that this "paper" seems to be just a student >> exercise that has somehow "escaped" into public domain - it makes no >> claims about trying to compare a realistic choice of languages. A HDL >> language comparison that doesn't even include Verilog cannot be taken >> seriously. I'm sure the student gave a good answer to the question his >> teacher posed, but don't read more into it than that. >> >> > > As you note, student paper escaped. But I do think > it would be reasonable to use only VHDL or Verilog > when comparing the plethora of alternative HDLs. I > believe the author was trying to explore non-traditional > HDLs (i.e. other than V*). > > I don't think many would simply accept the conclusions but > it is a starting point for a conversation: how to compare > HDLs? How would one objectively quantify different HDLs. > What is being determined: speed of design entry, maintenance, > QoR, testabilty, ... ? Yes, this is not an easy question. However, this is also a reason to attack this question. Maybe by some discussions here. I personally want to explore alternatives ti VHDL and Verilog. I think it is time for new languages, now. We still use V*, but now as intermediate language to feed the design tools. Cheers, Martin > > Regards, > ChrisArticle: 154765
pavel.m wrote: >> Hello, >> >> I'm new in FPGA world. I read some VHDL books and I can create not much >> advanced, but working projects. Most of my designs I tested on Spartan3. >> And the only constraints I always use are LOC to assign pins. >> It works, but I know that in more advanced projects it is necessary to > use >> other constraints. I read Xilinx tutorials, but don't feel it from them. >> >> I'm trying to find something where it is explained on some real examples, >> maybe some examples with growing level of difficulty. >> Do you know some book, pdf, website? >> >> >> >> --------------------------------------- >> Posted through http://www.FPGARelated.com >> > > I checked on Linux and Windows, on different browsers and see that my > post's lines aren't wrapped. Sorry for that, don't know why. > > --------------------------------------- > Posted through http://www.FPGARelated.com Did you look at the Xilinx user forum. There is a Blog section and in there is a 5-part (IIRC) series of articles about timing constraints. I definitely agree that the Constraints Guide is very hard to use, mostly because the "examples" don't show a complete constraint, but rather a strange BNF-like definition of the constraint syntax. I find that I very often look through UCF files of old projects to see how the constraint is actually defined. You could of course use the constraints editor from the Xilinx GUI, but I've found that it tends to trash my UCF files, so I generally stay away from it. -- GaborArticle: 154766
On Thursday, December 6, 2012 4:09:24 PM UTC-5, Vectorblox_rob wrote: > We are looking for testers/evaluators of our newly released MXP Matrix I am curious, since both Altera and Xilinx pushing hard with embedded hard Arm core, any plans to support it along with Nios/uBlaze? And specifically where does it fit in with other HLS support on either platform. Thanks Best Regards.Article: 154767
>Did you look at the Xilinx user forum. There is a Blog >section and in there is a 5-part (IIRC) series of articles >about timing constraints. I definitely agree that the >Constraints Guide is very hard to use, mostly because the >"examples" don't show a complete constraint, but rather >a strange BNF-like definition of the constraint syntax. >I find that I very often look through UCF files of old projects >to see how the constraint is actually defined. > >You could of course use the constraints editor from the Xilinx >GUI, but I've found that it tends to trash my UCF files, so >I generally stay away from it. > >-- Gabor > That looks very useful. I have to read and understand it. Thank you. Maybe you have some idea how to create not complex example where I could see that it works only with constraints? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154768
some snips >> >> I don't think many would simply accept the conclusions but >> it is a starting point for a conversation: how to compare >> HDLs? How would one objectively quantify different HDLs. >> What is being determined: speed of design entry, maintenance, >> QoR, testabilty, ... ? > > > Yes, this is not an easy question. However, this is also a reason > to attack this question. Maybe by some discussions here. > > I personally want to explore alternatives ti VHDL and Verilog. > I think it is time for new languages, now. We still use V*, but > now as intermediate language to feed the design tools. Some status update: having now the BeMicro FPGA board up and running for comparison in HW. It does blink nicely in VHDL ;-) Next step MyHDL. Don't know jet if I like this dynamic typing. Hello world simulation was a very quick start! Getting MyHdL in to HW was always tricky, However, using V* as an intermediate language might be a quite good idea. Cheers, MartinArticle: 154769
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Nico Coesel <nico@puntnl.niks> wrote: >> Martin Schoeberl <martin@jopdesign.com> wrote: > >(snip) >>>A good comparison would be to do one HW design, e.g. a standard MIPS >>>pipeline, in all languages and compare the efficiency of the language and >>>the efficiency of the resulting HW implementation. > >> The problem with that approach is that you need to be proficient in >> all the languages you try. Usually this isn't the case so language >> comparisons are mostly useless. I'd stick to VHDL and learn how to use >> it more efficiently. IMHO very few people are using the full potential >> VHDL is offering. A lot of people still think in gates and counters >> and produce netlists instead of an abstract description of what they >> want to implement. > >My belief for some time has been that you have to think in terms of >gates and counters or you write lousy HDL code. That sounds like an assembly versus C discussion. In reality designs get so big these days that hand optimising the last gate from a design costs way more than using a bigger FPGA or ASIC. Besides that a high level language usually offers a more structured approach which should result in better maintainability, platform independance, re-usability, etc. Just let the synthesizer deal with platform specifics and optimisation. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 154770
On Dec 29 2012, 10:55=A0pm, Christopher Felton <a...@def.org> wrote: > On 12/28/12 11:25 PM, Martin Schoeberl wrote: > > > > > > > > > > > "garyr" <ga...@fidalgo.net> wrote: > >> "Martin Schoeberl" <mar...@jopdesign.com> wrote in message > >>news:1621424063378432030.694310martin-jopdesign.com@reader.albasani.net= ... > >>> Hi all, > > >>> started to look into alternatives to Verilog and VHDL and > >>> stumbled over chisel from UCB: > >>>http://chisel.eecs.berkeley.edu/ > > >>> Any experiences and comment on this language? > > >>> Looks like some challenge for me as it involves practically > >>> learning 3 new languages at once: chisel itself, Scala on which > >>> it is based, and Verilog, which is produced (I'm used to VHDL). > > >>> Cheers, > >>> Martin > > >>> PS: I was *very* long absent from this group ;-) > > >> You might find this interesting: =A0http://www.myhdl.org > > > Thanks for pointing this out, although it was not the 'real' answer to > > my question ;-) > > > I'm already looking at MyHDL and some other projects. chisel just looke= s > > most promising at the moment. Maybe I change my mind. > > > A good comparison would be to do one HW design, e.g. a standard MIPS > > pipeline, in all languages and compare the efficiency of the language a= nd > > the efficiency of the resulting HW implementation. > > > Martin > > Typically to do a comparison you have to have an example/project fairly > limited in scope. =A0It is hard to realize the benefits with such small > examples. =A0A language might have a /nice/ description for example "A" > but is horrible at parametrization or it can be difficult to connect > many modules or fails miserably at example "B" and "C". > > I am not familiar with Chisel and Scala and cannot comment directly. =A0I > am familiar with MyHDL and I have used MyHDL successfully for commercial > and independent projects. > > Regards, > Chris Can you list 2-3 most important productivity enhancements that MyHDL gave you over VHDL?Article: 154771
Nico Coesel <nico@puntnl.niks> wrote: (snip, I wrote) >>My belief for some time has been that you have to think in terms of >>gates and counters or you write lousy HDL code. > That sounds like an assembly versus C discussion. Maybe. But note that I said think. I believe that C programmers who have previously written in assembler write better C than those who haven't. (Well, maybe on average.) Assembler programmers are more used to thinking in terms of addresses, and so make better use of C pointers. > In reality designs > get so big these days that hand optimising the last gate from a design > costs way more than using a bigger FPGA or ASIC. Yes you don't need to optimize the last gate from a design, just as you don't need to optimize the last instruction in assembler or C programming. In a modular design, the lowest level modules might need to be gate optimized, though likely not to the last gate. > Besides that a high > level language usually offers a more structured approach which should > result in better maintainability, platform independance, re-usability, > etc. Just let the synthesizer deal with platform specifics and > optimisation. You still have to write something that the synthesizer can recognize. As far as I know, there still aren't any C compilers that will optimize a bubble-sort algorithm to quicksort, and there are definitely limits to what the synthesizer can figure out. But if you write verilog like you would C, it is likely that you get lousy hardware. -- glenArticle: 154772
On 1/6/13 10:42 AM, Michael S wrote: > On Dec 29 2012, 10:55 pm, Christopher Felton <a...@def.org> wrote: >> On 12/28/12 11:25 PM, Martin Schoeberl wrote: >> >>> "garyr" <ga...@fidalgo.net> wrote: >>>> "Martin Schoeberl" <mar...@jopdesign.com> wrote in message >>>> news:1621424063378432030.694310martin-jopdesign.com@reader.albasani.net... >>>>> Hi all, >> >>>>> started to look into alternatives to Verilog and VHDL and >>>>> stumbled over chisel from UCB: >>>>> http://chisel.eecs.berkeley.edu/ >> >>>>> Any experiences and comment on this language? >> >>>>> Looks like some challenge for me as it involves practically >>>>> learning 3 new languages at once: chisel itself, Scala on which >>>>> it is based, and Verilog, which is produced (I'm used to VHDL). >> >>>>> Cheers, >>>>> Martin >> >>>>> PS: I was *very* long absent from this group ;-) >> >>>> You might find this interesting: http://www.myhdl.org >> >>> Thanks for pointing this out, although it was not the 'real' answer to >>> my question ;-) >> >>> I'm already looking at MyHDL and some other projects. chisel just lookes >>> most promising at the moment. Maybe I change my mind. >> >>> A good comparison would be to do one HW design, e.g. a standard MIPS >>> pipeline, in all languages and compare the efficiency of the language and >>> the efficiency of the resulting HW implementation. >> >>> Martin >> >> Typically to do a comparison you have to have an example/project fairly >> limited in scope. It is hard to realize the benefits with such small >> examples. A language might have a /nice/ description for example "A" >> but is horrible at parametrization or it can be difficult to connect >> many modules or fails miserably at example "B" and "C". >> >> I am not familiar with Chisel and Scala and cannot comment directly. I >> am familiar with MyHDL and I have used MyHDL successfully for commercial >> and independent projects. >> >> Regards, >> Chris > > Can you list 2-3 most important productivity enhancements that MyHDL > gave you over VHDL? > From my perspective, probably, the number one productivity gain is access to the rich Python ecosystem. And this theme will be repeated throughout this conversation. _Ecosystem_. In my past, present, and future work I am often developing algorithms and then implementing them in digital circuits. Previously, before adopting the Python/MyHDL methodology I would constantly be moving from Matlab to the HDL of my employer (VHDL or Verilog). I was always looking for ways to leverage the work I did in the Matlab environment in the HDL environment (i.e use the models and analysis with the HDLs). With Python and MyHDL I can work in one environment and reuse the algorithm, modeling, and analysis in the HDL development. A simple example and some background described here: http://www.fpgarelated.com/showarticle/7.php Note, MyHDL is not an HLS it would be considered the same level of modeling/abstraction as Verilog/VHDL. _Verification_. For any decent size design this is always an area of active interest. I have found verifying designs with Python and MyHDL to be everything I want and need. Also, in my experience when I need to find additional resources for verification. In the cases where I have implemented my verification environment in Python I have an easier time getting SW or HW designers quickly proficient and contributing without loss of quality. _Modularity_. I have had fun and success, more so than the V* in creating highly modular IP (modules, blocks, whatever you want to call them). When doing this in Verilog/VHDL we would always use another language in tandem to create the IP. A customer would first use the Matlab/tcl/perl, whatever, to first configure the IP and then the HDL would pop out. Now, it is all simply done in Python with MyHDL. Regards, ChrisArticle: 154773
On 1/5/13 2:40 PM, Martin Schoeberl wrote: > some snips >>> >>> I don't think many would simply accept the conclusions but >>> it is a starting point for a conversation: how to compare >>> HDLs? How would one objectively quantify different HDLs. >>> What is being determined: speed of design entry, maintenance, >>> QoR, testabilty, ... ? >> >> >> Yes, this is not an easy question. However, this is also a reason >> to attack this question. Maybe by some discussions here. >> >> I personally want to explore alternatives ti VHDL and Verilog. >> I think it is time for new languages, now. We still use V*, but >> now as intermediate language to feed the design tools. > > Some status update: having now the BeMicro FPGA board up > and running for comparison in HW. It does blink nicely in > VHDL ;-) > > Next step MyHDL. Don't know jet if I like this dynamic typing. > Hello world simulation was a very quick start! > Getting MyHdL in to HW was always tricky, However, using > V* as an intermediate language might be a quite good idea. > > Cheers, > Martin > I think one of the tricks, is you really want to have a testbench/simulation to verify the design. Watching folks over the years, it has mainly been those that did not verify that had trouble in conversion. For simple designs this might seem silly but it is how you flush out, efficiently, simple errors when learning. Regards, ChrisArticle: 154774
Christopher Felton <abc@def.org> wrote: > On 1/5/13 2:40 PM, Martin Schoeberl wrote: >> some snips >>>> >>>> I don't think many would simply accept the conclusions but >>>> it is a starting point for a conversation: how to compare >>>> HDLs? How would one objectively quantify different HDLs. >>>> What is being determined: speed of design entry, maintenance, >>>> QoR, testabilty, ... ? >>> >>> >>> Yes, this is not an easy question. However, this is also a reason >>> to attack this question. Maybe by some discussions here. >>> >>> I personally want to explore alternatives ti VHDL and Verilog. >>> I think it is time for new languages, now. We still use V*, but >>> now as intermediate language to feed the design tools. >> >> Some status update: having now the BeMicro FPGA board up >> and running for comparison in HW. It does blink nicely in >> VHDL ;-) >> >> Next step MyHDL. Don't know jet if I like this dynamic typing. >> Hello world simulation was a very quick start! >> Getting MyHdL in to HW was always tricky, However, using >> V* as an intermediate language might be a quite good idea. >> >> Cheers, >> Martin >> > > I think one of the tricks, is you really want to have > a testbench/simulation to verify the design. Watching > folks over the years, it has mainly been those that > did not verify that had trouble in conversion. > > For simple designs this might seem silly but it is > how you flush out, efficiently, simple errors when > learning. > > Regards, > Chris Without a testbench I have the blinking LED running in MyHDL now. Just some quirks of a beginner to fight with. Don't know how one could do a decent testbench for a blinking LED. Now I will invest some more time on Phyton/MyHDL learning and more interesting examples. I realise that the MyHDL development is strongly based on test cases. Which is quite good. In my impression it is also way easier to do test benches in Python than in VHDL. Cheers, Martin
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z