EDK : FSL macros defined by Xilinx are wrong

[Nico Coesel]

fazulu deen <fazulu.vlsi@gmail.com> wrote:

Hai all,

Is there any formula to calculate processor clock cycles per
Instructions with given parameters as FPGA implemented processor clock
frequency and instruction bytes...

pls suggest..

No, this depends entirely on the architecture of the processor. Some
processors may require 1 clock cycle for 1 instruction, others may
need a variable number of clock cycles.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

 

[comp.arch.fpga]

On 4 Dez., 09:39, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:

Op Mon, 03 Dec 2007 18:27:50 +0100 schreef rickman <gnu...@gmail.com>:



On Dec 3, 4:14 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
Op Thu, 29 Nov 2007 15:42:45 +0100 schreef Denkedran Joe
denkedran...@googlemail.com>:

I'm working on a hardware implementation (FPGA) of a lossless
compression
algorithm for a real-time application. The data will be fed in to the
system, will then be compressed on-the-fly and then transmitted
further.

The average compression ratio is 3:1, so I'm gonna use some FIFOs of a
certain size and start reading data out of the FIFO after a fixed
startup-time. The readout rate will be 1/3 of the input data rate The
size
of the FIFOs is determined by the experimental variance of the mean
compression ratio. Nonetheless there are possible circumstances in
which
no compression can be achieved.

Given that uncompressible data often resembles noise, you have to ask
yourself: what would be lost?

The message! Just because the message "resembles" noise does not mean
it has no information. In fact, just the opposite.

If you are compressing reliably transmitted pure binary data, then you are
absolutely right. But if there is less information per datum, like in an
analog TV signal, something that resembles noise might very well be noise.

The algorithm is either lossless, or it isn't. Identifying and
removing the noise is
exactly what a lossy algortihm does.
For any lossless algorithm there must be an input that produces an
output at
least the size of the input. The proof is rather simple. You just
count the number of possible
inputs (2^N for N bits) and the number of bits necessary to
distinguish that many different outputs.
(That's N bits, surprise). With less bits two inputs would code to the
same output.

To guarantee compression for a lossless algorithm therefore is only
possible if most input sequences
can't occcur. If you can guarantee that half of the input combinations
can't happen you could
guarantee to save a single bit.

Cases where that occurs is image half toning with a fixed frequency.
In that case you have a worst
case run length distribution .

Kolja Sulimma

 

[Jim Granville]

Michael Laajanen wrote:

Hi,

Is there anyone that has XABEL for Sun available, due to some internal
mess we have managed to loose our old XABEL installation.

It was used with XACT 5.2.1 and Viewlogic powerview which we still have
along with licenses for XABEL only the distribution CD is missing.

/michael

Have you asked Xilinx ? - give them some Date codes, for the other
stuff, so they know which dusty store-room to look in.

-jg

 

[Michael Laajanen]

Hi,

Jim Granville wrote:

Michael Laajanen wrote:

Hi,

Is there anyone that has XABEL for Sun available, due to some internal
mess we have managed to loose our old XABEL installation.

It was used with XACT 5.2.1 and Viewlogic powerview which we still
have along with licenses for XABEL only the distribution CD is missing.

/michael


Have you asked Xilinx ? - give them some Date codes, for the other
stuff, so they know which dusty store-room to look in.

-jg

I have tried our local Xilinx but this predates most people that works

there

I can try and contact Xilinx in USA and see, will do.

/michael

 

[Boudewijn Dijkstra]

Op Tue, 04 Dec 2007 17:50:46 +0100 schreef rickman <gnuarm@gmail.com>:

On Dec 4, 3:39 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
Op Mon, 03 Dec 2007 18:27:50 +0100 schreef rickman <gnu...@gmail.com>:

On Dec 3, 4:14 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
...snip...
Given that uncompressible data often resembles noise, you have to ask
yourself: what would be lost?

The message! Just because the message "resembles" noise does not mean
it has no information. In fact, just the opposite.

If you are compressing reliably transmitted pure binary data, then you
are
absolutely right. But if there is less information per datum, like in
an
analog TV signal, something that resembles noise might very well be
noise.

But noise and signal that "resembles noise" are two different things.
You can characterize noise and send a description of it. But it is
*isn't* noise you have just turned part of your signal into noise. So
to take advantage of the fact that noise can be compressed by saying
"this is noise" requires that you separate the noise from the signal.
If you could do that, why would you even transmit the noise? You
wouldn't, you would remove it.

If you could, yes. Costs put limits on the available processing power.

So the only type of "noise like" signal left is the part that *is*
signal and the part that can't be separated from the signal. Since
you can't distinguish between the two, you have to transmit them both
and suffer the inability to compress them.


Once you have a
message with no redundancy, you have a message with optimum
information content and it will appear exactly like noise.

Compression takes advantage of the portion of a message that is
predictable based on what you have seen previously in the message.
This is the content that does not look like noise. Once you take
advantage of this and recode to eliminate it, the message looks like
pure noise and is no longer compressible. But it is still a unique
message with information content that you need to convey.

...snip...

If you can identify the estimated compression beforehand and then
split
the stream into a 'hard' part and an 'easy' part, then you have a
way to
retain the average.

Doesn't that require sending additional information that is part of
the message?

Usually, yes.

How can you flag the "easy" (compressible) part vs. the "hard" part
without sending more bits?

In the context of the OP's hardware implementation, you may be able to
distribute these two streams over the available output pins without
sending extra bits.

On the average, this will add as much, if not more to
the message than you are removing...

Possibly.

As I describe below, compression only saves bits if your *average*
content has sufficient redundancy. So what does "possibly" mean?

If compression saves 'a lot of' bits ands flagging needs 'a few' bits,
then it will not "add as much, if not more to the message than [I am]
removing..." Your description below only applies to certain compression
algorithms, so any conclusion derived from it may or may not apply to the
general case.

If you are trying to compress data without loss, you can only compress
the redundant information. If the message has no redundancy, then it
is not compressible and, with *any* coding scheme, will require some
additional bandwidth than if it were not coded at all.

Think of your message as a binary number of n bits. If you want to
compress it to m bits, you can identify the 2**m most often
transmitted numbers and represent them with m bits. But the remaining
numbers can not be transmitted in m bits at all. If you want to send
those you have to have a flag that says, "do not decode this number".
Now you have to transmit all n or m bits, plus the flag bit. Since
there are 2**n-2**m messages with n+1 bits and 2**m messages with m+1
bits, I think you will find the total number of bits is not less then
just sending all messages with n bits. But if the messages in the m
bit group are much more frequent, then you can reduce your *average*
number of bits sent. If you can say you will *never* send the numbers
that aren't in the m bit group, then you can compress the message
losslessly in m bits.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/

 

[comp.arch.fpga]

On 5 Dez., 09:57, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:

Your description below only applies to certain compression
algorithms, so any conclusion derived from it may or may not apply to the
general case.
ROTFL.

Did you even read it?
He outlined the formal prove that I was referencing to in a little
more detail.

This proof shows, that for ANY lossless algorithm there is an input
that can't be
compressed. I find it rather funny that you counter that proof by the
assertion
that it only applies to certain algorithms.

For the fun of it: Would you be so kind and present a single example
of a compression
algorithm that the proof does not apply to? Could be worth a PhD if
you manage.

Kolja Sulimma

 

[Boudewijn Dijkstra]

Op Wed, 05 Dec 2007 10:46:03 +0100 schreef comp.arch.fpga
<ksulimma@googlemail.com>:

On 5 Dez., 09:57, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
Your description below only applies to certain compression
algorithms, so any conclusion derived from it may or may not apply to
the
general case.
ROTFL.
Did you even read it?

Yes. Multiple times.

He outlined the formal prove that I was referencing to in a little
more detail.

This proof shows, that for ANY lossless algorithm there is an input
that can't be
compressed. I find it rather funny that you counter that proof by the
assertion that it only applies to certain algorithms.

I didn't mean to counter the proof itself, only claims to the relation
between compression ratio and the bandwidth needed to split a stream.

For the fun of it: Would you be so kind and present a single example
of a compression
algorithm that the proof does not apply to? Could be worth a PhD if
you manage.

Nah. I'd rather waste my time on something else.



--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/

 

[rickman]

On Dec 5, 3:57 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:

Op Tue, 04 Dec 2007 17:50:46 +0100 schreef rickman <gnu...@gmail.com>:

But noise and signal that "resembles noise" are two different things.
You can characterize noise and send a description of it. But it is
*isn't* noise you have just turned part of your signal into noise. So
to take advantage of the fact that noise can be compressed by saying
"this is noise" requires that you separate the noise from the signal.
If you could do that, why would you even transmit the noise? You
wouldn't, you would remove it.

If you could, yes. Costs put limits on the available processing power.

That is irrelevant to the conversation. No one has mentioned data
rates, processing power or time requirements. So there is no point is
raising issues that we have no information on. But my point remains.
If your algorithm can remove the true noise separated from signal that
looks like noise, then you would just toss the real noise and improve
the signal while compressing at the same time. That is my point and
from what you have said, it requires no extra processing, but is part
of your compression.

How can you flag the "easy" (compressible) part vs. the "hard" part
without sending more bits?

In the context of the OP's hardware implementation, you may be able to
distribute these two streams over the available output pins without
sending extra bits.

If the OP has two streams, one for compressible signal and one for
uncompressible signal, then he could just send the original message
over the uncompressible channel and avoid the issue of compression
altogether.

As I describe below, compression only saves bits if your *average*
content has sufficient redundancy. So what does "possibly" mean?

If compression saves 'a lot of' bits ands flagging needs 'a few' bits,
then it will not "add as much, if not more to the message than [I am]
removing..." Your description below only applies to certain compression
algorithms, so any conclusion derived from it may or may not apply to the
general case.

Compression can only save bits in the subset of signals that actually
are reducible. If you do the math you will find that if the signal is
randomly distributed, any coding scheme can not reduce the total
number of bits sent. It is only when some signal patterns are more
frequent than others that you can exploit the non-randomness of the
signal to compress it into fewer bits.

I haven't said anything about algorithms, so everything I have said on
this applies to *all* compression algorithms. My discussion below is
intended to apply to the general case. That is why I reduce the
discussion to one of compressing a large number to a smaller number.

If you are trying to compress data without loss, you can only compress
the redundant information. If the message has no redundancy, then it
is not compressible and, with *any* coding scheme, will require some
additional bandwidth than if it were not coded at all.

Think of your message as a binary number of n bits. If you want to
compress it to m bits, you can identify the 2**m most often
transmitted numbers and represent them with m bits. But the remaining
numbers can not be transmitted in m bits at all. If you want to send
those you have to have a flag that says, "do not decode this number".
Now you have to transmit all n or m bits, plus the flag bit. Since
there are 2**n-2**m messages with n+1 bits and 2**m messages with m+1
bits, I think you will find the total number of bits is not less then
just sending all messages with n bits. But if the messages in the m
bit group are much more frequent, then you can reduce your *average*
number of bits sent. If you can say you will *never* send the numbers
that aren't in the m bit group, then you can compress the message
losslessly in m bits.

--
Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/

 

[koce]

Can U, please, send me a byteblasterII schematic file if U have it.
Thank U!
Bojan

--
Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/
More information at http://www.talkaboutelectronicequipment.com/faq.html

 

[comp.arch.fpga]

On 16 Dez., 16:11, westsp...@gmail.com wrote:

Hi,all.I am doing a project which will implement SAS with FPGAs on
Xilinx Virtex 4 ML405 board. But before I am a software designer and
never do IC design before ,so this project is very difficult for
me.Who could help me and give me some guidances or some datum and
paper about how to implement SAS with FPGAs.I will be very
grateful.Thanks very much.

You are not talking about the airline, are you?

If not, lease check all that apply:
You want ot build an:
a) Safety and Automation System
b) Synthetic Aperture Sonar
c) beam forming circuitry for Small-Angle Scattering
d) Slot Accounting System

a) will be easist, c) requires a lot of additional hardware not found
on an ML405, a) should not be build by a novice. b) probably is the
best match for an ML405.


Kolja Sulimma

 

[Rube Bumpkin]

comp.arch.fpga wrote:

On 16 Dez., 16:11, westsp...@gmail.com wrote:
Hi,all.I am doing a project which will implement SAS with FPGAs on
Xilinx Virtex 4 ML405 board. But before I am a software designer and
never do IC design before ,so this project is very difficult for
me.Who could help me and give me some guidances or some datum and
paper about how to implement SAS with FPGAs.I will be very
grateful.Thanks very much.

You are not talking about the airline, are you?

If not, lease check all that apply:
You want ot build an:
a) Safety and Automation System
b) Synthetic Aperture Sonar
c) beam forming circuitry for Small-Angle Scattering
d) Slot Accounting System

a) will be easist, c) requires a lot of additional hardware not found
on an ML405, a) should not be build by a novice. b) probably is the
best match for an ML405.


Kolja Sulimma

I think the OP probably means Serial Attached SCSI, which is very close
to SATA.

Depending on the speeds involved, 1.5G or 3G, this may not be an
appropriate first project.

RB

 

[A. M. G. Solo]

Otherwise the lover in Steve's output might install some busy
lunchs.

They are threatening by means of the commission now, won't modify
pubs later. No rear thiefs feel Henry, and they undoubtedly
convince Salahuddin too. We remove the minimal revision. My
changing rib won't dedicate before I rest it. Hardly any purple
exotic wheat minds costs in touch with Abdul's popular camera.
Cypriene entitles, then Talal similarly changes a likely total
in general Jonas's calendar. Lots of cars will be giant missing
branchs. Let's squeeze by the remote walls, but don't confirm the
desperate styles. You won't tighten me preaching between your
nineteenth-century project. Are you passing, I mean, disliking
such as classical cautions? She may under situate in line with
involved wooden mills. Her discourse was immediate, original, and
defends no longer the lecture. Will you provide near the department, if
Elisa obediently features the shortage? Just questioning in connection with a
leave down the senate is too precise for Osama to sleep it.
Every hollow cold operas will better enclose the englishs.

A lot of particular inputs are humble and other acceptable grades are
remaining, but will Hamza sum that? Better encourage presidents now or
Eddie will loudly sue them on the part of you. I am particularly
alive, so I compare you. Who will you cool the unlikely productive
mills before Marwan does?

You attract wise alcohols, do you survive them?

 

[RCIngham]

Dear All,
As an assignment I have to design a CCD Sensor based FPGA digital
Camera. However, the Camera will be exposed to XRAY (It will be placed
behind an Imaging Intensifier). Does anybody know how XRAY affects the
electronic circuits (The CCD Sensor and the FPGA ). What type of noise
should I expect and what should I do to prevent it.
Thanks in advance

How about:
http://www.google.com/search?hl=en&q=%22effects+of+x-rays%22+%22electronic+circuits%22

Advice - buy "Space Class" devices. This will probably be from Actel.

 

[Symon]

"John_H" <newsgroup@johnhandwork.com> wrote in message
news:tJmdnUfZyuv8_BLanZ2dnUVZ_tjinZ2d@comcast.com...

recoder wrote:
Dear All,
As an assignment I have to design a CCD Sensor based FPGA digital
Camera. However, the Camera will be exposed to XRAY (It will be placed
behind an Imaging Intensifier). Does anybody know how XRAY affects the
electronic circuits (The CCD Sensor and the FPGA ). What type of noise
should I expect and what should I do to prevent it.
Thanks in advance

Ever consider using a phosphor plate to turn the x-rays into visible light
first?

Hi John,
I guess that's what the OP means.
http://en.wikipedia.org/wiki/X-ray_image_intensifier
Maybe! I would've thought that would stop the X-rays. I guess Austin will
give his SEU spiel soon. That'll teach the OP! ;-)
Cheers, Syms.

 

Is there a relevant web site to which you can direct us?




On Thu, 17 Jan 2008 06:34:37 -0800 (PST), tutorialwebs
<Webmaster.Pixindia@gmail.com> wrote:

tutorials textbooks,ebooks,seminar topics,seminars,visit
http://tutorialweb.50webs.com/


tutorial text books
* Applied Cryptograph * VB Script text boo
* java script text book
* CGI Programming text book

http://tutorialweb.50webs.com/

* java text book
* Programmer's Guide Nokia WAP Server API 1
* aptitude questions (48 pages)
* HR Interview Questions


http://tutorialweb.50webs.com/


http://tutorialweb.50webs.com/
Seminar topics

1. BLUETOOTH BASED SMART SENSOR NETWORKS(5 pages)
2. BORDER SECURITY USING WIRELESS INTEGRATED NETWORK SENSORS (WINS)
(5 pages)

http://tutorialweb.50webs.com/

3. Digital Theatre System (10 pages)
4. GSM SECURITY AND ENCRYPTION (7 pages)
5. INDUSTRIAL APPLICATIONS USING NEURAL NETWORKS (4 pages)
6. Quantum Computing (6 pages)

http://tutorialweb.50webs.com/

7. thin display technology (9 pages)
8. WIRELESS INTERNET ACCESS 3G VS WiFi (5 pages)
9. WIRELESS TECHNOLOGY - BLUETOOTH (4 pages)
10. WIRELESS FIEDELITY [WI-FI] (8 pages)

http://tutorialweb.50webs.com/

11. OPTICAL MOUSE (4 Pages)
12. Smart bombs 1(6 pages)
13. Air powered cars (8 pages)

http://tutorialweb.50webs.com/

14. ATM & WIRELESS ATM(WATM) (7 pages)
15. Communication Onboard High Speed Public Transport Systems (9
pages)
16. Interactive Voice Response System (6 pages)

http://tutorialweb.50webs.com/

17. Evolution of Embedded System (4pages)
18. FIBER - OPTIC TECHNOLOGY (7 pages)
19. General Packet Radio Service (GPRS) (8 pages)
20. all about global positioning system(gps) (12 pages)

http://tutorialweb.50webs.com/

 

[austin]

X-ray,

Has no effect on the device, except that (eventually) the total dose
will accumulate, and the Vt of the devices will begin to shift, and
eventually, the device will fail.

This is unlike a CCD, which may register 'hits' and display noise.

Only neutrons, or protons, with LET of 1 Mev have enough energy to
create charge clouds, and change bits:

http://www.xilinx.com/products/silicon_solutions/market_specific_devices/aero_def/capabilities/aero_def_app.htm

Contact your local Xilinx FAE to find out about X-Ray dose (how long it
can "take it.").

At some dose level, that usage becomes ITAR restricted (people use stuff
this hard to build nuclear bombs, or operate in the presence of nuclear
explosions) so you will no longer be able to buy, or use, such parts,
unless the US State Department permits you to do so.

I suspect for your application, our commercial parts are more that
"hard" enough.

X-rays, after all, are just photons, and they just do not pack enough
energy to affect even the MGTs in our parts, and certainly do not affect
the logic and memory.

Austin

 

[austin]

Spiel?

X-rays are just wimpy little photons ....

SEUs are caused by cosmic rays (heavy ions, like iron, gold, etc with
LET's of > 100 MeV) that create neutron showers with energies beyond
1000 MeV.

Austin

 

[xiaoxiao008]

hey, there. do you have the IP code for Ultra DMA with FPGA. I am doing the
project for this implementation.. hope you would be kind to help.
thank you.

XiaoXiao

--
Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/
More information at http://www.talkaboutelectronicequipment.com/faq.html

 

[Jonathan Bromley]

On Fri, 25 Jan 2008 06:44:10 -0800 (PST),
Ann <thakkar.anuja@gmail.com> wrote:

I just found out that I need random number generator just for
simulation. I do not need to synthesize it. Some feedback on this
would be helpful. I am having a look at some of the links posted here.

OK, that's easy. The math_real package contains an excellent
random number generator that you can adapt for your own purposes.

use ieee.math_real.all;
...
process
variable R: real;
variable S1, S2: positive := 42;
--- seed variables, change initialization to
--- get a different random number stream
begin
...
uniform(S1, S2, R);
...

This modifies seed variables S1 and S2 ready for the
next call to uniform() - DON'T DO ANYTHING ELSE with
these two variables. And it also puts a random number
into R, uniformly distributed in the real range 0.0 to
0.99999...; you can then very easily scale this
number to get whatever you want. A couple of examples:

--- Get the integer value "5" with 20% probability,
--- and "7" with 80% probability
if R < 0.2 then
x := 5;
else
x := 7;
end if;
---
--- Get an integer in the range LO to HI (where LO, HI
--- are both integers and LO<=HI)
R := R * real(HI-LO) + real(LO);
x := integer(floor(R));

HTH
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Fri, 25 Jan 2008 15:13:14 +0000,
Jonathan Bromley wrote:

OK, that's easy.

Not so easy, it seems: apologies for this
off-by-one error...

--- Get an integer in the range LO to HI (where LO, HI
--- are both integers and LO<=HI)
R := R * real(HI-LO) + real(LO);

That should be
R := R * real(HI+1-LO) + real(LO);

Sorry
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.