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 62850

Article: 62850
Subject: Re: ASIC vs FPGA
From: nagaraj_c_s@yahoo.com (Nagaraj)
Date: 10 Nov 2003 02:57:22 -0800
Links: << >>  << T >>  << A >>
For all your basic questions you can read the book on "ASIC" by
Micheal John Sebastin Smith. According to me this is the ASIC bible
for beginners.

regards,
CS

"newbie" <nospam@nospam.org> wrote in message news:<W7wrb.13571$Mn.339275@news.xtra.co.nz>...
> Hi all
> 
> Can someone help in understanding the main difference between ASIC and FPGA.
> I keep hearing both these terms and am not fully clear.
> Is there a website explaning this?
> 
> Thanks

Article: 62851
Subject: Re: 0.13u device with 5V I/O
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 11 Nov 2003 00:02:34 +1300
Links: << >>  << T >>  << A >>
Eric Crabill wrote:
> 
> Hi,
> 
<snip>
> >  Can you think of an instance where a customer would need
> > both at once, on the same pin ?
> 
> For a general purpose FPGA, with general purpose programmable
> I/O, you need this on every pin...  While the end user makes
> a selection via the bitstream, the actual hardware has to be
> capable of handling all possible configurations.

Not true. Some of the more esoteric IOs are already 'blocked'
Users could live with not having 5V IO on every single IO, 
jus like they live with not having 840MHz SerDes on every IO.

> On recent devices, 5V I/O is gone...  I would not be surprised
> if it's the same issue all over again with 3.3V in a few years.

Depends on where you look, and why.
On embedded controllers, 5V is actually making a comeback.
Lattices' very newest CPLDs, added 5V tolerant IOs.

On chip regulators are also appearing, as other vendors look
at ways to expand the use-ability of the shrink silicon.
 
> As I had mentioned, it is possible to build a device to support
> 5V I/O.  That device will cost more for everyone, even if they
> are not using 5V I/O.  Those I/O will also be slower.  I believe
> few people would buy these parts, due to the higher cost and
> lower performance.

Give the customers some hard numbers, and let them decide for
themselves :)

I see Hynix have just released a high voltage 0.18u process,
that targets LCD display drivers (so high voltage here means
40-50V region )

> 
> There are other approaches -- things like dedicated banks of I/O
> just for a specific purpose.  Xilinx uses this for the gigabit
> serial transceivers in V2pro.  One could do something similar
> but for a bank of 5V I/O.  For 5V I/O, it would still make the
> devices more expensive.

Some numbers ?  XX cents per pin ?

> > The point is, if FPGA wish to broaden their market with
> > processor cores, and so play in the larger controller
> > sandpit, they are going to have to address issues that
> > normally go into the 'too hard / not enough market'
> > reflex-box.
> 
> If there's "not enough market" I doubt anyone trying to make
> money is going to address it.  If there were a significant
> market, but there were technical hurdles, I am sure people
> here, and at other FPGA vendors, would be researching a way
> to cash in on it.

 They are already. 
Wider Vcc range devices are appearing, you just have to look 
for them (they are not appearing in FPGA markets first). 
 Narrow/lowered/restricted Vcc devices have been replaced
by better engineered, wider Vcc ones.

 There was an interesting earlier thread that touched on leakage
failure modes in higher IO on the finest processes.

-jg

Article: 62852
Subject: VirtexII-Pro: Why is ICAP slower than SelectMAP?
From: Sean Durkin <23@iis.42.de>
Date: Mon, 10 Nov 2003 12:48:04 +0100
Links: << >>  << T >>  << A >>
Hi all,

xapp660 states that the maximum frequency for the ICAP (internal version 
of the SelectMAP-interface) is 35MHz. Yet the maximum frequency for 
SelectMAP is supposed to be 50MHz. How come there's a difference there 
if the whole point of ICAP is to give you access to the regular 
SelectMAP-port with all its capabilities from within the FPGA? Isn't 
ICAP supposed to be just a way to access the exact same logic that is 
connected to the outside via a set of pins? So the why does it make a 
difference if I access the same configuration logic via pins from 
outside the FPGA or via nets from within?

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])


Article: 62853
Subject: How to create a look up table for a RAM application
From: andres.vazquez@gmx.de (Vazquez)
Date: 10 Nov 2003 04:48:04 -0800
Links: << >>  << T >>  << A >>
Dear Sir or Madame,

I have a data packet which has a 13 bit field for an USB
application(7bit + 4bit + 1bit + 1bit).


Because of lack of memory I do create a RAM which
has a data input width of only 10 bit. The write address of
the RAM is [4..0], i.e. 32 words á 10 bit.
The words which are written into the RAM 
are searched for later (CAM-like function).

The problem: I have to reduce 13 bit to 10 bit without losing the
significance of the 13 bit. But it is not possible to leave out for
example
two bits of the 7bit (usb address) because the enumeration by the host
is not
predictable.

How could I solve this problem?

Thank you very much.

Best regards

Andres Vazquez
G&D System Development

Article: 62854
Subject: Re: ISE 5.2 to 6.1
From: "Giuseppe³" <miaooaim.REMOVETHIS@libero.it>
Date: Mon, 10 Nov 2003 13:53:03 +0100
Links: << >>  << T >>  << A >>
Hi,
In my experience, when I have to move from a release to another of the ISE,
I prefer to create a new project and reuse only the vhdl file and the ucf
file.
Sometimes there are a strange incompatibility from the release that can
generate strange behaviour.

By
Giuseppe

"colin hankins" <colinhankins@cox.net> ha scritto nel messaggio
news:kzCrb.14571$Zb7.8816@fed1read01...
> I installed ISE 6.1 with the service pack and my Spartan IIe design that
> worked fine under 5.2 no longer works in the timing simulation in 6.1.
Also,
> the number of Slices used increased by 10% as well as the TBUFS. I have
> fiddled with almost every combination of options in the synth, map, and
par
> to try and recreate the better results I had in ISE 5.2. I talked to
Xilinx
> and they just told me to fiddle with the parameters some more. Has anyone
> else had similar problems migrating a project from 5.2 to 6.1?
>
> Regards,
> Colin
>
>



Article: 62855
Subject: Unconstrained net to DLL's
From: "Morten Leikvoll" <m-leik@online.nospam>
Date: Mon, 10 Nov 2003 16:10:03 +0100
Links: << >>  << T >>  << A >>
I'm trying to get rid of all unconstrained nets and wonder how I can specify
max delay for nets that is (partly) used to reset DLL's. There are keywords
for FFS, LATCHES and RAMS, but none for DLLs?



Article: 62856
Subject: Re: ISE 5.2 to 6.1
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 10 Nov 2003 07:17:59 -0800
Links: << >>  << T >>  << A >>
Yes, there has been discussion on this group regarding this
"phenomenon."  I have a design that lost about 10% in timing going to
6.1 and that was with heavy use of timing constraints and area
constraints.  I ended up having to hand place individual LUTs (which
also means I lost many of the benefits of synthesis).  I wasn't very
happy.

I've gone back to 5.2 on some of my projects.  6.1 on a few, but with
this kind of track record, I don't have much faith in 6.1.  If it
ain't broke...

   Jake


"colin hankins" <colinhankins@cox.net> wrote in message news:<kzCrb.14571$Zb7.8816@fed1read01>...
> I installed ISE 6.1 with the service pack and my Spartan IIe design that
> worked fine under 5.2 no longer works in the timing simulation in 6.1. Also,
> the number of Slices used increased by 10% as well as the TBUFS. I have
> fiddled with almost every combination of options in the synth, map, and par
> to try and recreate the better results I had in ISE 5.2. I talked to Xilinx
> and they just told me to fiddle with the parameters some more. Has anyone
> else had similar problems migrating a project from 5.2 to 6.1?
> 
> Regards,
> Colin

Article: 62857
Subject: Enumeration by Host Controller
From: andres.vazquez@gmx.de (Vazquez)
Date: 10 Nov 2003 07:19:20 -0800
Links: << >>  << T >>  << A >>
Hi, 

I have a question concerning the enumeration by USB 2.0 host
controllers:
How does the host controller enumerate the devices, in a sequential or
in a random order?
Are there differences between controllers 
or is it left to the designer's own controller programming ressources?

Thanks a lot. 

Kind regards

Article: 62858
Subject: Re: VirtexII-Pro: Why is ICAP slower than SelectMAP?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 10 Nov 2003 07:48:01 -0800
Links: << >>  << T >>  << A >>
Sean,

It has to do with what we are able to test, and thus what we are able to
specify.

The ICAP should be just as fast, but not being able to verify that easily
makes it something that gets specified in a safe region where 100% of the
parts are guaranteed to operate.

Austin

Sean Durkin wrote:

> Hi all,
>
> xapp660 states that the maximum frequency for the ICAP (internal version
> of the SelectMAP-interface) is 35MHz. Yet the maximum frequency for
> SelectMAP is supposed to be 50MHz. How come there's a difference there
> if the whole point of ICAP is to give you access to the regular
> SelectMAP-port with all its capabilities from within the FPGA? Isn't
> ICAP supposed to be just a way to access the exact same logic that is
> connected to the outside via a set of pins? So the why does it make a
> difference if I access the same configuration logic via pins from
> outside the FPGA or via nets from within?
>
> --
> Sean Durkin
> Fraunhofer Institute for Integrated Circuits (IIS)
> Am Wolfsmantel 33, 91058 Erlangen, Germany
>
> mailto:23@iis.42.de
> ([23 , 42] <=> [durkinsn , fraunhofer])


Article: 62859
Subject: Re: FPGA Prototyping Board
From: "Sergej" <hilgurt@ukr.net>
Date: Mon, 10 Nov 2003 17:48:54 +0200
Links: << >>  << T >>  << A >>

If this project is realized, pls. let me know too: ser@hil.kiev.ua

Sergej Hilgurt




Article: 62860
Subject: Re: Home grown CPU core legal?
From: news@sulimma.de (Kolja Sulimma)
Date: 10 Nov 2003 07:55:36 -0800
Links: << >>  << T >>  << A >>
> If by some chance I ever used my home grown, ISA compatible, core in a
> commercialized product, would there be legal issues?   Chances are I
> would never use my own and would probably use a Nios or Microblaze
> instead, but if I just needed a simple little core, it could prove
> useful.

AFAIK (and IANAL) the only effective legal way against a processor
clone are patents. This means that very old designs like the 8051,
6502, PIC, etc. should be no problem.
The patents only affect ways to design or implement the processor, not
the ISA. So if you knew the patents you could design the CPU in a way
that does not violate the patent. Unfortuanatle as an amateur you can
never be sure what kind of wierd patents suddenly surface out of
nowhere.

The ISA can not be protected effectively. This does not mean that a
pissed processor vendor will not send a hord of lawyers after you to
scare you or to cover you in loads of expensive paperwork. Therefore
you should stay away from CPUs from companies that live from processor
licensing fees. (Like ARM or MIPS)

If you really want to play it safe you should implement a SPARC ISA.
That's an open standard.

Or do a reimplementation of picoblaze or microblaze or xr16. I believe
that Xilinx won't mind another Microblaze implementation that helps
selling there Chips. (Göran, can you comment on that?)

And Jan Gray explicitely stated that he does not object to
reimplementations of his xr16 design.

Kolja Sulimma



Article: 62861
Subject: Re: Home grown CPU core legal?
From: Goran Bilski <goran@xilinx.com>
Date: Mon, 10 Nov 2003 17:17:13 +0100
Links: << >>  << T >>  << A >>


Hi,

I can't see why Xilinx would be against a clean room implementation of 
MicroBlaze.
It would actually be quite interesting.
We actually want to promote the use of MicroBlaze.
We are not getting our money from MicroBlaze sells but rather on the 
FPGAs that MicroBlaze uses.
If someone did a clean room, open source implementation of MicroBlaze it 
would probably letting us sell more FPGAs.

As Kolja said, you can't really effectively patent an ISA, only an 
implementation.
BUT an implementation can have certain features which you can patent and 
thus make it hard to design around that patent.
ARM has the shadow registers at interrupts and MIPS has the unaligned 
word access handling,...

Even if you did a clean room implementation of ARM and avoid all 
patents, ARM will sue you to the end.
So unless you have big financial backing that will pay your lawyers, you 
will not win.

Göran

Kolja Sulimma wrote:

>>If by some chance I ever used my home grown, ISA compatible, core in a
>>commercialized product, would there be legal issues?   Chances are I
>>would never use my own and would probably use a Nios or Microblaze
>>instead, but if I just needed a simple little core, it could prove
>>useful.
>>    
>>
>
>AFAIK (and IANAL) the only effective legal way against a processor
>clone are patents. This means that very old designs like the 8051,
>6502, PIC, etc. should be no problem.
>The patents only affect ways to design or implement the processor, not
>the ISA. So if you knew the patents you could design the CPU in a way
>that does not violate the patent. Unfortuanatle as an amateur you can
>never be sure what kind of wierd patents suddenly surface out of
>nowhere.
>
>The ISA can not be protected effectively. This does not mean that a
>pissed processor vendor will not send a hord of lawyers after you to
>scare you or to cover you in loads of expensive paperwork. Therefore
>you should stay away from CPUs from companies that live from processor
>licensing fees. (Like ARM or MIPS)
>
>If you really want to play it safe you should implement a SPARC ISA.
>That's an open standard.
>
>Or do a reimplementation of picoblaze or microblaze or xr16. I believe
>that Xilinx won't mind another Microblaze implementation that helps
>selling there Chips. (Göran, can you comment on that?)
>
>And Jan Gray explicitely stated that he does not object to
>reimplementations of his xr16 design.
>
>Kolja Sulimma
>  
>




Article: 62862
Subject: Re: VirtexII-Pro: Why is ICAP slower than SelectMAP?
From: Sean Durkin <23@iis.42.de>
Date: Mon, 10 Nov 2003 17:22:55 +0100
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Sean,
> 
> It has to do with what we are able to test, and thus what we are able to
> specify.
> 
> The ICAP should be just as fast, but not being able to verify that easily
> makes it something that gets specified in a safe region where 100% of the
> parts are guaranteed to operate.
Thanks for the info, Austin.

It seems to me that the 35MHz is indeed all ICAP can handle. At least 
I've tried 33MHz and 38Mhz, and it works fine with the first but doesn't 
with the latter, so 35MHz seems reasonable.

Whereas the strange thing is that it even works at 50MHz, but only for a 
while.

I posted awhile back that I had trouble performing a readback of the CLB 
configuration data via ICAP. Now I know it's because I used a CCLK out 
of spec (I was using 50MHz back then), but the strange thing is that it 
worked fine for about 370000 bytes, stopping exactly at the same point 
each and every time I tried, so problems with the clock weren't the 
first thing I looked into.

Seems like there's some error accumulating there that sums up to a 
S/H-time violation or something after a give time...

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])


Article: 62863
Subject: Re: Home grown CPU core legal?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 10 Nov 2003 16:42:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <b890a7a.0311100755.72deef43@posting.google.com>,
Kolja Sulimma <news@sulimma.de> wrote:

>The ISA can not be protected effectively. This does not mean that a
>pissed processor vendor will not send a hord of lawyers after you to
>scare you or to cover you in loads of expensive paperwork. Therefore
>you should stay away from CPUs from companies that live from processor
>licensing fees. (Like ARM or MIPS)

I'm not so sure about this, look at some of the unique ISA features
(eg, the initial conditional execution in ARM, the IA64 deferred
exceptions (good idea) and rotating register file (bad idea)).  I
think these items can and are patented.

>If you really want to play it safe you should implement a SPARC ISA.
>That's an open standard.

Just don't call it SPARC.  You have to say "Sparc Compatabile IEEE
whatever" until you pay sparc money.  But that's no big deal.

>Or do a reimplementation of picoblaze or microblaze or xr16. I believe
>that Xilinx won't mind another Microblaze implementation that helps
>selling there Chips. (Göran, can you comment on that?)

Microblaze is probably a nice one, since it should map well to large
families of FPGAs.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 62864
Subject: Re: Home grown CPU core legal?
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 10 Nov 2003 08:49:22 -0800
Links: << >>  << T >>  << A >>
Hi Goran,
    So, playing devli's advocate, Xilinx wouldn't mind if the clean room
Microblaze was targeted at their competitors' devices? Or do you think that
no one would do this because Microblaze only efficiently fits the Xilinx
devices? Or the competitors have their own solutions for their parts?
    I wonder....
                cheers, Syms.


"Goran Bilski" <goran@xilinx.com> wrote in message
news:boodq5$bgr2@cliff.xsj.xilinx.com...
Hi,

I can't see why Xilinx would be against a clean room implementation of
MicroBlaze.
It would actually be quite interesting.
We actually want to promote the use of MicroBlaze.
We are not getting our money from MicroBlaze sells but rather on the FPGAs
that MicroBlaze uses.
If someone did a clean room, open source implementation of MicroBlaze it
would probably letting us sell more FPGAs.





Article: 62865
Subject: Re: FPGAs and DRAM bandwidth
From: fortiz80@tutopia.com (Fernando)
Date: 10 Nov 2003 08:53:36 -0800
Links: << >>  << T >>  << A >>
Thanks all for the good pointers.  

As mentioned, the simultaneous switching will definitely be an issue. 
I never heard about this technique of switching different DRAM chips
on different phases of the clock.  Is it commonly used?

There was also a brief mention of "serial DIMMs".  Has anyone seen
anything like that, or would I need to start from scratch?

The problem I'm looking operates on data sets ~16GB.  Computation
takes about 0.5 sec, compared with ~2 sec required to download
(@100MHz).  BRAM is used as cache for bandwidth.

The main memory bandwidth range I'm interested in would be ~50GB/s, so
the computation and memory-access times are comparable. That's why I'm
asking the experts, is this currently attainable with FPGAs?

Thanks again,

Fernando

Article: 62866
Subject: Re: FPGAs and DRAM bandwidth
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 10 Nov 2003 17:03:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <2658f0d3.0311100853.4468d276@posting.google.com>,
Fernando <fortiz80@tutopia.com> wrote:
>As mentioned, the simultaneous switching will definitely be an issue. 
>I never heard about this technique of switching different DRAM chips
>on different phases of the clock.  Is it commonly used?

I don't see why not, its a simple and elegant solution.

>The main memory bandwidth range I'm interested in would be ~50GB/s, so
>the computation and memory-access times are comparable. That's why I'm
>asking the experts, is this currently attainable with FPGAs?

Its pin bandwidth which is going to be needed, and lots of pins.  

So lets take a 200 MHz DDR signaling, thats 400 Mbps/pin peak.  Thus
50 GBs would take, at MINIMUM, 1000 pins!  

1000 signaling pins, at 400 MHz, is not very happy.  Probably barely
doable on the largest part, but not happy.  Then there are all the
control pins.


Quesion: do you REALLY need all that memory bandwidth?  Do you really
need all that speed?  Or could you just make things take 10x longer,
only require 2 banks of DDR, and use a smaller piece of FPGA logic?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 62867
Subject: Re: ISE 5.2 to 6.1
From: "KD" <kd@home>
Date: Tue, 11 Nov 2003 04:24:02 +1100
Links: << >>  << T >>  << A >>
"colin hankins" <colinhankins@cox.net> wrote in message
news:kzCrb.14571$Zb7.8816@fed1read01...
> I installed ISE 6.1 with the service pack and my Spartan IIe design that
> worked fine under 5.2 no longer works in the timing simulation in 6.1.
Also,
> the number of Slices used increased by 10% as well as the TBUFS. I have
> fiddled with almost every combination of options in the synth, map, and
par
> to try and recreate the better results I had in ISE 5.2. I talked to
Xilinx
> and they just told me to fiddle with the parameters some more. Has anyone
> else had similar problems migrating a project from 5.2 to 6.1?
>

Even worse, I have fatal errors in synthesis of pipelined LUT multipliers
which worked fine in 5.2
Talked to Xilinx and got the same useless answer...

Hopefully, someone will stumble on a solution, or Xilinx will fix it in a
service pack. If not, we'll be stuck on 5.2 ;(



Article: 62868
Subject: Re: Home grown CPU core legal?
From: Goran Bilski <goran@xilinx.com>
Date: Mon, 10 Nov 2003 18:30:28 +0100
Links: << >>  << T >>  << A >>
Hi Symon,

I don't think Xilinx would be happy but I don't think we would do 
anything against it.
I also think that MicroBlaze will be better implemented in our FPGA than 
in our competitors.

If someone did a clean, pure RTL implementation of MicroBlaze, I think 
that someone will very quickly try it on our competitors FPGA.

I have a pure RTL version of MicroBlaze and it doesn't look good when 
targeting other devices than Xilinx's devices.

But someone started from scratch, the design would probably not be so 
biased against Xilinx.

Göran

Symon wrote:

>Hi Goran,
>    So, playing devli's advocate, Xilinx wouldn't mind if the clean room
>Microblaze was targeted at their competitors' devices? Or do you think that
>no one would do this because Microblaze only efficiently fits the Xilinx
>devices? Or the competitors have their own solutions for their parts?
>    I wonder....
>                cheers, Syms.
>
>
>"Goran Bilski" <goran@xilinx.com> wrote in message
>news:boodq5$bgr2@cliff.xsj.xilinx.com...
>Hi,
>
>I can't see why Xilinx would be against a clean room implementation of
>MicroBlaze.
>It would actually be quite interesting.
>We actually want to promote the use of MicroBlaze.
>We are not getting our money from MicroBlaze sells but rather on the FPGAs
>that MicroBlaze uses.
>If someone did a clean room, open source implementation of MicroBlaze it
>would probably letting us sell more FPGAs.
>
>
>
>
>  
>


Article: 62869
Subject: Re: 0.13u device with 5V I/O
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 10 Nov 2003 12:35:07 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> > Don't get me wrong.  As a standard bus interface IP developer
> > (PCI, PCI-X, and now PCI Express...) I like 5V I/O even more
> > than the next guy.  I'd love to be able to directly support
> > 5V PCI on newer Xilinx parts without external components.
> 
> What's the newest/best/cheapest part that's reasonable to
> connect to old 5V PCI?
> 
> Is there a legal recipe using external parts?  I'd expect
> that approach would have troubles meeting the loading rules.
> 
> --
> The suespammers.org mail server is located in California.  So are all my
> other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
> commercial e-mail to my suespammers.org address or any of my other addresses.
> These are my opinions, not necessarily my employer's.  I hate spam.

The newest 5 volt tolerant parts that Xilinx has are the Virtex /
Spartan II lines.  But they both have high startup current
requirements.  They have recently refined these requirements, but they
are still very high relative to the normal currents and require special
attention to power supply design, especially if you are using industrial
temp parts.  

On the 5 volt IO parts without the high startup current requirement,
Xilinx has no parts that are fully supported with current software. 
They still recommend the old Spartan XL parts for new designs, but they
are only supported with old software which is poorly supported by the
hotline.  Because of that and the poor price/function ratio, we chose a
different vendor.  

Altera has the ACEX line of parts which are still fully supported by the
current software.  They are also newer parts (~2 years old) which should
be available for a long time to come.  

BTW, on the price issue, I have found that both vendors will
substantially cut their prices to get a design win.  If you talk
directly to the FPGA vendor's rep you can get 50% or larger reduction in
price for moderate volumes.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 62870
Subject: Re: Tools Tree
From: "Neeraj Varma" <neeraj@cg-coreel.com>
Date: Mon, 10 Nov 2003 23:19:25 +0530
Links: << >>  << T >>  << A >>
Synthesis :
1.XST
2.Mentor Leo Spec
3.mentor Precision RTL
4. Synplicity Synplify /Pro
5. Synopsys FPGA Compiler II
6. Synopsys Design Compiler

Physical Optimization /Synthesis:
1. Mentor Precision Physical
2. Synplicity Amplify
3. Magma (acquired from Aplus) Design PALACE
4. HDI PlanAhead

Simulation (HDL)
1. ModelSim
2. Cadence Verilog XL, NC-Sim
3. Synopsys VCS

Formal Verification:
1. Synopsys Formality
2. Verplex (now Cadence) Conformal-FPGA

Co-design:
1. Mentor Seamless

Schematic:
1. Mentor Design architect
2. Innoveda
3. Cadence concept

Board level timing
1. Mentor Tau

Board level Signal integrity
1. Mentor HyperLYNX
2. Mentor ICX
3. Cadence Specctraquest

"Nagaraj" <nagaraj_c_s@yahoo.com> wrote in message
news:91710219.0311050420.679a7a14@posting.google.com...
> I meant much more. For a detailed design flow, including code
> coverage, DFT, physical synthesis, etc.
>
> regards,
> nagaraj
>
> Mike Treseler <tres@tc.fluke.com> wrote in message
news:<3FA83665.9030100@tc.fluke.com>...
> > 1. Design entry
> > Tool1: emacs vhdl-mode, verilog mode
> > Tool2: Quartus block diagram
> > 2. Simulation
> > Tool1: Modelsim
> > Tool2: Aldec
> > 3. Synthesis
> > Tool1: Leo Spec
> > Tool2: Synplify Pro
> > Tool3: Quartus
> > Tool4: XST
> > 4. Place and Route
> > Tool1: Xilinx Place & Route  + static timing
> > Tool2: Quartus Place & Route + static timing
> >
> >       -- Mike Treseler



Article: 62871
Subject: Xilinx SelectMAP configuration
From: brad@tinyboot.com (Brad Eckert)
Date: 10 Nov 2003 10:02:38 -0800
Links: << >>  << T >>  << A >>
Hi all,

Is there a VHDL simulation model of the Spartan II/III boot process? I
have some boot logic that runs in a CPLD and I'd like my testbench to
have something that behaves like a booting FPGA.

--
Brad Eckert

Article: 62872
Subject: Re: Home grown CPU core legal?
From: bpride@monad.net (Bruce P.)
Date: 10 Nov 2003 10:08:48 -0800
Links: << >>  << T >>  << A >>
> If you really want to play it safe you should implement a SPARC ISA.
> That's an open standard.
> 
> Or do a reimplementation of picoblaze or microblaze or xr16. I believe
> that Xilinx won't mind another Microblaze implementation that helps
> selling there Chips. (Göran, can you comment on that?)
> 

Thanks, the Picoblaze looks like a simple one to look at first. 
Plenty of documentation and free tools as well.

BP

Article: 62873
Subject: Re: FPGAs and DRAM bandwidth
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 10 Nov 2003 18:20:57 GMT
Links: << >>  << T >>  << A >>
I asked a DRAM vendor about the possibility of serial DRAM.  The comment was
that they weren't considering that direction because of poorer latency.  I'm
not certain the arguement was valid, though, because the DDR design I was
trying to put together had to register in the IOBs and in the logic fabric;
if the buffering was reduced in the FPGA internals using the serial links,
the overall latency might be the same (or better) at a huge reduction in
pins.

The bandwidth is, however, still an issue.  64 bits wide, 400M/s -> 25.6
Gb/s.  Oops!


"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:UKFrb.6522$2e2.2752@newssvr25.news.prodigy.com...
> It would seem to me that the idea of using custom "serial dimms" combined
> with Virtex II Pro high speed serial I/O capabilities might be the best
way
> to get a boost in data moving capabilities.  This would avoid having to
> drive hundreds of pins (and related issues) and would definetly simplify
> board layout.
>
> I haven't done the numbers.  I'm just thinking out loud.
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
>
>
>
> "Robert Sefton" <rsefton@abc.net> wrote in message
> news:bomt69$1equ1q$1@ID-212988.news.uni-berlin.de...
> > Fernando -
> >
> > Your instincts are right on with respect to the difficulty of fitting
> > that many DIMMs on a board and interfacing to them from a single FPGA.
> > Forget about it. The bottom line is that there's a trade-off between
> > memory size and speed, and memory is almost always the limiting factor
> > in system throughput. If you need lots of memory then DRAM is probably
> > your best/only option, and the max reasonable throughput is about what
> > you calculated, but even the 5-DIMM 320-bit-wide data bus in your
> > example would be a very tough PCB layout.
> >
> > If you can partition your memory into smaller fast-path memory and
> > slower bulk memory, then on-chip memory is the fastest you'll find and
> > you can use SDRAM for the bulk. Another option, if you can tolerate
> > latency, is to spread the memory out to multiple PCBs/daughtercards,
> > each with a dedicated memory controller, and use multiple lanes of
> > extremely fast serial I/O between the master and slave memory
> > controllers.
> >
> > A hierarchy of smaller/faster and larger/slower memories is a common
> > approach, e.g., on-chip core-rate L1 cache, off-chip fast L2 cache, and
> > slower bulk SDRAM in the case of microprocessors. If you tossed out some
> > specific system requirements here you'd probably get some good feedback
> > because this is a common dilemma.
> >
> > Robert
> >
> > "Fernando" <fortiz80@tutopia.com> wrote in message
> > news:2658f0d3.0311090256.21ce5a9a@posting.google.com...
> > > Sharing the control pins is a good idea; the only thing that concerns
> > > me is the PCB layout.  This is not my area of expertise, but seems to
> > > me that it would be pretty challenging to put (let's say) 10 DRAM
> > > DIMMs and a big FPGA on a single board.
> > >
> > > It can get even uglier if symmetric traces are required to each memory
> > > sharing the control lines...(not sure if this is required)
> > >
> > > Anyway, I'll start looking into it
> > >
> > > Thanks
> > >
> > > Phil Hays <SpamPostmaster@attbi.com> wrote in message
> > news:<3FAD39F6.5572E42C@attbi.com>...
> > > > Fernando wrote:
> > > >
> > > > > How fast can you really get data in and out of an FPGA?
> > > > > With current pin layouts it is possible to hook four (or maybe
> > even
> > > > > five) DDR memory DIMM modules to a single chip.
> > > > >
> > > > > Let's say you can create memory controllers that run at 200MHz (as
> > > > > claimed in an Xcell article), for a total bandwidth of
> > > > > 5(modules/FPGA) * 64(bits/word) * 200e6(cycles/sec) *
> > (2words/cycle) *
> > > > > (1byte/8bits)=
> > > > > 5*3.2GB/s=16GB/s
> > > > >
> > > > > Assuming an application that needs more BW than this, does anyone
> > know
> > > > > a way around this bottleneck? Is this a physical limit with
> > current
> > > > > memory technology?
> > > >
> > > > Probably can get a little better.  With a 2V8000 in a FF1517
> > package,
> > > > there are 1,108 IOs.  (!)  If we shared address and control lines
> > between
> > > > banks (timing is easier on these lines), it looks to me like 11
> > DIMMs
> > > > could be supported.
> > > >
> > > > Data pins 64
> > > > DQS pins   8
> > > > CS,CAS,
> > > > RAS,addr  12 (with sharing)
> > > >         ====
> > > >           92
> > > >
> > > > 1108/92 = 11 with 100 pins left over for VTH, VRP, VRN, clock,
> > reset, ...
> > > >
> > > > Of course, the communication to the outside world would also need go
> > > > somewhere...
> >
> >
>
>



Article: 62874
Subject: Re: 0.13u device with 5V I/O
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Mon, 10 Nov 2003 10:25:10 -0800
Links: << >>  << T >>  << A >>

Hi,

You can use Virtex or Spartan-II to interface with 5V PCI bus
and retain full compliance per the specification.  You can use
any of our devices, even Spartan3 and Virtex2Pro, with the 5V
PCI bus, but you need some level translators.  This is certainly
a functional solution (I've tested it personally) but it is not
compliant with the letter of the specifications.

The specifications are pretty clear that you are allowed only
one component, and that is your "PCI component" and all bus
signals must attach directly to that one component.

Eric

Hal Murray wrote:
> > Don't get me wrong.  As a standard bus interface IP developer
> > (PCI, PCI-X, and now PCI Express...) I like 5V I/O even more
> > than the next guy.  I'd love to be able to directly support
> > 5V PCI on newer Xilinx parts without external components.
> 
> What's the newest/best/cheapest part that's reasonable to
> connect to old 5V PCI?
> 
> Is there a legal recipe using external parts?  I'd expect
> that approach would have troubles meeting the loading rules.



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