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 138000

Article: 138000
Subject: Re: Why the second flip-flop in Virtex-6?
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Wed, 4 Feb 2009 01:56:56 +0100
Links: << >>  << T >>  << A >>

"glen herrmannsfeldt":
> Jan Bruns <testzugang_janbruns@arcor.de> wrote:

>> Will that Spartan6 have internal tristatable interconnects,
 
> As far as I know, that will never happen again.  It is part
> of the scaling laws for MOS circuits that as the circuitry
> gets smaller the RC time constant of wires increases.  
> R increases faster than C decreases, resulting in slower
> circuits.  The fix is to add buffers on longer lines,
> but those are directional.

That's probably not 100% fpga related, but why would R and C
change with smaller devices? Shouldn't R be constant for wires
(halfed length and width), and C shrink with either the
wire's surface or at most be constant shorter distance to 
other lines, but shorter)? 

BTW.: I mean a way to get wired a AND/OR, using some 
driver enable (to avoid MUXing many lines).

>> and/or better capabilites to build large MUXes?
 
> This should be possible.  As far as I know, AND/OR logic,
> where the signal and its enable drive an AND gate, then
> all the AND outputs drive an OR gate to generate the
> result.  That can be distributed back to where it is needed.

Sure, but there are only two options for an input to a mux:
register or combinatorial. If it is combinatorial, there might 
be a chance to absorb the AND with enable. If it's a register,
we have a "wasted" LUT per MUX-input.
The large OR at the end also adds levels of logic.
 
>> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4
>> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because
>> both CLBs won't absorb much of any logic following the mux32,
>> the result has to be routed far away.
> 
> Can you replace that with AND/OR logic?  

That could probably mean 
32 LUT4s for (en & src & a0 & a1)
11 LUT4s to OR the 32 signals
 8 LUT4s for a a2..a4 3->8 decoder 
========
61 LUT4s (much more then the 16 LUTs using a standard spartan3 MUX32)

>> It seems obvious to me that giving the spartan3 CLB additional full mux32
>> logic wasn't a theoretical problem nor would it blow up required routing
>> resources (since a CLB already has enough external interconnects), and
>> the remaining logic would still be theoretically usable without any
>> external routing blow up (maybe non-registered adders or registered
>> counters; not sure if these would mean exactly no blowup, but nearly).

Or what about a minimal hardwired (yet impossible) modification to the F5MUX:

module new_f5mux(f,g,f4,g4,f3,g3,bx,ce, o);
  parameter static_fsel = 1'b0;
  parameter static_gsel = 1'b0;
  input g,g,f3,f4,g3,g4,bx,ce;
  output o;
  wire mf = (ce) ? f3 : f4;  // hardwired, but
  wire mg = (ce) ? g3 : g4;  // dynamic
  wire fq = (static_fsel) ? f : mf;  // config-time
  wire gq = (static_gsel) ? g : mg;  // static
  assign o = (bx) ? fq : gq;
endmodule

This would still allow a MUX16 per CLB or MUX32 per 2 CLBs,
but would free many other resources in the CLBs (carrychains,
LUT2, FlipFlops driven local, without ce, but still with reset 
option).

How does this compare to "dualport-ram option" the SLICEMs have.

Gruss

Jan Bruns



Article: 138001
Subject: Re: FFT core has reversed output data
From: kennheinrich@sympatico.ca
Date: Tue, 3 Feb 2009 17:44:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 1:53=A0pm, "kristian" <kri...@gmx.de> wrote:
> >> Kris,
>
> >> No idea about the details of the Xilinx core, but if you have real
> >> valued input data and complex output data, you can expect that the
> >> output (if you reverse the output samples, with the DC value at the
> >> middle) is the negative complex conjugate (see Wikipedia or a standard
> >> textbook). That means you could just swap the real and imaginary
> >> output, assuming it's a real bug that you want to hack up a fix for.
>
> >Mental misfire... negative complex conjugate is just inverting the
> >real part; no swap required.

Aargh...simple conjugate... have to remember to do the math before I
open my mouth.

>
> >> Alternatively, the behaviour you describe for a simple sinusoid could
> >> be correct, since you didn't specify the start phase. A sinusoid
> >> that's off by 180 degrees (pi radians) will have its value (dirac fft
> >> coeffs) multiplied by exp(i*pi) =3D3D -1.
>
> >> =3DA0- Kenn
>
> Hi Kenn,
>
> to verify the results of the fft core I used a java applet
> (http://sepwww.stanford.edu/oldsep/hale/FftLab.html). When I put at the
> input of the core a sinus for the real part and a cosinus for the imagina=
ry
> part then the java applet show only a positiv dirac puls at x(k) at the
> imaginary frequency domain. This result I also expect at the fft core
> output. But I get at x(N-k) a positiv dirac puls.
>
> Regards,
> Kris

Interesting. If you consider a sine input at pi/2, the input data
looks like

[0,+1,0,-1,...]

For a 16-point FFT, the exponential term exp(-j2pi*nk/N) in the fft
series for X[4] looks like

[1, -i, -1, +i, ...]

So the sum of products should be negative imaginary at X[4].  I can
see this expected value out of Matlab's fft as well, and it matches
your measured output.  But when I type this data into your java
simulator, it doesn't give me what I expect. So, assuming your input
data is the same, perhaps your testbench rather than your
implementation has the bug :-)

 - Kenn

Article: 138002
Subject: Re: Why the second flip-flop in Virtex-6?
From: -jg <Jim.Granville@gmail.com>
Date: Tue, 3 Feb 2009 18:37:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 4:12=A0am, jhal...@TheWorld.com (Joseph H Allen) wrote:
> I'm surprised that the Spartan-6 integrated memory controller does not su=
pport
> DIMMs. =A0Also surprised that there are no integrated memory controllers =
in
> Virtex-6.
>
> Note the Virtex-6 Select-IO voltage range: only up to 2.5V! =A02.5V is th=
e
> new 5V...

The Spartan 6 Guide says Standards up to 3.3V ?
Where is the 2.5V limit given ?

-jg

Article: 138003
Subject: Re: Spartan-6
From: -jg <Jim.Granville@gmail.com>
Date: Tue, 3 Feb 2009 18:42:51 -0800 (PST)
Links: << >>  << T >>  << A >>
> "One Spartan-6 FPGA, an LX16 device, is already sampling..."
> "The Spartan-6 family is priced at between about $3 and $54 in high
> volume of 10,000 units..."

10,000 is not really 'high volumes' ?

Xilinx used to quote  "Over the Horizon" prices,
eg for parts 250,000 pcs, delivered at the end of 2010.

Maybe sense finally prevails....?

-jg




Article: 138004
Subject: Re: Tabula - new kid on the FPGA block?
From: -jg <Jim.Granville@gmail.com>
Date: Tue, 3 Feb 2009 18:56:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 5:56=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> Anyone know anything about
>
> =A0www.tabula.com
>
> ??? =A0They are operating very firmly in "stealth" mode
> right now, but they have money, lots of patents and
> some high-profile people.
>
> A very quick scan of their patents suggests that they
> may be doing something with very fast - truly dynamic -
> reconfiguration of FPGA logic; one of the abstracts
> tantalisingly talks about reconfiguration faster
> than the system clock. =A0Lack of time, and frustration
> with the way the USPTO website fools around with
> QuickTime when you try to view images, has stopped
> me from going any further.
>
> Their "early adopter" pages don't seem to be up just yet.
>
> Maybe, just maybe, this and Achronix represent a real
> change in the FPGA game. =A0Interesting.
> --
> Jonathan Bromley, Consultant

Too early to extract much from their website, but History is against
them.
The further they move from standard FPGAs, the less existing Software
work they can leverage, and cracking BOTH the Silicon and Software is
the double hurdle FPGA startups face.
Also, not a great time to be pitching new devices...

-jg



Article: 138005
Subject: Re: Digilent Nexys 2 Issue
From: "freespace@gmail.com" <freespace@gmail.com>
Date: Tue, 3 Feb 2009 19:59:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 3:47=A0am, "freesp...@gmail.com" <freesp...@gmail.com> wrote:
>
> Even thought I emailed digilent about it pre-Christmas, I haven't had
> an email from the with a link to the new software, which I will try
> tomorrow morning. Hope it fixes my woes.
>
> Cheers,
> Steve

Hrm, it would appear I already had the latest version of adept and
export, and using the 2.0 version from the coolrunner package as Red
suggested didn't work either.

I still can't initalise the scan chain due to too many invalid devices
showing up (see my link in the previous post for a detailed account of
my problems).

At this point I am all out of idea, but would like to ask those if you
who have working Nexys2 boards to kindly post:

* your OS version
* whether you are shorting any pins on the JTAG port
* setting of the MODE jumper (jp9)

Cheers,
Steve

Article: 138006
Subject: Re: Invalid devices when initialising scan chain with Nexys2
From: "freespace@gmail.com" <freespace@gmail.com>
Date: Tue, 3 Feb 2009 20:02:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 8 2008, 7:44=A0pm, "freesp...@gmail.com" <freesp...@gmail.com>
wrote:
> I will ask the Digilent people. I have to use their ExPort program to
> communicate with my Nexys2 since it uses some usb-jtag magic. I might
> just by the Xilinx cable though if this continues to be a problem.
>
> Thank you for your advice.
Have asked digilent people, so far no progress and no advice besides
what has been said here and elsewhere on the net.

The last I heard from them their lead engineer is looking into it, and
the board might be broken leading to a broken chain. I

If the latter is the case, then their QC and self test is not doing
its job.

Cheers,
Steve

Article: 138007
Subject: Re: Spartan-6
From: Eric Smith <eric@brouhaha.com>
Date: Tue, 03 Feb 2009 20:33:28 -0800
Links: << >>  << T >>  << A >>
Simon <google@gornall.net> writes:
> well, this is all very nice, but more importantly, when are they going
> to actually start delivering these things, and how much will they
> cost ?
>
> I can't really believe they haven't *got* that information, so why the
> staged release of info ?

When was the last time that a semiconductor vendor gave you such
information about a major new product release, and the information
actually proved to be reasonably accurate?

Article: 138008
Subject: Re: Why the second flip-flop in Virtex-6?
From: Eric Smith <eric@brouhaha.com>
Date: Tue, 03 Feb 2009 20:58:24 -0800
Links: << >>  << T >>  << A >>
-jg <Jim.Granville@gmail.com> writes:
> The Spartan 6 Guide says Standards up to 3.3V ?
> Where is the 2.5V limit given ?

In the Virtex 6 guide.

Article: 138009
Subject: Re: Spartan-6
From: rickman <gnuarm@gmail.com>
Date: Tue, 3 Feb 2009 21:59:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 9:42=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> > "One Spartan-6 FPGA, an LX16 device, is already sampling..."
> > "The Spartan-6 family is priced at between about $3 and $54 in high
> > volume of 10,000 units..."
>
> 10,000 is not really 'high volumes' ?
>
> Xilinx used to quote =A0"Over the Horizon" prices,
> eg for parts 250,000 pcs, delivered at the end of 2010.
>
> Maybe sense finally prevails....?

I agree that their previous pricing was pretty absurd.  I wonder if
*any* customers ever got those numbers.  Still, I think 10,000 is not
very realistic for many of us, but then anyone buying less than 10,000
is likely not even on the Xilinx radar screen.  Personally, I like the
way TI does it listing the 1000 piece price and giving direct links to
the disti's web pages showing real prices.

I will very surprised if they can really sell any of the Spartan 6
parts for $3.  The smallest part they sell has 100 I/Os and who knows
how much logic.  I think it is about 2K LUTs and 4K FFs.  From what I
have been told most of the cost of a small part is from the testing
and that is dominated by the I/O count.  The cheapest part is likely
going to be around $10 at qty 1000 IMHO.

Rick

Article: 138010
Subject: Re: Spartan-6
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Wed, 04 Feb 2009 08:25:59 +0200
Links: << >>  << T >>  << A >>
Eric Smith wrote:

> When was the last time that a semiconductor vendor gave you such
> information about a major new product release, and the information
> actually proved to be reasonably accurate?

Under NDA for bigger customers the vendors give very accurate
information way before the launch and quite accurate estimates
on sample deliveries etc. Of course there are possible slips but
they estimate then new schedules. Many people do designs for
those chips way before the public release, and have own product
launch schedules also.

--Kim

Article: 138011
Subject: Sixteen serial ports ?
From: Bob Smith <usenet@linuxtoys.org>
Date: Tue, 03 Feb 2009 22:32:54 -0800
Links: << >>  << T >>  << A >>
Hi,

I would like to use a Spartan 3 100K FPGA to implement 16
serial ports.  The ports will be fairly simple: 1200 to
115200 baud, Tx, Rx, and two flow control lines per port.

I already have a working serial port and could make sixteen
instances of it.  This would chew up a lot of the FPGA.

Is there a better way to build sixteen serial ports?


Would it make sense to build one serial port and try to
time division multiplex it to the sixteen sets of inputs,
perhaps keeping all state information in RAM?  Is this a
feasible or reasonable approach?


thanks in advance
Bob Smith


Article: 138012
Subject: Core interface protocol
From: Manny <mloulah@hotmail.com>
Date: Tue, 3 Feb 2009 22:33:13 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

In trying to conform to good design practices, I have been doubting
lately my old ways. Until now, I've interfaced most of my cores to the
external system using standard 2/4-phase asynchronous handshake
protocols. Was wondering how good of a practice is this and whether
there is a definitive handbook out there in the literature that
tackles these issues. Don't want to sink into SoC bussing literature
with overly complicated arbitration since most of the designs I work
on are of the simple and tightly-coupled sort.

Would appreciate any pointers on this.

Regards,
Manny

Article: 138013
Subject: Re: Why the second flip-flop in Virtex-6?
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Wed, 04 Feb 2009 08:38:47 +0200
Links: << >>  << T >>  << A >>
Jan Bruns wrote:

> That's probably not 100% fpga related, but why would R and C
> change with smaller devices? Shouldn't R be constant for wires
> (halfed length and width), and C shrink with either the
> wire's surface or at most be constant shorter distance to 
> other lines, but shorter)? 

The problem is that with smaller nodes the geometry of the wires
is changed. They have become very narrow but tall compared to the
old more rectangular ones. Also the length might not be halved,
because the chip has more logic. The die sizes have been quite
constant all the time (io-pads create the first limit how small
the die can become).

Also the propagation delay in the metal wire is proportional to the
square of the wire length, with repeaters that can be changed to linear
dependency. That is one big reason to remove tristate busses inside the
chips, they would not work very fast.

--Kim

Article: 138014
Subject: Re: Why the second flip-flop in Virtex-6?
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Wed, 04 Feb 2009 08:42:15 +0200
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> No, 3.3V was the old new 5V.  The new new 5V is 2.5V.  Altera Straitx-IV
> also does not support 3.3V I/O.

Also in some of the new chips that still support the 3.3v volt the drive
strength might be very low, even so low that is is almost unusable.

--Kim

Article: 138015
Subject: generating 320Mhz clk from 80Mhz source in Virtex4-vlx100 (-11)
From: amk565@gmail.com
Date: Tue, 3 Feb 2009 23:56:28 -0800 (PST)
Links: << >>  << T >>  << A >>
I have the following problem.

The input clock to the FPGA, Virtex4-vlx100 (-11) is 80MHz.
For the design, I'll need to generate a 160Mhz and 320Mhz clock.
The 160Mhz clock is not a problem.

However, using the single DCM, I'm not able to generate this 320Mhz
clock.
As CLKFX output only goes up to 315MHz, according to COREGEN.

SO single DCM is out of the question and decided on trying cascade
DCM.

From the COREGEN, there is a function "Cascading in Series with 2
DCM_ADVs" for Virtex-4.
So I think it's better to use that.

a. I've configured ... "Select  clock for cascading" to be CLK2X.
b. Then I select the "Input frequency" of the 1st DCM to be 80MHz
but COREGEN pop-up an error message
"Only low frequency mode is valid for Cascading in series
Please enter an Input Clock Frequency  value within  the valid Low
Frequency rang.
DLL Low frequency mode 32.000Mhz - 75.000 MHz."

This 75MHz doesn't seem to agree with what is written in the datasheet
(eg. 150MHz)

So, my questions are
1. Are there any better way to achieve 320MHz without cascading DCM?
2. Is the 75MHz limit defined on purpose to prevent excessive jitter?
3. Should I just instantiate and cascade the DCMs, to avoid the
COREGEN limitation?

thanks for any help.
ed









Article: 138016
Subject: Re: xilinx platform usb cable linux troubles
From: "h.e." <he@thisisnovalidaddress.net>
Date: Wed, 04 Feb 2009 09:19:45 +0100
Links: << >>  << T >>  << A >>
>  Using libusb.
> Connecting to cable (Usb Port - USB21).
> Checking cable driver.
> File version of /tools/Xilinx_10.1_x86_64/ISE/bin/lin64/xusbdfwu.hex =
> 1030.
> File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1030.
>  Using libusb.
>  Max current requested during enumeration is 74 mA.
> Type = 0x0004.
>  Cable Type = 3, Revision = 0.
>  Setting cable speed to 6 MHz.
> Cable connection established.
> Firmware version = 1303.
> File version of /tools/Xilinx_10.1_x86_64/ISE/data/xusb_xlp.hex =
> 1303.
> Firmware hex file version = 1303.
> PLD file version = 0012h.
>  PLD version = 0012h.

This is my log with ise10.1 sp3 and libusb, maybe it helps to update the
firmware files being loaded? do you use the udev-rules suggested by
xilinx? ($XILINX/bin/lin64/xusbdfwu.rules)

 Using libusb.
Connecting to cable (Usb Port - USB21).
Checking cable driver.
File version of /opt/Xilinx/10.1/ISE/bin/lin64/xusbdfwu.hex = 1100.
File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1100.
 Using libusb.
 Max current requested during enumeration is 74 mA.
Type = 0x0004.
 Cable Type = 3, Revision = 0.
 Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1303.
File version of /opt/Xilinx/10.1/ISE/data/xusb_xlp.hex = 1303.
Firmware hex file version = 1303.
PLD file version = 0012h.
 PLD version = 0012h.

Article: 138017
Subject: Re: Tabula - new kid on the FPGA block?
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Wed, 4 Feb 2009 01:10:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 5:56=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> Anyone know anything about
>
> =A0www.tabula.com
>
> ??? =A0They are operating very firmly in "stealth" mode
> right now, but they have money, lots of patents and
> some high-profile people.

Sounds like 90% of all startups homepage text if you ask me.

>
> A very quick scan of their patents suggests that they
> may be doing something with very fast - truly dynamic -
> reconfiguration of FPGA logic; one of the abstracts
> tantalisingly talks about reconfiguration faster
> than the system clock. =A0Lack of time, and frustration
> with the way the USPTO website fools around with
> QuickTime when you try to view images, has stopped
> me from going any further.

went over to www.google.com/patents and searched for tabula.inc and
got a few hits. At least on my setup with firefox it was no problem to
view the patents and even download them as pdf if I wanted. I did also
not have good luck at uspto with their tiff offer. I don't know if all
patents on uspto are available at google, but that's probably a minor
detail.

>
> Their "early adopter" pages don't seem to be up just yet.

As long as they are in "stealth mode" they probably don't have any
real devices or customers, just hot air and press releases. They are
polishing the bride.

>
> Maybe, just maybe, this and Achronix represent a real
> change in the FPGA game. =A0Interesting.

Anything new may lead to a change if they are bought by the right
company. This is more or less outsourced business development for
companies too big to get it done themselves. Startups are highly
dynamic (hire and fire) organisations that suits well to ride the
storm of bringing an idea to something worth putting into mass-
production, as long as the venture capital doesn't dry out half-way
there.

--
Svenn

Article: 138018
Subject: Re: Tabula - new kid on the FPGA block?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 04 Feb 2009 09:15:15 +0000
Links: << >>  << T >>  << A >>
On Wed, 4 Feb 2009 01:10:22 -0800 (PST), Svenn Are Bjerkem wrote:

>Anything new may lead to a change if they are bought by the right
>company. This is more or less outsourced business development for
>companies too big to get it done themselves. Startups are highly
>dynamic (hire and fire) organisations that suits well to ride the
>storm of bringing an idea to something worth putting into mass-
>production, as long as the venture capital doesn't dry out half-way
>there.

Nice to know I'm not the only curmudgeonly cynic out there :-)

You're probably right.  Pessimists are rarely disappointed.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138019
Subject: Re: Why the second flip-flop in Virtex-6?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 4 Feb 2009 09:31:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jan Bruns <testzugang_janbruns@arcor.de> wrote:
 
> "glen herrmannsfeldt":
>> Jan Bruns <testzugang_janbruns@arcor.de> wrote:
>>> Will that Spartan6 have internal tristatable interconnects,
 
>> As far as I know, that will never happen again.  It is part
>> of the scaling laws for MOS circuits that as the circuitry
>> gets smaller the RC time constant of wires increases.  
>> R increases faster than C decreases, resulting in slower
>> circuits.  The fix is to add buffers on longer lines,
>> but those are directional.
 
> That's probably not 100% fpga related, but why would R and C
> change with smaller devices? Shouldn't R be constant for wires
> (halfed length and width), and C shrink with either the
> wire's surface or at most be constant shorter distance to 
> other lines, but shorter)? 

Wires shrink in width and height, both of which change
the resistance, C depends (mostly) just on width. 
Shrink by a factor of 2, R increases by a factor
of (about) 4, C decreases by a factor of 2.

If you actually shrink the die then the length would
also decrease, but it is more usual to keep the die size
and put more CLBs on.
 
> BTW.: I mean a way to get wired a AND/OR, using some 
> driver enable (to avoid MUXing many lines).
 
>>> and/or better capabilites to build large MUXes?
 
>> This should be possible.  As far as I know, AND/OR logic,
(snip)
 
> Sure, but there are only two options for an input to a mux:
> register or combinatorial. If it is combinatorial, there might 
> be a chance to absorb the AND with enable. If it's a register,
> we have a "wasted" LUT per MUX-input.
> The large OR at the end also adds levels of logic.

When you did have tristate devices on the chip interior
they were in special places, complicating routing.
 
>>> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4
>>> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because
>>> both CLBs won't absorb much of any logic following the mux32,
>>> the result has to be routed far away.
 
>> Can you replace that with AND/OR logic?  
 
> That could probably mean 
> 32 LUT4s for (en & src & a0 & a1)
> 11 LUT4s to OR the 32 signals
> 8 LUT4s for a a2..a4 3->8 decoder 
> ========
> 61 LUT4s (much more then the 16 LUTs using a standard spartan3 MUX32)

Plus the priority encoder to use for the MUX inputs?

As I understand it, some tools will convert a wide (bus)
MUX into a decode and AND/OR logic.  For a single MUX
that doesn't seem to help.

-- glen

Article: 138020
Subject: Re: Sixteen serial ports ?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 4 Feb 2009 09:38:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
Bob Smith <usenet@linuxtoys.org> wrote:
 
> I would like to use a Spartan 3 100K FPGA to implement 16
> serial ports.  The ports will be fairly simple: 1200 to
> 115200 baud, Tx, Rx, and two flow control lines per port.
 
> I already have a working serial port and could make sixteen
> instances of it.  This would chew up a lot of the FPGA.
 
> Is there a better way to build sixteen serial ports?
 
> Would it make sense to build one serial port and try to
> time division multiplex it to the sixteen sets of inputs,
> perhaps keeping all state information in RAM?  Is this a
> feasible or reasonable approach?

So only one data bus for all 16?  My first thought is,
assuming you have FIFOs on them, would be to multiplex the
FIFOs (write the port and data into the FIFO) for the
receiver, and then when you read it read the data and port.

For the transmitter, that probably doesn't work, but you
could use one RAM and 32 pointer registers.  (top and
bottom for each UART.)   Can you use the SRL16 for the
shift registers?  Otherwise, a UART shouldn't be all
that big.

-- glen


Article: 138021
Subject: Re: Sixteen serial ports ?
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 4 Feb 2009 01:43:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 7:32=A0pm, Bob Smith <use...@linuxtoys.org> wrote:
> Hi,
>
> I would like to use a Spartan 3 100K FPGA to implement 16
> serial ports. =A0The ports will be fairly simple: 1200 to
> 115200 baud, Tx, Rx, and two flow control lines per port.
>
> I already have a working serial port and could make sixteen
> instances of it. =A0This would chew up a lot of the FPGA.
>
> Is there a better way to build sixteen serial ports?
>
> Would it make sense to build one serial port and try to
> time division multiplex it to the sixteen sets of inputs,
> perhaps keeping all state information in RAM? =A0Is this a
> feasible or reasonable approach?

What did your calculator say ?
115200 baud is 8.68us, at x8 or 16 sampling, that's ~2MHz. Split that
16 ways
and you have ~32MHz - does not sound high.....
15-16 byte fifos would likely fit into a ~byte sized state variable.


Article: 138022
Subject: Re: Spartan-6
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 4 Feb 2009 01:53:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 6:59=A0pm, rickman <gnu...@gmail.com> wrote:
> I will very surprised if they can really sell any of the Spartan 6
> parts for $3. =A0The smallest part they sell has 100 I/Os and who knows
> how much logic. =A0I think it is about 2K LUTs and 4K FFs. =A0From what I
> have been told most of the cost of a small part is from the testing
> and that is dominated by the I/O count. =A0The cheapest part is likely
> going to be around $10 at qty 1000 IMHO.

Sounds about right.
Smallest part says 3366 Logic cells, 9101 for larger sibling, and
largest in TQFG144.

I would paste in the table but Xilinx has disabled COPY in the PDF,
and I would
give a link to a google find that would allow you to View as HTML, but
google
cannot find the named pdf, even when pointed to Xilinx.com.

Seems Xilinx really is doing everything to prevent anyone sharing this
information!!

[I wonder if they even realize this....]

-jg



Article: 138023
Subject: Re: Why the second flip-flop in Virtex-6?
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 4 Feb 2009 01:59:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 5:58=A0pm, Eric Smith <e...@brouhaha.com> wrote:
> -jg <Jim.Granvi...@gmail.com> writes:
> > The Spartan 6 Guide says Standards up to 3.3V ?
> > Where is the 2.5V limit given ?
>
> In the Virtex 6 guide.

So it seems they made a deliberate process decision, for Virtex 6 to
be
2.5V, and Spartan 6 to be 3.3V ?

That's  a large market to isolate your devices from - one hopes the
few picoseconds of speed that might have gained, turn out to be wrth
it!! :)

-jg
.

Article: 138024
Subject: Re: Why the second flip-flop in Virtex-6?
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Wed, 04 Feb 2009 12:15:18 +0200
Links: << >>  << T >>  << A >>
-jg wrote:
> So it seems they made a deliberate process decision, for Virtex 6 to
> be
> 2.5V, and Spartan 6 to be 3.3V ?

One decision maker might be, that usually new expensive designs are
not interfacing very old chips. But on the other hand cheap chips
can be used to cost reduce old designs or replace old ASICs.


> That's  a large market to isolate your devices from - one hopes the
> few picoseconds of speed that might have gained, turn out to be wrth
> it!! :)

It more a question of die space. 3.3v tolerant IO is huge in 40/45nm.
In V6 they are trying to reach the high end of IO and LUT counts. On
the other hand with S6 the LUT counts are not that high and also the IO
count is lower than in V6 so they can waste space for the IO.

--Kim



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