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
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:3f4a0737@dnews.tpgi.com.au... > I notice that the maximum recommended Virtex2pro Vbatt is 2.63V. > Lithium cells put out more than that. Many chips don't go to sleep mode until the VDD has dropped quite a bit. See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm The 2V63 value might be the ideal value on their VDD/IDD graph, with most headroom for battery voltage droop, but lower voltages (e.g. 2V4) might work just as well. > Is the solution as simple as a series Si diode on the Vbatt line? Textbooks show zero current up to Vf but I suspect Vf drop depends on current, even before then. It should be a quick experiment to see what happens.Article: 59776
I am using DCM in VirtexII device. I feed 40 MHz clock to CLKIN and use CLK2X output (80Mhz) and CLKDV output (2.5MHz), so these clocks should be in phase. Can I feed output from flip/flop clocked by CLKDV directly to FF clocked by CLK2X without additional constraints except of PERIOD for CLKIN? The PERIOD constraint propagates to both clocks, but I'm not sure that path from CLKDV FF to CLK2X FF is checked as well. Constraints Guide says: "A clock period specification checks timing between all synchronous elements within the clock domain as defined in the destination element group. The group may contain paths that pass between clock domains if the clocks are defined as a function of one or the other." Also examples show that it is possible to specify phase shift between clock and clock derived from this base clock. I think just to check path between two created in this way clock domains. So, I think this path is checked, but I'm looking for some confirmation. -- RobertPArticle: 59777
Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>... > The output level of a flip-flop during its metastable time is > irrelevant. If it were in the middle ( which it isn't) we could easily > fix this with a zener diode. > The problem is timing. The Q output can - and will - change to the > opposite state at a totally unpredictable time. That's the problem: > unpredictable timing, not unknown levels. > > Cascading flip-flops is the standard remedy, but it introduces latency. > > Remember: Metastability causes an extra 3 ns of unpredictable delay once > in a billion years... Seems to be an affordable risk. > > Peter Alfke Peter, kind of disagree. Of course for the designer, the problem is timing. But the timing problem is caused by the voltage problem. If we had a well defined voltage behavior (as I thought, but now I know I were wrong), we could fix the timing problem (as you said for the "in the middle" problem). Anyway, I undestood what you said. I also disagree that the problem has no solution. As an engineer I don't believe in no solution problems, we just don't know the solutions yet. But this is philosophy! Luiz CarlosArticle: 59778
Thankyou Philip. But as I said, I don't believe "There is no cure for metastability", or any other problem. It's just a question of time. Luiz Carlos.Article: 59779
> I'm thinking to implement it in the Block RAM (Is there any other > method which is more efficient than this one in SpartanII?). > The dual RAM ports of Spartan-II are configurable to any size from > 4Kx1 to 256x16. (In the XAPP173 "Using Block Select Ram+ Memory in > Spartan-II" of Xilinx, there is a table1 which don't have port aspect > ratios for 32x1) > Can I implement FIFO of 32x1 in this BlockRam of Spartan-II? You can use any depth for your FIFO as long as it is below 4K. XAPP175 talks about FIFO implementation in SpartanII. Jim Wu jimwu88NOOOSPAM@yahoo.com http://www.geocities.com/jimwu88/chipsArticle: 59780
I want to use an FPGA input as an high speed analog comparator. Let's say I'm using an Spartan2 and configured one it's inputs as HSTL class 3. I want to sample an analog input signal. The manual says: Vout = low, if Vin <= Vref - 0.5 Vout = high, if Vin >= Vref + 0.5 But, what does hapen if Vin=Vref+0.1? Does Vout still go high? What's the maximum clock (sample) frequency? Is there a formula for the settling time versus Vin-Vref difference? I think this is related to the metastability problem, but I preferred to start a new thread. Is there a better input configuration for this purpose (HSTL, AGP, etc)? Now let's suppose this works, and that I don't care the value of Vref, and it's not a problem if Vref changes slowly. I will configure the input as LVCMOS. What can produce a fast change of the internal Vref? Other pins of the same IO bank configured as outputs and swithcing? Luiz CarlosArticle: 59781
You sound like a good candidate to spend you time pursuing a perpetual motion machine.
The physics stipulate that you'll have a probability of hitting a metastable state. As
processes improve, we can narrow the width of the window, but we can't eliminate it.
Narrowing the width reduces the probability of hitting it for a fixed clock rate. Trouble
is, as the process improvements occur that permit narrowing the window, the clock speeds
also increase, so unless the designer designs for metastbility, the odds may not improve.
Luiz Carlos wrote:
> Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>...
> > The output level of a flip-flop during its metastable time is
> > irrelevant. If it were in the middle ( which it isn't) we could easily
> > fix this with a zener diode.
> > The problem is timing. The Q output can - and will - change to the
> > opposite state at a totally unpredictable time. That's the problem:
> > unpredictable timing, not unknown levels.
> >
> > Cascading flip-flops is the standard remedy, but it introduces latency.
> >
> > Remember: Metastability causes an extra 3 ns of unpredictable delay once
> > in a billion years... Seems to be an affordable risk.
> >
> > Peter Alfke
>
> Peter, kind of disagree.
>
> Of course for the designer, the problem is timing. But the timing
> problem is caused by the voltage problem. If we had a well defined
> voltage behavior (as I thought, but now I know I were wrong), we could
> fix the timing problem (as you said for the "in the middle" problem).
> Anyway, I undestood what you said.
>
> I also disagree that the problem has no solution. As an engineer I
> don't believe in no solution problems, we just don't know the
> solutions yet. But this is philosophy!
>
> Luiz Carlos
--
--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: 59782kryten_droid wrote: > "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in > message news:3f4a0737@dnews.tpgi.com.au... > >>I notice that the maximum recommended Virtex2pro Vbatt is 2.63V. >>Lithium cells put out more than that. > > > Many chips don't go to sleep mode until the VDD has dropped quite a bit. > > See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm Is this relevant to Virtex2pro? > The 2V63 value might be the ideal value on their VDD/IDD graph, with most > headroom for battery voltage droop, but lower voltages (e.g. 2V4) might work > just as well. The data sheet indicates voltages down to 1.0V are fine. >>Is the solution as simple as a series Si diode on the Vbatt line? > > > Textbooks show zero current up to Vf but I suspect Vf drop depends on > current, even before then. You might like to Google for the "diode equation". It will confirm your suspicion. BTW, you need better textbooks ;) Extrapolating a curve in the 1N914 datasheet gives about 120 - 130mV forward voltage at 100nA forward current. (This diode has an ideality factor of about 2.) The V2P data sheet indicates 100nA typical Ibatt over the recommended operating conditions. They don't specify a maximum current - I hope it's not 10uA or something. ;) Regards, Allan.Article: 59783
"Nicholas C. Weaver" wrote: > > In article <3F4D5682.AA13889@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> wrote: > >I understand how the resolution time affects the failure rate. I also > >understand that the timing window is so small that it is very hard to > >hit even if you try. My point is that the analysis has been done > >assuming a random distribution of timing which is not valid for this > >case. If you have an MTBF of 100 years with the standard model, you may > >well see an MTBF of an hour or less with this situation. I will be > >using a half clock cycle (10 ns) minus some 5 ns of delay which should > >give me lots of room for settling. But unless I acutally know something > >about my timing distribution it will be hard to say what my expected > >MTBF is. > > Then add random jitter into your CLOCK, and now you are back into the > randomized model, no? There is already jitter in any clock you pick. I expect this jitter is much larger than the fs window that Peter has calculated for the metastable time window. But unless all values of delay are equally likely, the original equations do not apply. If your clock cycle period is p and your jitter is j, the occurance of failure compared to the standard model is p/j times more likely. I think knowing this helps a lot since it should be easy to add enough extra delay to offset any fixed value for this ratio. -- 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: 59784
RobertP wrote: > > I am using DCM in VirtexII device. I feed 40 MHz clock to CLKIN and use > CLK2X output (80Mhz) and CLKDV output (2.5MHz), so these clocks should > be in phase. > Can I feed output from flip/flop clocked by CLKDV directly to FF clocked > by CLK2X without additional constraints except of PERIOD for CLKIN? > > The PERIOD constraint propagates to both clocks, but I'm not sure that > path from CLKDV FF to CLK2X FF is checked as well. > > Constraints Guide says: > > "A clock period specification checks timing between all synchronous > elements within the clock domain as defined in the destination element > group. The group may contain paths that pass between clock domains if > the clocks are defined as a function of one or the other." > > Also examples show that it is possible to specify phase shift between > clock and clock derived from this base clock. I think just to check path > between two created in this way clock domains. > > So, I think this path is checked, but I'm looking for some confirmation. I am not certain, but I think the above text is saying that if you specify the derived clocks in terms of the starting clock, then the tool will check paths between the clock domains. This means you should say the period of CLKIN is 25 ns and the period of CLK2X is half of this and the period of CLKDV is 16 x this value. -- 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: 59785
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:3f4df8f2$1@dnews.tpgi.com.au... > > See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm > Is this relevant to Virtex2pro? The bits about chips often having definite thresholds for low-power modes kicking in. > The data sheet indicates voltages down to 1.0V are fine. Great, a 2V4 batt should be fine then. > You might like to Google for the "diode equation". It will confirm your > suspicion. BTW, you need better textbooks ;) No insult to your intelligence intended. It's just that on most graphs of Vf/If, it does look flat below Vf threshold. > The V2P data sheet indicates 100nA typical Ibatt over the recommended > operating conditions. They don't specify a maximum current - I hope > it's not 10uA or something. ;) Even with 700 mV drop, a 2V4 batt should be fine. By the time it drops to 1V7, it is pretty much out of juice anyway.Article: 59786
Luiz, you need to read up on metastability. There are things even in physics that have no solution. Perpetual motion is one. If you want to get philosophical about metastability, read Heisenberg's Uncertainty papers. Phil Freidin has described the problem very well. He and I agree 100% on the problem. But I have made quantitative tests and know the (very low) probability. Everybody has an opinion, very few have performed measurements... Peter Alfke ================================= Luiz Carlos wrote: > > Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>... > > The output level of a flip-flop during its metastable time is > > irrelevant. If it were in the middle ( which it isn't) we could easily > > fix this with a zener diode. > > The problem is timing. The Q output can - and will - change to the > > opposite state at a totally unpredictable time. That's the problem: > > unpredictable timing, not unknown levels. > > > > Cascading flip-flops is the standard remedy, but it introduces latency. > > > > Remember: Metastability causes an extra 3 ns of unpredictable delay once > > in a billion years... Seems to be an affordable risk. > > > > Peter Alfke > > Peter, kind of disagree. > > Of course for the designer, the problem is timing. But the timing > problem is caused by the voltage problem. If we had a well defined > voltage behavior (as I thought, but now I know I were wrong), we could > fix the timing problem (as you said for the "in the middle" problem). > Anyway, I undestood what you said. > > I also disagree that the problem has no solution. As an engineer I > don't believe in no solution problems, we just don't know the > solutions yet. But this is philosophy! > > Luiz CarlosArticle: 59787
John, there is only one way to find your answer: Contact your local sales representative or distributor or FAE for the X andalso for the A company and explain your requirements in as much detail as possible ( speed, package, delivery date, etc). Then let them each give you a quote. Peter Alfke ============================ John Lee wrote: > > Hi all, > > What is the price for a maximux of 50K system gates, IO counts is not > an issue, with more than 100K volumn per year? We look at cyclone and > spartan series because Xilinx and Altera claimed they are cheap. > > 100K is the minimum. > > Thanks, > JohnArticle: 59788
The word "Flash" means that it is electrically erasable. Peter Alfke ==================== Atif wrote: > > Can anyone please tell me is Xilinx Platform Flash PROM an Electrically > erasable? If no, which technology it uses? > > Regards > AtifArticle: 59789
Hi to all, The sum or average of a certain number of samples (for ex. the last 100 values received) have to be checked constantly against a threshold. I thought of implementing this by keeping a "Moving Sum" which will work by adding the new value and subtracting the oldest. I think that can be implemented by adding to a register the value just arriving and subtracting the value coming out of an 100 word deep shift register. Now, if a longer sum has to be checked then there is a memory problem because a lot of values have to be stored. In addition more than one "Moving Sums" is needed so if I use the above implementation I will have in addition to store the same data more than once (for ex. the 1000 word Shift Register will include the 100 word S.R. data). Any idea of how this could be implemented? The final system will have to keep 10 moving sums with the largest being 250,000 (8-bit) values for each of the 16 independent input channels. Help to the design problem will be appreciated and acknowledged. Christos __________________________________________________ Christos Zamantzas CERN, European Organization for Nuclear Research Div. AB/BDI/BL tel: +41 22 767 3409 CH-1211 Geneva 23 fax: +41 22 767 9560 Switzerland christos.zamantzas@cern.ch __________________________________________________Article: 59790
"Ray Andraka" <ray@andraka.com> wrote in message news:3F4D8155.A14C666F@andraka.com... > How about not just music out of an FPGA pin, but a complete shortwave receiver using just a SpartanII FPGA > and an AtoD converter? See the block diagram on my website. Sounds like fun. Are you going to post the HDL?Article: 59791
In article <bil9f7$4o2$1@sunnews.cern.ch>, Christos <chris_saturnNOSPAM@hotmail.com> wrote: > >I thought of implementing this by keeping a "Moving Sum" which will work by >adding the new value and subtracting the oldest. I think that can be >implemented by adding to a register the value just arriving and subtracting >the value coming out of an 100 word deep shift register. > >Now, if a longer sum has to be checked then there is a memory problem >because a lot of values have to be stored. In addition more than one "Moving >Sums" is needed so if I use the above implementation I will have in addition >to store the same data more than once (for ex. the 1000 word Shift Register >will include the 100 word S.R. data). > >Any idea of how this could be implemented? Can you cheat? That is, instead of having a 250,000 deep moving sum, have it be 250,000 deep but only at intervals of every 1000 samples? The other option is once you have to go off-chip for memory for the FIFO's, the size doesn't matter much because you can easily just throw ~1GB of DRAM on the other side. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 59792
On 28 Aug 2003 04:08:55 -0700, oen_br@yahoo.com.br (Luiz Carlos) wrote: >Thankyou Philip. >But as I said, I don't believe "There is no cure for metastability", >or any other problem. It's just a question of time. Yep, you are right, it is just a matter of time. In this case it is infinite. When you do your designs do you A) Do nothing special for async signals entering a synchronous domain, because some day someone will solve this problem. or B) Use multistage synchronizers to move signals from one clock domain to another, because some day someone will solve this problem, but it hasn't happened yet. or C) Not sure, because I haven't ever seen this problem. >Luiz Carlos. PhilipArticle: 59793
Hi all, I have a vhdl component with a "clock_in" input. Depending on the mode of operation, I want to switch between two different clock signals. I will never switch on the fly though. Can I use a mux in front of the clock_in input? I'm afraid it might glitch. Thanks DavidArticle: 59794
Jan Panteltje wrote: > On a sunny day (Tue, 26 Aug 2003 18:58:54 GMT) it happened Rene Tschaggelar > <tschaggelar@dplanet.ch> wrote in > <d8a593f9a0070578ab8201755480f4a3@news.teranews.com>: > > >>NOSPAM@NOSPAM.invalid.com wrote: >> >>>Hello, >>>Please, does anybody know if there's any FPGA manufacturer >>>that will give a sample FPGA for free? >> >>You're going to spend days and weeks with the free software, >>to become familiar. >>And you may have to build your own programmer, again a day of >>layout and etching, so what does it help if you don't have to >>pay 4$ for a 4$ part ? > > That will buy you a huge peche melba here, nice if its 40 celcius. > Yes. I'd get the peche melba by saving my time by not spending a few hours on the internet looking for free samples of 4$ parts. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 59795
"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message news:bilfne$sel$1@home.itg.ti.com... > Hi all, > I have a vhdl component with a "clock_in" input. Depending on the mode of > operation, I want to switch between two different clock signals. I will > never switch on the fly though. Can I use a mux in front of the clock_in > input? I'm afraid it might glitch. > Thanks > David > > David, Do a query for 'clock sources' in the category 'XCELL Journals' on the Xilinx web site. This will provide you with a link called 'XCELL 24 - Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead you to xl24_20.pdf, a neat little circuit that hopefully will ease your worries :) Keep in mind that whatever you put in the clock path will affect the setup and hold time requirements for the particular component. Take care, Marten ] remove the obvious to repy by e-mail [Article: 59796
In article <8471ba54.0308280308.232c7bfe@posting.google.com>, Luiz Carlos <oen_br@yahoo.com.br> wrote: >Thankyou Philip. >But as I said, I don't believe "There is no cure for metastability", >or any other problem. It's just a question of time. You can make the capture window small, but there is always a finite chance that you will capture the metastable point. Basic calculus: IF a curve has two local minima (the stable points), there must be one local maximum (the metastable point) between the two. If you happen to capture the input data when it is at the metastable point, metastability/unstable equilibria happens. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 59797
Look for "CIC filter". CIC is a Cascaded integrator Comb filter. It is a
recursive implementation of a moving sum. In your case, it sounds like you are
sampling the output once for every input sample, so you don't get the benefit of
decimation (if you could decimate, then the delay queue is shortened by a ratio
equal to the decimation ratio). The CIC consists of an integrator, a subtractor
and a delay queue. For a moving sum, you are stuck with the storage and the key
is to minimize the number of transactions you need to do with the storage per
sample. In the case of the CIC, you need to do one read and one write per
sample. For the depth you are looking at, you'll need to use off chip memory
for the storage (you might fit it into the bulk storage on an Altera Stratix).
You did not mention the sample rate. If the data rate is sufficiently low, you
can time multiplex the data in/out of the external memory so that you can trade
memory width for depth, which might get you a lower parts count.
Christos wrote:
> Hi to all,
>
> The sum or average of a certain number of samples (for ex. the last 100
> values received) have to be checked constantly against a threshold.
>
> I thought of implementing this by keeping a "Moving Sum" which will work by
> adding the new value and subtracting the oldest. I think that can be
> implemented by adding to a register the value just arriving and subtracting
> the value coming out of an 100 word deep shift register.
>
> Now, if a longer sum has to be checked then there is a memory problem
> because a lot of values have to be stored. In addition more than one "Moving
> Sums" is needed so if I use the above implementation I will have in addition
> to store the same data more than once (for ex. the 1000 word Shift Register
> will include the 100 word S.R. data).
>
> Any idea of how this could be implemented?
>
> The final system will have to keep 10 moving sums with the largest being
> 250,000 (8-bit) values for each of the 16 independent input channels.
>
> Help to the design problem will be appreciated and acknowledged.
>
> Christos
>
> __________________________________________________
>
> Christos Zamantzas
> CERN, European Organization for Nuclear Research
> Div. AB/BDI/BL tel: +41 22 767 3409
> CH-1211 Geneva 23 fax: +41 22 767 9560
> Switzerland christos.zamantzas@cern.ch
> __________________________________________________
--
--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: 59798Another option, if you're using Xilinx parts, is to take advantage of those SRL16's. In V2P parts (and I think V2) there are 2 per slice. With 64 of these guys cascaded together, you've got a 1-bit wide, 1024-bit long moving sum (barrel shift down for the average). That's 32 slices, or 8 CLB's per bit-width, depending on the level of abstraction you like to think about. --Josh "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message news:bilbs8$1ck0$2@agate.berkeley.edu... > In article <bil9f7$4o2$1@sunnews.cern.ch>, > Christos <chris_saturnNOSPAM@hotmail.com> wrote: > > > >I thought of implementing this by keeping a "Moving Sum" which will work by > >adding the new value and subtracting the oldest. I think that can be > >implemented by adding to a register the value just arriving and subtracting > >the value coming out of an 100 word deep shift register. > > > >Now, if a longer sum has to be checked then there is a memory problem > >because a lot of values have to be stored. In addition more than one "Moving > >Sums" is needed so if I use the above implementation I will have in addition > >to store the same data more than once (for ex. the 1000 word Shift Register > >will include the 100 word S.R. data). > > > >Any idea of how this could be implemented? > > Can you cheat? That is, instead of having a 250,000 deep moving sum, > have it be 250,000 deep but only at intervals of every 1000 samples? > > The other option is once you have to go off-chip for memory for the > FIFO's, the size doesn't matter much because you can easily just throw > ~1GB of DRAM on the other side. > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 59799
Whoops, probably won't work in your case-- I didn't read that last paragraph. But the SRL's are still good for less gigantic moving sums. --Josh "Josh Model" <model@ll.mit.edu> wrote in message news:cBs3b.78$Y5.41@llslave.llan.ll.mit.edu... > Another option, if you're using Xilinx parts, is to take advantage of those > SRL16's. In V2P parts (and I think V2) there are 2 per slice. With 64 of > these guys cascaded together, you've got a 1-bit wide, 1024-bit long moving > sum (barrel shift down for the average). That's 32 slices, or 8 CLB's per > bit-width, depending on the level of abstraction you like to think about. > > --Josh > > > "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message > news:bilbs8$1ck0$2@agate.berkeley.edu... > > In article <bil9f7$4o2$1@sunnews.cern.ch>, > > Christos <chris_saturnNOSPAM@hotmail.com> wrote: > > > > > >I thought of implementing this by keeping a "Moving Sum" which will work > by > > >adding the new value and subtracting the oldest. I think that can be > > >implemented by adding to a register the value just arriving and > subtracting > > >the value coming out of an 100 word deep shift register. > > > > > >Now, if a longer sum has to be checked then there is a memory problem > > >because a lot of values have to be stored. In addition more than one > "Moving > > >Sums" is needed so if I use the above implementation I will have in > addition > > >to store the same data more than once (for ex. the 1000 word Shift > Register > > >will include the 100 word S.R. data). > > > > > >Any idea of how this could be implemented? > > > > Can you cheat? That is, instead of having a 250,000 deep moving sum, > > have it be 250,000 deep but only at intervals of every 1000 samples? > > > > The other option is once you have to go off-chip for memory for the > > FIFO's, the size doesn't matter much because you can easily just throw > > ~1GB of DRAM on the other side. > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.edu > >
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