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 101350

Article: 101350
Subject: Re: Xilinx Virtex-4 OCM Usage Issues
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 29 Apr 2006 16:12:30 +0100
Links: << >>  << T >>  << A >>
On Fri, 28 Apr 2006 13:01:57 +0100, "Ben Jones" <ben.jones@xilinx.com>
wrote:

>Hi Brian,
>
>"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
>news:reu352d73g90urns1j9k3j88ie8ahk0qcm@4ax.com...

>> IMO this limitation COULD have been more clearly documented, as well as
>> trapped by the tools...
>
>Good point. As far as documentation goes it took me a while to find where
>this is explained (PowerPC Processor Reference Guide, Chapter 7 "Exceptions
>and Interrupts", section "Interrupt-Handling Registers", EVPR, page ~204,
>and also mentioned in the OS and Libraries Documentation, Standalone PowerPC
>BSP section). :-) Do you have a suggestion as to where else you think this
>should be mentioned, to make it more obvious?

I confess I haven't been through every page of documentation ... 
I'd have to think to recreate the places I looked unsuccessfully.
XAPP778 page 14 was where I found it. It took a while searching the
support site on things like "PPC interrupts".

>The EDK tools do the Right Thing when generating the default linker script -
>and Base System Builder will notify you if you don't have room for the
>vector table in your project due to this limitation (e.g. you have < 64KB of
>BRAM).

Good to hear ... 7.1 didn't (at least, not in my hands). 

I had a 32K plb_bram at ffff8000, and a 16k one at ffff4000. I inherited
the project (so no BSB phase), and in ignorance, moved the lower from
ffff0000 to make them contiguous, and wrongly assigned segments in
"Generate Linker Script". This dialog could warn; but that wouldn't
cover hand edited scripts.

> I guess the linker could be modified to check what it's being asked
>to do with the "vectors" section and barf (or at least issue a warning) if
>the alignment is wrong, but this would be a bit of an ugly "special case"...

IMO it *is* an ugly special case already. I don't believe telling the
user about it is uglier than linking non-functional code.

- Brian

Article: 101351
Subject: Re: What would be the tariff classification of an FPGA development
From: Rene Tschaggelar <none@none.net>
Date: Sat, 29 Apr 2006 17:14:35 +0200
Links: << >>  << T >>  << A >>
jaxato@gmail.com wrote:

> I was wondering what's the tariff classification of an FPGA development
> board.
> Searching through some documentations, I ended up thinking that it may
> be this:
> 
> 8542.70.00 or Electronic microassembly.
> 
> Any person around here knows what it might be. This call specially goes
> to ppl who are exporting to the EU.

I let my stuff be shipped under 8537. None ever
cared. I guess they have certain triggers on
agriculture, fishery, iron, you name them. Where
subsidies protect closed markets. The rest is
not worth checking except for value, the VAT value.

I once wanted to get an export paper for stuff I
transported by car and thus sent a piece of alu
sheet metal with a tag and a part number as dummy.
Together with valid invoice and customs papers.
They, the customs, called me and complained that
the stated 600$ for this alu were not real. And
I replied that they don't have to care as long
as the customer pays for it.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 101352
Subject: Re: Spartan 3 documentation confusing...
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 29 Apr 2006 08:42:12 -0700
Links: << >>  << T >>  << A >>
John,

I have no issues with Rick - I understand his frustration, and I share 
it.  Please do not think poorly of him.  Xilinx did not do him a 
service, and he feels compelled to share his experience here.  OK.  At 
least Steve got it, and fixed it (which is what counts).  For every 
verbal complaint, there are at least ten others too busy to complain (a 
basic rule of customer support).

I am actively working every day to improve Xilinx communications to our 
customers because it is just darned good business to do so:  faster it 
works, faster we get orders.  Just that simple.

But, let us go back to history...

Napoleon was a great leader, and a visionary.  Parks, forests, roads, 
and many other things people take for granted in Europe were done by his 
command.  The fact that he lost his last battle has left him judged 
rather poorly by the English dominated history books.  If he would have 
won, the books would vilify the losers!

History is written by the winners.  A good historian recognizes this, 
and attempts to place themselves in the loser's shoes, and read all 
original accounts, and tries to feret out what facts they can.

To accuse me of being as arrogant as Napoleon was obviously designed to 
tweak my nose - I know that.  But in the Zen tradition, I thank Rick for 
his gift of Napoleon, and appreciate it all the more for its wisdom.

Merci beaucoup M. Rickman, je vous remercie pour votre compliment.

Reflecting on world history,

Austin

Article: 101353
Subject: Re: How to see *.vcd file outported from ChipScope from different computer
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 29 Apr 2006 09:28:49 -0700
Links: << >>  << T >>  << A >>
Hi Hans,
Thank you.

I will try vcd2wlf first because I have access to ModelSim.

Weng


Article: 101354
Subject: Re: Spartan 3 documentation confusing...
From: David Brown <david@westcontrol.removethisbit.com>
Date: 29 Apr 2006 18:48:30 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> John,
> 
> I have no issues with Rick - I understand his frustration, and I share 
> it.  Please do not think poorly of him.  Xilinx did not do him a 
> service, and he feels compelled to share his experience here.  OK.  At 
> least Steve got it, and fixed it (which is what counts).  For every 
> verbal complaint, there are at least ten others too busy to complain (a 
> basic rule of customer support).
> 
> I am actively working every day to improve Xilinx communications to our 
> customers because it is just darned good business to do so:  faster it 
> works, faster we get orders.  Just that simple.
> 
> But, let us go back to history...
> 
> Napoleon was a great leader, and a visionary.  Parks, forests, roads, 
> and many other things people take for granted in Europe were done by his 
> command.  The fact that he lost his last battle has left him judged 
> rather poorly by the English dominated history books.  If he would have 
> won, the books would vilify the losers!
> 
> History is written by the winners.  A good historian recognizes this, 
> and attempts to place themselves in the loser's shoes, and read all 
> original accounts, and tries to feret out what facts they can.
> 

"History will treat me kindly, for I intend to write it"
Winston Churchill.

But I'm not sure the vilification of the loser was unjust that time.


Article: 101355
Subject: Quartus and source control
From: "avishay" <avishorp@yahoo.com>
Date: 29 Apr 2006 09:53:44 -0700
Links: << >>  << T >>  << A >>
Hello all,
I'm interested in implementing a source control system (Subversion) in
the company I work. We do mostly Altera FPGA designs, so our main tool
is Quartus. I would like to know if anyone has done that before, and
how. The main problem with Quartus is that it has no "source file
list", but rather it searches dynamically for files (mostly true for
old design entry methods like AHDL and schematic). Does anyone know of
a tool (maybe a TCL script) that takes a projects and generate a list
of all source files included?
I would be happy to hear about any experience of this kind.

Thanks,
Avishay


Article: 101356
Subject: Re: Opteron HT coprocessors
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Sat, 29 Apr 2006 18:13:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
JJ (johnjakson@gmail.com) wrote:

: > One of the posibilities that interest me is a V4 module sitting in a 940
: > socket with some MGTs wired up (space is tight - I realise that!)  - if
: > you happen to be dealing in high speed data aquisition and processing on
: > the bit/word and (large) frame level then a tightly coupled
: > FPGA/commodity CPU system is really quite exciting.
: >

: Takes one back to when you could interface 68000s or whatever to your
: custom logic or even wire wrap your own mobo, its been along time since
: one could "touch" a processor.

I hate to say it, but that's before my time other than tinkering with the 
CPU bus sticking out the back of an old Amstrad CPC...  There are various 
things now bringing high end commodity CPUs (as opposed to specialist DSP 
hardware) and FPGAs close together - offerings from Cray, SGI, this new 
opteron socketed thingie etc.  Most of the fuss is around their use in 
reconfigurable computing so the offerings tend to be lacking for raw 
serial IO...

: Whats you acquisition area?

Starlight - astronomical adaptive optics.  Potentially you can be talking 
about multiple CCDs of many thosands of pixels framing at over 1KHz...

cds

Article: 101357
Subject: Re: Working Altera USB-Blaster compatible design published underGPL
From: Eric Smith <eric@brouhaha.com>
Date: 29 Apr 2006 11:56:49 -0700
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@openchip.org> writes:
> nops - even vendor generated ASCII SVF/STAPL are not compatible :(

Are you saying that they aren't actually compliant with the standard?

If so, it seems like submitting bug reports to the vendors to get this
fixed would be a good idea.

Article: 101358
Subject: Re: What would be the tariff classification of an FPGA development board?
From: jaxato@gmail.com
Date: 29 Apr 2006 12:01:57 -0700
Links: << >>  << T >>  << A >>
Hi Rene,

Thanks for the tip, 8537.10.10

Jacques


Rene Tschaggelar wrote:
> jaxato@gmail.com wrote:
>
> > I was wondering what's the tariff classification of an FPGA development
> > board.
> > Searching through some documentations, I ended up thinking that it may
> > be this:
> >
> > 8542.70.00 or Electronic microassembly.
> >
> > Any person around here knows what it might be. This call specially goes
> > to ppl who are exporting to the EU.
>
> I let my stuff be shipped under 8537. None ever
> cared. I guess they have certain triggers on
> agriculture, fishery, iron, you name them. Where
> subsidies protect closed markets. The rest is
> not worth checking except for value, the VAT value.
>
> I once wanted to get an export paper for stuff I
> transported by car and thus sent a piece of alu
> sheet metal with a tag and a part number as dummy.
> Together with valid invoice and customs papers.
> They, the customs, called me and complained that
> the stated 600$ for this alu were not real. And
> I replied that they don't have to care as long
> as the customer pays for it.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net


Article: 101359
Subject: Re: What would be the tariff classification of an FPGA development
From: Philipp Klaus Krause <pkk@spth.de>
Date: Sat, 29 Apr 2006 21:23:43 +0200
Links: << >>  << T >>  << A >>
Rene Tschaggelar wrote:

> 
> I let my stuff be shipped under 8537. None ever
> cared. I guess they have certain triggers on
> agriculture, fishery, iron, you name them. Where
> subsidies protect closed markets. The rest is
> not worth checking except for value, the VAT value.

I just got a shipment from digikey. Some TTL-ICs, PICs, Flash,
resistors, capacitors, etc...
I only had to pay the VAT on everything except the ceramic oscillators.
There was 3.7% tariff on the oscillators.
That was a shipment from the USA to the EU a few weks ago.

Philipp

Article: 101360
Subject: Re: Working Altera USB-Blaster compatible design published underGPL
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 29 Apr 2006 21:47:42 +0200
Links: << >>  << T >>  << A >>
"Eric Smith" <eric@brouhaha.com> schrieb im Newsbeitrag 
news:qhhd4cky6l.fsf@ruckus.brouhaha.com...
> "Antti Lukats" <antti@openchip.org> writes:
>> nops - even vendor generated ASCII SVF/STAPL are not compatible :(
>
> Are you saying that they aren't actually compliant with the standard?
>
> If so, it seems like submitting bug reports to the vendors to get this
> fixed would be a good idea.

that would not help. SVF is not complete standard, and some things that
are needed to program flash devices, serial proms, plds, just arent so
much doable with pure SVF as per SVF specification, this is where
the vendors step away to use files that can work on their silicon.

as of ram-fpga there are almost no issues using pure generic SVF but
with anything that has non-volatile its not so nice anymore.

same thing goes for STAPL what is an actual standard - if you use
Actel flavor of STAPL that was downloadable at the time PA3
was released, then voila - there was release notes saying the
STAPL player supports PA+ devices only. when I tried it
with Actel generatedPA3 STAPL files then I got parsing errors!
After fixing the STAPL player to not fail on parsing the Actel
STAPL (that is JAM) player reported succes in programming
and verifying an PA3 device using a STAPL file generated by
Actel software.

There was one gotcha - the silicon was programmed and
player reported verify succes, but the silicon did not work
(fpga did not get configured) - using the same STAPL file with
actel new programmed yielded the silicon being programmed
and configured.

similar things can be expected when working with Xilinx
config memories or PLD's using SVF files, or when trying
to program lattice devices using too old and incompatible
version of their VME player (they use SVF -> VME -> VMEplayer)

So there is no point of reporting issues - all the vendors are going
to reply: use the methods that are intended for the programming
eg XSVFplayer in case of Xilinx or
ispVME in case of Lattice or
correct version of STAPL player in case of Actel or
correnct version of JAM player in case of Altera

none of the vendors will add an magic option:
"generate valid generic SVF for all our silicon devices"
to their software - for one simple reason - they can not.

So no point of asking the impossible.

Please note that with RAM based FPGA there are almost no
(or shouldnt be) any issues using plain generic SVF, there
are some seldom exceptions - as example there are cases
where Xilinx Impact software can not configure S3e over
JTAG but software from Xilant Technologies still works -
this is because of some errata with mode pins - our software
uses a board specific workaround that use NOR Flash CFI
interface to place the ext flash in Query ID mode for the
time of JTAG configuration that prevents the FPGA to
see valid bitstream header (that prevent Impact from
from proper configuration) - this is an extreme case, but
ther are really cases where generic JTAG tools (like
Impact) fail in 'native' eg not SVF mode, so if in such
case an SVF is generated then it would also fail. Sure
in this example our software could generate plain
vanilla SVF that uses the CFI trick, and theoretically
could impact do that too - but it doesnt. Asking
Xilinx to fix that - they will not do (and for good
reason - they fixed the silicon).

To my knowledge this issue should not happen any
more with actual S3e production silicon, but there
is still some ES silicon around that under some
circumstances requires that CFI trick (or change
of mode pins as xilinx suggest as workaround).

Antti

PS folks belive me, I know what I am talking, I have
been struggling with in-system flash programming for
very long time, some links to my early works can still be
found with google search: "PIP02 programming software"
it supported many different
programmer (most of what I have never seen) and in many
cases worked with them better than the original software
from the programmer vendors. I am using the same low
level hardware abstraction layer PINAPI(tm) in our
current JTAG software, what again is thanks to that
completly separated from the 'cable driver' that is
all of our software would work with any jtag cable
given there is a very simple low level driver (basically
pin bit-bang driver)

PPS the JTAG programming should be plain simple
and always work, but there are many cases where
strange things are observed - like S3 board that
will get configured with either Cable IV (original)
or Platform cable. However when platform flash
config is enabled then the S3 starts up with bad
bitstream - done=1 but impact gives verify
error, also when platform is erased, but only
when using the Cable IV !! when using the
USB Cable it all works. The S3 is not bad
the thing can be observed any several boards.

If impact fails with Cable IV and succeeds with
USB cable then SVF player would fail, or
at least would not guaranteed to succeed. This
issues is not related to bad board or JTAG
signal quality. Similary there is 'minimum clock
requirement' for some revision of platform
flash, as SVF player that is standard compliant
doesnt have to maintain any minimum TCK
then those config memories would never get
programmed using SVF.




















Article: 101361
Subject: Re: Quartus and source control
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 29 Apr 2006 22:14:05 +0200
Links: << >>  << T >>  << A >>
"avishay" <avishorp@yahoo.com> writes:

> I'm interested in implementing a source control system (Subversion) in
> the company I work. We do mostly Altera FPGA designs, so our main tool
> is Quartus. I would like to know if anyone has done that before, and

Most of my designes are under CVS. They are are a mix of ASIC, Altera,
and Xilinx designs. Some of the designs have even an implementation
for all the above. However, I rarely use the GUI tools, except for
floorplanners, memory/ip-builder and waveform viewers. To generate a
new implementation I usually do:

cvs checkout designname
cd designname/impl/somefpgadevicename
make

In the Altera case make will run quartus_sh.

> how. The main problem with Quartus is that it has no "source file
> list", but rather it searches dynamically for files (mostly true for
> old design entry methods like AHDL and schematic). Does anyone know of
> a tool (maybe a TCL script) that takes a projects and generate a list
> of all source files included?

I usually explicitly list my source files:

foreach f designfile1.v designfile2.v designfile3.v {
    set_global_assignment -name VERILOG_FILE $f
}


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 101362
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 29 Apr 2006 13:34:44 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> rickman wrote:
>
> > People here are driving me crazy insisting that the Xilinx factory has
> > told them that you *MUST* tie the mode pins to either Vaux or GND.
> > After finding all the info in the data sheet and talking with support,
> > it looks pretty clear to me that the S3 parts have a very stiff
> > internal pull up and there is no need for an external pull up of any
> > kind, resistor or direct connection to Vaux.
> >
> > Am I misunderstanding?  Why did the factory tell us before that the
> > mode pins *MUST* be tied to Vaux?  Did we misunderstand what they were
> > saying?
> >
> > I promise this is the last time I will ask about this.  I am totally
> > sick of going around this loop with everyone here.
>
> Design the PCB with options for SMD resistors, that can also be
> 0-Ohm shunts, and say 'define in production for valid logic levels'.
> That gets you past the design review, and closes the case :)

I started the design review process with pullups and pull downs of 10
kohms and was told I had to use direct connections.  Of course they
could have been replaced with 0 ohm resistors at any time if needed.
Once I had researched the issue, I thought I had an FAE's blessing of
4.7 kohm resistors.  I had found that the pull up resistors were rather
strong in the S3 parts, but did not find any indication that there were
internal pullups on those pins.  Turns out I had missed the sentance
that told about them.  Once I found that, it all started to make sense.
 With internal pullups of 1-3 kohms I can see where a pull down
resistor would have to be low enough that there would not be much point
of using a value larger than 0 ohms.  Being very cramped for space,
especially in the area of the mode pins, I removed the pullups all
together and am relying on the internal pullups.  But some people here
("here" my work, not "here" the newsgroup) just won't let go of the
bone.  They are insisting that the pins must be connected to Vaux
directly because of what they were told a year ago.

I don't want to put parts on the board that aren't required.  It seems
pretty durn clear to me that pullup resistors are not needed on the
mode pins at any time, under any circumstances.  The board is due to
come out of layout in a couple of days and I don't want to interrupt
progress.  I don't understand why I can't get a clear answer to this
question.  Peter replied, but didn't answer the question.  I honestly
do not trust the support phone line (because I don't actually talk to
the person who gives the answer, just the gopher who relays the
message) and can't document what I am told verbally.  I can't get an
account to work to get support by email.  So I guess I'll have to
resort to working with the FAE who has already given me bad advice.


Article: 101363
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 29 Apr 2006 13:38:36 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> rickman wrote:
>
> > People here are driving me crazy insisting that the Xilinx factory has
> > told them that you *MUST* tie the mode pins to either Vaux or GND.
> > After finding all the info in the data sheet and talking with support,
> > it looks pretty clear to me that the S3 parts have a very stiff
> > internal pull up and there is no need for an external pull up of any
> > kind, resistor or direct connection to Vaux.
> >
> > Am I misunderstanding?  Why did the factory tell us before that the
> > mode pins *MUST* be tied to Vaux?  Did we misunderstand what they were
> > saying?
> >
> > I promise this is the last time I will ask about this.  I am totally
> > sick of going around this loop with everyone here.
>
> Design the PCB with options for SMD resistors, that can also be
> 0-Ohm shunts, and say 'define in production for valid logic levels'.
> That gets you past the design review, and closes the case :)

I started the design review process with pullups and pull downs of 10
kohms and was told I had to use direct connections.  Of course they
could have been replaced with 0 ohm resistors at any time if needed.
Once I had researched the issue, I thought I had an FAE's blessing of
4.7 kohm resistors.  I had found that the pull up resistors were rather
strong in the S3 parts, but did not find any indication that there were
internal pullups on those pins.  Turns out I had missed the sentance
that told about them.  Once I found that, it all started to make sense.
 With internal pullups of 1-3 kohms I can see where a pull down
resistor would have to be low enough that there would not be much point
of using a value larger than 0 ohms.  Being very cramped for space,
especially in the area of the mode pins, I removed the pullups all
together and am relying on the internal pullups.  But some people here
("here" my work, not "here" the newsgroup) just won't let go of the
bone.  They are insisting that the pins must be connected to Vaux
directly because of what they were told a year ago.

I don't want to put parts on the board that aren't required.  It seems
pretty durn clear to me that pullup resistors are not needed on the
mode pins at any time, under any circumstances.  The board is due to
come out of layout in a couple of days and I don't want to interrupt
progress.  I don't understand why I can't get a clear answer to this
question.  Peter replied, but didn't answer the question.  I honestly
do not trust the support phone line (because I don't actually talk to
the person who gives the answer, just the gopher who relays the
message) and can't document what I am told verbally.  I can't get an
account to work to get support by email.  So I guess I'll have to
resort to working with the FAE who has already given me bad advice.


Article: 101364
Subject: Re: What would be the tariff classification of an FPGA development board?
From: jaxato@gmail.com
Date: 29 Apr 2006 13:49:24 -0700
Links: << >>  << T >>  << A >>
Hi Philipp,

>From what i've read, a VAT price would already include tariff, but the
oscillators might be VAT exempted, but still with tariff. Was it
written explicitly on the invoice that tariff was applied?

Jacques


Article: 101365
Subject: Book Software for XC3190A?
From: tuxfriend <tuxfriend@arcor.de>
Date: Sat, 29 Apr 2006 22:52:17 +0200
Links: << >>  << T >>  << A >>
Hi,
is it possible to program the XC3190A with the tools in the book:
The Practical Xilinx Designer Lab Book: Version 1.5
Are there any restrictions?

Thank you!

Article: 101366
Subject: Re: What would be the tariff classification of an FPGA development
From: Philipp Klaus Krause <pkk@spth.de>
Date: Sat, 29 Apr 2006 23:21:56 +0200
Links: << >>  << T >>  << A >>
jaxato@gmail.com wrote:
> Hi Philipp,
> 
>>From what i've read, a VAT price would already include tariff, but the
> oscillators might be VAT exempted, but still with tariff. Was it
> written explicitly on the invoice that tariff was applied?
> 
> Jacques
> 

I got the components first, a few days later I received an invoide from
customs.
It says they estimated the value (invoice value - estimated fraction of
shipment costs) of the oscillators to be 41.45 €. On this value there
was a tariff of 3.7%.
It says the value for VAT calculation (invoice value + tariff) is 48.38
€. On this value there was a VAT of 16%.

So I had to pay both tariff and VAT for the oscillators, but VAT only
for the rest.

Philipp

Article: 101367
Subject: Re: Quartus and source control
From: "johnp" <johnp3+nospam@probo.com>
Date: 29 Apr 2006 16:06:56 -0700
Links: << >>  << T >>  << A >>
What a timely post.  I was just looking into this on Friday (but with
CVS).

I've been used to Xilinx where I just archived my .npl an .ucf files to
capture
the project settings for the Synthesis/P&R..

I believe in Quartus you need to archive the .qpf and .qsf files (as
well
as your HDL code, of course).

Does anyone know of other Quartus specific files that need archived to
be
able to restore the Synthesis/P&R project?



John Providenza


Article: 101368
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 29 Apr 2006 16:16:01 -0700
Links: << >>  << T >>  << A >>
For crying out loud, do not make a federal case out of this!

If the documentation asks for a short circuit, then do it!
If your gut feel says there is no need for any external pull-up at all,
then measure the internal pull-up impedance the way I suggested, and if
it is below 3 kilohm, then connect nothing.
If the FAE suggests an external resistor, so use one.
This may be a question of belts or suspenders or both or neither...

But remember: If you want to establish a logical Low level, you must
definitely be cautious and measure whether you are fighting an internal
pull-up.

I much rather spend 10 minutes with a multi-meter than indulge in
contankerous debates in the newsgroup.
We are all engineers and not scribes, aren't we?

Peter Alfke, obviously somewhat irritated...
Like Austin, I am human, too.
Even though we always wear the Xilinx badge, we are still allowed to
voice an opinion...


Article: 101369
Subject: Re: Spartan 3 documentation confusing...
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 29 Apr 2006 16:29:01 -0700
Links: << >>  << T >>  << A >>
Regarding Napoelon:
France loves him, although he caused misery and the death of hundreds
of thousands of her sons.
The Germans hate him for beating their armies, although he also
terminated the Middle Ages and laid the beginning of the foundation of
the modern German state and its secular laws.

For better or worse, Napoleon left an enormous, and largely positive
heritage.
(I grew up in a house that Napoleon rode by on his way to Moscow...
History is everywhere in Europe.)
Peter Alfke


Article: 101370
Subject: Re: Quartus and source control
From: "Subroto Datta" <sdatta@altera.com>
Date: Sun, 30 Apr 2006 00:14:10 GMT
Links: << >>  << T >>  << A >>
The list of all source files compiled can be found in the Report file under 
Analysis and Synthesis->Source Files Read.
You can right click in this window and save the panel out to a text file. 
Take every file which says User Entered, every file which is not under the 
Quartus installation directory and add it to your source code control 
system. Then follow Petter's instructions. The process of discovery only 
works in the cases where there is 1-1 relationship between filename and 
entity name. This is true for BDF's (schematics) and TDF's(AHDL), but does 
not hold true for HDL's like VHDL and Verilog. You are required to add the 
list of HDL files in your project.

I recommend that you archive your design, and restore it in a separate 
directory. This should contain the list of files that Quartus needs to 
recreate your project.  Never archive the db directory. To learn how to 
generate a Quartus Project from scratch each time if you only have the HDL 
files  take a look at the Tcl file generated by the Project->Generate Tcl 
file for Project command.

Hope this helps,
Subroto Datta
Altera Corp.


"avishay" <avishorp@yahoo.com> wrote in message 
news:1146329623.963661.11530@j73g2000cwa.googlegroups.com...
> Hello all,
> I'm interested in implementing a source control system (Subversion) in
> the company I work. We do mostly Altera FPGA designs, so our main tool
> is Quartus. I would like to know if anyone has done that before, and
> how. The main problem with Quartus is that it has no "source file
> list", but rather it searches dynamically for files (mostly true for
> old design entry methods like AHDL and schematic). Does anyone know of
> a tool (maybe a TCL script) that takes a projects and generate a list
> of all source files included?
> I would be happy to hear about any experience of this kind.
>
> Thanks,
> Avishay
> 



Article: 101371
Subject: Re: Book Software for XC3190A?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 29 Apr 2006 18:16:04 -0700
Links: << >>  << T >>  << A >>
The XC3190A was introduced 15 years ago, which makes it hopelessly
obsolete. Even if you find the hardware sufficient (no on-chip RAM!),
the software is so antiquated that nobody should be forced to use it.
Get yourself a modern chip of Spartan or Virtex caliber and of 2003+
vintage. The hardware is cheap, and the software is free, and both are
very competent.
Happy designing with 21st century stuff!
Peter Alfke, Xilinx


Article: 101372
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: John_H <johnhandwork@mail.com>
Date: Sun, 30 Apr 2006 01:16:53 GMT
Links: << >>  << T >>  << A >>
The documentation DOESN'T say to strap unless you think a schematic in 
an app note is definitive direction on how to treat those pins.

The engineers are bugging rickman because of app notes they saw that 
showed direct connects.

The documentation does not clearly state the condition of the pullups 
for dedicated inputs like the JTAG lines that I couldn't get to work in 
a chain for the life of me a few months ago.

There have been repeated attempts to clarify the datasheet information 
on this board without a clear answer - it's clear that he needs to email 
Steve Knapp directly but that certainly won't help me without follow up 
here.

This is not a federal case and I have been impressed with the civility 
demonstrated by rickman and Austin.

Steve Knapp hasn't appeared to answer the question most explicitly posed 
by Rickman as a clarifying question.

Gut feels do not work when an engineer has to submit to a design review 
process that doesn't allow "gut feel" for a documented follow up to a 
design review action item.

The FAE suggested a resistor which isn't compatible with the Spartan-3 
configuration.

Multimeters work for one part, not for a production design.
____________

I may be asked to consider a Spartan3 as opposed to the 2 big Spartan3Es 
on my one board - if I have to go that route I'll be facing the same 
documentation and the knowledge that there hasn't been a clear answer 
here in these threads.

All that's desired is a straight answer - is that so much to ask?


Peter Alfke wrote:
> For crying out loud, do not make a federal case out of this!
> 
> If the documentation asks for a short circuit, then do it!
> If your gut feel says there is no need for any external pull-up at all,
> then measure the internal pull-up impedance the way I suggested, and if
> it is below 3 kilohm, then connect nothing.
> If the FAE suggests an external resistor, so use one.
> This may be a question of belts or suspenders or both or neither...
> 
> But remember: If you want to establish a logical Low level, you must
> definitely be cautious and measure whether you are fighting an internal
> pull-up.
> 
> I much rather spend 10 minutes with a multi-meter than indulge in
> contankerous debates in the newsgroup.
> We are all engineers and not scribes, aren't we?
> 
> Peter Alfke, obviously somewhat irritated...
> Like Austin, I am human, too.
> Even though we always wear the Xilinx badge, we are still allowed to
> voice an opinion...

Article: 101373
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 29 Apr 2006 18:54:31 -0700
Links: << >>  << T >>  << A >>
John, this is analog territory, and there is NOT just ONE right answer.

Obviously, a short circuit will always work, if you never need the pin
for any other purpose.
   But we will not force you to do that, since you may have reasons not
to like it. It's a free country!
   There is no mystery here, the purpose is only to establish a High
logic level. Nothing more, nothing less.
Obviously, a built-in pull-up resistor will establish a High logic
level, but it might be sensitive to crosstalk coming from your
pc-board..
Obviously, any external resistor reduces the pull-up impedance, and
improves the situation.
Obviously an external pull-down resistor must be low enough in value to
overcome the internal pull-up resistance.

And I still favor a multimeter for getting a grip on fundamentals.

I am all for clear documentation, but it never hurts to keep the
engineering mind alive.
Compared to multi-gigabit receiver issues, this mode-pin level debate
is really a trivial subject. 

Peter Alfke


Article: 101374
Subject: Reset
From: "Fizzy" <fpgalearner@gmail.com>
Date: 29 Apr 2006 18:56:33 -0700
Links: << >>  << T >>  << A >>
Hi,

What is the difference between Asynchronous and Synchronous reset. When
do you want to use one of them. I am desging a state machine how would
i figure out which one i want to use. How would it impact the
hardware???

Thanks




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