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
rickman wrote: > Russell Shaw wrote: > ... >>For me, nothing is better than SRL in every slice. With few SRLs, i >>might as well use altera. I didn't mind paying more for more SRLs. > > > Half the normal number is far from "few SRLs". I think a few thousand > SRLs is still enough for some 99.9% of the typical designs. Of course > there will always be the unusual vector processing designs like Ray's, > but even then if the pricing holds to the typical Spartan curve, you > will do better in terms of price with a Spartan that has twice as many > CLBs as the Virtex chips and has the same number of SRLs. I filled a spartan-200 with a cascade of filters, and couldn't expand any further because the bigger chips were bga. Hopefully the spartan-3 leaded chips will have more srls. There's nothing unusual about large dsp designs, but they're hard to do when you want 80% hand placement.Article: 54701
Hello, in the JTAG Programmer from Xilinx it's possible to run a functional test which uses test vectors from the jedec file. I have looked around but it seems that this test vectors can only be generated from the ABEL design flow. Does anyone know if there is another possibility? Thank you very much -- Klaus Falser Durst Phototechnik AG kfalser@IHATESPAMdurst.itArticle: 54702
lsimsic@altera.com (Lara Simsic) writes:
Hi Lara, thank you for your suggestions.
> Everything is setup for CSH and SH, but not BASH. Please try using
> CSH or SH. If you want to use BASH, you can look in nios_csh file and
I tried:
pegu@scifire 1% setenv sopc_builder /net/sciraid2/raid2/home/local-solaris-sun4/altera/nios-3.0
pegu@scifire 2% source $sopc_builder/bin/nios_csh
pegu@scifire 3% nios-build hello_world.c
Can't use string ("-1") as a HASH ref while "strict refs" in use at - line 478.
This seems to be related to a Perl script.
http://www.troubleshooters.com/codecorn/littperl/perlfuncorder.htm
Don't know which script since only the line in error and not the file
name is listed.
> One thing I noticed is that you are using SunOS 5.9 (Solaris 2.9).
> SOPC Builder 2.8 is supported on Solaris versions 2.7 and 2.8 only.
> This may or may not be the problem.
I got hold of a Windows PC and installed SOPC/Quartus and got the same
error message so it does not appear to be related to Solaris 2.9.
> There is a makefile in the lib directory for all the examples (in
> fact, all systems generated by SOPC Builder have one). Here is the
> path to the makefile for the standard_32 example design for the
> Stratix 1S10 board (the one which comes with the Nios Dev Kit, Stratix
> Edition):
> <sopc_builder>\examples\verilog\nios_stratix_1s10\standard_32\cpu_sdk\lib
Thank you. I'll try this approach instead.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
Article: 54703Hi Goran, First of my 0.2$ shouldn't you know if Webpack ISE supports all familys? But that is beside the point. However you claiming that the 40 perhiperals is include with EDK it is acctually 38 (quick count on Xilinx homepage), this number is by your own addmittans far more than Altera is shipping with Nios (could be since there is only 18 free peripheral in the SOPC builder). But you are missing a fair amount of addons that Xilinx is counting as peripheral and Altera is not (bsp for instans). For the dev kit itself you also have a lot of peripherals onboard (it is my guess this is what Jim is refering to) Stuff like this acctually speed up once development quickly. I also see a lot of similarities between Microblaze and Nios, since I am somewhat biased towards Altera solutions I would say that the big advantage with Nios compared to Microblaz is the fact that when buy a Nios-kit you get everything you need in ONE box (and one bill) you just have to add power (not the cord, it is included). Cheers Fredrik Goran Bilski <Goran.Bilski@Xilinx.com> wrote in message news:<3E9C9779.F1D0FF89@Xilinx.com>... > Hi Jim, > > I'm just interested on how MicroBlaze compares against NIOS. > > So what family is not supported in Webpack ISE? > I think that there is a least one member from each family in Webpack. > > Xilinx EDK tool cost $495 and includes 40 peripherals which is far more than Altera is shipping in > their NIOS kit. > You can buy the EDK and a board from other vendors for a total less than $995. > > MicroBlaze is also shipped free with each EDK and there is no royalty and license required. > MicroBlaze is not any different than NIOS in that respect. > > MicroBlaze fulfill all your requirements that you had for choosing NIOS. > > If you're still interested, I can create your system on MicroBlaze and you can do the comparison. > > Göran > > "Jim M." wrote: > > > Goran, > > > > I mentioned that I had mixed feelings then went on to only convey the > > negative ones. Not the best move on my part. > > > > I don't really want to open up a Xilinx vs. Altera debate. > > > > One of the big reasons I went with Altera is that they support all of > > their devices in the free versions of their software. What I mean by > > 'all' is that each family has at least one device supported. Event > > the Excalibur family with ARM processor. > > > > Their dev kits come with a device and are generally less expensive > > with more peripherals. > > > > In addition the NIOS soft core is provided free with any NIOS dev-kit > > (with software tools) and it's royalty free for re-use... this is a > > big deal. > > > > Those were some of the factors in my decision to go with Altera. > > > > I'm very interested in hearing from other NIOS users on their > > experiences. > > > > Goran Bilski <Goran.Bilski@Xilinx.com> wrote in message news:<3E9B1F99.17B9B1C5@Xilinx.com>... > > > Hi Jim, > > > > > > If you can give the overview picture of your system, I could then create a > > > similar system using MicroBlaze. > > > This will give you something to compare against. > > > > > > Göran Bilski > > > > > > "Jim M." wrote: > > > > > > > I recently purchased a NIOS Stratix 1S10 Development Kit from Altera > > > > and have mixed feelings about Quartus, SOPC Builder, and the NIOS > > > > Core. (For those poor souls interested, I've included some comments > > > > at the end of this post... feel free to provide feedback.) > > > > > > > > However, here's my question: > > > > > > > > What's the maximum clock frequency anyone has achieved using the NIOS > > > > 3.0 CPU in 32bit mode with the standard peripherals (SRAM, SDRAM, > > > > Ethernet, PIO, UART, etc. as in the Reference Design provided by > > > > Altera)? > > > > > > > > I've tried isolating the various components into LogicLock regions. > > > > I've tried different fitter/netlist optimizations. The maximum Fmax I > > > > have achieved to date is 80 MHz. This is after letting Quartus "fit" > > > > for 10 hours... it actually didn't stop, I had to abort the fitting > > > > and refit to finially get an interim result (see other misc comments > > > > below). > > > > > > > > Altera advertises 125 MHz for the Stratix Device and NIOS 3.0... > > > > However a reference design that builds at that clock rate is not > > > > provided. It appears that Altera gives you just enough to get your > > > > feet wet... anything above and beyond that is Intellectual Property > > > > that you need to buy. > > > > > > > > Other Observations/Comments: > > > > > > > > 1. The Quartus II SP1 software is extremely flakey. I've generated > > > > numerous faults when deleting/modifying child LogicLock Regions. It > > > > also takes forever to fit my Stratix design which is only 6000 LEs. > > > > If I select the "limit fitting attempts to 1" option, Quartus > > > > sometimes fits many times (like forever...) why?!?!? Also, after a > > > > design is finished building, the software sits around for up to 5 > > > > minutes before it generates a "finished" dialog box. I'm not sure > > > > what's going on between the Quartus Application thread and the Quartus > > > > Compiler thread, but it's fustrating enough just waiting for the > > > > design to build, let alone waiting for Quartus to figure out the build > > > > is done. I could go on and on, and that's only the result of 4 weeks > > > > of effort with a small design. I feel sorry for those folks working > > > > on a 100,000+ gate design. I guess modularity is the key there. > > > > > > > > 2. I can't simulate designs with virtual pins. I get warning during > > > > the analysis of the simulation and then receive results with all input > > > > pins a zero and output pins undefined. In addition, I can generate > > > > hold time warnings during simulation for a design that didn't compile > > > > with any hold time warnings. I'm not talking about hold time warnings > > > > on my input signals, I'm talking about hold time warnings on internal > > > > registers in my verilog code. Registers that I've taken care to hold > > > > for 1 or more clock cycles before using in other parts of the design. > > > > Again, the compilation of the design did not generate hold time > > > > warnings... only the simulation of the design. > > > > > > > > 3. PLLs generate different timing analysis results. THIS IS VERY > > > > ANNOYING! When I build up a "black-bock" design with virtual pins I > > > > obtain a Fmax calculation from the timing analysis routine. I then > > > > LogicLock the design and export it. When I import the design into a > > > > new project and clock it using a PLL it generates negative slack time > > > > warnings! If I remove the PLL and replace it with a clock pin, I get > > > > the Fmax result that I obtained during the "black box" design. I beat > > > > myself up for a week trying to debug a design that wasn't broken > > > > because of this goofy behavior in Quartus. I'm still not sure if the > > > > slack time warning it legit and wether I should be concerned about it. > > > > > > > > 4. SOPC Builder will lock itself up if you double-click components > > > > before selecting them. Give it a try... double click a component line > > > > in your NIOS design before selecting the line item. After a couple > > > > times the SOPC builder application creeps to a halt. > > > > > > > > 5. Documentation on the various megafunctions is lacking. A good > > > > example is the altsyncram megafunction. It doesn't state any timing > > > > requirements on the input registers, enable, and clock signals. Do I > > > > hold the data 1 cycle before flipping the write enable? How about > > > > holding the write enable before de-activating it? Why is the > > > > addressing based upon the data bit-width? Trying to tie a 32-bit > > > > altsyncram block to a NIOS CPU is difficult because you need to > > > > specify the address space of the peripheral and the address space of > > > > the altsyncram block is based upon the bit width (not the number of > > > > bytes). > > > > > > > > 6. I have yet to get a Leonaro-Spectrum synthesized Verilog file to > > > > build in Quartus. I can used Spectrum generated .edf files but not > > > > verilog. I get LCELL parameter errors. Unfortunately, Altera can't > > > > seem to duplicate this... anyone else see this behavior? I'm not sure > > > > if Spectrum synthesizes Verilog better that Quartus, but it definitely > > > > does it faster. > > > > > > > > Feedback is welcome... even if it's the "you're an idiot and here's > > > > why" variety...Article: 54704
Hi Ben, I have no problem to compile; the problem is to generate symbol. I cannot understand how can I mix at top level my VHDL blocks with blocks from Quartus II libraries, and connect them together in a schematic (bdf) without having the symbol of my own VHDL. Best regards, Andrea "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl> ha scritto nel messaggio news:JW%ma.1809$KF1.81823@amstwist00... > Hi Andrea, > > > How can I manage a complex design with many files that use components and > > packages from different files ? > > (Consider that the same package may be used by different files at the > > different level of hierarchy) > > Once Quartus has read the package, it should be able to use its delarations > and components at any design depth. If you have a design, no matter how > trivial, that proves otherwise, please send it to me aand I'll try to figure > out what is going wrong - except, of course, if you want to generate > symbols. > > Best regards, > > > Ben > >Article: 54705
Hi fellows. I want to make file using command line. thats why lookig to make makefile for that purpose. As I didn't get FPGA express thats why I am using XST.exe. But te problem is " Errors". Do you think I need to change the command line options so as to make it compatible with xst because my makefile was using FST complier as target FEXP. Because what I did that I copy HW2_TPLT as a different name in my c directory. Then I installed make utility and then I changed the path to FEXP = c:\xilinx\bin\xst.exe which is where my xst.exe is located. Now, the following errors were there when I started making the files. Before I show you the errors, I replace -oem opiton to -ofn because it was appearing on the screen that -oem option is not allowed. Errors: : Error Number (1): : c:\xilinx\bin\nt\xst.exe -ofn xilinx -f fe_run.fst : ERROR:Portability:90 - Command line error: Switch "-force" is not : allowed. : Error Number (2): : c:\xilinx\bin\nt\xst.exe -ofn xilinx -f fe_run.fst : ERROR:Portability:90 - Command line error: Switch "-force" is not : allowed. ----------------------------------------------------------------------------------------- Now, then what i did I deleted all -force -progress or ect options in fe_run.fst and fe_tmplt.fst as required by the errors appearing on the screen. But it didn't work. Can anybody give me the link on how to make makeflie using XST so that I could proceed further. Thanking you in advance. M.K.KhanArticle: 54706
Hi Khan, how about reading the manual? ISE, Menu: Help\Online Documenation\Xilinx Synthesis Technology\Command Line Mode And do you really expect a command-line for one tool to work on a completly different tool? FritzArticle: 54707
Agree with you. Drop-in replacement with different bitstream is the question, obviously. I have never seen two different families with pin-compatibility within the same package, and there are both technical as well as business reasons, I presume. Even if Vcc, Gnd pins are tried to kept same, there would always be voltage level changes due to different process geometries which will make board changes inevitable. So why not take the fullest advantage of the new family features? --Neeraj "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3E9CDBE6.260D0EC@yahoo.com... > Neeraj Varma wrote: > > > > Yes, S3 does have the DCI. And 2E and S3 are not pin compatible. S3 supports > > 23 I/o standards as compared to 19 in S2E. > > That in itself does not make them pin incompatible. That would just be > additional features inside the chip. I don't think the OP meant pin > compatible in the sense of using the same bit stream. I know when I > look for pin compatible in an FPGA, I just figure I can solder the chip > in the same footprint and have it work. I fully expect to have to > generate a new bit stream. > > The data sheets can be downloaded. I found differences in the JTAG, > VCCINT and GND signals, so I would say they are not very pin compatible > if at all. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54708
What worries me more is the divergence from a consistent architecture. For
synthesized designs, that is not an issue. For designs constructed
structurally with placement in order to gain performance and density it is a
huge issue. The gratuitous change of placement grids from virtex to
virtexII was enough of an upset to cause a significant re-write of our
library along with adding a bunch of complexity to our macros so that family
is considered in placement. Now Spartan-3 adds another complexity, and it
sounds like Virtex 3 is going to be yet another departure. The fact that
spartan-II was compatible with VirtexII was very much appreciated.
We can live (begrudgingly) with the reduced SRL density, but it does require
a major update to our libraries. Our filters, for example, use SRL16's in
slice 1 (the left half of each column), which is exactly opposite what
Spartan-3 does, and below each column, both slices are SRL's. We'll see
what Virtex-3 brings.
Russell Shaw wrote:
> rickman wrote:
> > Russell Shaw wrote:
> >
> ...
> >>For me, nothing is better than SRL in every slice. With few SRLs, i
> >>might as well use altera. I didn't mind paying more for more SRLs.
> >
> >
> > Half the normal number is far from "few SRLs". I think a few thousand
> > SRLs is still enough for some 99.9% of the typical designs. Of course
> > there will always be the unusual vector processing designs like Ray's,
> > but even then if the pricing holds to the typical Spartan curve, you
> > will do better in terms of price with a Spartan that has twice as many
> > CLBs as the Virtex chips and has the same number of SRLs.
>
> I filled a spartan-200 with a cascade of filters, and couldn't expand
> any further because the bigger chips were bga. Hopefully the spartan-3
> leaded chips will have more srls. There's nothing unusual about large
> dsp designs, but they're hard to do when you want 80% hand placement.
--
--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: 54710
Generally, synthesis is good enough that you don't need to use the cores for
these simple functions. Look at what your synthesis produces, and compare it
with what the coregen produces (you can use the floorplanner or fpga editor to
do the comparison) and decide for yourself.
David wrote:
> Hi,
> I'm using Xilinx ISE 5.2 and this is the first time I have access to the
> core generator. I wonder if it is always better (in terms of size and speed)
> to use basics components created with the Core Generator. For example,
> should I change all the Dflipflops of my designs (I wrote them in vhdl) for
> the one that can be generated with Core generator?
> What about adders? Is (c <= b+a ) still used or you always take the core
> generator components?
>
> Thanks
> David
--
--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: 54711
I looked at this a while back for a potential customer. IIRC, ray tracing could
be substantially accelerated using somewhere around six more ot less independent
pipelined co-processes in an FPGA. I don't recall what all of them were, but it
included texture mapping, geometry etc.
Rene Tschaggelar wrote:
> Svjatoslav Lisin wrote:
> > Does somebody know any ready hardware systems for raytracing acceleration ?
> > How much can it cost?
>
> You'd need a geometry unit that calculates the traces, with
> refraction and reflection
> Then you'd need a scene manager that can sort the objects and
> find which are to be met by which ray.
> It appears to be more of a cpu job to me, once the geometry
> is done.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net
--
--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: 54712Hi, Uwe Bonnes wrote: > A recent well configured wine with the prerequisited for Installshield 6 > installers ( native stdole*.tbl) in the <wine>/windows directory should > do the job. Installation will take some time ( wine directory handling in > help/usenglish/newroot with it's 5499 files is not optimal) , show some > errors and message box stacking may be wrong so that na "OK" buttom is > hidden, but the installation should be useable. Ok I've managed to get a little more time to look at this. I've upgraded the version of wine I have by compiling from source and attempted various things to get the WebPack 5.2i installer to work. 1) Wine only (no native files) attempt at running WebPACK_52_fcfull_i.exe. This initially looks great, until it attempts to run the Java Runtime Environment installer where it bombs out into winedbg. 2) Copy all files which match the pattern stdole*.tlb from a Win98 machine and place them into ~/c/windows/. This attempt gets through to about 10% of the main xilinx installer (i.e. before installing the JRE) and then "freezes". 3) Copy just stdole32.tlb from a Win98 machine and place into ~/c/windows. This attempt just acts the same as 1) above. 4) Copy all files which match the pattern stdole*.tlb from a Win2K machine and place them into ~/c/windows/. This attempt just acts the same as 1) above. 5) Copied all the files outlined in the following posting (http://www.winehq.com/hypermail/wine-devel/2003/02/0288.html) from a Win2K machine and executed WebPACK_52_fcfull_i.exe as outlined. The posting says it won't work with win2k binaries, but that's the only system(s) I have readly available access to at the moment and I thought it was worth a shot anyway.... With this setup when the installer launches the "Java 2 Platform Standard Edition installer" I get a message box saying "The InstallShield Engine (iKernel.exe) could not be launched (0x80074fec)"... Clicking ok causes it to die, but the WebPACK installer appears to continue on (complaining about not being able to make desktop shortcuts) I've looked through various articles on the xilinx website about using wine and ise together but nothing seems to help. But none that appear to help. Some more details: [chris@shazam chris]$ wine --version Wine 20030408 Any hints? Thanks, Christopher FairbairnArticle: 54713
On Wed, 16 Apr 2003 00:40:46 -0400, rickman <spamgoeshere4@yahoo.com> wrote: > >They only issue I see with BGAs is the requirement for hot air soldering >with BGA while a flatpack can be iron soldered. But you can do hot air >soldering with an inexpensive rework station. In my experience it has not been this simple. I had a multi-thousand dollar hot air system here for a while ... I will not do bga's again in house until I also have the xray equipment to properly QC the bga soldering ... and unfortunately that equipment isn't exactly in my budget.Article: 54714
Hello again, I guess I'm still confused by a couple of things... [1] I can see a power supply aspect to the problem, wherein the load line crosses the I-V characteristic in two places, call them "normal operation" and "current-limit", and the system can get stuck in the current-limit. But I can't quite reconcile this with a slew rate limit. Specifically, if I have a power supply which can source a million Amps at any voltage, but has a rise time of a day, will there be a problem ? Why ? Maybe I need to go and study more about CMOS gates... [2] The Spartan-II datasheet (Module 3: DC and Switching > page 3) shows the startup current requirement _with_no_reference_ to the device size... you'd think there'd be _some_ difference between a 2S15 and a 2S200, surely a 2S15 application shouldn't be required to design in a 2S200-rated power supply ? Regards, -rajeev- ----------------- Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3E9B2C2A.A85@designtools.co.nz>... > rickman wrote: > > > > Rajeev wrote: > > > <...> > > > > > > Can somebody shed light on why power-up waveforms matter ? I mean, one > > > might (naively ?) imagine that things would be OK so long as all the > > > voltages settle down before configuration starts... > > <...> > The mechanism is quite simple: you have a sea of complementary fets, > and > as Vcc ramps, the Gate capacitance is going to ramp Vg at appx 50% of > Vcc. > At the point where the FETS just start to conduct, and so are able to > drive > their LOAD gates, you are going to get small, but finite currents thru > a very large number of devices, hence the AMPS order of init current @ > 0.7V Vcc > > Sometimes 0.7V is inside the foldback of a linear regulator, and not > many > data sheets plot Io/Vo. > > What needs to be watched, is that there is a slew-threshold, and if you > do NOT > give it 'a hard enough kick', it will NOT cross the linear threshold, > and > stays there for ever - so it is not a simple charge model, of a single > FET. > If it were, half the current for twice as long would be fine. > > - jgArticle: 54715
Christopher Fairbairn <ckf13@student.canterbury.ac.nz> wrote: : Hi, : Uwe Bonnes wrote: :> A recent well configured wine with the prerequisited for Installshield 6 :> installers ( native stdole*.tbl) in the <wine>/windows directory should :> do the job. Installation will take some time ( wine directory handling in :> help/usenglish/newroot with it's 5499 files is not optimal) , show some :> errors and message box stacking may be wrong so that na "OK" buttom is :> hidden, but the installation should be useable. : : Ok I've managed to get a little more time to look at this. I've upgraded the : version of wine I have by compiling from source and attempted various : things to get the WebPack 5.2i installer to work. : 1) Wine only (no native files) attempt at running WebPACK_52_fcfull_i.exe. : This initially looks great, until it attempts to run the Java Runtime : Environment installer where it bombs out into winedbg. This error is known. Quit the debugger, and the installation will proceed. A patch to get the Java Installation a little further is pending. Now cd to the webpack base directory and run "wine bin/nt/ise.exe". It should work. Set the wine version to a windows version required by webpack. Running with native msvcrt is needed at least for the CPLD verilog flow. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 54716
"Neeraj Varma" <neeraj@cg-coreel.com> wrote in message news:<b7jagq$1hhq3$1@ID-159439.news.dfncis.de>... > Agree with you. Drop-in replacement with different bitstream is the > question, obviously. > > I have never seen two different families with pin-compatibility within the > same package, and there are both technical as well as business reasons, I > presume. Even if Vcc, Gnd pins are tried to kept same, there would always be > voltage level changes due to different process geometries which will make > board changes inevitable. So why not take the fullest advantage of the new > family features? I guess it depends on how you define "family". I believe the original Virtex (and later 4000 series) high end devices were pin compatible with lower-end Spartan families, but back then the Spartan was an almost exact copy of the higher end device. Starting with the S2E, they started making more changes, and S3 is obviously an even bigger change. Regardless, you are correct about there being technical AND business reasons for them not being pin compatible. > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:3E9CDBE6.260D0EC@yahoo.com... > > Neeraj Varma wrote: > > > > > > Yes, S3 does have the DCI. And 2E and S3 are not pin compatible. S3 > supports > > > 23 I/o standards as compared to 19 in S2E. > > > > That in itself does not make them pin incompatible. That would just be > > additional features inside the chip. I don't think the OP meant pin > > compatible in the sense of using the same bit stream. I know when I > > look for pin compatible in an FPGA, I just figure I can solder the chip > > in the same footprint and have it work. I fully expect to have to > > generate a new bit stream. > > > > The data sheets can be downloaded. I found differences in the JTAG, > > VCCINT and GND signals, so I would say they are not very pin compatible > > if at all. I haven't bothered to look, but considering that the I/O is staggered on the die, I'd put money on the I/O banks not lining up with older parts, in addition to power and ground pins being in different locations as you've outlined. Have fun, MarcArticle: 54717
On Wed, 16 Apr 2003 08:37:09 -0700, KB wrote: > On Wed, 16 Apr 2003 00:40:46 -0400, rickman <spamgoeshere4@yahoo.com> > wrote: >> >>They only issue I see with BGAs is the requirement for hot air soldering >>with BGA while a flatpack can be iron soldered. But you can do hot air >>soldering with an inexpensive rework station. > > In my experience it has not been this simple. I had a multi-thousand > dollar hot air system here for a while ... I will not do bga's again in > house until I also have the xray equipment to properly QC the bga > soldering ... and unfortunately that equipment isn't exactly in my > budget. Hey I've done many 388 and 516 pin BGAs proto cards with nothing but a lot of flux and a $79.00 Granger hot air gun, Never had an unsoldered pin though I have occasionally had shorts. The shorts were easy to spot by sighting along the rows of balls under the BGA (Using a bright light and looking edge on) Its not that hard, certainly not a whole lot harder than QFPs Now I wouldn't solder a really large or expensive chip this way, but FP256's should be a piece of cake... PCWArticle: 54718
Rajeev, The size matters not in the peak, but in the duration (please no jokes!). Whereas a Virtex 2000E may take (if available) X amperes for 3 ms, a 2S50E may take X amps for 20us. It matters little if the supply trips at X-.1 amps. That is why xapp158 says that if you have a supply that trips or folds back, delay the trip or fold back by 20 ms, and everyone is happy. Your point #1 below is excellent: you got it. It is so tough to explain what you did so well. Thank you. As for slew rate: there is hardly any variation with slew rate over thousands of parts, and all operating conditions. There may be some variation with a single part, or a lot, which leads people to think that some ramps are better than others (they are not). But we do test all parts (100%) at slightly faster than 100us, and at 50 ms to be sure that they all power on and configure properly. If you want to use them outside of the spec, we can't guarantee it. One thing does happen when you have 300 million transistors on an IC: you can't read the CMOS Blue Book* and understand what the hell is happening anymore. Austin *CMOS Circuit Design, Layout, and Simulation, Baker & Boyce Rajeev wrote: > Hello again, > > I guess I'm still confused by a couple of things... > > [1] I can see a power supply aspect to the problem, wherein the load > line crosses the I-V characteristic in two places, call them "normal > operation" and "current-limit", and the system can get stuck in the > current-limit. But I can't quite reconcile this with a slew rate > limit. Specifically, if I have a power supply which can source a > million Amps at any voltage, but has a rise time of a day, will there > be a problem ? Why ? Maybe I need to go and study more about CMOS > gates... > > [2] The Spartan-II datasheet (Module 3: DC and Switching > page 3) > shows the startup current requirement _with_no_reference_ to the > device size... you'd think there'd be _some_ difference between a > 2S15 and a 2S200, surely a 2S15 application shouldn't be required to > design in a 2S200-rated power supply ? > > Regards, > -rajeev- > ----------------- > Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3E9B2C2A.A85@designtools.co.nz>... > > rickman wrote: > > > > > > Rajeev wrote: > > > > > <...> > > > > > > > > Can somebody shed light on why power-up waveforms matter ? I mean, one > > > > might (naively ?) imagine that things would be OK so long as all the > > > > voltages settle down before configuration starts... > > > > <...> > > The mechanism is quite simple: you have a sea of complementary fets, > > and > > as Vcc ramps, the Gate capacitance is going to ramp Vg at appx 50% of > > Vcc. > > At the point where the FETS just start to conduct, and so are able to > > drive > > their LOAD gates, you are going to get small, but finite currents thru > > a very large number of devices, hence the AMPS order of init current @ > > 0.7V Vcc > > > > Sometimes 0.7V is inside the foldback of a linear regulator, and not > > many > > data sheets plot Io/Vo. > > > > What needs to be watched, is that there is a slew-threshold, and if you > > do NOT > > give it 'a hard enough kick', it will NOT cross the linear threshold, > > and > > stays there for ever - so it is not a simple charge model, of a single > > FET. > > If it were, half the current for twice as long would be fine. > > > > - jgArticle: 54719
Hi Fredrik, I know that it supports at least one member from each architecture. I was a rhetoric questions. In the website there is 3 "peripherals" that is pure software which would leave 35 peripherals. If I go to Altera website, I can count to 9 peripherals but they bundle in memory controllers under one line. The point was that it was stated that Microblaze was shipped with less number of peripherals than NIOS but the truth is the opposite. If you want to buy using ONE box and bill, go to avnet,memec,nuhurizon or nohau and they bundle the EDK kit with their boards. They usually sell kit for less than $995. Göran Fredrik wrote: > Hi Goran, > First of my 0.2$ shouldn't you know if Webpack ISE supports all > familys? But that is beside the point. > However you claiming that the 40 perhiperals is include with EDK it is > acctually 38 (quick count on Xilinx homepage), this number is by your > own addmittans far more than Altera is shipping with Nios (could be > since there is only 18 free peripheral in the SOPC builder). But you > are missing a fair amount of addons that Xilinx is counting as > peripheral and Altera is not (bsp for instans). For the dev kit itself > you also have a lot of peripherals onboard (it is my guess this is > what Jim is refering to) Stuff like this acctually speed up once > development quickly. > > I also see a lot of similarities between Microblaze and Nios, since I > am somewhat biased towards Altera solutions I would say that the big > advantage with Nios compared to Microblaz is the fact that when buy a > Nios-kit you get everything you need in ONE box (and one bill) you > just have to add power (not the cord, it is included). > Cheers > Fredrik > > Goran Bilski <Goran.Bilski@Xilinx.com> wrote in message news:<3E9C9779.F1D0FF89@Xilinx.com>... > > Hi Jim, > > > > I'm just interested on how MicroBlaze compares against NIOS. > > > > So what family is not supported in Webpack ISE? > > I think that there is a least one member from each family in Webpack. > > > > Xilinx EDK tool cost $495 and includes 40 peripherals which is far more than Altera is shipping in > > their NIOS kit. > > You can buy the EDK and a board from other vendors for a total less than $995. > > > > MicroBlaze is also shipped free with each EDK and there is no royalty and license required. > > MicroBlaze is not any different than NIOS in that respect. > > > > MicroBlaze fulfill all your requirements that you had for choosing NIOS. > > > > If you're still interested, I can create your system on MicroBlaze and you can do the comparison. > > > > Göran > > > > "Jim M." wrote: > > > > > Goran, > > > > > > I mentioned that I had mixed feelings then went on to only convey the > > > negative ones. Not the best move on my part. > > > > > > I don't really want to open up a Xilinx vs. Altera debate. > > > > > > One of the big reasons I went with Altera is that they support all of > > > their devices in the free versions of their software. What I mean by > > > 'all' is that each family has at least one device supported. Event > > > the Excalibur family with ARM processor. > > > > > > Their dev kits come with a device and are generally less expensive > > > with more peripherals. > > > > > > In addition the NIOS soft core is provided free with any NIOS dev-kit > > > (with software tools) and it's royalty free for re-use... this is a > > > big deal. > > > > > > Those were some of the factors in my decision to go with Altera. > > > > > > I'm very interested in hearing from other NIOS users on their > > > experiences. > > > > > > Goran Bilski <Goran.Bilski@Xilinx.com> wrote in message news:<3E9B1F99.17B9B1C5@Xilinx.com>... > > > > Hi Jim, > > > > > > > > If you can give the overview picture of your system, I could then create a > > > > similar system using MicroBlaze. > > > > This will give you something to compare against. > > > > > > > > Göran Bilski > > > > > > > > "Jim M." wrote: > > > > > > > > > I recently purchased a NIOS Stratix 1S10 Development Kit from Altera > > > > > and have mixed feelings about Quartus, SOPC Builder, and the NIOS > > > > > Core. (For those poor souls interested, I've included some comments > > > > > at the end of this post... feel free to provide feedback.) > > > > > > > > > > However, here's my question: > > > > > > > > > > What's the maximum clock frequency anyone has achieved using the NIOS > > > > > 3.0 CPU in 32bit mode with the standard peripherals (SRAM, SDRAM, > > > > > Ethernet, PIO, UART, etc. as in the Reference Design provided by > > > > > Altera)? > > > > > > > > > > I've tried isolating the various components into LogicLock regions. > > > > > I've tried different fitter/netlist optimizations. The maximum Fmax I > > > > > have achieved to date is 80 MHz. This is after letting Quartus "fit" > > > > > for 10 hours... it actually didn't stop, I had to abort the fitting > > > > > and refit to finially get an interim result (see other misc comments > > > > > below). > > > > > > > > > > Altera advertises 125 MHz for the Stratix Device and NIOS 3.0... > > > > > However a reference design that builds at that clock rate is not > > > > > provided. It appears that Altera gives you just enough to get your > > > > > feet wet... anything above and beyond that is Intellectual Property > > > > > that you need to buy. > > > > > > > > > > Other Observations/Comments: > > > > > > > > > > 1. The Quartus II SP1 software is extremely flakey. I've generated > > > > > numerous faults when deleting/modifying child LogicLock Regions. It > > > > > also takes forever to fit my Stratix design which is only 6000 LEs. > > > > > If I select the "limit fitting attempts to 1" option, Quartus > > > > > sometimes fits many times (like forever...) why?!?!? Also, after a > > > > > design is finished building, the software sits around for up to 5 > > > > > minutes before it generates a "finished" dialog box. I'm not sure > > > > > what's going on between the Quartus Application thread and the Quartus > > > > > Compiler thread, but it's fustrating enough just waiting for the > > > > > design to build, let alone waiting for Quartus to figure out the build > > > > > is done. I could go on and on, and that's only the result of 4 weeks > > > > > of effort with a small design. I feel sorry for those folks working > > > > > on a 100,000+ gate design. I guess modularity is the key there. > > > > > > > > > > 2. I can't simulate designs with virtual pins. I get warning during > > > > > the analysis of the simulation and then receive results with all input > > > > > pins a zero and output pins undefined. In addition, I can generate > > > > > hold time warnings during simulation for a design that didn't compile > > > > > with any hold time warnings. I'm not talking about hold time warnings > > > > > on my input signals, I'm talking about hold time warnings on internal > > > > > registers in my verilog code. Registers that I've taken care to hold > > > > > for 1 or more clock cycles before using in other parts of the design. > > > > > Again, the compilation of the design did not generate hold time > > > > > warnings... only the simulation of the design. > > > > > > > > > > 3. PLLs generate different timing analysis results. THIS IS VERY > > > > > ANNOYING! When I build up a "black-bock" design with virtual pins I > > > > > obtain a Fmax calculation from the timing analysis routine. I then > > > > > LogicLock the design and export it. When I import the design into a > > > > > new project and clock it using a PLL it generates negative slack time > > > > > warnings! If I remove the PLL and replace it with a clock pin, I get > > > > > the Fmax result that I obtained during the "black box" design. I beat > > > > > myself up for a week trying to debug a design that wasn't broken > > > > > because of this goofy behavior in Quartus. I'm still not sure if the > > > > > slack time warning it legit and wether I should be concerned about it. > > > > > > > > > > 4. SOPC Builder will lock itself up if you double-click components > > > > > before selecting them. Give it a try... double click a component line > > > > > in your NIOS design before selecting the line item. After a couple > > > > > times the SOPC builder application creeps to a halt. > > > > > > > > > > 5. Documentation on the various megafunctions is lacking. A good > > > > > example is the altsyncram megafunction. It doesn't state any timing > > > > > requirements on the input registers, enable, and clock signals. Do I > > > > > hold the data 1 cycle before flipping the write enable? How about > > > > > holding the write enable before de-activating it? Why is the > > > > > addressing based upon the data bit-width? Trying to tie a 32-bit > > > > > altsyncram block to a NIOS CPU is difficult because you need to > > > > > specify the address space of the peripheral and the address space of > > > > > the altsyncram block is based upon the bit width (not the number of > > > > > bytes). > > > > > > > > > > 6. I have yet to get a Leonaro-Spectrum synthesized Verilog file to > > > > > build in Quartus. I can used Spectrum generated .edf files but not > > > > > verilog. I get LCELL parameter errors. Unfortunately, Altera can't > > > > > seem to duplicate this... anyone else see this behavior? I'm not sure > > > > > if Spectrum synthesizes Verilog better that Quartus, but it definitely > > > > > does it faster. > > > > > > > > > > Feedback is welcome... even if it's the "you're an idiot and here's > > > > > why" variety...Article: 54720
Neeraj Varma wrote: > > Agree with you. Drop-in replacement with different bitstream is the > question, obviously. > > I have never seen two different families with pin-compatibility within the > same package, and there are both technical as well as business reasons, I > presume. Even if Vcc, Gnd pins are tried to kept same, there would always be > voltage level changes due to different process geometries which will make > board changes inevitable. So why not take the fullest advantage of the new > family features? "Why" is pin comnpatibility desired? That is an easy one. To allow a wide range of choices in product lines. You can put a 1 Mbit or a 128 Mbit Flash part in the same socket with no need to use a more expensive than the application requires. The same with SRAM and DRAM. Even MCUs are often pin compatible between a $1 part and a $5 part. In the same way it can be very useful to be able to sell a product with a $15 Spartan-x FPGA or to be able to "pump up the volume" and use a multi-million gate Virtex-y part. I belive this is possible with the Virtex and Spartan II parts. But when they moved to the Virtex E and the Spartan IIE, they made a few subtle changes to the pin out which make them incompatible. I did not see a way to use them in the same socket. Seems the Virtex II and the Spartan 3 are pin incompatible as well. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54721
KB wrote: > > On Wed, 16 Apr 2003 00:40:46 -0400, rickman <spamgoeshere4@yahoo.com> > wrote: > > > >They only issue I see with BGAs is the requirement for hot air soldering > >with BGA while a flatpack can be iron soldered. But you can do hot air > >soldering with an inexpensive rework station. > > In my experience it has not been this simple. I had a multi-thousand > dollar hot air system here for a while ... I will not do bga's again > in house until I also have the xray equipment to properly QC the bga > soldering ... and unfortunately that equipment isn't exactly in my > budget. I recently saw a new product announcement for an *optical* BGA inspection device. It looks like they use fiberoptics to slip the head *under* the BGA. They are selling "From $3000". Company is ASG in Cleveland, OH 216-486-6163, www.asg-jergens.com. I'm glad you brought that up. I wanted to check this out and it had slipped out of my "to-do" list. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54722
On Wed, 16 Apr 2003 08:05:24 -0700, Peter Wallace <pcw@karpy.com> wrote: >On Wed, 16 Apr 2003 08:37:09 -0700, KB wrote: > >> On Wed, 16 Apr 2003 00:40:46 -0400, rickman <spamgoeshere4@yahoo.com> >> wrote: >>> >>>They only issue I see with BGAs is the requirement for hot air soldering >>>with BGA while a flatpack can be iron soldered. But you can do hot air >>>soldering with an inexpensive rework station. >> >> In my experience it has not been this simple. I had a multi-thousand >> dollar hot air system here for a while ... I will not do bga's again in >> house until I also have the xray equipment to properly QC the bga >> soldering ... and unfortunately that equipment isn't exactly in my >> budget. > >Hey I've done many 388 and 516 pin BGAs proto cards with nothing but a lot >of flux and a $79.00 Granger hot air gun, Never had an unsoldered pin though >I have occasionally had shorts. The shorts were easy to spot by sighting along >the rows of balls under the BGA (Using a bright light and looking edge >on) Its not that hard, certainly not a whole lot harder than QFPs > >Now I wouldn't solder a really large or expensive chip this way, but FP256's >should be a piece of cake... > >PCW interesting .. could you describe your technique further ? did you put down solder paste ? did you hold the chip in position or let it free float ? etc. when you had a short did you remove the chip and try again ... I assume they would have to be reballed .... thanks KBArticle: 54723
Unfortunately, Spartan-3 devices are not pin compatible with Spartan-IIE or Virtex-II families. The good news is that there is _full_ compatibility within the Spartan-3 family. We adopted the common-footprint mentality from the memory manufacturers. For each supported package type, there is a single pin-compatible footprint for all density devices offered in that package. For example, in the 256-ball BGA package, there are three different Spartan-3 FPGAs offering a 5X density range--all with the identical footprint. Module 4 of the Spartan-3 data sheet shows details, package by package. Any differences are highlighted. Smaller devices may have unconnected pins (N.C.) where the larger devices have an I/O pin. Migrating upwards always results in the same number or greater number of I/Os. You never lose I/Os by migrating upwards like you do in some other technologies. Spartan-3 FPGA Pinout Tables [872 KB] http://direct.xilinx.com/bvdocs/publications/ds099-4.pdf Okay, so why didn't we make Spartan-3 compatible with Spartan-IIE or Virtex-II? Like Virtex-II, Spartan-3 has three possible power supply inputs. Spartan-IIE does not have the VCCAUX supply. If we designed a backwards compatible footprint with Spartan-IIE, then you could never operate the Spartan-3 I/Os at anything other than 2.5V. Spartan-3 has a different footprint than Virtex-II because both use a different die-bonding technology. Virtex-II uses a higher-performance flip-chip technology. Spartan-3 uses a lower-cost pad ring. Having the freedom to create a new footprint also allowed us to maximize the number of single-ended and differential I/O for each package. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE, Spartan/XL FPGAs E-mail: steve.knapp@xilinx.com --------------------------------- Paul Szczesny wrote: > > Does anybody know if Spartan3 devices will be pin compatible with Spatan 2E? > Thanks --Article: 54724
These are the tough decisions decided by marketing people. :-) Personally, I liked the idea of a Spartan-Ayeyaiyai! Tim wrote: > > Steve Knapp wrote > > --------------------------------- > > Steven K. Knapp > > Spartan-3/II/IIE FPGAs > > --------------------------------- > > Why Spartan-3, not Spartan-III? -- --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE, Spartan/XL FPGAs E-mail: steve.knapp@xilinx.com ---------------------------------
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