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
Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3CCEAECB.C40196E9@xilinx.com>... Let me preface my message by saying that I use, and have used, and will continue to use, Xilinx for many applications. I've been very happy with the abilities of their hardware both from a standpoint of being moderately intutive and being able to absorb changes later that weren't anticipated (although I have to admit pretty strong annoyance with their SLOW and buggy software release after software release). That being said... let me respond to Austin's email. I was going to leave this thread alone, but Austin keeps pressing the issue... > I think everyone is missing the beauty of the EasyPath program. Perhaps *everyone* is not missing it - rather you've bought into your own marketing BS a little too much? You wouldn't be the first, nor the last. Hell, I bought into the market BS of my previous company all the way to it cancelling the project. > We run lots of silicon to a specific customer test program, and the yield for > just that functionality is good so that we can offer the parts at a price > competitive with the price of an ASIC. This is plain absurd. Easypath is not the end-all be-all that Xilinx makes it out to be. There is *almost* no way you can compete with a custom designed ASIC. There are a number of reasons for this, and I'll outline a few: 1. A custom ASIC die will always be smaller because it doesn't have to have all that unused logic and memory 2. A custom ASIC package will sometimes be smaller (lower I/O count) because you aren't forced to pick from Xilinx's choices 3. Because of the above two items, the piece price on the ASIC will usually be cheaper 4. A custom ASIC will typically burn less power, because of #1 above - and this is even when it is running 1.8V rather than 1.5V... -or- 4. A custom ASIC can be designed to whatever voltage(s) you have available so that you don't have to buy a 1.5V supply because the Virtex2 parts are the only thing running 1.5 volts. 5. Put items #2 and #4 together, and you can have a higher density product than you could have with EasyPath parts 6. Put #3 and #5 together and you now have some profit margin for your company, rather than giving your profit margin to Xilinx for the EasyPath parts. 7. Despite Xilinx showing that they can run incredibly high frequencies through their parts, when you have everyday designs out in the lab, our experience has been that 78 MHz is plenty hard to achieve with the devices that use > 65% of their LUTS. I suspect that Ray would say #7 is because of poor logic placement, and I'll bet money he is correct. So when is Xilinx going to start taking floorplanning seriously?! It doesn't have to mean admitting anything is wrong with your parts - just ask your marketing people. They've done such a good job on the EasyPath marketing that I'm sure they can come up with something showing that good floorplanning is good for the economy or environment or SOMETHING! Either that, or improve the placer, cause it does some really silly things with real world designs. So when would you use EasyPath? (remember after all of the above, at heart I *am* a fan of Xilinx) 1. Don't have resources for an ASIC group 2. Can't afford the risk and must get cost out of the product ASAP (no time for an ASIC) 3. Can't afford the resources to respin a PCB to make a pinout change for an ASIC. 4. Don't trust the ASIC group to have first pass success 5. When certain things converge, it may make sense. Say the amount of RAM you need matches up pretty good with a Virtex2 part, and it is available in a reasonable priced package. Or perhaps you are using most of the I/O on your packageand you don't have an application where power isn't one of the top issues. > Thus, no reason to redesign your IP into an ASIC for cost reduction, just > make the exact same decisions you would make anyway: freeze the program, > stop making changes, and sign up for a big order, with some NRE for the test > program. The phrase "some NRE" is misleading. The NRE that was discussed with us was on par with medium sized ASIC NRE's. And then if that weren't enough, don't forget the statement that you made in passing "sign up for a big order". I'm not kidding when I say that my manager laughed the EasyPath marketing people out of his office (ie, I'm not the only one with this opinion). [...] > This is a revolutionary concept, one that will change the face of the use of > programmable logic. Wow. Now that is truely a bold claim. I suspect you're wrong - but I try to approach things with an open mind, so I'm willing to wait a while and see. Since you're making a bold claim that we have to wait on, I'll make one too: As Xilinx increases logic density (say 500k logic cells), the routing required on the die is going to start to dwarf the amount of logic you have. IE, an exponentially increasing amount of routing is going to be required to guarantee moderate connectivity of logic. This is because even marginally good placement won't be good enough when you have that much logic. You're gonna need a top notch placer, and so far, we haven't seen that out of Xilinx's software group. I like the PROM idea that somebody else on this thread had. Burn the defect locations into the on-die PROM on each device that fails your 100% test. Then put them into bin's. No need to screw the customer for NRE plus a big order. Oh my, this has turned out to be longer than I intended - and I hope it doesn't project that bad an image of Xilinx. It's just the EasyPath program that I'm commenting on. If it is any relief, I own some Xilinx stock - that's how much I believe in the company. Best regards, MarcArticle: 42676
4 - xc4010 -6 pq208i 2 - xc2028xl bg352c 1 - xc95144xl cs144 2 - xc4013xl bg256c Unused. These are for sale. Make offer if interested. -- "If you're not a part of the solution, there's good money to be made in prolonging the problem."Article: 42677
Nicholas Weaver wrote: > > In article <3CCEEE48.1B6EA5BA@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> wrote: > > > > >> •You can deliberately delay the internal clock that drives the output in > >> question. > > > >Can you give details on this? Does it require the use of a DLL? Can > >the DLL be used independantly of the clock routing, that is, if I > >already am using all four clock buffers, can I use the DLL as a fifth, > >or do I need to delete one of the other clocks? > > Ick, if you are using all the clock buffers, this would be > problematic. Otherwise, you drive the I/O output flip-flops with a 90 > degree phase offset from the bus clock, asuming you would still meet > other timing constraints. > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu Then I have a couple of problems. 1) I am using all four of the global clock buffers (in fact I would like to use five or six). 2) Using a clock 90 degrees out of phase would give me an added 2.5nS of delay which would delay the data output by 2.5 nS. This may be workable, but if the input clock is also delayed (advanced) by 2.5 nS, then it won't work unless the clock is slowed to 12.5 nS. There is already very little margin on the read path. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42678
Bob, These are still plain old single ended IOs, and as measured in the lab, there is virtually no difference in ground bounce from a regular single ended IO. LVDS in Virtex II and Virtex II Pro are current sink and source differential drivers, and there is actually a large benefit from such drivers. Austin Bob Perlman wrote: > Austin - > > On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea > <austin.lesea@xilinx.com> wrote: > > >Bob, > > > >Spartan 2 uses external resistor networks to get the LVPECL levels, so there > >is no benefit from differential switching as regards to ground bounce. Each > >single ended IO is already switching rail to rail, and driving hard. Thus > >even though some of the current flows out comes back in on the other pin, a > >lot of current is flowing through power and ground. > > > >Austin > > The original poster wanted to use Spartan IIE which, if I'm reading > the data sheet correctly, supports LVPECL differential outputs > terminated with 100 ohms across the two signals. > > The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is > 1.06-1.43V, or~ 1.25V typical. This means that the current through > the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA. > > When the differential signal switches, one driver switches from source > to sink, while the other switches from sink to source. On the ground > side, one driver slews from sinking 8.5 mA to sinking nothing, while > the other slews from sinking nothing to sinking 8.5mA. Similar things > happen on the VCC side, except that current is being sourced rather > than sunk. > > Beyond a certain point, the strength of the drivers is moot; the > current into or out of the I/O pin will be limited by the transmission > line impedance. If we think of the differential lines as two 50-ohm > single-ended lines, the current needed to send a 0.85V delta V down > each line is 17mA, which is exactly the delta you get when you stop > sourcing 8.5mA and start sinking it, or vice versa. > > The balance isn't perfect, but the net di/dt on either the VCC or > ground paths should be considerably less than for single-ended > signals. > > Bob Perlman > ----- > Cambrian Design Works > http://www.cambriandesign.com > > > > >Bob Perlman wrote: > > > >> Hi - > >> > >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks > >> <hicksthe@egr.msu.edu> wrote: > >> > >> >Hi, > >> > I am seriously considering using a spartan2e to serve as a clock > >> >distribution generator for a lvpecl clock system. This clock system > >> >will be driving a total of 17 differential clocks. When I price the > >> >LVPECL chips the spartan2e looks very competetive. Also, it would give > >> >me the clock DLL to clean up my system clock. The question is that I > >> >have a total of 34 output lines that should be switching at the same > >> >time. The spec says 12 power and ground pairs in the chip and 3 > >> >simulatneous outputs per pair. Thus a total of 36 outputs. (one spare > >> >pair for me.) How do I split these up over the 12 power/ground pairs? > >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E). Where do > >> >I get 12 power/ground pairs from these 24 pins? > >> > >> If you're using differential outputs, the power and ground di/dt > >> should be significantly less than what you'd see for single-ended > >> signals. Assuming that the true and complementary transitions occur > >> in unison, one driver should be increasing its ground or VCC current > >> as the other driver's current is decreasing. The match isn't perfect, > >> but it should be pretty good. > >> > >> Ask Xilinx for diff pair power/ground guidelines; they should be less > >> stringent than the guidelines for single-ended signals. > >> > >> Bob Perlman > >> ----- > >> Cambrian Design Works > >> http://www.cambriandesign.com > >>Article: 42679
Jim, Sounds like something I would not want to use: just a simple linear current limiting response, please. Austin Jim Granville wrote: > Austin Lesea wrote: > > > > YD, > > > > Texas Instruments has a web page devoted to powering Virtex and Virtex > > E. > > > > National Semi, Linear Tech, Elantec, and many others all make either low > > dropout linear regulators, and/or switchers that can be used (and we use > > ourselves). > > > > Read app note 158, 450, and 451. > > > > http://www.support.xilinx.com/apps/appsweb.htm > > > > Look up 158 under Virtex, and 450 and 451 under Spartan II. > > > > Avoid parts that trip, foldback, or shut off. It is OK to trip, > > foldback, or shutoff only after a time delay (say 20 ms) in order to > > meet UL or VDE safety requirements. > > > > Many regulator parts today will start turning on, sense the current, and > > if the current exceeds some threshold, they will turn off, and then > > start up again. This is exactly the kind of behavior you must avoid. > > It will terminally confuse the startup logic of the Virtex, Virtex E, > > Spartan II, Spartan IIE, and they will not power ON. > > > > The regulator parts which have thermal shutdowns, and are linear current > > limiting all work fine. > > > > Avoid parts that say things like "high speed" as the FPGA is not an > > Intel chip, and doesn't require 20 amperes in 100 ns. > > > > Read the data sheet and be sure you can supply at least the minimum > > required current for power ON (ie 500 mA for most Virtex C grade parts). > > > > Austin > > What about the so called snap-action regulators ? > > -jgArticle: 42680
Jim, There is no issue with reliability: gate arrays ship with unknown defects present, and they work just fine forever. What are planning is actually much, much better. We have the complete reliabilty report ready for those who wish to review it (and believe me, the question was asked from day one by all customers we approached, and everyone so far is completely satisfied with the study). Austin Jim Granville wrote: > Austin Lesea wrote: > > > > All, > <snip> > > Do we care where the non-functional parts and pieces are? No. Do we > > want to spend anytime trying to identify what is broken? No. Do we > > want to fill experimenter bags with bogus parts that could be > > remarked, and sold on the grey market and cause untold grief for our > > real paying customers? Absolutely not. (anyone remember the grief on > > bad EPROMs that were re-marked as good, and resold about twenty years > > ago?). > > I had seen this as a risk exposure, and since you have now mentioned > it, > what actually stops these devices comming back to bite users ? > > > This is a revolutionary concept, one that will change the face of the > > use of programmable logic. > > Sorry, but not at the MOQ and NRE's.... > > As to revolutionary ? - I've heard stories about russian programmers > being given chips with an errata tagged to each device. > They had to work around the errata on a batch basis ! > > -jgArticle: 42681
Austin Lesea wrote: > > Jim, > > Sounds like something I would not want to use: just a simple linear current > limiting response, please. My understanding of 'snap action' regulators, is they deliver a fast Vcc ramp, on slower inputs, by waiting until the Vin is high enough to delivery Vout. - ie unlike simple linear regulators, they hold OUT off, until Vin is reasonably high, then enable it. Given the Vcc issues of many Logic devices, it sounded like a good idea to me. - jgArticle: 42682
Austin Lesea wrote: > > Jim, > > There is no issue with reliability: gate arrays ship with unknown > defects present, and they work just fine forever. > > What are planning is actually much, much better. > > We have the complete reliabilty report ready for those who wish to > review it (and believe me, the question was asked from day one by all > customers we approached, and everyone so far is completely satisfied > with the study). You missed the point. You mentioned : " parts that could be remarked, and sold on the grey market and cause untold grief for our real paying customers? " My question, was what stops that happening ? ( customer honesty ? ;) -jgArticle: 42683
In article <15881dde.0204301227.16749c14@posting.google.com>, Marc Randolph <mrand@my-deja.com> wrote: >7. Despite Xilinx showing that they can run incredibly high >frequencies through their parts, when you have everyday designs out in >the lab, our experience has been that 78 MHz is plenty hard to achieve >with the devices that use > 65% of their LUTS. > >I suspect that Ray would say #7 is because of poor logic placement, >and I'll bet money he is correct. So when is Xilinx going to start >taking floorplanning seriously?! It doesn't have to mean admitting >anything is wrong with your parts - just ask your marketing people. >They've done such a good job on the EasyPath marketing that I'm sure >they can come up with something showing that good floorplanning is >good for the economy or environment or SOMETHING! Either that, or >improve the placer, cause it does some really silly things with real >world designs. There are TWO big changes which need to be made to the toolflows: either at the Xilinx backend level or one up (during synthesis). The first is datapath placement. Simulated anneiling is SOOO F)@#*$@ borken for datapaths that tweaking it is not really going to help. I've argued that it is the synthesis tool's job, but barring that, the placer should do a much better job. The second is C-slow retiming. Many synthesis tools (eg, Symplify Pro, FPGA Compiler) already support retiming (moving registers to balance delay paths). Allowing C-slowing within a module is a very small extension (replace each logical register with C registers before applying retiming, and two different memory options: shared or split), but a huge win in performance and best done in the tools. If there are no feedback loops, this is a time-C repipelining. Otherwise, it is creating a block which interleaves C separate streams. There are huge numbers of "free" registers in many of these 75 MHz designs. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42684
In article <3CCF16DD.77EF@designtools.co.nz>, Jim Granville <jim.granville@designtools.co.nz> wrote: >You missed the point. You mentioned : >" parts that could be remarked, and sold on the grey market > and cause untold grief for our real paying customers? " a) How big is the gray market for the top size xilinx chips? b) Plain, evident packaging. If you laser enscribe the package, AND drill a small, known hole or small, known cut in the side of the package, such packages are instantly verifiable as being from the easypath side of things. OR even just use a slightly different alloy (enough to make a color difference) for the metal on the BGA. >My question, was what stops that happening ? ( customer honesty ? ;) > >-jg -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42685
Austin - I know they're conventional single-ended I/Os; I thought I made that clear in my analysis (I assumed that the drivers both source and sink current; real PECL drivers only source current). I'm not sure why you mentioned LVDS drivers, but they also source and sink. If you're not seeing lower ground bounce for Spartan IIE differerential LVPECL in the lab, it would be useful to figure out why. If you're not seeing lower ground bounce, I have to wonder if the true and complementary transitions are simultaneous or near-simultaneous. If they're not, that could spell big trouble for the receiver. When lab results are counter-intuitive, it pays to find out why. Bob Perlman ----- Cambrian Design Works http://www.cambriandesign.com On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >Bob, > >These are still plain old single ended IOs, and as measured in the lab, there is >virtually no difference in ground bounce from a regular single ended IO. > >LVDS in Virtex II and Virtex II Pro are current sink and source differential >drivers, and there is actually a large benefit from such drivers. > >Austin > >Bob Perlman wrote: > >> Austin - >> >> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea >> <austin.lesea@xilinx.com> wrote: >> >> >Bob, >> > >> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there >> >is no benefit from differential switching as regards to ground bounce. Each >> >single ended IO is already switching rail to rail, and driving hard. Thus >> >even though some of the current flows out comes back in on the other pin, a >> >lot of current is flowing through power and ground. >> > >> >Austin >> >> The original poster wanted to use Spartan IIE which, if I'm reading >> the data sheet correctly, supports LVPECL differential outputs >> terminated with 100 ohms across the two signals. >> >> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is >> 1.06-1.43V, or~ 1.25V typical. This means that the current through >> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA. >> >> When the differential signal switches, one driver switches from source >> to sink, while the other switches from sink to source. On the ground >> side, one driver slews from sinking 8.5 mA to sinking nothing, while >> the other slews from sinking nothing to sinking 8.5mA. Similar things >> happen on the VCC side, except that current is being sourced rather >> than sunk. >> >> Beyond a certain point, the strength of the drivers is moot; the >> current into or out of the I/O pin will be limited by the transmission >> line impedance. If we think of the differential lines as two 50-ohm >> single-ended lines, the current needed to send a 0.85V delta V down >> each line is 17mA, which is exactly the delta you get when you stop >> sourcing 8.5mA and start sinking it, or vice versa. >> >> The balance isn't perfect, but the net di/dt on either the VCC or >> ground paths should be considerably less than for single-ended >> signals. >> >> Bob Perlman >> ----- >> Cambrian Design Works >> http://www.cambriandesign.com >> >> > >> >Bob Perlman wrote: >> > >> >> Hi - >> >> >> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks >> >> <hicksthe@egr.msu.edu> wrote: >> >> >> >> >Hi, >> >> > I am seriously considering using a spartan2e to serve as a clock >> >> >distribution generator for a lvpecl clock system. This clock system >> >> >will be driving a total of 17 differential clocks. When I price the >> >> >LVPECL chips the spartan2e looks very competetive. Also, it would give >> >> >me the clock DLL to clean up my system clock. The question is that I >> >> >have a total of 34 output lines that should be switching at the same >> >> >time. The spec says 12 power and ground pairs in the chip and 3 >> >> >simulatneous outputs per pair. Thus a total of 36 outputs. (one spare >> >> >pair for me.) How do I split these up over the 12 power/ground pairs? >> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E). Where do >> >> >I get 12 power/ground pairs from these 24 pins? >> >> >> >> If you're using differential outputs, the power and ground di/dt >> >> should be significantly less than what you'd see for single-ended >> >> signals. Assuming that the true and complementary transitions occur >> >> in unison, one driver should be increasing its ground or VCC current >> >> as the other driver's current is decreasing. The match isn't perfect, >> >> but it should be pretty good. >> >> >> >> Ask Xilinx for diff pair power/ground guidelines; they should be less >> >> stringent than the guidelines for single-ended signals. >> >> >> >> Bob Perlman >> >> ----- >> >> Cambrian Design Works >> >> http://www.cambriandesign.com >> >>Article: 42686
Jim, I saw something like this just recently that was a problem. The power supply (this was a switcher) waiting for the input to get to say about 2 volts, and then it turned ON. The output ramped from 0 to 1.8 Volts in about 40 microseconds (!!! Wow !!!). Now as you may know we specify our minimum start up current from 2 ms to 50 ms, and anything below 2 ms is considered unknown territory and isn't tested, or characterized. Now we know that the current needed to reliably start up a V1000E for example, in 40 us may be anywhere from 2 amperes to ten amperes. This is partly from the bypass capacitors on the board (I = C dV/dt), and partly from the turn on behavour of the V1000E (more current with faster ramps). Now if the power supply had just continued to supply a steady linearly increasing, or at least not a decreasing current, everything would have been OK. But no, the 'evil' supply folded back to 1/4 of the peak current it was delivering, and then the poor V1000E was stuck at 0.6 Vdc on Vccint forever. The solution was to remove the foldback to 1/4 Imax, and to slow down the rate at which the power supply woke up after the input voltage got to the 2 V input level. If you have a data sheet URL, just send it to me directly, and I would be happy to look at it and comment. I do not want to talk about specific products here, as the power supply vendors have all done a wonderful job supporting Xilinx, and it isn't that they have bad products (they have wonderful parts), they have some products that are not well matched to the FPGA powering application, and others which can be used, but require some modifications from the applications drawings in their data sheets. Austin Jim Granville wrote: > Austin Lesea wrote: > > > > Jim, > > > > Sounds like something I would not want to use: just a simple linear current > > limiting response, please. > > My understanding of 'snap action' regulators, is they deliver a fast > Vcc ramp, on > slower inputs, by waiting until the Vin is high enough to delivery Vout. > - ie unlike simple linear regulators, they hold OUT off, until Vin is > reasonably > high, then enable it. > > Given the Vcc issues of many Logic devices, it sounded like a good idea > to me. > > - jgArticle: 42687
Mr. Finc, A complete PTF user guide is currently being created. If it's okay, I can email you a preliminary copy early next week. Per your questions, the PTF format has changed and expanded from Nios v1.1. The new document mentioned above will contain a description of -every- legal PTF setting known to mankind. Alan Calac Altera Corp. "Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajeh1$a3c$1@planja.arnes.si>... > Hello! > > Can anyone advise where can I find the documentation about a complete list > of ptf sections and assignments? According to Altera's manual it should be > at http://www.altera.com/nios but no sign of it. I'd like the ptf specs for > Nios 2.0 because I already have it for 1.1 (is there any difference or new > feature?). > > Regards, > Matjaz FincArticle: 42688
Jim, I suppose if one got a hold of a lot of EasyPath parts, they could somehow figure out what they really are (they are not marked with their Xilinx standard part number, but with an 'ASIC like' code part number--- you know, like ABH0735494735-012, and a date code). Then they would have to erase or mask the old markings, and try to copy the new marking. Since the marking is a laser etch now, that is kind of tough. In fact I hate it because I can't read it easily....although I suppose my eyesight isn't as good as it used to be either. They would have to fake the markings pretty well, so they at least looked credible. Now one phone call to us, and a customer would know instantly the parts were bogus, as we track what gets shipped where, and to whom. Austin Jim Granville wrote: > Austin Lesea wrote: > > > > Jim, > > > > There is no issue with reliability: gate arrays ship with unknown > > defects present, and they work just fine forever. > > > > What are planning is actually much, much better. > > > > We have the complete reliabilty report ready for those who wish to > > review it (and believe me, the question was asked from day one by all > > customers we approached, and everyone so far is completely satisfied > > with the study). > > You missed the point. You mentioned : > " parts that could be remarked, and sold on the grey market > and cause untold grief for our real paying customers? " > > My question, was what stops that happening ? ( customer honesty ? ;) > > -jgArticle: 42689
Hi,
I'm using an XC4010E on an XS40 board, and am trying to implement a
simple parallel cable readback interface. I've scoured the Xilinx web
pages, newsgroups, and the web in general, and am having great
difficulty doing what appears on the surface to be fairly
straight-forward. The problem is not the parallel interface, but simply
trying to instantiate a readback block and get the readback going.
I'm using FPGA Express under ISE4.2i targetting the XC4010E.
I've tried using both schematic capture and VHDL, and whatever I do, it
seems like the readback block is being "optimised out". I've even tried
attaching dummy logic to the inputs and outputs to force the signals to
remain, but it still happens. There's a Xilinx Answer which proposes
the following VHDL code to implement readback:
-- begin rb_vhdl.vhd
entity rb_vhdl is
port(trig: in bit;
data, rip: out bit);
end rb_vhdl;
architecture inst of rb_vhdl is
component RDBK
port(trig: in bit;
data, rip: out bit);
end component;
begin
U1: RDBK port map(trig, data, rip);
end inst;
-- end rb_vhdsl.vhd
I've synthesised this, and received the warning:
"Warning: The net '/rb_vhdl/trig' has no load. (FPGA-CHECK-7)"
I continued, and constrained the inputs and outputs to external ports so
I can excite the clock and trig signals (and watch for RIP going high),
however P&R fails saying there are no connections to route. I checked
the map report and found this:
Loadless block "U1" (RDBK) removed.
The signal "N_trig" is loadless and has been removed.
Loadless block "C2" (IBUF) removed.
The signal "trig" is loadless and has been removed.
Loadless block "trig" (X_IPAD) removed.
Which seems to support the idea that the synth tools () are throwing
away my request for a readback block. I've even surrounded the readback
block with explicit IBUFs and OBUFs, but get similar messages to the
effect that the readback block basically isn't there.
I've seen references to the mode pins M0 and M1, but nothing explicit.
The Xilinx doco states pretty plainly that for the 4000 series trig,
clk, rip and data are just normal nets and can be routed to any user
IOB, so I don't see what the problem is.
Can anyone please give a clear description of what is required to get
the readback connected? After that I'll start worrying about actually
decyphering the stream - for now i'd be overjoyed to see the RIP line go
high!
Thanks in advance,
John
PS A contradiction: In the 4000.pdf product specification document, the
readback section has a timing table giving contraints on the readback
clock and associated signals. For the readback clock signal, the worst
case min and max high/low times are 250ns and 500ns respectively. This
corresponds to a worst case readback clock requirement between 1 and 2
MHz. However, in the xilinx app note "Using the XS4000 Readback
Capability" it says the readback clock must be between 10KHz and 1MHz.
On the final page, there's the usual diagram and timing table, but the
timing figures are blanked out, with the words "Preliminary" stamped
across it. Any clues what's going on here?
Article: 42690Ulf Samuelsson wrote: > If you take one year subscribtion to a magazine, and do not renew, is > it unfair that they do not continue send you magazines? I don't think this is an appropriate analogy - if you've paid for the software once, you shouldn't have to keep paying for it. Of course, if you don't pay, you don't expect dedicated tech support, or continued updates, but in my opinion that should be be the choice of the user. A better analogy I think is whether, once you buy a book, you should have to keep paying to read it year after year. You wouldn't expect to be sent the latest edition for free, nor would you expect to be sent corrections to paste in, but you can keep and read the original copy which you bought. However, this is probably not the best place to get into a debate on whether software is a product or a service :) Regards, JohnArticle: 42691
> Ray Andraka wrote: > > > A summary sheet listing the deltas (in detail) from the previous family would > > probably make a lot of people happy. As promised last weekend, here it is: Changes from Virtex-II to Virtex-II Pro Virtex-II Pro adds dedicated logic, 4 to 16 Multi-Gigabit Transceivers and 0 to 4 PowerPC microprocessors per chip. Each MGT takes the place of one BlockRAM at the top or bottom of the chip. Each PPC, (with caches, MMU and wide interfaces) takes the space of 128 CLBs plus 8 BlockRAMs The rest of the architecture is unchanged; same CLBs, IOBs, BlockRAMs, multipliers, DCMs, and the same routing structure. Same I/O interface capabilities, including on-chip termination. All circuits are re-laid out for the new 130 nm technology with nine layers of metal. (Virtex-II uses eight layers.) Same Vccint of 1.5 V, but Vccaux changed from 3.3 V to 2.5 V Each MGT has its own supply and ground pins. No bitstream or package-pin-out compatibility with other families. Nomenclature is different. Here are the approximate logic equivalents, ignoring MGT and microprocessor capabilities. XC2VP2 ~ XC2V250 XC2VP4 ~ XC2V500 XC2VP7 ~ XC2V1000 XC2VP20 ~ XC2V2000 XC2VP50 ~ XC2V4000 Changes from Virtex-E to Virtex-II Virtex-II is a major redesign of the Virtex architecture. The CLB has now 8 LUTs ( 4 slices) from 4 LUTs and 2 slices in Virtex and Virtex-E. The BlockRAM is >4 times bigger, and has x9, x18, and x36 option The BlockRAM has 3 options for read during write ( read first, write first, don't read) There is a dedicated 18 x 18 (max) 2-s complement multiplier close to each BlockRAM The DLL has grown to be a Digital Clock Manager with options for more multiply and devide ratios, simultaneous multipliy and divide ( frequency synthesis) and programmable phase delay. Support for many I/O standards is added, and there is an option for on-chip termination ( serial or parallel) Virtex-II uses 180 nm micron technology with 8 layers of metal.. The internal logic uses Vccint = 1.5 V, Vccaux is 3.3 V, Vccio is 1.5...3.3 V Virtex-II is not directly 5-V compatible ( needs external current-limiting resistor) Virtex-II (and Virtex-II Pro) have eliminated the large power-on inrush current. Viretx-II is not bitstream or package-pin-out compatibe with other families. Changes from Virtex to Virtex-E Virtex-E is a minor change, mainly a shrink for higher speed and cost reduction. The basic architecture is identical to Virtex, but the family now extends to larger sizes. Additional I/O standards are supported, notably LVDS ( with 2 pins per signal). There are eight DLLs, vs four in Virtex. I/O pins are 3-V tolerant, but need a 100 Ohm external resistor for 5-V tolerance. Not 5-V PCI compatible ( use Virtex or Spartan-II instead). Change in the banking rules. LVTTL, LVCMOS2, and PCI inputs are powered from Vccio. Vccint is 1.8 V, instead of 2.5 V for Virtex. This is due to 180 nm processing technology. Virtex-E is not bitstream compatibel with other families. Virtex-E is almost package-pin-out compatible with Virtex, see pin-out documentation for details. ============================================= This is not a substitute for studying the data sheets. Please e-mail me if you find any errors or omissions peter@xilinx.comArticle: 42692
Hello Mr. Finc, Using the multi-master capabilities of the Avalon bus, you can easily add a DMA peripheral to your Nios system. The DMA allows most other peripherals to act as a master on the bus. The Nios CPU sets up the DMA transaction by specifying the source and destination peripherals (in your case, peripheral source and memory destination), and the DMA peripheral carries out the transaction. For more information, check out: Altera application note #184: Simultaneous Multi-Mastering with the Avalon Bus (http://www.altera.com/literature/an/an184.pdf). Another excellent resource for this type of application is the Nios tutorials that came on the Nios 2.0 CD-ROM. In particular, the SMM tutorial might be of interest. Alan Calac Altera Corp. "Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajfgi$aku$1@planja.arnes.si>... > Hello again! > > I would like to make a Nios peripheral that receives some data (as slave > peripheral) from Nios cpu and after some processing pass it directly (as > master) to shared RAM and let Avalon do the arbitration. How do I implement > the master fuctionality and how can I address RAM directly through Avalon in > the ptf file or SOPC builder? > > Please advise. > > Regards, > Matjaz FincArticle: 42693
Jan Gray wrote > > Another cut at this can be formed by browsing fpgacpu.org, where Jan > > is proposing hundreds of processors per FPGA. The record I have seen > > (not on fpgacpu.org) is over 800 processors in one of the big Virtex-EM > > parts. Three processors per block RAM - giving some pretty severe > > limitations on control flow changes. The design was fractionally > > application-specific :) > > Can you please provide a reference, or is it a proprietary design? Proprietary - it was in a proposal document. The application was simulation, which is probably one of the few reasonable apps given the limitations of this sort of dense architecture. Each processor a maximum instruction memory of 256 10-bit instructions, though looping was allowed. The idea was that a master processor gave the 'go' signal to the array, then each CPU ran until it hit a 'stop' instruction. When all the CPUs had asserted 'stop', and side effects had stopped, the master processor could start off another cycle. As you can see, the 256-instruction limit would not be a problem for this domain, though it turned out to be expensive to encode immediates. FWIW, I am not that impressed by this sort of architecture - it amounts to implementing a slab of 'mini-transputers' in an FPGA fabric, with a pretty low quotient of new thinking from an FPGA angle. Another point - the architecture was optimized for big implementations, typically 100+ FPGAs, with maybe 100,000 CPUs. As Mike Flynn, the architecture god, said "How many problems can be stamped to death by a army of bunny rabbits?"Article: 42694
Has anyone used the MicroBlaze? How did it work out? Thanks! VernArticle: 42695
Laurent Gauch wrote > I am searching an EDIF parser for automatic documentation generation. > > where can I get some scripts? I don't want to discourage your search, but somewhere in the PERL FAQ it discusses the problems PERL has with grammars like EDIF...Article: 42696
"Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajeh1$a3c$1@planja.arnes.si>... > Hello! > > Can anyone advise where can I find the documentation about a complete list > of ptf sections and assignments? According to Altera's manual it should be > at http://www.altera.com/nios but no sign of it. I'd like the ptf specs for > Nios 2.0 because I already have it for 1.1 (is there any difference or new > feature?). > > Regards, > Matjaz Finc Look on http://www.altera.com/literature/lit-nio.html The SOPCBuilder data sheet will have all of the information you need. ------------------------------------------------- I am an Altera FAE. I am participating in this forum on my own time, please direct all techincal questions to http://mysupport.altera.com -------------------------------------------------Article: 42697
"Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote in message news:<aajfgi$aku$1@planja.arnes.si>... > Hello again! > > I would like to make a Nios peripheral that receives some data (as slave > peripheral) from Nios cpu and after some processing pass it directly (as > master) to shared RAM and let Avalon do the arbitration. How do I implement > the master fuctionality and how can I address RAM directly through Avalon in > the ptf file or SOPC builder? > > Please advise. > > Regards, > Matjaz Finc Again, all the information you need is available on-line at: http://www.altera.com/literature/lit-nio.html ------------------------------------------------- I am an Altera FAE. I am participating in this forum on my own time, please direct all techincal questions to http://mysupport.altera.com -------------------------------------------------Article: 42698
I have to update a board that has a Spartan on it that interfaces to memory. The memory I have to use is 3.3V LVTT, changed from 5V TTL. From what the specs for the Spartan and memory say, the DRAM inputs to the Spartan aren't a problem, but I am concerned about the outputs from the Spartan to the DRAM. The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and 15ns of VCC + 1.6V). The TTL output from the Spartan is min 2.4V, with no max. Anyone have any experience interfacing a Spartan to a 3.3Vmemory? Switching to an XL isn't a really good option, as I do not believe they are pin compatible with their non-XL counterpart (or are they, except for VCC obviously, which is an easy change?) and the PCB routing etc. from the old design can be used, except for the DRAM to Spartan interface, and 3.3V regulator, which are reasonably easy to re-do... Any experience/input (sic) would be greatly appreciated. AustinArticle: 42699
I did check the Spartan vs Spartan XL pinouts...and they are the same (except for a few configuration pins), and obviously VCC has to change. I measured the output of a Spartan to the DRAMs, and it was 4V+, so that's not going to work...default is TTL, so I believe this is TTL output. Looks like I have to change to an XL... My outputs have to be registered in the IOBs too, so that probably precludes my using any I/O open collector type trick. Anyone know if the 5V PROMs will work fine with the SpartanXL part? "Austin Franklin" <austin@dark87room.com> wrote in message news:ucutbb7if6khe3@corp.supernews.com... > I have to update a board that has a Spartan on it that interfaces to memory. > The memory I have to use is 3.3V LVTT, changed from 5V TTL. From what the > specs for the Spartan and memory say, the DRAM inputs to the Spartan aren't > a problem, but I am concerned about the outputs from the Spartan to the > DRAM. The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and 15ns of > VCC + 1.6V). The TTL output from the Spartan is min 2.4V, with no max. > > Anyone have any experience interfacing a Spartan to a 3.3Vmemory? Switching > to an XL isn't a really good option, as I do not believe they are pin > compatible with their non-XL counterpart (or are they, except for VCC > obviously, which is an easy change?) and the PCB routing etc. from the old > design can be used, except for the DRAM to Spartan interface, and 3.3V > regulator, which are reasonably easy to re-do... > > Any experience/input (sic) would be greatly appreciated. > > Austin > > >
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