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 132000

Article: 132000
Subject: Re: Spartan 3 Mapping Problem
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Fri, 09 May 2008 10:47:31 -0700
Links: << >>  << T >>  << A >>
Each of the clock signals is LOCed to a dedicated clock IO pin.

So I went in with the FPGA editor to do a little more investigation, and 
  it sure looked like I could just pipe the clock signals from their 
points of origin to the proper BUFG with no problems.  I tried LOCing 
them down in the UCF and rebuilding, and came up with the excitingly new 
error of:

---
ERROR:Place:1023 - A global clock component <INST_PLL/BUF10/BUFGMUX>
configured as a selectable mux is placed in site BUFGMUX6. This 
configuration requires that the global clock site BUFGMUX7 either be 
empty or contain a global buffer or mux with the inputs IN0 and IN1 
either not driven by a signal or driven by the same signals as the 
original muxes IN1 and IN0 pins respectively in order to route up both 
of the inputs. In other words the input signal for IN0 on one buffer 
must be the same as the input signal driving IN1 on the other buffer (or 
one of them must not be driven) to place the two buffers in the paired 
sites. The site BUFGMUX7 has the global buffer <io_clk_BUFG> placed 
there. This design is unroutable.
---

That finally gave me enough information to figure it out.

In looking a little more closely at it, the problem seems to be the use 
of a BUFGCE on the 10 MHz clock.  It looks like the Spartan requires 
adjacent pairs of BUFGMUXes to share the same two input clocks.  Trying 
to make that pair accept CLK20, CLK10, and GLOBAL_LOGIC_0 as potential 
input clocks was too much for it.  Since the logic on the CLK10 path had 
to be runt-resistant anyhow to handle the case where the 10 MHz clock 
was suddenly disconnected, I can just switch that over to a regular BUFG 
rather than a BUFGCE, and live with the runts when the clock is suddenly 
connected too.

Thanks for the help, guys.
-- Rob

Marvin wrote:
> Rob,
> 
> Did you LOC your IOs down?  Each BUFG has a dedicated IO that should
> be used.  A list of these IO locations are available from the Spartan
> 3 User Guide.  If you LOC the IO to one of the non-dedicated IOs, this
> error message will appear.
> 
> Marvin
> 
> On May 8, 4:44 pm, John_H <newsgr...@johnhandwork.com> wrote:
>> Rob Gaddi wrote:
>>
>>> Three of them (including the one throwing the error and the one with the
>>> DCM on it) are along the top of the chip (CLK4, CLK6, and CLK7 pins)
>>> The fourth is down on the bottom on CLK0.
>> <snip>
>>
>> So are you going to look into the FPGA Editor view like I suggested?
>>
>> Another question for you to ponder much more than to answer here: did
>> you instantiate the BUFGMUX primitives or are those coming from your
>> synthesizer?  It may be that you need to hook up the I1 channel rather
>> than the I0 on one or two of your BUFGMUXs to work with the routing
>> from the clock pins to the buffers... which is why I suggested looking
>> at the details of the part in FPGA Editor.
>>
>> - John_H
> 


-- 
--
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 132001
Subject: Re: Virtex XCV1000E-6FG860C
From: jon <jon@pyramidemail.com>
Date: Fri, 9 May 2008 12:14:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 8, 11:29=A0am, austin <aus...@xilinx.com> wrote:
> jon,
>
> Unauthorized distributors are likely to have slower parts re-marked as
> faster parts so they can gouge you for more money....
>
> -6 is the slowest, so maybe you won't have that problem.
>
> Or, devices that look like our parts, but are empty inside, or just
> remarked garbage (non-functional).
>
> This is the most common results we have seen when we have looked into
> these "sources."
>
> I am also concerned that we made a gift of Virtex E to Universities a
> long time ago.
>
> These devices were "not suitable for commercial use" ...
>
> Caveat Emptor!
>
> Austin

Austin,

Thanks for the heads up. I am aware of what some of these companies
are doing and have taken it to the extreme as to purchase an x-ray
machine. The parts that you donated to a University, were they
engineering samples? Do you know if the engineering samples meet full
spec?

I am very aware, but want to at least look at possible options. Do you
know of a legitimate OEM/CM that has over bought on these? You would
be helping us both out and keeping legitimate product in the
marketplace.


Regards,
Jon E. Hansen

Article: 132002
Subject: Re: Virtex XCV1000E-6FG860C
From: austin <austin@xilinx.com>
Date: Fri, 09 May 2008 13:04:17 -0700
Links: << >>  << T >>  << A >>
Jon,

I believe the parts that were donated had normal production markings.

And, no, I know of no legitimate holder of material (Xilinx does not
recognize resellers, as we have lost the chain of control), other than
our authorized distributors.

Austin

Article: 132003
Subject: Re: 5 V oscillator output to GCLK
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 10 May 2008 08:09:31 +1200
Links: << >>  << T >>  << A >>
John_H wrote:

> maverick wrote:
> 
>>Hi,
>>I am using a Spartan3 xc3s1000-4 fg456 FPGA. I have an oscillator
>>which gives clk output at 5V p-p swing.  I am using the FPGA in LVTTL
>>mode which works on 3.3 V signaling. Is it OK to feed the 5V clock to
>>one of the GCLK pins of the Spartan 3 FPGA? Should I put a current
>>limiting resistor in the clock path before I feed it to the GCLK pin?
>>Any issues with that?
>>
>>Best Wishes,
>>Farhan
> 
> 
> I just got a 3.3V oscillator driving a 2.5V input working.  The
> oscillator has miserable drive capability and I suspect the 5V
> oscillator you're using may have poor drive capability as well.
> 
> Unless you have a rare high-drive oscillator OR if you're oscillating
> at a leisurely rate, do like the FPGA vendor recommends: use a 100 ohm
> series resistor.
> 
> If you use a resistor divider, your parasitics can severely slow down
> your edges.  Our 125 MHz oscillator looked almost like a sine wave and
> was reduced in amplitude to the point we were getting 25% duty cycle.
> Not good for our application.  If it was a 20 MHz oscillator, the
> resitor divider would probably be fine.  If we could deal with 25%
> duty cycle we could have probably used what was there.  The series
> resistor just plain works.  The input protection on the Spartan3 is
> pretty robust so you can drive the many milliamps (if you have many
> milliamps) into the protection diode without affecting reliability.
> 
> If I wanted to be detailed, I'd understand the drive capability, the
> frequency, and the parasitics involved.

Or, think like a scope probe, and do a capacitive divider, That 
preserves the edges, and allows higher value resistors (so saves power)
Measure the pin/pcb capacitance, and Osc output swing, and then 
calculate the driving capacitance, likely to be in tne 30-40pF region.

Or, add a LVC1G57/58/97/98 to your parts list, and use that.

-jg




Article: 132004
Subject: Re: Anyway to secure a Xilinx NGC file ?
From: SoyAnarchisto <greg.daughtry@gmail.com>
Date: Fri, 9 May 2008 13:09:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
http://syndicated.synplicity.com/Q306/aldec.html

ngc2edif will not extract encrypted cores.

Is it perfectly secure?  I'll leave that answer as an exercise for the
reader....

'Greg

On May 9, 12:26 am, "fpganut" <r...@myhouse.com> wrote:
> Hi,
>
> Is there anyway to secure a Xilinx NGC file from being reverse engineered ?
> Xilinx has a ngc2edif  utility to convert the binary ngc file into a
> readable netlist.
> Still work of course but makes it a lot easier to copy a design.
>
> So anyway to secure a NGC file ?
>
> Thanks.
>
> Jim


Article: 132005
Subject: Re: 5 V oscillator output to GCLK
From: "David Spencer" <davidmspencer@verizon.net>
Date: Fri, 09 May 2008 20:51:02 GMT
Links: << >>  << T >>  << A >>
"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com...
>On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:

>
>> A better solution would be to feed the clock through a 3.3V buffer that 
>> is
>> 5V tolerant. An AHC family device would do the job I think. In fact, a
>> 74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
>> package.- Hide quoted text -
>

> By what measure would an IC be a "better solution" than two resistors?

> KJ

Static drive current.

Assuming the divider is matched to the impedance of the trace, as originally 
suggested, the oscillator would need to source and sink around 100 mA. 



Article: 132006
Subject: Re: 5 V oscillator output to GCLK
From: Jon Elson <elson@wustl.edu>
Date: Fri, 09 May 2008 16:33:22 -0500
Links: << >>  << T >>  << A >>


KJ wrote:
> On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:
> 
> 
>>A better solution would be to feed the clock through a 3.3V buffer that is
>>5V tolerant. An AHC family device would do the job I think. In fact, a
>>74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
>>package.- Hide quoted text -
>>
> 
> 
> By what measure would an IC be a "better solution" than two resistors?
You don't want slow clock transitions, and high drive impedances at
the receiving end.  Now, the right choice of resistors probably won't
cause such trouble, but it at least needs to be considered.  A long 
clock trace (bad idea, anyway) fed with a series resistor is essentially 
a lumped-constant low-pass filter.  I'm not sure how fast Spartan III 
is, but if the Tr got slowed to tens of nS it would be really dangerous.
Just add a little on-chip or on-board noise, and you have extra clock 
transitions.  I've seen this on a 5V Spartan setup that got its clock 
from an LVDS receiver.  Some reflections on the LVDS cable caused 
multiple clocks that the Spartan FFs responded to.  I'm sure this would 
only be more sensitive on Spartan 3.

I just did a board that had a bunch of logic turned upside down (-5 V 
and ground) and used resistive networks with matching caps across the 
series resistor to keep the edges sharp.  This had to be done some
70 places on the board, and there's no suitable chip for such a 
conversion.  It worked, but had me sweating until proven.

Jon


Article: 132007
Subject: Re: ISE 9.2 - how do I extract component/slice placements for locking
From: SoyAnarchisto <greg.daughtry@gmail.com>
Date: Fri, 9 May 2008 14:42:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
Fred,

ngd does not have placement information, I think you are referring to
ncd.  Beginning w/ ISE 10.1 PlanAhead is shipped with all versions of
ISE, including the webpack (free) version.  Prior to that PlanAhead
was a separate optional tool, but evaluation licenses are readily
available for the asking:

http://www.xilinx.com/ise/optional_prod/planahead.htm

PlanAhead is a fairly straightforward tool to use.  At a high level,
to do what you are asking:

1) download and install planAhead
2) create a project by importing an edif/ngc netlist and optionally
ucf constraints (and pick a target device if ngc).
3) File->Import Placement and browse to your placed and/or routed ncd
file

This will import placement from an ncd file and convert them to LOC
and BEL constraints.

At this point you have tons of options, depending on what you are
trying to accomplish.  You can go to File->Export Floorplan to write
out all these loc/bels into a ucf file, but a huge file of locs is of
limited use, for floorplanning, timing closure, ip reuse flows.

Take a look at the PlanAhead tutorial and methodology guides, as a
starting point.  More questions will doubtlessly follow...

'Greg

On May 9, 11:14 am, Kevin Neilson
<kevin_neil...@removethiscomcast.net> wrote:
> Fred wrote:
> > Is there any NGD reader which can extract placement information?
>
> > I know I can use FPGA editor and go through all the primitives, one by
> > one, but this would be a mamoth task!  Any ideas?
>
> Are you trying to floorplan or trying to figure out how PAR performed
> placement?  If the former, PlanAhead is a very nice tool for
> floorplanning.  -Kevin


Article: 132008
Subject: Re: 5 V oscillator output to GCLK
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 9 May 2008 15:36:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 1:51=A0pm, "David Spencer" <davidmspen...@verizon.net> wrote:
> "KJ" <kkjenni...@sbcglobal.net> wrote in message
>
> news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com...
>
> >On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:
>
> >> A better solution would be to feed the clock through a 3.3V buffer that=

> >> is
> >> 5V tolerant. An AHC family device would do the job I think. In fact, a
> >> 74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
> >> package.- Hide quoted text -
>
> > By what measure would an IC be a "better solution" than two resistors?
> > KJ
>
> Static drive current.
>
> Assuming the divider is matched to the impedance of the trace, as original=
ly
> suggested, the oscillator would need to source and sink around 100 mA.

Make that 50 mA, if the series resistor is 50 Ohm, and the parallel
destination termination another 50 Ohm.
Peter Alfke

Article: 132009
Subject: Re: 5 V oscillator output to GCLK
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 9 May 2008 18:50:15 -0400
Links: << >>  << T >>  << A >>

"David Spencer" <davidmspencer@verizon.net> wrote in message 
news:WO2Vj.1895$Uz2.1141@trnddc06...
> "KJ" <kkjennings@sbcglobal.net> wrote in message 
> news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com...
>>On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:
>
>>
>>> A better solution would be to feed the clock through a 3.3V buffer that 
>>> is
>>> 5V tolerant. An AHC family device would do the job I think. In fact, a
>>> 74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
>>> package.- Hide quoted text -
>>
>
>> By what measure would an IC be a "better solution" than two resistors?
>
>> KJ
>
> Static drive current.
>
> Assuming the divider is matched to the impedance of the trace, as 
> originally suggested, the oscillator would need to source and sink around 
> 100 mA.
>

Oscillator outputs typically can't drive PCB trace impedance types of values 
(i.e. 50-100 ohm) anyway so you wouldn't terminate it with that low of a 
resistor value.  Instead you would use something quite a bit higher so that 
you would get the edge quality that you need and the divider to limit the 
input voltage to the part.

The 5<-> 3.3V ICs are nice when you have a bunch of signals that need 
translating (like a bus) but if it's just a single net (or a small handful) 
the resistors work nicely....of course it begs the question of why not use a 
3.3V oscillator in the first place.

KJ 



Article: 132010
Subject: Re: 5 V oscillator output to GCLK
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 9 May 2008 18:50:46 -0400
Links: << >>  << T >>  << A >>

"maverick" <sheikh.m.farhan@gmail.com> wrote in message 
news:867bdf28-6f10-4dd4-a00b-dc5f9cae4de7@m44g2000hsc.googlegroups.com...
> Hi,
> I am using a Spartan3 xc3s1000-4 fg456 FPGA. I have an oscillator
> which gives clk output at 5V p-p swing.  I am using the FPGA in LVTTL
> mode which works on 3.3 V signaling. Is it OK to feed the 5V clock to
> one of the GCLK pins of the Spartan 3 FPGA? Should I put a current
> limiting resistor in the clock path before I feed it to the GCLK pin?
> Any issues with that?
>

Any reason why you wouldn't just use an oscillator that has a 3.3V swing to 
begin with?

KJ 



Article: 132011
Subject: Re: 5 V oscillator output to GCLK
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 9 May 2008 19:06:20 -0400
Links: << >>  << T >>  << A >>

"Jon Elson" <elson@wustl.edu> wrote in message 
news:4824C322.9000505@wustl.edu...
>
>
> KJ wrote:
>> On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:
>>
>>
>>>A better solution would be to feed the clock through a 3.3V buffer that 
>>>is
>>>5V tolerant. An AHC family device would do the job I think. In fact, a
>>>74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
>>>package.- Hide quoted text -
>>>
>>
>>
>> By what measure would an IC be a "better solution" than two resistors?

> You don't want slow clock transitions, and high drive impedances at
> the receiving end.  Now, the right choice of resistors probably won't
> cause such trouble, but it at least needs to be considered.

I was answering within the context of what info the original poster provided 
which was that he has a 5V signal going into a 3.3V tolerant input.  No 
mention of any other similar signals that might also be problems, or that 
the clock is a long distance away or anything, just looking for a way to use 
(for some unknown reason) a 5V osc into a 3.3V tolerant part.

> A long clock trace (bad idea, anyway) fed with a series resistor is 
> essentially a lumped-constant low-pass filter.  I'm not sure how fast 
> Spartan III is, but if the Tr got slowed to tens of nS it would be really 
> dangerous.

The same can happen with any driver.  An electrically long net will need to 
be terminated

KJ 



Article: 132012
Subject: Re: 5 V oscillator output to GCLK
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 9 May 2008 16:12:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 2:33=A0pm, Jon Elson <el...@wustl.edu> wrote:
> KJ wrote:
> > On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:
>
> >>A better solution would be to feed the clock through a 3.3V buffer that =
is
> >>5V tolerant. An AHC family device would do the job I think. In fact, a
> >>74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
> >>package.- Hide quoted text -
>
> > By what measure would an IC be a "better solution" than two resistors?
>
> You don't want slow clock transitions, and high drive impedances at
> the receiving end. =A0Now, the right choice of resistors probably won't
> cause such trouble, but it at least needs to be considered. =A0A long
> clock trace (bad idea, anyway) fed with a series resistor is essentially
> a lumped-constant low-pass filter. =A0I'm not sure how fast Spartan III
> is, but if the Tr got slowed to tens of nS it would be really dangerous.
> Just add a little on-chip or on-board noise, and you have extra clock
> transitions. =A0I've seen this on a 5V Spartan setup that got its clock
> from an LVDS receiver. =A0Some reflections on the LVDS cable caused
> multiple clocks that the Spartan FFs responded to. =A0I'm sure this would
> only be more sensitive on Spartan 3.
>
> I just did a board that had a bunch of logic turned upside down (-5 V
> and ground) and used resistive networks with matching caps across the
> series resistor to keep the edges sharp. =A0This had to be done some
> 70 places on the board, and there's no suitable chip for such a
> conversion. =A0It worked, but had me sweating until proven.
>
> Jon
When you series-terminate the driver, and parallel-terminate the
receiver, each with a resistor that equals the characteristic
impedance of the clock trace, then a fast transition sees just a
resistive divider, not a lumped capacitance.
That's the beauty of terminated transmission lines...
Peter Alfke

Article: 132013
Subject: Re: 5 V oscillator output to GCLK
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 10 May 2008 12:19:36 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> When you series-terminate the driver, and parallel-terminate the
> receiver, each with a resistor that equals the characteristic
> impedance of the clock trace, then a fast transition sees just a
> resistive divider, not a lumped capacitance.
> That's the beauty of terminated transmission lines...

That's true, until it bangs into the lumped input capacitance of the
FPGA.
You also get a voltage-loss with this focus on transmission
line matching, which might give noise margin issues, as
well as Buffer Current adders, from the lower Vih.

-jg


Article: 132014
Subject: Re: 5 V oscillator output to GCLK
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 9 May 2008 17:58:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 5:19=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Peter Alfke wrote:
>
> > When you series-terminate the driver, and parallel-terminate the
> > receiver, each with a resistor that equals the characteristic
> > impedance of the clock trace, then a fast transition sees just a
> > resistive divider, not a lumped capacitance.
> > That's the beauty of terminated transmission lines...
>
> That's true, until it bangs into the lumped input capacitance of the
> FPGA.
> You also get a voltage-loss with this focus on transmission
> line matching, which might give noise margin issues, as
> well as Buffer Current adders, from the lower Vih.
>
> -jg

Let's not forget: "Voltage loss" was the purpose of the whole
exercise...
Peter

Article: 132015
Subject: Re: 5 V oscillator output to GCLK
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 10 May 2008 14:57:13 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> On May 9, 5:19 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>Peter Alfke wrote:
>>
>>
>>>When you series-terminate the driver, and parallel-terminate the
>>>receiver, each with a resistor that equals the characteristic
>>>impedance of the clock trace, then a fast transition sees just a
>>>resistive divider, not a lumped capacitance.
>>>That's the beauty of terminated transmission lines...
>>
>>That's true, until it bangs into the lumped input capacitance of the
>>FPGA.
>>You also get a voltage-loss with this focus on transmission
>>line matching, which might give noise margin issues, as
>>well as Buffer Current adders, from the lower Vih.
>>
>>-jg
> 
> 
> Let's not forget: "Voltage loss" was the purpose of the whole
> exercise...
> Peter

I should have been clearer :
Equal Source/Load terminations will turn the 5V swing into 2.5V Hi, on a 
3.3V system.
The ideal Vih is 3.3V, (lowest power, best noise immunity), so this
is a lower Vih, which was the 'voltage loss' I was getting at.

-jg




Article: 132016
Subject: Re: 5 V oscillator output to GCLK
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 9 May 2008 20:54:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 7:57=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Peter Alfke wrote:
> > On May 9, 5:19 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>Peter Alfke wrote:
>
> >>>When you series-terminate the driver, and parallel-terminate the
> >>>receiver, each with a resistor that equals the characteristic
> >>>impedance of the clock trace, then a fast transition sees just a
> >>>resistive divider, not a lumped capacitance.
> >>>That's the beauty of terminated transmission lines...
>
> >>That's true, until it bangs into the lumped input capacitance of the
> >>FPGA.
> >>You also get a voltage-loss with this focus on transmission
> >>line matching, which might give noise margin issues, as
> >>well as Buffer Current adders, from the lower Vih.
>
> >>-jg
>
> > Let's not forget: "Voltage loss" was the purpose of the whole
> > exercise...
> > Peter
>
> I should have been clearer :
> Equal Source/Load terminations will turn the 5V swing into 2.5V Hi, on a
> 3.3V system.
> The ideal Vih is 3.3V, (lowest power, best noise immunity), so this
> is a lower Vih, which was the 'voltage loss' I was getting at.
>
> -jg

So let's reduce the series resistor at the source to 25 Ohm, and keep
the parallel termination at the destination at 50 Ohm.
That puts 2/3 of Vcc on the cable and the FPGA input =3D 3.3 V. The 25
Ohm includes the drive impedance, which might mean no external series
resistor at all...
Peter

Article: 132017
Subject: Re: 5 V oscillator output to GCLK
From: "pdudley1@comcast.net" <pdudley1@comcast.net>
Date: Fri, 09 May 2008 22:09:47 -0600
Links: << >>  << T >>  << A >>
KJ wrote:
> "maverick" <sheikh.m.farhan@gmail.com> wrote in message 
> news:867bdf28-6f10-4dd4-a00b-dc5f9cae4de7@m44g2000hsc.googlegroups.com...
>> Hi,
>> I am using a Spartan3 xc3s1000-4 fg456 FPGA. I have an oscillator
>> which gives clk output at 5V p-p swing.  I am using the FPGA in LVTTL
>> mode which works on 3.3 V signaling. Is it OK to feed the 5V clock to
>> one of the GCLK pins of the Spartan 3 FPGA? Should I put a current
>> limiting resistor in the clock path before I feed it to the GCLK pin?
>> Any issues with that?
>>
> 
> Any reason why you wouldn't just use an oscillator that has a 3.3V swing to 
> begin with?
> 
> KJ 
> 
> 

Or even better, for a little more money you could use an oscillator with 
differential LVDS or LVPECL output. Differential signalling would reduce 
jitter and EMI.

Article: 132018
Subject: udp receive problem under nios
From: "bjzhangwn@gmail.com" <bjzhangwn@gmail.com>
Date: Fri, 9 May 2008 21:40:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi ,everyone,now I use the NicheStack tcp/ip stack for sending and
receiving the udp packets, the hardware platform is as follows,cyc-II
70 ,nios-ii,lan91c111 and so on.the receive code is as follows.
void RecvData(int socket)
{
    INT8U rx_buf[1024];
    INT8U *rx_buf_pos;
    int recv_len;
    struct sockaddr_in from_addr;
    int fromLen = 100;

    rx_buf_pos = rx_buf;

    recv_len = recvfrom(socket,rx_buf,100,0,(struct
sockaddr*)&from_addr,&fromLen);
    //recv_len = recv(recv_socket,rx_buf,sizeof(rx_buf),0);
    if(recv_len == SOCKET_ERROR)
    {
        printf("Socket error!!\n");
    }
    else
    {
        printf("receive %d bytes from 192.168.1.2\n",recv_len);
    }
}
the send packet is normal but the receive code seem to be something
wrong,It doesn't work,if the packet is short the funciton doesn't have
any return,if the packet upto 1024 bytes,the console continuous print
"Your Ethernet MAC address is 00:50:04:ee:0a:0d
Static IP Address is 192.168.1.3"
Another strage phenomenon is that the tcp/ip stack will be failed to
initialize if I remove the second line in the follow task
void SSSSimpleSocketServerTask()
{
   int send_socket;
   static SSSConn conn;
   struct sockaddr_in far_addr;
   struct sockaddr_in local_addr;
   int recv_socket;
............................
}
And the conn is not used in this task,I don't know why,all the data
code is changed based the simple socket server demo code.
Can anyone give any advice,Thanks!

Article: 132019
Subject: Re: Problem writing quadrature decoder
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 09 May 2008 20:57:34 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
(snip, I wrote)

>>I like the clocked design that Peter A. has in another post.
>>I believe that one works as long as the clock is faster than
>>the fastest possible real count.  Bounces might be missed, but
>>the count will be right.

> Bounces should (or must) be missed..
> That's the whole purpose of the circuit  .:-)

If it bounces long enough, up to the next clock pulse,
it won't be missed.   As long as the extra counts come
in matched (up and down) pairs, the count is right.

-- glen


Article: 132020
Subject: Re: Anyway to secure a Xilinx NGC file ?
From: "fpganut" <rats@myhouse.com>
Date: Fri, 9 May 2008 22:41:43 -0700
Links: << >>  << T >>  << A >>

"austin" <austin@xilinx.com> wrote in message 
news:g022gp$p032@cnn.xsj.xilinx.com...
> Jim,
>
> Copying the bitstream is trivial, so why bother with the NGC?

  Copying is fine. I don't care about copies.

>
> What is the vulnerability you are analyzing?

   I have some circuits implementing some unique algorithms. I  don't want 
someone to figure out
  the algorithm by extracting the circuit and figuring out how it operates.

>
> Who is your threat? (a major government, or an individual hacker...)

   A motivated competitor.

   Thanks.

 Jim

>
> Not knowing what you are trying to protect (and why), we can't provide
> you with an answer.
>
> Austin 



Article: 132021
Subject: Conversion from VERILOG READMEMB to INTEL HEX
From: "beky4kr@gmail.com" <beky4kr@gmail.com>
Date: Sat, 10 May 2008 01:25:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
Conversion from VERILOG READMEMB to INTEL HEX

http://bknpk.no-ip.biz/readmemb_to_intel_hex/readmemb_to_intel_hex.html

Article: 132022
Subject: Re: 5 V oscillator output to GCLK
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 10 May 2008 20:37:53 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> On May 9, 7:57 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>Peter Alfke wrote:
>>
>>>On May 9, 5:19 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>>wrote:
>>
>>>>Peter Alfke wrote:
>>
>>>>>When you series-terminate the driver, and parallel-terminate the
>>>>>receiver, each with a resistor that equals the characteristic
>>>>>impedance of the clock trace, then a fast transition sees just a
>>>>>resistive divider, not a lumped capacitance.
>>>>>That's the beauty of terminated transmission lines...
>>
>>>>That's true, until it bangs into the lumped input capacitance of the
>>>>FPGA.
>>>>You also get a voltage-loss with this focus on transmission
>>>>line matching, which might give noise margin issues, as
>>>>well as Buffer Current adders, from the lower Vih.
>>
>>>>-jg
>>
>>>Let's not forget: "Voltage loss" was the purpose of the whole
>>>exercise...
>>>Peter
>>
>>I should have been clearer :
>>Equal Source/Load terminations will turn the 5V swing into 2.5V Hi, on a
>>3.3V system.
>>The ideal Vih is 3.3V, (lowest power, best noise immunity), so this
>>is a lower Vih, which was the 'voltage loss' I was getting at.
>>
>>-jg
> 
> 
> So let's reduce the series resistor at the source to 25 Ohm, and keep
> the parallel termination at the destination at 50 Ohm.
> That puts 2/3 of Vcc on the cable and the FPGA input = 3.3 V. The 25
> Ohm includes the drive impedance, which might mean no external series
> resistor at all...
> Peter

Yes, that would work, However....

# You are no longer doing strict series-impedance-match termination
# One can tell you are used to high-power FPGAs ;)
  - as this sugestion adds a cost of 33mA in power budget (@50% clk duty 
cycle).

Suppose the target was a Zero power CPLD ?
The whole device Icc might be 14.6mA at 200Mhz - 7.5mA @ 100MHz.
[OP did not mention speed, but 5V sources are << 100Mhz ]

The clock-terminator is consuming far more power than the CPLD !

-jg




Article: 132023
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 10 May 2008 20:45:07 +1200
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:

> Peter Alfke wrote:
> (snip, I wrote)
> 
>>> I like the clocked design that Peter A. has in another post.
>>> I believe that one works as long as the clock is faster than
>>> the fastest possible real count.  Bounces might be missed, but
>>> the count will be right.
> 
> 
>> Bounces should (or must) be missed..
>> That's the whole purpose of the circuit  .:-)
> 
> 
> If it bounces long enough, up to the next clock pulse,
> it won't be missed.   As long as the extra counts come
> in matched (up and down) pairs, the count is right.

Correct. Peter has published a partial VHDL source, and
the design he is talking about uses what I'd call an 
anti-Chatter-Filter, which is a back-lash state
engine that uses hand-over edges.

That could be a good idea on a user-interface,
(less flicker effects) but could be a bad idea
on a closed loop control system driven from a rotary encoder.

-jg


Article: 132024
Subject: USB full speed final project proposal
From: "beky4kr@gmail.com" <beky4kr@gmail.com>
Date: Sat, 10 May 2008 01:48:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
I invite you to use free code of a USB full speed project as final
work for diploma.

The site includes some description of the functionality and main state
machines.

The code is based on some free cores 8051 and USB function. The PHY is
my own code.

http://bknpk.no-ip.biz/usb_invitation_for_final_pj.html



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