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 132575

Article: 132575
Subject: Combinatorial logic delay plus routing delay exceeds clock period
From: "Sam Worth" <no-reply@some.org>
Date: Sun, 1 Jun 2008 17:00:52 -0700
Links: << >>  << T >>  << A >>
Generally speaking, it is not good, if a module's combinatoral logical delay 
plus the routing delay exceed the clock period.

A certain module calculates a 100-bit accumulation in approxinately 5ns (in 
a Virtex 5LXT-1). However, the design clock period is 4ns.

I could break the sum logic into two pieces, register the high-50-bits, 
adding the low-50-bits into a register, adding the registered high-50-bits 
with carry from the low-50-bits, and finally concatenate the high-50-bit sum 
with the registered low-50-bit registered sum. That would satifiy timing 
requirements. Howerver, the extra 100-bits of register resources does not 
seem offer a benefit and likely increases the likelyhood that a larger 
device will be required. There could be hundreds of these 100-bit adders in 
the design.

So, the module calculates the 100-bit accumulation in one go, taking 5ns and 
100 less registers than the preceeding example. Obviously, the input terms 
must remain stable for two clock periods for the sum to be valid and this is 
accounted for in the upper logic layers.

My issue is how to tell the ISE tool-chain that the 5ns total delay is 
acceptable in these modules. The Constraints Guide may cover this issue, but 
I do not see it. Can someone give me an example of the appropriate 
constraint usage?

Thanks in advance.

- Sam 



Article: 132576
Subject: Re: Combinatorial logic delay plus routing delay exceeds clock period
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 1 Jun 2008 17:13:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 1, 5:00=A0pm, "Sam Worth" <no-re...@some.org> wrote:
> Generally speaking, it is not good, if a module's combinatoral logical del=
ay
> plus the routing delay exceed the clock period.
>
> A certain module calculates a 100-bit accumulation in approxinately 5ns (i=
n
> a Virtex 5LXT-1). However, the design clock period is 4ns.
>
> I could break the sum logic into two pieces, register the high-50-bits,
> adding the low-50-bits into a register, adding the registered high-50-bits=

> with carry from the low-50-bits, and finally concatenate the high-50-bit s=
um
> with the registered low-50-bit registered sum. That would satifiy timing
> requirements. Howerver, the extra 100-bits of register resources does not
> seem offer a benefit and likely increases the likelyhood that a larger
> device will be required. There could be hundreds of these 100-bit adders i=
n
> the design.
>
> So, the module calculates the 100-bit accumulation in one go, taking 5ns a=
nd
> 100 less registers than the preceeding example. Obviously, the input terms=

> must remain stable for two clock periods for the sum to be valid and this =
is
> accounted for in the upper logic layers.
>
> My issue is how to tell the ISE tool-chain that the 5ns total delay is
> acceptable in these modules. The Constraints Guide may cover this issue, b=
ut
> I do not see it. Can someone give me an example of the appropriate
> constraint usage?
>
> Thanks in advance.
>
> - Sam

I would create two accumulators and drive their Enable inputs at half
frequency, in counterphase.
Peter Alfke

Article: 132577
Subject: Re: Combinatorial logic delay plus routing delay exceeds clock period
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 2 Jun 2008 01:20:01 +0100
Links: << >>  << T >>  << A >>
"Sam Worth" <no-reply@some.org> wrote in message 
news:4843384c$0$12931$4c368faf@roadrunner.com...
>
> So, the module calculates the 100-bit accumulation in one go, taking 5ns 
> and 100 less registers than the preceeding example. Obviously, the input 
> terms must remain stable for two clock periods for the sum to be valid and 
> this is accounted for in the upper logic layers.
>
> My issue is how to tell the ISE tool-chain that the 5ns total delay is 
> acceptable in these modules. The Constraints Guide may cover this issue, 
> but I do not see it. Can someone give me an example of the appropriate 
> constraint usage?
>
> Thanks in advance.
>
> - Sam
Hi Sam,

Read the constraints guide. Also, Google this:-
 multi cycle path

NET "clock_en" TNM=FFS "clock_enable";
TIMESPEC TS1 = FROM : clock_enable : TO : clock_enable : 8ns  ;

HTH., Syms.



Article: 132578
Subject: Re: Combinatorial logic delay plus routing delay exceeds clock period
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 01 Jun 2008 19:15:44 -0800
Links: << >>  << T >>  << A >>
Sam Worth wrote:

> Generally speaking, it is not good, if a module's combinatoral logical delay 
> plus the routing delay exceed the clock period.

I believe there have been designs that depended on the delay being
long enough.

> A certain module calculates a 100-bit accumulation in approxinately 5ns (in 
> a Virtex 5LXT-1). However, the design clock period is 4ns.

I would say that 5ns is too close, and for FPGA that you can't predict
the times that well, anyway.  There are many stories about Cray and
his computers related to logic delay.  (There is also the Cray-2
resonant box story, where to accomplish a 4ns clock cycle they
designed a box resonant at 250MHz.  Unfortunately, the clock cycle
ended up being 4.2ns, and much delay in product release.)

> I could break the sum logic into two pieces, register the high-50-bits, 
> adding the low-50-bits into a register, adding the registered high-50-bits 
> with carry from the low-50-bits, and finally concatenate the high-50-bit sum 
> with the registered low-50-bit registered sum. That would satifiy timing 
> requirements. Howerver, the extra 100-bits of register resources does not 
> seem offer a benefit and likely increases the likelyhood that a larger 
> device will be required. There could be hundreds of these 100-bit adders in 
> the design.

FPGAs usually have so many FF's that registers are free.  Without
knowing anything else about the design, though, pipelining is usually
a good thing.  The question always is where to put the pipeline
registers for best effect.

> So, the module calculates the 100-bit accumulation in one go, taking 5ns and 
> 100 less registers than the preceeding example. Obviously, the input terms 
> must remain stable for two clock periods for the sum to be valid and this is 
> accounted for in the upper logic layers.

Is there no other loss in reducing the clock rate for that
part of the design?

-- glen


Article: 132579
Subject: Re: Combinatorial logic delay plus routing delay exceeds clock period
From: "Sam Worth" <no-reply@some.org>
Date: Sun, 1 Jun 2008 21:37:10 -0700
Links: << >>  << T >>  << A >>
"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1778944e-c20b-4263-9979-de97a3ad80d7@z24g2000prf.googlegroups.com...
I would create two accumulators and drive their Enable inputs at half
frequency, in counterphase.
Peter Alfke

That sounds interesting and something I would like to learn about. Do you 
have an example of such technique?

- Sam 



Article: 132580
Subject: Re: Combinatorial logic delay plus routing delay exceeds clock period
From: Mike Treseler <mtreseler@gmail.com>
Date: Sun, 01 Jun 2008 22:06:45 -0700
Links: << >>  << T >>  << A >>
Sam Worth wrote:
> "Peter Alfke" <alfke@sbcglobal.net> wrote in message 
> I would create two accumulators and drive their Enable inputs at half
> frequency, in counterphase.
> Peter Alfke
> 
> That sounds interesting and something I would like to learn about. Do you 
> have an example of such technique?

Follow the red wire here for two register banks
on opposite enable phases:
  http://mysite.verizon.net/miketreseler/count_enable.pdf

      -- Mike Treseler

Article: 132581
Subject: Re: Combinatorial logic delay plus routing -- typo
From: Mike Treseler <mtreseler@gmail.com>
Date: Sun, 01 Jun 2008 22:10:05 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Sam Worth wrote:
>> "Peter Alfke" <alfke@sbcglobal.net> wrote in message I would create 
>> two accumulators and drive their Enable inputs at half
>> frequency, in counterphase.
>> Peter Alfke
>>
>> That sounds interesting and something I would like to learn about. Do 
>> you have an example of such technique?
> 
> Follow the red wire here for two register banks
> on opposite enable phases:
>  http://mysite.verizon.net/miketreseler/count_enable.pdf

sorry. Make that:
    http://mysite.verizon.net/miketreseler/stack.pdf

       -- Mike Treseler

Article: 132582
Subject: Re: (won't even attempt to try again .. .. ..)
From: Eric Smith <eric@brouhaha.com>
Date: Sun, 01 Jun 2008 23:57:24 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> Well, does this http://www.andraka.com/shortwave.htm demo project
> count? I did it as a demo back in early 2003.  It worked surprisingly
> well considering there is no analog front end.

Very cool!  Any plans to publish more details of the design?

Best regards,
Eric

Article: 132583
Subject: Help with $setuphold
From: FP <FPGA.unknown@gmail.com>
Date: Mon, 2 Jun 2008 06:08:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am running a simulation after synthesis and I am getting the
following error.

** Error: C:/Modeltech_xe_starter/library/lib18.v(9835):
$hold( posedge CK &&& (flag == 1):54 ns, posedge E:54 ns, 500 ps );

lib18.v is a library with various net delays. I dont have anything
setup for setup and hold in my verilog testbench. I am getting the
same error, no matter what frequency I run the master clock at. How do
I get rid of this error?
Currenty the master clock is running at 200MHz(4 ns period)

Your help would be appreciated

Article: 132584
Subject: Re: Help with $setuphold
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 2 Jun 2008 06:39:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 9:08=A0am, FP <FPGA.unkn...@gmail.com> wrote:
> I am running a simulation after synthesis and I am getting the
> following error.
>
> ** Error: C:/Modeltech_xe_starter/library/lib18.v(9835):
> $hold( posedge CK &&& (flag =3D=3D 1):54 ns, posedge E:54 ns, 500 ps );
>
> lib18.v is a library with various net delays. I dont have anything
> setup for setup and hold in my verilog testbench. I am getting the
> same error, no matter what frequency I run the master clock at. How do
> I get rid of this error?
> Currenty the master clock is running at 200MHz(4 ns period)
>

The reported error appears to be a hold time violation which means
that the signal is not remaining stable for the required amount of
time after the rising edge of the clock.  To fix.
1. Identify exactly which signal it is
2. Determine if this is a design error or a modelling error and then
apply the appropriate fix.
3. Re-run the simulation.

As a first guess, it is likely that your testbench signals get
generated on the rising edge of your clock input and then go into your
design.  But if the design has some non-zero hold time requirement
then the testbench inputs will be changing before the required time
and generate the error that you're seeing.  This type of problem is
frequently a modelling error, your model of the environment in which
your design is operating is flawed in that it does represent the real
world (no real part would generate an input 0ns after the rising edge
of a clock).  One way to fix this type of error would be to generate
the inputs on the falling edge of the clock.

It's also possible that the input signal truly is asynchronous to your
system clock.  In this situation, hold time (and setup time)
violations are inevitable, your design has to handle the async inputs
properly with internal synchronizers but there is no way to get rid of
the simulation detecting the violation since it really is occurring.
One possible work around though would be to artificially add
synchronization to the testbench.

Kevin Jennings

Article: 132585
Subject: Re: (won't even attempt to try again .. .. ..)
From: Ray Andraka <ray@andraka.com>
Date: Mon, 02 Jun 2008 10:14:04 -0400
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> Ray Andraka wrote:
> 
>>Well, does this http://www.andraka.com/shortwave.htm demo project
>>count? I did it as a demo back in early 2003.  It worked surprisingly
>>well considering there is no analog front end.
> 
> 
> Very cool!  Any plans to publish more details of the design?
> 
> Best regards,
> Eric


I had been working on a chapter for it in my book.  I gave up the book 
project because I was finding I couldn't dedicate enough time to it.  I 
may eventually post more details on that page on my website.  I kind of 
want to avoid putting the whole thing up there and giving college 
students a ready-made project.

Article: 132586
Subject: Re: Combinatorial logic delay plus routing delay exceeds clock period
From: "Sam Worth" <no-reply@some.org>
Date: Mon, 2 Jun 2008 08:35:47 -0700
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:g1vebu$q48$1@aioe.org...
> Hi Sam,
>
> Read the constraints guide. Also, Google this:-
> multi cycle path
>
> NET "clock_en" TNM=FFS "clock_enable";
> TIMESPEC TS1 = FROM : clock_enable : TO : clock_enable : 8ns  ;
>
> HTH., Syms.

Thank, Symon. That did the trick.

- Sam 



Article: 132587
Subject: Problem with Xilinx 9.2i and Modelsim 6.0
From: ghuardian@gmail.com
Date: Mon, 2 Jun 2008 08:58:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I`m trying to make a temporal simulation ( Post place & route
model ) of a FPGA designed in Xilinx 9.2i in Modelsim 6.0, but the
Modelsim gives me an error of type Error - (vsim 3193), refered from a
library called swifpli_mti.dll wich Modelsim doesn=B4t find.

I can't get other Modelsim, and I was looking in the modelsim.ini
file, changing any command that I found in Internet. This changes made
the Modelsim execute the Behavorial model with a Xilinx core filters,
but I didn't get the temporal simulation runs.

How could I repared this?

Thank you very much

Article: 132588
Subject: Re: xilinx and jtag
From: Charles Xavier <skelotar@gmail.com>
Date: Mon, 2 Jun 2008 12:03:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 31, 10:16=A0am, <discussi...@fpga.usenet> wrote:
> I have a jtag programmer with a 20pin idc connector.
> Are these in general suitable for cplds/fpgas?
>
> Also, I have the following test program. The program
> is supposed to switch on =A0a led when the input is hi.
> Is this program ok?
>
> module modled(a1, b1);
> input wire a1;
> output wire b1;
>
> assign b1=3Da1;
>
> endmodule

Yes, the jtag programmer is suitable for cplds/fpgas from a variety of
manufacturers. JTAG is a standard and as such will be compatible. As
for your program, try simulating and seeing what you get.

Article: 132589
Subject: Re: xilinx and jtag
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 2 Jun 2008 12:54:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
discussi...@fpga.usenet wrote:
> I have a jtag programmer with a 20pin idc connector.
> Are these in general suitable for cplds/fpgas?
>
> Also, I have the following test program. The program
> is supposed to switch on  a led when the input is hi.
> Is this program ok?
>
> module modled(a1, b1);
> input wire a1;
> output wire b1;
>
> assign b1=a1;
>
> endmodule

Keep in mind the 20 pin header may be rearranged from what your cpld/
fpga board expects; there is no header standard used throughout the
industry.  Also please make sure your JTAG voltages are compatible.
Does your jtag programmer include your xilinx devices as a target?  I
end up just using the Xilinx USB Platform Cable to program my chips
directly from the Xilinx utilities when I'm doing iterative design.  A
different JTAG programmer will probably need a generic, compatible
file format.

The Verilog module you included is one step in your journey.  You may
find a high on the input turns off the LED by driving the cathode
high, depending on your board (active low logic).  You still need to
compile the code, assign pins, place & route the design, and generate
a programming file.

You have all that down?  It should be covered pretty well in the
documantation available to you.

Welcome to the fun,
- John_H

Article: 132590
Subject: clock divider
From: FP <FPGA.unknown@gmail.com>
Date: Mon, 2 Jun 2008 13:10:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
How do I design a clock divider without using initial conditions. I
designed once using initial values but they dont mean anything in
synthesis.

Thanks in advance for your help

Article: 132591
Subject: Re: clock divider
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 2 Jun 2008 13:12:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 4:10=A0pm, FP <FPGA.unkn...@gmail.com> wrote:
> How do I design a clock divider without using initial conditions.

With a reset signal.

> I designed once using initial values but they dont mean anything in
> synthesis.
>
If your targetted part has a specified power up state and the tools
that you choose to use support initial values then initial values will
work just fine.

KJ

Article: 132592
Subject: Re: ANNOUNCE:-- TimingAnalyzer Free Version -- Draw timing diagrams
From: Andy Peters <google@latke.net>
Date: Mon, 2 Jun 2008 14:40:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 5:58 am, timinganalyzer <timinganaly...@gmail.com> wrote:
> Hello All,
>
> The TimingAnalyzer can be used to quickly and easily draw timing
> diagrams.
> Signals, clocks, buses, delays, constraints, and states are easily
> added
> from the GUI.
>
> It can also be used to quickly do a timing analysis and check for
> timing faults. Minimum, typical, and worst case analysis can be
> performed.
> Delays and constraints are easily specified and changed to see if
> faster
> clocks or slower parts can be used without any timing faults.
>
> There are 3 editions planned.  The Free Edition(FE),  the Standard
> Edition(SE),
> and the Professional Edition(PE).
>
> You can download the Free Edition now and read all about the
> TimingAnalyzer at:
>
> www.timing-diagrams.com
>
> Comments and feedback are welcome at
>
> supp...@timing-diagrams.com

Hey, it's back!

It's good to see that this hasn't died. The commercial alternatives
are WAAAAAY too expensive.

-a

Article: 132593
Subject: Celoxica (AgilityDS) running on Gentoo
From: Simon <wlpstxzhd@gmail.com>
Date: Mon, 2 Jun 2008 16:06:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am a lover of Gentoo, I managed to do almost everything including my
life and work in Gentoo. The only one thing left stuck me is the
Celoxica DK which is intended to be working at RHEL, SUSE, or Debian
based box. I did emerge  rpm and dpkg, but still cannot get it
working. If by chance anyone managed to get it working, could you
please share with me? Thanks.

Simon

Article: 132594
Subject: Re: Combinatorial logic delay plus routing delay exceeds clock period
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 2 Jun 2008 16:21:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 8:35=A0am, "Sam Worth" <no-re...@some.org> wrote:
> "Symon" <symon_bre...@hotmail.com> wrote in message
>
> news:g1vebu$q48$1@aioe.org...
>
> > Hi Sam,
>
> > Read the constraints guide. Also, Google this:-
> > multi cycle path
>
> > NET "clock_en" TNM=3DFFS "clock_enable";
> > TIMESPEC TS1 =3D FROM : clock_enable : TO : clock_enable : 8ns =A0;
>
> > HTH., Syms.
>
> Thank, Symon. That did the trick.
>
> - Sam

Sam, here is an even simpler solution that works if you accumulate for
many clock ticks and can sacrifice two or three clock ticks before you
get the result.
You just divide the long accumulator into 2, 3, or 4 parts, with a
single carry flip-flop between (you thus pipeline the carry signal)
Then, at the end, you use 1, 2, or 3 clock ticks to flush the carry
through the accumulator. It costs you no additional hardware at all,
(Virtex-5 has the pipeline flip-flop built-in) and it runs as fast as
a short accumulator. You pay with the latency at the end. There is no
free lunch...
Peter Alfke

Article: 132595
Subject: Re: ANNOUNCE:-- TimingAnalyzer Free Version -- Draw timing diagrams
From: timinganalyzer <timinganalyzer@gmail.com>
Date: Mon, 2 Jun 2008 17:37:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 2, 5:40 pm, Andy Peters <goo...@latke.net> wrote:
> On Jun 2, 5:58 am, timinganalyzer <timinganaly...@gmail.com> wrote:
>
>
>
> > Hello All,
>
> > The TimingAnalyzer can be used to quickly and easily draw timing
> > diagrams.
> > Signals, clocks, buses, delays, constraints, and states are easily
> > added
> > from the GUI.
>
> > It can also be used to quickly do a timing analysis and check for
> > timing faults. Minimum, typical, and worst case analysis can be
> > performed.
> > Delays and constraints are easily specified and changed to see if
> > faster
> > clocks or slower parts can be used without any timing faults.
>
> > There are 3 editions planned.  The Free Edition(FE),  the Standard
> > Edition(SE),
> > and the Professional Edition(PE).
>
> > You can download the Free Edition now and read all about the
> > TimingAnalyzer at:
>
> >www.timing-diagrams.com
>
> > Comments and feedback are welcome at
>
> > supp...@timing-diagrams.com
>
> Hey, it's back!
>
> It's good to see that this hasn't died. The commercial alternatives
> are WAAAAAY too expensive.
>
> -a

Yes,  it's alive and doing well, and yes the competition is expensive.
The TimingAnalyzer will not be.  I'm trying very hard to make it as
easy as
possible to use.

Please feel free to request new features or suggest feature
improvements.

Regards,
Dan

Article: 132596
Subject: Re: Checksums
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Tue, 3 Jun 2008 01:35:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-06-03, Ambreen Ashfaq Afridi <amboafridi@gmail.com> wrote:
> hi all,
>  Im working on a project in FPGAs called "network Traffic Manager" in
> verilog implemented in virtex 4. Im using trimode ethernet MAC core in
> it. Now i have to send a packet via ethernet to the other machine and
> recalculate the checksum. For that i have to first calculate the
> cheksum. Now the problem is that im a bit confused as to which
> algorithm should I use to calculate the cheksum. I started to work on
> TCP/IP checksum algo but now im totally confused b/w TCP/IP checksum
> and CRC. So can anyone tell me which algo shud i use?

Normally the ethernet MAC will take care of the CRC, so you will only
need to care about the TCP/IP checksums.

/Andreas

Article: 132597
Subject: Re: Are FPGAs headed toward a coarse granularity?
From: rickman <gnuarm@gmail.com>
Date: Mon, 2 Jun 2008 18:58:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 29, 7:56 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> On 29 Mai, 07:59, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
> But, if you need 49 bits you lose a factor of two immediately. (The
> fabric implementation grows only by a 2%, the DSP48 implementation by
> 100%)

I don't know that adders are a good comparison because they are pretty
durn fast in an FPGA.  The carry chain has been highly optimized and
are still pretty good even at 48 bits.  But if that is what people
want from FPGAs, then I guess it shows that the dedicated logic route
does not always pay large dividends.


> It should be noted that in FPGAs both delay and area are dominated by
> the routing ressources. Therefore mainly the granularity of the
> routing should be optimized.

I have never thought of "granularity" as a property of routing, but I
see your point.  I seem to recall that the ORCA devices claimed to
facilitate routing of the four bit hunks their LUTS/FFs were arranged
in.  They didn't drop the 1x routing, but they had more of the 4x than
other devices might have had.  That was quite a while back when it was
still AT&T.


> No design has millions of gates of random logic. Large designs are
> dominated by arithmetic function blocks. Therefore it is likely that
> an FPGA with a granularity of 2 for example will have a much better
> efficiency than current FPGAs. For random control logic half of the
> LUTs would remain unused, but for datapathes the utilization would
> approach 100% and the device coud save as much as 75% of the switches
> and configuration bits.

When you say "dominated", can you put that in definitive terms?  The
larger designs I have worked on were still very data path oriented
with a lot of muxes (still not very efficient in generic LUT
architectures) and pipeline delays.  This was all IP type comms work,
not RF/IF or mod/demod type stuff.


> This is old knowledge for FPGA architecure folks, but there are two
> strong arguments against it:
>
> 1.)
> It is hard to quantify routing utilization, but the competitors
> marketing will immediately target the lower LUT utilization as a
> disadvantage. (But hey, if a LUT costs 75% less, who cares if I can
> only use 80% of the LUTS? Especially if the clock frequency is
> better?)

Yes, that is in line with the quote I made above, "We sell you the
routing and throw in the logic for free!", and that was in the days of
XC4000 devices!  It is pretty impressive in fact, just how dominating
the routing is in an FPGA.  The image in the chip editors is a pretty
close approximation to the real spacial relations from what I have
heard.  If you zoom all the way out you will see very little of the
logic, the chip is overwhelmingly routing.  But like you point out, it
is as much a marketing issue as anything.  But even the technical
people get wrapped up in the numbers game.  It is more than once I
have seen a post here about how "their" brand of chip is so much
better because it has these features that let you do so much more in
so little real estate... but in the end real estate is not on my list
of FPGA critera, I only care about speed, power cost, etc.  If feature
X impacts those things, then I want to know that explicitly, not by
inference.  This trade off between routing and logic is similar in
that no one wants to be known for only being 75% routable even if I
can still fit my design in a cheaper chip because of it.

> 2)
> Granularity 1 FPGAs make use of the huge knowledge about ASIC EDA
> algorithms. For higher granularities you need to redevelopemost of the
> software toolflow from scratch.

Does it really require new toolflows from *scratch*?  I would expect
that the current tools could be adopted.


> There is a small FPGA vendor that has high speed global routing with
> 10bit granularity. Maybe this is a start. The area savings are
> marginal, as most of the switches are in local routing, but the speed
> improvement for long connections is significant.

That is interesting, especially how it improves the speed rather than
density.

Rick

Article: 132598
Subject: Checksums
From: Ambreen Ashfaq Afridi <amboafridi@gmail.com>
Date: Mon, 2 Jun 2008 19:26:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi all,
 Im working on a project in FPGAs called "network Traffic Manager" in
verilog implemented in virtex 4. Im using trimode ethernet MAC core in
it. Now i have to send a packet via ethernet to the other machine and
recalculate the checksum. For that i have to first calculate the
cheksum. Now the problem is that im a bit confused as to which
algorithm should I use to calculate the cheksum. I started to work on
TCP/IP checksum algo but now im totally confused b/w TCP/IP checksum
and CRC. So can anyone tell me which algo shud i use?

plz reply asap
thank u
Regards
Ambreen Ashfaq

Article: 132599
Subject: Re: Checksums
From: Ambreen Ashfaq Afridi <amboafridi@gmail.com>
Date: Mon, 2 Jun 2008 20:49:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
just for information:
TCP/IP chksum calculates chksum on psuedo header which includes some
fields from ip and some from TCP
ip source add
ip destination add
tcp length
tcp protocol number
etc





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