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 wrote: > I wrote: > >> However, when placed in this slot the P160 MAC phy_rx_d<3> pin, defined >> as 3.3V LVCMOS, connects to FPGA pin AD13 which is on the same IO bank >> as most of the main board's DDR signals (2.5V SSTL) e.g.: > Any ideas on how I might get past this? I could fudge the IOSTD > constraints to force it to map, but intermixing 2.5V FPGA pins with 3.3V > signals seems like a bad idea. Hmm, perhaps I should stop talking to myself so much. Anyway, a very helpful Insight engineer has helped to resolve this one. It's just a case of changing the IOSTD constraint to LVCMOS25, and trusting the source termination resistors on the P160 module to sufficiently reduce the 3.3V driving voltages down to the IO's clamping/protection thresholds. This Xilinx answer says more: http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=20492 Cheers, JohnArticle: 85776
sean wrote: > > Is this from UMC or Toshiba? Or Both? > > Will the current specifications be maintained? Or is there a new > specification to deal with the change in process/FAB? Whether the parts are made by UMC or Toshiba (Spartan3 is not), and whether they were born on a 200 mm or a 300 mm wafer is of no concern ( or should be of no concern) to the average user. All these parts have to meet (and do meet) the data sheet specification. But since there are (albeit minute) process differences and different mask sets involved, we have to do new qualification tests ( like static discharge) on all pins and on all internal functions. And that takes time. Having multiple fabs is common these days, not only for ICs, also for raw materials, food stuff, machinery, automobiles, household goods, books and magazines, etc. Whether a particular car is assembled in Michigan, Canada, or Ohio should not be a major concern for the buyer. But when you buy a whole fleet of them, you may be interested, perhaps for reasons of consistency and tracability. IC mask sets and wafer sizes went through many rapid changes over the previous decades, and few buyers were concerned, as long as the specs were met. And the IC supplier had a lot of latitude. Now we have far less freedom, since a smaller-geometry process automatically means a lower supply voltage, and thus a completely new part number. In the 5-V era, we all used to make lots of changes without telling you, unless you were a big corporate customer. Guess how many fabs and mask revisions Intel has on their Pentiums? (Pentia?) In other words, no user should be concerned about the wafer diameter. We just try to abide by self-imposed rules. (And they, unfortunately, led to the artificial scarcity). Peter Alfke, from home.Article: 85777
hi all, I am trying to find some means of converting a design described as a vhdl code to edif file. I am using xilinx tool set (from entry to device programming). Are there any other tools that can do the same job. Thanks! NarayanArticle: 85778
Whether the long leads time have been artificially created by Xilinx or not I would strongly suggest anyone using Spartan3s to check with their distributor. It isn't pretty. Ricky > In other words, no user should be concerned about the wafer diameter. > We just try to abide by self-imposed rules. (And they, unfortunately, >led to the artificial scarcity).Article: 85779
Narayan wrote: > I am trying to find some means of converting a design described as a > vhdl code to edif file. I am using xilinx tool set (from entry to > device programming). Are there any other tools that can do the same > job. Synplify will also do it... I don't think that's the answer to your ultimate question though. What are you trying to do? JeremyArticle: 85780
Nju Njoroge wrote: > I found out what the issue was: > [...snip...] > Fix: Make sure PATH variable has %XILINX%\bin\nt in it. OK, good to know. I *KNEW* it was something with the path :)= cu, SeanArticle: 85781
Dear (current) Xilinx user, We design boards that are manufactured in quantity elsewhere, and we depend on easy and quick availability of prototype and pre-production quantities. Particularly for FPGAs, where there are multiple parts in identical packages, we often need to try one size up (for capacity) or one size down (for cost) quickly. We also build small runs of boards for customer approval, always on short turn-around. The message from Xilinx seems to be that they don't want to bother with anyone that is not also directly responsible for the manufacture (i.e. have the distribution relationships). Spartan 3 parts were formerly available even in pre-production quantities through the web store, and it offered excellent service (so good it was definitely a plus factor in designing in Xilinx parts). Without the web store, there are today exactly zero distributors that currently have, or can obtain in any reasonable time, the Spartan 3 parts we are using. This is true whether it is from a 200mm fab or 300mm fab. I'm sure with a good distribution relationship there are strings that could be pulled to get something more quickly. However, I'm not sure why we would want to spend time and use up favors for something that should be readily available overnight in small quantities. It is a week since Xilinx's own representative said he would try and find out if/when the product would be available, and no news looks like very bad news. To cut off supply with no notice, and fail to make any reasonable arrangements with alternative distribution, makes us nervous about continuing to incorporate Xilinx parts even if they do sort this situation out. Our customers expect us to select components from reliable suppliers that won't change the rules in the middle of the game. Despite their persistent enthusiasm, we have always declined to meet with our local Altera rep because, despite the odd hiccup, we were pretty satisfied with the Xilinx solution. My understanding is that Altera are more committed to multiple distribution channels and generally superior product availability (any satisfied / dissatisfied Altera purchasers out there to comment?). While hoping that the Xilinx situation will improve quickly and dramatically, past experience with semiconductor suppliers that take their eye off the ball is that one bad decision is quickly followed by others, and it is wise to start looking at alternatives.Article: 85782
Hello Guys, I am integrating an MiniPCI core on virtex 2 pro fpga. In order for me to test the core i need an MINI card. Can i use any Mini card for testing or is any special mini card for testing. If not can anyone plz suggest how can i test the miniPCI core. Thanks and Regards WilliamsArticle: 85783
We have admitted our sins, we have suggested a relatively simple work-around (the 0974 suffix to the order code), and I can assure you that there are strong efforts underway to correct this untenable situation, as fast as we can. The ugly comments in this newsgroup have been relayed to the highest (and also the lower) levels of management, and there will be action. You have been heard, and you were right. I have used pretty strong language internally, and I expect things to change. It just takes more than a few days... Peter Alfke, from home.Article: 85784
Hi comrades, I am into hardware design and eventhough I have designed for many components and modules one question always bugs me. How do we go about determining the partition of a design, say some device controller. In case of interfaces like control blocks to memories or fifos the interface and fucntionality is quite clear. But what about the interfaces when we partition a design in to sub-blocks. Is there an optimum way to partition the design and also minimize the interface details between them.Article: 85785
Steve Knapp explained: Append 0974 to the order code, and every distributor should be able to quote short leadtimes. If not, contact a better distributor. They are not Xilinx employees, but rather independent businessmen. Xilinx has lots and lots of parts, especially of the 3S200. This is just a logistical snafu, not a real availability problem. Sorry for the confusion. Peter AlfkeArticle: 85786
Hi,
The problem is solved. The last problem was due to the SELinux policy
that Fedora Core 3 enforces. It shows up in /var/log/messages as:
Jun 16 07:50:40 localhost kernel: audit(1118901040.916:0): avc: denied
{ execmod } for pid=5234 comm=impact
path=/home/krish/binaries/Xilinx/bin/lin/libSTL.so dev=hda2 ino=4394222
scontext=user_u:system_r:unconfined_t
tcontext=root:object_r:user_home_t tclass=file
To temporarily evade this, you can
# sudo setenforce 0
and later,
#sudo setenforce 1
The problem is (probably) caused by the fact that the ``offending''
library libSTL.o should have been compiled with -fPIC
(position-independent code). It is described for similar cases - but
not impact - in the Red Hat bug database and can be solved permanently
by reading the
Fedora Core 3 SELinux FAQ and working around the enforcing.
Much tx for everybody who helped,
Kris Heyrman
Article: 85787"Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag news:1118901840.407859.104810@z14g2000cwz.googlegroups.com... > We have admitted our sins, we have suggested a relatively simple > work-around (the 0974 suffix to the order code), and I can assure you > that there are strong efforts underway to correct this untenable > situation, as fast as we can. The ugly comments in this newsgroup have > been relayed to the highest (and also the lower) levels of management, > and there will be action. You have been heard, and you were right. I > have used pretty strong language internally, and I expect things to > change. > It just takes more than a few days... > Peter Alfke, from home. > I am sure this is will be good news. There are many ways and reasons, but I can say one thing: ".. 'taking the S3 OFF from the web store' - this is the one thing one should never do .." REALLY, I mean it. If it was possible to sell the S3 from Xilinx webstore then there can be no reasons explainable to the customer why it is not possible any more. The only thing the people will belive is that the store is not carrying them any more because there is no silicon to sell. Doesnt matter what the real cause is. If the decision to put S3 to Xilinx webstore is now considered as bad decision internally in Xilinx, then Xilinx should still 'stick' with it that decision and keep carrying the S3, even if it is making too much problems. The Digikey - thats another issue to deal with, I used to checkout Digikey to get price indicators and warnings on component leadtimes. The fact that there is no S3 on Digikey at all, is alarming itself, it means either there are no requests, no interest in S3 or there is no silicon, or that somewhere is a major problem of some sort. The Memec-Avnet, due to the pending purchasing of Memec by Avnet (what is pending the US anti-trust court approval) I would not count that Avnet or Memec is very interested in anything, Memec has lots of losses, and Avnet is about to pay for those, so both of those have internal things to solve. And with NuHorizon as Xilinx supplier would I not count at all. So all that together - it is quite understandable that customers have BIG concernes on the availability and about the overall situation with S3 (and other Xilinx silicon) Antti's 5 cents to the story...Article: 85788
Hello everybody, I'm a newbye in FPGA so I need some help in a simple problem. I would like to implement a 256 byte LUT on a Virtex 300 E FPGA. Can you suggest me some on line resource that explains how to implement this LUT, how to select the memory resources that I want use for this task etc? Thanks a lot for any help, GiovanniArticle: 85789
> : Well, inserting registers changes your design in a fundamental way.
> : Most circuits I can think of would just stop working if you added
> : registers to them at random. Only you, the designer, know exactly
> : how much pipelining it is legal to apply to a given part of your
> : circuit. So I don't believe such a tool exists - certainly not in the
> : general case.
> This is very true, but there's no reason a designer couldn't specify a
> bunch of signals (e.g. the data signal from a combinatorial multiply and
> associated control signals) and some tool would add aribtrary (to a user
> specified limit) stages of pipelining to all signals to meet timing, with
> logic/register shuffling. This would only work the control and data flows
> can be aribtrarily pipelined, but many ops can be described this way/
True, although I don't see much merit in doing it that way. In FPGAs, the
pipeline registers are essentially free (because they're there after every
LUT, even if you don't use them). So you don't get much advantage from
"just" meeting timing - if you have four clock cycles do do something in,
then you might as well take all four - who cares? You'll get better results
out of the tools that way, too.
Of course, if you *do* care about the latency of your operations and you
want to minimize it, then you're already thinking in enough depth about your
design that an automated tool would be unnecessary.
Cheers,
-Ben-
P.S. Whenever someone says "automated tool" I immediately envisage a smug
paperclip: "I see you're trying to close timing - would you like some help
with that?" This of course means that all my subsequent utterances on the
subject can be safely disregarded. :-)
Article: 85790On 15 Jun 2005 02:46:53 -0700, "himassk" <himassk@gmail.com> wrote: > > Hi, > Can any body help me by giving website address or info > about VHDL synthesis coding techniques. > > Thank u. > > Hima. http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/preface.htmlArticle: 85791
the tool will automatically infer distributed ram if you can do without a reset.Article: 85792
can you provide me some reference to the documentation that documents that? Moreover a LUT of 256 byte has an acceptable size or is too big? I know this is a stupid question, but I'm a newbye Thanks a lotArticle: 85793
Basically let the camera take it's picture though user's hand is shaky, and use a mechanism to record down the angle of user's handshake in steps of 1us, now I get V = [v0, v1, ...v(n-1)]; With this vector, I calculate displacement vector the image has moved in terms of number of pixels P. Assume the image sensor's voltage rises linearly w.r.t exposure time (or any charactized waveform). I slice the image into n slices by dividing each pixel's RGB data into RGB/n (depending on the waveform of the sensor's characters), and use a technique similar to the motion compensation, move the slices according to displacement vector P and add them together to reconstruct final image. How does my idea work?Article: 85794
On a sunny day (Thu, 16 Jun 2005 18:40:37 +0800) it happened "Kris Neot" <Kris.Neot@hotmail.com> wrote in <42b15483$1@news.starhub.net.sg>: These systems (software stabilization) are already in many consumer video cameras. There are also stand alone (MS windows) programs that will stabilize an existing shaking recording. >Basically let the camera take it's picture though user's hand is shaky, and >use a >mechanism to record down the angle of user's handshake in steps of 1us, now You will at best get a set of motion vectors per frame, so 1us makes no sense? Think 40mS (@25fps). >I get V = [v0, v1, ...v(n-1)]; With this vector, I calculate displacement >vector >the image has moved in terms of number of pixels P. And of cause mpeg2 encoding already gives us these vectors for free. >Assume the image sensor's voltage rises linearly w.r.t exposure time (or any >charactized waveform). I do not see what motion in one direction or an other has to do with exposure time. Exposure time has to do with how much sensitivity you have to light. Of cause when your exposure time get freaky long, you get motion blur. >I slice the image into n slices by dividing each pixel's RGB data into RGB/n >(depending on the waveform of the sensor's characters), and use a technique >similar to the motion compensation, move the slices according to >displacement >vector P and add them together to reconstruct final image. I have lost you here. >How does my idea work? What idea?Article: 85795
I was recently evaluating Synplify Pro as i was getting pushed to the corner in terms of area usage on the XC2VP7. This is what i found: The comparison is not EXACT since there are probably some differences in the design constraints, but it certainly gives a fair idea. The designs are constrained for 40 MHz System Clock. (but the comparison is also valid for 80 MHz, as in my opinion, either frequency is on the low end of what these devices can handle). Also, not ALL the error checking is implemented. Resource ISE6.3sp3 Synplify 8.0 Flip Flops 4170 3945 4 Input LUTs (Logic) 5503 3923 4 Input LUTs(Route-thru) 814 309 4 Input LUTs(Total) 6318 4232 Occupied Slices 4075 3330 4928(Total) (Overall 15 % Savings !!!) The comparison is not EXACT since there are probably some differences in the design constraints, but it certainly gives a fair idea. The designs are constrained for 40 MHz System Clock. i agree its not a "fair" comparison as i was using ise6.2sp3 vs Synplify 8.1. cheers, adarsh "B. Joshua Rosen" <bjrosen@PleaseDontSpamMEpolybus.com> wrote in message news:pan.2005.06.13.21.58.40.8091@PleaseDontSpamMEpolybus.com... > On Mon, 13 Jun 2005 20:51:55 +0000, Joseph H Allen wrote: > > > In article <3h3o19Ff6phbU1@individual.net>, > > Falk Brunner <Falk.Brunner@gmx.de> wrote: > >>"Austin Franklin" <austin@dark99room.com> schrieb im Newsbeitrag > >>news:911re.4452$Ub4.3176@fe06.lga... > > > >>> > I used Synplify for many years but I haven't used it recently. I > >>> > switched to XST about a year ago when it got to the good enough level. > >>> > XST improves with each release, my gut says that it's pretty close to > >>> > Synplify's level at this point. > > > >>Recently, I had a design, not really a big deal. Running at 36 and 72 MHz. > >>XST was not able to squeeze it into a XC2S50E, but Synplify was. (~1600 LUTs > >>to ~ 1200 LUTs). Speed was not the problem, both implementation where fast > >>enough. But Synplify was more area efficient. > >>We are using XST only, this was just a test with a real case. > > > > I'm having the same experience: Synplify_pro 8.1 uses 97% (map with -tx on) > > of an XC2V6000 (which "map" with "-tx on -timing" actually can close timing > > on), whereas XST 5.2 uses 102% (no -tx on). I think Synplify's CSE (or > > "resource sharing") is better. The difference in price between an XC2V8000 > > and an XC2V6000 more than covers Synplicity's fee. On the other hand, XST > > and Synplicity seem to be on par as far as the resulting design's speed. > > > > One big annoyance: attributes use a completely different concept between the > > two tools: Synplicity, following verilog tradition, associates attributes by > > position within a comment before the ; of an instantiation. XST follow VHDL > > and associates them by name: the comment can be anywhere in the file. But > > now that I have my conversion script, this is no big deal. XST uses > > data_bus<1> and Synplicity uses data_bus[1]. XST flattens the hierarchy, > > Synplicity doesn't (earlier versions used to). All of this makes the .ucf > > file fun. > > > > We are not using later versions of XST due to answer record #16808 (casex > > doesn't always make correct code)- I'd like to try 7.1i, but it wont work on > > RedHat 7.3. Synplify 8.1 (their latest) does work in RedHat 7.3. Also code > > errors which XST 5.2 allows cause XST 6.1 - 6.3 to core dump- which makes it > > difficult to find the error. Note that we have to run XST 5.2i in wine (but > > we then run place & route with 6.2isp3). > > > > Other issues: synplicity runs about 33% faster, but sometimes for larger > > designs it is much faster. I think we are hitting some exponential time > > algorithm in XST. > > > > The error reporting from Synplify is much better than XST: > > > > // XST gives no error > > output [5:0] foo; > > reg [4:0] foo; > > > > // XST gives no error: two always blocks writing to the same signal when the > > // signal gets optimized out because nobody is readying it. > > reg x; > > > > always @(posedge clk or negedge reset_l) > > if (!reset_l) > > x <= 0; > > > > always @(posedge clk or negedge reset_l) > > if (!reset_l) > > x <= 0; > > else > > x <= y; > > There are switches in the XST script for controlling things like hierarchy > flattening and bus delimiters. There is an issue with case statements > doing something unexpected if you don't have a default, the solution is to > always have a default: in every case statement, this is the correct thing > to do anyway. > > I played around with XST's switches until I was happy with the results. > XST's switches can make a big difference in the size and speed of the > final results. Here are the switches from one of my scripts, > > > run > -ifn loopback_m325_sma.xprj > -ifmt Verilog > -ofn loopback_m325_sma.ngc > -top loopback_m325_sma > -ofmt NGC > -p xc2vp70-6-ff1704 > -opt_mode SPEED > -opt_level 1 > -max_fanout 32 > -keep_hierarchy no > -register_duplication YES > -equivalent_register_removal no > -hierarchy_separator / > -bus_delimiter <> > -mux_extract YES > -mux_style MUXF > -ram_extract YES > -ram_style Auto > -rom_extract YES > -rom_style Distributed > -verilog2001 NO > -vlgcase Full-Parallel > -decoder_extract YES > -priority_extract YES > -shreg_extract YES > -shift_extract YES > -xor_collapse YES > -resource_sharing YES > -iobuf NO > -register_balancing no > -slice_packing Yes > -glob_opt max_delay > -fsm_encoding Compact > >Article: 85796
[X-post, F'up2 cut down by me, should have been done by you!] In comp.arch.embedded Kris Neot <Kris.Neot@hotmail.com> wrote: > Basically let the camera take it's picture though user's hand is > shaky, and use a mechanism to record down the angle of user's > handshake in steps of 1us, 1 microsecond won't do you any good. No human can move anything at a frequency of 1 MHz. Anyway, what happens during the exposition for a single frame will be completely impossible to correct for after the fact. That's why some current consumer cameras do this in a different way: they use movable parts in the optical system to compensate shaking *before* any light hits the sensors. That's the only way it becomes possible to do in-frame shake compensation. > now I get V = [v0, v1, ...v(n-1)]; With this vector, I calculate > displacement vector the image has moved in terms of number of pixels > P. Displacement alone is also useless. You also have to take care of rotation --- that's actually more important than displacement. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.Article: 85797
"Antti Lukats" <antti@openchip.org> wrote in message news:d8r7c0$eop$03$1@news.t-online.com... > "Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag > news:1118901840.407859.104810@z14g2000cwz.googlegroups.com... > > We have admitted our sins, we have suggested a relatively simple > > work-around (the 0974 suffix to the order code), and I can assure you > > that there are strong efforts underway to correct this untenable > > situation, as fast as we can. The ugly comments in this newsgroup have > > been relayed to the highest (and also the lower) levels of management, > > and there will be action. You have been heard, and you were right. I > > have used pretty strong language internally, and I expect things to > > change. > > It just takes more than a few days... > > Peter Alfke, from home. > > > > I am sure this is will be good news. > There are many ways and reasons, but I can say one thing: > > ".. 'taking the S3 OFF from the web store' - this is the one thing one > should never do .." > > REALLY, I mean it. > > If it was possible to sell the S3 from Xilinx webstore then there can be no > reasons > explainable to the customer why it is not possible any more. The only thing > the people will > belive is that the store is not carrying them any more because there is no > silicon to sell. > Doesnt matter what the real cause is. > > If the decision to put S3 to Xilinx webstore is now considered as bad > decision internally > in Xilinx, then Xilinx should still 'stick' with it that decision and keep > carrying the S3, even > if it is making too much problems. > > The Digikey - thats another issue to deal with, I used to checkout Digikey > to get price > indicators and warnings on component leadtimes. The fact that there is no S3 > on Digikey > at all, is alarming itself, it means either there are no requests, no > interest in S3 or there > is no silicon, or that somewhere is a major problem of some sort. > > The Memec-Avnet, due to the pending purchasing of Memec by Avnet (what is > pending > the US anti-trust court approval) I would not count that Avnet or Memec is > very interested > in anything, Memec has lots of losses, and Avnet is about to pay for those, > so both of those > have internal things to solve. > > And with NuHorizon as Xilinx supplier would I not count at all. So all that > together - > it is quite understandable that customers have BIG concernes on the > availability and > about the overall situation with S3 (and other Xilinx silicon) > > Antti's > 5 cents to the story... > > While Xilinx are listening can I re-enforce some of Atti's comments. I'm a freelance designer and I never buy many parts but some of my customers buy in the 10k+ per annum range. When I get a design contract availability of parts for prototyping is absolutely key to the design in decision. My experience of the large distributors (other than the catalogue guys like Farnell and Digikey) is that they just get in the way. Suppliers with good sample/web sales systems usually win. For examples of how to do it right check out Microchip, Linear Technology and TI. Michael KellettArticle: 85798
On Thu, 16 Jun 2005 14:24:30 +0200, Adarsh Kumar Jain wrote: > I was recently evaluating Synplify Pro as i was getting pushed to the corner > in terms of area usage on the XC2VP7. > This is what i found: > > The comparison is not EXACT since there are probably some differences in the > design constraints, but it certainly gives a fair idea. The designs are > constrained for 40 MHz System Clock. (but the comparison is also valid for > 80 MHz, as in my opinion, either frequency is on the low end of what these > devices can handle). > > Also, not ALL the error checking is implemented. > > Resource ISE6.3sp3 Synplify > 8.0 > > Flip Flops 4170 > 3945 > > 4 Input LUTs (Logic) 5503 3923 > > 4 Input LUTs(Route-thru) 814 309 > > 4 Input LUTs(Total) 6318 4232 > > Occupied Slices 4075 3330 > 4928(Total) (Overall 15 % Savings !!!) > > > > The comparison is not EXACT since there are probably some differences in the > design constraints, but it certainly gives a fair idea. The designs are > constrained for 40 MHz System Clock. > > i agree its not a "fair" comparison as i was using ise6.2sp3 vs Synplify > 8.1. > > cheers, > > adarsh > Which switch did you use for hierarchy in XST? I've found that it does much better if you tell it to flatten the hierarchy.Article: 85799
Jan Panteltje wrote: > <snip> > >>Assume the image sensor's voltage rises linearly w.r.t exposure time (or any >>charactized waveform). > > I do not see what motion in one direction or an other has to do with exposure > time. > Exposure time has to do with how much sensitivity you have to light. > Of cause when your exposure time get freaky long, you get motion blur. > > <snip> > >>How does my idea work? > > What idea? > I believe he's talking about a single frame exposure not video. He's talking about motion during the exposure and I assume a problem of varying affects of the motion on the different sensors (e.g. R,G and B) that combine to give the final image. I don't have any feedback for him other than to suggest he try to state his problem better next time especially when cross-posting so broadly. -- ced -- Chuck Dillon Senior Software Engineer NimbleGen Systems Inc.
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