EDK : FSL macros defined by Xilinx are wrong

Symon wrote:

Do you have any examples of any 'proper' CAM devices that I can research? I
know that Altera's ESBs can be used as small CAMs, and that Xilinx have an
app. note design that can do single cycle reads and multi-cycle writes using
a BlockRAM. It would appear that Micron have dumped their 2Mb 'Harmony'
device long ago. I found various dead links to products, but nothign active.
Click to expand...
Useful CAM structures don't fit well in FPGAs
and the vendors have quit trying.
Some sort of hash table may be a better fit.
http://en.wikipedia.org/wiki/Hash_table

-- Mike Treseler
 
Mike Treseler wrote:

Useful CAM structures don't fit well in FPGAs
and the vendors have quit trying.
Some sort of hash table may be a better fit.
http://en.wikipedia.org/wiki/Hash_table
Click to expand...
Or systolic array if you are doing many such searches
at the same time.

http://en.wikipedia.org/wiki/Systolic_array

-- glen
 
*Ihan kiva ja asiantunteva firmarypästiedote lopussa!
______________________________________

[Heikki Jaakkola, Energia, 02.06.2008] Lisää aurinkosähköä samalla
rahallaAurinkosähkön suuri ongelma on hyvin tiedossa.------- Ongelmasta
yritetään irrottautua valoa keskittävillä ratkaisuilla. Valo kootaan näissä
tehokkaasti hyvin pienelle alueelle, mikä voi vähentää piimateriaalin
tarvetta jopa tuhannesosaan entisestä. Tämä mahdollistaa piin ohella myös
muiden tehokkaiden, mutta kalliiden erikoismateriaalien käytön.

Keskittävistä aurinkosähköstä eli CPV-järjestelmistä kiinnostuneen kannattaa
matkustaa nyt Espanjan Castilla la Manchaan. Paikkakunnalle rakennetaan
ISFOC-nimisessä projektissa koealuetta, jossa testataan seitsemää erilaista
keskittävää valosähköjärjestelmää. Nämä tuottavat sähköä yhteensä kolmen
megawatin teholla. Projektia rahoittaa Espanjan valtio, joka haluaa kehittää
La Manchan alueesta CPV:n maailmanlaajuisen osaamiskeskuksen.

Espanjassa on käytössä syöttötariffijärjestelmä, jonka ansiosta kokeilun
yhteydessä tuotettu sähkö voidaan myydä takuuhinnalla verkkoon. Tämä on
osaltaan tehnyt teollisen mittakaavan kokeilun taloudellisesti
mahdolliseksi. Hankkeessa ovat mukana espanjalainen Isofoton, saksalainen
Concentrix Solar sekä kalifornialainen SolFocus. Sekä Solfocus että
Concentrix toimittavat paikalle 500 kilowatin laitteistot.

Tavoitteena on, että nyt rakennettavat demonstraatiolaitokset antaisivat
näyttöä eri teknologioiden luotettavuudesta ja käyttökelpoisuudesta niin,
että teollisuuden olisi helpompi ryhtyä omiin keskittävää valosähköä
hyödyntäviin pilottiprojekteihinsa. Linssejä ja heijastavia pintoja Valon
keskittäminen tapahtuu linssien tai heijastavien pintojen avulla.

Concentrix Solar tukeutuu Fresnel-linsseihin. Nämä ovat alkujaan majakoita
varten suunniteltuja linssejä, jotka eivät muodosta tarkkaa kuvaa, mutta
toimivat erittäin tehokkaasti valon keskittäjinä. Yrityksen
aurinkopaneeleissa linssit keskittävät valon intensiteetin 500-kertaiseksi
verrattuna tilanteeseen ilman linssiä. Valoalueelle voidaan asentaa
päällekkäin kaksi tai kolmekin eri puolijohdemateriaaleista valmistettua
aurinkokennoa, jotka hyödyntävät valon eri aallonpituuksia. Valmistajan
mukaan näin voidaan saavuttaa jopa yli 35 prosentin hyötysuhde valon
muuttamisessa sähköksi.

*Hupaisan korkea hyötysuhde muuten ylittää heittämällä ydinvoimareaktorille
tuskin saavutusmaksimin vuosipysyvyyshyötysuhteen 25%. Täällä muistaakseni
haahuiltiin jostain 10%katosta osaamattomilta aurinkofakiireilta taannoin?)

SolFocus perustaa ratkaisunsa valon keräämiseen ja heijastamiseen kennoon
alumiinipeilin avulla. Kenno on samalla koteloitu lasin ja alumiinin sisään,
mikä vähentää sen likaantumista ja kulumista käytössä. Järjestelmää
markkinoidaankin luotettavuudella. Myös SolFocuksen ratkaisu keskittää valoa
500-kertaisesti. Se lieneekin jonkinlainen raja-arvo, jonka jälkeen
kuumenemisen hallintaan ei enää riitä passiivinen jäähdytys.


Olennainen osa SolFocuksen järjestelmää ovat myös ohjelmistot ja mekaniikka,
jotka suuntavat paneelin jatkuvasti kohti aurinkoa siten, että ne seuraavat
auringon liikettä taivaalla. Suuntauksen luotettavuus ja tarkkuus ovatkin
olennainen edellytys aurinkopaneelien tehokkuudelle. Nämä ominaisuudet
ovatkin samalla ehkä kuviteltua isompi tekninen haaste. SolFocuksen
paneelielementit on kiinnitetty maston päässä olevaan neliömäiseen tasoon.
Yritys itse vakuuttaa älykkäästi suuntautuvan järjestelmän olevan erittäin
tarkka, liikkuva ja samalla kestävä vaativassakin ympäristössä.
Automaattisesti suuntautuvat telineet lisännevät kuitenkin selvästi
järjestelmän kustannuksia. Isoissa järjestelmissä mastoja on oltava
lukuisia, koska yhden tason pinta-alaa ei voida jo mekaanisista syistä
kasvattaa määrättömästi.

Hinta kilowattitunnilta halpenee
Keskitettyjen järjestelmien hinta tuotettua energiamäärää kohden on
kutakuinkin sama kuin perinteisten aurinkopaneelien. ISFOC:n tutkijat
uskovat keskitettyjen ratkaisujen olevan jo vuoden kuluessa perinteisiä
PV-paneeleita edullisempia. Etenkin Solfocus on esittänyt kovia odotuksia
kustannustehokkuuden suhteen. Yrityksen tavoitteena on haastaa perinteinen
sähköntuotanto myös taloudellisessa kilpailukyvyssä ilman mitään tukia.
ISFOC:n edustajien mukaan tämän saavuttamiseen menee kuitenkin vielä "joitain"
vuosia.

Aiemmin verkkopalvelussa

Suomi on ihanteellinen aurinkosähkölle [19.05.2008] ť
Aurinkosähkön tuottajilla valoisat näkymät [15.05.2008] ť
Aurinko sähköistää Portugalia [12.03.2008] ť

Aiheesta Talentumin verkostossa

Energiapula ratkeaa nanotekniikalla [19.05.2008] ť
Aurinko sähköistää Portugalia [12.03.2008] ť
Espanjaan nousee aurinkovoimaa suomalaisella sähkötekniikalla
[12.03.2008] ť
Uudenlainen aurinkovoimala Espanjaan [30.01.2008] ť
"Nyhjää tyhjästä" [26.10.2007] ť


Aiheeseen liittyvien yritysten tiedot (Inoa.fi)

Rini-Tuote Oy ť
Jakelulaite Oy Ab ť
Lapijoen Sähkö Oy ť
*********************!!!!!!!!!!!!!

Hyvä juttuLähetä kaverille Tulosta artikkeli LÄHETÄ KAVERILLE *oma nimesi
*oma sähköpostiosoitteesi *kaverin sähköpostiosoite Otsikko: Viesti:
*Tähdellä merkityt kentät ovat pakollisia

[Jukka Lukkari, 03.06.2008] Ydinvoimalat vanhenevat käsiin Yhdysvalloissa
on toiminnassa 104 voimalaa, jotka alkavat vähitellen tulla elinkaarensa
loppupuolelle. Toinen vanhentuvien voimaloiden maa on Iso-Britannia. ť
 
rickman wrote:
On Jul 19, 2:57 am, Antti <Antti.Luk...@googlemail.com> wrote:
Snip
hi I may have different interests, yes smallest nonserialized CPU
as for your current task is one of the wishes, and here also there
is no one definitive winner
snip
I read your thread about the serial processor and it was interesting.
I think my project actually has the time to use such a processor, but
I think you never found one that met your requirements.
Click to expand...
Related to this 'serial' processor design, (probably should be better
called 'most compact'?), I spotted a reference in a larger CPU released
recently, that mentioned it had Quad-SPI SRAM support - so it looks
like SRAM will soon be added to the already-available Quad-SPI FLASH
memory. (There is a 32K SPI SRAM out, but this is not quad)
Such a device would also help those 'needing more SRAM' in their
FPGAs...

-jg
 
On Tue, 19 Aug 2008 09:31:57 +0100, Martin Thompson wrote:

Having said that, I haven't had the need to instantiate a RAM, except
in the case of a dual-port RAM with two different clocks, which my
current synth tools can't infer.
Click to expand...
Hmmmm.... I've been playing with a cache design that needs
rather wide data words. I decided I could get 72-bit wide
single-port memory out of just one BlockRAM by using both
ports simultaneously, with addresses that were identical
save for just one bit that was tied to 0 on one port and
tied to 1 on the other.

I wrote a nice inference model...

Two major synth tools correctly inferred the memory as
a write-first BlockRAM, but inferred two distinct RAM
blocks instead of using both ports, thereby wasting
half of each block.

ISE 8.2 (yeah, I know it's ancient, but I haven't got
around to installing anything newer yet) just locked-up
with 100% CPU usage, presumably because it failed to
infer the RAM from my description and was trying to
build a gazillion registers instead. Must go look up
the correct inference templates for XST :)

Does anyone know how to pull this double-width/single-port
trick without using instantiation?
--
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.
 
was actually trying something very similar myself...perhaps same
problem...that's why I'm going for instantiation for now...tell me if
you find a good inference model...
 
On Aug 19, 5:15 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Tue, 19 Aug 2008 09:31:57 +0100, Martin Thompson wrote:
Having said that, I haven't had the need to instantiate a RAM, except
in the case of a dual-port RAM with two different clocks, which my
current synth tools can't infer.

Hmmmm.... I've been playing with a cache design that needs
rather wide data words. I decided I could get 72-bit wide
single-port memory out of just one BlockRAM by using both
ports simultaneously, with addresses that were identical
save for just one bit that was tied to 0 on one port and
tied to 1 on the other.

I wrote a nice inference model...

Two major synth tools correctly inferred the memory as
a write-first BlockRAM, but inferred two distinct RAM
blocks instead of using both ports, thereby wasting
half of each block.

ISE 8.2 (yeah, I know it's ancient, but I haven't got
around to installing anything newer yet) just locked-up
with 100% CPU usage, presumably because it failed to
infer the RAM from my description and was trying to
build a gazillion registers instead. Must go look up
the correct inference templates for XST :)

Does anyone know how to pull this double-width/single-port
trick without using instantiation?
Click to expand...
I don't know for sure, but I expect you can make it work by inferring
a standard dual port memory where both ports access the same address
space. I expect the vendors have a template for that. Then just feed
the two addresses with the high bit set or clear depending on the
port. The source you show below may infer memory, but it is single
port. I don't see any reason to expect the tools to be able to
recognize that you are using half of two memories and they can combine
them into one dual port memory.

Rick
 
On Aug 29, 2:58 pm, MooseFET <kensm...@rahul.net> wrote:
On Aug 28, 9:50 pm, already5cho...@yahoo.com wrote:



On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote:

On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:

MooseFET wrote:
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.

Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions.

I wasn't referring to just my code when I said "seen".

Do you use the assignment of the "Z" value to cause a tri-state?
Quartus doesn't compile them.

When you assign "Z" to external pin - Quartus compiles it very well,
thank you.

Have you done it?
Click to expand...
Of course.

I am surprised if they have fixed it. I had to
recode to use the tri() to get the tri-state pins to work. I had
defined a component with the tristate pins that I connected directly
to the pins of the chip. The compiler would choke on it. The same
code compiled on Cypress's "warp" and produced exactly the tristated
pin I expected.
Click to expand...
Did your component had tristate pins defined as out or inout?
The later, indeed, had problems until relatively recently but the
former always worked as expected.
I, personally, always prefer to have separate in and out ports in
internal components, so I wasn't hit by earlier bugs.

Why they fixed it at the end? I think, the main reason was SOPC
builder. They wanted the same SOPC builder output to work both as a
top level project and as a component so they had little choise.
Hopefully, by now, they realized that except for the toy problems no
sane developer will use SOPC builder output as a top level but the
inout fix is done already and there are no reason to go back.

On the other hand, internal tristate nodes are not supported by Altera
architecture - how would you expect Quartus to synthesize them in this
case? Infer muxes?

I didn't do this but yes a compiler could easily turn it into
something like this to send to the fitter:

Y = X1 & EN1 # X2 & EN2 # X3 & EN3;

There is no need to make a full mux because there should only be one
assignment of a non-Z value at a time and thus only one EN# would be
true.
Click to expand...
As I said in another post, nobody here codes this way so I have no
idea whether the compiler does the right thing.

P.S.
I added comp.arch.fpga to the list. Let's see the opinion of real
experts.
 
On Aug 29, 9:41 pm, already5cho...@yahoo.com wrote:
On Aug 29, 2:58 pm, MooseFET <kensm...@rahul.net> wrote:



On Aug 28, 9:50 pm, already5cho...@yahoo.com wrote:

On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote:

On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:

MooseFET wrote:
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.

Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions.

I wasn't referring to just my code when I said "seen".

Do you use the assignment of the "Z" value to cause a tri-state?
Quartus doesn't compile them.

When you assign "Z" to external pin - Quartus compiles it very well,
thank you.

Have you done it?

Of course.

I am surprised if they have fixed it. I had to
recode to use the tri() to get the tri-state pins to work. I had
defined a component with the tristate pins that I connected directly
to the pins of the chip. The compiler would choke on it. The same
code compiled on Cypress's "warp" and produced exactly the tristated
pin I expected.

Did your component had tristate pins defined as out or inout?
Click to expand...
IIRC: Some were inout because they were bidirectional to the same
part. Others were outputs of one part but inputs to another. This
was a data bus situation.

I had two Cygnal F124 CPUs and a DMAed input sharing 512K * 8 RAM.
The result was that I needed two 8 bit true I/O busses and a MUXed bus
at the RAM.

The later, indeed, had problems until relatively recently but the
former always worked as expected.
I, personally, always prefer to have separate in and out ports in
internal components, so I wasn't hit by earlier bugs.

Why they fixed it at the end? I think, the main reason was SOPC
builder. They wanted the same SOPC builder output to work both as a
top level project and as a component so they had little choise.
Hopefully, by now, they realized that except for the toy problems no
sane developer will use SOPC builder output as a top level but the
inout fix is done already and there are no reason to go back.

On the other hand, internal tristate nodes are not supported by Altera
architecture - how would you expect Quartus to synthesize them in this
case? Infer muxes?

I didn't do this but yes a compiler could easily turn it into
something like this to send to the fitter:

Y = X1 & EN1 # X2 & EN2 # X3 & EN3;

There is no need to make a full mux because there should only be one
assignment of a non-Z value at a time and thus only one EN# would be
true.

As I said in another post, nobody here codes this way so I have no
idea whether the compiler does the right thing.

P.S.
I added comp.arch.fpga to the list. Let's see the opinion of real
experts.
Click to expand...
 
Muzaffer Kal <kal@dspia.com> writes:

On 06 Sep 2008 20:12:16 -0700, thutt <thutt151@comcast.net> wrote:
The 'signal' at the top level isn't removed, it's still present and
quasi-used. It works like this:

-- S3E demo board has 4 slider switches & 8 LEDs.
-- I combine the switches and the LEDs to get 16 banks of 8 LEDs.
-- I have an array, 16 x 8 of std_logic which corresponds to the
LED values.
-- The bank of LEDs which is actively connected to the actual
on-board LEDs is selected by the slider switches.

The signal which was assigned to the output port of the
'harp_keyboard_controller' entity was one element of the 16-element
array. That element of the array was not used for anything else in
the design -- it's just for outputting the most recent byte received
from the attached PS2 keyboard.

At the point that I removed the assignment to the output port in the
top level design, the 'harp_keyboard_controller' did not use the port
at all -- it did not assign anything to it at all; it was completely
unused.

So, I just don't understand why removing a port that it unused can
make the design fail.

I have one question and a suggestion. What exactly do you mean by
"project ... fails to function properly" ? What parts of it break
down? That may help to figure out what's going on.
Click to expand...
I'm working on building a single board computer using the S3E demo
board. At present, I've gotten most of the component cobbled
together, and I've reached the point that I can actually write
software for the system. I'm now working on writing a low-level
driver which will interpret the make & break codes from the PS2
keyboard.

I do not yet use the on-board RAM of the S3E board, but instead have
written a RAM simulator using the serial port on the S3E board which
is hooked up to a program running on my host computer.

When I start the RAM simulator program on the host computer, I give it
a binary file to load (the program I wish to run).

The current program I am running reads data from the keyboard and
outputs the hex values on the screen. I'm using this information to
figure out how to write the low-level driver.

Finally, to answer your question, when the output port signal is
included in the 'harp_keyboard_controller' entity, the program which
I'm running actually executes until I stop it.

When I remove the 'kbd_leds' output port, the cpu executes a bunch of
instructions (probably a few hundred) and then hangs.

It's pretty obvious that something is wrong, but I just don't
understand how removing a completely unused signal can cause the
Xilinx tools to generate such a radically different output.

The suggestion is based on an assumption. If you left the switch
selection still at the keyboard output, does it help to change it to
another of the 16 possibilities?
Click to expand...
It makes no difference. I was originally using index '8' into the
array. I switched it to '0' and the design still works.

Last night I also made a new signal, 'gungla' in my top level design
and used that instead of the arbitrary index into the array.

The system fails in exactly the same way as if I had removed the
output port from 'harp_keyboard_controller'.

The next test was to remove the 'kbd_leds' output port, and use:

leds(0) <= (others => '0");

in my top level entity. In this case, the system also fails in the
same way.

So, somehow the design is now dependent upon using some index into the
16x8 array -- the array is used only for output to the LEDs.

If you're interested in more detail, you can check out the on-going
work at http://www.harp-project.com/

The site deliberately runs behind the work that I've actually
completed, so it's not up-to-date with this issue.

I've trimmed the posting list to just comp.arch.fpga.

--
Inconceivable!
 
John_H <newsgroup@johnhandwork.com> writes:

thutt wrote:
snip
At this point, 'kbd_leds' is not assigned inside
'harp_keyboard_controller', so then I tried to remove the signal from
the entity declaration, and the corresponding assignment in the
instantiation of the 'harp_keyboard_controller' entity.
I rebuilt my project and it fails to function properly.
snip

Are you certain that all the *other* I/O in your design are properly
constrained to the pins you want? An unconstrained pin will often
move when other I/O are removed with unpredictable results.

Please let me know if you regularly visit *both* newsgroups or if only
one is your normal place to search for responses. Cross-posting to
multiple newsgroups often causes more troubles than it solves.
Click to expand...
All the IO is constrained to specific pins using a constraints file.

--
Inconceivable!
 
Hi,

On Mon, 2008-09-29 at 08:10 -0700, Fred wrote:
Do I require any ARP or any other protocol? Will it just work, with
the destination PC receiving UDP packets?
Click to expand...
You have to include the FPGA host (mac and ip) into the ARP table of the
host PC. Then you didn't need to implement the ARP protocol.

Ben
 
On Mon, 2008-09-29 at 08:34 -0700, cs_posting@hotmail.com wrote:
I don't think that will be needed, since the PC is not expected to
reply.

I suppose there might be software on the PC that would consider this
"traffic from nowhere" suspicious and possibly forged, but that's a
configuration problem, not a fundamental one.
Click to expand...
Sure, software which listen on a port and capture/evaluate the sent
data are also needed. But the host pc needs to arp entry to recognize
the FPGA (the other host).
 
On Sep 29, 11:15 am, Benjamin Krill <b...@codiert.org> wrote:

You have to include the FPGA host (mac and ip) into the ARP table of the
host PC. Then you didn't need to implement the ARP protocol.
Click to expand...
I don't think that will be needed, since the PC is not expected to
reply.

I suppose there might be software on the PC that would consider this
"traffic from nowhere" suspicious and possibly forged, but that's a
configuration problem, not a fundamental one.
 
On 29 Sep, 16:34, cs_post...@hotmail.com wrote:
On Sep 29, 11:15 am, Benjamin Krill <b...@codiert.org> wrote:

You have to include the FPGA host (mac and ip) into the ARP table of the
host PC. Then you didn't need to implement the ARP protocol.

I don't think that will be needed, since the PC is not expected to
reply.

I suppose there might be software on the PC that would consider this
"traffic from nowhere" suspicious and possibly forged, but that's a
configuration problem, not a fundamental one.
Click to expand...
Many thanks for the replies. I wasn't sure if I needed to add my MAC
and IP address to the PC ARP table, or if it would be added by default
once I had sent a packet. It would be nice if this was a purely one
way transmission.

Thanks again.
 
me_rythm wrote:

I have made a program which calculate FFT of two images (1024X1024) and
then convolve them. I wish to know which FPGA chips would be best for this
task, I want the result of the algorithm in real time (more than 30hz). It
takes around 10 seconds on my machine(AMD 1.8 Ghz Dual Core) for just one
convolution of both the images. I am thinking to use xilinx XC3S500E (500k
gates). I have no experience in FPGA, if anyone can help me i would really
appreciate.
Click to expand...
You would do better to post in comp.arch.fpga. (added)

How many bits per sample? Are you using the SSE feature
of the AMD machine? That lets you process multiple 8 bit
values in one instruction, but might require assembly coding.

I suggest looking at the systolic array architecture as
it works well for many problems like this. You don't really
need FPGA experience, but digital logic experience helps a lot.

Could you build such a device out of 7400 series TTL?
If so, you can figure out how to do it in an FPGA, but much
faster (in your time) and cheaper. The thought process is
very different from C coding.

Is this a commercial product or a class project?

-- glen
 
On Oct 1, 5:53 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
me_rythm wrote:
I have made a program which calculate FFT of two images (1024X1024) and
then convolve them. I wish to know which FPGA chips would be best for this
task, I want the result of the algorithm in real time (more than 30hz). It
takes around 10 seconds on my machine(AMD 1.8 Ghz Dual Core) for just one
convolution of both the images. I am thinking to use xilinx XC3S500E (500k
gates). I have no experience in FPGA, if anyone can help me i would really
appreciate.

You would do better to post in comp.arch.fpga.  (added)

How many bits per sample?  Are you using the SSE feature
of the AMD machine?  That lets you process multiple 8 bit
values in one instruction, but might require assembly coding.

I suggest looking at the systolic array architecture as
it works well for many problems like this.  You don't really
need FPGA experience, but digital logic experience helps a lot.

Could you build such a device out of 7400 series TTL?
If so, you can figure out how to do it in an FPGA, but much
faster (in your time) and cheaper.  The thought process is
very different from C coding.

Is this a commercial product or a class project?

-- glen
Click to expand...
Did you take a look at this document?

http://www.xilinx.com/support/documentation/ip_documentation/xfft_ds260.pdf

To achieve the speed you need you may need a much larger part or one
with
more block RAM and multiplier resources.
 
Eric,

First, this isn't the place to post pictures. You should post a link
here only (read Usenet FAQ's).

The Xilinx impact GUI is not very intuitive. The picture you
(almost) posted shows a window for generating a file to
load into the flash memory. If you want to program the
FPGA directly you can just use the .bit file created in
the "generate program file" step. To generate the PROM
file from the window you see, either right click in the
white area of the right window and select "generate
file" (or something like that). Or use the Operations
menu from the toolbar to do the same thing. Then look
for your .mcs file to load into the flash.

Regards,
Gabor
 
Hi,

The above link (http://help.xilant.com/Xilinx:Configuration:CRC) is not
valid anymore. Would some one who has a copy of the CRC calculation
algorithm for Virtex 4 send me a copy please.

Thanks in advance.

Shahram
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top