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
Jim, this was the first pre-announcement of something new from Xilinx. Don't complain that it is vague, it is meant to be. It's supposed to create interest, curiosity, perhaps even impatient excitement. Exactly what the company wants. We cannot yet offer this for sale, but we can create some expectations. As Austin said, wait for the next, more detailed disclosure. Any similarity with strip-tease is purely intentional... Peter ============================ Jim Granville wrote: > > "Austin Lesea" wrote > > Jim, > > > > Now really, Jim, why so negative? > > I did not think I was negative on the engineering aspects ? > - I listed more pluses than minuses :) ? > > > Isn't Xilinx justified in rolling out a new architecture with some > fanfare? > > Of course, but when the gush exceeds the hard data, expect some > analysts to get it wrong.... > > > Why is it that others are allowed > > to make outrageous and sometimes even false claims, and no one cares? > > Yet when we announce a truely revolutionary FPGA architecture, we get > > complaints? > > "truely revolutionary" is a bold claim. > > I can see good Engineering & Yield trade-offs in what's released so far, but > that's some way short of "truely revolutionary". > > > > > If we can architect a device to allow for any collection of "stripes" > > and have the mask, and the software ready immediately, isn't that worth > > shouting about? > > Can you clarify 'the mask' ? > Does this mean this will become like a block-hard-copy (but still FPGA), > where a large enough customer (/market?) can 'select the mix of stripes' > and a new die results ? > With real care, 'the mask' could even be effectively virtual by using > stripe based exposures at the wafer level. > > Challenge there will be in the definition, to get devices to reach critical > mass, and > not go EOL as uptakes do not quite meet forecasts. > > > More and more we see market specific applications that require a more > > cost effective FPGA (eg software defined radio is a totally different > > mix of features than automotive entertainment center). Why not be able > > to target a general purpose device to a specific market segment at > > reduced cost and better margins? Might get more business that way, > > right? If Spartan 3 is already cost effective against many ASICs, might > > this not make us even a better cost/benefit solution? > > So is this not a merchant market device, but an 'ASIC cherry pick' vehicle ? > > -jgArticle: 63951
Does anyone know why Xilinx' socket function library, xilsock.h, does not contain a xilsock_connect() function? Also, do you know how xilsock_accept() works? It appears to be non-blocking by default. Is this the case? At this moment, the client I have running on a windows PC is getting a WSACONNREFUSED error when it attempts to connect() to a socket on the V2Pro. The server on the V2Pro is spinning in a loop that executes xilsock_accept(). I've tried various port numbers and the connect error is the same. If you have any insight from just this info, please let me know. Also if you have the time and would like to see the code, I'd be happy to email it to you. Or I can probably post it here later. Thanks, JimArticle: 63952
"Peter Alfke" wrote > Jim, > this was the first pre-announcement of something new from Xilinx. Don't > complain that it is vague, it is meant to be. It's supposed to create > interest, curiosity, perhaps even impatient excitement. > Exactly what the company wants. We cannot yet offer this for sale, but > we can create some expectations. > As Austin said, wait for the next, more detailed disclosure. > Any similarity with strip-tease is purely intentional... Sounds like a new marketing manager fresh in from another industry.... ;-) Even the technical press have taken the slightly misleading "Xilinx Unveils Revolutionary..." and watered it down to the more accurate "Xilinx set to debut novel FPGA architecture" "..set to debut in a 90nm Virtex device in the first half of 2004, segments function blocks into interchangeable columns, rather than squares on a grid." -jgArticle: 63953
"John_H" <johnhandwork@mail.com> wrote in message news:<JQrBb.13$Y51.3456@news-west.eli.net>... > Every 4 CLBs, the horizontal tristate line has a pip, delivering the > partitioning you read about. Only one of the four horizontal lines has a > pip at each CLB column giving a staggered partitioning. Those lines can > also interface with the IOBs on the left and right side of the device. They Thanks, this is exactly what I wnated to know. > aren't "real" tristates in that if you drive a 1 and a 0 into the same line, > the chip doesn't complain with smoke and heat - it gives you the low logic > level. Yes, this info I've seen somewhere in the group archives. > FPGA Editor is in the 6.1 tools, but I understand it's not a WebPack item. > (I could be mistaken on this) Unfortunately it was the case - it was WebPack installed on this machine. I'll get access to full installation at university soon :) Thanks !Article: 63954
Hi Muthu, I don't believe you will find a script to do this. However, static property checkers like Averant's Solidify (www.averant.com) can autocheck for multicycle path violations. Regards, Hans. www.ht-lab.com "Muthu" <muthu_nano@yahoo.co.in> wrote in message news:28c66cd3.0312080539.703aff20@posting.google.com... > Hi, > > Is there any script kind of, which can scan the RTL files and list out > the Available Multicyle paths ? > > It is possible. Isn't it? > > Regards, > MuthuArticle: 63955
Hi, can anyone point out a book, paper or webpage where manufacturing tests are described? By manufacturing tests I mean before packaging, when the manufacturer determines whther a chip is defective or not ThanksArticle: 63956
Thank you very much. That solved my problem. -- Pratip Mukherjee "Subroto Datta" <sdatta@altera.com> wrote in news:OoaBb.4440$bc1.866@newssvr33.news.prodigy.com: > The PLL report for the ACEX1K -3 is a bug. This device does not have a > PLL, and this is a reporting bug which has been fixed in the next > version of Quartus. Without seeing your design, the best I can say for > the timing problem, is that you need to tell Quartus of the > relationship between your 10Mhz derived clock and the 40 MHz external > clock. You can do this using the Assignment Settings->Timing > Requirements and Options Dialog. The steps are as follows, based on > the assumption that your incoming 40 Mhz clock is clock40. > > 1. Open Assignment Settings->Timing Requirements and Options Dialog > 2. In the Clock Settings Group select the Settings for Individual > clock signals. > 3. Click on the New button to define the new clock. > 4. Fill in the entries in the New clock settings dialog. Set the clock > settings name to clock40 (for ease of use) and the "Applies to node" > should be selected to be the pin from the Node finder. The > "Relationship to other clock settings" should be set to "independent > of other clock settings". The fmax should be 40Mhz. Hit OK to close > the New clock settings dialog box. 5. Next define the 11 MHz clock > based on the output of the divide by 4. Click on the New button to > define clock10. 6. Set the clock settings name to clock10. The Applies > to node should be the output of the register that is the 10MHz signal. > The "Relationship to other clock settings" should be set to "Based on" > clock40 (defined in step4). Click on the Derived Clock Requirements, > and fill in the Divide base clock field.Hit OK, and close all the > dialogs. 7. Compile the design. > > Hope this helps > > - Subroto Datta > Altera Corp. > "Pratip Mukherjee" <pratipm_nooospam@hotmail.com> wrote in message > news:Xns944AE74DDA1B2pratipmnooospamhotma@216.148.227.77... >> Hi, >> I am trying to use AVRCore project from opencores.com on ACEX1K100-3 >> FPGA. Timing summary tells me that maximum clock is 11.xxx MHz. Since >> my > external >> clock is 40MHz, I inserted a divide by 4 counter before feeding it to >> the CPU clock. But Quartus still says that max. clock is 11.xxx MHz. >> How's that, shouldn't it be now 44.xxx MHz, assuming the input >> counter can count to 44MHz. I am not using the input clock for any >> other purpose than dividing by 4. >> Another related question. ACEX1K datasheet says that the -3 devices >> do not have PLL. But Quartus always reports 0 of 1 PLL used, even >> when I specifically select -3 device. Which one is right, datasheet >> or Quartus? Thanks in advance. >> >> Pratip Mukherjee > > >Article: 63957
The input_jitter constraint does not factor in jitter caused skew between clock
nets. It only decreases the available cycle time in your period constraint to
account for cycle to cycle variations (jitter) in the clock for that net. I
don't know if the VirtexII suffers to the same degree or not (and I haven't
chanced it) from DLL output spreading due to input jitter.
Safe crossing between related clock domains in not overly difficult, and is
still possible to do with the faster clock speeds. The only work around other
than deliberate safe crossing design is to guarantee the delay between two
flip-flops on different but related clocks is greater than the maximum possible
clock skew between those flip-flops, which is to say you have to depend on LUTs
and routing to delay the data signal. If speed is critical, then adding the
delays can hurt you more than doing a proper safe crossing.
John_H wrote:
> The new version of Xilinx tools (6.1i and on) appear to be doing a more
> complete job on this analysis. The biggest problem earlier was the effect
> of input jitter on the DCM that couldn't be accounted for. Uneven loading
> on the clock nets was also an issue. Now the tools allow an INPUT_JITTER
> constraint to go along with your specified period and duty cycle. Also with
> the automated elimination of hold-time violations, it looks like the tools
> are filling in for the corner cases of design as long as we, the designers,
> give the tool the right info.
>
> I'm now happier making the transition between same-edge clock domains
> without special treatment though I know where to look first if my design
> starts to misbehave.
>
> "jean-francois hasson" <jfhasson@club-internet.fr> wrote in message
> news:3fd377da$0$6982$7a628cd7@news.club-internet.fr...
> > Hi,
> >
> > I remember reading a few lines on this newsgroup about the fact that a DLL
> > in a Virtex might not be able to handle a negligible skew between two
> > outputs (clk0 and clk2X for instance) in some situations like a heavy
> > loading difference between the two clock trees with maybe an important
> (but
> > in the datasheet spec ?) jitter on the input clock. Ever since I read this
> I
> > did not consider I could change from one clock domain to the other without
> > special care. Has anyone something new concerning these potential cases ?
> If
> > there is still a possibility does it apply only to Virtex or also to
> Virtex
> > II ? The reason I ask is that the designs coming up are running faster and
> > faster making it more difficult to consider changing clock domains with
> some
> > extra precaution.
> > Thanks,
> >
> > JF
> >
> >
--
--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: 63958
It doesn't necessarily have to be a big FPGA, it depends on the size of the FFT
as well as the required latency and throughput. Size can also be reduced by
working with mixed fixed and floating point. I've done a number of FFT designs
in FPGAs, some of which are in rather small devices. There is a 4K point example
in an old 5v Virtex shown on the gallery page of my website.
dMon wrote:
> ... throughput similar to what RAID drives do. As for FFT's they
> are done way faster in a FPGA than in any processor including DSP
> processors. The only problem is the cost of the FPGA if you need
> really big FFT's (4K 24 bit wide). The card I was working on was
> ...
--
--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: 63959Jim, It is NOT "hard-to-copy"! Retains ALL of the reprogrammability and functionality of a 'true' FPGA -- just does it for a better cost/benefit trade-off. "Hard-to-copy" means that if you make a mistake, you are toast. It is inevitable that customers do not think of absolutely everything. The new architecture will also allow us to provide EasyPath(tm), which if the customer calls up (which has happened, and boy are they glad they went with Xilinx!), and says "I forgot an inverter" we just modify the test program, and they are back in business IMMEDIATELY, with only a small charge (perhaps very small) for the modified test program work that we have to do. No one else can do this, either! In fact, EasyPath(tm) can be done for a few images (bistreams) and still retain the savings. This fits it well with customers that wish to have single platforms that perform multiple functions (ie cellular basestations which are notorious for needing major changes every three months). "Hard-to-copy" on a base station? Disaster. End of the world. Remember I worked in telecom for 23 years, and FPGAs saved by rear-end so many times, I can not count them all. Ever had a Class-A recall of 100,000 units from telephone companies? Nightmare. But if they are reprogrammable, we only needed a seed stock of 1,000 units, and then sent the new ones out, got back the old ones, reprogrammed them, and went on thru the whole 100K. Saved the company. Saved the product. Today you could send out a floppy, flash, or download it over the 'net. That is why we state that "structured ASICs" are just a new description for a "buggy whip" -- not even in the same century as what we are doing. As for 'revolution', who has ever announced such a chip architecture? Certainly no one in the FPGA industry. Haven't ever heard of it anywhere else. 'Novel' is accurate as well. It is new. Prefer 'revolutionary', as that implies a complete re-thinking, and introduction of radically new benefits and features. The press announcement mentioned 100 innovations. That is no small feat for a new device family. I suppose Peter and I are guilty of working here, but some of the things that are coming up are awesome....... Austin Jim Granville wrote: > "Peter Alfke" wrote > >>Jim, >>this was the first pre-announcement of something new from Xilinx. Don't >>complain that it is vague, it is meant to be. It's supposed to create >>interest, curiosity, perhaps even impatient excitement. >>Exactly what the company wants. We cannot yet offer this for sale, but >>we can create some expectations. >>As Austin said, wait for the next, more detailed disclosure. >>Any similarity with strip-tease is purely intentional... > > > Sounds like a new marketing manager fresh in from another industry.... ;-) > > Even the technical press have taken the slightly misleading > "Xilinx Unveils Revolutionary..." > and watered it down to the more accurate > "Xilinx set to debut novel FPGA architecture" > "..set to debut in a 90nm Virtex device in the first half of 2004, segments > function blocks into interchangeable columns, rather than squares on a > grid." > > -jg > > > >Article: 63960
Brian is correct, you sometimes need to put syn_keeps on signals going into the
adder to keep it from optimizing segments of the carry chain. This typically
happens when one or more of the adder input bits are constants. The syn keep has
to be on the signal coming in, not on the adder:
attribute syn_keep of kept_a:true;
attribute syn_keep of kept_b:true;
kept_a<= a;
kept_b<= b;
sum_d<= kept_a + kept_b;
if sum_d is not going immediately to a register, then you may also need put a
syn_keep on sum_d.
In order to put RLOCs on the adder, you need to build the adder out of
instantiated primitives. In that case you may still need some syn_keeps on
either the LUT outputs or the carry signal to keep synplify from messing with
it, depending on the version of synplify. v7.3.3 requires a syn_keep on the
carry if you have a constant '1' going into the adder's carry in. An earlier
version, I think it was 5.3 needed a syn keep on the lut outputs, but 7.3.x need
the syn_keep on the LUT outputs taken off or it will insert an extra lut between
the LUT and the carry chain.
Brian Davis wrote:
> Ken wrote:
> > the Synplify logfile indicates no replication/pruning has taken place
> > but I still see Synplify reporting a broken chain in the worst path report.
>
> Can you post the offending fragment of code showing the adder and
> input operands, and the broken chain report message that results?
>
> some other suggestions:
>
> - drop your synthesis target clock to 1 MHz and see if the
> broken chain problem goes away
>
> - put the offending adder in its' own module with the
> leave-my-module-hierarchy-alone attribute set
> ( you can then stick an area constraint on that module to force
> it to stay in one column, but if the chain's already broken
> that won't help too much )
>
> - do the HDL-Analyst RTL/primitive views of the offending adder
> show something odd splitting it apart near that bit?
>
> Brian
--
--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: 63961Hello, Is it possible for a hobbyist to solder FPGAs with high pin counts to PCBs? How would I go about doing it? What equipment would I need? I want to starting working with FPGAs and rather than buying a development board I wanted to build my own board gradually from scratch. Is this a silly idea? I've talked to some electrical repair people I know and they say its impossible to solder chips with 200 pins or so without expensive kit. Is this true? I could afford to spend maybe $100-$250 on some kit. I've read some stuff, on the web, that seems to suggest that it is possible for a hobbyist to solder FPGAs. What advice can you guys give? Thanks very much, Joel.Article: 63962
I haven't played around with the socket library since they came out with EDK 6.1, but I seem to recall that at the time, only one side (server side) had been implemented, which would explain why there is only a xilsock_accept, and no xilsock_connect. Additionally, I remember many a discussion (you might want to do an archive search) on this NG about the flakiness of the socket library (I was hoping it had been improved with 6.1, which version are you using?). For what it's worth, I personally never got it to work reliably. However, from what I can tell of the code I have, xilsock_accept was blocking. If you want to compare your non-working code to my non-working code (I seem to recall that I could at least accept connections, however unreliably), I'd be happy to make it available, although I heavily based it on the (MicroBlaqze) web server example I got from Xilinx, which I assume you've already looked at. Has anyone out there ever gotten the xilsock library to work reliably? I don't want to waste any more time on it unless there's a good chance of success at the end... -- Pierre-Olivier -- to email me directly, remove all _N0SP4M_ from my address -- Jimbo wrote: > Does anyone know why Xilinx' socket function library, xilsock.h, does > not contain a xilsock_connect() function? > > Also, do you know how xilsock_accept() works? It appears to be > non-blocking by default. Is this the case? > > At this moment, the client I have running on a windows PC is getting a > WSACONNREFUSED error when it attempts to connect() to a socket on the > V2Pro. The server on the V2Pro is spinning in a loop that executes > xilsock_accept(). > > I've tried various port numbers and the connect error is the same. If > you have any insight from just this info, please let me know. Also if > you have the time and would like to see the code, I'd be happy to > email it to you. Or I can probably post it here later. > > Thanks, > JimArticle: 63963
It is perfectly possible to solder and unsolder FPGAs (up to PQ208 or similar) with fairly simple tools - good soldering iron, solder wick, and, with my eyesight, a low power microscope. You can remove an fpga with a very sharp scalpel blade (you will probably destroy the fpga in the process). The real problem with FPGAs is the PCB. Most FPGAs are very high speed devices and need a good ground plane and proper supply decoupling - without these you will have endless problems. You should also bear in mind that typical pin spacing is 0.65mm - translated this means 'very close' and very fragile. It is very difficult to reliably attach wires directly to a device. Making your own PCB for these purposes is not a job to be undertaken lightly, particularly as you usually need at least 4 layers ! So, my advice would be - if you are learning, and do not have a specific project in mind, buy one of the development/educational boards - believe me, the reduction in hassle is well worth the extra cost ! There is also great merit in starting from a known working state - debugging an FPGA board may take more exotic equipment than you have hanging around. I have used Burched boards www.burched.biz , but there are quite a few others. When you have a specific project in mind, and a bit more experience, then design your own pcb - and find someone to make it for you. Dave "Joel Smith" <joels@mobyfoo.org> wrote in message news:1071075419.16811.0@eunomia.uk.clara.net... > Hello, > > Is it possible for a hobbyist to solder FPGAs with high pin counts to > PCBs? How would I go about doing it? What equipment would I need? > > I want to starting working with FPGAs and rather than buying a development > board I wanted to build my own board gradually from scratch. Is this a > silly idea? > > I've talked to some electrical repair people I know and they say its > impossible to solder chips with 200 pins or so without expensive kit. Is > this true? I could afford to spend maybe $100-$250 on some kit. > > I've read some stuff, on the web, that seems to suggest that it is possible for a > hobbyist to solder FPGAs. What advice can you guys give? > > Thanks very much, > > Joel.Article: 63964
Hi,
I'm developing a digital signal processing algorithm on Xilinx Virtex2
FPGA. I use the Xilinx ISE 6.1i developing environment.
I'm trying to use the "/" (divisor) operator included in the ieee
"numeric_std" library but the systesis produces the following error
message:
"ERROR:Xst:769 - C:/test/div.vhd line 35: Operator <INVALID OPERATOR>
must have constant operands or first operand must be power of 2"
Does the ieee "/" operator is really defined for constant or power of
2 operators only?
How can I evaluate Q=NUM/DEN, where NUM and DEN are not constant, not
of power 2 and of type SIGNED ?
I already tested the Xilinx "Pipelined Divider V2.0" core but I can't
use it because of it's very high latency.
Thanks.
------------------------------
It follows the source code that generates the error message:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_SIGNED.ALL;
use IEEE.NUMERIC_STD.ALL;
entity div is Port (
clk: in std_logic;
NUM: in SIGNED(15 downto 0);
DEN: in SIGNED(15 downto 0);
Q: out SIGNED(15 downto 0) );
end div;
architecture Behavioral of div is
begin
process (clk, NUM, DEN)
begin
if clk='1' and clk'event then
Q <= NUM/DEN;
end if;
end process;
end Behavioral;
Article: 63965
Howdy Austin,
Austin Lesea wrote:
[...]
> "Hard-to-copy" means that if you make a mistake, you are toast. It is
> inevitable that customers do not think of absolutely everything. The
> new architecture will also allow us to provide EasyPath(tm), which if
> the customer calls up (which has happened, and boy are they glad they
> went with Xilinx!), and says "I forgot an inverter" we just modify the
> test program, and they are back in business IMMEDIATELY, with only a
> small charge (perhaps very small) for the modified test program work
> that we have to do. No one else can do this, either! In fact,
> EasyPath(tm) can be done for a few images (bistreams) and still retain
> the savings. This fits it well with customers that wish to have single
> platforms that perform multiple functions (ie cellular basestations
> which are notorious for needing major changes every three months).
Hmmmm. If the customer is just changing the contents of a LUT, does
that really require requal'ing EasyPath parts and changing the test
program? My understanding of EasyPath was that components and routes
are tested, but I guess I don't have an exact definition of "component."
Could the contents of a LUT be changed without going through this
hassle? What about changing the polarity of a signal (or clk) going to
a flop? IOB parameters? Contents of a BRAM?
[...]
> That is why we state that "structured ASICs" are just a new description
> for a "buggy whip" -- not even in the same century as what we are doing.
And yet there are perfect applications for both buggy whips and
structured ASICs. Funny how an improvement on something doesn't
necessarily out date everything before it, isn't it?
> As for 'revolution', who has ever announced such a chip architecture?
> Certainly no one in the FPGA industry. Haven't ever heard of it
> anywhere else.
>
> 'Novel' is accurate as well. It is new. Prefer 'revolutionary', as
> that implies a complete re-thinking, and introduction of radically new
> benefits and features. The press announcement mentioned 100
> innovations. That is no small feat for a new device family.
Where I work, whenever we hear the word "revolution," our ears perk up.
Because we know that that history has shown that most real revolutions
fail, or at least, the first couple attempts at the revolution do. Both
old history and recent history, in all areas, from politics to the
telecom world, to the semiconductor world. It is VERY rare. So if I
were you, I'd personally shy away from that term unless it truly is
revolutionary, in which case, as a shareholder, I hope you're not
betting too much on it.
I am not saying I'm against revolutions when they are really called for.
I'm just saying that the word has been associated with A LOT of
failure and that whenever I hear it coming from the mouth of a marketing
droid, I hold onto my wallet.
> I suppose Peter and I are guilty of working here, but some of the things
> that are coming up are awesome.......
Indeed they are. It is a very exciting time for FPGAs, semiconductors,
and electronics in general. But just like we don't blame you for
talking up Xilinx, don't blame us for trying to keep the marketers in
check with all the fluff (and few details) they put out.
Have fun,
Marc
Article: 63966Jim, here are some fictitious press releases that might be to your taste: Boeing 747: like a 727, just bigger Porsche 911: like a VW, just faster Nokia cell phone: like a Walkie-Talkie, just lighter Transistor: like a vacuum tube, just smaller LCD display: like a CRT, just flatter FPGA: like a CPLD, just more complex Any spectacular innovation can be de-dramatized. Wouldn't excite any magazine editor, though. Peter Alfke Jim Granville wrote: > > "Peter Alfke" wrote > > Jim, > > this was the first pre-announcement of something new from Xilinx. Don't > > complain that it is vague, it is meant to be. It's supposed to create > > interest, curiosity, perhaps even impatient excitement. > > Exactly what the company wants. We cannot yet offer this for sale, but > > we can create some expectations. > > As Austin said, wait for the next, more detailed disclosure. > > Any similarity with strip-tease is purely intentional... > > Sounds like a new marketing manager fresh in from another industry.... ;-) > > Even the technical press have taken the slightly misleading > "Xilinx Unveils Revolutionary..." > and watered it down to the more accurate > "Xilinx set to debut novel FPGA architecture" > "..set to debut in a 90nm Virtex device in the first half of 2004, segments > function blocks into interchangeable columns, rather than squares on a > grid." > > -jgArticle: 63967
Hi all, My machine is Window 2000, Fndtn3.1i, SP8. I have used spartan2-100-TQ144 before, actually I've just installed the software on a new laptop and re-run the old project which working well on other machine. On the new latop, I encountered a strange error. When I use P10 as an IO (data sheet says it is an IO, and bsd too), mapping gives error, but if I change it to (for example) P12, it will map/ route ok. Then I open the PAD report, it reports P10 as a VCCINT, which is incorrect! Looking at the whole 144 pin's function and compare with the data sheet, I find out all pin number are increment by 1. For example bsd file and data sheet has P9 = VCCINT, P142 = TMS; but in the PAD report it has P10=VCCINT, P143=TMS... and so on Does any one know how to fix this? Thanks, lnguyenArticle: 63968
Did you try simulating the problem to see if you can get more information. Your description of the problem is rather high level. Mike "algous" <algous2002@yahoo.com.cn> wrote in message news:1e71fcd5.0312081757.40fea000@posting.google.com... > Dear all, > I implement a DMA controller in the PLD side of the ALtera's > excalibur device(epxa1), and a block ram in the PLD other. DMA > controller access data through the PLD-to-STRIP bridge. I config the > DMA controller through STRIP-to-PLD bridge. > now I need to exchange datas between the sdram(out of chip) and the > RAM in PLD. It seemed that some datas not translated successly, there > would be eight continual beats failed every since. while other datas > sucessful, and there would be eight continual beats as well. > The DMA controller was designed refer to ALtera's "AN 287: Using > Excalibur DMA Controllers for Video Imaging ". I dont confirmed the > AN287 is ok, I thinked it's worked well. > In the other hand, If the DMA controller exchange between the > SPRAM(single port RAM on chip) and the block ram in the PLD, the DMA > controller worked very well. The timing and function simulation is > successed as well. > I think if there were some bugs in the excliabur device. The above > sympton seemd is related with the SDRAM' controller or the AHB BUS. > because THE HARDWARE REFERENCE MANUAL's SDRAM section said "Transfers > to the memory are made up of eight-beat reads and writes. A request > from the system bus that does not map directly to this fixed-beat > access(for example, A larger burst size or a wrapping transfer) is > handled by performing multiple accesses. Burst termination is utilized > to maximize throughput." > > regards > > algousArticle: 63969
Hey Joel, It is possible to solder TQFP/PQFP packages using a gold soldering iron and bit of patience. Be sure do doulbe-check visually and electrically the board before power-up. There are also other methods. For example, take a look at this page (I have not tried this method myself... yet): http://www.seattlerobotics.org/encoder/200006/oven_art.htm Regards, -- Georgi "Joel Smith" <joels@mobyfoo.org> wrote in message news:1071075419.16811.0@eunomia.uk.clara.net... > Hello, > > Is it possible for a hobbyist to solder FPGAs with high pin counts to > PCBs? How would I go about doing it? What equipment would I need? > > I want to starting working with FPGAs and rather than buying a development > board I wanted to build my own board gradually from scratch. Is this a > silly idea? > > I've talked to some electrical repair people I know and they say its > impossible to solder chips with 200 pins or so without expensive kit. Is > this true? I could afford to spend maybe $100-$250 on some kit. > > I've read some stuff, on the web, that seems to suggest that it is possible for a > hobbyist to solder FPGAs. What advice can you guys give? > > Thanks very much, > > Joel.Article: 63970
If you make the FIFO 32 bits wide on both ports. Then alternate between writing to the lower and upper half of the 32 bit datapath on the "16 bit" side of the fifo you have effectively converted from 16 to 32 bits when travelling through the FIFO. "Simone Winkler" <simone.winkler@gmx.at> wrote in message news:1070991277.205907@news.liwest.at... > Hello! > > I want to build a FIFO for a special purpose: > I've got a microcontroller that interfaces to a SDRAM via an > SDRAM-interface. The microcontrollers data width is 16 bit while the > SDRAM-interface needs 32 bit (if i write something to the sdram, in the > first clock cycle, the interface needs the bank, row and column address (32 > bit) and in the second clock cycle the data (only 16 bit, the upper 16bit > are just don't care)). > Now I need a FIFO that converts the 2x16 bit to one 32-bit word. Timing is > not important, only the 2 words of 32 bit have to be sent one clock cycle > after the other. (so i don't need a "doubling" of the clock rate, just a > method to combine the two incoming words) could it work with a kind of shift > register? > > Thank you for your help! > > Simone >Article: 63971
The AMBA APB bus does not support bursting. All accesses are of a fixed length (3 clocks). Typically an application that uses an APB bus also has an APB bridge that connects the APB bus to an AHB bus. You can busrt on the AHB bus if you like .... the bridge will convert that to fixed length cycles on the APB bus and insert wait states in the AHB burst. "Invincible" <asdf@asdf.com> wrote in message news:br5iph$v0e$1@reader01.singnet.com.sg... > Hi, there: > > I am reading AMBA specification. > Does the Read/Write waveform for the APB indicate the bus speed is 1/3 of > the pclk frequency? > Now if I need to write a continuously in every clock cycle, may I keep the > PWRITE, PSELx and > PENABLE high for many cycles while keep changing address and data every > clock cycle? > OR, am I obliged to use AHB's burst moode? > > Thanks. > > > >Article: 63972
Here is a general answer: Most manufacturers perform some degree of functional testing on the wafer, before it is divided into individual dice. The failing devices are marked with a red dot, and then dicarded after the wafer is divided. (Throwing bad devices away before packaging saves money, especially with large chips where the yield is significantly lower than 100%. The smallest devices are sometimes all packaged and tested as packaged parts.) Parametric testing ( especially for speed parameters) is difficult or impossible on the wafer level, and is therefore done on the packaged devices. Xilinx packaged FPGAs are 100% tested at temperature (above 85 degrees junction for commercial devices). During test, the FPGAs are being reprogrammed many times to allow access to all the internal functions. Each device is tested with millions of test vectors. Functional failures and dc-parametric failures are thrown away, speed-parameter differences lead to "binning" into the different speed categories. That's it in a nutshell. Peter Alfke, Xilinx Applications. ============================== Nick wrote: > > Hi, > > can anyone point out a book, paper or webpage where manufacturing > tests are described? > > By manufacturing tests I mean before packaging, when the manufacturer > determines whther a chip is defective or not > > ThanksArticle: 63973
Marc, --snip-- > > Hmmmm. If the customer is just changing the contents of a LUT, does > that really require requal'ing EasyPath parts and changing the test > program? My understanding of EasyPath was that components and routes > are tested, but I guess I don't have an exact definition of "component." > Could the contents of a LUT be changed without going through this > hassle? What about changing the polarity of a signal (or clk) going to > a flop? IOB parameters? Contents of a BRAM? If they use a LUTRAM, SRL16, BRAM, then those features are 100% tested. If they do not use a clock inversion, or do not use a different IO standard, then these are not tested. > > [...] > >> That is why we state that "structured ASICs" are just a new >> description for a "buggy whip" -- not even in the same century as what >> we are doing. > > > And yet there are perfect applications for both buggy whips and > structured ASICs. Funny how an improvement on something doesn't > necessarily out date everything before it, isn't it? Oh yes. I have a buggy whip at home. Use it all of the time. Right. > >> As for 'revolution', who has ever announced such a chip architecture? >> Certainly no one in the FPGA industry. Haven't ever heard of it >> anywhere else. > > > > > 'Novel' is accurate as well. It is new. Prefer 'revolutionary', as > > that implies a complete re-thinking, and introduction of radically new > > benefits and features. The press announcement mentioned 100 > > innovations. That is no small feat for a new device family. > > Where I work, whenever we hear the word "revolution," our ears perk up. > Because we know that that history has shown that most real revolutions > fail, or at least, the first couple attempts at the revolution do. Both > old history and recent history, in all areas, from politics to the > telecom world, to the semiconductor world. It is VERY rare. So if I > were you, I'd personally shy away from that term unless it truly is > revolutionary, in which case, as a shareholder, I hope you're not > betting too much on it. > > I am not saying I'm against revolutions when they are really called for. > I'm just saying that the word has been associated with A LOT of failure > and that whenever I hear it coming from the mouth of a marketing droid, > I hold onto my wallet. Most revolutions fail? Hmmm. I suppose you also belong to the "glass is half empty crowd." AustinArticle: 63974
>It is perfectly possible to solder and unsolder FPGAs (up to PQ208 or >similar) with fairly simple tools - good soldering iron, solder wick, and, >with my eyesight, a low power microscope. You can remove an fpga with a very >sharp scalpel blade (you will probably destroy the fpga in the process). > >The real problem with FPGAs is the PCB. Most FPGAs are very high speed >devices and need a good ground plane and proper supply decoupling - without >these you will have endless problems. You should also bear in mind that >typical pin spacing is 0.65mm - translated this means 'very close' and very >fragile. It is very difficult to reliably attach wires directly to a device. >Making your own PCB for these purposes is not a job to be undertaken >lightly, particularly as you usually need at least 4 layers ! Your advice is perfectly ok, let me tell you though, that I'm regularly fabricating my own four layer PCB's at home. To produce a four layer PCB 3x3" in size takes about 4 hours. Such a PCB costs me then ~$10 so provided you need some of them over time it's IMHO well worth the effort. That's especially true for prototyping and advanced hobbyist use. My main motivation was that I really got sick of waiting for the boardhouse to complete the PCB. I know that in some areas it's much easier to get cheap and quick PCB's, but four hours are IMHO hard to beat! :-)) If you consider the fact that where I live getting a four layer PCB of said size in say three workign days costs a fortune ($2K!!!!) it really makes sense. Six layer is also possible just means more work (add two hours for above sample PCB). So, if one is dedicated enough it can be done. The main requirement is having a through hole plating station. I built one myself. Those which are interested might want to visit www.myhome.ch/mzingg/pcbstuff/tps Soldering BGA's is trickey but even here are (rare) "homebrew" solutions around. I'm curently experimenting in this area and hope to have this working for myself soon. Please note that this is strictly for my personal needs / prototyping work. That said it's clear that even for small production runs I'm more than happy to use the services of a board house. Markus
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