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 46600

Article: 46600
Subject: Re: choice of fpga
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Wed, 04 Sep 2002 10:56:48 +0200
Links: << >>  << T >>  << A >>
The CPLD solution will be the better.

For prototyping Coolrunner CPLD check http://www.amontec.com where you 
will find the Chameleon POD.

Laurent

Sheila Sim wrote:

> I am planning on using an FPGA to drive a small LCD display (not much more
> than a simple counter circuit), and this should run off of a typical watch
> battery.  Does anyone have any reccomendations as to which FPGA I should
> use?
> 
> Thanks in advance!
> 
> 
> 


Article: 46601
Subject: Re: C/C++ to Verilog/VHDL ?!
From: klonsky@hotmail.com (Noel Klonsky)
Date: 4 Sep 2002 02:24:40 -0700
Links: << >>  << T >>  << A >>
Hey Frank, I'd recommend having a look at DK1 from Celoxica as a
methodology for taking your design from C to an optimized
implementation.  You can either use its in-built synthesis capability
(which is optimized for specific devices)for direct implmentation via
Place and Route or output VHDL/ Verilog for implmentation through HDL
synthesis. I've had sound results with both.

In terms of co-processing I saw some Xilinx/ Celoxica/ Wind River
demo's at Programmable World that did just what you say.  This may be
worth a look and it sure would make sense to approach this kind of
concurrent design problem with a higher level language.

Your comments on 'the future' are interesting.  I remember many years
ago in the software world when memory was a precious resource and a
priority in any design specification.  Today, memory is cheap.

Noel

"Frank Andreas de Groot" <nospam@nospam.com> wrote in message news:<b57d9.17394$sR2.307156@news4.ulv.nextra.no>...
> "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> news:3D74F026.77355BAC@xilinx.com...
> >
> > c, or c++ is a single thread, single process language.
> 
> The tools we are talking about extend a subset of C to include keywords for
> paralellism,
> and JAVA (Forge) has built-in mechanisms to work with threads.
> 
> > For example, to try to use a c program for a DSP application that ran on a
> > popular DSP uC, and retargeting it for an FPGA might be a real
>  dissapointment
> > (been there, done that).
> 
> I don't doubt that. But some niche markets benefit greatly from a C/JAVA to
> HDL converter.
> I want to make a PCI addin card with a FPGA-based coprocessor for a
> massively parallel problem.
> As long as it approaches the speed of an equivalent implementation on an
> ordinary CPU, it is comercially justified.
> To replace a motherboard with a dual-Pentium for example would be more
> expensive for the customer,
> not to mention that most customers would not be able/willing to do that for
> the sake of my product.
> 
> I think that for most purposes, a HDL will remain into the far future the
> method of choice to design ASIC's or FPGA's, but there is an emerging market
> that has much less strict demands for speed of execution as opposed to speed
> of implementation.
> 
> It may be that in the future, there will be very clever optimizers for VHDL
> that can turn the stuff that comes out of a C --> VHDL converter into
> something efficient.
> Who knows what software improvements will bring us? A large library of VHDL
> used by such a converter, advanced optimization techniques etc. And there
> will be many directives that can be used to 'hint' the converter on what
> kind of hardware should be generated, constraints that can optionally be
> specified etc. Just because it's extremely hard to make such a tool doesn't
> mean that it won't be done...
> 
> Frank

Article: 46602
Subject: Question for Verilog
From: "Reala" <->
Date: Wed, 4 Sep 2002 17:50:46 +0800
Links: << >>  << T >>  << A >>
Dear all,

I write a code for modelsim in netlist formal.
eg:
mux mux1(muxout,0,yi,xi,si,xj,yj);
The simulation is OK.

However, it is a warning for "0" in Xilinx Webpack for systhesis.
Actually,I want to connect this to "Gnd" or VCC".
How can I do?
Moreover I would like to find a library guide for Spartan-II XC2S200,
because my design in netlist format. I try to search in xilinx webpage but I
cannot find the information i want.

Sorry for the simple question.

Reala



Article: 46603
Subject: Re: Hardware Code Morphing?
From: "Ketil Malde" <ketil+@ii.uib.no>
Date: 04 Sep 2002 13:14:49 +0200
Links: << >>  << T >>  << A >>
robertwessel2@yahoo.com (Robert Wessel) writes:

> nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<al0fks$in9$2@agate.berkeley.edu>...

>> Well, it handled MOST of the OS, IIRC.  I seem to recall the portable
>> NT relying very heavily on a 486 emulator.

> Hardly.  NT booted, and ran, natively on non-x86 systems since day one
> (when it was NT 3.1 running on MIPS and x86).  Of course, the non-x86
> NT systems would not run x86 Win32 binaries.  They *did*, however,
> have a 16 bit x86 emulator so that they could run DOS and Win16
> applications (obviously the x86 versions used the real hardware to run
> Win16 and DOS applications).  Until DEC shipped FX!32 for NT (Alpha),
> there was never any x86 (Win32) capability on non-x86 versions of NT.

Wasn't there also some x86 emulation (somehow 'PALcode' pops up in my
mind?) in order to initialize PCI (VGA?) cards?

Hardly useful for applications, I bet.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

Article: 46604
Subject: PPC blocks in XC2VP50
From: "Neeraj Varma" <neeraj@cg-coreel.com>
Date: Wed, 4 Sep 2002 18:05:40 +0530
Links: << >>  << T >>  << A >>
Hi,

The Virtex-II Pro datasheet says that there are 2 PPC blocks in XC2VP50,
whereas in the Xilinx Floorplanner, as well as in the Synplicity Amplify
floorplanner, 4 PPC blocks are visible.

Can Xilinx clarify which is correct, and if the data sheet is correct, what
are the files (speed files etc.) needed to have the correct floorplan in
Xilinx tools? How can we get those files?


--Neeraj




Article: 46605
Subject: Re: Any resource about MCU and DSP
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 4 Sep 2002 06:02:11 -0700
Links: << >>  << T >>  << A >>
"Reala" <-> wrote in message news:al49mj$j1m7@imsp212.netvigator.com...
> I want to develop a simple MCU and DSP chip with FPGA.
> Apart from Opencore, any other resource in internet for me to learn "How
to
> design MCU/DSP" step by step? or any suggest for me?

Some resources for you:

The 4- and 8-bit MCUs in Dave Vanden Bout's Practical Xilinx Designer Lab
Book.

Ken Chapman's Creating Embedded Microcontrollers series
http://www.xilinx.com/support/techxclusives/PSM-techX25.htm

fpgacpu.org, fpgacpu.org/links.html, the fpga-cpu mailing list
(yahoogroups.com/group/fpga-cpu), and the Circuit Cellar article series
Designing a RISC System-on-a-Chip in an FPGA,
fpgacpu.org/papers/xsoc-drafts.pdf.

Jan Gray, Gray Research LLC




Article: 46606
Subject: Re: Hardware Code Morphing?
From: Robin KAY <komadori@myrealbox.com>
Date: Wed, 04 Sep 2002 14:26:08 +0100
Links: << >>  << T >>  << A >>
Ketil Malde wrote:

> Wasn't there also some x86 emulation (somehow 'PALcode' pops up in my
> mind?) in order to initialize PCI (VGA?) cards?

PALcode (Privileged Architecture Library Code) is library of horizontal microcode routines that abstract the
operating system from specifics of the processor implementation (i.e method for loading TLB entries, etc...). It
has nothing to do with x86 emulation.

The ARC console firmware however, implements a simple x86 emulator to execute the VGA BIOS initialization code and
emulate an int 10.

--
Wishing you good fortune,
--Robin Kay-- (komadori)



Article: 46607
Subject: Handel-C: Undeclared identifier
From: govind.kharbanda@sli-institute.ac.uk (Govind Kharbanda)
Date: 4 Sep 2002 06:29:29 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm getting a compile-time error of an undeclared identifier 'stages',
even though it is declared within the only macro proc in which it is
used (I highlighted all occurrences of it within DK1).  I have tried
declaring it within the mdct_initialise function which calls the macro
procs, but the problem persists.

Below is the 'paraphrased' code, which I've tried to keep as short as
possible, whilst maintaining the original structure.  Broadly
speaking, 'stages' is declared within macro proc mdct_butterflies,
which is called from macro proc mdct_hardware_backward, which itself
is called from main.

Cheers,
Gov

[headers, libraries and so on snipped]

/*
 * Declarations of Handel-C functions
 */

void mdct_hardware_initialise(void);      /* Read in lookup tables */
macro proc mdct_butterfly_8(x);               /* 8 point butterfly */ 
macro proc mdct_butterfly_16(x);             /* 16 point butterfly */
[rest snipped]

/*
 * Global lookup tables. Block sizes. Input and output blocks.
 */

ram <signed int> trig_256[320]    with {block = 1};
[rest snipped]
unsigned int n = 256;
[rest snipped]
signed 32 inp[n<-9];   // input block (using 'n' complains that value
is not constant)
signed 32 out[n<-9];   // output block (using 'n' complains that value
is not constant)

/*
 * Main program
 */

void main(void)
{
/*
 * Initialise lookup tables
 */

  mdct_hardware_initialise();

/*
 * Perform transformation
 */

  mdct_hardware_backward(n, inp, out);
}

void mdct_hardware_initialise(void)
{
  /*
   *  read in trig array into block ram (block = 1)
   *  read in bitrev array into lookup tables (block = 0)
   */

  chanin <signed int> input_trig_256 with { infile = "trig_256.dat" };
  [snip]
  unsigned int 13 i;  // index for looping arrays
  unsigned int x1, x2, j, n2, n4, T, stages;
  int r0, r1, r2, r3;
[snip: no calculations actually performed using any of above variables
other than i]
}

macro proc mdct_butterflies(n, x, points) /* x is index to out */
{
  /*
   * call butterfly routines
   * originally an inline function to reduce function call overhead
   * coded here as a macro procedure for same benefits
   */

  par
  {
    unsigned int T;      /* index to init->trig */
	unsigned int stages; /* conventional variables */
	int i;
	int j;
  }

  if (n == 256)
    stages=3; /* 8-5 */
  else
    stages=6; /* 11-5 */

  par
  {
  /*
   * originally 'if (--stages>0}'
   * N.B. parameters in function call may need changing
   */

    if (stages>1) mdct_butterfly_first(T,x,points);
    stages--;
  }

  /* for loop */

  par
  {
    stages--;
    i=1;
  }

  do{

    par{
      for(j=0;j<(1<<i);j++)

  /*
   * again, parameters in function call may need changing
   */
  	    mdct_butterfly_generic(T,x+(points>>i)*j,points>>i,4<<i);

     i++;
    }

  }while(stages>0);

  j=0;
  do{

    par
	{

  /*
   * again, parameter in function call may need changing
   */
      mdct_butterfly_32(x+j);
	  j+=32;
    }

  }while(j<points);

} /* end macro proc mdct_butterflies(n, x, points) */

macro proc mdct_hardware_backward(n, inp, out)
{

/*
 * Perform inverse MDCT
 */
  
  unsigned int n2, n4, iX, oX, T;

  par
  {
    n2 = n>>1;
    n4 = n>>2;
  }

  /* rotate */

  /*
   * set up indexes
   */

  par
  {
    iX = n2-7;
    oX = n2+n4;
    T = n4;
  }

  do{
    oX -= 4;

    par
	{
	  out[oX]   = MULT_NORM (-inp[iX+2] * trig_256[T+3] - inp[iX+0] *
trig_256[T+2]);
[snip]
        }while (iX>=0);
[snip even more]
  /*
   * Perform butterflies calculation and bit reversal
   * Note that the first parameter has been changed from
   * structure 'init' to integer 'n' as the lookup tables
   * are now in ROM and do not have to be passed as a pointer
   */

  mdct_butterflies(n, n2, n2); // second parameter changed from out+n2
to just n2
  mdct_bitreverse(n, out);

[snip rest of function]  	
}

Article: 46608
Subject: Synplify and FPGA Express translates clock from normal I/O differently
From: Utku Ozcan <utku.ozcan@netas.com.tr>
Date: Wed, 04 Sep 2002 16:49:31 +0300
Links: << >>  << T >>  << A >>

Technology is Xilinx XC95288XL-7-PQ208C.

I can't connect clock signal from a normal I/O to a FF and logic
at the same time.

FPGA Express 3.4.0.5124 output of Verilog code below doesn't cause any error
in Xilinx tools.

Synplify v7.1 output of Verilog code below causes hitop program to terminate
with hi811 error. If I use IBUF/BUFG combinations, NGDBUILD terminates with
NgdBuild:455 and NgdBuild:466 errors.

Is there any workaround for this?

=== Verilog code ===
...
input CLOCK;
input ANOTHER_CLOCK;
input BLA_BLA;
...

always @(CLOCK or ANOTHER_CLOCK or BLA_BLA)
 if (BLA_BLA == 1)
  new_CLOCK <= CLOCK;
 else
  new_CLOCK <= ANOTHER_CLOCK;

 always @(posedge CLOCK)
   xxx <= yyy;

=== end of code ===

Utku

Article: 46609
Subject: Handel-C: Undeclared identifier: take2
From: govind.kharbanda@sli-institute.ac.uk (Govind Kharbanda)
Date: 4 Sep 2002 07:16:51 -0700
Links: << >>  << T >>  << A >>
I have solved the 'undeclared identifier' problem by:

* removing the 'par' statement around the variable declaration
* declaring the variables in main as well as in the macro procs.

However I now get a new error: 'object cannot be assigned to'.  This
seems to be cropping up everywhere so I guess I'll have to look at the
code in some depth before I try and find a suitable example.  If
anyone is brave enough to look at the code, I've uploaded it to

http://www.sli-institute.ac.uk/~gk/mdct.hcc

It will also appear at some point on my TWiki page at
http://www.sli-institute.ac.uk/project/motorola_projects/twiki/bin/view/H2/WebHome

Cheers,
Gov

Article: 46610
Subject: Re: Actel Proto Boards
From: "Eric Braeden" <braeden@erinet.com>
Date: Wed, 4 Sep 2002 10:20:41 -0400
Links: << >>  << T >>  << A >>

"Gregory C. Read" <readgc@xxxhotmail.com> wrote in message news:clid9.5530>
Any plans for a 6809 core?
>
> --
> Greg
> readgc@xxxhotmail.com
> (Remove the 'xxx' to send Email)
>
I like the old 6809 too, but a real one is a lot cheaper. :(




Article: 46611
Subject: Re: Altera APEX clock problem
From: Prager Roman <rprager@frequentis.com>
Date: Wed, 04 Sep 2002 14:32:49 GMT
Links: << >>  << T >>  << A >>
Lähteenmäki Jussi <jusa@students.cc.tut.fi> wrote:
> Hello,

> Im using The Altera Excalibur kit with APEX 20k and have the following 
> problem regarding clocks. My Design uses two clocks, one for the NiOS 
> module (33MHz)  and one for my own module (VHDL, speed varies). It's 
> really just a test on how to transfer data between asynchronous clock 
> domains. The problem is that whenever I use the my module with a clock 
> slower that 11MHz, the block won't work. Nothing seems to happen (I've 
> checked a few signals with logic analyzer). Are there things to consider 
> during synthesis when using clocks that are considerably slow? Im using 
> Quartus II. Between 11MHz and 100MHz the design works fine...
hmm... 
you should tell us a little bit more about your design.
Are you using dedicated pins or a PLL for your module?
> regards, 
> -- 
> Juza

Article: 46612
Subject: Re: PPC blocks in XC2VP50
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 04 Sep 2002 08:04:39 -0700
Links: << >>  << T >>  << A >>
Neeaj,

The 2VP50 PPC count was reduced to 2 from 4.

The largest family member still has 4 PPC.

Contact the hotline or your FAE for the updates.

The changes to the speeds files are very minor (the PPC is not a large area).

Austin


Neeraj Varma wrote:

> Hi,
>
> The Virtex-II Pro datasheet says that there are 2 PPC blocks in XC2VP50,
> whereas in the Xilinx Floorplanner, as well as in the Synplicity Amplify
> floorplanner, 4 PPC blocks are visible.
>
> Can Xilinx clarify which is correct, and if the data sheet is correct, what
> are the files (speed files etc.) needed to have the correct floorplan in
> Xilinx tools? How can we get those files?
>
> --Neeraj


Article: 46613
Subject: CLK DLL problem
From: Fabien Arrive <fabien.arrive@sacet.com>
Date: Wed, 04 Sep 2002 17:38:46 +0200
Links: << >>  << T >>  << A >>
Xilinx Virtex E - Foundation 4.2 Tools

I made a block to generate a CLKx2 by using a clk dll. The timing
simulation step is running without any problem.
When I use this block in another design, I got this error message during
the implementation step :
"Signal "CLK" is used as the clock in one or more OFFSET specifications,
but this signal is not connected directly to a pad. An OFFSET
specification must be relative to pad signals."
How to use clk dll to avoid this message ?

Thank you.

Fabien





Article: 46614
Subject: Re: Altera APEX clock problem
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Wed, 4 Sep 2002 16:40:29 +0100
Links: << >>  << T >>  << A >>

> > Are there things to consider
> > during synthesis when using clocks that are considerably slow? Im using
> > Quartus II. Between 11MHz and 100MHz the design works fine...
> hmm...
> you should tell us a little bit more about your design.
> Are you using dedicated pins or a PLL for your module?

For instance the PLLs don't work with lower frequencies (certainly at 10MHz
and below, but possibly limited to even higher frequency depending on pll
configuration.)

Check the Apex20KE datasheet and the sectionon clock lock/boost.

Paul



Article: 46615
Subject: xilinx contact with regard to qpro
From: "Gaga" <blah@blah.org>
Date: Wed, 4 Sep 2002 11:15:39 -0500
Links: << >>  << T >>  << A >>
I am a graduate student at Texas A&M University. We are building a fpga
based device for space applications. Originally the plan was to use the
virtex qpro line. But some people we talked to suggested that actel line
would be better in terms of radiation characteristics and reliability. Does
any one have any previous experiences with either brands? Or if you are from
xilinx or actel do you know whom I should contact to acquire further
information on this matter?



Article: 46616
Subject: Re: Any resource about MCU and DSP
From: jerry@quickcores.com (Jerry D. Harthcock)
Date: 4 Sep 2002 09:24:26 -0700
Links: << >>  << T >>  << A >>
"Reala" <-> wrote in message news:<al49mj$j1m7@imsp212.netvigator.com>...
> Dear all,
> 
> I want to develop a simple MCU and DSP chip with FPGA.
> Apart from Opencore, any other resource in internet for me to learn "How to
> design MCU/DSP" step by step? or any suggest for me?
> Thanks you.
> 
> Reala

Just do it.

Try to avoid the most common pitfall -- leaving out the embedded debug
solution.

Your MCU/DSP design should actually be a JTAG real-time monitor/debug
shell in disguise.  If your MCU/DSP is going to be completely embedded
and you don't have the embedded debug solution, your design will be
rendered unusable for the most part.

Therefore, I would first try to learn as much as I could about
embedded debug methodology, especially JTAG methodology.  Once you
have a handle on embedded debug, adopt a method and stick with it so
your debug software is easily retargetable from one architecture to
the next.

A good way to learn about FPGA-embeddable micros and embedded debug is
to try someone elses IP and tool set.  This is primarily what
QuickCores Musketeer IP delivery system was developed for.  It's a low
cost and very "entry level" platform. It's based on Actel's ProASIC+
"re-programmable ASIC", features free downloadable ready-made
microcontroller reference designs based on the 68HC05, 16C5x and a
proprietary 9-bit RISC, and all supported by a single source-level
debugger.

Jerry

Article: 46617
Subject: Re: Actel Proto Boards
From: "Gregory C. Read" <readgc@xxxhotmail.com>
Date: Wed, 04 Sep 2002 16:54:51 GMT
Links: << >>  << T >>  << A >>


"Eric Braeden" <braeden@erinet.com> wrote in message
news:3d7616b1$0$1433$272ea4a1@news.execpc.com...
>
> "Gregory C. Read" <readgc@xxxhotmail.com> wrote in message
news:clid9.5530>
> Any plans for a 6809 core?
> >
> > --
> > Greg
> > readgc@xxxhotmail.com
> > (Remove the 'xxx' to send Email)
> >
> I like the old 6809 too, but a real one is a lot cheaper. :(
>

I agree. But they are out of production, AFAIK. If I'm wrong, I would sure
like to know who's making them.

--
Greg
readgc@xxxhotmail.com
(Remove the 'xxx' to send Email)



Article: 46618
Subject: Re: xilinx contact with regard to qpro
From: "Steve Casselman" <sc@vcc.com>
Date: Wed, 04 Sep 2002 17:10:53 GMT
Links: << >>  << T >>  << A >>
The raditation guru at Xilinx is Carl Carmichael. Look at the app notes on
the subject at Xilinx.
http://support.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Military+%2
6+Aerospace

Steve Casselman


"Gaga" <blah@blah.org> wrote in message news:al5bim$f9o$1@news.tamu.edu...
> I am a graduate student at Texas A&M University. We are building a fpga
> based device for space applications. Originally the plan was to use the
> virtex qpro line. But some people we talked to suggested that actel line
> would be better in terms of radiation characteristics and reliability.
Does
> any one have any previous experiences with either brands? Or if you are
from
> xilinx or actel do you know whom I should contact to acquire further
> information on this matter?
>
>



Article: 46619
Subject: ARC-PCI Board
From: Bill Bishop <wdbishop@ece.uwaterloo.ca>
Date: Wed, 4 Sep 2002 13:17:38 -0400
Links: << >>  << T >>  << A >>

I was just wondering if any papers have ever been published that discuss
the ARC-PCI Board developed by the Altera Programmable Hardware Development
Program in the late 1990s.  I'd like to have a few references to the board
in my thesis so that I don't have to document the entire board design,
device driver architecture, and development flow.

Any pointers to references, technical reports, or theses that mention the
ARC-PCI Board would be appreciated.

Thanks in advance,
Bill.
----------------------------------------------------------------------------
William Bishop, B.A.Sc., M.A.Sc.      http://www.pads.uwaterloo.ca/~wdbishop
----------------------------------------------------------------------------


Article: 46620
Subject: Re: Actel Proto Boards
From: jerry@quickcores.com (Jerry D. Harthcock)
Date: 4 Sep 2002 10:34:58 -0700
Links: << >>  << T >>  << A >>
"Gregory C. Read" <readgc@xxxhotmail.com> wrote in message news:<clid9.5530$YL.3259@nwrddc01.gnilink.net>...
> "Jerry D. Harthcock" <jerry@quickcores.com> wrote in message
> news:c4cfbb5c.0209030916.415f8e44@posting.google.com...
> 
> >
> > QuickCores offers the cores in synthesizable Verilog netlist format
> > under separate license.  Hook up is straightforward.  You simply
> > instantiate at the top level the CPU, memory, I/O, and whatever other
> > modules you need for your application.  We're working on an object
> > oriented builder which will allow you to do this automatically.
> >
> > On the Musketeer, the ProASIC+ is fed with a 24.5 MHz clock (see data
> > sheet at QC web)from the Musketeer's built-in "helper" micro.  For the
> > Q68HC05 soft core, this equates to 12.25 MIPs (single cycle
> > instructions).  If implemented in anti-fuse such as QuickLogic
> > QuickDSP or Actel for example, it's about 2x that.
> >
> > Jerry
> 
> 
> Any plans for a 6809 core?

Not at this time.

Article: 46621
Subject: why the need for HIGH speed design?
From: hristostev@yahoo.com (hristo)
Date: 4 Sep 2002 10:55:15 -0700
Links: << >>  << T >>  << A >>
in image processing and with color PAL , 33.32 Mhz is enough to do real time, 
with less image size, the sufficient speed is much less
so why the need for higher speed?

any practical  cases

Article: 46622
Subject: Virtex-2 BRAM
From: floreq10@hotmail.com (flora)
Date: 4 Sep 2002 11:07:02 -0700
Links: << >>  << T >>  << A >>
Hello,

<<
The RAMB16_Sm_Sn components listed in the following table are
dual-ported dedicated random access memory blocks with synchronous
write capability. Each block RAM port has 16384 bits of data memory.
Ports configured as 9, 18, or 36-bits wide have an additional 2048
bits of parity memory. Each port is independent of the other while
accessing the same set of 16384 data memory cells. Each port is
independentlyconfigured to a specific data width. The possible port
and cell configurations are listed in the following table.>>
 

could someone explain me please what it means from 
<<Ports configured as 9, 18, or 36-bits wide have an additional 2048
bits of parity memory.>>

many thanks

Article: 46623
Subject: Re: xilinx contact with regard to qpro
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 04 Sep 2002 11:24:24 -0700
Links: << >>  << T >>  << A >>
Gaga,

We are happy to work with you on how to use our FPGAs in space.

"better" form a radiation point of view can mean many things.

The most serious issues of latchup, and eventual dossage causing total failures
are of course the first issues that must be dealt with.  This is done by using
the QPRO line of rad hard parts.

Next comes the single even upsets of flip flops and gates in the logic, which
lead to transient errors in the function of the device.

Finally comes the single event upsets which change the memory cells, and the
function of the device.

Techniques exist to design with triple modular redundancy (TMR) to get around
the SEU effects on logic and configuration, and by designing such that one
continually reconfigures the part, even momentary configuration changes are
corrected within a few ms without an error (due to TMR).

Use of the block RAM requires ECC logic to find and correct errors.

In short, there is nothing to prevent you from using our FPGAs in space
appliciations, once you know how to do it.

The huge density of our components is a tremendous advantage, as even though the
TMR and ECC require more logic, we have much larger parts than the fusable PLDs
(which actually need TMR and ECC to be as reliable as us anyway).

Austin



Gaga wrote:

> I am a graduate student at Texas A&M University. We are building a fpga
> based device for space applications. Originally the plan was to use the
> virtex qpro line. But some people we talked to suggested that actel line
> would be better in terms of radiation characteristics and reliability. Does
> any one have any previous experiences with either brands? Or if you are from
> xilinx or actel do you know whom I should contact to acquire further
> information on this matter?


Article: 46624
Subject: Re: Virtex-2 BRAM
From: Ray Andraka <ray@andraka.com>
Date: Wed, 04 Sep 2002 18:40:06 GMT
Links: << >>  << T >>  << A >>
There is a parallel 2Kbit  memory to the 16Kbit memory that is only
accessible when the port is 8,16 or 36 bits wide (the added memory has
the same number of address bits and an aspect ratio of 1,2 or 4 bits
respectively).  This is nominally for parity bits, but is also useful
for working with word widths of slightly greater than the nominal memory
widths.

flora wrote:

> Hello,
>
> <<
> The RAMB16_Sm_Sn components listed in the following table are
> dual-ported dedicated random access memory blocks with synchronous
> write capability. Each block RAM port has 16384 bits of data memory.
> Ports configured as 9, 18, or 36-bits wide have an additional 2048
> bits of parity memory. Each port is independent of the other while
> accessing the same set of 16384 data memory cells. Each port is
> independentlyconfigured to a specific data width. The possible port
> and cell configurations are listed in the following table.>>
>
>
> could someone explain me please what it means from
> <<Ports configured as 9, 18, or 36-bits wide have an additional 2048
> bits of parity memory.>>
>
> many thanks

--
--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





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