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
see below, plz. Dick On Sun, 25 Nov 2001 04:10:13 GMT, Peter Alfke <palfke@earthlink.net> wrote: >Dick, the way I understand this, you have a continuously running counter >that sampels incoming data. Every 16 clock ticks you dump the assembled data > Actually, I want a 22-bit synchronous and monotonic counter, the outputs of which are valid for every count, as I need them for addressing the buffer RAM. I also need this to fit into a PLCC-84 package. I don't believe there's a part that fits in the PLCC-84 that also has enough RAM space. (Perhaps an updated databook would help me here ... My last one's from 1999). There's good economic reason for the PLCC package, but it's not relevant to this discussion. The counter doesn't run all the time, and it uses the MSB as a count-disable. When it's reset, it runs until the MSB is set. >word into a DRAM ( why not SRAM, which would save you the fancy control and >the refresh ? And in Virtex-II you could easily store it in the BlockRAMs >inside...) Have you got parts that one can afford, costing less than 10x what the DRAM costs and with 512KB of RAM available in a package one can use at reasonable cost in quantities numbered in dozens rather than multiples of 1k/week? >Absolutely under all circumstances use a modern FPGA with dedicated carry, >like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II. >Depending on the family, the carry delay is between 50 and 100 ps per bit, >so you should not have any difficulty with your 22 bits. >But if you are very conservative, you can break the counter into a 4-bit >front-end, decode its all-ones state (F), and use it as a count enable for >the remaining 18 bits.This is all very easy, and is totally synchronous. It >does not create any pipeline delay or other funnies. Your code is all >binary, like you want it to be. > Yes, the current stuff is all that's under consideration, though I'm looking at some CPLD's as well because the logic is actually pretty simple. The problem is simply in getting a long enough counter that runs at the desired speed without having too many pins on the package and the associated cost per pin. Once the package is bigger than the PLCC-84 the costs associated with using the package seem to go through the roof for a number of reasons. I know I can shorten the counter by separating the > >Have fun! > >Peter Alfke, Xilinx Applications >============================ >Richard Erlacher wrote: > >> Well, OK ... Let's try this. >> >> We have a data stream that has to be sampled at 120 MHz, assembled >> into words and shoved into an external DRAM. The DRAM is small >> (256Kx16) and the data will be assembled and then registered as words >> before being pipelined off into the RAM. States of the fast end of >> the counter have to be decoded in order to synchronize the operation >> with the RAM, and the MSB of the counter is a "DONE" bit. When the >> counter is reset, it runs until the msb, used as the count enable, >> goes true. That's a 22-bit counter ... Not terribly long, but long >> enough. I suppose this could be done as 3-bit counter and a 19-bit >> counter, but, either way, it's painful. The DRAM access has to be >> done in short (page-mode) bursts, which is why the synchronization of >> the decoding of the lower 3-bit section of the counter is critical. >> >> How close to the required 120 MHz can this counter be made to go in an >> FPGA with 5-volt-tolerant I/O? It's got to be synchronous and the >> sequence has to be monotonic, so the same counter will be useable to >> accomplish refresh as required. LFSR's don't produce that sort of >> sequence. What other alternatives are there? >> >> Dick >> >Article: 36926
Rick, I was having a bad week last week, so I apologize to everyone for my curt comments. I will say that I get tired of people asking me the same question over and over, and the joke around here is to answer every question with: "Did you simulate it?" And, as I said before, we do simulate test cases, and real pcb's for our customers through the hotline. The full blown HyperLynx form Innoveda is less than one proto run of the pcb boards. Now, how can you argue with that? You say to your boss (or the company you are contracting for), "I need this tool. It costs about the same as one proto run of boards - fab, parts, assembly. If I have this tool, the number of times we go through the task of building boards is reduced by at least ONE. In the future, with experience, the number of board turns will almost never exceed ONE (at least for signal integrity reasons!)" The demo on Innoveda's website for HyperLynx is free. It doesn't allow you to store, or print, or load new IBIS files, but it is great for "what if I did this..." kind of things. Once you start to use it, you are hooked, and you need to go sell it to your 'cost savings' accounting department (as a true means of lowering costs). I have made the cost argument here, so folks will just go spend some money wisely. There is another argument: can you continue to exist when your competition made their prototypes work in one quarter the time, and at three times less money than you did? Austin Rick Filipkiewicz wrote: > Peter Alfke wrote: > > > Let me make a constructive suggestion: > > > > We will publish a step-by-step cookbook how you can use the free > > version of HypeLynx to analyze output behavior with astounding > > accuracy and surprising ease. > > Do you mean the "demo" version or is there something else I can't see on > the site? I had a look there some while ago but the word "demo" to me > tends to mean next-to-useless. Maybe my cynisism is misplaced in this > case ... > > <snip> > > > > > That's what Austin meant when he mentioned the need to learn how to > > fish. > > Signal integrity is no longer a subject only for the speed-demons, it > > affects every design. > > We all have got lo learn this "new" discipline, whether we want to or > > not. > > And the available tools actually make it fun, once you master them. > > I agree & I want to, finally, start getting to grips with this stuff. In > the past, though, what's tended to put me off is the quantity of $$$s > required to get into it, a bit like simulation & synthesis tools until > ModelSIM-PE & Synplicity came along.Article: 36927
--------------079A41933EB3582B88A78609 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Dick, I suggest the XCS05 or XCS05XL. They come in PLCC84 packages ( we call it PC84) They have a 10 x 10 matrix of Logic Blocks, each with 2 flip-flops. The carry chain runs vertically, so I would create an 18-bit counter in 9 CLBs, and drive the clock enable from the decoded F of the less significant 4 bits. That gives you a synchronous 22-bit counter. Teh carry-chain delay is irrelevant since it has 16 clock ticks to settle. You can make the 4-bit front end run at up to 200 MHz in the -5 speed grade XCS05XL. All this takes less than 15% of the chip, so you can still add a lot of stuff. And the XCS05 ( Vcc=5V) and XCS05XL (Vcc=3.3V) are really cheap., the cheapest FPGAs we make. I would use the 3.3-V -XL device, since it is much faster, and I would not start any new design today with a 5-V device. 5V is definitely obsolete ! State-of-the-art is now 1.5 V. For detailed information, click on: http://www.xilinx.com/partinfo/ds060.pdf Peter Alfke, Xilinx Applications ======================================== Richard Erlacher wrote: > see below, plz. > > Dick > > On Sun, 25 Nov 2001 04:10:13 GMT, Peter Alfke <palfke@earthlink.net> > wrote: > > >Dick, the way I understand this, you have a continuously running counter > >that sampels incoming data. Every 16 clock ticks you dump the assembled data > > > Actually, I want a 22-bit synchronous and monotonic counter, the > outputs of which are valid for every count, as I need them for > addressing the buffer RAM. I also need this to fit into a PLCC-84 > package. I don't believe there's a part that fits in the PLCC-84 that > also has enough RAM space. (Perhaps an updated databook would help me > here ... My last one's from 1999). There's good economic reason for > the PLCC package, but it's not relevant to this discussion. The > counter doesn't run all the time, and it uses the MSB as a > count-disable. When it's reset, it runs until the MSB is set. > > >word into a DRAM ( why not SRAM, which would save you the fancy control and > >the refresh ? And in Virtex-II you could easily store it in the BlockRAMs > >inside...) > > Have you got parts that one can afford, costing less than 10x what the > DRAM costs and with 512KB of RAM available in a package one can use at > reasonable cost in quantities numbered in dozens rather than multiples > of 1k/week? > > >Absolutely under all circumstances use a modern FPGA with dedicated carry, > >like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II. > >Depending on the family, the carry delay is between 50 and 100 ps per bit, > >so you should not have any difficulty with your 22 bits. > >But if you are very conservative, you can break the counter into a 4-bit > >front-end, decode its all-ones state (F), and use it as a count enable for > >the remaining 18 bits.This is all very easy, and is totally synchronous. It > >does not create any pipeline delay or other funnies. Your code is all > >binary, like you want it to be. > > > Yes, the current stuff is all that's under consideration, though I'm > looking at some CPLD's as well because the logic is actually pretty > simple. The problem is simply in getting a long enough counter that > runs at the desired speed without having too many pins on the package > and the associated cost per pin. Once the package is bigger than the > PLCC-84 the costs associated with using the package seem to go through > the roof for a number of reasons. I know I can shorten the counter by > separating the > > > >Have fun! > > > >Peter Alfke, Xilinx Applications > >============================ > >Richard Erlacher wrote: > > > >> Well, OK ... Let's try this. > >> > >> We have a data stream that has to be sampled at 120 MHz, assembled > >> into words and shoved into an external DRAM. The DRAM is small > >> (256Kx16) and the data will be assembled and then registered as words > >> before being pipelined off into the RAM. States of the fast end of > >> the counter have to be decoded in order to synchronize the operation > >> with the RAM, and the MSB of the counter is a "DONE" bit. When the > >> counter is reset, it runs until the msb, used as the count enable, > >> goes true. That's a 22-bit counter ... Not terribly long, but long > >> enough. I suppose this could be done as 3-bit counter and a 19-bit > >> counter, but, either way, it's painful. The DRAM access has to be > >> done in short (page-mode) bursts, which is why the synchronization of > >> the decoding of the lower 3-bit section of the counter is critical. > >> > >> How close to the required 120 MHz can this counter be made to go in an > >> FPGA with 5-volt-tolerant I/O? It's got to be synchronous and the > >> sequence has to be monotonic, so the same counter will be useable to > >> accomplish refresh as required. LFSR's don't produce that sort of > >> sequence. What other alternatives are there? > >> > >> Dick > >> > > --------------079A41933EB3582B88A78609 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Dick, I suggest the XCS05 or XCS05XL. <br>They come in PLCC84 packages ( we call it PC84) <br>They have a 10 x 10 matrix of Logic Blocks, each with 2 flip-flops. <br>The carry chain runs vertically, so I would create an 18-bit counter in 9 CLBs, and drive the clock enable from the decoded F of the less significant 4 bits. <br>That gives you a synchronous 22-bit counter. Teh carry-chain delay is irrelevant since it has 16 clock ticks to settle. You can make the 4-bit front end run at up to 200 MHz in the -5 speed grade XCS05XL. <br>All this takes less than 15% of the chip, so you can still add a lot of stuff. <br>And the XCS05 ( Vcc=5V) and XCS05XL (Vcc=3.3V) are really cheap., the cheapest FPGAs we make. <br>I would use the 3.3-V -XL device, since it is much faster, and I would not start any new design today with a 5-V device. <br>5V is definitely obsolete ! State-of-the-art is now 1.5 V. <p>For detailed information, click on: <p><u><A HREF="http://www.xilinx.com/partinfo/ds060.pdf">http://www.xilinx.com/partinfo/ds060.pdf</A></u><u></u> <p>Peter Alfke, Xilinx Applications <br>======================================== <br>Richard Erlacher wrote: <blockquote TYPE=CITE>see below, plz. <p>Dick <p>On Sun, 25 Nov 2001 04:10:13 GMT, Peter Alfke <palfke@earthlink.net> <br>wrote: <p>>Dick, the way I understand this, you have a continuously running counter <br>>that sampels incoming data. Every 16 clock ticks you dump the assembled data <br>> <br>Actually, I want a 22-bit synchronous and monotonic counter, the <br>outputs of which are valid for every count, as I need them for <br>addressing the buffer RAM. I also need this to fit into a PLCC-84 <br>package. I don't believe there's a part that fits in the PLCC-84 that <br>also has enough RAM space. (Perhaps an updated databook would help me <br>here ... My last one's from 1999). There's good economic reason for <br>the PLCC package, but it's not relevant to this discussion. The <br>counter doesn't run all the time, and it uses the MSB as a <br>count-disable. When it's reset, it runs until the MSB is set. <p>>word into a DRAM ( why not SRAM, which would save you the fancy control and <br>>the refresh ? And in Virtex-II you could easily store it in the BlockRAMs <br>>inside...) <p>Have you got parts that one can afford, costing less than 10x what the <br>DRAM costs and with 512KB of RAM available in a package one can use at <br>reasonable cost in quantities numbered in dozens rather than multiples <br>of 1k/week? <p>>Absolutely under all circumstances use a modern FPGA with dedicated carry, <br>>like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II. <br>>Depending on the family, the carry delay is between 50 and 100 ps per bit, <br>>so you should not have any difficulty with your 22 bits. <br>>But if you are very conservative, you can break the counter into a 4-bit <br>>front-end, decode its all-ones state (F), and use it as a count enable for <br>>the remaining 18 bits.This is all very easy, and is totally synchronous. It <br>>does not create any pipeline delay or other funnies. Your code is all <br>>binary, like you want it to be. <br>> <br>Yes, the current stuff is all that's under consideration, though I'm <br>looking at some CPLD's as well because the logic is actually pretty <br>simple. The problem is simply in getting a long enough counter that <br>runs at the desired speed without having too many pins on the package <br>and the associated cost per pin. Once the package is bigger than the <br>PLCC-84 the costs associated with using the package seem to go through <br>the roof for a number of reasons. I know I can shorten the counter by <br>separating the <br>> <br>>Have fun! <br>> <br>>Peter Alfke, Xilinx Applications <br>>============================ <br>>Richard Erlacher wrote: <br>> <br>>> Well, OK ... Let's try this. <br>>> <br>>> We have a data stream that has to be sampled at 120 MHz, assembled <br>>> into words and shoved into an external DRAM. The DRAM is small <br>>> (256Kx16) and the data will be assembled and then registered as words <br>>> before being pipelined off into the RAM. States of the fast end of <br>>> the counter have to be decoded in order to synchronize the operation <br>>> with the RAM, and the MSB of the counter is a "DONE" bit. When the <br>>> counter is reset, it runs until the msb, used as the count enable, <br>>> goes true. That's a 22-bit counter ... Not terribly long, but long <br>>> enough. I suppose this could be done as 3-bit counter and a 19-bit <br>>> counter, but, either way, it's painful. The DRAM access has to be <br>>> done in short (page-mode) bursts, which is why the synchronization of <br>>> the decoding of the lower 3-bit section of the counter is critical. <br>>> <br>>> How close to the required 120 MHz can this counter be made to go in an <br>>> FPGA with 5-volt-tolerant I/O? It's got to be synchronous and the <br>>> sequence has to be monotonic, so the same counter will be useable to <br>>> accomplish refresh as required. LFSR's don't produce that sort of <br>>> sequence. What other alternatives are there? <br>>> <br>>> Dick <br>>> <br>></blockquote> </html> --------------079A41933EB3582B88A78609--Article: 36928
Dear FPGA experts, does someone have got a design for a simple logic analyser, for example a PC-controlled circuit? I am a student and I would like to have such a device with at least 16 inputs and 50MHz sample rate. In the internet, I found a nice design which was unfortunately based an older PLD which is not available any more. Thank you very much! Gunther MayArticle: 36929
"Wolfgang Loewer" <wolfgang.loewer@elca.de> writes: > Peter, > you write "the granularity of the clocking scheme is 300 ps at best". Can > you please elaborate on what this assertion is based upon. > > From: AN 130, CDR in Mercury Devices, page 8: > "... Each of the eight equally-spaced phase clocks is divided into seven > fractions; therefore, the resulting best-case clock granularity is 1/56 of > the clock period. ..." "best case": It can absolutely, never, ever get better than this, but possibly worse. 14 ps seems pretty good. Perhaps you hit another limit at high frequencies. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 36930
The Virtex-II data sheet shows that the Xilinx devices support the LVDS standard, driving 250 to 400 mV across the 100 Ohm termination resistor. This takes a total of max 8 mA Icc for the transmitter, since there also is internal termination at the driving end. ( the receiver uses 2 mA) This dc current must be multiplied by Vcc, which is either 2.5 or 3.3 V. It's as simple as that, and nobody can be any better. Peter Alfke ============================== Rotem Gazit wrote: > Peter, > Can you elaborate (or give a pointer) on how Xilinx calculates its > LVDS buffers power consumption ? > Do Xilinx LVDS buffers support the full LVDS specification, or just > the "reduced range" ?. > > Thanks, > Rotem Gazit > MystiCom LTD > mailto:rotemg@mysticom.com > http://www.mysticom.com/ > > Peter Alfke <palfke@earthlink.net> wrote in message news:<3C015E9A.B98CA518@earthlink.net>... > > Here are some observations from my not-so-impartial viewpoint: > > > > 1. The Altera clock recovery requires a specialized training sequence. > > > > 2. The claim that it eliminates the need for balanced pc-bord trace length is > > somewhat strange, since the granularity of the clocking scheme is 300 ps at > > best. That is equivalent to about 2 inches or 5 cm trace length. For any of the > > more realistic smaller differences in trace length, this adaptive per-bit > > clocking scheme offers no advantage. > > > > 3. And finally, Altera makes bogus claims about LVDS power consumption, where > > they quote not the consumed power (Vcc x Icc ) in the driver, but rather the > > power dissipated in the 100 Ohm termination resistor. Nobody cares about this > > nice low number, which makes it a candidate for the "Misleading Marketing" > > award of the year. > > > > Parallel busses with 800 Mbps per channel are challenging today. > > Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking. > > Xilinx goes for fine-granularity ( 50 ps ) common clocking. > > Guess which one I like better. > > > > And next year, self-clocking bit-serial 2.5 Gbps, > > with 4-channel bonding for 10 Gbps data traffic will become the standard. > > > > Peter Alfke, Xilinx Applications Engineering. > > ======================================== > > Arie Zychlinski wrote: > > > > > I would be much obliged to learn for your experience with the ALTERA's > > > Mercury CDR using the M1GXCVR core. we intend to use it in a new project for > > > 800 Mbps links. > > > thank you in advance. > > > > > > -- > > > > > > yours - > > > Arie Z. > > > > > > ============================================ > > > Arie Zychlinski > > > R&D Consulting & Development > > > P.O.Box 536 > > > Kfar-Saba 44104 > > > ISRAEL > > > > > > Mobile: 972-58-320230 > > > Phone: W: 972-9-7673074 H: 972-9-7658268 > > > > > > E-Mail: ariez@attglobal.net > > > ===========================================Article: 36931
Hi,
swan a écrit :
> hi,
> i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this?
It's much easier than it seems, using the slave serial mode (and not JTAG).
Assuming that you have a 8 bits controller with external bus, connect the Spartan's D0 line to
the processor's D7 line, CCLK to a decoded "Chip Select" output (simple qualified address
decoding), and PROGRAM to a port pin (can be tied with the processor's Reset if you have
an external watchdog).
The software does the following :
- Apply a pulse to the "PROGRAM" pin (if PROGRAM is not tied to Reset)
- Wait at least 1 ms
- Start reading the ".bit" file until you find a $FF followed by a $2x (this is to skip the header)
(if your ROM space is tight, you can safely remove the header from the ".bit" file before
it's linked to your application)
- Write each subsequent byte to the CS decoded address (8 times per byte, with left rotation)
- Write $FF twice (can't remember why I did that, maybe you can skip it)
That's it ! Your Spartan should be configured.
Note that neither "INIT" or "DONE" is used since (unless the processor & FPGA functions are
completely unrelated after configuration) the processor can check the FPGA to determine if it's
properly configured or not (I usually add a loadable counter with inverted output as an internal
register to my designs for this purpose).
If configuration failed, it can be retried (if PROGRAM is connected to the processor's reset,
just "hang" the processor in an endless loop and wait for the watchdog reset).
You can find below x86 code that does it all. It's written in 16 bits Delphi/assembly for an embedded
target, but it's simple enough to give you some clues.
hope this helps...
Eric.
--------------------------------------------------------------------------------------------------------------------------------
unit XiLoad;
interface
uses SysLib,Cpu186;
const BitStream_XCS05 = 6900; {}
Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;
implementation
{Din = D7 / PROGRAM pin = P1-3(80C186EB) }
procedure Xil_WB (B:Byte;Addr:Word);
begin
asm
MOV AL,[BP+06]
MOV DX,[BP+04]
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
end;
end;
Procedure xil_block (p:pointer;l,addr:Word);
begin
asm
LES DI,[BP+08]
MOV CX,[BP+06]
@1:
MOV AL,ES:[DI]
MOV DX,[BP+04]
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
INC DI
DEC CX
JNZ @1
end;
end;
Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;
var f,state : word;
by : Byte;
byp : ^byte absolute p;
Position:Longint;
Begin
Result:=False;
if byp<>Nil then
begin
Set_Control(P1LTCH,$000F); { Program pin inactive }
Dly (1); { Delay so that the pulse is long enough }
Set_Control(P1LTCH,$0007);; { Pulses "PROGRAM" (INIT) pin low }
Dly (16); { Delay so that the pulse is long enough }
Set_Control(P1LTCH,$000F); { Program pin inactive }
Dly (1); { Delay so that the pulse is long enough }
state:=0;
Position:=0;
Result:=True;
while (Position<L) and Result do
begin
by:=byp^;
inc (byp);
Inc(position);
case state of
1 : if by and $F0 = $20 then
begin
xil_wb($FF,Addr);
xil_wb(by,Addr);
xil_block (byp,word(l-Position),Addr);
Position:=L;
end
else
state:=0;
0 : if by=$FF then state:=1;
end;
end;
xil_wb($FF,Addr);
xil_wb($FF,Addr);
Result:=true;
end;
End;
Article: 36932--------------AB840AD6FD044D218C3530FC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Wolfgang, Correct, we are just a bit excited about some other claims we have heard lately regarding Apex II. To guess the average phase of a single serial stream in Mercury's all two family devices (120K gates, and 350K gates) dedicated 1.25 Gb/s serializer/deserializers, you are correct. The 50 ppm clock requirement is pretty tight in Mercury, I thought all those quoted industry specs require a 200 ppm clock tolerance?..... In Apex II's LVDS (Appnote 157, 162, 166), the per bit deskew is pretty useless (Figure 6, page 7), which was Peter's (misplaced) comment. It is one thing to claim "per bit deskew" in Mercury (where it is at least possible), it is another to claim it in Apex II, where it is clearly not possible (what has gotten Peter excited of late). Peter's oversight was his Apex II comment about Mercury's CDR. Peter has realized this, but was running off to a meeting right now, so I offered to respond. As for Virtex II's clock granularity, it does not claim, and does not have CDR for high speed gigabit serial channels. The granularity of the DCM is useful for the LVDS wide bus application, which does compare favorably with the Apex II solution (Peter's point). It is no secret we purchased Rocket Chips, and it is also no secret we licensed proven IP from Connexant/Mindspeed. Stay tuned .... exciting times to come! Austin Wolfgang Loewer wrote: > Peter, > you write "the granularity of the clocking scheme is 300 ps at best". Can > you please elaborate on what this assertion is based upon. > > From: AN 130, CDR in Mercury Devices, page 8: > "... Each of the eight equally-spaced phase clocks is divided into seven > fractions; therefore, the resulting best-case clock granularity is 1/56 of > the clock period. ..." > > 1/56 of a 1.25 GHz clock is equal to about 14 ps. > > 14 ps in today's Altera devices compared to 50 ps granularity in future > Xilinx devices - please correct me if I have misinterpreted something here, > but guess which one I like better. > > Wolfgang > http://www.elca.de > > "Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag > news:3C015E9A.B98CA518@earthlink.net... > > Here are some observations from my not-so-impartial viewpoint: > > > > 1. The Altera clock recovery requires a specialized training sequence. > > > > 2. The claim that it eliminates the need for balanced pc-bord trace length > is > > somewhat strange, since the granularity of the clocking scheme is 300 ps > at > > best. That is equivalent to about 2 inches or 5 cm trace length. For any > of the > > more realistic smaller differences in trace length, this adaptive per-bit > > clocking scheme offers no advantage. > > > > 3. And finally, Altera makes bogus claims about LVDS power consumption, > where > > they quote not the consumed power (Vcc x Icc ) in the driver, but rather > the > > power dissipated in the 100 Ohm termination resistor. Nobody cares about > this > > nice low number, which makes it a candidate for the "Misleading Marketing" > > award of the year. > > > > Parallel busses with 800 Mbps per channel are challenging today. > > Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking. > > Xilinx goes for fine-granularity ( 50 ps ) common clocking. > > Guess which one I like better. > > > > And next year, self-clocking bit-serial 2.5 Gbps, > > with 4-channel bonding for 10 Gbps data traffic will become the standard. > > > > Peter Alfke, Xilinx Applications Engineering. > > ======================================== > > Arie Zychlinski wrote: > > > > > I would be much obliged to learn for your experience with the ALTERA's > > > Mercury CDR using the M1GXCVR core. we intend to use it in a new project > for > > > 800 Mbps links. > > > thank you in advance. > > > > > > -- > > > > > > yours - > > > Arie Z. > > > > > > ============================================ > > > Arie Zychlinski > > > R&D Consulting & Development > > > P.O.Box 536 > > > Kfar-Saba 44104 > > > ISRAEL > > > > > > Mobile: 972-58-320230 > > > Phone: W: 972-9-7673074 H: 972-9-7658268 > > > > > > E-Mail: ariez@attglobal.net > > > =========================================== > > --------------AB840AD6FD044D218C3530FC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Wolfgang, <p>Correct, we are just a bit excited about some other claims we have heard lately regarding Apex II. <p>To guess the average phase of a single serial stream in <b>Mercury's all <u>two</u> family devices (120K gates, and 350K gates) </b>dedicated 1.25 Gb/s serializer/deserializers, you are correct. <p>The 50 ppm clock requirement is pretty tight in Mercury, I thought all those quoted industry specs require a 200 ppm clock tolerance?..... <br> <br> <p>In <b>Apex II's</b> LVDS (Appnote 157, 162, 166), the per bit deskew is pretty useless (Figure 6, page 7), which was Peter's (misplaced) comment. <p>It is one thing to claim "per bit deskew" in Mercury (where it is at least possible), it is another to claim it in Apex II, where it is clearly not possible (what has gotten Peter excited of late). <p>Peter's oversight was his Apex II comment about Mercury's CDR. Peter has realized this, but was running off to a meeting right now, so I offered to respond. <br> <p>As for Virtex II's clock granularity, it does not claim, and does not have CDR for high speed gigabit serial channels. The granularity of the DCM is useful for the LVDS wide bus application, which does compare favorably with the Apex II solution (Peter's point). <p>It is no secret we purchased Rocket Chips, and it is also no secret we licensed proven IP from Connexant/Mindspeed. Stay tuned .... exciting times to come! <p>Austin <br> <br> <p>Wolfgang Loewer wrote: <blockquote TYPE=CITE>Peter, <br>you write "the granularity of the clocking scheme is 300 ps at best". Can <br>you please elaborate on what this assertion is based upon. <p>From: AN 130, CDR in Mercury Devices, page 8: <br>"... Each of the eight equally-spaced phase clocks is divided into seven <br>fractions; therefore, the resulting best-case clock granularity is 1/56 of <br>the clock period. ..." <p>1/56 of a 1.25 GHz clock is equal to about 14 ps. <p>14 ps in today's Altera devices compared to 50 ps granularity in future <br>Xilinx devices - please correct me if I have misinterpreted something here, <br>but guess which one I like better. <p>Wolfgang <br><a href="http://www.elca.de">http://www.elca.de</a> <p>"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag <br><a href="news:3C015E9A.B98CA518@earthlink.net">news:3C015E9A.B98CA518@earthlink.net</a>... <br>> Here are some observations from my not-so-impartial viewpoint: <br>> <br>> 1. The Altera clock recovery requires a specialized training sequence. <br>> <br>> 2. The claim that it eliminates the need for balanced pc-bord trace length <br>is <br>> somewhat strange, since the granularity of the clocking scheme is 300 ps <br>at <br>> best. That is equivalent to about 2 inches or 5 cm trace length. For any <br>of the <br>> more realistic smaller differences in trace length, this adaptive per-bit <br>> clocking scheme offers no advantage. <br>> <br>> 3. And finally, Altera makes bogus claims about LVDS power consumption, <br>where <br>> they quote not the consumed power (Vcc x Icc ) in the driver, but rather <br>the <br>> power dissipated in the 100 Ohm termination resistor. Nobody cares about <br>this <br>> nice low number, which makes it a candidate for the "Misleading Marketing" <br>> award of the year. <br>> <br>> Parallel busses with 800 Mbps per channel are challenging today. <br>> Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking. <br>> Xilinx goes for fine-granularity ( 50 ps ) common clocking. <br>> Guess which one I like better. <br>> <br>> And next year, self-clocking bit-serial 2.5 Gbps, <br>> with 4-channel bonding for 10 Gbps data traffic will become the standard. <br>> <br>> Peter Alfke, Xilinx Applications Engineering. <br>> ======================================== <br>> Arie Zychlinski wrote: <br>> <br>> > I would be much obliged to learn for your experience with the ALTERA's <br>> > Mercury CDR using the M1GXCVR core. we intend to use it in a new project <br>for <br>> > 800 Mbps links. <br>> > thank you in advance. <br>> > <br>> > -- <br>> > <br>> > yours - <br>> > Arie Z. <br>> > <br>> > ============================================ <br>> > Arie Zychlinski <br>> > R&D Consulting & Development <br>> > P.O.Box 536 <br>> > Kfar-Saba 44104 <br>> > ISRAEL <br>> > <br>> > Mobile: 972-58-320230 <br>> > Phone: W: 972-9-7673074 H: 972-9-7658268 <br>> > <br>> > E-Mail: ariez@attglobal.net <br>> > =========================================== <br>></blockquote> </html> --------------AB840AD6FD044D218C3530FC--Article: 36933
Hi,
swan a écrit :
> hi,
> i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this?
> rgds
> swan
It's much easier than it seems, using the slave serial mode (and not JTAG).
Assuming that you have a 8 bits controller with external bus, connect the Spartan's D0 line to
the processor's D7 line, CCLK to a decoded "Chip Select" output (simple qualified address
decoding), and PROGRAM to a port pin (can be tied with the processor's Reset if you have
an external watchdog).
The software does the following :
- Apply a pulse to the "PROGRAM" pin (if PROGRAM is not tied to Reset)
- Wait at least 1 ms
- Start reading the ".bit" file until you find a $FF followed by a $2x (this is to skip the header)
(if your ROM space is tight, you can safely remove the header from the ".bit" file before
it's linked to your application)
- Write each subsequent byte to the CS decoded address (8 times per byte, with left rotation)
- Write $FF twice (can't remember why I did that, maybe you can skip it)
That's it ! Your Spartan should be configured.
Note that neither "INIT" or "DONE" is used since (unless the processor & FPGA functions are
completely unrelated after configuration) the processor can check the FPGA to determine if it's
properly configured or not (I usually add a loadable counter with inverted output as an internal
register to my designs for this purpose).
If configuration failed, it can be retried (if PROGRAM is connected to the processor's reset,
just "hang" the processor in an endless loop and wait for the watchdog reset).
You can find below x86 code that does it all. It's written in 16 bits Delphi/assembly for an embedded
target, but it's simple enough to give you some clues.
hope this helps...
Eric.
--------------------------------------------------------------------------------------------------------------------------------
unit XiLoad;
interface
uses SysLib,Cpu186;
const BitStream_XCS05 = 6900; { safe limit }
BitStream_XCS10 = 12000; { safe limit }
BitStream_XCS20 = 22450; { safe limit }
BitStream_XCS30 = 31200; { safe limit }
BitStream_XCS40 = 41400; { safe limit }
Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;
implementation
{Din = D7 / PROGRAM pin = P1-3(80C186EB) }
procedure Xil_WB (B:Byte;Addr:Word);
begin
asm
MOV AL,[BP+06]
MOV DX,[BP+04]
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
end;
end;
Procedure xil_block (p:pointer;l,addr:Word);
begin
asm
LES DI,[BP+08]
MOV CX,[BP+06]
MOV DX,[BP+04]
@1:
MOV AL,ES:[DI]
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
INC DI
DEC CX
JNZ @1
end;
end;
Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;
var by : Byte;
byp : ^byte absolute p;
Position:Longint;
Begin
Result:=False;
if byp=Nil then then exit;
Set_Control(P1LTCH,$000F); { Program pin inactive }
Dly (1); { Delay so that the pulse is long enough }
Set_Control(P1LTCH,$0007);; { Pulses "PROGRAM" (INIT) pin low }
Dly (16); { Delay so that the pulse is long enough }
Set_Control(P1LTCH,$000F); { Program pin inactive }
Dly (1); { Delay so that the Spartan can complete internal reset }
Position:=L;
while (Position>0) and not Result do { skip the header }
begin
by:=byp^;
inc (byp);
Dec(position);
if (by=$FF) and (byp^ and $F0 = $20) then
begin
dec (byp);
xil_block (byp,word(Position),Addr); { Configure the FPGA }
xil_wb($FF,Addr);
xil_wb($FF,Addr);
Result:=True;
end
end;
End;
Article: 36934
Hi,
swan a écrit :
> hi,
> i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this?
> rgds
> swan
It's much easier than it seems, using the slave serial mode (and not JTAG).
Assuming that you have a 8 bits controller with external bus, connect the Spartan's D0 line to
the processor's D7 line, CCLK to a decoded "Chip Select" output (simple qualified address
decoding), and PROGRAM to a port pin (can be tied with the processor's Reset if you have
an external watchdog).
The software does the following :
- Apply a pulse to the "PROGRAM" pin (if PROGRAM is not tied to Reset)
- Wait at least 1 ms
- Start reading the ".bit" file until you find a $FF followed by a $2x (this is to skip the header)
(if your ROM space is tight, you can safely remove the header from the ".bit" file before
it's linked to your application)
- Write each subsequent byte to the CS decoded address (8 times per byte, with left rotation)
- Write $FF twice (can't remember why I did that, maybe you can skip it)
That's it ! Your Spartan should be configured.
Note that neither "INIT" or "DONE" is used since (unless the processor & FPGA functions are
completely unrelated after configuration) the processor can check the FPGA to determine if it's
properly configured or not (I usually add a loadable counter with inverted output as an internal
register to my designs for this purpose).
If configuration failed, it can be retried (if PROGRAM is connected to the processor's reset,
just "hang" the processor in an endless loop and wait for the watchdog reset).
You can find below x86 code that does it all. It's written in 16 bits Delphi/assembly for an embedded
target, but it's simple enough to give you some clues.
hope this helps...
Eric.
--------------------------------------------------------------------------------------------------------------------------------
unit XiLoad;
interface
uses SysLib,Cpu186;
const BitStream_XCS05 = 6900; { safe limit }
BitStream_XCS10 = 12000; { safe limit }
BitStream_XCS20 = 22450; { safe limit }
BitStream_XCS30 = 31200; { safe limit }
BitStream_XCS40 = 41400; { safe limit }
Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;
implementation
{Din = D7 / PROGRAM pin = P1-3(80C186EB) }
procedure Xil_WB (B:Byte;Addr:Word);
begin
asm
MOV AL,[BP+06]
MOV DX,[BP+04]
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
end;
end;
Procedure xil_block (p:pointer;l,addr:Word);
begin
asm
LES DI,[BP+08]
MOV CX,[BP+06]
MOV DX,[BP+04]
@1:
MOV AL,ES:[DI]
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
ADD AL,AL
OUT DX,AL
INC DI
DEC CX
JNZ @1
end;
end;
Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;
var by : Byte;
byp : ^byte absolute p;
Position:Longint;
Begin
Result:=False;
if byp=Nil then exit;
Set_Control(P1LTCH,$000F); { Program pin inactive }
Dly (1); { Delay so that the pulse is long enough }
Set_Control(P1LTCH,$0007);; { Pulses "PROGRAM" (INIT) pin low }
Dly (16); { Delay so that the pulse is long enough }
Set_Control(P1LTCH,$000F); { Program pin inactive }
Dly (1); { Delay so that the Spartan can complete internal reset }
Position:=L;
while (Position>0) and not Result do { skip the header }
begin
by:=byp^;
inc (byp);
Dec(position);
if (by=$FF) and (byp^ and $F0 = $20) then
begin
dec (byp);
xil_block (byp,word(Position),Addr); { Configure the FPGA }
xil_wb($FF,Addr);
xil_wb($FF,Addr);
Result:=True;
end;
end;
End;
Article: 36935I checked out the info on which devices are supported by the ISE Webpack software and it looks like Virtex II 40, 80 and 250 are supported in addition to all of the Spartan II and IIE(?). http://www.xilinx.com/ise/products/webpack_config.htm Can anyone verify that these devices are actually supported and working in the current release of Webpack? Also, it is clear that only a trial version of ModelSim is included and you need to buy the XE version if you want to do real work with the simulator. Are there any other pieces included that are not fully functional? Finally, the only supported OS listed are 98, 2000 and NT 4.0. Anyone know if they plan to update this list with something more current like XP? I expect to be buying a new machine soon and hate to have to use an old OS just for Xilinx. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 36936
I am sorry to have made a basic mistake, and I apologize if I have mislead anybody. The question was about Mercury, and I answered it as if it were about APEX-II. I had worked up so much steam about APEX-II that I mixed up the two families. I'll be more careful in the future. Peter AlfkeArticle: 36937
I have used the webpack for the virtex2-40 series device. Web pack does not support logiblox, coregen, and FPGA editor. With those exceptions I found it to be quite usable. The so-called modelsim limitation is not entirely true. Modelsim is crippled in that as the simulations get more and more lines of code the simulator gets bogged down. It does not stop entirely. I have used it to simulate a virtex2-40 with 95% of the chip utilized. The worst thing I can say about the modelsim is that the models for DCM's and other similar virtex2 specific devices are not simulatable at the behavioral or post-translate levels. Thus to simulate a DCM one has to at least map the device to get a simulation result. If you are just using standard VHDL then model-sim webpack works great. rickman wrote: > I checked out the info on which devices are supported by the ISE Webpack > software and it looks like Virtex II 40, 80 and 250 are supported in Correct also, the virtexE series up to 300K gates, spartan2, and spartan2E to similar sizes. also Coolrunner, coolrunner2, and XC9500, xc9500xl and xc9500xv series devices. These all show up in my options for devices. I have gone to the ISE4.1 package but only because I really wanted the coregen devices. It was $695 with the same modelsim as webpack. By the way, if anyone knows a workaround for any of my complaints, please let me know. Thanks, Theron Hicks > > addition to all of the Spartan II and IIE(?). > > http://www.xilinx.com/ise/products/webpack_config.htm > > Can anyone verify that these devices are actually supported and working > in the current release of Webpack? > > Also, it is clear that only a trial version of ModelSim is included and > you need to buy the XE version if you want to do real work with the > simulator. Are there any other pieces included that are not fully > functional? > > Finally, the only supported OS listed are 98, 2000 and NT 4.0. Anyone > know if they plan to update this list with something more current like > XP? I expect to be buying a new machine soon and hate to have to use an > old OS just for Xilinx. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 36938
Hananiel Sarella wrote:
> Hello folks,
> Im trying to implement large FFTs on Xilinx vertex II FPGAs. I have a couple of questions.
> 1. There are multipliers on chip with 5ns delays.
Check the latest data sheets. Those multipliers are not nearly that fast.
> There is a paper by lez mintzer "large ffts on fpgas" which describes how to code one fft butterfly with DA tables. The pipeline delay in this case is less than the multiplier delay and there are more multiplies per stage delay.
The DA approach is inherently serial, although it can be paralleled up to get a fully parallel implementation. For the fully parallel case, the resource usage is close to parity with a design built from multipliers, and in most cases so is the latency/speed. Where virtexII has the
dedicated multipliers, you will use many less LUTs by using the multipliers...although that advantage is not as clear if you are using the multipliers and fabric at the highest possible speed. There are other ways to skin the FFT cat too. Even with the dedicated multipliers it may
be advatageous to use alternative algorithms to reduce the hardware complexity.
>
> Can some one tell me which is better?
> 2. Im writing synthesizeable structural VHDL code for the butterfly processor. Im having to write code for controlling this for say, 8192 point FFT. Is this the way people do it. Like say guys writing xilinx cores. Or is there a better way you can suggest.
I'm not sure what you are referring to as "code" VHDL is code, as is microcode for a state machine. The cores are structurally instantiated, although many have been translated to a java script.
>
>
> Thanks a lot,
> Hananiel
--
--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: 36939Hello everyone, Since everyone here has more experience with FPGAs than I, I will ask for some advice. Since I'm just starting with FPGAs it seems to me a good idea to pick a vendor and stick to it (and this seems to be cheaper since you don't have to purchase everyone's tools). I would like some comments on which vendor is the "preferred" vendor these days. In other words why should I choose Altera over Xilinx over Atmel, etc. I'm looking for honest answers and no sales calls. My applications will vary in size and speed so flexibility is very important, along with relative costs of software and ICs/demonstration boards. I'm interested to know so I can save myself some head aches and make an informed decision on which company to align myself with. Thanks JasonArticle: 36940
Jason Berringer wrote: > > In other words why should > I choose Altera over Xilinx over Atmel, etc. Brand X and A are the biggest and most often mentioned in this group. The parts are roughly equivalent. Pick the vendor that gives you the best service. -- Mike TreselerArticle: 36941
It really depends on what your major applications are. Altera has CAM built in,
which is very nice to nice in those network and sorter applications, whilc
xilinx's ability to use CLBs as small RAMs or shift registers is extremely
valuable in DSP applications. You need to carefully look at the features and
architecture while thinking about how they will help or hurt your typical
designs.
Jason Berringer wrote:
> Hello everyone,
>
> Since everyone here has more experience with FPGAs than I, I will ask for
> some advice. Since I'm just starting with FPGAs it seems to me a good idea
> to pick a vendor and stick to it (and this seems to be cheaper since you
> don't have to purchase everyone's tools). I would like some comments on
> which vendor is the "preferred" vendor these days. In other words why should
> I choose Altera over Xilinx over Atmel, etc. I'm looking for honest answers
> and no sales calls. My applications will vary in size and speed so
> flexibility is very important, along with relative costs of software and
> ICs/demonstration boards.
>
> I'm interested to know so I can save myself some head aches and make an
> informed decision on which company to align myself with.
>
> Thanks
>
> Jason
--
--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: 36942Hey all. I am implementing a very basic, simple uC to FPGA(XC4010E-4) interface. The uC simply updates an 8-bit register in the FPGA via SPI -- the FPGA does not communicate back. The only real logic involved is an 8-bit shift register. System clock in the FPGA is a fixed 40MHz. The uC outputs(to the FPGA) are an SPI_Clock output, SPI_Data_Out (data valid on rising edge of clock) and nDevice_Select (active low "enable" to SPI device). My SPI clock is <= 1MHz and speed isn't a big issue(it could be run in the kHz if need be). While the logic involved is straight I still have a few questions... The most obvious and "direct" method of implementation is to use the SPI clock from the uC as the clock for the 8-bit shift register in the FPGA and use the nDevice_Select(synchronized) as a data "valid" for the block that uses the data from the shift register. However thinking about it, an approach that might be more suitable for an FPGA might be to use the SPI clock (synchronized through a 2 DFF "de-metastabilifier") as the Clock_Enable on the shift register FF's and use a synchronized nDevice_Select as a data valid while the clock to the shift register FF's is driven by my FPGA system clock. A practical concern however is that I already have a simple design (debugged, working) that when Xilinx P&R'ed runs @ 42MHz that needs to be integrated with the SPI interface/register. If I were to use implementation technique #2, does the possibility exist of my existing circuit being forced to run at a lower clock rate? Are there other caveats to either design choice? Thanks! VR.Article: 36943
Theron Hicks wrote: > > I have used the webpack for the virtex2-40 series device. Web pack does not > support logiblox, coregen, and FPGA editor. With those exceptions I found > it to be quite usable. The so-called modelsim limitation is not entirely > true. Modelsim is crippled in that as the simulations get more and more > lines of code the simulator gets bogged down. It does not stop entirely. I > have used it to simulate a virtex2-40 with 95% of the chip utilized. The > worst thing I can say about the modelsim is that the models for DCM's and > other similar virtex2 specific devices are not simulatable at the behavioral > or post-translate levels. Thus to simulate a DCM one has to at least map > the device to get a simulation result. If you are just using standard VHDL > then model-sim webpack works great. Theron, Thanks for the reply. This is useful info. I am aware of the ModelSim behavior. I did a project with it a little over a year ago and it got to be a real pain at 500 lines of code. It was not a gradual change in simulation time, but was about a 5x to 10x reduction in speed once you reached the 500 line limitation. This made it MUCH harder to get any real work done. Since it is not clearly indicated in the documentation, it snuck up behind me in the middle of this small project. Now I know better than to try to use any of the demo tools for a project, even when they look useful. IIRC, logiblox lets you instantiate complex elements like counters, adders, bus muxes and the like, right? I am not familiar with coregen. I will read up on it at the Xilinx web site. FPGA editor is important. I take it there are no replacement modules for Logiblox and FPGA editor in WebPack? It would be a pain to work without these functions. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 36944
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes: > Petter Gustad <newsmailcomp1@gustad.com> writes: > > In case somebody is struggling with a not-internet-exporer-for-windows > > web browser (like myself, using Opera under Linux) to download WebPack > > - Here is how you can download it using wget: > > > > wget --http-user USER --http-passwd PASS http://www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe > > > > Where USER is your Xilinx registered username and PASS is your > > selected password. > > or even > > wget http://USER:PASS@www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe > > I wonder how much money they spent developing that horrible navigation > system? It's almost as if their intent was to prevent people from I wish they could have spent this effort on qualifying a Linux version or a faster better synthesis and/or place and route tool (something that would run effectively on a cluster). Same thing with the Java based installation under Solaris: This effort could also have been spent at the above mentioned tasks. I would rather have a cpio based sh script which would complete in the matter of minutes, not hours like the Java based installation tool. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 36946
Hi, "Jason Berringer" <jberringer@trace-logic.com> wrote: > for some advice. Since I'm just starting with FPGAs it seems to me a > good idea to pick a vendor and stick to it (and this seems to be > cheaper since you don't have to purchase everyone's tools). Normaly you get the vendor-specific tools free. If your not only doing a few designs it's a good idea to get a full version of tools for synthesis and simulation. So don't stick to a vendor because of the tools. Anyway it may be cheaper to buy all FPGA from the same vendor. > like some comments on which vendor is the "preferred" vendor these > days. In other words why should I choose Altera over Xilinx over Atmel, > etc. I'm looking for honest answers and no sales calls. My applications > will vary in size and speed so flexibility is very important, along > with relative costs of software and ICs/demonstration boards. First you should think about RAM-based and Fuse-Based FPGA. RAM means normaly reloading your design every power-up. That's IMHO a major drawback for selling applications and a great advantage while prototyping. A Fuse-Based FPGA needs a burner and you can't change anything if its once burned. For prototyping only I would choose Xilinx (as I have no experience with Atmel or Altera *g*). Because of the wide spread experience of prototyping with Xilinx wherever I look (e.g. here in this NG). bye Thomas -- Thomas Stanka BC/EMD4 Space Communications Systems Tesat Spacecom GmbH & Co KG thomas.stanka@de.bosch.comArticle: 36947
Really thanks, but what you mean with Clock Enable Inputs for derived frequencies?Article: 36948
Well, the point was to replace the couple hundred thousand dollar clock which can do it!
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