Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 47525

Article: 47525
Subject: Re: Looking for a dead Virtex
From: pierrotlafouine@hotmail.com (Pierre Lafrance)
Date: 27 Sep 2002 08:06:28 -0700
Links: << >>  << T >>  << A >>
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.
> >
> > David

Article: 47526
Subject: Re: JTag question
From: "Steve Casselman" <sc@vcc.com>
Date: Fri, 27 Sep 2002 15:21:13 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: implementation of adaptive FIR with many input channels?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 27 Sep 2002 17:38:29 +0200
Links: << >>  << T >>  << A >>
"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
Falk




Article: 47528
Subject: Re: Dual Port RAM
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 27 Sep 2002 16:34:07 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Is it possible to build a Ring Oscillator in an FPGA chip?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 27 Sep 2002 12:49:50 -0400
Links: << >>  << T >>  << A >>
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 FAX

Article: 47530
Subject: Re: Unpredictable Place and Route
From: Peter Young <Peter.Young@STOPSPAM.amirix.com>
Date: Fri, 27 Sep 2002 17:32:10 GMT
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Quartus 2 Error: "Full compilation was cancelled due to an error"
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 27 Sep 2002 10:36:34 -0700
Links: << >>  << T >>  << A >>
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 Treseler


Article: 47532
Subject: Xilinx CoreGenerator/IP Capture
From: Mike Hubert <mph@xiphos.ca>
Date: Fri, 27 Sep 2002 17:38:53 GMT
Links: << >>  << T >>  << A >>
**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
Subject: Re: Finding nets in hierarchy
From: Peter Young <Peter.Young@STOPSPAM.amirix.com>
Date: Fri, 27 Sep 2002 17:50:35 GMT
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Dual Port RAM
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Fri, 27 Sep 2002 18:15:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.edu

Article: 47535
Subject: Re: Dual Port RAM
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 27 Sep 2002 20:34:21 GMT
Links: << >>  << T >>  << A >>
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 implementations

Article: 47536
Subject: Re: My CPLD (XC9536) is overheated
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Fri, 27 Sep 2002 17:30:09 -0500
Links: << >>  << T >>  << A >>
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.

Jon


Article: 47537
Subject: Block Ram maximum speed
From: hristostev@yahoo.com (hristo)
Date: 27 Sep 2002 16:27:20 -0700
Links: << >>  << T >>  << A >>
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

Article: 47538
Subject: Re: Unpredictable Place and Route
From: "Clyde R. Shappee" <clydes@world.std.com>
Date: Fri, 27 Sep 2002 20:43:45 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Block Ram maximum speed
From: Ray Andraka <ray@andraka.com>
Date: Sat, 28 Sep 2002 04:50:36 GMT
Links: << >>  << T >>  << A >>
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
Subject: Why no ROC for Xilinx Verilog sim and synthesis?
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 27 Sep 2002 22:24:44 -0700
Links: << >>  << T >>  << A >>
[[[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: 47541
Subject: Ignore me - just a test
From: Anonymous <bogus@attbi.com>
Date: Sat, 28 Sep 2002 05:40:00 GMT
Links: << >>  << T >>  << A >>
Hmmmm.

Article: 47542
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 28 Sep 2002 05:44:10 -0000
Links: << >>  << T >>  << A >>
>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
Subject: Re: pulldown resistor value for Xilinx CPLD
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 28 Sep 2002 06:26:07 -0000
Links: << >>  << T >>  << A >>
>> 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
Subject: Re: Block Ram maximum speed
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 28 Sep 2002 09:45:53 +0200
Links: << >>  << T >>  << A >>
"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
Subject: Re: My CPLD (XC9536) is overheated
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Sat, 28 Sep 2002 12:10:04 GMT
Links: << >>  << T >>  << A >>
"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.

--
Lorenzo



Article: 47546
Subject: Re: My CPLD (XC9536) is overheated
From: "Valentin Tihomirov" <valentin@abelectron.com>
Date: Sat, 28 Sep 2002 15:43:25 +0300
Links: << >>  << T >>  << A >>
Thanks,
but I have powered all 3 (and all 3 grounds). Other chips don't overheat in
this configuration.



Article: 47547
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: "Pete Ormsby" <faepeteDELETETHIS@attbi.com>
Date: Sat, 28 Sep 2002 12:54:25 GMT
Links: << >>  << T >>  << A >>

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
Subject: Re: Block Ram maximum speed
From: Ray Andraka <ray@andraka.com>
Date: Sat, 28 Sep 2002 13:28:57 GMT
Links: << >>  << T >>  << A >>
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: 47549
Subject: Re: FPDP
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Sat, 28 Sep 2002 16:34:11 +0100
Links: << >>  << T >>  << A >>
There'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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search