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 Sat, 13 Feb 2010 06:29:20 +0100, whygee wrote: >I did not know that I would trigger so many strong reactions, <wipes spilt coffee from keyboard, resets cardiac pacemaker> Ignorance is bliss, but often unhelpful. -- Jonathan BromleyArticle: 145526
On Sat, 13 Feb 2010 06:25:13 +0100, whygee wrote: >The phrase that I partly remember summed up > many things about the divergences >between these two major HDL. It was, and still is, an amusing quote. Similarly amusing is the response, which I think is Janick Bergeron's, to the question "which HDL do you prefer"; the answer is "the one I'm not using this week". VHDL is, by any sensible measure, a hugely superior language for RTL design; but it was driven almost to the point of extinction by Verilog advocates in the RTL design community, who fell in love with Verilog's conciseness and apparent simplicity. They had some real ammunition too; Verilog was designed from the outset to do a good job of gate-level and netlist simulation, but VHDL initially lacked some crucial features to deal with that. The VITAL standard filled that gap in VHDL, but its performance has always lagged far behind what Verilog can do and it's hard to imagine anyone doing VHDL gate-level simulation from choice. The RTL community's reluctance to adopt what it can from the software world is saddening and mystifying. I cannot think of even one serious attempt to raise the abstraction level of RTL design in the last 20 years that has been commercially successful. By contrast, VHDL's limitations in the world of testbench writing are so severe that it's amazing it gained any traction at all in that space. >> ...to comp.lang.vhdl where you will find polite software people. >does THAT exist ? Depends what they have been smoking recently :-) -- Jonathan BromleyArticle: 145527
Eric Smith wrote: > That's a quote by someone who doesn't understand VHDL. I wrote that it summed up a lot of things, so it was interesting to me. I did not infer that it was acurate :-) yg -- http://ygdes.com / http://yasep.orgArticle: 145528
Petter Gustad wrote: > whygee <yg@yg.yg> writes: >> Does anybody know the exact wording and origin ? > You mean this? > http://groups.google.com/group/comp.lang.vhdl/msg/c9edc45f3a7c86d4 yes, that's it ! thanks, > Petter yg -- http://ygdes.com / http://yasep.orgArticle: 145529
Jonathan Bromley wrote: > On Sat, 13 Feb 2010 06:29:20 +0100, whygee wrote: >> I did not know that I would trigger so many strong reactions, > <wipes spilt coffee from keyboard, resets cardiac pacemaker> > Ignorance is bliss, but often unhelpful. sorry for your keyboard :-) yg -- http://ygdes.com / http://yasep.orgArticle: 145530
Hi !
Jonathan Bromley wrote:
> On Sat, 13 Feb 2010 06:25:13 +0100, whygee wrote:
>> The phrase that I partly remember summed up
>> many things about the divergences
>> between these two major HDL.
> It was, and still is, an amusing quote.
you get the point of the intention for the quote :-)
> Similarly amusing
> is the response, which I think is Janick Bergeron's, to the
> question "which HDL do you prefer"; the answer is "the one
> I'm not using this week".
Funny, I have tried to reinvent quite a lot of wheels,
but never a HDL.
> VHDL is, by any sensible measure, a hugely superior
> language for RTL design; but it was driven almost
> to the point of extinction by Verilog advocates in the
> RTL design community, who fell in love with Verilog's
> conciseness and apparent simplicity.
Well, I learnt VHDL because :
- I'm french and it's a de facto HDL in Europe
(or at least it was 10 years ago)
- it's very rich and expressive,
and I discover something new all the time
but yes, the overhead of learning all the subtleties
can distract my efforts away from actual design.
But I stick to it.
Fortunately, I don't run (yet) an ASIC design company :-D
> They had some
> real ammunition too; Verilog was designed from the
> outset to do a good job of gate-level and netlist
> simulation, but VHDL initially lacked some crucial
> features to deal with that.
I thought that VHDL was initially designed for simulation,
before synthesisers used it too (?)
> The VITAL standard filled
> that gap in VHDL, but its performance has always
> lagged far behind what Verilog can do and it's hard
> to imagine anyone doing VHDL gate-level simulation
> from choice.
hmmm... interesting, I have never thought about this.
Do you refer to post-route simulations here ?
And, according to your experience,
why would it be so slow compared the Verilog ?
> The RTL community's reluctance to adopt what it can
> from the software world is saddening and mystifying.
> I cannot think of even one serious attempt to raise
> the abstraction level of RTL design in the last
> 20 years that has been commercially successful.
I think that I'll leave this aspect uncovered in
my paper :-)
> By contrast, VHDL's limitations in the world of
> testbench writing are so severe that it's amazing
> it gained any traction at all in that space.
what are these limitations, in your opinion ?
I don't think I have run into any yet.
thanks for your explanations,
yg
--
http://ygdes.com / http://yasep.org
Article: 145531John_H wrote: > The quote predates Oct 200 as noted by the post: > http://www.fpga-faq.com/archives/26475.html#26480 i think that you missed one zero :-) But I'm surprised that the title of this post is exactly the same as mine. Damnit, I want to be original and I write the same stuff as others again :-/ > Elsewhere the quote is attributed to David Bishop (in a few places > including a 2007 conference paper) but I'm not certain if that's from > a restatement (e.g. January 2006) or the original from Y2K or before. > David Bishop has at least reused the quote in 2006 prior to the 2007 > reference. Does he like to "quote and paste" ? :-D thanks for the hints and pointers :-) yg -- http://ygdes.com / http://yasep.orgArticle: 145532
On Feb 13, 4:20=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sat, 13 Feb 2010 10:15:34 +0100, Petter Gustad > > <newsmailco...@gustad.com> wrote: > >whygee <y...@yg.yg> writes: > > >> Does anybody know the exact wording and origin ? > > >You mean this? > > >http://groups.google.com/group/comp.lang.vhdl/msg/c9edc45f3a7c86d4 > > Right, that's it, but the epithet has been around far > longer than that post. The quote predates Oct 200 as noted by the post: http://www.fpga-faq.com/archives/26475.html#26480 Elsewhere the quote is attributed to David Bishop (in a few places including a 2007 conference paper) but I'm not certain if that's from a restatement (e.g. January 2006) or the original from Y2K or before. David Bishop has at least reused the quote in 2006 prior to the 2007 reference.Article: 145533
On Feb 12, 11:32=A0am, rickman <gnu...@gmail.com> wrote: <snip> > > In the case of using latches in place of registers, the speed gains > are always usable. =A0But can't the same sort of gains be made by > register leveling? =A0If you have logic that is slower than a clock > cycle followed by logic that is faster than a clock cycle, why not > just move some of the slow logic across the register to the faster > logic section? > > Rick I argued with my coworker for a few days about the benefit of latches versus registers before I finally realized the advantage of latch based designs. Not only is granularity less of a problem (e.g., only able to fit 2 logic delays in a level rather than the maximum 2.8 available, losing nearly 30%) but synchronous delays are different. Rather than accounting for Tco+Tsu for every register in a chain of a few clock cycles where register leveling is helpful, only the Tito transparent latch delay (minus the Tilo LUT delay) needs to be added for each latch in the chain [using Xilinx timing nomenclature]. I agree that the register based FPGAs are probably designed (and tested) to minimize Tsu and Tco without strong consideration for Tito and that the timing analysis is NOT set up to do a good job with "latch leveled" timing analysis. When I do use latches (when transferring data between rising/falling time domains for a fast clock, for instance) I have to specify false values around the latch for synchronous analysis rather than the precise values through the latch because the analysis wants to see registers at each stage even with the proper analysis flag turned on. If the analyzer would recognize a chain of rise/fall/rise/fall controlled latches and automatically increase the timing constraint by a half period for each stage, we'd potentially have a powerful tool at our disposal. But they don't so we don't. At least not in FPGAs. - John_HArticle: 145534
whygee <yg@yg.yg> wrote: >hi, > >recently I read a quote about VHDL vs Verilog, >along the lines of "VHDL is made by SW people who >don't understand HW and vice versa"... Bottom line is that VHDL is more powerful & complicated than Verilog but neither are the perfect language. For people with a background in schematic capture for FPGA design VHDL may be a big step to take. Verilog looks just like a netlist which is much closer the schematic capture. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 145535
On 2/13/2010 5:25 AM, whygee wrote: > thanks for the off-topic anyway :-) > > yg ...and thank you for taking it in the spirit it was intended! :-) All the best, Symon.Article: 145536
I saw this and thought of C.A.F. http://www.altera.com/corporate/news_room/releases/2010/products/nr-innovating-at-28-nm.html Fuck-a-doodle-do, 28 Gbps transceivers. Maybe now we will see who can really design a PCB and who is a blowhard. Bring. It. On!! Oh, there are some other interesting things also. Cheers, Syms.Article: 145537
In comp.arch.fpga John_H <newsgroup@johnhandwork.com> wrote: (snip) > I argued with my coworker for a few days about the benefit of latches > versus registers before I finally realized the advantage of latch > based designs. Not only is granularity less of a problem (e.g., only > able to fit 2 logic delays in a level rather than the maximum 2.8 > available, losing nearly 30%) but synchronous delays are different. > Rather than accounting for Tco+Tsu for every register in a chain of a > few clock cycles where register leveling is helpful, only the Tito > transparent latch delay (minus the Tilo LUT delay) needs to be added > for each latch in the chain [using Xilinx timing nomenclature]. I would have thought that they were fast enough now for that not to matter so much. My thought would be that clock skew, even with the fancy clock distribution system, would be the important factor. If the granularity is the problem then you might try clocking some on rising and some on falling edge (if available) or having two clocks with known phase difference. That would be especially true if the DLL's could generate the appropriate clocks. > I agree that the register based FPGAs are probably designed (and > tested) to minimize Tsu and Tco without strong consideration for Tito > and that the timing analysis is NOT set up to do a good job with > "latch leveled" timing analysis. > When I do use latches (when transferring data between rising/falling > time domains for a fast clock, for instance) I have to specify false > values around the latch for synchronous analysis rather than the > precise values through the latch because the analysis wants to see > registers at each stage even with the proper analysis flag turned on. > If the analyzer would recognize a chain of rise/fall/rise/fall > controlled latches and automatically increase the timing constraint by > a half period for each stage, we'd potentially have a powerful tool at > our disposal. But they don't so we don't. At least not in FPGAs. That sounds useful. If it gets popular enough, maybe they will add it. -- glenArticle: 145538
On Feb 14, 9:05=A0am, Symon <symon_bre...@hotmail.com> wrote: 28 Gbps transceivers. Maybe now we will see who can > really design a PCB and who is a blowhard. Bring. It. On!! Yes, the 28Gbps was more interesting than some 'another fab process notch' release. As for PCB design, doesn't that actually get easier, as you have less and less freedom of length ;) ?Article: 145539
> > The RTL community's reluctance to adopt what it can > from the software world is saddening and mystifying. > I cannot think of even one serious attempt to raise > the abstraction level of RTL design in the last > 20 years that has been commercially successful. > But RTL generally is very different to software, because RTL has the extra requirement that things have to happen at explicit times. I'm not sure RTL could adopt much from the software world that would make RTL quicker/easier. I can't think of how OO methods would work for RTL coding. For testbenches maybe. Although procedural testbenches are probably more than adequate for the majority of cases. Dynamic types of course are also no good for RTL, because signals/ variables are static. Dynamic languages could be used for testbenches but then dynamic languages are slower, possibly not what you want for testbenches. Although I guess the speed impact of a dynamic language for testbenches would depend on the relative complexity of a testbench to the RTL design. Agile methods are probably out. Apparently they're good for quickly changing code to accommodate quickly changing requirements. But because RTL coding is harder than writing software (because of the extra requirement that things have to happen happen at specific times), quickly changing RTL code isn't really possible. And for FPGA designs tying specs down to a reasonable level is a lot easier than for software engineering, because an FPGA has at least well defined requirements in what it has to drive on a circuit board. So just write the specs right, or mostly right to start with, and you don't need agile. I can't think of how any recent software methods would help RTL. Maybe I'm a stick-in-the-mud :-) > By contrast, VHDL's limitations in the world of > testbench writing are so severe that it's amazing > it gained any traction at all in that space. (1) vhdl is used for RTL so use the same language for testbenches, and (2) a lot of electronics engineers' requirements for test benches are pretty simple, and so VHDL is mostly adequate; i.e. basic test- benching, then debug on hardware, maybe also using something like chipscope. Writing good testbenches, especially self-checking ones, takes time. And you have to debug the testbenches as well as the RTL. So if you can debug the RTL in hardware, why spend a lot of time writing/ debugging testbenches? The reason why I say 'suspect' above is because I don't really know, but the majority of electronics engineers who design FPGAs that I've come across whilst working as an electronics engineer, do the minimum amount of testbenching, with self-cheking testbenches very thin on the ground. I'm supposing that full time ASIC/FPGA designers (rather than electronics engineers who design hardware as well as designing FPGAs) do put a lot of effort into writing good testbenches, but then they'll probably be using SystemVerilog or something similar. It would be interesting to see some statistics on debug methods actually used in industry. Of course you could say that if VHDL was easier to use for writing testbenches more electronics engineers would be writing more comprehensive testbenches, hmmm... It would be nice if VHDL had a more flexible approach to creating/ controlling processes (or threads or tasks, whatever they might be called). VHDL static processes are fine for RTL of course, but essentially a bit crumby for testbenches. It will be interesting to see what future vhdl standards throw up. I would like some process/ thread/task control in VHDL, much more than OO additions.Article: 145540
Symon wrote: > Fuck-a-doodle-do, 28 Gbps transceivers. Maybe now we will see who can > really design a PCB and who is a blowhard. Bring. It. On!! damnit, the fundamental wavelength of a 28GHz signal is smaller than the pin's pitch... or close... > Oh, there are some other interesting things also. like... hummm... the price tag ? oh, and the software tools that we'll have to pay to be able to debug for Altera ? > Cheers, Syms. happy hacking, yg -- http://ygdes.com / http://yasep.orgArticle: 145541
On Feb 13, 12:48 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sat, 13 Feb 2010 06:25:13 +0100, whygee wrote: > > By contrast, VHDL's limitations in the world of > testbench writing are so severe that it's amazing > it gained any traction at all in that space. > > Jonathan Bromley I am assuming the above was intended to read as "By contrast, Verilog's limitations in the world of testbench writing are so severe that it's amazing it gained any traction at all in that space." Just a slip or Freudian Slip?Article: 145542
On Feb 13, 3:09=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: <snip> > > Rather than accounting for Tco+Tsu for every register in a chain of a > > few clock cycles where register leveling is helpful, only the Tito > > transparent latch delay (minus the Tilo LUT delay) needs to be added > > for each latch in the chain [using Xilinx timing nomenclature]. > > I would have thought that they were fast enough now for that > not to matter so much. =A0My thought would be that clock skew, > even with the fancy clock distribution system, would be the important > factor. Clock skew becomes entirely unimportant in the latch scheme as I know it unless CLK and CLK180 are used instead of normal and inverted versions of the same clock. The latches are explicitly alternated posedge/negedge/posedge/negedge effectively decomposing a conceptual register into its two latches and balancing the logic between them. For clock skew to be an issue, two consecutive latches would have to be transparent long enough for the logic path plus delays to sneak through; that won't happen when using the normal and invert of the *same* clock net unless things are very, very wrong in the latch design. > If the granularity is the problem then you might try clocking > some on rising and some on falling edge (if available) or having > two clocks with known phase difference. =A0That would be especially > true if the DLL's could generate the appropriate clocks. Some... registers? Using the posedge and negedge in a registered arrangement would simply exacerbate the granularity problem, able to fit fewer whole delays into the same clock period by dividing the logic into two phases. The latches allow longer delays to move the valid data further toward the end of the transparent window and shorter delays to move it back, always with the safeguard that data for the next (half) cycle isn't allowed to be valid any sooner than the front edge of the transparent window. The description comes out a little muddy which is why it took me a few days to buy in to the whole concept. It's sweet! It just takes some timing diagrams and head scratching. And it's certainly not set up for proper analysis especially in the Xilinx tools where I experimented with the phase domain changes. - John_HArticle: 145543
On 2/13/2010 8:37 PM, -jg wrote: > On Feb 14, 9:05 am, Symon<symon_bre...@hotmail.com> wrote: > 28 Gbps transceivers. Maybe now we will see who can >> really design a PCB and who is a blowhard. Bring. It. On!! > > Yes, the 28Gbps was more interesting than some 'another fab process > notch' release. > > As for PCB design, doesn't that actually get easier, as you have less > and less freedom of length ;) ? You may be right. But if you are, my microwave buddies are gonna have to take a big pay cut! Hedging, I will still be taking them out for beer to steal their secrets. Shhhh... Syms.Article: 145544
On 2/13/2010 11:17 PM, Michael S wrote: > On Feb 13, 12:48 pm, Jonathan Bromley<jonathan.brom...@MYCOMPANY.com> > wrote: >> On Sat, 13 Feb 2010 06:25:13 +0100, whygee wrote: >> >> By contrast, VHDL's limitations in the world of >> testbench writing are so severe that it's amazing >> it gained any traction at all in that space. >> >> Jonathan Bromley > > I am assuming the above was intended to read as "By contrast, > Verilog's limitations in the world of testbench writing are so severe > that it's amazing it gained any traction at all in that space." > Just a slip or Freudian Slip? OT, but couldn't resist. A Freudian slip is when you say one thing, but mean amother. HTH, Syms.Article: 145545
On 2/13/2010 5:22 AM, KJ wrote: > On Feb 12, 8:16 pm, Symon<symon_bre...@hotmail.com> wrote: > >> ...to comp.lang.vhdl where you will find polite software people. Ask for >> Jonathan, Mike and KJ. Tell them I sent you. >> > > Ooooo...you read my posts and am on your recommended reading list > now!!! > > KJ I have do a lot of HDL in my job, and you guys really know your stuff. I rarely have to post to ask, because a search reveals your considered solutions! Thanks!! Syms.Article: 145546
On 2/13/2010 8:57 PM, whygee wrote: > Symon wrote: >> Fuck-a-doodle-do, 28 Gbps transceivers. Maybe now we will see who can >> really design a PCB and who is a blowhard. Bring. It. On!! > damnit, the fundamental wavelength of a 28GHz signal > is smaller than the pin's pitch... or close... > Right! We will see who paid attention in their maths lessons! à bientôt, Syms.Article: 145547
On Feb 13, 1:01=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > On Feb 12, 7:35=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > > On Feb 12, 10:32=A0am, rickman <gnu...@gmail.com> wrote: > > > > In the case of using latches in place of registers, the speed gains > > > are always usable. =A0But can't the same sort of gains be made by > > > register leveling? =A0If you have logic that is slower than a clock > > > cycle followed by logic that is faster than a clock cycle, why not > > > just move some of the slow logic across the register to the faster > > > logic section? > > > That's a similar technique, to be sure, for speed-gains. =A0But as I > > wrote in an earlier post, I think the primary motivation for latch- > > based design was originally cost. =A0For example, since each flop is > > really two latches, if you are going to have logic which ANDs together > > the output of two flops, you could replace that with ANDing the output > > of two latches, and outputting that result through another latch, for > > a net savings of 75% of the latches. > > Your method's target and the target used by CPU designers inserting > latches in the pipeline line are totally different. > > They use it because a combinational signal time delay is tool long to > fit within one clock cycle and too short within two clock cycles in a > pipeline, not in any places you may want to. I was agreeing with rickman that in many cases, register retiming can achieve similarly satisfactory results, while pointing out there were originally other reasons besides timing to use latches. I agree that latches are used for speed reasons, as well as cost reasons. But, as the paper you cite points out, the timing tools aren't very good at analyzing the speed, and I don't know about the specifics of the atom, but these days, if a chip designer wants something that goes faster, he'll just as often use some domino logic on a few paths rather than using simple latches -- same concept but even more complicated. In any case, you have to get your timing information somewhere -- a latch really is just half a flop, and you have to decide when to close it, so often you're either you're doing some fancy self-timing, or your local clock tree gets a lot more complicated when you are doing the described time-borrowing. Regards, PatArticle: 145548
On Feb 13, 6:21=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > The description comes out a little muddy which is why it took me a few > days to buy in to the whole concept. =A0It's sweet! =A0It just takes some > timing diagrams and head scratching. =A0And it's certainly not set up > for proper analysis especially in the Xilinx tools where I > experimented with the phase domain changes. It's not just FPGA tools. Many of the high-end chip tools don't support this very well, and to do it you need a PhD in the tool.Article: 145549
On Feb 13, 2:57=A0pm, whygee <y...@yg.yg> wrote: > Symon wrote: > damnit, the fundamental wavelength of a 28GHz signal > is smaller than the pin's pitch... or close... Well it's late, and I haven't looked at the announcement yet, but 1/28th of a ns should be slightly over a centimeter for light in a vacuum, probably around half an inch for a signal on a board -- exactly how far apart are the pins on this new chip :-) BTW, if you're talking about the wavelength, you can probably double that to around an inch, because 28Gbps using 1s and 0s is probably only a 14 GHz signal, right? Pat
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