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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 40775

Article: 40775
Subject: Re: the server to access to this newgroup
From: "Topo Gigio" <luigi.adorni@raytecvision.com>
Date: Fri, 15 Mar 2002 09:53:18 +0100
Links: << >>  << T >>  << A >>

"Sniper Daryl" <e-engineer@eastday.com> ha scritto nel messaggio
news:289dc5a9.0203132210.32599f08@posting.google.com...
> if anyone would tell me how to set in Outlook Express

You need to set a new account for the News (Tools -> Account -> create a new
account -> News.)
Type the name and your mail address for the direct answers.
There are more than one server available that contains this newsgroup: I
normally use news.interbusiness.it

Bye
Luigi




Article: 40776
Subject: Re: DES implementation in Handel C
From: "John" <jmn122@hotmail.com>
Date: Fri, 15 Mar 2002 09:32:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
"Saurabh Pal" <saupal@indiatimes.com> wrote in message
news:62ef09ee.0203130229.16e82dc4@posting.google.com...

> Hi !
> 
> Can anyone tell whether the source code of DES implementation in
> Handel C is available publically or not.
> 
> Thanks in advance.
> 
> Saurabh

Saurabh

Try http://www.celoxica.com/3des/3des.htm, 
the white paper contains code snippets.

John




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

Article: 40777
Subject: Re: Spartan-XL, SpartanII and Spartan-IIE bitstream format question ...
From: acher@in.tum.de (Georg Acher)
Date: 15 Mar 2002 10:24:22 GMT
Links: << >>  << T >>  << A >>
In article <3C91A458.D7CFE85F@algor.co.uk>,
 Rick Filipkiewicz <rick@algor.co.uk> writes:

|> I don't know why you'd want to do this but the answer, for
|> Virtex/Virtex-E and Spartan2 parts is yes. In fact if you look at the
|> bit stream produced by the Xilinx s/w for these devices you'll probably
|> see an initial 32 1's before the sync word.

If you want to independently program two chips with only 5 wires (2*program,
1*clk, 2*din), it is quite useful that clocking in ones doesn't disturb the
other chip. If everything works, you can program the chips in parallel...

-- 
         Georg Acher, acher@in.tum.de         
         http://www.in.tum.de/~acher/
          "Oh no, not again !" The bowl of petunias          

Article: 40778
Subject: Re: Virtex BUFGDLL
From: "H.L" <alphaboran@yahoo.com>
Date: Fri, 15 Mar 2002 15:32:20 +0200
Links: << >>  << T >>  << A >>
Hello,
thanks a lot! With your suggestion to have a look at FPGA Editor I don't
have to instantiate the DLL,IBUFG and BUFG separately. By default the RST
pin of BUFGDLL is '0'.

Best Regards,
Harris


"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
news:a6qskv$gikto$2@ID-84877.news.dfncis.de...
> "H.L" <alphaboran@yahoo.com> schrieb im Newsbeitrag
> news:a6pkdl$2fh6$1@ulysses.noc.ntua.gr...
> > Hello all,
> > I use a BUFGDLL in a Virtex-E FPGA to succeed a proper distribution of a
> > clock (155MHz). I instantiate BUFGDLL in my code and I did the port map.
> In
> > this way I have not access to the RST pin of the DLL (I want to set it
'0'
> > as xilinx suggests). I checked that DLL's CLKIN,CLKFB and CLK0 pins are
OK
> > but I cant check if the RST pin is '0' by default. How can I check if
the
> > RST pin is grounded or not?
>
> Have a look at the design in FPGA editor. OR just instanciate the DLL and
> BUFG seperately, which is saver, since it gives you access to the reset
> (just in case)
>
> --
> MfG
> Falk
>
>
>
>



Article: 40779
Subject: Re: Spartan-XL, SpartanII and Spartan-IIE bitstream format question ...
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Mar 2002 09:11:23 -0500
Links: << >>  << T >>  << A >>
Georg Acher wrote:
> 
> In article <3C91A458.D7CFE85F@algor.co.uk>,
>  Rick Filipkiewicz <rick@algor.co.uk> writes:
> 
> |> I don't know why you'd want to do this but the answer, for
> |> Virtex/Virtex-E and Spartan2 parts is yes. In fact if you look at the
> |> bit stream produced by the Xilinx s/w for these devices you'll probably
> |> see an initial 32 1's before the sync word.
> 
> If you want to independently program two chips with only 5 wires (2*program,
> 1*clk, 2*din), it is quite useful that clocking in ones doesn't disturb the
> other chip. If everything works, you can program the chips in parallel...

Or how about if you use 1*program, 1*din and 2*cclk?  This is fewer pins
and you don't have to do anything special on the din of the unclocked
chip.  Of course you will need two program pins of you want to program
just one and not the other.  

-- 

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: 40780
Subject: VHDL:Problem with depuncturing unit
From: Stefanos <stxe@intranet.gr>
Date: Fri, 15 Mar 2002 06:18:03 -0800
Links: << >>  << T >>  << A >>
I have a little problem with a depuncturing unit I am currently building.It is supposed to support 3 code rates (1/2,2/3,3/4).When I implemented only one code rate,everything was fine.When I added a second,everything crumbled.The output data isn't displayed properly,but not always.Sometimes the first bits are wrong ,but sometimes they show up just as they should.I am pasting my code and hope some of you will discern quickly my mistakes.Any help deeply appreciated.
Thanks in advance
Code :
Library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

--============================================================*
--* Test 1/2  - Use of d_val /register input/ Create Counter***
--============================================================*
-- ==           xanei ta case 1 outputs kai pairnei to    ====*
--                  case others,alla oxi panta            ====*
-- ===               15.3.2002                            ====*         
--============================================================*
Entity test_2cases is
port (
       clock	: in std_logic; -- rising edge
       reset	: in std_logic; -- active low
       sel	: in std_logic; --select code rate
       data_in	: in std_logic_vector(23 downto 0);
       dval_in	: in std_logic; -- Input data valid flag 
       data_out	: out std_logic_vector(5 downto 0); 
       dval_out	: out std_logic
       );
       end test_2cases;
       
   Architecture test of test_2cases is
   signal data_input_register	:std_logic_vector(23 downto 0);
   signal c5value		:integer range 0 to 5;--temporary counter5 value
   signal counter_5_out		:integer range 0 to 5;--counter 5 output
   signal counter_5_enable	:std_logic; -- counter 5 enable flag
   signal i5_dval_out		:std_logic;--counter 5 output data valid
   signal dvalid_in_r		:std_logic; -- data valid register
   signal counter_6_out		:integer range 0 to 6;-- counter 6 output
   signal counter_6_enable	:std_logic; -- counter 6 enable flag
   signal i_data_out  		:std_logic_vector(5 downto 0); -- temporary output value
   signal c6value		:integer range 0 to 6; -- temporary counter6 value
   signal i6_dval_out		:std_logic; -- output valid flag of counter 6
   signal ii_dval_out		:std_logic; -- output valid flag 
   
   
   
   begin
  	 counter_6_enable<='1' when sel='0' and (dval_in='1' or c6value /=0) else '0';-- enable code rate 3/4
	 i6_dval_out<='1' when counter_6_out/=0 else '0';
	 counter_5_enable<='1' when sel='1' and (dval_in='1' or c5value /=0) else '0';--enable code rate 2/3
	i5_dval_out<='1' when counter_5_out/=0 else '0';
	ii_dval_out<='1' when (i5_dval_out='1' or i6_dval_out='1') else '0';
	
   -- Register input data--
   					register_input	 :process (clock,reset)
   	begin
   			if reset='0' then
   data_input_register<=(others=>'0');
   			elsif rising_edge(clock) then
   			if (dval_in='1') then
   data_input_register<=data_in;
   		else 
   data_input_register<=data_input_register ;
   		end if ;
   	end if ;
   					end process register_input ;
   
-- COUNTER 5 OUTPUT PROCESS ---
					counter_5	:process(clock,reset)
	
	begin
			if reset='0' 
		then c5value<=0;
	elsif rising_edge(clock) then
			if c5value=5 then
	c5value<=0;
			elsif counter_5_enable='1' then
	c5value<=c5value+1;
		else 
			c5value<=c5value;
	end if;
	end if;
					end process counter_5;
	counter_5_out<=c5value;
   
-- COUNTER 6 OUTPUT PROCESS---
   					counter_6 	: process(clock,reset)

	begin	
				if reset='0'
 			then c6value<= 0;
  		 elsif rising_edge(clock) then 
   	if c6value =6 then
   	c6value<=0;
   		elsif counter_6_enable='1' then
   	c6value<=c6value+1 ;
   		else
   	c6value<=c6value;
   	end if;
   	end if;
   					end process counter_6;
  
   	 counter_6_out<=c6value; 	
   	
   	-- Depuncturing process --
   					Depunct2	:process(clock,reset) 
   		begin
   				if reset='0'  then
   		   i_data_out<=(others=>'0');
  

Article: 40781
Subject: Re: VHDL:Problem with depuncturing unit
From: Stefanos <stxe@intranet.gr>
Date: Fri, 15 Mar 2002 06:20:28 -0800
Links: << >>  << T >>  << A >>
Sorry about this!!! Apparently it is not readable..

Article: 40782
Subject: Re: Spartan-XL, SpartanII and Spartan-IIE bitstream format question ...
From: acher@in.tum.de (Georg Acher)
Date: 15 Mar 2002 15:18:15 GMT
Links: << >>  << T >>  << A >>
In article <3C92010B.8EB00E4B@yahoo.com>,
 rickman <spamgoeshere4@yahoo.com> writes:

|> > If you want to independently program two chips with only 5 wires (2*program,
|> > 1*clk, 2*din), it is quite useful that clocking in ones doesn't disturb the
|> > other chip. If everything works, you can program the chips in parallel...
|> 
|> Or how about if you use 1*program, 1*din and 2*cclk?  This is fewer pins
|> and you don't have to do anything special on the din of the unclocked
|> chip.  Of course you will need two program pins of you want to program
|> just one and not the other.  

For development this may be a bit inconvenient (at least IMHO). And if you care
about faster startup time for the whole system, the 2*din is also a nice to have.

-- 
         Georg Acher, acher@in.tum.de         
         http://www.in.tum.de/~acher/
          "Oh no, not again !" The bowl of petunias          

Article: 40783
Subject: PCI design in a Spartan II which crashes in some wintel PCs
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Fri, 15 Mar 2002 10:28:18 -0500
Links: << >>  << T >>  << A >>
Hello,

I have designed my own PCI logic for a target board.(33/32) It works in the
majority of wintel PCs but crashes in a significant number of PCs.

I have implemented a design in a Xilinx PCI proto board made by Insight.
This way I can assume that the PCB fabrication is sound.

I feel the problem comes down to the way TRDY# and DEVSEL# are being driven.
This is the logic that must be improved.

The crashing occurs with reads. With my exisiting logic one motherboard may
crash while another is ok. On a motherboard that is ok, the addition of a
certain 3rd party PCI card will then result in  crashes. The logic I have
must be on the verge of being PCI compliant. I expect that one little tweak
should be enough to clear up all my problems.

In tracking down the problem I have removed more and more logic to simplify
the design and to narrow in on the cause. Almost all the logic is now gone.
All that remains is:

OUTPUTS:
TRDY#
DEVSEL#

INPUTS:
FRAME#
IRDY#
AD[31:00]
C/BE[3:0]#
CLK

In this stripped down implementation there are no bursts, no parity, no
master logic, no configuration space ( which is not needed to effect
reads/writes if you know of a conflict free address, which I do for test
purposes )
The logic is very simple. When a read or write is decoded I take DEVSEL#
active low, followed by TRDY#. When IRDY# is seen low I release TRDY# and
DEVESEL# on the next clock.(wintels do not do burst reads so I know FRAME#
will indicate a single data phase cycle)  This complete test is a trivial
and small piece of logic. ( For anyone designing their own PCI logic this is
an excellent first step to try. Once this works then you would go on to add
other features.)  Note that I am not even driving AD[31:00] on the reads. So
the only PCI signals that I drive in response to a decoded PCI read in my
address space is DEVSEL# and TRDY#.

When a crash occurs it happens on a read but not every read so as you can
see this is erractic.
Note: all PCI input and output signals are clocked.

My schematics will be provided to anyone who requests them.

Is there anyone out there who has gone down this road designing their own
PCI logic for a FPGA ? Come on over. I have a plane ticket for you. Name
your price.

Sincerely
Daniel DeConinck
www.PixelSmart.com
TEL: 416-248-4473



Article: 40784
Subject: Re: Xilinix FPGA with 5V IO
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 15 Mar 2002 07:29:50 -0800
Links: << >>  << T >>  << A >>
Rick,

The Quickswitches won't drop the overshoot much (if at all) so you need to simulate
it to be sure you are really limiting the current to the input structure (the
parasitic diode to Vcco).  Of course, this isn't an easy IBIS sim, this requires
something like spice, which means that you need the IO model in spice, or use the
latest Avanti Hspice which accepts IBIS models as .model statements.

The Quickswitch really works well to eliminate the undershoot.

I don't know if Cadence SpectraQuest ACE accepts devices like the Quickswitch, but
it would be nice if it did.  I don't know if Hyperlynx can do it, as it requires
modeling of the series nmos transistor (not something in their library of
components!).

Also, if you simulate it (the input to the FPGA), and you see that the current into
the input pin is less than 10 mA, then you don't need any resistor at all.  Many 5V
drivers in cmos use stacked nmos transistors, because they can be faster, and meet
TTL levels without having to pull all the way to 5V.  Even the devices that are cmos
in their outputs, may have really weak pullups, as with TTL, the pullup is ten times
weaker than the pulldown.

Virtex II is also "5V compatible" when the current into the pin is less than ~ 10 to
12 mA, so the 100 ohms works for Virtex II, too.

Austin



Rick Filipkiewicz wrote:

> Falk Brunner wrote:
>
> > "Martin Sauer" <msauer@gmx.net> schrieb im Newsbeitrag
> > news:a6pqk7$cpa$06$1@news.t-online.com...
> > > Hello,
> > >
> > > one question: Is it possible to connect a 5V IO Device direct to the
> > Xilinx
> > > Virtex FPGA series?
> >
> > Yes.
> > The Virtex inputs (as well as Spartan-II) are 5V tolerant. You can also
> > drive a 5V device with the 3.3V IO of the Virtex, when the 5V device has TTL
> > inputs (1.4V switching level)
> >
> > Virtex-E/Spartan-IIE/Virtex-II are NOT 5V tolerant. But you can add
> > tolerance using a 100Ohm series resistor. But this will influence timing.
> >
>
> Or, if board area and cost permit, use some QuickSwitch style parts to do the
> level translation. These are just a bunch of FETs whose on resistance is very
> low (5-10R) until the driving signal gets to about 0.7V below its power pin,
> when it starts increasing rapidly. I think, for something like PCI, this is much
> less intrusive than a bunch of 100Rs.
>
> We tend to still use the QS3245 or Pericom equivalent but with the VCC Zener'ed
> down to 3.9V, or even connected to the 3.3V supply.


Article: 40785
Subject: Re: Proto boards for labs
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Fri, 15 Mar 2002 16:37:09 +0100
Links: << >>  << T >>  << A >>
Nitin,

you might want to consider a DIGILAB 1Kx208 board.

It has an Altera EP1K100QC208-1 chip on it together with FLASH, RAM and an
on-board 18-bit stereo AC97 DSP Codec. It supports Altera's NIOS embedded
processors as well as Altera's FIR and IIR compiler. You could either use
the free MAX+plus II (Baseline) or Qartus II (Webedition) tools.

Check: http://www.elca.de/Products/prod%20d1kx208e.html

You might also check the Altera University program at:
http://www.altera.com/education/univ/unv-index.html
for full versions of the tools, a NIOS licenses and licenses for the FIR,
IIR or FFT compilers.

- Wolfgang

"Nitin Chandrachoodan" <nitin@eng.umd.edu> schrieb im Newsbeitrag
news:1103_1016120744@news.glue.umd.edu...
>
> Hello,
>
> We are trying to decide on boards for use in a course in the
> Electrical Engg. department at our university. The
> requirements we have come up with so far are as follows:
>
> 1. Easy to get started and working with it.
> 2. Relatively inexpensive
> 3. Can be used to implement reasonably large designs,
> especially DSP filters, FFTs etc. Here  we would like to
> implement the designs without having to go to too much low-
> level optimization (bit-serial implementations etc.) unless
> absolutely necessary, as this would change the focus from
> learning about FPGA implementation to low-level design.
> 4. Can be used with existing tools (we have Synopsys DC and
> FPGA compiler II, so we would prefer not to have to purchase
> Foundation etc. unless necessary)
>
> It seems that the Xilinx Spartan chips can be used with the
> Webpack which is free, and they also have very large
> capacities (100k-200k for XC2S200). Two boards I have found
> so far with these are
>
> 1. XESS XSA-100 (100k gate, $279) from xess.com
> 2. Digilab XLA 2 (XC2S200 Spartan II - 200k gates, $99) from
> digilentinc.com
>
> The digilent board seems to have better features at a lower
> price, but XESS appears more popular overall. Are there any
> other compelling reasons for using one or the other?
>
> Alternately, are there any other boards that are especially
> suited to classroom use? Apart from basic use in a classroom
> setting, we are also interested in boards that can be used
> for rapid reconfiguration etc., for use in research into
> reconfigurable computing techniques.
>
> Any replies much appreciated.
>
> Thank you,
>
> Nitin
>
>



Article: 40786
Subject: 18X18, oh the possibilities!
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 15 Mar 2002 07:42:30 -0800
Links: << >>  << T >>  << A >>
Pete,

As with any new feature, it took careful characterization by the team to
verify the performance of all of the features.  The multipliers are especially
tough, as there are not just 2E36 possibilities, but the previous multiplier
and multiplicand affect the speed of the result of the subsequent multiplier
and multiplicand.... or 2E72.

Now think about it.  2E72 = 4.722E21 possibilities.  At a test rate of 1E8
(optomistically) per second, that is 1.5 million years.  Talk about job
security!  But seriously, we have to get smart about the testing, and cover
all of the possibilities.

Various tweaks, and minor changes, and the speed in the faster speed grade
parts is as stated in the latest speed files, and meets our original goals.

The probablity that you would find the slow combination is the inverse of the
possibility, or ~.5E-21, which is about the probablity of the earth falling
into a black hole in the next year, so I hope there are those who appreciate
the trouble that the Xilinx characterization team goes to, and the quality
level that we strive to achieve when we test a new part.

To press the point, if it was an ASIC, or ASIC IP, you would never know it was
broken until your customers started to hammer you.

Austin


Pete Fraser wrote:

> "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> news:3C90C799.E64C72C2@xilinx.com...
>
> > Virtex E was a shrink to 0.18u of the classic Virtex architecture and
> > circuitry.  Virtex E added LVDS input buffers to the original Virtex
> > design, but little else was changed.
> >
> > Virtex II was a complete redesign in 0.15u at 1.5V for the core, that
> > extended the reach of the interconnect, and buffered virtually all paths
> > to reduce loading effects.  The CLB had more features added (more LUT
> > RAM modes, SRL modes), as well as the horizontal carry (useful for
> > p-terms).  The block RAMS got bigger, and there are more of them (4K vs
> > 18K), as well as having three read/write modes instead of one in
> > addition to a 18X18 multiplier in each BRAM block.
>
> Hi Austin.
>
> The multipliers were hella fast when the spec first came out,
> and have gradually crept down in speed as new "improved"
> speed files have been issued. Are you working on getting
> the multipliers back to their original hoped-for speed, or will
> we have to wait for the next family?


Article: 40787
Subject: Re: exceeding 2GB limits in xilinx
From: "Peter Dudley" <pdudley1@comcast.net>
Date: Fri, 15 Mar 2002 16:06:31 GMT
Links: << >>  << T >>  << A >>
There ought to be some way to use the fpga fabric itself for place and route
acceleration. Is there any research in this area?


"Petter Gustad" <newsmailcomp1@gustad.com> wrote in message
news:m3ofi07olz.fsf@scimul.dolphinics.no...
> "Peter Ormsby" <faepete.deletethis@attbi.com> writes:
>
> > Lars Rzymianowicz <larsrzy@atoll-net.de> wrote in message
> > news:3C85C76F.3B5FA1A5@atoll-net.de...
> > > And since Xilinx and most other EDA vendors support Linux now, why
> > > step down to the bluescreen?
> >
> > Just to be clear here, the Xilinx Linux solution is currently limited to
> > command-line only on WINE.  For those unfamiliar with this approach,
check
> [...snip...]
>
> Does anybody know why Xilinx did this rather than porting their
> Solaris/HP-UX version to Linux?
>
> Petter
> --
> ________________________________________________________________________
> Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com
>



Article: 40788
Subject: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Mar 2002 12:42:47 -0500
Links: << >>  << T >>  << A >>
I need to plan a high speed bus that will connect 5 devices.  They will
all be very closely spaced so that the lengths of the routes can be kept
pretty short.  The clock line is the one I am most concerned about.  It
is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an SBSRAM,
two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.  

The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if
you keep it square (as layout guys like to do).  The other signals are
within the box these two points inscribe.  

Another approach would be to daisy chain them which would make the total
run about 3 inches.  What type of termination could I expect to work
well with this type of run? 

With such short runs, I was thinking about using no termination with a
star topology.  I am not even sure I need to worry about keeping the net
delays equal since the variation will be less than +- 1 inch or about
100 pS of clock skew.  

Anyone have much experience with running high speed clocks on such short
runs?  Can I expect this to work well?  

I know Austin will tell me to simulate it, which I plan to do.  I am
just trying to get a "gut" feeling as Bob Pease would want to do.  You
know how easy it is to get the WRONG, right answer from a computer. 
GIGO.  


-- 

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: 40789
Subject: Re: where to start with constraining..
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 15 Mar 2002 18:47:49 +0100
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> writes:

> Somebody, somewhere, needs to do the world a service and write `Xilinx Timing
> Constraints for Dummies' but AFAIK this magic volume doesn't exist.

What about:
http://support.xilinx.com/support/techtips/documents/timing/presentation/timingcsts3_1i/index.htm

I find it a good placce to start. After that, the Ref. Doc. should be used.

But then, I'm not a Dummie... ;-)

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 40790
Subject: Re: High speed clock routing
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 15 Mar 2002 19:01:05 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> I need to plan a high speed bus that will connect 5 devices.  They will
> all be very closely spaced so that the lengths of the routes can be kept
> pretty short.  The clock line is the one I am most concerned about.  It
> is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an SBSRAM,
> two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.  


Is this differential? In that case I would go for daisychaining and
termination at the end. SHORT stubs at intermediate devices.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 40791
Subject: Re: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Mar 2002 13:05:28 -0500
Links: << >>  << T >>  << A >>
Magnus Homann wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> 
> > I need to plan a high speed bus that will connect 5 devices.  They will
> > all be very closely spaced so that the lengths of the routes can be kept
> > pretty short.  The clock line is the one I am most concerned about.  It
> > is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an SBSRAM,
> > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.
> 
> Is this differential? In that case I would go for daisychaining and
> termination at the end. SHORT stubs at intermediate devices.
> 
> Homann

No this is not differential.  This is LVTTL.  BTW, what do you mean by
SHORT?  Is that anything like telling someone to pay CAREFULL attention
to signal routing?  :)  

-- 

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: 40792
Subject: Re: Xilinix FPGA with 5V IO
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 15 Mar 2002 19:15:23 +0100
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin.lesea@xilinx.com> schrieb im Newsbeitrag
news:3C92136E.B45304E1@xilinx.com...
> Rick,
>
> Virtex II is also "5V compatible" when the current into the pin is less
than ~ 10 to
> 12 mA, so the 100 ohms works for Virtex II, too.

Hm. After all, I think in most cases, you dont need  such a high-tec "toy"
like Virtex-II when there are still some "old guys" with 5V on your
board(yes, PCI is one of these exceptions). A Spartan-II will do the job (i
think . . .). Or some functions and the 5V Interface is put into a
Spartan-II, and the rest into a Virtex-II (interfacing with the Spartan-II
at 3.3V or even 2.5V, IO Banking rules ;-).

Regards
Falk







Article: 40793
Subject: Re: PCI design in a Spartan II which crashes in some wintel PCs
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Fri, 15 Mar 2002 10:20:07 -0800
Links: << >>  << T >>  << A >>
Hi,

It seems odd that it works sometimes, and fails to work
in other cases.  Without seeing what you have done, it
is hard to say -- but have you considered the following:

Is your card compliant with the PCI timing specifications?
If not, this could be causing a lot of your problems.

You say you have not implemented parity, I wonder if some
machines you are testing with have parity error detection
enabled while others do not...  As a target, when you are
being read, you should be generating correct parity.

Eric

Dan wrote:
> 
> Hello,
> 
> I have designed my own PCI logic for a target board.(33/32) It works in the
> majority of wintel PCs but crashes in a significant number of PCs.
> 
> I have implemented a design in a Xilinx PCI proto board made by Insight.
> This way I can assume that the PCB fabrication is sound.
> 
> I feel the problem comes down to the way TRDY# and DEVSEL# are being driven.
> This is the logic that must be improved.
> 
> The crashing occurs with reads. With my exisiting logic one motherboard may
> crash while another is ok. On a motherboard that is ok, the addition of a
> certain 3rd party PCI card will then result in  crashes. The logic I have
> must be on the verge of being PCI compliant. I expect that one little tweak
> should be enough to clear up all my problems.
> 
> In tracking down the problem I have removed more and more logic to simplify
> the design and to narrow in on the cause. Almost all the logic is now gone.
> All that remains is:
> 
> OUTPUTS:
> TRDY#
> DEVSEL#
> 
> INPUTS:
> FRAME#
> IRDY#
> AD[31:00]
> C/BE[3:0]#
> CLK
> 
> In this stripped down implementation there are no bursts, no parity, no
> master logic, no configuration space ( which is not needed to effect
> reads/writes if you know of a conflict free address, which I do for test
> purposes )
> The logic is very simple. When a read or write is decoded I take DEVSEL#
> active low, followed by TRDY#. When IRDY# is seen low I release TRDY# and
> DEVESEL# on the next clock.(wintels do not do burst reads so I know FRAME#
> will indicate a single data phase cycle)  This complete test is a trivial
> and small piece of logic. ( For anyone designing their own PCI logic this is
> an excellent first step to try. Once this works then you would go on to add
> other features.)  Note that I am not even driving AD[31:00] on the reads. So
> the only PCI signals that I drive in response to a decoded PCI read in my
> address space is DEVSEL# and TRDY#.
> 
> When a crash occurs it happens on a read but not every read so as you can
> see this is erractic.
> Note: all PCI input and output signals are clocked.
> 
> My schematics will be provided to anyone who requests them.
> 
> Is there anyone out there who has gone down this road designing their own
> PCI logic for a FPGA ? Come on over. I have a plane ticket for you. Name
> your price.
> 
> Sincerely
> Daniel DeConinck
> www.PixelSmart.com
> TEL: 416-248-4473

Article: 40794
Subject: Re: Spartan-XL, SpartanII and Spartan-IIE bitstream format question ...
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 15 Mar 2002 19:23:37 +0100
Links: << >>  << T >>  << A >>
"Georg Acher" <acher@in.tum.de> schrieb im Newsbeitrag
news:a6si4m$13e$1@sunsystem5.informatik.tu-muenchen.de...
> |> see an initial 32 1's before the sync word.
>
> If you want to independently program two chips with only 5 wires
(2*program,
> 1*clk, 2*din), it is quite useful that clocking in ones doesn't disturb
the
> other chip. If everything works, you can program the chips in parallel..

This is no problem with Spartan-II/Virtex. Since the unprogrammed FPGA can
be hold in reset (PROGAM LOW) you can configure the other. Then, the
configured FPGA will ignore CCLK and DIN.
.
--
MfG
Falk





Article: 40795
Subject: Re: PCI design in a Spartan II which crashes in some wintel PCs
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 15 Mar 2002 19:29:14 +0100
Links: << >>  << T >>  << A >>
"Dan" <daniel.deconinck@sympatico.ca> schrieb im Newsbeitrag
news:crok8.4124$R85.558182@news20.bellglobal.com...

> When a crash occurs it happens on a read but not every read so as you can
> see this is erractic.
> Note: all PCI input and output signals are clocked.

??? AFAIK not all PCI inputs can be registered.

> My schematics will be provided to anyone who requests them.
>
> Is there anyone out there who has gone down this road designing their own
> PCI logic for a FPGA ? Come on over. I have a plane ticket for you. Name

I dont. But Kevin is doing so since a while. And in his threads, it came
out, that the timing of TRDY and IRDY is critical, and Xilinx provides
special macros to implement this logic, some kind of black magic voodoo-box
;-))
Have a look at the pinouts, they name TRDY and IRDY a special IO-Pins.

Just my 2 EURO.cents ;-)
--
MfG
Falk





Article: 40796
Subject: Re: High speed clock routing
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 15 Mar 2002 19:32:18 +0100
Links: << >>  << T >>  << A >>
"Magnus Homann" <d0asta@mis.dtek.chalmers.se> schrieb im Newsbeitrag
news:ltg03190da.fsf@mis.dtek.chalmers.se...
> rickman <spamgoeshere4@yahoo.com> writes:
>
> > I need to plan a high speed bus that will connect 5 devices.  They will
> > all be very closely spaced so that the lengths of the routes can be kept
> > pretty short.  The clock line is the one I am most concerned about.  It
> > is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an SBSRAM,
> > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.
>
>
> Is this differential? In that case I would go for daisychaining and
> termination at the end. SHORT stubs at intermediate devices.

Isnt end termination the ONLY clean way when daisy-chaining??? (According to
the "bible" from  Howard Johnson)

Regards
Falk





Article: 40797
Subject: Re: where to start with constraining..
From: kayrock66@yahoo.com (Jay)
Date: 15 Mar 2002 11:52:35 -0800
Links: << >>  << T >>  << A >>
Hi Josh,
What you're seeing is not uncommon but the thing to keep in mind is
that you're running one particular design at room temp.  As you might
guess, Xilinx would like to rate their parts as fast as possible so
there must be some explaination.  The answer lies in that operating
speeds vary with temperature, the part and timing report are
guaranteeing that over the full temperature range, you will have
reliable operation.  Hotter is slower.  One of the common methods of
"shotgunning" setup time problems is a can of freeze spray.  You know
that the delays will shorten when the part is cooled so that if the
design starts working when you hit it with the freeze spray, then you
should be thinking about setup time.  The other issue is that the
timing report may be listing a worst case path that doesn't chnage
state in your real application- the static timing analyzer doesn't
know how you'll use the circuit, so it just lists the worst possible
path between 2 flops.  And thirdly, you might have just been "lucky"
on a route, and landed your most critical paths in a relatively fast
part of the chip.  If seen this many times before wheer you're lucky
on one route and can over clock, then unlucky on another and have to
run closer to rated speed.  The overclocking stuff is great for lab
work, but not for production equipment.

Regards

p.s. You can derate and prorate the static timing report with voltage
and temp restrictions, it's somewhere in there, can't remember
exactly.


"Josh Pfrimmer" <yeah_spam_me@thisaddress.com> wrote in message news:<a6q0jj$g99k4$1@ID-132015.news.dfncis.de>...
snip...
>     Incidentally, the post-layout timing report gives a figure of ~20MHz fo
> the maximum clock speed, but on the board, I'm well over 45.. is this
> typical?  How can I get more accurate numbers out of the reports?
> 
> Thanks for your attention
> JoshP

Article: 40798
Subject: Re: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Mar 2002 15:08:16 -0500
Links: << >>  << T >>  << A >>
Austin, thanks for the simulation.  

This looks like great data.  But I am not sure if you were trying to
help by doing my simulation for me, or if you were just trying to show
what the tool can do.  

I am not clear about what this is simulating.  Obviously you used the
daisy chain model, but how do you know what to use as a trace impedance
and where did the delays come from?  The preliminary layout I am using
has the following delays in the daisy chain case, assuming 100pS per
inch.  Is that a valid assumption?  

DSP to FPGA       100pS
FPGA to SDRAM1     50pS
SDRAM1 to SDRAM2   50pS
SDRAM2 to SBSRAM  100pS

Don't I need to caclulate the trace impedance from the PCB design
rules?  The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8
layers with a total thickness of 0.062".  Of course, I can use wider
traces for the clock and control which layer they are on.  

I would expect these four loads to behave much better than the five
loads with 200+ pS delays.  

If you were just trying to demonstate the tool, that's fine.  But if you
were trying to simulate my case, these are the data that should be
used.  

When I am done my other work today, I will try downloading the software
and giving it a try this weekend or next week.  



Austin Lesea wrote:
> 
> Rick,
> 
> [Image]
> 
> Parallel termination (shown above) is great for daisy chained clocks.
> Of course, you have to deal with the timing, and the delays (or
> skews).
> 
> Another great thing that is easy to do in HyperLynx using IBIS models.
> 
> Austin
> 
> PS:
> 
> Here is no termination ....
> [Image]
> 
> Note some devices don't get any clocks at all .....
> 
> 
> rickman wrote:
> 
> > I need to plan a high speed bus that will connect 5 devices.  They
> > will
> > all be very closely spaced so that the lengths of the routes can be
> > kept
> > pretty short.  The clock line is the one I am most concerned about.
> > It
> > is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an
> > SBSRAM,
> > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.
> >
> > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y
> > if
> > you keep it square (as layout guys like to do).  The other signals
> > are
> > within the box these two points inscribe.
> >
> > Another approach would be to daisy chain them which would make the
> > total
> > run about 3 inches.  What type of termination could I expect to work
> >
> > well with this type of run?
> >
> > With such short runs, I was thinking about using no termination with
> > a
> > star topology.  I am not even sure I need to worry about keeping the
> > net
> > delays equal since the variation will be less than +- 1 inch or
> > about
> > 100 pS of clock skew.
> >
> > Anyone have much experience with running high speed clocks on such
> > short
> > runs?  Can I expect this to work well?
> >
> > I know Austin will tell me to simulate it, which I plan to do.  I am
> >
> > just trying to get a "gut" feeling as Bob Pease would want to do.
> > You
> > know how easy it is to get the WRONG, right answer from a computer.
> > GIGO.
> >
> > --
> >
> > 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

-- 

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: 40799
Subject: Re: Universal FPGA Programmer
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 15 Mar 2002 20:10:30 -0000
Links: << >>  << T >>  << A >>
Falk Brunner wrote

> Look at the Xilinx homepage->support->hardware.
>
> There you can find a schematic for the parallel-III cable, which allows you
> to do JTAG and Serial Slave downloads.

Does not seem to be there any more.  It may be on the excellent
Xilinx DataSource CD.

Although there are some references on the X site to the parallel-III
cable, the current product is the parallel-IV.







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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search