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
Hi Johnson, > You mentioned "although some multiplexing of resources might be required." > Could you please explain it in a little bit more detail? I think he means that after sampling, there's a data stream going through the FPGA at 370MHz (if we do need to stick to the Nyquist frequency). This is possible, but not easy to sustain. Therefore, if the algorithm allows it, it may be easier to split (multiplex) the data into a number (say 4) of data streams running at the inversely reduced (i.e. 1/4th in this case) frequency, possibly recombining (demultiplexing) the sample streams after some sort of decimation. Just my $.02 BenArticle: 86176
Sinking 1.6 mA and sourcing 400 uA is a very easy task for modern CMOS outputs. they are usually specified for much higher currents (or lower output resistance). The bigger input issue is: what happend when the input is driven High. Many CMOS pins have a diode directly connected to their Vcc, which will be driven to conducting current by any input voltage above 4 V ( or even 3.6 V at extremes). That's where the 100 Ohm current-limiting-resistor idea comes from. Peter AlfkeArticle: 86177
Hi methi,
> HDET_REG : DFF;
>
> Its been used in the code as follows:
>
> HDET_REG.CLK = DIGRESET;
> HDET_REG.D = VCC;
> HDET.REG.CLRN = !HDET;
Firstly, I find this _ugly_.
What happens is that as long as HDET is 1, the Q output of this DFF remains
0. If HDET is 0, the DFF will be set to 1 on the next transition for
DIGRESET from 0 to 1. HDET has a higher priority then DIGRESET and is
asynchronous.
In VHDL you'd write this as
process(DIGRESET, HDET)
begin
if HDET = '1' then
HDET_REG <= '0';
elsif rising_edge(DIGRESET) then
HDET_REG <= '1';
end if;
end process;
Yuck...
Ben
Article: 86178"Mike Harrison" <mike@whitewing.co.uk> wrote in message news:irmfb19n0plvl00ccm5e4p202ik5qhj81p@4ax.com... > On 20 Jun 2005 13:37:10 -0700, "xilinx_user" <barrinst@ix.netcom.com> wrote: > > >Yes. I think we owe a big round of thanks to Peter Alfke and his crew > >for making this happen. > > > >Mike Harrison wrote: > >> Further to recent discussiuons here, I Just noticed That S3s have appeared in the Xilinx web store. > >> A few are even shown as in stock.... > > Hmmm now everything is shown in stock but the parts bigger then 400 have disappeared - I'm sure they > were there at the weekend when I first noticed..... Just FYI, the Spartan-3 XC3S50 through the XC3S1500 FPGAs are all available now via the Xilinx online store at ... http://www.xilinx.com/store or via the following speedy link. http://tinyurl.com/b6gsn Be sure to click the Refresh button on your browser. Also FYI, the Xilinx Online Store primarily services small-volume or prototyping applications. If your project requires larger production volumes with corresponding volume pricing, please contact your local Xilinx distributor or Xilinx sales representative. Xilinx Authorized Distributors http://www.xilinx.com/company/sales/ww_disti.htm Xilinx Sales Representatives http://www.xilinx.com/company/sales/ww_reps.htm Xilinx Sales Offices http://www.xilinx.com/company/sales/sales_offices.htm --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 86179
Just FYI, the Spartan-3 XC3S50 through the XC3S1500 FPGAs are all available now via the Xilinx online store at ... http://www.xilinx.com/store ... or via the following speedy link. http://tinyurl.com/b6gsn Be sure to click the Refresh button on your browser. Also FYI, the Xilinx Online Store primarily services small-volume or prototyping applications. If your project requires larger production volumes with corresponding volume pricing, please contact your local Xilinx distributor or Xilinx sales representative. Xilinx Authorized Distributors http://www.xilinx.com/company/sales/ww_disti.htm Xilinx Sales Representatives http://www.xilinx.com/company/sales/ww_reps.htm Xilinx Sales Offices http://www.xilinx.com/company/sales/sales_offices.htm --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 86180
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> schrieb im Newsbeitrag news:d9chg3$te5@cliff.xsj.xilinx.com... > Just FYI, the Spartan-3 XC3S50 through the XC3S1500 FPGAs are all available > now via the Xilinx online store at ... > http://www.xilinx.com/store > > ... or via the following speedy link. > http://tinyurl.com/b6gsn > > Be sure to click the Refresh button on your browser. > > Also FYI, the Xilinx Online Store primarily services small-volume or > prototyping applications. If your project requires larger production > volumes with corresponding volume pricing, please contact your local Xilinx > distributor or Xilinx sales representative. > > Xilinx Authorized Distributors > http://www.xilinx.com/company/sales/ww_disti.htm > > Xilinx Sales Representatives > http://www.xilinx.com/company/sales/ww_reps.htm > > Xilinx Sales Offices > http://www.xilinx.com/company/sales/sales_offices.htm > > --------------------------------- > Steven K. Knapp > Applications Manager, Xilinx Inc. > General Products Division > Spartan-3/-3E FPGAs > http://www.xilinx.com/spartan3e > --------------------------------- > The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs. > WAU! I did think that largest devices at online starte are (and will be) S3-400, having 1500 also listed is nice move! AnttiArticle: 86181
Hi Ben, Actually I am trying to figure out this AHDL code I have and hence translate it into VHDL... The part of the code , I am tryin to understand and hence implement in VHDL is as follows: IF PD[9..2] == H"FF" THEN TRS0 = VCC; ELSE TRS0 = GND; END IF; IF PD[9..2] == H"00" AND TRS0Q THEN TRS1 = VCC; ELSE TRS1 = GND; END IF; IF PD[9..2] == H"00" AND TRS1Q THEN TRS2 = VCC; ELSE TRS2 = GND; END IF; TRS0LATCH.CLK = PCLK_DIG; TRS0LATCH.ENA = TRS0; TRS0LATCH.D = TRS0; TRS0LATCH.CLRN = TRSRESET; TRS0Q = TRS0LATCH.Q; TRS1LATCH.CLK = PCLK_DIG; TRS1LATCH.ENA = TRS1; TRS1LATCH.D = TRS1; TRS1LATCH.CLRN = TRSRESET; TRS1Q = TRS1LATCH.Q; TRS2LATCH.CLK = PCLK_DIG; TRS2LATCH.ENA = TRS2; TRS2LATCH.D = TRS2; TRS2LATCH.CLRN = TRSRESET; TRS2Q = TRS2LATCH.Q; IF TRS0Q & TRS1Q & TRS2Q THEN XYZ = VCC; ELSE XYZ = GND; END IF; XYZLATCH[].CLK = PCLK_DIG; XYZLATCH[].ENA = XYZ; XYZLATCH[2..0].D = PD[8..6]; XYZQ[] = XYZLATCH[].Q; HSYNC = !XYZQ[0]; FIELD = !XYZQ[2]; TRESETGEN[].CLK = PCLK_DIG; TRESETGEN[].D = TRESETGEN[].Q + 1; TRESETGEN[].CLRN = TRSRESET; TRESETGEN[].ENA = TRS0Q; TCOUNT[] = TRESETGEN[].Q; IF TCOUNT[] == H"3" THEN TRSRESET = GND; ELSE TRSRESET = VCC; END IF; GENHCOUNTER.CLOCK = PCLK_ANA; GENHCOUNTER.SCLR = DIGHRESET; GENCOUNT[] = GENHCOUNTER.Q[]; IF GENCOUNT[] == 2000 THEN HDET = VCC; ELSE HDET = GND; END IF; HDET_REG.CLK = DIGHRESET; HDET_REG.D = VCC; HDET_REG.CLRN = !HDET; HSYNC_REG0.CLK = PCLK_DIG; HSYNC_REG0.D = HSYNC; HSYNC_REG1.CLK = PCLK_DIG; HSYNC_REG1.D = HSYNC_REG0.Q; HSYNC_PULSE = HSYNC_REG1.Q; DIGHRESET = !HSYNC AND HSYNC_PULSE; D_VIDEO_DET = !HDET_REG.Q; DIG_VID_PRES = !HDET_REG.Q; I hope that this is doing nothing but the work of some dflipflops and counter... Thank you, Methi Ben Twijnstra wrote: > Hi methi, > > > HDET_REG : DFF; > > > > Its been used in the code as follows: > > > > HDET_REG.CLK = DIGRESET; > > HDET_REG.D = VCC; > > HDET.REG.CLRN = !HDET; > > Firstly, I find this _ugly_. > > What happens is that as long as HDET is 1, the Q output of this DFF remains > 0. If HDET is 0, the DFF will be set to 1 on the next transition for > DIGRESET from 0 to 1. HDET has a higher priority then DIGRESET and is > asynchronous. > > In VHDL you'd write this as > > process(DIGRESET, HDET) > begin > if HDET = '1' then > HDET_REG <= '0'; > elsif rising_edge(DIGRESET) then > HDET_REG <= '1'; > end if; > end process; > > Yuck... > > > BenArticle: 86182
someone92@hotmail.com wrote: > I'm starting to learn FPGA programming (using a Xilinx Spartan II > 200K). I will use VHDL and already have bought VHDL books, but I think > I also need a general introduction to FPGA so I plan to buy a book on > FPGA. I found this one: > FPGA-Based System Design by Wayne Wolf I went through the same thing and ended up with that same book based on looking at everything available at the local tech bookstore. It's been a while since I picked it up (haven't had time to play with FPGA lately) so I can't really offer any other comment than this looked like the best one available. G.Article: 86183
I am generating a slow serial data stream in response to a input clock. I need to delay n uSec's after detecting the clock edge before I output the data. The input clock is currently running at 10 Khz. I was going to run another process at 1 Mhz but don't know the best way to wait for a delay count in the slower 10 Khz process. Any suggestions? ThanksArticle: 86184
The problem is when you start using the counter bits as clocks. If your clock is simply one of the counter's bits, this is not really a gated clock, there is no problem in terms of that there is no ambiguity of metastability. Honestly I really hate this thing in Quartus as many other warnings, which are far from reality. Try using the same highest clock and counter bits as "clock enable"s. If you designing a UART-like application, this is the way to go. Vladislav "BQ" <spammalatuamamma@gmail.com> wrote in message news:mkfue.16513$yM4.241008@twister2.libero.it... > In my project, which uses an Altera Cyclone EP1C12, I need to generate a > lot of different frequencies, such as f=10Mhz, 1MHz, 2.5MHz, 250kHz, etc. > I used counters but quartus' design assistant complains that I'm using > gated clocks. Are there better solutions than counters to achieve what I > need? Or better ways to implement frequency divisors? > Thank you in advance, > BQArticle: 86185
Does anyone has an example of a user IP core hooked up to the PLB bus for a Virtex 2P in EDK? I am wondering how I can get my core to be connected to the PLB bus in the Virtex 2P anmd controlled it viua Software, I am using Xilinx EDK. Thanks NRArticle: 86186
Ben Jones wrote:
>It's happening already. When you're designing for 300MHz plus, those
>previously-innocuous net delays of 900ps are a massive chunk out of
>your cycle budget. More than once I've ended up with a critical path
>having no levels of logic...
>
>Cheers,
>
> -Ben-
>
>
>
>>P.S. I'm a Xilinx FAE, but writing this in my "off hours".
>>
>>
>
>P.S. I'm a Xilinx design engineer, and I don't get "off hours". :)
>
>
>
>
Shoot nothing new here, I've been pipelining wires when necessary since
my XC3000 days. It is even there as a bullet in some of the performance
tips I published in various places to that effect. If you are pushing
the envelope on FPGA performance, you'll need to do things like
pipelining wires. As true now as it ever was.
--
--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: 86187geoffrey wall wrote: > I using AVNET's Virtex II pro development kit. > They have included a simple memory project with > the board which using xilinx EDK. I want to scrap > their memory controller and EDK based project > (all the implementations are hidden through the use of countless wrappers), Those wrappers are inserted by EDK; they were not put there by Avnet. The actual source code that is being wrapped is in your EDK directory in the hw/XilinxProcessorIPLib/pcores directory. The wrapper used for the SRAM is the opb_emc core, as specified in the system.mhs file: BEGIN opb_emc PARAMETER INSTANCE = my_sram PARAMETER HW_VER = 1.10.b ... So to see the source, in the pcores library, go to the opb_emc_v1_10_b/hdl/vhdl directory. And there it is. Of course, all this assumes you are using a processor. In the case of the Avnet projects, they use the built in PPC processor. It sounds like this is overkill for your case. > and design my own simple memory controller for on board SRAM > and FSM to handle transactions with their PCI bus controller (Spartan IIe) > Does anyone have a suggestion as to how to approach this. I have never > designed a memory controller before... Go to the Cypress website. Download the datasheet, and the VHDL/Verilog models for the SRAM. Put the SRAM HDL model in your testbench and write your interface code. An SRAM is simple to use; it barely justifies being called a "memory controller". You should read the datasheet and do it yourself; you will learn a lot more than asking here.Article: 86188
Philip Freidin wrote: > On 21 Jun 2005 09:40:16 -0700, "Nemesis" <nemesis2001@gmx.it> wrote: > >Maybe my question was not so clear, I just wanted to know if these > >BRAMS that shares routing resources with the Multipliers will be > >available for other cores that need them (like the FFT i.e.). > > The BRAMs are still available when using the co-located multiplier, > except for BRAMs in the widest data path mode. I.E. you can use the > co-located BRAM in x1, x2, x4, x9 mode, but not x18 . > I'm pretty sure the widest mode is x36 and x18 is O.K. with co-located multiplier...Article: 86189
Let's look at the basics: If you have an incoming clock (say 10 MHz in your case) and you want to derive any clock from it, these derived clocks will inevitably be delayed from the original clock, even when you are smart and avoid ripple counters and clock gating. Also, the distribution of your many clocks might use local (instead of global) routing. Whatever you do, you end up with a sloppy clock structure, which invites hold-time problems when the different clock domains have to interact. (If they don't, you really have no problem.) Dumb clock gating can create glitches, mixing non-synchronous clocks can create metastability problem, but even the most careful clock selection scheme is dangerous. Clock Enable avoids all these problems (except the metastability). That's why we all favor CE (except for its higher power consumption). Peter Alfke, Xilinx ApplicationsArticle: 86190
Johnson Liuis wrote:
>Does anybody have filter design experience with FPGA? I would like to know a
>general picture with recent FPGA technologies like XtremeDSP and others. I
>am also curious about the limitation of FPGA design on filter design, like
>the maximum center frequency and bandwidth of the filters that can be
>implemented with FPGA. Could anybody let me know if I am able to simulate a
>SAW (surface acoustic wave ) filter with 185MHz center frequency and 4MHz
>double-side bandwidth, and Max. 20dB insertion loss inside of a FPGA?
>
>Any information will be highly appreciated. Thanks in advance.
>
>Johnson
>
>
>
>
The FPGA doesn't limit your filter design other than max sample rate
(and even then there are work-arounds). The DSP48 slices in Xilinx
Virtex4 can do 500 MS/Sec filters provided the data and coefficients are
18 bits or less and you choose a device with enough DSP48 slices to fit
one slice per filter tap. Remember, an FPGA is simply a medium in which
you realize a digital logic circuit.
As to your particular example, you've got a rather narrow bandpass
filter. Filtering such a narrow band relative to your sample rate is
going to require a high order filter (assuming FIR filter in order to
get the linear phase characteristic of the SAW) if you insist on doing
the filtering at the input sample rate. It is far more efficient to
downcovert the signal to complex baseband, filter it with a 4 MHz low
pass filter and then upconvert it back up to your 185 MHz center
frequency. This way, the filter has a much wider passband relative to
the sample rate, and therefore is much simplier to realize, both in
terms of number of taps (coefficients) and in data rate. The hardest
part of this design would be digitizing the data and getting it into the
FPGA, and that is quite doable.
--
--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: 86191
Marc Randolph wrote:
>Jeremy Stringer wrote:
>
>
>>I'm starting a new project at the moment, and I'm looking at upgrading
>>to ISE 7.1, since I prefer not to change synth/par tool versions
>>mid-project. I noted that a number of people complained about 7.1 when
>>it first came out, but also noted that Service Pack 2 is out now. Can
>>anybody comment on the state of ISE 7.1 at the moment?
>>
>>
>
>Howdy Jeremy,
>
>I don't use Linux, but Windoze based 7.1i has stablized enough that
>chances are slim you'd run into any problems with it - and even if you
>do, they are likely fixed in SP3 (due out in the next week or so).
>
>Have fun,
>
> Marc
>
>
>
Unless you are putting RLOCs on the DSP48's. That is still broken in
SP2. Last version it worked correctly in is ISE6.3 SP3. ise7.1 SP3
fixes that, but has a problem with the C ports on the DSP48 (the C Port
is physically shared by two DSP48 slices, but shows up individually for
each slice in the library. If both DSP48s do not have the same value
tied to the C Port, its CE input and its reset input, the mapper
crashes. If you are careful, that isn't a problem. The problem comes
if one DSP48 uses the Cport and one doesn't, you still have to specify
the same inputs on both. That creates a packing problem unless you've
pre-packed the DSP48s making sure both Cports are wired identically.
--
--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: 86192Hi, kittyawake@gmail.com wrote: > I am not getting a clear undertsanding of the debugging part of > microblaze. I tried reading many docs. but i dont undetsand the diff. > between doing executable and xmdstub. Have you read Chapter 15 of the EDK's Embedded System Tools Refernce Manual (est_rm.pdf, in the edk/docs subdirectory). Read it, then read it again! > 1. If i have a debug module in my system, how does it work to debug my > code? It connects to debug ports on the microblaze core, to directly control and query the CPU. XMD connects via JTAG to the MDM, and the gdb connects to XMD. IT's all explained in the docs, there's a lovely diagram that illustrates how it fits together. > 2.Do i still choose the xmdstub in the compiler settings??? No - you just use executable mode. See the note at the bottom of page 203 of est_rm.pdf (for edk7.1). In fact, you should read pages 199-205 - it's a very clear description of what's required in your MHS, MSS files and how to use XMD. > 3. According to my understanding this xmdstub is a software code which > goes at mem. loc 0x0. But then doesnt it overwrite the interrupt jump > which is at 0x10??? No, xmdstub is located at about 0x100 (or maybe 0x40, not sure, haven't used it in ages). Unless you are very very tight for logic, forget about xmdstub, and use mdm. You will never go back. Hope this helps, JohnArticle: 86193
On 22 Jun 2005 14:40:21 -0700, "Gabor" <gabor@alacron.com> wrote: >Philip Freidin wrote: >> On 21 Jun 2005 09:40:16 -0700, "Nemesis" <nemesis2001@gmx.it> wrote: >> >Maybe my question was not so clear, I just wanted to know if these >> >BRAMS that shares routing resources with the Multipliers will be >> >available for other cores that need them (like the FFT i.e.). >> >> The BRAMs are still available when using the co-located multiplier, >> except for BRAMs in the widest data path mode. I.E. you can use the >> co-located BRAM in x1, x2, x4, x9 mode, but not x18 . >> > >I'm pretty sure the widest mode is x36 and x18 is O.K. with >co-located multiplier... Yes, You are rignt. X18 works fine too, it is x36 that uses up all the fabric interface. Philip Philip Freidin FliptronicsArticle: 86194
In HDL you can do something like this:
module clock_generator(input clk, input resetN, output reg CE_out);
parameter clk_divisor = 1;
reg [3:0] cnt;
always @ (posedge clk or negedge resetN)
begin
if (~resetN)
begin
cnt <= 0; CE_out <= 0;
end
else begin
if (cnt == (clk_divisor - 1))
begin
cnt <= 0; CE_out <= 1;
end
else begin
cnt <= cnt + 1; CE_out <= 0;
end
end
end
endmodule
module top(input clk, input resetN, output reg Q1, output reg Q2);
wire CE1;
wire CE2;
defparam U1.clk_divisor = 10; // generate a CE every 10 clocks
clock_generator U1 (.clk(clk),.resetN(resetN),.CE_out(CE1));
defparam U2.clk_divisor = 5; // generate a CE every 5 clocks
clock_generator U2 (.clk(clk),.resetN(resetN),.CE_out(CE2));
always @ (posedge clk or resetN)
begin
if (~resetN) Q1 <= 0; else if (CE1) Q1 <= ~Q1;
if (~resetN) Q2 <= 0; else if (CE2) Q2 <= ~Q2;
end
endmodule
module tb(); //testbench
reg clk,resetN;
wire Q1,Q2;
initial
begin
resetN <= 0;
clk <= 0;
#10 resetN <= 1;
while (1) #100 clk <= ~clk;
end
top UUT(.clk(clk),.resetN(resetN),.Q1(Q1),.Q2(Q2));
endmodule
Best to always use a single clock whenever possible. If you need to
divide more than 16 you'll have to grow cnt, of course...
Article: 86195Ben Jones wrote: > Interesting! > > >>eg Why do we have HW multipliers & DSP blocks now ? - because they >>are much faster, and lower power, than FPGA fabric solutions. > > > They are also functions with a broad usefulness in a variety of > applications. > The "faster and lower power" argument can be applied to any piece of IP > you care to name; just for certain functions the transition to hard silicon > makes sense - multipliers, DSP, SERDES, Ethernet MACs, etc. I'm not > quite convinced (yet!) that this is true of MicroBlaze/Nios (yet!). The NiosII is relatively new ( as lifelines go ) so not for 2005, but for 2006, or 2007 - imagine a low end Cyclone, with NIOS in the corner ? > > >>>What's wrong with the PowerPC core? >> >>Let's see - Price, die area.... > > > The price premium of FPGAs with hard processor IP is artificial and it > will be eroded in time. The efficiency of a hard microblaze/Nios in terms > of MIPS/mm^2 will surely, surely be much worse than that of a > processor core that was designed specifically for 90nm. Why ? NIOS and Microblaze are fpga resource optimised, but that is not mutually exclusive to any process level. Altera will have numbers already on what a simple hardcopy NIOS port does, and probably also a good idea on what a little effort can do, were they to make it a more tuned HW cell. My guess is we will see this [HW FPGA.Cpu] first from Altera, as they do not have a PPC, and already have the flows. <snip> > > Was your "soft-boundary" idea intended to stay on a single die? That would > certainly be interesting, maybe even useful in limited contexts. Yes. Look at the ST STW22000 device, the Cell processor?, and the Triscend devices. They all focus on the approach that "some FPGA is a good idea". Most discussion here is ASIC _OR_ FPGA - but why not offer both ? - start to be intelligent about what resource moves to HW/ASIC, and what stays in the smaller/simpler FPGA corner of the die ? The tools are probably good enough now, the flows are proven. I think the new Xilinx Strip die/flip chip would make this relatively easy to do, engineering wise. The politics is another matter :) -jgArticle: 86196
Steven K. Knapp wrote: <snip> > Also FYI, the Xilinx Online Store primarily services small-volume or > prototyping applications. If your project requires larger production > volumes with corresponding volume pricing, please contact your local Xilinx > distributor or Xilinx sales representative. Can you put some numbers on that ? If we accept that 250,000 or 500,000 pcs in 2006 is largish volumes, what is the Xilinx threshold for "small-volume" ? Is it a price threshold, or a units threshold, and what happens if you go over it ? -jgArticle: 86197
Hi, Is anyone aware of a real (that is -- actually available) Z180 or 64180 core where the peripherals have all (or even mostly) been implemented. There are obviously some Z80 cores around, but they are just CPU's. TIA, -- Regards, Gavin Melville gavin.melville@acclipse.co.nzArticle: 86198
Hi All, I just tried GSRD design for ML403 from Xilinx web site. Did smbd in Xilinx make final test at all? I'm using ISE7.1sp2 and EDK7.1sp1. Bit file compiles fine. When I tried to start XMD from XPS environment, program didn't starts (I tried supplied downloads elf files also). After several hours of attempts I tried to start Xilinx Shell first and then typed XMD. Magic - it works! Next story is building soft application treck and xlltemac_tx_rx. It fails. Found misspelling in (upper case -lower case) in ll_temac_v1_00_b driver (xlltemac.c) for XLLTEmac_PhyInit function. Now it works. At least processor running. Will start to play with ref design itself. leevv PS. I did test ml403_emb_ref_ppc design before under ISE6.3sp3. It was working. Now it fails on PAR. Does anybody knows whats wrong?Article: 86199
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:42b9f603@clear.net.nz... > Steven K. Knapp wrote: > > <snip> > > Also FYI, the Xilinx Online Store primarily services small-volume or > > prototyping applications. If your project requires larger production > > volumes with corresponding volume pricing, please contact your local Xilinx > > distributor or Xilinx sales representative. > > Can you put some numbers on that ? > If we accept that 250,000 or 500,000 pcs in 2006 is largish volumes, > what is the Xilinx threshold for "small-volume" ? > > Is it a price threshold, or a units threshold, and what happens if you > go over it ? > > -jg The Xilinx Online Store offers products for near-term delivery, essentially at the single-unit pricing. While we would be more than happy to ship thousands of units at that price, you will receive better pricing through one of our world-wide sales partners for volumes exceeding 25 units. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.
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