EDK : FSL macros defined by Xilinx are wrong

On Mar 13, 1:27 pm, FPGA <FPGA.unkn...@gmail.com> wrote:

I would like to simulate some modules in Verilog along with a FIFO
generated by ISE core. I would like to know if it is possible to
simuate teh Xilinx generated cores. If so, which tools do I need to
use for that? Is there a free Xilinx simulator I could use to sereve
the purpose? I was using Modelsim till date. I dont think Modelsim
would recognize the Xilinx cores.
Your comments would be appreciated.

Try this:
<http://www.google.com/search?q=simulating+xilinx+cores>

Look at the 2nd result (of the about 248,000 hits).

At that site, Xilinx will teach you how to simulate Xilinx cores using
the Xilinx version of Modelsim.

 

[Mike Treseler]

Timo Gerber wrote:

I want to launch Modelsim from within Xilinx EDK.

Click up a shell, bash or cmd.exe

mkdir play
cd play
vcom

If this doesn't give you the vcom usage,
type "exit" to close the shell,
find vcom, and add it's location
to your path and try again.

-- Mike Treseler

 

[Boudewijn Dijkstra]

Op Mon, 03 Dec 2007 18:27:50 +0100 schreef rickman <gnuarm@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.

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.


Since the overall system does not support
variable bitrates a faster transmission is no solution here.

So my idea was to put the question to all of you what to do in case of
uncompressibility? Any ideas?

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.

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

Possibly.

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/

 

[Symon]

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

"Marty Ryba" <martin.ryba.nospam@verizon.net> writes:


What does the Xilinx timing report say? Have you constrained the
clock correctly (or indeed at all ?

^^^

What he said.

Syms.

 

[Andy]

On Mar 20, 6:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

kennheinr...@sympatico.ca writes:
- Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their
LOCK output can assert even though the output clock is completely
unstable, or possibly just running at a harmonic, like half-rate.

Really!? What's the point of the LOCKED output then? Do that flaw not
make them a bit useless?

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

There are input clock specifications for which the the DCM operation
is guaranteed, including the operation of the locked signal. Violate
those specs, and the DCM is no longer guaranteed to function
"properly". This is no different than any other clocked electronic
device, and is far from rendering the device/function "a bit useless".

Andy

 

[Martin Thompson]

Andy <jonesandy@comcast.net> writes:

On Mar 20, 6:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
kennheinr...@sympatico.ca writes:
- Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their
LOCK output can assert even though the output clock is completely
unstable, or possibly just running at a harmonic, like half-rate.

Really!? What's the point of the LOCKED output then? Do that flaw not
make them a bit useless?

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

There are input clock specifications for which the the DCM operation
is guaranteed, including the operation of the locked signal. Violate
those specs, and the DCM is no longer guaranteed to function
"properly". This is no different than any other clocked electronic
device, and is far from rendering the device/function "a bit
useless".

Ahh, that makes more sense. I misunderstood the original statement to
be a bit wider than that!

Thanks,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

On Mar 20, 7:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

Really!? What's the point of the LOCKED output then? Do that flaw not
make them a bit useless?

That's kind of what I thought, too :-(

- Kenn

 

On Mar 20, 7:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

kennheinr...@sympatico.ca writes:
- Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their
LOCK output can assert even though the output clock is completely
unstable, or possibly just running at a harmonic, like half-rate.

Really!? What's the point of the LOCKED output then? Do that flaw not
make them a bit useless?

Cheers,
Martin

--
martin.j.thomp...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

I thought so, too :-( And in case anyone thinks I'm making this up,
see for example Xilinx answer record #9451 (Virtex-2), containing the
magic words:

"...the DLL will produce an unreliable lock signal and unreliable
output clock. To recover from this condition, the DLL must be manually
reset."

Or Answer record #30306 (Spartan):

"The LOCK output is to indicate when the DCM outputs are valid. In
some cases it may not go LOW to indicate the DCM has lost lock."

...and I'm sure there are many others.

This is not an attempt to slag Xilinx, I'm just pointing out something
to watch for. It's an instance of one of my pet peeves, that in
99.999 percent of cases, an analog "thing" (like locked-ness, or
signal level, or sync pulse detection, or what have you) gets done
wrong up (often by design oversimplifications) when translated into a
digital "true/false" output. PLL lock signals are classic examples,
as are the outputs of video sync separators.

This is digressing from pure VHDL, so I'll stop while I'm ahead.

- Kenn

 

[dalai lamah]

Un bel giorno MM digitň:

I was wondering if there is a good VHDL document generation utility (free or
not) out there? I stumbled across an article describing HDLDoc by DualSoft,
which seemed promising, but it seems that that company ceased to exist... I
am looking for something that would be more than just a comments
extractor...

The almighty Doxygen now supports also VHDL:

http://www.stack.nl/~dimitri/doxygen/
http://www.stack.nl/~dimitri/doxygen/docblocks.html#vhdlblocks

--
emboliaschizoide.splinder.com

 

[John_H]

Kevin Neilson wrote:

mk wrote:
On Fri, 28 Mar 2008 11:14:23 -0700 (PDT), FPGA
FPGA.unknown@gmail.com> wrote:

what does the following code do
output <= input[x*-1 -: y];

That's called an indexed part select. The first expression signifies
base and the second expression signifies width. It the sign is + it's
an ascending select if it's negative it's a descending select. Your
example is equivalent to input[x*-1: x*-y] ie you need to
subtract (y-1) from the base to get the lower index.

I think your equivalent should be: input[x*-1: x*-y+1]

If I remember correctly, the width has to be a constant. In this case
that would mean y could be a parameter, but not an integer or register.
-Kevin

The y that follows the indexed part select operator is the width. The
vector mk showed has a width of y bits which is accurate. The vector
Kevin showed has a width of y-1 bits which is inaccurate. Use mk's
suggestion.

Oh, and invest in a Verilog-2001 reference.

Also - I removed the cross-post to comp.lang.vhdl because this is
VERILOG! The VHDL abbreviations doesn't mean "Verilog Hardware
Description Language." You can go to comp.lang.verilog for Verilog issues.

- John_H

 

[FPGA]

On Mar 29, 12:18 am, John_H <newsgr...@johnhandwork.com> wrote:

Kevin Neilson wrote:
mk wrote:
On Fri, 28 Mar 2008 11:14:23 -0700 (PDT), FPGA
FPGA.unkn...@gmail.com> wrote:

what does the following code do
output <= input[x*-1 -: y];

That's called an indexed part select. The first expression signifies
base and the second expression signifies width. It the sign is + it's
an ascending select if it's negative it's a descending select. Your
example is equivalent to input[x*-1: x*-y] ie you need to
subtract (y-1) from the base to get the lower index.

I think your equivalent should be:  input[x*-1: x*-y+1]

If I remember correctly, the width has to be a constant.  In this case
that would mean y could be a parameter, but not an integer or register.
-Kevin

The y that follows the indexed part select operator is the width.  The
vector mk showed has a width of y bits which is accurate.  The vector
Kevin showed has a width of y-1 bits which is inaccurate.  Use mk's
suggestion.

Oh, and invest in a Verilog-2001 reference.

Also - I removed the cross-post to comp.lang.vhdl because this is
VERILOG!  The VHDL abbreviations doesn't mean "Verilog Hardware
Description Language."  You can go to comp.lang.verilog for Verilog issues.

- John_H- Hide quoted text -

- Show quoted text -

Thanks always for your valuable help.

 

[KJ]

"benn" <benn686@hotmail.com> wrote in message
news:9778f926-8359-4310-a9bd-1ec3c9d0fabf@u36g2000prf.googlegroups.com...

I'm pretty new to fpgas, but theres an i2c core on opencores.org that
I'd like to use in my Altera project. I understand Wishbone is a
subset of Avalon, but what is involved in bridging these two together?

Not much, they have different names for the signals and that's most of the
differences. Functionally they are almost the same.

I'm assuming its not too trivial since I could buy an IP bridge that
does it from Men Micro, but what exactly is involved if I were to try
tackling this myself?

Businesses are in business to sell, whether it's easy or hard doesn't
matter, there is still $$ to be made. To roll your own...

1. Take a look at the I2C core to see which types of transactions it handles
(most likely it's a slave with only simple read and writes with a ready
signal to hold things off).
2. Read through the Wishbone spec to get an understanding of the types of
transactions that can be performed, but paying more attention to the subset
of ones that the I2C core actually uses.
3. Repeat step 2 but reading the Avalon spec, making note of the
differences. As I mentioned at the start, you'll probably find that signal
names are darn near the only differences.
4. Take a day or so and write the couple lines of code that it takes to
create an entity/architecture that has Wishbone names on one side, Avalon on
the other. Write a testbench and see that it seems to work, hook up the I2C
core to the Wishbone side and see if that works then start integrating the
bridge and I2C core into your main design.

The water is not too deep in making such a bridge, 'specially when narrowing
it down to a particular Wishbone component. Once you've done it for one
component, you'll probably find that it's also not too difficult to
generalize the bridge to handle more generic Wishbone components and still
you'll find that it's not terribly difficult.

Kevin Jennings

 

[Symon]

<jamicrotech@gmail.com> wrote in message
news:3234335a-7821-41f1-b69d-fa6dcad78e68@q1g2000prf.googlegroups.com...

Hi,
I am using virtex4 device for my designs. In timing analysis i
found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is
that a way , i can reduce this gate delay by giving some constraints.
ie is to reduce the gate delay by tools .

In your .ucf file try something like this:-

NET "I_CANT_BE_BOTHERED_TO_RTFM" SLEW=FAST;

Or, better still, read the constraints guide.

HTH., Syms.

 

[Symon]

<jamicrotech@gmail.com> wrote in message
news:3234335a-7821-41f1-b69d-fa6dcad78e68@q1g2000prf.googlegroups.com...

Hi,
I am using virtex4 device for my designs. In timing analysis i
found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is
that a way , i can reduce this gate delay by giving some constraints.
ie is to reduce the gate delay by tools .

In your .ucf file try something like this:-

NET "I_CANT_BE_BOTHERED_TO_RTFM" SLEW=FAST;

Or, better still, read the constraints guide.

HTH., Syms.

 

[Symon]

"Symon" <symon_brewer@hotmail.com> wrote in message
news:ftfp5l$4go$1@aioe.org...

jamicrotech@gmail.com> wrote in message
news:3234335a-7821-41f1-b69d-fa6dcad78e68@q1g2000prf.googlegroups.com...
Hi,
I am using virtex4 device for my designs. In timing analysis i
found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is
that a way , i can reduce this gate delay by giving some constraints.
ie is to reduce the gate delay by tools .



In your .ucf file try something like this:-

NET "I_CANT_BE_BOTHERED_TO_RTFM" SLEW=FAST;

Or, better still, read the constraints guide.

HTH., Syms.


....oh, and changing the drive strength will also affect the output delay.

This can also be set by a UCF constraint. You've read DS302, right?
HTH., Syms.

 

[David Spencer]

Hi,

Yes, you can work with internal ram only.
Yes you can store program in configuration memory used for FPGA.

I tested.

Adam

Or you can store the program in internal RAM (functioning as ROM) too for a
fully self-contained system. To make this easier, there is a mechanism to
update the RAM initialization contents without needing to do a full
re-synthesis and PAR each time.

If you use SOPC Builder it is trivial to set this up.

 

[Alvin Andries]

"VIPS" <thevipulsinha@gmail.com> wrote in message
news:37d9abbf-eb08-490b-b176-40c4c9b07a26@k13g2000hse.googlegroups.com...

Hi All

This application I am looking at requires 17 tera bytes of
multiplication per second. Which in an FPGA means 40K FPGAs. What I
want to know is how many 32x32 Mults can you fit into an ASIC today
Standard Cell or Custom ASIC. Also what kind of speeds can I get.

Assuming that you mean 17 10^12 multipliers?

With a 90nm process you can get quite a few in a standard cell ASIC. But
without further explanation, I would say that speed per multiplier will be
dreadfull: you won't be able to get that much data on and off a single chip
(I/O limitations). So you may stick to an FPGA as well (saves you time and
risk, read on).

As for your FPGA count: you need 3 DSP48 blocks on a Xilinx device or 1
32x32 multiplier on an Altera device. The DSP48s go up to 550MHz, for the
Altera part, I don't know.

But: 3 * (17 10^12 / 550 10^6) = +/- 92800 DSP48 resources. Since there are
more than 100 of these in the larger V5 SX(T) devices (too lasy to look up
the exact number), you will end up with quite a bit less than 1000 FPGAs.

Still, you need to look at your I/O, power, algorithm, costs, etc. to get
the whole picture.

Regards,
Alvin.

 

[Alvin Andries]

"VIPS" <thevipulsinha@gmail.com> wrote in message
news:37d9abbf-eb08-490b-b176-40c4c9b07a26@k13g2000hse.googlegroups.com...

Hi All

This application I am looking at requires 17 tera bytes of
multiplication per second. Which in an FPGA means 40K FPGAs. What I
want to know is how many 32x32 Mults can you fit into an ASIC today
Standard Cell or Custom ASIC. Also what kind of speeds can I get.

Assuming that you mean 17 10^12 multipliers?

With a 90nm process you can get quite a few in a standard cell ASIC. But
without further explanation, I would say that speed per multiplier will be
dreadfull: you won't be able to get that much data on and off a single chip
(I/O limitations). So you may stick to an FPGA as well (saves you time and
risk, read on).

As for your FPGA count: you need 3 DSP48 blocks on a Xilinx device or 1
32x32 multiplier on an Altera device. The DSP48s go up to 550MHz, for the
Altera part, I don't know.

But: 3 * (17 10^12 / 550 10^6) = +/- 92800 DSP48 resources. Since there are
more than 100 of these in the larger V5 SX(T) devices (too lasy to look up
the exact number), you will end up with quite a bit less than 1000 FPGAs.

Still, you need to look at your I/O, power, algorithm, costs, etc. to get
the whole picture.

Regards,
Alvin.

 

jjlindula@hotmail.com <jjlindula@hotmail.com> wrote:

Hello, I need a PCI Express application and I could find a vendor that
sells PCI Express cards and add in my design to the FPGA or I could
design my own PCI Express card from the ground up. I decided to buy an
evaluation card from PLDA and see if I could get things going from
their design. I am new to the PCI Express bus protocol and wanted to
find a vendor that would make working with PCIe very easy. Does anyone
have experience with PLDA? Or, perhaps could recommend another company
that is Altera based. I visited Altera's web site and they have a PCIe
evaluation card and have thought about using their product because of
their excellent support.

Check with:
enterpoint.co.uk
digilent.com

 

jjlindula@hotmail.com <jjlindula@hotmail.com> wrote:

Hello, I need a PCI Express application and I could find a vendor that
sells PCI Express cards and add in my design to the FPGA or I could
design my own PCI Express card from the ground up. I decided to buy an
evaluation card from PLDA and see if I could get things going from
their design. I am new to the PCI Express bus protocol and wanted to
find a vendor that would make working with PCIe very easy. Does anyone
have experience with PLDA? Or, perhaps could recommend another company
that is Altera based. I visited Altera's web site and they have a PCIe
evaluation card and have thought about using their product because of
their excellent support.

Check with:
enterpoint.co.uk
digilent.com