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
Roberto, I build many ham kits for fun. Good luck with your project! 73 IZ5FCY de AB6VU sk Roberto IZ5FCY wrote: >>I think for Ham radio, 2E48 is a bit overkill, unless you are doing >>coherent detection... > > > Thanks Austin but isn't an Ham project...in the Web we can find thousand > projects/kits ready-to-use for Ham. > Bye. >Article: 98026
Hi Symon, I think that the use of PR is not related with the money of companies. The real question will be: is there any kind of application where PR is really necessary? Companies try to reduce the cost of the products, and the research and development is only necessary when the solution is not available with the current technology... why they have to use PR in their designs when they do not need it? Moreover, you need to understand that some of academic researches/customers (as you said) are using PR in their projects because they are financed by companies. They are looking for this kind of applications... like Xilinx people, I think. Regards, Ivan Symon wrote: > "Steve Lass" <lass@xilinx.com> wrote in message > news:4407EC49.7060706@xilinx.com... >> It's great to see so much interest in partial reconfiguration. I posted >> on >> Feb 14, but mayby wasn't clear. We have developed new tools and a new >> flow >> for partial reconfig. That software works with ISE 8.1i, but is not >> included with >> ISE 8.1i. You need to contact your local FAE to get the software. >> > Hi Steve, > Are any non-academic customers using this flow with reliable success? My > point being, it's probably a great post-graduate project, but should I be > willing to bet my companies R&D money on it? Is there a commitment from > Xilinx to support this design flow into the future? I'd like to see some IP > cores based on this being released by Xilinx. It would show that the Xilinx > IP developers believe in it! > Please don't get me wrong, I'm typing in a friendly tone of voice! I really > hope you guys have it cracked this time. I hope you can understand the > caution expressed by some of the more cynical posters on CAF!! > Many thanks, Syms. > >Article: 98027
Symon, I can't give you the names of the companies, as we have non-disclosure policies. I can direct you to our web pages that have customer testimonials and press releases. I will say that for development of software defined radio (SDR), reconfigurability is the only practical solution (OK, IMHO). As such, we have been highly motivated to make it (the flow) work (better) by the demand from companies supplying advanced communications from around the entire globe who also believe as we do. Is it perfect yet? No. Is it something people are investing megabucks in? You bet. SDR for JTRS is a $5 billion program for the next 7 years (just one program). Like any military program you can expect that to overrun by ten or twenty times that. Is all that $$ FPGA chips? No, of course not. There are batteries, antennnas, plastic cases, etc. Is it enough $$ to have FPGA and DSP companies sit up and take notice? Yup. Austin Symon wrote: > "Steve Lass" <lass@xilinx.com> wrote in message > news:4407EC49.7060706@xilinx.com... > >>It's great to see so much interest in partial reconfiguration. I posted >>on >>Feb 14, but mayby wasn't clear. We have developed new tools and a new >>flow >>for partial reconfig. That software works with ISE 8.1i, but is not >>included with >>ISE 8.1i. You need to contact your local FAE to get the software. >> > > Hi Steve, > Are any non-academic customers using this flow with reliable success? My > point being, it's probably a great post-graduate project, but should I be > willing to bet my companies R&D money on it? Is there a commitment from > Xilinx to support this design flow into the future? I'd like to see some IP > cores based on this being released by Xilinx. It would show that the Xilinx > IP developers believe in it! > Please don't get me wrong, I'm typing in a friendly tone of voice! I really > hope you guys have it cracked this time. I hope you can understand the > caution expressed by some of the more cynical posters on CAF!! > Many thanks, Syms. > >Article: 98028
Ivan, Software defined radio is one application. And even here, there are people who say that DSP can also do the job for less cost/power. Spacecraft traveling to other planets is another (although you could argue that they just need to be reprogrammed, and not dynamically). Also possibly orbiting communications satellites. So far, there is more solution than problem. There are examples where a vendor did something very clever, and saved money and had a competitive advantage using dynamic reconfiguration, but nothing that has taken the world by storm. Austin Ivan wrote: > Hi Symon, > > I think that the use of PR is not related with the money of companies. > The real question will be: is there any kind of application where PR is > really necessary? Companies try to reduce the cost of the products, and > the research and development is only necessary when the solution is not > available with the current technology... why they have to use PR in > their designs when they do not need it? > > Moreover, you need to understand that some of academic > researches/customers (as you said) are using PR in their projects > because they are financed by companies. They are looking for this kind > of applications... like Xilinx people, I think. > > Regards, > > Ivan > > > Symon wrote: > >> "Steve Lass" <lass@xilinx.com> wrote in message >> news:4407EC49.7060706@xilinx.com... >> >>> It's great to see so much interest in partial reconfiguration. I >>> posted on >>> Feb 14, but mayby wasn't clear. We have developed new tools and a >>> new flow >>> for partial reconfig. That software works with ISE 8.1i, but is not >>> included with >>> ISE 8.1i. You need to contact your local FAE to get the software. >>> >> Hi Steve, >> Are any non-academic customers using this flow with reliable success? >> My point being, it's probably a great post-graduate project, but >> should I be willing to bet my companies R&D money on it? Is there a >> commitment from Xilinx to support this design flow into the future? >> I'd like to see some IP cores based on this being released by Xilinx. >> It would show that the Xilinx IP developers believe in it! >> Please don't get me wrong, I'm typing in a friendly tone of voice! I >> really hope you guys have it cracked this time. I hope you can >> understand the caution expressed by some of the more cynical posters >> on CAF!! >> Many thanks, Syms. >> >>Article: 98029
Hi Ivan, Thanks for your reply, I've included some comments for your perusal! "Ivan" <gmivan@terra.es> wrote in message news:%rZNf.706502$kp.4944071@telenews.teleline.es... > Hi Symon, > > I think that the use of PR is not related with the money of companies. The > real question will be: is there any kind of application where PR is really > necessary? Companies try to reduce the cost of the products, and the > research and development is only necessary when the solution is not > available with the current technology... why they have to use PR in their > designs when they do not need it? > When it gives them a competitive advantage in their market. IMO the use of PR in a commercial environment is absolutely related to money by definition. That's what companies (try to) do, invest money to make money. My point is that I've not heard of a single successful commercial project using PR. (NB. That doesn't mean there haven't been any, just I've not heard of one.) I think this is because it's too expensive in terms of R&D investment and the tool chain has a support lifetime of about a year! > > Moreover, you need to understand that some of academic > researches/customers (as you said) are using PR in their projects because > they are financed by companies. They are looking for this kind of > applications... like Xilinx people, I think. > I already understand this, I think. Companies use students to experiment with PR because real engineers are too expensive to waste on something that's not ready for prime-time. (Tongue-in-cheek alert for that last sentence!) It's also a good educational project I believe. You learn that not everything's possible! ;-) As I said, it'd be great if Xilinx's new tool flow works, but it's a big gamble given PRs track record. Thanks again, Syms.Article: 98030
I've not worked with interrupts in SoPC builder, but I suppose tha the interrupt should be visible. I've seen somewhere in examples/documentation that a column named IRQ appears in SoPC builder, but I don't have anything like this in my system configuration... I suppose that there should be some possibility to assign IRQ number to a device that can raise interrupt, am I right? MartinArticle: 98031
"Austin Lesea" <austin@xilinx.com> wrote in message news:du9o62$ar21@xco-news.xilinx.com... > Symon, > > I can't give you the names of the companies, as we have non-disclosure > policies. I can direct you to our web pages that have customer > testimonials and press releases. > > I will say that for development of software defined radio (SDR), > reconfigurability is the only practical solution (OK, IMHO). As such, we > have been highly motivated to make it (the flow) work (better) by the > demand from companies supplying advanced communications from around the > entire globe who also believe as we do. > > Is it perfect yet? No. > > Is it something people are investing megabucks in? > > You bet. SDR for JTRS is a $5 billion program for the next 7 years (just > one program). Like any military program you can expect that to overrun by > ten or twenty times that. > > Is all that $$ FPGA chips? No, of course not. There are batteries, > antennnas, plastic cases, etc. > > Is it enough $$ to have FPGA and DSP companies sit up and take notice? > Yup. > > Austin > Hi Austin, Thanks for your post, can you point me to those press releases? I agree with you SDR could be a good application for partial reconfiguration. As for the miltary project, are you suggesting the project will overrun by 10-20 times the cost or 10-20 times the schedule? :-) Both? I'm not sure my employment could stand a fraction of either of those! When I first saw the V4 architecture, it did strike me as more suited to PR than previous devices, if Xilinx get a stable tool flow, I bet you'll get a competitive advantage from it. Best regards, Syms.Article: 98032
Hi Joseph, Hmmmn, let me try that. Nothing else has seemed to work so far, aside from stripping out everything in the system except for the processors and OCM which obviously is no "solution". That just happened to have "magic" placement and no problems. I have my system setup the same way you had your's originally (with the dsbram_if_cntrl at 100 MHz and the PowerPC at 300 MHz). I'll let you know what happens next week. We've got a big project deadline in the next few days that's keeping me busy, and, aside from this OCM issue, the system is performing great. We optimized our software enough to not need the second processor at the moment, so I can safely ignore this for a little while. :-) Thanks, Jeff "Joseph" <joeylrios@gmail.com> wrote in message news:1141335040.252179.271460@t39g2000cwt.googlegroups.com... > Not sure if this is relevant to your problem anymore, but I found the > problem with my design (briefly described above). There is only one > signal that can be assigned in the dsbram_if_cntlr, that is > BRAMDSOCMCLK. We were running our PPCs at 200MHz and our PLB bus at > 100MHz using proc_clk_s and sys_clk_s, respectively. It was such a > habit to assign all non-processor clks to sys_clk_s, that we did so for > BRAMDSOCMCLK. After reading the data sheet for dsbram_if_cntlr, we > found that the BRAMDSOCMCLK signal needed to be 1-4X the processor clk. > The slow clock we gave to the BRAM caused our unpredictable behavior. > If anything, I have learned to read those data sheets a little better. > This may or may not be the same as your problem, Jeff, but thought I > would follow up with the fix we came up with for our system. We are > running a prodcuer/consumer type system as well and haven't had any > problem with inconsistencies. The shared BRAM is a circular FIFO in > our system. I could provide details on its operation if you still have > trouble with your system. >Article: 98033
>From working with 7.1 for a few weeks, I'd agree-- it's not nearly as intuitive as 2.1 However, our goal is to keep the lab assignments relatively static while migrating to the new platform, so the schematic tool will need to used for the relative future. I wouldn't have a problem writing the I/O submodules in verilog, if that would allow me to assign pins-- my problem seems to be that the implementation tool ignores any constraints (either via net properties in the schematic or a .ucf file associated with the submodule) set on submodules entirely. Is there some setting that causes the tool to evaluate constraints for submodules that I'm not setting?Article: 98034
Hi Austin, I agree with you. I know about the possibilities of partial reconfiguration because I have been using (and continuous on it) PR during the 5 years that I need to finish my PhD. Thesis: JBits, PARBIT, Modular design (Module-based). I have had to suffer the consequences of use this technology (like Symon, I think). But finally I finished my final application: A Hardware-Accelerated SSH on a Self-reconfigurable MicroBlaze-uCLinux system (using a Spartan-3 device and ISE 6.3). It was a very big challenge, but it finally works fine in a commercial Spartan-3 board. Next step... Virtex-4 ;) About your answer, I am very happy to know that there are some interesting areas that require PR. They are the support that PR needs :) Regards, Ivan Austin Lesea wrote: > Ivan, > > Software defined radio is one application. And even here, there are > people who say that DSP can also do the job for less cost/power. > > Spacecraft traveling to other planets is another (although you could > argue that they just need to be reprogrammed, and not dynamically). > > Also possibly orbiting communications satellites. > > So far, there is more solution than problem. > > There are examples where a vendor did something very clever, and saved > money and had a competitive advantage using dynamic reconfiguration, but > nothing that has taken the world by storm. > > Austin > > Ivan wrote: > >> Hi Symon, >> >> I think that the use of PR is not related with the money of companies. >> The real question will be: is there any kind of application where PR >> is really necessary? Companies try to reduce the cost of the products, >> and the research and development is only necessary when the solution >> is not available with the current technology... why they have to use >> PR in their designs when they do not need it? >> >> Moreover, you need to understand that some of academic >> researches/customers (as you said) are using PR in their projects >> because they are financed by companies. They are looking for this kind >> of applications... like Xilinx people, I think. >> >> Regards, >> >> Ivan >> >> >> Symon wrote: >> >>> "Steve Lass" <lass@xilinx.com> wrote in message >>> news:4407EC49.7060706@xilinx.com... >>> >>>> It's great to see so much interest in partial reconfiguration. I >>>> posted on >>>> Feb 14, but mayby wasn't clear. We have developed new tools and a >>>> new flow >>>> for partial reconfig. That software works with ISE 8.1i, but is not >>>> included with >>>> ISE 8.1i. You need to contact your local FAE to get the software. >>>> >>> Hi Steve, >>> Are any non-academic customers using this flow with reliable success? >>> My point being, it's probably a great post-graduate project, but >>> should I be willing to bet my companies R&D money on it? Is there a >>> commitment from Xilinx to support this design flow into the future? >>> I'd like to see some IP cores based on this being released by Xilinx. >>> It would show that the Xilinx IP developers believe in it! >>> Please don't get me wrong, I'm typing in a friendly tone of voice! I >>> really hope you guys have it cracked this time. I hope you can >>> understand the caution expressed by some of the more cynical posters >>> on CAF!! >>> Many thanks, Syms. >>> >>>Article: 98035
I am using ISE 8.1.02i webedition and have just installed the MIG 1.5 coregen. When I try to use it nothing is generated. Do I need the full version of ISE or should it work in the webedition? Thanks JonArticle: 98036
Symon wrote: > Hi Ivan, Hi Symon, > When it gives them a competitive advantage in their market. IMO the use of > PR in a commercial environment is absolutely related to money by definition. > That's what companies (try to) do, invest money to make money. My point is > that I've not heard of a single successful commercial project using PR. (NB. > That doesn't mean there haven't been any, just I've not heard of one.) I > think this is because it's too expensive in terms of R&D investment and the > tool chain has a support lifetime of about a year! I do not understand the commercial advantage, if you do not need it to make your product. Another thing will be the marketing advantage... "we can do these things" or "we do it more sophisticated". Then I understand it. Austin talked about some applications that needs partial reconfiguration. It possible that SDR requires PR to improve the flexibility and adaptability of the system. That is the answer that I am looking for ;) > I already understand this, I think. Companies use students to experiment > with PR because real engineers are too expensive to waste on something > that's not ready for prime-time. (Tongue-in-cheek alert for that last > sentence!) It's also a good educational project I believe. You learn that > not everything's possible! ;-) In my case, when I started my PhD. Thesis I thought that PR was "impossible mission", but now I believe that PR is possible. I need to look for another challenge ;) > As I said, it'd be great if Xilinx's new tool flow works, but it's a big > gamble given PRs track record. > Thanks again, Syms. And I thank you as well. Regards, IvanArticle: 98037
Ivan wrote: > Hi, > > your comments reveal that you are very annoyed about PR. Yes... I did my diploma thesis on it, i.e. on dynamic partial reconfiguration using the ICAP in Virtex-II Pro devices. The idea was to use the embedded PowerPC or a Microblaze to reconfigure other parts of the FPGA doing e.g. image processing. The next step would've been reconfiguring components of the SoC On-the-Fly. Like you load/unload Linux kernel modules, you were supposed to be able to load/unload peripherals for the processor. The end result was more or less: Yes, it's possible, but there are so many restrictions and so many problems with the tools that there really isn't a single application that is worth the immense extra effort you have to put in simply to make it work somehow. Instead, just get a bigger FPGA, cram it all in and be done with it. I literally spent WEEKS doing nothing else than running the same design over and over and over again, trying all the different command line switches for all the tools, trying ISE-versions from 4.2 to 6.3 with all corrresponding EDK-releases and the service packs for each, just to find one single combination of tools and service packs that wouldn't constantly quit on me with another dubious "INTERNAL_ERROR" or "FATAL_ERROR" somewhere along the way. And every time my boss was as kind as to open a web case for me (as you don't get support when you're a student, understandably), the answer was the same: "Will be fixed in the next service pack, currently there is no work-around", "Is a known bug that will be fixed in the next release" and so on. Yeah, they DID fix it in the next release (ISE7.1), by disabling partial reconfiguration completely. No more "INTERNAL_ERRORS"! > I think it is a > hard work to make use of it, but actually there are a lot of interesting > applications and research works when PR has been applied successfully. Of course it's INTERESTING... I could think of dozens of things that would be nice to play around with. But once you're not a student anymore, you simply don't have the time to play around, unless maybe you're in research or an academic environment. But there's no way I'd even think about doing PR in a PRODUCT, unless it's for small things like changing RocketIO parameters and the like. In Virtex4 I think you can do PR to change DCM parameters on-the-fly, that's another thing that seams feasible. But not exchanging whole modules of logic. > Of course these good results have been obtained at present. When ISE 4.2 > was released, the PR was well-supported by the JBits tool. You chose the > wrong tool :( Well, JBits didn't handle Virtex-II Pro then. Don't know if it does now... JBits seemed pretty much dead the last time I checked. And when I did my thesis, the Virtex-II Pro-bitstream format was still undisclosed. That would've helped, too... But, too late now... Nice to hear that now finally there seem to be tools that really can handle it, even though they're not shipped with ISE and you even have to buy some extra, like PlanAhead. Don't have the time to play around with it, but I'd be glad to hear some experiences if someone really gets it working reliably. cu, SeanArticle: 98038
http://www.xilinx.com/prs_rls/dsp/0626_sdr.htm Thanks, Austin Symon wrote: > "Austin Lesea" <austin@xilinx.com> wrote in message > news:du9o62$ar21@xco-news.xilinx.com... > >>Symon, >> >>I can't give you the names of the companies, as we have non-disclosure >>policies. I can direct you to our web pages that have customer >>testimonials and press releases. >> >>I will say that for development of software defined radio (SDR), >>reconfigurability is the only practical solution (OK, IMHO). As such, we >>have been highly motivated to make it (the flow) work (better) by the >>demand from companies supplying advanced communications from around the >>entire globe who also believe as we do. >> >>Is it perfect yet? No. >> >>Is it something people are investing megabucks in? >> >>You bet. SDR for JTRS is a $5 billion program for the next 7 years (just >>one program). Like any military program you can expect that to overrun by >>ten or twenty times that. >> >>Is all that $$ FPGA chips? No, of course not. There are batteries, >>antennnas, plastic cases, etc. >> >>Is it enough $$ to have FPGA and DSP companies sit up and take notice? >>Yup. >> >>Austin >> > > Hi Austin, > Thanks for your post, can you point me to those press releases? I agree with > you SDR could be a good application for partial reconfiguration. As for the > miltary project, are you suggesting the project will overrun by 10-20 times > the cost or 10-20 times the schedule? :-) Both? I'm not sure my employment > could stand a fraction of either of those! > When I first saw the V4 architecture, it did strike me as more suited to PR > than previous devices, if Xilinx get a stable tool flow, I bet you'll get a > competitive advantage from it. > Best regards, Syms. > >Article: 98039
Sean, 'JBits' was a great academic project (lots of degrees and happy grad students and advisors), and was seen as the solution for reconfigurable computing. It failed. Commercial flop. End of story. As with anything else that fails (like the xc6200), it is dead and gone, yet there are those who loved it, and can't seem to realize that it is no more... C'est domage, et triste: c'est la vie. Austin Sean Durkin wrote: > Ivan wrote: > >>Hi, >> >>your comments reveal that you are very annoyed about PR. > > Yes... I did my diploma thesis on it, i.e. on dynamic partial > reconfiguration using the ICAP in Virtex-II Pro devices. The idea was to > use the embedded PowerPC or a Microblaze to reconfigure other parts of > the FPGA doing e.g. image processing. The next step would've been > reconfiguring components of the SoC On-the-Fly. Like you load/unload > Linux kernel modules, you were supposed to be able to load/unload > peripherals for the processor. > > The end result was more or less: Yes, it's possible, but there are so > many restrictions and so many problems with the tools that there really > isn't a single application that is worth the immense extra effort you > have to put in simply to make it work somehow. Instead, just get a > bigger FPGA, cram it all in and be done with it. > > I literally spent WEEKS doing nothing else than running the same design > over and over and over again, trying all the different command line > switches for all the tools, trying ISE-versions from 4.2 to 6.3 with all > corrresponding EDK-releases and the service packs for each, just to find > one single combination of tools and service packs that wouldn't > constantly quit on me with another dubious "INTERNAL_ERROR" or > "FATAL_ERROR" somewhere along the way. > And every time my boss was as kind as to open a web case for me (as you > don't get support when you're a student, understandably), the answer was > the same: "Will be fixed in the next service pack, currently there is no > work-around", "Is a known bug that will be fixed in the next release" > and so on. > > Yeah, they DID fix it in the next release (ISE7.1), by disabling partial > reconfiguration completely. No more "INTERNAL_ERRORS"! > > >>I think it is a >>hard work to make use of it, but actually there are a lot of interesting >>applications and research works when PR has been applied successfully. > > Of course it's INTERESTING... I could think of dozens of things that > would be nice to play around with. But once you're not a student > anymore, you simply don't have the time to play around, unless maybe > you're in research or an academic environment. > > But there's no way I'd even think about doing PR in a PRODUCT, unless > it's for small things like changing RocketIO parameters and the like. In > Virtex4 I think you can do PR to change DCM parameters on-the-fly, > that's another thing that seams feasible. But not exchanging whole > modules of logic. > > >>Of course these good results have been obtained at present. When ISE 4.2 >>was released, the PR was well-supported by the JBits tool. You chose the >>wrong tool :( > > Well, JBits didn't handle Virtex-II Pro then. Don't know if it does > now... JBits seemed pretty much dead the last time I checked. > > And when I did my thesis, the Virtex-II Pro-bitstream format was still > undisclosed. That would've helped, too... > > But, too late now... > > Nice to hear that now finally there seem to be tools that really can > handle it, even though they're not shipped with ISE and you even have to > buy some extra, like PlanAhead. > > Don't have the time to play around with it, but I'd be glad to hear some > experiences if someone really gets it working reliably. > > cu, > SeanArticle: 98040
"Brian Davis" <brimdavis@aol.com> wrote in message news:1141364601.057606.323670@i40g2000cwc.googlegroups.com... <snip> > I've put together a simple LTSpice simulation model of that > interconnection ( model is completely unverified ) > > slides at: > http://members.aol.com/Fpgastuff/lvds_current.pdf > > zip including .pdf and LTSPICE files > http://members.aol.com/Fpgastuff/lvds_current.zip > > Brian Thanks for putting together that info, Brian. Is the ADS5273 a non-standard LVDS "style" of driver? The lack of back termination that you included in the "normal" LVDS driver makes me wonder if the greater problem is with the ADS5273 rather than the non-ideal FPGA input. Two non-ideal ends gives an ugly signal it seems! A technique used in telecomm systems that might be helpful for probing: rather than using a large attenuator between Rx and Tx with the raw probe point somewhere along the transmission line, consider using a reduced-amplitude probe point. By using a power splitter rather than a raw attenuator with most of the power getting to the Rx, the presense or absence of the probe makes little difference. Reflections are an issue for probes in any system, some come out better than others. If the power splitter is close to the Rx side, the nearby probe may show better results without affecting the signal. Good SI analysis is so critical these days; it's nice to see someone else's results. - John_HArticle: 98041
I haven't had time to load Xilinx's tools (sometime I'm going to have to do it for another project) to see what there DPRAM library device looks like. The solution I was going to offer was going to be a time division solution like rhnlogic suggested. Relative to the reading/writing of the ports of the DPRAM, what clocks are available? What other controls signals are present that could be taken advantage of? If you want to reinvent the wheel you could implement your own dual port memory. It would probably be a little bit more than 6240 flip flops if you can limit the address to 130 range and if you're sloppy about it 16384 flip flops for the whole 256 range. (plus addressing and control support) DerekArticle: 98042
zhangweidai@gmail.com wrote: > thanks for the reply. yes ive looked at them. but they dont share pcb > layout files. i would like examples that i can use for like... > dimensions and component placement examples. maybe something that > utilizes different layers. You sound vague about what you want the expansion board to do. I know I have the equivalent of "writer's block" when starting a new design. I often start with a vauge idea of what I want, and it takes me a while to decide what I really want. I sketch a lot of block diagrams, most of which I toss. It's tempting to add feature after feature, but start with simple designs at first. Be prepared to make mistakes. Hopefully you'll learn from those mistakes. The CAD package I use is EAGLE. The version I bought has a board size limit of 100mm x 160mm, which is roughly 4" x 6". 4x5 or 4x6 is also a good board size if you use the $33/bd company, and other PCB companies. When it comes to placing parts, look at your block diagram and schematic diagram. Parts that are nearby on the schematic should be nearby on the board. Connectors should be near the board's edge, etc. You can make paper cutouts of the parts, which you place on a piece of paper that represents your board. You can then shuffle parts around until you are satisfied with the placement. Again, looking at web sites that sell board-level products (e.g. Digilent), should give you some ideas on placing parts. HTH -Dave PollumArticle: 98043
John, I went and downloaded: http://focus.ti.com/docs/prod/folders/print/ads5273.html the IBIS model. I also downloaded the internal termination V4 IBIS model. I then used Mentor Hyperlynx to simulate the interface. A nice short 3" trace. Eye pattern looks plenty open for a 0 bit error rate recovery. Looks just fine to me. Is it perfect? No. But who needs perfect? All you need is good enough to be recovered with no fancy tricks. Go to the center of the eye, and sample. I don't know about anyone else, but it works fine, and posts like this of sims poorly done are not helpful to anyone. Anyone want my screenshot can email me directly, as posting big graphis files is bad newsgroup behavior (and is blocked). Austin John_H wrote: > "Brian Davis" <brimdavis@aol.com> wrote in message > news:1141364601.057606.323670@i40g2000cwc.googlegroups.com... > <snip> > >>I've put together a simple LTSpice simulation model of that >>interconnection ( model is completely unverified ) >> >>slides at: >> http://members.aol.com/Fpgastuff/lvds_current.pdf >> >>zip including .pdf and LTSPICE files >> http://members.aol.com/Fpgastuff/lvds_current.zip >> >>Brian > > > Thanks for putting together that info, Brian. > > Is the ADS5273 a non-standard LVDS "style" of driver? The lack of back > termination that you included in the "normal" LVDS driver makes me wonder if > the greater problem is with the ADS5273 rather than the non-ideal FPGA > input. Two non-ideal ends gives an ugly signal it seems! > > A technique used in telecomm systems that might be helpful for probing: > rather than using a large attenuator between Rx and Tx with the raw probe > point somewhere along the transmission line, consider using a > reduced-amplitude probe point. By using a power splitter rather than a raw > attenuator with most of the power getting to the Rx, the presense or absence > of the probe makes little difference. Reflections are an issue for probes > in any system, some come out better than others. If the power splitter is > close to the Rx side, the nearby probe may show better results without > affecting the signal. > > Good SI analysis is so critical these days; it's nice to see someone else's > results. > > - John_H > >Article: 98044
Hi (again!) As we're still looking at this device on quite a low level (we're trying to look at implementing a model of neurons in the brain on the device, and in particular the connectivity) we've come across another problem in our understanding... When looking at the 'Hierarchical Routing Resources', the paragraph states "... a number of resources counted between any two adjacent switch matrix rows or columns.". Therefore, are we right in thinking that in our device (which has 56x48 CLBs) for the '40 horizontal double lines', from each row we can send out 40 connections (giving a total of 40x48 double connections), or is there something we've missed (as depending on which way we look at it, it's either *loads* of connections, or *very* few connections!). The same goes for the long lines and hex lines etc. Again, any pointers to documentation would be appreciated, or if someone has the time to type a concise answer all the better (the reason we're posting is because we can't find anything helpful, so we're hoping to learn from your experience, rather than just leeching off you!) :) Thanks again ChrisArticle: 98045
Chris, Have you looked at the device in FPGA_Editor? You should. Austin Chris Francis wrote: > Hi (again!) > > As we're still looking at this device on quite a low level (we're trying > to look at implementing a model of neurons in the brain on the device, > and in particular the connectivity) we've come across another problem in > our understanding... > > When looking at the 'Hierarchical Routing Resources', the paragraph > states "... a number of resources counted between any two adjacent > switch matrix rows or columns.". Therefore, are we right in thinking > that in our device (which has 56x48 CLBs) for the '40 horizontal double > lines', from each row we can send out 40 connections (giving a total of > 40x48 double connections), or is there something we've missed (as > depending on which way we look at it, it's either *loads* of > connections, or *very* few connections!). The same goes for the long > lines and hex lines etc. > > Again, any pointers to documentation would be appreciated, or if someone > has the time to type a concise answer all the better (the reason we're > posting is because we can't find anything helpful, so we're hoping to > learn from your experience, rather than just leeching off you!) :) > > Thanks again > ChrisArticle: 98046
Nial Stewart wrote: > >> You've had to understand the target architecture and what's causing your > >> timing constraint to fail, then re-jig your HDL to reduce the number of > >> levels of logic to achieve timing closure. > > > Not at all. Programmers juggle instruction/statement flow all the time > > to reach timing closure in C and asm for device drivers and embedded > > applications in many fields First, your cut an paste of several different points and answers isn't accurate. My answer above is to this part that that it directly followed: ||> I thought that one of the arguments for using a C based HDL was you can avoid ||> this level of design implementaion detail? My point was and is that low level programmers have to understand the underlying hardware in significant detail to program it properly ... that has never changed in 35 years. It really doesn't mater if we are talking about clock latency and scheduling for multiple pipelines, or the physics and dynamics of a motion control system. I really does matter if the system measurement units are hours, seconds, microseconds or picoseconds. Or that the units are core access and cycle times, pipeline latencies, clock cycles, gate delays or routing segment latencies. > > But you're not just juggling lines of code about so the order of > execution is different (ie to make sure things are picked up > quickly enough in an ISR or whatever). Certainly. So what's your point? > > Looking at the problem a little more this afternoon, the C based 66mhz > > PCI core is looking much more viable. The combinatorial length was > > actually from unnecessarily including the main references to the pci > > bus signals in the else side of the reset conditional. Breaking that > > dependency changed the base FSM speed from 63mhz to better than 73mhz, > > making it likely the other setup and hold times can be met as well. > > I still think this is an accurate observation... > > "You've had to understand the target architecture and what's causing your > timing constraint to fail, then re-jig your HDL to reduce the number of > levels of logic to achieve timing closure." Certainly. But the second part and real point in your question remains, and that I addressed in detail I still have issues with: || > I thought that one of the arguments for using a C based HDL was you can avoid ||> this level of design implementaion detail? and the answer remains, not at all.Article: 98047
Hey guys/gals What are the advantages and disadvantages of using a CPLD instead of using an FPGA for a design? ThanksArticle: 98048
Austin Lesea wrote: > Chris, > > Have you looked at the device in FPGA_Editor? > > You should. It would be nice if the fpga editor would allow you to start it without a design loaded, select the device that you want to explore/edit/design with, go into edit mode, and save the resulting design from the editing (if any). Or open an existing design, and be able to extend it by editing iob's and slices that do not have design elements loaded. ... but that is another point ... >From the posters second question, it's likely he's not familar with how to operate fpga editor. Actually just looking at it probably will not answer his question, as the defaults don't show you very much. He needs to get close in, turn on all the resources (as many are turned off to reduce the visual clutter), and put it in edit mode. IE from the tool bar, where the yellow controls are: 1) turn on local lines 2) turn on long lines 3) turn on pin wires 4) turn on Pips 5) turn on switch boxes Then from the loaded design, select a site entry from list 1, click on the red find tool to zoom in on it, then zoom out one or two steps and look around that are in detail. start clicking on the circles at the edges of the switch boxes to see the connection resources available, and open up the clb and iob blocks that have design elements to see the internal connections.Article: 98049
Austin Lesea wrote: > Sean, > > 'JBits' was a great academic project (lots of degrees and happy grad > students and advisors), and was seen as the solution for reconfigurable > computing. > > It failed. Commercial flop. End of story. > > As with anything else that fails (like the xc6200), it is dead and gone, > yet there are those who loved it, and can't seem to realize that it is > no more... > > C'est domage, et triste: c'est la vie. Nothing like insulting a bunch of xilinx reconfigrable computing advocates by calling them, and their pet projects which need JBits, failures because it didn't have a commercial, billion dollar market success. I think it's a chicken and egg problem ... the success and failure, is because Xilinx has not really allowed people to use those interfaces, by keeping them tightly locked up with NDA terms which might be important for tightly controlling information between corporate customers, but is the death of open academic development tied to open source deliveries. Given the number of other academic programs which are built on JBits, and the unique access it provides, and the slow emergance of reconfigurable computing due to device costs and lack of low level access to the parts by open source developers, maybe the real problem is that the Xilinx corporate culture hasn't been able to decide to open up enough that people really can do reconfigurable computing and fully exploit the low level interfaces necessary for 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