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 83750

Article: 83750
Subject: wrong place
From: =?ISO-8859-15?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Fri, 06 May 2005 13:23:53 +0200
Links: << >>  << T >>  << A >>
Hi,

sorry, I hit the wrong button.

regards,
Benjamin

Article: 83751
Subject: FPGA choice advice needed
From: Mouarf <toto@toto.de>
Date: Fri, 06 May 2005 14:26:38 +0200
Links: << >>  << T >>  << A >>
hello all,

Could someone give me an advice of the best FPGA(s) that meets following 
requirements:

Application: PCI board to be connected to an automotive bus (CAN, or 
LIN, or FlexRay etc...), an IP will be integrated for each of thoses 
busses (only 1 bus type per PCI board, several channels).

The application must include:
- a 5V PCI target core (32 bit, 33Mhz), how much does this cost?
- the PCI core owns a Win98 (option: Linux) driver and an API to map the 
dual port RAM (ie: the application gets a pointer to the dual port RAM 
and use it as memory without any function to be called when accessing 
PCI hardware), how much does this cost?
- a dual port RAM core (maybe with anti collision feature or boundary 
areas), with a size of at least 512kbit or a large FIFO, how much does 
this cost? What is the RAM size range that is possible to build in a FPGA?
- the automotive bus IP core (I will code it)
- a non BGA package because of higher production cost and hardware debug 
difficulties and low pin count (<150)
- low price (very very small quantities), below $40 in single quantity 
(for one or 2 FPGA that will do the job), and low power consumption (ok, 
everyone ask for that!)
- Xilinx or Altera because the FPGA community (like this newsgroup) know 
their product well (ie: good support)
- free 16 or 32 bit processor core (or already integrated core like ARM 
or PowerPC or maybe LEON) with well documented free development tools 
(gcc...) or used by many open source projects, the firmware  code will 
be stored in an external parallel Flash memory.

I know that I should first code and then choose the best FPGA that fits 
the application but I must make a preselection in order to have more 
ideas about the board architecture, power consumption and price...

Should I consider that everything fits in a 300kGate FPGA?

Could someone tell me and approximate number of required Kgate for each 
block mentionned above?

For more flexibility in the future (eg: available IC for processor or 
automotive bus), I've thought about using 2 FPGA on the board:
- one for PCI interface, very large dual port RAM and a small FIFO (both 
with the same connexion to external local bus), this will be the same 
for every new board
- one for the automotive bus controller, and the processor (and its RAM) 
that will have an external connection to the RAM inside the first FPGA, 
this board can be changed to use a fast microcontroller instead of 
processor core and/or to use an already existing CAN/LIN controller.

Which FPGA would you recommend for both?


Other question:
Does someone know if there is an equivalent product table as 
http://www.xilinx.com/products/tables/fpga.htm but for Altera, Actel or 
Lattice?

Article: 83752
Subject: Parallel Cable IV opened in "Compatibility Mode"
From: Sean Durkin <smd@despammed.com>
Date: Fri, 06 May 2005 12:33:55 GMT
Links: << >>  << T >>  << A >>
Hi folks,

this is starting to drive me nuts:

I use a Xilinx Parallel Cable IV to program some big FPGAs (big as in
V2P70 and the like). Now Impact and Chipscope always open this cable in
"Compatibility Mode", meaning it is used as a Parallel Cable III and
takes FOREVER to download a bitstream. No matter what I do, no matter
what settings for the parallel port I use, it keeps getting detected as
a Parallel Cable III. This is a problem we've been having constantly for
years now... on some machines it works fine, on some it doesn't, and on
some others it sometimes works but sometimes doesn't.

The only certain thing is that it never works on the machine I am
currently working on when I have a lot of testing to do and big bitfiles
to download.

Now, I've googled my eyes out for this, read all the answer records,
tried everything mentioned there and everything I could think of:

- I tried all possible BIOS-settings for the parallel port: ECP, EPP,
bidirectional, different DMA-channels, different IRQs; you name it, I've
tried it

- I tried uninstalling the cable drivers from Xilinx, reinstalling new
ones. I tried uninstalling the entire ISE, making sure there's nothing
left in the Windows-Drivers-Dir, reinstalling ISE. I've tried every
ISE-version from 4.2 to 7.1 without success. I've tried doing a fresh
install on a freshly installed Windows, nothing.

Now we bought one of the new platform cables for USB, works much better,
but those are expensive and we have probably half a dozen "Parallel
Cable IVs" in use.

Any pointers, any hints?

cu,
Sean

Article: 83753
Subject: Re: FPGA choice advice needed
From: "Teo" <themarenas@comcast.net>
Date: 6 May 2005 05:58:51 -0700
Links: << >>  << T >>  << A >>
I've recently assisted implementing a pci slave in a Lattice EC device.
That was 3.3v pci.  The reference design on Lattice's website take ~ 1k
LUTs.
As far as the embedded ram, you're not going to get 500k in a non BGA
package
from anyone.  You need to either use two devices or use a BGA.
CAN controller should be less than 2k LUTs.
Don't think Lattice has a free micro, but you can get 8051s & such from
open cores.  Here is the product table for the EC family.
http://www.latticesemi.com/products/fpga/ecp/index.cfm


Mouarf wrote:
> hello all,
>
> Could someone give me an advice of the best FPGA(s) that meets
following
> requirements:
>
> Application: PCI board to be connected to an automotive bus (CAN, or
> LIN, or FlexRay etc...), an IP will be integrated for each of thoses
> busses (only 1 bus type per PCI board, several channels).
>
> The application must include:
> - a 5V PCI target core (32 bit, 33Mhz), how much does this cost?
> - the PCI core owns a Win98 (option: Linux) driver and an API to map
the
> dual port RAM (ie: the application gets a pointer to the dual port
RAM
> and use it as memory without any function to be called when accessing

> PCI hardware), how much does this cost?
> - a dual port RAM core (maybe with anti collision feature or boundary

> areas), with a size of at least 512kbit or a large FIFO, how much
does
> this cost? What is the RAM size range that is possible to build in a
FPGA?
> - the automotive bus IP core (I will code it)
> - a non BGA package because of higher production cost and hardware
debug
> difficulties and low pin count (<150)
> - low price (very very small quantities), below $40 in single
quantity
> (for one or 2 FPGA that will do the job), and low power consumption
(ok,
> everyone ask for that!)
> - Xilinx or Altera because the FPGA community (like this newsgroup)
know
> their product well (ie: good support)
> - free 16 or 32 bit processor core (or already integrated core like
ARM
> or PowerPC or maybe LEON) with well documented free development tools

> (gcc...) or used by many open source projects, the firmware  code
will
> be stored in an external parallel Flash memory.
>
> I know that I should first code and then choose the best FPGA that
fits
> the application but I must make a preselection in order to have more
> ideas about the board architecture, power consumption and price...
>
> Should I consider that everything fits in a 300kGate FPGA?
>
> Could someone tell me and approximate number of required Kgate for
each
> block mentionned above?
>
> For more flexibility in the future (eg: available IC for processor or

> automotive bus), I've thought about using 2 FPGA on the board:
> - one for PCI interface, very large dual port RAM and a small FIFO
(both
> with the same connexion to external local bus), this will be the same

> for every new board
> - one for the automotive bus controller, and the processor (and its
RAM)
> that will have an external connection to the RAM inside the first
FPGA,
> this board can be changed to use a fast microcontroller instead of
> processor core and/or to use an already existing CAN/LIN controller.
>
> Which FPGA would you recommend for both?
>
>
> Other question:
> Does someone know if there is an equivalent product table as
> http://www.xilinx.com/products/tables/fpga.htm but for Altera, Actel
or 
> Lattice?


Article: 83754
Subject: Re: MAX II UFM data specification and programming
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Fri, 06 May 2005 15:18:11 +0200
Links: << >>  << T >>  << A >>
"Subroto Datta" <sdatta@altera.com> writes:

Hi Subroto,

> Chapter 9 of the  MAX II handbook explains how to use the ALTUFM
> megafunction to add UFM data with mif or hex file.  The user has to
> recompile if they want to change the hex file data, as this is how you
> convert it to POF.
> 
> This can be found at
> http://www.altera.com/literature/hb/max2/max2_mii51010.pdf
> (page 9-34 thru 9-38.)

I've read the databook some time ago. I tried to simulate the UFM
using $QUARTUS/eda/sim_lib/maxii_atoms.v. But this model does not seem
to use the MIF file at all. The verilog model is using defparams to
initialize the UFM contents during simulation and Quartus is using MIF
to initialize the UFM during implementation. I was somewhat confused
by this fact.

Anyway, what I would like to do is to program the UFM during
production. The MAX II is supposed to replace some older PLD's, a
couple I2C PROM's and some other logic. The I2C PROM's are programmed
during production and I was hoping I could to the same for the MAX II
UFM. 

Is there a way I can generate a SVF file for the UFM only?

If not I'll have to install and run Quartus for each card at the
prodcution site, pregenerate POF files for all serial numbers and
product variations, or make the UFM control signals available
externally so I can write some software to program the UFM at the
production site.


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 83755
Subject: Re: FPGA choice advice needed
From: Mouarf <toto@toto.de>
Date: Fri, 06 May 2005 15:37:53 +0200
Links: << >>  << T >>  << A >>

Teo a écrit :
> I've recently assisted implementing a pci slave in a Lattice EC device.
> That was 3.3v pci.  The reference design on Lattice's website take ~ 1k
> LUTs.
> As far as the embedded ram, you're not going to get 500k in a non BGA
> package
> from anyone.  You need to either use two devices or use a BGA.
> CAN controller should be less than 2k LUTs.
> Don't think Lattice has a free micro, but you can get 8051s & such from
> open cores.  Here is the product table for the EC family.
> http://www.latticesemi.com/products/fpga/ecp/index.cfm

OK, thanks for your feedback

Do you know how was the PCI driver implemented?
Are you talking about this PCI controller 
http://www.latticesemi.com/products/devtools/ip/pcitarget32/index.cfm ?

My problem with opencore uC cores is that I did not find any suitable 
with powerfull development tool (compiler and debugger)...

Article: 83756
Subject: Re: FPGA choice advice needed
From: "Teo" <themarenas@comcast.net>
Date: 6 May 2005 06:51:39 -0700
Links: << >>  << T >>  << A >>
Here is the free reference design for pci 32 bit slave.
http://www.latticesemi.com/products/devtools/ip/refdesigns/pcitarget.cfm

Not sure exactly what features you want in a compiler & debugger, but
there are some out there like http://www.pjrc.com/tech/8051/


Article: 83757
Subject: Re: FPGA choice advice needed
From: "John M" <statepenn99@gmail.com>
Date: 6 May 2005 06:55:07 -0700
Links: << >>  << T >>  << A >>
Mouarf,

If you need a 512Kb fifo, check out the Stratix I and II parts from
Altera.  The M-RAMs are 576Kb.  However, I don't know if $40 is going
to possible, especially when you add in the cost for a programming
PROM.  Same is true for the Xilinx V2P or V4s.  As for PCI cores, both
Xilinx and Altera have cores that require an annual fee.  Price depends
on if it is a slave or master core.  As far as I know Altera and Xilinx
only support 3.3V PCI.  Why do you need 5V?   Finally, you're not going
to get a free 16b or 32b microprocessor core unless you use an open
source solution.  That said, both Xilinx and Altera have IP you can
purchase.  I would expect the fees would be similar to a PCI core.

John


Article: 83758
Subject: Re: FPGA choice advice needed
From: Mouarf <toto@toto.de>
Date: Fri, 06 May 2005 16:19:59 +0200
Links: << >>  << T >>  << A >>
John M a écrit :
> Mouarf,
> 
> If you need a 512Kb fifo, check out the Stratix I and II parts from
> Altera.  The M-RAMs are 576Kb.  However, I don't know if $40 is going
> to possible, especially when you add in the cost for a programming
> PROM.  Same is true for the Xilinx V2P or V4s.  As for PCI cores, both
> Xilinx and Altera have cores that require an annual fee.  Price depends
> on if it is a slave or master core.  As far as I know Altera and Xilinx
> only support 3.3V PCI.  Why do you need 5V?   Finally, you're not going
> to get a free 16b or 32b microprocessor core unless you use an open
> source solution.  That said, both Xilinx and Altera have IP you can
> purchase.  I would expect the fees would be similar to a PCI core.
> 
> John
> 

OK a PCI 3,3V would fit but do you have an idea about prices for IPs 
(PCI target, processor, CAN etc...)?

Article: 83759
Subject: Re: cascaded dcms
From: Brijesh <brijesh_xyz@cfrsi_xyz.com>
Date: Fri, 06 May 2005 10:37:40 -0400
Links: << >>  << T >>  << A >>
Benjamin Menküc wrote:
> Hi,
> 
>> When you are cascading DCM's you should bring out the second DCM out 
>> of reset after some delay from the time the first DCM is locked. There 
>> was an appnote which used 16 bit shift register to delay the 'locked' 
>> signal from the first DCM. That could be one of the problems.
> 
> 
> I have to do that now, because simulation doesn't work if I connect the 
> inverted locked signal directly to the 2nd DCM.
> 
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPagePath=19005&BV_SessionID=@@@@0453148829.1115333172@@@@&BV_EngineID=ccccaddeifmhfficflgcefldfhndfmo.0 
> 
> 
> Here Xilinx says the same, however it seems that this is only neccessary 
> for simulation? Or is this any good for in hardware too?

Don't know if its needed in hardware or not, in all probablity it is 
needed in hardware too. But once you have it why bother remove it? It 
just uses a single LUT.


> 
> regards,
> Benjamin

Article: 83760
Subject: Re: cascaded dcms
From: =?ISO-8859-15?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Fri, 06 May 2005 16:46:21 +0200
Links: << >>  << T >>  << A >>
Hi Brijesh,

yes thanks. I leave it in there and don't bother about it :)

regards,
Benjamin

Article: 83761
Subject: Re: Xilinx V4 Power Calculations
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 06 May 2005 07:50:39 -0700
Links: << >>  << T >>  << A >>
OK,

I have received three votes for the spreadsheet.

That isn't going to convince anyone!

I am sure there are more of you out there who would like the 
spreadsheet, but perhaps you are just not inclined to email me?

Please don't clutter up the newsgroup, mail me directly at 
austin@xilinx.com.

Austin

Ray Andraka wrote:

> Austin Lesea wrote:
> 
>> How many folks out there want to have the local spreadsheet version 
>> for estimating?
>>
> I vote for a spreadsheet.  Using the web thing to present power numbers 
> to a customer is a real PITA.
> 

Article: 83762
Subject: Using capacitor to slow the rise time.
From: Brijesh <brijesh_xyz@cfrsi_xyz.com>
Date: Fri, 06 May 2005 10:50:54 -0400
Links: << >>  << T >>  << A >>

I know that we can vary the drive strength of the Virtex outputs and 
control the rise time. This just for my understanding of things.

Using a capacitor to ground to slow the rise time feels like a very 
wrong thing to do. But I am not able to convince others why its a bad 
practise?

The reasons I can come up with are
1) It increases the total current and hence can contribute to ground 
bounce and cross talk.
2) Total power dissipation in the device is increased.

3) It takes up board space, requires more components etc.(for now lets 
stick to the electrical aspect of things and ignore this issue)

I am unable convince that this practise is bad and a real issue.

Is there something I am missing?

Brijesh

Article: 83763
Subject: on chip termination for DVI (TMDS) possible?
From: =?ISO-8859-15?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Fri, 06 May 2005 17:21:51 +0200
Links: << >>  << T >>  << A >>
Hi,

I have looked a little bit into the standard.
The DVI uses a LVDS, with a 50 Ohm pullup to 3,3V on each line at the 
receiver. The min peak-to-peak is 150 mV and max peak-to-peak 
differential is 1560mV.

Is there a IO standard in the VirtexIIPro that supports this TMDS link, 
when I use external pullups?

The RocketIOs accept 175-2000mV differential input voltage, might that 
be the right choice for DVI?

regards,
Benjamin

Article: 83764
Subject: Re: Using capacitor to slow the rise time.
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 06 May 2005 08:21:51 -0700
Links: << >>  << T >>  << A >>
Brijesh,

A cap directly at the output pin slows down the rise time, and is not 
all that bad.  I say that only because it sometimes has to be done.

It is a lot like a one-shot, you should be able to design everything 
without having to use one.

Or, like a "GO TO" statement in a program, something to avoid, as it is 
considered bad practice.

Placing the cap at the receiver is really bad from a signal integrity 
standpoint:  it makes for a huge reflection that may lead to 
discontinuities in the rising and falling edges.

(Much) Preferable to a cap load is to set the SLOW attribute, or use a 
weaker drive output.

Austin

Brijesh wrote:

> 
> I know that we can vary the drive strength of the Virtex outputs and 
> control the rise time. This just for my understanding of things.
> 
> Using a capacitor to ground to slow the rise time feels like a very 
> wrong thing to do. But I am not able to convince others why its a bad 
> practise?
> 
> The reasons I can come up with are
> 1) It increases the total current and hence can contribute to ground 
> bounce and cross talk.
> 2) Total power dissipation in the device is increased.
> 
> 3) It takes up board space, requires more components etc.(for now lets 
> stick to the electrical aspect of things and ignore this issue)
> 
> I am unable convince that this practise is bad and a real issue.
> 
> Is there something I am missing?
> 
> Brijesh

Article: 83765
Subject: a note
From: =?ISO-8859-15?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Fri, 06 May 2005 17:40:35 +0200
Links: << >>  << T >>  << A >>
the differences between LVDS and TMDS are discussed here.

http://www.national.com/nationaledge/may01/lvds.html

regards,
Benjamin

Article: 83766
Subject: Re: including components, i.e. SRL16
From: Duane Clark <dclark@junkmail.com>
Date: Fri, 06 May 2005 15:49:55 GMT
Links: << >>  << T >>  << A >>
John Adair wrote:
> Libraries Guide is always a good place to start for component instantiation. 
> There are some component templates also available in ISE under the little 
> light style button.
> 
> If you want a simple shift then doing it in VHDL or Verilog is also easy. If 
> write your code as the following style (VHDL shown), i.e. without  a reset, 
> most synthesisers will turn it into SRL16 based logic.
> 
> process(clk)
> begin
> if clk'event and clk='1' then
> 
>     shift1 <= input;
>     shift2 <= shift1;
>             ...
>     shift(n) <= shift(n-1);
> end if;
> end process;
> 

Yikes! I guess I don't know why you would write a shift register that way.

signal shift : std_logic_vector(n downto 0);

process(clk)
begin
   if rising_edge(clk) then
     shift <= shift(n-1 downto 0) & input;
   end if;
end process;

Article: 83767
Subject: Re: Using capacitor to slow the rise time.
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 06 May 2005 15:52:30 GMT
Links: << >>  << T >>  << A >>
"Brijesh" <brijesh_xyz@cfrsi_xyz.com> wrote in message
news:d5g004$hui$1@solaris.cc.vt.edu...
>
> I know that we can vary the drive strength of the Virtex outputs and
> control the rise time. This just for my understanding of things.
>
> Using a capacitor to ground to slow the rise time feels like a very
> wrong thing to do. But I am not able to convince others why its a bad
> practise?
>
> The reasons I can come up with are
> 1) It increases the total current and hence can contribute to ground
> bounce and cross talk.
> 2) Total power dissipation in the device is increased.
>
> 3) It takes up board space, requires more components etc.(for now lets
> stick to the electrical aspect of things and ignore this issue)
>
> I am unable convince that this practise is bad and a real issue.
>
> Is there something I am missing?
>
> Brijesh

I haven't "gotten to a good place" yet with respect to slowing rise times
but I agree that adding capacitors to the output isn't an ideal solution.
What might work better (even more board space) is adding series resistors at
the drivers and capacitors on the other side of the resistor from the
driver.  The wave shape is less ideal, perhaps, but the high edge rate
transients traveling down the wire are significantly reduced without forcing
the high near-rail currents at the start of the transition.

For local point-to-point signals with a good ground reference, a series
resistor is still probably your best bet because you don't have many
mechanisms to be affected by high risetimes - EMI is still decent as long as
you don't switch routing planes far from a return path or cross plane
splits.



Article: 83768
Subject: Re: DDR SODIMM on Avnet Virtex II PRO development kit
From: Duane Clark <dclark@junkmail.com>
Date: Fri, 06 May 2005 15:54:41 GMT
Links: << >>  << T >>  << A >>
Antony wrote:
> 
> 
> Hi and thanks for the new files,
> worked on it again yesterday and now it still doesn't run properly but 
> at least now when I write a 16 bit value the system stalls (before it 
> couldn't write anything from 32 bit to 8 bit: I always got back 0), so 
> it's clear that something as changed (although I don't know if for the 
> better :) ). I'll see if finally I could make it work!
> 

Well, I'll admit to only using with 32 bit values. There may very well 
be problems with other data widths, though I expect a fix would not be 
terribly difficult. That is definitely something that would be a lot 
easier to check in simulation rather than hardware.


Article: 83769
Subject: Re: Parallel Cable IV opened in "Compatibility Mode"
From: Thomas Rudloff <thomas_rudloff_REMOVE_SPAM@gmx.net>
Date: Fri, 06 May 2005 18:14:31 +0200
Links: << >>  << T >>  << A >>
Sean Durkin wrote:

>Hi folks,
>
>this is starting to drive me nuts:
>
>I use a Xilinx Parallel Cable IV to program some big FPGAs (big as in
>V2P70 and the like). Now Impact and Chipscope always open this cable in
>"Compatibility Mode", meaning it is used as a Parallel Cable III and
>takes FOREVER to download a bitstream. No matter what I do, no matter
>what settings for the parallel port I use, it keeps getting detected as
>a Parallel Cable III. This is a problem we've been having constantly for
>years now... on some machines it works fine, on some it doesn't, and on
>some others it sometimes works but sometimes doesn't.
>
>The only certain thing is that it never works on the machine I am
>currently working on when I have a lot of testing to do and big bitfiles
>to download.
>
>Now, I've googled my eyes out for this, read all the answer records,
>tried everything mentioned there and everything I could think of:
>
>- I tried all possible BIOS-settings for the parallel port: ECP, EPP,
>bidirectional, different DMA-channels, different IRQs; you name it, I've
>tried it
>
>- I tried uninstalling the cable drivers from Xilinx, reinstalling new
>ones. I tried uninstalling the entire ISE, making sure there's nothing
>left in the Windows-Drivers-Dir, reinstalling ISE. I've tried every
>ISE-version from 4.2 to 7.1 without success. I've tried doing a fresh
>install on a freshly installed Windows, nothing.
>
>Now we bought one of the new platform cables for USB, works much better,
>but those are expensive and we have probably half a dozen "Parallel
>Cable IVs" in use.
>
>Any pointers, any hints?
>
>cu,
>Sean
>  
>
Once we had problems with "Wigglers" for Motorola processors. It pointed 
out that it was related
to cabeling. Use of a good printer cable and keeping the cable between 
the Wiggler and the development
board short solved the problem. I bet you did not change the cables 
while trying.

Regards,
Thomas

Article: 83770
Subject: Re: Using capacitor to slow the rise time.
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Fri, 06 May 2005 16:24:46 GMT
Links: << >>  << T >>  << A >>
On Fri, 06 May 2005 10:50:54 -0400, Brijesh
<brijesh_xyz@cfrsi_xyz.com> wrote:

>
>I know that we can vary the drive strength of the Virtex outputs and 
>control the rise time. This just for my understanding of things.
>
>Using a capacitor to ground to slow the rise time feels like a very 
>wrong thing to do. But I am not able to convince others why its a bad 
>practise?
>
>The reasons I can come up with are
>1) It increases the total current and hence can contribute to ground 
>bounce and cross talk.
>2) Total power dissipation in the device is increased.
>
>3) It takes up board space, requires more components etc.(for now lets 
>stick to the electrical aspect of things and ignore this issue)
>
>I am unable convince that this practise is bad and a real issue.
>
>Is there something I am missing?
>
>Brijesh

I've avoided using capacitors on digital lines for the last 30 years.
Actually, that's not quite true.  About 10 years ago, another designer
I was working with convinced me that we had a special situation in
which a capacitor was called for.  So now my policy is, every 20 years
or so, go nuts.  Now that I think of it, I've also suggested using RCs
on I2C drivers that are too fast.  But that's about it.

And some folks might say that it's acceptable to filter
non-speed-critical digital signals that enter or leave a system, for
EMI purposes.  I haven't found it necessary, but I won't argue the
point. 

I avoid capacitors on digital lines because (1) the resulting risetime
is usually poorly controlled, (2) the resulting additional signal
delay is usually poorly controlled, (3) the capacitor is often used to
cover up an underlying design problem, e.g., a glitchy decoder driving
a synchronous input, and (4) I've always been able to find a better
solution.

I don't know how many people on this group read Joel Spolsky's "Joel
on Software" blog.  Spolsky has an interesting idea called the Joel
Test, a list of 12 questions with yes/no answers that you can use to
evaluate the quality of a software team.  You can find it here.

http://www.joelonsoftware.com/articles/fog0000000043.html

I think it would be an interesting idea to come up with a similar list
for digital hardware design.  And now Brijesh has provided me with the
inspiration to start such a list:

1) Do you use capacitors on digital lines?
2) Do you use analog one-shots in your designs?

A "yes" answer to either question should be accompanied by a whole lot
of 'splaining.

One other thought: CPLD and FPGA vendors did the digital design
community a great and lasting service by not including an "add a
capacitor to this net" feature.

Bob Perlman
Cambrian Design Works
  





Article: 83771
Subject: Re: Parallel Cable IV opened in "Compatibility Mode"
From: "Brannon" <brannonking@yahoo.com>
Date: 6 May 2005 09:36:28 -0700
Links: << >>  << T >>  << A >>
Make sure that your board has proper termination on the JTAG lines.
Scope the voltages on the JTAG plug and make sure they are stable. Use
the mouse PS2 port, not the keyboard one, for the cable power. Make
sure you have updated chipset drivers. The odds are that your parallel
port controller is made by Intel. I wouldn't run any version of ISE
older than 6.2.3. I noticed some fixes in the 6.2 service packs. Make
sure the device manager shows that it is using the ECP driver and set
it to use an interrupt if one is available, which it should be.

If all of the above appear correct, then recognize the truth: there is
no spoon. The fact is that the DMA mode for the parallel IV stuff has
never worked worth a crap for me. The impression I got from support
when I called about it was that they get an aweful lot of calls on the
topic. The fact that they charge $500 for their USB cable is BS. They
do that because they have a monopoly on the item and use the
frustration caused by their parallel cables to drive the market.


Article: 83772
Subject: Will this DCM cascade track a frequency offset clock?
From: "Ken" <no@spam.com>
Date: Fri, 6 May 2005 18:40:25 +0200
Links: << >>  << T >>  << A >>
Hi all,

I need to generate a 20MHz clock from a 10MHz clock on a V2Pro.

Plan is to use 2 DCMs:

1st DCM:
10MHz into CLKIN
Use CLKFX output with default of M = 4 and D = 1 to get 40MHz.
I need to leave CLKFB unconnected because CLK0 and CLK2X will be below 
24MHz.
Also, since I am using CLKFX, I can leave CLKFB open since it is ok for 
CLKFX clock to be out of phase with the input 10MHz clock.

2nd DCM:
40MHz into CLKIN
20MHz out of CLKDV
CLKFB gets CLK0.

First question - will that work?

Next question:

The input 10MHz clock can be varied by +/- 25 parts per million to give a 
frequency offset.

So, input period is (1/10e6) +/- 2.5ps.

The +/-2.5 ps seems to be way less than the cycle and period jitter spec of 
the DCM so I am not worried about that.

The input clock will be held at each offset for 20ms minimum.  Also, there 
is 800us available for the DCMs to adjust to the new input frequency.

I see that the lock time of the DCM is 10ms and I assume this is just at 
configuration time?

So, am i right in thinking that my DCM cascade will track my freq offset 
when it is applied?  Is there a spec somewhere that states how long it will 
take to adjust to the new input freq or is it instantaneous since the 
variance is only +/- 2.5ps?

Thanks for your time guys,

Ken 



Article: 83773
Subject: Re: Parallel Cable IV opened in "Compatibility Mode"
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 6 May 2005 10:10:39 -0700
Links: << >>  << T >>  << A >>
Hi Sean,
Is there also a dongle on the port?
Syms.



Article: 83774
Subject: Re: Will this DCM cascade track a frequency offset clock?
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Fri, 6 May 2005 13:52:13 -0400
Links: << >>  << T >>  << A >>
hi Ken,

First question - no. tried almost the same thing on Virtex 2 (was locking 
and losing lock periodically).
What you should do is to multiply by a larger number using CLKFX as now,
and then used FFs to divide the clock down for feeding it to the next DCM 
stage.
In this fashion, the output jitter on DCM1/CLK0 is divided as well to be 
suitable for the DCM2/CLKIN jitter tolerance.
I tried, it works PERFECTO!
What happens, is that DCM multiplies whatever jitter you have at your clock 
source plus adding some cycle-cycle
jitter, due to its tapped delay line nature. I think there is some web page 
in Xilinx website or tools that
calculates that output jitter per given input jitter.

Regarding you 2nd question...
I never saw anything specifiying the lock time in this case, however, i have 
noticed that the resets of DCMs
cascaded in this way are to be held for much more than just 3/4/5 CLKIN 
cycles; exactly how much time, i cannot tell.
but 20 ms is definitely sufficient.

Hope this helps.

Vladislav

"Ken" <no@spam.com> wrote in message 
news:d5g6lp$lth$03$1@news.t-online.com...
> Hi all,
>
> I need to generate a 20MHz clock from a 10MHz clock on a V2Pro.
>
> Plan is to use 2 DCMs:
>
> 1st DCM:
> 10MHz into CLKIN
> Use CLKFX output with default of M = 4 and D = 1 to get 40MHz.
> I need to leave CLKFB unconnected because CLK0 and CLK2X will be below 
> 24MHz.
> Also, since I am using CLKFX, I can leave CLKFB open since it is ok for 
> CLKFX clock to be out of phase with the input 10MHz clock.
>
> 2nd DCM:
> 40MHz into CLKIN
> 20MHz out of CLKDV
> CLKFB gets CLK0.
>
> First question - will that work?
>
> Next question:
>
> The input 10MHz clock can be varied by +/- 25 parts per million to give a 
> frequency offset.
>
> So, input period is (1/10e6) +/- 2.5ps.
>
> The +/-2.5 ps seems to be way less than the cycle and period jitter spec 
> of the DCM so I am not worried about that.
>
> The input clock will be held at each offset for 20ms minimum.  Also, there 
> is 800us available for the DCMs to adjust to the new input frequency.
>
> I see that the lock time of the DCM is 10ms and I assume this is just at 
> configuration time?
>
> So, am i right in thinking that my DCM cascade will track my freq offset 
> when it is applied?  Is there a spec somewhere that states how long it 
> will take to adjust to the new input freq or is it instantaneous since the 
> variance is only +/- 2.5ps?
>
> Thanks for your time guys,
>
> Ken
> 





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