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
2017JanFebMarApr2017

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 41100

Article: 41100
Subject: Xilinx Spartan XL VHDL????
From: "James Lewis" <jlewis@nomadics.com>
Date: Wed, 20 Mar 2002 16:40:44 -0800
Links: << >>  << T >>  << A >>
Is anyone using VHDL for Spartan XL's?  I'm using the WebPack for a
Spartan-II, but it doesn't support the XL and was wondering what people use
for that series of part (Spartan/XL/4000/etc.).  I am inquiring with Xilinx,
and haven't received a definite answer yet, but it sounds like Alliance +
third party software.  It's rather shocking if that is the case that it is
free/cheap to develop for newer parts yet very expensive to develop for
older parts.

I should have shelled out the extra bucks to get Foundation Express with my
1.5 version of Foundation 3 years ago!?!?! argh.

James



Article: 41101
Subject: Re: How do I simulate two separate designs simutaneously in ModelSim XE?
From: schop@veritools.com (Robert Schopmeyer)
Date: 20 Mar 2002 16:57:19 -0800
Links: << >>  << T >>  << A >>
If you are using Undertow, you will not have to buy another tool like
Compare Scan just to compare your waveform files. You have with
Undertow three different ways to allow you to compare files. Note that
these files can be of any format, wlf, vcd, compressed, any format
that Undertow can read, and this tool can read almost every single
format from every commercial simulator on the market today. You can
compare files even if they have completely different formats.

Using Test Analyzer, a tool on Undertow, you can compare two different
files, with the differences showing up on the waveform window as a
plumb colored back ground over the area of the signal that is
different. You can specify the start and end time for the compare, the
signals to be compared and a clock with a window on the trailing or
leading edge of this clock  for this comparison.

Using the "Overlay feature" you can overlay three separate files. The
resulting waveform will be orange if the signal area is the same, and
yellow where they are different.

Using the built in Perl scripting tool, and then the
compare_file.script which is one of the many several dozen scripts
that come with Undertow. With this script, you can do a compare as a
batch or interactive process. On very large designs this script can be
run without a GUI in a batch process, against files that may be  many
gigabytes in size. These scripts have been designed to work at very
high speeds, hundreds of thousands of times faster than just plane
generic Perl.  Since the Perl script source code is included in the
Undertow distribution, you can quickly modify this code in any way you
wish to change the behavior of the exact compare operation. For
example, you can allow jitter for a set of signals, or allow a
difference threshold before indicating a mismatch, etc. Every  single
possible compare operation that you can do manually, you can do using
this built in Perl scripting capability.

You can get Undertow from www.veritools-web.com, and send a request to
schop@veritools.com, in order to get a no cost license to use this
software. Regards,
Robert Schopmeyer/Veritools, Inc.


Petter Gustad <newsmailcomp1@gustad.com> wrote in message news:<87it7s1mq1.fsf@filestore.home.gustad.com>...
> Petter Gustad <newsmailcomp1@gustad.com> writes:
> 
> > Design Acceleration (now part of Cadence) has a product called
> > comparescan for this purpose.
> 
> Comparing waveforms that is, not instantiating the two DUTs. 
> 
> With signalscan (waveform viewer) you can easily open two TRN (trace
> files generated by the signalscan PLI routines or converted from VCD)
> from two different simulations. You can also specify an event search
> to find where they differ.
> 
> Petter

Article: 41102
Subject: Re: Possibility of RTL and Gate-level simulation dont match?
From: kayrock66@yahoo.com (Jay)
Date: 20 Mar 2002 17:04:39 -0800
Links: << >>  << T >>  << A >>
How possible is it?  Well if you're a new HDL guy then it's very
possible, and if you're not, then its still possible.  You should be
able to run the same test bench on RTL or gates and have them both
pass.

"Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message news:<3c97f13b@news.starhub.net.sg>...
> Hi,
> 
> I am using Spartan-II chip, I want to know how much possibility that
> the RTL and gate-level simulation don't match?
> When they don't match, how can I detect that? It seemed that the synthesis
> report in ISE 4.1 doesn't give me a warning or error?

Article: 41103
Subject: Re: Fixed Point Library
From: kayrock66@yahoo.com (Jay)
Date: 20 Mar 2002 17:07:55 -0800
Links: << >>  << T >>  << A >>
Huh? Isn't fixed point implicit in the HDL?  What operations are you looking for?

magz@citiz.net (Jacke) wrote in message news:<4f071e35.0203191744.1bfd4668@posting.google.com>...
> Hi,
> Do you know where I can find the open source code of Fixed Point Math Library?
> 
> thanks, :-)

Article: 41104
Subject: Re: FIFO general question
From: John_H <johnhandwork@mail.com>
Date: Thu, 21 Mar 2002 01:15:51 GMT
Links: << >>  << T >>  << A >>
If you have a system that experiences a short-term loss of frequency lock, you will shift
the center point of your FIFO.  If the clock recovery mechanism switches from a phase
error correction mechanism to a frequency error correction mechanism, you will inject or
extract a fixed amount of data until the system regains phase lock.

Phase locked loops maintain *phase lock* with input jitter levels that are hundreds of
unit intervals in deviation.  The frequencies during these slews can be off by large
amounts - at the low deviation, high frequency end, the slews can be several percent off.
These systems maintain phase lock typically by generating the phase error from divided
values of the VCO and reference frequencies such that a +/- 180 degree phase slip at the
comparator corresponds to +/- M/2 clock cycles for the VCO or +/- N/2 clock cycles in the
reference for an M/N divider.

Do you contend that a system which tolerates a loss of phase lock and starts the slip
required (in typical PLL system's frequency error loops) to reachieve the frequency lock
will perform to design with a finite FIFO?

If the FIFO fill level is used for feedback in the clock recovery, it is still a phase
error that's being fed to the control loops.

Only if you consider "phase lock" to be guaranteed phase alignment of less than one clock
period, than my terminology fails.  If you deal with PLL systems with phase error and
frequency error loops (almost all PLLs I've seen), you will have problems if you switch
loops.

- John_H



Peter Alfke wrote:

> John_H wrote:
>
> > The terminology is a bit loose, perhaps. ...
>
> >   The clocks need to be phase locked,
> > but can deviate by (significantly) more than one clock period with an appropriately
> > sized FIFO.
>
> That's a self-contradicting sentence!  Peter
>
> John, I do not like  "loose terminology".
> The FIFO does NOT require phase lock, not even short-term frequency lock. It fixes all
> that.
> But it can cover up for a frequency deviation only for a limited time, then it either
> misses one character or has to "invent" a character.
>
> You may mean the same thing, but that's not what you said (wrote).
>
> Peter Alfke


Article: 41105
Subject: Re: Possibility of RTL and Gate-level simulation dont match?
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Thu, 21 Mar 2002 09:35:14 +0800
Links: << >>  << T >>  << A >>
sure it's possible since i need to match the result with a C program, while
i tried best
to match the C result, gate level simulation is not correct. One constraint
is that after I
finished RTL and everything, I still don't know what problem the design was
intended to
solve...faint!
While RTL simulation and synthesis all pass, w/o major error or warning...i
am experienced
HDL designer anyway...prob is gate-level won't pass.
I want to know how can I detect fatal bugs in my code, besides RTL simu and
warning in ISE 4.1?





"Jay" <kayrock66@yahoo.com> wrote in message
news:d049f91b.0203201704.55c58ac8@posting.google.com...
> How possible is it?  Well if you're a new HDL guy then it's very
> possible, and if you're not, then its still possible.  You should be
> able to run the same test bench on RTL or gates and have them both
> pass.
>
> "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message
news:<3c97f13b@news.starhub.net.sg>...
> > Hi,
> >
> > I am using Spartan-II chip, I want to know how much possibility that
> > the RTL and gate-level simulation don't match?
> > When they don't match, how can I detect that? It seemed that the
synthesis
> > report in ISE 4.1 doesn't give me a warning or error?



Article: 41106
Subject: Re: spartan 2e, 5V i/o
From: emanuel stiebler <emu@ecubics.com>
Date: Wed, 20 Mar 2002 18:48:17 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Emanual,
> 
> Why do you need any pullup at all?

the als641 is an open collector ?
And, I remember reading sowething that I shouldn't use the internal 
pullups for that purpose. But I could be mixing up something. I have to
read 
it again I guess ;-)
 
> If the 74ALS powered from 5Vdc pulls to less than 3.3 Vdc for the high, so
> no series resistor to/from the Spartan IIE is required (simulated the IBIS
> models for the 74ALS outputs at 5Vdc driving high into a Spartan IIE).

Great ! Save me a lot of troubles here ...
 
> Sounds like the right IOB standard, and just connecting things up is the
> right way to go.
> Austin

Cheers & thanks again.
 
> emanuel stiebler wrote:
> 
> > Hi,
> >
> > I hope a little problem.
> > Trying to connect a 74als641 to a spartan 2e i/o pin.
> > And, it is bidirectional ...
> >
> > My idea is something like:
> >
> > (74als641 OC) -- (4k7 pullup to 3.3V) -- (100 Ohm resistor in series) --
> > (fpga pin)
> >
> > Does it work this way ? Any better ideas ?
> >
> > And if it is of any help, there are around 50-60 pins I have to use this
> > way ...
> >
> > cheers & thanks in advance,
> > emanuel

Article: 41107
Subject: Re: Possibility of RTL and Gate-level simulation dont match?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 21 Mar 2002 01:52:49 -0000
Links: << >>  << T >>  << A >>
Tried slowing down the test-bench "clock"?

Kelvin Hsu wrote
> sure it's possible since i need to match the result with a C program, while
> i tried best
> to match the C result, gate level simulation is not correct. One constraint
> is that after I
> finished RTL and everything, I still don't know what problem the design was
> intended to
> solve...faint!
> While RTL simulation and synthesis all pass, w/o major error or warning...i
> am experienced
> HDL designer anyway...prob is gate-level won't pass.
> I want to know how can I detect fatal bugs in my code, besides RTL simu and
> warning in ISE 4.1?
>
>
>
>
>
> "Jay" <kayrock66@yahoo.com> wrote in message
> news:d049f91b.0203201704.55c58ac8@posting.google.com...
> > How possible is it?  Well if you're a new HDL guy then it's very
> > possible, and if you're not, then its still possible.  You should be
> > able to run the same test bench on RTL or gates and have them both
> > pass.
> >
> > "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message
> news:<3c97f13b@news.starhub.net.sg>...
> > > Hi,
> > >
> > > I am using Spartan-II chip, I want to know how much possibility that
> > > the RTL and gate-level simulation don't match?
> > > When they don't match, how can I detect that? It seemed that the
> synthesis
> > > report in ISE 4.1 doesn't give me a warning or error?
>
>



Article: 41108
Subject: Re: High speed clock routing
From: bobsrefusebin@hotmail.com (Bob Perlman)
Date: 20 Mar 2002 17:57:45 -0800
Links: << >>  << T >>  << A >>
Rick - 

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C98D60E.859D5A1A@yahoo.com>...
> Bob Perlman wrote:
> > 
> > Rick -
> > 
> > A few comments/observations:
> > 
> > 1) If your board stackup is at all conventional, trace impedances will
> > fall somewhere in the range of 45 to 65 ohms.  You can, with effort,
> > get other impedances, but getting to 200 ohms will require tricks that
> > you won't want to play.
> 
> I am not at all clear on how you can guestimate the trace impedance to
> be in such a narrow range.  I was under the impression that it varied
> directly with trace width.  I could be using trace widths anywhere from
> 4 mil to 10 mil.  Further, the board stackup depends entirely on layer
> count vs. power plane count.  What were you assuming for these?  

I'm assuming that you're using a multi-layer board in which the height
of the trace off the nearest plane is roughly the same as the trace
width.  For a 5-mil trace, for example, you'd be 5 mils from the
nearest plane.  You can violate this rule and make the height greater,
thus increasing the impedance, but then crosstalk will bite you unless
your trace-to-trace spacings are wide.  And increasing the height of
the trace above the plane does not increase the impedance rapidly. 
Here's a question that I ask students when I hold signal integrity
courses: Suppose I'm in the space shuttle and I have a length of #30
AWG wire, and there's an infinitely wide ground plane sitting on the
earth's surface 160 miles below.  What's the impedance?  Zillions of
ohms?  Any guesses?

I'm also assuming that traces are narrow enough to fit between the
vias for fine-pitch parts; this means they're not going to be
extremely wide.  These factors tend to put a bound on the practical
range of achievable trace impedances.

> 
> I am hoping that I can get away with 4 routing planes and two power
> planes.  But that is not clear at this point.  I also would like to use
> 5/5 width/space on the traces, and I think this is less likely to vary. 
> But I can certainly make the clock traces wider to lower the impedance.  
> 
> HJ has a T circuit analysis (or two) on the web that uses series
> terminations at each end (all three).  The series resistors at the
> receiver were to damp resonant oscillations that can build up between
> the receivers.  I may give this a try if I can model it.  
> 
> 
> > 2) I don't know the strength of the C6711 clock driver.  If it's
> > strong enough to drive a Thevenin-equivalent parallel termination, and
> > if you can tolerate the inevitable clock skew that arises from
> > daisy-chaining the clock net, then use a single net and parallel
> > termination.  But be sure to check the weak/slow corner clock buffer
> > drive.  In my experience, the clock outputs of processor chips tend to
> > be underpowered.  (And they can be glitchy, too; a
> > ground-bounce-related glitch on the clock output of TI's TMS320C31
> > nearly torpedoed one project I worked on.)
> 
> I think I can afford to be accomodating in the skew since my daisy
> chained route would be about 3 inches or ~500 ps.  However the longest
> single trace in a star configuration is only 1.4 inches or ~240 ps.  The
> driver spec gives a max of 2 ns (no min) for the rise time, so even if
> it is 1 ns, my round trip is half the rise time.  This is not ideal, but
> I think it will likley work without termination.  

What happens when TI spins the die and the nominal risetime goes from
1ns to 0.6ns?
 
> > 3) If (2) doesn't pan out, spring for one of the small zero-delay
> > buffers, and drive each clock load with its own PLL output.  If the
> > zero-delay buffer has built-in series termination, great; if not,
> > series-terminate each output.  It'll cost you (not much) space and
> > (not much) money.  I never try to economize on either when generating
> > and distributing clocks.
> 
> Yes, I have thought about that, but small is a relative term and I am
> loath to add another part to the parts list.  
> 
> I would love to model this circuit, but I don't think I want to plunk
> down a few $k for a tool that will only be used one or twice per
> design.  I may try to find a friend at a company with the tool and
> "borrow" it or let him run my tests after I come up with all the
> relevant data.  

You can do surprisingly useful simulations with nothing more than the
student version of PSpice.  It's nowhere near as convenient as
Hyperlynx, but it's free (or at least it used to be).

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 41109
Subject: Re: FPGA or Micro-controller in Lowpower designs?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 21 Mar 2002 14:42:52 +1200
Links: << >>  << T >>  << A >>
Matz wrote:
> 
> Hi,
> 
> I am using a XPLA3 (CoolRunner) Device XCR3064XL. Now I need a crystal oscillator with low frequency (8...12 MHz). I want to do it with a simple crystal and an inverter within the XPLA3 device.
> Unfortunately the oscillator is not running. The input stucks on high signal. Although I disabled the XPLA3 internal PullUp Resistors.
> Who can help me, how to do it.
> 
> Best Regards
> Matz

 Use a TinyLOGIC HCU04, either singly, or as a pair to increase the slew 
rate into the PLD pins.
 Also Philips did a 74HC6323, that was OSC+DIviders in SO8

-jg

Article: 41110
Subject: Re: Possibility of RTL and Gate-level simulation dont match?
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Thu, 21 Mar 2002 10:50:03 +0800
Links: << >>  << T >>  << A >>
if clock is too fast the design output nothing at all. I am sure the clock
is no problem.

--
Best Regards,
-----------------------------------------------------------------
Xu Qijun
Engineer
OKI Techno Centre (S) Pte Ltd
Tel: 770-7049 Fax: 779-1621
Email: qijun@okigrp.com.sg
"Tim" <tim@rockylogic.com.nooospam.com> wrote in message
news:1016675701.23934.0.nnrp-07.9e9832fa@news.demon.co.uk...
> Tried slowing down the test-bench "clock"?
>
> Kelvin Hsu wrote
> > sure it's possible since i need to match the result with a C program,
while
> > i tried best
> > to match the C result, gate level simulation is not correct. One
constraint
> > is that after I
> > finished RTL and everything, I still don't know what problem the design
was
> > intended to
> > solve...faint!
> > While RTL simulation and synthesis all pass, w/o major error or
warning...i
> > am experienced
> > HDL designer anyway...prob is gate-level won't pass.
> > I want to know how can I detect fatal bugs in my code, besides RTL simu
and
> > warning in ISE 4.1?
> >
> >
> >
> >
> >
> > "Jay" <kayrock66@yahoo.com> wrote in message
> > news:d049f91b.0203201704.55c58ac8@posting.google.com...
> > > How possible is it?  Well if you're a new HDL guy then it's very
> > > possible, and if you're not, then its still possible.  You should be
> > > able to run the same test bench on RTL or gates and have them both
> > > pass.
> > >
> > > "Kelvin Hsu" <qijun@okigrp.com.sg> wrote in message
> > news:<3c97f13b@news.starhub.net.sg>...
> > > > Hi,
> > > >
> > > > I am using Spartan-II chip, I want to know how much possibility that
> > > > the RTL and gate-level simulation don't match?
> > > > When they don't match, how can I detect that? It seemed that the
> > synthesis
> > > > report in ISE 4.1 doesn't give me a warning or error?
> >
> >
>
>



Article: 41111
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: David Bishop <dbishop@vhdl.org>
Date: Thu, 21 Mar 2002 03:17:55 GMT
Links: << >>  << T >>  << A >>

I've seen this in designs that have come across my desk.

After looking at the designs closely, Synplicity is doing the
correct thing.  The code needs to be fixed, as it really is
inferring a tristate output.

In VHDL, all you need to do is to set the output type to
"std_ulogic_vector", which is unresolved (thus it really
can't tristate).  That prevents this from happening in VHDL.
How you would do it in Verilog, I don't know.

Synplicity does supply a patch for 7.0.3, which puts it back
into the original behavior.  At work, we did put this patch
on for 1 user.

BTW, on the Verilog and VHDL synthesis SIGS on eda.org this
has stirred up a discussion as well.

> Unfortunately, their conclusion is completely opposite to my
> understanding.  I'm still not convinced that such logic mapping
> is correct.
> 
> Since Synplify is #1 in the FPGA synthesis market, a huge number
> of engineers in the world are using Synplify to design FPGAs.
> 
> I would like to ask everyone about this new feature of
> Synplify 7.x. If you feel this feature is incorrect and
> dangerous (or support Synplicity's arguments), please
> send me an e-mail. I will present all e-mails I receive
> to Synplicity (both for and against).
> 
> Feedback / support to : synp_petition@usa.net
> 
> I will post the update when I have something to report.
> 
> Thank you for your attention.
> Hope I can hear from many of you.
> You can forward this to any other newsgroups or your friends
> to get more feedbacks.
> 
> Sincerely yours,
> Aki Niimura - being a Synplify user since 1999
> 
> P/S I have created a Web site to list feedbacks I receive.
> http://www.petition-synplify.0catch.com

-- 
NAME:     David W. Bishop           INTERNET: dbishop@vhdl.org  (  \  )
US MAIL:  Hilton NY                 A Long time ago,             \__\/
PHYSICAL: 43:17:17N 77:47:37W 281'  In a Galaxy far, far away...  | |
For Supernova info:  http://www.RochesterAstronomy.org/snimages/  | |
For VHDL/Synthesis info:  http://www.vhdl.org/siwg              _/___\_
All standard disclaimers apply.                                [_______]

Article: 41112
Subject: Re: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 21 Mar 2002 00:34:49 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:
> 
> Rick -
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C98D60E.859D5A1A@yahoo.com>...
> > Bob Perlman wrote:
> > >
> > > Rick -
> > >
> > > A few comments/observations:
> > >
> > > 1) If your board stackup is at all conventional, trace impedances will
> > > fall somewhere in the range of 45 to 65 ohms.  You can, with effort,
> > > get other impedances, but getting to 200 ohms will require tricks that
> > > you won't want to play.
> >
> > I am not at all clear on how you can guestimate the trace impedance to
> > be in such a narrow range.  I was under the impression that it varied
> > directly with trace width.  I could be using trace widths anywhere from
> > 4 mil to 10 mil.  Further, the board stackup depends entirely on layer
> > count vs. power plane count.  What were you assuming for these?
> 
> I'm assuming that you're using a multi-layer board in which the height
> of the trace off the nearest plane is roughly the same as the trace
> width.  For a 5-mil trace, for example, you'd be 5 mils from the
> nearest plane.  You can violate this rule and make the height greater,
> thus increasing the impedance, but then crosstalk will bite you unless
> your trace-to-trace spacings are wide.  And increasing the height of
> the trace above the plane does not increase the impedance rapidly.
> Here's a question that I ask students when I hold signal integrity
> courses: Suppose I'm in the space shuttle and I have a length of #30
> AWG wire, and there's an infinitely wide ground plane sitting on the
> earth's surface 160 miles below.  What's the impedance?  Zillions of
> ohms?  Any guesses?

I would not have a clue.  But I want to know how you plan to measure it
and verify your answer!


> I'm also assuming that traces are narrow enough to fit between the
> vias for fine-pitch parts; this means they're not going to be
> extremely wide.  These factors tend to put a bound on the practical
> range of achievable trace impedances.

I don't know if that is a valid assumption.  We are not talking about a
bus of many signals.  This is the clock route and it can be made any
impedance or width I want.  There is also not much point in using
extremely narrow traces since many of the finer pitch parts can not be
rounted between the pins unless you go to unmanufacturable line/space
widths.  


> > I think I can afford to be accomodating in the skew since my daisy
> > chained route would be about 3 inches or ~500 ps.  However the longest
> > single trace in a star configuration is only 1.4 inches or ~240 ps.  The
> > driver spec gives a max of 2 ns (no min) for the rise time, so even if
> > it is 1 ns, my round trip is half the rise time.  This is not ideal, but
> > I think it will likley work without termination.
> 
> What happens when TI spins the die and the nominal risetime goes from
> 1ns to 0.6ns?

If they respin the die, the max clock rate will go up and I will be
reexamining the board for many reasons.  


> You can do surprisingly useful simulations with nothing more than the
> student version of PSpice.  It's nowhere near as convenient as
> Hyperlynx, but it's free (or at least it used to be).
> 
> Bob Perlman
> Cambrian Design Works
> http://www.cambriandesign.com

You can, but it takes a lot of time and effort to get the input data
right.  I was willing to do some testing with Hyperlynx, but I think
pSpice will be a rather large effort to ramp up on.  I think that a good
book will help me more easily and quickly. 

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 41113
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 21 Mar 2002 00:33:36 -0600
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> 
> "Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> schrieb
> im Newsbeitrag news:a79fvc$qo1$1@newsreader.mailgate.org...
> 
> >         Compared to using a regular CLB FF, using an IOB OE FF makes Tsu
> > worse because routing distance will get longer, and will get only worst
> > if the device's die gets larger.
> > Also, for a path starting from unregistered control signals of PCI bus
> > (FRAME#, IRDY#, DEVSEL#, TRDY#, and STOP#) to AD[31:0] or C/BE#[3:0]'s
> > OE FFs, I already got 4 levels of 4-input LUT, and so far, I haven't
> > been successful reducing the level of LUT.
> 

> I got it. But still, try to locate the critical stuff close together so that
> the signal dont have to cross the whol chip.
> 


        Even if the relevant LUTs are group inside an CLB, the signal
will still have to travel quite a long distance.
Therefore, I find it better not to use IOB OE FFs, and keep an OE FF
near the control signals to reduce routing distance.




> > But the problem is XST overrides my design of using one OE FF for
> > AD[31:0], and one OE FF for C/BE[3:0], and duplicates them 32 times and
> > 4 times, respectively.
> > Attaching "keep" attribute didn't help either.
> 

> Did you check the settings in the synthesis options?? In the preferences,
> switch to "Advanced" properties, then there is a switch which allows you to
> set global generation of IOB FlipFlops. Just set it to Auto or OFF. Then
> just add the right attribute to the FF you want inside the IOB.
> 
> attribute iob: string;
> attribute iob of
> {component_name|entity_name|label_name}:
> {component|entity|label} is "(true|false|auto)";
> 
> Regards
> Falk


        I already use Advanced options.
I already tried attaching Pack regsiters into IOB synthesis option to
individual FFs that will ultimately become IOB FFs, but the problem of
XST's IOB synthesis option is when a FF that will ultimately become an
IOB FF is located one or two hierarchy deep from the top module, the IOB
synthesis option attached seems to get ignored.
I believe this is a bug of XST.
So, the only way I figured out duplicating FFs that will become IOB FFs
is to use the global Pack registers into IOB option, and set it to Yes.
        I am aware of XST's synthesis options, and I do use some of them
in my PCI IP core like a "keep" attribute to prevent signals from
getting optimized, and a "blackbox" attribute when I use the infamous
PCILOGIC (The secret IRDY# and TRDY# pin thing people always talk about.
After I figured it out, it doesn't seem like a big deal.) in my PCI IP
core.
I don't like adding XST specific synthesis options to my code because I
want to keep it vendor independent, so I almost always use a synthesis
constraint file, but adding the synthesis options directly into my code
didn't make any difference either.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41114
Subject: Re: how to deal with signal pass through two clock domain
From: shengyu_shen@hotmail.com (ssy)
Date: 20 Mar 2002 22:46:04 -0800
Links: << >>  << T >>  << A >>
kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0203201627.44fb0ed@posting.google.com>...
> Why are you driving your timer with a different clock then your
> processor that is reading it?
> 

the timer can be driven by an external clock or an internal clock

Article: 41115
Subject: more questions
From: "Jimmy Zhang" <zhengyu@attbi.com>
Date: Thu, 21 Mar 2002 08:20:06 GMT
Links: << >>  << T >>  << A >>
For all the spartan II FPGA based PCI cards, can I expect the bandwidth to
be a full
blown  33Mx4 MB/s?

Also some cards seem to have implemented the PCI logic onto the FPGA
already. One
manufacture claims to have used 15K gates on the FPGA, and have left 135K
gates left
on the FPGA for other things. Just curious, if I download the code onto the
FPGA, will
I overwrite the orignal PCI logic, and from a HDL coding perspective, how do
I interface
the backend processing logic with their PCI design.

Jimmy



Article: 41116
Subject: Re: more questions
From: "Jimmy Zhang" <zhengyu@attbi.com>
Date: Thu, 21 Mar 2002 08:23:27 GMT
Links: << >>  << T >>  << A >>
Also, how would I know if the design I have is too big so that there
wouldn't be enough
resources on board to accomodate the design?

Jimmy


Jimmy Zhang wrote in message ...
>For all the spartan II FPGA based PCI cards, can I expect the bandwidth to
>be a full
>blown  33Mx4 MB/s?
>
>Also some cards seem to have implemented the PCI logic onto the FPGA
>already. One
>manufacture claims to have used 15K gates on the FPGA, and have left 135K
>gates left
>on the FPGA for other things. Just curious, if I download the code onto the
>FPGA, will
>I overwrite the orignal PCI logic, and from a HDL coding perspective, how
do
>I interface
>the backend processing logic with their PCI design.
>
>Jimmy
>
>



Article: 41117
Subject: Difference between two mulplications?
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Thu, 21 Mar 2002 16:56:54 +0800
Links: << >>  << T >>  << A >>
What makes them different in ISE 4.1?

Case A:
assign beta_X_x = beta_tmp * x;
assign beta_X_y = beta_tmp * y;
assign meanpos_temp1 = {y, {5'h00}} + beta_X_x - beta_X_y;

Case B:
assign meanpos_temp1 = beta_tmp * x + (6'd32 - beta_tmp) * y;

What did happen was that the gate level simulation of the two are different.
Case A is same as RTL simulation, Case B differnet.

Any comments?

--
Email: qijun@okigrp.com.sg



Article: 41118
Subject: Re: low cost PCI spartan board needed
From: "Jimmy Zhang" <zhengyu@attbi.com>
Date: Thu, 21 Mar 2002 08:58:13 GMT
Links: << >>  << T >>  << A >>
A question from a newbie,

 Can I program the FPGA via PCI interface thru device calls?

Jimmy
Kevin Brace wrote in message ...
>Who is "they" in this case?
>You mean, Insight Electronics?
>All the reference design's software is for Windows 9x/NT/2000.
>Another thing I should add is that according to another person who was
>interested in this board said Insight Electronics discontinued the
>board.
>Supposedly, they are going to release a new one at some point.
>
>
>
>Kevin Brace (In general, don't respond to me directly, and respond
>within the newsgroup.)
>
>
>
>Jimmy Zhang wrote:
>>
>> Just curious if they have a Linux version of the driver or not?
>>
>> Jimmy



Article: 41119
Subject: doubt on GDSII file integration
From: satya@iwavesystems.net (satya)
Date: 21 Mar 2002 01:59:52 -0800
Links: << >>  << T >>  << A >>
Hi all,
I have a small doubt.Say I have 2 cores whose GDSII files are
available(layout files) and at later point of time I decided to
integrate the two cores.Is it possible to integrate the two GDSII
files at the fab itself?or should I repeat the whole process
integrating the cores at RTL level?
Please clear my doubt.I will be waiting for ur reply.

Thanks and Regards
- satya

Article: 41120
Subject: RAM initialization
From: "Wolfgang Pieper" <amor@hs-bremen.de>
Date: Thu, 21 Mar 2002 11:01:51 +0100
Links: << >>  << T >>  << A >>
Hi all,

I would like to initialize my ramb4_S4 with the following expression:

attribute INIT_00: string;
attribute INIT_00 of INST_RAMB4_S4: label
is"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A0980706050403020100";

Syntesizing is passed without error/warning, but translating tells:

    WARNING:NgdBuild:526 - On the RAMB4_S4 symbol
        "inst_ramb4_s4/Mram_mem_inst_ramb_0", the following properties are
undefined:
        INIT_00, INIT_01, INIT_02, INIT_03, INIT_04, INIT_05, INIT_06,
INIT_07,
        INIT_08, INIT_09, INIT_0A, INIT_0B, INIT_0C, INIT_0D, INIT_0E,
INIT_0F. A
        default value of all zeroes will be used.

    WARNING:NgdBuild:486 - Attribute "INIT_00" is not allowed on symbol
        "inst_ramb4_s4" of type "ram_1024_4".  This attribute will be
ignored.

Is it right, that XST (the Syntsize-tool in Xilinx free ISE WebPack) ignores
others than predefined attributes? Or what's wrong?

Thank's a lot!





Article: 41121
Subject: Re: doubt on GDSII file integration
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Thu, 21 Mar 2002 18:06:29 +0800
Links: << >>  << T >>  << A >>
you will need some software from Cadence, the Design Framework II, in which
Virtuosso can be
used to draw layouts. It is a very expensive software.

--
Best Regards,
-----------------------------------------------------------------
Xu Qijun
Engineer
OKI Techno Centre (S) Pte Ltd
Tel: 770-7049 Fax: 779-1621
Email: qijun@okigrp.com.sg
"satya" <satya@iwavesystems.net> wrote in message
news:82741d43.0203210159.77f8de34@posting.google.com...
> Hi all,
> I have a small doubt.Say I have 2 cores whose GDSII files are
> available(layout files) and at later point of time I decided to
> integrate the two cores.Is it possible to integrate the two GDSII
> files at the fab itself?or should I repeat the whole process
> integrating the cores at RTL level?
> Please clear my doubt.I will be waiting for ur reply.
>
> Thanks and Regards
> - satya



Article: 41122
Subject: simulation issues
From: "H.L" <alphaboran@yahoo.com>
Date: Thu, 21 Mar 2002 12:06:35 +0200
Links: << >>  << T >>  << A >>
Hello all,
I have already searched in google for past posts regarding post-PAR and
post-map simulation in modelsim but I still have a question. Post-map
simulation includes the block delays (worst case) for the design but not the
routing delays, so if the post-map simulation is OK and the timing analyzer
after PAR reports no timing errors is it necessary to simulate the post-PAR
simulation model?

Greetings,
Harris



Article: 41123
Subject: Re: simulation issues
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Thu, 21 Mar 2002 19:06:38 +0800
Links: << >>  << T >>  << A >>
better to perform post-PAR simu in case the synthesizer make mistakes.

--
Best Regards,
-----------------------------------------------------------------
Xu Qijun
Engineer
OKI Techno Centre (S) Pte Ltd
Tel: 770-7049 Fax: 779-1621
Email: qijun@okigrp.com.sg
"H.L" <alphaboran@yahoo.com> wrote in message
news:a7cbc9$1d4f$1@ulysses.noc.ntua.gr...
> Hello all,
> I have already searched in google for past posts regarding post-PAR and
> post-map simulation in modelsim but I still have a question. Post-map
> simulation includes the block delays (worst case) for the design but not
the
> routing delays, so if the post-map simulation is OK and the timing
analyzer
> after PAR reports no timing errors is it necessary to simulate the
post-PAR
> simulation model?
>
> Greetings,
> Harris
>
>



Article: 41124
Subject: Re: more questions
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 21 Mar 2002 11:59:20 +0000
Links: << >>  << T >>  << A >>
"Jimmy Zhang" <zhengyu@attbi.com> writes:

> For all the spartan II FPGA based PCI cards, can I expect the
> bandwidth to be a full blown 33Mx4 MB/s?
> 
Unlikely, for any PCI implementation I would think.  You can get that
in a burst, but I doubt you will achieve sustained transfers of that
magnitude.  Anyone got any experience of real-world sustained
transfer rates on PCI?

> Also some cards seem to have implemented the PCI logic onto the FPGA
> already. One manufacture claims to have used 15K gates on the FPGA,
> and have left 135K gates left on the FPGA for other things. Just
> curious, if I download the code onto the FPGA, will I overwrite the
> orignal PCI logic, and from a HDL coding perspective, how do I
> interface the backend processing logic with their PCI design.
> 

You will need to implement their PCI logic with your logic.  It will
be supplied in HDL, or netlist form.  The supplier *should* give you
all the details, and hopefully some sample designs to work from.  It's
unlikely you will be able to reconfigure part of the FPGA with your
own logic and leave the PCI bit alone.  Apparantly the silicon is up
to it in some families, but the tools don't make implementations like
this straightforward.

HTH,
Martin
 

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
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
2017JanFebMarApr2017

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