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 119675

Article: 119675
Subject: Dual Core or Quad Core when running Quartus 7.1
From: "jjlindula@hotmail.com" <jjlindula@hotmail.com>
Date: 24 May 2007 08:19:52 -0700
Links: << >>  << T >>  << A >>
Hello, I'm about to purchase a new computer and I wanted to get some
opinions on what I should get. I mostly work with Quartus II on my job
and wanted to know what would be a good system to run the software.
I've been hearing more about dual-core and quad core systems which do
you think gives better performance running Quartus? Last, should I get
4GB of memory or 2GB?  I usually program the larger fpga devices and
compilation time takes about 30 minutes and my simulations take about
an hour. My current system is a dual processor with 2GB of memory. If
anyone can comment on what would be the best computer system I'd
greatly appreciate it.

thanks,
joe


Article: 119676
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: austin <austin@xilinx.com>
Date: Thu, 24 May 2007 08:40:49 -0700
Links: << >>  << T >>  << A >>
Symon,

Yes, I know what the author of the post is trying to do.

Yes, Hyperlynx has built in models for a number of ribbon cables.

Without running the simulator, it is a complete waste of time to suggest 
anything as a "solution" to this question.

Now that I have spent three times longer than I would have solving it 
with the simulator, it appears that we have paid for the simulator, once 
again.

GET IT? (I know you do, Symon).

Austin

Article: 119677
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 24 May 2007 16:51:07 +0100
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:f349ou$ppq$1@aioe.org...
> "austin" <austin@xilinx.com> wrote in message 
> news:f34740$6dj2@cnn.xilinx.com...
>>
>> One comment: matching the transmitter impedance is a good idea, as a 
>> perfect match at the receiver is impossible (perfect may happen in 
>> textbooks, but not in real life).
>>
>> Austin
>>
> It is possible to match even Xilinx's hideous 10pF receiver pins. Here's 
> an example from Xilinx's own consultant's website:-
> http://sigcon.com/Pubs/edn/ConstantRTermination.htm
>
> HTH, Syms.
>
Here's some more links:-

http://sigcon.com/Pubs/edn/TerminatorOne.htm
http://sigcon.com/Pubs/edn/TerminatorTwo.htm
http://sigcon.com/Pubs/edn/TerminatorThree.htm

HTH, Syms.



Article: 119678
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: austin <austin@xilinx.com>
Date: Thu, 24 May 2007 08:57:41 -0700
Links: << >>  << T >>  << A >>
Symon,

Wrong solution.

Using the _DT internal differential termination, the driver will see 100 
ohms in parallel with 5 pF (10pF in series with 10 pF).

If you SIMULATE this load, you will find that since the capacitance is 
directly across the 100 ohms, the receive signal is just fine.

Any reflections are absorbed by the 100 ohm driver (gee?  I wonder what 
genius thought of doing this?).

The rise times from the driver are moderate, and adequate, so 
mis-matches don't jump up and make life difficult, and cross talk is 
reduced.

Some folks have lightning fast drivers, which cross talk like crazy, and 
even their "lower" input C looks awful, as a signal with 2X the rise 
makes even 3pF look really bad.

"The system is the solution."  Driver, termination, line, receiver, all 
have to be considered.  I know, you, personally have issue with the 
solution, but, face it, Virtex family has been an astounding success: 
and TO THIS DAY, we are the only ones with 65nm product, shipping (at 
all) production parts.  ONE YEAR as of May 5th....

Think of all those sockets we are being designed into.  All of those 
LVDS interfaces working.  Literally tens of millions of them.

Do we have room to improve?  Of course.  But, any improvement is 
weighted against its benefits.  Make the input less capacitive has no 
benefit (other than you would immediately post "see!  I told you!" and I 
would not have to reply to this issue anymore).

What might be a better item to work on, rather than spend time on 
something that "ain't broke?"

Oh, did I mention how ecstatic we are that we have a one year lead on 65nm?

Austin

Article: 119679
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 24 May 2007 09:10:12 -0700
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:f349ou$ppq$1@aioe.org...
>>
> It is possible to match even Xilinx's hideous 10pF receiver pins. Here's 
> an example from Xilinx's own consultant's website:-
> http://sigcon.com/Pubs/edn/ConstantRTermination.htm
>
> HTH, Syms.

This kind of approach certainly isn't obvious.

The reflections will *certainly* be much better.  Heck, the line can be 
probed and a good signal seen just about anywhere along the transmission 
line (assuming the probe doesn't introduce problems).

What should be noted is that - while there are no reflections and the end of 
the transmission line will see a superb voltage slow thanks to the R-only 
termination, this clean transition sees a series Zo impedance between it and 
the capacitor.

For a standard parallel Zo termination to a Zo characteristic impedance 
transmission line, the effective source is half the drive voltage through a 
Zo/2 impedance into the capacitor.  If there is no capacitance, the 
transition is gorgeous at the receiver.

For the termination scheme suggested, the point where the transition line 
sees the resistance is the same half-voltage swing.  Trouble here is that 
the equivalent series impedance to the capacitor is no longer fed by a half 
voltage with Zo/2 equivalent series impedance, but now a half voltage with a 
Zo series impedance.

If it's important to not have reflections, the R-only equivalent termination 
is superb.
If it's important to have the high slew rate, the standard termination with 
the associated pin capacitance is the way to go because the reflection 
*will* be absorbed by the transmitter's impedance if it's properly matched.

Signal Integrity *at the pin* is what's important and where a monte-carlo SI 
analysis will show which approach provides a cleaner interface in the end.

For this implementation where the speed is low, the extra 250 ps of RC time 
constant (it's C/2 for a differential signal) will probably provide 
excellent results.

- John_H 



Article: 119680
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 24 May 2007 09:18:43 -0700
Links: << >>  << T >>  << A >>
"austin" <austin@xilinx.com> wrote in message 
news:f34blr$62p3@cnn.xilinx.com...
<snip>
> Without running the simulator, it is a complete waste of time to suggest 
> anything as a "solution" to this question.
<snip>

No need to get <snip>py.  There were many successful high speed designs 
before SI got the usable, affordable tools available today.  Without a 
fundamental understanding of what DOES affect signal fidelity, we doom our 
engineering future to shotgun hacks at "trying" to get the signals to 
perform well.

Since we have the SI tools available now in a way they weren't available a 
decade ago, quick analysis of alternatives can be pursued.  To suggest that 
fundamental knowledge be tossed out since there's a tool available is the 
short-sided view that often comes with the frustration of trying to 
communicate your point.

Please don't ask engineers to avoid learning the basics of delivering good 
signal integrity just because the tools are available to avoid doing the 
heavy mental lifting.  When's the last time you gave someone $22 for a $17 
charge expecting to get a $5 bill back and they stare at you like you're 
nuts.  "But it's only $17."  The crutch of calculators and cash registers 
have crippled much of a generation.  Lets keep engineering steeped in 
fundamentals and use the tools as they're meant: as tools.

- John_H 



Article: 119681
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 24 May 2007 17:23:37 +0100
Links: << >>  << T >>  << A >>
"austin" <austin@xilinx.com> wrote in message 
news:f34blr$62p3@cnn.xilinx.com...
> Symon,
>
> Yes, I know what the author of the post is trying to do.
>
> Yes, Hyperlynx has built in models for a number of ribbon cables.
>
> Without running the simulator, it is a complete waste of time to suggest 
> anything as a "solution" to this question.
>
> Now that I have spent three times longer than I would have solving it with 
> the simulator, it appears that we have paid for the simulator, once again.
>
> GET IT? (I know you do, Symon).
>
> Austin

Hi Austin,
I do so enjoy our little chats! I also know that you're a big fan of 
simulation, and I totally agree it's a great tool. (Oh, and BTW, thanks for 
the pointer, I didn't realise that some ribbon cables were included in 
Hyperlynx, that's cool! Although, I fear the OP's cable is not included.)
My only comment is that some people are actually interested in the 
mechanisms at work. I'd say it's important to learn that first, and then use 
the simulator.
All the best, Syms. 



Article: 119682
Subject: Re: Dual Core or Quad Core when running Quartus 7.1
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 24 May 2007 09:27:51 -0700
Links: << >>  << T >>  << A >>
<jjlindula@hotmail.com> wrote in message 
news:1180019992.519179.25720@q66g2000hsg.googlegroups.com...
> Hello, I'm about to purchase a new computer and I wanted to get some
> opinions on what I should get. I mostly work with Quartus II on my job
> and wanted to know what would be a good system to run the software.
> I've been hearing more about dual-core and quad core systems which do
> you think gives better performance running Quartus? Last, should I get
> 4GB of memory or 2GB?  I usually program the larger fpga devices and
> compilation time takes about 30 minutes and my simulations take about
> an hour. My current system is a dual processor with 2GB of memory. If
> anyone can comment on what would be the best computer system I'd
> greatly appreciate it.
>
> thanks,
> joe

Multi-threaded flows that get strong performance benefits are probably years 
away.  If you won't replace your PC for 5 years, the quad core might be 
good.  For the next 2 years, the dual core should be *plenty* but be sure to 
get more L2 cache.  For the larger FPGAs, larger system memory is suggested. 
If you were doing Cyclone and Spartan3, I'd suggest the lower memory is 
fine.  With the higher end parts, more memory will be properly utilized.

If you want to run simulations while you're compiling your design and write 
up the documentation while you wait for those processes to complete, get the 
quad core.  If you just want to do one high-power task and one not so 
demanding activity, I would expect no improvement of quad-core over 
dual-core in the next 2 years.

If the quad core allows less L2 cache to the main thread than the dual-core, 
your performance will actually be worse in the near term.  Look into the L2 
management as a critical factor in chosing your tool and expect 85-100% of 
your logical and physical synthesis to be on one core for the year or two 
directly ahead.

These are my opinions based largely on hear-say and system understanding.  I 
just have a single core at the moment and am trying to make my next work PC 
(the cheap one) to have as much L2 as is reasonable.  The next home system 
will be the capable machine.  It's sad how that goes.

- John_H 



Article: 119683
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 24 May 2007 17:28:23 +0100
Links: << >>  << T >>  << A >>
"austin" <austin@xilinx.com> wrote in message 
news:f34cle$6381@cnn.xilinx.com...
> Symon,
>
> Wrong solution.
>
> Using the _DT internal differential termination, the driver will see 100 
> ohms in parallel with 5 pF (10pF in series with 10 pF).
>
> If you SIMULATE this load, you will find that since the capacitance is 
> directly across the 100 ohms, the receive signal is just fine.
>
> Any reflections are absorbed by the 100 ohm driver (gee?  I wonder what 
> genius thought of doing this?).
>
We've been here before. I'll explain again. Remember that the OP is driving 
the line from a S3. So the 100 ohm driver has 5pf across it. Oh dear, the 
same reflection mechanism as at the receiver!
>
> The rise times from the driver are moderate, and adequate, so mis-matches 
> don't jump up and make life difficult, and cross talk is reduced.
>
Of course they're moderate, they have to charge up a 5pF cap. That's not a 
good thing, no matter how you spin it! It's only adequate if your 
application needs a moderate rise time!?
>
> Some folks have lightning fast drivers, which cross talk like crazy, and 
> even their "lower" input C looks awful, as a signal with 2X the rise makes 
> even 3pF look really bad.
>
So, I think on all my future high speed designs I'll add on extra capacitors 
to the drivers, you make it sound such a great idea! (Apologies for the 
sarcasm)
>
> "The system is the solution."  Driver, termination, line, receiver, all 
> have to be considered.  I know, you, personally have issue with the 
> solution, but, face it, Virtex family has been an astounding success: and 
> TO THIS DAY, we are the only ones with 65nm product, shipping (at all) 
> production parts.  ONE YEAR as of May 5th....
>
> Think of all those sockets we are being designed into.  All of those LVDS 
> interfaces working.  Literally tens of millions of them.
>
> Do we have room to improve?  Of course.  But, any improvement is weighted 
> against its benefits.  Make the input less capacitive has no benefit 
> (other than you would immediately post "see!  I told you!" and I would not 
> have to reply to this issue anymore).
>
> What might be a better item to work on, rather than spend time on 
> something that "ain't broke?"
>
> Oh, did I mention how ecstatic we are that we have a one year lead on 
> 65nm?
>
> Austin

Wow, what brought that on? I'm sorry but for some reason I kept seeing Tom 
Cruise on the couch when I was reading that! Ever thought of switching to 
de-caf? :-) (Just kidding!!) Anyway, we've been through this before, we're 
never gonna agree, your loyalty to Xilinx is too strong for that (kidding 
again!), but anyone who's interested can search back through comp.arch.fpga 
and decide for themselves whether high speed outputs and receivers are 
compromised by pin capacitance.
Cheers, Syms. 



Article: 119684
Subject: ModelSim Memory Content import from Intel Hex
From: Udo <WeikEngOff@aol.com>
Date: 24 May 2007 09:33:29 -0700
Links: << >>  << T >>  << A >>
Hello,

I'm looking for an import utility from Intel Hex to the supported
formats of ModelSim,
e. g. MTI or Verilog (Hex).


Many thanks in advance
Udo


Article: 119685
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 24 May 2007 17:33:54 +0100
Links: << >>  << T >>  << A >>
"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:135be6pdo0nn37e@corp.supernews.com...
> "Symon" <symon_brewer@hotmail.com> wrote in message 
> news:f349ou$ppq$1@aioe.org...
>>>
>> It is possible to match even Xilinx's hideous 10pF receiver pins. Here's 
>> an example from Xilinx's own consultant's website:-
>> http://sigcon.com/Pubs/edn/ConstantRTermination.htm
>>
>> HTH, Syms.
>
>
> If it's important to not have reflections, the R-only equivalent 
> termination is superb.
> If it's important to have the high slew rate, the standard termination 
> with the associated pin capacitance is the way to go because the 
> reflection *will* be absorbed by the transmitter's impedance if it's 
> properly matched.
>
> Signal Integrity *at the pin* is what's important and where a monte-carlo 
> SI analysis will show which approach provides a cleaner interface in the 
> end.
>
> For this implementation where the speed is low, the extra 250 ps of RC 
> time constant (it's C/2 for a differential signal) will probably provide 
> excellent results.
>
> - John_H
>
Hi John,
Neatly summarised!
Thanks, Syms. 



Article: 119686
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: austin <austin@xilinx.com>
Date: Thu, 24 May 2007 09:54:08 -0700
Links: << >>  << T >>  << A >>
Symon,

We agree to disagree.

I would hope that it is clear that the Xilinx solution works just fine.

There are just far too many working pcbs out there to suggest otherwise.

I have already agreed it could be better, but if it works, why bother?


As for loyalty to Xilinx, I am trying to be an engineer:  facts, facts, 
facts.

Fact: input Z (and output Z) = 100 ohms + 5pf
Fact: risetime is adequate for the job (too fast is actually a bad 
thing, too slow just mens you can't operate at very high rates, parts 
meet their specifications)
Fact: Symon hates having any C in parallel with the termination.
Fact: All terminations have some C.
Fact: Symon and I do not agree.

Austin

Article: 119687
Subject: Re: 6502 and CPU licences in general
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 24 May 2007 16:54:15 GMT
Links: << >>  << T >>  << A >>
on www.fpgaarcade.com you can get the latest version of the T65 core from 
Opencores.

I did a lot of debuging work on the original and still maintain it as the 
original author has vanished. It is used in a number of the arcade game 
projects with great success.

/Mike



Article: 119688
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: austin <austin@xilinx.com>
Date: Thu, 24 May 2007 10:01:49 -0700
Links: << >>  << T >>  << A >>
John,

In no way did I imply that engineers should not learn about SI.

But, I can not require SI knowledge, either.

That is why we have IO standards (cookbook recipes).

Without a degree in E&M theory, I would argue that you can't really 
understand what is going on.

Well, a suppose a physicist might be capable of recognizing Maxwell's 
equations, but as far as I know, only those who have actually set up, 
and solved these equations, have the fundamental knowledge that is required.

There are many who have practical knowledge (experience), and that 
sometimes passes for understanding.

Anyone else is someone who is just pretending they have the knowledge.

And that is just fine:  just as we can not ask that all users of FPGAs 
know everything about heat transfer, we recognize that the team who are 
using the FPGA will require some support for those specialties that they 
lack.

Austin

Article: 119689
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: austin <austin@xilinx.com>
Date: Thu, 24 May 2007 10:03:17 -0700
Links: << >>  << T >>  << A >>
Symon,

I agree.  For those for whom SI is a mystery, learn something today:  go 
read up on SI.

Austin

Article: 119690
Subject: Actel timing constraints
From: "Niv (KP)" <kev.parsons@mbda.co.uk>
Date: 24 May 2007 10:49:50 -0700
Links: << >>  << T >>  << A >>
I need to write some timing constraints for an ProAsic device.  The
Designer tool doesn't seem to cater for what I need;  as follows:

FPGA1 (Xilinx) outputs data on clk rising edge & FPGA2 (my Actel)
captures data on the clk falling edge  (Same clock with very low skew
to both devices)
Similarly Actel outputs data on clk falling edge & Xilinx capture on
rising edge.
I have the Xilinx input & output delays and the clock period is 30 ns.
The clock M/S ratio is 40/60 though, so the total allowed time from
one device clocking out to the other device clocking in is therefore
12 ns (40% of 30ns as worst case). PCB trace is assumed ~1ns.

So how do I apply the constraints to my Actel chip; I've never used an
SDC file, so some tips or pointers to examples would be useful.

TIA, Niv


Article: 119691
Subject: Re: Problems to simulate (behavioural) in XPS
From: ferorcue <le_marq@hotmail.com>
Date: 24 May 2007 10:55:41 -0700
Links: << >>  << T >>  << A >>
My supervisor installed gmake. The first problem is solved but not the
second:
In modelsim, when try to simulate (behavioral) it tries to load the
whole system but the next massage is shown:

 Loading opb_arbiter_v1_02_e.or_gate(imp)#1
# ** Fatal: (vsim-3348) Port size (1) does not match actual size (32)
for port '/system/opb/opb/opb_abus_i/y'.
#    Time: 0 ps  Iteration: 0  Instance: /system/opb/opb/opb_abus_i
File: /opt/xilinx/EDK8.2/hw/XilinxProcessorIPLib/pcores/
opb_arbiter_v1_02_e/hdl/vhdl/or_gate.vhd Line: 125
# FATAL ERROR while loading design
# Error loading design


Someone have any idea?







On May 24, 9:44 am, ferorcue <le_m...@hotmail.com> wrote:
> I have a question:
>
> I think that gmake is not installed in my operating system (solaris)>whereis gmake
> gmake:
>
> whereas make is intalled>whereis make
>
> make: /usr/bin/make /usr/X11R6/bin/make /usr/bin/X11/make
> /usr/share/man/man1/make.1.gz
>
>
>
> What file and how should I change in order to use make with LIBGEN ?
>
> Thank you for your consideration.



Article: 119692
Subject: Re: Use BRAM as ROM (Xilinx)
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 24 May 2007 11:28:21 -0700
Links: << >>  << T >>  << A >>
Lancer wrote:

> is it possible to use Spartan 3 BRAM (on my xc3s1000 it should be
> 432K) as a ROM memory for data storage 

I make ROMs like this:
http://home.comcast.net/~mike_treseler/sync_rom.vhd

       -- Mike Treseler

Article: 119693
Subject: How to code a bidirectional databus?
From: "Fed" <Fed@net.net>
Date: Thu, 24 May 2007 20:59:42 +0200
Links: << >>  << T >>  << A >>
What are the rules for coding a bidirectional databus in VHDL?

I must be able to connect several different entities to the same bus, and
all entities but one has its outputs as 'Z'.

Should the bus signals be declared as inout?



Article: 119694
Subject: Re: How to code a bidirectional databus?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 24 May 2007 12:16:03 -0700
Links: << >>  << T >>  << A >>
Fed wrote:
> What are the rules for coding a bidirectional databus in VHDL?
> I must be able to connect several different entities to the same bus, and
> all entities but one has its outputs as 'Z'.

That's the rule.

> Should the bus signals be declared as inout?

I would prefer to use separate data_in and data_out buses.
There are no real tri-state nodes inside the fpga.

        -- Mike Treseler

Article: 119695
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 24 May 2007 12:22:19 -0700
Links: << >>  << T >>  << A >>
On Thu, 24 May 2007 07:23:01 -0700, austin <austin@xilinx.com> wrote:

>All,
>
>I suppose suggesting that the question could be answered in less than 10 
>minutes using a SIGNAL INTEGRITY simulator would just be silly?
>
>I am absolutely amazed at how much time, money, and energy is wasted 
>just because a SI simulator is "expensive."
>
>One respin of a pcb is MORE $$$ than buying the SI simulator tool.
>
>Mentor's Hyperlynx(tm) simulator is my favorite, but Cadence has their 
>tool which might be more to some folks liking (it is integrated with the 
>PCB layout stuff).
>
>So, how about it?  Invest in something that will save you enough money 
>to pay for it the first time you do not screw up.
>
>Submit a hotline webcase, and ask for a "what if" SI simulation.  That 
>way you will get a free example of (one) solution to your problem.
>
>
>One comment: matching the transmitter impedance is a good idea, as a 
>perfect match at the receiver is impossible (perfect may happen in 
>textbooks, but not in real life).
>

Does an LVDS transmitter have an impedance? The ones I've played with
seem to behave like current sources; unloaded, the diff outputs swing
(slowly!) almost rail-to-rail. That said, presenting the transmitter
with an equivalent 100 ohm net diff load will normalize the swing to
standard levels and speed things up a bit as compared to letting them
see a 173 or whatever diff load.

John


Article: 119696
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 24 May 2007 12:31:12 -0700
Links: << >>  << T >>  << A >>
On Thu, 24 May 2007 15:26:15 +0100, "Symon" <symon_brewer@hotmail.com>
wrote:

>"John_H" <newsgroup@johnhandwork.com> wrote in message 
>news:cUg5i.9206$ix.312@trndny01...
>> stefan.elmsted@gmail.com wrote:
>>> Hi
>>
>> On the transmitter, you want a 100 ohm to 173 ohm impedance match so the 
>> transmitter sees 100 ohm but the transmission line sees 173 ohm.  You'll 
>> need a differential termination on the transmitter side of this network 
>> and two series resistors to the ribbon cable.  The signal amplitude will 
>> again be reduced.
>>
>You don't _need_ to match both transmitter and receiver. One or the other is 
>good enough, provided the path between the driver and the cable has the same 
>impedance as the cable, or this path is short. Cf. ECL logic, low output 
>impedance, but can drive a properly terminated diff. pair. LVDS outputs are 
>matched to the line to get a belt 'n' braces approach to reduce reflections, 
>but it's not necessary to match the transmitter to the line.
>
>Here's an app note which describes the output structures.
>http://www.maxim-ic.com/appnotes.cfm/an_pk/291
>
>HTH, Syms. 
>

National's CMOS structure is different,

http://www.national.com/appinfo/lvds/files/lvds_ch1.pdf

more of a real current source. I'd guess that the Maxim is the oddball
here. The National and Fairchild transmitters I've played with will go
rail-to-rail if not terminated. I haven't tried an unterminated Xilinx
lvds driver; their receivers are pretty good r-r comparators.

John


Article: 119697
Subject: Re: Ddr sdram feedback pin
From: Duane Clark <junkmail@junkmail.com>
Date: Thu, 24 May 2007 12:45:21 -0700
Links: << >>  << T >>  << A >>
Pablo wrote:
> Hi everyone, I want to design a model with my Smt338. This is a
> Sundance board with a Virtex IIPro30 ff896-6 and a Micron MT46V16M16
> as DDR memory. First of all I need to implement the hardware
> architecture, so I use edk 8.1 (or edk 8.2) to create a model with
> PowerPC and this DDR memory. In the ucf I map every port, but I have
> not any pin to DDR_CLK, that is, the feedback ddr clock.
> 
> This is the loc entry: Net fpga_0_GEN_DDR_CLK_FB LOC=;
> 
> What can I do?. Perhaps I could use a DCM_module but I don't know how
> could I implement it.

One way is to put the feedback on an unused pin:
    DDR_Clk_fb     : inout std_logic;

To keep the timing independent of PAR layout, drive the pin with a DDR 
register:
    DDR_CLK_FB_e: FDDRRSE
    port map (
       Q   => DDR_Clk_fb_o,
       C0  => CLK90,
       C1  => CLK90n,
       CE  => '1',
       D0  => '1',
       D1  => '0',
       R   => '0',
       S   => '0'
    );

Then instantiate the io buffer:

    ddr_clk_io : IOBUF
    port map (
       I => DDR_Clk_fb_o,
       IO => DDR_Clk_fb,
       O => DDR_Clk_fb_i,
       T => '0'
    );

And so, of course, DDR_Clk_fb_i is the input feedback signal.

Article: 119698
Subject: Re: LVDS termination scheme to nonstandard ribbon cable
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 24 May 2007 12:54:13 -0700
Links: << >>  << T >>  << A >>
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:0ppb531bd38oj99t3dne4fei8n4lrotm00@4ax.com...
>
> National's CMOS structure is different,
>
> http://www.national.com/appinfo/lvds/files/lvds_ch1.pdf
>
> more of a real current source. I'd guess that the Maxim is the oddball
> here. The National and Fairchild transmitters I've played with will go
> rail-to-rail if not terminated. I haven't tried an unterminated Xilinx
> lvds driver; their receivers are pretty good r-r comparators.
>
> John

The FPGA structures appear to be what are important to this conversation. 
There are transmitters that are true current sources both with and without 
internal 100 ohm parallel terminations.  There are transmitters that present 
voltage drivers with (series) source impedances that roughly match the 
current-source approach.

For anyone designing with LVDS, appropriate reading of the data sheet 
information on the transmitter is important.  For a proper LVDS connection, 
the transmitter needs to appear to be a 100 ohm differential source. 
Different manufacturers are happy to deviate slightly from the originally 
proposed driver structure to present something with equivalent 
characteristics when properly configured whether this means plug&play, an 
external parallel termination, or a 3-resistor network to "look" like the 
equivalent source.  Without the 100 ohm equivalent transmit impedance, any 
reflections from the receiver or other impedance mismatches will reflect 
back toward the receiver rather than be absorbed at the source.

- John_H 



Article: 119699
Subject: Re: Actel timing constraints
From: Alan Myler <amyler@eircom.net>
Date: Thu, 24 May 2007 21:16:48 +0100
Links: << >>  << T >>  << A >>
Niv (KP) wrote:

> I need to write some timing constraints for an ProAsic device.  The
> Designer tool doesn't seem to cater for what I need;  as follows:
> 
> FPGA1 (Xilinx) outputs data on clk rising edge & FPGA2 (my Actel)
> captures data on the clk falling edge  (Same clock with very low skew
> to both devices)
> Similarly Actel outputs data on clk falling edge & Xilinx capture on
> rising edge.
> I have the Xilinx input & output delays and the clock period is 30 ns.
> The clock M/S ratio is 40/60 though, so the total allowed time from
> one device clocking out to the other device clocking in is therefore
> 12 ns (40% of 30ns as worst case). PCB trace is assumed ~1ns.
> 
> So how do I apply the constraints to my Actel chip; I've never used an
> SDC file, so some tips or pointers to examples would be useful.
> 
> TIA, Niv
> 
> 




You need the "set_output_delay" constraint I think. Designer "help" menu 
will tell you how to use it.

Alternatively use the Timing Analyser GUI in Designer to set the 
constraints.

Alan





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