Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 54075

Article: 54075
Subject: Re: parity checking trick for PCI core
From: Kevin Brace <kev0inbrac1eusen2et@ho3tmail.c4om>
Date: Tue, 01 Apr 2003 20:40:20 -0600
Links: << >>  << T >>  << A >>
marlboro,

Yes, to meet PCI's strict setup time requirements (Tsu < 7ns for 33MHz
PCI and Tsu < 3ns for 66MHz PCI.), AD and C/BE# should (must) be
registered before calculating the parity of those inputs.
Parity should be calculated from those FFs, and compare it against PAR
all in one cycle.
That way, the parity checker has 30ns (15ns for 66MHz PCI) for parity
calculation + comparison against PAR versus 7ns (3ns for 66MHz PCI) for
calculating the parity if inputs weren't registered (In the later case,
comparison against PAR will be done in the next clock cycle.).


Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)



marlboro wrote:
> 
> Hi,
> You don't have to register the AD and C/BE for parity checker, that
> can save you 1 clk, but beware of timing. How fast you want it gonna
> be?

Article: 54076
Subject: Re: parity checking trick for PCI core
From: Kevin Brace <kev0inbrac1eusen2et@ho3tmail.c4om>
Date: Tue, 01 Apr 2003 20:49:25 -0600
Links: << >>  << T >>  << A >>
Praveen,

Yes, you are on the right track that AD[31:0] and C/BE#[3:0] should
(must) be registered before calculating the parity of it for parity
checking purposes.
However, you should be aware that when calculating the parity of it
after the signals are registered, you should add "keep" or "preserve"
attribute of the synthesis tool to constrain the final output coming out
of the 36-input parity tree.
What happens with most synthesis tools is that they almost always try to
optimize the structure of the parity tree, and in that process, almost
always mess up the original structure of the parity tree, often leading
to timing problems with PAR input (PAR input is a PCI signal.).


Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)


praveen wrote:
> 
> Hello Sirs/Friends,
> I am designing a PCI core in which i have parity checker module. I
> wanted to know how can design a parity checker which can meet the PCI
> specification. I will have registered AD[31:0] and C/BE[3:0] signal
> whose parity should be checked and PAR signal come in the next clock
> and i have signal the  PERR the next clock itself. How to design this.
> Waiting for ur reply
> Praveen

Article: 54077
Subject: Shove a binary file into Xilinx 4.2 as input for testing...
From: mhollinger@ou.edu (Mike Hollinger)
Date: 1 Apr 2003 19:21:06 -0800
Links: << >>  << T >>  << A >>
I'm a student at the University of Oklahoma. We're using Xilinx
Student Edition 4.2i for ECE 5623, Computer Hardware Design (feat.
VHDL). Part of that class is a final project. Mine will be
implementing parts of an MP3 decoder in hardware. The only way I have
to test my hardware so far is to use the "testbench waveforms," which
involves manually inputting the stream of data. I really would like to
avoid this.

Is there a way to feed a binary file into the simulator or testbench?
If not, I'd like to whip up a quick little C (or Perl or PHP) program
to generate a TBW file for me. Anyone got some pointers?

Please reply back or e-mail.

Mike Hollinger
--
Michael C. Hollinger
mhollinger@ou.edu
Senior, Computer Engineering / Electrical Engineering
Univ. of Oklahoma
Boomer? Sooner!

Article: 54078
Subject: CPLD applications?
From: foredl@yahoo.com (datalines)
Date: 1 Apr 2003 20:45:31 -0800
Links: << >>  << T >>  << A >>
Hello. I am new to programming CPLDs...and
I would like to know from experienced programmers...
what are the most popular applications for this?
for consumers?  Industry?  Military?
Return on investment of time?  and resources??
any good authoritative textbooks on this??

Article: 54079
Subject: [ANN] uClinux on Xilinx Microblaze
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 02 Apr 2003 15:00:14 +1000
Links: << >>  << T >>  << A >>
Dear Friends,

Earlier this year we commenced a project to port the open-source uClinux 
  operating system (kernel version 2.4.x) to the Xilinx Microblaze 
softcore processor.

The purpose of this message is to update you on the status of the 
project, and invite interested parties to join a new mailing list 
devoted to this effort.

Status:
-------
It is now possible to boot a basic uClinux kernel on one specific 
Microblaze target, which I have dubbed "mbvanilla".  Clearly, the 
ability to target arbitrary microblaze hardware configurations is a 
major long-term goal of the project.

I have submitted a series of patches to the uClinux source maintainers 
for inclusion in their CVS tree that will allow others access to the new 
code.  When this is available I will notify the mailing list (see below).


Work to be done:
----------------
The port is incomplete and experimental.  There are several loose ends 
to be tied up before it can be considered "working", and even more 
before it will be anything approaching "stable".

In the short term, the following issues remain outstanding:
  - elf2flt and bin_fmt_flat userland binary support
  - testing and completion of uClibc C library support
  - a root file system (romfs)
  - general kernel testing and debugging
  - proper integration into the uClinux kernel build system

Longer term, we need to get a stable core of applications built and 
tested on the new platform, as well as networking support and much more. 
  Further, there is a general desire to integrate or at least 
interoperate the kernel configuration process with the Xilinx platform 
generation tools.  Hard real-time support and Microblaze/uClinux 
single-chip multiprocessing are also definitely on the agenda.

Mailing list:
-------------
While there is a dedicated and active uClinux mailing list 
(uclinux-dev@uclinux.org), I have taken the step of creating a 
microblaze/uclinux specific list.  It is my intention for this list to 
operate for a maximum of six months, or until the port is stable enough 
that the participants can migrate to uclinux-dev.  If it is appropriate, 
I will post a weekly digest of our new list across to uclinux-dev.

To subscribe, send an email to majordomo@itee.uq.edu.au, with the 
following as the body of the message:

subscribe microblaze-uclinux

Follow the instructions in the reply email, then you will be on the 
list.  I expect it will be quite low volume, but would love to be proven 
wrong!

Finally, if you know of anybody else who might be interested to join 
this project, then please feel free to forward this message to them as 
you see fit.

I have very high hopes for this work, and think that there lie ahead 
many exciting opportunities for uClinux on the Microblaze platform.  Any 
involvement, no matter how small, will be welcomed and appreciated.

Thank you,

John Williams
-- 
Dr John Williams, Research Fellow,
Reconfigurable Computing, School of ITEE
University of Queensland, Brisbane, Australia
Ph : 61-7-3365-8305


Article: 54080
Subject: Re: parity checking trick for PCI core
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 1 Apr 2003 22:32:50 -0800
Links: << >>  << T >>  << A >>
praveenkumar1979@rediffmail.com (praveen) wrote in message news:<ff8a3afb.0304010305.7274cd95@posting.google.com>...
> Hello Sirs/Friends,
> I am designing a PCI core in which i have parity checker module. I
> wanted to know how can design a parity checker which can meet the PCI
> specification. I will have registered AD[31:0] and C/BE[3:0] signal
> whose parity should be checked and PAR signal come in the next clock
> and i have signal the  PERR the next clock itself. How to design this.
> Waiting for ur reply
> Praveen

For best results, your parity-module design should have two pipeline
stages: one on the incoming data (before the parity logic) and one 
on the parity-out signal itself, after the parity logic (single FF).

There are actually two separate parity operations on the PCI bus:

* When your device drives the A/D lines, it must also drive the 
PAR line with the correct parity one clock later. You can drive 
the parity-logic input pipeline register with the same data that
is used for the A/D-out register (you DO have a pipeline reg on
the A/D-out path, don't you?); the registered parity-out signal
will now be at the correct clock-cycle.

* When you check parity on incoming address/data, you have two
clocks to report parity errors on PERR#. Surprise! when the PCI
spec was defined, they recognized the need for two pipeline stages!

(note that most of the PCI spec is intended for pipelining -
the only exceptions are the TRDY#/IRDY# signals; if you design
a PCI interface, they are usually the hardest signals to get
within the PCI timing spec).

If you have the available logic resources, I'd recommend using 
two separate parity modules for incoming and outgoing data paths; 
this may even require less logic, since you save a lot of muxes. 
It will make the design easier to bring to timing spec.

Article: 54081
Subject: Re: uP interface question
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 02 Apr 2003 07:27:25 GMT
Links: << >>  << T >>  << A >>
Jonathan,

Your comments are right on target.  I considered using internal FPGA
clocking (>5x microprocessor clock) to implement a state machine approach to
the interface, but decided to go asynchronous on the input side of the
registers and synchonous on the output side, where required.  Most of my
registers do things like provide one side of the data for equality
comparators or set parameters that will be used after a reset command.  As
such there are no issues in terms of metastability or even the use of
latches (which I'm not using, but...).  In the case of the RAM lookup
tables, all operations stop within the FPGA when they get loaded by the uP,
so I have very few worries about getting into trouble there as well.

Thanks,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"





"Jonathan Bromley" <jonathan.bromley@doulos.co.uk> wrote in message
news:b6bglu$jug$1$8300dec7@news.demon.co.uk...
> "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
> news:Z2%ha.215$Iz6.14915853@newssvr14.news.prodigy.com...
> > In order to maximize access speed I'm thinking of using both edges of
the
> > uP's WE pulse to run these SelecRAM ports.  The idea is to capture the
> data
> > byte on the leading edge and use the trailing edge to increment the
> address
> > counter that is driving the SelectRAM block.  With this, all the uP has
to
> > do is present  new data and pulse WE until it fills the memory bank.
> > I'm looking for feedback on this technique.  Any problems?  Any reason
for
> > not taking this approach?  Any other approaches that might warrant
> > consideration?
>
> I've used this kind of "autoincrement" mechanism successfully in the
> past, but you must pay attention to the details.
>
> I'm guessing that your FPGA system clock is way faster than the
> CPU I/O write cycles, so it's reasonable to run some kind of
> state machine inside the FPGA, controlled by activity on WE.
> That way you can schedule your memory writes and address updates
> in whatever way is most appropriate.  You could even do
> address pre-increment (instead of post-increment) if you wanted.
>
> Look out for data setup and hold times relative to WE edges.  Like
> I said, it's all in the detail.  Watch out, too, for the
> comparatively long delays through FPGA I/Os - particularly if
> you're relying on timing relative to the CPU clock, and you
> generated that CPU clock inside the FPGA.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
UK
> Tel: +44 (0)1425 471223                    mail:
jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
>
>



Article: 54082
Subject: Excel and FPGA's
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 02 Apr 2003 07:49:43 GMT
Links: << >>  << T >>  << A >>
I find Excel incredibly valuable in various programming tasks, not just
FPGA's.  On that topic though, I've been wondering if anyone has published
useful worksheets/utilities in order to facilitate the use of Excel in FPGA
programming.  I'm working with Verilog, however, more generalized solutions
are of interest as well, hence the cross-post to comp.arch.fpga.

I have, for example, created Excel worksheets to generate the Verilog code
to initialize large RAM blocks with data.  The desired data is entered or
calculated on a column, a graph shows it to the right and the whole thing is
reformatted into Verilog code that can be cut and pasted right into a
module.

Another example is a little VBA utility I wrote that lets me generate module
instantiation code (or other variants) by taking a sample instantiation,
say:

widget U1 (.A(8'h23), .B(8'h99), .C(8'hAB));

replacing the parameters/instance name with "%n%":

widget %1% (.A(%2%), .B(%3%), .C(%4%));

and then using rows and columns withing Excel to enter/calculate the
parameters for multiple instances of this module.  As in the prior example,
the code can then be cut and pasted right into Excel.

My thinking is along the lines of trying to limit repetitive error-prone
typing and automating as much as possible.  Another candiate is the
repetitive signal, port type declaration style that requires typing the same
thing three times.  In Excel this can be done once and then transfered into
your Verilog editor in one shot.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"





Article: 54083
Subject: Re: Shove a binary file into Xilinx 4.2 as input for testing...
From: "Hans" <hansydelm@no-spam-ntlworld.com>
Date: Wed, 2 Apr 2003 08:59:47 +0100
Links: << >>  << T >>  << A >>
Hi Mike,

Yes you can stream in data using sockets or pipes in Modelsim. For sockets
you can use TCL on Modelsim PE/XE or TCL/C/C++ on Modelsim SE. If you
program in Verilog you can use the PLI/VPI interface on Modelsim PE/XE.

A nice demo of the project would be to read the encoded file from your
harddisk and stream the decoded output realtime to your soundcard :-)
Modelsim PE/SE (not XE) is most likely fast enough to handle this task. I
have a real-time fractal generator on my website which generates 80KBytes of
coordinates every second on a 2.4GHz P4 machine.

Good luck,

Hans.

www.ht-lab.com

"Mike Hollinger" <mhollinger@ou.edu> wrote in message
news:50461b3.0304011921.20e295e0@posting.google.com...
> I'm a student at the University of Oklahoma. We're using Xilinx
> Student Edition 4.2i for ECE 5623, Computer Hardware Design (feat.
> VHDL). Part of that class is a final project. Mine will be
> implementing parts of an MP3 decoder in hardware. The only way I have
> to test my hardware so far is to use the "testbench waveforms," which
> involves manually inputting the stream of data. I really would like to
> avoid this.
>
> Is there a way to feed a binary file into the simulator or testbench?
> If not, I'd like to whip up a quick little C (or Perl or PHP) program
> to generate a TBW file for me. Anyone got some pointers?
>
> Please reply back or e-mail.
>
> Mike Hollinger
> --
> Michael C. Hollinger
> mhollinger@ou.edu
> Senior, Computer Engineering / Electrical Engineering
> Univ. of Oklahoma
> Boomer? Sooner!



Article: 54084
Subject: Matrix multiply in FPGA
From: "jerry1111" <No_this_fucking_spam_jerry1111@wp.pl>
Date: Wed, 2 Apr 2003 10:32:34 +0200
Links: << >>  << T >>  << A >>
I need to do 32bit fixed-point 6x6 matrix multiply
in hardware - it's a design which needs much matrix
operations and everything says that fixed-point will be
enough. I plan to keep matrices in fixed locations in
embedded ram, feed 'start' signal to multiply logic and
look for a result after doing other things.
It will be used with Nios.

Are there any guidelines or examples on the web (I don't like
reinventing the wheels :-) Or (at least) I'd like to
see some comments, ideas, does and don'ts from you...

As I will need matrix transpose from time to time, I will
put simple mux between row/column counters and address generation
logic.

Any suggestions? Any ideas?


BTW: It's not a homework :-)

-- 
jerry

"The day Microsoft makes something that doesn't suck is probably
the day they start making vacuum cleaners." - Ernst Jan Plugge 



Article: 54085
Subject: Re: What would it take?
From: johnjakson@yahoo.com (john jakson)
Date: 2 Apr 2003 00:44:23 -0800
Links: << >>  << T >>  << A >>
"Steve Casselman" <sc_nospam@vcc.com> wrote in message news:<MMria.308$Zg.28941436@newssvr15.news.prodigy.com>...
> I wrote a little artical for EETimes that proposed having a full wafer of
> FPGA fabric that included a purge map for defective resources. You could
> have an area on the FPGA die that got laser burned to record the defects.
> Once you have a "master" design rerouting around the defects would not be
> that hard or take that long. Of course you know of the Xilinx program where
> you give them a bitfile and they screen to that. But really someone will do
> the work to include a bitmap someday. Like I say it would be great for wafer
> sized FPGAs. Imagine a Billion gate device. You could put everything
> including the OS on something that size.
> 
> Steve
> 


Now that takes us right back to WaferScale integration. At least one
company out of U Cambridge did wafer scale integrated DRAMs in late
80s, self test would automagically find a serial path through all the
good die and bypass over the dead ones. The wafer was never sawed.
Ofcourse it died when Japan Inc figured how to make DRAMs >>64K. Wafer
scale work became irrelavant about 15yrs ago.

Still the self test of an FPGA and the rest of it would be an
enormouse undertaking.

Article: 54086
Subject: Re: XC9572XL Macrocell power
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 2 Apr 2003 08:50:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote:
: ...

: Thanks for your help, it turns out that the CPLD wouldn't run in low power
: mode, until I feed a WR line into a global clock pin.

It should work anyhow, until  very fast signals (> 20 MHz) were
involved. Did you give a sensible constraints file? 

: There was a thread here a while back about feeding an input signal out a
: global clock pin and then using the global clock signal - thus letting any
: pin be a global clock.

If you still have a GCLK pin unconnected, feed the signal to that output and
read it back as GCLK signal. XST is normally good at doing this
automatically.  Read the log files.

: Does anyone have any idea how to get the syntheses to understand that?

As said above, XST will do it automativally, until you put up obstacles.

Bye

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 54087
Subject: altera device config problem
From: "leon qin" <leon.qin@2911.net>
Date: Wed, 2 Apr 2003 17:18:50 +0800
Links: << >>  << T >>  << A >>
I want to config Altera sram based FPGA (ex ACEX series) with AVR MCU+EEPROM
by ps mode,
because the smallest AVR mcu only have 6 IOs,and clk need 1,
so I think I may tie e2prom's clk whith fpga's DCLK,tie e2prom's Dout with
fpga's data0,
I wang to see if it alwayes config successfully when I low nConfig,I first
feed some
dummy bits before the valid config data,and then feed right data.
sorry for my poor english.



Article: 54088
Subject: Re: Excel and FPGA's
From: Petter Gustad <newsmailcomp4@gustad.com>
Date: 02 Apr 2003 11:55:14 +0200
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> writes:

> I find Excel incredibly valuable in various programming tasks, not just
> FPGA's.  On that topic though, I've been wondering if anyone has published
> useful worksheets/utilities in order to facilitate the use of Excel in FPGA

Many (most?) designers do this with their favorite tool like Perl,
Python, Ruby, Guile, Dylan, etc. Personally I prefer Common Lisp.
Writing small utilities in Emacs Lisp is also very productive since
you don't have to import/export data from external tools.


Petter
-- 
________________________________________________________________________
Petter Gustad         8'h2B | ~8'h2B        http://www.gustad.com/petter

Article: 54089
Subject: FFT 256pt on Spartan
From: furia1024@wp.pl (Jerzy)
Date: 2 Apr 2003 05:03:14 -0800
Links: << >>  << T >>  << A >>
Hi
I'd like to know if is there any possibility to make usable IPCore
from Xilinx FFT 256pt, for Spartan?
Spartan IIe has similiar resources as virtex.
Or could You give me advice where I can find core this class?

Greatings

Jerzy Gbur

Article: 54090
Subject: ALTERA APEX 20K Series: Are there configurable pullups in IO cells?
From: "Christian" <cw@nikocity.de>
Date: Wed, 2 Apr 2003 15:54:29 +0200
Links: << >>  << T >>  << A >>
Hi There,
I am currently working on a FPGA based System using a serial arbitration
strategy.
I want to implement a dominant "low", and a recessive "high",
and for that I need to know if APEX 20k have the possibility to use pullups
on certain signals.

hope you can help me
best regards
Chris.




Article: 54091
Subject: Re: Matrix multiply in FPGA
From: Ray Andraka <ray@andraka.com>
Date: Wed, 02 Apr 2003 14:55:11 GMT
Links: << >>  << T >>  << A >>
You didn't say how fast it has to run.  Given enough clock cycles you
could do it with two adders, a memory with address counter and a
little bit of logic.

jerry1111 wrote:

> I need to do 32bit fixed-point 6x6 matrix multiply
> in hardware - it's a design which needs much matrix
> operations and everything says that fixed-point will be
> enough. I plan to keep matrices in fixed locations in
> embedded ram, feed 'start' signal to multiply logic and
> look for a result after doing other things.
> It will be used with Nios.
>
> Are there any guidelines or examples on the web (I don't like
> reinventing the wheels :-) Or (at least) I'd like to
> see some comments, ideas, does and don'ts from you...
>
> As I will need matrix transpose from time to time, I will
> put simple mux between row/column counters and address generation
> logic.
>
> Any suggestions? Any ideas?
>
> BTW: It's not a homework :-)
>
> --
> jerry
>
> "The day Microsoft makes something that doesn't suck is probably
> the day they start making vacuum cleaners." - Ernst Jan Plugge

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 54092
Subject: Re: FFT 256pt on Spartan
From: Ray Andraka <ray@andraka.com>
Date: Wed, 02 Apr 2003 14:59:46 GMT
Links: << >>  << T >>  << A >>
It is possible.  What are your performance and wordsize requirements?
We've got a 16 point core for this family, it would have to be married
with a phase rotator (which we also have) to get 256 points in two
passes.  The rotator and core together will fit in an XC2s300e.  We've
also got a radix4 core that would fit and would require 4 passes.
That one will fit in a smaller device, and in fact by using the
multipliers will fit in an XC2V40.

Jerzy wrote:

> Hi
> I'd like to know if is there any possibility to make usable IPCore
> from Xilinx FFT 256pt, for Spartan?
> Spartan IIe has similiar resources as virtex.
> Or could You give me advice where I can find core this class?
>
> Greatings
>
> Jerzy Gbur

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 54093
Subject: Multilinx Cable
From: "Stamatis Sotiropoulos" <ssothro@hotmail.com>
Date: Wed, 2 Apr 2003 18:00:24 +0300
Links: << >>  << T >>  << A >>
Hi all,
    I am using a SpartanII FPGA (XC2S100-5tq144) and I use the Xilinx
Multilinx Cable to configure it (Boundary-Scan Mode). Every time the FPGA is
configured and after 1-2 minutes of operation, it seems to "lose" its
configuration, stops to operate normally and the MultiLinx 's power
indicator turns off, although the power supplies continue to operate
normally. The same problem exists when the MultiLinx is detached from the
board after the configuration.
    Does anybody have similar experience?

Thank you in advance,
Stamatis



Article: 54094
Subject: quartus_cmd under Linux
From: Petter Gustad <newsmailcomp4@gustad.com>
Date: 02 Apr 2003 17:39:41 +0200
Links: << >>  << T >>  << A >>

I'm currently using QuartusII (2.2sp1) under Linux. I prefer not to
use the GUI except for floorplanning. Hence I prefer the quartus_cmd
tool.

Is there a smart way to wait for the completion of the "cmp start"
command without doing an idle loop? Since I'm not running the GUI I
don't need to do any refresh.

I would like to do something like:

puts $gOut "compilation started at [clock format [clock seconds] -format {%D %T}]"
set status [cmp start -blockuntilcompleted]
if {$status == 1} {
    puts $gOut "compilation completed at [clock format [clock seconds] -format {%D %T}]"
} else {
    puts $gOut "compilation failed: $status"
}

Unfortunately, cmp start does not have a -blockuntilcompleted option.
Currently I'm wasting valuable CPU time in a tight loop within
quartus_cmd waiting for [cmp is_running] to become false.

Petter
-- 
________________________________________________________________________
Petter Gustad         8'h2B | ~8'h2B        http://www.gustad.com/petter

Article: 54095
Subject: Re: Matrix multiply in FPGA
From: "jerry1111" <jerry1111@wp.pl>
Date: Wed, 2 Apr 2003 18:25:06 +0200
Links: << >>  << T >>  << A >>
> You didn't say how fast it has to run.

Sorry - I was so absorbed with this problem that I forgot to write it:

10us with 40MHz clock => 400 cycles would be perfect, but it's almost
impossible - at least from my current point of view.
I'll be happy getting any reasonable speed of course, but this timing gives
an idea how should it be....

I have to do 6 muls and cumulate them (6 adds) for each element from result matrix.
Matrix is 6x6, so 36 elements gives 216 muls and 216 adds....

Now I'm thinking about some sort of parralel operations, but it's not so
simple because of storing data in ram. The best would be to store each row
from A in separate block, columns from B in another 6 blocks, multiplying with
6 parallel logic pieces and feed results to FIFO. Each row/column is 6x36 bits -
- maybe it would be better to make some pipelinig...

Now I have 10 sheets of paper with various solutions, but I'd like to hear
opinions from 'another point of view'....

Selected device is EP1C6 from Altera.

PS: Sorry for my bad english, but I'm more reading than writing.

-- 
jerry

"The day Microsoft makes something that doesn't suck is probably
the day they start making vacuum cleaners." - Ernst Jan Plugge 



Article: 54096
Subject: Re: [Question] FPGA/PLX9054
From: g.ryan@macetech.com (Garrett Mace)
Date: 2 Apr 2003 08:26:32 -0800
Links: << >>  << T >>  << A >>
> > > + There is a way to configure your FPGA with PCI9080/54/54 signals
> > > witout PROM and additional PLDs. Think a little and you would find it
> > > yourself. I'm not going to tell you how :)
> > 
> > ummm, use an ISP CPLD?
> > 
> 
> Nah. No CPLD. Just PCI9056, FPGA and one pullup resistor...
> 
> > Seriously, tho', I guess you would use the FPGA's parallel config
> > mode.
> > 
> 
> No, I don't. Everything works with Passive Serial (speaking in
> A-terms).

Well, there is a user output pin...though perhaps DEVSEL could be
pressed into service. Actually there's any number of outputs that
could conceivably be wiggled.

Article: 54097
Subject: Xilinx Divider Core
From: Salman Sheikh <sheikh@pop500.gsfc.nasa.gov>
Date: Wed, 02 Apr 2003 11:33:26 -0500
Links: << >>  << T >>  << A >>
Hello,

I am using Simulink to model a divider.  My input is two integers of size 31
bits for the numerator and 24 bits for the denominator. For the precision I
require, the result requires 43 bits consisting of 37 fractional bits and 6
bits for the magnitude.  I see that Xilinx has a pipelined divider core
(v2.0), but will this give me the resolution I need? If not, does anyone
know of any other cores that I can use for a Xilinx Virtex II part?


Salman


Article: 54098
Subject: Re: uP interface question
From: "Jonathan Bromley" <jonathan.bromley@doulos.co.uk>
Date: Wed, 2 Apr 2003 18:18:57 +0100
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:xhwia.425$P41.30953712@newssvr14.news.prodigy.com...

> Your comments are right on target.  I considered using internal FPGA
> clocking (>5x microprocessor clock) to implement a state machine approach
to
> the interface, but decided to go asynchronous on the input side of the
> registers and synchonous on the output side, where required.  Most of my
> registers do things like provide one side of the data for equality
> comparators or set parameters that will be used after a reset command.  As
> such there are no issues in terms of metastability or even the use of
> latches (which I'm not using, but...).

OK, but beware that if you use decoded WE directly to clock
data into some registers, the FPGA tools will probably try to
put it on to a dedicated clock net, and if you have very large
numbers of these signals then there could be trouble with
allocation of the clock net resources.

Any special reason for choosing the async write?  I know it's
conceptually easier, but I've always found it was less pain
in the long run to stay synchronous where possible (and you
clearly *can* stay synchronous in this case).
--
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

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



Article: 54099
Subject: Re: DSP-FPGA interface
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Wed, 02 Apr 2003 17:43:02 GMT
Links: << >>  << T >>  << A >>
"Michael S" <already5chosen@yahoo.com> ha scritto nel messaggio
news:f881b862.0304011447.2808066f@posting.google.com...

> According to TI, the fastest C67 (TMS320C6713-225) has a
> _peak_
> performance of 1350 MFLOPs: (4 FADD + 2 FMUL) * 225MHz.
> Sorry for nit picking, I couldn't resist.

Ok, you are right too. It's the 62x family that has over 2000 MIPS, but
they are MIPS, not MFLOPS. :)

--
Lorenzo





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search