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
On 2008-05-20, Kolja Sulimma <ksulimma@googlemail.com> wrote: > Don't confuse architecture and coding. > The parallel linear adder chain will cost exactly the same hardware > when coded with or without the for loop. Of course, and I believe I wrote in my original post that a for loop will simply be unrolled. My example was merely meant to illustrate that it is very easy to write a for loop which will be extremely expensive in hardware even though it is only a couple of lines of code. This is why we recommend students to avoid for-loops in our introductory courses, it is too easy to try to program instead of designing hardware. If you don't use a for loop you will immediately figure out that something is not right with your design as you are going to write 512 individual additions... However, since you seem to have some experience with synthesizers that support wait statements I have a question for you: How should you implement a synchronous reset if you have a process like the following? always begin always @(posedge clk); // This is the state I want to end up with at reset time bar <= 0; always @(posedge clk); bar <= bar + 1; always @(posedge clk); bar <= bar + 1; always @(posedge clk); bar <= bar + 1; end /AndreasArticle: 132276
On 20 Mai, 05:04, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > This is going to be hugely expensive in terms of hardware to > implement as you will end up with 512 adders and force your > memory to be implemented using flip-flops instead of a blockram. > In this case it is probably a much better idea to write a small > state machine to sum the values. It will take around 512 clock > cycles unless you do something clever like reading several values > at a time, but the footprint will be much more reasonable. Don't confuse architecture and coding. The parallel linear adder chain will cost exactly the same hardware when coded with or without the for loop. The same is true for the serial version (for synthesizers that support wait statements in for loops). The decision whether to build a single cycle or multi cycle hardware has nothing to do with for loops. Kolja SulimmaArticle: 132277
On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote: > On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote: > > > input: Asynchronous, non-fix width, non-fix frequeny(but equal or > > smaller than 30 Mhz), something like random fast signal coming in. > > System clock is only 40MHz, > > > What can I latch the "rising" edge of the input and synchronize it and > > don't get into big trouble of Metastability? > > Since the input freq is very near the System clock and Asynchronous > > don't have a clock signal coming in. > > is it possible that connecting the input signal directly to FF clock > > then following with a negative clk edge FF then positive clk edge FF? > > will it make any trouble and how to solve it? > > Synchronizing a 30 MHz signal with a roughly 40 MHz clock will > generate an uncontrollable extra metastable delay of a few ns > occasionally. > But an extra 4 ns only once per many thousand years, statistically. > You really do not have to worry about metastability. > At ten times higher frequencies, you would run into problems... > Se my Xilinx appnote XAPP094... > Peter Alfke My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean that the min time different between two signal will be =( 1/30Mhz). In income signal don't have a clock domain, it just "Happen".Article: 132278
On May 20, 9:55 am, Aiken <aikenp...@gmail.com> wrote: > On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote: > > > > > On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote: > > > > input: Asynchronous, non-fix width, non-fix frequeny(but equal or > > > smaller than 30 Mhz), something like random fast signal coming in. > > > System clock is only 40MHz, > > > > What can I latch the "rising" edge of the input and synchronize it and > > > don't get into big trouble of Metastability? > > > Since the input freq is very near the System clock and Asynchronous > > > don't have a clock signal coming in. > > > is it possible that connecting the input signal directly to FF clock > > > then following with a negative clk edge FF then positive clk edge FF? > > > will it make any trouble and how to solve it? > > > Synchronizing a 30 MHz signal with a roughly 40 MHz clock will > > generate an uncontrollable extra metastable delay of a few ns > > occasionally. > > But an extra 4 ns only once per many thousand years, statistically. > > You really do not have to worry about metastability. > > At ten times higher frequencies, you would run into problems... > > Se my Xilinx appnote XAPP094... > > Peter Alfke > > My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean > that the min time different between two signal will be =( 1/30Mhz). In > income signal don't have a clock domain, it just "Happen". Still what Peter seems to suggest is that you can just sample the asynchronous input with your 40 MHz clock and don't worry about metastability. In fact you could sample on both clock edges and still have a very small chance of seeing a metastable event at those frequencies. Just be sure that there is only one point of sampling on the input signal. The output of that single sampling flip-flop can then be used within the design. Adding one more stage after the sampling flip-flop can improve your metastability tolerance in two ways. 1) The second flip-flop would receive the sample flip-flop input after a complete cycle without LUT delays. This increases the length of a metastable event required to upset the second stage. 2) Having a single second point of sampling prevents logic upsets caused by different loads sampling the metastable vs. post-metastable state of the first sampling flop.Article: 132279
fazulu deen wrote: > hai, > > I learned from the Xilinx manual that for,while do statements are > synthesized in XST.. > > I would like to know how these statements(for,while,do while) are > implemented as logic design(EDIF and constraints) in FPGA device?? . > > Though FOR loop is synthesizable , it is always advised that FOR loops > are not to be used in RTL coding. This is because it consumes lot of > resources (like area etc)whether XST will not optimize it before > targetting to FPGA device??? > > As wait() is not supported for synthesis wat should i use instead of > wait()?? > > regards, > faz One key point with these loops is that the conditionals that define how much to loop are typically only supported for constants. Trying to do a for loop with a vector controlling your max value will probably only bring synthesis errors. Using parameters or other constant values allow you to use these loops without the synthesis complaints. - John_HArticle: 132280
Joseph, Why bother? Only because all of the 'other' solutions actually exist, where H4 is a hyper-active sales pitch for an untested capability that hasn't even been taped out yet... Imagine all those Altera customers who designed in the Stratix III GX: all dressed up, and nowhere to go. Using FPGAs is all about reducing risk. Converting the FPGA to an ASIC (structured or otherwise) is all about reducing costs. No risk: Virtex 5, today, available Lower Cost: Virtex 5 EasyPath(tm) devices, guaranteed to work, because they are IDENTICAL to the FPGA AustinArticle: 132281
KJ wrote: > On May 19, 2:38 pm, Pablo <pbantu...@gmail.com> wrote: >> this is my code: >> >> entity Top_Module is >> port ( >> o_DSP0 : out MyRecordType >> ); >> end Top_Module; >> >> whe o_DSP0 is: >> >> type MyRecordType is record >> int4 : std_logic; >> int5 : std_logic; >> int6 : std_logic; >> int7 : std_logic; >> end record; >> >> --------------- >> >> How is o_DSP0 declared in ucf file? > > Most likely the 'o_DSP0' signal will get synthesized to a 'flattened' > set of names like 'o_DSP0_int4', 'o_DSP0_int5', etc. Check the output > of your synthesis result to find out how the record type signal > elements got renamed. > > KJ I tried this recently and had that result: I had wanted the signal names "int4", "int5", etc., but got the "flattened" names. -KevinArticle: 132282
On May 20, 7:04=A0am, Gabor <ga...@alacron.com> wrote: > On May 20, 9:55 am, Aiken <aikenp...@gmail.com> wrote: > > > > > On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote: > > > > On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote: > > > > > input: Asynchronous, non-fix width, non-fix frequeny(but equal or > > > > smaller than 30 Mhz), something like random fast signal coming in. > > > > System clock is only 40MHz, > > > > > What can I latch the "rising" edge of the input and synchronize it a= nd > > > > don't get into big trouble of Metastability? > > > > Since the input freq is very near the System clock and Asynchronous > > > > don't have a clock signal coming in. > > > > is it possible that connecting the input signal directly to FF clock= > > > > then following with a negative clk edge FF then positive clk edge FF= ? > > > > will it make any trouble and how to solve it? > > > > Synchronizing a 30 MHz signal with a roughly 40 MHz clock will > > > generate an uncontrollable extra metastable delay of a few ns > > > occasionally. > > > But an extra 4 ns only once per many thousand years, statistically. > > > You really do not have to worry about metastability. > > > At ten times higher frequencies, you would run into problems... > > > Se my Xilinx appnote XAPP094... > > > Peter Alfke > > > My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean > > that the min time different between two signal will be =3D( 1/30Mhz). In= > > income signal don't have a clock domain, it just "Happen". > > Still what Peter seems to suggest is that you can just sample > the asynchronous input with your 40 MHz clock and don't worry > about metastability. =A0In fact you could sample on both clock > edges and still have a very small chance of seeing a metastable > event at those frequencies. =A0Just be sure that there is only > one point of sampling on the input signal. =A0The output of that > single sampling flip-flop can then be used within the design. > Adding one more stage after the sampling flip-flop can improve > your metastability tolerance in two ways. > > 1) The second flip-flop would receive the sample flip-flop input > after a complete cycle without LUT delays. =A0This increases the > length of a metastable event required to upset the second > stage. > > 2) Having a single second point of sampling prevents logic > upsets caused by different loads sampling the metastable > vs. post-metastable state of the first sampling flop. Yes, Gabor, we agree. This is a non-problem, as long as the usual precautions are being observed. Peter AlfkeArticle: 132283
PFC <lists@peufeu.com> wrote: > On Mon, 03 Mar 2008 20:40:07 +0100, Antti <Antti.Lukats@googlemail.com> > wrote: > > here it is: > > ... > Here's mine : > - PQ208 : put thermal pad below connected to GND, remove all GND pins > from package ; put other smaller "thermal pads" for the power supplies > and get rid of the supply pins, you get 50 more IO on the package. National did someting like that for the DP83847 ... And keep 3.3V IO capability! -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 132284
Joseph wrote:
> They've also released Hardcopy-IV, including serdes and PCI-e.
> Why bother with ASICs...
austin wrote:
> Joseph,
> Why bother? Only because all of the 'other' solutions actually exist,
I believe Joseph said,
"Why bother with ASICs"
not "Why bother with Xilinx"
> where H4 is a hyper-active sales pitch for an untested capability that
> hasn't even been taped out yet...
Let he who is without sin,
cast the first stone.
-- Mike Treseler
Article: 132285Hello, I know many will say this is not an appropriate group to post such a question, but I wasn't getting any response on the Verilog group, so please let me apologize. I am new to Verilog and need some help instantiating a lpm dcfifo in my code. Here is what I have so far: FIFIN : lpm_fifo_dc WITH (LPM_WIDTH = 64, LPM_NUMWORDS = 64, LPM_WIDTHU = 9, RDSYNC_DELAYPIPE = 3, WRSYNC_DELAYPIPE = 3); FIFIN.aclr = (!rstn); FIFIN.wrclock = (clk); FIFIN.wrreq = (wr_fiforeq); FIFIN.data[31..0] = (dma_wrdata); FIFIN.rdclock = (clk); FIFIN.rdreq = (dma1_rddata); FIFIN.q = (rd_fiforeq); If anyone has some examples of instantiating a lpm function within Verilog I would greatly appreciate your help. Thanks, joeArticle: 132286
On May 20, 11:42 am, Peter Alfke <pe...@xilinx.com> wrote: > On May 20, 7:04 am, Gabor <ga...@alacron.com> wrote: > > > > > On May 20, 9:55 am, Aiken <aikenp...@gmail.com> wrote: > > > > On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote: > > > > > On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote: > > > > > > input: Asynchronous, non-fix width, non-fix frequeny(but equal or > > > > > smaller than 30 Mhz), something like random fast signal coming in. > > > > > System clock is only 40MHz, > > > > > > What can I latch the "rising" edge of the input and synchronize it and > > > > > don't get into big trouble of Metastability? > > > > > Since the input freq is very near the System clock and Asynchronous > > > > > don't have a clock signal coming in. > > > > > is it possible that connecting the input signal directly to FF clock > > > > > then following with a negative clk edge FF then positive clk edge FF? > > > > > will it make any trouble and how to solve it? > > > > > Synchronizing a 30 MHz signal with a roughly 40 MHz clock will > > > > generate an uncontrollable extra metastable delay of a few ns > > > > occasionally. > > > > But an extra 4 ns only once per many thousand years, statistically. > > > > You really do not have to worry about metastability. > > > > At ten times higher frequencies, you would run into problems... > > > > Se my Xilinx appnote XAPP094... > > > > Peter Alfke > > > > My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean > > > that the min time different between two signal will be =( 1/30Mhz). In > > > income signal don't have a clock domain, it just "Happen". > > > Still what Peter seems to suggest is that you can just sample > > the asynchronous input with your 40 MHz clock and don't worry > > about metastability. In fact you could sample on both clock > > edges and still have a very small chance of seeing a metastable > > event at those frequencies. Just be sure that there is only > > one point of sampling on the input signal. The output of that > > single sampling flip-flop can then be used within the design. > > Adding one more stage after the sampling flip-flop can improve > > your metastability tolerance in two ways. > > > 1) The second flip-flop would receive the sample flip-flop input > > after a complete cycle without LUT delays. This increases the > > length of a metastable event required to upset the second > > stage. > > > 2) Having a single second point of sampling prevents logic > > upsets caused by different loads sampling the metastable > > vs. post-metastable state of the first sampling flop. > > Yes, Gabor, we agree. This is a non-problem, as long as the usual > precautions are being observed. > Peter Alfke thanksArticle: 132287
>> - PQ208 : put thermal pad below connected to GND, remove all GND >> pins >> from package ; put other smaller "thermal pads" for the power supplies >> and get rid of the supply pins, you get 50 more IO on the package. > > National did someting like that for the DP83847 Hey, this is a cool package, no pin wasting for power supplies, I like it... (plus it probably has better signal integrity). And no pins, which means no bent pins like on PQ208 ! > And keep 3.3V IO capability! Well, definitely !Article: 132288
Hello all I have made an 8 channel 500kHz low pass IIR-filter in VHDL. The filter uses 32 bits for it's coefficients and 32 bits for it's internal signals. The filter doesn't give the same DC-gain for small vs. large input signals. I suspect the internal truncation of the intermediate sums and states effects this. But today I thought about increasing the bits for the signal and decreasing the bits for the coefficients. I tried it out and the filter gave better gain over different input signal levels. Now I wonder how I should optimize the coefficient and signal bit lengths to get the best result?Article: 132289
Jeff Cunningham wrote:
> Rob Gaddi wrote:
>
>> Jon Elson wrote:
>>
>> > <snip>
>>
>>> the whole thing is synchronous, running at 40 MHz on a Spartan 2E,
>>> except a couple external inputs such as the "inputa" above.
>>
>> > <snip>
>>
>> That right there could be your problem. If those inputs aren't
>> synchronous then you could get into some trouble if they change just
>> before a clock edge happens. Some of your state machine flops get the
>> new message, some get the old one, and you've magically got an illegal
>> state.
>>
>> Can you register those signals for a clock before you use them?
>
>
> In addition to registering all inputs, you also should make sure that
> the state machine is initialized with a synchronous reset after your
> DLLs have locked.
No DLLs, just a plain single clock. The state machine and all other
hardware
does initialize perfectly.
As for registering the inputs, that DOES seem to be the right thing to
do, but the binary-coded state version works fine without. Also, the
clock rates on this are so low, it seems that this malfunction is
happening too frequently. I hadn't thought about the possibility of
there being multiple gating paths from the syntax
if state = x then
if inputa = '1' then
state <= y;
to the actual flip-flops of signal "state", but I can see how that would
synthesize to such a condition. A pretty narrow window for this to
happen, but certainly conceivable.
Thanks, I will do the extra registering of the asynch inputs on the next
rev of this!
Jon
Article: 132290On May 20, 3:04 pm, "From Sweden" <s...@sw.se> wrote: > Hello all > > I have made an 8 channel 500kHz low pass IIR-filter in VHDL. The filter uses > 32 bits for it's coefficients and 32 bits for it's internal signals. > > The filter doesn't give the same DC-gain for small vs. large input signals. > I suspect the internal truncation of the intermediate sums and states > effects this. > > But today I thought about increasing the bits for the signal and decreasing > the bits for the coefficients. I tried it out and the filter gave better > gain over different input signal levels. > > Now I wonder how I should optimize the coefficient and signal bit lengths to > get the best result? 32 bits oughta be enough for nearly any application. a quantization error of 1 part outa 4 bizillion? i mean, holy crap!!! the consequences of quantizing coefficients is different from quantizing the signal (or some internal intermediate signal). quantizing coefficients means that the filter you get is not precisely the one that you designed. the poles and zeros didn't go exactly to where you wanted them to go. but with 32-bits it should easily be close enough. how the coefs map to the poles and zeros depends on the filter topology. what topology are you using? Direct Form 1 or Direct Form 2 or Lattice or Normalized Ladder or some other? (i think there is a Gold-Rader form, there's a bunch of them, some of which have an internal All-pass filter that the rest of the thing is built around. i am a partisan for the Direct Form 1 in fixed-point applications.) what you do, is solve for the pole and zero loci as a function of the coefs (that get quantized) and see what effect the coef quantization has on the pole/zero locus. but dividing each of two dimensions of the unit circle up into 4 bizillion slices should be more than good enough. consequences of quantizing the signal can range from a additive noise model (if the signal amplitude is much, much larger than the quantization level) to all sorts of nasties (harmonic distortion, limit cycles). triangular PDF additive dither of 2 LSB amplitude is sufficient to get rid of that stuff. i would think that at 32 bits, simple 1st-order noise shaping (with a zero at DC) would suffice if you got 32 bit words (no dither necessary). this particular error or noise shaping requires one extra state in the DF1 and has been called "fraction saving" and Randy Yates has written about it recently in the IEEE Sig Proc magazine. really, 32 bit words oughta be good enough. r b-jArticle: 132291
Jon Elson wrote:
> As for registering the inputs,
> that DOES seem to be the right thing to do,
It is.
> but the binary-coded state version works fine without.
So far, but wait a while.
The temperature may change.
> Also, the
> clock rates on this are so low, it seems that this malfunction is
> happening too frequently.
It's the the frequency *difference*
that sweeps the setup times
and throws the race the wrong way.
-- Mike Treseler
Article: 132292Jon Elson wrote: > > No DLLs, just a plain single clock. The state machine and all other > hardware > does initialize perfectly. > > As for registering the inputs, that DOES seem to be the right thing to > do, but the binary-coded state version works fine without. That may have more to do with the implicit ELSE handling. ie One State engine locks solid, the other will recover in a few clocks (which means you may not notice, or have not yet noticed the effects!) Even with input registering, you should cover ALL states, (including the 'illegal' ones) in your state code. > Also, the > clock rates on this are so low, it seems that this malfunction is > happening too frequently. Can you clarify 'too frequently' ? With a 25ns clock, a couple of IPs and 5 choices, lets take a nice round 100ns IP sample rate. (10MHz) An aperture effect of 1ns would be hit 1:100, or average 10us. A more likely 100ps aperture, would hit 1:1000, or average 100us, or 10,000 times a second. (assumes random hits) Take your true IP sample rate, and reported timing skews, and get a more accurate prediction. > I hadn't thought about the possibility of > there being multiple gating paths from the syntax > > if state = x then > if inputa = '1' then > state <= y; > > to the actual flip-flops of signal "state", but I can see how that would > synthesize to such a condition. A pretty narrow window for this to > happen, but certainly conceivable. > > Thanks, I will do the extra registering of the asynch inputs on the next > rev of this! There could be a case for the tools to a) Warn on async state conditions b) Warn that illegal/ELSE options are not covered -jgArticle: 132293
On May 20, 10:02 am, "jjlind...@hotmail.com" <jjlind...@hotmail.com> wrote: > Hello, I know many will say this is not an appropriate group to post > such a question, but I wasn't getting any response on the Verilog > group, so please let me apologize. I am new to Verilog and need some > help instantiating a lpm dcfifo in my code. Here is what I have so > far: > > FIFIN : lpm_fifo_dc WITH (LPM_WIDTH = 64, LPM_NUMWORDS = 64, > LPM_WIDTHU = 9, RDSYNC_DELAYPIPE = 3, WRSYNC_DELAYPIPE = 3); > > FIFIN.aclr = (!rstn); > FIFIN.wrclock = (clk); > FIFIN.wrreq = (wr_fiforeq); > FIFIN.data[31..0] = (dma_wrdata); > FIFIN.rdclock = (clk); > FIFIN.rdreq = (dma1_rddata); > FIFIN.q = (rd_fiforeq); > > If anyone has some examples of instantiating a lpm function within > Verilog I would greatly appreciate your help. > > Thanks, > joe Hello, I believe this works: dcfifo # ( .intended_device_family ( "Stratix II GX"), .lpm_hint ( "MAXIMIZE_SPEED=5,"), .lpm_numwords ( 64), .lpm_showahead ( "OFF"), .lpm_type ( "dcfifo"), .lpm_width ( 64), .lpm_widthu ( 6), .overflow_checking ( "ON"), .rdsync_delaypipe ( 4), .underflow_checking ( "ON"), .use_eab ( "ON"), .write_aclr_synch ( "OFF"), .wrsync_delaypipe ( 4) ) dcfifo_component ( .wrclk (wrclk), .rdreq (rdreq), .aclr (aclr), .rdclk (rdclk), .wrreq (wrreq), .data (data), .wrusedw (sub_wire0), .q (sub_wire1), .rdusedw (sub_wire2) // synopsys translate_off , .rdempty (), .rdfull (), .wrempty (), .wrfull () // synopsys translate_on );Article: 132294
"Jon Elson" <elson@wustl.edu> wrote in message news:483324F1.4030005@wustl.edu... > > As for registering the inputs, that DOES seem to be the right thing to do, > but the binary-coded state version works fine without. Hi Jon, You do realise that every build can have different timing? If you're saying DOES because of your P&R results, you MAYBE mistaken. HTH., Syms.Article: 132295
Symon wrote: > "Jeff Cunningham" <jcc@sover.net> wrote in message > news:483200e3$0$11170$4d3efbfe@news.sover.net... >> Clemens wrote: >> >>> A different seed for each power-up would have been nice. >> Here's a method I've used for this in the past: >> >> Create a ring oscillator that can be stopped by some other bit. The ring >> oscillator drives a 2-bit ripple counter. >> >> Once the FPGA clock starts up, count off say 1 second's worth pulses of >> your high speed system clock and then disable the ring oscillator. The >> ripple counter will now have your 4-bit random value. >> >> This method relies on slight differences in the ring osc rate due to >> heating, etc. to add up over 1 second at startup. You might need to >> experiment with adding buffers (and make sure the tools don't remove them) >> and such to make sure the ring osc rate is not too high. >> >> -Jeff > > Hi Jeff, > > I've heard that ring oscillators can phase lock to other clocks on the same > die. What did you find? I came across this link that gives some insights > into the pitfalls. > http://warmcat.com/_wp/ Hi Syms, To generate one number at startup it seemed to work fine, though I admit I didn't subject it to statistical analysis beyond just looking a a bunch of samples. I actually used it to create a GUID that would be stored in flash the first time the product was ever turned on. The goal was that no two devices would have the same number. It seemed to work well for that. Maybe not a good technique for crypto. Interesting web site though. -JeffArticle: 132296
Jon Elson wrote:
>> In addition to registering all inputs, you also should make sure that
>> the state machine is initialized with a synchronous reset after your
>> DLLs have locked.
> No DLLs, just a plain single clock. The state machine and all other
> hardware
> does initialize perfectly.
Just be aware that even without DLLs to worry about, the internal reset
is asynchronous and can cause problems if the state bits see it go away
on different clock pulses, i.e. it is another asynchronous input to your
state machine. I generally always do something like this:
signal resetv: std_logic_vector(2 downto 0) := "000";
process(clk)
begin
if rising_edge(clk)
resetv <= resetv(1 downto 0) & 1;
end if;
end process;
state_machine_reset <= not resetv(2);
-Jeff
Article: 132297austin wrote: > Joseph, > > Imagine all those Altera customers who designed in the Stratix III GX: > all dressed up, and nowhere to go. Maybe Altera also shares roadmaps like you do to bigger customers, and those designers maybe do not exist... Imagine all those V4FX designers who wanted working fast tranceivers. I would say all vendors offer surprises to customers who are using leading edge devices. > Lower Cost: Virtex 5 EasyPath(tm) devices, guaranteed to work, because > they are IDENTICAL to the FPGA My opinion is that EasyPath is the worst of the two worlds. It has limitations in flexibility, and the possibilities with price are not that great because it is the same silicon. Better to have either the full flexibility which costs or then the lowest possible cost with no flexibility. --KimArticle: 132298
On May 19, 5:44=A0pm, morphiend <morphi...@gmail.com> wrote:
> On May 19, 1:35 am, vikram <vikram...@gmail.com> wrote:> hello,
>
> > I am trying to interface between my pc (windows) and a Xilinx
> > Virtex2Pro board using ethernet. i am told i require Xilinx PLB
> > Ethernet MAC ip core. i must admit i am very new to such work, forgive
> > my blatantness.... i would like to know:
>
> > 1) What exactly do i get in the Xilinx Ethernet MAC ip core? (design
> > files etc?)
>
> You get the unlocked CoreGen core. In other words, you could generate
> the core from CoreGen and use it however. Or, you'll be able to use it
> directly in EDK. Of course, since you're referring to the V2Pro,
> you're also referring to the Softcore MAC. This provides a full MAC
> capable of performing 10/100 communication. Starting with EDK 9.2, the
> OPB version of the core has been released for 'free' (included w/ the
> purchase of EDK 9.2).
>
> > 2) Using XPS (EDK 9.1) and ISE 9.1, how do i integrate it into an
> > existing project?
>
> It will appear as an unlocked core in the High-Speed communications
> category of the EDK core list in any of your projects.
>
> > 3) the ethernet is just a part of the project.... i only need to
> > transfer data between my pc and the board.... should the MAC be a part
> > of the board?
>
> Well, Ethernet is split into multiple parts. The first part is the PHY
> or the physical communication. This provides the lowest layer to which
> the data is transmitted. This device is responsible for conversion
> from a Media-Independent Interface (R/S/G/MII) to the physical layer:
> copper/fiber/etc. The next layer up is the MAC: Media Access Control.
> This provides the conversion from your real data into a Media-
> Independent Interface (R/S/G/MII). So unless you're going to build
> your own MAC and design it to meet all of the IEEE specs for whatever
> MII you use, then YES you need it.
>
> > 4) do i have to use an embedded processor (microblaze/powerpc) to
> > integrate the MAC?
>
> No, but depending on what you're doing you may want to have processor
> perform the work. It's possible to create devices that just take/put
> streams with solely logic and state machines. But if you want to start
> handling TCP traffic or anything higher-layer (HTTP/FTP) or more
> complicated you will probably want a processor and software to handle
> it. But that's my $0.02.
>
> -- Mike
dear Mike
thanks for the prompt response. the board i'm using has an on-board
PHY.
>You get the unlocked CoreGen core. In other words, you could generate
the core from CoreGen and use it.
once i have the generated MAC core, do i just add it to my existing
project to 'use' it?
or, from EDK, do i add it as a peripheral ("import peripheral") to my
existing project?
thanks again
vikram
Article: 132299On May 20, 10:17=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > austin wrote: > > Joseph, > > > Imagine all those Altera customers who designed in the Stratix III GX: > > all dressed up, and nowhere to go. > > Maybe Altera also shares roadmaps like you do to bigger customers, and > those designers maybe do not exist... Imagine all those V4FX designers > who wanted working fast tranceivers. > > I would say all vendors offer surprises to customers who are using > leading edge devices. > > > Lower Cost: Virtex 5 EasyPath(tm) devices, guaranteed to work, because > > they are IDENTICAL to the FPGA > > My opinion is that EasyPath is the worst of the two worlds. It has > limitations in flexibility, and the possibilities with price are > not that great because it is the same silicon. Better to have either > the full flexibility which costs or then the lowest possible cost > with no flexibility. > > --Kim Let's not turn this into a marketing slugfest. It does not take a genius to figure out why Altera was forced to embark on such a risky gamble... "We live in interesting times" Peter Alfke
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