Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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.htmArticle: 16351
> 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
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 romanArticle: 16353
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
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
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
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
(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, AlainArticle: 16358
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
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! 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.
A
<br>little info, this device was running on a 80 Mhz clock with most of
the
<br>internals stepped down to 40 Mhz. Utilization was about 25% of
the
<br>device. Yes, I agree that the part should be smaller but, there
will be
<br>more added in the future. Everything was coded in Vhdl using
Aldec
<br>tools and Fpga express.
<p>Problem #1 - Clock enable
<br> The biggest problem I ran into was routing getting the clock
enable to
<br>the logic to slow it down to 40 Mhz. 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. 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. 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.
<p>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.
<p>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.
<blockquote TYPE=CITE>Problem #2 - Vhdl and Clock enable
<br> 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? I had alot of trouble especially with
state
<br>machines to get the clock enable routed to the ce pin on the clb.
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. 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:
<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> SYNC_PROC: process (CLOCK, RESET)</tt>
<br><tt> begin</tt>
<br><tt> if (RESET='1') then</tt>
<br><tt>
CS <= S1;</tt>
<br><tt> elsif (CLOCK'event and
CLOCK = '1') then</tt>
<br><tt>
if (CE='1') then</tt>
<br><tt>
CS <= NS;</tt>
<br><tt>
end if;</tt>
<br><tt> end if;</tt>
<br><tt> end process; --End REG_PROC</tt><tt></tt>
<p><tt> COMB_PROC: process (CS, A, B, C, D, E)</tt>
<br><tt> begin</tt>
<br><tt> case CS is</tt>
<br><tt>
when S1 =></tt>
<br><tt>
MULTI <= '0';</tt>
<br><tt>
CONTIG <= '0';</tt>
<br><tt>
SINGLE <= '0';</tt>
<br><tt>
if (A and not B and C) then</tt>
<br><tt>
NS <= S2;</tt>
<br><tt>
elsif (A and B and not C) then</tt>
<br><tt>
NS <= S4;</tt>
<br><tt>
else</tt>
<br><tt>
NS <= S1;</tt>
<br><tt>
end if;</tt>
<br><tt>
when S2 =></tt>
<br><tt>
MULTI <= '1';</tt>
<br><tt>
CONTIG <= '0';</tt>
<br><tt>
SINGLE <= '0';</tt>
<br><tt>
if (not D) then</tt>
<br><tt>
NS <= S3;</tt>
<br><tt>
else</tt>
<br><tt>
NS <= S4;</tt>
<br><tt>
end if;</tt>
<br><tt>
when S3 =></tt>
<br><tt> </tt>
<br><tt>
..... etc ......</tt>
<br>
<blockquote TYPE=CITE>Problem #3 - High speed visibility
<br> 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? 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. This worked well but, at
the high
<br>speeds, routing to pins will change your internal routing delays and
<br>possibly mask the problem. 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). 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.
<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.
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.
<p>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.
<br>
<p>A few ideas. Hope some of them may help you out.
<br>
<p>-- Brian
<br>
<br>
<br>
<blockquote TYPE=CITE>
<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>--
-------------------------------------------------------------------
/ 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
-------------------------------------------------------------------</pre>
</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: 16360In 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
[ 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: 16362Hi, 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, RichArticle: 16363
Please help!! I have need crack Synopsys FPGA Express 3.1!!! Thank youArticle: 16364
--------------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> <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. 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> <BR> <BR> <BR> <BR> <P>Bill Kury wrote: <BLOCKQUOTE TYPE=CITE>Hi! 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. A <BR>little info, this device was running on a 80 Mhz clock with most of the <BR>internals stepped down to 40 Mhz. Utilization was about 25% of the <BR>device. Yes, I agree that the part should be smaller but, there will be <BR>more added in the future. Everything was coded in Vhdl using Aldec <BR>tools and Fpga express. <P>Problem #1 - Clock enable <BR> The biggest problem I ran into was routing getting the clock enable to <BR>the logic to slow it down to 40 Mhz. 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> 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? I had alot of trouble especially with state <BR>machines to get the clock enable routed to the ce pin on the clb. 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> 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? 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. This worked well but, at the high <BR>speeds, routing to pins will change your internal routing delays and <BR>possibly mask the problem. 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
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 QuayleArticle: 16366
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 youArticle: 16367
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 UdayArticle: 16368
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
"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: 16370In 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
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
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
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, CarlhermannArticle: 16374
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:
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