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
i think this is a VARIABLE parameter, and it's a function of fractional frequency synthesis M/N, temperature, input jitter ,etc... "al82" <yscdi62k001@sneakemail.com> wrote in message news:1118146996.993258.79830@g43g2000cwa.googlegroups.com... > Can anyone tell me which is the phase delay between input and > output(CLKFX) when there is no feedback (Input frequency less than > 24MHz) > > Thanks >Article: 85301
There are two ways to do this: (1) Use DCM with CLKFX output, DO NOT USE DLL outputs, as they limit you to 24 MHz. (2) There is a nice circuit which doubles any frequency using a delay buffer + XOR. If you REALLY want to go for it (it's working, but ...), just say it. Hope this helps. Vladislav "methi" <gmethi@gmail.com> wrote in message news:1118085861.383732.169030@g14g2000cwa.googlegroups.com... > Hi, > > I need to double an input clk of 13.5mhz to 27 mhz...but the DCM core > in xilinx can take frequencies from 24 Mhz and up only... > > On going through some of the posts, this is the idea that I have come > across: > > Give my input clk to one input of the XOR gate. > > Delay my input clk with a series of inverters and give it as the second > input of the XOR gate.. > > Would this work? > > Thank you, > > Methi >Article: 85302
"Paul Smith" <ptsmith@nospam.indiana.edu> schrieb im Newsbeitrag news:d84q4e$uga$1@rainier.uits.indiana.edu... > Hi, > > I need to add a pair of 8 bit (unsigned) integers to get a 9 bit > (unsigned) result at 250 MHz, preferably in an XC3S50-4. > > Using the Coregen adder/subtractor V7 with maximum pipelining (9) and > RPM on, the best cycle time I can get is 4.55 ns. At each pipeline > level the critical path is a LUT, a MUXCY, and another LUT. > > Can anyone point me at some hints for a faster implementation (besides > going to a faster part? > > TIA > > Paul Smith > Indiana University Physics solution (one possibility) is simple do it 2 times in parallel and demux the output results back into one stream then the addition works on 125MHz and the demux should be single LUT so it works on 250 without problems :) antti3centsArticle: 85303
as simple as this: ALWAYS use Verilog/VHDL NEVER use schematic capture those who come from ASIC/FPGA world would probably agree. but honestly, the only place where you might use schematic capture would be a small, very well defined project with knowing that the flexible design & fast design time is not an issue. yet the speed of the design process + its integrability with some other people like me, who really hate schematic capture, because the warnings generated during synthesis are annoying and i most cases cannot be avoided. Vladislav <learnfpga@gmail.com> wrote in message news:1118084694.279439.98850@g43g2000cwa.googlegroups.com... >I had a question about the latest happening in this market. Since I am > new in this area excuse me in advance if the question sounds > stupid.(:-. What is trend for programming devices now a days. I mean > are people using VHDL/Verilog more and more for design or they use > design tools such as Orcad etc. What is better off the two. What are > the pro/cons of using VHDL/Verilog in comparision to schematic capture. > Thanks >Article: 85304
On Mon, 06 Jun 2005 10:01:02 -0700, Fred wrote: > 14 week lead time for samples for the XC3S200. How can you prototype > with that? > > It makes worry even more when it comes to manufacture where I might need > quantity. If you want to pay shipping I've got 4 XC3S400-PQ208 engineering samples (ony minor bugs should not affect most applications) You can have for just cost of shipping. These are pin compatible with the XC3S200 so should work on your proto Peter WallaceArticle: 85305
(1) try using timing driven packing and placement, it might help. (2) if you can pipeline the result, i.e. just add one more sample, this would solve a problem. but try using high level code, but core generator. (3) split the addition into two parallel ones at 1/2 frequency, and multiplex them at full frequency take also a look how much % of the delay is contributed by routing :o( Hope this helps Vladislav "Paul Smith" <ptsmith@nospam.indiana.edu> wrote in message news:d84q4e$uga$1@rainier.uits.indiana.edu... > Hi, > > I need to add a pair of 8 bit (unsigned) integers to get a 9 bit > (unsigned) result at 250 MHz, preferably in an XC3S50-4. > > Using the Coregen adder/subtractor V7 with maximum pipelining (9) and RPM > on, the best cycle time I can get is 4.55 ns. At each pipeline level the > critical path is a LUT, a MUXCY, and another LUT. > > Can anyone point me at some hints for a faster implementation (besides > going to a faster part? > > TIA > > Paul Smith > Indiana University PhysicsArticle: 85306
The seminar was a nice follow-up to the previous one and I thought was well done. I'd like to see a future seminar dealing in more detail with board layout issues that affect signal integrity. John ProvidenzaArticle: 85307
The trouble is probably your second LUT. The first LUT feeds the S input of the carry chain, yes? This would be the LUT attached directly to the carry chain. The second LUT means - for reasons unknown to us - the result is going through additional logic. It's this logic that needs to be tweaked a little. Since it didn't pass through an XORCY I'm guessing this is the carry-out of the 8-bit adder? Look at what else feeds the LUT and try to determine why the synthesizer wants to add logic to the adder's OUTPUT rather than in the 4-input LUT. "Paul Smith" <ptsmith@nospam.indiana.edu> wrote in message news:d84q4e$uga$1@rainier.uits.indiana.edu... > Hi, > > I need to add a pair of 8 bit (unsigned) integers to get a 9 bit > (unsigned) result at 250 MHz, preferably in an XC3S50-4. > > Using the Coregen adder/subtractor V7 with maximum pipelining (9) and > RPM on, the best cycle time I can get is 4.55 ns. At each pipeline > level the critical path is a LUT, a MUXCY, and another LUT. > > Can anyone point me at some hints for a faster implementation (besides > going to a faster part? > > TIA > > Paul Smith > Indiana University PhysicsArticle: 85308
Thank you for your reply, I did finally find this information.Article: 85309
I am trying to figure out what version of GCC the mb -gcc is based on. This will tell me if I can use anonymous structures with the Microblaze compiler. Any ideas? JWArticle: 85310
Antti Lukats wrote: > Hi > > some info from the Lattice roadshow seminar at Mentor > > 1) 0.9 and 0.65 !? products are coming... You mean 90nm and 65nm ? > 2) new FPGA products to be exptected (when you are back from sommer > vaccation..) that goes for new FPGA products (not low end), not just some > new device/derivate of existing things > 3) something new is coming to the PLD offering as well (same timeline as > above?) No hints on pin counts and resource ? [A MAXII ~clone with RAM would be nice :) ] > 4) serdes 2.5G+ will be included in some of the new devices > 5) Lattice has completly solved the NBTI (and other submicron) issues (as > much as I understood it means all the V4 NBTI like issues, things why xilinx > is not shipping V4 silicon with working MGTs and why Stratix IIGX is > delayed) are solved Fujitsu are the ones who would do the solving, not Lattice, and I would suspect anyone's "completely solved" claim, until proven by time... > 6) EC family pricing can meed the S3 pricing in all cases where xilinx is > not dumping on the high volumes > 7) ECP and XP prices are EC+10% > > please dont take those above as some official announcements, its only the > answers I got ;) and possible my interpretation what may not be entirely > accurate On the topic of news, ST have their second member roll out on this family : http://www.st.com/stonline/press/news/year2005/p1613h.htm & http://www.st.com/stonline/books/pdf/docs/11335.pdf With a claimed 'volume' price of ~$30, and the raw MIPS performance and resources, it has the potential to shake the FPGA tree. Similar in concept to the uPSD, [uC.ADC.PLD.Memory] but monstered up with 300MHz ARM9, 600MHz Dual MAX DSP, 200MHZ FPGA, & OnChip DRAM, plus peripherals FPGA users can only dream about. They still call this a MicroController :) Success will depend on the device errata, how solid the tools are, and their ability to ship - [as other FPGA vendors are finding...?] -jgArticle: 85311
On 6 Jun 2005 13:26:56 -0700, Eric wrote: >What is the best FREE Schematic & PCB Layout software available that >will run on Windoze XP? > >I've looked at PCB123.com and Expresspcb.com and they have pretty good >programs available. Unfortunately if I use either one I'm stuck getting >the prototypes through them. (Because they won't output Gerbers) > >I've also looked at Eagle Layout at cadsoft.de, but the size limitation >of 100 x 80mm on the free version is a negative. It would work for my >current project. > >I'm just curious at what other people's opinions are. I'm quite happy with Eagle (also on Linux). Don't underestimate the value of a big component library and how important it is that you can create your own components easily. For non-profit, there's a non-free but cheap version of Eagle which will do full eurocard format (100x160). Eagle is also extensible my user programs, there is such an 'ULP' to export to spice for simulation by e.g. SwitchCadIII (I've never tried that though). Mat NieuwenhovenArticle: 85312
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:42a5f953$1@clear.net.nz... > Antti Lukats wrote: > > Hi > > > > some info from the Lattice roadshow seminar at Mentor > > > > 1) 0.9 and 0.65 !? products are coming... > > You mean 90nm and 65nm ? yes > > 2) new FPGA products to be exptected (when you are back from sommer > > vaccation..) that goes for new FPGA products (not low end), not just some > > new device/derivate of existing things > > 3) something new is coming to the PLD offering as well (same timeline as > > above?) > > No hints on pin counts and resource ? no, but I think they have also recognized that CSP and QFN packages are nice, but no info if/when products in CSP will be available > [A MAXII ~clone with RAM would be nice :) ] not sure, what it will be, but yes Lattice thinks as well that missing ram in MAX2 is a BIG MISTAKE, almost as big as having the RAM not initializeable in PA3 ! > > 4) serdes 2.5G+ will be included in some of the new devices > > 5) Lattice has completly solved the NBTI (and other submicron) issues (as > > much as I understood it means all the V4 NBTI like issues, things why xilinx > > is not shipping V4 silicon with working MGTs and why Stratix IIGX is > > delayed) are solved > > Fujitsu are the ones who would do the solving, not Lattice, and I would > suspect anyone's "completely solved" claim, until proven by time... sure actually that what they meant, that F has solved the issues, eg whatever issues they think there are > > 6) EC family pricing can meed the S3 pricing in all cases where xilinx is > > not dumping on the high volumes > > 7) ECP and XP prices are EC+10% > > > > please dont take those above as some official announcements, its only the > > answers I got ;) and possible my interpretation what may not be entirely > > accurate > > On the topic of news, ST have their second member roll out on this family : > > http://www.st.com/stonline/press/news/year2005/p1613h.htm > & > http://www.st.com/stonline/books/pdf/docs/11335.pdf > > With a claimed 'volume' price of ~$30, and the raw MIPS performance and > resources, it has the potential to shake the FPGA tree. > > Similar in concept to the uPSD, [uC.ADC.PLD.Memory] but monstered up > with 300MHz ARM9, 600MHz Dual MAX DSP, 200MHZ FPGA, & OnChip DRAM, > plus peripherals FPGA users can only dream about. > They still call this a MicroController :) > > Success will depend on the device errata, how solid the tools are, and > their ability to ship - [as other FPGA vendors are finding...?] > > -jg > WAU!! I want that starterkit NOW !! 1MS/S ADC!, real DAC and hei they even have POR detect on that chip, I would not have even dreamed of that in such monster, the small things are usually forgotten AnttiArticle: 85313
John, Indeed, layout is important. Like put the ground plane as close as possible to the BGA rather than on the otherside of the board to make the Altera parts look unusable. Don't get me wrong, the Xilinx BGA pin layout is superior to the Altera one in terms of SI. However, by using a more realistic stackup, I would suggest the problems are not as pronounced as in today's demo. Also, in the original demo, http://www.xilinx.com/products/virtex4/pdfs/BGA_Crosstalk.pdf , I would question whether the PCB was laid out optimally, or in such a way as to accentuate the problem. Long and adjacent traces far from a ground plane would do this. There's no picture of the stackup or layout in the demo document. >From the first demo, the conclusion is :- The Altera package suffers from two issues: 1.. . Excessively fast signal rise/fall time 2.. . Over-concentration of power/ground balls in core region I'd argue that 1) isn't a problem; fast rise time is good, as long as you know what you're doing. (BTW Xilinx can't compete on risetime because of their 12.5pF pin capacitance.) Now, 2) could be a SI problem, for which the Xilinx package is a solution, but I question whether the data presented are a realistic 'real world' set up. If they are, no-one would be able to drive DDR ram from an Altera part. On the other hand, 2) could be better in terms of signal routing, the traces from the centre of the Altera package don't have to negotiate a lot of power and ground vias as they fan out from the device. In conclusion, I think the Xilinx BGA layout is a good thing. Well done. But, I don't believe the Altera parts have to be as bad as they appear in these demos. And, for differential signals, for which the Altera parts are much better (see above comment about pin capacitance), the BGA layout makes bugger all difference. Cheers, Syms. p.s. Thanks to Xilinx for these seminars; it shows the subject is being taken seriously. "johnp" <johnp3+nospam@probo.com> wrote in message news:1118171841.280608.167380@o13g2000cwo.googlegroups.com... > The seminar was a nice follow-up to the previous one and I thought was > well done. I'd like to see a future seminar dealing in more detail > with board layout issues that affect signal integrity. > > John Providenza >Article: 85314
"c d saunter" <christopher.saunter@durham.ac.uk> schrieb im Newsbeitrag news:d84pvd$5pu$1@heffalump.dur.ac.uk... > Bubble sort should actually be quite fast - you can store all 48 values in > registers, then compare and swap if necessary odd pairs on odd clock cycles > and even pairs on even cycles. After 48 cycles the registers should hold > a sorted data set. This sounds like a almost full parallel approach. Could be quite fast, but also quite resouce hungry. > Probably this aproach is about as fast as you can get? The speedup comes > from the fact that many many bubble sort opperations can occour in > parallel. Is this the most hardware efficient sort that runs at this speed > though? > > If possible data should be shifted sequentially into and out of (or at least > out of) the registers as a readout mux would be a resource hog. Using a Thats why a BRAM is quite handy. Using both ports you can pull two datas out in one cycle, compare, and write them back on a second cycle. Regards FalkArticle: 85315
Better use external transistor / Fet as multiple pin can get all burned due to the fact that they do not open and close at the same exact moment and the first to open theoretically will need to drive for some period the total current and this get repeated over and over until ... Of course if the current ramp slow enough multiple IO can be solution though myself I would stick with one IO and transistor / Fet. Have funArticle: 85316
Nah, I think the I/Os are safe even if they're shorted to ground or Vcco. Use the IOB FFs to be on the safe side! Cheers, Syms. "Berty" <wooster.berty@gmail.com> wrote in message news:1118178964.986594.252320@f14g2000cwb.googlegroups.com... > Better use external transistor / Fet as multiple pin can get all burned > due to the fact that they do not open and close at the same exact > moment and the first to open theoretically will need to drive for some > period the total current and this get repeated over and over until ... > > Of course if the current ramp slow enough multiple IO can be solution > though myself I would stick with one IO and transistor / Fet. > > Have fun >Article: 85317
This maybe an issue with the constraints listed in the UCF file. iSE 7.1 incorrectly interprets "NET-PERIOD" constraints when applied to designs assembled from multiple NGC files. Unfortunate, as this is the design assembly method of EDK. If you have a UCF constraint of the following format: NET sys_clk PERIOD = 10 ns; Replace with the following TIMESPEC "TS_sys_clk" = PERIOD "sys_clk_grp" 10 ns; NET sys_clk TNM_NET=sys_clk_grp; Also, you may want to also change the effort level of "-ol std" to "-ol high". This can be modified in the <proj>/etc/fast_runtime.opt Big Boy wrote: > I tried both ISE/EDK 7.1 and 6.3 (all with latest service pack, but > tested very quicly), and I'm having some problems with 7.1. For > example, a Microblaze design that fit in 6.3 doesn't fit as tight in > 7.1. Moreover, I'm using Spartan-3 (FG456, speed: -4) with 66.6MHz > clock, and I can't meet the timing requirement in 7.1, while 6.3 meet > it. Moreover, for the same design, 6.3 give 6 level of logic in the > critical path, while 7.1 give 9 levels. > > Also, with 7.1, when doing synthesis, I get a lot of warnings, like > 'Packer: ... can not be packed with the carry due to conflict ...'. > Some other warnings too. With 6.3, no such warnings. > > I'm currently testing on a workstation with 6.3, and I'll verify if > some of the other issues I was having are there or not. > > Anyone having bad experience with 7.1? > -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 85318
"Paul Smith" <ptsmith@nospam.indiana.edu> schrieb im Newsbeitrag
news:d84q4e$uga$1@rainier.uits.indiana.edu...
> I need to add a pair of 8 bit (unsigned) integers to get a 9 bit
> (unsigned) result at 250 MHz, preferably in an XC3S50-4.
>
> Using the Coregen adder/subtractor V7 with maximum pipelining (9) and
> RPM on, the best cycle time I can get is 4.55 ns. At each pipeline
> level the critical path is a LUT, a MUXCY, and another LUT.
Hmm, strange. a 8 bit adder should fit into one level of logic. make sure
both inputs are registered and placed correctly (close to the carry chain).
The output should be registerd too, of course ;-)
OK, I did a quick test using Webpack 7.1.
A plain description reaches 3.995 ns, uhhh tight timing ;-)
Looking at the floorplanner (after P&R) I see the mess.The registers for my
inputs are placed inside the IOBs. Not bad in general, but bad here, where
we need every fraction of a ns. So I disable the option for placing the
registers into the IOBs and run again.
BINGO! 3.5ns.
But the automatic P&R tools are lazy bastards. A look at the floorplanner
reveals, that the input registers are spread over the chip. OK, handmade is
handmade. We add some LOCs into the UCF. New run.
3.49 ns. Hmm, not too much improvement, but since the placement is fixed
this should be reliable.
See the files below.
Njoy.
Falk
-- VHDL
----------------------------------------------------------------------------
----
-- Company:
-- Engineer:
--
-- Create Date: 23:08:28 06/07/05
-- Design Name:
-- Module Name: top_adder - Behavioral
-- Project Name:
-- Target Device:
-- Tool versions:
-- Description:
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------
----
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity top_adder is
Port ( clk : in std_logic;
a : in std_logic_vector(7 downto 0);
b : in std_logic_vector(7 downto 0);
c : out std_logic_vector(8 downto 0));
end top_adder;
architecture Behavioral of top_adder is
signal a_int, b_int : std_logic_vector(7 downto 0);
signal c_int : std_logic_vector(8 downto 0);
begin
process(clk)
begin
if rising_edge(clk) then
a_int <= a;
b_int <= b;
c <= c_int;
c_int <= ('0' & a_int) + ('0' & b_int);
end if;
end process;
end Behavioral;
-- UCF
net clk period=3.5ns;
INST "c_int_0" LOC = "SLICE_X14Y4";
INST "c_int_1" LOC = "SLICE_X14Y4";
INST "c_int_2" LOC = "SLICE_X14Y5";
INST "c_int_3" LOC = "SLICE_X14Y5";
INST "c_int_4" LOC = "SLICE_X14Y6";
INST "c_int_5" LOC = "SLICE_X14Y6";
INST "c_int_6" LOC = "SLICE_X14Y7";
INST "c_int_7" LOC = "SLICE_X14Y7";
INST "c_int_8" LOC = "SLICE_X14Y8";
INST "a_int_0" LOC = "SLICE_X13Y4";
INST "a_int_1" LOC = "SLICE_X13Y4";
INST "a_int_2" LOC = "SLICE_X13Y5";
INST "a_int_3" LOC = "SLICE_X13Y5";
INST "a_int_4" LOC = "SLICE_X13Y6";
INST "a_int_5" LOC = "SLICE_X13Y6";
INST "a_int_6" LOC = "SLICE_X13Y7";
INST "a_int_7" LOC = "SLICE_X13Y7";
INST "b_int_0" LOC = "SLICE_X15Y4";
INST "b_int_1" LOC = "SLICE_X15Y4";
INST "b_int_2" LOC = "SLICE_X15Y5";
INST "b_int_3" LOC = "SLICE_X15Y5";
INST "b_int_4" LOC = "SLICE_X15Y6";
INST "b_int_5" LOC = "SLICE_X15Y6";
INST "b_int_6" LOC = "SLICE_X15Y7";
INST "b_int_7" LOC = "SLICE_X15Y7";
Article: 85319Falk Brunner (Falk.Brunner@gmx.de) wrote: : "c d saunter" <christopher.saunter@durham.ac.uk> schrieb im Newsbeitrag : news:d84pvd$5pu$1@heffalump.dur.ac.uk... : > Bubble sort should actually be quite fast - you can store all 48 values in : > registers, then compare and swap if necessary odd pairs on odd clock : cycles : > and even pairs on even cycles. After 48 cycles the registers should hold : > a sorted data set. : This sounds like a almost full parallel approach. Could be quite fast, but : also quite resouce hungry. Yup. Unless the OP posts some details about desired performance it's impossible to know which one is best... : Thats why a BRAM is quite handy. Using both ports you can pull two datas out : in one cycle, compare, and write them back on a second cycle. Indeed. There is a nice intermediate level of parallelism availible by using LUT RAMs to build units 16 words deep, each of which sort sequentially, with every other set of sorts crossing the LUT RAM boundaries. This would also be the most complicated case to code :-) cheers cdsArticle: 85320
Symon wrote: > John, > Indeed, layout is important. Like put the ground plane as close as possible > to the BGA rather than on the otherside of the board to make the Altera > parts look unusable. Don't get me wrong, the Xilinx BGA pin layout is > superior to the Altera one in terms of SI. However, by using a more > realistic stackup, I would suggest the problems are not as pronounced as in > today's demo. > Also, in the original demo, > http://www.xilinx.com/products/virtex4/pdfs/BGA_Crosstalk.pdf , I would > question whether the PCB was laid out optimally, or in such a way as to > accentuate the problem. Long and adjacent traces far from a ground plane > would do this. There's no picture of the stackup or layout in the demo > document. NOR any detail of the DIE bonding. The total path is what matters. Are these Xilinx devices flip-chip / direct bonded ? If so, they should clarify which other xilinx devices are not.... > From the first demo, the conclusion is :- > > The Altera package suffers from two issues: > > 1.. . Excessively fast signal rise/fall time For dI/dT, yes, but slower rise times make poorer eye diagrams... > > 2.. . Over-concentration of power/ground balls in core region > I'd argue that 1) isn't a problem; fast rise time is good, as long as you > know what you're doing. (BTW Xilinx can't compete on risetime because of > their 12.5pF pin capacitance.) Now, 2) could be a SI problem, for which the > Xilinx package is a solution, but I question whether the data presented are > a realistic 'real world' set up. If they are, no-one would be able to drive > DDR ram from an Altera part. Most logic interfaces do not try and clock at the same time as the address bus changes, so cross talk becomes mission-serious only onto the write line - and if you are silly enough to choose a WRN strobe, right on the most noisy pin, then you rather deserve to get bitten.... That said, there are other more analog situations where low system noise is a very good thing, and EMC tests would have been interesting. > On the other hand, 2) could be better in terms > of signal routing, the traces from the centre of the Altera package don't > have to negotiate a lot of power and ground vias as they fan out from the > device. > In conclusion, I think the Xilinx BGA layout is a good thing. Well done. > But, I don't believe the Altera parts have to be as bad as they appear in > these demos. Probably not in the real world.... The pdf says min 7" traces, and 500 aggressors - and I've never seen a real design come close to either number... Still, it is an educational test, and good to see simulations and physical correlations. Comment: The inductive nature of the cross talk, suggests some controlled capacitive crosstalk could actually help counteract/null this Has anyone actually tried that ? -jgArticle: 85321
Fred wrote: > Thanks for your offer but I need the pins. > > Xilinx have their buy online store but they only sell CPLDs there. A reply > to an email I sent to "online store" said talk to your distributor and sales > office which are things I had already done. I have searched in vain but > can't get any hint of sourcing samples off their website. Do you have any > links? Try mentioning this link, might hurry them along a bit... http://www.altera.com/buy/devices/buy-devices.html Xilinx only have CPLDs here : http://www.xilinx.com/xlnx/xebiz/onlinestore.jsp?sGlobalNavPick=PURCHASE and then, they do not have the new 32A and 64A, nor the MLF packages.... I did notice this line in the XC2C64 ?! listings XC3S200-4FT256C FT -4 256 Commercial $25.55 In Stock -jgArticle: 85322
Jim, we described Virtex-4, which is 100% flip-chip. This was not a history lesson on the older families, nor on TQ144 packages :-( Peter AlfkeArticle: 85323
mb-gcc --version -> 2.95.3-4 Xilinx EDK 6.3 Yes, it supports anonym structs. ZoleeArticle: 85324
This was a good, useful presentation, particularly the discussion on the utility of "soft grounds." But it did make me wonder this: with all of the concern about crosstalk, how many designers take the time to separate groups of mutually asynchronous signals when assigning the FPGA pinout? Most of us don't have the luxury of running everything at the same clock speed, and yet I've seen little or no mention of how beneficial it is to separate signals that run at different speeds. Maybe this idea is buried in the docs somewhere, but I've yet to see a single presentation from any vendor that suggests this. Perhaps this gets little play because it's obvious. But given the number of designs I've seen with I/O signals placed anywhere they'll fit, I think otherwise. Bob Perlman Cambrian Design Works
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