Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 103675

Article: 103675
Subject: Rumor Control:: Will Quartus phase out supporting AHDL?
From: "jjlindula@hotmail.com" <jjlindula@hotmail.com>
Date: 7 Jun 2006 16:00:03 -0700
Links: << >>  << T >>  << A >>
Hello, I posted this question a while back but I'm hearing the rumor
again from people attending Altera's Quartus workshops. The rumor is
that Altera may eventually phase out their support of AHDL in their
Quartus development software. Does anyone know what's in the future for
AHDL?

Thanks,
joe


Article: 103676
Subject: Re: Rumor Control:: Will Quartus phase out supporting AHDL?
From: "Subroto Datta" <sdatta@altera.com>
Date: 7 Jun 2006 16:38:30 -0700
Links: << >>  << T >>  << A >>

jjlindula@hotmail.com wrote:
> Hello, I posted this question a while back but I'm hearing the rumor
> again from people attending Altera's Quartus workshops. The rumor is
> that Altera may eventually phase out their support of AHDL in their
> Quartus development software. Does anyone know what's in the future for
> AHDL?
>
> Thanks,
> joe

Hi Joe,

  AHDL support will be there in Quartus for a long long time.The AHDL
language, is fully maintained and supported for reasons of backwards
compatibility. There are lots of legacy Max+Plus II designs which
customers are migrating to Quartus for use in both existing and new
projects. We are sensitive to our customers needs and will not do
anything to jeopardize their productivity.

Hope this helps,
Subroto Datta
Altera Corp.


Article: 103677
Subject: Re: Rumor Control:: Will Quartus phase out supporting AHDL?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 08 Jun 2006 12:12:36 +1200
Links: << >>  << T >>  << A >>
jjlindula@hotmail.com wrote:

> Hello, I posted this question a while back but I'm hearing the rumor
> again from people attending Altera's Quartus workshops. The rumor is
> that Altera may eventually phase out their support of AHDL in their
> Quartus development software. Does anyone know what's in the future for
> AHDL?

  I can see that they would move AHDL to "maintenance mode", but I doubt
they would kill it entirely.

  Altera took some trouble to keep the MAX +II interface option, and
CPLDs must still be a sizeable chunk of their business.

  I liked what Xilinx did with ABEL : that now generates VHDL output 
(IIRC), and so can hook into all the back end tools, whilst at the
same time, preserve customers code base.
  In this form, ABEL is a valid choice for new designs ( esp in the
CPLD arena ).

  Altera could do the same, with their AHDL (or may have already).

  Someone at Altera may clarify this ?

-jg


Article: 103678
Subject: Re: Incrmental Compilation in Quartus 5.1
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 08 Jun 2006 10:23:27 +1000
Links: << >>  << T >>  << A >>
jjlindula@hotmail.com wrote:

> He asked if you
> could do IC after the I/O pin symbols have been physically assigned
> to pins? I'm not an expert on IC so I hope someone can help.

Yes. Look at Design Partitioning...

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 103679
Subject: Re: Can ILMB and DLMB of Microblaze be 24kByte?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 08 Jun 2006 12:13:28 +1000
Links: << >>  << T >>  << A >>
Dale wrote:

> Hello,
> 
> I'm trying to get my ILMB and DLMB of my microblaze to be 24kBytes, but
> I am only given an option of powers of two.  Is there any way around
> this?
> 

You can instantiate 16K and 8K BRAM blocks on the LMB, at contiguous addresses.
 However, I think that the data2mem tool (which stuffs ELFs into BRAM) will not
recognise them as a contiguous memory space.  This might introduce some
complications for you, but shouldn't be a showstopper.

Regards,

John

Article: 103680
Subject: Re: Efficient implementation of Address Decoding logic
From: "Srikanth BJ" <bj.srikanth@gmail.com>
Date: 7 Jun 2006 21:18:14 -0700
Links: << >>  << T >>  << A >>
Andy wrote:
> If you use "falling_edge(awe)" then awe will get tied to the clock
> input on one or more registers that will hold the signal values that
> you assign within that if-then clause.
>
> Storing data on falling edges of strobes will work, but think about
> what you are going to do with that data in the latches. The timing can
> be very difficult to manage if you need to use that data elsewhere in a
> synchronous (clocked) system. Handling asynchronous buses in a
> synchronous system is beyond the scope of this conversation. Whole
> chapters/books have been written on it. Generally speaking, you usually
> end up syncrhonizing the control lines, and using those synchronized
> versions to control storage into synchronous registers (i.e. they form
> clock enables on registers that are clocked by your system clock). If
> your clock is not fast enough to handle the timing of the controls,
> then you may need to latch the data with the asynchronous strobe, then
> use a synchronized version of the strobe to enable transfer from the
> latch into a register on the system clock.
>
Andy., got to know many things from you. I havenot worked too much on
handling
asynchronous events., i think its probably very challenging and i guess
one should be fully equipped with the basics involved. If you could
suggest any book/links which might be very helpful to go further in to
the above discussed  topics, it  would be really appreciated.
Thanks in advance,
Srikanth


Article: 103681
Subject: Block Ram vs Distributed Ram
From: "Ashish" <ashish.shringarpure@gmail.com>
Date: 7 Jun 2006 21:41:19 -0700
Links: << >>  << T >>  << A >>
Hi,

I have a query regaring RAM usage in FPGA. Please help me in
understanding it.

Whats the thumb rule for choosing Block ram vs distributed Ram?

When, which should be preffered? Why?


Thanks


Ashish


Article: 103682
Subject: Re: Can ILMB and DLMB of Microblaze be 24kByte?
From: Zara <yozara@terra.es>
Date: Thu, 08 Jun 2006 06:57:34 +0200
Links: << >>  << T >>  << A >>
On Thu, 08 Jun 2006 12:13:28 +1000, John Williams
<jwilliams@itee.uq.edu.au> wrote:

>Dale wrote:
>
>> Hello,
>> 
>> I'm trying to get my ILMB and DLMB of my microblaze to be 24kBytes, but
>> I am only given an option of powers of two.  Is there any way around
>> this?
>> 
>
>You can instantiate 16K and 8K BRAM blocks on the LMB, at contiguous addresses.
> However, I think that the data2mem tool (which stuffs ELFs into BRAM) will not
>recognise them as a contiguous memory space.  This might introduce some
>complications for you, but shouldn't be a showstopper.
>

I did it on EDK 6.1 and 7.1, without problems. Don't know about EDK
8.1, but I have the feeling that it will work right away

Regards,

Zara

Article: 103683
Subject: Re: Block Ram vs Distributed Ram
From: Zara <yozara@terra.es>
Date: Thu, 08 Jun 2006 07:22:41 +0200
Links: << >>  << T >>  << A >>
On 7 Jun 2006 21:41:19 -0700, "Ashish" <ashish.shringarpure@gmail.com>
wrote:

>Hi,
>
>I have a query regaring RAM usage in FPGA. Please help me in
>understanding it.
>
>Whats the thumb rule for choosing Block ram vs distributed Ram?
>
>When, which should be preffered? Why?
>
>

- If it should be dual ported with different clocks per port, use
block ram
- If it is large (more then 1kbit, use block ram)
- If you are have unused block ram, use it
...

Use distributed ram only when you can't use block ram

Zara


BTW, these are guidelines. As every guide line, it may be followed. Or
not. It is your personal option, and you may behave differently if
such things as timing, clock distrbuiton... indicates you should.


Article: 103684
Subject: Re: Block Ram vs Distributed Ram
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 Jun 2006 22:38:31 -0700
Links: << >>  << T >>  << A >>
With each Virtex FPGA you get a certain number of BlockRAMs. Until you
have used all of them, they are incrementally free, so use them, even
if it may look wasteful (18 K or 36 K bit capacity).

Nice features like progrmmable width/depth ratio, dual-ported,
read-befor-write option, etc
You can even do one read-modify-write operation per clock cycle (using
both ports)

One caveat: Reading is a synchronous operation, it only occurs after a
clock edge.

Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and
is faster, but requires more design effort.

Peter Alfke, Xilinx Applications


Article: 103685
Subject: Re: Block Ram vs Distributed Ram
From: "Ashish" <ashish.shringarpure@gmail.com>
Date: 7 Jun 2006 23:51:14 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> With each Virtex FPGA you get a certain number of BlockRAMs. Until you
> have used all of them, they are incrementally free, so use them, even
> if it may look wasteful (18 K or 36 K bit capacity).
>
> Nice features like progrmmable width/depth ratio, dual-ported,
> read-befor-write option, etc
> You can even do one read-modify-write operation per clock cycle (using
> both ports)
>
> One caveat: Reading is a synchronous operation, it only occurs after a
> clock edge.
>
> Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and
> is faster, but requires more design effort.
>
This is my main query. How does speed matter here? What is thumb rule
from operation speed point of view?

I have some logic which uses counters, some configuration registers and
FIFO.
Fortunately same clock is used for all.

What will be best choice for implementing these? BRAM and distributed
RAM?
Pls. advice.

I am using Spartan2 device.

> Peter Alfke, Xilinx Applications



Thanks 


Ashish


Article: 103686
Subject: Re: IOBDELAY's delay value
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 08 Jun 2006 02:52:16 -0500
Links: << >>  << T >>  << A >>

>I am very suspicious of any claims of self-contained internal precision
>ocillators, although such claims have been made. (Precision defined as
>1 or 2%)

Microchip/PIC says they get 1% at typical conditions and 2%
over reasonable VCC and temp.  (5% for wider VCC/Temp.)

That needs a calibration step specific to each chip.  A magic
number is stored in flash.  You have to copy it over to a
speed-tweak register as part of initialization.  The factory
initializes the flash location and/or you can rederive it with
their tools.

That's from the data sheet for the PIC-12F675 which is several years
old.  I haven't checked their more recent chips.  (Or newer versions
of that data sheet.)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 103687
Subject: Re: IOBDELAY's delay value
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 08 Jun 2006 21:07:06 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Uwe, wishful thinking.
> The frequency must be brought in from the outside.
> I am very suspicious of any claims of self-contained internal precision
> ocillators, although such claims have been made. (Precision defined as
> 1 or 2%)

  These things do keep getting better and better, but they are not 
simple, or trivial blocks.

  Maxim and Linear tech have 'Silicon Oscillators', that claim these
precisions, but in these devices all they have to do is oscillate,
so they can target a process very specifically.

  A very recent, and perhaps better example, is the Freescale
MC9RS08KA2 tiny microcontroller. That is true mixed signal.

  That claims 2% MAX, over voltage and temperature,(which I think
means -40'C to 85'C and 1.8V-5.5V), and it has a 0.2% trim precision.

This costs ~140uA, for 32Khz, but they also have a 300nA/1KHz
oscillator, with reduced precision ~30%.

  They also have a 1% 1.2V bandgap reference in this device -
AND it all costs under 50c !!.

All of this will be something of a culture shock to FPGA vendors :)
[ uA ?! cough,  what's a nA ?  50 _cents_ ?! , choke... ]


-jg




Article: 103688
Subject: Re: Block Ram vs Distributed Ram
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 8 Jun 2006 02:18:25 -0700
Links: << >>  << T >>  << A >>
>From my experiance there will be large routing delay if you use block
RAMs and that will be very difficult to avoid if your block RAM usage
is in a scattered manner. I tried to implement a 16 port RAM design
suggested early in this group but with lot of effort could get only
10ns delay.
Sumesh V S


Article: 103689
Subject: Space invaders on Spartan3e starter board
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 08 Jun 2006 09:40:38 GMT
Links: << >>  << T >>  << A >>
www.fpgaarcade.com

With a bit of help from Paul Walsh, Invaders now has audio.
I have targeted it at the Spartan3E starter board from Xilinx and tarted it 
up a bit with a colour overlay emulator.

Enjoy,

Cheers,
MikeJ 



Article: 103690
Subject: Re: Space invaders on Spartan3e starter board
From: pbdelete@spamnuke.ludd.luthdelete.se.invalid
Date: 08 Jun 2006 09:58:25 GMT
Links: << >>  << T >>  << A >>
MikeJ <mikej@fpgaarcade.nospam.com> wrote:
>www.fpgaarcade.com

>With a bit of help from Paul Walsh, Invaders now has audio.
>I have targeted it at the Spartan3E starter board from Xilinx and tarted it 
>up a bit with a colour overlay emulator.

Now we are waiting for the fpga demoscene ;)


Article: 103691
Subject: Re: Block Ram vs Distributed Ram
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Thu, 08 Jun 2006 08:38:39 -0400
Links: << >>  << T >>  << A >>
On Wed, 07 Jun 2006 22:38:31 -0700, Peter Alfke wrote:

> With each Virtex FPGA you get a certain number of BlockRAMs. Until you
> have used all of them, they are incrementally free, so use them, even
> if it may look wasteful (18 K or 36 K bit capacity).
> 
> Nice features like progrmmable width/depth ratio, dual-ported,
> read-befor-write option, etc
> You can even do one read-modify-write operation per clock cycle (using
> both ports)
> 
> One caveat: Reading is a synchronous operation, it only occurs after a
> clock edge.
> 
> Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and
> is faster, but requires more design effort.
> 
> Peter Alfke, Xilinx Applications


The big advantage of distributed RAM is that it's everywhere on the chip
which means that PAR can put it near the logic that it's driving.
Routing delays are the dominant factor in determining the overall
performance of a design. When I look at the worst case paths in .twr
reports I generally see that 75% of the delay is due to interconnect so
anything that can be done to simplify PARs placement job is helpful.
Sixteen word FIFOs are deep enough for many applications, for example I
generally use them to couple different stages of my pipelines together.
The other advantage of distributed RAM is lower latency. The read port on
distributed RAM is asynchronous which saves a minimum of one clock cycle.
In high speed designs it's frequently necessary to double pipeline the
output of a Block RAM, i.e use the output register that's included V4
Block RAM plus an additional dflop register to handle the interconnect
delay, so the difference between distributed RAM and Block ram can be as
much as three cycles (although I would generally pipeline the output of
the distributed RAM in those applications also so the difference is two
cycles). 

In my experience it always been pretty obvious which type of memory to
use. Either you need a lot, in which case you use Block RAM, or you need a
little in which case you use distributed RAM. I've never run into a
situation where I needed something intermediate, either 16 or rarely 32
words is enough or I need 1K or more.


Article: 103692
Subject: Re: API on Virtex 4 FPGA or the email of Delon Levi wanted
From: boxi.yang@gmail.com
Date: 8 Jun 2006 06:54:52 -0700
Links: << >>  << T >>  << A >>

Jacek Wawrzaszek =E5=86=99=E9=81=93=EF=BC=9A

> <boxi.yang@gmail.com> wrote:
> > it would be use on academic research only). Would you please tell me
> > where can I get a  copy of the API or tell me the email address of
> > Delon Levi? Eager for your help, thank you
> >
>
> Heve you tried  Delon (dot) Levi (at) xilinx (dot) com ?
>=20
> J.
Thank you for your reply.Yes I did try but did not get reply


Article: 103693
Subject: Re: Incrmental Compilation in Quartus 5.1
From: "Shawn Malhotra" <shawn.malhotra@gmail.com>
Date: 8 Jun 2006 08:36:47 -0700
Links: << >>  << T >>  << A >>
Hi Joe,

You can certainly use Quartus II Incremental Compilation after
assigning the pins in your design to physical locations on the device.
Incremental compilation should help your co-worker preserve the
unchanged parts of his design, including the pin locations, as he adds
updated modules.  He should also save compilation time during this
process as well.  For more information on Quartus II Incremental
Compilation you can visit the following links:

Quartus II Incremental Compilation Website (Provides an overview of the
feature and links to more information):

http://www.altera.com/products/software/products/quartus2/design/qts-incremental.html

Quartus II Handbook Volume 1, Chapter 1 (Provides a thorough
description of the feature and how to use it):

http://www.altera.com/literature/hb/qts/qts_qii51015.pdf

Hopefully this provides all the information your co-worker needs to use
incremental compilation for his design, good luck!

Regards,

Shawn Malhotra
Altera Corp.

jjlindula@hotmail.com wrote:
> Hello, my co-worker has a very large Altera Quartus 5.1 design that
> takes about 45 minutes to compile. The project has already had the pins
> physically assigned and he is still adding things to the project such
> as updated modules. I mentioned to him that trying Incremental
> Compilation (IC) might decrease compilation time. He asked if you could
> do IC after the I/O pin symbols have been physically assigned to pins?
> I'm not an expert on IC so I hope someone can help.
> 
> Thanks,
> joe


Article: 103694
Subject: Re: Block Ram vs Distributed Ram
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 8 Jun 2006 10:12:35 -0700
Links: << >>  << T >>  << A >>
I think everybody asking for advice should always mention the intended
clock rate.
A 5 ns delay is horribly slow in some applications, but blindingly fast
in others.
Most experienced designers are accustomed to push the envelope, but
many novices might operate below 50 MHz. My first question is always:
How fast is your design?

Peter Alfke, Xilinx
=================
Josh Rosen wrote:
> On Wed, 07 Jun 2006 22:38:31 -0700, Peter Alfke wrote:
>
> > With each Virtex FPGA you get a certain number of BlockRAMs. Until you
> > have used all of them, they are incrementally free, so use them, even
> > if it may look wasteful (18 K or 36 K bit capacity).
> >
> > Nice features like progrmmable width/depth ratio, dual-ported,
> > read-befor-write option, etc
> > You can even do one read-modify-write operation per clock cycle (using
> > both ports)
> >
> > One caveat: Reading is a synchronous operation, it only occurs after a
> > clock edge.
> >
> > Distributed RAM uses 16-bit LUTs and reads in a combinatorial way, and
> > is faster, but requires more design effort.
> >
> > Peter Alfke, Xilinx Applications
>
>
> The big advantage of distributed RAM is that it's everywhere on the chip
> which means that PAR can put it near the logic that it's driving.
> Routing delays are the dominant factor in determining the overall
> performance of a design. When I look at the worst case paths in .twr
> reports I generally see that 75% of the delay is due to interconnect so
> anything that can be done to simplify PARs placement job is helpful.
> Sixteen word FIFOs are deep enough for many applications, for example I
> generally use them to couple different stages of my pipelines together.
> The other advantage of distributed RAM is lower latency. The read port on
> distributed RAM is asynchronous which saves a minimum of one clock cycle.
> In high speed designs it's frequently necessary to double pipeline the
> output of a Block RAM, i.e use the output register that's included V4
> Block RAM plus an additional dflop register to handle the interconnect
> delay, so the difference between distributed RAM and Block ram can be as
> much as three cycles (although I would generally pipeline the output of
> the distributed RAM in those applications also so the difference is two
> cycles).
>
> In my experience it always been pretty obvious which type of memory to
> use. Either you need a lot, in which case you use Block RAM, or you need a
> little in which case you use distributed RAM. I've never run into a
> situation where I needed something intermediate, either 16 or rarely 32
> words is enough or I need 1K or more.


Article: 103695
Subject: Re: Rumor Control:: Will Quartus phase out supporting AHDL?
From: "Andy" <jonesandy@comcast.net>
Date: 8 Jun 2006 10:56:17 -0700
Links: << >>  << T >>  << A >>
I find it interesting that Xilinx webpack has tools to convert AHDL to
VHDL, but Altera does not!  Of course, the copyright notice included in
the generated code restricts its use to Xilinx products.

Andy


Jim Granville wrote:
> jjlindula@hotmail.com wrote:
>
> > Hello, I posted this question a while back but I'm hearing the rumor
> > again from people attending Altera's Quartus workshops. The rumor is
> > that Altera may eventually phase out their support of AHDL in their
> > Quartus development software. Does anyone know what's in the future for
> > AHDL?
>
>   I can see that they would move AHDL to "maintenance mode", but I doubt
> they would kill it entirely.
>
>   Altera took some trouble to keep the MAX +II interface option, and
> CPLDs must still be a sizeable chunk of their business.
>
>   I liked what Xilinx did with ABEL : that now generates VHDL output
> (IIRC), and so can hook into all the back end tools, whilst at the
> same time, preserve customers code base.
>   In this form, ABEL is a valid choice for new designs ( esp in the
> CPLD arena ).
>
>   Altera could do the same, with their AHDL (or may have already).
> 
>   Someone at Altera may clarify this ?
> 
> -jg


Article: 103696
Subject: Re: Rumor Control:: Will Quartus phase out supporting AHDL?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 08 Jun 2006 11:23:57 -0700
Links: << >>  << T >>  << A >>
Andy wrote:
> I find it interesting that Xilinx webpack has tools to convert AHDL to
> VHDL, but Altera does not! 

Yes. In fact Quartus synthesis still maps
a few VHDL code templates to
.tdf (AHDL) blocks.

Still some reptile brain inside :)

              -- Mike Treseler

Article: 103697
Subject: stable, tested 6502 core
From: aiiadict@gmail.com
Date: 8 Jun 2006 11:27:09 -0700
Links: << >>  << T >>  << A >>
I'm looking for a stable, tested 6502 core

does one exist?

I'm looking for freebies or
pay-to-gets

Rich


Article: 103698
Subject: Re: Webpack larger than CDs
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 8 Jun 2006 12:33:32 -0700
Links: << >>  << T >>  << A >>
Ryan Laity wrote:
> Rickman,
>
> You don't have to install them using the web installer - that's why I
> suggested that you check the "Install Later" box once the installer
> downloads and you run it.  That makes the Web Installer just act like a
> download tool.  You get installers that can easily be installed from a
> CD at a later time (even by IT).
>
> I've also forwarded this request on the right person within Xilinx,
> perhaps he will comment.  I certainly don't think that the web installer
> is the most intuitive way to download individual installers so I am
> motivated to get this suggestion in the hands of someone who can do
> something about it.  Nonetheless, I've used this method for my customers
> (I'm an FAE) to get a lab-only install of iMPACT standalone, so I've
> been through it myself.
>
> Best regards,
> Ryan Laity
>
> BTW - Rich, I don't like bottom posting, I think that top posting is
> much easier for the flow of the thread (just start at the bottom and
> work up).

Well, I got over my frustration with this effort and gave the download
a try with the "install later" option.  It would not complete.

When I ran the Webinstall software, it started with an error message,
"System Administrator priviledges are needed to install this software."
 It ran anyway, but I kept getting error messages saying "The following
error was encountered during installation:2:An error was detecgted in
the archive.. Press retry to try again, otherwise press cancel to exit
the installation."  I tried both the "Connect directly to the Internet"
and "Use Internet Explorer Proxy Settings" options and got the same
error.

Our system is expressly set up to not allow software installation
without priviledges.  I guess this is still an installation even though
nothing is being installed.  So this method will not work for everyone.


Article: 103699
Subject: Re: Rumor Control:: Will Quartus phase out supporting AHDL?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 09 Jun 2006 07:51:30 +1200
Links: << >>  << T >>  << A >>
Andy wrote:
> I find it interesting that Xilinx webpack has tools to convert AHDL to
> VHDL, but Altera does not!  Of course, the copyright notice included in
> the generated code restricts its use to Xilinx products.

  Given Subroto's reply, why would Altera need to do this ?
AHDL works fine, and is supported.

  Xilinx, on the other hand, have to oil the pathways for
Altera users, so they have to offer something...

-jg




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search