Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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... > > FrankArticle: 46602
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. RealaArticle: 46603
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 giantsArticle: 46604
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? --NeerajArticle: 46605
"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 LLCArticle: 46606
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
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: 46608Technology 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 === UtkuArticle: 46609
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, GovArticle: 46610
"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
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, > -- > JuzaArticle: 46612
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? > > --NeerajArticle: 46613
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. FabienArticle: 46614
> > 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. PaulArticle: 46615
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
"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. JerryArticle: 46617
"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
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
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
"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
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 casesArticle: 46622
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 thanksArticle: 46623
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
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:
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