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
The issue is not whether or not it works, rather it is an issue of noise added
to you sampled signal due to sampling jitter. A better set-up is to run the
clock directly from your oscillator to the ADC and to the FPGA, then use the DLL
in the FPGA to solve the I/O timing issues at the ADC. Frequently, the ADC data
is brought through a discrete registers such as an 'LS374 before going into the
FPGA to improve the timing relationship at the expense of an additional cycle of
clock latency.
Amazingly, several of the commercial boards out there that have an FPGA and a
decent speed ADC are set up with the ADC clock supplied through the FPGA, an
arrangement that doesn't make sense for real DSP applications.
Noddy wrote:
> Hi Ray,
>
> > Depends on how much jitter is acceptable in your application. JItter at
> the
> > ADC clock translates to noise in your system. A DLL adds some jitter to
> your
> > clock, so it is usually not appropriate to use a clock that has gone
> through a
> > DLL to clock an ADC when you are sampling IF or RF signals. We try to use
> an
> > externally generated clock for clocking both the ADC and the FPGA.
>
> Just a quick question as to the amount of jitter introduced by DLL. I am
> using an external clock (which has precision of 1 mHz). I have quadrature
> mixed my IF down to DC, and am sampling at 32 MHz (nominally). The way my
> clocks are set up are that the external clock goes directly to FPGA (DLL),
> then is fed out from the FPGA to the ADC (I did it this way to solve some
> timing issues between the FPGA and ADC). Would you suggest otherwise? It
> seems to be working at the moment.
>
> adrian
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45151Hi Ray! > The issue is not whether or not it works, rather it is an issue of noise > added to you sampled signal due to sampling jitter. A better set-up is > to run the clock directly from your oscillator to the ADC and to the > FPGA, then use the DLL in the FPGA to solve the I/O timing issues at the > ADC. Frequently, the ADC data is brought through a discrete registers > such as an 'LS374 before going into the FPGA to improve the timing > relationship at the expense of an additional cycle of clock latency. I decided to route the clock directly to the ADC and in parallel to the FPGA instead of routing it through the FPGA. The oscillator I've chosen has 3-5ps RMS jitter, which is below my calculated 7.8ps. The ADC itself has 2ps. But my oscillator is able to handle only 30pF max load. One ADC has 5 pF where I have 4 of. A Spartan-II, Virtex, Virtex-E has 8 pF input capacitance, a Virtex-II (Pro) has 10pF. The SRAM has a lot too. How can I amplify the clock? :-) IDT and Cypress provide clock distribution ICs, but they have >1-2ns propagation delay. And the data sheets don't say anything of additional jitter introduced by the ICs. Do you know how to amplify the clock without adding (too much) jitter? Thanks HansiArticle: 45152
Hi all, Based on Nick Weaver's estimate (Thanks, Nick) of configuration bits for a slice (57), and XAPP151, from which I've derived a figure of 864 bits/CLB (including both logic and routing), the proportion of configuation bits used for routing the logic in Virtex is 86.8%. I've had a look at the routing diagram for the XC4000X devices (Figure 27 of the 4000E/X datasheet), and estimate the configuration bits for routing to be ~580. However, an XC4085XL requires 1,924,240 bits of configuration data in total. It also has 3,136 CLBs and 448 IOBs. Even assuming that the IOBs require NO configuration at all (!), this would only leave 614 bits per CLB, which implies that the estimate of 580 is too high (each CLB requiring 32 bits for the LUTs, plus some for local interconnect). In arriving at this figure of 580, I've assumed 6 bits for each of the elements of the swtich matrix, and six for the three corner-turning connections of the quadlines (marked as diamonds in the diagram). Does anyone have any idea where an error is being introduced? Regards, SteveArticle: 45153
> Do you know how to amplify the clock without adding (too much) jitter? Best advice is to look at what the ADC chip designers recommend. Difficult to be more specific without knowing more details. e.g. AD6645 (80/100 MHz 14 bit) has lots of advice on its data sheet about best choice of clock arrangement. AN501 at www.analog.com is about Aperture uncertainty and ADC clock requirements.Article: 45154
Arrigo Benedetti <arrigo@vision.caltech.edu> wrote: : Does the most recent version of the Webpack run well under Linux/Wine? : I am interested in the command tools only. It's not for the faint hearted, but you can go quite a long way with the most recent wine version. Also there is one patch hanging around from me that keeps webpack from crashing in the device selection that is still not applied to the main tree. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 45155
Why is this important? Everybody agrees that the Look-Up Tables and flip-flops are an insignificant part of FPGA complexity, but where does logic end, and where does interconnect begin? How's about intra-CLB interconnect, tying the eight (!) LUTs in a Virtex-II CLB together? What's the purpose of the question? Just curious. Peter Alfke ====================== Steve Charlwood wrote: > Hi all, > > Based on Nick Weaver's estimate (Thanks, Nick) of configuration bits for > a slice (57), and XAPP151, from which I've derived a figure of 864 > bits/CLB (including both logic and routing), the proportion of > configuation bits used for routing the logic in Virtex is 86.8%. > > I've had a look at the routing diagram for the XC4000X devices (Figure > 27 of the 4000E/X datasheet), and estimate the configuration bits for > routing to be ~580. However, an XC4085XL requires 1,924,240 bits of > configuration data in total. It also has 3,136 CLBs and 448 IOBs. Even > assuming that the IOBs require NO configuration at all (!), this would > only leave 614 bits per CLB, which implies that the estimate of 580 is > too high (each CLB requiring 32 bits for the LUTs, plus some for local > interconnect). In arriving at this figure of 580, I've assumed 6 bits > for each of the elements of the swtich matrix, and six for the three > corner-turning connections of the quadlines (marked as diamonds in the > diagram). > > Does anyone have any idea where an error is being introduced? > > Regards, > > SteveArticle: 45156
This will work! :-) Peter Alfke, Xilinx Applications Steve T Shannon wrote: > Hello! I am designing a system with a series of identical add-in data > acq. cards. Each card interfaces with a shared bus via a Spartan-II > from xilinx. I am trying to avoid the expensive serial PROM > configuration option, and instead would like to configure each device > in slave serial mode. Each FPGA (of which there will be 1/board, or > ~16) will be running identical code. Since both the /INIT and DONE > lines are open-drain, can i just wire all the DIN, CCLK, /INIT, and > DONE lines for each FPGA in parallel, and clock data in like it's a > single FPGA? All FPGAs would need to be ready to receive the bitstream > (i.e. have /INIT high) in order for the aggregate /INIT to actually be > high; similar behavior would be apparent with DONE. Is there any > reason why this won't work?? > > Thanks, SteveArticle: 45158
I like to respond to posts with an idea of the end goal. I'm stumped. The XC4000 is old technology by now so your interest there is confusing. If you know the actual values for any device, what can the information do for you? Are you looking for silicon versus metal reliability figures? Alpha partical event upset issues? Reverse engineering the FPGA industry to develop your own product? Producing programming file logic deltas for fixed routing? If you give a better idea of where the information is heading, the right people might be able to address the real issue. Steve Charlwood wrote: > Hi all, > > Does anyone have any good estimates of the proportion of an FPGA's > configuration memory used for defining the interconnect, or can provide > me with a sensible way of estimating the number of configuration bits > used by a Xilinx Virtex CLB (not including routing external to the CLB)? > This information could probably be determined for Xilinx devices by > someone with the JBits toolkit (and time on their hands). Has anyone > done this? I would be interested in any data, but especially for Xilinx > chips: XC4000X, Virtex and later architectures. > > Any help would be appreciated. From XAPP151 I've estimated the total > number of coniguration bits per CLB and per IOB _including_ the routing, > and would like to split this figure up. > > Regards, > > SteveArticle: 45159
Ray, I agree with you that 4.x has some problems, but for V-II, it's a necessity. We are presently doing V-E designs, and we've noticed that 4.2's PAR tool was tweaked to run fast, not provide quality results. We've used the Floorplanner to get the job done, and it doesn't do that well, either. The client company doesn't like going back to previous SW, but I will consider asking them if we can install 3.3SP8 to make the design less troublesome. One reason that they may consider it is because they like a simplified design flow in order to make changes when I'm gone, and Floorplanning introduces complexity. It may be worthwhile to play with 3.3SP8 and see what the results are. Thanks for the tip. Simon "Ray Andraka" <ray@andraka.com> wrote in message news:3D3046E6.512ABBBF@andraka.com... > There are exceptions to that, of course. For example, if I am not designing in > VirtexII or IIP, I am still using M3.3sp8 because 1) the floorplanner in 4.x is > seriously broken, and 2) the router in 3.3sp8 does a considerably better job > than the router in 4.x with a given placement. I haven't compared routing > results for VirtexII between the two versions. Based on some of the things the > 4.2 router is doing in a carry-chain intensive V2 design, I suspect the 3.3 > virtexII routing is also better for a given placment. Unfortunately, the 3.3 SW > doesn't know about the pipeline register in the multipliers and has overly > optimistic speed files for V2.Article: 45160
You may also want to look at ValpeyFisher. See the VFAC570 at http://www.valpeyfisher.com/Data/DescriptionFiles/VF(B5FB3).pdf You should be able to use a non-pll clock buffer chip. Make sure that you use a separate low-noise regulated supply for the crystal oscillator and clock buffer and keep the clock lines away from noisy digital lines. Daniel Lang "Johann Glaser" <Johann.Glaser@gmx.at> wrote in message news:agpjt7> Aaaj, I see. The data sheet says ADC jitter are 2 ps. I found really nice > oscillators at http://www.mfelectronics.com/ with extra low jitter saying > downto 5 ps RMS (and 25 peak-peak). They also fulfill the requirement of > rise and fall time being no more than 2ns. They have really nice things > there. :-) > > Bye > HansiArticle: 45161
On Fri, 12 Jul 2002 08:07:39 GMT, Petter Gustad <newsmailcomp3@gustad.com> wrote: >allan_herriman.hates.spam@agilent.com (Allan Herriman) writes: > >> On Thu, 11 Jul 2002 09:32:01 -0700, Alan Nishioka <alann@accom.com> >> wrote: >> >> >The .bit file contains the date and time from the ncd file in its >> >header, so at the very least, this will change. >> > >> >The actual bitstream should be the same, but I don't use the same >> >toolchain so I don't know for sure. >> >> We have had problems with the 3.1i tools. Sometimes the downloads >> would differ between different computers, even though the inputs >> (edif, ucf) were identical, and the software version was identical. >> Reinstalling the software on all machines concerned didn't improve >> matters. >> The differences we were seeing were quite significant: some downloads >> would work, and others were completely nonfunctional. >> >> Xilinx said that they would look into this, but I'm not sure if it has >> been fixed in the 4.2 tools. >> >> OTOH, I've always had identical results from a given PC. > >Are you sure there isn't some setting stored in the Windows registry >which is causing this? I don't think so, but I'm not entirely sure. Xilinx said they were going to do something about it, but I don't know if they ever determined the root cause of the problem. Regards, Allan.Article: 45162
"BROTO Laurent" <lbroto@free.fr> wrote in message news:<3d2c25ec$0$559$626a54ce@news.free.fr>...
> Today, we've a Spartan with a PLX. We would like to introduce Logicore in
> Spartan to replace PLX but IO aren't the same (excuse me for my english...
> I'm french).
> Do you know an interface to use my old VHDL program (with PLX IO) with a
> logicore without modification ?
>
> Thanks a lot,
>
> BROTO Laurent
Using LogiCore will require a non-trivial design effort:
PLX chips create a simple secondary bus, which is asynchronous to the
PCI bus and synchronized to your on-board clock. The PLX chip handles
all details of handshaking, buffering and moving across clock domains.
The LogiCore is primarily a PCI-domain state machine and data path.
You have to build all the buffering (FIFOs/registers) and the control
state-machine. Xilinx documentation gives some sample designs, but if
your design can't fit exactly to their samples, you are on your own.
Also, the logic for crossing clock domains between the PCI and your
system clock is hard to simulate and even harder to debug on real
hardware (since the simulation can't cover all the nasty surprises
caused by async logic and timing violations).
I would suggest that the only reason to move to LogiCore is that your
system will be manufactured in large enough numbers to be
cost-effective (X PLX chips vs. fixed-cost of core + conversion effort
+ higher price per FPGA to include the core).
Regards
Assaf Sarfati
Article: 45163Hi! > e.g. AD6645 (80/100 MHz 14 bit) has lots of advice on its data sheet > about best choice of clock arrangement. Thanks, they have really good tips. Bye HansiArticle: 45164
Hi! > You may also want to look at ValpeyFisher. See the VFAC570 at > http://www.valpeyfisher.com/Data/DescriptionFiles/VF(B5FB3).pdf Wow, this one has only 1ps jitter. And can drive up to 50pF load. > You should be able to use a non-pll clock buffer chip. Make sure that > you use a separate low-noise regulated supply for the crystal oscillator > and clock buffer and keep the clock lines away from noisy digital lines. I found series ferrite filters on the datasheet from Analog Devices' AD6645. May that be enough? Thanks HansiArticle: 45165
Hi all, By way of an explanation... --------------------------- The reason that I'm interested in the the proportion of the configuration data for a particular device used for routing is that in order to partially-reconfigure a device (such as the Xilinx Virtex architecture), it is necessary to ensure that residual configuration data does not interfere with the new configuration. Connections to the global interconnect obviously can cause interference regardless of the region into which the new operator is configured, but even local routing, such as the hex lines of the Virtex could cause problems where the new operator overlaps a previous one (for example, hex lines can be driven from both ends, which could lead to problems if the new configuration drove one end whilst the other was still configured to drive in the opposite direction by a previous configuration). Preventing these problems requires over-writing any routing connections of previously-configured operators that could conceivably interfere (or cause harm to the device). In Virtex, with its frame-based configuration subsystem, overwriting just the routing is not possible, since frames contain both routing and configuration data. However, in order to gain maximum benefit from re-using operators previously configured, just overwriting that routing which is necessary would be desirable. Knowing the proportion of the configuration data that corresponds to routing would allow me to put an upper bound on the cost of eliminating routing for a previous operator, given that CLB (along with all intra-CLB routing) and inter-CLB routing configuration data was organised in such a way that it could be accessed separately. Any comments welcomed. Regards, Steve PS. I have no particular interest in the XC4000 series other than it would be interesting to see if there is an upward trend in the ratio of configuration data used for routing to that for CLBs. I thought there might also be a greater likelihood that the data is availabe for the XC4000 series.Article: 45166
Uwe Bonnes wrote: > Arrigo Benedetti <arrigo@vision.caltech.edu> wrote: > : Does the most recent version of the Webpack run well under Linux/Wine? > : I am interested in the command tools only. > > It's not for the faint hearted, but you can go quite a long way with the > most recent wine version. Also there is one patch hanging around from me > that keeps webpack from crashing in the device selection that is still not > applied to the main tree. > > Bye Alexandre applied a patch: http://www.winehq.com/hypermail/wine-cvs/2002/07/0038.html which seemed to fix that problem for me. At least in my case, there are mainly two things that don't work with the Webpack GUI. One is that running XST synthesis from the GUI does not ever complete. But XST can be run from the command line under Wine, and it works fine. When run from the GUI once, the XST configuration files (<project>.xst and <project>.prj) seem to get set up correctly, making it easy to then run XST again from the command line. The other is that things like source files never get written into the project file <project>.npl. But these are plain text files and can the info can be added with a text editor. Still, it is probably easier to run the tools from the command line until these bugs can be worked out. -- My real email is akamail.com@dclark (or something like that).Article: 45167
Steve, let me just clarify something you probably know: XC4000 is really obsolete. Virtex-type devices are "better, bigger, faster, and cheaper". No mainstream FPGA prior to Virtex ever allowed partial reconfigurtion ( yes, I know XC6200 did, that's why a said "mainstream"). Virtex partial reconfiguration must always be with complete "frames", i.e. vertical strips, but nothing happens while the new frame is being shifted in. The whole new frame then overwrites the old one "instantly". Whether routing bits are 80% or 90% or 95% should not make much of a difference... Peter Alfke, Xilinx Applications Steve Charlwood wrote: > Hi all, > > By way of an explanation... > --------------------------- > > The reason that I'm interested in the the proportion of the > configuration data for a particular device used for routing is that in > order to partially-reconfigure a device (such as the Xilinx Virtex > architecture), it is necessary to ensure that residual configuration > data does not interfere with the new configuration. Connections to the > global interconnect obviously can cause interference regardless of the > region into which the new operator is configured, but even local > routing, such as the hex lines of the Virtex could cause problems where > the new operator overlaps a previous one (for example, hex lines can be > driven from both ends, which could lead to problems if the new > configuration drove one end whilst the other was still configured to > drive in the opposite direction by a previous configuration). Preventing > these problems requires over-writing any routing connections of > previously-configured operators that could conceivably interfere (or > cause harm to the device). In Virtex, with its frame-based configuration > subsystem, overwriting just the routing is not possible, since frames > contain both routing and configuration data. However, in order to gain > maximum benefit from re-using operators previously configured, just > overwriting that routing which is necessary would be desirable. Knowing > the proportion of the configuration data that corresponds to routing > would allow me to put an upper bound on the cost of eliminating routing > for a previous operator, given that CLB (along with all intra-CLB > routing) and inter-CLB routing configuration data was organised in such > a way that it could be accessed separately. > > Any comments welcomed. > > Regards, > > Steve > > PS. I have no particular interest in the XC4000 series other than it > would be interesting to see if there is an upward trend in the ratio of > configuration data used for routing to that for CLBs. I thought there > might also be a greater likelihood that the data is availabe for the > XC4000 series.Article: 45168
Duane Clark wrote: > Mike Rosing wrote (on 7/13/2002): > Wow, two days before the quote you were replying to :-) Yeah, ain't the net wonderful :-) I tried replacing the battery in my motherboard, but it didn't make a difference. I think the clock only runs when there's main power to the board, so I'm losing about 2 hours a day somehow. Intel marches on.... > For simulation, you need to specify the library: [nice details snipped] OK, that actually makes sense. Will it work just as well for synthisis as for simulation? -- Mike Rosing www.beastrider.com BeastRider, LLC SHARC debug toolsArticle: 45169
Back in early June, Kevin Brace (I think) noted that one can generate an EDIF netlist in Webpack if you run XST from a batch file. I tried it back then, and indeed it worked. I recently upgraded my hard drive, reinstalled WebPack, and have been using Webpack and ModelSIM. However, now when I try to generate an EDIF netlist using the XST command as Kevin specified, I get an error message saying "XILINX environment variable not set." I didn't have this problem before, and XST still generates the (groan) NGC netlist from the Webpack IDE. There is probably a simple solution, but I can't find it. Any pointers? Thanks, MichaelArticle: 45170
MICHAEL ALEX <michaelalex@attbi.com> wrote: : Back in early June, Kevin Brace (I think) noted that one can generate an : EDIF netlist in Webpack if you run XST from a batch file. I tried it : back then, and indeed it worked. I recently upgraded my hard drive, : reinstalled WebPack, and have been using Webpack and ModelSIM. However, : now when I try to generate an EDIF netlist using the XST command as : Kevin specified, I get an error message saying "XILINX environment : variable not set." I didn't have this problem before, and XST still : generates the (groan) NGC netlist from the Webpack IDE. There is : probably a simple solution, but I can't find it. Any pointers? Did you try the simple solution: Set the "XILINX environment variable"? set XILINX=c:\xilinx ( or where your xilinx tree resides). Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 45171
Duane Clark <junkmail@junkmail.com> wrote: : Uwe Bonnes wrote: :> Arrigo Benedetti <arrigo@vision.caltech.edu> wrote: :> : Does the most recent version of the Webpack run well under Linux/Wine? :> : I am interested in the command tools only. :> :> It's not for the faint hearted, but you can go quite a long way with the :> most recent wine version. Also there is one patch hanging around from me :> that keeps webpack from crashing in the device selection that is still not :> applied to the main tree. :> :> Bye : Alexandre applied a patch: : http://www.winehq.com/hypermail/wine-cvs/2002/07/0038.html : which seemed to fix that problem for me. Have to check that... : At least in my case, there are mainly two things that don't work with : the Webpack GUI. One is that running XST synthesis from the GUI does not : ever complete. But XST can be run from the command line under Wine, and : it works fine. When run from the GUI once, the XST configuration files : (<project>.xst and <project>.prj) seem to get set up correctly, making : it easy to then run XST again from the command line. : The other is that things like source files never get written into the : project file <project>.npl. But these are plain text files and can the : info can be added with a text editor. Still, it is probably easier to : run the tools from the command line until these bugs can be worked out. For me it looks as if the wrapper (exewrap) around the command line tools communicates withe the command line tools in a way not yet supported in wine. Some help form Xilinx people would be appriciated. Also I noticed a great speed difference with native msvcrt versus builtin. Have to investigate too... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 45172
Greetings all, I am a newbie to FPGA & VHDL (currently a junior CoE at
NJIT). I have a Xess XSA-50 protoboard with a XC2S50 FPGA and am
using the latest Xilinx Webpack to create simple VHDL models like
comparators, d-q FFs, carry bit adders, etc to get a feel for things.
I run into trouble when I try to assign a signal in a process
sensitivity list to various FPGA locations such as buttons, parallel
port locations, etc. With my d-q FF, for example, I had wanted to use
the push button as a 'clock' input. My code seems straightforward and
simple enough:
process (clk)
begin
if (clk'EVENT) AND (clk = '1') THEN
-- flip flop code here
end if;
end process;
However, if I assign clk to pin 93, the pushbutton, I receive the
following error during the "Map" stage of "Implement Design":
ERROR:MapLib:93 - Illegal LOC on symbol "clk" (pad signal=clk) or
BUFGP symbol
"clk_BUFGP" (output signal=clk_BUFGP), IPAD-IBUFG should only be
LOCed to
GCLKIOB site.
To correct the situation, I simply assigned clk to the FPGA's internal
oscillator. (As the error message suggests). Being new to both VHDL &
FPGAs I am curious, what if my design required me to act upon a change
in those other locations? Do I need some sort of work-around, or am I
simply missing something obvious?
Thanks,
Joe Lawrence
-- jdl1291@njit.edu
Article: 45173
"S. Ramirez" wrote:
> Ray,
>
> I agree with you that 4.x has some problems, but for V-II, it's a necessity.
Unfortunately true. If we change the multipliers and back off on the timing,
route it with 3.3sp then do the timing analysis with 4.2 the results seem to be
quite a bit better (albiet unusable) than what the 4.2 router does. Sure would
be nice to have a setting that reverts back to the 3.3 router.
>
>
> We are presently doing V-E designs, and we've noticed that 4.2's PAR tool
> was tweaked to run fast, not provide quality results. We've used the
> Floorplanner to get the job done, and it doesn't do that well, either. The
> client company doesn't like going back to previous SW, but I will consider
> asking them if we can install 3.3SP8 to make the design less troublesome.
> One reason that they may consider it is because they like a simplified
> design flow in order to make changes when I'm gone, and Floorplanning
> introduces complexity. It may be worthwhile to play with 3.3SP8 and see
> what the results are.
Unfortunately, we've found the floorplanner to be nearly useless in 4.1/4.2
because it drops all the G/Y elements when try to place an RLOC'd macro. The
only work around is to let it do an autoplace, then constrain from placement,
then unbind and bind all the RPMs. Unfortunately, in a dense design (with large
RPMs), PAR gives up with no placement solution so that workaround isn't
available when you need it the most. I've also tried using RLOC_ORIGINs in the
ucf to help the placer out, but those seem to get ignored as often as used (the
weird thing there is the floorplanner recognizes the RLOC origin and puts the
decimated RPM in the right place, but the placer just blows them off). Part of
the reason we do so much RLOCed logic in the code is to avoid the customer
having to spend lots of timein floorplanner when he goes to change stuff in the
design, but the bigger reason is because we don't want to spend weeks on end in
the floorplanner.
>
>
> Thanks for the tip.
>
> Simon
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3D3046E6.512ABBBF@andraka.com...
> > There are exceptions to that, of course. For example, if I am not
> designing in
> > VirtexII or IIP, I am still using M3.3sp8 because 1) the floorplanner in
> 4.x is
> > seriously broken, and 2) the router in 3.3sp8 does a considerably better
> job
> > than the router in 4.x with a given placement. I haven't compared
> routing
> > results for VirtexII between the two versions. Based on some of the
> things the
> > 4.2 router is doing in a carry-chain intensive V2 design, I suspect the
> 3.3
> > virtexII routing is also better for a given placment. Unfortunately, the
> 3.3 SW
> > doesn't know about the pipeline register in the multipliers and has overly
> > optimistic speed files for V2.
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45174
Peter Alfke wrote:
> Steve, let me just clarify something you probably know:
> XC4000 is really obsolete. Virtex-type devices are "better, bigger, faster,
> and cheaper".
> No mainstream FPGA prior to Virtex ever allowed partial reconfigurtion (
> yes, I know XC6200 did, that's why a said "mainstream").
Atmel 6K and 40K devices also support partial configuration, and have since
long before the 6200 ever came out...while those are not "mainstream" devices
either, I'd venture to say that many more of them have made it into products
than the 6200. I know I have several customers I used those parts for in the
first half of the '90s because they supported partial configuration in some
cases and because they had the highest flip-flop count of any FPGA for a long
time in others. The Atmel devices configure a cell at a time.
>
> Virtex partial reconfiguration must always be with complete "frames", i.e.
> vertical strips, but nothing happens while the new frame is being shifted
> in. The whole new frame then overwrites the old one "instantly".
> Whether routing bits are 80% or 90% or 95% should not make much of a
> difference...
>
> Peter Alfke, Xilinx Applications
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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