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 98975

Article: 98975
Subject: Re: Instantiating addsub, comparators in Xilinx
From: "Leow Yuan Yeow" <nordicelf@msn.com>
Date: Sat, 18 Mar 2006 01:25:18 -0800
Links: << >>  << T >>  << A >>
Does resource sharing also apply for a + sign in different states? It 
appears the synthesizer doesn't like my code then.


"Andy Peters" <Bassman59a@yahoo.com> wrote in message 
news:1142615703.883972.125680@j33g2000cwa.googlegroups.com...
> Leow Yuan Yeow wrote:
>> Hi, I was doing that before but I found that each + that I use generates 
>> a
>> 32-bit adder under the synthesis report which increases the LUT usage by
>> quite a fraction. After that I tried to multiplex them to a addsub 
>> component
>> and the LUT usage went down from 90+% to 80+% (I'm using the old RC100 
>> board
>> with spartan II so I have limited resources :( ).
>
> It may be that the rest of your design precludes resource sharing.
> Every time I've needed an adder or subtractor, I write code similar to
> what Weng describes.
>
> For example, the following code will create only one adder:
>
>    if (add) then
>        result <= a + b;
>    else
>        result <= a - b;
>    end if;
>
>> I was wondering if there are any other components that I can instantiate 
>> for
>> comparators as well?
>
> Why instantiate?
>
> -a
> 



Article: 98976
Subject: Re: Urgent Help Needed!!!!!
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 18 Mar 2006 10:45:23 +0100
Links: << >>  << T >>  << A >>
Chauhan wrote:

> Special Thanks to Ralf Hildebrandt
> who ignored the formalities and helped with his valuable

I do _not_ ignore the formalities! Reading this group is really hard.

1) high traffic
    It seems to be uninteresting? Ignore thread.
2) seldom minimal examples
    No time for such a bunch of code.
3) gimme code fast!!!!
    Should I do your homework?
4) plz can u adv?
    What? I am not a native English speaker. (Look at the email
    addresses. I am not the only one.) Although I can understand this, it
    makes "eye cancer".
5) I have that problem ...
    Did you try to solve it? What are your ideas?
...

O.k. the OP's posting was to that hard to read, but it may have been the 
the last straw that breaks the camel's back. Netcopping is not nice, but 
sometimes necessary. Here in this particular case it was an additional hint.
So it may be a good idea to form a clear and easily readable question 
and provide as much as information as required (but not more) to get an 
answer.
This is not a problem of the "generation gap". (I am 27.)
And at last: There are some real experts here in the group that give 
often very useful hints (regulars). I would recommend to think about, 
what they write, because otherwise you may hit soon the bottom of a 
killfile or the experts will leave.

I have seen newsgroups with much more strict formalities, that are much 
more readable. Here is the "wild west".

Ralf

Article: 98977
Subject: Re: SerialATA with Virtex-II Pro
From: "Antti" <Antti.Lukats@xilant.com>
Date: 18 Mar 2006 02:10:42 -0800
Links: << >>  << T >>  << A >>
let me know if you manage to get any SATA PHY

Antti


Article: 98978
Subject: Re: Where are FPGAs heading?
From: panteltje@yahoo.com
Date: 18 Mar 2006 03:57:29 -0800
Links: << >>  << T >>  << A >>

Austin Lesea schreef:

> Andy,
>
> The only proof is in the orders, and the shipments, and what I was told.
>
> That you, and others do not believe me is just fine.  I didn't need your
> approval to ship the parts.
>
> Does anyone honestly think I am making this up?  I have no time for
> fantasies:  I have real work to do.  The announcement was made (and the
> part briefly shown at the press conference) for 65 nm.  Busy doesn't
> really describe my shop right now.  'Frantic' is more accurate.
>
> A very happy, and pleasing kind of frantic.
>
> Austin
No, I do not think you make it up.
I think the FPGA could perhaps be used in the dashboard displays.
IIRC for example Toyota used one big LCD display, for all instuments
:-)
In such a case you need many many IO (to drive each segment),
and using FPGA could also make it possible to do speed / tacho
conversion,
temp sensor linearization, basically any sensor processing, either
digital
or analog, all in one chip on the back of that big LCD panel.
Now with mega cell FPGA, add the radio, GPS, and what not.
So, yes, and a couple of million cars sold.
But this is not for the reason you mentioned, but simply for the one I
just stated.
Does GM do something like that these days? Ford?
They will have to perhaps.

Posted from planet P


Article: 98979
Subject: Re: Support software for XC3042
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Sat, 18 Mar 2006 07:35:37 -0500
Links: << >>  << T >>  << A >>
On Fri, 17 Mar 2006 13:25:59 -0800, J Silverman wrote:

> Hi All,
> 
> I was able to get a bunch of Xilinx XC3042 FPGAs from a dealer and am
> trying to find if there is any support software out there still for the
> chip. I looked at the current ISE offerings from Xilinx, but none state
> they support the XC3042. Does anyone know of anything for the XC3042?
> 
> Thanks, J Silverman

The tools that you are looking for never existed. The only thing that was
available at the time were crude schematic entry tools which ran on DOS or
maybe Windows 3.1, I don't remember which. I wrote my own synthesis tools
in Gnu Lisp which converted ABEL (a now dead language for PALs) into XNF
format (the old Xilinx Netlist Format), rather then use the schematic
tools.

Take Peter's advice and get a modern development board.

Article: 98980
Subject: Re: ISE 8.1 linux 64bit license key
From: marcobuffa@gmail.com
Date: 18 Mar 2006 05:05:20 -0800
Links: << >>  << T >>  << A >>
Eric Smith ha scritto:
> If you're using ISE Foundation (the paid version), your key should work
> for both 32-bit and 64-bit.
I was trying to install the Foundation one, but our Xilinx consultant
gave us a serial id only for 32 bit version :-( After a lot of phone
calls and emails, I got the right code, and now it works fine on a
debian dual AMD64 machine! But... there is not chipscope for that
architecture, I found Chipscope available only for 32bit computers :-(

I tryed to install chipscope for linux 32 with then official 64bit java
virtual machine from Sun Microsystem, but the coreinserter hangs just
on starting :-(

Hoping chipscope will be released very quickly for 64 bit
architecture...

Thank you very much.
-- 
Marco


Article: 98981
Subject: CAS signal problem with OPB DDR SDRAM controller in PPC system in EDK
From: "Milind Toke" <milindt@gmail.com>
Date: 18 Mar 2006 06:08:39 -0800
Links: << >>  << T >>  << A >>
Hi,

I'm interfacing Micron's DDR with PowerPC using OPB DDR SDRAM
controller available in EDK.

The problem I face in simulation is that during a single read operation
CAS signal extends to two full (consecutive) clock cycles.

Thus for a burst length 2, I get 2 back to back identical burts.

However During single write the CAS signal is asserted properly for 1
clk cycle.

The DDR I use is micron mt46v16m16.
I have tried with both 7.1 and 8.1 versions of EDK.

Can anybody suggest me the possible reason for this problem?


Article: 98982
Subject: Re: About Altera FPGA Board
From: laura_pretty05@yahoo.com.hk
Date: 18 Mar 2006 06:26:17 -0800
Links: << >>  << T >>  << A >>
i mean that pin assignments from the FPGA to the I/O pins at
FLEX_EXPAN_X.


Article: 98983
Subject: Spartan 3 Power Supply Design
From: "Jakob" <franzjakob@gmail.com>
Date: 18 Mar 2006 06:31:46 -0800
Links: << >>  << T >>  << A >>
Hello Everyone,

I am currently investigating my options for designing the power supply
part for an imaging application. The FPGA that I had in mind, because
of its small footprint and its availibility was the XC3S400. Because I
can't and don't want to make any assumptions about the utilisation of
the device at this point, I will probably have to design for the worst
case.
>From http://www.xilinx.com/products/design_resources/power_central/ I
figured that I will probably need around 3A for the core, something
like 2A for the I/O and a low-ripple 0.3A for the auxilliary rail.
Because I am a software engineer gone electronics, my knowledge on
power supply design is rather limited at this stage.
The device itself will be battery powered at around 11.6V, and I would
like the power supply part to be as small as possible. The efficiency
is also not that crucial, as long as I won't have to provide cooling.
Because its only a prototype cost is not an issue (within reason). Also
I might need to add, that the 11.6V could be quite noisy as there are
DC motors connected to it. My first shot was the TPS75003 from TI as it
has all three rails integrated. However, it only operates on <6.5V Vin.
I've had a look at the other manufacturers and feel a bit lost know.
Because some other parts of my design will also require 5V, should I
step down from 11.6V to 5V and then use something like the TPS75003? Or
would it be better to have four rails all going down from 11.6V. What
are my best options to keep the design small? Which bits do I need to
be careful about?

Any suggestions on the design or where I could get some additional
information would be greatly appreciated. 

cheers,

Jakob


Article: 98984
Subject: Re: ISE 8.1 linux 64bit license key
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Sat, 18 Mar 2006 09:44:08 -0500
Links: << >>  << T >>  << A >>
On Sat, 18 Mar 2006 05:05:20 -0800, marcobuffa wrote:

> Eric Smith ha scritto:
>> If you're using ISE Foundation (the paid version), your key should work
>> for both 32-bit and 64-bit.
> I was trying to install the Foundation one, but our Xilinx consultant
> gave us a serial id only for 32 bit version :-( After a lot of phone
> calls and emails, I got the right code, and now it works fine on a
> debian dual AMD64 machine! But... there is not chipscope for that
> architecture, I found Chipscope available only for 32bit computers :-(
> 
> I tryed to install chipscope for linux 32 with then official 64bit java
> virtual machine from Sun Microsystem, but the coreinserter hangs just on
> starting :-(
> 
> Hoping chipscope will be released very quickly for 64 bit
> architecture...
> 
> Thank you very much.

The basic 32 bit tools run fine on 64 bit Linux, I'm running them on 64bit
FC4. I'm also running 32 bit NCVerilog on 64 bit FC4 instead of 64 bit NC
because the 32 bit version is faster. The only reason to run 64 bit
applications is if you need > 4G of memory which isn't necessary with any
of the current parts. CAE applications are all integer so they slow down
if you double the size of all of your integers and pointers which is why
you should use the 32 bit versions if you can.

As for ChipScope, you only need that on your lab machines. There is no
reason to put a 64 bit OS on a lab machine. In my experience lab
machines tend to be older boxes but even if you have a brand new A64
system out there it can still run a 32 bit OS. AMD64 systems don't need a
64 bit OS, they work fine with 32 bit OSes. I run 32 bit FC4 on my single
core A64 desktop and laptop machines, and 64 bit FC4 on my dual core 4G
server box. There is 0 difference in performance between 32 bit FC4 and 64
bit FC4, the only reason that I'm using 64 bit FC4 is so that I have the
option of running a 64 bit app if I ever need to.


Article: 98985
Subject: Re: Disk/LCD defect tolerant models for FPGA sales
From: Ray Andraka <ray@andraka.com>
Date: Sat, 18 Mar 2006 10:07:48 -0500
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Jim Granville wrote:
> 
>>  So, that means the Tools have to be defect-literate, and be able to
>>read a device ID and then find that device's defect map ?
> 
> 
> Having a unique serial number for identification might be nice, but is
> certainly not necessary to apply defect mapping to a particular well
> known FPGA device. Two likely environments exist ... the fpga device,
> or devices are mounted on a pci card and installed in a traditional
> system. The installation process for that card would run extensive
> screening diagnostics, and develop and error map for it. The driver for
> that device, interfaced to the tool chain would make the map available
> as a well known service. In addition the device/card would be sold with
> either media or internet access to the more accurate testing done prior
> to sale by the mfg.
> 
> The other likely RC environment, are FPGA centric processor clusters,
> built arround a mix of pure logic FPGA's (like XC4VLX200's) coupled
> with cpu core FPGAs (II-Pro and SX parts) possibly coupled to 32/64bit
> traditional risc processors. These have been my research for the last 5
> years. These super computers would be targeting extereme performance
> for mostly high end simulation and processing applications
> traditionally found doing nuke simulations, heat/stress sim's, weather
> sims, genetic sim and searches, and other specialty applications.
> Machines doing this in various degress exist today in both research and
> production environments. The software for controlling these machines
> and ground up vendor specific designs .... and defect management is a
> trivial task for that software.
> 
> 
>>  I suppose that is do-able, but it does not sound cheap, and the SW
>>teams are struggling with quality now, do we really want them
>>distracted with defect mapping ?
> 
> 
> Defect mapping is an integral part of every operating system, and you
> will find it to cover for faults on floppy media, optical media, and
> even hard drives .... it's part of most filesystems.
> Providing defect mapping generated keep out zones on the fpga for place
> and route is rather trivial. That is a very small price to pay to have
> access to large numbers of relatively inexpensive FPGA's. Anything that
> will allow effectively higher yields will lower the prices for RC
> computing based on defect management, AND lower the price for zero
> defect parts where the design and deployment infrastructure is unable
> to handle defect mangement due to fixed bitstreams.
> 
> 
>>  How long can you tolerate running a Place/Route, for just one device ?
> 
> 
> For RC ... not long at all. Which is why different strategies which are
> baed in fast acceptable placement and routing, with dynamic clock
> fitting are better for RC, while extensive optimization for fixed
> bitstreams used in embedded applications need the tools used today. RC
> has very very different goals .... bitstreams whose life may be
> measured in seconds, or hours, maybe even a few days. Embedded is
> trying to optimize many other variables, and for the goal of using
> bitstreams with lifetimes in years.
> 
> 
>>  There might be long-term potential, for some FPGA vendor to
>>make their Tools and Silicon Defect-map-smart, but the P&R would have
>>to be way faster than present - and anyway, why not just fix it in
>>silicon, with some redundancy and fuse re-mapping ?.
> 
> 
> Much easier said that done, and loaded with the same problems that
> dynamic sparing has in disk drives. To access a spared sector requires
> a seek, and rotational latency loss TWICE for each error .... huge
> performance penalty. Ditto for FPGA's when you have to transparently
> alter routing to another LUT in an already densely routed design.
> 
> Defect tollerant is a completely different strategy where place and
> route happens defect aware. It's actually not that difficult to edit a
> design on the fly .... using structures similar to todays cores, which
> are linked as a block into an existing netlist. That can happen both
> quickly and distort the prelinked/routed object during the load process
> to effect the remapping around the failed resources.
> 
> Anyway ... zero defect designs need zero defect parts, systems designed
> around defect tollarent strategies are built from the ground up to
> edit/alter/link the design around defects to avoid them.
> This could be done using a soft core or a $1 micro on board with the
> fpga for embedded designs that do not want to suffer the zero defect
> price premium.
> 
> 
>>  Seems only a tiny portion of users could tolerate the custom P&R's ?
> 
> 
> With todays ISE tools ... that is certainly true.  Using custom JBits
> style loaders, such as found in JHDL and JHDLBits, really a piece of
> cake using mature tools that have been around for many years on the
> educational side, with some small tweeks for defect mapping. All the
> same tools the FpgaC project needs for compile load and go to an FPGA
> coprocessor board.
> 
> Tiny relative to the size of the FPGA universe today  ... sure. Tiny in
> terms of dollars and importance certainly not. Completely disjoint to
> embedded fpga design today ... different customers, different designs,
> different cost structures, different applications.
> 

A few points:
1)  The routing structure is many times larger than the LUT structures. 
  A defect in the FPGA is far more likely to show up in the routing 
structure, and it may not be a hard failure.

2)  The testing only identifies bad devices.  It does not isolate or map
the exact fault, to do so would add considerably to the tester time for 
a part that can't be sold at full price anyway.

3) Defect map dependent PAR is necessarily unique to each device with a
defect, so you wind up not being able to use the same bitstream for each 
  copy of a product.  Fine for onesy-twosy, but a nightmare for anything 
that is going into production.  The administration cost would far exceed 
the savings even if you get the parts for free.

4)  Each part would need to come with a defect map stored electronically 
somewhere.  Since the current parts have no non-volatile storage, that 
means a separate electronic record has to be kept for each part.  This 
is expensive to administer for everyone involved from the manufacturer, 
the distributors, and the end user.  Again, the administration costs 
would overshadow any savings for parts with a reasonable yield.

5) Timing closure has to be considered when re-spinning an FPGA 
bitstream to avoid defects.  In dense high performance designs, it may 
be difficult to meet timing in a good part, much less one that has to 
allow for any route to be moved to a less direct routing.

Article: 98986
Subject: Altera Cyclone II DQ/DQS pins location
From: v_mirgorodsky@yahoo.com
Date: 18 Mar 2006 07:09:53 -0800
Links: << >>  << T >>  << A >>
Hello group,

I have an issue with porting my high-speed DDR interface to Altera
Cyclone II device. As far as datasheet says, Altera Cyclone II device
does not have any dedicated circuitry to support DDR signaling in its
Input/Output blocks for DQ pins. The only thing present in hardware is
the clock delay circuitry on DQS pins. All other DDR logic is
implemented using LUT's and triggers from adjacent Logic Array
Blocks. So, it seams that we have only DQS pins location fixed,
whenever all other DDR pins may float within the selected IO bank. Is
that right? If yes, then what is the reason to denote certain pins on
the Altera Cyclone II package as dedicated pins for DQ input/outputs?

With best regards,
Vladimir S. Mirgorodsky


Article: 98987
Subject: Historical Fpga Resources
From: fpga_toys@yahoo.com
Date: 18 Mar 2006 07:12:55 -0800
Links: << >>  << T >>  << A >>
What historical resources do we have for preserving early FPGA
development?
What web sites and peoples blogs are archiving this information?

Prior generations left a rich legacy of paper records, but so much of
the early digital generation is being lost. We were lucky to get early
Unix sources archived in the public domain.

What should be we tring to get released and archived to preserve the
legacy of early FPGA tools?

Has someone managed to get sources reconstructed for early Altera and
Xilinx tools and possibly released since they have little to no
commercial value these days, and great historical value?


Article: 98988
Subject: Re: Disk/LCD defect tolerant models for FPGA sales
From: fpga_toys@yahoo.com
Date: 18 Mar 2006 07:43:45 -0800
Links: << >>  << T >>  << A >>
Good points Ray.

Ray Andraka wrote:
> A few points:
> 1)  The routing structure is many times larger than the LUT structures.
>   A defect in the FPGA is far more likely to show up in the routing
> structure, and it may not be a hard failure.

Intermittant failures on all mediums have been a difficult testing
problem, but is something that can reach closure if part of the system
design includes regular testing. This would have to be part of idle
activity for a reliable RC system design.

> 2)  The testing only identifies bad devices.  It does not isolate or map
> the exact fault, to do so would add considerably to the tester time for
> a part that can't be sold at full price anyway.

I suspect that this would not be a tester project, but more like
specialized board fixturing that would facilitate loadable self tests
under various voltage and temp corner cases. That is significantly
cheaper to implment for the RC board vendor.

> 3) Defect map dependent PAR is necessarily unique to each device with a
> defect, so you wind up not being able to use the same bitstream for each
>   copy of a product.  Fine for onesy-twosy, but a nightmare for anything
> that is going into production.  The administration cost would far exceed
> the savings even if you get the parts for free.

That was addressed initially. For RC using incremental place and route
for fast compile, load and go operation a keep out zone is really no
different than an existing utilized resource that can not be used.

For more mainstream production use, I suggested that the go-nogo
testing of the part look for errors in 16 sub quadrants, and bin parts
failing to each. That would allow purchasing a run of  parts which all
had different failures in the same sub quadrant, and the rest of the
die was known good and usable.  That is much more manageable, without
creating too many sku's.

> 4)  Each part would need to come with a defect map stored electronically
> somewhere.  Since the current parts have no non-volatile storage, that
> means a separate electronic record has to be kept for each part.  This
> is expensive to administer for everyone involved from the manufacturer,
> the distributors, and the end user.  Again, the administration costs
> would overshadow any savings for parts with a reasonable yield.

For RC systems that would have to be addressed on a system by system
basis, as part of the host development software ... not a big deal.

individual resources faults at a detailed level for embedded
applications is quite unrealistic, which is why I suggested subquadrant
level sorting of the parts.

> 5) Timing closure has to be considered when re-spinning an FPGA
> bitstream to avoid defects.  In dense high performance designs, it may
> be difficult to meet timing in a good part, much less one that has to
> allow for any route to be moved to a less direct routing.

Certainly. I've suggested several times that RC applications may well
need to actually assign clock nets at link time based on the nets
linked delays, and choose from a list of clocks that satisfy the timing
closure. I have this on my list of things for FpgaC this spring, along
with writing a spec for RC boards suggesting that derived rising edge
aligned clocks be implemented on the RC board covering a certain range
of periods. That would allow the runtime linker (dynamic incremental
place and route) to merge the netlist onto the device, and assign
reasonable clocks for each sub-block in the design. This is necessary
to be able to reuse libraries of netlist compiled subroutines for a
particular architecture, across a number of host boards and clock
resources.

A very different model of timing closure than embedded designs today.


Article: 98989
Subject: Re: Historical Fpga Resources
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 18 Mar 2006 17:08:19 +0100
Links: << >>  << T >>  << A >>
<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1142694775.663304.303780@e56g2000cwe.googlegroups.com...
> What historical resources do we have for preserving early FPGA
> development?
> What web sites and peoples blogs are archiving this information?
>
> Prior generations left a rich legacy of paper records, but so much of
> the early digital generation is being lost. We were lucky to get early
> Unix sources archived in the public domain.
>
> What should be we tring to get released and archived to preserve the
> legacy of early FPGA tools?
>
> Has someone managed to get sources reconstructed for early Altera and
> Xilinx tools and possibly released since they have little to no
> commercial value these days, and great historical value?
>

hm what you mean 'reconstructed' those historical tools still exist.
they are just harder to get, as example XACT was on sale on ebay
just two days ago, I was going to buy it, but as I wanted to bid
on last second, and I selpt trough (I as sick that day and a sleep
most of the day) - the final price was 12USD !! I would have
bidded up to 50

Antti 



Article: 98990
Subject: Re: Altera Cyclone II DQ/DQS pins location
From: "Rob" <robnstef@frontiernet.net>
Date: Sat, 18 Mar 2006 16:49:38 GMT
Links: << >>  << T >>  << A >>

The DQS signal is usually associated with a group of data (DQ) pins; so =
where ever the DQS singal is you want the associated DQ pins located in =
close proximity.  Also, some DDR2 I/O standards, like SSTL-18 class II, =
are only supported on two sides of the chip.



Article: 98991
Subject: Re: Where am I heading?
From: "Rob" <robnstef@frontiernet.net>
Date: Sat, 18 Mar 2006 16:55:34 GMT
Links: << >>  << T >>  << A >>
> Again, I apologize if you found my posting objectionable.  I do realize 
> that there are some (not implying you) that have absolutely no sense of 
> humor whatsoever, and for them, all I can say is: don't waste your time 
> reading my posts, you won't like them (as I do have a sense of humor, and 
> I do enjoy life and its challenges).
>

AMEN!  A little humor, some sarcasim, and even a little pretention 
(ambitious is a better word) can all make for interesting diaglogue.

Take care,
Rob


"Austin Lesea" <austin@xilinx.com> wrote in message 
news:dvf4vc$atv6@xco-news.xilinx.com...
> Rick,
>
> If I have offended you, I apologize.  In fact, if I have offended anyone, 
> I apologize.  I intended to poke fun (gently) at Metal's posting.
>
> I am an engineer, and I am not in marketing.  If that means I  am not 
> politically correct: I never pretended to be anything other than honest.
>
> Again, I apologize if you found my posting objectionable.  I do realize 
> that there are some (not implying you) that have absolutely no sense of 
> humor whatsoever, and for them, all I can say is: don't waste your time 
> reading my posts, you won't like them (as I do have a sense of humor, and 
> I do enjoy life and its challenges).
>
> Austin
>
>
>
> rickman wrote:
>
>> Austin Lesea wrote:
>>
>>>Metal,
>>>
>>>Pessimists always claim they are just observing reality.
>>>
>>>You must be working for one of those companies "circling the drain?"
>>>
>>>Really hard to be positive about anything.
>>>
>>>
>>>I see (our) business increasing (a lot), and I see margins that are
>>>good, and getting better, and I see new opportunities popping up all
>>>over the place.  And I see the financials that support it.
>>>
>>>You have told all of us how we will need food, shelter, and a few sticks
>>>to burn here in the not so distant future.
>>>
>>>Austin
>>
>>
>>
>> Austin, it is hard to believe that no one at Xilinx has ever reigned
>> you in.  Often your posts are useful and technically sound.  But
>> concepts of customer interaction and company representation seem to be
>> lost on you.  I was not even involved in this thread and I find your
>> post to be insulting as well as totally inappropriate.  Your "ad
>> hominem" attacks seem to occur anytime someone makes a technical
>> argument that might be hard to dispute.
>>
>> To be honest, my impression of Xilinx has changed a lot over the last
>> few years, partly due to your postings here.  Initially I did not pay a
>> lot of attention to your comments to me or others until I realized that
>> you are actually fairly influential in the company.  Now I realize that
>> Xilinx as a whole is not a lot different than the image you present and
>> it bothers me.  It bothers me enough that I now have a strong
>> preference for any other FPGA manufacturer.
>>
>> I think the fact that no one at Xilinx seems to have a problem with
>> your posts like this one says a lot about the company.
>> 



Article: 98992
Subject: question regarding maximum frequency on virte-e-2000
From: "bachimanchi@gmail.com" <bachimanchi@gmail.com>
Date: 18 Mar 2006 08:59:10 -0800
Links: << >>  << T >>  << A >>
Hi all,
i am designing a circuit for a cryptogrpahy application based on
elliptic curve cryptography.I want to know one thing when i implement
the same circuit on different devices from different families results
are as follows.
with spartant3 i m getting max. frequency as 89 Mhz
with virtex2 i am geting max. frequency as 123 MHz
but to my surprise with vortex-e-2000 i am getting max. frequency as
48MHz.
can anyone explain why performance of virtex-e-2000 is like this.


thanks.


Regards
Ramakrishna Bachimanchi


Article: 98993
Subject: Re: 8051 IP core with JTAG debugger for FPGA?
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 18 Mar 2006 17:04:18 GMT
Links: << >>  << T >>  << A >>
Pszemol@PolBox.com posted on Thu, 23 Feb 2006 14:36:34 -0600:

""Robert F. Jarnot" <jarnot@mls.jpl.nasa.gov> wrote in message news:dtl22v$73q$1@nntp1.jpl.nasa.gov...
> quickcores has become SiliconLaude -- www.siliconlaude.com -- and
> interesting 8051 cores with real-time JTAG debug are available.

I have just visited their website and could not find IP cores available.
Instead they offer radiation-hardened silicon...
I am looking for an IP core to be put into a generic FPGA device."


After Mr. Jarnot's post I contacted Silicon Laude as a radiation-hardened
8051 would be very useful for me, and in under a week was given a very
reasonable offer.

Silicon Laude does not make silicon, it sells its intellectual property
as an FPGA chip programming file for a specific radiation-hardened
FPGA. As any non-radiation-hardened device would be suitable for you,
you could ask Silicon Laude to produce a netlist for a common FPGA.


Article: 98994
Subject: Re: 8051 IP core with JTAG debugger for FPGA?
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 18 Mar 2006 17:11:58 GMT
Links: << >>  << T >>  << A >>
Colin Paul Gloster posted on 18 Mar 2006 17:04:18 GMT:

"[..]

Silicon Laude does not make silicon, it sells its intellectual property
as an FPGA chip programming file for a specific radiation-hardened
FPGA. As any non-radiation-hardened device would be suitable for you,
you could ask Silicon Laude to produce a netlist for a common FPGA."


Indeed, Silicon Laude already mentions that it does this on its
webpage WWW.SiliconLaude.com/products.html :

"[..]
SL80C051-AX001
Functionally equivalent to the SL80RT051-AX001 except that it is
implemented in a commercial grade Actel Axcelerator FPGA and
plastic 208-pin PQFP package.
SL80C051-AF001
Functionally the equivalent to the SL80RH051-AF001 except that
it is implemented in a commercial grade QuickLogic Eclipse
FPGA and plastic 208-pin PQFP package.

[..]"


Article: 98995
Subject: Re: Spartan 3 Power Supply Design
From: austin <austin@xilinx.com>
Date: Sat, 18 Mar 2006 09:25:53 -0800
Links: << >>  << T >>  << A >>
Jakob,

http://www.xilinx.com/products/design_resources/power_central/

scroll down to "Power Partner Websites"

All of these excellent vendors products have been reviewed for use for 
Virtex, and Spartan products.  They have fully integrated packaged 
solutions (for example, TI POLA series which we use on our ML series of 
boards), or components, and most have eval pcb's, too.

My lab has tested many of these to be sure they work (such as the 
advanced Bellnix super fast point of load supplies which don't require 
any high value capacitors, and one uses fewer bypass caps -- really!), 
and all have been thoroughly reviewed.

Any questions or comments on any power supply information should be 
directed BOTH to the vendor directly, and please cc me.

Vendors have their own FAEs and engineers who will supply you with 
complete designs, layouts, and a bill of materials.

I started this service, and I take it very seriously that we recommend 
only those products that will work without any difficulties.

Austin

Jakob wrote:

> Hello Everyone,
> 
> I am currently investigating my options for designing the power supply
> part for an imaging application. The FPGA that I had in mind, because
> of its small footprint and its availibility was the XC3S400. Because I
> can't and don't want to make any assumptions about the utilisation of
> the device at this point, I will probably have to design for the worst
> case.
>>From http://www.xilinx.com/products/design_resources/power_central/ I
> figured that I will probably need around 3A for the core, something
> like 2A for the I/O and a low-ripple 0.3A for the auxilliary rail.
> Because I am a software engineer gone electronics, my knowledge on
> power supply design is rather limited at this stage.
> The device itself will be battery powered at around 11.6V, and I would
> like the power supply part to be as small as possible. The efficiency
> is also not that crucial, as long as I won't have to provide cooling.
> Because its only a prototype cost is not an issue (within reason). Also
> I might need to add, that the 11.6V could be quite noisy as there are
> DC motors connected to it. My first shot was the TPS75003 from TI as it
> has all three rails integrated. However, it only operates on <6.5V Vin.
> I've had a look at the other manufacturers and feel a bit lost know.
> Because some other parts of my design will also require 5V, should I
> step down from 11.6V to 5V and then use something like the TPS75003? Or
> would it be better to have four rails all going down from 11.6V. What
> are my best options to keep the design small? Which bits do I need to
> be careful about?
> 
> Any suggestions on the design or where I could get some additional
> information would be greatly appreciated. 
> 
> cheers,
> 
> Jakob
> 

Article: 98996
Subject: Re: Historical Fpga Resources
From: ghelbig@lycos.com
Date: 18 Mar 2006 09:30:31 -0800
Links: << >>  << T >>  << A >>
People really want that stuff?  Really?

email me.......


Article: 98997
Subject: Re: Historical Fpga Resources
From: austin <austin@xilinx.com>
Date: Sat, 18 Mar 2006 09:33:03 -0800
Links: << >>  << T >>  << A >>
Antti,

You do know that we have an archive of the 'last' supported versions, 
for customers use when they have to make a change to an ancient design?

I had the web link, but I can't find it now.

If anyone is interested, I will go find it again.

You will also need an ancient operating system to go with it, and 
possibly an ancient computer, too.

Austin

Antti Lukats wrote:

> <fpga_toys@yahoo.com> schrieb im Newsbeitrag 
> news:1142694775.663304.303780@e56g2000cwe.googlegroups.com...
> 
>>What historical resources do we have for preserving early FPGA
>>development?
>>What web sites and peoples blogs are archiving this information?
>>
>>Prior generations left a rich legacy of paper records, but so much of
>>the early digital generation is being lost. We were lucky to get early
>>Unix sources archived in the public domain.
>>
>>What should be we tring to get released and archived to preserve the
>>legacy of early FPGA tools?
>>
>>Has someone managed to get sources reconstructed for early Altera and
>>Xilinx tools and possibly released since they have little to no
>>commercial value these days, and great historical value?
>>
> 
> 
> hm what you mean 'reconstructed' those historical tools still exist.
> they are just harder to get, as example XACT was on sale on ebay
> just two days ago, I was going to buy it, but as I wanted to bid
> on last second, and I selpt trough (I as sick that day and a sleep
> most of the day) - the final price was 12USD !! I would have
> bidded up to 50
> 
> Antti 
> 
> 

Article: 98998
Subject: Re: Where are you heading?
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 18 Mar 2006 09:34:27 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> rickman wrote:
>  Now I realize that
> > Xilinx as a whole is not a lot different than the image you present and
> > it bothers me.  It bothers me enough that I now have a strong
> > preference for any other FPGA manufacturer.
> >
> > I think the fact that no one at Xilinx seems to have a problem with
> > your posts like this one says a lot about the company.
>
> Rickman, Austin is not alone in posting outspoken comments. You are no
> slouch yourself !

Now an ad hominem from Peter... how exactly do my posts relate to
Austin's?  If I commit a crime does that mean it is ok for Austin to do
the same?

When I post I don't represent a company.  If I make a comment, it does
not reflect on my employer and I don't claim to be offering anything
but my opinion.  I think it is interesting that you fail to see the
difference and that failure is part of what concerns me about Xilinx.

> Luckily, Xilinx is not a monolithic dictatorship, and the company
> trusts its senior employees to post in this newsgroup without
> censorship and without reprimands.

All companies are monolithic dictatorships to one degree or another.  I
think if upper management saw all of the posts that Austin makes they
would likely not be pleased by the way the company is presented.  Or
maybe they wouldn't have a problem, I can't say.  I do know that the
apperence is that Xilinx is a rather arrogant company, not unlike Intel
in the early days.


> Austin and I give fast response, to the best of our knowledge (which is
> quite extensive), but we are not always politically correct, and both
> of us have a temper that can indeed be provoked by certain stupidities
> repeatedly voiced on this newsgroup. We handle complex and sometimes
> controversial subjects with engagement and also some humor.
> We are not the official "Voice of Xilinx". You get that from Marketing
> and in press releases.

Having knowledge is not the only criterion for a good FAE or company
representative.  I thnk you both know that.  I also think that you two
have had a lot of leeway in these groups that you would not normally
have in typical business forums.

> I would be amazed if any smart engineer would base his component choice
> on Austin's typing style. We would, however, appreciate if you base it
> on the technical information you get in this newsgoup.

Typing style...  I like the way you trivialize the issue.  That is the
other part of my problem with the way that Xilinx is represented in the
newsgroups.  Even when a problem is pointed out to you and Austin, it
is often trivialized rather than dealt with.

That includes both customer interface issues as well as technical
issues.  I have been reading here for some years now and I have seen
many, many times Xilinx claim that a given techical issue is not a
problem only to deal with the problem in their next chip family and do
a "1984" type reversal to brag about solving the problem as if they had
never said the issue was not a problem.  Other FPGA vendors add block
memory and Xilinx claims that is not a good idea, then the Virtex parts
come out with block memory.  The power on surge currents are not a
problem and can be dealt with easily with by a few extra parts on the
board and the next Spartan generation is designed for no heavy power on
surge current.  The latest Xilinx families require three power supply
voltages and I fully expect Xilinx to deal with this in following
families by returning to just two supply voltages.

So the problem is not just "typing style" and it is not just Austin.

When someone from Xilinx trivializes an issue that is pointed out to
them, I assume that means, like a teenager ignoring their parents, they
just aren't ready to deal with it.


Article: 98999
Subject: Re: question regarding maximum frequency on virte-e-2000
From: austin <austin@xilinx.com>
Date: Sat, 18 Mar 2006 09:36:28 -0800
Links: << >>  << T >>  << A >>
Ramarishna,

Virtex E is .18 micron technology.

Spartan 3 is 90nm.

Virtex II is 150nm.

Depending on how the resources are used, larger technologies are 
generally slower, and smaller are faster.

If a resource is targeting that doesn't exist in hardened form (like the 
18x18 multiplier is not in Virtex E), then it will be implemented in 
fabric, and the design may be even slower.

Austin

bachimanchi@gmail.com wrote:

> Hi all,
> i am designing a circuit for a cryptogrpahy application based on
> elliptic curve cryptography.I want to know one thing when i implement
> the same circuit on different devices from different families results
> are as follows.
> with spartant3 i m getting max. frequency as 89 Mhz
> with virtex2 i am geting max. frequency as 123 MHz
> but to my surprise with vortex-e-2000 i am getting max. frequency as
> 48MHz.
> can anyone explain why performance of virtex-e-2000 is like this.
> 
> 
> thanks.
> 
> 
> Regards
> Ramakrishna Bachimanchi
> 



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