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 62875

Article: 62875
Subject: Re: VirtexII-Pro: Why is ICAP slower than SelectMAP?
From: "PO Laprise" <plapri_NOTPARTOFEMAIL_@cim.mcgill._REMOVE_.ca>
Date: Mon, 10 Nov 2003 10:50:11 -0800
Links: << >>  << T >>  << A >>
So if you send the internal signals that currently connect to the 
ICAP off-chip and back to the SelectMAP pins instead, you can get a speed boost? 
Pierre-Olivier 

-- to contact me directly, remove the obvious from my email address -- 


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

Hi Jim,

I see we have a difference of opinion.  I'm not going to try to
change your mind, only answer the additional questions you posed:

> > 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.

There are no Xilinx devices like this.  With the exception of
the gigabit serial I/O, all I/O pins are the same.

There are some vendors that have banking rules like you have
described, but even so, those banks don't support 5V I/O.

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

I am looking specifically at the FPGA market.

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

Most vendors have limited resources, and so make intelligent
guesses about price/feature tradeoffs.  The market is wide open
for someone do exactly what you suggest.
 
> Some numbers ?  XX cents per pin ?

I don't have this information.  If I did, I'm sure my employer
would not be pleased if I were to share it.  However, I do know
that the expense is considerable:

1.  Additional mask sets.
2.  Additional processing steps.
3.  Cost of lost general purpose I/O.
4.  Cost of a low volume, "novelty" product,
    including software, support, and documentation.

It would be more expensive.  I don't know how much.  Time will
tell if FPGA vendors think this is a good return on investment.

Eric

Article: 62877
Subject: Re: Home grown CPU core legal?
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 10 Nov 2003 11:33:06 -0800
Links: << >>  << T >>  << A >>
news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0311100755.72deef43@posting.google.com>...
> 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?)

Once a version of microblaze becomes widely available on the Cyclone
series (or other Altera chip) and starts selling Altera chips, I'm
sure Xilinx would mind. :)

   Jake

Article: 62878
Subject: Re: Home grown CPU core legal?
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Tue, 11 Nov 2003 08:50:02 +1300
Links: << >>  << T >>  << A >>

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

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

Perhaps you should do one that is biased *towards* Xilinx parts ;-)

Ralph



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

Well, MicroBlaze is biased against Xilinx FPGA.
The whole ISA is done towards our devices.

That's why I mean it will probably not be efficient in other FPGA 
vendors architecture.
But I think it would be very suited for an ASIC implementation.

Göran

Ralph Mason wrote:

>"Goran Bilski" <goran@xilinx.com> wrote in message
>news:booi3e$bg72@cliff.xsj.xilinx.com...
>  
>
>>Hi Symon,
>>    
>>
>
>  
>
>>But someone started from scratch, the design would probably not be so
>>biased against Xilinx.
>>
>>    
>>
>
>Perhaps you should do one that is biased *towards* Xilinx parts ;-)
>
>Ralph
>
>
>  
>




Article: 62880
Subject: Re: 0.13u device with 5V I/O
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 11 Nov 2003 09:29:00 +1300
Links: << >>  << T >>  << A >>
Eric Crabill wrote:
> 
<snip
> > Depends on where you look, and why.
> > On embedded controllers, 5V is actually making a comeback.
> > Lattices' very newest CPLDs, added 5V tolerant IOs.
> 
> I am looking specifically at the FPGA market.

Quite understood.
I am looking from a designers viewpoint, across many markets,
and asking 'why' wrt a specific feature.

> 
> > Give the customers some hard numbers, and let them decide for
> > themselves :)
> 
> Most vendors have limited resources, and so make intelligent
> guesses about price/feature tradeoffs.  The market is wide open
> for someone do exactly what you suggest.
> 
> > Some numbers ?  XX cents per pin ?
> 
> I don't have this information.  If I did, I'm sure my employer
> would not be pleased if I were to share it.  However, I do know
> that the expense is considerable:
> 
> 1.  Additional mask sets.

Accepted - perhaps one more, maybe none with the right cleverness.
Note this mask would not be 0.13u, nor full die area.

> 2.  Additional processing steps.

 Yes, and it also requires that the foundry qualify the process, 
which requires their customers indicate they need it.

 This may come sooner than you think. 
I see foundries are now offering 110nm process as a 'back fill' 
between the 130nm and 90nm processes. 
 Seems the customers are not rushing to 90nm quite as
fast as they hoped - so a significant mindset change is occuring
where smallest/fastest is no longer the sole target on the radar.

> 3.  Cost of lost general purpose I/O.

Not sure they are mutually exclusive.
An IC designer could exclude it on some specialist high speed IO.


> 4.  Cost of a low volume, "novelty" product,
>     including software, support, and documentation.

 The other markets releasing 'wide supply' ICs do not think they
are "novelty" products - quite the reverse. Their intention 
is to have one die cover as many customers as practical, and 
reduce the part number proliferation, as well as extend the
'design life' of a given die. 

 There are LOTS of benefits along the whole supply chain. 

 LOGIC has now moved to 1.65-5.5V Vcc specs after some 
market failures with lower/narrower offerings.
 uC are following, with the better ones now doing 1.8-5.5V, 
or 2.0-5.5V - some uC and CPLD have on-die regulators.
 When you see the curves, you can appreciate the 1.8-5.5V 
was not easy, and not without effort or some silicon cost.

 Besides Wide Vcc, commercial temp spec releases are 
being dropped in favour of industrial (or wider) 'as standard'.
 
> It would be more expensive.  I don't know how much.  Time will
> tell if FPGA vendors think this is a good return on investment.

 See rickmans post, covers the trade-offs designers face and the
reasons for device selection, nicely.

-jg

Article: 62881
Subject: Re: Home grown CPU core legal?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 11 Nov 2003 09:53:59 +1300
Links: << >>  << T >>  << A >>
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....

 Xilinx's protection does not come from attack on the clean room clone,
but rather from the protection of the Microblaze name, and tool flows.
 So, anyone would be free to create an opcode compatible core, 
if they wished, but not to use the brand, nor the Xilinx tool flows.

 Older uC cores are easier to copy (any patents lapsed), and their tools 
are widely available. Things like 80C51, 6502, Z8, and even 8085....
 ( someone must have done a 8048 core ? :)

-jg

Article: 62882
Subject: Re: Unconstrained net to DLL's
From: Marc Randolph <mrand@my-deja.com>
Date: Mon, 10 Nov 2003 21:04:36 GMT
Links: << >>  << T >>  << A >>
Morten Leikvoll wrote:
> 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?

How about the MAXDELAY constraint?


Article: 62883
Subject: Re: Home grown CPU core legal?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 10 Nov 2003 13:16:26 -0800
Links: << >>  << T >>  << A >>
Jake,

Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other
architectures.  The specific features required are covered by patents.

Austin

Jake Janovetz wrote:

> news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0311100755.72deef43@posting.google.com>...
> > 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?)
>
> Once a version of microblaze becomes widely available on the Cyclone
> series (or other Altera chip) and starts selling Altera chips, I'm
> sure Xilinx would mind. :)
>
>    Jake


Article: 62884
Subject: Re: Home grown CPU core legal?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 10 Nov 2003 21:18:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3FAFFAE7.2939@designtools.co.nz>,
Jim Granville  <jim.granville@designtools.co.nz> wrote:

> Xilinx's protection does not come from attack on the clean room clone,
>but rather from the protection of the Microblaze name, and tool flows.
> So, anyone would be free to create an opcode compatible core, 
>if they wished, but not to use the brand, nor the Xilinx tool flows.

Isn't the compiler flow gcc?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



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


The name MicroBlaze is a trademark of MicroBlaze.
So a cleanroom can't be called MicroBlaze.
For the tools part, yes, the EDK tools is our tools which we don't give 
away for free (they costs $495 and that's including all the IP)
The actual compiler tools is GNU tools and they are open-sourced.

Göran

Jim Granville wrote:

>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....
>>    
>>
>
> Xilinx's protection does not come from attack on the clean room clone,
>but rather from the protection of the Microblaze name, and tool flows.
> So, anyone would be free to create an opcode compatible core, 
>if they wished, but not to use the brand, nor the Xilinx tool flows.
>
> Older uC cores are easier to copy (any patents lapsed), and their tools 
>are widely available. Things like 80C51, 6502, Z8, and even 8085....
> ( someone must have done a 8048 core ? :)
>
>-jg
>  
>




Article: 62886
Subject: Re: Home grown CPU core legal?
From: acher@in.tum.de (Georg Acher)
Date: 10 Nov 2003 21:33:35 GMT
Links: << >>  << T >>  << A >>
In article <3FB0002A.909E765A@xilinx.com>,
 Austin Lesea <Austin.Lesea@xilinx.com> writes:

|> Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other
|> architectures.  The specific features required are covered by patents.

I like the perversion of the word "patent".

"patere", lat.: "standing open".

SCNR(tm)
-- 
         Georg Acher, acher@in.tum.de
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias


Article: 62887
Subject: Re: 0.13u device with 5V I/O
From: Larry Doolittle <ldoolitt@recycle.lbl.gov>
Date: Mon, 10 Nov 2003 21:50:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3FAFDFB9.63CF0853@xilinx.com>, Eric Crabill wrote:
(posting from a Xilinx e-mail address)
> 
>> On embedded controllers, 5V is actually making a comeback.
>> Lattices' very newest CPLDs, added 5V tolerant IOs.
> 
> I am looking specifically at the FPGA market.
> 
>> Give the customers some hard numbers, and let them decide for
>> themselves :)
> 
> Most vendors have limited resources, and so make intelligent
> guesses about price/feature tradeoffs.  The market is wide open
> for someone do exactly what you suggest.

Ahem.  I think your company's lawyers would have something
to say if anyone but you, and maybe Altera, tried anything
of the sort.

     - Larry

Article: 62888
Subject: Implementing a very fast counterin VirtexII
From: "Erez Birenzwig" <erez_birenzwig@hotmail.com>
Date: Tue, 11 Nov 2003 11:09:07 +1300
Links: << >>  << T >>  << A >>
Hi,

  I'm trying to write some code for a 64 bit counter for a VirtexII.

  The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz).

  I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

  Did anyone ever had a similar problem and solved it ?
  Unfortunately I'm not familiar with a pipelined implementation, I'll be
happy
to learn one.

  Many thanks,
  Erez.




Article: 62889
Subject: Reverse engineering an EDIF file?
From: Rastislav Struharik <rasti@eunet.yu>
Date: Mon, 10 Nov 2003 23:10:39 +0100
Links: << >>  << T >>  << A >>
Hello,

I would like to know does anyone knows, is it possible to reverse
engineer an edif netlist file? I am currently developing an FPGA core.
I would like to supply an evaluation version of the core, that would
have all the functionality of the final core, but would operate only
for a limited period of time. My fear is that there is a way to modify
the evaluation version edif netlist (find and remove modules that set
a time limit to the operation of the evaluation version), and thus
obtain completely functional core. Can something like this be done, or
am I being paranoid?
Every help and clarification on this subject is most welcome.

Thanks in advance,
Rastislav Struharik

Article: 62890
Subject: Re: Home grown CPU core legal?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 11 Nov 2003 08:16:35 +1000
Links: << >>  << T >>  << A >>
Georg Acher wrote:
> In article <3FB0002A.909E765A@xilinx.com>,
>  Austin Lesea <Austin.Lesea@xilinx.com> writes:
> 
> |> Microblaze(tm) requires specific Xilinx features, and can not be implemented efficiently in (by) other
> |> architectures.  The specific features required are covered by patents.
> 
> I like the perversion of the word "patent".
> 
> "patere", lat.: "standing open".

Which is precisely what they do - the details are published (ie open), 
but there is protection for the inventor to profit exclusively from that 
invention for a limited period of time.

A reasonable idea in principle - it's the rampant abuse that is the problem.

Regards,

John


Article: 62891
Subject: Re: Home grown CPU core legal?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 11 Nov 2003 08:19:14 +1000
Links: << >>  << T >>  << A >>
Nicholas C. Weaver wrote:
> In article <3FAFFAE7.2939@designtools.co.nz>,
> Jim Granville  <jim.granville@designtools.co.nz> wrote:
> 
> 
>>Xilinx's protection does not come from attack on the clean room clone,
>>but rather from the protection of the Microblaze name, and tool flows.
>>So, anyone would be free to create an opcode compatible core, 
>>if they wished, but not to use the brand, nor the Xilinx tool flows.
> 
> 
> Isn't the compiler flow gcc?

It is indeed.  I host a copy of the tools on my website, and one may 
build entire microblaze linux kernels without paying a cent to Xilinx.

Of course, you won't have a processor to run it on unless you do!  Same 
as any gcc-targeted processor really.

Regards,

John


Article: 62892
Subject: Re: Home grown CPU core legal?
From: bpride@monad.net (Bruce P.)
Date: 10 Nov 2003 14:31:05 -0800
Links: << >>  << T >>  << A >>
> 
> Once a version of microblaze becomes widely available on the Cyclone
> series (or other Altera chip) and starts selling Altera chips, I'm
> sure Xilinx would mind. :)
> 

Did I mention that my new board design has a Cyclone on it? Hmmm, "The
Cyclo-Blaze"...has sort of a nice ring to it. ;>)

I guess if it's smaller than the Altera Nios and a lot simpler, it
could be of some use.  Anyway, it should be a good learning
experience.  Thanks again.

BP

Article: 62893
Subject: Re: How to create a look up table for a RAM application
From: "Erez Birenzwig" <erez_birenzwig@hotmail.com>
Date: Tue, 11 Nov 2003 11:31:54 +1300
Links: << >>  << T >>  << A >>
You can use a one way hash function to do the reduction.
A CRC is a good example, one can think of others. It will probably not solve
your
space problem though.

Erez.

"Vazquez" <andres.vazquez@gmx.de> wrote in message
news:eee19a7a.0311100448.1577e5c2@posting.google.com...
> 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: 62894
Subject: Re: Reverse engineering an EDIF file?
From: Jim Lewis <Jim@SynthWorks.com>
Date: Mon, 10 Nov 2003 14:57:15 -0800
Links: << >>  << T >>  << A >>
Sorry.  An EDIF file should be pretty straight forward to
reverse engineer.  I have had to edit one before.  You could
make it difficult by obfusciating it.  One method changes
all names to be sequences of letters O and l and numbers
0 and 1.  This would not deter those that are determined
though.  If there is money involved, people are determined.

You would be better off working with a good legal agreement
and people who you can trust to abide by it.

Cheers,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Rastislav Struharik wrote:
> Hello,
> 
> I would like to know does anyone knows, is it possible to reverse
> engineer an edif netlist file? I am currently developing an FPGA core.
> I would like to supply an evaluation version of the core, that would
> have all the functionality of the final core, but would operate only
> for a limited period of time. My fear is that there is a way to modify
> the evaluation version edif netlist (find and remove modules that set
> a time limit to the operation of the evaluation version), and thus
> obtain completely functional core. Can something like this be done, or
> am I being paranoid?
> Every help and clarification on this subject is most welcome.
> 
> Thanks in advance,
> Rastislav Struharik



Article: 62895
Subject: Re: Implementing a very fast counterin VirtexII
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 10 Nov 2003 15:00:05 -0800
Links: << >>  << T >>  << A >>
"Counter" can mean many things.
If you need a synchronous counter that gives you the updated value
before the next count pulse comes in, that is a demanding design and may
have timing problems at 200 MHz.

If, at the other extreme, you just need a counter that can resolve 200 (
or 500+ ) MHz, and you can wait some nanoseconds before you read the
final count value, that is trivial. In the extreme case you would just
concatenate 2-bit Johnson counters (at least at the input end), one
slice clocking the next. And there are many variations on this theme.
I built a 400 MHz frequency counter 5 years ago with XC4002XL...Playing
around, aiming at 1 GHz now.

Peter Alfke, Xilinx Applications


Erez Birenzwig wrote:
> 
> Hi,
> 
>   I'm trying to write some code for a 64 bit counter for a VirtexII.
> 
>   The problem I'm facing is that it has to run at least at 200MHz, and
> therefore
> a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz).
> 
>   I've tried a split approach with four smaller counters and a selector
> depending on the carry out of the previous stages but it only got me to
> about
> 180MHz.
> 
>   Did anyone ever had a similar problem and solved it ?
>   Unfortunately I'm not familiar with a pipelined implementation, I'll be
> happy
> to learn one.
> 
>   Many thanks,
>   Erez.

Article: 62896
Subject: Re: FPGAs and DRAM bandwidth
From: "Erez Birenzwig" <erez_birenzwig@hotmail.com>
Date: Tue, 11 Nov 2003 12:02:21 +1300
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:boogcg$2ft9$1@agate.berkeley.edu...
> 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.

Don't forget you're dealing with DDR DRAM, it already uses all the phases of
the clock.
From my experience running ~160 pins at 200MHz causes the FPGA to be very
hot
(~85C without a heat sink).

Erez.



Article: 62897
Subject: Re: FPGAs and DRAM bandwidth
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 10 Nov 2003 23:13:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <TPUrb.50$%o4.11977@news.xtra.co.nz>,
Erez Birenzwig <erez_birenzwig@hotmail.com> wrote:

>Don't forget you're dealing with DDR DRAM, it already uses all the phases of
>the clock.

It's using both phases of a single clock, but that clock can be out of
phase with other DRAM clocks, which seems to be the idea.

>From my experience running ~160 pins at 200MHz causes the FPGA to be
>very hot (~85C without a heat sink).

Not suprising.

But slap an Itanic heatsink on it!  (IA64 heatsink can cool 130W).
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 62898
Subject: Re: Implementing a very fast counterin VirtexII
From: "Erez Birenzwig" <erez_birenzwig@hotmail.com>
Date: Tue, 11 Nov 2003 12:16:16 +1300
Links: << >>  << T >>  << A >>
To be more precise the implementation requires the calculation of:
a = a + 1

When a is a 64bit vector, every clock cycle at 200MHz, using a virtexII-6
FPGA.

Erez.


"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FB01875.A2C23F2F@xilinx.com...
> "Counter" can mean many things.
> If you need a synchronous counter that gives you the updated value
> before the next count pulse comes in, that is a demanding design and may
> have timing problems at 200 MHz.
>
> If, at the other extreme, you just need a counter that can resolve 200 (
> or 500+ ) MHz, and you can wait some nanoseconds before you read the
> final count value, that is trivial. In the extreme case you would just
> concatenate 2-bit Johnson counters (at least at the input end), one
> slice clocking the next. And there are many variations on this theme.
> I built a 400 MHz frequency counter 5 years ago with XC4002XL...Playing
> around, aiming at 1 GHz now.
>
> Peter Alfke, Xilinx Applications
>
>
> Erez Birenzwig wrote:
> >
> > Hi,
> >
> >   I'm trying to write some code for a 64 bit counter for a VirtexII.
> >
> >   The problem I'm facing is that it has to run at least at 200MHz, and
> > therefore
> > a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to
114MHz).
> >
> >   I've tried a split approach with four smaller counters and a selector
> > depending on the carry out of the previous stages but it only got me to
> > about
> > 180MHz.
> >
> >   Did anyone ever had a similar problem and solved it ?
> >   Unfortunately I'm not familiar with a pipelined implementation, I'll
be
> > happy
> > to learn one.
> >
> >   Many thanks,
> >   Erez.



Article: 62899
Subject: "clean" or "unprotected" versions of AHDL2X, SYNTHX from Xilinx (ABL2XNF sub tools)
From: bill@2ez.com (Bill Smith)
Date: 10 Nov 2003 15:17:56 -0800
Links: << >>  << T >>  << A >>
i am attempting to migrate my design environment for a legacy design
based on older xilinx parts from win98 to XP.  it's a key problem that
would be resolved by getting non-hardware locked versions of these
programs.  if you have these, please forward them to me with the above
subject line.  if someone at xilinx can make them for me, the details
are below.

the details:
currently, the compiling is done using a DOS based design flow in XNF
format.  the AHDL sections of the design are performed by ABL2XNF
(v5.2.1), but this tool does not work under XP.  it simply exits. 
this may be unrelated to the key problem, but it appears to be an
unnecessary design flow gizmo - i ran the sub-tools directly under
win98 and the finished result is identical.

the ABL2XNF "sub-tools" are: AHDL2X, BLIFOPTX, SYNTHX, and IMPROVEX. 
AHDL2X and SYNTHX both fail in XP because the hardware key can not be
read (though it is present).  the other two programs are not locked. 
xilinx doc# 902 indicates the key needs a "rainport" driver for NT. 
this driver does not appear to work, but configuration information is
not available, rainbow refuses requests for support indicating that
the programs need to be re-linked with their new libraries (which are
free) and then i will need their current drivers.

xilinx tech support says "xilinx does not have the resources..." to
support me on this.  the real deal is that they don't know who to ask
in development.  it's probably a 10 minute job if the make-files
exist.  any xilinx coders out there care to help?

it seems odd that these are the only two programs remain hardware
locked when all of the programs which had previously been locked have
been unlocked in newer versions.

has anyone previously faced this problem and found a functional
work-around?

many thanks,
bill



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