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 101400

Article: 101400
Subject: Re: design optimization
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 30 Apr 2006 09:19:38 -0700
Links: << >>  << T >>  << A >>
How can we possibly help you, when we know nothing about your design?
Peter Alfke


Article: 101401
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 30 Apr 2006 19:11:21 +0200
Links: << >>  << T >>  << A >>
"Hans" <hans64@ht-lab.com> schrieb im Newsbeitrag 
news:h_%4g.4329$ca3.3138@newsfe5-gui.ntli.net...
> Hi Antti,
>
> What about morse code to give the status?
>
> I should have some code in VHDL which I will dig out and send to you,
>
> Regards,
> Hans
> www.ht-lab.com

Hi Hans,

yes VHDL based morse message could be added, I think I had something some 
while ago, but not sure if I can dig that out, so if you find I will look 
it.

I have been actve on short-waves ages ago so Morse of course popped up in my 
mind too, well its of course easier to implement with some small soft-core 
processor, but plain HDL version could also be a nice example

Antti 



Article: 101402
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: Austin Lesea <austin@xilinx.com>
Date: Sun, 30 Apr 2006 10:30:52 -0700
Links: << >>  << T >>  << A >>
.-  -.  -  -  .-

.--  .  .-.  .    -.--  ---  ..-    .-    ....  .-  --     ..--..

.-  ..-  -....  ...-  ..-


Article: 101403
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: John_H <johnhandwork@mail.com>
Date: Sun, 30 Apr 2006 18:04:09 GMT
Links: << >>  << T >>  << A >>
Responses embedded - this is to underscore why I don't believe the 
information has been adequately digested, not because I feel an 
arguement is necessary.  Trivial aspects of the design are not properly 
documented - that's been admitted - but the corrections have not been 
brought to our attention.  So - trivially - what *did* I need to know 
about the JTAG interface that would have saved about 50 engineering 
hours and a change to a board that would have gone through a spin 
anyway?  I'd sure like to know in case I end up designing with that part 
instead of the two XC3S1600Es on an upcoming board.

Peter Alfke wrote:
> John, this is analog territory, and there is NOT just ONE right answer.

This could be digital territory but the analog aspects - pullups that 
are unaffected by HSWAP_EN - are forced upon the designers for pins - 
such as the JTAG - that no engineer should suspect would be pulled up by 
the silicon.

> Obviously, a short circuit will always work, if you never need the pin
> for any other purpose.
>    But we will not force you to do that, since you may have reasons not
> to like it. It's a free country!
>    There is no mystery here, the purpose is only to establish a High
> logic level. Nothing more, nothing less.
> Obviously, a built-in pull-up resistor will establish a High logic
> level, but it might be sensitive to crosstalk coming from your
> pc-board..

And the Spartan3 devices have an explicitly low pullup impedance that 
should be virtually immune to any crosstalk that's applied to an 
unconnected pin.  I'd expect the antenna of connecting a 10 kohm 
resistor to the internal 3 kohm pullup would introduce more noise than 
leaving the pin unconnected.

> Obviously, any external resistor reduces the pull-up impedance, and
> improves the situation.
> Obviously an external pull-down resistor must be low enough in value to
> overcome the internal pull-up resistance.
> 
> And I still favor a multimeter for getting a grip on fundamentals.

A multimeter is nice if a board that *isn't* strapped to VCC or GND is 
readily available - not usually the case when someone's designing their 
first board with this series of devices - but it still provides only an 
order of magnitude idea of what's happening on the pin.  Tolerances on 
pullup and pulldown currents don't need to be tight so they aren't.  I 
*will not* design a production board that relies on measurements to 
determine acceptable operation.  The silicon *must* be tested to analog 
parameters that will guarantee operation in the board environment I 
design to.

> I am all for clear documentation, but it never hurts to keep the
> engineering mind alive.

An engineering mind is of little use when you have to submit to a design 
review with other engineers - some of which haven't designed with the 
device or know the documentation as thoroughly as someone who has - and 
must have documentation to support any action items produced from the 
review.

> Compared to multi-gigabit receiver issues, this mode-pin level debate
> is really a trivial subject. 
> 
> Peter Alfke

Trivial subjects deserve trivial answers.  There have been no answers 
that I have seen in these threads.
_____

Will the mode pins which appear to always have external pullups 
independent of the HWSWAP_EN pin behave fine when no external resistors 
are connected?  Will the ~3kohm equivalent pullup impedances in 
unconnected pins work *just as well* or better than an external 4.7kohm 
pullup resistor to an imaginary mode pin with no internal pullup?

If the answer is "sure, no problem" where do we assure the fellow 
engineers that the pins will behave properly on power up (e.g., once the 
POR thresholds are passed, will those internal pullups have the full 
logic level established with internal pullups)?  Is there a design issue 
such that POR from external pullups of nominal impedance willnot produce 
valid operation?  Where could I possibly devine what the minimum 
pulldown resistor is to establish guaranteed behavior allowing an 
external jumper to change the mode pins?

These are trivial issues.  With no documented answers.  The last request 
from rickman was specifically - quoted in full:

rickman wrote:
 > People here are driving me crazy insisting that the Xilinx factory has
 > told them that you *MUST* tie the mode pins to either Vaux or GND.
 > After finding all the info in the data sheet and talking with support,
 > it looks pretty clear to me that the S3 parts have a very stiff
 > internal pull up and there is no need for an external pull up of any
 > kind, resistor or direct connection to Vaux.
 >
 > Am I misunderstanding?  Why did the factory tell us before that the
 > mode pins *MUST* be tied to Vaux?  Did we misunderstand what they were
 > saying?
 >
 > I promise this is the last time I will ask about this.  I am totally
 > sick of going around this loop with everyone here.

Do you believe that the trivial answer *has* been fully illustrated by 
Steve Knapp or others in these threads?

There isn't a great desire to spend time and attention to trivial 
matters when there are problems like Multi-Gigabit transceivers out 
there.  If we lose the trivial details, we lose the ability to design 
for error free production because of trivial misunderstandings.

All ricman wants is to get the fellow engineers off his back on a 
trivial issue.  All I want is an understanding of how the pins behave 
that I connect for "trivial" functionality such as the JTAG pins that I 
*could not configure* to operate as part of a chain - I had to give the 
Spartan3 its own chain.  The problems I had are probably trivial but I 
was unable to work past them without extreme measures.

Article: 101404
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 30 Apr 2006 20:04:35 +0200
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
news:e32s8f$cvm2@xco-news.xilinx.com...
> .-  -.  -  -  .-
>
> .--  .  .-.  .    -.--  ---  ..-    .-    ....  .-  --     ..--..
>
> .-  ..-  -....  ...-  ..-
>
ROTFL !

i did think f**** windows has trouble refreshing screen, so I closed and 
opened this email many times.
in the hope it would display the fonts properly - morse code !!!

A N T T A
W E R E   Y O U  A H  A M ?
A U 6 V U

uh? I probably need morse-classes to decode the message properly :)

Antti 



Article: 101405
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 30 Apr 2006 20:09:08 +0200
Links: << >>  << T >>  << A >>
"Ben Twijnstra" <btwijnstra@gmail.com> schrieb im Newsbeitrag 
news:4e4cb$4454abc7$d52e23a9$4555@news.chello.nl...
> Hans wrote:
>
>> Hi Antti,
>>
>> What about morse code to give the status?
>>
>> I should have some code in VHDL which I will dig out and send to you,
>>
>
> Best to then blink the Morse dots using PWM at 1KHz and 50% duty cycle so
> that you can also hear it with a solar cell and a piezo earpiece ;-)
>
> Ben

HAHA - I was going to reply that the LED is SMD 0603 so connecting beeper in 
parallel would not make sense, but then hum solar cell !!

hum, interesting would it actually work? I bet not the solar cell possible 
would not deliver AC or would it? I am almost tempted to test!

well the LED on board will be possible cheapest one available (around 0.01 
USD from HK) so it will not have many mcd, but the LED + solar cell idea is 
something that could be even used for some weird application.

Antti



Article: 101406
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: John_H <johnhandwork@mail.com>
Date: Sun, 30 Apr 2006 18:15:48 GMT
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Jim, please give us the benefit of the doubt, that we are not totally
> stupid.
> The mode pins are of interest at the very beginning of the
> configuration process.
> That's obviously when the pull-ups are active.
> I do not know when they are being de-activated, but trust us that they
> are active when it matters.

But is that if externally strapped to ground as someone at the factory 
appears to have informed rickman's group or unconnected such that the 
internal pullups guarantee operation all the time?

> We have 22 years experience in this technology, and have shipped many
> hundreds of millions of FPGAs...
> But you are right, there is always an opportunity for better
> documentation.
> Remember: This whole lengthy discussion never mentioned a technical
> problem or malfunction, only a diversity of suggestions, all of them
> correct.

The discussion has a technical problem as the source.  His steps may be 
slightly different but in my ISO9000 dictated compliance from years ago, 
if a design review produces an action item that says "check if the mode 
pins must be strapped to the rails directly because I saw that done on a 
Xilinx official application note" then that item must be followed up 
with a documented response providing evidence to address the original 
concern.

This technical problem - guaranteeing the design will operate as 
expected to the satisfaction of picky reviewers - cannot be addressed 
with the information at hand either through the data sheets, the FAE 
(incorrect info - we're all human), or through this forum.

> 
> Peter Alfke, Xilinx, from home

- John Handwork
Exclusively Xilinx for 8 years now

Article: 101407
Subject: Re: design optimization
From: "Rob" <robnstef@frontiernet.net>
Date: Sun, 30 Apr 2006 18:18:29 GMT
Links: << >>  << T >>  << A >>
Aren't you and Xilinx developing a new line of FPGA's called "The Crystal 
Ball Series"?  Parallel psychic processing that transcends the sphere of 
phsyical science or knowledge.

Sorry, I couldn't resist.


"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1146413978.650624.70750@i39g2000cwa.googlegroups.com...
> How can we possibly help you, when we know nothing about your design?
> Peter Alfke
> 



Article: 101408
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 30 Apr 2006 20:21:42 +0200
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
news:44548f48@clear.net.nz...
> Antti Lukats wrote:
>
>> Hi all
>>
>> I am looking for ideas for: "FPGA Single LED Demos", The requirements for 
>> the demo Application are following:
>>
>> * Display visible 'sign of live' or 'self-test passed' message
>> * Impemented in FPGA Vendor neutral HDL
>> * <= 3000 LUT
>> * <= 4KB of Block RAM
>> * uncalibrated (+-50%) high frequency oscillator
>> * 1 user LED for display
>>
>> The Demo application should have some sort of LED visible 'message' to 
>> indicate the demo is working or has passed internal self test code. There 
>> is no user interface byeound one single LED.
>  Most obvious is to extend to a BiColour LED, Driven from 2 pins, so
> that you can generate : Pure RED, Modulated RED (OE), Pure GREEN,
> Modulated GREEN (OE) and Colour Modulated (PWM %R/100-% G)
> Control lines are : R, R.oe, G, G.oe
>
dual color SMD led costs 10 times as much as single color and the layout
isnt so standard and I have some pre-series PCBs with only one LED
already. Sure dual color LED would have more possibilities for visual 
effects

>  Then at eye-ball rates, you can signal something over 4 states, without
> needing long dividers.
>
> [Well, yes, this is only partially vendor neutral: it works on all those 
> vendors who actually gave this some thought, and installed a BiColour 
> LED ]
>
>  My preferred modulation is PDM (Rate Multiplier), rather than PWM : PDM 
> uses the least resource in CPLDs, and filters better in DAC applications.
>
could you elaborate on this? I had delta-sigma DAC already on my list
that is pulse density modulation - but you are referring to something else?

>  Also not on your list, is a RC5 / manchester Encoded LED modulate.
> Target the std IR-Remote Receivers, perhaps with an IR led in Parallel
> if the RED energy is too low to activate a NearBy - StdIR RX unit.
>
>  That allows actual BIT serial (status flags) info to be sent, into a 
> simple receiver.
>
>  One-Wire encoding is another way to send Freq tolerant information,
> in an easily decoded manner.
>

Actually one-wire comm requires known frequency reference better than
I can count for, also in my  requirements was no other interface (than LED)

>> Best ideas can be rewarded with an FPGA evaluation board (with your idea 
>> pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not 
>> count.
>
> -jg
>
I was possible giving not enough information at first place - the module in 
question
has actually 3 interfaces with 6+6+4 (shared with JTAG pins in parallel) 
I/O's
one of them can be used for block transfers to host with up to 6MByte/S

However any communication with host would require some software on the
host what may not exist for the host platform, so I was looking for demos
that can be 'tested' for simple 'it blinks, ít works' in the case we assume
there host communication is unavailable - similarly any demos requirying
additional hardware ae beyound the scope, dual color, tri-color led
buzzer, IR tranceiver are all things that could be used, - with extra
add-on modules.

I was more looking for more ideas to demonstrate things that an
FPGA can do, it could be some algorithm that is processed once
or in a look and if the self check result is ok then blink a led.

Just to have people a way to 'seeing is beliving' want to test
this or that, download this, when LED blinks then it is signal
that this or that works - in real hardware.

Antti



























Article: 101409
Subject: Re: design optimization
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 30 Apr 2006 20:39:53 +0200
Links: << >>  << T >>  << A >>
<harikris@gmail.com> schrieb im Newsbeitrag 
news:1146413671.605299.107260@v46g2000cwv.googlegroups.com...
> Hi,
>
> I am targeting the design for XC2C512 coolrunner device. That's the
> biggest device i could find. Are you aware of any larger CPLD device?
> I have a dual-edge triggered clock i.e i have no other CPLD choice
> other than the coolrunner series.
>
> I find that i am falling short of a dozen macrocell counts. The
> fitter report says it needs 524 macrocells and i have 512 macrocells
> available to me :-(
>
> I have tried to optimize the design to my best possible knowledge (and
> my knowledge is not that profound).
>
> Can anybody here advise me on how to squeeze the design a LITTLE BIT
> more
> to make it fit into the XC2C512 device?
>
> Thanks.
>
there are almost no generic rules, but specially for PLDs the design for PLD 
optimization
can yield in huge macrocell reduction.

if your current count is 524, then I would say with 99.9% that the desing 
can be made
fit into 512 unless you have already spent over one man-month in PLD 
specific optimization
to get the MC count down to 524.

the easiest way to find some resources is to find some block that are never 
active at same time
and use 1 extra MC to flag for resource sharing

as example if you need counter and shift register but not at the same time 
then almost all
MCs uses in counter and shift register could be shared.

besides that there are pretty many things for PLD that can influence the 
design fit, but again
no golden rule for you, its all design specific and based on general 'it 
doesnt fit' there is
little help that could be given to you

Antti










Article: 101410
Subject: Re: Xilinx PROM
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 30 Apr 2006 11:40:54 -0700
Links: << >>  << T >>  << A >>

maxascent wrote:
> I may have overlooked something but I cant seem to find the dimensions of
> the platform flash PROM in a FS48 package. I have the datasheet but it
> appears not to be in it. Also had a look on the Xilinx website but again
> no luck. Can someone point me to the right place?
>
> Cheers
>
> Jon

Try this link to the package drawing.
http://www.xilinx.com/bvdocs/packages/fs48.pdf

-- Steve Knapp


Article: 101411
Subject: Re: design optimization
From: Kolja Sulimma <news@sulimma.de>
Date: Sun, 30 Apr 2006 20:53:05 +0200
Links: << >>  << T >>  << A >>
Rob schrieb:
> Aren't you and Xilinx developing a new line of FPGA's called "The Crystal 
> Ball Series"?  Parallel psychic processing that transcends the sphere of 
> phsyical science or knowledge.

How dare you write this in a newsgroup?
I had to sign an NDA on that topic.

Kolja Sulimma

Article: 101412
Subject: Re: design optimization
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 30 Apr 2006 21:01:01 +0200
Links: << >>  << T >>  << A >>
"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag 
news:44550796$0$4514$9b4e6d93@newsread2.arcor-online.net...
> Rob schrieb:
>> Aren't you and Xilinx developing a new line of FPGA's called "The Crystal
>> Ball Series"?  Parallel psychic processing that transcends the sphere of
>> phsyical science or knowledge.
>
> How dare you write this in a newsgroup?
> I had to sign an NDA on that topic.
>
> Kolja Sulimma

is there an April joke somewhere? 'Crystal Ball' !?

Antti 



Article: 101413
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 01 May 2006 07:52:53 +1200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
>> Most obvious is to extend to a BiColour LED, Driven from 2 pins, so
>>that you can generate : Pure RED, Modulated RED (OE), Pure GREEN,
>>Modulated GREEN (OE) and Colour Modulated (PWM %R/100-% G)
>>Control lines are : R, R.oe, G, G.oe
>>
> 
> dual color SMD led costs 10 times as much as single color and the layout
> isnt so standard and I have some pre-series PCBs with only one LED
> already. Sure dual color LED would have more possibilities for visual 
> effects

But costs a tiny fraction of the PCB / FPGA price, which is
what actually matters ?

>> My preferred modulation is PDM (Rate Multiplier), rather than PWM : PDM 
>>uses the least resource in CPLDs, and filters better in DAC applications.
>>
> 
> could you elaborate on this? I had delta-sigma DAC already on my list
> that is pulse density modulation - but you are referring to something else?

  It is probably the same thing, if your delta-sigma is PDM.
I am used to delta-sigma having a feedback loop of some sort, so I avoid
that term.
  The PDM we use is the same as the venerable Rate Multipliers
( 4089, 4527 IIRC) and they use one PT per resolution bit.
PWM compares need two, unless hand-coded.


>> Also not on your list, is a RC5 / manchester Encoded LED modulate.
>>Target the std IR-Remote Receivers, perhaps with an IR led in Parallel
>>if the RED energy is too low to activate a NearBy - StdIR RX unit.
>>
>> That allows actual BIT serial (status flags) info to be sent, into a 
>>simple receiver.
>>
>> One-Wire encoding is another way to send Freq tolerant information,
>>in an easily decoded manner.
>>
> 
> Actually one-wire comm requires known frequency reference better than
> I can count for, also in my  requirements was no other interface (than LED)

You would use optical pickup, so are outside the "Mk1 EyeBall", but the
functions can be stacked on the LED.
One wire systems are usually PWM coded, so autobaud ?

> Just to have people a way to 'seeing is beliving' want to test
> this or that, download this, when LED blinks then it is signal
> that this or that works - in real hardware.

Always a good idea.

-jg


Article: 101414
Subject: Re: design optimization
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 01 May 2006 08:00:56 +1200
Links: << >>  << T >>  << A >>
harikris@gmail.com wrote:

> Hi,
> 
>  I am targeting the design for XC2C512 coolrunner device. That's the
> biggest device i could find. Are you aware of any larger CPLD device?

There are plenty :
Lattice MachXO, Altera MAX II are the 'new designs' arena,
Lattice & Actel also have FLASH FPGAs, and lattice have older
CPLD families that are > 512 MCells, but their price/ability point
is probably not ideal these days.

> I have a dual-edge triggered clock i.e i have no other CPLD choice
> other than the coolrunner series.

See other threads, on how to create Dual Edge using two single edge 
FF+XOR. Plus, you can always clock double, or use a PLL.

> 
>  I find that i am falling short of a dozen macrocell counts. The
> fitter report says it needs 524 macrocells and i have 512 macrocells
> available to me :-(
> 
>  I have tried to optimize the design to my best possible knowledge (and
> my knowledge is not that profound).
> 
> Can anybody here advise me on how to squeeze the design a LITTLE BIT
> more to make it fit into the XC2C512 device?

  Scan thru the FIT RPT file, and look at your modules, for resource 
usage. Sometime it is easier to compile portions of the design, and
paste those summaries, then scan them with your eye and a pencil, for
ones that use more that their 'fair share' of resource.
  A small change in HDL coding can give a big change in resource.

-jg


Article: 101415
Subject: OPB Clocking Question
From: "motty" <mottoblatto@yahoo.com>
Date: 30 Apr 2006 13:01:38 -0700
Links: << >>  << T >>  << A >>
I am working with an embedded MicroBlaze project that has multiple
Xilinx cores and multiple custom IP cores.  The FPGA hardware is used
to interface to our comapanie's "parts".  Some of the custom core
functionality includes serial communications interfaces and special
time-critical data interfaces.  We have two "flavors" of parts that the
FPGA hardware has to support.  Each part outputs a reference clock that
we want to use inside the FPGA.  However, each part outputs a different
clock frequency.  I am working on reconciling the FPGA hardware in
order to run both parts with the same FPGA build.

The clock from the part is used to clock our custom IP modules.  The
timing of the modules is derived from those clocks and works out
nicely.  However, one of the part's clocks needs to be used at 1X
fequency, the other at 2X.

My first thought is to use the input clock from the part, which would
be one of two different values, and route that to a DCM.  Then I would
use the 1X and the 2X output of that DCM.  Both outputs would be fed to
an OPB software controlled mux.  I forgot to mention that we also have
an on-board xtal that is currently used for ALL the clocking needs of
the FPGA.  We run it at one of the part's frequencies so it is fine.
But a new part, with a new clock, is coming out that we have to
support.  So the one clock solution will not work for both.  I am
rambling...

Anyways, I am thinking of using the xtal to feed a DCM that will derive
a clock that will drive the MicroBlaze, the Xilinx OPB cores, and the
above-mentioned clock switching mux.  My concern is with driving the
OPB clock inputs on different cores with two different clocks.

Out cores would be driven by one of the two clocks selected from the
mux.  The xilinx OPB cores would be driven by the xtal DCM clock.  Is
it OK to do this?  Do I have to consider clock domain issues when doing
this?  

Thanks!


Article: 101416
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 30 Apr 2006 13:10:58 -0700
Links: << >>  << T >>  << A >>
Peter-

> Compared to multi-gigabit receiver issues, this mode-pin level debate
> is really a trivial subject.

I think that type of thinking shows a problem.  Engineers can't use
your devices if they a) can't trust your documentation, b) can't get a
straight answer from Xilinx experts to augment the documentation in an
official and formal manner that stands up to design review, and c) have
to spend weeks messing around with configuration just to get the part
up and running before they can even try advanced features.

I would turn this around and say:  if you can't handle basic
configuration issues, then how can you be trusted to handle MGT issues?

What happens when you next decide that inner workings of a BUFGMUX are
"trivial"?  I can't get a straight answer on that either.

I always worried important Xilinx people were thinking like this.
Please I hope it's not really the case.

-Jeff


Article: 101417
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Sun, 30 Apr 2006 22:43:18 +0200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> HAHA - I was going to reply that the LED is SMD 0603 so connecting beeper
> in parallel would not make sense, but then hum solar cell !!
> 
> hum, interesting would it actually work? I bet not the solar cell possible
> would not deliver AC or would it? I am almost tempted to test!
> 
> well the LED on board will be possible cheapest one available (around 0.01
> USD from HK) so it will not have many mcd, but the LED + solar cell idea
> is something that could be even used for some weird application.

Some twenty-five years ago I used to be able to 'hear' the brightness on the
television by the volume of the 50Hz hum if I pointed a solar cell at the
screen at close range (10-20cm). The solar cell was a cheap single-cell
thingie bought at Tandy/Radio Shack, so if solar cell efficiency has made
any sort of improvement in the last quarter-century, this might actually be
viable.

Best regards,



Ben


Article: 101418
Subject: Re: Xilinx PROM
From: "Gabor" <gabor@alacron.com>
Date: 30 Apr 2006 14:44:31 -0700
Links: << >>  << T >>  << A >>

Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
> maxascent wrote:
> > I may have overlooked something but I cant seem to find the dimensions of
> > the platform flash PROM in a FS48 package. I have the datasheet but it
> > appears not to be in it. Also had a look on the Xilinx website but again
> > no luck. Can someone point me to the right place?
> >
> > Cheers
> >
> > Jon
>
> Try this link to the package drawing.
> http://www.xilinx.com/bvdocs/packages/fs48.pdf
>
> -- Steve Knapp

In another thread you asked for feedback on documentation.
Not including packaging in the main datasheet is very bothersome.
Almost everyone else in the chip industry puts packaging at
the end of the part datasheet.

Just my 2 cents
Gabor


Article: 101419
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 30 Apr 2006 14:54:21 -0700
Links: << >>  << T >>  << A >>
Let me repeat:
If you want a mode pin to be interpreted as all High, you can do one of
three things, and all are correct:
1. do nothing
2. use external pull-up of any value
3. strap to Vcc

If you want a mode pin to be interpreted as Low, do one of two things:
1. strap to ground
2. use a resistor of 330 Ohm or lower to ground.

The mode pins have an internal pull-up resistor during configuration.
Once  the FPGA has been powered up, and the configuration memory has
been cleared, the INIT pin goes High, and this Low-to-High transition
on INIT samples the levels on the mode pins. At any other time,
(earlier or later) the levels on the mode pins are irrelevant to the
FPGA configuration process, or to its operation.

For people who prefer not to think, we can also be dictatorial:
"You must strap mode pins to either Vcc or ground."
It sure works 100% of the time, but it is not the only possible way.

This has been described in many generations of Xilinx data books, ever
since I was responsible for them in the late 'eighties and early
'nineties, and the behavior of the mode pins never changed in our
18-year history.
Peter Alfke


Article: 101420
Subject: Microblaze GPIO (basic) question
From: "jmariano" <jmariano@ualg.pt>
Date: 30 Apr 2006 16:07:32 -0700
Links: << >>  << T >>  << A >>
Dear All,


For my application, I'm using a Spartan-3 Starter Kit Board, with a
microblaze microcontroller
(uart, timer, bram, etc).

I need the microcontroller to control a few digital lines connected to
somme discrete logic on
the outside of the board. As far as I can understand, and since those
lines don't need to be
fast, the easiest way is to hook them on the OPB via a GPIO module. My
question is how to do
that.

I think I wave to create a custom OPB peripheral using the XPS wizard,
and then edit the
created VHD files, as it is donne for a "regular" IP, but in this case
connecting the
registers directly to signals, noting more, but i'm not sure. Is this
correct?  Can anyone
direct me to a tutorial.

Tank you very much

jmariano


Article: 101421
Subject: Re: design optimization
From: harikris@gmail.com
Date: 30 Apr 2006 16:12:35 -0700
Links: << >>  << T >>  << A >>
Hi Lukats/Jim,

 Thanks for the sugggestions. I will work on those lines.
 I have not spent nearly a day thus far to try fit the design and your
comments seem to be encouraging.

 Thanks.


Article: 101422
Subject: Re: Microblaze GPIO (basic) question
From: "motty" <mottoblatto@yahoo.com>
Date: 30 Apr 2006 16:28:04 -0700
Links: << >>  << T >>  << A >>
Using the EDK you can just add a GPIO module to your project and
connect it how you want to.  the module is parameterized so you can
specify how many lines you need.  After that, you have to use the
Xilinx provided drivers to "talk" to the core via software.  I assume
you know C or C++.  It is not my strong suit by any means.  Someone
else in my group does that part of the project!  But I know from
looking that there are functions you call to set the direction of the
lines and to set bits high or low (in essence, making that GPIO line
high or low).  You access the core using the address generated by the
EDK and software pointers (at least that is how we do it).  Basically,
you will read and write to the GPIO address to control the actual lines
of the device, which will be added to your external port list and
connected to your outside logic.

I am sure that there is documentation in the EDK installation directory
that will go in to this in detail.  Since you mentioned you are using
the UART, Timer, etc. I assume that you know the nitty gritty of the
programming side.

Hope that helps some!


Article: 101423
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 30 Apr 2006 17:03:44 -0700
Links: << >>  << T >>  << A >>
On 30 Apr 2006 06:34:15 -0700, "rickman" <spamgoeshere4@yahoo.com>
wrote:

>John Larkin wrote:
>> On 28 Apr 2006 11:30:00 -0700, "rickman" <spamgoeshere4@yahoo.com>
>> wrote:
>>
>> >People here are driving me crazy insisting that the Xilinx factory has
>> >told them that you *MUST* tie the mode pins to either Vaux or GND.
>> >After finding all the info in the data sheet and talking with support,
>> >it looks pretty clear to me that the S3 parts have a very stiff
>> >internal pull up and there is no need for an external pull up of any
>> >kind, resistor or direct connection to Vaux.
>> >
>> >Am I misunderstanding?  Why did the factory tell us before that the
>> >mode pins *MUST* be tied to Vaux?  Did we misunderstand what they were
>> >saying?
>> >
>> >I promise this is the last time I will ask about this.  I am totally
>> >sick of going around this loop with everyone here.
>>
>>
>> We leave them open, slave serial. Works fine.
>
>At last, a clear, rational statement.  Thanks.
>
>I can't say that solves my problem though.  I have little doubt that
>there is any issue to the pullups working if you just leave them open.
>The fact that they are such a low resistance seems to me to make it a
>near certainty that they will pull up properly if left open.
>
>This board is currenly ready to come out of layout with the only
>remaining issues, SI on the data and address bus which we think is due
>to an overly agressive TI IBIS model, it does not match the units we
>can measure; and this stupid pullup resistor issue.
>
>There is little doubt in my mind that the stiff internal pullups make
>an external pullup unnecessary.  I spoke with the engineer who had
>spoken with the Xilinx factory person and I had trouble finishing a
>sentance without being interrupted.  It is very likely that she
>misunderstood what Xilinx was saying to her.  I expect she was told
>that the pull *down* resistors needed to be tied directly to GND and/or
>the distinction between the pull ups and pull downs was not made.  The
>fact that the data sheet and app notes show direct connections to Vaux
>and GND does not make the matter any more clear.
>
>Just to be very clear that the difference between a resistor pullup and
>a direct connection is not splitting hairs, we have a current part on a
>board that does not work correctly because of a similar issue.  The pin
>has three states for setting an I2C bus address; high, low and open.
>Seems the part is having trouble distinguishing the difference between
>high and open with most reistor values.  That data sheet also did not
>make it clear what value resistor was required as well as the level of
>noise immunity on the input.
>
>That engineer is working a lot of unpaid overtime at the moment.  I
>prefer to get this ironed out before I am done with layout and can
>still make a change if *required*.

Well, the real issue is: who's in charge of the design? The point of
engineering is (I theorize) not that you do what other people say, but
that you think.

And can't you demonstrate the pullup strength with a milliammeter?

John


Article: 101424
Subject: Re: Spartan 3 documentation confusing...
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 30 Apr 2006 17:12:39 -0700
Links: << >>  << T >>  << A >>
On 24 Apr 2006 09:27:02 -0700, "rickman" <spamgoeshere4@yahoo.com>
wrote:


>I found this sentance to be especially unenlightening...
>
>"The Dedicated configuration pins (CCLK, DONE, PROG_B, M2, M1, M0,
>HSWAP_EN) and the JTAG pins (TDI, TMS, TCK, and TDO) always have a
>pull-up resistor to HSWAP_EN during configuration, regardless of the
>value on the HSWAP_EN pin."


It's stunning how bad IC documentation is, and not just Xilinx. The
use of the passive voice ("the enable input, when asserted..."  Who
the hell pulls it high, or maybe low, me or the chip?) and the
persistant refusal to distinguish between levels and edges are two
especially annoying lapses. The guys who do mixed-level stuff, like
serial ADCs, are extra bad.

Who *writes* this stuff?

John





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