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 16350

Article: 16350
Subject: Re: 4062XL problems and solutions
From: Le mer Michel <michel.lemer@ago.fr>
Date: Tue, 18 May 1999 10:11:13 +0200
Links: << >>  << T >>  << A >>
Bill Kury wrote:

> Hi!  I just finished a project using a 4062XL from Xilinx and I would
> like to get some feedback on some of the problems that I ran into.  A
> little info, this device was running on a 80 Mhz clock with most of the
> internals stepped down to 40 Mhz.  Utilization was about 25% of the
> device.  Yes, I agree that the part should be smaller but, there will be
> more added in the future.  Everything was coded in Vhdl using Aldec
> tools and Fpga express.
>
> Problem #3 - High speed visibility
>   This isn't so much a problem but a question to ask how you do it.
> When running at high speed internal to your fpga, how do you get
> visibility into the device without changing the routing?  I know you can
> check the static timing and this will resolve 99.99% of your problems.
> What I did was allowed some extra pins on the design to route signals
> out to so that I could take a look.  This worked well but, at the high
> speeds, routing to pins will change your internal routing delays and
> possibly mask the problem.  Are there any other solutions out there?

I use pipelined flip-flop, which limit the routing modifications, and I
have to consider that these signals are one clock period shifted.


Hope this helps,

Michel Le Mer
Gerpi sa (Xilinx Xpert)
3, rue du Bosphore
Alma city
35000 Rennes (France)
(02 99 51 17 18)
http://www.xilinx.com/company/consultants/partdatabase/europedatabase/gerpi.htm

Article: 16351
Subject: Re: 4062XL problems and solutions
From: murray@pa.dec.com (Hal Murray)
Date: 18 May 1999 10:16:55 GMT
Links: << >>  << T >>  << A >>

> Hi!  I just finished a project using a 4062XL from Xilinx and I would
> like to get some feedback on some of the problems that I ran into.  A
> little info, this device was running on a 80 Mhz clock with most of the
> internals stepped down to 40 Mhz.

...

> Problem #1 - Clock enable
>   The biggest problem I ran into was routing getting the clock enable to
> the logic to slow it down to 40 Mhz.  In order for the clock enable to
> work properly, it has to be there in 1 80Mhz cycle = 12.5 ns. I found
> that using a bufg or bufgls did not work for especially for the iobs.
> The solution for me was to route the problem locally through another
> flop by reclocking the clock enable.


This is a good example of why I've never been very interested in
the software-will-do-everything approach to FPGA or ASIC designs.

-- 
These are my opinions, not necessarily my employers.
Article: 16352
Subject: Re: Fancy Dram problem
From: roman pollak <roman.pollak@Sun.COM>
Date: Tue, 18 May 1999 14:46:00 +0200
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> Phil Short wrote in message <373CBABF.768BD300@nospam.ix.netcom.com>...
> >Andy Peters wrote:
> >> Also register the address bus outputs.  That's a lesson learned the hard
> >> way, too.
> >
> >In general, I disagree with this one.  Setup and hold times for address
> >WRT RAS and CAS will generally require extra delay in the asynchronous
> >DRAM access cycle.  I suspect that there were better solutions to
> >whatever problem that you were trying to solve.  There are, I am sure,
> >cases where registering the address lines is a useful technique, but I
> >would never suggest this as a general solution.
> 
> Now that I think of it, the one time I did not have the address registered
> and had problems was when I used a Xicor (async) NVRAM.  The address bus was
> muxed inside an Altera EPLD whose output drove the NVRAM.  Only one load and
> not too fast, either; I think it was 20 MHz.

That was it ? You just used registered output for it ?



> 
> >But in any case, I strongly suggest the use of an oscilloscope to
> >actually observe the circuit in action.
> 
> With the NVRAM circuit, I looked at everything with an HP16500 logic
> analyzer.  I had memory corruption even with the write line tied permanently
> high.  Address and data lines were settled *weeks* before the read strobe.
> The only thing that fixed it was to simply register the address lines.  (And
> to look at the timing and make sure setup and hold requirements are still
> met.)


Sounds strange, was it a mux configuration as well or was it address and
treestate ?


regards roman
Article: 16353
Subject: Re: 4062XL problems and solutions
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 18 May 1999 09:19:57 -0400
Links: << >>  << T >>  << A >>
Bill Kury wrote:
> 
> Hi!  I just finished a project using a 4062XL from Xilinx and I would
> like to get some feedback on some of the problems that I ran into.  A
> little info, this device was running on a 80 Mhz clock with most of the
> internals stepped down to 40 Mhz.  Utilization was about 25% of the
> device.  Yes, I agree that the part should be smaller but, there will be
> more added in the future.  Everything was coded in Vhdl using Aldec
> tools and Fpga express.
> 
> Problem #1 - Clock enable
>   The biggest problem I ran into was routing getting the clock enable to
> the logic to slow it down to 40 Mhz.  In order for the clock enable to
> work properly, it has to be there in 1 80Mhz cycle = 12.5 ns. I found
> that using a bufg or bufgls did not work for especially for the iobs.
> The solution for me was to route the problem locally through another
> flop by reclocking the clock enable.

I think you have found the optimal method here. It is just a limitation
of multirate processing (my term for this) in an FPGA that you have to
work very hard still to get the enable signal routed in one clock
period. When it has to run over a large part of the chip, it works well
to reclock it at some intermediate points. In your case it sounds like
this did not cause any issues with design, but if the clock enable is
itself a logic generated signal, you can have problems calculating it
one clock early. So there is no magic bullet for all cases. 

 
> Problem #2 - Vhdl and Clock enable
>   Has anyone run into the problem where they want to slow the logic in
> their design down using a clock enable but have been unable to get the
> tools to do what you want?  I had alot of trouble especially with state
> machines to get the clock enable routed to the ce pin on the clb.  My
> solution was to write my vhdl like palasm (Gack! I know this shows my
> age but go easy on me :)) in order to get it to do what I wanted.

Yes. This is a basic weakness of VHDL. The nature of the problem also
varies considerably with compiler vendor. I found that with one vendor
it was very difficult to get the compiler to even use the CE on the FF.
With another vendor, the CE was used in nearly every clocked process
whether it was warranted or not. Often using the CE to perform part of
the logic would greatly increase the amount of logic produced. Your
Palasm approach solves this problem, but greatly reduces the advantages
of using VHDL. So again, there is no magic bullet to solving this
problem. 


> Problem #3 - High speed visibility
>   This isn't so much a problem but a question to ask how you do it.
> When running at high speed internal to your fpga, how do you get
> visibility into the device without changing the routing?  I know you can
> check the static timing and this will resolve 99.99% of your problems.
> What I did was allowed some extra pins on the design to route signals
> out to so that I could take a look.  This worked well but, at the high
> speeds, routing to pins will change your internal routing delays and
> possibly mask the problem.  Are there any other solutions out there?

I have not seen this to be a problem in the way you are seeing it. My
designs are 100% synchronous with the only exception being the global
reset (and even that is duplicated in the synchronous logic to bring the
machine out of reset cleanly). So the only timing issues I have are
logic running too slow. Adding a stub to a net for observation may make
a delay longer and therefor fail, but it should never make it faster. I
am assuming here that you are adding the observation tap in the hand
editor. But even if you put the tap signals into your design, the timing
constraints will take that into account. If the design then works, you
either have not specified your constraints well enough or you have a
tool limitation which can't route the signals to your constraints.

The only observation related problem I have is the fact that the
observation tap is delayed by an unknown amount from the internal
signal, so it is not very useful for checking timing. 

This was an issue once when my timing constraints had an error in them.
I didn't notice the problem for quite a while since the chip was working
at room temp and the observation taps I had didn't do a good job of
showing timing. 

I would say that you have a pretty good understanding of the limitations
of the tools. With that knowledge, and the willingness to live with the
limitations, you should be able to do any design you wish. 



-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.
Article: 16354
Subject: Re: Fancy Dram problem
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 18 May 1999 09:28:22 -0400
Links: << >>  << T >>  << A >>
Steve Rencontre wrote:
> 
> In article <373CBABF.768BD300@nospam.ix.netcom.com>,
> pjs3@nospam.ix.netcom.com says...
> 
> [snip]
> > But in any case, I strongly suggest the use of an oscilloscope to
> > actually observe the circuit in action.
> 
> But make sure the probe capacitance doesn't swallow the spikes you're
> looking for!
> 
> I'm sure we've all had problems where the act of measurement makes the
> effect go away :-)

Or make it appear. With the speed of digital circuits these days, it is
very hard to observe noise and glitches accurately with a scope. I have
found that the only time I can trust as noise measurement with a scope
is when I have a ground probe of less than one inch. This is a paper
clip or similar wire wrapped around the ground band at the tip of the
probe. Any longer ground lead picks up enough noise to make my signal
look like it is not meeting spec. 

With today's high density packaging and my eyes of aging technology, I
also find it very hard to place such probes. So I try very hard to make
sure I don't need them. The board I am currently designing is using a
lot of BGA packages. So I am trying very hard not to need probes.
Perfect design the first time? We'll see...


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.
Article: 16355
Subject: Re: Post route simulation: EDIF or VHDL?
From: William White <will@edasource.com>
Date: Tue, 18 May 1999 15:37:22 +0100
Links: << >>  << T >>  << A >>
Both Speedwave and Viewsim are capable of reporting violation of
constraints such as setup/hold/pulse width etc. There are two reasons
why ViewSim might not be reporting such violations. They are not enables
in the simulator settings ( Simulate -> Simulator Settings, ViewSim tab
) or more likely, the simulation model does account for this using the
special ViewSim builtin primitives SHFE SHRE.

In the case of VHDL back-annotation an IEEE standard (VITAL - VHDL
Initiate Towards ASIC Libraries ) is used to define the timing
characteristics of the device. Since this is an IEEE standard, provided
the vendor, in this case Altera, adheres to it, it is likely that the
timing model will be more detailed and accurate. However the accuracy is
not dependent on the simulator but more on the accuracy of the timing
model.

If you have the choice VHDL is probably the better option especially if
you are using a VHDL testbench to stimulate the design. ( If you are not
you may wish to consider this ). The only slight disadvantage is that
the exported VHDL will require the extra compilation step.

William White


In article <7hpitl$nn3$1@nnrp1.deja.com>, micheal_thompson@my-
dejanews.com writes
>I'm doing a timing simulation on a design fitted to an Altera Max7000
>device. I've used Altera's Maxplus2 for routing and have Viewlogic's
>tools for simulation.
>MaxPlus2 has given me a choice of output files: EDIF or VHDL. And this
>therefore gives me a choice of Viewlogic simulation tools: Viewsim
>(EDIF) or Speedwaves (VHDL).
>So, is there an obvious better choice or should I expect to get
>identical results from both simulations?
>Right now I am not getting identical or even functionally similar
>results so I suspect I have screwed up a bit on my part. What I have
>noticed in favour of the VHDL simulation though is that I am getting
>run-time messages about set up and hold violations etc whereas the EDIF
>runs don't ever specify errors as explicitly. Is this true in general?
>Thanks in advance
>Mike
>
>
>--== Sent via Deja.com http://www.deja.com/ ==--
>---Share what you know. Learn what you don't.---

-- 
William White                    <
 ---------------------------  <  <  <  --- mailto:will@edasource.com
| Direct Insight Ltd       <  <  <  <  >   Tel: +44 1280 700262     |
| http://www.edasource.com    <  <  <      Fax: +44 1280 700577     |
 ------------------------------  <  --------------------------------
Article: 16356
Subject: Case study: Viewlogic's IntelliFlow
From: Jim Kipps <jkipps@viewlogic.com>
Date: Tue, 18 May 1999 11:26:23 -0400
Links: << >>  << T >>  << A >>

IntelliFlow Users,

If you would like to contribute to a case study of Viewlogic's
IntelliFlow, please respond to this email.  I'd like to know about
your experiences, good and bad, with this tool and what impact
it has had with your design methodology.  I'll post a summary
of the results to comp.arch.fpga at the conclusion of the study.

Thanks,
-Jim

--
--------------------------------------------------------
James R. Kipps                  FPGA Marketing Manager
jkipps@viewlogic.com            Phone: (508) 303-5246
--------------------------------------------------------


Article: 16357
Subject: Onboard JTAG-programming Xilinx CPLD with Found.Series?
From: "Alain Cloet" <alain.cloet@planetinternet.be>
Date: Tue, 18 May 1999 17:41:57 +0200
Links: << >>  << T >>  << A >>
(Previously posted in comp.arch.embedded, I just subscribed to this
fpga-newsgroup after a reply where I was said someone around here might be
able to help me, so no, I haven't read the FAQ or other articles yet)
With the Foundation Series of XIlinx, it should be possible to program a
CPLD onboard with their parallel cable (JTAG programming).
We succeeded already in that way that we can program a single chip if we are
able to use the chip TDI and TDO.
If we want to simulate a real case, with a JTAG chain with more than 1 chip,
than it doesn't work.  We always get an "basut"-error, so we don't succeed.
We tried to add elements of which we have the bsdl-file, and we don't get
errors during configuration, but the programming doesn't work.
Has anyone experience with this, and is able to guess what we're forgetting.
Thanks,
Alain






Article: 16358
Subject: Re: Glue logic
From: Elder V Costa <elder@dixtal.com.br>
Date: Tue, 18 May 1999 13:45:29 -0300
Links: << >>  << T >>  << A >>
wannarat wrote:
> 
> -  Glue Logic mean ?
> Regard
> wannarat  (ksuwanna@kmitl.ac.th)
> 
> 
> 
It means the extra logic elements you need to add to have a piece of
functionality working. For instance, to access a RAM, in addition to the
RAM chip itself you will need some AND/OR gates and/or selectors
(74LS138 or so) or a PAL/PLD to decode addresses and access signals
(MEMWR\ MEMRD\ etc.) Some processors or microcontrollers (e.g.
80C186/188 and derivatives) dismiss the glue logic by offering
configurable chip select lines, making your circuitry "cleaner" and
smaller.
Article: 16359
Subject: Re: 4062XL problems and solutions
From: Brian Philofsky <brianp@xilinx.com>
Date: Tue, 18 May 1999 10:28:53 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------2AB9A7323033DA9E1B8837BB
Content-Type: multipart/alternative;
 boundary="------------510FCE6102B25FD7F1952D3D"


--------------510FCE6102B25FD7F1952D3D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill Kury wrote:

> Hi!  I just finished a project using a 4062XL from Xilinx and I would
> like to get some feedback on some of the problems that I ran into.  A
> little info, this device was running on a 80 Mhz clock with most of the
> internals stepped down to 40 Mhz.  Utilization was about 25% of the
> device.  Yes, I agree that the part should be smaller but, there will be
> more added in the future.  Everything was coded in Vhdl using Aldec
> tools and Fpga express.
>
> Problem #1 - Clock enable
>   The biggest problem I ran into was routing getting the clock enable to
> the logic to slow it down to 40 Mhz.  In order for the clock enable to
> work properly, it has to be there in 1 80Mhz cycle = 12.5 ns. I found
> that using a bufg or bufgls did not work for especially for the iobs.
> The solution for me was to route the problem locally through another
> flop by reclocking the clock enable.

Can't comment too much about this without knowing a little more about the
CE path but can make some general comments.  If there are a few levels of
logic on that path though, sometimes a pipeline register would be required
to meet speed.

The global buffers are not definitly not the fastest routes on the device
(especially to certain non-clock pins) but are generally the most skew
intollerant.  For the clock enable path, skew is not as much of an issue as
long as the signal reaches every register before the setup time before the
clock.  So in some cases it is better to use local routing for these
signals because it can be fatser especially when techinques like
register/logic replication can be used.

The 4062XL is a fairly large device and generally the larger the device the
longer the routing delays.  This can be especially true for a design that
is not very dense in the device as you mentioned your is.  By default, the
mapping and placement algorithms try to spread out the design a bit to ease
routing however the end effect can be to lengthen the routes.  To prevent
this from hurting you, be sure you specified raelisitic timespecs on all
paths that need to be constrained in the design.  Unconstrained portions of
the design will tend to spread out on the device.

Above I mentioned to use realistic timespeces.  This does not only mean
specifying your tightest timespecs in your design but also relaxing the
ones that don't have to be too tight.  This will give the software some
more flexibility to place and route the most difficult paths in the design
rather than wasting time on paths that do not necessarily need to be
clocked so fast.

> Problem #2 - Vhdl and Clock enable
>   Has anyone run into the problem where they want to slow the logic in
> their design down using a clock enable but have been unable to get the
> tools to do what you want?  I had alot of trouble especially with state
> machines to get the clock enable routed to the ce pin on the clb.  My
> solution was to write my vhdl like palasm (Gack! I know this shows my
> age but go easy on me :)) in order to get it to do what I wanted.

Not sure how you wrote your state machine because there is more than one
way but generally, I have seen most state machines written in two seperate
processes, one for the synchronous portion and one for the combinatorial.
I tried a simple test case with FPGA Express 3.1 where I just described a
standard Clock Enable into the synchronous process and it implemented the
clock enable without a problem.  I will attach some code to show you how I
did it:

architecture BEHV of enum is

type STATE_TYPE is (S1, S2, S3, S4, S5, S6, S7);

signal CS, NS: STATE_TYPE;

begin

    SYNC_PROC: process (CLOCK, RESET)
    begin
        if (RESET='1') then
            CS <= S1;
        elsif (CLOCK'event and CLOCK = '1') then
            if (CE='1') then
                CS <= NS;
            end if;
        end if;
    end process; --End REG_PROC

    COMB_PROC: process (CS, A, B, C, D, E)
    begin
        case CS is
            when S1 =>
                MULTI  <= '0';
                CONTIG <= '0';
                SINGLE <= '0';
                if (A and not B and C) then
                    NS <= S2;
                elsif (A and B and not C) then
                    NS <= S4;
                else
                    NS <= S1;
                end if;
            when S2 =>
                MULTI  <= '1';
                CONTIG <= '0';
                SINGLE <= '0';
                if (not D) then
                    NS <= S3;
                else
                    NS <= S4;
                end if;
            when S3 =>

            ..... etc ......


> Problem #3 - High speed visibility
>   This isn't so much a problem but a question to ask how you do it.
> When running at high speed internal to your fpga, how do you get
> visibility into the device without changing the routing?  I know you can
> check the static timing and this will resolve 99.99% of your problems.
> What I did was allowed some extra pins on the design to route signals
> out to so that I could take a look.  This worked well but, at the high
> speeds, routing to pins will change your internal routing delays and
> possibly mask the problem.  Are there any other solutions out there?

Generally extensive static timing analysis and post-route functional
simulation should identify most problems however some problems slip through
especially for asynchronous portions of a design.

The one suggestion that comes to mind is since you mentioned you have extra
pins, you can use epic to route internal nodes out to these extra pins (not
sure if this is what you were doinf).  That should preserve the routing for
the most part.  It will place an extra load on that node but you could
minimize that by routing to a nearby CLB and using the lookup table as a
buffer.  Since you mention the desice is not too full, I assume there are
empty CLBs nearby.  Maybe not the easiest method to debug but an option.

There is readback circuitry builtin to the FPGA that allows you to readout
the status of any node in the device however our current cable, the
xchecker cable does not support devices larger than a 4013 due to a
hardware limitation.  We are working on releaseing an updated cable that
will address this and other limitations of the current cable.  Not sure
about dates for this but keep your eye out because this could be of use to
you in the future but just an FYI for now.

A few other obvious/not-so-obvious things you could try are, slow down the
clock (if possible) and see what happens.  Try to re-place and route the
design with a different cost table and/or effort level.  This will change
routing delays and may change the behavior.  Cold spray?  Make sure power
supply is clean and device is decoupled.  Make sure clock/input signal are
clean.  These things may not necessarily fix the problem but may help
identify the problem so I thought I would suggest them.  I am sure there
are several other tricks of the trade.


A few ideas.  Hope some of them may help you out.


--  Brian




>
>
> Bill
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---

--
-------------------------------------------------------------------
 / 7\'7 Brian Philofsky   (brian.philofsky@xilinx.com)
 \ \ `  Xilinx Applications Engineer             hotline@xilinx.com
 / /    2100 Logic Drive                         1-800-255-7778
 \_\/.\ San Jose, California 95124-3450          1-408-879-5199
-------------------------------------------------------------------



--------------510FCE6102B25FD7F1952D3D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Bill Kury wrote:
<blockquote TYPE=CITE>Hi!&nbsp; I just finished a project using a 4062XL
from Xilinx and I would
<br>like to get some feedback on some of the problems that I ran into.&nbsp;
A
<br>little info, this device was running on a 80 Mhz clock with most of
the
<br>internals stepped down to 40 Mhz.&nbsp; Utilization was about 25% of
the
<br>device.&nbsp; Yes, I agree that the part should be smaller but, there
will be
<br>more added in the future.&nbsp; Everything was coded in Vhdl using
Aldec
<br>tools and Fpga express.
<p>Problem #1 - Clock enable
<br>&nbsp; The biggest problem I ran into was routing getting the clock
enable to
<br>the logic to slow it down to 40 Mhz.&nbsp; In order for the clock enable
to
<br>work properly, it has to be there in 1 80Mhz cycle = 12.5 ns. I found
<br>that using a bufg or bufgls did not work for especially for the iobs.
<br>The solution for me was to route the problem locally through another
<br>flop by reclocking the clock enable.</blockquote>

<p><br>Can't comment too much about this without knowing a little more
about the CE path but can make some general comments.&nbsp; If there are
a few levels of logic on that path though, sometimes a pipeline register
would be required to meet speed.
<p>The global buffers are not definitly not the fastest routes on the device
(especially to certain non-clock pins) but are generally the most skew
intollerant.&nbsp; For the clock enable path, skew is not as much of an
issue as long as the signal reaches every register before the setup time
before the clock.&nbsp; So in some cases it is better to use local routing
for these signals because it can be fatser especially when techinques like
register/logic replication can be used.
<p>The 4062XL is a fairly large device and generally the larger the device
the longer the routing delays.&nbsp; This can be especially true for a
design that is not very dense in the device as you mentioned your is.&nbsp;
By default, the mapping and placement algorithms try to spread out the
design a bit to ease routing however the end effect can be to lengthen
the routes.&nbsp; To prevent this from hurting you, be sure you specified
raelisitic timespecs on all paths that need to be constrained in the design.&nbsp;
Unconstrained portions of the design will tend to spread out on the device.
<p>Above I mentioned to use realistic timespeces.&nbsp; This does not only
mean specifying your tightest timespecs in your design but also relaxing
the ones that don't have to be too tight.&nbsp; This will give the software
some more flexibility to place and route the most difficult paths in the
design rather than wasting time on paths that do not necessarily need to
be clocked so fast.
<blockquote TYPE=CITE>Problem #2 - Vhdl and Clock enable
<br>&nbsp; Has anyone run into the problem where they want to slow the
logic in
<br>their design down using a clock enable but have been unable to get
the
<br>tools to do what you want?&nbsp; I had alot of trouble especially with
state
<br>machines to get the clock enable routed to the ce pin on the clb.&nbsp;
My
<br>solution was to write my vhdl like palasm (Gack! I know this shows
my
<br>age but go easy on me :)) in order to get it to do what I wanted.</blockquote>

<p><br>Not sure how you wrote your state machine because there is more
than one way but generally, I have seen most state machines written in
two seperate processes, one for the synchronous portion and one for the
combinatorial.&nbsp; I tried a simple test case with FPGA Express 3.1 where
I just described a standard Clock Enable into the synchronous process and
it implemented the clock enable without a problem.&nbsp; I will attach
some code to show you how I did it:
<p><tt>architecture BEHV of enum is</tt><tt></tt>
<p><tt>type STATE_TYPE is (S1, S2, S3, S4, S5, S6, S7);</tt><tt></tt>
<p><tt>signal CS, NS: STATE_TYPE;</tt><tt></tt>
<p><tt>begin</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp; SYNC_PROC: process (CLOCK, RESET)</tt>
<br><tt>&nbsp;&nbsp;&nbsp; begin</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (RESET='1') then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CS &lt;= S1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elsif (CLOCK'event and
CLOCK = '1') then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if (CE='1') then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CS &lt;= NS;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end if;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end if;</tt>
<br><tt>&nbsp;&nbsp;&nbsp; end process; --End REG_PROC</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp; COMB_PROC: process (CS, A, B, C, D, E)</tt>
<br><tt>&nbsp;&nbsp;&nbsp; begin</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; case CS is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when S1 =></tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MULTI&nbsp; &lt;= '0';</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CONTIG &lt;= '0';</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SINGLE &lt;= '0';</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if (A and not B and C) then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NS &lt;= S2;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
elsif (A and B and not C) then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NS &lt;= S4;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
else</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NS &lt;= S1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end if;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when S2 =></tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MULTI&nbsp; &lt;= '1';</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CONTIG &lt;= '0';</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SINGLE &lt;= '0';</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if (not D) then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NS &lt;= S3;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
else</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NS &lt;= S4;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
end if;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when S3 =></tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..... etc ......</tt>
<br>&nbsp;
<blockquote TYPE=CITE>Problem #3 - High speed visibility
<br>&nbsp; This isn't so much a problem but a question to ask how you do
it.
<br>When running at high speed internal to your fpga, how do you get
<br>visibility into the device without changing the routing?&nbsp; I know
you can
<br>check the static timing and this will resolve 99.99% of your problems.
<br>What I did was allowed some extra pins on the design to route signals
<br>out to so that I could take a look.&nbsp; This worked well but, at
the high
<br>speeds, routing to pins will change your internal routing delays and
<br>possibly mask the problem.&nbsp; Are there any other solutions out
there?</blockquote>

<p><br>Generally extensive static timing analysis and post-route functional
simulation should identify most problems however some problems slip through
especially for asynchronous portions of a design.
<p>The one suggestion that comes to mind is since you mentioned you have
extra pins, you can use epic to route internal nodes out to these extra
pins (not sure if this is what you were doinf).&nbsp; That should preserve
the routing for the most part.&nbsp; It will place an extra load on that
node but you could minimize that by routing to a nearby CLB and using the
lookup table as a buffer.&nbsp; Since you mention the desice is not too
full, I assume there are empty CLBs nearby.&nbsp; Maybe not the easiest
method to debug but an option.
<p>There is readback circuitry builtin to the FPGA that allows you to readout
the status of any node in the device however our current cable, the xchecker
cable does not support devices larger than a 4013 due to a hardware limitation.&nbsp;
We are working on releaseing an updated cable that will address this and
other limitations of the current cable.&nbsp; Not sure about dates for
this but keep your eye out because this could be of use to you in the future
but just an FYI for now.
<p>A few other obvious/not-so-obvious things you could try are, slow down
the clock (if possible) and see what happens.&nbsp; Try to re-place and
route the design with a different cost table and/or effort level.&nbsp;
This will change routing delays and may change the behavior.&nbsp; Cold
spray?&nbsp; Make sure power supply is clean and device is decoupled.&nbsp;
Make sure clock/input signal are clean.&nbsp; These things may not necessarily
fix the problem but may help identify the problem so I thought I would
suggest them.&nbsp; I am sure there are several other tricks of the trade.
<br>&nbsp;
<p>A few ideas.&nbsp; Hope some of them may help you out.
<br>&nbsp;
<p>--&nbsp; Brian
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p>Bill
<p>--== Sent via Deja.com <a href="http://www.deja.com/">http://www.deja.com/</a>
==--
<br>---Share what you know. Learn what you don't.---</blockquote>

<pre>--&nbsp;
-------------------------------------------------------------------
&nbsp;/ 7\'7 Brian Philofsky&nbsp;&nbsp; (brian.philofsky@xilinx.com)
&nbsp;\ \ `&nbsp; Xilinx Applications Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hotline@xilinx.com
&nbsp;/ /&nbsp;&nbsp;&nbsp; 2100 Logic Drive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1-800-255-7778&nbsp;
&nbsp;\_\/.\ San Jose, California 95124-3450&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1-408-879-5199&nbsp;
-------------------------------------------------------------------</pre>
&nbsp;</html>

--------------510FCE6102B25FD7F1952D3D--

--------------2AB9A7323033DA9E1B8837BB
Content-Type: text/x-vcard; charset=us-ascii;
 name="brianp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brianp.vcf"

begin:vcard 
n:Philofsky;Brian
tel;fax:(408) 879-4442
tel;work:1-800-255-7778
x-mozilla-html:TRUE
org:<BR><H1 ALIGN="CENTER"><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx" ALIGN="CENTER">  Design Center
version:2.1
email;internet:brianp@xilinx.com
title:<H3 ALIGN="CENTER"><img src="http://bennyhills.fortunecity.com/deadparrot/108/homer.gif" alt="Homer" align="center"> Application Engineer 
adr;quoted-printable:;;2100 Logic Drive=0D=0ADept. 2510;San Jose;CA;95124-3450;USA
x-mozilla-cpt:;15200
fn:<H3 ALIGN="CENTER">Brian Philofsky
end:vcard

--------------2AB9A7323033DA9E1B8837BB--

Article: 16360
Subject: Re: Fancy Dram problem
From: woodyj@pptvision.com
Date: Tue, 18 May 1999 18:08:11 GMT
Links: << >>  << T >>  << A >>
In article <37394D92.7080B6C0@Sun.COM>,
  roman pollak <roman.pollak@Sun.COM> wrote:
> ...snip general description of dram design problem...snip

It would be helpful if you better described the problems you are seeing.  Do
you see "bad" writes to other locations in the same row?  different row but
same column?  Or are they random?

Try to fill the memory range with some value (say A55A55AA - if its 32-bits
wide).	Then starting at location zero, 1) verify location zero to pattern,
2) compliment pattern and write back to location zero, repeat steps 1 and 2
for rest of memory.  By looking at what locations fail, you can often get
some clue were the problem is.

Try to do the above memory test while probing first the control signals, then
the address, etc.  See if probing a pin effects the problem.  Again, this can
provide a clue were to search further for the problem.

You asked about resistors.  As others said, they are used to terminate the
signals.  When should you use them?  If the signal is "long" (say, more than
a couple two or three inches?) or if the signal is driving a lot of
capacitance (say, more than 50pf?).  If you use a resistor, try a value of
say 33 ohms and put it in series as near as possible to the source.

I would always recommend series termination on the RAS and CAS as they are
edge sensitive inputs (on asynchronous DRAM).  Put them on the address if you
have more than 8 dram loads (remember each chip on a simm is going to be an
address load).

Finally, if you really want some help, tell us what your general timing is
(Try drawing an ascii waveform with setup and hold timing) and memory
configuration (how many loads and in what arrangement).

- WJ


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Article: 16361
Subject: Yikes! Only 2 Days Left For The Boston SNUG Call-For-Papers !
From: jcooley@world.std.com (John Cooley)
Date: Tue, 18 May 1999 21:46:17 GMT
Links: << >>  << T >>  << A >>

  [ Editor's Note: I was just reminded that there's only 2 days left to
    submit abstracts for the upcoming Boston SNUG.  Here's the info if
    you're interested in doing one of the 25 minute presentations.  - John ]


  First Annual SNUG'99 Boston (Synopsys Users Group) Call For Papers
                     October 7 - October 8, 1999
                      The Westford Regency Hotel 
                       Westford, Massachusetts


Preliminary Schedule: SNUG'99 Boston 

  Thursday, October 7th	
  Morning       Tutorial Sessions
  Afternoon     Tutorial Sessions
  Evening       Cocktail Party

  Friday, October 8th
  Morning       Executive Status
  Mid-Morning   User Breakout Sessions
  Afternoon     User Breakout Sessions


Preliminary User Breakout Sessions

These sessions are always the hit of the conference. Hear Synopsys users'
experiences on specific topics. Each user breakout session will consist of
three presentations, twenty-five minutes each, with another five minutes
for questions and answers.
   
               
Preliminary topics include: 

Synthesis/Design Productivity:

Strategies, experiences, and best practices for design productivity with an
emphasis on synthesis. Users share experiences with automation techniques
for synthesis. 

Synthesis/Area and Design Compiler Runtime:

The goal of this session is to present Design Compiler methodologies to get
the best area, the best compile runtimes, or a combination of both. These
techniques will include compile options, DC variables, and HDL coding
styles for synthesis.

High-Level Verification/Simulation Techniques using Behavioral Coding:

The higher level a design is coded, the more complex the design becomes to
verify. This session calls for papers on behavioral system modeling
approaches when given design descriptions and performance goals. Further
discussion includes the verification/simulation strategies to ensure design
correctness.

FPGA & PLD Synthesis:

Having surveyed the User community, it was brought to our attention that
there is a desire to see more User papers on FPGA.  If you have any FPGA
stories to share with us, please come forward!  Concentrating on the unique
challenges of programmable logic, the tricks and techniques used for
designing and synthesizing FPGAs or PLDs will be presented. Incremental
synthesis, fanout control, and floorplanning issues relative to FPGAs will
also be part of this section.  

High-Level Verification/Simulation Techniques - (VCS):

System-level strategies covering design functional verification using
Verilog and VCS. Users share experiences in developing a test bed to verify
combined hardware and software systems for large complex designs. 

High-Level Verification/Simulation Techniques - (VSS):

System-level strategies covering design functional verification using VHDL
and VSS.  Users share experiences in developing a test bed to verify
combined hardware and software systems for large complex designs. 

Higher Levels of Abstraction/Behavioral Synthesis:

User experiences with using behavioral synthesis are explored in this
session. Topics include high-level design techniques, behavioral
scheduling, datapath synthesis, pipeline retiming, and integration with
other ASIC design and verification tools. Other topics include the
methodology for top-down design, and high-level techniques for DSP design. 

Hardware/Software Co-design:

Authors are invited to submit original papers describing recent experiences
in designing and verifying embedded processor-based ASIC/SOC systems. This
includes the methodologies used and tools required to handle tasks of
verifying both the hardware and software before physical prototypes are
available for these systems. Authors are encouraged to share their insights
on the use of the Eagle hardware/software tools, Cyclone, VSS, and VCS from
Synopsys and the overall impact on the project. Explore system design
objectives: Users experience with system development, verification and
integration. 

Deep Submicron/Large Designs/Power/Physical Design:

This session concentrates on the unique challenges of submicron and low
power design techniques that may involve large design, deep submicron and
physical aspects. Low power & physical design sessions provide experience
with automating scripts for submicron, special techniques for managing
wireloading, floorplanning, over consumption, and non-linear delay
modeling. 

Makefiles Methodology/Configuration Management:

This popular session addresses the increased effort to automate and extend
the synthesis process through scripting. The session includes case studies
by users who have taken advantage of the power of Make and Perl to drive
synthesis iterations, to extend DC Shell, and to manage complex designs. 

Design Reuse:

This session includes a practical methodology for design reuse based on
real-world experiences. Issues and guidelines are explored. Does anybody
really have a working Design Reuse methodology in place? Let us know about
it and how it works. 

Test - DFT:

This session focuses on strategies and real-world experiences implementing a
manufacturing test strategy (DFT) for large SOC-type designs. Various SCAN
and isolation techniques are explored in the context of core-based designs.
Techniques used to interface a DFT solution (Full or Partial) with
synthesis and power will be included. 

Protocol Compiler:

User experiences with Protocol Compiler in system or ASIC design,
explaining what the advantages and disadvantages are of using Protocol
Compiler over conventional HDL methodologies. Users will discuss how
Protocol Compiler's high abstraction level eases the designing of
structured data streams. 

Module Compiler:

This session explores the use of Module Compiler to achieve high
performance datapath designs, focusing on effective datapath synthesis
strategies, coding styles, and integration with other ASIC design tools.
User experiences with datapath synthesis are shared. 

PrimeTime Techniques/Formal Verification:

This session explores strategies and user experiences using a static
verification flow, concentrating on highlights and lowlights of static
timing analysis using Primetime and Formal Verification using Formality. 

High Speed/Mixed-Signal/Low Power/Nanometer/Physical Design:

This session concentrates on recent and emerging challenges related to
troublesome physical effects encountered while using process technologies
350nm and smaller during IC design. In the race towards high speed (GHz!)
and low power (sub-volt!) designs, designers must have solutions for
accurate characterization, modeling, and verification.  Structured-custom
IC and ASIC designers are invited to share how Synopsys/EPIC tools are
implemented in their flows. 


To present your experiences by a contribution in a user session:

  1. Please forward a brief summary description and an outline of your
     idea to the Boston Conference Technical Committee,
     (snug_boston@synopsys.com), by May 20th, 1999. 

  2. You will be notified of your acceptance by June 2nd, 1999.

  3. When an Author is selected, an assigned Technical Committee member
     will work with them to develop and review the paper and presentation. 

  4. Please review Author's Kit for details on paper format, deadlines,
     and structure.  http://www.snug-universal.org/Boston_akit.html

Important Dates

    Submit Abstracts from April 14th - May 20th.
    Notification of Abstract Acceptance will be June 2nd, 1999.
    In-depth Outline due by June 23, 1999.
    Papers for review are due by July 16, 1999.
    Final papers for print are to be completed by August 4, 1999.
    Slides for review due August 10, 1999.
    Final slides for print are due August 14, 1999. 

Who to Contact

Should you wish to discuss your potential contribution, please feel free to
contact your local Synopsys applications engineering manager or the SNUG'99
Boston Technical Committee via email at snug_boston@synopsys.com. 

===========================================================================
 Trying to figure out a Synopsys bug?  Want to hear how 6,000+ other users
   dealt with it?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."

Article: 16362
Subject: JTAG program Altera and Xilinx same chain?
From: Rich McNeil <rich.mcneil@gsc.gte.com>
Date: Tue, 18 May 1999 17:46:48 -0400
Links: << >>  << T >>  << A >>
Hi,
I would like to use the maxplus 2 software to program 3 Altera and 1
xlinx
virtex part in the same chain.  Has anyone played around with this?
I know that I can bypass each device and program the Alteras with
maxplus and the xlinx part with their software.
I would really like to make this happen with one piece of software.

Thanks,
Rich

Article: 16363
Subject: Need crack
From: "Tibor Szolnoki" <fpga@dartsgame.com>
Date: Wed, 19 May 1999 00:16:52 +0200
Links: << >>  << T >>  << A >>
Please help!!
I have need crack Synopsys FPGA Express 3.1!!!

Thank you



Article: 16364
Subject: Re: 4062XL problems and solutions
From: Cant Tell You <IamHereToHelpYou@notXilinx.com>
Date: Tue, 18 May 1999 16:52:06 -0700
Links: << >>  << T >>  << A >>

--------------94D0ED75DD12E7723383CB7D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Bill,


I believe the best thing you can do to your design without affercting
functionality is to replicate the logic that generates the clock enable.
By duplicating logic, you will be able to reduce the fanout of each clock
enable effectively by half.  If replicating it once still doesnt get you
there,
then try replicating over and over again until space becomes an issue or
other timing problems start to occur as a consequence of your changes.

Replicating logic is my solution of choice when high fanout slows down my
design.






Bill Kury wrote:

> Hi!  I just finished a project using a 4062XL from Xilinx and I would
> like to get some feedback on some of the problems that I ran into.  A
> little info, this device was running on a 80 Mhz clock with most of the
> internals stepped down to 40 Mhz.  Utilization was about 25% of the
> device.  Yes, I agree that the part should be smaller but, there will be
> more added in the future.  Everything was coded in Vhdl using Aldec
> tools and Fpga express.
>
> Problem #1 - Clock enable
>   The biggest problem I ran into was routing getting the clock enable to
> the logic to slow it down to 40 Mhz.  In order for the clock enable to
> work properly, it has to be there in 1 80Mhz cycle = 12.5 ns. I found
> that using a bufg or bufgls did not work for especially for the iobs.
> The solution for me was to route the problem locally through another
> flop by reclocking the clock enable.
>
> Problem #2 - Vhdl and Clock enable
>   Has anyone run into the problem where they want to slow the logic in
> their design down using a clock enable but have been unable to get the
> tools to do what you want?  I had alot of trouble especially with state
> machines to get the clock enable routed to the ce pin on the clb.  My
> solution was to write my vhdl like palasm (Gack! I know this shows my
> age but go easy on me :)) in order to get it to do what I wanted.
>
> Problem #3 - High speed visibility
>   This isn't so much a problem but a question to ask how you do it.
> When running at high speed internal to your fpga, how do you get
> visibility into the device without changing the routing?  I know you can
> check the static timing and this will resolve 99.99% of your problems.
> What I did was allowed some extra pins on the design to route signals
> out to so that I could take a look.  This worked well but, at the high
> speeds, routing to pins will change your internal routing delays and
> possibly mask the problem.  Are there any other solutions out there?
>
> Bill
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---

--------------94D0ED75DD12E7723383CB7D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Hello Bill,
<BR>&nbsp;
<P>I believe the best thing you can do to your design<B> without affercting</B>
<BR><B>functionality</B> is to replicate the logic that generates the clock
enable.
<BR>By duplicating logic, you will be able to reduce the fanout of each
clock
<BR>enable effectively by half.&nbsp; If replicating it once still doesnt
get you there,
<BR>then try replicating over and over again until space becomes an issue
or
<BR>other timing problems start to occur as a consequence of your changes.
<P>Replicating logic is my solution of choice when high fanout slows down
my design.
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;
<P>Bill Kury wrote:
<BLOCKQUOTE TYPE=CITE>Hi!&nbsp; I just finished a project using a 4062XL
from Xilinx and I would
<BR>like to get some feedback on some of the problems that I ran into.&nbsp;
A
<BR>little info, this device was running on a 80 Mhz clock with most of
the
<BR>internals stepped down to 40 Mhz.&nbsp; Utilization was about 25% of
the
<BR>device.&nbsp; Yes, I agree that the part should be smaller but, there
will be
<BR>more added in the future.&nbsp; Everything was coded in Vhdl using
Aldec
<BR>tools and Fpga express.
<P>Problem #1 - Clock enable
<BR>&nbsp; The biggest problem I ran into was routing getting the clock
enable to
<BR>the logic to slow it down to 40 Mhz.&nbsp; In order for the clock enable
to
<BR>work properly, it has to be there in 1 80Mhz cycle = 12.5 ns. I found
<BR>that using a bufg or bufgls did not work for especially for the iobs.
<BR>The solution for me was to route the problem locally through another
<BR>flop by reclocking the clock enable.
<P>Problem #2 - Vhdl and Clock enable
<BR>&nbsp; Has anyone run into the problem where they want to slow the
logic in
<BR>their design down using a clock enable but have been unable to get
the
<BR>tools to do what you want?&nbsp; I had alot of trouble especially with
state
<BR>machines to get the clock enable routed to the ce pin on the clb.&nbsp;
My
<BR>solution was to write my vhdl like palasm (Gack! I know this shows
my
<BR>age but go easy on me :)) in order to get it to do what I wanted.
<P>Problem #3 - High speed visibility
<BR>&nbsp; This isn't so much a problem but a question to ask how you do
it.
<BR>When running at high speed internal to your fpga, how do you get
<BR>visibility into the device without changing the routing?&nbsp; I know
you can
<BR>check the static timing and this will resolve 99.99% of your problems.
<BR>What I did was allowed some extra pins on the design to route signals
<BR>out to so that I could take a look.&nbsp; This worked well but, at
the high
<BR>speeds, routing to pins will change your internal routing delays and
<BR>possibly mask the problem.&nbsp; Are there any other solutions out
there?
<P>Bill
<P>--== Sent via Deja.com <A HREF="http://www.deja.com/">http://www.deja.com/</A>
==--
<BR>---Share what you know. Learn what you don't.---</BLOCKQUOTE>
</HTML>

--------------94D0ED75DD12E7723383CB7D--

Article: 16365
Subject: Re: Need crack
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Tue, 18 May 1999 18:26:15 -0700
Links: << >>  << T >>  << A >>
Tibor Szolnoki wrote in message <7hskld$srk$1@newsgate.elender.hu>...
>Please help!!
>I have need crack Synopsys FPGA Express 3.1!!!

You can easily get crack cocaine on Ave D in NYC, although the kids are down
with smack these days.

Crack kills.


-- a
------------------------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters@noao.edu

"Space, reconnaissance, weather, communications - you name it. We use space
a lot today."
-- Vice President Dan Quayle



Article: 16366
Subject: Re: Need crack
From: rk <stellare@erols.com.NOSPAM>
Date: Tue, 18 May 1999 22:49:20 -0400
Links: << >>  << T >>  << A >>
hi,

ah, this one is trivial.

send the vendor money, they will send you the codes to crack it.

piece of cake,

rk

p.s. i assume the people who wrote this stuff want to get paid for
working.  i assume you want to get paid for what you do.  and a hint:
please don't post in a public place an intent to steal.
_____________________________________________________

Tibor Szolnoki wrote:

> Please help!!
> I have need crack Synopsys FPGA Express 3.1!!!
>
> Thank you



Article: 16367
Subject: Is schmitt trigger possible with Xilinx 9536?
From: "Uday Godbole" <udayg@technofour.com>
Date: Wed, 19 May 1999 13:28:48 +0530
Links: << >>  << T >>  << A >>
Hi,

I need to use a schmitt trigger gate.  Can it be made on a Xilinx 9536 cpld?
I have their starter kit, but the schematic capture software does not seem
to have one in the library.. Also, can an open collector output be simulated
on this device?

TIA

Uday



Article: 16368
Subject: Aries Ballnet sockets?
From: Peter Sels <peter@easics.be>
Date: Wed, 19 May 1999 10:43:30 +0200
Links: << >>  << T >>  << A >>
Hello,

Does anybody have experience with Aries BallNest sockets for BGAs? 

We are using the Virtex BGA560 devices and
all sockets were about 1000USD. ZIF, Clamp, Pop-top, True BGA, etc...
Compared to all others, the Aries ones are quite cheap: 100 USD set up
fee, and then 156.80 USD per piece. 134 USD per piece when 25 pieces or
more.

It works with a BGA base, a center locator piece and the lid which
screws on
top of the rest. I just wonder how hard one can screw before screwing up
the reletively soft balls. Durability is 100 cycles according to data
sheet.
They seem to be custom made for the BGA560.

Please CC to peter@easics.be

thanks & best regards,

Peter
-- 
======================================================================
Peter Sels                   ===              Easics               ===
ASIC Design Engineer         ===  VHDL-based ASIC design services  ===
mailto:peter@easics.be          ===================================
Tel: +32-16-395 605          Interleuvenlaan 86, B-3001 Leuven, BELGIUM
Fax: +32-16-395 619                 http://www.easics.com/peter/
Article: 16369
Subject: Re: Dual Port mem
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Wed, 19 May 1999 10:49:24 +0100
Links: << >>  << T >>  << A >>

"J. Khatib" wrote:
> 
> Hi
> Please is there any problem with this dual port memory VHDL code?
> 
>   ------------------------------------------------------------------------
>               Name: mem.vhd
>    mem.vhd    Type: Active VHDL Source (application/x-unknown-content-type-VHDLSource)
>           Encoding: base64

If I were you, I would avoid using variables (if you want to
synthesize your VHDL code).

From the code below Synplify can instantiate a 1K x 8 d-port RAM for
XC4000 Xilinx FPGAs. Small changes in this code may be a problem
for the synthesis tool. 

Eduardo.


library IEEE;
   use IEEE.std_logic_1164.all;
   use IEEE.std_logic_unsigned.all;

entity RAM1K_MEM is
  port ( CLK_IN       : in  std_logic;
         RADDR_IN     : in  std_logic_vector(9 downto 0);
         WADDR_IN     : in  std_logic_vector(9 downto 0);
         WR_IN        : in  std_logic;
         DATA_IN      : in  std_logic_vector(7 downto 0);
         DATA_OUT     : out std_logic_vector(7 downto 0)
        );
end RAM1K_MEM;

architecture RAM1K_MEM_BEH of RAM1K_MEM is
   type RAM_TYP is array(1023 downto 0) of std_logic_vector(7 downto 0);
   signal MEM         : RAM_TYP;
   signal RADDR_IDX   : std_logic_vector(9 downto 0);

begin
   DATA_OUT <= MEM(conv_integer(RADDR_IDX));
   MEMORY_PRO: process (CLK_IN)
   begin
      if CLK_IN'event and CLK_IN = '1' then
         if (WR_IN = '1') then
            MEM(conv_integer(WADDR_IN)) <= DATA_IN;
         end if;
         RADDR_IDX <= RADDR_IN;
      end if;
   end process MEMORY_PRO;
end RAM1K_MEM_BEH;
Article: 16370
Subject: Re: JTAG program Altera and Xilinx same chain?
From: steve@rsn-tech.demon.co.REMOVEuk (Steve Rencontre)
Date: Wed, 19 May 1999 12:08:36 +0100
Links: << >>  << T >>  << A >>
In article <3741DFC8.DB2D12A8@gsc.gte.com>, rich.mcneil@gsc.gte.com 
says...
> Hi,
> I would like to use the maxplus 2 software to program 3 Altera and 1
> xlinx
> virtex part in the same chain.  Has anyone played around with this?
> I know that I can bypass each device and program the Alteras with
> maxplus and the xlinx part with their software.
> I would really like to make this happen with one piece of software.
> 
> Thanks,
> Rich

Do Xilinx support JAM? If so, the JAM player is supposed to be device-
independent. 

-- 
Steve Rencontre - Design Consultant
http://www.rsn-tech.demon.co.uk/
Article: 16371
Subject: Re: Dual Port mem
From: Peter =?iso-8859-1?Q?S=F8rensen?= <ps@emi.dtu.dk>
Date: Wed, 19 May 1999 13:08:50 +0200
Links: << >>  << T >>  << A >>
In general the todays synthesis tools are very limited in synthesizing RAM blocks. See the synthesis
tool for what is supported and examples. See also the place&route tool for supported black box code. (A
black box is synthesized by the place&route tool and not by the synthesis tool.

Hi Peter

"J. Khatib" wrote:

> Hi
> Please is there any problem with this dual port memory VHDL code?
>
>   --------------------------------------------------------------------------------
> -------------------------------------------------------------------------------
> -- Dual port Memory core
> -- 8 bit word size
> -- 256 byte width
> --
> -- This VHDL design file is an open design; you can redistribute it and/or
> -- modify it and/or implement it under the terms of the Openip General Public
> -- License as it is going to be published by the OpenIP Organization and any
> -- coming versions of this license.
> -- You can check the draft license at
> -- http://www.geocities.com/SiliconValley/Pines/6639/openip/license.html
> --
> --
> -- Creator : Jamil Khatib
> -- Date 14/5/99
> --
> -- version 0.1
> -- Untested version
> --
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
>
> ENTITY dpmem IS
>
>   PORT (
>     clk      : IN  std_logic;                     -- write clock
>     reset    : IN  std_logic;                     -- System Reset
>     W_add    : IN  integer RANGE 0 TO 255;  -- Write Address
>     R_add    : IN  integer RANGE 0 TO 255;  -- Read Address
>     Data_In  : IN  std_logic_vector(7 DOWNTO 0);  -- input data
>     Data_Out : OUT std_logic_vector(7 DOWNTO 0);  -- Output Data
>     WR       : IN  std_logic;                     -- Write Enable
>     RE       : IN  std_logic);                    -- Read Enable
> END dpmem;
>
> ARCHITECTURE dpmem_v1 OF dpmem IS
>
> BEGIN  -- dpmem_v1
>
> TYPE data_array IS ARRAY (integer range <>) OF std_logic_vector(7 DOWNTO 0);
>                                         -- Memory Type
> SIGNAL data : data_array(0 TO 7);       -- Local data
>
> PROCESS (clk, reset)
>     VARIABLE result_data : std_logic_vector(7 DOWNTO 0);  -- holds the internal data of output data
>
> BEGIN  -- PROCESS
>     result_data := (OTHERS Z);          -- Defualt value
>
>     -- activities triggered by asynchronous reset (active low)
>     IF reset = '0' THEN
>         result_data := (OTHERS Z);
>
>     -- activities triggered by rising edge of clock
>     ELSIF clk'event AND clk = '1' THEN
>         IF RE = '1' THEN
>             result_data := data(R_add);
>         END IF;
>
>         IF WR = '1' THEN
>             data(W_add) := Data_In;
>         END IF;
>     END IF;
>
>     Data_OUT <= result_data;
>
> END PROCESS;
>
> END dpmem_v1;

Article: 16372
Subject: Re: Virtex based PCI cards
From: Malachy Devlin <m.devlin@nallatech.com>
Date: Wed, 19 May 1999 12:54:30 +0100
Links: << >>  << T >>  << A >>
Nallatech has been supplying a Virtex development platform since
February. This is a 32bit 33Mhz PCI card with a 300K - 800K Virtex
device and 2 individual banks of 2MBytes 100Mhz ZBT SRAM.
The PCI card, called the Ballynuey, handles all the PCI issues and comes
with a pre-configured Spartan that handles the PCI interfacing and data
buffering between the Virtex and the PC application. PCI drivers, Virtex
debug tool, FPGA configuration and Application API are included with the
card.
Additionally the card includes 4 DIME modules for expansion and custom
I/O. Currently there are modules for Image Capture and Display, a Dual
XCV1000 module (yes over 2Million gates!) and various other I/O modules
(e.g. LVDS) with more in the pipeline. The modules can provide over
2Gbytes/sec bandwidth and has over 200 I/O connections.

Configuration of the on-board Virtex is configured dynamically over the
PCI using the tools provided with the card (and is much faster than
Xchecker!) If additional DIME modules are placed on the card their FPGAs
are also individually configurable via PCI.


Check out the web site for more details and new developments soon to be
announced at http://www.nallatech.com/ 


Malachy Devlin
Nallatech Ltd
m.devlin@nallatech.com


> -----Original Message-----
> From: alfred fuchs [mailto:alfred.fuchs@siemens.at]
> Posted At: 12 May 1999 19:09
> Posted To: fpga
> Conversation: Virtex based PCI cards
> Subject: Re: Virtex based PCI cards
> 
> 
> I've just finished the design of a CompactPCI board (6U) with 
> one Virtex1000
> and two synchronous SRAM-modules (2Mx72). It mainly uses 
> rear-panel-I/O
> (more than 100 signals) and is therefore open for various 
> applications. The
> PCI-IF is a PLX9054, the FPGA is configured by the PCI-master.
> Pricing is TBD, but we tend to be expensive.
> 
> Alfred Fuchs
> Siemens Austria
> PSE PRO LMS2
> +43/1/1707-34113
> 
> Atif Zafar schrieb:
> 
> > Hello:
> >
> >     Does anyone know of any development boards (PCI) that 
> use the Virtex
> > FPGA? I am interested in a board with preferably several 
> XV800 or XV1000
> > devices along with RAM for prototyping a custom graphics pipeline. I
> > have heard of the PCI Pamette board, but to my knowledge 
> this does not
> > have Virtex silicon. Thanks for any info.
> >
> > Atif Zafar
> > Regenstrief Institute
> > Zafar_A@regenstrief.iupui.edu
> 

Article: 16373
Subject: Re: flex10k 1 gate change
From: Peter =?iso-8859-1?Q?S=F8rensen?= <ps@emi.dtu.dk>
Date: Wed, 19 May 1999 14:19:53 +0200
Links: << >>  << T >>  << A >>
Altera Support seems to have overlooked something.
Try backannnotate the fit including Lcells, then recompile. Smart recompile
really doesn't matter it is only
a matter of building databases. The important thing for place and route is that
the old "name".fit file is there if you do not backannotate the design. The
problem is that the fitter might give up for changes when you backannotate all
locations, but the fit time is fast and then the smart option is relative more
important.

Nb PC'er are faster than most Unix machine;integer performence and amount of RAM
matters.

Hi Peter


Carlhermann Schlehaus wrote:

> Hi Jeff,
>
> Jeff Christenson <jchrist@airmail-not.net> schrieb in im Newsbeitrag:
> 2E51EB3934753BFD.9E29146E6E814155.D1B5C73BFEC426E4@library-proxy.airnews.net
> ...
> > >pasquale wrote in message <371A1D1F.2E618F3C@zoran.com>...
> > >>
> > >>My altera flex10k200e design takes about 8 hours to place and route.
> > >>I needed to change one gate in my design (and inverter to a buffer)
> > >>and Altera tech support told me I had to start the place and route
> > >>(i.e. "recompile") from scratch. They said that there was no way
> > >>to make a minor change like this and that there was no way
> > >>to directly edit the LUT equations by hand.
> > >>They say that this capbility may be available by year end.
> > >>
> > >>Is this true?
>
> Try the 'Smart recompile' option in the Processing menu when in compiler
> window. This should reduce the compilation time when making minor changes.
> Works with the 8K and 6K family (as I am working with).
> The other extreme setting would be 'Total recompile'. Compilation times
> increases to 3 times in my designes when using 'total' and not 'smart'
> recompile.
>
> Ciao, Carlhermann

Article: 16374
Subject: Re: Fpga gates, PLD gates ASIC gates: Help us please.
From: Peter =?iso-8859-1?Q?S=F8rensen?= <ps@emi.dtu.dk>
Date: Wed, 19 May 1999 14:31:05 +0200
Links: << >>  << T >>  << A >>
I used a lot of Altera PDL and FPGA devices. I say you can't make a simple
compare of ASIC/FPGA/PLD sturctures at all. The capacity vary with several
factors due to the actual design.

Hi Peter

hhk wrote:

> Hello,
>
> We are two gratuade students in Holland. Currently we are examining
> the possibillity's of the Actel 54SX 16 (Antifuse) FPGA.
> During this examination we compare this component with an Altera MAX
> 7000 CPLD (EEPROM).
>
> At this point we want to compare the capacity of both components....
> Evry one we talked to adviced us to compare the capacity by means of
> gates.
>
> But here is the problem. The Actel family's capacity is specified in
> (usable) PLD gates and the Altera probably specified in ASIC gates.
>
> The big problem is: What are PLD gates, ASIC gates an what are FPGA
> gates. And above all: What is the DIFFERENCE between these types of
> gates.
>
> Please help us, reply's can also be directed to dg351@signaal.nl.
>
> Yours cincerely,
>
> H.H. Kruizinga



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