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
2017JanFebMarApr2017

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 39100

Article: 39100
Subject: Re: {72,64} extended hamming ECC
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 31 Jan 2002 17:45:03 -0000
Links: << >>  << T >>  << A >>
If you happen to have John Wakerly' latest textbook on the shelf,
it _may_ have this in VHDL.

Probably not worth a trip to Computer Literacy if the book is
not to hand.  (trying to be helpful!)

"Austin Lesea" wrote

> Is there someone who is willing to share their verilog code for a 72,64
> bit extended hamming code decoder (error corrector)?
>
> We are looking at error correction, and would appreciate any URL to some
> actual working code.





Article: 39101
Subject: Re: glitchless clock enable/disable in spartanII
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 31 Jan 2002 10:01:12 -0800
Links: << >>  << T >>  << A >>

--------------4A4120E531E913F44D21FFB7
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit



Rick Filipkiewicz wrote:

>
> Peter,
>
> I seem to remember you saying on this very NG that when the Virtex-2 arrived you'd be
> able to play games with the DCM to get some hard data on the metastability parameters
> ?

Still on my "to do" list. Kind of embarrassing.

But, although Philip seems not to believe it, the old 1997 documentation shows that even
the now-obsolete XC4005-3  increases the MTBF by ten decimal orders of magnitude for
every extra ns of acceptable delay. This XAPP094 data has been publicly available for 4
years and has never been challenged.
http://www.xilinx.com/xapp/xapp094.pdf
The modern flip-flops must be doing so much better that measuring might again be a
challenge. Let's try !
Metastability exists and is a devious problem, but modern flip-flops resolve it
surprisingly fast.

Peter Alfke, Xilinx Applications




Article: 39102
Subject: Re: Xilinx XC3020-70
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 31 Jan 2002 10:07:42 -0800
Links: << >>  << T >>  << A >>
Donate this 12-year old part to a museum and experiment with Spartan or Virtex
parts. They are so much better, and they are not expensive. Less so than the
time you might be wasting chasing old software.

Peter Alfke, Xilinx Applications
============================================
Remco Poelstra wrote:

> Hi,
>
> A friend gave me an Xilinx XC3020-70 FPGA. The problem is that I can't
> find any software to compile verilog for that chip.
> Does anyone here know where I can get a compiler/programmer?
>
> Thanks in advance,
>
> Remco Poelstra


Article: 39103
Subject: Re: FPGA or Micro-controller in Lowpower designs?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 31 Jan 2002 10:24:31 -0800
Links: << >>  << T >>  << A >>

rickman wrote:

>
> Ulf is an Atmel representative, so it is not likely he will say much
> about a TI product. He would be ill advised to say anything good for the
> sake of his job and won't say anything bad for being thought of as
> badmouthing the competition.  :)  Even if we ask...

I don't like this statement. I am a Xilinx employee, and I hope that my postings
are not considered Xilinx propaganda. I have even recommended Atmel EEPROMs (
long ago ) when they offered a solution that Xilinx did not have then.
As employees, we have to be loyal to our employer; but as engineers, we also have
to be honest and forthright. Sometimes this can be tricky to combine, and one
solution is to shut up.
But, please, do not consider us spineless mercenaries or marketing puppets.
We are not!
And kudos to Xilinx management for never even having tried to censor me.

Peter Alfke, Xilinx Applications

>
>
> --
>


Article: 39104
Subject: Re: FPGA or Micro-controller in Lowpower designs?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 31 Jan 2002 10:29:08 -0800
Links: << >>  << T >>  << A >>

--------------200CDCC567A843522E3E27C1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter is right,

We say what we say in perhaps the best light, but we are honest (after all, we are
engineers).

I also appreciate Xilinx' faith in its employees who answer the many questions that
are posed to us in these public forums.

Austin


Peter Alfke wrote:

> rickman wrote:
>
> >
> > Ulf is an Atmel representative, so it is not likely he will say much
> > about a TI product. He would be ill advised to say anything good for the
> > sake of his job and won't say anything bad for being thought of as
> > badmouthing the competition.  :)  Even if we ask...
>
> I don't like this statement. I am a Xilinx employee, and I hope that my postings
> are not considered Xilinx propaganda. I have even recommended Atmel EEPROMs (
> long ago ) when they offered a solution that Xilinx did not have then.
> As employees, we have to be loyal to our employer; but as engineers, we also have
> to be honest and forthright. Sometimes this can be tricky to combine, and one
> solution is to shut up.
> But, please, do not consider us spineless mercenaries or marketing puppets.
> We are not!
> And kudos to Xilinx management for never even having tried to censor me.
>
> Peter Alfke, Xilinx Applications
>
> >
> >
> > --
> >



Article: 39105
Subject: skew between gated clks in Virtex2?
From: Lasse Langwadt Christensen <langwadt@ieee.org>
Date: Thu, 31 Jan 2002 19:39:21 +0100
Links: << >>  << T >>  << A >>

I'm about to build an ASIC prototype in a Virtex2, 
The design has several clk domains, all the same 
frequency (24Mhz) but separately gated, I'd rather 
not change too much in the design to get it a working 
fpga protype so, 
if I use the clk gating in Virtex2 to replace the 
gating in design will I be guaranteed that all the 
clks will be aligned?  

thanks, 
--Lasse 
----------------------------
- Lasse Langwadt Christensen
- Aalborg - Danmark

Article: 39106
Subject: Linking IP
From: In Memory of tecNovia <remember@me.com>
Date: Thu, 31 Jan 2002 10:50:31 -0800
Links: << >>  << T >>  << A >>

I have a processor core synthesized and turned into a complete FPGA
programming file by Xilinx Foundation 3.3i. 

Instead I need to turn the processor into a module which would be only
a part of the FPGA, so that other IP could be linked with it inside
the FPGA. I must deliver only the EDIF or similiar file to potential
users so as to keep the source code secure.

I'm currently using Foundation (XST) to synthesize to an EDIF file
then running a DOS batch file to get from the EDIF file to the MCS
programming file.

	edif2ngd pscxl.edn
	ngdbuild -p xcv600ehq240-6 pscxl
	map -p xcv600ehq240-6 -cm speed -pr b pscxl
	par -w -ol 3 -t 4 -i 3 pscxl.ncd pscxl_par.ncd
	trce -e 10 -s 6 -o pscxl.twr pscxl_par.ncd pscxl.pcf
	bitgen -d -w pscxl_par.ncd pscxl.bit pscxl.pcf
	promgen -w -p mcs -u 0 pscxl.bit

I'm a novice user - the processor core and Xilinx setup was created by
another - I'm just making minor mods and learning as I go.

So, exactly how are IP blocks combined inside one FPGA? My source code
is partitioned into VHDL modules with the top layer only a Xilinx
wrapper with components ibuf, ibufg, and the next lower level VHDL
module, so I assume my first step would be to compile an EDIF file
without the top level.

John
jkolb@ptsc.com


Article: 39107
Subject: Re: Setting PCI command register in WinNT OS
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 31 Jan 2002 10:54:11 -0800
Links: << >>  << T >>  << A >>

Hi,

My admittedly limited experience has shown that you should not
count on the operating system to do anything for you, particularly
if you are using a non-PNP operating system like WindowsNT.

I have seen identical boards left in different states of "configuration"
by WindowsNT after the operating system boots when placing them in
different machines.  I think (don't know for sure) that these
differences
are the result of what the BIOS on the machine is doing before the
operating system boots -- not actually the doing of WinNT.  If you go
look at your BIOS settings, you may see things like:

Slot 1: Enable BusMaster  Y/N
Slot 2: Enable BusMaster  Y/N
Enable PNP OS             Y/N
etc...

Or, you may not see anything at all.  This particular BIOS help
indicated this was for legacy devices with a non-PNP operating
system where you needed the BIOS to set the bit before the OS
booted.

So, for a robust solution, the key is to not assume anything, and
when you write the device driver, go out and set the bit yourself
as part of the routine that executes when the driver is loaded.

If you are using one of the common device driver kits, I am sure
there is a function call to do this.  If you are writing the driver
without one of these kits, refer to some of the example drivers in
the WinNt4.0 DDK.  You can manually read the command register, set
the bit, and then write it back using HalGetBusData and HalSetBusData.

Hope that helps,
Eric

Marco Serafini wrote:
> 
> Hello,
> 
> I'm writing a Win NT Driver for my PCI board in which I've used a FPGA
> to instantiate an Altera MegaCore Function for bus interfacing (bus
> mastering access to system memory).
> My question is: have I to initialize the function by writing a proper
> value to PCI command register in my driver? Looking at some downloaded
> samples the answer seems to be "NO" and it sounds a bit strange to me!
> I've recently read all the docs about the PCI Function: a bus master
> has to write to the configuration register and set the MegaCore to be
> a Master. Perhaps the Bios does this job, but I'm not familiar with
> Bios enumerating process. Are there any programming guidelines or
> suggestions? Thanks for help.
> 
> Marco

Article: 39108
Subject: Re: skew between gated clks in Virtex2?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 31 Jan 2002 11:05:54 -0800
Links: << >>  << T >>  << A >>
Yes, the skew between the global clocks will be less than 100 ps. How much less
may require some more investigation. Maybe you will get an independent answer
from Austin.  He lives 30 feet away from me...

Peter Alfke
===============================
Lasse Langwadt Christensen wrote:

> I'm about to build an ASIC prototype in a Virtex2,
> The design has several clk domains, all the same
> frequency (24Mhz) but separately gated, I'd rather
> not change too much in the design to get it a working
> fpga protype so,
> if I use the clk gating in Virtex2 to replace the
> gating in design will I be guaranteed that all the
> clks will be aligned?
>
> thanks,
> --Lasse
> ----------------------------
> - Lasse Langwadt Christensen
> - Aalborg - Danmark


Article: 39109
Subject: Re: skew between gated clks in Virtex2?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 31 Jan 2002 11:40:19 -0800
Links: << >>  << T >>  << A >>
Lasse,

(From the cube down the hall), if the clock signal comes from the same
DCM, then the arrival time at the other end of the two BUFGs to the same
IOB (for example) is +/- 10 ps (basically we can't measure it).  Now the
DCM has some error for its two outputs (say CLK0 and CLK180) of a tap
value (~60ps).

Any individual BUFG is from 0 to 120 ps in a 2V6000, and from 0 to 100
ps in a 2V4000 or 2V3000, and from 0 to 60 ps in a 2V1000.

I would expect the worst case skew from any DCM driving a BUFG to any
IOB receiving the BUFG to be less than the total skew of one BUFG, as
they can't really add together, as they are both always greater than 0,
and increasing.  If they are both increasing together, then the skew
might be 0.  Skews/delays to CLBs are less or equal to skew to IOBs
(they are closer).

Austin

Lasse Langwadt Christensen wrote:

> I'm about to build an ASIC prototype in a Virtex2,
> The design has several clk domains, all the same
> frequency (24Mhz) but separately gated, I'd rather
> not change too much in the design to get it a working
> fpga protype so,
> if I use the clk gating in Virtex2 to replace the
> gating in design will I be guaranteed that all the
> clks will be aligned?
>
> thanks,
> --Lasse
> ----------------------------
> - Lasse Langwadt Christensen
> - Aalborg - Danmark


Article: 39110
Subject: Re: Altera support sites
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Thu, 31 Jan 2002 20:28:47 +0000 (UTC)
Links: << >>  << T >>  << A >>

"Paul" <nospam@nospamplease.com> wrote in message
news:U2z48.28161$ka7.4681948@news6-win.server.ntlworld.com...
> Anyone got any tips about web sites/newsgroups discussing problems/tips
with
> Altera devices and tools.
>
> Obviously there is a certain amount of excellent information here and in
> c.l.vhdl, but I was surprised that there wasn't an altera newsgroup or
> similar bulletin board for users to discuss things.
>
> Altera do respond to specific service requests as best they can, but I
think
> I'd gain alot from discussions with other users etc.

You could always form a Yahoo group for this type of discussion.

Leon
--
Leon Heller, G1HSM leon_heller@hotmail.con
http://www.geocities.com/leon_heller
Low-cost Altera Flex design kit: http://www.leonheller.com






Article: 39111
Subject: metastability: failsafe solution???
From: Maximilian Epple <maximilian.epple@gmx.net>
Date: Thu, 31 Jan 2002 22:17:22 +0100
Links: << >>  << T >>  << A >>
Hi Gurus,

I'm new to FPGA programming and I just found out about the metastability
issue.

My problem is good natured, i.e my asyncronous signal is slow compared
to the clock(33MHz) which means that it remains at least 150ns in the
same state. In addition I'm only interested in the rising edge of the
asyncronous signal which I want store in a register.

Is the following AHDL design failsafe?

lclk		: clock of the system
eoc		: DFF;	-- storage register
as_in		: INPUT; -- asyncronous input
eoc_reset	: DFF; -- reset from a syncronous signal 

eoc.clk = as_in & (global (lclk));
!eoc.clrn = eoc_reset;
!eoc.prn = GND;
eoc.d = VCC;

I don't see any problem since the register setup and hold times are
respected  (because of eoc.d = VCC;). And since eoc.clk is in phase with
the system clock, the output of my register eoc.q should be syncronous
with the system.

=> all is fine!! Or did I miss something ??? 

	Max

Article: 39112
Subject: Re: metastability: failsafe solution???
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 31 Jan 2002 13:48:21 -0800
Links: << >>  << T >>  << A >>
Maximilian Epple wrote:
> 
> Hi Gurus,
> 
> I'm new to FPGA programming and I just found out about the metastability
> issue.
> 
> My problem is good natured, i.e my asyncronous signal is slow compared
> to the clock(33MHz) which means that it remains at least 150ns in the
> same state. In addition I'm only interested in the rising edge of the
> asyncronous signal which I want store in a register.
> 
> Is the following AHDL design failsafe?

No. The question is, is it safe enough?

> lclk            : clock of the system
> eoc             : DFF;  -- storage register
> as_in           : INPUT; -- asyncronous input
> eoc_reset       : DFF; -- reset from a syncronous signal
> 
> eoc.clk = as_in & (global (lclk));
> !eoc.clrn = eoc_reset;
> !eoc.prn = GND;
> eoc.d = VCC;
> 
> I don't see any problem since the register setup and hold times are
> respected  (because of eoc.d = VCC;).

Your D setup to clock is fine. 
However, the gated clock could glitch
and the clear signal could cause a runt pulse
if it happens at just the wrong time near the wrong clock edge. 

Consider synchronizing  as_in and eoc_reset with
two DFF stages and make eoc.clk = (global (lclk));

 -- Mike Treseler

Article: 39113
Subject: Re: Linking IP
From: Vikram <Vikram.Pasham@xilinx.com>
Date: Thu, 31 Jan 2002 16:55:24 -0600
Links: << >>  << T >>  << A >>
John,

 Your top-level seems to be a wrapper file with  instantiations of  I/O
buffers and processor core. If this is the case, all you need to do is

1. Synthesize the lower level processor core and generate the edif file.
While generating this netlist file, make sure the synthesis tool does not
inserts any I/O buffers (all synthesis tools have an option to turn I/O
buffer insertion off).

2. Synthesize only the the top-level file and use black box attribute for
the processor core instantiation.

Now you have two netlist files, top level netlist file and processor core
netlist. Make sure these two netlist files are in the same folder and run
your DOS batch file. Ngdbuild will combine these two netlists and
generates a ngo file.

The processor netlist can be distributed instead of your HDL source code.
If you need to interface/add any other module to this processor, this can
be done with a different hierarchy in the top level HDL file.

Hope this helps !!!


-Vikram
Xilinx Design Services.


In Memory of tecNovia wrote:

> I have a processor core synthesized and turned into a complete FPGA
> programming file by Xilinx Foundation 3.3i.
>
> Instead I need to turn the processor into a module which would be only
> a part of the FPGA, so that other IP could be linked with it inside
> the FPGA. I must deliver only the EDIF or similiar file to potential
> users so as to keep the source code secure.
>
> I'm currently using Foundation (XST) to synthesize to an EDIF file
> then running a DOS batch file to get from the EDIF file to the MCS
> programming file.
>
>         edif2ngd pscxl.edn
>         ngdbuild -p xcv600ehq240-6 pscxl
>         map -p xcv600ehq240-6 -cm speed -pr b pscxl
>         par -w -ol 3 -t 4 -i 3 pscxl.ncd pscxl_par.ncd
>         trce -e 10 -s 6 -o pscxl.twr pscxl_par.ncd pscxl.pcf
>         bitgen -d -w pscxl_par.ncd pscxl.bit pscxl.pcf
>         promgen -w -p mcs -u 0 pscxl.bit
>
> I'm a novice user - the processor core and Xilinx setup was created by
> another - I'm just making minor mods and learning as I go.
>
> So, exactly how are IP blocks combined inside one FPGA? My source code
> is partitioned into VHDL modules with the top layer only a Xilinx
> wrapper with components ibuf, ibufg, and the next lower level VHDL
> module, so I assume my first step would be to compile an EDIF file
> without the top level.
>
> John
> jkolb@ptsc.com


Article: 39114
Subject: Leonardo=>MaxPlus/Quartus Vs Synopsys=>MaxPlus/Quartus
From: vnpeker@netvision.net.il (Igor Peker)
Date: 31 Jan 2002 15:00:20 -0800
Links: << >>  << T >>  << A >>
Hi,

Can anybody explain me why the same Verilog design from Synopsys FPGA
Express is fitted by MaxPlus/Quartus into 4992 LCs of Flex10KE-100,
but from Leonardo -
no ?
+: all procedures to extract ROM/RAM, etc. were made in Leo instead of
FPGA, but Synopsys wins.

Thanks in advance,
Igor Peker

Article: 39115
Subject: Re: WebPack 4.1 ISE Errors with Insight Demo files
From: Arthur <>
Date: Thu, 31 Jan 2002 15:30:56 -0800
Links: << >>  << T >>  << A >>
Gunther -

Change the bus delimiters from ()s to <>s. 

Regards,
Arthur

Article: 39116
Subject: Re: Intel vs. AMD
From: emanuel stiebler <emu@ecubics.com>
Date: Thu, 31 Jan 2002 16:54:52 -0700
Links: << >>  << T >>  << A >>
VR wrote:
> 
> I have a new AMD "XP 1700+" (1.6GHz) 

Sorry, but the "XP 1700+" is clocked at 1.47 GHz ;-)

cheers

Article: 39117
Subject: Re: the cause of the simulation/synthesis mismatch
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 01 Feb 2002 00:09:35 +0000
Links: << >>  << T >>  << A >>


ssy wrote:

> Hi every one
>
> I am using sopc board from altera, it hold an APEX20k400E, I am using
> synplicity 6.2.4 to synthesis and then use quartus II 1.1 to P&R,
>
> my design is an cpu, the cpu hold one cpu core(design by me), an
> interconnect network(design by other), and some slave device(design by
> my team member)
>
> the cpu core have two master port to fetch instruction and data
>
> the interconnect network have 8 master and 16 slave, any unuse port's
> output pin will not connect and input pin will assign 0,
>
> I run pre syn rtl simulation, all ok,but after burn on the board, it
> is error,
>
> I want to know possible cause of synthesis/simulation mismatch.

What does your post P&R timing analysis say ?



Article: 39118
(removed)


Article: 39119
Subject: Re: glitchless clock enable/disable in spartanII
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 01 Feb 2002 01:09:32 +0000
Links: << >>  << T >>  << A >>


Philip Freidin wrote:

>
>
> >The 1997 Xilinx app note XAPP094 documents the archaic XC4005-3 at an MTBF of 100 000
> >years for metastable delay of 2 ns, ( really 1 million years at 10 MHz clock and 1 MHz
> >data, but that translates to 100 000 years at the ten times higher clock rate) and the
> >MTBF increases ten decimal orders of magnitude for every additional ns. That's three
> >additional ns in this case.
>
> "ten decimal orders of magnitude" ???? I seem to remember the slope is more like
> an improvement of a factor of 40 per each additional ns. When di the slope
> change to 10^30 ?????
>
> >That means an MTBF of 10exp35, which is many times the age of the universe.
> >
> >Peter Alfke, Xilinx Applications

Nice app note that XAPP094, it was the first good discussion of metastability from a chip
maker I'd seen since a very early Lattice GAL data book [IIRC there was also one in the red
Fairchild `F' series TTL data book, and one in the MMI PAL handbook].

>From it we have the `K2' per nsec. scale factors for metastab resolution:

XC4005E-3 IOB FF = exp(16.1) =~ 9.8 * 10^6.
XC4005E-3 CLB FF = exp(19.4) =~ 2.6 * 10^8.

Not quite 10 orders of mag per nsec. but I was quite happy with 7. Now I derate the delay
for Virtex-E synchroniser FFs in CLBs by 5 nsec so, assuming the V-E is no worse than the
4005Es, I get an MTBF between the 33MHz PCI domain and a main 100MHz domain of: about

   8.8 * 10^21 years

That'll do for me.

*BUT*

I've always had one caveat about that apps note. The `metastab catching window' is quoted
as 0.1nsec but the data book setup times for the XC4005E FFs were much larger. Does this
mean that  the hold times quoted as 0 were/are in fact negative ?


Article: 39120
Subject: Re: glitchless clock enable/disable in spartanII
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 31 Jan 2002 18:44:49 -0800
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

>
> Nice app note that XAPP094, it was the first good discussion of metastability from a chip
> maker I'd seen since a very early Lattice GAL data book [IIRC there was also one in the red
> Fairchild `F' series TTL data book, and one in the MMI PAL handbook].

Thanks

>
> *BUT*
>
> I've always had one caveat about that apps note. The `metastab catching window' is quoted
> as 0.1nsec but the data book setup times for the XC4005E FFs were much larger. Does this
> mean that  the hold times quoted as 0 were/are in fact negative ?

Well, that is a different subject.
Metastability is concerned with one devive at one temperature and supply voltage, whatever it
is at the magic moment of making the decision.
The data sheet is a worst-case specification that has to cover everything, process,
temperature, and voltage variation plus tester guardband ( the tester alone adds 0.5 ns
inaccuracy )
So the max set-up time is the longest set-up time that might ever occur anytime anywhere, and
the quoted negative hold time would be the shortest possible set-up time. But since that
smallest set-up time is difficult to measure, and, if guaranteed, would preclude future
process improvement, the manufacturers tend to say: 0 ns hold time, which means:
"The hold time is guaranteed to be NOT positive, but we are not specifying how negative it
really is". ( Negative is good when hold time is concerned).

The spread between set-up and hold time has nothing whatsoever to do with the metastability
catching window, which obviously is only a fraction of a picosecond.

Peter Alfke



Article: 39121
Subject: Re: glitchless clock enable/disable in spartanII
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 01 Feb 2002 02:53:11 GMT
Links: << >>  << T >>  << A >>
On Fri, 01 Feb 2002 01:09:32 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote:
>*BUT*
>
>I've always had one caveat about that apps note. The `metastab catching window' is quoted
>as 0.1nsec but the data book setup times for the XC4005E FFs were much larger. Does this
>mean that  the hold times quoted as 0 were/are in fact negative ?

The `metastab catching window' is also the window in which the FF actually
samples the D (and CE) input and decides what to do. If new data is valid
before the start of the window, the FF catches the new data. If the new
data changes after the window, the FF catches the data value prior to the
new data.

The window slides around based on temp, voltage, device age, phase of moon,
Dv/Dt of the data signal, Dv/Dt of the clock signal, what the async reset
has done recently, and what the current FF state is.
The data sheet numbers for setup and hold give a bounded limit for how far
the window can wander. ( it wanders around during normal operation, but
within these limits).

So reality is that 'setup' and 'hold' do not actually exist. By specifying
these values, and designing to them, you get reliable system behaviour
regardless as to where the window is at the time of the clock signal.

So getting to your question, the FFs are designed so that if every thing
conspires to make the window as late as possible, the end of the window
will be no later than 0.0 ns after the clock (which gives hold time of
0.0 ns).

Similarly, if everything conspires to make the window as early as possible,
the beginnining of the windo will be no earlier than the setup time before
the clock.

You could read more on this at:

   http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm


Philip
Philip Freidin
Fliptronics

Article: 39122
Subject: www.easics.com
From: rgf <erwh@iurf.jhf>
Date: Thu, 31 Jan 2002 22:02:29 -0800
Links: << >>  << T >>  << A >>
I generate a crc (data width 2 bit,32 bit crc,802.3)from (www.easics.com  ).Then ,i study the module.there is a function in the module.but it need input "input [31:0] CRC".i think the crc result is what i need.where is it 
from?that is ,the crc result should be calculated by it.
     can you help me?

Article: 39123
Subject: Re: Flex10KA vs MAX7000S
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 01 Feb 2002 01:03:22 -0500
Links: << >>  << T >>  << A >>
Kevin Brace wrote:
> 
> Chris Cowdery wrote:
...snip...
> > I am using the Quartus fitter - free license at the moment, which
> > doesn't support timing driven fitting. If I get the full version,
> > is it smart enough to give me a working design if I tell it about
> > Tsu for example?
> >
> > Thanks,
> >
> > Chris.
> 
>         In my opinion having synthesized my PCI IP core with ISE WebPACK
> 4.1 for Spartan-II XC2S150-5CPQ208 and with Quartus II 1.1 Web Edition
> for FLEX 10KE100K-1 is that P&R tool won't do much good.
> I have more experiences with ISE WebPACK, so I will talk about my
> experience there with Spartan-II, but in that case, the P&R tool simply
> couldn't meet my Tsu requirement simply with full automatic P&R (no
> partial manual floorplanning) with only a Tsu <= 7ns requirement.
> Looking at how the design was placed automatically, I saw that some LUTs
> for several signal paths violating Tsu were being placed far away from
> the destination FF.
> So, I simply placed such LUTs near or in a straight path towards the
> destination FF.
> I had to repeat that about 10 to 12 times, each time starting over with
> a new layout, but at each iteration, I will have more LUTs placed
> manually, so the timing violations were gradually decreasing.
> I haven't tried this approach with Quartus II 1.1 Web Edition yet, but
> after I get through Quartus II 1.1's fir_filter tutorial, I will try to
> do some manual placement.
> Regarding how MAX+PLUS II-BASELINE's (free version of MAX+PLUS II)
> non-timing driven fitter will fare is a question I don't know because
> ever since I discovered that MAX+PLUS II-BASELINE doesn't support timing
> driven fitting, I stopped putting any effort into getting my design to
> meet 33MHz PCI timings with ACEX 1K.
> My guess is that you may have to do more manual floorplanning than you
> will have to do if timing driven fitting was supported.
>         So, summarizing what I wrote, P&R tool is not a magical tool
> that will P&R an FPGA and meet Tsu requirement if the user supplies the
> timing requirement.
> Actually, P&R tool is a pretty dumb tool which doesn't know where to
> place a LUT even if a LUT is on a critical timing path (Like a path
> starting from FRAME# or IRDY# going towards AD[31:0] output FF and
> tri-state control FF.).
> Assuming the user has some understanding of the target architecture,
> humans can do a far better job than software placing critical timing
> LUTs in the right location.
> Therefore, I will not recommend spending US $2,000 for a paid version
> (subscribed version) of MAX+PLUS-II, at least initially, although you
> will get Quartus II 1.1/2.0 and ModelSim-AE with it, but you won't be
> eligible for upgrades after a year.
> Just to see how a timing driven fitter will fare, you can try out
> Quartus II 1.1 Web Edition for free, and target FLEX 10KE-1 as a test
> vehicle.
> You can use FLEX 10KE PCI development board's pin out for the test
> vehicle (That is what I do.).
> 
> Kevin Brace (Don't respond to me directly, respond within the
> newsgroup.)

Let me share my two cents worth about the MAX+PlusII fitter, which by
the way, is what you have to use to P&R the 10KA parts, unless there has
been an update to Quartus in the last 6 months to include the 10KA
parts. 

We were doing a design in the 10K100A because it was on a board that was
in the field. We were adding new features to an existing product with a
new download. This design needed to run fast and used about 83% of the
chip. We had TONS of trouble getting the design to meet our timing specs
as given to the MAX+PlusII tool. This was on top of all the trouble we
had generating a constraint file due to the lack of generalized timing
constraints available in this tool. We actually had to write programs to
take our lists of constraints and compare them to the list of nets
sorting them out by the timing we had applied and the ones we had
missed. We spent many hours wading through megabyte files checking for
errors and ommisions. 

Once we had the contraint file working, the tool had a very hard time
meeting the timing constraints. We had to use trial and error to find
placement controls that would help rather than hurt the timing. This was
not very deterministic, but rather was a very hit and miss thing. Then
once we got a route that meet our timing, we found that the chip would
fail on the bench if we ran the temp up a few degrees, or even fail at
room temp in some cases! Freeze spray always made it start working. 

Our conclusions were :

1) Routing the signals through multiple passes up and down in the
heirarchy due to routing congestion causing much longer timing than a
standard route would take. 

2) The tool was miscalculating these delays (or high fanout delays which
we tried to avoid like the plague) causing our designs to fail at
temperature. 

It was not until we axed a hunk of our design (and functionality) so
that we only had to run a much smaller design at full speed did we get
it to P&R and pass temperature tests. Even then it was not a slam dunk
requiring many passes to get a good route. 

We also implemented the same design on a 20K part with about 55%
utilization using QuartusII. This worked very easily with the only
problem being some bad constraints early in the process. Of course the
lower utilization helped a lot, but I believe that if we had been able
to use Quartus to process our 10KA design, we would have finished two or
three months earlier and I would have a little more hair and a little
less gray!


-- 

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: 39124
Subject: Re: Leonardo=>MaxPlus/Quartus Vs Synopsys=>MaxPlus/Quartus
From: Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com>
Date: Fri, 01 Feb 2002 00:07:09 -0600
Links: << >>  << T >>  << A >>
I suppose the answer is that not all synthesis tools are created
equally.
Have you ever tried synthesizing your design from Quartus II 1.1 Altera
in-house synthesis tool (not the third party ones you use)?
I must say that from my experience synthesizing the exact same Verilog
design with both LeonardoSpectrum-Altera (free version) and Quartus II
1.1 Altera in-house synthesis tool is that Quartus II 1.1 Web Edition
Altera in-house synthesis tool used far more LEs (LeonardoSpectrum used
1,600 LEs versus 2,500 LEs for Quartus II 1.1 Web Edition Altera
in-house synthesis tool.).
The FPGA I targeted was the same chip you are targeting, FLEX 10K100E-1.
        All I can say is that you should try to adjust the synthesis
options to reduce the number of LEs that gets generated (i.e., optimize
for area rather than speed), or move to a larger device.




Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)




Igor Peker wrote:
> 
> Hi,
> 
> Can anybody explain me why the same Verilog design from Synopsys FPGA
> Express is fitted by MaxPlus/Quartus into 4992 LCs of Flex10KE-100,
> but from Leonardo -
> no ?
> +: all procedures to extract ROM/RAM, etc. were made in Leo instead of
> FPGA, but Synopsys wins.
> 
> Thanks in advance,
> Igor Peker



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
2017JanFebMarApr2017

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