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 42625

Article: 42625
Subject: Re: un-constraint path - from Clock pad to FFS clock pin
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Mon, 29 Apr 2002 16:18:27 GMT
Links: << >>  << T >>  << A >>
On 29 Apr 2002 08:03:18 -0700, ospyng@yahoo.com (spyng) wrote:

>hi,
>does anyone have experience these?
>
>CLK pad input to FF show up as unconstraint path during timing
>analysis. and reduce coverage of timing constraint (90.5%). These
>un-constraint paths are the clock delay from the clk pad to the clk
>pin of the FFS
>
>Clk Pad input goes through a DCM and generate a internal clk to most
>of the ffs in the design. there is currently a period constraint on
>the clk pad input and during translate, there is message that show
>that the period constraint have been push through the DCM and new
>period constraint had been generated for the internal clock. The
>internal clock period constraint is working fine.
>
>Why are all paths from Clk pad input to all ffs clk pin show up as an
>unconstraint path?

Because they're not constrained.

The delay from the input pin to an internal flip-flop or RAM has no
effect on the speed at which the device can be clocked internally.  If
you have a 50 MHz  period constraint, the internal paths do not care
if the delay from the clock pin to the internal FFs and RAMs is 0.5ns
or 500ns, as long as that delay is common to all devices; in either
case, you'll still be able to run at 50 MHz.  (Of course, there is the
issue of whether a 500ns path could actually pass a 10ns pulse, but
that's a topic for another day.)

I always add constraints for the pads-to-internal-devices clock paths,
because I don't want my unconstrained paths report to be cluttered
with stuff that's actually OK.  And it's also a good way to confirm
that the delay is what I expect it to be.  For example, I added the
following constraint in the ucf file to a 100 MHz clock passing
through a DCM in a 2V3000:

TIMESPEC TSCLK04 = FROM PADS(ext_clk100) TO FFS     : 0.5;

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

Article: 42626
Subject: Re: Partial reconfiguration
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Mon, 29 Apr 2002 16:24:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3cccf815@news.broadpark.no>,
Stein Kjølstad <stein.kjolstad@visitech.no> wrote:
>Is it possible to use the dedicated SelectMap data pins D0..D7 as ordinary
>IO-pins
>when configuration is finsihed and at the same time support partial
>reconfiguration? Readback does not need to be supported. I would like D0..D7
>to be used as part of a 16 bit wide microprocessor data bus, when the FPGA
>is not in configuration mode or partial reconfiguration mode.

I assume you are refering to Virtex 1 family (Virtex/Virtex E/Spartan II
and IIe) and not the Virtex 2?  This pertains to Virtex 1:

In order to enable partial reconfiguration, those pins must be used as
the dedicated SelectMap port, so you can't share the pins if you want
to do partial reconfiguration on the same design, to the best of my
recolection.  Also, if you want to do partial reconfiguration from
WITHIN the part, you have to have another set of pins to drive the
SelectMap port.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42627
Subject: Re: 4005XL and 4010XL compatibility
From: Jon <jlocker@flash.net>
Date: Mon, 29 Apr 2002 16:52:39 GMT
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Click on
> http://www.xilinx.com/partinfo/ds006.pdf
> 
> and look for the XC4000E/XL pin-out tables.
> You may have to print out two pages and do a visual compare...
> Sorry for the inconvenience, but my memory does not serve me well
> enough to give you a reliable answer.

Well, I did the heavy lifting and it appears that the two chips are pin
compatible - or at least I could drop in the 4010 for my application. 
Still, I'd sleep better knowing that someone else had already done this
with no problems.

Jon

Article: 42628
Subject: Re: 4005XL and 4010XL compatibility
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 29 Apr 2002 10:31:33 -0700
Links: << >>  << T >>  << A >>
Jon, if you "did the heavy lifting"(=comparing two sets of 144 names),  and
found that the pin descriptions are identical for the two parts, then you have
no reason to hesitate. We made these devices intentionally pin-compatible. We
used to make a big issue of this, allowing migration to a larger device, or
allowing prototyping with a larger chip, then streamlining the design for
production in a smaller chip, all without changing the pc-board.

Just go ahead and trust us...

Peter Alfke, Xilinx Applications
================================
Jon wrote:

> Peter Alfke wrote:
> >
> > Click on
> > http://www.xilinx.com/partinfo/ds006.pdf
> >
> > and look for the XC4000E/XL pin-out tables.
> > You may have to print out two pages and do a visual compare...
> > Sorry for the inconvenience, but my memory does not serve me well
> > enough to give you a reliable answer.
>
> Well, I did the heavy lifting and it appears that the two chips are pin
> compatible - or at least I could drop in the 4010 for my application.
> Still, I'd sleep better knowing that someone else had already done this
> with no problems.
>
> Jon


Article: 42629
Subject: Re: High current I/O on SpartanXL
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 29 Apr 2002 20:02:32 +0200
Links: << >>  << T >>  << A >>
"Frank Zampa" <NOSPAMingzampa77@yahoo.com> schrieb im Newsbeitrag
news:3ccce74e.1754152@news.inet.it...
> Hi,  I must configure some pins on this device with 24mA output
> drive.Where can I find this option (in the UCF file, in the Project
> Manager, ..)?

In the UCF write

NET my_net_name drive=24;

--
MfG
Falk





Article: 42630
Subject: Re: DCM off chip deskew
From: mrand@my-deja.com (Marc Randolph)
Date: 29 Apr 2002 11:13:21 -0700
Links: << >>  << T >>  << A >>
Patrik Eriksson <patrik.eriksson@netinsight.net> wrote in message news:<3CC51356.90000@netinsight.net>...
> My question was/is:
> 
> I'm using an DCM to deskew an external clock relative to an internal
> clock. The feedback signal is connected through an global clock input
> pad. How does the input delay of the feedback signal affect the skew 
> between the internal and external clock?
> 
> Device: xc2v1500-4FG676C
> 
> Xilinx support answered the following:
> 
> The return delay to the DLL must be equal to the dealy to the other chip.
> If the delay is not the same then the external clock will not appear to 
> be deskew.
> 
> The delay that the input buffers introduce must be monitored as well.
> 
> In a board-level clock deskew; when two different I/O Standard IBUFGs 
> for the CLKIN and the CLKFB, the DCM will not lock.
> 
> This happens because the maximum phase difference allowed for the DCM to 
> work correctly between CLKIN and CLKFB is 100 ps. If the CLKFB and CLKIN 
> are using two different I/O standards that introduce a differential 
> delay greater than 100 ps, the CLKDLL will not lock or function correctly.
> 
> One example is using an IBUFG_LVPECL for the CLKIN and IBUFG for the 
> CLKFB. The differential delay in this case is 150 ps; therefore, the DCM 
> will not work.
> 
> To prevent this, ensure that the maximum phase difference between CLKFB 
> and CLKIN is less than 100 ps.
> 
> 
> Can anyone help me understand the answer? If the phase difference 
> between CLKFB and CLKIN is less than 100 ps I don't need to deskew the 
> signals ;-()

Howdy Patrik,

I'm surprised by several things:

1. That no-one (including Xilinx) has responded to this post
2. That Xilinx would misunderstand your question so much
3. That Xilinx would give you that answer (even if they did
misunderstand your question).

As much as I hate to say it, I think you have ignore Xilinx's answer
here.
CLKIN_CLKFB_PHASE (the value quoted above by Xilinx) appears to be an
output timing parameter, not input (this it the reason for my
statement #3, above).  Do a search in the .pdf.

I can guess an answer for you (it's the same thing that I've assumed
in my use of offchip deskew on the Virtex-E), but you may want to
repose your question to Xilinx, or maybe someone else that knows for
sure will respond here.

My assumption when generating a deskewed clock is that you must count
everything.  You have to count the on-chip routing delay from the
DLL/DCM, count the output IOB delay driving off chip, count the
routing delay on the PCB, and count the input IOB delay back on chip.

The best (only?) way to get ALL of these values, that I'm aware of, is
to run timing analyzer.

But in looking at this a bit closer, I realized that I have a question
about this as well.  Not that it will change my design - on the PCB, I
simply make the feedback net the same length as the net going to the
remote device, and that gets me close enough.

My question arises from the output of timing analyzer, with respect to
using a normal `GCLK' pin vs. a `DLL' pin for the clock input to a
DLL:


Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tiodll                0.000   CLKIN1
                                  CLKIN1_ibuf
    net (fanout=1)        0.000   CLKIN1_c
    Tdllino              -1.924   I14/I24/I0
    net (fanout=1)        0.000   I14/clk1_dll
    Tgio                  0.500   I14/I23/I0
    net (fanout=373)      0.729   clk1
    ----------------------------  ------------------------------
    Total                -0.695ns (-1.424ns logic, 0.729ns route)

But that can't be right, can it?!  Tiodll is really zero?  Compare
that to when you use a global clock input:

Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tgpio                 0.700   CLKIN2
                                  CLKIN2_ibuf
    net (fanout=1)        0.000   CLKIN2_c
    Tdllino              -1.924   I14/I15/I0
    net (fanout=1)        0.000   I14/clk2_dll
    Tgio                  0.500   I14/I18/I0
    net (fanout=2371)     0.829   clk2
    ----------------------------  ------------------------------
    Total                 0.105ns (-0.724ns logic, 0.829ns route)

Notice how the total comes very close to being equal to zero?  This is
what I'd expect.  If you pretend the input delay of the DLL pad is
also .7, then suddenly the total for clk1 is a slightly positive
number, just like clk2.

Any hints on this from anybody?  Is the Xilinx timing file wrong on
Tiodll?

Have fun,

   Marc

Article: 42631
Subject: Re: ABEL for the Altera MAX 7000
From: James Horn <jimhorn@svn.net>
Date: 29 Apr 2002 11:33:05 -0800
Links: << >>  << T >>  << A >>
Back in '94 I needed to do just that - convert a significant ABEL design 
to MAX7000 parts.  We bought the Altera fitter add-on to Data I/O's ABEL 
package and started doing so.

However, the "fitter" just took the optimized logic file from ABEL and 
re-compiled it in Altera's Max+Plus II.  The (frequent) error messages 
referred to the intermediate logic file and were of limited use and lots 
of frustration.

Finally, after a week or so of effort I spent a day converting the 
numerous ABEL files to AHDL and compiled them in Max+Plus II directly.  
The results fit better, were easier to understand, and - frankly - were 
much easier to create.  A bonus was that the source was smaller, clearer, 
and more understandable as well.

Having spent years using ABEL and AHDL, I strongly perfer the latter.  The 
only downside of course is that it locks you into Altera's parts.  But if 
you're going to use them anyway, it's a good way to go.  Besides, 
translating between the two languages that are so doggone similar is 
simple anyway.

Jim Horn

Article: 42632
Subject: Re: SpartanII design considerations...
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 29 Apr 2002 13:43:10 -0700
Links: << >>  << T >>  << A >>
Hi, Kevin, I was not accusing you, I was just annoyed at the whole issue, which really
is a non-issue:

The Spartan-II shows correctly in Fig. 2 of its data sheet, that the internal OE
control signal is active High. ( Anybody should be able to deduce that this imlies that
the 3-state control is active Low).

It also says that polarity can be controlled by software.
I looked at the detailed schematic. You can flip around the polarity of:

•the T or OE input
•the D of the OE-control flip-flop
•its CE
•its clock
•its S/R input
•the direct O signal
•the D of the data output flip-flop
•its CE
•its clock
•its S/R signal that is shared with the OE-control flip-flop and the Input FF
• the CE of the input flip-flop
•and its clock.

In other words, you can change almost any polarity in the whole I/O.

But we tacitly assumed that everybody knows the big difference between Output Enable
and Tristate. They are not the same thing, they are the opposite of each other !
Maybe we should have included a tutorial...
That's what I meant by "silly misunderstanding"

Peter Alfke, Xilinx Applications
==============================
Kevin Brace wrote:

> > Life is too precious to be wasted on such silly misunderstandings.
>
>         What do you mean?
> Are you saying that I should have known that Virtex IOB tri-state
> buffers are active low?
> I think what I said previously should have been included in Spartan-II
> datasheet.
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)
>
> Peter Alfke wrote:
> >
> > It's the old confusion between output enable and tristate, which obviously are the
> > opposite of each other. But we should, therefore, make it redundantly absolutely
> > and perfectly clear that active High OE is identical with active Low 3-state ( and
> > vice versa).
> > Life is too precious to be wasted on such silly misunderstandings.
> >
> > Peter Alfke, Xilinx Applications
> > =============================================


Article: 42633
Subject: Power-up reset of Xilinx Spartan-II
From: "Barry Brown" <barry_brown@agilent.com>
Date: Mon, 29 Apr 2002 14:18:41 -0700
Links: << >>  << T >>  << A >>
My design uses a Spartan-II configured from a PROM, and I'm using a clock
DLL in the FPGA.  I have had some problems that I believe are due to
power-up initialization, so I'm trying to come up with a fool-proof scheme
to handle power-on config and reset.  Here's my plan:

1. My board has a power-supply supervisor, which I will connect to the
PROGRAM input.  This will hold off loading configuration until well after
the supply is stable, and in case the power ever glitches, the FPGA should
re-load itself.

2. In BitGen, I will set LCK_cycle to 1, so that the startup after
configuration will wait until the DLL is locked.

3. I will connect the DONE signal to an input, where I will invert it and
synchronize it and use it as the internal reset for my circuits in the FPGA.

4. I will set GTS_cycle = 2, GSR_cycle =3, and GWE_cycle = 3.  I will set
DONE_cycle = 6.  Therefore, my internal reset will be asserted until a short
while after the DLL is locked and the GSR is released.

Anyone see a problem here?

Thanks,
Barry Brown



Article: 42634
Subject: Re: Changing ROM contents
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Mon, 29 Apr 2002 15:27:51 -0600
Links: << >>  << T >>  << A >>


There is a new tool in the 4.2i software called DATA2BRAM that should
address your needs.  It is documented in the online docs at:
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/d2b/d2b.html  I would
take a look at this utility and see if it fits your requirements.


--  Brian



Paul wrote:

> Hy,
>
> I am using a ROM in my design on a VirtexE-1000. This ROM is made as a
> RAM block where the WE signal is always inactive. To write the initial
> value to the ROM I regenerate the core (core generator) assigning a
> new init file to the memory. The problem is that doing it I have to
> re-synthetize and P&R the whole design everytime I want to change some
> value in the ROM. Is there any way to change the ROM content without
> synthesis and P&R?? (I am using Xilinx ISE 4.2 tools and the XST
> synthetizer)
>
> Thaks in advance!!
> Paul.



Article: 42635
Subject: Loading values in Quartus II Waveform editor
From: prashantj@usa.net (Prashant)
Date: 29 Apr 2002 15:55:46 -0700
Links: << >>  << T >>  << A >>
hi,
I'm using the Quartus II simulator to simulate my design. My design
has grown and reached a point where I need to load up a thousands of
different input vectors for a specific input. It would be a waste of
time to try and do this manually.

Is there a smart way to load many input vector values on a single
input in the waveform editor of Quartus II waveform editor ?

Thanks,
Prashant

Article: 42636
Subject: Tristate and Output Enable
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 29 Apr 2002 16:07:58 -0700
Links: << >>  << T >>  << A >>


Please allow me to follow up with interesting information
from Eric Crabill:

From a primitive point of view, the IOB has a "T" input.
All of the primitives in the library have "T" inputs.
It really is a "T" (TRISTATE) signal, active high.

1.
As far as I am aware, you cannot change the polarities
by what you do in the design, short of using FPGA Editor.

2.
If you are in schematics, all the library elements have
a "T" pin on them, so you would probably just implement
a tristate logic function to directly control the I/O.
This is somewhat natural and obvious.  But most people are
not using schematics anymore...

3.
If you are in HDL-land, here is one example of what a
designer might do:

assign bidir = my_oe ? my_value : 1'bz;

In this case, the synthesis tool probably generates
the following circuit:

my_oe ---> inverter ---> T pin on I/O primitive

Here, the inverter can be pushed forward into the IOB
by the mapper, using the local inversion (instead of
a separate lut).  It is also possible that either the
mapper or the synthesis tool could push the inverter
backwards into the logic that was driving my_oe.

If you are in HDL-land, here is another example of what
a designer might do:

assign bidir = my_t ? 1'bz: my_value;

In this case, the synthesis tool probably generates
the following circuit:

my_t ---> T pin on I/O primitive

Here, there is no need for inverters anywhere, so nothing
special is done, and this logic is what gets implemented.

I think the idea of those local inverters in the IOB is
that the CAD tools can compensate for a designer who is
not aware of the architecture.  If the local inverters did not exist,
the coding style of the HDL designer would impact the
circuit performance (that extra "inverter" would cost
something in terms of delay, because it would be in a LUT).

Eric





Article: 42637
Subject: Re: Does Vertex II PRO Really work?
From: davisbmoore@netscape.net (Davis Moore)
Date: 29 Apr 2002 16:08:26 -0700
Links: << >>  << T >>  << A >>
I agree that this is priceless, but...

Is it possible the IP address was spoofed?

I don't know a lot about it, but I am mostly posting
as a test by repeating the apparent steps that "Hideout" followed:

1. Get a generic email account www.usa.com.
(I used netscape.net)

2. Register the generic account with google groups.

3. Post to google groups.

(I am just a curious Xilinx employee.)


Brian Drummond <brian@shapes.demon.co.uk> wrote in message news:<g83lcugkcdlhmi5sb75fh7eblc4c5spmhl@4ax.com>...
> On 25 Apr 2002 18:47:09 -0700, hideout@usa.com (SECRET) wrote:
> 
> >Hi,
> >
> >I noticed that Xilinx is claiming on their website that they have a
> >Vertex II PRO with a 3.125 Gbps Transceiver and up to 4 IBM PowerPC
> >Processors?  Can you actually get silicon for this or is this just
> >Marketing BS?
> >
> >(do not e-mail me.. just post here)
> >
> >>Hideout<
> 
> Priceless...
> 
> Turn the headers on. See a line that says
> NNTP-Posting-Host: 66.35.226.228
> 
> Try a lookup...
> 
> IP address: 66.35.226.228
> Official name: ip66-35-226-228.altera.com
> 
> 
> oops!
> 
> - Brian

Article: 42638
Subject: Re: Does Vertex II PRO Really work?
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 30 Apr 2002 00:07:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1259ab37.0204291508.3700008a@posting.google.com>,
Davis Moore <davisbmoore@netscape.net> wrote:
>I agree that this is priceless, but...
>
>Is it possible the IP address was spoofed?


The posting is done through google, and google's newsgroup poster does
log the IP, so this initially suggests that it is through the given IP.

IP address spoofing is a lot harder when you want to convey
information, not just forge a SYN (connection request).  It may be
possible (I'm not sure how sequence numbers are defined), but would be
very vulnerable to dropped packets and other issues.

My bet is that it is some intern at Altera, thinking it would be a
funny joke.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42639
Subject: Re: Does Vertex II PRO Really work?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 29 Apr 2002 17:16:09 -0700
Links: << >>  << T >>  << A >>
It's not germ warfare yet, but it is getting closer...
  :-(
Peter Alfke




Article: 42640
Subject: Re: Xilinx XC9500XL family - disabling the bus-hold circuits
From: Mark Ng <mark.ng@xilinx.com>
Date: Mon, 29 Apr 2002 17:48:12 -0700
Links: << >>  << T >>  << A >>
Hi Len,

It is definitely possible to disable the bus-hold circuitry in all 9500XL
devices.

Disabling the bus-hold circuit has always been physically possible -  It's just
that we didn't advertise it as such when the devices first came out.  Now it's a
feature in software because people have asked for it...

Best Regards,
Mark

Len Chisholm wrote:

> Hi all,
>
> While searching for some detailed information about the 9500XL family,
> I tripped over an item in the Answer Database containing a very
> interesting comment.
>
> Answer #5175 "CPLD XC9500XL/XV - What is the bus-hold circuit?" has
> the following paragraph :
>
> This bus-hold circuit is always enabled during normal operation. To
> turn this feature off, select the "Disable BUSHOLD Circuit" option
> under the "Generate Programming File" process properties in Project
> Navigator. This option is only available as of 4.1i Service Pack 2.
>
> However, the data sheet for the 9500XL family does not say that this
> is possible - although the data sheet is dated June 1999 and
> sub-titled "Preliminary Product Specification"
>
> Can anybody shed any light on this ?
>
> I'd like to know if it is really possible to disable the bus-holders
> in the 9536XL - this would be extremely useful to me. I'm surprised
> that this information seems to have only become visible in November
> 2001 ( the date of the answer record ).
>
> Is it that somebody has only just realised that it is physically
> possible, that somebody has finally asked for it, or that it is only
> available in more recent revisions of the chip ?
>
> Hoping for the right answer :-)
>
> Len Chisholm.


Article: 42641
Subject: Re: Loading values in Quartus II Waveform editor
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 29 Apr 2002 22:16:03 -0500
Links: << >>  << T >>  << A >>
Isn't it time to move to an HDL-based simulator?



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

Article: 42642
Subject: SpartanII ISA interface, IDE and ISA contention??
From: Sean A Laughter <s2salaug@mail2.vcu.edu>
Date: Tue, 30 Apr 2002 00:37:02 -0400
Links: << >>  << T >>  << A >>
Hi all,

I'm interfacing the Spartan-II over a PC/104 bus as an IO device.  In my
logic there is a finite state machine that for all intents and purposes
should never be stopping no matter what happens.  It just relies on a
counter to trigger it and it goes, and the counter isn't stopping.  This
FSM just triggers an external A/D-converter and writes samples to a FIFO
in the FPGA.  It doesn't test for a full FIFO as the FIFO doesn't allow
writes if it's full anyway, so we just let it run nonstop regardless of
the fullness state of the FIFO.  Therefore it should never stop.
However, for some reason at a certain point in the program this FSM just
stops going for no apparent reason.  The system reset is staying low and
the trigger for the FSM is still going, the FSM just mysteriously stops!

This Spartan-II is on a device that is connected to a PC on a card running
software that writes
samples retrieved from the FPGA onto the D: drive (a compact flash card
set as the slave drive on the IDE bus).  Since this is the PC/104 bus it
appears the IDE and ISA signals are shared (not sure if this is the case
in a regular PC or not).  I noticed that it looks like the crash could
possibly be happening when there is a write to the compact flash card.
Could I be doing something really wacky because the Spartan is responding
to IDE bus signals?  If so, would I need to compensate for this by
decoding the IRQ14 signals or maybe the IDECS0# or IDECS1#.  I haven't
been able to find a good resource for IDE information, so if anyone could
point one of those out too it would be great.

I'm not sure if this IDE thing is my problem, but at this point it's about
the only thing I can think of that would even remotely be causing this
behavior.  Thanks alot.

Sean


Article: 42643
Subject: Query on Power Compiler.
From: "Kelvin XCJ" <qijun@okigrp.com.sg>
Date: Tue, 30 Apr 2002 14:18:13 +0800
Links: << >>  << T >>  << A >>
Hi:

I am learning Power Compiler from Synopsys. My example is a 5-bit
ring counter at 200MHz and a synchronous Add-1 counter. The counter
is supposed go to zero and continue when it reaches 19.
Does it mean if I estimate the switching rate at the five registers in
each design, and run report_power, it will generate me the correct power
report?

My constraints are 1)
include syn_1.scr
create_clock -name clk_100m -period 10 -waveform {0 5} {clk_100m}
set_switching_activity -clock clk_100m -toggle 0.5 -static 0.1 S0
set_switching_activity -clock clk_100m -toggle 0.25 -static 0.1 S1
set_switching_activity -clock clk_100m -toggle 0.125 -static 0.1 S2
set_switching_activity -clock clk_100m -toggle 0.0625 -static 0.1 S3
set_switching_activity -clock clk_100m -toggle 0.03125 -static 0.1 n982
report_power > myfile.log

2)
include syn_2.scr
create_clock -name clk_100m -period 10 -waveform {0 5} {clk_100m}
/* Does it mean their switching activity are same in the two counters? */
set_switching_activity -clock clk_100m -toggle 0.5 -static 0.1
swl_counter_reg[0]
set_switching_activity -clock clk_100m -toggle 0.25 -static 0.1
swl_counter_reg[1]
set_switching_activity -clock clk_100m -toggle 0.125 -static 0.1
swl_counter_reg[2]
set_switching_activity -clock clk_100m -toggle 0.0625 -static 0.1
swl_counter_reg[3]
set_switching_activity -clock clk_100m -toggle 0.03125 -static 0.1
swl_counter_reg[4]
report_power >> myfile.log

I am wondering what are the difference in their power report? I found the
add-1 counter
is 150uW, ring counter takes 140 uW. Is this a reasonable number? What is
the gain in
power consumption when people choose ring counter instead of normal?

Please attach to cobraxu@singnet.com.sg

 Thanks
 Kelvin




Article: 42644
Subject: Re: fpga limitation
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Tue, 30 Apr 2002 06:59:55 -0000
Links: << >>  << T >>  << A >>
In article <3CC421BB.E48790FD@xilinx.com>,
 Austin Lesea <austin.lesea@xilinx.com> writes:
>Hal,
>
>I wish I had the answer to that.  Complex chips = complex bypassing.
>Believe me when I say we are working on it.

Life would get boring if we didn't have problems like this.  :)


>The hole in the center is great for hiding a bunch of bypass.
>
>Blind or hidden vias a re great for that as well (caps on the back of
>the board).

I'm having troubles picturing how to use blind/burried vias to
get better bypassing.  If the BGA is on one side of the board
and the bypass caps are on the other, blind vias are evil in
the sense that they prevent connecting the BGA to the cap which
is the whole object of the bypass cap.

Are you thinking of something like using blind vias where full
length vias would otherwise collide with the pads for the caps?
And (magically/luckily) placing each cap so it hits a couple of
appropriate (non blind) vias from the BGA?

Any estimates on the cost of using "a few" blind vias for something
like this?


>0402 is better than 0603 for SM caps (smaller is better, less
>inductance, and you can pack more on the pcb).

Got any numbers?  How does N 0402 caps compare with M 0603 caps,
assuming vias-in-pads?  What if I use 2 vias per pad on the 0603?

>Austin


Thanks.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 42645
Subject: Re: Loading values in Quartus II Waveform editor
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Tue, 30 Apr 2002 08:14:03 +0100
Links: << >>  << T >>  << A >>
You can use a .vec or .vwf file which is just a text representation of the
signal transitions. Edit this and use it as stimulus to your simulation.
Results will still get displayed.
(You can start by saving your current waveform as a .vec/.vwf and looking at
the results/modifying it.

IMHO however you might want to consider using another simulator that
supports more functions of a testbench. You write a test bench in your HDL
which provides the waveforms and/may even check the results of the Device
Under Test.

I used to exclusively use waveform entry, but it really becomes limiting for
larger designs and almost impossible to do hierarchical testing.

Paul

"Prashant" <prashantj@usa.net> wrote in message
news:ea62e09.0204291455.4f95879@posting.google.com...
> hi,
> I'm using the Quartus II simulator to simulate my design. My design
> has grown and reached a point where I need to load up a thousands of
> different input vectors for a specific input. It would be a waste of
> time to try and do this manually.
>
> Is there a smart way to load many input vector values on a single
> input in the waveform editor of Quartus II waveform editor ?
>
> Thanks,
> Prashant



Article: 42646
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Tue, 30 Apr 2002 07:19:36 -0000
Links: << >>  << T >>  << A >>
>Aw, come on.  Be serious for a moment.
>
>Is 2 Mbytes enough for video, or is that just not even close for
>something like a high performance MPEG4 coder?  Is 1 Mbyte enough for a
>packet processor?  What if you are using a 405PPC?  How much code space
>do you need for a control program?  For a DSP support program (with all
>of the hard stuff in the FPGA like the FFT cores, etc.)?
>
>If you look at SDRAM prices, are you willing to pay twice the commodity
>price in an FPGA?  Three times?  How much is it worth to you?
>
>I already know that programs grow to fit the available memory space, and
>that data grows to fill the disk.....

There is obviously an chicken and egg problem.  If you put X bytes
of RAM on the chip, then people will dream up ideas to use it.  Some
of them won't fit so there will be a market for chips with more RAM.

I remember a story about Motorola...  Nothing firm, just a rumor,
but it seems reasonable.

They had a good collection of "cores" for their small micro family.
If you would sign up to purchase enough of them, they would build
whatever you wanted from their collection of cores and make it into
a standard product - n A/D, y counters, x ROM, y RAM...  Whatever
you wanted from their chinese menu. 

You got normal product type support and documentation.  They got
a guaranteed order to cover (some of?) the NRE.


That sort of chinese menu approach might make sense for something
like Easypath.  For example, you could take chips with broken RAM,
zap a few links, and sell them as no-RAM (or smaller RAM) versions.
If volume gets high enough you can make a special/cheaper die.
Same for multipliers, and maybe PowerPC cores.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 42647
Subject: Re: SpartanII ISA interface, IDE and ISA contention??
From: Jens Hildebrandt <jens.hildebrandt@etechnik.uni-rostock.de>
Date: Tue, 30 Apr 2002 09:44:20 +0200
Links: << >>  << T >>  << A >>


Sean A Laughter wrote:
> 
> Hi all,
> 
> I'm interfacing the Spartan-II over a PC/104 bus as an IO device.  In my
> logic there is a finite state machine that for all intents and purposes
> should never be stopping no matter what happens.  It just relies on a
> counter to trigger it and it goes, and the counter isn't stopping.  This
> FSM just triggers an external A/D-converter and writes samples to a FIFO
> in the FPGA.  It doesn't test for a full FIFO as the FIFO doesn't allow
> writes if it's full anyway, so we just let it run nonstop regardless of
> the fullness state of the FIFO.  Therefore it should never stop.
> However, for some reason at a certain point in the program this FSM just
> stops going for no apparent reason.  The system reset is staying low and
> the trigger for the FSM is still going, the FSM just mysteriously stops!
> 
> This Spartan-II is on a device that is connected to a PC on a card running
> software that writes
> samples retrieved from the FPGA onto the D: drive (a compact flash card
> set as the slave drive on the IDE bus).  Since this is the PC/104 bus it
> appears the IDE and ISA signals are shared (not sure if this is the case
> in a regular PC or not).  I noticed that it looks like the crash could
> possibly be happening when there is a write to the compact flash card.
> Could I be doing something really wacky because the Spartan is responding
> to IDE bus signals?  If so, would I need to compensate for this by
> decoding the IRQ14 signals or maybe the IDECS0# or IDECS1#.  I haven't
> been able to find a good resource for IDE information, so if anyone could
> point one of those out too it would be great.
> 
> I'm not sure if this IDE thing is my problem, but at this point it's about
> the only thing I can think of that would even remotely be causing this
> behavior.  Thanks alot.
> 
> Sean

Hi Sean,

I don't know what kind of computer system you are using, but according to your
description it is no real PC/104 bus since there are no IDE signals in PC/104
(see specification at http://www.pc104.org/technology/PDF/PC104Specv246.pdf).
You should look in the documentation of your board since there seem to be done
some proprietary extensions by the board vendor. Since IDE can be easily derived
from the ISA bus (and PC/104 is nothing else, just in a different format with
some electrical characteristics changed) it could be that the manufacturer
simply used some logic gates to generate IDECS0# and IDECS1# from address lines
above SA2 and added them to the original PC/104 signal. How this decoding is
done exactly should be stated in your manuals (at least I would expect to find
it there).
Some information about the IDE bus you can find at http://ata-atapi.com or at
http://www.t13.org .

Good luck,
 Jens


Article: 42648
Subject: Re: fpga limitation
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Tue, 30 Apr 2002 09:30:54 +0100
Links: << >>  << T >>  << A >>
Hal Murray wrote

> Any estimates on the cost of using "a few" blind vias for something
> like this?

Not as much as it used to be :)  Fairly mainstream technology now.

As someone else noted, fan the inner balls inwards, then the outer
balls outwards, generating a little 'ring' for the caps.

> >0402 is better than 0603 for SM caps (smaller is better, less
> >inductance, and you can pack more on the pcb).
>
> Got any numbers?  How does N 0402 caps compare with M 0603 caps,
> assuming vias-in-pads?  What if I use 2 vias per pad on the 0603?

Lots of good info on the PhyComp site (ex-Philips Components)





Article: 42649
Subject: power supply sequencer for Virtex II
From: ydeville@cmseddyscan.com (Deville)
Date: 30 Apr 2002 02:07:28 -0700
Links: << >>  << T >>  << A >>
Hi all,

For Virtex, are there any issues regarding powering up the different
voltage supplies in different orders?
What sort of component can be use for supplying the Virtex?

best regards,

YD



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