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
On Sat, 26 Aug 2000 22:18:33 GMT, daniel_elftmann@my-deja.com wrote: >In article <5budqsg18fb94j1onn30a4n17kvj23fec4@4ax.com>, > Bob Perlman <bobperl@best_no_spam_thanks.com> wrote: >> Hi - >> >> Technical issues aside, I'd be curious about just how much demand >> there'd be for an anti-fuse part that's as large as the biggest Xilinx >> and Altera SRAM parts. Although a good economic argument might be >> made for using such parts, the cringe factor in throwing away >> expensive parts during debug is not to be underestimated (the cost of >> removing/replacing them is a good point, too). Sure, it's cheaper >> than spinning an ASIC. But with an ASIC, at least you get a low >> recurring cost. > >Low recurring cost? Only if you can get an ASIC vendor to give you a >significant break on the NRE. Are we talking about the same thing? Recurring cost and non-recurring cost are mutually exclusive, by definition. I assume you're talking about something akin to effective cost per unit, which is recurring cost plus the NRE divided by total number of units. Bob PerlmanArticle: 25126
Jim Granville wrote:
< snip >
> Interesting, so there is a bundle of latch/shift elements 'behind' the
> user
> resource. ( does nudge the die area up towards RAM designs, but you can
> read a cell in a lot fewer latch elements than needed to configure it )
>
> Is this access Read only, or can you Read/Write ?
>
> Can you address READ the elements in any way, or is it just
> a very-long-bitstream ?
In the Actel devices, there is a shift register that is used to command the
parts, and it's not terribly large. An important part of the contents is
X-Y like addressing information for the two probe points. Once the part, in
system, is given the proper command, the output of any logic module appears
at the probe point where you can clip on your scope or analyzer. As Dan
mentioned, you get two probe points per part and these have no effect on
what you want to measure; that is, it doesn't effect either routing or
loading. I would say it's more on the outside than "behind" the user
resources.
This is read only access.
Reading the modules can be done in any way and in any combination. Each
time you shift in a new command it is independent of prior commands.
The application note in the data book I have doesn't appear to be on-line
(at least a quick look didn't find it). I found this, which I skimmed,
which may be of interest:
http://www.actel.com/apps/guru/jul98/hc1708.html
Have a good evening,
rk
Article: 25127Hi Dan, Thanks a lot. This is something that we've asked for and it's nice to see that it is being done. And thanks for keeping us all informed in the newsgroup. Now, being that there are a flurry of concurrent, antifuse threads going on (OK, two), shall we start an RFD for comp.arch.fpga.antifuse? :-) Again, thanks. Have a nice weekend, rk ======================================================== Elftmann wrote: > Rich, > > I was able to stop into the product engineering group at Actel this week to > see how the metastability characterization was going. I'm happy to report > that the characterization has been completed for the .45u (MX), .35u(SX), > .25u/.22u(SXA) and the RTSX devices. This report is now in the hands of the > marketing folks to turn it into an application note. I will continue > pushing on it to insure it is posted to the web site as soon as possible. > > "rk" <stellare@nospamplease.erols.com> wrote in message > news:39A5D52C.3B54A8A7@nospamplease.erols.com... > > Hal Murray wrote: > > > > > > [1] "Metastability Report for FPGAs," Quicklogic Data > > > > Book, 1994, pp. 523-526. > > > ^^^^ > > > > > > > [2] Actel Data Book, 1992, pp. 5-1 to 5-2. > > > ^^^^ > > > > > > Ugh. Maybe it's a conspiracy to make Xilinx look good. :) > > > > While I am almost always a believer in conspiracy theories, I can't say > > that I know of one here. I just had some old books laying around the > > study. Now, I don't recall any of the newer books having any more > > up to date information. Perhaps Dan or John can chime in. > > > > I did try and hunt for more information on various www sites to update > > things but couldn't find anything relevant. Help, anyone? > > > > Have a nice evening, > > > > rkArticle: 25128
"rk" <stellare@nospamplease.erols.com> wrote in message news:39A87087.C28E751@nospamplease.erols.com... > Hi Dan, > > Thanks a lot. This is something that we've asked for and it's nice to see that > it is being done. > > And thanks for keeping us all informed in the newsgroup. > > Now, being that there are a flurry of concurrent, antifuse threads going on (OK, > two), shall we start an RFD for comp.arch.fpga.antifuse? :-) Only if the SRAM guys get upset with us using some of there bandwidth :-) And don't use that word "flurry" around a guy originally from the great white north (MN). I don't know why, but it brought back memories of dipping Honeywell 10K gate arrays into liquid nitrogen; just to get a CPU running at 7ns. What ever happened to the Supercomputer capital of the world? > > Again, thanks. > > Have a nice weekend, > > rk > > ======================================================== > > > Elftmann wrote: > > > Rich, > > > > I was able to stop into the product engineering group at Actel this week to > > see how the metastability characterization was going. I'm happy to report > > that the characterization has been completed for the .45u (MX), .35u(SX), > > .25u/.22u(SXA) and the RTSX devices. This report is now in the hands of the > > marketing folks to turn it into an application note. I will continue > > pushing on it to insure it is posted to the web site as soon as possible. > > > > "rk" <stellare@nospamplease.erols.com> wrote in message > > news:39A5D52C.3B54A8A7@nospamplease.erols.com... > > > Hal Murray wrote: > > > > > > > > [1] "Metastability Report for FPGAs," Quicklogic Data > > > > > Book, 1994, pp. 523-526. > > > > ^^^^ > > > > > > > > > [2] Actel Data Book, 1992, pp. 5-1 to 5-2. > > > > ^^^^ > > > > > > > > Ugh. Maybe it's a conspiracy to make Xilinx look good. :) > > > > > > While I am almost always a believer in conspiracy theories, I can't say > > > that I know of one here. I just had some old books laying around the > > > study. Now, I don't recall any of the newer books having any more > > > up to date information. Perhaps Dan or John can chime in. > > > > > > I did try and hunt for more information on various www sites to update > > > things but couldn't find anything relevant. Help, anyone? > > > > > > Have a nice evening, > > > > > > rk > >Article: 25129
I've had customers successfully use the BGA and FBGA packages on standard solder coated boards. I have gotten the impression that these are actually easier to do than the fine pitch flat packs, with the only difficulty being that you can't visually inspect. I recommend you use a board house that has done them before. They should offer xray inspection which will find any defects. John Larkin wrote: > > Well, I want to do a really cool image-processing gadget, and I'll > need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to > send me a couple of sample Xilinx BGA parts. I showed them to my > manufacturing people and actually escaped with my life. > > So, if any of you have experience with BGAs, I'd appreciate some help: > > 1. Is it necessary to go with gold-plated (or maybe bare copper) pads > to ensure planarity? Anybody having success with regular FR-4, > solder-coated SMOBC stuff? > > 2. Assuming I send the boards out for assembly, I'd still like to > verify that all the BGA soldering is intact. I could code up a special > FPGA design to just configure the chip as a lot of I/O latches, and > then run test patterns (from the uP that configures and supervises the > FPGA). Clearly, I can detect shorts between pins this way. Any ideas > on how to detect open ball-to-PCB solder joints? > > 3. What sorts of PCB line/spacings are needed for something like a > 460-ish pin 1.27 mm BGA? > > 4. Any other advice or cautions? > > Thanks, > > John -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25130
Bob, You are right they are mutually exclusive. But with sub-micron geometries, the NRE costs are skyrocketing and it doesn't make sense to keep these two mutually exclusive cost factors in different rooms, unless the NRE cost is just a noise factor based on the volume. "Bob Perlman" <bobperl@best_no_spam_thanks.com> wrote in message news:vgpgqs0uakgdfam0a3rceiojkke520qi4m@4ax.com... > On Sat, 26 Aug 2000 22:18:33 GMT, daniel_elftmann@my-deja.com wrote: > > >In article <5budqsg18fb94j1onn30a4n17kvj23fec4@4ax.com>, > > Bob Perlman <bobperl@best_no_spam_thanks.com> wrote: > >> Hi - > >> > >> Technical issues aside, I'd be curious about just how much demand > >> there'd be for an anti-fuse part that's as large as the biggest Xilinx > >> and Altera SRAM parts. Although a good economic argument might be > >> made for using such parts, the cringe factor in throwing away > >> expensive parts during debug is not to be underestimated (the cost of > >> removing/replacing them is a good point, too). Sure, it's cheaper > >> than spinning an ASIC. But with an ASIC, at least you get a low > >> recurring cost. > > > >Low recurring cost? Only if you can get an ASIC vendor to give you a > >significant break on the NRE. > > Are we talking about the same thing? Recurring cost and non-recurring > cost are mutually exclusive, by definition. I assume you're talking > about something akin to effective cost per unit, which is recurring > cost plus the NRE divided by total number of units. > > Bob Perlman > >Article: 25131
Elftmann wrote: > "inertia" and "nervous", not exactly terms taught by the universities :<) > > Rather than try to oversimplify the topic of SEU or go way off topic, those > interested can head to > Rich Katz's web page which has a good collection of papers and data on SEU: > http://rk.gsfc.nasa.gov/fpgas.htm#SEU-Hardening%20of%20Flip-Flops -- Lurk mode off. I see that the URL has some spaces in it (%20) and that doesn't work with all systems. I have updated this URL and several other bookmarks on that page and will shortly clean up the rest of them. Here is an updated URL: http://rk.gsfc.nasa.gov/fpgas.htm#SEU-Hardening_of_Flip-Flops There are some good examples of the effects of "inertia" there, using custom designed flip-flops to illustrate the point. Sometimes more nervous or "faster" flip-flops perform better with respect to SEU then "slower" flip-flops. There are a couple of different factors that come into play. Regards, Richard B. Katz National Aeronautics and Space Administration -- Lurk mode on. ============================================= > "Peter Alfke" <palfke@earthlink.net> wrote in message > news:39A02C19.20190222@earthlink.net... > > > > > > Elftmann wrote: > > > > > Peter, > > > > > > The A40MX02 and A40MX04 devices still require the master/slave latch > > > implementation, we call these CC-Flops. While the A40MX family is not a > > > qualified space environment device, it is interesting to note that the > > > CC-Flops have traditionally had better "Single Event Upset" SEU > > > characteristics versus the "hard-coded" flops in the RH1280 (same > > > architecture as A42MX). > > > > I believe that. SEU-tolerance gets better when there is a lot of "inertia" > in > > the latch, while fast metastable recovery needs a "nervous", very fast > > feedback loop. > > > > Peter Alfke > > > >Article: 25132
I had the same problem as Jens did and I had the labels. In fact Synopsys will not compile without them so I think Jens simply missed them while posting. Unfortunately, I was not able to find a solution so I had to unwrap all my nice constructs into huge amount of repetitive code. Does anyone know what is going on here? Generate statement is pretty much useless when it works like that! Mikhail Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:39A6C0CE.DC04BD84@flukenetworks.com... > Jens Hildebrandt wrote: > > > I have a problem with the names Synopsys_1999.10 uses for multiple > > instances of a component created using the VHDL "generate" construct. > > For instance, when using a construct like > > > > for i in 0 to 7 generate > > instance_name: component_name port map ( > > ... > > ); > > end generate; > > > You need a label. > > It should have been a syntax error without one. > > > MY_LABEL:for i in 0 to 7 generate > ... > end generate MY_LABEL; > > > > -- mike.treseler@flukenetworks.com or > -- tres@tc.fluke.comArticle: 25133
Ray Andraka wrote: > I recommend you use a board house that has done them before. > They should offer xray inspection which will find any defects. Can anyone comment on what happens when you X-ray inspect a factory, or pre- programmed EPLD in BGA ? ie is the XRay enough to erase ( or reduce the margin) of the FLASH cells ? -jgArticle: 25134
Neil Nelson wrote: > ... > I am here. > I have not bailed out. > > Regards, > > Neil Nelson Bail out! Chris clearly doesn't want to finger the perpetrator. Thank him for the advance notice and move on. Jerry -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------Article: 25135
Jerry Avins wrote: > Neil Nelson wrote: > > > ... > > I am here. > > I have not bailed out. > > > > Regards, > > > > Neil Nelson > > Bail out! Chris clearly doesn't want to finger the perpetrator. Thank > him for the advance notice and move on. I did not object to Chris' reasons as to why he would not give any names. He asked, rather determinedly, why I felt names were important. I had, in my post previous to the one quoted, attempted to move on. Regards, Neil NelsonArticle: 25136
Daniel,
I am glad that you admitted that you are an Actel FAE! We need more
vendor representation here than just Peter Alfke!
Now we have Peter (Xilinx) and Daniel (Actel). Are there any others?
-Simon Ramirez, Consultant
Synchronous Design, Inc.
Sent By Daniel Eltmann on comp.arch.fpga:
The logic modules in the Actel antifuse devices are all tested via
dedicated circuitry, which designers can also utilize for real time
debug. Designers can access internal nodes in the device after
programming via the Silicon Explorer tool without having to further
program the device. Silicon Explorer has saved the day in many cases
in my personal experience as an Actel FAE. All Actel antifuse devices
offer two probe pins. Via these probe pins the output of all logic
modules can be observed at the probe pins. When needed for user I/O
these two probe pins can also be used in the customers design. This
same circuitry is utilized during the testing of un-programmed devices
to guarantee 100% functionality of the modules in the device prior to
shipment of the blank devices
Article: 25137
Dear colleagues,
Could you please share experience on auto-routing
PCB's with large FPGA packages (PQFP, BGA).
The problem I encountered:
there is no way to tell PCB autorouter, that it should connect each power
pin with appropriate decoupling capacitor!
Instead, PCB autorouter tends to connect a group of power pins with a group
of decoupling capacitors by a single wire. Of course, such connection
minimizes the wire length, but it makes all decoupling capacitors senseless
...
Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to
avoid improper connection with decoupling capacitors?
Are there any methods with commonly used PCB autorouters - to autoroute
power network with variable width traces?
Thanks,
Alex Sherstuk
sherstuk@iname.com
Article: 25138Alex Sherstuk wrote: > > Dear colleagues, > > Could you please share experience on auto-routing > PCB's with large FPGA packages (PQFP, BGA). > > The problem I encountered: > there is no way to tell PCB autorouter, that it should connect each power > pin with appropriate decoupling capacitor! > Instead, PCB autorouter tends to connect a group of power pins with a group > of decoupling capacitors by a single wire. Of course, such connection > minimizes the wire length, but it makes all decoupling capacitors senseless > ... > > Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to > avoid improper connection with decoupling capacitors? Yes, you just place the Capacitors around the FPGA - most CPLD.FPGAs have pin-pair type arrangements, and if a Cap is placed close to this, you by nature have a very low 'cost' path to the Cap. ( this for QFP type packages ) If your autorouter is finding a shorter path somewhere else, you probably have the CAPs placed non optimially. > Are there any methods with commonly used PCB autorouters - to autoroute > power network with variable width traces? Some Autorouters can neck-down the last segment(s), but with plane PCB's the plane stubs are normally very short. -jgArticle: 25139
On Mon, 28 Aug 2000 01:10:41 +0400, "Alex Sherstuk" <sherstuk@iname.com> wrote: Hi - The common widsom is that the best way to connect bypass capacitors to chips is to run very short traces between the capacitors and the power and ground pins of the chip being bypassed. Unfortunately, the inductance of such an interconnect often greatly reduces or outright eliminates the effectiveness of the capacitor. For a while now, many people in the signal integrity world have been suggesting a different approach: sink vias directly from the capacitor pads to the power and ground planes; do the same for the chip power and ground pins, of course. If done carefully, this creates a very low inductance path. I've worked on large, fast boards where this approach was used (we couldn't get vias in the bypass cap pads, but used short, thick traces to the vias instead); the Vcc and ground planes were quite clean. But don't take my word for it. Read the following paper by the folks at Sun: ftp://ftp.qsl.net/pub/wb6tpu/si_documents/epep-98.pdf Take care, Bob Perlman >Dear colleagues, > > Could you please share experience on auto-routing >PCB's with large FPGA packages (PQFP, BGA). > >The problem I encountered: >there is no way to tell PCB autorouter, that it should connect each power >pin with appropriate decoupling capacitor! >Instead, PCB autorouter tends to connect a group of power pins with a group >of decoupling capacitors by a single wire. Of course, such connection >minimizes the wire length, but it makes all decoupling capacitors senseless >... > >Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to >avoid improper connection with decoupling capacitors? > >Are there any methods with commonly used PCB autorouters - to autoroute >power network with variable width traces? > >Thanks, > Alex Sherstuk > sherstuk@iname.com > > ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.cambriandesign.com Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 25140
On Mon, 28 Aug 2000 01:10:41 +0400, "Alex Sherstuk" <sherstuk@iname.com> wrote: >Dear colleagues, > > Could you please share experience on auto-routing >PCB's with large FPGA packages (PQFP, BGA). > >The problem I encountered: >there is no way to tell PCB autorouter, that it should connect each power >pin with appropriate decoupling capacitor! >Instead, PCB autorouter tends to connect a group of power pins with a group >of decoupling capacitors by a single wire. Of course, such connection >minimizes the wire length, but it makes all decoupling capacitors senseless >... > >Are there any tricks with commonly used PCB autorouters (like SPECCTRA) - to >avoid improper connection with decoupling capacitors? > >Are there any methods with commonly used PCB autorouters - to autoroute >power network with variable width traces? > >Thanks, > Alex Sherstuk > sherstuk@iname.com > > Hi, what we do is make sure that there's a solid Vcc plane under the chip, at least as big as the chip itself, with just a few (typically 4-8) bypass caps per chip. The Vcc plane is ideally as big as the whole PCB, but may have to be just an island on a multiple-voltage (split) power plane. What's important is to minimize the spacing between the power plane/island and the ground plane (3-5 mils is nice) to use the plane as an area capacitor (or you can think of it as a very low-Z transmission line). The plane capacitance handles the fast stuff, and the discrete caps supply longer-term energy storage. We've TDR'd such structures at 20 GHz bandwidth, and they look like essentially ideal capacitors. It doesn't seem to matter much where you place the discrete caps... just scatter them around. JohnArticle: 25141
Sorry. I evidently missed that. (I had stopped reading assiduously.) Jerry Neil Nelson wrote: > > Jerry Avins wrote: > > > Neil Nelson wrote: > > > > > ... > > > I am here. > > > I have not bailed out. > > > > > > Regards, > > > > > > Neil Nelson > > > > Bail out! Chris clearly doesn't want to finger the perpetrator. Thank > > him for the advance notice and move on. > > I did not object to Chris' reasons as to why he would not give any > names. He asked, rather determinedly, why I felt names were important. > I had, in my post previous to the one quoted, attempted to move on. > > Regards, > > Neil NelsonArticle: 25142
Hi, As the error message said, the component LDCE uses ULOGIG type, so prefer : component LDCE port ( Q : out STD_ULOGIC; D : in STD_ULOGIC; ... ); That will be better. Next, if you want to create latches, you have to prefer instanciate RAM element used like latches more than a flip-flop...You can find more details in Xilinx site, on topic : optimizing vhdl for Xilinx. CU, Paul Bob Perlman <bobperl@best_no_spam_thanks.com> a écrit dans le message : pgofqs0foh8qeit8ets319h171916svqi3@4ax.com... > Hi - > > For reasons too complicated to explain, I temporarily took leave of my > senses and agreed to synthesize a VHDL design in FPGA Express (I > usually rely on Synplicity and Verilog). Because FPGA Express has > some problems with building latch enables sensibly, I decided to > directly instantiate the latches, as follows: > > architecture RTL of mystery_module is > > component LDCE > port( > Q : out STD_LOGIC; > D : in STD_LOGIC; > G : in STD_LOGIC; > GE : in STD_LOGIC; > CLR : in STD_LOGIC); > end component; > . > . > . > begin > . > . > . > r_nw_latch: LDCE port map (Q => R_nW, > D => io_dr, > G => iosd_set, > GE => r_nw_latch_ge, > CLR => r_nw_clr); > > All of my signals are declared std_logic. > > When I run "update," the line with the LDCE instantiation throws error > VSS-543 (Actual designator not of correct type - STD_ULOGIC expected). > > Here's where I get confused. Absolutely every direct instantiation > example I've encountered in the Xilinx documents suggests that modules > for primitives use data types std_logic and std_logic_vector; that's > why I declared the component as I did. However, when I look in > Xilinx's VHDL-related unisim files--unisim_VCOMP.vhd and > unisim_VPKG.vhd--it appears as if the LDCEs in those files expect > input and output types STD_ULOGIC. (I'm not including these files in > my compiles; I just used them as a reference.) > > Can someone tell me what I'm doing wrong? > > Thanks, > Bob Perlman > > > >Article: 25143
Hellow!
I've encountered with the following problem: I try to set a guide
revision in the Xilinx Foundation 2.1i. It leads to "windows general
protection fault".I tried to do it in the Xilinx Foundation 1.4 and
there was the same problem.
Does anybody use this option, and does anybody know about the problem?
Please explane me how to workaround it.
Thanks.
Alexandr.
Article: 25144On Wed, 23 Aug 2000 08:26:45 -0600, David Kessner <davidk@free-ip.com> wrote: >I've seen multiple problems with 3.1i that I'm still trying to sort >out. Some of the problems are: > > - FF's not being put into IOB's when F2.1i successfully put > them there (Spartan-II). This was not fixed with SP2. Also, 3.1i was supposed to address the issue of tristate FFs not being placed in IOBs as directed. It doesn't, unfortunately. DanArticle: 25145
Peter Alfke wrote: > > Simon is of course right, in general. But Spartan-II is a special case: > It is derived from "good old Virtex", which has been around for well over a > year. > From a software point ov view, there is no big difference. The speedsfile > numbers differ, there is no temp-measuring diode in Spartan-II, and, perhaps > most importantly for your projects, the packages differ. And Spartan-II extends > the Virtex family downwards to '30 and '15, devices that will never exist in > Virtex. > "Besides that..." there is no difference. So you can definitely start the > software portion of your design without any worry. I have tried to get a > realistic availability answer out of Spartan marketing. Let's see. > > Peter Alfke, Xilinx Applications Just a little nudge. Were you still trying to get a realistic availability answer? I at the very least am very interested in the answer. -- My real email is akamail.com@dclark (or something like that).Article: 25146
Hello Dan, I know of no Map problems involving the packing of tristate FFs into Virtex IOBs and have just successfully tested this functionality. Could this be a problem with the front end tool not passing IOB constraints as in Xilinx Answer #9071? If instead you are speaking of 4KXLA IOBs, then this is a known issue. There are currently no plans for the mapper to support the tristate FFs in the 4KXLA IOBs. If there is some documentation that states otherwise, please point me to it and I'll see that it is corrected. See Xilinx Answer #5140 for a work around to the Map limitation. Regards, Bret Wade Xilinx Product Applications Dan Hopper wrote: > On Wed, 23 Aug 2000 08:26:45 -0600, David Kessner <davidk@free-ip.com> wrote: > >I've seen multiple problems with 3.1i that I'm still trying to sort > >out. Some of the problems are: > > > > - FF's not being put into IOB's when F2.1i successfully put > > them there (Spartan-II). This was not fixed with SP2. > > Also, 3.1i was supposed to address the issue of tristate FFs not > being placed in IOBs as directed. It doesn't, unfortunately. > > DanArticle: 25147
Mike Treseler wrote: > > "K. Orthner" wrote: > > > I've received my copy of the Xilinx 3.1i software, and installed it this > > morning. > > > > It seems to me that it doesn't support multiple entities in a single file! > > I just want to check to see if anyone's run into the same thing. This is > > what I did: > > > > 1. Installed it. > > 2. Created new project (Since it doesn't seem to read 2.1i projects) > > 3. Added all my source files from an old project. this includes "Ram.vhd", > > which has a bunch'o'entities for different RAM constructs. > > 4. Looked at the "Modules" window, where I found only the last entity in > > any given file was displayed. > > You are getting the "default configuration" for the > last entity/architecture in the file. This is a VHDL rule. > > You need to write and compile specific configurations for > the specific entity/arch combinations you want to use. > Then you can put everything in one file if you like. > > Otherwise, you need separate files for each default configuration. 'cept FPGA Expess doesn't know about configurations (boo, hiss), so he's stuck. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25148
Steven DeLong wrote: > > I have an application that requires the connection of a large amount of > I/O between multiple FPGAs on a single PCB. The application requires one > type of device to fan in/out to 8 each of a second type of device. Each > connection requires about 6.4 Gbit of bandwidth in each direction. > > One connection scheme could use two 32 bit buses (one bus in each > direction) between each of the eight devices and the one device. The bus > bits would each run at 200 Mb/s. That's 64 single ended > drivers/receivers on each of the eight devices and 512 single ended > drivers/receivers on the other device. > > Does anyone have any experience with anything similar to the above > and/or large amounts of high-speed interconnect between chips? What type > of I/O was used (LVTTL, LVDS, HSTTL, etc.) What, if any type of > terminations were used? Any other suggestions? > > I would like to avoid external terminations and reduce as much as > possible the number of physical routes between the devices because of > PCB real estate limitations. Wow. Lots of routes. Do yourself a big favor and get a copy of Hyperlynx BoardSim, or some other post-layout PCB simulation tool. That way, you'll have some idea what the board is doing to you before you build it. Given good IBIS models for your FPGAs (and the Xilinx ones work well), the simulation should be accurate. You probably won't be able to discard the terminations. You should check out http://www.signalintegrity.com/ and the mailing list there for more help. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25149
On Fri, 25 Aug 2000 09:14:49 +0200, Andreas Doering wrote:
>Hal Murray wrote:
>>
>> > Please, Altera and Xilinx, never give up the command line interface to
>> > your tools.
>>
>> I'd like to second that. Good documentation is important too.
>>
>> What I really want is something that cooperates with make.
>> Aside from all the options that I can specify on the command
>> line, I need to understand the sequence of steps to go through
>> and I need to know what files each step produces.
>>
>> I consider the Makefile to be a critical part of the documentation.
>
>For larger designs "make" does not fit very well, unless you build
>wrappers around the tools. It is very design specific what is
>considered a severe problem (with the consequence, make should stop)
>and what is ok. Just yesterday someone complaint that certain IOs
>were not put into the IOBs. Hence, the number of "IOB FFs" reported
>by make is crucial for this design. The same number will be irrelevant
>for
>other designs.
Hm. wrapper is too big a word for that, I think. Something like
${DESIGN}.ncd ${DESIGN}.pad: map.ncd
par -w -pl ${PLACER_EFFORT} -rl ${ROUTER_EFFORT} -d ${CLEANUP_PASSES} \
map.ncd ${DESIGN}.ncd ${DESIGN}.pcf
perl ./local_lint par.rpt
should actually do, local_lint being a perl script in the build directory that
checks anything you want it to (timing, IOB FF usage, you name it).
[rest of dreaming snipped (but shared - I'd love to see embedded perl there,
and NOT tcl)]
chm.
--
cmautner@ - Christian Mautner
mail.com - Vienna/Austria/Europe
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