Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
"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. AnttiArticle: 91427
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. yusufArticle: 91428
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: 91429air_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, JeremyArticle: 91430
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. SylvainArticle: 91431
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. -jgArticle: 91432
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
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"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? -AndrewArticle: 91435
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: 91436I'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
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: 91438Jim 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
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: 91440Antti 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. --- JecelArticle: 91441
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. -jgArticle: 91442
"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?? -AndrewArticle: 91443
"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. AnttiArticle: 91444
"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. AnttiArticle: 91445
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. PhilArticle: 91446
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.... PhilArticle: 91447
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
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
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:
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