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 17:54, glen herrmannsfeldt wrote: > 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. > That is correct. So what is needed here is for the "length" and "frequency" to refer to the parameters, rather than whatever is in scope at the time. That would be a change to the language, and theoretically could break existing valid code - but you would be unlikely to find such code outside the IOCCC. But obviously such a change would need a lot of thought from the language lawyers and the compiler implementers to see if there are any other non-obvious issues. >> 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. > > -- glen >Article: 154776
On 04/01/13 19:25, Martin Schoeberl wrote: > 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, ... ? > I can agree with that. The paper is certainly enough to be an inspiration that there are alternative languages, and that it is worth looking at them - along with some ideas on how to do such a comparison. But it is not a valid comparative paper on its own. > > Yes, this is not an easy question. However, this is also a reason > to attack this question. Maybe by some discussions here. The biggest reason for it being hard, is that the question is not clear. Ultimately, the question is "what is the best language for /me/, or /my/ company, for /this/ project?". But it is quite possible to have more general discussions, as long as no one expects /the/ answer to /the/ question. > > 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. > I believe this is quite common. Many people use some sort of generator - either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of perl, tcl, and other scripts to put together the VHDL or Verilog that is used for the actual synthesis. Many years ago, I used Confluence which was a functional programming language for HDL development. I found it very natural to work with - it was a lot more compact than either V*, and much easier to make sure everything was correct (properly synchronise, registers exactly when I wanted them, etc.), and good for testing. But it was very much a one-man project - and when that man moved on, development and progress stopped. It still exists (see the bottom of <http://tomahawkins.org/>) - open source software seldom dies completely.Article: 154777
<snip> >>> >>> 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, ... ? >> > > I can agree with that. The paper is certainly enough to be an > inspiration that there are alternative languages, and that it is worth > looking at them - along with some ideas on how to do such a comparison. > But it is not a valid comparative paper on its own. > >> >> Yes, this is not an easy question. However, this is also a reason >> to attack this question. Maybe by some discussions here. > > The biggest reason for it being hard, is that the question is not clear. > Ultimately, the question is "what is the best language for /me/, or > /my/ company, for /this/ project?". But it is quite possible to have > more general discussions, as long as no one expects /the/ answer to > /the/ question. Think most are agreeing, comparing languages is hard because it typically is subjective by the user. And there hasn't been many good examples of language comparisons. I think one good thing the paper did was try to break it down to three, possibly, objective points: /Conciseness/, /Comprehensibility/, and /Reusability/. The paper did fail in the execution, that is, defining a quantifiable approach for each of the defined metrics. And it would have been better off getting examples from each of the different gurus/communities. A comparison study shouldn't say if language X, Y, or Z is better but given a set of defined metrics how each language measures. And this wouldn't be perfect either, this would be similar to existing benchmarks. You need a suite of benchmarks and try to flush out the ones that are tailored for a specific design. > >> >> 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. >> > > I believe this is quite common. Many people use some sort of generator > - either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of > perl, tcl, and other scripts to put together the VHDL or Verilog that is > used for the actual synthesis. I don't know if I would call it a generator. You have an HDL language and its goal is not to generate V* but it is pragmatic to leverage existing tools so *converting* to V* makes sense. I try to differentiate because, some of the earlier tcl, perl, etc were intended to be generators they were not intended to be an HDL. But things like MyHDL, Lava, etc are HDLs and convert because it is practical. Regards, ChrisArticle: 154778
On 1/7/2013 1:59 AM, Martin Schoeberl wrote: > 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 > I know it might seem silly to create a testbench (or toggle bench) for a simple design. But while learning it can give a lot of insight and help avoid simple mistakes. Here is an example for a simple LED toggle based off a counter. http://pastebin.com/qPueFcsY The test wasn't difficult to write and didn't take a whole lot of time. But if I made a simple typo or a mistake with a concept I didn't quite understand it would help flush out those issues in MyHDL sim rather than working through the conversion then to the FPGA tools and hitting an error somewhere along the process. In addition you could also open up the waveform in a waveform viewer and see things are working as expected. And yes, I realize you indicated you have the blinky LED working with MyHDL and this is a moot point for this particular instance but nonetheless important. Regards, ChrisArticle: 154779
Having developed in VHDL (RTL and verification) for over 20 yrs, I recently= took a two week intensive course in Verilog, SystemVerilog and UVM. I have= a newfound appreciation for just how nice VHDL really is! Verilog has so m= any rabbit holes that look like they should work, but don't, and if you don= 't use a separate linter, you'll never find them. Add to that the lack of s= ubprogram overloading, unconstrained array types (including inspection of a= rguments to determine array range, etc.) and a host of other features I've = taken for granted for so many years, and its a now brainer.=20 If systemverilog did not have all the baggage of verilog, it might be a pre= tty good language. Take a look and the scheduling model for SystemVerilog: = it is a total mish-mash of bolted-on steps to handle this problem or that. = And if systemverilog is so powerfull, why is the preprocessor so integral t= o a standard class library and use model like UVM? Pre-processors are crutc= hes for hobbling along on the broken limbs of ill-conceived or incomplete l= anguages.=20 Perhaps the most glaring ommission of verilog/SV is the lack of bounds chec= king on array indices and scalar arguments to subprograms. This feature alo= ne allows VHDL to give you an error message that identifies where the probl= ems is, rather than simply strange behavior, or a segmentation fault in ver= ilog/SV. Take this example: try doing what the synthesizeable, standard VHDL fixed a= nd floating point packages do, in verilog or even system verilog. And keep = in mind that the first versions (complete functionality) were all done in t= he 20 year old '93 version of VHDL! The 2008 version only added generics to= the packages for default handling of saturation, rounding, etc.=20 The other issue that struck me during the course was the common reliance up= on the pre-processor in the lab examples to ensure compatibility with sever= al different brands of simulators. What works in one simulator, doesn't al= ways work in another! And these are all "compliant" simulators! A leisurely= stroll through the VHDL and SystemVerilog LRMs reveals the difference: The= VHDL strictly defines what the language does and what is not allowed, with= very few ambiguities. The SV LRM replaces strict specification with usage = examples, and hopes that each developer gets the same idea about what to su= pport and what to disallow. Ever seen an SV compliance suite?=20 Does VHDL have room for improvement? Absolutely! It needs an object-oriente= d capability complete with inheritance. Existing protected types are a star= t (see OSVVM.org for an example of what can be accomplished with them), but= no substitute for a complete OO implementation. An interface capability fo= r multi-directional elements on ports of record type is also needed (one of= the nice features of systemverilog). The good news is these and other issu= es are being worked today for the next version of VHDL. AndyArticle: 154780
On Mon, 07 Jan 2013 10:47:43 -0800, jonesandy wrote: > Having developed in VHDL (RTL and verification) for over 20 yrs, I > recently took a two week intensive course in Verilog, SystemVerilog and > UVM. I have a newfound appreciation for just how nice VHDL really is! > Verilog has so many rabbit holes that look like they should work, but > don't, and if you don't use a separate linter, you'll never find them. Rabbit holes ... I like it! that was my impression on the brief look I took at Verilog, and I have never had to use it (other than adding DDR2 memories to my VHDL projects). > Does VHDL have room for improvement? Absolutely! It needs an > object-oriented capability complete with inheritance. Existing protected > types are a start (see OSVVM.org for an example of what can be > accomplished with them), but no substitute for a complete OO > implementation. And there is a very good model to follow in Ada-2005 - I hope those in charge know of it. Goes both ways ... VHDL-2008 beat Ada to conditional and case-expressions (now in Ada-2012 ... admittedly also in Algol-W from 1963!) Would also be nice to see an interface to proof tools, along the lines of SPARK in Ada - especially since the provable subset of Ada and the synthesisable subset of VHDL have quite a lot in common. - BrianArticle: 154781
David Brown <david@westcontrol.removethisbit.com> wrote: > On 04/01/13 19:25, Martin Schoeberl wrote: >> 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, ... ? >> > > I can agree with that. The paper is certainly enough to be an > inspiration that there are alternative languages, and that it is worth > looking at them - along with some ideas on how to do such a comparison. > But it is not a valid comparative paper on its own. Maybe we should also add how easy it is to learn the language. Or if the language can be used to teach digital design at the University. >> Yes, this is not an easy question. However, this is also a reason >> to attack this question. Maybe by some discussions here. > > The biggest reason for it being hard, is that the question is not clear. > Ultimately, the question is "what is the best language for /me/, or > /my/ company, for /this/ project?". But it is quite possible to have > more general discussions, as long as no one expects /the/ answer to > /the/ question. Agree that there will probably be no /the/ language. But I don't want to explore them to just find a language that fits just me. >> 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. >> > > I believe this is quite common. Many people use some sort of generator > - either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of > perl, tcl, and other scripts to put together the VHDL or Verilog that is > used for the actual synthesis. > > > Many years ago, I used Confluence which was a functional programming > language for HDL development. I found it very natural to work with - it > was a lot more compact than either V*, and much easier to make sure > everything was correct (properly synchronise, registers exactly when I > wanted them, etc.), and good for testing. But it was very much a > one-man project - and when that man moved on, development and progress > stopped. It still exists (see the bottom of <http://tomahawkins.org/>) > - open source software seldom dies completely. Wow, that adds another tow languages to my list. This little exploration project looks like becoming a longer journey. Currently I have: MyHDL Chisel Lava Gezel JHDL Confluence HDCamel I think that would also mean I have to look at Python, Scala, Haskel, and OCaml. Cheers, MartinArticle: 154782
On 07/01/13 14:12, Christopher Felton wrote: > <snip> >>>> >>>> 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, ... ? >>> >> >> I can agree with that. The paper is certainly enough to be an >> inspiration that there are alternative languages, and that it is worth >> looking at them - along with some ideas on how to do such a comparison. >> But it is not a valid comparative paper on its own. >> >>> >>> Yes, this is not an easy question. However, this is also a reason >>> to attack this question. Maybe by some discussions here. >> >> The biggest reason for it being hard, is that the question is not clear. >> Ultimately, the question is "what is the best language for /me/, or >> /my/ company, for /this/ project?". But it is quite possible to have >> more general discussions, as long as no one expects /the/ answer to >> /the/ question. > > Think most are agreeing, comparing languages is hard because it > typically is subjective by the user. And there hasn't been > many good examples of language comparisons. I think one good > thing the paper did was try to break it down to three, possibly, > objective points: /Conciseness/, /Comprehensibility/, and > /Reusability/. The paper did fail in the execution, that is, > defining a quantifiable approach for each of the defined > metrics. And it would have been better off getting examples > from each of the different gurus/communities. > Breaking it down into objective points is good - but I think there are a few other points that are perhaps equally important to the three mentioned here. One is "how easy is it to write correct code?", covering things like ease of learning, syntax, etc., as well as how helpful it is in encouraging good design (a language that takes a dozen lines to standard features like clocking, async reset, and sync enable for a simple register would fail here). A second point is "how hard is it to write incorrect code?". This might seem redundant giving the previous point, but it covers things like warning messages and error reporting, syntax that avoids confusing operators or syntax (hands up those who have never confused assignment types in Verilog), and language features that make it difficult to write code that is unlikely to be correct (it should be hard - but not impossible - to code a latch, for example). A third point is "how well can you test the code?" - including simulation or testbenches within the tool itself. Since any such languages work by generating a mainstream HDL (usually Verilog and/or VHDL, but theoretically also others like System Verilog, AHDL, etc.), it is also important to consider the way this is done. How efficient is the generated code - do you end up using the same FPGA resources at the same speed as hand-written V* ? How comprehensible is the generated code - is it easy to relate to the source code, or is it a single incomprehensible mess? > A comparison study shouldn't say if language X, Y, or Z is > better but given a set of defined metrics how each language > measures. And this wouldn't be perfect either, this would > be similar to existing benchmarks. You need a suite of > benchmarks and try to flush out the ones that are tailored > for a specific design. Agreed. > >> >>> >>> 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. >>> >> >> I believe this is quite common. Many people use some sort of generator >> - either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of >> perl, tcl, and other scripts to put together the VHDL or Verilog that is >> used for the actual synthesis. > > I don't know if I would call it a generator. You have > an HDL language and its goal is not to generate V* but it > is pragmatic to leverage existing tools so *converting* > to V* makes sense. I try to differentiate because, some > of the earlier tcl, perl, etc were intended to be generators > they were not intended to be an HDL. But things like MyHDL, > Lava, etc are HDLs and convert because it is practical. > Fair enough - your terminology here is more accurate than mine. > Regards, > Chris > >Article: 154783
On 08/01/13 03:06, Martin Schoeberl wrote: > David Brown <david@westcontrol.removethisbit.com> wrote: >> On 04/01/13 19:25, Martin Schoeberl wrote: <snip> >> >> Many years ago, I used Confluence which was a functional programming >> language for HDL development. I found it very natural to work with - it >> was a lot more compact than either V*, and much easier to make sure >> everything was correct (properly synchronise, registers exactly when I >> wanted them, etc.), and good for testing. But it was very much a >> one-man project - and when that man moved on, development and progress >> stopped. It still exists (see the bottom of <http://tomahawkins.org/>) >> - open source software seldom dies completely. > > Wow, that adds another tow languages to my list. This little exploration > project looks like becoming a longer journey. Currently I have: > > MyHDL > Chisel > Lava > Gezel > JHDL > Confluence > HDCamel > > I think that would also mean I have to look at Python, Scala, Haskel, and > OCaml. > > Cheers, > Martin > OCaml and Haskel are both on my list of languages to learn. I already use Python, but Scala hasn't made it to my list yet... Be careful that both Confluence and HDCamel are "dead" languages - the single developer has moved on. With enough enthusiasm, they could be resurrected - the tools are all open source, so you can download the code and use it, and you can build on them and improve them, and build a new community around the development and use of the tools. But since there is no longer an existing community, that would be no small job. Of course, you can also consider them as finished tools - they do the job they were supposed to do, and you can just use them like that.Article: 154784
How many have used the iCECube2 tool? I am just getting started with it
and it seems to be less than optimal. It uses Synplify Pro for
synthesis. I wrote code for a simple enabled up/down counter which I
expect would use one LUT per bit. But it seems to be using two LUTs
per. Instead of running the enable to the register, it is adding the
enable into the logic to control whether the bit is inverted or not.
This requires an extra input and so an extra LUT per bit. Here is the
code involved.
...
PORT (
SysRst : in std_logic;
RateHigh : in std_logic;
RateEn : in std_logic;
...
signal VFOclkout : std_logic;
signal PhaseStepReg : signed (RESOLUTION - 1 downto 0);
...
PROCESS (VFOclkout, SysRst) begin
if (SysRst ='1') then
PhaseStepReg <= to_signed(-VFOSTEPSIZE, RESOLUTION);
elsif (rising_edge(VFOclkout)) then
if (RateEn = '1') then
if (RateHigh = '0') then
PhaseStepReg <= PhaseStepReg + 1;
else
PhaseStepReg <= PhaseStepReg - 1;
end if;
end if;
end if;
end process;
...
The output, PhaseStepReg, is used in another process. I can't see
anything that would affect the synthesis of this counter.
I'm wondering if there is something about the architecture of these
parts that precludes an up/down counter in one LUT/bit. They use a
single input on a register bank for all enables in common, but could
that really make them use an extra bank of logic? I may simplify this
code to just the up/down counter and send it off to support. So far I
haven't gotten much from Lattice support other than the local FAE.
Seems they are in a time zone about 12 hours off from mine.
Rick
Article: 154785On Jan 8, 3:02=A0am, Brian Drummond <br...@shapes.demon.co.uk> wrote: > On Mon, 07 Jan 2013 10:47:43 -0800, jonesandy wrote: > > Having developed in VHDL (RTL and verification) for over 20 yrs, I > > recently took a two week intensive course in Verilog, SystemVerilog and > > UVM. I have a newfound appreciation for just how nice VHDL really is! > > Verilog has so many rabbit holes that look like they should work, but > > don't, and if you don't use a separate linter, you'll never find them. > > Rabbit holes ... I like it! that was my impression on the brief look I > took at Verilog, and I have never had to use it (other than adding DDR2 > memories to my VHDL projects). From that I learn that so far you managed to avoid qsys. > > > Does VHDL have room for improvement? Absolutely! It needs an > > object-oriented capability complete with inheritance. Existing protecte= d > > types are a start (see OSVVM.org for an example of what can be > > accomplished with them), but no substitute for a complete OO > > implementation. > > And there is a very good model to follow in Ada-2005 - I hope those in > charge know of it. Goes both ways ... VHDL-2008 beat Ada to conditional > and case-expressions (now in Ada-2012 ... admittedly also in Algol-W from > 1963!) Yesterday I looked (again) at VHDL-2008 additions. I like few of them. In particular, unconstrained arrays in records (and other arrays) remove one of the last reasons to avoid defining entity ports as records. Unconstrained arrays of unconstrained arrays also look useful and probably had to be part of the language from the very beginning. By comparison to 2 items above, (all) specification in sensitivity list may look as minor addition, but until now those error-prone sensitivity list were the main reason for me to avoid combinatorial processes altogether. Now I can reconsider. So, I'd like to use VHDL-2008. Altera integrated synthesis even appear to support all features that I care about. But there remains a question of simulation. Does ModelSim Altera Edition support them? What about ModelSim Altera Starter Edition? > > Would also be nice to see an interface to proof tools, along the lines of > SPARK in Ada - especially since the provable subset of Ada and the > synthesisable subset of VHDL have quite a lot in common. > > - Brian I don't consider proof tools particularly useful.Article: 154786
On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote: > On Jan 8, 3:02 am, Brian Drummond <br...@shapes.demon.co.uk> wrote: >> On Mon, 07 Jan 2013 10:47:43 -0800, jonesandy wrote: >> > Verilog has so many rabbit holes that look like they should work, >> > but don't, and if you don't use a separate linter, you'll never find >> > them. >> >> Rabbit holes ... I like it! that was my impression on the brief look I >> took at Verilog, and I have never had to use it (other than adding DDR2 >> memories to my VHDL projects). > > From that I learn that so far you managed to avoid qsys. Apparently it's an Altera tool. Yes I have, so far. > Yesterday I looked (again) at VHDL-2008 additions. > I like few of them. > By comparison to 2 items above, (all) specification in sensitivity list > may look as minor addition, but until now those error-prone sensitivity > list were the main reason for me to avoid combinatorial processes > altogether. Now I can reconsider. I think it's a harmless addition, but I've never found a role for combinational processes anyway! >> Would also be nice to see an interface to proof tools, along the lines >> of SPARK > I don't consider proof tools particularly useful. Understandable. They have been around since the 80s, but it's only in the last couple of years they have started to gain any traction. - BrianArticle: 154787
On Jan 10, 2:28=A0am, Brian Drummond <br...@shapes.demon.co.uk> wrote: > On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote: > > On Jan 8, 3:02=A0am, Brian Drummond <br...@shapes.demon.co.uk> wrote: > >> On Mon, 07 Jan 2013 10:47:43 -0800, jonesandy wrote: > >> > =A0Verilog has so many rabbit holes that look like they should work, > >> > but don't, and if you don't use a separate linter, you'll never find > >> > them. > > >> Rabbit holes ... I like it! that was my impression on the brief look I > >> took at Verilog, and I have never had to use it (other than adding DDR= 2 > >> memories to my VHDL projects). > > > From that I learn that so far you managed to avoid qsys. > > Apparently it's an Altera tool. Yes I have, so far. > > > Yesterday I looked (again) at VHDL-2008 additions. > > I like few of them. > > By comparison to 2 items above, (all) specification in sensitivity list > > may look as minor addition, but until now those error-prone sensitivity > > list were the main reason for me to avoid combinatorial processes > > altogether. Now I can reconsider. > > I think it's a harmless addition, but I've never found a role for > combinational processes anyway! > I am thinking about one specific use case. <code> signal bar, bar0, bar1 : bar_record_t; begin x:foo1 port map (..., bar_out =3D> bar); process (all) begin bar0 <=3D bar; bar1 <=3D bar; bar0.valid <=3D bar.valid and not addr(5); bar1.valid <=3D bar.valid and addr(5); end process; y0:foo2 port map (bar_inp =3D> bar0, ...); y1:foo2 port map (bar_inp =3D> bar1, ...); </code> Pay attention that combinatorial process is required only because of not sufficiently powerful syntax for concurrent assignment of record types. I'd very much prefer to write (outside of the process) something like: bar0 <=3D (valid =3D> bar.valid and not addr(5), others =3D> from bar); May be, in the next VHDL edition?Article: 154788
On Thu, 10 Jan 2013 02:35:05 -0800, Michael S wrote:
> On Jan 10, 2:28 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>> On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote:
>> > Yesterday I looked (again) at VHDL-2008 additions.
>> > By comparison to 2 items above, (all) specification in sensitivity
>> > list may look as minor addition, but until now those error-prone
>> > sensitivity list were the main reason for me to avoid combinatorial
>> > processes altogether. Now I can reconsider.
>>
>> I think it's a harmless addition, but I've never found a role for
>> combinational processes anyway!
> I am thinking about one specific use case.
> <code>
I can see the rationale for that use case.
> I'd very much prefer to write (outside of the process) something like:
> bar0 <= (valid => bar.valid and not addr(5), others => from bar);
I appreciate the desire for this in a future VHDL.
Meanwhile, this is a good place for a function.
It can be declared locally, but my solution is to treat bar_record_t as
an abstract type. Wrap it in a package along with functions to manipulate
it.
package bar_type is
type bar_record_t is...
function validate (B : bar_record_t; V : bar_valid_t)
return bar_record_t;
...
end bar_type;
-- in the package body
function validate (B : bar_record_t; V : bar_valid_t)
return bar_record_t is
variable temp: bar_record_t := B;
begin
temp.valid := V;
return temp;
end validate;
Then the main code simply reads:
bar0 <= bar_type.validate(bar, bar.valid and not addr(5));
bar1 <= bar_type.validate(bar, bar.valid and addr(5));
To my eyes, this makes the main code cleaner, so I wouldn't even
contemplate a combinational process here.
- Brian
Article: 154789rickman wrote: > How many have used the iCECube2 tool? I am just getting started with it > and it seems to be less than optimal. It uses Synplify Pro for > synthesis. I wrote code for a simple enabled up/down counter which I > expect would use one LUT per bit. But it seems to be using two LUTs > per. Instead of running the enable to the register, it is adding the > enable into the logic to control whether the bit is inverted or not. > This requires an extra input and so an extra LUT per bit. Here is the > code involved. > > ... > PORT ( > SysRst : in std_logic; > RateHigh : in std_logic; > RateEn : in std_logic; > ... > signal VFOclkout : std_logic; > signal PhaseStepReg : signed (RESOLUTION - 1 downto 0); > ... > PROCESS (VFOclkout, SysRst) begin > if (SysRst ='1') then > PhaseStepReg <= to_signed(-VFOSTEPSIZE, RESOLUTION); > elsif (rising_edge(VFOclkout)) then > if (RateEn = '1') then > if (RateHigh = '0') then > PhaseStepReg <= PhaseStepReg + 1; > else > PhaseStepReg <= PhaseStepReg - 1; > end if; > end if; > end if; > end process; > ... > > The output, PhaseStepReg, is used in another process. I can't see > anything that would affect the synthesis of this counter. > > I'm wondering if there is something about the architecture of these > parts that precludes an up/down counter in one LUT/bit. They use a > single input on a register bank for all enables in common, but could > that really make them use an extra bank of logic? I may simplify this > code to just the up/down counter and send it off to support. So far I > haven't gotten much from Lattice support other than the local FAE. Seems > they are in a time zone about 12 hours off from mine. > > Rick It's been a while since I used any Lattice tools, but I seem to remember that Synplify for Lattice has a compiler directive that encourages it to use a particular signal as a clock enable. In your case you could apply this to RateEn and see if it causes the synthesizer to recognize it as an enable to reduce the LUT count. That being said, I have not used the ICE series parts and there may still be another reason why the tools have not inferred clock enables. -- GaborArticle: 154790
On Jan 10, 3:27=A0pm, Brian Drummond <br...@shapes.demon.co.uk> wrote: > On Thu, 10 Jan 2013 02:35:05 -0800, Michael S wrote: > > On Jan 10, 2:28=A0am, Brian Drummond <br...@shapes.demon.co.uk> wrote: > >> On Wed, 09 Jan 2013 04:59:25 -0800, Michael S wrote: > >> > Yesterday I looked (again) at VHDL-2008 additions. > >> > By comparison to 2 items above, (all) specification in sensitivity > >> > list may look as minor addition, but until now those error-prone > >> > sensitivity list were the main reason for me to avoid combinatorial > >> > processes altogether. Now I can reconsider. > > >> I think it's a harmless addition, but I've never found a role for > >> combinational processes anyway! > > I am thinking about one specific use case. > > <code> > > I can see the rationale for that use case. > > > I'd very much prefer to write (outside of the process) something like: > > bar0 <=3D (valid =3D> bar.valid and not addr(5), others =3D> from bar); > > I appreciate the desire for this in a future VHDL. > > Meanwhile, this is a good place for a function. > > It can be declared locally, but my solution is to treat bar_record_t as > an abstract type. Wrap it in a package along with functions to manipulate > it. > > package bar_type is > type bar_record_t is... > function validate (B : bar_record_t; V : bar_valid_t) > =A0 =A0 =A0 =A0 =A0return bar_record_t; > ... > end bar_type; > > -- in the package body > function validate (B : bar_record_t; V : bar_valid_t) > =A0 =A0 =A0 =A0 =A0return bar_record_t is > =A0 =A0variable temp: bar_record_t :=3D B; > begin > =A0 =A0temp.valid :=3D V; > =A0 =A0return temp; > end validate; > > Then the main code simply reads: > > bar0 <=3D bar_type.validate(bar, bar.valid and not addr(5)); > bar1 <=3D bar_type.validate(bar, bar.valid and addr(5)); > > To my eyes, this makes the main code cleaner, so I wouldn't even > contemplate a combinational process here. > > - Brian That's what I do today, more or less. Except I prefer to keep things as local as possible, so, unless it is used by more than one entity, I'll not put validate() function into package. It works, but it takes few minutes when writing code - not a big deal. More importantly, when reading a code, understanding what's going on takes few tens of second, unless similar technique already appeared many times in the project an the reader already caught with writer's patterns. BTW, in order to facilitate reader's pattern recognition I'd call the helper function set_valid() rather than validate(). The advantage of built in tool, i.e. non-existent "others=3D>from" syntax, is that reader already knows what it means. The advantage of solution with combinatorial process is that although reader does not know what it means, he is able to figure it out without jumping back and and force between different source LOCs and files.Article: 154791
On Wednesday, January 9, 2013 3:43:54 PM UTC+13, rickman wrote: > I'm wondering if there is something about the architecture of these > parts that precludes an up/down counter in one LUT/bit. I thought the tile in an iCE40 was not as smart as the MachXO2, and so that was why any iCE40 design uses more cells ? Did you try re-targeting to the MachXO2 ? -jgArticle: 154792
On 1/10/2013 8:50 AM, GaborSzakacs wrote: > rickman wrote: >> How many have used the iCECube2 tool? I am just getting started with >> it and it seems to be less than optimal. It uses Synplify Pro for >> synthesis. I wrote code for a simple enabled up/down counter which I >> expect would use one LUT per bit. But it seems to be using two LUTs >> per. Instead of running the enable to the register, it is adding the >> enable into the logic to control whether the bit is inverted or not. >> This requires an extra input and so an extra LUT per bit. Here is the >> code involved. >> >> ... >> PORT ( >> SysRst : in std_logic; >> RateHigh : in std_logic; >> RateEn : in std_logic; >> ... >> signal VFOclkout : std_logic; >> signal PhaseStepReg : signed (RESOLUTION - 1 downto 0); >> ... >> PROCESS (VFOclkout, SysRst) begin >> if (SysRst ='1') then >> PhaseStepReg <= to_signed(-VFOSTEPSIZE, RESOLUTION); >> elsif (rising_edge(VFOclkout)) then >> if (RateEn = '1') then >> if (RateHigh = '0') then >> PhaseStepReg <= PhaseStepReg + 1; >> else >> PhaseStepReg <= PhaseStepReg - 1; >> end if; >> end if; >> end if; >> end process; >> ... >> >> The output, PhaseStepReg, is used in another process. I can't see >> anything that would affect the synthesis of this counter. >> >> I'm wondering if there is something about the architecture of these >> parts that precludes an up/down counter in one LUT/bit. They use a >> single input on a register bank for all enables in common, but could >> that really make them use an extra bank of logic? I may simplify this >> code to just the up/down counter and send it off to support. So far I >> haven't gotten much from Lattice support other than the local FAE. >> Seems they are in a time zone about 12 hours off from mine. >> >> Rick > > It's been a while since I used any Lattice tools, but I seem to remember > that Synplify for Lattice has a compiler directive that encourages it > to use a particular signal as a clock enable. In your case you could > apply this to RateEn and see if it causes the synthesizer to recognize > it as an enable to reduce the LUT count. That being said, I have not > used the ICE series parts and there may still be another reason why > the tools have not inferred clock enables. > > -- Gabor Thanks for the reply. You might be right. A simple divide by two FF also uses the logic to implement an enable. I'll look into the directive. Seems rather retarded really. Most of the time the synthesizer will even add logic to the enable and with these tools it doesn't want to use the enable at all. I'll give the directive a try. I did put in a ticket for this and we'll see what they say. The iCE40 parts started out with their own tools so it's hard to say what might have happened when they were brought over to Lattice. RickArticle: 154793
On 1/10/2013 3:50 PM, jg wrote: > On Wednesday, January 9, 2013 3:43:54 PM UTC+13, rickman wrote: >> I'm wondering if there is something about the architecture of these >> parts that precludes an up/down counter in one LUT/bit. > > I thought the tile in an iCE40 was not as smart as the MachXO2, and so that was why any iCE40 design uses more cells ? > Did you try re-targeting to the MachXO2 ? > > -jg I looked at the documentation and the only restriction I could see is that all the clock enables within a block share the same input pin. So there is only one clock enable for the entire block. I wouldn't think this is a real problem, at least not one that required using extra LUTs. Even if you are using the extra input, each LUT has four and there are only four inputs, counter value, carry in, up/down flag and enable. Also, the extra LUT is combining the up/down flag and the enable flag. Why would that have to be done more than once? So this is messed up in three different ways... We'll see what Lattice says. RickArticle: 154794
On Thu, 10 Jan 2013 07:14:54 -0800, Michael S wrote: > On Jan 10, 3:27 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote: >> function validate (B : bar_record_t; V : bar_valid_t) >> return bar_record_t; ... >> Then the main code simply reads: >> >> bar0 <= bar_type.validate(bar, bar.valid and not addr(5)); >> bar1 <= bar_type.validate(bar, bar.valid and addr(5)); >> >> To my eyes, this makes the main code cleaner, so I wouldn't even >> contemplate a combinational process here. > > That's what I do today, more or less. Except I prefer to keep things as > local as possible, so, unless it is used by more than one entity, I'll > not put validate() function into package. Fair enough - for single uses, I do use locally declared functions too. > It works, but it takes few minutes when writing code - not a big deal. > More importantly, when reading a code, understanding what's going on > takes few tens of second, unless ...the reader already caught with > writer's patterns. A good argument for adopting a small and consistent set of patterns! > BTW, in order to facilitate reader's pattern recognition I'd call the > helper function set_valid() rather than validate(). It's your example; you have the context to name it better than I do! > The advantage of built in tool, i.e. non-existent "others=>from" syntax, > is that reader already knows what it means. However you won't be able to sell anyone the idea of a new reserved word "from" on such a lightweight justification. How about "others => bar.others" instead? Equally clear, I think, and quite in keeping with the language. - BrianArticle: 154795
On Fri, 11 Jan 2013 00:22:53 +0000 (UTC) Brian Drummond <brian@shapes.demon.co.uk> wrote: > On Thu, 10 Jan 2013 07:14:54 -0800, Michael S wrote: >=20 > > On Jan 10, 3:27=C2=A0pm, Brian Drummond <br...@shapes.demon.co.uk> wrot= e: >=20 > >> function validate (B : bar_record_t; V : bar_valid_t) > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return bar_record_t; > ... > >> Then the main code simply reads: > >> > >> bar0 <=3D bar_type.validate(bar, bar.valid and not addr(5)); > >> bar1 <=3D bar_type.validate(bar, bar.valid and addr(5)); > >> > >> To my eyes, this makes the main code cleaner, so I wouldn't even > >> contemplate a combinational process here. > > > > That's what I do today, more or less. Except I prefer to keep things as > > local as possible, so, unless it is used by more than one entity, I'll > > not put validate() function into package. >=20 > Fair enough - for single uses, I do use locally declared functions too. >=20 > > It works, but it takes few minutes when writing code - not a big deal. > > More importantly, when reading a code, understanding what's going on > > takes few tens of second, unless ...the reader already caught with=20 > > writer's patterns. >=20 > A good argument for adopting a small and consistent set of patterns! >=20 > > BTW, in order to facilitate reader's pattern recognition I'd call the > > helper function set_valid() rather than validate(). >=20 > It's your example; you have the context to name it better than I do! >=20 > > The advantage of built in tool, i.e. non-existent "others=3D>from" synt= ax, > > is that reader already knows what it means. >=20 > However you won't be able to sell anyone the idea of a new reserved word= =20 > "from" on such a lightweight justification.=20 > How about "others =3D> bar.others" instead?=20 >=20 > Equally clear, I think, and quite in keeping with the language. >=20 > - Brian Or others =3D> unaffected --=20 Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154796
On Jan 11, 2:26=A0am, Rob Gaddi <rga...@technologyhighland.invalid> wrote: > On Fri, 11 Jan 2013 00:22:53 +0000 (UTC) > > > > > > > > > > Brian Drummond <br...@shapes.demon.co.uk> wrote: > > On Thu, 10 Jan 2013 07:14:54 -0800, Michael S wrote: > > > > On Jan 10, 3:27=A0pm, Brian Drummond <br...@shapes.demon.co.uk> wrote= : > > > >> function validate (B : bar_record_t; V : bar_valid_t) > > >> =A0 =A0 =A0 =A0 =A0return bar_record_t; > > ... > > >> Then the main code simply reads: > > > >> bar0 <=3D bar_type.validate(bar, bar.valid and not addr(5)); > > >> bar1 <=3D bar_type.validate(bar, bar.valid and addr(5)); > > > >> To my eyes, this makes the main code cleaner, so I wouldn't even > > >> contemplate a combinational process here. > > > > That's what I do today, more or less. Except I prefer to keep things = as > > > local as possible, so, unless it is used by more than one entity, I'l= l > > > not put validate() function into package. > > > Fair enough - for single uses, I do use locally declared functions too. > > > > It works, but it takes few minutes when writing code - not a big deal= . > > > More importantly, when reading a code, =A0understanding what's going = on > > > takes few tens of second, unless ...the reader already caught with > > > writer's patterns. > > > A good argument for adopting a small and consistent set of patterns! > > > > BTW, in order to facilitate reader's pattern recognition I'd call the > > > helper function set_valid() rather than validate(). > > > It's your example; you have the context to name it better than I do! > > > > The advantage of built in tool, i.e. non-existent "others=3D>from" sy= ntax, > > > is that reader already knows what it means. > > > However you won't be able to sell anyone the idea of a new reserved wor= d > > "from" on such a lightweight justification. > > How about "others =3D> bar.others" instead? > > > Equally clear, I think, and quite in keeping with the language. > > > - Brian > > Or others =3D> unaffected > Why unaffected? I want other fields of bar1 to get values from bar. Remember, we are discussing concurrent assignments, not assignments in the processArticle: 154797
Hello, I'm looking for some kind person who could test my SD card controller. Board with SD card slot with 4 data pins connected is needed. I'm asking for it because I've designed my own board and I can trust it too much ;) So I'd like to check if I have now hardware or VHDL problem. Best regards, Pavel --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154798
On 1/1/2013 1:24 PM, spman wrote: > Hi > > I have created a controller for DDR3 with the MIG. The MIG output folders > are example_design and user_design. according to MIG report : > " > - example_design: > This folder includes the design with synthesizable test bench. > > - user_design: > This folder includes the design without test bench modules. > " > > But actually i don't see any important difference between these folders > except the name of some files! The top module of both folders have > instantiated the controller and the traffic generator for testing. So which > module is appropriate for start of my design?! Both are too complicated > that i can't use in my design! > Any hint please? > > Thanks in advance > > --------------------------------------- > Posted through http://www.FPGARelated.com > On 1/1/2013 1:24 PM, spman wrote:> Hi > > I have created a controller for DDR3 with the MIG. The MIG output folders > are example_design and user_design. according to MIG report : > " > - example_design: > This folder includes the design with synthesizable test bench. > > - user_design: > This folder includes the design without test bench modules. > " > > But actually i don't see any important difference between these folders > except the name of some files! The top module of both folders have > instantiated the controller and the traffic generator for testing. So which > module is appropriate for start of my design?! Both are too complicated > that i can't use in my design! > Any hint please? > > Thanks in advance > > --------------------------------------- > Posted through http://www.FPGARelated.com > Here are the differences between the designs example_design -------------- The memory tester components along with the MIG are collected into a top level module, example_top.vhd, that is in the ip_top folder. The top level test bench, ui_top in the sim folder only instantiates one DUT (Device Under Test) module, example_top. The other modules in the test bench are memory and wire models needed to complete the test bench. There are two status outputs from example_top - phy_init_done and error - and these indicate when memory calibration has successfully completed and when an error has occurred in the memory test. example_design can actually be run through the Xilinx tools and the resulting bit stream can be used to verify that the memory is actually working on the board. You can connect the phy_init_done and error signals to LEDs on your board and use this to verify that the memory is working. To verify that the memory test is working, random memory pins can be shorted to ground with a low value resistor and the error LED should turned on. NOTE: The error signal is latching, so the design must be reset to clear the error! user_design -------------- The top level DUT for this design is the mig_ddr3 module from the ip_top folder. The sim_tb_top.vhd module instantiates this, as well as the memory tester modules and wire and memory modules. You will probably want to use mig_ddr3 as your top level, because it has the interface to the user's application code as well as to the memory chips/modules but doesn't have any memory test logic. If you want to have the capability for memory testing in your design, you can add this buy combining the init_mem_pattern_ctr and mcb_traffic_gen modules into a single module, following the connectivity in the test bench. Then mux the memory tester module and your application code into the mig_ddr3 module. Good luck, PaulArticle: 154799
Hi, I've installed the Quartus II 12.1 Web Edition for my students in 64-bit Linux machine, and I've found, that in System Sources and Probes (iSS&P) Editor does not work. Generally the program starts. It is possible to program the FPGA with the .sof file, but then the instance of iSS&P block is displayed with the status "Unexpected JTAG Communication Error". In the main Quartus window, in the "System" tab I can see: Info (209060): Started Programmer operation at Fri Jan 11 23:37:26 2013 Info (209016): Configuring device index 1 Info (209017): Device 1 contains JTAG ID code 0x020B20DD Info (209007): Configuration succeeded -- 1 device(s) configured Info (209011): Successfully performed operation(s) Info (209061): Ended Programmer operation at Fri Jan 11 23:37:26 2013 Error (261005): Can't find the instance. Download a design with SRAM Object File containing this instance. Error (261005): Can't find the instance. Download a design with SRAM Object File containing this instance. The .sof file is OK. In the 32-bit Windows machine it works correctly with Sources & Probes. Has anybody experienced and solved similar problem? -- TIA & Regards, Wojtek
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