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 39375

Article: 39375
Subject: Re: BRAM, clka too short setup time
From: kayrock66@yahoo.com (Jay)
Date: 7 Feb 2002 09:53:36 -0800
Links: << >>  << T >>  << A >>
Is it possible you have a hold violation masqurading as a setup
problem?  The simulator being confused which clock edge the data was
intended for and thus reporting the problem as a "setup time" problem.

Regards

"Hristo Stevic" <hristostev@yahoo.com> wrote in message news:<08784b3f07ff378d941fafb3063eb255.52609@mygate.mailgate.org>...
> hello,
> 
> Really i can't see why i am getting this error message
> bram.clka too short setup time, missing time 2.3ns!
> bram.clkb too short setup time, missing time 2.3ns!
> 
> i am using bram in both read and write mode. the two ports are clocked
> with the same clock, the master clock. one port is set always for
> writing the other for reading. The address are always differents!
> 
> the Bram address as well as the input data are REGISTRED, clocked with
> the same clock clk
> 
> so how can i get short setup time! i am using F3.1, sp7.
> i have even set the data input to zero value, the same error happen, I
> did timing simulation, the address values are as i expect (they change
> the value after the clock rising edge)
> 
> the we,en, rst bram inputs are set to VCC, or GND as required , the
> input data are registred in the IOB, so really what i am missing ? why i
> am getting this error?
> 
> thanks

Article: 39376
(removed)


Article: 39377
Subject: Re: Virtex2-3000 (XC2V3000) engineering samples and chipscope
From: kayrock66@yahoo.com (Jay)
Date: 7 Feb 2002 10:00:29 -0800
Links: << >>  << T >>  << A >>
There may have been nothing on the erratta directly, but I seem to
remember chipscope wanted its own global clock, and the V2 samples
that everyone was getting had something wierd with the clock routing-
don't remember the details.

Regards


Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C5AB737.C3425BD3@xilinx.com>...
> No errata on the errata sheet affects Chipscope ILA,
> 
> I worked personally with one customer who was using it to resolve a design
> issue on some 2V3000ES parts.
> 
> If you need help, open a hotline case.
> 
> Austin
> 
> strut911 wrote:
> 
> > hi.
> > i am having trouble getting chipscope to run on the XC2V3000ES FG676
> > -5 part. i was wondering if this was a known issue with the samples or
> > if it somehow has to do with my configuration. i have ran chipscope on
> > the XC2V1000 parts with no problem (the Insight board) and i would
> > really like to get it up on the 3000.
> > strut911

Article: 39378
Subject: Re: FPGA vs GAL : Lattice
From: whazzup <nospam@spam.com>
Date: Thu, 7 Feb 2002 10:24:54 -0800
Links: << >>  << T >>  << A >>
yes, that sounds good. Altera is telling the same stuff for their MAX 7000 series EPM3032īs. The device cost is only $1 per piece. The problem is that you donīt get DIP package which still is the best for volume production and easy prototyping.

Article: 39379
Subject: Design with Triscend E5
From: "Josan Moreno" <joseanmo@unex.es>
Date: Thu, 7 Feb 2002 19:32:21 +0100
Links: << >>  << T >>  << A >>
Hi,
I'm looking for an RTL description or PLI module of the 8051 included in
Triscend for simulation purposes.
Thanks.



Article: 39380
Subject: Re: solutions manuals, and no they are not for school
From: Jerry Avins <jya@ieee.org>
Date: Thu, 07 Feb 2002 14:14:00 -0500
Links: << >>  << T >>  << A >>
Bob Cain wrote:
> 
> Rick Lyons wrote:
> >
> >
> > >I just wish there was some bonded credential I could get that stated
> > >"Bob Cain is not a student nor is he assisting one."  :-)
> > >Bob
> >
> > Ah ha!  That credential would be handy for a student
> > to have!  Are you sure you're not a student Bob?  ;-)
> > [Maybe a student of the 'School of Hard Knocks'.]
> 
> I'll be a student in that school probably forever.  :-)
> 
> >
> > Yea, it happens.  I once posted a question about
> > solving equations containing complex exponentials
> > whose real parts are non-zero.  [e^(a +jb)]
> > Someone teased me that my question looked like
> > a homework problem, and that surprised/shocked
> > me.  No matter though, 'cause then the fellow
> > proceeded to help me out for which I really was
> > grateful.  The guy's answer forced me to stick my
> > toes in the chilly waters of hyperbolic functions.
> > Brrrrr!
> 
> Yeah, that's what I mean.  Even at my "advanced age" I still stumble
> across things like functional analysis and wavelets and Kolmogorov
> complexity where I know I've got yet another plunge that must be taken.
> Now what's this about hyperbolic functions?  :-)
> 
> Bob
> --
> 
Try computing the attenuation along a DC transmission line without
hyperbolics. They will seem simple compared to the alternative ways. (I
learned about DC attenuation in order to design telegraph lines - aren't
all curricula outdated? - but nothing goes to waste: DC power
transmission is big these days, and the math hasn't changed.)

Jerry
-- 
Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer.
                                                 Edsger W. Dijkstra
-----------------------------------------------------------------------

Article: 39381
Subject: Re: Multiple clock domein synchronization.
From: Arvin Patel <apatel@chello.no>
Date: Thu, 07 Feb 2002 19:30:35 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:

The following app note from Philips (prev. Signetics) might be of interest
to start with.

http://www.semiconductors.philips.com/acrobat/applicationnotes/AN219_1.pdf

Arvin

> It is not for glitches, it is for metastability resolution.  Metastability
> is a state between the legal 0 and 1 states that can be entered if the
> flip-flop's data input changes right when the clock is clocking in the data
> input.  See the comp.arch.fpga FAQ (http://www.fpga-faq.com/) on
> metastability.
> 
> Richard Meester wrote:
> 
> > Hello All,
> >
> > Why do you typically use 2 ffflops on a source signal to synchronize
> > between 2 clocks with 2 different speeds. Has this to do with glitches?
> >
> > Could someone perhaps point me to a website which has good information
> > about this topic.
> >
> > Thanks,
> >
> > Richard
> >
> > --
> >
> > Quest Innovations
> > tel: +31 (0) 227 604046
> > fax: +31 (0) 227 604053
> > http://www.quest-innovations.com
> 
> --
> --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: 39382
Subject: Re: Pseudorandom Bitstream
From: jrcinnh@yahoo.com (jrc)
Date: 7 Feb 2002 13:00:02 -0800
Links: << >>  << T >>  << A >>
It is pretty easy to contruct a state-machine to mimic the effects of
a LFSR shift register that has been clocked an arbitrary number of
times. To use your example the normal logic for X^3+X^2+1 using four
flip-flops is:

ff0=ff3^ff2^1 (xnor the last two flip-flops in the shift register)
ff1=ff0 (shift)
ff2=ff1 (shift)
ff3=ff2 (shift)

For each clock, the following design will produce the same four bit
sequence produced by clocking the orignal design four times:

ff0=ff3^ff2^ff0 (three term xor)
ff1=ff1^ff0^1 (xnor)
ff2=ff2^ff1^1 (xnor)
ff3=ff3^ff2^1 (xnor)

So the bit sequence for ff0 the upper design is:

0111011001010000111...

The bit sequence for the four flip-flops on second design is:

3210
----
0111
0110
0101
0000
1110
...

I always called this generating pseudorandom in parallel. It is used a
lot in communications work. Once you get the knack you can generate
any sequence in any width. If you add flip-flops you can actually
generate this sequence 8 bits at a time or even wider.

JRC


Ray Andraka <ray@andraka.com> wrote in message news:<3C62A21F.C8BFFA23@andraka.com>...
> No.  The neighboring bits, when taken a byte at a time from an LFSR are time shifted copies
> of previous bits.  If you take more than 1 bit per clock from an LFSR, you lose the uniform
> white properties.  Consider the 4 bit LFSR  X^3+X^2+1:
> 
> 0000
> 0001
> 0011
> 0111
> 1110
> 1101
> 1011
> 0110
> 1100
> 1001
> 0010
> 0101
> 1010
> 0100
> 1000
> 0000
> 
> Note that only the right most bit is random, the other bits are the same as the rightmost
> but delayed by 1,2 and 3 clocks.  If you use more than one bit per clock from an LFSR, you
> wind up with a correlation that colors the output and destroys the uniform random
> properties.  The bottom line is that an LFSR at 100MHz produces a random BIT stream at 100
> MHz, not a byte stream.  To get a random byte stream, you need to clock the LFSR 8 times
> between samples so as to get new bit values (uncorrelated to any bits in previous sample)
> in all 8 bits, which gives you a random byte stream of 100/8= 12.5 MHz.
> 
> vt313@comsys.ntu-kpi.kiev.ua wrote:
> 
> > In the LSFR bitstream the bytes of neighboring bits,
> > considered as signed vectors, are practically
> > uncorrelated, and belong to the interval (-1.0 : 1.0).
> > Therefore LSFR generator at 100 MHz
> > provides the byte stream at 100 MHz.
> >
> > If you add couples of neigboring
> > sampling bytes from LSFR,
> > then you get the  approximation
> > of the "triangle" distribution.
> >
> > If you want the Gaussian distribution,
> > then you would add n>10 neigboring
> > sampling bytes from LSFR,
> > and get the rather exact approximation
> > of the Gaussian distribution.
> >
> > Anatoli  S.
> 
> --
> --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: 39383
Subject: Xilinx ISE 3.3 upgrade to 4.1
From: "Jui Tan" <juitongtanSPAM@yahoo.com>
Date: Thu, 7 Feb 2002 13:39:05 -0800
Links: << >>  << T >>  << A >>
I have a verilog design that was targetted for the virtex 600e device.
Using the foundation ISE version 3.3 tools (servicepack 8), I ran the place
and route tools with some timing constraints, and the design was
successfully routed with 0 timing violation.  The hardware prototype worked
perfectly.

2 weeks ago, I decided to upgrade my tools to version 4.1.  After the
upgrade, I ran the same design through version 4.1 and got a whole list of
timing violations (some constraints are violated due to gate delays alone).
I called the Xilinx tech hotline, and they said that the timing library for
version 4.1 reflects the characteristics of the latest silicon.  He told me
sorry for the inconvenience- I should either relax the constraints (not
possible) or redesign the circuit (or face the possibility that the circuit
may fail).

Apparently, I would never have realise this problem if I did not upgrade my
tools.  According to Xilinx tech support, the big timing difference between
ver 3.3 & 4.1 affects all the virtex E devices.

I am sure I am not the only person with this problem.  If you have a virtexE
design in production PAR with ISE 3.3, what have/would you do?

Thanks.



Article: 39384
Subject: Schema Schematic Capture/ C models
From: "AP" <escorpiontale@hotmail.com>
Date: Thu, 07 Feb 2002 22:00:48 GMT
Links: << >>  << T >>  << A >>
Has anyone heard of Schema Schematics capture ?
I have the behavioral model, schema netlist, and Lux FPDL netlist for an
ASIC and need to convert it into VHDL. Any pointers ?
Does the Schema uses the behavioral models as part of the schematics and
then gets converted by the Lux FPDL into RTL ?
Any help will be appreciated.
Angel




Article: 39385
Subject: Re: conv_integer problem ???
From: "Madhu" <pp_madhavi@yahoo.com>
Date: Thu, 7 Feb 2002 22:22:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
"Antonio" <dottavio@ised.it> wrote in message
news:fb35ea96.0201032335.7ab30bd8@posting.google.com...

> I've the problem that with the following code I can't obtain an output
> from the ROM when the address is all zeroes, pratically I obtain UUU
> instead of a value 49E located in ROM_SRRCx3(0), may be that
> conv_integer is not working for this value ?? What is the solution ??
> 
> 
> 
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_signed.all;  
> use ieee.std_logic_arith.all;
> use std.textio.all;	
> use work.SRRC_coeffs.all; 
> 
> entity ROMx3 is 
>   port(reset      : in STD_LOGIC   ;
>   	   clk		  : in STD_LOGIC   ;
>   	   --load		  : in STD_LOGIC   ;
>   	   fir_sel    : in STD_LOGIC_VECTOR(2 downto 0);	 
> 	   addr_6     : in STD_LOGIC   ;
> 	   addr_5     : in STD_LOGIC   ;
> 	   addr_4     : in STD_LOGIC   ;
> 	   addr_3     : in STD_LOGIC   ;
> 	   addr_2     : in STD_LOGIC   ;
> 	   addr_1     : in STD_LOGIC   ;
> 	   addr_0     : in STD_LOGIC   ;
> 	   
> 	   SRRC_out   : out STD_LOGIC_VECTOR(11 downto 0));
> end; 
>  
> architecture ROMx3_arch of ROMx3 is 	  
> begin 			
>   process(clk, reset)
>   begin
>     if( reset = '1' ) then
>     	SRRC_out <= "000000000000";
>     elsif falling_edge(clk) then
> 	    SRRC_out <= ROM_SRRCx3( conv_integer(fir_sel & addr_6 & addr_5 &
> addr_4 & addr_3 & addr_2 & addr_1 & addr_0) );
>     end if;
>   end process;
> end ROMx3_arch;


Antonio,
  I have used similar which worked. I am a starter in fpga field.
  I worked with a following code.


library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity SCRAMBLING_RAM is
port(
	ADDRESS	  : IN std_logic_VECTOR(2 downto 0);  
	SCR_BYTE  : OUT std_logic_VECTOR(7 downto 0) 
	);
end SCRAMBLING_RAM;

architecture SCRAMBLING_RAM_ARCH of SCRAMBLING_RAM is
  type MEM is array (0 to 8) of std_logic_vector(7 downto 0);
  signal ramTmp : MEM;
begin

   ramTmp(0) <= "11111110";
   ramTmp(1) <= "00000100";
   ramTmp(2) <= "00011000";
   ramTmp(3) <= "01010001";
   ramTmp(4) <= "11100100";
   ramTmp(5) <= "01011001";
   ramTmp(6) <= "11010100";
   ramTmp(7) <= "11111010";
   ramTmp(8) <= "00011100";

   SCR_BYTE <= ramTmp(Conv_integer(ADDRESS)) ;

end SCRAMBLING_RAM_ARCH;

                           Madhu

  


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 39386
Subject: Re: Pseudorandom Bitstream
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Feb 2002 23:13:12 GMT
Links: << >>  << T >>  << A >>
Exactly.  In fact, all the LFSR is is a special case of the CRC hardware.  I did't want to
confuse the issue, but as you say, you can create a parallel version of the LFST that appears at
the outputs to advance N clocks in a single clock.

jrc wrote:

> It is pretty easy to contruct a state-machine to mimic the effects of
> a LFSR shift register that has been clocked an arbitrary number of
> times. To use your example the normal logic for X^3+X^2+1 using four
> flip-flops is:
>
> ff0=ff3^ff2^1 (xnor the last two flip-flops in the shift register)
> ff1=ff0 (shift)
> ff2=ff1 (shift)
> ff3=ff2 (shift)
>
> For each clock, the following design will produce the same four bit
> sequence produced by clocking the orignal design four times:
>
> ff0=ff3^ff2^ff0 (three term xor)
> ff1=ff1^ff0^1 (xnor)
> ff2=ff2^ff1^1 (xnor)
> ff3=ff3^ff2^1 (xnor)
>
> So the bit sequence for ff0 the upper design is:
>
> 0111011001010000111...
>
> The bit sequence for the four flip-flops on second design is:
>
> 3210
> ----
> 0111
> 0110
> 0101
> 0000
> 1110
> ...
>
> I always called this generating pseudorandom in parallel. It is used a
> lot in communications work. Once you get the knack you can generate
> any sequence in any width. If you add flip-flops you can actually
> generate this sequence 8 bits at a time or even wider.
>
> JRC
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3C62A21F.C8BFFA23@andraka.com>...
> > No.  The neighboring bits, when taken a byte at a time from an LFSR are time shifted copies
> > of previous bits.  If you take more than 1 bit per clock from an LFSR, you lose the uniform
> > white properties.  Consider the 4 bit LFSR  X^3+X^2+1:
> >
> > 0000
> > 0001
> > 0011
> > 0111
> > 1110
> > 1101
> > 1011
> > 0110
> > 1100
> > 1001
> > 0010
> > 0101
> > 1010
> > 0100
> > 1000
> > 0000
> >
> > Note that only the right most bit is random, the other bits are the same as the rightmost
> > but delayed by 1,2 and 3 clocks.  If you use more than one bit per clock from an LFSR, you
> > wind up with a correlation that colors the output and destroys the uniform random
> > properties.  The bottom line is that an LFSR at 100MHz produces a random BIT stream at 100
> > MHz, not a byte stream.  To get a random byte stream, you need to clock the LFSR 8 times
> > between samples so as to get new bit values (uncorrelated to any bits in previous sample)
> > in all 8 bits, which gives you a random byte stream of 100/8= 12.5 MHz.
> >
> > vt313@comsys.ntu-kpi.kiev.ua wrote:
> >
> > > In the LSFR bitstream the bytes of neighboring bits,
> > > considered as signed vectors, are practically
> > > uncorrelated, and belong to the interval (-1.0 : 1.0).
> > > Therefore LSFR generator at 100 MHz
> > > provides the byte stream at 100 MHz.
> > >
> > > If you add couples of neigboring
> > > sampling bytes from LSFR,
> > > then you get the  approximation
> > > of the "triangle" distribution.
> > >
> > > If you want the Gaussian distribution,
> > > then you would add n>10 neigboring
> > > sampling bytes from LSFR,
> > > and get the rather exact approximation
> > > of the Gaussian distribution.
> > >
> > > Anatoli  S.
> >
> > --
> > --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

--
--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: 39387
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: "Mike Johnson" <mikej<NOSPAM>freeuk.com>
Date: Fri, 8 Feb 2002 00:14:24 -0000
Links: << >>  << T >>  << A >>
worrying isn't it !
In the past I've generally found that the speed files have become less
pessimistic as Xilinx have refined them, so the chips 'get faster'. No
excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ?
there is a Xilinx utility (speedprint) which prints out the timing details
for a device from a speedfile - I'll compare 3.1 sp 8 and 4.1. sp2 tomorrow.
In my experience 4.1 generally gives a faster result than 3.3 for the same
code & virtex E device, however in your particular case it may be that the
tool is doing a worse job ?
Mike

"Jui Tan" <juitongtanSPAM@yahoo.com> wrote in message
news:1013117951.597749@hp-sdd.sdd.hp.com...
> I have a verilog design that was targetted for the virtex 600e device.
> Using the foundation ISE version 3.3 tools (servicepack 8), I ran the
place
> and route tools with some timing constraints, and the design was
> successfully routed with 0 timing violation.  The hardware prototype
worked
> perfectly.
>
> 2 weeks ago, I decided to upgrade my tools to version 4.1.  After the
> upgrade, I ran the same design through version 4.1 and got a whole list of
> timing violations (some constraints are violated due to gate delays
alone).
> I called the Xilinx tech hotline, and they said that the timing library
for
> version 4.1 reflects the characteristics of the latest silicon.  He told
me
> sorry for the inconvenience- I should either relax the constraints (not
> possible) or redesign the circuit (or face the possibility that the
circuit
> may fail).
>
> Apparently, I would never have realise this problem if I did not upgrade
my
> tools.  According to Xilinx tech support, the big timing difference
between
> ver 3.3 & 4.1 affects all the virtex E devices.
>
> I am sure I am not the only person with this problem.  If you have a
virtexE
> design in production PAR with ISE 3.3, what have/would you do?
>
> Thanks.
>
>



Article: 39388
Subject: Re: Announce: VHDL Simili 2.0 - Graphics, Windows, Linux, Affordable
From: "Haneef Mohammed" <haneefd@attbi.com.nospam>
Date: Fri, 08 Feb 2002 00:42:58 GMT
Links: << >>  << T >>  << A >>
Hi Srini,

I tried the newest Leon code (2.4.0) and the one I used to use
on a regular basis (2.2 I think). Both of them compile and simulate
fine. I have tried the main testbench as well as the various
configurations supplied. The problem could be specific to WinXP
(very unlikely). If you can send me the exact vhdle command
line which demonstrates the problem, I will have it resolved
as soon as possible.

Regards,
Haneef

PS: Can you please respond directly to me. Once we have things
resolved, we can report back to the group.




Article: 39389
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: "Marc Klingelhofer" <marc_klingelhofer@hotmail.com>
Date: Thu, 7 Feb 2002 17:05:34 -0800
Links: << >>  << T >>  << A >>
"Jui Tan" <juitongtanSPAM@yahoo.com> wrote in message
news:1013117951.597749@hp-sdd.sdd.hp.com...
> I have a verilog design that was targetted for the virtex 600e
> device. Using the foundation ISE version 3.3 tools (servicepack 8),
> I ran the place and route tools with some timing constraints, and
> the design was successfully routed with 0 timing violation.  The
> hardware prototype worked perfectly.
>
> 2 weeks ago, I decided to upgrade my tools to version 4.1.  After
> the upgrade, I ran the same design through version 4.1 and got a
> whole list of timing violations (some constraints are violated due
> to gate delays alone).  I called the Xilinx tech hotline, and they
> said that the timing library for version 4.1 reflects the
> characteristics of the latest silicon.  He told me sorry for the
> inconvenience- I should either relax the constraints (not possible)
> or redesign the circuit (or face the possibility that the circuit
> may fail).
>
> Apparently, I would never have realise this problem if I did not
> upgrade my tools.  According to Xilinx tech support, the big timing
> difference between ver 3.3 & 4.1 affects all the virtex E devices.
>
> I am sure I am not the only person with this problem.  If you have
> a virtexE design in production PAR with ISE 3.3, what have/would you
> do?
>
> Thanks.



Jui,

    Not all the problems with 3.3i sp8 or before were due to poor device
characterization. We use the 1000e-7 and there was a bug in the timing
analysis, either in the speed file or in the software. In our case, the
WEAs for BlockRAMs in column 0 (RxC0.WEA) had phenomenal(!) timing.

    A single net went to the WEA of all 16 BlockRAMs in column 0 and
several  BlockRAMs in other columns. The net delays to the other BlockRAMs
looked sensible, and indeed they matched when comparing timing analysis
for the routed design using 3.3i sp8 and 4.1i sp2.

    However, the delays reported for the net as it traveled down C0 were
a little optimistic (sarcasm) with 3.3i sp8. From row 0 to row 15 the net
showed a delay of 5 ps. Yes, 5 picoseconds. The row-to-row delta was either
0 ps or 1 ps. (We could only hope for such timing!)

    4.1i sp2 showed something a little different. The row-to-row delay was
consistently 392 ps or 393 ps, so the total net delay from row 0 to row 15
was 5.885 ns.

    I would never have found this nor suspected it except we had a failure
in the lab and I happened to have upgraded the tools since the build. I
ran timing analysis using 4.1i sp2 and was a little surprised to see
timing violations. (There were 0 errors and 0 unconstrained paths with
3.3i sp8.) I looked at the nets and this WEA was the worst violator.
Comparing 3.3 to 4.1 it was obvious what the problem was. And the failure
in the lab was associated with the BlockRAM at row 15, which had the most
grossly underestimated delay. Case closed: 3.3 with its speed file is
bad. I never tried running 3.3 sp8 with a newer speed file, so I can't
say for sure whether it's a software problem ("let's zero out the delays
for BlockRAM column 0"--oops) or a speed file problem.

    Now to your question. If you can verify margin in your system
(operating temperature or voltage) I'd take that into account and see if
you're still missing timing. Then, and this is as risky as design gets,
I'd try to rationalize how much faster the parts are than what the timing
reports say. If you're using the -8, there may not be a lot of margin,
and you should think about recalling your hardware. In the meantime, see
if you can get a clean build using 4.1i, because that's what you'll want
to use going forward.

    Not all designs can justify a network connection or the hardware that
supports upgrading over the Internet, but it is worth considering for
situations like this.

    Good luck,


                Marc Klingelhofer






Article: 39390
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: Bob Perlman <no-spam@sonic.net>
Date: Fri, 08 Feb 2002 01:27:08 GMT
Links: << >>  << T >>  << A >>
Hi - 

You pose a good question.  I can't give you a complete answer, but
perhaps I can suggest a few things.

Quite a while ago, Xilinx put in place a system for categorizing speed
files which, if I recall correctly, goes like this:

advanced - speed files based on SPICE simulations, educated guesses,
etc.

preliminary - speed files based on early silicon

final - speed files based on production silicon

I assume that Xilinx still uses this system, or something similar (can
someone from Xilinx confirm or correct?).   This nomenclature is
fairly common practice in the industry, although company X and company
Y may disagree on the specifics of what constitutes a given category.

If you're designing an FPGA and the speed files are advanced or
preliminary, do two things: 

1) Design in some timing margin by decreasing the timespecs.  For
example, if your clock is supposed to run at 100MHz, make your period
target 8 or 9ns instead of 10. If you can't meet the faster specs, you
may have to rethink your design.  (Case in point: I've been working on
a Virtex II design, and I created twice as many datapaths as the
initial timing specs seemed to indicate were necessary, and ran them
at half speed.  It was a lot of trouble, but when the Virtex II
multiplier specs took a significant speed hit a few months ago, I was
very glad I did it.)

2) Do NOT design with the fastest speed grade; save it to dig yourself
out of trouble if the unthinkable happens.

What to do about products that have already shipped is a tough call.
If you've put 100%  of your outgoing units through 4-corner
environmental test (i.e., voltage and temperature extremes), you
should be OK.  If not, you may have to come up with an alternative
design, perhaps in a faster speed grade, to replace those units that
are returned.  

Bob Perlman
--
Cambrian Design Works
digital design, signal integrity
http://www.cambriandesign.com
e-mail: respond to bob at the domain above.



On Thu, 7 Feb 2002 13:39:05 -0800, "Jui Tan"
<juitongtanSPAM@yahoo.com> wrote:

>I have a verilog design that was targetted for the virtex 600e device.
>Using the foundation ISE version 3.3 tools (servicepack 8), I ran the place
>and route tools with some timing constraints, and the design was
>successfully routed with 0 timing violation.  The hardware prototype worked
>perfectly.
>
>2 weeks ago, I decided to upgrade my tools to version 4.1.  After the
>upgrade, I ran the same design through version 4.1 and got a whole list of
>timing violations (some constraints are violated due to gate delays alone).
>I called the Xilinx tech hotline, and they said that the timing library for
>version 4.1 reflects the characteristics of the latest silicon.  He told me
>sorry for the inconvenience- I should either relax the constraints (not
>possible) or redesign the circuit (or face the possibility that the circuit
>may fail).
>
>Apparently, I would never have realise this problem if I did not upgrade my
>tools.  According to Xilinx tech support, the big timing difference between
>ver 3.3 & 4.1 affects all the virtex E devices.
>
>I am sure I am not the only person with this problem.  If you have a virtexE
>design in production PAR with ISE 3.3, what have/would you do?
>
>Thanks.
>


Article: 39391
Subject: Re: FPGA vs GAL : Lattice
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 08 Feb 2002 01:35:50 +0000
Links: << >>  << T >>  << A >>


whazzup wrote:

> yes, that sounds good. Altera is telling the same stuff for their MAX 7000 series EPM3032īs. The device cost is only $1 per piece. The problem is that you donīt get DIP package which still is the best for volume production and easy prototyping.

It was a long time ago, still in the DIP era, when we made the decision that its really not worth making up wire-wrap proto boards - just do the real thing. With that in mind and the fact that the XC95K parts are in system reprogrammable the DIP
argument falls. And for volume production auto pick&place pure SMT boards reduce assembly costs.


Article: 39392
Subject: Re: Programming Altera PGAs.
From: James <james.fenech@remove.nec.com.au>
Date: Fri, 08 Feb 2002 03:53:50 GMT
Links: << >>  << T >>  << A >>
Thanks for the replies,

Looks like they're throw aways. They were removed (socketed) from old 
boards so I don't know the source.

As I have a well stocked junk box, I thought the programmer would be 
easy and cheap, but obviously with controlled rise times - maybe not.

James.

Victor Schutte wrote:

> I agree. The cost of a couple of 7064Ss and a homemade ByteBlaster cable is
> a lot less than an Altera programmer.
> 
> Victor
> 
> "Jim Granville" <jim.granville@designtools.co.nz> wrote in message
> news:3C60C6D5.48CB@designtools.co.nz...
> 
>>James wrote:
>>
>>>Hi,
>>>
>>>just scored some used, but reusable EPM7064 gate arrays that I would
>>>
> like to
> 
>>>use in some home projects. Unfortunately they are NOT "in circuit
>>>programmable" and require a seperate programmer.
>>>
>>>The Altera web site has no details on programming these devices, but do
>>>
> have
> 
>>>free software for circuit entry etc.
>>>
>>>Can a programmer be built by me for these parts (I don't need high speed
>>>
> or
> 
>>>flexibility)? Obviously my budget doesn't allow for a bought one -
>>>
> unless
> 
>>>extremely cheap (few 10s of $), else I'd just buy one.
>>>
>>>Does anyone know where programming details can be found? Surely such
>>>
> details
> 
>>>are freely available!
>>>
>>No, because the support is too costly. It wont work first time, and then
>>what happens...
>>
>>You might find an old programmer that supports the non-isp models, but
>>better
>>is to move to ISP CPLDs
>>
>>In this class of CPLD are
>>
>>Altera 7064S - newer ISP versions of those you have
>>Xilinx CoolRunner XCR3064
>>Atmel ATF1504AS
>>
>>Atmel have the best 5V support.
>>
>>-jg
>>
> 
> 


Article: 39393
Subject: Re: Multiple clock domein synchronization.
From: Richard Meester <rme@quest-innovations.com>
Date: Fri, 08 Feb 2002 08:26:51 +0100
Links: << >>  << T >>  << A >>
Thanks all for the pointers.

Richard

Arvin Patel wrote:

> Ray Andraka <ray@andraka.com> writes:
>
> The following app note from Philips (prev. Signetics) might be of interest
> to start with.
>
> http://www.semiconductors.philips.com/acrobat/applicationnotes/AN219_1.pdf
>
> Arvin
>
> > It is not for glitches, it is for metastability resolution.  Metastability
> > is a state between the legal 0 and 1 states that can be entered if the
> > flip-flop's data input changes right when the clock is clocking in the data
> > input.  See the comp.arch.fpga FAQ (http://www.fpga-faq.com/) on
> > metastability.
> >
> > Richard Meester wrote:
> >
> > > Hello All,
> > >
> > > Why do you typically use 2 ffflops on a source signal to synchronize
> > > between 2 clocks with 2 different speeds. Has this to do with glitches?
> > >
> > > Could someone perhaps point me to a website which has good information
> > > about this topic.
> > >
> > > Thanks,
> > >
> > > Richard
> > >
> > > --
> > >
> > > Quest Innovations
> > > tel: +31 (0) 227 604046
> > > fax: +31 (0) 227 604053
> > > http://www.quest-innovations.com
> >
> > --
> > --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

--


Quest Innovations
tel: +31 (0) 227 604046
fax: +31 (0) 227 604053
http://www.quest-innovations.com



Article: 39394
Subject: Re: CLKDLL x4 problem
From: dottavio@ised.it (Antonio)
Date: 7 Feb 2002 23:30:33 -0800
Links: << >>  << T >>  << A >>
Hi Ray,
the problem is synchronization between the data arriving from the
pattern generator and the clocks that are inside FPGA, my idea to use
clkdll was to enter inside the FPGA with the clock (25MHz for example)
associated to the data and coming from the pattern generator, from
that clock to obtain a 100MHz master clock via the CLKDLL and in this
way is all synchronized, but 100MHz out of the DINI board seems to be
not achieved.
If I choose your schema 40MHz quartz plus clkdll divider, I've the
problem that this divided frequency, maybe 10MHz is not synchronized
to the 10 MHz coming from the pattern generator, about this I'm
studing the opportunity to insert a FIFO which write is driven from
the pattern generator clock and read is driven from the board reduced
clock.
What do you think about this, there's a simple way to obtain the same
results ??

                                Antonio

Article: 39395
Subject: Xilinx DCM question anyone? (or Peter if he is there?)
From: "Tim Ottley" <tim.ottley@elixent.com>
Date: Fri, 8 Feb 2002 09:34:38 -0000
Links: << >>  << T >>  << A >>
Hi Peter et al,

I wish to use a DCM as a programmable and sweepable clock source
within a Vertex2 device.  It will only be supplying its output to an
external pin,
but the output will need to be gatable.

I want to use it in the Digital Frequency Synthesis mode, with registers to
hold
the Multiplier & Divider values so that the output frequency can be changed
at
any time.  The only problem I have is that I cannot find the M & D control
signals
on the instance of the DCM block.  I  believe that I will need to use the
CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
is instanced, but I am not clear how I can use these in a dynamically
adjustable way.

Can anyone tell me if this is possible, and if so, a little snippet of
Verilog to illustrate?
(pretty please)

Thanks,
              Tim Ottley.



Article: 39396
Subject: Re: solutions manuals, and no they are not for school
From: strut911@hotmail.com (strut911)
Date: 8 Feb 2002 01:40:23 -0800
Links: << >>  << T >>  << A >>
yes,
you have all discovered my secret. i wish to sell solutions manuals
over the internet, especially the manuals to complex graduate
algorithmic books. i have seen the potential and it is huge. it
completely dwarfs my asic design salary (which is not that much at all
by the way). in this way, i can undermine the whole engineering
education system, and throw the world, nay, the universe to a time
when technology was just an apple falling on newton's head. far be it
from me to actually try and work out a textbook problem by problem and
learn something. that is for sissies. real men are the ones that can
walk a tightrope without a net, drive a car without a seat belt.
unfortunately, i was hoping that mummy would hold my hand, and
unfortunately, i discovered that mummy doesn't exist. and so, i will
pursue my solutions manuals on amazon.com and search for them through
hotbot and other metasearch engines. when i do come across interesting
engineering manuals and am tempted to buy the book, i might have the
inclination to suspect myself of trying to cheat on the midterm i give
myself or my personal take-home final. maybe i will collaborate with
myself on my homework, or copy my own answers. hmmm...i can understand
how suspicious my actions are. i am, after all, trying to grab a chunk
of that huge engineering technical reference book pie that has made
many a professor rich and famous.
strut911
p.s. i hope no one takes offense at this. i really enjoyed reading the
responses.

Article: 39397
Subject: Re: solutions manuals, and no they are not for school
From: ricklyon@remove.onemain.com (Rick Lyons)
Date: Fri, 08 Feb 2002 12:11:28 GMT
Links: << >>  << T >>  << A >>
On Wed, 06 Feb 2002 21:05:49 -0800, Bob Cain <arcane@znet.com> wrote:

  (snipped)
>Now what's this about hyperbolic functions?  :-)
>
>Bob

Ah, I was tryin' to derive the equation for the 
frequency response of an IIR filter having poles 
lying just inside the unit circle.  I ended up with 
terms like (1 + Ke^jw), where K was just less than 
unity.  As my algebra plodded along I ended up with terms 
like e^(x+jw), a complex exponential with a non-zero 
real part in the exponent, and that's when I needed help.

[-Rick-]

Article: 39398
Subject: Re: solutions manuals, and no they are not for school
From: ricklyon@remove.onemain.com (Rick Lyons)
Date: Fri, 08 Feb 2002 12:13:22 GMT
Links: << >>  << T >>  << A >>
On Thu, 07 Feb 2002 14:14:00 -0500, Jerry Avins <jya@ieee.org> wrote:

  (snipped)

>I learned about DC attenuation in order to design telegraph lines - aren't
>all curricula outdated? - but nothing goes to waste: DC power
>transmission is big these days, and the math hasn't changed.)
>
>Jerry

Telegraph lines!!  Maybe I was right when I 
once posted that you knew Abraham Lincoln personally.

[-Rick-]

Article: 39399
Subject: Re: Xilinx DCM question anyone? (or Peter if he is there?)
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 08 Feb 2002 13:13:15 GMT
Links: << >>  << T >>  << A >>
On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com> wrote:
>Hi Peter et al,
>
>I wish to use a DCM as a programmable and sweepable clock source
>within a Vertex2 device.  It will only be supplying its output to an
>external pin,
>but the output will need to be gatable.
>
>I want to use it in the Digital Frequency Synthesis mode, with registers to
>hold
>the Multiplier & Divider values so that the output frequency can be changed
>at
>any time.  The only problem I have is that I cannot find the M & D control
>signals
>on the instance of the DCM block.  I  believe that I will need to use the
>CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
>is instanced, but I am not clear how I can use these in a dynamically
>adjustable way.
>
>Can anyone tell me if this is possible, and if so, a little snippet of
>Verilog to illustrate?
>(pretty please)
>
>Thanks,
>              Tim Ottley.
>

This is do-able, but FAR from easy. The M and D values are parameters
that end up being encoded in the bit stream. There is no direct runtime
access to them.

The Virtex-II devices do support run-time partial configuration.

You would need to find the location of these bits in the bitstream,
and create a partial reconfig to modify them on the fly. Given the
issues with DCM reset, I would suspect that to be succesful, you would
need to assert the DCM reset, then do the reconfig, then release DCM
reset. Since configuration is by frames, you would also have to build
reconfiguration frames that did not damage other parts of your design.

So I dont think that sweeping is going to be possible.

To see what you are up against, create a design with a DCM in it.
and create an RBT file from it. Using the XDL interface to the
NCD file, edit the M and D, convert back to NCD and create a new
RBT. Compare to see how it changed.

In the XDL, look for something like this:

inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
 cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
      STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
      FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
      FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
      STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
      PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
      RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
      CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
      CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
      CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
      CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
      DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
      PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
      LL_HEX_COM:: LL_HEX_MISC::"


M and D are on the third last line. BUT ... there seems to be
quite a few other attributes that are being automatically set
by the sw, that are not documented for user control.

The command I used to create the above was:

   xdl -ncd2xdl app_1.ncd

I am using M4.1i sp3

Good luck,

Philip Freidin


Philip Freidin
Fliptronics



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