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 41275

Article: 41275
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: Ken McElvain <ken@synplicity.com>
Date: Sun, 24 Mar 2002 20:13:43 GMT
Links: << >>  << T >>  << A >>
You are correct.  I've forwarded it to our compiler group to
see what they say about it.

Allan Herriman wrote:

> On 22 Mar 2002 22:01:27 -0800, brimdavis@aol.com (Brian Davis) wrote:
> 
> 
>>  ts_mux <= a_in  when sel = "00" else  'Z';
>>  ts_mux <= b_in  when sel = "01" else  'Z';
>>  ts_mux <= c_in  when sel = "10" else  'Z';
>>
>>  process
>>    wait until rising_edge(clk);
>>     sig1 <= ts_mux;
>>     sig2 <= ts_mux AND '1';
>>  end process;
>>
> 
> 
> I would add to this:
> 
>        sig3 <= to_X01(ts_mux);
> 
> This should *never* allow a tristate to propagate through a flip flop,
> regardless of any tool settings.
> (Ken, can you confirm this please?)
> 
> Regards,
> Allan.
> 


Article: 41276
Subject: Re: Too many clocks
From: "Mike Johnson" <mikej<NO SPAM>@freeuk.com>
Date: Sun, 24 Mar 2002 21:24:52 -0000
Links: << >>  << T >>  << A >>
Its a right pain isn't it !
Spectrum has been doing this since 2000 1d I think, and it caught me out.
There is a paramter somewhere which is approx  'set attribute do not insert
global clock buffers'.
Search the documentation for exact incantation.
However, I think you have to then manually instantiate BUFG's on your global
clocks and IBUF's for the others.

Cheers,
MikeJ

"Niv" <niv@ntlworld.com> wrote in message
news:9HXm8.1321$QR.101429@news11-gui.server.ntli.net...
> I have a design with more than 4 clocks, the Virtex max., (but some are
very
> slow, < 1MHz).
>
> LeoSpec insists on putting BUFG's on all the clocks, which causes Xilinx
PAR
> to throw a wobbler.
>
> The design now has a 40MHz master clk into a CLKDLL, which produces 2
> internal clocks with BUFG's, which is wanted, and 4 other clocks, only 2
of
> which need BUFG's.  The other 2 clocks are low freq. and low fanout.
>
> The old design worked fine with 6 external clks; LeoSpec just sorted it
out
> somehow;  But now with 5 external clks, the master one to a DLL, it all
goes
> to pot!
>
> Anyone got any bright ideas please?
>
> i.e. How do I force some of my clocks NOT to use BUFG's & IBUFG's,  just
use
> IBUF's instead?
>
> TIA, Niv.
>
>



Article: 41277
Subject: Re: Clock termination affecting JTAG interface
From: Dean Armstrong <daa1@cs.waikato.ac.nz>
Date: Mon, 25 Mar 2002 11:04:12 +1200
Links: << >>  << T >>  << A >>
Hi Paul,

Yes, your diagram is correct.

I have now tried terminating with Rt_high = Rt_low = 180R, as well as 
with Rt_high = 270R, Rt_low = 120R, but this does not solve the problem.

What I cannot figure out is why this clock should affect the Spartan II 
JTAG interface in any way. At this stage the clock input to the Spartan 
II is simply connected to one of the GCLK inputs, and the chip is not 
configured, so I figure that it should not matter what the clock is doing!

With regard to 5V tolerance, all of the devices are supposed to have 5V 
tolerant I/O's, including the Spartan II.

Regards,
Dean.

Paul wrote:
> In article <3C9ABB11.1030006@cs.waikato.ac.nz>, Dean Armstrong
> <daa1@cs.waikato.ac.nz> wrote:
> 
> 
>>Hi All,
>>
>>I have encountered a strange problem on a board we have designed. The 
>>board contains a Xilinx Spartan II XC2S200, two Xilinx XC95288XL CPLDs, 
>>and one Xilinx XC95144XL CPLD.
>>
>>There are three power supply voltages on the board: 2.5V for the Spartan 
>>II core, 3.3V for the CPLDs and the Spartan II I/O, and 5V for some RAM 
>>and ROM.
>>
>>There is a 19.6608MHz Crystal Oscillator Module running on the 5V rail, 
>>which provides a clock to the four Xilinx chips. This clock rings more 
>>than I would like, so I wish to terminate it using pads included in the 
>>design for this reason.
>>
>>Using information from the manufacturer I have established that the 
>>impedance of the clock trace is around 90 Ohms, so I terminated it to 5V 
>>and to ground, each with 180 Ohm resistors.
>>
>>When I do this, however, the JTAG test access port on the Spartan II 
>>appears to become unreliable - I am not able to configure the Spartan II 
>>via JTAG.
>>
>>I am using the Xilinx Parallel Cable III running using the 5V supply on 
>>the board.
>>
>>I use the IDCODE looping feature in the Xilinx iMPACT JTAG programmer 
>>software, and when the clock is terminated then this fails after a 
>>varying number of iterations (often between 200 and 8000).
>>
>>As soon as I remove the clock termination, this IDCODE looping is 
>>successful.
>>
>>One idea that was put to me was that the clock termination may be 
>>introducing noise into my 5V rail, which is affecting the Parallel Cable 
>>III. I tried decoupling this supply close to the Cable, and this had no 
>>effect. I also tried using an entirely seperate power supply for the 
>>Parallel Cable, and this also made no difference.
>>
>>I tried terminating just to Ground (ie. removing the resistor from the 
>>clock net to 5V). This seemed to make things better, but did not fix the 
>>problem completely.
>>
>>My 5V supply is actually ~4.72V. While this is within the +/-10% 
>>specified limits of all the chips that use it, it is outside the +/-5% 
>>specified limits of the crystal oscillator module. I cannot see how this 
>>could cause problems, because the JTAG interface has nothing to do with 
>>this clock.
>>
>>Does anyone have any ideas about what may be causing this, or what I can 
>>try to establish the cause?
>>
>>Kind regards,
>>Dean Armstrong
>>The University of Waikato
>>New Zealand
> 
> 
> I need a little clarification. This oscillator at 19.6608MHz is the
> clock for the digital logic you have implemented - how is that related
> electrically to the TCK clock that comes from the JTAG cable ? I assume 
> your mission mode clock is like [view in Courier Font...]
> 
>                                   +5V
>                                    |                                   
>                                   Rt_high
>                                    |
>  osc-------------------------------|
>  19M    |      |      |      |     |
>         |      |      |      |    Rt_Low
>        Load  Load   Load    Load   |
>                                   Gnd
> 
>                                   
> JTAG-------------------------------
>  TCK    |      |      |      |     
>         |      |      |      |   
>        Load  Load   Load    Load  
> 
> 
> In the figure above, the 19MHz osc probably doesn't have enough drive
> strength, to drive a parallel termination (shown here as Thevenin
> equivalent consisting of Rt_high and Rt_Low). I would try a partial
> termination, which may reduce the ringing enough to make it work.
> I.e. Aim for 180 ohms as the parallel equivalent and use a 360ohm
> resistor to +5V anda 360ohm resistor to GND.
> 
> This 19MHz interconnect also brings up another issue. Are the clock
> inputs on the loads 5V tolerant ? I bet the device powered by 2.5V 
> isn't.
> 
> Frequently, driver outputs, like this 19M oscillator, have different
> high and low drive capability. You should adjust the strength of
> Rt_high and Rt_low according to the low and high drive strength
> of the oscillator. When I had to do this termination case once 
> (when another board in a system gave me a clock with no series 
> termination), I used markedly different values for Rt_high and 
> Rt_low, to help the driver at the source board make a better 
> logic one. You could use a lower value for Rt_Low, if the logic 1
> voltage looks too high.
> 
> Now, consider if we were doing the design again...
> 
> A device driving the JTAG line should have a slow edge rate. If it
> does, then no termination resistor is necessary. Ideally, clocks 
> should be point to point, so for perfection you should use
> 
>               _____
>              |     |
>              |     |
>           ___|     |---Rseries------ Load
>          |   |     |
>          |   | 244 |
>          |___| BUF |---Rseries------ Load
>          |   |     |
>          |   |     |
> JTAG---------|     |---Rseries------ Load
>  TCK     |   |     |
>          |   |     |
>           ___|     |---Rseries------ Load
>              |     |
>              |     |
>               ------
> 
>               _____
>              |     |
>              |     |
>              |     |---Rseries------ Load
>              |     |
>              |     |
>              | *   |---Rseries------ Load
>              |     |
>              |     |
> Osc ---------|     |---Rseries------ Load
> 19M          |     |
>              |     |
>              |     |---Rseries------ Load
>              |     |
>           ___| FB  |---Rseries---
>           |   _____              |
>           |                      |
>           -----------------------
> 
> * = Cypress CY2305 or CY2308 zero delay buffer
> 
> The reason a 74xx244 can be used for JTAG, is data is clocked in
> on rising edge, and out on falling edge. This makes the timing
> insensitive to delay, so a sloppy and cheap buffer can be used
> and JTAG will work just fine. By using series damping resistors,
> the edge rate can be as sharp as you want.
> 
> For the 19M distribution, I am assuming you are being bold, and
> are passing data using only rising edges. In this case, a zero
> delay buffer can be used to deliver the clocks in phase, with
> only a few hundred picoseconds of penalty on your hold time
> budget.
> 
>        Paul
> 
> P.S. Don't worry about the supply voltage :-)



Article: 41278
Subject: Re: Clock termination affecting JTAG interface
From: Dean Armstrong <daa1@cs.waikato.ac.nz>
Date: Mon, 25 Mar 2002 11:06:13 +1200
Links: << >>  << T >>  << A >>
Thanks for the ideas, I will try these.

I do not however, understand why this would affect the ability to use 
the JTAG interface to the Spartan II.

Regards,
Dean.

Peter Alfke wrote:
> 
> Paul Burke wrote:
> 
> 
>>Can your clock source and sink 28mA? Try isolating the termination with
>>a capacitor of negligible impedance at 20MHz, say 10nF. Or try a 91 ohm
>>resistor in series with the clock close to the oscillator.
>>
> 
> 
> Series termination at the source is great for single-destination signals. But
> here there are 4 destinations, and the 50% voltage step can cause a lot of
> trouble.
> 
> But parallel termination at the far end with an RC combination ( 91 Ohm in
> series with a few nF) to ground might be a good idea.
> 
> Peter Alfke
> 
> 



Article: 41279
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: brimdavis@aol.com (Brian Davis)
Date: 24 Mar 2002 18:56:43 -0800
Links: << >>  << T >>  << A >>
Allan wrote:

>
>I would add to this:
>
>       sig3 <= to_X01(ts_mux);
>
>This should *never* allow a tristate to propagate through
> a flip flop, regardless of any tool settings.
>

 Thanks, I added that one to my test-case-in-progress.

      sig1 <= ts_mux;
      sig2 <= ts_mux AND '1';
      sig3 <= to_X01(ts_mux);

  Although both sig2 and sig3 resolve to 'X' in pre-synthesis
 simulation, Synplify 7.0.3 builds a tristate on all three outputs
 instead of just on sig1. 

  That is completely incorrect from any perspective, whether you
 believe in Z-transport DFFs or not.


Test Case notes ( see code below):

   Sig5 shows the tristate pushthough in action across a big shift
  register, which requires pipelining the phantom enable to match.

   Also see sig7, which shows the tristate pushthough affecting
 some combinatorial logic described with a conditional assignment. 

  For a real chuckle:
   - synthesize the test case below
   - look at the synthesis results in the HDL Analyst RTL viewer
   - uncomment the fourth driver on the tristate bus & resynthesize
   - look at the synthesis results again

   
Improved workaround:

  Although "to_X01" doesn't work in Synplify 7.0.3, you could write
 the following and still be fairly portable if you always use this
 resolved signal as the input to registers or other logic:

   attribute syn_keep : boolean;
   attribute syn_keep of ts_mux_resolved : signal is true;
     .
     .
   ts_mux_resolved <= to_X01(ts_mux)


Other Notes:

   I was going to try this test case with Synplify 7.1, but it doesn't
 seem to be available on the website.

   I spent a while last night searching for this switch in 7.0.3;
 there seems to be no mention of this tristate pushthrough feature
 in the 7.0.3 release notes or documentation.


thanks,
Brian


--
-- tt2.vhd
--
-- - demonstrates nasty side effects of tristate pushthrough,
--   which will unpredictably create tristates at output pins
--
-- - demonstrates improper implementation of the pushthrough feature
--    - signals that have 'X's in pre-synth RTL sim also incorrectly
--       suffer from tristate pushthrough
--
-- - tested with Synplicity 7.0.3, targeting Spartan-2
--
--
library ieee;
use ieee.std_logic_1164.all;

entity tt2 is 
  port
    (	
      clk   : in  std_logic;

      sel   : in  std_logic_vector( 1 downto 0 );

      a_in  : in  std_logic;
      b_in  : in  std_logic;
      c_in  : in  std_logic;
      d_in  : in  std_logic;

      dummy : in  std_logic;

      sig1 : out std_logic;
      sig2 : out std_logic;
      sig3 : out std_logic;
      sig4 : out std_logic;
      sig5 : out std_logic;
      sig6 : out std_logic;
      sig7 : out std_logic;
      sig8 : out std_logic
    );
end tt2;

architecture arch1 of tt2 is

  signal   ts_mux   : std_logic;

  constant PIPE_MSB : natural := 17;
  signal   pipe     : std_logic_vector(PIPE_MSB downto 0);

begin

 --
 -- build an not-fully-populated internal tristate mux
 --
 ts_mux <= a_in  when sel = "00" else  'Z';
 ts_mux <= b_in  when sel = "01" else  'Z';
 ts_mux <= c_in  when sel = "10" else  'Z';

 --
 -- Need to comment out the last driver so tristate pushthrough
 -- behavior appears. If the tristate mux is fully populated,
 -- some of the output tristates vanish, as Synplify's analysis
 -- of the enables concludes that the bus is always being driven
 --
 -- ts_mux <= d_in  when sel = "11" else  'Z';

 --
 -- register the mux several ways
 --
 --
 out_reg: process(clk)
  begin

    if rising_edge(clk)  then

      --
      -- results w/7.0.3 : sig1 has a tristate output
      -- MATCH
      --
      sig1 <= ts_mux;

      --
      -- results w/7.0.3 : sig2 has a tristate output
      -- MISMATCH
      --   AND is optimized away, although it should resolve signal
      --
      sig2 <= ts_mux AND '1';

      --
      -- results w/7.0.3 : sig3 has a tristate output
      -- MISMATCH
      -- resolution function is apparently ignored
      --
      sig3 <= to_X01(ts_mux);

      --
      -- results w/7.0.3 : sig4 has a normal output
      -- MATCH
      -- Synplify can't optimize this AND away, so it works
      --
      sig4 <= ts_mux AND dummy;


      --
      -- create a big shift register for the next two signals
      --
      pipe <= pipe(PIPE_MSB-1 downto 0) & ts_mux;

      --
      -- results w/7.0.3 : sig5 has a tristate output
      -- MATCH
      -- lots of enable pipelining
      --
      sig5 <= pipe(PIPE_MSB);

      --
      -- results w/7.0.3 : sig6 has a normal output
      -- MATCH
      --
      sig6 <= pipe(PIPE_MSB) XOR pipe(7);

    end if;

    --
    -- try a FF with reset
    --
    if dummy = '0' then
      sig7 <= '0';

    elsif rising_edge(clk)  then
      --
      -- results w/7.0.3 : sig7 has a tristate output
      -- MATCH
      --
      sig7 <= ts_mux;

    end if;

  end process;


 --
 -- this pushthrough feature also affects combinatorial logic
 --
  sig8 <=  ts_mux when dummy = '0' else NOT ts_mux;

end arch1;

Article: 41280
Subject: Re: simple Free FPGA tool
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Mon, 25 Mar 2002 14:33:57 +0800
Links: << >>  << T >>  << A >>
Hi, Kevin:

I am not sure what kind of hobby project do you do? Do you have any
facilities to fabricate them out? I tend to like making some mp3 player or
motor control toys out of an FPGA chip but it seems impossible to make
into hardware as it's a lot of money when converted to my currency. I am
using ISE Webpack from Xilinx. Its really a great tool anyway.

--
Best Regards,
-----------------------------------------------------------------
Xu Qijun
Engineer
OKI Techno Centre (S) Pte Ltd
Tel: 770-7049 Fax: 779-1621
Email: qijun@okigrp.com.sg
"Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in
message news:a79cg2$orc$1@newsreader.mailgate.org...
> As an active ISE WebPACK 4.1 user, I don't find Altera's free tools as
> powerful as Xilinx's offerings because Altera doesn't offer a limited
> version of ModelSim like Xilinx does.
> Yes, ModelSim XE-Starter (The free version that comes with ISE WebPACK.)
> slows down after 500 lines of code, but it still lets the user run the
> simulator past 500 lines of code, and because it is an OEM version of
> ModelSim, it lets me run HDL testbench code.
> I personally find the slow down acceptable for my application.
> However, Altera offerings (Quartus II 2.0) only has a simple waveform
> simulator which lacks the ability to run HDL testbench code.
> Plus, Quartus II 1.1/2.0 Web Edition tends to be less reliable compared
> to ISE WebPACK 4.1 on Windows 98 PCs because QII tends to consume system
> resources heavily.
> Also, LeonardoSpectrum-Altera (LS-Altera) tends to be buggier compared
> to ISE WebPACK's synthesis tool XST (The latest 2002 version is somewhat
> better, but still has some problems, and I have to question Mentor
> Graphics' quality control. Do Mentor Graphics/Exempler Logic/Altera test
> LS-Altera before releasing it? It almost seems like they never test
> their products.)
> At least, I personally will like to see Altera letting users use a
> limited version of ModelSim AE (Altera Edition) for free, but until that
> happens, I recommend using ISE WebPACK + ModelSim XE-Starter for doing
> serious hobby projects with free tools.
> I am sure some die hard Altera fans won't appreciate my comments, but
> that is too bad because Altera's free tools are clearly inferior
> compared to Xilinx's offerings.
>
>
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)
>
>
>
> "arpit.desai" wrote:
> >
> > Jacky Renaux <renaux.jacky@wanadoo.fr> wrote in message
news:<2002319-12443-423681@foorum.com>...
> > > Try
> > >
http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack
> > > the free package is very powerfull , be sure you have a large disk
space
> > > and fast internet download access.
> > >
> > > regards
> >
> > Altera also has a free software package which is pretty powerful at:
> >
> >
https://www.altera.com/support/software/download/sof-download_center.html



Article: 41281
Subject: question on LFSR
From: anish@myrealbox.com (anish)
Date: 24 Mar 2002 22:57:22 -0800
Links: << >>  << T >>  << A >>
hi all,
  would be glad to know about effcient implmentation of LFSR of odd
length i.e not powers of 2 ...like 257 ...is it possible if so how...
thanks in advance 
anish

Article: 41282
Subject: Re: SystemC compiler
From: Eyck Jentzsch <jentzsch@cadence.com>
Date: Mon, 25 Mar 2002 08:01:07 +0100
Links: << >>  << T >>  << A >>
Use GNU V2.95.2 on Solaris or Linux

-Eyck

Article: 41283
Subject: Re: question on LFSR
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Mon, 25 Mar 2002 07:02:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <abc3b185.0203242257.1cf8a4ca@posting.google.com>,
anish <anish@myrealbox.com> wrote:
>hi all,
>  would be glad to know about effcient implmentation of LFSR of odd
>length i.e not powers of 2 ...like 257 ...is it possible if so how...
>thanks in advance 

All max period shift registers of size N have a length of (2^N) - 1.



-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 41284
Subject: Re: High speed clock routing
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 25 Mar 2002 08:33:49 +0000
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

<snip>

> 
> I was planning to do a simulation using the demo version of Hyperlynx. 
> But they no longer allow you to so ANY useful work.  This is one of my
> problems with demo software.  They want me to spend thousands of dollars
> of time to "evaluate" their product, but are not willing to let me get
> anything in return.  I feel it is very reasonable to let me accomplish
> some amount of work during the evaluation so that my time is not totally
> wasted if the product does not turn out to be something that I wish to
> pay thousands of dollars for.  
> 

I got a 30-day eval of the full Hyperlynx tool from them, for 30 days
I reckon,  They were very nice about extending it when I hadn't been
able to start the eval soon enough as well.  Delivered with manuals
(real paper!) and everything!

<snip>

> 
> >    a) Multipoint daisy chain. Works fine if the chips have extremely
> >       small input capacitance. Otherwise, much careful work must be done.
> >       If using a parallel termination resistor, place it AFTER the
> >       last IC.
> 
> Can you define what you mean by "extremely small input capacitance".  Is
> 10 pF small enough?  Is 5 pF small enough?  I don't think I remember
> ever seeing an input spec of 5 pF or less.  They are all about 6 to 12
> pF. 
> 

IIRC you are doing a C6711 design?  I did a C6711, two flash, two
SDRAM (ith two footprints each to accomodate 64MBit and 256MBit
devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-).  It ended up as
a daisy chain, with series ternminators on the FPGA datalines as its
edges were horrible.  The C6711 has (according to TI) been designed
with slower edges than the previos C6x family so it doens;t need
terminators as it is a low cost device - and that did seem to be the
case.

<snip>

HTH,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 41285
Subject: Re: SystemC compiler
From: Alan Fitch <alan.fitch@doulos.com>
Date: Mon, 25 Mar 2002 09:04:24 +0000
Links: << >>  << T >>  << A >>
In article <a7fafm$mg8$1@harrier.doc.ic.ac.uk>, Jacke <magz@citiz.net>
writes
>Hi, there
>Are there anyone know where I can find a free systemC compiler?
>or just convert systemC to verilog , VHDL is also acceptable.
>
>Thanks.
>
>

If you mean a tool that compiles the code, then use gcc and the free
SystemC library.

If you mean a synthesis tool, I'm not aware of a free SystemC synthesis
tool.

Alan
-- 
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                           Email: alan.fitch@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.









Article: 41286
Subject: Re: which is the fastest FPGA ?
From: "Le Mer Michel" <michel.lemer@sta.fr>
Date: Mon, 25 Mar 2002 10:49:40 +0100
Links: << >>  << T >>  << A >>
 Are these LVDS interfaces compatible with the FPGA LVDS ? Is there a demux
 problem ?


"Ray Andraka" <ray@andraka.com> wrote in message
news:3C9B2AE5.B02F842D@andraka.com...
> several that sample at well over 1GS/sec.  These seem to be mostly LVDS
> interfaces, mostly 8 bit.
>
> Hal Murray wrote:
>
> > >                                          An option for high data
> > >rate is to use a demux such as the Atmel TS81102G0 to break a high
> > >data rate ADC output stream into several parallel interleaved
> > >streams at rates the FPGA can easily handle.  We did this recently
> > >for a 960 MS/S FFT design.
> >
> > Wow!  Thanks for the info.
> >
> > I haven't been looking at ADCs recently.  How fast do they go
> > now?  What sort of signaling do the fast ones use?
> >
> > --
> > These are my opinions, not necessarily my employer's.  I hate spam.
>



Article: 41287
Subject: Re: Pipelined sorting algorithms...
From: Christopher.Saunter@durham.ac.uk (Christopher Saunter)
Date: Mon, 25 Mar 2002 11:17:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
Eric Crabill (eric.crabill@xilinx.com) wrote:

: Hi,

: I am looking to build a circuit for sorting small data sets,
: and am hoping someone here might have some pointers for where
: I should start looking for algorithms to do it.

: Every cycle, 16 pieces of data are provided as input.
: Some number of cycles later, the data set is provided
: at the output, sorted...

< stated elsewhere - 32 bit words, sorted off a nibble >

Hi,

I got thinking about sorting, and this is what I came up with.
It should sort data at high speed, and accepts all words in 
a single cycle in parallel, and spits them out in parallel,
sorted, a fixed number of cycles later.  I think with a bit
of effort in layout it would run very fast as well.  However,
it makes rather less efficient use of a Xilinx device than
the FIFO solution, as it uses flip-flops for data storage, not
LUTs.

Please lay into any problems it has, I'm out to learn!

---
The design consists of a number of pipeline stages, each of which
partially sorts the data by sorting pairs of values.

We have N words.  Conceptually these are split into N/2 pairs 
of words, each of which are sorted based on the 4 bit key.
This could be done with a 4 bit magnitude comparitor and two 2:1 
mux's - see my noddy diagram at
http://www.dur.ac.uk/christopher.saunter/sort1.bmp

So the first stage of the sorting pipeline is as follows:

w0 	>	larger (w0,w1) = v0
w1      >       smaller(w0,w1) = v1

w2 	>	larger (w2,w3) = v2
w3      >       smaller(w2,w3) = v3

w4      >       larger (w4,w5) = v4
w5      >       smaller(w4,w5) = v5

w6      >       larger (w4,w5) = v6
w7      >       smaller(w4,w5) = v7

The next stage is  similar, although it sorts pairs consisting of 
(v1, v2), (v3,v4), (v5,v6) and optionally (v0,v7) (I say optinally
- this sort of folds the flat rectangular shape of the pipeline
into a cylinder - I think doing this will save you one pipeline stage
but it might make getting a fast design out of P&R harder?)

So if we watch the effect of this on some worst case data...
e represents a sort of (w0, w1), (w2,w3) etc and o represents
a sort of (w1,w2), (w3,w4) etc:

  e   o   e   o   e   o   e
1 > 2 > 7 > 7 > 7 > 7 > 7 > 8
2 > 1 > 4 > 4 > 6 > 6 > 8 > 7
3 > 4 > 1 > 6 > 4 > 8 > 6 > 6
4 > 3 > 6 > 1 > 8 > 4 > 5 > 5
5 > 6 > 3 > 8 > 1 > 5 > 4 > 4
6 > 5 > 8 > 3 > 5 > 1 > 3 > 3
7 > 8 > 5 > 5 > 3 > 3 > 1 > 2
8 > 7 > 2 > 2 > 2 > 2 > 2 > 1


So if I have this right, you should be able to sort N words in
N-1 pipeline stages, requiring N(N-1) word registers.

You want 32 bit words, 16 words, so thats 32.16.15 = 7680 registers.
That's doable in larger devices.

If you can run the sorter faster that the data rate, then
you can time mux it, by reducing the number of stages and looping
datra back through it repeatedly.  Infact, using 3:1 mux's and a bit
of logic, you could probably reduce it to just one stage.
However, you said 100MHz clock...

This approach should sort data at a scary rate, although getting that much
data into and off the chip might be interesting....

Cheers,
	Chris Saunter



: The latency isn't a big issue, as long as it is constant,
: and I can provide a new data set to the circuit every cycle.

: Thanks,
: Eric

Article: 41288
Subject: Re: Xilinx Async Fifo trouble
From: "Phil Connor" <p.connorXXX@optionYYY.com>
Date: Mon, 25 Mar 2002 11:23:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
"BumsukLee" <bumsuklee@yahoo.com> wrote in message
news:%2Um8.182$bI1.911@news.hananet.net...

> Hello,
> 
> I am working on an asynchronous fifo (Xiliinx coregen 3.1) which uses
> separate clocks(both 100MHz) for read/write and getting read error or write
> error flag asserted when I simulate with various different phases between
> two clocks even though read enable ot write enable signal has enough setup
> time..
> 
> Any advice?

Hi,

You'll need to toggle ainit, then its quite a complex issue.

Pointers generated in different clock domains are a problem.

See page 17 of this execellent paper by Clifford Cummings.


http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf

However, I suspect Xilinx will have done the hard work for you. I've
found there is quite a lot of latency on the flag information so allow
plenty of time before you read them.

Hope this helps.

Phil


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

Article: 41289
Subject: Re: Maximum device usage for successful PAR
From: "S.H.McBader" <shm4@ukc.ac.uk>
Date: Mon, 25 Mar 2002 11:42:46 +0000
Links: << >>  << T >>  << A >>

Post-Map Timing Analysis reports that all timing constraints have been
met, in fact there's only one constraint and that is the clock period.
Device usage indicates that no resource has been estimated over 100%:

   Number of Slices:              6,489 out of  6,912   93%
   Number of Slices containing
      unrelated logic:                0 out of  6,489    0%
   Number of Slice Flip Flops:   10,169 out of 13,824   73%
   Total Number 4 input LUTs:     8,508 out of 13,824   61%
      Number used as LUTs:                      8,504
      Number used as a route-thru:                  4
   Number of bonded IOBs:            21 out of    158   13%
      IOB Flip Flops:                              10
   Number of Block RAMs:             32 out of     72   44%
   Number of GCLKs:                   1 out of      4   25%
   Number of GCLKIOBs:                1 out of      4   25%
   Number of DLLs:                    1 out of      8   12%
   Number of RPM macros:           32
Total equivalent gate count for design:  709,935
Additional JTAG gate count for IOBs:  1,056

And yes, it is the Placer which fails! Implementation never gets as far as
the routing process.. I get numerous warnings similar to:

WARNING:Place:78 - The SLICE component
   "totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579"
could not be placed.

Followed by errors similar to:

ERROR:Place:1613 - Design object
   (totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579)
could not be placed.

So it's neither a case of timing constraints not being met, nor one of
excessive usage of SLICEs or any other resources..

Still puzzling!

Stephanie McBader
Researcher/Design Engineer
NeuriCam S.p.A


Article: 41290
Subject: Re: Pipelined sorting algorithms...
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Mon, 25 Mar 2002 12:27:08 +0000
Links: << >>  << T >>  << A >>
In article <3C9BB6A0.B9DBB6C1@mail.com>, John_H <johnhandwork@mail.com>
writes

[a radix sort]
>Sounds like the best approach for the parts he's dealing with. 
[snip]

Radix sorts are good if the key is small (as is yours) but in the
general case of a larger key there are other hardware-friendly 
methods.

The classic source for this kind of material is Donald Knuth's
masterly work "The Art of Computer Programming"; volume 3 covers
sorting and searching.  He describes a method due to Batcher, which
Knuth calls "merge-exchange" sort.  It maps really nicely on to 
hardware because:
* it uses lots of instances of a single, simple logic element
  (compare two values, swap them if they're out of order)
* it is very pipeline-friendly;  the software algorithm
  naturally suggests a pipelined hardware implementation
* although it's fairly extravagant of hardware, as any
  fully-parallel sort is sure to be, it is not as expensive
  as some of the better known methods

I have a little C program that "designs" Batcher sorting
networks for arbitrary numbers of input words:  source code
by email on request!  Here's its output for a network to sort
six numbers into order.  The data comes in at the top and
falls out, sorted, at the bottom.  The "|-|-|-|-|-|" lines
represent places where a pipeline register could go.
Strings like "O======O" represent a compare/swap module.
The numbers on the left represent steps in the algorithm
given by Knuth, and use the same notation - they only make
sense if you read his description.

View this in a monospaced font!!!!
=========================================
  p,q,r,d =  4, 4, 0, 4  |-|-|-|-|-|
                         O=======O |
                         | O=======O
  p,q,r,d =  2, 4, 0, 2  |-|-|-|-|-|
                         O===O | | |
                         | O===O | |
  p,q,r,d =  2, 2, 2, 2  |-|-|-|-|-|
                         | | O===O |
                         | | | O===O
  p,q,r,d =  1, 4, 0, 1  |-|-|-|-|-|
                         O=O O=O O=O
  p,q,r,d =  1, 2, 1, 3  |-|-|-|-|-|
                         | O=====O |
  p,q,r,d =  1, 1, 1, 1  |-|-|-|-|-|
                         | O=O O=O |
  
  Sorted 6 elements using:
     6 levels of logic;
    12 compare/exchange modules.
=========================================
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 41291
Subject: Re: Pipelined sorting algorithms...
From: Christopher.Saunter@durham.ac.uk (Christopher Saunter)
Date: Mon, 25 Mar 2002 12:59:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
Okay, so playing around with my sugestion in a -4 virtex, it'll take a lot
of work to get it up to 100MHz.  I suppose the 100MHz data rate could be
split into 2x50MHz streams, processed in parallel.

Article: 41292
Subject: Re: synplify, quartus II 2.0
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Mon, 25 Mar 2002 15:36:57 +0100
Links: << >>  << T >>  << A >>
Maciek,

as far as I know, LeonardoSpectrum 2002a crashing after startup has to do
with the windows versions you're using, international or US.

Try to set the following Windows environment variable:

Name of the variable:     TZ
Value of the variable:        GST-1GDT

Regards
Wolfgang

"kudla" <kudla@fuw.edu.pl> schrieb im Newsbeitrag
news:a7d1lg$s3g$1@sunsite.icm.edu.pl...
> My Synplify (Leonardo Spectrum OEM2002a_Altera_NIGHTLY_14) crashes soon
> after start.
> (License passes - that I can see before window disapears). I have w2k sp2
> and Quartus II 2.0.
> Does somebody know what I can do?
> Maciek
>
>



Article: 41293
Subject: Re: Maximum device usage for successful PAR
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Mar 2002 14:39:05 GMT
Links: << >>  << T >>  << A >>
Sounds like the geometry of the 32 RPMs is such that the placer can't find a
suitable placement.  This is not uncommon when you have reasonably large RPMs,
or a fairly full device.  Try manually placing the RPMs with the floorplanner
and then letting the placer do the rest.

"S.H.McBader" wrote:

> Post-Map Timing Analysis reports that all timing constraints have been
> met, in fact there's only one constraint and that is the clock period.
> Device usage indicates that no resource has been estimated over 100%:
>
>    Number of Slices:              6,489 out of  6,912   93%
>    Number of Slices containing
>       unrelated logic:                0 out of  6,489    0%
>    Number of Slice Flip Flops:   10,169 out of 13,824   73%
>    Total Number 4 input LUTs:     8,508 out of 13,824   61%
>       Number used as LUTs:                      8,504
>       Number used as a route-thru:                  4
>    Number of bonded IOBs:            21 out of    158   13%
>       IOB Flip Flops:                              10
>    Number of Block RAMs:             32 out of     72   44%
>    Number of GCLKs:                   1 out of      4   25%
>    Number of GCLKIOBs:                1 out of      4   25%
>    Number of DLLs:                    1 out of      8   12%
>    Number of RPM macros:           32
> Total equivalent gate count for design:  709,935
> Additional JTAG gate count for IOBs:  1,056
>
> And yes, it is the Placer which fails! Implementation never gets as far as
> the routing process.. I get numerous warnings similar to:
>
> WARNING:Place:78 - The SLICE component
>    "totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579"
> could not be placed.
>
> Followed by errors similar to:
>
> ERROR:Place:1613 - Design object
>    (totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579)
> could not be placed.
>
> So it's neither a case of timing constraints not being met, nor one of
> excessive usage of SLICEs or any other resources..
>
> Still puzzling!
>
> Stephanie McBader
> Researcher/Design Engineer
> NeuriCam S.p.A

--
--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: 41294
Subject: Re: which is the fastest FPGA ?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Mar 2002 14:42:21 GMT
Links: << >>  << T >>  << A >>
Depends, some may not be. Please refer to the data sheets for the FPGA and the
ADC or demux.

Le Mer Michel wrote:

>  Are these LVDS interfaces compatible with the FPGA LVDS ? Is there a demux
>  problem ?
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C9B2AE5.B02F842D@andraka.com...
> > several that sample at well over 1GS/sec.  These seem to be mostly LVDS
> > interfaces, mostly 8 bit.
> >
> > Hal Murray wrote:
> >
> > > >                                          An option for high data
> > > >rate is to use a demux such as the Atmel TS81102G0 to break a high
> > > >data rate ADC output stream into several parallel interleaved
> > > >streams at rates the FPGA can easily handle.  We did this recently
> > > >for a 960 MS/S FFT design.
> > >
> > > Wow!  Thanks for the info.
> > >
> > > I haven't been looking at ADCs recently.  How fast do they go
> > > now?  What sort of signaling do the fast ones use?
> > >
> > > --
> > > These are my opinions, not necessarily my employer's.  I hate spam.
> >

--
--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: 41295
Subject: Re: Too many clocks
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Mar 2002 14:45:29 GMT
Links: << >>  << T >>  << A >>
A better way to handle those slow clocks is to bring them in on regular I/O
through a register clocked by your local master clock (typically many times
faster than the slow clock), then detect the edges of the slow clock
synchronously to create clock enables for the data 'clocked' by the slow clock.

Niv wrote:

> I have a design with more than 4 clocks, the Virtex max., (but some are very
> slow, < 1MHz).
>
> LeoSpec insists on putting BUFG's on all the clocks, which causes Xilinx PAR
> to throw a wobbler.
>
> The design now has a 40MHz master clk into a CLKDLL, which produces 2
> internal clocks with BUFG's, which is wanted, and 4 other clocks, only 2 of
> which need BUFG's.  The other 2 clocks are low freq. and low fanout.
>
> The old design worked fine with 6 external clks; LeoSpec just sorted it out
> somehow;  But now with 5 external clks, the master one to a DLL, it all goes
> to pot!
>
> Anyone got any bright ideas please?
>
> i.e. How do I force some of my clocks NOT to use BUFG's & IBUFG's,  just use
> IBUF's instead?
>
> TIA, Niv.

--
--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: 41296
Subject: Re: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 25 Mar 2002 10:17:03 -0500
Links: << >>  << T >>  << A >>
Martin Thompson wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> 
> <snip>
> 
> >
> > I was planning to do a simulation using the demo version of Hyperlynx.
> > But they no longer allow you to so ANY useful work.  This is one of my
> > problems with demo software.  They want me to spend thousands of dollars
> > of time to "evaluate" their product, but are not willing to let me get
> > anything in return.  I feel it is very reasonable to let me accomplish
> > some amount of work during the evaluation so that my time is not totally
> > wasted if the product does not turn out to be something that I wish to
> > pay thousands of dollars for.
> >
> 
> I got a 30-day eval of the full Hyperlynx tool from them, for 30 days
> I reckon,  They were very nice about extending it when I hadn't been
> able to start the eval soon enough as well.  Delivered with manuals
> (real paper!) and everything!
> 
> <snip>
> 
> >
> > >    a) Multipoint daisy chain. Works fine if the chips have extremely
> > >       small input capacitance. Otherwise, much careful work must be done.
> > >       If using a parallel termination resistor, place it AFTER the
> > >       last IC.
> >
> > Can you define what you mean by "extremely small input capacitance".  Is
> > 10 pF small enough?  Is 5 pF small enough?  I don't think I remember
> > ever seeing an input spec of 5 pF or less.  They are all about 6 to 12
> > pF.
> >
> 
> IIRC you are doing a C6711 design?  I did a C6711, two flash, two
> SDRAM (ith two footprints each to accomodate 64MBit and 256MBit
> devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-).  It ended up as
> a daisy chain, with series ternminators on the FPGA datalines as its
> edges were horrible.  The C6711 has (according to TI) been designed
> with slower edges than the previos C6x family so it doens;t need
> terminators as it is a low cost device - and that did seem to be the
> case.

I am a little confused by what you said.  You say that the edge rates on
the C6711 seem to be slower than other C6x chips, and yet you say that
you needed terminators since the edges were horrible.  I don't
understand.  Did you mean that the C6711B was redesigned?  

-- 

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: 41297
Subject: Re: Missing Timing by 30,000 ns
From: Goran Bilski <goran.bilski@xilinx.com>
Date: Mon, 25 Mar 2002 08:10:41 -0800
Links: << >>  << T >>  << A >>

--------------8FBC77CCF5844D6EAD5B8E9E
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Kevin,

Glad I could help.

I'm not sure why it wasn't fixed in 4.2, probably because it was not an
easy fix.
The period has to be non-integer and with a lot of decimal digits. I
think that the problem is due
to rounding errors with floating point calculations.

I'm told that it will be fixed in our next major release.

G=F6ran

Kevin Neilson wrote:

>  Goran,You're right... I thought this didn't work because I changed
> the period in the UCF to an integer and saw no difference but forgot
> that I had a period constraint in the NCF too so I just deleted the
> NCF. Thanks a lot... you save me a lot of time. But since you're from
> Xilinx maybe I can complain a bit... how come I have version 4.2 and
> this problem still persists?  Am I the only person that uses
> noninteger periods? -Kevin
>
>      "Goran Bilski" <goran@xilinx.com> wrote in message
>      news:3C99089E.57DA27B5@xilinx.com...Hi,
>
>      I actually run in to this problem a little while ago.
>      The reason for the huge timing delays is when you are using
>      DLL and has a clock period constraint that
>      has many decimals. I think that there are some rounding
>      errors in the timing tools.
>      So just change your clock period to 41 ns and the problem
>      should go away
>
>      G=F6ran
>
>
>      Kevin Neilson wrote:
>
>     > All,I keep running into this problem all the time in which
>     > I have a route that misses my constraint by tens of
>     > thousands of nanoseconds.  I'm using the Xilinx 4.1 PAR
>     > tools.  In this case the bad paths are ones that cross
>     > from a domain with a 20ns period to a domain with a 10ns
>     > period.  The faster domain is generated from a DLL locked
>     > to the first, so while it is twice the freq, it is
>     > synchronous to the first.  I'm taking care to read data in
>     > the second domain only on "even" cycles of the first
>     > domain, so the data has 20ns to get from the slow domain
>     > to the fast.The first evidence of a problem comes during
>     > routing: End of iteration 1
>     > 22869 successful; 0 unrouted; (152088) REAL time: 5 mins
>     > 34 secsYou've all cringed at seeing this message before.
>     > Then, in the PAR summary, I see
>     > this:------------------------------------------------------------=
--------------------
>     >
>     > * PERIOD analysis for net "clk_management/f | 10.416ns   |
>     > 38591.280ns | 4
>     >   irclk_dcm_clk2x" derived from  NET "clk_m |
>     > |            |
>     >   anagement/CLK_ibufg" PERIOD =3D  41.667 nS  |
>     > |            |
>     >     HIGH 50.000000 %                        |
>     > |            |
>     >
>     > -----------------------------------------------------------------=
--------------This
>     > is obviously a problem:  my constraint for the fast clock
>     > domain is 10.4ns, and one path requires 38591ns, meaning I
>     > need to slow my clock to the kilohertz range. Here's the
>     > detail from
>     > Trace:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DTiming
>     > constraint: PERIOD analysis for net
>     > "clk_management/firclk_dcm_clk2x" derived from NET
>     > "clk_management/CLK_ibufg" PERIOD =3D 41.667 nS   HIGH
>     > 50.000000 % ; divided by 2.00 and duty cycle corrected to
>     > 10.416 nS  HIGH 5.208 nS  29336 items analyzed, 58 timing
>     > errors detected. Minimum period is
>     > 38591.280ns.-----------------------------------------------------=
---------------------------Slack:
>     > -3.704ns (requirement - (data path - negative clock
>     > skew))  Source:               dpll/theta[12]
>     > Destination:          fir/phase_reclock[5]
>     > Requirement:          0.001ns  Data Path Delay:
>     > 3.705ns (Levels of Logic =3D 4)  Negative Clock Skew:
>     > 0.000ns  Source Clock:         sclk rising at
>     > 216975.695ns  Destination Clock:    firclk rising at
>     > 216975.696ns  Data Path: dpll/theta[12] to
>     > fir/phase_reclock[5]    Location             Delay
>     > type         Delay(ns)  Physical
>     > Resource
>     > Logical Resource(s)
>     > -------------------------------------------------
>     > -------------------    SLICE_X57Y32.YQ
>     > Tcko                  0.568
>     > theta[13]
>     > dpll/theta[12]    SLICE_X54Y33.F1      net
>     > (fanout=3D3)        0.551   theta[12]
>     > SLICE_X54Y33.COUT    Topcyf                0.769
>     > fir/phase_reclock[2]
>     > fir/phase_reclock_qxu[2]
>     > fir/phase_reclock_cry[2]
>     > fir/phase_reclock_cry[3]    SLICE_X54Y34.CIN     net
>     > (fanout=3D1)        0.000   fir/phase_reclock_cry[3]/O
>     > SLICE_X54Y34.Y       Tciny                 1.446
>     > fir/phase_reclock[4]
>     > fir/phase_reclock_cry[4]
>     > fir/phase_reclock_s[5]    SLICE_X54Y34.DY      net
>     > (fanout=3D1)        0.001   fir/phase_reclock_s[5]
>     > SLICE_X54Y34.CLK     Tdyck                 0.370
>     > fir/phase_reclock[4]
>     > fir/phase_reclock[5]
>     > -------------------------------------------------
>     > ---------------------------
>     > Total                                      3.705ns
>     > (3.153ns logic, 0.552ns
>     > route)
>     > (85.1% logic, 14.9%
>     > route)-----------------------------------------------------------=
---------------------This
>     > is just whack.  You can see that the path delay is 3.7ns,
>     > which easily meets the 20ns period of the slow clock
>     > (sclk).  However, for some reason it thinks the source
>     > clock is sclk rising at 216975ns.  Where did that come
>     > from?  And how did it get a slack of -3.704ns?  Also,
>     > where did the 38591ns period in the PAR summary come
>     > from?  That's not even close to 216975. This path really
>     > shouldn't be analyzed at all.  The Xilinx answer files
>     > state that 4.1i doesn't analyze paths that cross clock
>     > domains.  Sometimes when I see this problem, I can "fool"
>     > PAR by putting a FROM-TO in the UCF that explicity states
>     > that paths from the "sclk" domain to the "firclk" domain
>     > have 20ns.  However, this isn't working now, and Trace
>     > claims that 0 items are analyzed using that TIMESPEC, even
>     > though there are obviously many paths that fit that
>     > description.Has anybody else seen this?-Kevin
>



Article: 41298
Subject: Xilinx 4.2i not working on my design
From: "David Frith" <david.frith@ffei.co.uk>
Date: Mon, 25 Mar 2002 16:22:00 -0000
Links: << >>  << T >>  << A >>
Hello all

I've just loaded on ISE 4.2i and the first design I ran through gives me an
error at ngdbuild. This is with exactly the same input files as 4.1i which
works fine. I've reproduced the error log below but, to me, this looks like
something is broken in the software or it hasn't installed properly, not
something wrong with the input files as I can switch back to 4.1i and route
the design fine. I'm still waiting for euroapps support to get back to me so
I thought I try the experts here.

(The design comes from Leonardo and contains an edf and an ncf file as the
main input files, several edn files from coregen as well as the ucf file.)

ERROR:NgdBuild:669 - A parsing error has occurred at line 0 while reading
lsb_opif.ucf. The value is .
ERROR:NgdBuild:31 - Errors found while parsing .ucf file "lsb_opif.ucf".
Please
check for syntax errors in the UCF file. For more information on legal UCF
constraints, please see the Constraints Guide for more information on this
attribute.


I've tried re-installing to no avail. I've also tried an empty ucf file
(just comments) but this makes ngdbuild Dr Watson. It's interesting how the
error above is on line 0!

Running the design through 4.1i has no problems like this whatsoever.

Does anyone know if any of the system dll's need updating with this new
release?

Thanks and regards

David Frith             Fujifilm Electronic Imaging
Principal Engineer         Hemel Hempstead, Herts
david.frith@ffei.co.uk         +44 1442 343083




Article: 41299
Subject: Re: Missing Timing by 30,000 ns
From: fpgaguy@aedinc.net (Jason Daughenbaugh)
Date: 25 Mar 2002 08:38:45 -0800
Links: << >>  << T >>  << A >>
> But since you're from Xilinx maybe I can complain a bit... how come I 
> have version 4.2 and this problem still persists?  Am I the only person 
> that uses noninteger periods?

No, you are not the only one.

I have seen this problem many times since I upgraded to 4.1i.  

Xilinx support pointed me to answer #12174.

It is for Virtex2 DCM's, but he said that the problem also exists for
Vitex/spartan-2 DLL's.

A agree that it is a little dissappointing that has not been fixed in
any service pack or 4.2i, especially since it has apparently bitten
several engineers and they have known about it for a while (I
contacted them in December / January, and he told me that it is a
"known issue.")  Hopefully it will be fixed in the next service pack? 
But answer 12174 does not seem to indicate any plan to fix it.

It is almost comical to see the report say that something with two
logic levels can only run at 33kHz in a Spartan-2 FPGA.  Seems like
something Xilinx would like to avoid...

Jason Daughenbaugh
http://www.aedinc.net



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