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 91425

Article: 91425
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: "Andrew Lohbihler" <xyz.interactive@rogers.com>
Date: Sun, 6 Nov 2005 14:56:15 -0500
Links: << >>  << T >>  << A >>
Either way the reason Xilinx did this does not help someone that is porting
this code to a higher Virtex device. They are stuck with this error with no
understanding or explanation of how to proceed fixing their code to make it
work. This is not good support!! Why can't Xilinx make this clear to
engineers upgrading their devices.

-Andrew


"GaLaKtIkUsT" <taileb.mehdi@gmail.com> wrote in message 
news:1131255526.842676.30480@g44g2000cwa.googlegroups.com...
> But why were these changes done ? is it a sacrifice made by Xilinx to
> allow adding XtremeDSP and other hard cores inside the Virtex-4 ?
> Or is it simply because a few people use the CLBs as memory or shift
> registers?
> 



Article: 91426
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 6 Nov 2005 21:12:41 +0100
Links: << >>  << T >>  << A >>
"Andrew Lohbihler" <xyz.interactive@rogers.com> schrieb im Newsbeitrag 
news:DLqdnfJwZNJ8wvPenZ2dnUVZ_sOdnZ2d@rogers.com...
> Either way the reason Xilinx did this does not help someone that is 
> porting
> this code to a higher Virtex device. They are stuck with this error with 
> no
> understanding or explanation of how to proceed fixing their code to make 
> it
> work. This is not good support!! Why can't Xilinx make this clear to
> engineers upgrading their devices.
>
> -Andrew
>
>
> "GaLaKtIkUsT" <taileb.mehdi@gmail.com> wrote in message 
> news:1131255526.842676.30480@g44g2000cwa.googlegroups.com...
>> But why were these changes done ? is it a sacrifice made by Xilinx to
>> allow adding XtremeDSP and other hard cores inside the Virtex-4 ?
>> Or is it simply because a few people use the CLBs as memory or shift
>> registers?
>>
>

as already said the RPM stuff just is and will be 'family' specific.

and as only half of the slices are SLICEM then the RPM logic
must account for that and fix functions that need SLICEM function
at horisontal offset 2. This is relativly easy todo by calculating
the X values accordingly. The need todo this for existing V2
desing sure is additional PITA thing.

This 'feature' that only 50% of the slice's are now 'good'
old slices (in terms of Virtex slices) is defenetly fully clear
from Xilinx datasheets. Well there are others small things
that are harder do know, like that new devices only support
LVDS output when VCCIO is 2.5 (no 3.3V support)
and that lots of LVDS pins in Virtex4 are 'input' only.
Both the latter 'new fetures' did come as a surprise
to me - while I was testing an already ready made PCB.

--
BTW: Both Actel and Lattice have also a similar
to SLICEM/SLICEL difference between memory
capable and logic only slices - it does reduce
the die size.

Antti
















Article: 91427
Subject: Re: xapp807-Minimal Footprint Tri-Mode Ethernet MAC Processing Engine
From: yusufilker@gmail.com
Date: 6 Nov 2005 12:15:15 -0800
Links: << >>  << T >>  << A >>
I can't see any OS related sw in the document.
Ultracontroller2 runs tcp/ip stack and httpd from 16kB Instruction
cache.
I don't think there is an OS (kernel-user space) in xapp807 .
User application software is running as direct executable. (probably)

But if your application runs on ML403 board with Linux,
it will use external SDRAM which is slower than Inst. cache.
Also Linux is slower than direct executable.

But these excuses does not mean bottleneck is not sw.


yusuf


Article: 91428
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sun, 06 Nov 2005 12:46:44 -0800
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> BTW: Both Actel and Lattice have also a similar
> to SLICEM/SLICEL difference between memory
> capable and logic only slices - it does reduce
> the die size.

Interesting.
The much-hyped SRL16 isn't free after all.
Perhaps Xilinx is discovering that some
designers use a lot of generic rtl code.

        -- Mike Treseler

Article: 91429
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Mon, 07 Nov 2005 10:20:18 +1300
Links: << >>  << T >>  << A >>
air_bits@yahoo.com wrote:
> The reality is that forms of parallelism emerge when using C as
> an HLL for FPGAs. The first is that the compiler is free to parallel
> statements as much as can be done. This alone is typically enough
> to bring the performance of a 300MHz fpga clock cycle near the
> performance of a several GHz RISC/CISC CPU for code bodies that
> have a significant inner loop. Second, explicit parallelism is
> available
> by replicating these inner loops by creating threads with the same
> code body and using established MPI code structures and libraries.

An interesting point with this, of course, is that it's just splitting 
the work less - instead of going

C -> object code -> Processor (with out of order execution),

this would seem to be a case where the management of of-of-order 
execution type things is done statically at compile time, rather than 
dynamically by the processor.

It could be interesting to see how far this could go -
Compile to code+processor, where the processor architecture is 
implemented by the compiler subject to the requirements of the design.

My 2c,
Jeremy

Article: 91430
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: Sylvain Munaut <com.246tNt@tnt>
Date: Sun, 06 Nov 2005 22:31:00 +0100
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Antti Lukats wrote:
> 
>> BTW: Both Actel and Lattice have also a similar
>> to SLICEM/SLICEL difference between memory
>> capable and logic only slices - it does reduce
>> the die size.
> 
> 
> Interesting.
> The much-hyped SRL16 isn't free after all.

Well, half of them being "simple" slice isn't much
of a cost, there is quite always a need for simple
stuff that will fit nicely in a simple LUT4 ...

I wonder, in other brands of FPGA, what if you need
to delay a 16 bits bus by 16 clocks cycles ? You use
simple registers ? That would be 256 registers just
for that ...


> Perhaps Xilinx is discovering that some
> designers use a lot of generic rtl code.

They're inferred quite well for the common cases,
no need to instanciate them explicitly.


	Sylvain

Article: 91431
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 07 Nov 2005 11:10:42 +1300
Links: << >>  << T >>  << A >>
Jeremy Stringer wrote:
> It could be interesting to see how far this could go -
> Compile to code+processor, where the processor architecture is 
> implemented by the compiler subject to the requirements of the design.

  I think that is being done already, tho at the simple end of the scale,
it does prove it is possible.
  IIRC, it involved compiling the design twice. Once to generate the
Core+Codes, and again to remove unused portions of the core.
  It can introduce other problems - if the CPU changes every time, that
complicates things more, and what looks like a few lines of code, might
enable a new block of the CPU, and have an unexpected hit on both % 
Usage, and speed.

  Cores themselves are not too large these days, the bigger bottleneck
is on chip code memory.

-jg


Article: 91432
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: John_H <johnhandwork@mail.com>
Date: Sun, 06 Nov 2005 22:15:32 GMT
Links: << >>  << T >>  << A >>
Andrew Lohbihler wrote:
> Either way the reason Xilinx did this does not help someone that is porting
> this code to a higher Virtex device. They are stuck with this error with no
> understanding or explanation of how to proceed fixing their code to make it
> work. This is not good support!! Why can't Xilinx make this clear to
> engineers upgrading their devices.
> 
> -Andrew

The error was EXPLICIT !!  How much MORE do you want?  I've included the 
error below.

The only reason for confusion in this instance is that the person 
receiving the error doesn't know the target silicon well enough to 
understand the issues.  Once explained in plain language, the person 
receiving the error was still unable to interpret the solution.  (I 
answered the question twice in this thread)


The error was:

ERROR:Pack:1142 - A problem was encountered updating the component types 
  within the following shape:
     The RPM "uChip0_Cal1_XA1_TA0/hset"

    A problem was encountered trying to change the type of the component
    containing the following symbols to "SLICEL".

     <LUT, Shift, and FLOP instances showed up here>

    The component is already of type "SLICEM".  The setting of the 
component type is necessary since it is an odd number of columns away 
from a component which already has a type of "SLICEM".  This second 
component contains the following symbols:

     <Two shift and 2 Flop instances showed up here>

This architecture has two types of components, SLICELs and SLICEMs, in 
  alternating columns.  Only SLICEMs can contain RAM symbols.

________________________

Now, do you still want to gripe about Xilinx leaving the designer 
without any idea why his placement failed ?!

Personally, I appreciate the level of support that *is* in the tools. 
It doesn't take much to be able to figure out what's going on if you 
choose to look past your own keyboard.

Article: 91433
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: Mike Treseler <miketreseler@yahoo.com>
Date: Sun, 06 Nov 2005 15:55:50 -0800
Links: << >>  << T >>  << A >>
Sylvain Munaut wrote:

> I wonder, in other brands of FPGA, what if you need
> to delay a 16 bits bus by 16 clocks cycles ? You use
> simple registers ? That would be 256 registers just
> for that ...

Unless you shifted a clock enable
down to the output registers.

> They're inferred quite well for the common cases,
> no need to instanciate them explicitly.

Yes. However you do have to take a side trip
to describe these odd bricks before you describe the wall.

Having no reset is also slightly annoying.

      -- Mike Treseler

Article: 91434
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: "Andrew Lohbihler" <xyz.interactive@rogers.com>
Date: Sun, 6 Nov 2005 19:40:18 -0500
Links: << >>  << T >>  << A >>

"John_H" <johnhandwork@mail.com> wrote in message 
news:8gvbf.8850$dU6.4850@trnddc03...
> Andrew Lohbihler wrote:
>> Either way the reason Xilinx did this does not help someone that is 
>> porting
>> this code to a higher Virtex device. They are stuck with this error with 
>> no
>> understanding or explanation of how to proceed fixing their code to make 
>> it
>> work. This is not good support!! Why can't Xilinx make this clear to
>> engineers upgrading their devices.
>>
>> -Andrew
>
> The error was EXPLICIT !!  How much MORE do you want?  I've included the 
> error below.
>
> The only reason for confusion in this instance is that the person 
> receiving the error doesn't know the target silicon well enough to 
> understand the issues.  Once explained in plain language, the person 
> receiving the error was still unable to interpret the solution.  (I 
> answered the question twice in this thread)
>
>
> The error was:
>
> ERROR:Pack:1142 - A problem was encountered updating the component types 
> within the following shape:
>     The RPM "uChip0_Cal1_XA1_TA0/hset"
>
>    A problem was encountered trying to change the type of the component
>    containing the following symbols to "SLICEL".
>
>     <LUT, Shift, and FLOP instances showed up here>
>
>    The component is already of type "SLICEM".  The setting of the 
> component type is necessary since it is an odd number of columns away from 
> a component which already has a type of "SLICEM".  This second component 
> contains the following symbols:
>
>     <Two shift and 2 Flop instances showed up here>
>
> This architecture has two types of components, SLICELs and SLICEMs, in 
> alternating columns.  Only SLICEMs can contain RAM symbols.
>
> ________________________
>
> Now, do you still want to gripe about Xilinx leaving the designer without 
> any idea why his placement failed ?!
>
> Personally, I appreciate the level of support that *is* in the tools. It 
> doesn't take much to be able to figure out what's going on if you choose 
> to look past your own keyboard.


John, I understand what you are saying and appreciate the follow through of 
my error message. but given your solution as;

So 1) find all your memory elements, and 2) move them around so they're
either all in even RLOC columns or they're all in odd RLOC columns.

I don't understand how to implement this in ISE. How do you set the 
constraint in ISE to ensure that the components end up in SLICEMs. Or 
possibly how do you do that manually, or at the silicon level using ISE 
tools?

-Andrew 



Article: 91435
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: Ray Andraka <ray@andraka.com>
Date: Sun, 06 Nov 2005 20:55:33 -0500
Links: << >>  << T >>  << A >>


Andrew Lohbihler wrote:

>Thanks John,
>
>The code did work for a Virtex-II and the details of the packing don't 
>indicate which column constraint was used. Any idea what constraint should 
>be changed to make it work in a Virtex-4? There must be a way to tweak the 
>design for the V4 to make it pack similarily as a V2. Any help will do.
>
>Thanks,
>Andrew
>
>  
>
Most of the time, you can re-do the layout so as to not RLOC SRL16s ore 
RAM16's into odd columns (this is what you need to do).  It is going to 
require you to get familiar with the floorplanning that was done for V2 
for this design, and then alter it so that those memory elements only 
fall in even columns.

There is also a bug in the mapper that does not allow RPMs with memory 
elements to straddle DSP48 or BRAM columns if there are any memory 
elements to the left of the DSP48/BRAM column (in other words, you can't 
have any DSP48 or BRAM columns between the RPM's origin and any column 
containing either SRL16 or RAM16 elements).  That bug was present in 6.x 
and 7.1 at least through SP3.  I haven't checked to see if it was 
corrected in SP4.  I don't believe that it was however.  In practical 
terms, this means any of your macros that use the LUT memory elements 
must be less than 4 columns until the bug is fixed, which may require 
you breaking them into separately placed pieces (you can do it by just 
adding different  HU_SET attributes to the elements in each 4 column zone).

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 91436
Subject: The Xilinx MultiPoint Synthesis Flow - Synplify Pro
From: irezki@gmail.com
Date: 6 Nov 2005 17:55:33 -0800
Links: << >>  << T >>  << A >>
I'm doing my work using next tutorial: "MultiPoint Synthesis Using
Synplify Pro for Xilinx".
I defined three compile points in the top-level .sdc file:
Block_1
Block_2
Block_3
After that I run synthesis. And I have next error:
@E: FA165 :"../../top/top_level.v" - Unable to insert correct pad for
port TDO. It is driven by a tristate in an unreachable hierarchy
(Blackbox or Compile Point).
This output port TDO located in Block_2 module. Without compile points
it works correctly.

Verilog code for top_level.v
module top_level(
..
..
..
TDO
);
..
..
..
output TDO;
..
..
Block_2 uBlock_2(
..
.TDO   (TDO),
..
);

..
endmodule

May be I have to define this port in constraint file ?


Article: 91437
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: Ray Andraka <ray@andraka.com>
Date: Sun, 06 Nov 2005 21:01:45 -0500
Links: << >>  << T >>  << A >>
GaLaKtIkUs™ wrote:

>But why were these changes done ? is it a sacrifice made by Xilinx to
>allow adding XtremeDSP and other hard cores inside the Virtex-4 ?
>Or is it simply because a few people use the CLBs as memory or shift
>registers?
>
>  
>
Its because of the users Xilinx polled, most either didn't use SRL16's 
at all or if they did used less than 5% of the LUTs as SRL16s/RAM. The 
SRL16 is not free, it substantially increases the physical area occupied 
by the LUT, as well as the testing required to verify the part 100%, so 
Xilinx took the opportunity to reduce the complexity by stripping out 
half the distributed memory elements. I think a large part of the fault 
lies in the fact that Xilinx does a very poor job of touting the 
benefits of the SRL16 capability, in fact, I don't think they have more 
than a few people there that understand how powerful this element is. It 
is a shame they stripped it out of half the part, and I think it makes 
the software that much harder as well. They don't really feel the pain 
though because their top shelf users are not really using the capability 
effectively, and synthesis only makes use of it in the most rudimentary way.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 91438
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 6 Nov 2005 18:01:54 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:
>   IIRC, it involved compiling the design twice. Once to generate the
> Core+Codes, and again to remove unused portions of the core.
>   It can introduce other problems - if the CPU changes every time, that

That's interesting :) ... who's tools are doing that?

The other extreme are Sarah's HarPE tools which even optimize away
pretty much the whole core into logic.


Article: 91439
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: Ray Andraka <ray@andraka.com>
Date: Sun, 06 Nov 2005 21:07:43 -0500
Links: << >>  << T >>  << A >>
Andrew Lohbihler wrote:

>
>John, I understand what you are saying and appreciate the follow through of 
>my error message. but given your solution as;
>
>So 1) find all your memory elements, and 2) move them around so they're
>either all in even RLOC columns or they're all in odd RLOC columns.
>
>I don't understand how to implement this in ISE. How do you set the 
>constraint in ISE to ensure that the components end up in SLICEMs. Or 
>possibly how do you do that manually, or at the silicon level using ISE 
>tools?
>
>-Andrew 
>
>  
>
Andrew,

You are going to have to find out where the placement is specified.  It 
may be in the source, in a UCF file or in the floorplanner.  If you are 
using RPM macros from a 3rd party, you may have to either recompile 
those macros with fixes or contact the 3rd party for a modified macro 
suitable for V4.  Basically, you have to modify the placement where ever 
it was specified.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 91440
Subject: Re: Why Spartan-3e is the best
From: "Jecel" <jecel@merlintec.com>
Date: 6 Nov 2005 19:46:40 -0800
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> 5) Some nice new (compared to other Spartan FPGAs)
> package combinations like:
> *Largest fabric in VQ100
> *Largest fabric in chip-scale package
> *Largest fabric in FT256
> *Largest fabric in non-BGA package

Where did you see that? Looking at
http://www.xilinx.com/products/silicon_solutions/fpgas/product_tables.htm#Spartan3E
it seems only the two smallest models are available in VQ100 and TQ144
packages. The smallest package for the largest fabric is the FG320,
right? The datasheet has the same information.

--- Jecel


Article: 91441
Subject: Re: Why Spartan-3e is the best
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 07 Nov 2005 18:00:26 +1300
Links: << >>  << T >>  << A >>
Jecel wrote:
> Antti Lukats wrote:
> 
>>5) Some nice new (compared to other Spartan FPGAs)
>>package combinations like:
>>*Largest fabric in VQ100
>>*Largest fabric in chip-scale package
>>*Largest fabric in FT256
>>*Largest fabric in non-BGA package
> 
> 
> Where did you see that? Looking at
> http://www.xilinx.com/products/silicon_solutions/fpgas/product_tables.htm#Spartan3E
> it seems only the two smallest models are available in VQ100 and TQ144
> packages. The smallest package for the largest fabric is the FG320,
> right? The datasheet has the same information.

I think Antti meant that the 3e has the largest resource available in 
(any) QFP, not that the biggest s3e die goes into a QFP.
ie it is more a LUT/package measure.

-jg


Article: 91442
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: "Andrew Lohbihler" <xyz.interactive@rogers.com>
Date: Mon, 7 Nov 2005 01:11:16 -0500
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote in message 
news:EEybf.3490$IC.959@dukeread07...
> Andrew Lohbihler wrote:
>
>>
>>John, I understand what you are saying and appreciate the follow through 
>>of my error message. but given your solution as;
>>
>>So 1) find all your memory elements, and 2) move them around so they're
>>either all in even RLOC columns or they're all in odd RLOC columns.
>>
>>I don't understand how to implement this in ISE. How do you set the 
>>constraint in ISE to ensure that the components end up in SLICEMs. Or 
>>possibly how do you do that manually, or at the silicon level using ISE 
>>tools?
>>
>>-Andrew
>>
> Andrew,
>
> You are going to have to find out where the placement is specified.  It 
> may be in the source, in a UCF file or in the floorplanner.  If you are 
> using RPM macros from a 3rd party, you may have to either recompile those 
> macros with fixes or contact the 3rd party for a modified macro suitable 
> for V4.  Basically, you have to modify the placement where ever it was 
> specified.
>
> -- 
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com  http://www.andraka.com
> "They that give up essential liberty to obtain a little temporary safety 
> deserve neither liberty nor safety."
>                                          -Benjamin Franklin, 1759
>
>

I use Xilinx cores here, specifically the Logicore multiplier (Multiplier 
7.0) in the Xilinx Core Generator. This is the code near where the mapping 
failed. The "multiplier construction" parameter field apparently has no 
selector for "ExtremeDSP" slices but does have a "Luts" selector. Perhaps I 
have an old Logicore that was not updated for the V4. The documentation 
recommends using either field to construct for a V4, and clearly shows that 
the ExtremeDSP selector should be there. Anyone have experience with thes 
cores to know this??

-Andrew 



Article: 91443
Subject: Re: Why Spartan-3e is the best
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 7 Nov 2005 07:18:31 +0100
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
news:436edf24$1@clear.net.nz...
> Jecel wrote:
>> Antti Lukats wrote:
>>
>>>5) Some nice new (compared to other Spartan FPGAs)
>>>package combinations like:
>>>*Largest fabric in VQ100
>>>*Largest fabric in chip-scale package
>>>*Largest fabric in FT256
>>>*Largest fabric in non-BGA package
>>
>>
>> Where did you see that? Looking at
>> http://www.xilinx.com/products/silicon_solutions/fpgas/product_tables.htm#Spartan3E
>> it seems only the two smallest models are available in VQ100 and TQ144
>> packages. The smallest package for the largest fabric is the FG320,
>> right? The datasheet has the same information.
>
> I think Antti meant that the 3e has the largest resource available in 
> (any) QFP, not that the biggest s3e die goes into a QFP.
> ie it is more a LUT/package measure.
>
> -jg
>

yes Jim.

also that it has largest fabric in SAME package compared to S3 or other 
Xilinx FPGA.

as example VQ100 is really nice package very thin, so largest LUTs you get 
in VQ100 is S3e. etc..

worlds largest non BGA FPGA is Actel PA3-3000E I think.

Antti










Article: 91444
Subject: Re: Anybody understand this ISE 7.1 error, and what to do about it???
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 7 Nov 2005 07:21:45 +0100
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag 
news:2zybf.3489$IC.2133@dukeread07...
> GaLaKtIkUs™ wrote:
>
>>But why were these changes done ? is it a sacrifice made by Xilinx to
>>allow adding XtremeDSP and other hard cores inside the Virtex-4 ?
>>Or is it simply because a few people use the CLBs as memory or shift
>>registers?
>>
> Its because of the users Xilinx polled, most either didn't use SRL16's at 
> all or if they did used less than 5% of the LUTs as SRL16s/RAM. The SRL16 
> is not free, it substantially increases the physical area occupied by the 
> LUT, as well as the testing required to verify the part 100%, so Xilinx 
> took the opportunity to reduce the complexity by stripping out half the 
> distributed memory elements. I think a large part of the fault lies in the 
> fact that Xilinx does a very poor job of touting the benefits of the SRL16 
> capability, in fact, I don't think they have more than a few people there 
> that understand how powerful this element is. It is a shame they stripped 
> it out of half the part, and I think it makes the software that much 
> harder as well. They don't really feel the pain though because their top 
> shelf users are not really using the capability effectively, and synthesis 
> only makes use of it in the most rudimentary way.
>
> -- 
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com  http://www.andraka.com

AGREE 100%

SRL16 is way useful but I do not see it nearly possible that they will be 
used the best
way with regular synthesis. so the customer should be at least aware of what 
is needed
to get the SRL16 being used (automatically) or then use them directly.

Antti
























Article: 91445
Subject: Re: icarus verilog
From: ptkwt@aracnet.com (Phil Tomson)
Date: 7 Nov 2005 07:48:33 GMT
Links: << >>  << T >>  << A >>
In article <dkggau$slh$1@lnx107.hrz.tu-darmstadt.de>,
Uwe Bonnes  <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:
>Brian Dam Pedersen <brian.pedersen@mail.danbbs.dk> wrote:
>> I don't use the iverilog for synthesis - however I *do* use it for rtl 
>> simulation - since I can't find other free simulators to run on Linux - 
>> and for hobby projects (even large ones) it is quite good imho. A pity 
>> if it disappeared completely - time for making a fresh backup of the 
>> current source tree on my HDD - I'd be quite stuck without it ;)
>
>I think Stephan is on some longer vacation, ast Stephan told on the gea
>mailing list october 8. It's natural that the website goes down in such a
>situation... 
>
>The other option for a free simuator is
>
>http://www.pragmatic-c.com/ 
>

How would you compare the two?  Is Cver as complete and mature as Icarus?

BTW: even if the icarus website were to disappear, the icarus codebase 
itself would live on forever since it is under GPL - that's the nice 
thing about open source.  Hopefully, the icarus website will be back up soon.

Phil

Article: 91446
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: ptkwt@aracnet.com (Phil Tomson)
Date: 7 Nov 2005 07:55:44 GMT
Links: << >>  << T >>  << A >>
In article <qhoe52lmhz.fsf@ruckus.brouhaha.com>,
Eric Smith  <eric@brouhaha.com> wrote:
>Rene Tschaggelar wrote:
>> Why are those guys so keen on C ? Suggesting compatibility with
>> something while having least readability ?
>
>air_bits@yahoo.com writes:
>> The description at the project page pretty much says it all:
>> 
>> "C provides an excellent alternative to VHDL/Verilog for algorithmic
>> expression of tasks targeting FPGAs for reconfigurable computing."
>
>That doesn't explain *why* it's an excellent alternative.  I can just
>as easily state that "C provides a terrible alternative to VHDL/Verilog
>for algorithmic expression of tasks targetting FPGAs for reconfigurable
>computing".  So why is their statement any more accurate than mine?

The main advantage that C has over the HDLs is that many software 
engineers know C, not many know VHDL/verilog.  Perhaps the goal of 
targetting FPGAs with C is to allow lots of software engineers to be able 
to develop algorithms that can be accelerated in a FPGA.

Of course a lot of software engineers do not prefer C these days....

Phil

Article: 91447
Subject: Re: icarus verilog
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 7 Nov 2005 09:06:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
Phil Tomson <ptkwt@aracnet.com> wrote:
> In article <dkggau$slh$1@lnx107.hrz.tu-darmstadt.de>,
> Uwe Bonnes  <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:
> >Brian Dam Pedersen <brian.pedersen@mail.danbbs.dk> wrote:
> >> I don't use the iverilog for synthesis - however I *do* use it for rtl 
> >> simulation - since I can't find other free simulators to run on Linux - 
> >> and for hobby projects (even large ones) it is quite good imho. A pity 
> >> if it disappeared completely - time for making a fresh backup of the 
> >> current source tree on my HDD - I'd be quite stuck without it ;)
> >
> >I think Stephan is on some longer vacation, ast Stephan told on the gea
> >mailing list october 8. It's natural that the website goes down in such a
> >situation... 
> >
> >The other option for a free simuator is
> >
> >http://www.pragmatic-c.com/ 
> >

> How would you compare the two?  Is Cver as complete and mature as Icarus?

I feel Cver is more complete. Cver comes as a GPL incarnation and as a
commercial product.

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 91448
Subject: Adder synthesis
From: "nezhate" <mazouz.nezhate@gmail.com>
Date: 7 Nov 2005 02:34:40 -0800
Links: << >>  << T >>  << A >>
Hi all,
Can anyone tell me why this occurs : "when synthetizing we get a good
results (time/area) by using an adder contained in the fpga circuit and
when we use an adder that can be manually designed, we get a less
performances (time/area) "  ? 
Thanks.


Article: 91449
Subject: which Altera CPLD?
From: "Manfred Balik" <manfred.balik@tuwien.ac.at>
Date: Mon, 7 Nov 2005 11:56:58 +0100
Links: << >>  << T >>  << A >>
I want to use an Altera CPLD to do the interface between an ISA-Bus and a 
Cyclone II-FPGA.
The CPLD should satisfy the criteria of the ISA-Bus timing to enable/disable 
the FPGA and do the level-conversion between the 5V ISA-Bus-levels and the 
logic levels of the FPGA (3,3V or 2,5V or 1,8V).

I found this Altera CPLDs:
MAX II doesn't support 5V I/Os
MAX 3000A
MAX 7000B doesn't support 5V I/Os
MAX 7000AE
MAX 7000S
What is the main difference between this 3 remaining CPLDs?
Is one of them a mature device?
Which Altera CPLD should I use, I'm unfortunately not so familiar with 
CPLDs.

Thanks for help, Manfred 





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