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 100050

Article: 100050
Subject: Re: Xilinx SelectMAP problem
From: smu <pas@d.adresse>
Date: Sun, 02 Apr 2006 18:28:37 +0200
Links: << >>  << T >>  << A >>
jenze a écrit :
> Hi smu,
> 
> usually this behavior is caused by incorrect data loaded into the
> device. The BUSY Signal will be driven high some CCLK cycles after the
> incorrect data has been loaded into the device. Have you checked the
> data alignment (D0=MSB), correct assertion/deassertion of CS#, and the
> setup/hold times on the select map interface?
> 
> Regards
> 
> Jens
> 

Hallo Jens,

Where did you find this information?

This information could explain why it works in a previous version of my 
antifuse design. Probably some routing delay that made setup and hold 
time not conforms. I will check that.

Regards,

smu

> smu schrieb:
> 
> 
>>Hi,
>>
>>I have developed board with a Spartan 2E. The Spartan is configured by
>>an antifuse fpga with the SelectMAP mode. The configuration of M[2:0] is
>>ok. The configuration stream is transferred at 2.5MBytes/s.
>>It said in the datasheet that the busy flag is provide for frequency
>>above 50MHz. But in my design, I see a high level on the busy flag.
>>
>>Somebody saw this kind of phenomena on Spartan 2E device?
>>What was the origin of this phenomenon?
>>
>>Thank you in advance
>>
>>smu
> 
> 

Article: 100051
Subject: Re: hwicap can be used in the virtex4
From: zhangxun0501@gmail.com
Date: 2 Apr 2006 11:51:00 -0700
Links: << >>  << T >>  << A >>
in the doc of liberary guid of vitex4 where we can find the model hdl
and symbole of ICAP so I'm sur icap is in the virtex4 but hwicap!!!!!!!
no idea! maybe there will have another version ip will  be used !!!

Paul Hartke a =E9crit :

> Hi Alan,
>
> This would only work if the ICAP in Virtex4 operated the same way as in
> Virtex2/Virtex2p.  Maybe they are not the same and this is why the
> ARCH_SUPPORT doesn't include Virtex4.
>
> Paul
>
> Alan Nishioka wrote:
> >
> > zhangxun0501@gmail.com wrote:
> > > but in the sit of xilinx , it said the hwicap support the virtex4-fx
> >
> > Have you tried adding virtex4 to the list of supported architectures
> > in:
> > EDK/hw/XilinxProcessorIPLib/pcores/opb_hwicap_v1_00_b/data/opb_hwicap_v=
2_1_0.mpd
> >
> > That is, change
> > OPTION ARCH_SUPPORT =3D virtex2:virtex2p
> > to
> > OPTION ARCH_SUPPORT =3D virtex2:virtex2p:virtex4
> >
> > I don't have 8.1 and am not using hwicap, so I have not tried this and
> > don't know if it will work.
> >=20
> > Alan Nishioka


Article: 100052
Subject: Re: hwicap can be used in the virtex4
From: zhangxun0501@gmail.com
Date: 2 Apr 2006 11:52:32 -0700
Links: << >>  << T >>  << A >>
I think that is the reason maybe the new version will different than
the old


Article: 100053
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 02 Apr 2006 12:40:07 -0700
Links: << >>  << T >>  << A >>
On Sat, 01 Apr 2006 21:07:24 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Hello John,
>
>
>> We're leaning towards slowing down the edge at the xo, maybe with an
>> R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at
>> each fpga, giving most of a volt of noise immunity. There's no room
>> for star traces, or at least not without a lot of ripups. If we put
>> the tinies on the bottom, under the fpga's, they fit nicely and we
>> don't have to waste a bunch of hundreds of bucks on a new solder-paste
>> stencil and reprogramming the pick-and-place.
>> 
>
>That increases phase noise. It may not matter in the digital world but I 
>wouldn't do that for ADC clocks.
>
>One technique I use if a home-run star system isn't practical is a 
>nicely impedance controlled clock line (or a few) and then tapping off 
>with low-C RF transistors wherever the clock is needed. It raises the 
>hackles of the digital folks during design reviews but after a thorough 
>explanation they like it.


Emitter followers?

John



Article: 100054
Subject: Re: hwicap can be used in the virtex4
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 2 Apr 2006 21:41:30 +0200
Links: << >>  << T >>  << A >>
<zhangxun0501@gmail.com> schrieb im Newsbeitrag 
news:1144003952.207614.206090@z34g2000cwc.googlegroups.com...
>I think that is the reason maybe the new version will different than
> the old
>

yes, ICAP is OK in V4, its just the EDK that has the ip cores not updated 
with V4 support :(

Antti 



Article: 100055
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 02 Apr 2006 12:43:34 -0700
Links: << >>  << T >>  << A >>
On Sun, 02 Apr 2006 02:32:13 GMT, "Michael A. Terrell"
<mike.terrell@earthlink.net> wrote:

>John Larkin wrote:
>> 
>> Hey, the CPU has a clock-out pin, same freq as the clock-in in this
>> case. We could use *that* to drive the two following FPGAs in the
>> string. It's a 68332, ancient process cmos, swings hard and makes nice
>> sedate edges! May as well leave the deglitcher in there, so we don't
>> have to re-release the designs.
>
>
>   The MC68340 is the same family as the MC68332.  I saw a lot of
>MC68340 on the embedded controllers we built for the Microdyne 700 &
>1620 series of telemetry equipment, as well as a satellite tracking
>controller that used a modified version of the same custom controller. 
>They made a layout error for the 32,768 Hz oscillator that no one had
>noticed.  It caused starting problems, and there was no way to fix it
>without changing the board layout.

The 32 KHz oscillator/PLL thing is really a pain on the Moto parts.
It's a lot easier and much more reliable to just buy a packaged XX MHz
oscillator and use it directly.

John


Article: 100056
Subject: Re: PCB Bypass Caps
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 02 Apr 2006 13:00:58 -0700
Links: << >>  << T >>  << A >>
On Sat, 01 Apr 2006 19:25:56 GMT, "RobJ" <rsefton@abc.net> wrote:

>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
>news:mbit229a62jkgeffc3r9h8jgmr9ekh2s96@4ax.com...
>>
>> Howard knows a lot of stuff, and makes up the rest.
>>
>> John
>>
>
>That's hilareous, but partly true. I've been a Howie fan since Black Magic 
>came out and it's been interesting to see what is gospel one year become 
>anathema the next. The whole topic of high-speed design (SI, PDS design, 
>modeling, etc.) reminds me of the FDA guidelines on what's good and bad to 
>eat. It's all a constantly moving target, which is understandable because 
>this is very complicated stuff.


I've highlighted a number of howlers in Black Magic. Half his stuff is
right and half is silly. If you know enough to tell the difference,
you don't need the book.

His opinions on "return currents" are hilarious.

>
>After seeing some awful board stackups and PDS designs work flawlessly, I've 
>concluded that a lot of the advanced art of PDS design is only needed for 
>boards with super high-speed and high-current devices, like Pentium 
>processors and the like. The research is driven mainly by companies like 
>Sun, who deal in that area, and by the consultants and EDA tool vendors who 
>have a vested interest in companies trying to follow the "state of the art" 
>PDS design methodologies. Way overkill for most designs, even very large 
>FPGA designs.


Exactly. Everybody has his religiously-observed way to do bypassing.
The fact is that most any bypassing scheme works fine in most
situations on multilayer/powerplane boards. I know a guy who uses no
bypass caps at all, and that works too. I like four 0.33 uF caps per
FPGA per supply, and that's just cowardly overkill.

I saw a board being stuffed once (on a Panasonic turret p-n-p, in a
tin-roof assembly shack in Hamamatsu) that had over 3000 bypass caps,
part of an Anritsu memory tester, as I recall.

>
>Signal integrity is a different story. There are tons of ways to get in 
>trouble there, as I've proven to myself many times. :)

Amen. And it's not getting any easier. The FPGA designers should take
pity on us and give us the option to slow down i/o cells and clock
buffers. Not every FPGA works flat-out.

John


Article: 100057
Subject: Re: deglitching a clock
From: "Michael A. Terrell" <mike.terrell@earthlink.net>
Date: Sun, 02 Apr 2006 20:01:45 GMT
Links: << >>  << T >>  << A >>
John Larkin wrote:
> 
> On Sun, 02 Apr 2006 02:32:13 GMT, "Michael A. Terrell"
> <mike.terrell@earthlink.net> wrote:
> 
> >John Larkin wrote:
> >>
> >> Hey, the CPU has a clock-out pin, same freq as the clock-in in this
> >> case. We could use *that* to drive the two following FPGAs in the
> >> string. It's a 68332, ancient process cmos, swings hard and makes nice
> >> sedate edges! May as well leave the deglitcher in there, so we don't
> >> have to re-release the designs.
> >
> >
> >   The MC68340 is the same family as the MC68332.  I saw a lot of
> >MC68340 on the embedded controllers we built for the Microdyne 700 &
> >1620 series of telemetry equipment, as well as a satellite tracking
> >controller that used a modified version of the same custom controller.
> >They made a layout error for the 32,768 Hz oscillator that no one had
> >noticed.  It caused starting problems, and there was no way to fix it
> >without changing the board layout.
> 
> The 32 KHz oscillator/PLL thing is really a pain on the Moto parts.
> It's a lot easier and much more reliable to just buy a packaged XX MHz
> oscillator and use it directly.
> 
> John

   I agree, but the design team insisted that they needed the ability to
reprogram the CPU's clock rate, "Just in case."  Then to add insult to
injury, they mounted the watch type tuning fork crystal vertically, and
soldered the bottom edge of the crystal's case to a large pad rather
than lay it down and use a drop of RTV to shock mount it.  I saw a lot
of dead boards with dead crystals.  There were so many that I kept 10
spare crystals on my bench.  They mounted the less sensitive baud rate
crystal the right way, and soldered the top of the can to a pad.  All of
this was done a year before I was hired so I was stuck with getting the
things out of production, and into customer's hands.


-- 
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Article: 100058
Subject: Re: ModelSim Designer
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sun, 02 Apr 2006 13:25:25 -0700
Links: << >>  << T >>  << A >>
Brian Drummond wrote:

 > (1) Viewing/drawing block diagrams and state machines gives me a very
 > clear view of the design, which helps me handle the complexity.

Note that ISE and Quartus now have added serviceable block viewers.
While you can't click on anything in this pdf printout,
http://home.comcast.net/~mike_treseler/uart.pdf
when seen live from Quartus, clicking on a yellow
box will bring up a graphical state diagram, even though
all I actually wrote was a case statement in text.

 > (2) Code generation from these blocks means I have very little contact
 > with the alleged verbosity of VHDL. (And when I do, it's helping me by
 > providing clarity, instead of making me type long words)

HDL designer does hierarchy with a block
diagram editor. To fill these boxes, it provides logic
entry from state diagrams or flowcharts.
This style appeals to schematically oriented
designers who would rather drag boxes, wires,
circles and arrows around than write code.
This is a valid alternative for those
who don't like writing HDL code, and Mentor
has made lots of money with this product.

Code generation from graphics *appalls* designers
who know an HDL and see a tidy code listing
as the only viable and portable source format.
A single block HDL style allows the bottom up
use of variable (register) structures, functions and procedures
to construct a design of arbitrary complexity
from a standard template. While verbosity is
possible, so is a clean, modular, single-threaded
logic description with registers, wires and muxes inferred
as needed by synthesis.

 > (1) Creating and using components works well and greatly encourages
 > re-use.
 > I make this neutral because when I started (1998),
 > I created components at a low level of abstraction - even down to a > 
 > parameterisable pipeline register. And re-used them in higher level > 
 > blocks, etc - to give quite a deep hierarchy.
 > Not necessarily a bad thing, but somewhat opposed to e.g. Mike
 > Treseler's "one process" style. These are two approaches to the same
 > goal - minimising complexity, so to some extent, using one renders the
 > other less important.

Yes, synthesis has improved in the last
eight years, and it is no longer necessary to use
write deeply nested structural designs down to
the gate, mux and register level.
For designers who know an HDL for synthesis and simulation,
tools like HDL designer are largely irrelevant.

I use the emacs vhdl-mode compose commands
to wire up my single-process instances into
a top entity. If I need to view the design
graphically, I use the Quartus pre-map RTL viewer.

   -- Mike Treseler

Article: 100059
Subject: Re: deglitching a clock
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Sun, 02 Apr 2006 20:41:55 GMT
Links: << >>  << T >>  << A >>
Hello John,


>>One technique I use if a home-run star system isn't practical is a 
>>nicely impedance controlled clock line (or a few) and then tapping off 
>>with low-C RF transistors wherever the clock is needed. It raises the 
>>hackles of the digital folks during design reviews but after a thorough 
>>explanation they like it.
> 
> Emitter followers?
> 

Yes, generally. But you need a negative supply and ideally a +8V or 
higher as well (really, really good bypasses or it'll oscillate). This 
is usually the case for the systems I work on but the analog folks are 
often suspicious about me tapping into "their" supplies for lowly 
digital purposes. Once I tell them that I am an analog guy myself that 
relieves them from their worries. Now, about that big honking stepper 
motor...

Regards, Joerg

http://www.analogconsultants.com

Article: 100060
Subject: Re: ModelSim Designer
From: "RobJ" <rsefton@abc.net>
Date: Sun, 02 Apr 2006 21:57:33 GMT
Links: << >>  << T >>  << A >>
Mike, Brian -

Thanks for sharing your experiences with the tools. I now have 30-day demo 
licenses for both ModelSim Designer and HDL Designer, so I'll try to make 
time to see if there's anything here I can't live without. I use Verilog 
almost exclusively, and I don't use the methodology of building a library of 
low-level logic primitives and then building up my designs from that. As 
Mike said, the synthesis tools are smart enough now to not require that, and 
with that approach you may as well be drawing schematics, which I was happy 
to leave behind probably 12 years ago.

I have two main motivations for looking at these tools. First, I'd like to 
increase my productivity. I've been doing things basically the same way for 
years and it's time to see what's out there that can make the job faster, 
easier, and even better than what I'm doing now. Second, my main customer 
(I'm a consultant) is an avionics company (non-defense), and the FAA 
requires extensive documentation to certify a product. They've been very 
strict with software for years, but recently they've adopted the same 
standards for programmable logic. I want to come up with an FPGA design 
methodology for my customer that will make the FAA happy without requiring a 
ton of extra work.

By the way, Brian, the Mentor sales guy said ModelSim Designer does not work 
the same as ModelSim. He used some corny analogy to describe it, but the 
bottom line is that they're different tools that are not interchangeable or 
even necessarily compatible. Still, for $2500 I'd consider buying it if it 
has the documentation and task automation features I'm looking for. I just 
wouldn't use it as my simulation engine.

I'll post back with comments from my evals if I have anything worth 
reporting.

Rob 



Article: 100061
Subject: Re: Doubt about SERDES
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 02 Apr 2006 21:59:21 GMT
Links: << >>  << T >>  << A >>
Rob,

> Of course the FPGA doesn't have any knowledge of the bit stream; which is 
> why you have to tell it where the data is in relation to the rising edge 
> of the clock.  In the case of a receiver, the MegaWizard function gives 
> you the option of choosing 0, 45, 90, 135, 180, 225, 270, & 315 degrees. 
> This is possible because the Wizard funcion uses a PLL to strip the data 
> from the serialized stream.

What you're talking about here has to do with what Altera calls 'DPA' . 
What the data book has to say about DPA is the following (page 51 of 68) 
http://www.altera.com/literature/hb/stx2/stx2_sii5v2_03.pdf:

The DPA block aligns the incoming data to one of eight clock
phases to maximize the receiver's skew margin. The DPA circuit can be
bypassed on a channel-by-channel basis if it is not needed. Set the DPA
bypass statically in the Quartus II MegaWizard Plug-In or dynamically
by using the optional RX_DPLL_ENABLE port.

DPA has to do with skewing the SERDES clock a bit (with one of 8 settings) 
relative to a particular bit position in order to improve receiver skew 
margin in order to correct for known skew that may exist in your system but 
can be accounted for ahead of time (i.e. at design time when you're picking 
one of those 8 settings).  This is not the same thing that I was talking 
about though.  What I was talking about was along the lines of what is on 
the next page in the section titled "Receiver Data Realignment Circuit" 
where they say...

The data realignment circuit aligns the word boundary of the incoming
data by inserting bit latencies into the serial stream. An optional
RX_CHANNEL_DATA_ALIGN port controls the bit insertion of each
receiver independently controlled from the internal logic. The data slips
one bit for every pulse on the RX_CHANNEL_DATA_ALIGN port.

If you scroll a bit further to page 58 under the section titled 
"Differential I/O Bit Position" is a nice description showing the bit order 
of differential data that basically shows that the nominal rising edge of 
the SERDES clock occurs roughly at the transition between when data bits 2 
and 1 are being transmitted.  What they don't say is that you have to use 
the above mentioned "Receiver Data Realignment" feature first in order to 
get the bits in the proper position.

I ran across this one first in simulation since the receiver was not 
performing per the 'Figure 5-14' diagram where I suspected that it was just 
Altera's simulation model that was in error.  After opening a service 
request and subsequent escalations since the problems wasn't resolved and 
actually talking to someone at Altera who is very familiar with the SERDES 
circuitry the end result was that the simulation model is correct the 
diagrams they agreed are somewhat misleading and that the 'Receiver Data 
Realignment' feature really does need to be used in order to guarantee that 
your design is working correctly at every power up.

Typically everything seems to power up in the same fashion but I've also 
seen the actual hardware have to get 're-aligned' after having already been 
aligned.

> Most discrete SERDES type chips, like National's 90CR types, align the 
> data with the rising edge of the PLL clock.  In this case

And this was my mistake when I thought this to be true with Stratix SERDES 
also...thanks to Figure 5-14

KJ



Article: 100062
Subject: Re: Doubt about SERDES
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 02 Apr 2006 22:18:01 GMT
Links: << >>  << T >>  << A >>
Chris,
> without losing any words during the switching), but would it be possible 
> to
> just multiplex the serial data?
>

The problem is that no you can't just multiplex the serial data at 1Gbs even 
though fundamentally that is all you're trying to do.  FPGAs circa 2006 do 
not do any logic from external sources at that speed.  All you can do is 
deserialize then multiplex and re-serialize.

KJ 



Article: 100063
Subject: Re: Configuration pins on Spartan-3
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 2 Apr 2006 15:34:07 -0700
Links: << >>  << T >>  << A >>
There is one engineer on our team who is a real PITA.  He is always
kibitzing other people's designs for trivial things that no one else
thinks is worth mentioning.  These resistor issues is one of those
things.  Just so I don't have to change the parts on my schematic, can
I get you to explicitly say it is ok to use pullups to 2.5 volts of up
to 10k ohms on the various signals lines powered by VCCAUX?

I can't believe he is trying to say the direct connection shown in the
3.3 volt configuration guide is an indication that we should not be
using pull up resistors.  But the process we use for design requires me
to consider his input and justify my decision.  His only reason for
making that assertion is the digram in the app note which shows direct
connections.


Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
> The JTAG interface on Spartan-3 FPGAs are powered by the VCCAUX (2.5V)
> supply.
>
> The key limitation is to avoid back-driving the JTAG inputs.  For
> example, if you apply a 3.3V input to a JTAG input, then there will be
> a path back through the ESD protection diode.
>
> There are a variety of solutions here, depending on your specific
> application.
>
> 1.  If driving the JTAG interface with 2.5V, no problem.
>
> 2.  If actively driving the JTAG interface with 3.3V, be sure to use
> current-limiting series resistors and it is best to park the lines low
> or let them float when not in use.  You can also three-state the JTAG
> pins after configuration or drive them using open-drain outputs.  The
> JTAG pins have dedicated pull-up resistors to VCCAUX during
> configuration.  After configuration, these pull-up resistors are left
> enabled by default.  Via bitstream options, you can also change these
> to pull-down resistors or turn them off.
> ---------------------------------
> Steven K. Knapp
> Applications Manager, Xilinx Inc.
> General Products Division
> Spartan-3/-3E FPGAs
> http://www.xilinx.com/spartan3e
> ---------------------------------
> The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 100064
Subject: Re: Configuration pins on Spartan-3
From: "RobJ" <rsefton@abc.net>
Date: Sun, 02 Apr 2006 22:40:41 GMT
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:1144017247.324185.173090@i40g2000cwc.googlegroups.com...
> There is one engineer on our team who is a real PITA.  He is always
> kibitzing other people's designs for trivial things that no one else
> thinks is worth mentioning.  These resistor issues is one of those
> things.  Just so I don't have to change the parts on my schematic, can
> I get you to explicitly say it is ok to use pullups to 2.5 volts of up
> to 10k ohms on the various signals lines powered by VCCAUX?
>
> I can't believe he is trying to say the direct connection shown in the
> 3.3 volt configuration guide is an indication that we should not be
> using pull up resistors.  But the process we use for design requires me
> to consider his input and justify my decision.  His only reason for
> making that assertion is the digram in the app note which shows direct
> connections.
>
>

I think I know that guy!!

Everything you need to know to justify your design is in the data sheet. If 
people knew who writes most app notes in our business they wouldn't treat 
them with such veneration. Slap that PITA for me!!

Rob 



Article: 100065
Subject: Re: Configuration pins on Spartan-3
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 2 Apr 2006 16:15:29 -0700
Links: << >>  << T >>  << A >>
There are two good and two marginal reasons to use external pull-up
resistors instead of a short circuit to Vcc.:

If the pin is dual-use and might also be input or output (that's
obvious)

If you want to change the level for testing purposes, by shortening it
to ground.

If you are an old TTL guy who remembers that LS-TTL inputs could be
damaged by a very high Vcc. (historical-hysterical reason).

If you think a resistor is dirt-cheap and buys you some flexibility or
peace of mind.

Peter Alfke, Xilinx, from home.


Article: 100066
Subject: Re: Configuration pins on Spartan-3
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 03 Apr 2006 11:51:36 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> There are two good and two marginal reasons to use external pull-up
> resistors instead of a short circuit to Vcc.:
> 
> If the pin is dual-use and might also be input or output (that's
> obvious)
> 
> If you want to change the level for testing purposes, by shortening it
> to ground.
> 
> If you are an old TTL guy who remembers that LS-TTL inputs could be
> damaged by a very high Vcc. (historical-hysterical reason).
> 
> If you think a resistor is dirt-cheap and buys you some flexibility or
> peace of mind.

.. and another testing use, is to use the pin to bring out an
internal signal, for probing.
- ie I'd add a resistor _and_ a probe pad.
[ you also then side-step his input, as now your use is
clearly not in that appnote :) ]


Article: 100067
Subject: Re: Hierarchical FSM?
From: "radarman" <jshamlet@gmail.com>
Date: 2 Apr 2006 19:35:19 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Davy wrote:
>
> > I am new to hierarchical FSM design.
> > Is there any paper or guideline for design hierarchical FSM?
> > Any suggestions will be appreciated!
>
> I would suggest that if your state machine
> needs a hierarchy, there is likely a simpler
> logic description possible, using multiple
> process variables, not all of them enumerated.
>
>         -- Mike Treseler

It depends on the nature of the state machine (SM). Sometimes it is
helpful to take advantage of the inherent parallelism available in a
FPGAs and ASICs by having multiple state machines operating at once
while a "master" SM coordinates their activities. However, this
typically implies only two levels of hierarchy (the master machine, and
the servant machines)

That said, there are few circumstances that call for true hierarchy in
state machine design, and I would recommend also that you reexamine the
problem. Often, a problem can be more easily solved with an external
(to the SM) counter, pipeline register, or signal than by adding
additional states.

As a hint, try to limit the number of outputs each SM generates. This
will force you to partition the problem better, and should result in a
cleaner design. For example, rather than implement a full
microprocessor for a test application, I wrote two state machines that
were attached to an internal UART model. One state machine handled
incoming data, while the other acted as a message generator. By
partitioning in this way, each machine became much simpler, and
performance improved greatly.

Note, there are some graphical tools on the market (Mentor Graphics'
HDL Designer, and Xilinx' StateCAD) that allow you to implement
hierarchical state machines graphically - allowing them to be
understood more easily. However, if you examine the output, you will
find that the SM has almost invariably been flattened to just one (in
either two or three processes depending on what you specified in the
options)


Article: 100068
Subject: Re: Discrete
From: "Fizzy" <fpgalearner@gmail.com>
Date: 2 Apr 2006 19:58:32 -0700
Links: << >>  << T >>  << A >>
I guess if you cannot answer or help than its much better not to say
anything. I think you need some help in this area :)


Article: 100069
Subject: Xilinx Kernel
From: "Fizzy" <fpgalearner@gmail.com>
Date: 2 Apr 2006 20:10:03 -0700
Links: << >>  << T >>  << A >>
Hello All,

Any of you have ever used Xilinx Kernel in any project. I am wondering
how easy its is to use. I am planning to embed some applciation on
PowerPC 405 of Virtex4 FX. My only use to have kernel is to have some
basic scheduler so i can schedule the processes. Any known issues with
it? Round Robin scheduler is my priority :-)


Article: 100070
Subject: Re: Discrete
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 2 Apr 2006 20:48:53 -0700
Links: << >>  << T >>  << A >>
I suppose Duane is wondering how such a naive ( impossible to answer)
and poorly worded question comes from somebody working in such a
sophisticated company..."interesting"
We all want to be helpful, but I will also point out that posters
should do a little bit of thinking and googling before they embarrass
themselves.
We learned recently that we must be tolerant of "creative spelling"...
Peter Alfke


Article: 100071
Subject: Re: ModelSim Designer
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Mon, 03 Apr 2006 09:20:43 +0300
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> Code generation from graphics *appalls* designers
> who know an HDL and see a tidy code listing
> as the only viable and portable source format.

Actually HDL designer creates quite clean code from the FSM editor
and block diagrams. It can easily be read also manually. The
problem is lack of comments in the code if it is automatically
generated tough.

> A single block HDL style allows the bottom up
> use of variable (register) structures, functions and procedures
> to construct a design of arbitrary complexity
> from a standard template. While verbosity is

Just be wary with functions and procedures. Especially
procedures seem to be a big problem still for design tools. I think
I have seen all the major implementation tools to create garbage or crash
with very simple procedures (DC, Synplify, FormalPro, Formality, few linters
etc.)

> For designers who know an HDL for synthesis and simulation,
> tools like HDL designer are largely irrelevant.

Actually what I have seen very experienced VHDL coders (10+ years) also
like HDL designer. They usually use only the block diagrams and
text views. Block diagrams are good way of documenting
the functionality. Especially when the design team is big, different
coders have to read and sometimes fix other peoples code. Just browsing
the code is slower than to start with block diagrams that have the dataflow
clearly shown etc.

--Kim

Article: 100072
Subject: Re: KEEP_HIERARCHY
From: jaxato@gmail.com
Date: 2 Apr 2006 23:51:37 -0700
Links: << >>  << T >>  << A >>
Hi people,

I ran into a similar problem with a similar design, with an embedded
8-bit cpu and some cross domain signals. The design works with
chipscope, while it does not without it. Now, adding a KEEP_HIERARCHY
constrain actually makes it work again, and that without chipscope. I
am pretty sure that KEEP_HIERARCHY will keep module ports that the PAR
tools think is better to trim. So that it would be crucial to add the
property. Just to be on the safe side, I re-ran the flow a couple of
more times, with and without the attribute and it indeed makes the
difference.

Pretty much sure MAP is trimming off where it is not suppose to.

My two rupee :)
JA


Article: 100073
Subject: Re: Xilinx SelectMAP problem
From: "jenze" <jenze@et.upb.de>
Date: 3 Apr 2006 02:19:43 -0700
Links: << >>  << T >>  << A >>
Hi smu,

i have had similar problems some years ago on the Virtex-E. Virtex-E
ist (nearly) the same as Spartan-2E. The BUSY Signal will be driven
high if:

1) an abort has been requested.
2) the internal buffer is full. This will be the case if:
  2a) CCLK is above 50 MHz
  2b) the internal configuration packet processor is confused about the
configuration data and stops interpretation.
3) the internal buffer is empty, and you try to readback configuration
data. This is the case if:
  3a) CCLK is above  MHz
  3b) switching from write to read, so the buffer need to be filled
initially.

Regards

Jens


smu schrieb:

> Hallo Jens,
>
> Where did you find this information?
>
> This information could explain why it works in a previous version of my
> antifuse design. Probably some routing delay that made setup and hold
> time not conforms. I will check that.
> 
> Regards,
> 
> smu
>


Article: 100074
Subject: Re: deglitching a clock
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 03 Apr 2006 10:51:14 +0100
Links: << >>  << T >>  << A >>
John  Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

> I wonder if anyone has ever kluged a bga layout, sort of like one of
> those jellyfish with a thousand tentacles.
> 

We once soldered tiny wires to the vias on the *top* of a BGA package
to get at some signals we'd thought we wouldn't need to get to on the
prototype... that was fun :-)

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   



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