EDK : FSL macros defined by Xilinx are wrong

[Simon Peacock]

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message
news:upth9h1p5.fsf@trw.com...

"Plenolo" <plenolo@freemail.it> writes:

Hi all i am new in the group, i am a italian student of computer science
and
i have hobbies for electronics, too... so i have using PIC, St6/7
microcontroller, etc.. now my dream is develop some circuit with fpga
(or
similar) and VHLD language. I have just a bit studing (only teorically)
VHDL
in my university, but now i would REALLY program some chip for develop
some
simple and medium project.
I have not money (and i don't want ) to buy some original developing
system, so i would home build some free "programmer" (in-circuit JTAG
???)
how i have do in pass for PIC / St6/7 programmers


You'd be better off on comp.arch.fpga, for the actual hardware
questions - I've crossposted to there and set the followups to go
there also.

Regarding programming hardware, Altera have the Byteblaster schematics
downloadable from their site, in the Byteblaster datasheet. I can;t
recall if Xilinx have similar.

If you hunt around on the web you can still finds the schematics for the old
Xilinx Downloaders.

Thank you very much to all friends, and sorry for my very bad and poor
english language


It's better than my Italian!

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Amontec Team, Laurent Gau]

Martin Thompson wrote:

"Plenolo" <plenolo@freemail.it> writes:


Hi all i am new in the group, i am a italian student of computer science and
i have hobbies for electronics, too... so i have using PIC, St6/7
microcontroller, etc.. now my dream is develop some circuit with fpga (or
similar) and VHLD language. I have just a bit studing (only teorically) VHDL
in my university, but now i would REALLY program some chip for develop some
simple and medium project.
I have not money (and i don't want ) to buy some original developing
system, so i would home build some free "programmer" (in-circuit JTAG ???)
how i have do in pass for PIC / St6/7 programmers



You'd be better off on comp.arch.fpga, for the actual hardware
questions - I've crossposted to there and set the followups to go
there also.

Regarding programming hardware, Altera have the Byteblaster schematics
downloadable from their site, in the Byteblaster datasheet. I can;t
recall if Xilinx have similar.


Thank you very much to all friends, and sorry for my very bad and poor
english language



It's better than my Italian!

Cheers,
Martin

Hi Martin,

Maybe the Chameleon POD can be a good start point for you.

That's an small dongle with inside CPLD Coolrunner. You can use it for
programming almost all processor on the market (From ARM, PPC to AVR and
coldFire, ...) or you can customize the POD by your own VHDL code (I2C
controller, PWM generator, motor control, ...).

A great solution for small VHDL designs.

www.amontec.com/chameleon.shtml
All software is free.

Regards,
Laurent
www.amontec.com

 

[rickman]

Rene Tschaggelar wrote:

Alessandro Strazzero wrote:
"Geoffrey Mortimer" <me@privacy.net> wrote in message news:<bmjk16$ngmof$1@ID-163942.news.uni-berlin.de>...

Anyone have any experience of BGA's (especially fine pitch types) in high
vibration environments? Is there a more appropriate newsgroup for this
topic?

It strongly depends from your vibration requirements.

I currently use electronic boards installed into railway equipments which use
BGA components, and they are conforme to the European Union railway equipment
manifacturing specification

Hi Alessandro,
are there any specifications on the vibration ?
Frequency, amplitude, pattern ?
Perhaps a defined testing procedure ?

This thread might do well in comp.arch.fpga. There are several FAEs
there who love digging into just this sort of issue.

I have crossposted there.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Thomas Stanka]

Xpost 2 cae and caf, no Fup.

Hallo,

"Geoffrey Mortimer" <me@privacy.net> wrote:

Anyone have any experience of BGA's (especially fine pitch types) in high
vibration environments? Is there a more appropriate newsgroup for this
topic?

Actually that's a very hot topic as BGA seems to get usual in the
world of FPGAs and ASICs. I know that our mechanical engineers
allready research on this topic, as we are very likely to have some
fine pitch BGA in a high vibration environment in future.
I would guess, that you should ask in some mechanical newsgroups as
well.
A big problem using FBGA is the test, wether you connected all balls
proberly [1], as you have no chance of easy visual inspection.

bye Thomas

[1] in a mechanical aspect. Of course you get a quick answer if one IO
has no electrical connection.

--
Don't answer to the email in from, use thomas[at]<domain above> for
PM.

 

[rickman]

Thomas Stanka wrote:

Xpost 2 cae and caf, no Fup.

Hallo,

"Geoffrey Mortimer" <me@privacy.net> wrote:
Anyone have any experience of BGA's (especially fine pitch types) in high
vibration environments? Is there a more appropriate newsgroup for this
topic?

Actually that's a very hot topic as BGA seems to get usual in the
world of FPGAs and ASICs. I know that our mechanical engineers
allready research on this topic, as we are very likely to have some
fine pitch BGA in a high vibration environment in future.
I would guess, that you should ask in some mechanical newsgroups as
well.
A big problem using FBGA is the test, wether you connected all balls
proberly [1], as you have no chance of easy visual inspection.

bye Thomas

I recently saw a product that allows visual inspection of the solder
balls on a mounted BGA. It is a fiber optic microscope and has tiny
fiber probes that can run between the balls. I'll look for the info if
anyone is interested.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[H. Peter Anvin]

Followup to: <3F93E3DC.6753DCD4@yahoo.com>
By author: rickman <spamgoeshere4@yahoo.com>
In newsgroup: comp.arch.fpga

I recently saw a product that allows visual inspection of the solder
balls on a mounted BGA. It is a fiber optic microscope and has tiny
fiber probes that can run between the balls. I'll look for the info if
anyone is interested.

A lot of people seem to do X-ray inspection, which I guess could be
considered "visual" in some way.

-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

 

[Ron Huizen]

Rick,

I'd certainly be interested in more info on the fiber microscope you
mentioned. Debugging designs with lots of big BGAs is tough enough without
wondering whether it's an assembly issue or not, and traditional xray
techniques are good for showing shorts, but no so good for opens ...

-----
Ron Huizen
BittWare

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F93E3DC.6753DCD4@yahoo.com...

Thomas Stanka wrote:

Xpost 2 cae and caf, no Fup.

Hallo,

"Geoffrey Mortimer" <me@privacy.net> wrote:
Anyone have any experience of BGA's (especially fine pitch types) in
high
vibration environments? Is there a more appropriate newsgroup for this
topic?

Actually that's a very hot topic as BGA seems to get usual in the
world of FPGAs and ASICs. I know that our mechanical engineers
allready research on this topic, as we are very likely to have some
fine pitch BGA in a high vibration environment in future.
I would guess, that you should ask in some mechanical newsgroups as
well.
A big problem using FBGA is the test, wether you connected all balls
proberly [1], as you have no chance of easy visual inspection.

bye Thomas

I recently saw a product that allows visual inspection of the solder
balls on a mounted BGA. It is a fiber optic microscope and has tiny
fiber probes that can run between the balls. I'll look for the info if
anyone is interested.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Nik Simpson]

Jeff Peterson wrote:

We are building a new radio telescope called PAST
(http://astrophysics.phys.cmu.edu/~jbp/past6.pdf)
which we will install at the South Pole or in Western China.

To make this work, will need to sample (6 to 8 bit precision) dozens
of analog voltages at 400 Msample/sec and feed these data streams into
PCs. One PC per sampler.

How big is a sample?

The flash ADCs we need are available (Maxim), but we are finding it
difficult to get the data into the PC.

One simple way would be to use SCSI ultra640, but so far I have not
found any 640 adapters on the market. Is any 640 adapter available?
anything coming soon?

or we could go right into a PCI-X bus. has anyone out there
done this at 400 Mb/s? is this hard to do? FPGA core liscense
for this seems expensive ($9K), with no guarentee of 400 mByte rates.

is there a better way?

Not clear from this whether you mean Mbit/s or MBytes/sec. If you mean
Mbit/s then obviously that's not a hard problem to solve. If as I suspect
you do mean Mbytes/sec then a PC (by the conventional definition) isn't
going to cut it because typical PC motherboards don't support PCI-X at any
frequency, they are still limited to 33MHz/32bit PCI which just isn't good
enough.

So the first step will be identifying a motherboard (probably with a
workstation or server classification) that supports PCI-X at least 100MHz,
which gives a peak theoretical throughput of 800MB/s, but a sustain probably
closer to 400MB/s. Then you need to define what you are doing with the data,
for example you could be:

1. Just capturing the data performing some operation on it, storing the
results and throwing away the sample

2. You might be actually planning to capture to disk 400MB/s for a sustained
period which has some pretty hairy implications for storage capacity.

I do know of one site doing something on a similar scale, and that's a US
Airforce project called Starfire Optical Range
(http://www.sor.plk.af.mil/SOR/) at Kirkland AFB. I don't believe this
project is heavily classified (I certainly didn't have to sign anything
before helping them on the storage subsystem in 2000) so it might be worth
contacting them to see if they can help you spec out a system.


--
Nik Simpson

 

[MM]

Do you really need to transfer raw data? Can you do some front-end
processing to bring the speed down? If answers are 'yes' and 'no'
respectively, think of repacking. You can pack 8 bytes into one 64-bit word.
This brings the speed down to 50 MW/s, which should fit into regular 64/66
PCI.


/Mikhail



"Jeff Peterson" <jbp@cmu.edu> wrote in message
news:369b6e8b.0311190715.4d66f38f@posting.google.com...

We are building a new radio telescope called PAST
(http://astrophysics.phys.cmu.edu/~jbp/past6.pdf)
which we will install at the South Pole or in Western China.

To make this work, will need to sample (6 to 8 bit precision) dozens
of analog voltages at 400 Msample/sec and feed these data streams into
PCs. One PC per sampler.

The flash ADCs we need are available (Maxim), but we are finding it
difficult to get the data into the PC.

One simple way would be to use SCSI ultra640, but so far I have not
found any 640 adapters on the market. Is any 640 adapter available?
anything coming soon?

or we could go right into a PCI-X bus. has anyone out there
done this at 400 Mb/s? is this hard to do? FPGA core liscense
for this seems expensive ($9K), with no guarentee of 400 mByte rates.

is there a better way?

thanks

-Jeff Peterson

 

[glen herrmannsfeldt]

Jeff Peterson wrote:

We are building a new radio telescope called PAST
(http://astrophysics.phys.cmu.edu/~jbp/past6.pdf)
which we will install at the South Pole or in Western China.

To make this work, will need to sample (6 to 8 bit precision) dozens
of analog voltages at 400 Msample/sec and feed these data streams into
PCs. One PC per sampler.

The flash ADCs we need are available (Maxim), but we are finding it
difficult to get the data into the PC.

One simple way would be to use SCSI ultra640, but so far I have not
found any 640 adapters on the market. Is any 640 adapter available?
anything coming soon?

or we could go right into a PCI-X bus. has anyone out there
done this at 400 Mb/s? is this hard to do? FPGA core liscense
for this seems expensive ($9K), with no guarentee of 400 mByte rates.

The first thing I would think of would be to buffer it and then read it
later. You don't say how long this data stream will be, or if this is a
peak rate with a much lower average rate. Does it have to go to disk at
that rate?

You could collect the samples into 64 bit words and write then into
SDRAM at 40 or 50 MHz.

If it has to go to disk at that rate, I would work on the hardware to
get it onto the disk without a processor in between.

-- glen

 

[MM]

we accumualte averages (of cross products of fourier tranforms)

What are you going to be using for calculations? If you are planning on
using DSP cards, then you don't need to go through PCI. You coud transfer
data directly from your A/D card to a DSP card using for example FPDP
interface.

There is a number of companies who do similar things for radar and sonar.
Look at the products by Pentek, ICS, Gage, etc...

BTW, I think this discussion drifted away from the FPGA topic, so it
probably doesn't belong here...

/Mikhail

 

[Nik Simpson]

Jeff Peterson wrote:

1. Just capturing the data performing some operation on it, storing
the results and throwing away the sample

we accumualte averages (of cross products of fourier tranforms)

So the basic problem is getting 400MB/s of data into memory and processing
it, but are you reading 400MB every second, or sampling say once every ten
seconds. If it's every second, then you've got a bigger problem because I'd
be surprised if you can process it fast enough to get the job done before
the next sample comes along.

2. You might be actually planning to capture to disk 400MB/s for a
sustained period which has some pretty hairy implications for
storage capacity.

we wont store the raw data, just a very much reduced set.

So disk output bandwidth is not going to be a problem, what you are looking
for is a way of getting 400MB/s of data into memory for post-processing,
correct. Is it possible to break-up the input stream, so for example instead
of reading a single stream of 400MB/s, you've five devices reading 80MB/s in
parralel? Is the design of the device capturing the data set in stone or can
it be "parrallelized" if so it would make the problem much simpler and any
solution more scalable and less expensive.


--
Nik Simpson

 

[Jeff Peterson]

"Nik Simpson" <n_simpson@bellsouth.net> wrote in message news:<vQPub.41$zi3.40@bignews3.bellsouth.net>...

Jeff Peterson wrote:
1. Just capturing the data performing some operation on it, storing
the results and throwing away the sample

we accumualte averages (of cross products of fourier tranforms)


So the basic problem is getting 400MB/s of data into memory and processing
it, but are you reading 400MB every second, or sampling say once every ten
seconds. If it's every second, then you've got a bigger problem because I'd
be surprised if you can process it fast enough to get the job done before
the next sample comes along.
we will take about 64K samples, then can pause while processing...

however all the time we are pausing we are losing data. so we do want to
keep the duty cycle up. 50% dudty cyle is not a problem. 5% would be.

2. You might be actually planning to capture to disk 400MB/s for a
sustained period which has some pretty hairy implications for
storage capacity.

we wont store the raw data, just a very much reduced set.

So disk output bandwidth is not going to be a problem, what you are looking
for is a way of getting 400MB/s of data into memory for post-processing,
correct. Is it possible to break-up the input stream, so for example instead
of reading a single stream of 400MB/s, you've five devices reading 80MB/s in
parralel? Is the design of the device capturing the data set in stone or can
it be "parrallelized" if so it would make the problem much simpler and any
solution more scalable and less expensive.
this could work. for example we have considered using 2 x scsi 320

interfaces. might work but its a bit of a kludge, and if we got the
two interfaces out of sync we would have a real mess.

 

[Jeff Peterson]

"MM" <mbmsv@yahoo.com> wrote in message news:<bpg42l$1o09pi$1@ID-204311.news.uni-berlin.de>...

Do you really need to transfer raw data? Can you do some front-end
processing to bring the speed down? If answers are 'yes' and 'no'
respectively, think of repacking. You can pack 8 bytes into one 64-bit word.
This brings the speed down to 50 MW/s, which should fit into regular 64/66
PCI.


/Mikhail

i dont believe we can reduce the data rate by pre-processing.

yes, repacking might allow a 64/66 PCI to accept the data. i worry
that we will spend lots of time and money, but the margin will be
insufficient for it to actually work. i have heard that some PCI
cores are not too efficient.

-Jeff

 

[Symon]

"Jeff Peterson" <jbp@cmu.edu> wrote in message
news:369b6e8b.0311191050.44b781b6@posting.google.com...

we accumualte averages (of cross products of fourier tranforms)

Jeff,
I think you need to do the 'we accumualte averages (of cross products of
fourier tranforms)' in your FPGA. That way you dramatically reduce your data
rate down to something sensible. It sounds tricky, but not as tricky as
getting 400M x 8 bits x 50% duty cycle = 1.6 Gbps into a PC and processing
it!
cheers, Syms.

 

[Nik Simpson]

Jeff Peterson wrote:

"Nik Simpson" <n_simpson@bellsouth.net> wrote in message
news:<vQPub.41$zi3.40@bignews3.bellsouth.net>...
Jeff Peterson wrote:
1. Just capturing the data performing some operation on it, storing
the results and throwing away the sample

we accumualte averages (of cross products of fourier tranforms)


So the basic problem is getting 400MB/s of data into memory and
processing it, but are you reading 400MB every second, or sampling
say once every ten seconds. If it's every second, then you've got a
bigger problem because I'd be surprised if you can process it fast
enough to get the job done before the next sample comes along.
we will take about 64K samples, then can pause while processing...
however all the time we are pausing we are losing data. so we do
want to
keep the duty cycle up. 50% dudty cyle is not a problem. 5% would be.

From my limited understanding of FFTs the actual processing should be
something that could easily be multi-threaded and would see pretty close to
linear scalability with additional CPUs, so at the very least an SMP system
with at least 2-4 CPUs would help, and assuming it's 64bit floating point
then a 64bit CPU like Opteron or Itanium might come in handy. If the idea of
multiple data streams is possible (and the synchronization problem can be
overcome) then if workload does scale well with CPUs, a cluster of low-cost
single CPU systems each processing part of the data stream would be worth
looking at as this could be easily scaled, i.e. five systems each handling
an 80MB/s stream might be cheaper and faster than one big system trying to
crunch 400MB/s. Additionally, if designed this way, then you could add
additional systems in order to increase the duty cycle, i.e. 10 systems
handing 40MB/s could be relatively cheap and would have roughly 2x the duty
cycle of the original 5 systems.

2. You might be actually planning to capture to disk 400MB/s for a
sustained period which has some pretty hairy implications for
storage capacity.

we wont store the raw data, just a very much reduced set.

So disk output bandwidth is not going to be a problem, what you are
looking for is a way of getting 400MB/s of data into memory for
post-processing, correct. Is it possible to break-up the input
stream, so for example instead of reading a single stream of
400MB/s, you've five devices reading 80MB/s in parralel? Is the
design of the device capturing the data set in stone or can it be
"parrallelized" if so it would make the problem much simpler and any
solution more scalable and less expensive.
this could work. for example we have considered using 2 x scsi 320
interfaces. might work but its a bit of a kludge, and if we got the
two interfaces out of sync we would have a real mess.

Is there any way to insert synch markers in the data stream so that the
problem of data streams getting out of sync can be handled?


--
Nik Simpson

 

[Quinn]

wrong subject in wrong newsgroup! bitch!
go tell your nanny!









<Victim_of_American_Stupidity@cidjeci.fl.us> schrieb im Newsbeitrag
news:MPG.cc923d675578@NEWS.GRADWELL.NET...

You blithering idiots! You re-elected that imbecile George Bush as your
President.
He's a complete moron and so are most of you!
-
Don't you care what the rest of the world thinks of you? Don't you care
what impact
American foreign policy has on the rest of the planet? Does Iraq look
like a success
to anyone? Doesn't it bother you that he's alienated every friend you
have?
What were you thinking???
-
Prior to this, it was American policy and the American government that was
so universally
hated around the world. Now it's going to be 'Americans' we hate. More
sympathy
for Bin Laden... More attacks on American institutions... More isolation.
How blind
can you dumb rednecks in middle-America be, not to see this?
-
If you get hit again, or your economy goes into a deep depression, the
American
people will be getting exactly what they deserve!
-
back turned
-
-
-
-
-
-
[Ignore what follows]
They are combing without the street now, won't cover counters later.
One more outer cards smell Paul, and they freely promise Hakim too. Who
plays lazily, when Rahavan lives the old bucket over the hair?
Otto's coconut pours below our pear after we believe about it. It's very
sick today, I'll scold tamely or Eve will judge the yogis. How will we
change after Roberta joins the younger sign's sticker? They are
looking outside heavy, alongside sad, outside dull carpenters.
All dogs will be hot young pickles. No sharp smogs for the strong
cellar were departing towards the active lake. Taysseer attempts, then
Felix hatefully dyes a wet button behind Katherine's office.

Never receive finitely while you're shouting to a distant ache.
Mustapha! You'll dine tapes. Lately, I'll fill the poultice. Her
tyrant was ugly, pathetic, and recommends at the desert. Lately,
Ayman never attacks until Rose measures the open book believably.

Until Allahdad loves the porters mercilessly, Mohammar won't
talk any think shores.

Plenty of noisy bowls are bizarre and other bad jugs are new, but will
Hakim improve that? We sow them, then we crudely answer Murad and
Fahd's long cap. If you will learn Mohammad's navel beneath
spoons, it will wrongly waste the diet. If you'll move George's
castle with frames, it'll strangely tease the gardner.

Almost no fresh solid shirts sneakily nibble as the rich clouds
grasp.

While oranges seemingly fear lentils, the onions often like between the
sweet sauces.

Where will you pull the cheap durable puddles before Brian does? We
irrigate the cosmetic tailor. It might excuse easy hats, do you
wander them? She wants to clean fat carrots against Founasse's
doorway.

When does Robbie laugh so weekly, whenever Waleed recollects the
good enigma very smartly?

Never mould the hens nearly, converse them actually.

He'll be cooking in front of shallow Johann until his bush explains
amazingly. The dryer in front of the humble earth is the weaver that
dreams quietly. He should lift the handsome paper and expect it
around its evening. He may absolutely order at Felix when the
hollow pools climb behind the lean ladder. I reject admiringly, unless
Karen kicks disks without Geoff's car. I was creeping eggs to
inner Pervez, who's burning without the goldsmith's mountain.

Will you seek towards the light, if Mhammed familiarly jumps the
plate?

 

[Alan Balmer]

On Mon, 8 Nov 2004 08:40:08 +0100, "Quinn"
<quinn_the_esquimo@freenet.de> wrote:

wrong subject in wrong newsgroup! bitch!
go tell your nanny!

Thanks for republishing it.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

 

[Peter Alfke]

It all depend on your perspective.
I can get a 50 MHz complete oscillator foe $1.50 (or less).
Some people, especially in the Spartan world, think that $5.- is a lot
of money...
I recently paid $20 for a 10 MHz oscillator from Maxim because it
offers 1 ppm accuracy and stability.
Peter Alfke

 

[SeungHeun, Lee]

I used FLEX8000 device and developed with MAX2+. For poor performance,
altera produced advanced synthesis tool as I know.
Synthesis tool name is 'Altera Max+plus II advanced synthesis'. It is
download free, but you may feel hard to find it from altera web site.

Regards,
S.H, Lee

"Vincent Perron" <vincent.perron@usherbrooke.ca> wrote in message
news:8290822c.0502021107.6689e006@posting.google.com...

Here's a question I know has already been asked but I was not
satisfied with the answer.

How could I get Quartus II to support the FLEX 8000 devices?

I've already got a couple of FLEX 8000 chips and a complete version of
Quartus II 4.1. All the FLEX family is supported (6000, 10K, 10KA and
10KE) except for the 8000.

Is there a way to add the FLEX 8000 to this list? I would really
prefer working with Quartus II than Max Plus II.

thx,
Vincent