Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 145525

Article: 145525
Subject: Re: VHDL vs Verilog
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 13 Feb 2010 10:34:26 +0000
Links: << >>  << T >>  << A >>
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 Bromley

Article: 145526
Subject: Re: VHDL vs Verilog
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 13 Feb 2010 10:48:50 +0000
Links: << >>  << T >>  << A >>
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 Bromley

Article: 145527
Subject: Re: VHDL vs Verilog
From: whygee <yg@yg.yg>
Date: Sat, 13 Feb 2010 13:31:11 +0100
Links: << >>  << T >>  << A >>
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.org

Article: 145528
Subject: Re: VHDL vs Verilog
From: whygee <yg@yg.yg>
Date: Sat, 13 Feb 2010 13:31:21 +0100
Links: << >>  << T >>  << A >>
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.org

Article: 145529
Subject: Re: VHDL vs Verilog
From: whygee <yg@yg.yg>
Date: Sat, 13 Feb 2010 13:32:14 +0100
Links: << >>  << T >>  << A >>
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.org

Article: 145530
Subject: Re: VHDL vs Verilog
From: whygee <yg@yg.yg>
Date: Sat, 13 Feb 2010 13:49:52 +0100
Links: << >>  << T >>  << A >>
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: 145531
Subject: Re: VHDL vs Verilog (quote found)
From: whygee <yg@yg.yg>
Date: Sat, 13 Feb 2010 14:14:28 +0100
Links: << >>  << T >>  << A >>
John_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.org

Article: 145532
Subject: Re: VHDL vs Verilog
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 13 Feb 2010 05:28:47 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: What is the basis on flip-flops replaced by a latch
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 13 Feb 2010 06:00:01 -0800 (PST)
Links: << >>  << T >>  << A >>
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_H

Article: 145534
Subject: Re: VHDL vs Verilog
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 13 Feb 2010 15:39:49 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: VHDL vs Verilog
From: Symon <symon_brewer@hotmail.com>
Date: Sat, 13 Feb 2010 19:15:06 +0000
Links: << >>  << T >>  << A >>
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
Subject: 28nm FPGAs are coming...
From: Symon <symon_brewer@hotmail.com>
Date: Sat, 13 Feb 2010 20:05:36 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: What is the basis on flip-flops replaced by a latch
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 13 Feb 2010 20:09:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 145538
Subject: Re: 28nm FPGAs are coming...
From: -jg <jim.granville@gmail.com>
Date: Sat, 13 Feb 2010 12:37:27 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: VHDL vs Verilog
From: Paul <pault.eg@googlemail.com>
Date: Sat, 13 Feb 2010 12:46:15 -0800 (PST)
Links: << >>  << T >>  << A >>

>
> 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
Subject: Re: 28nm FPGAs are coming...
From: whygee <yg@yg.yg>
Date: Sat, 13 Feb 2010 21:57:04 +0100
Links: << >>  << T >>  << A >>
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.org

Article: 145541
Subject: Re: VHDL vs Verilog
From: Michael S <already5chosen@yahoo.com>
Date: Sat, 13 Feb 2010 15:17:09 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: What is the basis on flip-flops replaced by a latch
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 13 Feb 2010 16:21:35 -0800 (PST)
Links: << >>  << T >>  << A >>
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_H

Article: 145543
Subject: Re: 28nm FPGAs are coming...
From: Symon <symon_brewer@hotmail.com>
Date: Sun, 14 Feb 2010 01:31:30 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: VHDL vs Verilog
From: Symon <symon_brewer@hotmail.com>
Date: Sun, 14 Feb 2010 01:35:12 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: VHDL vs Verilog
From: Symon <symon_brewer@hotmail.com>
Date: Sun, 14 Feb 2010 01:41:38 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: 28nm FPGAs are coming...
From: Symon <symon_brewer@hotmail.com>
Date: Sun, 14 Feb 2010 01:50:48 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: What is the basis on flip-flops replaced by a latch
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sat, 13 Feb 2010 21:14:07 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Pat

Article: 145548
Subject: Re: What is the basis on flip-flops replaced by a latch
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sat, 13 Feb 2010 21:17:51 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: 28nm FPGAs are coming...
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sat, 13 Feb 2010 21:28:54 -0800 (PST)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search