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 80400

Article: 80400
Subject: Re: Genlock
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 05 Mar 2005 12:25:43 +1300
Links: << >>  << T >>  << A >>
fpgavhdl@gmail.com wrote:
> Thanx Again
> 
> The black burst generator is both NTSC and PAL compliant...
> 
> I am locking the Hsync using a PLL (external to the fpga) using a 1715
> x fh = twice 858 x fh ...which u were talking abt..
> 
> I cant get the Hsnyn without jitter. 
<snip>

  All PLLs will have some jitter - do you have some numbers on how much
jitter you are seeing ?

  If this is an external Analog PLL, it probably has a loop filter, so
you can scope that to check it is actually in stable lock.

  PLLs like this are also a trade off of lock-range vs stability.
eg Colour burst PLLs use XTALS, very high stability, but quite narrow 
lock ranges.
  Horiz PLLs can use RC or LC circuits, RC are cheaper, but have
higher jitter values.

-jg


Article: 80401
Subject: Re: 100Mbps ethernet core
From: junkmail@fastertechnology.com
Date: 4 Mar 2005 15:44:10 -0800
Links: << >>  << T >>  << A >>
Duane Clark wrote:
> junkmail@fastertechnology.com wrote:
> >
> > We have not measured the speed of the 10/100 EMAC. There are a
number
> > of reasons to support the slower speeds that Duane Clark mentioned:
> >
> > The EMAC core is on the OPB bus, and does not use the DMA engine in
the
> > IPIF. The processor has to copy the data between the core and
memory.
> > As the reference design is supplied, the PPC is only configured to
run
> > at 66MHz.
> > The memory used in the reference design is on the OPB bus.
> > The OPB bus has burst mode turned off. (At first glance, it does
not
> > look like the OPB memory interface works with burst mode turned
on).
>
> So you chose anonymity, I can only guess that you have some relation
to
  ^^^^^^^???????
  The email I post with is real, it just gets more heavily filtered.

> the Avnet board/project from your comments. In any case, I will add a

> comment that the board and project as provided by Avnet are quite
> impressive in my opinion. And at the price, they simply cannot be
beat.
>

I agree, that is why we use them.  My list above is just a list of what
to upgrade if one wants to speed up the design.

> >
> > My guess is that the OPB EMAC was used because a real version of
the
> > core is supplied with the EDK. All of the PLB EMAC cores are
evaluation
> > versions.  You can use them in a design, but they turn themselves
off
> > after about 12 hours.
> >
>
> Actually, the OPB_EMAC core supplied with EDK is also an evaluation
> version, with the same timeout limitation.
>
> --
> My real email is akamail.com@dclark (or something like that).

John McCaskill (Really)


Article: 80402
Subject: Re: Genlock
From: "Pete Fraser" <pfraser@covad.net>
Date: Fri, 4 Mar 2005 17:57:23 -0800
Links: << >>  << T >>  << A >>

<fpgavhdl@gmail.com> wrote in message 
news:1109966827.887251.96500@g14g2000cwa.googlegroups.com...
> Thanx Again
>
> The black burst generator is both NTSC and PAL compliant...
>
> I am locking the Hsync using a PLL (external to the fpga) using a 1715
> x fh = twice 858 x fh ...which u were talking abt..
>
> I cant get the Hsnyn without jitter.

So we have a problem right from the start. I didn't know if
your jitter was in h or in sc.

> What do u mean by source?
Is it a test generator, a DVD player etc.
If it's a non-tbc'd vtr that can cause interesting problems.

>
> The output from the PLL (which is clock of frequency 1715 x fh = 27
> MHz) is then given to the FPGA. The FPGA does the Black burst
> generation...also does the subcarrier locking..where it has two modes
> of operation. One when the extrenal is given...where the Black burst
> generated locks to the external reference and the second when no
> external is given...in this case....it acts as a free running black
> burst generator. The PDF document looks really good and will be of
> great help.
>
> Let me know if u need any more details...
>

How much is the jitter? Presumably you have video coming
into an LM1881 or such like. The output of your sync stripper
will go to one input of the phase comp, and the divided VCO
(from the FPGA) will go to the other. Stick a scope on these and
measure the jitter.

What PLL chip are you using, or did you make it yourself?

The PLL should have a memory style phicomp; not xor.

How well filtered is the VCO supply?

How clean is the loop filter ground (FPGA noise)?

Is the VCO LC, XTAL or relaxation (bad)?

What is the resonant frequency and damping factor of the loop?

Are you getting pure H out of your sync stripper (i.e., check that
there is no weird stuff going on in vertical)?




Article: 80403
Subject: Re: Maximum Current utilized by Spartan-3
From: Eric Smith <eric@brouhaha.com>
Date: 04 Mar 2005 18:18:17 -0800
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> writes:
> Yeah, but what about tolerances? The 1,25V reference of the good ole LM317
> ist exactly 1,25V. Are the tolerances within the +/-5 % of the 1,2V for the
> core?

No.  The reference voltage specification for the LM317 is min 1.20V, max
1.30V (page 5 of data sheet from National, dated July 2004).  So for any
given LM317, you *might* be able to adjust to within the rating of an
XC3S (1.14V to 1.26V), or you might not.  The LM317A has a tighter
range, 1.225V to 1.270V, which is still potentially out of spec.

The only linear regulators I've found that meet the spec are either 1.2V
fixed LDO, or special low voltage LDO.

Article: 80404
Subject: Re: 100Mbps ethernet core
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 04 Mar 2005 18:21:38 -0800
Links: << >>  << T >>  << A >>
junkmail@fastertechnology.com wrote:
> Duane Clark wrote:
> 
>> So you chose anonymity, I can only guess that you have some
>> relation
> 
> to ^^^^^^^??????? The email I post with is real, it just gets more
> heavily filtered.

My apologies. Rereading things, I see I just didn't read carefully.


-- 
My real email is akamail.com@dclark (or something like that).

Article: 80405
Subject: Re: How to readback a BRAM
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 4 Mar 2005 20:17:22 -0800
Links: << >>  << T >>  << A >>
Hi,
      Is there any specific reason that u want to read back.....U told
that u have a design that writes to BRAM's..does it write data or logic
to BRAM's or else does it write the bit file into the BRAM's...If you
can elaborate ..probably I can help you ..

--
Parag Beeraka


Article: 80406
Subject: Regarding Linux on ML 310
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 4 Mar 2005 20:29:37 -0800
Links: << >>  << T >>  << A >>
Hi Everyone,
             I wanted to load linux (Montavista ) on a partition in the
Compact Flash ..and wanted to run my program after linux gets
loaded..When I see the Xilinx Linux tutorial for the ML 310..I came to
know that the two important things are -- ml310_base_bootloop.bit
(which has a bootloop in it )and the zImage.initrd.elf (the Linux
kernel as a power pc executable)...So I downloaded the bit file using
iMPACT and then started of XMD and on the command line, then  I said
..dow zImage.initrd.elf... After the on the xmd command line I said
run..But nothing changes on the minicom(terminal..because I am running
Linux).....

             Has anyone tried this sort of a thing ...If so please help
me out..

Thanks in advance 

--

Parag Beeraka


Article: 80407
Subject: Re: Displays an image in the XS Board RAM on a VGA monitor
From: "greenplanet" <greenplanet@hotmail.com>
Date: 4 Mar 2005 20:30:31 -0800
Links: << >>  << T >>  << A >>
Thanks for the replies.

What I meant is the SRAM on the XS40 board, so the vga generator
example for XS40 works the same way as the one for XSA board?  The
img2xes utility works for XS40 too?
What if I actually have a bunch of data (put them all together would
make an image I suppose), how should I store the data to the SRAM?  I
would also have to modify the vga generator example since it always
sets web = '1'?


Article: 80408
Subject: Re: How to readback a BRAM
From: jaxato@gmail.com
Date: 4 Mar 2005 22:57:59 -0800
Links: << >>  << T >>  << A >>
My design is microprocessor based, on which 8-bit binary values
representing a picture are written to some region in my block rams. I
would like to know if it is possible to extract those value by using a
program, similar to data2bram, through JTAG out from the FPGA

Jacques


Article: 80409
Subject: Tristate problem
From: varin.vahia@gmail.com
Date: 4 Mar 2005 23:01:31 -0800
Links: << >>  << T >>  << A >>
I am designing a DDR controller which runs at 133 MHz. I am trying to
synthesize  this on Spartan 3.
I am using FDDR IO and OBUFT for generation of IO signals.
Everything works fine till FFDR block. It gives proper double data rate
output. But when this goes to OBUFT, output of OBUFT is distorted. I
miss the first hald of data completely and second half is also not
stable enough.
Can anybody help me on this. How can I make this tristate buuffers
work.


Article: 80410
Subject: Re: SoC positions in Bangalore
From: reachranbir@gmail.com
Date: 4 Mar 2005 23:15:50 -0800
Links: << >>  << T >>  << A >>
why not? infact, no matter wht the cost is, once technology is mass
produced, it tends to bring down the cost. qualcomm is thinking of
doing the same in india. but before tht they need to build a team. lets
hope we get a crack team to handle this.

moreover, its not tht we are lookng for indians only. anybody may apply
for this.

cheers
Ranbir
big_in_russia@yahoo.com wrote:
> Hi Ranbir!
>
> So, are you looking for Americans to move to India? It's so great
that
> India is finally going to take care of all the engineers here who
lost
> their jobs due to outsourcing.
>
> Will I be able to afford a Qualcomm-chipset based phone with the pay
I
> get?
>
> Thanks in advance!
>
> reachranbir@gmail.com wrote in message
news:<1109664726.181045.112170@z14g2000cwz.googlegroups.com>...
> > Hi,
> > I am Ranbir from eQURA Consulting.
> > Guys, my client, which is a San Diego based wireless telecom giant.
> > They were the original inventors of CDMA technology.
> >
> > They have recently set up a next gen design centre here in
Bangalore,
> > India.
> > We are looking at various profiles, starting from frontend, backend
to
> > verification managers.
> >
> > If interested do contact me on +91 09845365740
> > ranbir@equra.com


Article: 80411
Subject: Planning to Build Complex Wireless SoC...Anybody interested??
From: reachranbir@gmail.com
Date: 4 Mar 2005 23:21:19 -0800
Links: << >>  << T >>  << A >>
Hi,
this is ranbir here. my client is plannin to build complex SoC for
their CDMA based mobile handsets. their design centre will be based in
Bangalore, India.

they are looking for an entire team for that purpose. we want frontend
design engineer, backend, physical design, verification, memory design,
rtl architects and everyting else.

anybody from any nationlity are welcome to apply.

Anybody interested??


Article: 80412
Subject: Re: SoC positions in Bangalore
From: reachranbir@gmail.com
Date: 4 Mar 2005 23:24:06 -0800
Links: << >>  << T >>  << A >>
its a strange coincidence. belive me in India also we are thikning its
not fare to do this outsouring stuff. but wht to do?? business dynamics
makes u do strange actions

regs,
Ranbir


Article: 80413
Subject: Q: state encoding in FSM for simple cases ?
From: Michel Billaud <billaud@labri.u-bordeaux.fr>
Date: 05 Mar 2005 10:55:49 +0100
Links: << >>  << T >>  << A >>

Hi, I'm discovering the wonderful world of FPGA, so please excuse the
probably stupid question and use of improper terminology.

It seems to be a trivial case of the difficult "state assignment
problem" but i must admit i'm to lazy to read the 199 pages of
http://alexandria.tue.nl/extra2/200413270.pdf now :-/)

There are 2 very simple situations in FSM
1. n-step cycle   S1 -> S2 ->  Sn -> S1 -> S2 -> ....
2. n-step, last is a sink : S1 -> S2 -> Sn -> Sn -> Sn -> Sn ...
that can be easily implemented with counters, binary, gray code,
whatever.

The question is: what's your favorite representation when you
have strong restrictions on the number of gates/FF ?

I guess everybody uses a standard binary counter for large values,
say N>1000) with initial state = 0 and last = N-1, or the other way,
but are there "good practices" for small ones ? 

Michel Billaud

-- 
Michel BILLAUD                  billaud@labri.fr
LABRI-Université Bordeaux I     tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération     http://www.labri.fr/~billaud
33405 Talence  (FRANCE)     

Article: 80414
Subject: Re: high fan out skew in v2pro
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Sat, 05 Mar 2005 17:29:48 +0700
Links: << >>  << T >>  << A >>
skherich wrote:

> I am using v2pro 100 device with core clk speed of 200 mhz and am
> running rocket io, aurora and supporting logic at 156.25Mhz.
> I am noticing unusually high skews on these clocks. here is an excerpt
> from par report.

...

> Although this skew might be for two flops which are at farthest in the
> chip and probably not in the path it still does seem mighty large. Is
> there anything we can do to reduce this skew. We are using DCM and
> these clock as well.
> 
> samir

Proper way to address these type of issues would be to partition
your design by clocks (as much as possible) and constrain each
block to a dedicated area with a floor planner.

Best Regards,
rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Article: 80415
Subject: using atmel fit2500 fitter for a atf750
From: Fernando Peral <fperalQUITALASMAYUSCULAS@patagonmail.com>
Date: Sat, 05 Mar 2005 11:50:51 +0100
Links: << >>  << T >>  << A >>
i want to program atf750  from a .tt2  file (generated from another 
vendor software). I'm trying fitters, i download  fit5.0.zip  and the 
fitters for 1500, 1502, 1508...  works well, but fit2500 which i must 
use for atf750 says "NTTAPKP.DLL   not found"   and fails.  I,ve tried 
to download and use fit2500.zip  but when i do

fit2500 -i myfile.tt2 -dev p750

it says "error cannot open .dev file p750.dev"

i,ve tried also with ablfit2500.zip   but when i install it and try to 
use says "i cant connect to the key".
i've also tried to use the p750.dev file from ablfit2500.zip with the 
fit2500.exe froom   fit2500.zip  but it says it is a wrong file.  ¿is 
there any way of using the fitter from command line or similar?

thanks

Article: 80416
Subject: Re: programming ATF750 in ABEL
From: Fernando Peral <fperalQUITALASMAYUSCULAS@patagonmail.com>
Date: Sat, 05 Mar 2005 11:53:13 +0100
Links: << >>  << T >>  << A >>


Gabor wrote:
> Fernando Peral wrote:
> 
>>I want to use ATMEL  ATF750 with ABEL, but i cant find a tool.
>>¿is there any way?
>>
>>thanks
> 
> 
> If it HAS to be Abel, your only choice is Synario.  See:
> 
> http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2755
> 
> 

but that is not synario is just a synario update ¿no?  i can't find 
atmel synario anywhere.



Article: 80417
Subject: Synthesis with EDK 6.3
From: Marco <marcotoschi@email.it>
Date: Sat, 5 Mar 2005 03:55:42 -0800
Links: << >>  << T >>  << A >>
Hallo, I have tried to export an edk project to ise, but before exporting, edk make synthesis with xst.

Into the project option I have chosen Synthesis tool: none.

Why edk make synthesis in any case?

I would make synthesis of the edk project with synplify.

Marco

Article: 80418
Subject: Re: high fan out skew in v2pro
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 5 Mar 2005 14:03:17 +0100
Links: << >>  << T >>  << A >>

"Rudolf Usselmann" <russelmann@hotmail.com> schrieb im Newsbeitrag
news:d0c1ms$as$1@nobel.pacific.net.sg...

> > there anything we can do to reduce this skew. We are using DCM and
> > these clock as well.

Hmm, are these global clock nets?

> Proper way to address these type of issues would be to partition
> your design by clocks (as much as possible) and constrain each
> block to a dedicated area with a floor planner.

Why? Arnt the global clock nets supposed to drive the WHOLE chip with low
skew (full buffered etc.) ??

Regards
Falk






Article: 80419
Subject: Re: state encoding in FSM for simple cases ?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 5 Mar 2005 14:05:43 +0100
Links: << >>  << T >>  << A >>

"Michel Billaud" <billaud@labri.u-bordeaux.fr> schrieb im Newsbeitrag
news:7zekeupgbe.fsf@serveur5.labri.fr...

> There are 2 very simple situations in FSM
> 1. n-step cycle   S1 -> S2 ->  Sn -> S1 -> S2 -> ....
> 2. n-step, last is a sink : S1 -> S2 -> Sn -> Sn -> Sn -> Sn ...
> that can be easily implemented with counters, binary, gray code,
> whatever.
>
> The question is: what's your favorite representation when you
> have strong restrictions on the number of gates/FF ?

Binary or Gray offer the highest density when it comes to FF count. Using
Toggle-FFs instead of "ordinary" D-FFs can sometimes simplify the next state
encoding logic.

Regards
Falk




Article: 80420
Subject: Re: Displays an image in the XS Board RAM on a VGA monitor
From: Dave Vanden Bout <devb@xess.com>
Date: Sat, 05 Mar 2005 13:11:07 GMT
Links: << >>  << T >>  << A >>
"greenplanet" <greenplanet@hotmail.com> wrote in 
news:1109997031.596085.165410@f14g2000cwb.googlegroups.com:

> Thanks for the replies.
> 
> What I meant is the SRAM on the XS40 board, so the vga generator
> example for XS40 works the same way as the one for XSA board?

No, the XSA VGA generator fetches image data from 16-bit SDRAM so it has 
to account for the variable arrival time of the data with a FIFO.  The 
XS40 has a static 8-bit RAM with a fixed access time so the FIFO isn't 
needed and the image path is narrower.

  The
> img2xes utility works for XS40 too?

img2xes just translates the format of common image files into the simple 
XES format.  The XES file can be downloaded into the XS40 SRAM using the 
GXSLOAD utility.  You should be able to use the img2xes options to format 
the image data for the byte-wide SRAM on the XS40.  

> What if I actually have a bunch of data (put them all together would
> make an image I suppose), how should I store the data to the SRAM?  I
> would also have to modify the vga generator example since it always
> sets web = '1'?

For writing to the SRAM:

1) Lower the RAM chip-enable and raise the output-enable.
2) Output the address and data.
3) Pulse the write-enable low and then high.

You will have to modify the VGA generator to make it release the RAM 
address, data and control pins while you do the write operations.
 


-- 
----------------------------------------------------------------
Dave Van den Bout
XESS Corp.
PO Box 33091
Raleigh NC 27636
Phn: (919) 363-4695
Fax: (801) 749-6501
devb@xess.com
http://www.xess.com


Article: 80421
Subject: Re: V4 SI: The package is thrilling Explanation of Cin
From: "Brian Davis" <brimdavis@aol.com>
Date: 5 Mar 2005 05:29:23 -0800
Links: << >>  << T >>  << A >>
Austin,
>
>>  Looking at the output waveforms shown in figure 20, my first
>> reaction was that it clearly showed that Xilinx hasn't done
>> much to improve their I/O cell capacitance [1] since V2.
>
>Why should we do that?
>

Because 10 pF and 1 Gbps are a poor match.

>
>What is it about the Cout that is such a big deal?
>

Note that I used "I/O cell capacitance" in my post as I
attempted to point out the impact on both inputs and outputs.

However, as the only parameter given in the V4 datasheets is
called Cin, I wasn't consistent in that name usage.

Hereafter I shall attempt to use C to refer to the I/O
structure capacitance, as applies to both inputs & outputs.

>
>Driving the pcb trace, and the load at the other end swamps
>the intrinsic C of the pin in almost all cases.
>

Not in my experience, particularly when dealing with
connections from 'real' 1 Gbps logic <-> FPGA

>
>To do what we do (which is more than the competitor), we
>need the silicon area.  Silicon area = C.
>

My heretical $0.02:

DCI = not worth the penalty of excess C

So ditch DCI, keep the DT terminators, and invent a controlled
slew driver with low C for the LVCMOS-ish standards.

>
>>
>>  Meanwhile, the marketeering data rate has gone from
>> "840 Mbps" for V2 to "1 Gbps" for V4.
>
>Sure has.  Works great.  Eye diagrams look fantastic (on a real
board).
>

 Where in Xilinx's V4 documentation might one find these pictures
and eye diagrams, including real world vs. simulated waveforms at
the driver, receiver, and points in between ?

>
>>  Perhaps Dr. Johnson could proffer his honest opinion of
>> a "1 Gbps" LVDS receiver with a Cin of 10 pF [2].
>
>I am sure he wioll answer that if asked in a fair and impartial way.
>

 Those 1 Gbps and 10 pF numbers are straight from Xilinx's own
V4 datasheet- I don't see how you can claim any partiality on
my part for merely pointing out your own numbers.

>
>Perhaps he will also point out that there is a lot more to the
>IO performance than just C?
>
 When have I ever claimed that it is the only factor?

 Particularly in a post where my lead-in paragraph ended with
the phrase "... which is not the whole story for high speed I/O."

>
>>  While the reduced output slew rate due to capacitive loading
>> may be of marginal "benefit" for low speed I/O standards,
>
>Ho ho ho.  That is funny.  Take the problem of slew rate out of
control,
>and try to case our C as BAD because it slows us down SO WE WORK?  Ha
ha
>ha.  I am rolling on the floor.  Be serious.  The C is what it is.  It

>does not limit performance in any way.
>
ROTFL right back at ya

>
>If all the power is in the pin C, perhaps you will see a 30%
>improvement.  Again, we may be talking less than 6 milliwatts per pin.

>Big advantage when the S2 won't work in a system.
>
>Oh my, my 72 pin bus switching at 200 MHz with 2.5V has ~430 mW more
>power than an S2......but it WORKS!
>
 I suggested this test as a quick way of verifying Altera's
claims of improved C - given 500 switching outputs, a few
points along the power vs switching rate curve should give us
something to ponder.

 I never said anything about what percentage of device power
this would represent.

 BTW, how many of those 500 outputs connect to PCB traces, how
many only to a BGA solder pad?

>
>Excuse me, the waveforms look fine. Excessive rise and fall
>times don't buy you anything but misery. HJ just proved that.
>
 Dr. J demonstrated that Xilinx's package is better.

 He did not address the issue of whether the I/O capacitance
of the V4 was amenable to 1 Gbps operation.

"Too Fast For the Package" is bad.
"Just Fast Enough" is great.
"Can't get out of my own way due to high C" is also bad.

 As these are general purpose I/O, the case of multidrop
as well as point-point needs to be considered, along
with non-FPGA 1 Gbps drivers.


>
>> C) Differential output switching would mitigate the SSO package
>>    effects somewhat as compared to single ended switching at
>>    the same rate
>
>Yes, the C is half differentially.
>

 There's more to this one than just output C ( balanced
driver ICCO; some degree of agressor cancellation ).

 If you can repeat Figure 19 with 250 LVDS/LDT type pairs
( or as many as you can fit into both devices ), that would
be an interesting comparison.

>
>>
>> D) input reflections would be worse for the Xilinx part
>>
>Yes.  But, since our termination is internal, and the driver is
>terminated, it doesn't matter.
>
>Do the simulation, the eye the receiver sees is just fine.
>Reflected signal (small) is absorbed by the transmitter, and
>does not cause distortion in the receiver.
>
ROTFL yet again

  I'll note here that, unlike the current V2/V4 material, the
old Virtex-E LVDS application notes actually addressed the issues
of C, reflections, and multidrop configurations, with waveforms
plotted at points other than only the receiver of a point-point
connection.

>
>You are not correct in assuming bad SI always results from pin C.
>

When, and where, have I EVER said that pin C is the ONLY source
of SI problems?

>
> If you terminate externally, I would agree with you.
>
BTW, thanks to Xilinx for putting those DT terminators back
into the S3E parts.

>
>We'll keep that in mind if we ever get to where we have to do
>this to meet all specs and standards.  SO far, we do
>

Long ago and far away, when discussing this for V2, I wrote:

   Although the original LVDS specification did not directly
 specify a max Cin value, newer specifications such as
 HyperTransport do; for example, HyperTransport requires a
 maximum 2pf (single-ended) Cin for receivers rated > 800 Mbps.

and also:

 See for instance Table 13, footnote 1 of XAPP622, which
 clearly states that, although tested interoperable, the
 V2 devices do not meet the rise/fall requirements of the
 SFI-4 specification


>
>> [2]  I'd be happy to quote a Cdiff instead, if someone could tell
>>   me where it is documented.
>>
>>     Ideally, the differential input model would include both
>>   the single ended shunt Cin values as well as a differential
>>   across-the-pair Cdiff, so I could model both the differential
>>   and common mode reflections.
>>
>>     If Cdiff is negligible, and the input waveform is purely
>>   differential, then Cdiff = 1/2 Cin, as Austin has argued before.
>
>Uh, last I looked at circuit theory, it is still C/2 for the diff
pair.
> It also agrees with simulations (if you instantiate the V4 receiver,
>and compare it to a circuit model of the same thing).
>

 I'm not sure exactly what you're disagreeing with here.

 I was attempting to point out that real differential
input buffers have a mix of both "shunt to plane" and
"shunt across the pair" C, the values of each I'd like
to see documented separately for modeling purposes.

 Perhaps I should have said "effective Cdiff = 1/2 Cin"
in my last sentence about the special case?

Brian


Article: 80422
Subject: simulation and real world
From: usrdr@yahoo.co.uk
Date: 5 Mar 2005 05:56:20 -0800
Links: << >>  << T >>  << A >>
Hi all,
I have write some codes about magnetic card reader and simulation
result is good so code is done. But I can't run program on the board
well. You think what kind of difference are there between simulation
and real world (board)? I use Modelsim and 95XL CPLD. What do you
recommended?
Thanks


Article: 80423
Subject: for debugging
From: usrdr@yahoo.co.uk
Date: 5 Mar 2005 05:57:58 -0800
Links: << >>  << T >>  << A >>
Also what do you recommend for debugging?


Article: 80424
Subject: Re: simulation and real world
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 5 Mar 2005 16:25:15 +0100
Links: << >>  << T >>  << A >>

<usrdr@yahoo.co.uk> schrieb im Newsbeitrag
news:1110030980.829013.17840@f14g2000cwb.googlegroups.com...
> Hi all,
> I have write some codes about magnetic card reader and simulation
> result is good so code is done. But I can't run program on the board
> well. You think what kind of difference are there between simulation
> and real world (board)? I use Modelsim and 95XL CPLD. What do you
> recommended?

Debugging??

Have a look at the IO signals form the 95 XL using a scope. Are the signals
as expected?
Have a look to internal registers, route them to unused pins (testpins)

Regards
Falk






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