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
you don't link.. you replicate! Simon "vssumesh" <vssumesh_asic@yahoo.com> wrote in message news:1128426984.140362.116640@z14g2000cwz.googlegroups.com... > The problem is i want that in a single chip. How can i link those huge > control signals out of FPGA. > But i am still wondering why the ISE is not working with my design. Ok > any way i am proceeding with 120 registers and will let all of you know > the results. > Thanks for all the advice and suggestions. >Article: 90126
you guess wrong... The WEB data is meant for people who will only ever want one. It doesn't consider the company or the business case. Simon "Peter Rauschert" <usenet@rauschert-online.de> wrote in message news:i817k1pua4kamn8a1qqm1pkf3fcmhva3sd@4ax.com... > Hi Antti! > > I just checked the website of AVNET for availability. Guess its a good > thing to call them. > > Do you have informations concerning the special properties of the > Virtex 4 Engineering Samples? > > Peter > > >"Peter Rauschert" <usenet@rauschert-online.de> schrieb im Newsbeitrag > >news:24r6k1962p1tlj7kskbpe9a9gmn72llub5@4ax.com... > >> Hi! > >> > >> I just asked my distributor for availiable Xilinx XC4VFX devices and > >> found an XC4VFX20-10FF672CES2. > >> > >> Since I guess that ES means "Engineering sample", I was looking for > >> informations about its limitations compared to the final device. But > >> unluckily I failed. > >> > >> Maybe someone can give me a hint where to get these informations? > >> > >> Since I was inititally looking for a XC4VFX40, I figured out that this > >> is not available currently. Is this right? Does someone know when this > >> device gets available? > >> > >> Thank you very much, > >> Peter > > > >Hi, > > > >Talk more to your disti, they should be able to get you shipping date (we > >did) for FX40 (no ES), another thing if you will happy with that. As of > >today all FX parts that may be available are ES. Again pressure your disti, > >Xilinx may be able to ship the parts you need, even if they dont show as > >available by the disti-first look > > > >Antti > > >Article: 90127
or why not go to the extreme and give it a meaningful name? like clk_100MHz Simon "Nicolas Matringe" <nic_o_mat@msn.com> wrote in message news:1128500245.346115.215010@g44g2000cwa.googlegroups.com... > CMOS wrote: > > what im asking is, we have "clock", which is an input to the entity and > > a signal called "clk" declared in the entity. The input "clock" is > > mapped to the signal "clk". In all other places only "clk" is used, but > > "clock" is never used. What is the difference of doing this from just > > using "clock" everywhere and eliminating "clk" altogether? > > I'd ask the question the other way round: why not call the input port > 'clk'? > > Nicolas >Article: 90128
codejk, What kind of floating-point number is it? IEEE754? Single or double precision? Are those the actual dimensions of your matrices? It looks to me like you have 9 multiplications, 6 additions and 2 divisions to do every 80ns. I work this out to be 212.5MFLOPS. According to: http://www.xilinx.com/ipcenter/processor_central/microblaze/microblaze_fpu.htm The best performance you're going to get from a FPU-enabled microblaze running on a V4 is 33MFLOPS (clocking at 200MHz). I work out about 22-23 MFLOPS being the most you would get for your particular instruction mix. Reduce this again for the lower performance of the Spartan 3, then you're looking at being a long way off from what you need. So, FPU-enabled microblaze is a good suggestion, but when you factor in the 'result every 80 ns constraint' it's unfortunately not viable. All is not lost though, even with Spartan devices these days you can get well into the GFLOPS in terms of floating-point performance. To do it you need to take advantage of the vast real-estate and data-throughput capabilities of the devices. What I would suggest are floating-point cores. Pipelined, and with multiple instantiations. With these you could easily obtain the performance you need. You would have to pay for the IP, but once you had it you could very easily achieve your design with minimum headaches. Of course, if you don't have the cash to fork out on this, then you'll have no choice but to look at another way of doing it, fixed point for example... Tell us how you get on, RobinArticle: 90129
> Then of course there's HardCopy2, which, like EasyPath, only needs to be
> tested with the user design _but also_ is a lot smaller in die size.
> Thus:
> Better Yield+Shorter Time+Smaller Area = Even Lower Cost to Altera, which
> means even Lower Prices to customer. No ECO and no last-minute changes
> though, I'll give you that.
Shorter time? Lower cost? For an ASIC conversion product versus an FPGA?
Surely you jest, sir! So the mask set just magically creates itself and pays
for itself now, or what?
-Ben-
Article: 90130Firstly.. a 16-bit spi peripheral is just done with two spi transactions. Second.. don't use gated clocks. Third.. see two (can't repeat this often enough). Forth.. use a divide by two with a clock enable to generate the SPI clock. It will clean up all your problems. including sending on rising edge, receiving on falling edge. The only down side is it takes twice as long... so you wait 8 'busy_waits' instead of 4 .. usually it doesn't cause a problem. Simon "Marco" <marcotoschi@nospam.it> wrote in message news:dhu826$vdo$1@news.ngi.it... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:dhu2oi$a4c$05$1@news.t-online.com... > > "Marco" <marcotoschi@nospam.it> schrieb im Newsbeitrag > > news:dhu289$tce$1@news.ngi.it... > >> Hallo, > >> I have made a clock divider using a counter connected to master clock and > > a > >> comparator. > >> > >> The comparator has a clock enable to avoid "gating-clock". > >> > >> Now my trouble. I have connected some logic blocks to the new clock, but > > in > >> this way it has high load and delay. > > > > 1) you should connect ALL clk inputs to master clock (not the new clock) > > and > > use clock enables > > 2) why do you reinvent the wheel? the opb_spi core is provided by xilinx > > for > > free! > > 3) SPI is easier to implement as FSL peripheral :) > > 4) in most cases the GPIO bitbanged SPI is fastest to implement, and takes > > no resources (except gpio pins) sure takes some sw overhead > > > > antti > > > > > > I have tried using a BUFG, and I think it could be a work around. > > I would know if there are other solution when load is high. > > Marco > >Article: 90131
have you ever listened to the radio and heard those magic words "and coming up after 8am....." Simon "Antti Lukats" <antti@openchip.org> wrote in message news:dhua46$3eh$00$1@news.t-online.com... > > "Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag > news:4342A6AA.6020500@xilinx.com... > > Antti Lukats wrote: > > > "Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag > > > > > >>We have improved the VGA quality on the upcoming ML405 and ML410 boards > > >>that will be released early next year. > > >> > > >>Ed > > > > > > > > > Hi Ed, > > > > > > your comment about 405 "to be released early next year" (2006) sounds > like > > > firm indication that Xilinx has serious problems with 4FX? The ML405 was > > > announced no later than jan 2005 (maybe earlier), now you are saying > that it > > > is coming sometime in 2006 ? Why announce products that are 'maybe' > coming > > > more than a year later? I would have expect ML405 to be available by > now. > > > Well if there is really an issue with 4FX that would explain why no FX > > > boards are available from Xilinx online shop. Just wondering. > > > > > > > Right now almost all of the FX20 silicon is being shipped to customers > > on a priority basis. We do have fully functional ML405 and ML410 boards > > in house that we are now making available to our processor specialist > > FAEs and available on a limited loaner basis to customers and this will > > increase over coming months. > > > > It takes 3-4 months from this point before we can complete all of the > > rest of the material in order to turn it from early access board that > > requires a knowledgeable and trained person to use it into a general > > availability product with full manufacturing tests, documentation, > > reference designs and packaging. Also, our internal processes has > > certain requirements that must be met before we place boards in the Xilinx > > Online Store, this should happen 1-2 months after the boards are > > available from our distributors. > > > > We haven't formally announced the ML405 and ML410, but we have shown > > them at trade shows and forums such as this as an upcoming development > > vehicle for Virtex-4. We do this so that our customers and partners can > > understand what our plans our for support collateral so that they can > > develop their own product development and test roadmaps. > > > > Ed > > Ok that explains it a bit. I expected that Xilinx internally should have > ml405 boards. So the deal is that the boards are there, but are just not > going to be made available until someday in 2006. > > I still dont see a point to have the ml405 being mentioned in Xilinx > publications in JAN 2005, and then ship sometime in 2006 > > Antti > > > > >Article: 90132
In saying that Peter, I had a design I was working on last year using a 986 kHz clock (or there abouts) and a 16.384MHz clock.. and metastability 'glitches' hit 1 in 10 times... we use a Spartan 2e :-) with the usual double flip flop it was cured :-) Simon "Peter Alfke" <peter@xilinx.com> wrote in message news:1128457315.762325.327300@o13g2000cwo.googlegroups.com... > "Metastability" is a popular word to scare inexperienced designers. > > If you run a 1.8 MHz clock (even with a similar asynchronous data > rate), your chance of having a 3 ns extra metastable delay is once per > billion years (at 24 MHz it would be only 5 million years). > For every additional ns of acceptable settling time, the > mean-time-between-failure increases at least a million times. (see > XAPP094 on the Xilinx website) > The probability of your flip-flop failing during the life of this > universe (even if you do nothing) with more than 10 ns of > unaccounted-for delay is so minute it is practically zero. > There are more important things to worry about, forget metastability... > Peter Alfke, Xilinx Applications (who actually has created quantitative > data about metastability) >Article: 90133
I think the frequencies are real too.. we use 10 Xilinx FPGA's in one product.. its cheaper than ASIC's in low volumes... and we get a good price. :-) The main external clocks are 8 kHz, 968 kHz, 16.384 MHz, 25 Mhz.. I have been known to splash out and use 32.768 MHz too. you may notice the telco frequencies here... 25 is 1/2 of 50 (Ethernet) the rest are 4 x E1. Simon "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1128486239.789657.247430@z14g2000cwz.googlegroups.com... > Bob, I agree with everything you wrote, but the original posting > mentioned 1.8 MHz and 24 MHz. I did not make that up. It sure is not a > typical modern design... > I think we would agree that such a slow design will, almost inevitably, > have a few ns slack to accomodate a possible metastable delay. > If you use a 500 Mhz clock to synchronize a 400 MHz asynchronous data > stream, the problem is much more real. > I am so happy that we went to the trouble of measuring the delays on > real (V2Pro) silicon, same as we had done with XC4000 years before. > That gives us quantitative data. Less arm-waving. > > The rule still is: If you have reason to worry about metastability, > give the flip-flop in question maximum slack to settle, and have it > drive only one near-by synchronizing flip-flop. Without that > precaution, you might get into trouble... > Peter Alfke >Article: 90134
Hi codejk,
> Nowdays I'm focusing on building some design for
> multiplication of matrices that each element is
> floating point number.
> Is this multiplication and division are possible
> using Spartan3 device with VHDL?
> Or should I convert each floating point numbers
> to integers and calculate all after that?
A library of floating-point IP blocks is available in the latest release of
Coregen. If you have the ISE tools (not web-pack), go take a look. A
fixed-point implementation may be smaller and simpler, but you might need
bigger bit-widths to cope with the dynamic range.
What you specified (3x3 matrix times 3x1 vector + normalize result) might be
possible, but it depends on your processing requirements. You would need at
least one FP multiplier, one FP adder and one FP divider. You said in
another post that you needed a result every 80ns, but that pipelining was
not a problem (i.e. latency doesn't hurt, I guess). You have 9 multiplies, 6
adds and two divides to do. The adder and multiplier hardware could easily
be time-multiplexed between those operations (~9ns cycle time for the
multiplier is easily enough). Size-wise, the FP matrix multiply portion of
your design would need 4 MULT18x18s and less than 500 slices (assuming
single-precision).
The divide is the killer. A fully-parallel FP divider will currently set you
back around 3000 slices. So add on your sequencing logic (state machine) to
schedule all this compute, plus some buffering registers, and you're looking
at ~5000 slices running at (say) 120-150MHz. So probably the very smallest
S3 device would be too small. Depends what else you need in there, and how
you're interfacing it to the rest of your system.
Incidentally, what is your application? 3-D graphics, at a guess?
Cheers,
-Ben-
Article: 90135"Metastability" or "delay matching"? I was never bitten by the first, but the second... By the way, a single flip-flop solves the second... Ricardo. Simon Peacock escreveu: > In saying that Peter, I had a design I was working on last year using a 986 > kHz clock (or there abouts) and a 16.384MHz clock.. and metastability > 'glitches' hit 1 in 10 times... we use a Spartan 2e :-) > with the usual double flip flop it was cured :-) > > > Simon > > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:1128457315.762325.327300@o13g2000cwo.googlegroups.com... > >>"Metastability" is a popular word to scare inexperienced designers. >> >>If you run a 1.8 MHz clock (even with a similar asynchronous data >>rate), your chance of having a 3 ns extra metastable delay is once per >>billion years (at 24 MHz it would be only 5 million years). >>For every additional ns of acceptable settling time, the >>mean-time-between-failure increases at least a million times. (see >>XAPP094 on the Xilinx website) >>The probability of your flip-flop failing during the life of this >>universe (even if you do nothing) with more than 10 ns of >>unaccounted-for delay is so minute it is practically zero. >>There are more important things to worry about, forget metastability... >>Peter Alfke, Xilinx Applications (who actually has created quantitative >>data about metastability) >> > > >Article: 90136
I didn't understand that. How can i interconnect the huge routing signals between the FPGA's.Article: 90137
"Simon Peacock" <simon$actrix.co.nz> wrote in message news:4343a67a@news2.actrix.gen.nz... > Firstly.. a 16-bit spi peripheral is just done with two spi transactions. > I tried in the past, and it didn't work. I must send a clock enable to the ADC, wait for 5 clock cycle and then receive 16bit. When I receive 2 "packets" of 8 bit I loose some bits between the first and the second packet. The only way is to receive a packet of 16 bit sequentially. > Second.. don't use gated clocks. > I always have used FF with clock enable, but the clock enable now has high load (8-10 from report of XST synthesis). Here my trouble... I would avoid high load to clock enable > Third.. see two (can't repeat this often enough). > > Forth.. use a divide by two with a clock enable to generate the SPI clock. I think you're talking about a dcm. I can't because the max freq. supported by ADC is 2.9 MHz... In the past I tried with divide by 32 to obtain a freq. of about 1,5 MHz > It will clean up all your problems. > including sending on rising edge, receiving on falling edge. The only > down > side is it takes twice as long... so you wait 8 'busy_waits' instead of 4 > .. > usually it doesn't cause a problem. > > > Simon Many Thanks for your answer and sorry to everyone for my bad english. MarcoArticle: 90138
"Jecel" <jecel@merlintec.com> wrote in message news:1128483437.961648.169400@o13g2000cwo.googlegroups.com... > Ed McGettigan wrote: >> With every board that is designed you have to make some trade offs >> between peripherals, performance, power and cost. The ML401/2/3 >> boards are loaded with features at a very reasonable price point >> and in order to do that we had to make some compromises in certain >> areas. > > Indeed these boards are a great value and far cheaper than what it > would cost me to build something similar, which is not common for > development kits. Thank you for your explanation. I hadn't notice the > 15 bit per pixel llimitation of the ML403. > > I am still deciding if it is worth doing the extra VGA board - an > alternative is to reduce the vertical refresh to 56 Hz or something > like that. > I have not tried pushing the VGA clock, but I'd be surprised if the DAC could not run much faster. The ADV7125 comes in speed grades: 50 MHz, 140 MHz, 240 MHz and 330 MHz. I would image the 50 MHz part would run comfortably at 150 MHz.Article: 90139
Hi Ben Jones, > Shorter time? Lower cost? For an ASIC conversion product versus an FPGA? > Surely you jest, sir! So the mask set just magically creates itself and > pays for itself now, or what? OK, ok, forgot about the NRE to create the wiring/config layers. Blushing here. Then again, as far as I know, the setting up of the EasyPath part's testing program isn't free either. However, once actual HC2 production of a design has started, most definitely yes - most layers are pre-fabricated, so once a certain design batch needs to be produced, only the top few (2? 3?) metal layers need to be deposited, either from from stock wafers or straight in the production pipe. Also, assuming the same number of wafer defects (it's the same process after all), given the smaller die, the yield will automatically be higher. Best regards, BenArticle: 90140
you can have any name for clk and clock. what im asking is a technical question and not on naming standards of VHDL. Put it another way, my problem is, why do we need to map the input to a signal declared in the declaration and use that signal , rather than just using input. will it result in a different circuit being synthezised? CMOSArticle: 90141
Simon, your problem was not metastability. Since many designers do not really understand the metastable mechanism, it gets blamed for all mystery problems. In many cases the problem is caused by synchronizing an asynchronous input in more than one flip-flop in parallel. This will inevitably fail, because the two flip-flops have different capture times. But that has nothing whatsoever to do with metastabilty... Peter AlfkeArticle: 90142
Hi G.H.,
G.H. Hardy wrote:
> Kevin Brace wrote:
>
>>Hi,
>>
>>If you are considering purchasing a Xilinx FPGA-based PCI development
>>board, and is planning to use it for personal use, I recommend
>>purchasing a personal version of BDS XPCI PCI IP core.
>
>
> Is this an ngc netlist with verilog wrappers as was described by Antti?
> Also, the most important issue to me is whether this is something that
> I can use with the free version of Web ISE or whether I have to
> purchase a full ISE to use it?
>
>
The personal version of BDS XPCI PCI IP core will be supplied
as NGO (.ngo) netlist, similar to NGC netlist in a sense that they are
both not easily recognizable by humans.
Like Xilinx LogiCORE PCI, the NGO netlist gets instantiated by the
Verilog HDL or VHDL wrapper file.
Yes, BDS XPCI PCI IP core fully supports ISE WebPACK, so assuming that
ISE WebPACK is adequate, there is no need to purchase the paid version.
>>BDS XPCI PCI IP core comes with a PCI testbench for Verilog HDL which
>>allows the user to simulate the design extensively on an HDL simulator
>>like ModelSim before firing up the FPGA.
>
>
> That's excellent. Will it run within the evaluation version of ModelSim
> bundled with Web ISE or even better, will it run in Xilinx's free
> simulator?
>
> Thanks,
> GHH
>
Yes, you can use ModelSim XE-Starter that comes with ISE
WebPACK as a simulator.
The PCI testbench comes with compilation scripts for ModelSim.
That will make your cost of developing a basic PCI device to the cost of
a Xilinx FPGA-based PCI prototype board + BDS XPCI PCI IP core +
download cable + shipping + sales tax.
I am not sure what you mean by "Xilinx's free simulator," but
if you mean the ISE 7.1i's embedded HDL simulator (ISE Simulator), it is
not supported because I have not had the chance to evaluate it.
If Xilinx ever makes it free by including it with ISE WebPACK (Perhaps,
they might at some point.), we can probably support it.
That being said, in theory the PCI testbench contained in BDS XPCI PCI
IP core should work on almost any Verilog simulator, so although we
don't officially support the ISE Simulator, if the user can compile all
the relevant files without errors, it should work.
Kevin Brace
--
Brace Design Solutions
Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available
for as little as $100 for non-commercial, non-profit, personal use.
http://www.bracedesignsolutions.com
Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.
Article: 90143I tried Project > Cleanup Project Files, and that didn't seem to help. Are there any other implementation files that I should delete which isn't taken care of by that? Thanks, -- Matt "Adarsh Kumar Jain" <adarsh.jain@cern.ch> wrote in message news:dhqt4u$gcb$1@sunnews.cern.ch... > you can try to delete the project implementation files and retry. I also > had this portability error but with a different message but it went off > once i deleted the project implementation files. > Cheers, > Adarsh > "Matthew Plante" <maplante@iol.unh.edu> wrote in message > news:dhjtlc$80c$1@tabloid.unh.edu... >> Has anyone else received this error with ISE 7.1i? I added a peripheral >> to my embedded system, and when I re-synthesize it it XST, I get: >> >> ERROR:Portability:3 - This Xilinx application has run out of memory or >> has encountered a memory conflict. Current memory usage is 798040 kb. >> Memory problems may require a simple increase in available system memory, >> or possibly a fix to the software or a special workaround. To >> troubleshoot or remedy the problem, first: Try increasing your system's >> RAM. Alternatively, you may try increasing your system's virtual memory >> or swap space. If this does not fix the problem, please try the >> following: Search the Answers Database at support.xilinx.com to locate >> information on this error message. If neither of the above resources >> produces an available solution, please use Web Support to open a case >> with Xilinx technical Support off of support.xilinx.com. As it is likely >> that this may be an unforeseen problem, please be prepared to submit >> relevant design files if necessary. >> >> Any ideas? >> >> >> Thanks, >> -- Matt >> >> >> +-- >> |Matthew Plante >> | University of New Hampshire >> | InterOperability Lab >> | Research & Development >> | SMTP: maplante@iol.unh.edu >> | Phone: +1-603-862-0203 >> +- >> >> > >Article: 90144
I use similar structures in Synplify all the time. I don't see why XST would do a poor implementation of the same thing as long as it knows that useA and useB are wires and not to integrate the combinatorial equations for useA and useB into the adder. I modified the diagram to illustrate how the representation fits your need. "Sylvain Munaut" <com.246tNt@tnt> wrote in message news:4342f488$0$28231$ba620e4c@news.skynet.be... > John_H wrote: <snip> > > q <= (useA ? A : 0) + (useB ? B : 0); // 1 level > > Actually, I don't see how to fit your representation (useA useB) into a > single level ... > > What I wanted the tool to do is : (pt_n is not passthru) Following diagram modified for useA and useB above: > . cout > . _|_ > . ,--/___\ CYMUX > . | | | > . ______ | | | > . a(b) ---------| | | | | ____ XORCY > . b(n) ------x--| LUT4 |-x----------\\ \_____ > . useB ---x--|--| | | x----//___/ > . useA ---|--|--|______| | | > . | | / | > . | | __ / | > . | '------| \ _/ cin > . '---------|__/ > . MULT_AND > > > SylvainArticle: 90145
Ben,
-snip-
> Sounds quite reasonable. So, technologically there's nothing holding Altera
> back in investing in a few extra ("standard") device testers and, as an
> intermediate price-reduction step, doing same under the hereby trademarked
> name "Crippledie" (come to think of it, sounds great as the title of an
> ultra-violent FPS game taking place in a hospital or a leper colony too -
> I'll have a chat with my local EA Games marketing guy).
Except that 'EasyPath' has patents pending with a number of claims that
would prevent Altera from having an EasyPath clone (without paying us
for the rights to do so).
> I can't imagine that only partially testing an ASIC is patentable - but then
> again, one-click-shopping is patentable as well according the USPTO so I
> wouldn't be surprised.
Imagine if you will a car company that makes a top of the line car, and
sells it for a lot of money. Now emagine the same company establishing
a different distributorship for a lower cost version of the similar car,
less chrome, less power windows, etc. (but basically all the same
subcomponents).
Happens all the time, doesn't it?
Jaguar/Volvo/Lincoln/Ford. Buick/Potiac/GMC/Chevy. Lexus/Toyota. ...
>
> Then of course there's HardCopy2, which, like EasyPath, only needs to be
> tested with the user design _but also_ is a lot smaller in die size.
>
> Thus:
>
> Better Yield+Shorter Time+Smaller Area = Even Lower Cost to Altera, which
> means even Lower Prices to customer. No ECO and no last-minute changes
> though, I'll give you that.
>
> Am I right?
Yes, but ....
An ASIC is always going to be lower cost, only if the volume can
overcome the NRE cost. Now if Altera is happy to eat a majority of the
NRE, and have lower margins (which, by the way they announced last
financial report), then the customer benefits (obviously).
But, for every change, the whole cost picture is thrown out, as the line
stops until the new good parts can be delivered.
Since H2 is not even pin compatible with the S2, the pcb must be
redesigned. In some cases (most) the signal integrity analysis of all
IOs must be repeated. I have heard a case where the cost of the H2 is
very high, as the package is very expensive (that the customer wants).
To go from flip chip, back to a cheap wirebond package may result in
Signal Integrity issues that can not be solved!
(By the way, I will not even go into how the H2 is not even a logic
equivalent to S2: there are features and components that are just
different between the two!)
With EasyPath, you go from the working solution, to a less costly
working solution with no redesign whatsover, and no risk at all.
Seems like a simple problem to me: choose H2 and have a potentially
career limiting experience, or choose EasyPath and go home happy every
night....
Austin
Article: 90146Peter, Best to contact your Xilinx FAE for your area. They will be happy to share the errata sheet with you for the device in question. First try here: http://tinyurl.com/a2m2a Austin Peter Rauschert wrote: > Hi Antti! > > I just checked the website of AVNET for availability. Guess its a good > thing to call them. > > Do you have informations concerning the special properties of the > Virtex 4 Engineering Samples? > > Peter > > >>"Peter Rauschert" <usenet@rauschert-online.de> schrieb im Newsbeitrag >>news:24r6k1962p1tlj7kskbpe9a9gmn72llub5@4ax.com... >> >>>Hi! >>> >>>I just asked my distributor for availiable Xilinx XC4VFX devices and >>>found an XC4VFX20-10FF672CES2. >>> >>>Since I guess that ES means "Engineering sample", I was looking for >>>informations about its limitations compared to the final device. But >>>unluckily I failed. >>> >>>Maybe someone can give me a hint where to get these informations? >>> >>>Since I was inititally looking for a XC4VFX40, I figured out that this >>>is not available currently. Is this right? Does someone know when this >>>device gets available? >>> >>>Thank you very much, >>>Peter >> >>Hi, >> >>Talk more to your disti, they should be able to get you shipping date (we >>did) for FX40 (no ES), another thing if you will happy with that. As of >>today all FX parts that may be available are ES. Again pressure your disti, >>Xilinx may be able to ship the parts you need, even if they dont show as >>available by the disti-first look >> >>Antti >> > >Article: 90147
John_H wrote: > I use similar structures in Synplify all the time. I don't see why XST > would do a poor implementation of the same thing as long as it knows that > useA and useB are wires and not to integrate the combinatorial equations for > useA and useB into the adder. I modified the diagram to illustrate how the > representation fits your need. > Yeah, I confused the two choices of CYMUX ... My bad. The two representation works just fine. But XST doesn't understand yours either ... it also uses two level with useA and useB ... Sylvain > "Sylvain Munaut" <com.246tNt@tnt> wrote in message > news:4342f488$0$28231$ba620e4c@news.skynet.be... > >>John_H wrote: > > <snip> > >>>q <= (useA ? A : 0) + (useB ? B : 0); // 1 level >> >>Actually, I don't see how to fit your representation (useA useB) into a >>single level ... >> >>What I wanted the tool to do is : (pt_n is not passthru) > > > Following diagram modified for useA and useB above: > > >>. cout >>. _|_ >>. ,--/___\ CYMUX >>. | | | >>. ______ | | | >>. a(b) ---------| | | | | ____ XORCY >>. b(n) ------x--| LUT4 |-x----------\\ \_____ >>. useB ---x--|--| | | x----//___/ >>. useA ---|--|--|______| | | >>. | | / | >>. | | __ / | >>. | '------| \ _/ cin >>. '---------|__/ >>. MULT_AND >>Article: 90148
Hi Bill, On Tue, 4 Oct 2005 12:16:04 +0200, "Bill" <billbill@telia.se> wrote: >Is the following a good way to avoid meta stability problems? The signal 'd' >is synchronous to a 1.8 MHz clock? And from your code I assume that the synchronizing clock is 24 MHz. The answer to yor question is that your solution is NOT a good way to "avoid" metastability. First, you can't avoid it, you can only make its effect lower probability. The way to make it lower probability is to have additional settling time within the synchronizer. Second, while your circuit is clever, it boils down to a two stage synchronizer, with logic (your median circuit) between the first and second stage. This logic subtracts from the resolving time available between the first stage and the second stage of your synchronizer. As is often the case with proposed circuits to help mitigate metastability in clock domain crossing circuits, what you have done is made the analysis of the behavior harder, but the result is not as good as just two flipflops. Peter's response to you is dead wrong in this part: >There are more important things to worry about, forget metastability... in this part: >If you run a 1.8 MHz clock (even with a similar asynchronous data >rate), your chance of having a 3 ns extra metastable delay is once per >billion years (at 24 MHz it would be only 5 million years). the assumption of 3 ns slack is unsupported, and if you are using Xilinx's crappy FPGA router (you don't say which product you are targetting) then there may be no slack regardless of what the cycle time is, although as clock rates drop the likelyhood of there being no slack diminishes. This is because the router stops trying to improve the route as soon as the timing specification is met. At this point there is no slack. This issue can be helped by adding specific timing constraints to the synchronizer circuit that force additional resolving time by specifying path requirements that are more demanding than the clock cycle time implies. in this part: >For every additional ns of acceptable settling time, the >mean-time-between-failure increases at least a million times. (see >XAPP094 on the Xilinx website) this rule of thumb depends on what product you are using. The 1E6 is for the latest devices. You may be using something else. Older technology may have numbers as low as 1E2. In summary, you will be better served with a simple two stage synchronizer, with as tight a timing constraint as you can use to maximize the slack time between the first and second flip flops. You can read FAR more on the subject at this URL: http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm >... your VHDL ... Philip Freidin =================== Philip Freidin philip.freidin@fpga-faq.org Host for WWW.FPGA-FAQ.ORGArticle: 90149
CMOS wrote:
> why do we need to map the input to a signal declared in the declaration
> and use that signal , rather than just using input.
We don't.
Input port IDs can be used directly anywhere
in the architecture on the
right side of an assignment.
my_var := my_inport;
Same for output port IDs used on the
left side of a signal assignment:
my_outport <= my_var;
-- Mike Treseler
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