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
In article <3B7D55C5.52ED77F1@xilinx.com>, Peter Alfke
<peter.alfke@xilinx.com> writes
>> It doesn't help that I've also heard claims from certain Xilinx personnel
>> that their internal flip-flops are virtually metastable-proof...
>
>I really hope that nobody has said it that way. Metastability will be forever
>with us, like death and taxes.
For sure. As will the occasional mangling of well-meant technical
advice by over-enthusiastic sales persons :-)
>But, the recovery from a metastable situation has become much faster, now that
>we have a much higher gain-bandwidth product in the master latch. So we can
>count on metastability being resolved earlier, but the timing is still
>statistical, non-deterministic....
AIUI people have designed "metastable-hardened" FFs: naturally, no-one
can avoid the extended clock-to-output delay that goes with
metastability, but it *is* possible, I think, to side-step the worst
other effects: oscillating outputs, runt pulses, all that kind of
junk. Philips offered a "metastable hardened" FF in the 74F series
some years ago (74F5074???) which claimed these properties IIRC.
It may well be that these improvements were achieved at the cost
of other performance figures - particularly clock-to-output delay
in the normal case when Tsu/Th are met - which are likely to be
much more important for FFs within a typical FPGA.
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 34301
Dear Sir,
I am sending you (as the sane technical voice of Xilinx) a few
questions
and one bug report.
I approve in advance should you wish to post any part of this or subsequent
emails
onto the comp.arch.fpga newsgroup to assist others.
Questions mainly about Spartan2...
1) Is the access time / CLOCK to DOUT time for the BRAMS faster when set
for a wide data configuration?
(ie presumably the output signals can skip 4 levels of multiplexers)
2) is the carry out pin of a CLB in a LOW/HIGH/TRI STATE if not selected to
be used in a 1 CLB hard macro?
3) whats the point of the CIN pins in the lowest row of slices?
(ie with highest row index)
4) if the answer to the 3rd question is NONE then you might be amused
to try smart-placing (within FPGA_EDITOR) a hard macro which uses a CIN
(seems to like the lowest row for some reason!)
5) The Spartan2 databook is very unclear about IO banks & PQ packages.
Presumably the Vref & Vccio arrangements are as with the Virtex?
(which was at least clearly documented)
6) Any chance of filling in some of the blank fields for Spartan2 -6
timing?
7) How about guaranteed best case timings as well ?
( specifically for BRAM access)
8) Would it be possible to sacrifice a BRAM & use a DLL to lock onto the
Tbcko , or would the delay of other BRAMS not track?
(even though being guaranteed to have the same Vccint & presumably
approximately the same temperature?)
(bearing in mind question 1, I would only be applying this to identical
data width BRAMS)
If this approach is possible which data bit should I route through?
9) Do the industrial versions draw more startup current than the commercial
devices at any given temperature,
or is it only at extremely low temperatures (below the commercial range)
that the current increases?
10) Using XST VHDL (SP8, on both WebPACK & ISE3.3i)
RLOCS are lost on all but the first instance of a component containing
RLOCS.
This is BAD , especially when Carry logic and / or MUXF5 is involved,
because what creeps into the wrong CLB makes no sense at all
(as regards timing/space) .
I originally thought this was a problem with MAP, but then examined the
EDN file & found that MAP hadn't been told to cluster components within
a CLB. (for any except the first instance)
"Preserve Heirarchy" had been SET (as a synthesis option).
Presumably the only way around this is to use "Incremental Synthesis"?
(Apart from hacking the edn file to ensure all instances refer to the
first cell definition,which does indeed work, but surely can't be
considered a standard flow!)
but incremental synthesis doesn't work for any OTHER component!
I haven't tried using the XILFILE attribute which could be a way to
enforce the correct hierarchy.
11)The P&R tools seem to consider (single port) RAM address lines to be
unswappable.
Is there any way around this, because almost invariably I find that
swapping (ie deleting net pins then adding net pins)
the two highest net delay address inputs improves the timing on BOTH lines.
12) Any chance of a job at Xilinx?
(I can write tools. I can design hardware. I like Xilinx hardware.)
I'm afraid that jobs locally to me are of the sort
"You've got to use ACTEL" (probably something to do with the name of their
main product line.)
or "You've got to use Virtex" ( note not Virtex-E, Spartan2 or Virtex2 but
Virtex).
or "You've got to use ALTERA" or "You've got to have marketing experience".
I can supply the names of the guilty parties, but I don't think that would
help.
Respectfully yours,
Mark Taylor
Mark_Taylor_Chess@compuserve.com
101551.3434@compuserve.com
Article: 34302Falk Brunner <Falk.Brunner@gmx.de> wrote: > Lets say you have a design running at 333 MHz (3ns period). All decoding > logic between the FF of your design just needs has 3 ns propagation > delay. Now you need to synchronize asynchronous signals, requireing > additional 3ns of time. Now your slowest path is 6 ns, slowing down your > system to around 160 Mhz (6ns). How to slove this problem? > Simply insert a second FF close after the first synchronizing FF. Now > the synchonizing FF will settle within 3 ns, just right to be (now > synchronous) clocked in by the second FF. Really? If your clock period is 3 ns, don't you only have 1.5 ns to the falling edge for the first synchronizer to settle, not 3 ns? cheers, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 34304
Eric Crabill <eric.crabill@xilinx.com> wrote: > your design must have an individual TFD flop for each OFD. > If you instantiate them, it works great. If you are using > a synthesis tool, you must code up the appropriate number > and then be sure to disable duplicate register merge or > whatever your favorite synthesis tool calls it... Otherwise > it will tend to optimize all but one of them away, and the > packing will fail. BTW, recent Synplify seems quite good about this; I've seen it generate enough duplicates of the enable so that they can be mapped into the IOBs. At least, I think I have. Version 6.2.x. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 34305
Sorry for the double post. This was a copy of an email to Peter Alfke Peter.Alfke@Xilinx.com I didn't get a reply, so I'm hoping some answers might be available from this newsgroup.Article: 34306
Right, It isn't a question of damaging the metal interconnect (not enough current), or of damaging the transistors (again, not enough current); it is a question of creating many millions of uA loads, that together cause the chip to overheat. I have often wondered what all the fuss is about: use a power controller to sense the temperature from the temp diode in Virtex (or Virtex E, or Virtex II), or use a series current sensor in the Vccint line. If in the process of programming, either the temperature starts to rise, or the current is over the limit, you try the next configuration. Austin Reinoud wrote: > Eric Smith wrote: > > > > Reinoud <dus@wanabe.nl> writes: > > > A circuit like you have drawn above will oscillate at a fairly high > > > frequency. If there are many loops, or if a lot of logic is driven > > > at high frequency by such loops, this may draw a lot of power. Many > > > boards out there with large FPGAs were not designed to handle such > > > power. This is not a flaw of Virtex (actually, Xilinx documents > > > power issues quite clearly), it's more a board/system design issue > > > with current generation (high power density) chips. > > > > I appreciate the insight. However, I'm still curious as to whether > > such things are likely to damage the chip. I suppose the answer > > may depend on how many such circuits one manages to configure. > > It depends on how hot the chip can get when downloading such > problematic designs. This depends on FPGA technology, die size, > packaging and cooling - and the capacity of the power supply. The > combination of a huge modern FPGA, strong power supply, and no > heatsink has high potential for smoke emissions. With a tiny FPGA or > weak power supply, no sweat. Otherwise, cooling or power/temperature > monitoring can keep things within safe limits. > > You can get an idea of these power issues by playing with the power > estimator on the Xilinx website, and calculating die temperatures > with the package thermal data. > > - Reinoud > > (Spam goes to wanabe, mail to wanadoo.)Article: 34307
--------------2C597F5A0EFBD37388CCEA9C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hal, hyperlynx.com Austin Hal Murray wrote: > > There are other SI tools available, that are more (from Mentor, Cadence, Avanti, > > etc.) but I find Hyperlynx to be completely adequate for a lot of designs. It > > has a spice extraction mode to extract spice models from the pcb layout that is > > particularly useful, too. Maybe I just like its user interface. Any SI tool is > > a worthwhile investment. > > Thanks. > > What sort of "pcb layout" database/file can it read? > > -- > These are my opinions, not necessarily my employeers. I hate spam. --------------2C597F5A0EFBD37388CCEA9C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hal, <p><a href="http//www.hyperlynx.com">hyperlynx.com</a> <p>Austin <p>Hal Murray wrote: <blockquote TYPE=CITE>> There are other SI tools available, that are more (from Mentor, Cadence, Avanti, <br>> etc.) but I find Hyperlynx to be completely adequate for a lot of designs. It <br>> has a spice extraction mode to extract spice models from the pcb layout that is <br>> particularly useful, too. Maybe I just like its user interface. Any SI tool is <br>> a worthwhile investment. <p>Thanks. <p>What sort of "pcb layout" database/file can it read? <p>-- <br>These are my opinions, not necessarily my employeers. I hate spam.</blockquote> </html> --------------2C597F5A0EFBD37388CCEA9C--Article: 34308
According to Xilinx app. note 132, the feedback clock input of CLKDLLE can be clk0 or clk2x. But in the functional simulations the CLKDLLE doesn't work (all clock outputs remain 0's) if clk0 output is directly connected to the clkfb input. Everything works fine if a bufg is inserted between clk0 and clkfb. Does anybody know if this is just a simulation issue or it is how clkdlle logic actualy works (clkfb input has to be driven by a some form of bufg). I am using vcs and the clkdlle.v model revision is 1.4.20.2. Thanks,Article: 34309
> Eric Crabill <eric.crabill@xilinx.com> wrote: > > your design must have an individual TFD flop for each OFD. > > If you instantiate them, it works great. If you are using > > a synthesis tool, you must code up the appropriate number > > and then be sure to disable duplicate register merge or > > whatever your favorite synthesis tool calls it... Otherwise > > it will tend to optimize all but one of them away, and the > > packing will fail. Also (maybe this is obvious), Virtex/VirtexE/SpartanII PCI designs should use the 'magic' logic block, as discussed in various old posts to this newsgroup.Article: 34310
Hi all I've just finished a little PCB to replace an XC17S (DIP8) with an XC18V (VQ44) but the whole thing doesn't work. When I plug an XC17S100A in the socket, everything works fine but when I put my adapter, either the clock won't run or /rst will remain low. The JTAG part works fine, the PROM is programmed and verified so I think it is correctly powered and soldered. What am I doing wrong? -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/Article: 34311
Are you aware that all of Xilinx FPGAs since the XC4000 (1990) have included a TAP controller, and give access to it inside the FPGA. I am currently doing several designs, where after the FPGA is configured, I use the JTAG system to read and write registers in the FPGA. If you really want to design it your self, it isn't that complex. The schematic for it is included in the JTAG spec. It is about 100 gates (and 6 ? FFs) Philip Philip On Mon, 20 Aug 2001 10:54:33 +0200, "Hans" <hans@rohill.nl.nospam> wrote: >Hello group! > >Does anyone know of a way to do JTAG TAP controller within FPGA? > >Gr, Hans > Philip Freidin FliptronicsArticle: 34312
Marc Battyani wrote: > "Andy Peters <andy [@] exponentmedia com >" <".> wrote > > > There are a bunch of parts one can use to bridge the 5V <--> 3.3V gap. > > Basically, they're the usual sort of buffer types: '245, '541, '573, > > '573, '823. They're in various logic families: LPT, FCT, etc. See the > > Pericom or IDT web sites for examples. Look for devices that have 3.3V > > power rails and are 5V tolerant. > > Yes, but I have not found small devices. Well in fact there are small > devices (TVSOP48 for a X16 buffer) but they are still bigger than the device > I want to connect to the Virtex-II. And I don't have enough room on the > board to put them. You could use the XC95XL family as buffers. 0.8mm pitch chip scale packaging gives you 19 buffers at 7x7 square mm, 58 buffers at 12x12 square mm and 96 buffers at 16x16 square mm. Thats a density of 2.5 to 3 sqaure mm per buffer. This is probably pretty close to what you can do with resistor arrays. Maybe you can find 0.5mm CSP CPLDS? Kolja SulimmaArticle: 34313
On Mon, 20 Aug 2001 13:56:51 +0100, Jonathan Bromley <Jonathan.Bromley@doulos.com> wrote: >AIUI people have designed "metastable-hardened" FFs: naturally, no-one >can avoid the extended clock-to-output delay that goes with >metastability, but it *is* possible, I think, to side-step the worst >other effects: oscillating outputs, runt pulses, all that kind of >junk. Philips offered a "metastable hardened" FF in the 74F series >some years ago (74F5074???) which claimed these properties IIRC. You may want to have a look at the following: http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm where I go on at some length on the topic. The last section specifically deals with the oscillation vs. delayed output, where I explain that masking oscillation (and runts) as delayed clock-to-out is no fix at all. In my book they are just as bad. The only place where inhibiting oscillations or runts would have any effect would be if you were using the signal as a clock, and that would be crazy. >It may well be that these improvements were achieved at the cost >of other performance figures - particularly clock-to-output delay >in the normal case when Tsu/Th are met - which are likely to be >much more important for FFs within a typical FPGA. right, except I dont think they are improvements. Philip Freidin Philip Freidin FliptronicsArticle: 34314
Eric Smith wrote: > > I appreciate the insight. However, I'm still curious as to whether > such things are likely to damage the chip. I suppose the answer > may depend on how many such circuits one manages to configure. If you ( accidentally ) create a lot of internal oscillators or glitch generators, these circuits will consume Icc, and thus heat up the chip. But, by its nature, the local current is small, in the mA range. If total heat is a problem, the current will be widely distributed, and thus benign. You only have to worryabout chip temperature, not metal migration. Put your fingertip on the package: If you can keep it there, the package surface is below 65 degrees C, if it sizzles, it is above 100 degrees C. Ouch! Peter Alfke, Xilinx ApplicationsArticle: 34315
I checked with product engineering: These two pins are definitely unbonded, so connecting them to anything you want is ok. But in general, I would not recommend to connect something to pins labeled n.c. It can cause you grief when you have to migrate the design to a larger part in the same package. For that larger die, the pins may then not be n.c. So the best interpretation is: n.c. = not connected by Xilinx, and also n.c. = not to be connected on your pc-board. Peter Alfke, Xilinx Applications. ====================================== Hayden So wrote: > Hi All, > > Anyone knows what will happen to the > Xilinx Spartan2 if I have > accidentally connected the "not > connected" (e.g. P55, P56 on a > PQ208) pins externally on the PCB? > > My PCB maker has actually connected > all the pins that I marked as NC (no > connection)... > > Thanks for any advice. > > HaydenArticle: 34316
Just for fun I created a full loaded virtex-II 1000 part which toggled all of the luts in the chip as fast as the routing would support. It draws about 10A of 1.5V for the core. Kind of fun test, just don't leave it plugged in very long. This was in the 256 pin package. Bryan "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3B8145C0.3D5547D3@xilinx.com... > > > Eric Smith wrote: > > > > > I appreciate the insight. However, I'm still curious as to whether > > such things are likely to damage the chip. I suppose the answer > > may depend on how many such circuits one manages to configure. > > If you ( accidentally ) create a lot of internal oscillators or glitch > generators, these circuits will consume Icc, and thus heat up the chip. > But, by its nature, the local current is small, in the mA range. If total heat > is a problem, the current will be widely distributed, and thus benign. > You only have to worryabout chip temperature, not metal migration. > Put your fingertip on the package: If you can keep it there, the package surface > is below 65 degrees C, if it sizzles, it is above 100 degrees C. Ouch! > > Peter Alfke, Xilinx Applications > >Article: 34317
K.O schrieb: > > >This is possible too. You can also drive your 2x Clock with falling > >edges (in the HDL description) > >Or drive it on the same edge and just insert a synchronizer (running on > >the falling edge). > > Please Falk could you tell me how to implement this synchronizer, i am > interested in high speed design, or at least describe its function It is simply a FF, that is running (in this case) on the opposite clock edge. Lets say your 2x clock runs everything on the rising edge, as well as the the 1x clock. Then just insert a FF between the 1x and 2x clock domian which is clocked on the falling edge of the 2x clock. In our case with the DLL working not so perfect,we have the half clock cycle of 2x clock - maximum skew - jitter - duty cycle error of 2x clock for timing budget. This means if this number is positiv under worst case conditions, the design will work reliable. In general, you use a FF to synchronize datas which are asynchronous to the digital design by inserting a FF on this input. As long as the asynchronous data is stable during the setup and hold time of the FF, everything works fine. But when the data is changing just in the moment the FF is clocked (which is possible, because the data is asynchronm to your clock), the output of this FF will not go into a stable state just like normal. It will go metastable. This means, is takes some time to settle on a stable state. This time is called resolution time. It depends on the FF technology (manufacturing process). The older 4k series of Xilinx had something like 2-3ns. This means, if you let the FF 2-3ns to settle, it will settle stable with a probability of 1 failure in 1000 years. That means, your decoding logic, following this FF need 2-3ns more time. An example. Lets say you have a design running at 333 MHz (3ns period). All decoding logic between the FF of your design just needs has 3 ns propagation delay. Now you need to synchronize asynchronous signals, requireing additional 3ns of time. Now your slowest path is 6 ns, slowing down your system to around 160 Mhz (6ns). How to slove this problem? Simply insert a second FF close after the first synchronizing FF. Now the synchonizing FF will settle within 3 ns, just right to be (now synchronous) clocked in by the second FF. This second FF delivers the formerly asynchronous syignal to the decoding logic of your design, which can now utilize the full 3ns cycle time. The drawback of this design is, that it takes 2 clock cycles for the asynchronous signal to get to the logic (latency). But noting is perfect in this world ;-) OK, this is a VERY simple and not fully correct description of metastability of FFs. But I hope it gives a first impulse on thinking about metastability. There are some application notes from various companys (Xilinx, A**** and others ;-) about this topic. -- MFG FalkArticle: 34318
In a discussion something like: >> Can a combinatorial loop cause hardware damage to a Virtex or Spartan-II? >> I thought the only internal condition that was potentially damaging was >> an internal driver conflict. I thought logic like: >> >> --------------+----------- >> | | >> | | >> | |\ | >> -----| >O----- >> |/ >> >> would probably not work too well, but can it actually cause damage? >The same paragraph on that page explains: > Resulting oscillations may cause widespread high frequency > switching and this may draw more power than your hardware was > designed to handle. It would seem that the oscillations wouldn't be much faster than the highest frequency that the device can run at. I was once working on a design in which a large fraction of the gates/ff would change state each clock cycle. Well, random would say 50% and it might have done that. I asked in this group, wondering if there would be any Icc/heat related problems. As far as I understood at the time (XC4000 series days), and assuming ordinary free-air cooling, it would be fine. If it was 100% of the gates changing at twice the clock rate, that would be four times the power, and it might get a little warmer. The path through CLBs and routing to make an oscillator like that shown should be long enough to keep the frequency relatively low, compared to discrete logic. -- glenArticle: 34319
"Austin Franklin" <austin@darkroom99.com> wrote in message news:9lh1e7$hqi$1@slb6.atl.mindspring.net... > There is really no reason you can not make 25MHz, much less 33MHz with your > FPGA...if you're in an appropriate part, and your logic is "correct". > > What part are you using, and what is causing your PCI interface to be so > slow? Please be very specific in this answer if you could, and I might be > able to help you. Sorry this took a few days to get back... My main news server wasn't getting articles for some reason, so I had to switch servers. I'd still love some comments! Here's some responses and updates: - The goal is to prototype an ASIC in an FPGA. The extremely deep logic causes a problem. Even with floorplanning and synthesis optimizations, calculating an address pointer in half the cycle is trivial with ASIC gate delays but very difficult with FPGA gate delays. With the design partitioned across several virtexE 2000 -6 chips, even with floorplanning and synthesis improvements, I can hardly get the design above 12-14 MHz which is not even close to the 25 constraint. - I appreciate other people's suggestions for using a builtin PCI core, but the deep logic elsewhere is more of a problem which I can't get around. Redesigning so PCIclk doesn't equal localbus clk would be a great idea, but the workload is impractical for a prototype that just verifies the RTL code. Therefore slowing down the PCIclk sounds much more attractive right now. - Most machines seem to use some sort of clock chip (often Cypress) running off a 14.3 oscillator. Swapping that seems like it would certainly cause problems for the computer (dram, video, etc), correct? I'm not in modern motherboard design so I'm not sure what would happen. I looked at the CPU Cool program a little this afternoon. My primary computer wasn't supported (no big deal), so in the mean time I checked some other datasheets. It looked to me like most PLLs can easily adjust the CPU FSB, but keep the PCI clock fixed which is still a prob. Thanks for the ABIT suggestion, 15 MHz is much more realistic to reach on fpga! Of course it's not as good as the 2.75 MHz that the $3000 DINI card gets, but its hard to justify that much higher cost unless you design a lot of PCI cards. Would be nice to spread the cash around for tools on other bus technologies. All that being said, any other comments or suggestions would be much appreciated! I'd still love to solve this problem some way other than waiting for $3000 to become available for that nice 2.75 MHz card. Thanks a lot! -joeyArticle: 34320
How to resolve the problem that the virtex1000e can't set up after power up some times?Article: 34322
"Hayden So" <haydenso@yahoo.com> wrote in message news:ee7207c.-1@WebX.sUN8CHnE... > Hi All, > > Anyone knows what will happen to the > Xilinx Spartan2 if I have > accidentally connected the "not > connected" (e.g. P55, P56 on a > PQ208) pins externally on the PCB? > > My PCB maker has actually connected > all the pins that I marked as NC (no > connection)... I don't think they are actually bonded to the chip. You could always check this by measuring the resistance to ground (on an unmounted chip, of course). Leon -- Leon Heller, G1HSM leon_heller@hotmail.con http://www.geocities.com/leon_heller Low-cost Altera Flex design kit: http://www.leonheller.comArticle: 34323
Joseph Oravec wrote: > "Austin Franklin" <austin@darkroom99.com> wrote in message > news:9lh1e7$hqi$1@slb6.atl.mindspring.net... > > There is really no reason you can not make 25MHz, much less 33MHz with > your > > FPGA...if you're in an appropriate part, and your logic is "correct". > > > > What part are you using, and what is causing your PCI interface to be so > > slow? Please be very specific in this answer if you could, and I might be > > able to help you. > > Sorry this took a few days to get back... My main news server wasn't getting > articles for some reason, so I had to switch servers. I'd still love some > comments! Here's some responses and updates: > > - The goal is to prototype an ASIC in an FPGA. The extremely deep logic > causes a problem. Even with floorplanning and synthesis optimizations, > calculating an address pointer in half the cycle is trivial with ASIC gate > delays but very difficult with FPGA gate delays. With the design partitioned > across several virtexE 2000 -6 chips, even with floorplanning and synthesis > improvements, I can hardly get the design above 12-14 MHz which is not even > close to the 25 constraint. > I'm with Austin on this. It *is* possible to get a Virtex-E to meet 33MHz PCI timing. I was in a similar position ~2.5 years ago when (1) I had to proto a PCI i/f destined, ultimately, for an ASIC and (2) a bought in IP solution was not acceptable to the client. I never quite got the all-important 7nsec Tsu but the proto board ran quite happily at the 8-8.5nsec I could achieve with a -4 (non-E) Virtex. It wasn't easy since this was in the days of Xilinx's "who needs a Floorplanner for Virtex" so it had to be done with some very careful coding & attention so what the synth tool was doing. Migrating to the -6 E parts & all the hard work paid off since Tsu is now comfortably ~6ns, with some floorplanning I could get it down to 5nsec if need be. The basic trick I discovered (although I'm not claiming any originality) is to strip the master/target core statemachines down to the absolute minimum and "offline" everything that doesn't absolutely *have* to be driven direct out of them [6/5 states resp.]. Only these core machines + the outgoing data pipe control should use the raw, unregistered, PCI signals as inputs. One question I might ask is what Synth tool are you using ? We use Synplify.Article: 34324
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