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
Does anybody know if/where a pre-made linux build for the memec v4 fx12 mini-module development kit? PPC linux preferred but microblaze is fine too. I'm just doing software evaluation and measuring power consumption so any linux is fine. I'm not interest in the source files now, just what ever programming files I need for the board to get a console and network interface. Thanks, ClarkArticle: 99451
Thanks for all the thoughts about this issue. With my design, I put tight (but achievable) constraints on my critical signal and used RLOCs to lock the flip-flops in reasonable postitions. If I use the multi-pass P&R, sometimes the tool makes timing on the critical net, sometimes it just misses. So having a 'good' constraint won't force P&R to perform correctly. Gien that the identical verilog is used for my tests, Sean's comments about local clock inversion probably don't apply. It purely appears to depend on P&R. I'll give Brian's MAXDELAY tip a try next. I'll keep you posted on results. John ProvidenzaArticle: 99452
I know the mini modules as sold with as linux kit on japanese markets at least dont know if it is available outside japan but it isnt actually so complicated to get it going yourself too AnttiArticle: 99453
"Roger Bourne" <rover8898@hotmail.com> wrote in message news:1143217383.027265.260570@g10g2000cwb.googlegroups.com... > > > How can a half-band FIR filter be employed as a decimating FIR filter > for a downsampling factor of 2 ? If my limited understanding of > half-bands (Lth-bands=2) is accurate, then the stopband of the > half-band will lie above Fs/4 (Fs/2 -Fpass, where Fpass cannot exceed > Fs/4). This will violate the anti-aliasing criterion and as such will > make it non-viable to use as a decimating filter. > > What am I missing? > (From what I can tell from Mr.Google, halfs-bands are very popular, so > my reasonning must be off...) > > -Roger > Hi Roger, So, a lowpass half-band filter has a passband 0 to Fp where Fp is < Fs/4 The stop band is (Fs/2 - Fp) to Fs/2 If you use this as your specification for a filter using the Remez exchange algorithm for making odd order (i.e. odd number of coeffs) FIR filters, you'll find every second tap is zero, except for the middle tap which is 0.5. (Unless you've scaled things somewhere) To decimate by 8 in three stages, your first filter has a passband from 0 to Fs/32 and a stop band from Fs*15/32 to Fs/2 As you're decimating, you can throw away every other sample that comes out of this filter. Then, at your new sample rate, which is half the previous rate so F2s = Fs/2 , your next filter has a passband from 0 to F2s/16 and a stop band from F2s*7/16 to F2s/2 ....and so on for the third stage. Anyway, I hope this helps, I know my posts often ramble a bit, hopefully you can google some of this to make more sense! It works great though. Cheers, Syms. p.s. You could google for scopefir, a FIR design program that you can use for free for a while before you buy. p.p.s. I guess you've been here http://www.dspguru.com/info/faqs/mrfaq.htm ?Article: 99454
Hi all, If we have a big project involving one or more FPGAs plus several other circuits, and of course high frequencies on the board. Is it interesting to write models of the onboard components which communicate with the FPGA or is it sufficient to simulate/verify the FPGA and than to make signal integrity tests? Cheers MehdiArticle: 99455
Roger, The book I learnt all this from is Multirate Digital Signal Processing by Ronald E. Crochiere, Lawrence R. Rabiner HTH, SYms.Article: 99456
Hi, http://www.filter-solutions.com/ The full version can create C Sourcecode MarkusArticle: 99457
Hi Symon, > So, a lowpass half-band filter has a passband > 0 to Fp where Fp is < Fs/4 > > The stop band is > > (Fs/2 - Fp) to Fs/2 > > If you use this as your specification for a filter using the Remez exchange > algorithm for making odd order (i.e. odd number of coeffs) FIR filters, > you'll find every second tap is zero, except for the middle tap which is > 0.5. (Unless you've scaled things somewhere) > > To decimate by 8 in three stages, your first filter has a passband from > > 0 to Fs/32 > > and a stop band from > > Fs*15/32 to Fs/2 > > > As you're decimating, you can throw away every other sample that comes out > of this filter. Then, at your new sample rate, which is half the previous > rate so F2s = Fs/2 , your next filter has a passband from > If the stopband is Fs*15/32 to Fs/2, then it implies that the attenuation at frequencies around Fs/4 will be rather weak. Isn't important that all frequencies above Fs/4 suffer a strong attenuation, in order the Nyquist criterion be met at the post-decimation sampling frequency (F2s=Fs/2) because we are downsampling by 2 ? (I get the impression the solution is staring me rigth in the eyes and I just can't see it! ;) ) P.S I been using ScopeFiR. -RogerArticle: 99458
Roger Bourne wrote: >>Roger, >>Look at making your filter as a series of half-band FIR filters. These are >>efficient in that every other tap is zero. (Nice and easy to multiply by >>zero!) Use three, decimating by two at each stage. Your implementation >>should be a lot more compact. > > > I am new to the digital filter world. Every day I discover a new type > another type of digital filter, so perphaps (or most probably) I am > wrong in my following observation: > > How can a half-band FIR filter be employed as a decimating FIR filter > for a downsampling factor of 2 ? If my limited understanding of > half-bands (Lth-bands=2) is accurate, then the stopband of the > half-band will lie above Fs/4 (Fs/2 -Fpass, where Fpass cannot exceed > Fs/4). This will violate the anti-aliasing criterion and as such will > make it non-viable to use as a decimating filter. > > What am I missing? > (From what I can tell from Mr.Google, halfs-bands are very popular, so > my reasonning must be off...) > > -Roger > Roger, yes, as you point out, when the half band is used for decimate by 2, half of the transition band folds back on the other half of the transition band, so there is some aliasing in a band equal in width to half the width of the transition band. This folded energy is all adjacent to Fs/4. This happens because the half-band filter, by definition, has a symmetry about Fs/4, which means the attenuation is exactly 6dB at Fs/4. If this is the only filter in your design, then, yes this would present a problem for decimation. The piece you are missing is that these are used in conjuction with other filters in a system, and the other filtering removes the energy left over in the transition band. Most of the time, you have one or more cascaded decimate by 2 half band filters, followed by a filter at the lower sample rate that does the final passband filtering. Each half band stage eliminates the aliased transition band left over from the previous halfband stage, and then introduces a bit of aliasing from its own transition region. The (typically last) last filter in the filter chain is not a half-band filter and has a passband that eliminates the transition of the last halfband filter.Article: 99459
"Roger Bourne" <rover8898@hotmail.com> wrote in message news:1143220705.999192.189270@g10g2000cwb.googlegroups.com... > > If the stopband is Fs*15/32 to Fs/2, then it implies that the > attenuation at frequencies around Fs/4 will be rather weak. Isn't > important that all frequencies above Fs/4 suffer a strong attenuation, > in order the Nyquist criterion be met at the post-decimation sampling > frequency (F2s=Fs/2) because we are downsampling by 2 ? > (I get the impression the solution is staring me rigth in the eyes and > I just can't see it! ;) ) > Ah, OK, I see your problem. The idea is that you keep (only) your band of interest un-aliased. When you're decimating, signals alias or fold back. What you do is decide all your signals of interest are in a certain band, say 0 - Fs/32 in my previous post, and make sure this band stays un-aliased. It doesn't matter that other frequencies get aliased, you can filter them out later at your lower sample rate! HTH, Syms.Article: 99460
John McGrath wrote: > Hi, > Can you do this: > Take the tricky part of the design into a new blank design on its own. > Get the P&R to churn away on that until it gets something that works > (should be easier, as there is nothing from a huge design to get in its > way). > Then export that routing to a ucf, as suggested by Ray, and finally re > run with this ucf for the full design. > I could be completly wrong - but it might save you the hassle of hand > placing. > > Maybe something like PlanAhead also - that seems to be incredible for > constraining the P&R tools in a graphical way - check out the Demos on > Demand for it on the Xilinx website. > No, unfortunately that doesn't work too well. The router does no better for small designs...it just isn't as noticible because the routes that go outside the used LUTs aren't impeded by congestion from neighboring logic. If you tried to plug that back into a dense design, you get route collisions. PlanAhead and floorplanner also don't help for routing. They can specify placement, but not routing. Anyway, the hand placing isn't too much a hassle if you do it hierarchically in your source code. Look at the gallery on my website http://www.andraka.com/gallery for some (admittedly dated, I haven't updated it in a while) examples of designs that were floorplanned using RLOCs embedded in the VHDL.Article: 99461
Ah, I see Ray's posted a good explanation! Thanks! It's difficult to explain this on a text newsgroup as you can't see me frantically arm waving! So check out:- http://www.xilinx.com/ipcenter/catalog/logicore/docs/cic.pdf For some diagrams which show the aliasing when using CIC filters. The half=band thing is much the same. HTH, Syms.Article: 99462
Brian Davis wrote: > Ray wrote: > >>The thing is, it no longer picks the low hanging fruit (ie the direct connects) >>consistently, which in turn congests the other routing resources. >> > > > One thing I've done in 5.x and 6.x ( but haven't tried in 7.x or 8.x ) > that seems to work OK is to go into FPGA editor with a simple test > design, find the delays for the direct connect paths I want it to use, > then stick a MAXDELAY on those nets to force the router to use > those connections. > > This has worked well in conjunction with placed logic without > resorting to the directed routing constraints ( at least for the small > sections of critical logic that I've used it for so far, I'm not sure > if a horde of MAXDELAYs would blow up P&R for a big RPM ). > > Brian > Brian, I've tried that. For one or two it seems to work. For many, it slows PAR way down and usually won't find a solution where all the maxdelays get met, not to mention making the UCF a nightmare.Article: 99463
Ray Andraka wrote: > > If this is the only filter in your design, then, yes this would present > a problem for decimation. The piece you are missing is that these are > used in conjuction with other filters in a system, and the other > filtering removes the energy left over in the transition band. Most of > the time, you have one or more cascaded decimate by 2 half band filters, > followed by a filter at the lower sample rate that does the final > passband filtering. Each half band stage eliminates the aliased > transition band left over from the previous halfband stage, and then > introduces a bit of aliasing from its own transition region. The > (typically last) last filter in the filter chain is not a half-band > filter and has a passband that eliminates the transition of the last > halfband filter. I get it now. The halfband by 2 filters do not (can not) remove the aliasing that is incurred by the folding of their transitions over Fs/4 (and are not intrested to do so...). However, we (the general WE) do not care that aliasing occurs, since the aliasing does not affect the frequency range of interest (0Hz to Fs_orig/(something rather big, at least 2 digits). The aliasing is OF COURSE removed by an additional filter (following the cascaded half band filters) which targets the bandwith of the data. Hence, the benfits of using a cascade of half band filters to decimate by a power of 2, as I understand it, are: 1. Since aliasing is permitted (as mentionned before), the filter does not have to be sharp, and as such has a low nb of coeffcients. 2. Since every other coefficient is 0, in HW implemention, the FIR will require only ~1/2 the amount of delay elements clocked at half the input sampe rate (of that particular half band). Rigth? -RogerArticle: 99464
Hi, I know there are MIPS cores out there that support multithreading; I was wondering if a multithreaded version of Altera's NIOS II core exists or if it's under development? If it does exist, what is the software support for such an architecture? Or is anybody aware of any public-domain multithreaded cores? Thanks, ShyamArticle: 99465
Nju Njoroge wrote:
> I would like to access environment variables defined in ModelSim (6.0d)
> in my Verilog code so that I can use them with the `ifdef construct.
> For instance, ModelSim allows you to access the "MODEL_TECH"
> environment variable, which is useful for employing `ifdef's on code
> you want that you want to be compiled for simulation, but ignored for
> hardware synthesis.
From the modelsim TCL prompt you can
get at underlying OS commands using the
tcl _exec_ command. For example, if I
have env and grep on my machine, I can do
things like:
VSIM 17> exec env | grep RSH
# CVS_RSH=ssh
VSIM 18> exec env | grep MODEL
# MODELSIM_TCL=/evtfs/home/tres/tcl/modelsim.tcl
# MODELTECH=/flip/usr1/modeltech
# MODEL_TECH=/flip/usr1/modeltech/linux
# MODEL_TECH_TCL=/flip/usr1/modeltech/linux/../tcl
# MODELSIM=modelsim.ini
But the only interface common to HDL and TCL is a file.
-- Mike Treseler
Article: 99466The thing is that MODEL_TECH isn't an environment variable, it's a Verilog macro that Modelsim automatically defines for you. It's the same as if you did `define FOO in your code or +define+FOO on the vlog command line. Your choices are to pass your settings on the vlog command line (+define+MY_VARIABLE=1) or write them to a file (`define MY_VARIABLE 1) that gets compiled in with your testbench. -cbArticle: 99467
Roger Bourne wrote: Hence, the benfits of using a cascade of half > band filters to decimate by a power of 2, as I understand it, are: > 1. Since aliasing is permitted (as mentionned before), the filter does > not have to be sharp, and as such has a low nb of coeffcients. > 2. Since every other coefficient is 0, in HW implemention, the FIR will > require only ~1/2 the amount of delay elements clocked at half the > input sampe rate (of that particular half band). > > Rigth? > > -Roger > Close. You have only half the mulitplies, since the multiplies by zero are trivial. Also, with the polyphase decimation, the filter gets split into two banks, each operating at half the sample rate of the input. One bank has all the even coefficients, the other has all the odd. Only one odd coefficient is non-zero, so the odd filter bank reduces to a constant multiply. Plus, that is the center tap; in most halfband filters, the center tap value is equal to the sum of the other coefficients, and is half the DC gain. As a result, that tap multiplier is frequently just a shift and a delay of half the filter length (this delay is an odd number of clocks). The delay for the other taps can either be half the length clocked at the output frequency, or the full length clocked at the input frequency, since only every other tap is used. The big savings is eliminating the multipliers.Article: 99468
Austin Lesea wrote: > Antti, > > Personally, I think the purchasing agent should refine their negociation > skills. > > If you will not accept an early shipment, that has to be specified in > the purchase agreement. > > Of course, asking the distributor to stock for you (which is effectively > what you are doing) will cost them money (evening out the > supply/demand), which will raise the price to you. Anyone remember the old days, when 'distributor' actually meant what it says ? -jgArticle: 99469
Gentlemen, The least you can say, is that this thread is quite of the original request from OP. By the time everyone has said what he wanted to say about delivery issues/availability, we are heading up for Virtex10, Stratix10GX, and I'll retired. I find it quite annoying that this happens for every post. (I'm sorry if I'm picking on somebody) Regards, Luc On Sat, 25 Mar 2006 07:24:14 +1200, Jim Granville <no.spam@designtools.co.nz> wrote: >Austin Lesea wrote: >> Antti, >> >> Personally, I think the purchasing agent should refine their negociation >> skills. >> >> If you will not accept an early shipment, that has to be specified in >> the purchase agreement. >> >> Of course, asking the distributor to stock for you (which is effectively >> what you are doing) will cost them money (evening out the >> supply/demand), which will raise the price to you. > >Anyone remember the old days, when 'distributor' actually meant what it >says ? > >-jgArticle: 99470
I found the problem. The system wasn't recognizing changes I made to the hardware and was using the old compiled vhd file for all of its work. The solution was to perform a clean hardware BEFORE running the initialize BRAM function.Article: 99471
Luc, We like to talk about things we know. Sorry. I myself was really hoping I'd see postings of folks who have GX or SC parts (proving they are real). Austin lb.edc@telenet.be wrote: > Gentlemen, > > The least you can say, is that this thread is quite of the original > request from OP. > By the time everyone has said what he wanted to say about delivery > issues/availability, we are heading up for Virtex10, Stratix10GX, and > I'll retired. > I find it quite annoying that this happens for every post. (I'm sorry > if I'm picking on somebody) > > Regards, > > Luc > > On Sat, 25 Mar 2006 07:24:14 +1200, Jim Granville > <no.spam@designtools.co.nz> wrote: > > >>Austin Lesea wrote: >> >>>Antti, >>> >>>Personally, I think the purchasing agent should refine their negociation >>>skills. >>> >>>If you will not accept an early shipment, that has to be specified in >>>the purchase agreement. >>> >>>Of course, asking the distributor to stock for you (which is effectively >>>what you are doing) will cost them money (evening out the >>>supply/demand), which will raise the price to you. >> >>Anyone remember the old days, when 'distributor' actually meant what it >>says ? >> >>-jgArticle: 99472
Hi Austin, we had Lattice vice president visiting here last week. The SC parts are real. We did however not got the SC PCIe card loaner yet, all the boards are out, so we are on waitinglist to get to play with the SC board - we are hoping to test 4 lane PCIe on it. 1 maco can do 4 lane PCIe, this IP core solution comes from Lattice, 8 lane PCIe solution will be offered by northwest SC25 parts should be available, the promise was sample delivery in 3 weeks max if I recall correctly. So hum, I can assume that the parts actually are real, if the vice talked about boards that are in evaluation by some clients, then there must be parts on them :), but until today I havent seen and SC or ECP silicon yet. EC, XP, machXO are all real (I have used EC and XP), as of RAM based I would skip EC/ECP and only use ECP2, for nonvolatile solutions macXO if 8by8 mm 0.5mm BGA is needed for space constraints or XP3/XP3 (cheaper than large machXO). as of SC more, the SERDES is specified up to 3.4G (but is expected to work up to 3.8G) low cost ECP2 is specified to work with DDR2 400, and can possible be speficied up to DDR2 530 (that depends if... could be, not guaranteed yet). For low cost FPGA its pretty damn good. I have on board on my desk where Spartan3 was considered, but cancelled because of (possible) problems with DDR2 memory. >From Lattice FAE (was visiting today) well he was very surprised to hear about my fpga logic fabric measurements indicating that S3 is WAY slower than V4 despite using the same technology. Lattice is not using performance reduction on ECP2 so you get the low cost FPGA that works at fabric speed that are normal for the technology. Eg high performance and low cost. Of course there are things Lattice does badly also, ECP2 has nonvolatile OTP securtiy key, but SC does not have it ! but it would most useable in SC.. Ah, SC15 is possible the only modern high end PFGA with SERDES that is available in FT256 (or same size) footprint - FX12 that is in same sized package doesnt have serdes. hum, Lattice SoC design environment is coming too, if someone is wondering :) uses Wishbone for interconnect. Was it On topic now for the OP? AnttiArticle: 99473
Hi Antti, I didn't mean to offend somebody. This post is pretty well on topic. It looks like you did a comparison of SC with V4, but what about S2GX? Could you share some data? I did some projects with the ECP family and preformance wise they score quite well (esp. DSP) - maybe a bit light on memory. This is also true for the ECP2 - unfortunately. Based on the datahseet the SC scores well, but lack of DSP and security (like you mentioned). Best regards, Luc On 24 Mar 2006 13:35:49 -0800, "Antti" <Antti.Lukats@xilant.com> wrote: >Hi Austin, > >we had Lattice vice president visiting here last week. The SC parts are >real. We did however not got the SC PCIe card loaner yet, all the >boards are out, so we are on waitinglist to get to play with the SC >board - we are hoping to test 4 lane PCIe on it. > >1 maco can do 4 lane PCIe, this IP core solution comes from Lattice, 8 >lane PCIe solution will be offered by northwest > >SC25 parts should be available, the promise was sample delivery in 3 >weeks max if I recall correctly. > >So hum, I can assume that the parts actually are real, if the vice >talked about boards that are in evaluation by some clients, then there >must be parts on them :), but until today I havent seen and SC or ECP >silicon yet. > >EC, XP, machXO are all real (I have used EC and XP), as of RAM based I >would skip EC/ECP and only use ECP2, for nonvolatile solutions macXO if >8by8 mm 0.5mm BGA is needed for space constraints or XP3/XP3 (cheaper >than large machXO). > >as of SC more, the SERDES is specified up to 3.4G (but is expected to >work up to 3.8G) > >low cost ECP2 is specified to work with DDR2 400, and can possible be >speficied up to DDR2 530 (that depends if... could be, not guaranteed >yet). For low cost FPGA its pretty damn good. I have on board on my >desk where Spartan3 was considered, but cancelled because of (possible) >problems with DDR2 memory. > >>From Lattice FAE (was visiting today) well he was very surprised to >hear about my fpga logic fabric measurements indicating that S3 is WAY >slower than V4 despite using the same technology. Lattice is not using >performance reduction on ECP2 so you get the low cost FPGA that works >at fabric speed that are normal for the technology. Eg high performance >and low cost. > >Of course there are things Lattice does badly also, ECP2 has >nonvolatile OTP securtiy key, but SC does not have it ! but it would >most useable in SC.. > >Ah, SC15 is possible the only modern high end PFGA with SERDES that is >available in FT256 (or same size) footprint - FX12 that is in same >sized package doesnt have serdes. > >hum, Lattice SoC design environment is coming too, if someone is >wondering :) uses Wishbone for interconnect. > >Was it On topic now for the OP? > >AnttiArticle: 99474
<lb.edc@telenet.be> schrieb im Newsbeitrag news:3op822pg70jjt45dt50eodcvv4tkkrdqmc@4ax.com... > Hi Antti, > > I didn't mean to offend somebody. This post is pretty well on topic. > It looks like you did a comparison of SC with V4, but what about S2GX? > Could you share some data? not much - frst S2GX samples will go out last week march, with more availability in April. 6Gbit serdes PCIe solution provided by PLDA as primary PCIe IP partner. Antti
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