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
I have 1 Virtex 600E dead for unknow reason (still investigating). If I give it to you, are you able to open it and see why it died ? Cheers ! Pierre John_H <johnhandwork@mail.com> wrote in message news:<3D93A16F.CDB861A1@mail.com>... > Not free, but cheap and dead unless you reball 'em: > > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1771334936 > > > David wrote: > > > Hello, > > > > I'm looking for a really dead virtex. Is anybody have one or several > > dead virtex to give to me ? > > > > Thanks in advance. > > > > DavidArticle: 47526
With JTag you move to several different states by changing the TMS signal and then toggling the clock. There are two types of states that look at the TDI pin: data and command states. When your in the command state you shift in a string whos lenght is the sum of all the command registers in the chain. Most offten your command string will be to put all the devices but one into the bypass mode. The virtex jtag command register length is 5 bits long. Suppose you have two virtex in a chain then the command word 10 bits long. to read the idcode of the first virtex you scan in 0100111111 to the command register and to get the second you scan in 1111101001. There is an example of how to do this in the HOTMan program. Steve Look for HOTMan at www.vcc.com "Valentin Tihomirov" <valentin@abelectron.com> wrote in message news:3d943028$1_2@news.estpak.ee... > Hello, > I'm trying to program CPLD device, which can't be found through non-standard > cable. I would like to stimulate it myself to make sure it's alife. There is > example on the Xilinx site > http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/trbshoot5.html, > describing how to send IDCODE request. I'm confused, > > [1] the always-'1' TDI means BYPASS instruction?! > [2] How does currently loaded instruction affect states sransitition and > outputs? > > Thanks > >Article: 47527
"Dongho" <dhan@ecel.ufl.edu> schrieb im Newsbeitrag news:f6f40449.0209261223.55d8b63a@posting.google.com... > I intend to implement adaptive FIR(LMS) with 100~600 inputs. > I need to update within every 100ms, number of filter tap is 10, input > precision is 8bits, and coef. precision is 8bits. > Is it hard to implement with ALTERA(especially updating coef.)? How > about with Stratix? Is it same? Wasnt this question around a while ago? As Ray Andraka said, its better to solve this really slow speed stuff with a conventional DSP, since the tools and designer for DSPs are much more common available. ;-) Stratix is DEFENITELY overkill for this. -- MfG FalkArticle: 47528
Do you really want dual port RAM, or are you using it to build a FIFO? There are lots of FIFOs available as single chips. Much easier to get than dual port RAMs. Fewer pins and simpler logic too. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47529
Valentin Tihomirov wrote: > > > All you have to do is construct a ring feedback path with three 2-input > > NAND gates and then pull the other inputs to a one. > > Synthesier must complain that a signal is driven by several sources. Not sure what you are doing. How about showing your code. Here is a little pseudo code, it has been awhile since I have actually written in an HDL. a <= !(b AND enable); b <= !(c AND enable); c <= !(a AND enable); As someone else pointed out, you may want to only use the enable on a subset to help with a stable startup condition. -- 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: 47530
> The _synthesis_ tool is passing constraints it comes up with onto the Xilinx P&R tool. These > constraints are making the timing fail. It was inferring constraints that may not have been real. > > I believe I unchecked a box in the Xilinx Gui that stopped the synthesis tool from writing a .ncf file and I > deleted the one that was existing. I learned that the .ncf file is "sticky" and each time the synthesis tool > runs, it just appends more and more constraints to the file, making the design harder to P&R. Yeah, I've learned as well to turn off the "write ncf" option to avoid unwanted/conflicting constraints between what Synplicity does and what I want Xilinx to do. You might want to consider creating a Tcl script to control your Synplify compiles (the project file is basically a Tcl script). That way when you find a good group of settings you can code them into your script, run it in the background from an icon on your desktop, and not worry about a setting getting changed by accident in the GUI. It's also a simple matter to change the manifest file the script looks at so you can port all the settings to your next project. Pete -- Peter Young Hardware Designer AMIRIX Systems - Halifax, N.S. http://www.amirix.com (remove spam block in address to reply by e-mail)Article: 47531
Michael Tornow wrote: > I have checked this vhdl code with Leonardo Spectrum too. No errors were > found. If you have leo available, use that to make a .edf for Quartus. Quartus vhdl synthesis is a work in progress. Leo will accept, with warning, component instances for vendor functions, but consider writing your own code. -- Mike TreselerArticle: 47532
**Please email responses to mph@xiphos.ca Hi, I'm having a little problem here and I'm hoping someone has some input to help me out. I am using Foundation 4.1i sp3, with both 4x_ip_update1.zip and eip1_tp1.zip installed. It has taken me an incredibly long time to figure out how to successfully package and instantiate my own cores using Foundation/CoreGenerator/IP Capture. I create my .edn netlist file for the core by synthesizing my design in Foundation. The file is available in the project's dpm_net folder afterwards. Before proceeding, the optimization settings must be specified: optimize for speed/area, and effort level high/low are the options. My problem is that depending upon the settings chosen when synthesizing the core's netlist, and the synthesis settings chosen in the project which instantiates the core, once downloaded to the target device it doesn't always work. By settings I mean low/high effort and area/speed optimization. There 16 possible combinations, all of which I have tested, here are the results: ***********1) Core netlist Synthesis Settings: High Effort/Optimize for Area 1a) Core-instantiating project synthesis settings High/Area Doesn't work 1b) Core-instantiating project synthesis settings Low/Speed Works. 1c) Core-instantiating project synthesis settings Low/Area Works. 1d) Core-instantiating project synthesis settings High/Speed Works ***********2) Core netlist Synthesis Settings: Low Effort/Optimize for Speed 1a) Core-instantiating project synthesis settings High/Area Doesn't work 1b) Core-instantiating project synthesis settings Low/Speed Doesn't work. 1c) Core-instantiating project synthesis settings Low/Area Works. 1d) Core-instantiating project synthesis settings High/Speed Doesn't work. ***********3) Core netlist Synthesis Settings: Low Effort/Optimize for Area 1a) Core-instantiating project synthesis settings High/Area Works. 1b) Core-instantiating project synthesis settings Low/Speed Works. 1c) Core-instantiating project synthesis settings Low/Area Works. 1d) Core-instantiating project synthesis settings High/Speed Doesn't work. ***********4) Core netlist Synthesis Settings: High Effort/Optimize for Speed 1a) Core-instantiating project synthesis settings High/Area Doesn't work 1b) Core-instantiating project synthesis settings Low/Speed Doesn't work. 1c) Core-instantiating project synthesis settings Low/Area Works. 1d) Core-instantiating project synthesis settings High/Speed Doesn't work. The problem with this is that there isn't one way of generating the core's netlist which guarantees it will work regardless of the synthesis settings chosen for the core-instantiating project. We are planning on using IP Capture to produce distributable cores... and with these results the best I can do is create the core's netlist using Low/Area synthesis settings, with the assumption that in most core instantiating projects High/Area synthesis settings will be chosen. Any input would be much appreciate. Please email responses to mph@xiphos.ca THANKS!Article: 47533
> I would look in the file generated by your synthesis tool (edif for > synplicity) because that's where the nets are named with such generic names. I'd also look for warnings in the log file generated by the synthesis tool. One tool's error is another tool's warning, so the synthesizer may have noticed the problem (and indicate the file it occurs in) but not seen it as a show stopper. Check if there are any warnings about signals being optimized out or tied to a given value that you can't explain, and especially any to do with tristates. Good luck! Pete -- Peter Young Hardware Designer AMIRIX Systems - Halifax, N.S. http://www.amirix.com (remove spam block to reply by e-mail)Article: 47534
In article <91710219.0209270400.3af5b3ca@posting.google.com>, Nagaraj <nagaraj_c_s@yahoo.com> wrote: >Hello, > Thanx for the reply. > I require around 48K bits of memory. An XCV50E/XC2V40 should do the >job. Thats fine. > Now regarding your question about using memory in the existing >FPGA. I have my core logic plus the memory in the existing FPGA. In >the final product, the core logic will be converted to ASIC. But I am >not sure about the memory. Because as I understand it is difficult to >implement memory in ASIC of my required size (not digital ASIC) in >terms of process as well as cost, compared to external chip. First of >all, is this true? If so, I have to have another FPGA to implement >memory, as you told. Why would an ASIC have trouble with memory? Just about every ASIC process would have to have various memory blocks in the library which you could use, otherwise you would go completely crazy. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 47535
On Fri, 27 Sep 2002 18:15:14 +0000 (UTC), nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: >In article <91710219.0209270400.3af5b3ca@posting.google.com>, >Nagaraj <nagaraj_c_s@yahoo.com> wrote: >>Hello, >> Thanx for the reply. >> I require around 48K bits of memory. An XCV50E/XC2V40 should do the >>job. Thats fine. >> Now regarding your question about using memory in the existing >>FPGA. I have my core logic plus the memory in the existing FPGA. In >>the final product, the core logic will be converted to ASIC. But I am >>not sure about the memory. Because as I understand it is difficult to >>implement memory in ASIC of my required size (not digital ASIC) in >>terms of process as well as cost, compared to external chip. First of >>all, is this true? If so, I have to have another FPGA to implement >>memory, as you told. > >Why would an ASIC have trouble with memory? Just about every ASIC >process would have to have various memory blocks in the library which >you could use, otherwise you would go completely crazy. Actually you get what's called a memory compiler which generates various types and sizes of memory just as the FPGA tools do (genmem in A or coregen in X). Here is an example: http://www.artisan.com/products/memory/ This and other memory compilers from library vendors generate a simulation model and the physical design of the memories (in GDS2 and LEF format) so that you can instantiate them in your RTL and do P&R with a tool like SE. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 47536
Valentin Tihomirov wrote: > I attach only 5V power ang ground to the chip(that's all). I think the > problem raised after my attempt to configure the device manually. The > download cable was not functioning and I wanted to stimulate the device > manually resetting the boundry scan controller (TRST sequence) and capturing > (all 1s) instruction as described in Xilinx Troubleshooting guide > (http://toolbox.xilinx.com/docsan/3_1i/data/common/jtg/dppc/appc.htm#BHAICAB > I). And now the chip is consuming so much power that LED on the power supply > stops ligting. Well, it is possible to glitch the 9500 CPLDs so that they have a pathological program, and run anywhere from warm to burning hot. If you can get to it soon enough, and let it cool, and then reprogram them, they usually survive. I've had some problems with them, especially with the parallel cable. Some computers don't work well with the parallel cable, and will start programming and then quit, leaving the CPLD in a garbled state. And, sometimes, when moving a chip from one board to another, etc. they just get garbled, and need to be reprogrammed. JonArticle: 47537
Hello, what is the maximum possible speed that a BRAM can be clocked with? I am interested on the values for Virtex, Virtex-e, Virtex-2 if someone show me how can i deduce it from the datasheets, i will be really glad thanksArticle: 47538
Thanks for validating my approach and the suggestion for the tcl script. I need to become more tcl literate.... Clyde Peter Young wrote: > > The _synthesis_ tool is passing constraints it comes up with onto the Xilinx P&R tool. These > > constraints are making the timing fail. It was inferring constraints that may not have been real. > > > > I believe I unchecked a box in the Xilinx Gui that stopped the synthesis tool from writing a .ncf file and I > > deleted the one that was existing. I learned that the .ncf file is "sticky" and each time the synthesis tool > > runs, it just appends more and more constraints to the file, making the design harder to P&R. > > Yeah, I've learned as well to turn off the "write ncf" option to avoid > unwanted/conflicting constraints between what Synplicity does and what I > want Xilinx to do. You might want to consider creating a Tcl script to > control your Synplify compiles (the project file is basically a Tcl > script). That way when you find a good group of settings you can code > them into your script, run it in the background from an icon on your > desktop, and not worry about a setting getting changed by accident in > the GUI. It's also a simple matter to change the manifest file the > script looks at so you can port all the settings to your next project. > Pete > -- > Peter Young > Hardware Designer > AMIRIX Systems - Halifax, N.S. > http://www.amirix.com > (remove spam block in address to reply by e-mail)Article: 47539
The block ram speed is limited by the interconnect to it. If you can avoid using the
we and ena signals (tie both active and then use the write address count to direct
unwanted writes to trash locations) and you pipeline the address and data so that
there is no logic between the registers and the BRAM, and you floorplan it so that
those registers are on shortest wires you'll get the maximum performance. Numbers
depend on the speed grade and the aspect ratio of the BRAM (wide data widths congest
the routing forcing one or two to longer routes). Best numbers come from doing a
simple test design surrounding the BRAM with registers as indicated and looking at
the results. The speed files for the virtexII parts seem to still be in flux. I
think the virtexE files finally stabilized after the speed file released in one of
the 4.1 sp's.
hristo wrote:
> Hello,
> what is the maximum possible speed that a BRAM can be clocked with?
> I am interested on the values for Virtex, Virtex-e, Virtex-2
>
> if someone show me how can i deduce it from the datasheets, i will be really glad
>
> thanks
--
--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: 47540
[[[Before you reply to this message, please consider the five requirements
1-5 below carefully. Note, I am *not* asking the standard tired questions
about the internal GSR net vs. explicitly routed reset nets.]]]
VHDL users have all the luck.
Reprising this thread from 1999,
http://groups.google.com/groups?threadm=FIw2p8.BGz%40world.std.com&rnum=1
Like Joseph Allen, I wish to satisfy the following five requirements.
1. Widespread use of 0-cost GSR net to asynchronously reset or present the
myriad FFs in my design;
2. A carefully selected subset of FFs also receive an explicit, routed,
synchronous reset/preset signal to safely startup the key FFs in the design,
regardless of GSR skew (but nevermind, this issue is not germane to the
present discussion);
3. For simulation, a Verilog test bench that manages to assert and then
deassert GSR so as to reset/preset all FFs in the design;
4. A Verilog top level design module that does *not* have an explicit reset
net input signal (e.g. realized design will not have a reset input pin); and
5. Can write async reset/preset register semantics throughout my design,
e.g.
always @(posedge clk or posedge rst_async)
if (rst_async)
ff <= 0; // or 1;
else
ff <= ...;
Now, were it not for requirement #4 (no reset input pin), I could simply
write:
module foo_tb(); // testbench, not synthesized
reg rst_async;
... rst_async = 1; #100; rst_async = 0; ...
foo myfoo(..., rst_async, ...);
endmodule
module foo(..., rst_async, ...); // top level module, to be synthesized
... input rst_async; ...
STARTUP_VIRTEX2_GSR startup(rst_async); // NOTE1
always @(posedge clk or posedge rst_async)
if (rst_async)
ff <= 0; // or 1, as appropriate
else
ff <= ...;
...
endmodule
NOTE1: Without this explicit "startup" block, Synplicity seems to route
rst_async through programmable interconnect anyway; *with* this startup
block, Synplicity seems to route it through the dedicated GSR net.
But, requirement #4 above precludes module foo() above from receiving an
explicit rst_async input pin.
Instead, for the purposes of Verilog simulation and synthesis, it must pull
rst_async, a.k.a. GSR, from "thin air". Were I using VHDL, I could simply
instantiate a ROC and map rst_async to is O output port. But I'm using
Verilog.
For some reason, ROC is not and never has been provided in the Verilog
unisim library, which is puzzling, because it seems just as necessary and
useful there as it is in VHDL. Ditto for TOC.
Just as Joseph Allen wrote three years ago, the only workable solution seems
to burn an I/O for an unwanted reset input.
----- ASIDE ----
Here is a famous non-solution. Even though it is the year 2002, the Xilinx
Synthesis and Simulation Guide, for ISE 5.1i, p.6-67, still recommends the
following crock:
"module my_counter (CLK, D, Q, COUT);
input CLK, D;
output Q;
output [3:0] COUT;
wire GSR;
reg [3:0] COUT;
always @(posedge GSR or posedge CLK) begin
if (GSR == 1'b1)
COUT = 4'h0;
else
COUT = COUT + 1'b1;
end
...
endmodule"
"Since GSR is declared as a floating wire and is not in the port list, the
synthesis tool optimizes the GSR signal out of the design. GSR is replaced
later by the implementation software for all post-implementation simulation
netlists."
Now this is an unacceptable non-solution because a) synthesis tools properly
generate copious warnings on GSR not being driven -- and copious warnings
are a sure sign of sloppy and unprofessional work.
It is also unacceptable because b) it does not provide a way to synthesize
an async preset FF (FDP). If you write
if (GSR == 1'b1)
COUT <= 4'b1111;
...
you don't get four FDPs, you get an "undriven net" warning and four FDCs.
(The back-and-forth between Allen and the gentleman from Xilinx in the above
thread culminates in the *unbelievable* straight-faced proposal that we
achieve the same effect as FDPs by settling for FDCs and then adding
inverters on both their D inputs and their Q outputs. Read it and see for
yourself.)
----- -----
Now then, returning to the subject of this piece, VHDL users with similar
needs do not appear to be in this quandary, because they have the ROC
primitive, which lets you "get at" the GSR net for the purposes of
simulating and synthesizing async reset/preset flip-flops.
If the *Verilog* unisim library provided an ROC primitive, and if the
various synthesis tools knew about it, I could simply write
wire rst_async;
ROC roc(.O(rst_async));
in my top level design module and be done with it. (The VHDL ROC simulation
model internally asserts GSR for 100 ns and is presumably optimized away by
the synthesizer.)
But sans support for Verilog ROC, I can't see away to achieve my five
requirements stated above.
Do any Xilinx Verilog designers out there know of any way to achieve 1-5?
Thanks so much,
Jan Gray, Gray Research LLC
Article: 47541Hmmmm.Article: 47542
>One observation is that they are still using perimiter pads on these >parts, so that upping the IO beyond a certain point necessitates a >bigger die. >I'd personally like to see an area pad FPGA, where some of the logic >blocks are replaced with pads, so we wouldn't have these issues. I haven't thought about that apporach. Is there a web site or paper that gives a good overview? I assume one problem would be inductance in the bonding wires. That could make placement "interesting" to say the least. Or can they do a micro-BGA onto a ceramic substrate and turn that into super-short bond wires? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47543
>> What's magic about a toggle switch? I thought they all bounced too. >> >> Are you thinking of SPDT kicking an R-S type FF? > >Yes, exactly. The storage device can be a latch, even be a cross-coupled set of >inverters, in which case you need only one I/O pin. >You just yank that pin to Vcc or to ground. High instantaneous current, but only >for a nansecond or two. >Contact bounce is irrelevant in that case I think I got confused/sidetracked when you said "toggle" rather than SPDT. Don't they make SPDT type push-button switches? As far as I know, all mechanical switches bounce. I haven't studied (aka put a scope on) mecury switches or reed relays or ... I really like the one pin trickery. Thanks. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47544
"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag
news:3D953666.6C720BE@andraka.com...
> The block ram speed is limited by the interconnect to it. If you can
avoid using the
> we and ena signals (tie both active and then use the write address count
to direct
> unwanted writes to trash locations) and you pipeline the address and data
so that
> there is no logic between the registers and the BRAM, and you floorplan it
so that
> those registers are on shortest wires you'll get the maximum performance.
Numbers
> depend on the speed grade and the aspect ratio of the BRAM (wide data
widths congest
> the routing forcing one or two to longer routes). Best numbers come from
doing a
> simple test design surrounding the BRAM with registers as indicated and
looking at
> the results. The speed files for the virtexII parts seem to still be in
flux. I
I did this some time ago and got ~7 ns cycle time. See timing analyzer copy
below. It uses a BRAM in 4kx1 mode.
Still 2ns missing for my planned 200 Mhz signal generator :-(
----------------------------------------------------------------------------
----
Release 4.2WP3.x - Timing Analyzer E.35
Copyright (c) 1995-2001 Xilinx, Inc. All rights reserved.
Design file: generator_hs.ncd
Physical constraint file: generator_hs.pcf
Device,speed: xc2s100,-5 (PRELIMINARY 1.23 2001-12-19)
Report level: verbose report
----------------------------------------------------------------------------
----
============================================================================
====
Timing constraint: NET "clk_BUFGP/IBUFG" PERIOD = 8 nS HIGH 50.000000 % ;
286 items analyzed, 0 timing errors detected.
Minimum period is 7.086ns.
----------------------------------------------------------------------------
----
Slack: 0.914ns (requirement - (data path - negative clock
skew))
Source: l_singelram6.A
Destination: Mshreg_data_6__ram_reg_6
Requirement: 8.000ns
Data Path Delay: 7.086ns (Levels of Logic = 2)
Negative Clock Skew: 0.000ns
Source Clock: clk_BUFGP rising at 0.000ns
Destination Clock: clk_BUFGP rising at 8.000ns
Data Path: l_singelram6.A to Mshreg_data_6__ram_reg_6
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tbcko 3.985 l_singelram6.A
net (fanout=1) 2.269 ram_out<6>
Tdick 0.832 Mshreg_data_6__ram_reg_6
---------------------------- ------------------------------
Total 7.086ns (4.817ns logic, 2.269ns route)
(68.0% logic, 32.0% route)
--
MfG
Falk
Article: 47545"Valentin Tihomirov" <valentin@abelectron.com> ha scritto nel messaggio news:3d93f843$1_2@news.estpak.ee... > I have connected all 2 VCCs to +5V and all 3 GNDs to 0V. > All other signals > are unconnected. I suppose shortage is inside the chip. There are three Vcc signals also (two Vccint and one Vccio). You must connect every power pin even if some share the same name. -- LorenzoArticle: 47546
Thanks, but I have powered all 3 (and all 3 grounds). Other chips don't overheat in this configuration.Article: 47547
Nicholas C. Weaver <nweaver@ribbit.CS.Berkeley.EDU> wrote in message news:amsv1c$4nr$1@agate.berkeley.edu... > One observation is that they are still using perimiter pads on these > parts, so that upping the IO beyond a certain point necessitates a > bigger die. > > I'd personally like to see an area pad FPGA, where some of the logic > blocks are replaced with pads, so we wouldn't have these issues. > -- The Altera Mercury devices have I/O pads located throughout the middle of the device as well as around the perimeter. Look at the floorplan of the device and you'll see I/O running in rows straight through the part. However, it seems that the reason for this I/O structure was performance, rather than a greater I/O-per-die-area ratio. -Pete-Article: 47548
An XC2S -2 probably isn't going to get to 200 MHz with any margin, but you can
get closer than you are. There's not a lot you can do about Tbcko or Tdick.
Look at the net in between though. 2.2ns is going through a number of
segments. You should be able to improve on that with floorplanning the register
right next to the BRAM. It may take a look in the FPGA editor to see what the
router is doing to you. In 3.3i and earlier versions of the software, the
router did a pretty good job of getting a good route if the placement is good.
4.2's router does a much poorer job, even when -ol 5 and -xe 2 switches are
set. We still use 3.3sp8 on all but virtexII designs for this reason. You will
need to pester your FAE for updated speed files for virtexE for 3.3, the speed
files were updated with the release of 4.2sp1, and not officially back annotated
into 3.3. It wouldn't be a problem except the propagation delays *increased* in
the latest speed file.
Falk Brunner wrote:
> "Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag
> news:3D953666.6C720BE@andraka.com...
> > The block ram speed is limited by the interconnect to it. If you can
> avoid using the
> > we and ena signals (tie both active and then use the write address count
> to direct
> > unwanted writes to trash locations) and you pipeline the address and data
> so that
> > there is no logic between the registers and the BRAM, and you floorplan it
> so that
> > those registers are on shortest wires you'll get the maximum performance.
> Numbers
> > depend on the speed grade and the aspect ratio of the BRAM (wide data
> widths congest
> > the routing forcing one or two to longer routes). Best numbers come from
> doing a
> > simple test design surrounding the BRAM with registers as indicated and
> looking at
> > the results. The speed files for the virtexII parts seem to still be in
> flux. I
>
> I did this some time ago and got ~7 ns cycle time. See timing analyzer copy
> below. It uses a BRAM in 4kx1 mode.
> Still 2ns missing for my planned 200 Mhz signal generator :-(
>
> ----------------------------------------------------------------------------
> ----
> Release 4.2WP3.x - Timing Analyzer E.35
> Copyright (c) 1995-2001 Xilinx, Inc. All rights reserved.
>
> Design file: generator_hs.ncd
> Physical constraint file: generator_hs.pcf
> Device,speed: xc2s100,-5 (PRELIMINARY 1.23 2001-12-19)
> Report level: verbose report
> ----------------------------------------------------------------------------
> ----
>
> ============================================================================
> ====
> Timing constraint: NET "clk_BUFGP/IBUFG" PERIOD = 8 nS HIGH 50.000000 % ;
>
> 286 items analyzed, 0 timing errors detected.
> Minimum period is 7.086ns.
> ----------------------------------------------------------------------------
> ----
> Slack: 0.914ns (requirement - (data path - negative clock
> skew))
> Source: l_singelram6.A
> Destination: Mshreg_data_6__ram_reg_6
> Requirement: 8.000ns
> Data Path Delay: 7.086ns (Levels of Logic = 2)
> Negative Clock Skew: 0.000ns
> Source Clock: clk_BUFGP rising at 0.000ns
> Destination Clock: clk_BUFGP rising at 8.000ns
>
> Data Path: l_singelram6.A to Mshreg_data_6__ram_reg_6
> Delay type Delay(ns) Logical Resource(s)
> ---------------------------- -------------------
> Tbcko 3.985 l_singelram6.A
> net (fanout=1) 2.269 ram_out<6>
> Tdick 0.832 Mshreg_data_6__ram_reg_6
> ---------------------------- ------------------------------
> Total 7.086ns (4.817ns logic, 2.269ns route)
> (68.0% logic, 32.0% route)
>
> --
> MfG
> Falk
--
--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: 47549There's no reason the nrdy line can't pulse to temporarily delay things. Its asynchronous to the clock and may be used for long or short delays. You should get a copy of the FPDP specification or look for the draft version available freely which was made available prior to full release. BTW I recommend the Transtech DSP FPDP modules as a front end to your FPGA. Paul "Tim Plant" <tim@dskti.com> wrote in message news:2fe5a99c.0209250206.3d29a9a6@posting.google.com... > I've just implemented an fpdp tm interface to an externally supplied > board. The nrdy line coming from the rm board appears to pulse and not > maintain a steady level. Is this correct behaviour? Can anyone supply > me with a timing diagram?
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