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
"Stifler" <seannstifler69@hotmail.com> wrote in message news:bf780a06.0405241256.1b6a51e1@posting.google.com... > Altera finally wakes up. They realize that the window register type > architecture is not good for FPGAs and probably in general. They can > no longer support their own marketing hype about how great Nios I is. > If Nios 1 was so great, why did it need a complete redesign and > rearchitecture? It means it was poor. That's the only reason you do a > complete redesign. I believe they have switched to 32 bit instructions > also. Didn't it used to be 16 bit? Guess that wasn't so great either. > > They copy the Xilinx Microblaze style implementation. To me it shows > who knows what about designing and running a soft processor in an > FPGA. Enough said. > > They throw all the current Nios customers under the bus. Requires > publishing a 38 page app note to switch a Nios 1 to Nios II design. > Current Nios users, I feel sorry for you. Be careful and do your back > ups! I try not to respond to trolls, but in your case I'll make an exception. You don't know what your talking about! Nios I with SOPC builder is a small fast, flexible processor with great tools. Nios II is even better. It's smaller, faster, and has even better tools. How someone could see such an upgrade as something to feel sorry about is madness. If your car dealer called you up and said come pickup your new replacement car only it looks better, runs faster and gets better mileage, would you turn him down? Try to use some common sense! Ken LandArticle: 69926
I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design running with a 100MHz master clock. This clock is derived from a single source and distributed to each board so they are synchronised. The boards are postioned about 50m apart. I need to synchronise events on the boards, but occasionally sending a single pulse (say 10ns long) from the output pin of one of the FPGAs to the other boards, to allow them to synchronise internal timers. I need to make sure that the pulse arrives at the other two boards at the same time so that it is 'recognised' on the same rising edge of the reference clock in each case, so that the boards synchronise together. Clearly the attenuation of any 50m length of cable is such that I cannot connect them directly, but nor do I want the complexity of converting the pulse to optical fibre and back again. For the distribution of the reference clock I am using National CLC005/012 driver and equaliser chipset over UTP, using equal length wires so as to not introduce propagation skew. For practical reasons I can't use the same cable for sending this event pulse, and ideally would like a simple, elegant solution. I was just wondering if anyone had done anything similar before... if not, I have a back-up plan using more of the National drivers, but I thought they might be a sledgehammer to crack a nut - and am unsure what levels of skew they may introduce themselves... jitter is not so important because the event is resynced at the receiving fpga, as long as the total difference in edge is less than half of the reference clock cycle (so 5ns). Thank you in advance for any ideas....Article: 69927
Tom Derham wrote: > I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design > running with a 100MHz master clock. This clock is derived from a single > source and distributed to each board so they are synchronised. The boards > are postioned about 50m apart. > > I need to synchronise events on the boards, but occasionally sending a > single pulse (say 10ns long) from the output pin of one of the FPGAs to the > other boards, to allow them to synchronise internal timers. I need to make > sure that the pulse arrives at the other two boards at the same time so that > it is 'recognised' on the same rising edge of the reference clock in each > case, so that the boards synchronise together. > > Clearly the attenuation of any 50m length of cable is such that I cannot > connect them directly, but nor do I want the complexity of converting the > pulse to optical fibre and back again. > For the distribution of the reference clock I am using National CLC005/012 > driver and equaliser chipset over UTP, using equal length wires so as to not > introduce propagation skew. For practical reasons I can't use the same > cable for sending this event pulse, and ideally would like a simple, elegant > solution. > I was just wondering if anyone had done anything similar before... if not, I > have a back-up plan using more of the National drivers, but I thought they > might be a sledgehammer to crack a nut - and am unsure what levels of skew > they may introduce themselves... jitter is not so important because the > event is resynced at the receiving fpga, as long as the total difference in > edge is less than half of the reference clock cycle (so 5ns). > > Thank you in advance for any ideas.... The natsemi drivers might seem an over-kill, but they do give you tracking with your clock system, and since that sounds like it rather matters, anything you a) already know and b) tracks what you already use sounds to me like a simple, elegant solution ? Another scheme for global sync, (but that some systems cannot tolerate), is to send a break in the clock stream - can be as simple as a single missing pulse. Gives you a time-Zero, and all units thereafter are in-phase. -jgArticle: 69928
Hi, there: My clock is 40MHz, but I have complicated FFT operations and other DSP stuff. The longest path is 25.8ns, though after I set the constraints at 23ns...Previously it was 27.5ns at constraints of 25ns... What may I do now? How far can over constraining go? The source codes are from other people so I can't change a lot of it. Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1? Does Synplify optimize for speed? How does it compare with XST? KelvinArticle: 69929
hello currently I am looking for the previous academic reconfigurable system which uses VPR as a software environment. Could anyone point me out successfully published reconfigurable system (or stand-alone hardware) using VPR environment ? Thankyou in advanceArticle: 69930
> I believe they have switched to 32 bit instructions > also. Didn't it used to be 16 bit? Guess that wasn't so great either. Depends on what you are interested in. If it's code density, then 16-bit instructions are great. NIOS had a significant code size advantage over MicroBlaze. NIOS II doesn't. Perhaps that isn't important, but when you have an instruction cache, good code density can also improve performance (less cache misses). Cheers, JonBArticle: 69931
Jon Beniston wrote: >>I believe they have switched to 32 bit instructions >>also. Didn't it used to be 16 bit? Guess that wasn't so great either. >> >> > >Depends on what you are interested in. If it's code density, then >16-bit instructions are great. NIOS had a significant code size >advantage over MicroBlaze. NIOS II doesn't. Perhaps that isn't >important, but when you have an instruction cache, good code density >can also improve performance (less cache misses). > > With the few benchmarks that I have done, I didn't see any big savings in the NIOS I code size. I think that most NIOS2 users will see that the code size will not increase that much compared to NIOS1. A 32-bit instruction can do more for each instruction than a 16-bit instruction and a 16-bit ISA also have problems with immediate values. So the code size is very application dependent but you will not see a "significant" difference. >Cheers, >JonB > >Article: 69932
all formats are not neccesarily contigious, that means the file can contain data for address 0x100-0x200 and 0x40000-0x4000F for example, is the binary size 0x10F then, or 0x40000F? But usually the files contain contigious addresses. The NIOS SDK comes with a utility called nios-elf-size. Run it like "nios-elf-size <yourfile>.objout", that will give you an indication how big your file will be. You can also interpret the last line of the SREC file yourself. When you run out of code/data space I think the linker will give you an error. Jeroen "GreateWhite.DK" <mse@ect.dk> schreef in bericht news:40b1bc0a$0$474$edfadb0f@dread14.news.tele.dk... > Hi > > How can subject be done??? > > Regards up front > GreateWhite.DK > >Article: 69933
a hub also needs to sense currents downstream devices use and it should be able to turn devices off, so a FPGA only implementation is not possible. Is there any reason you want to implement a hub in an FPGA, while readily available hubs are cheaper than the FPGA device alone? Atmel make HUB chips (AT43301 for example), maybe you can find some useful info in the datasheets. Jeroen "jimboluke" <jimlyke@comcast.net> schreef in bericht news:UemdnYXatLsRQjPdRVn-tw@comcast.com... > Is there an open USB hub anywhere? I can find USB device cores, but not > hubs. -jim >Article: 69934
> "Stifler" <seannstifler69@hotmail.com> wrote in message > news:bf780a06.0405241256.1b6a51e1@posting.google.com... > > Altera finally wakes up. They realize that the window register type > > architecture is not good. They can no longer support their own marketing > > If Nios 1 was so great, why did it need a complete redesign and > > rearchitecture? It means it was poor. That's the only reason you do a > > complete redesign. I believe they have switched to 32 bit instructions > > also. Didn't it used to be 16 bit? Guess that wasn't so great either. Other user said: > Nios I with SOPC builder is a small fast, flexible processor with great > tools. Nios II is even better. It's smaller, faster, and has even better > tools. Both can have good share in the market. For my own purposes it is more probable that i would use Nios than MicroBlaze. In Microblaze there is no way to add your own custom instructions. It is not an extensible processor but just provides the means to add peripherals to a small SoC. Correct me if i am wrong. I just hope that the tools (assembler, simulator, debugger) can be retargeted for the new ISA. Or be able to use inline assembly with the new instructions. The corresponding hardware should be built by some RTL description i would give. Since customization is out of the issue, no Microblaze for me. Uncle "The G.B. Man" NoahArticle: 69935
Chuck McManis wrote: > "Rene Tschaggelar" <none@none.net> wrote in message > news:40b0fd9d$0$721$5402220f@news.sunrise.ch... > >>The Nexar package is not really that overpriced. It allows to develop >>FPGAs with a 8051 kernel built in, with debugger, compiler, everything. > > > I should have been more crisp, $8,000 is waaaaaaay overpriced for me. Even > the $1000 I spent on the Proteus package (www.labcenter-electronics.com) > seemed steep but it too has the embedded processor simulator (PIC, AVR, and > 8051) and as I use PICs (some AVRs, but no 8051 yet) in my robotics I was > moderatly motivated by it. Yes, for non-protel user it is a lot to just have a look at. And when you don't have a certain number of projects where you could save a lot of time on development, it could be hard to justify. > Bringing it back on topic... > > Have you played with the FPSLIC stuff? AVR core plus FPGA? I've got the > development board as I was looking at some sort of custome baseboard > controller (SMBus, i2c, etc) and it looks great but Atmel doesn't seem > particularly committed to it ... As said, I had no gain in putting any core into an FPGA yet. While using a standalone cpu let you select between a bunch of compilers, they somehow vanish when you put a core into an FPGA. BTW, what does an I2C or SMB, that cannot be done with some port pins ? Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 69936
Tom Derham wrote: > I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design > running with a 100MHz master clock. This clock is derived from a single > source and distributed to each board so they are synchronised. The boards > are postioned about 50m apart. > > I need to synchronise events on the boards, but occasionally sending a > single pulse (say 10ns long) from the output pin of one of the FPGAs to the > other boards, to allow them to synchronise internal timers. I need to make > sure that the pulse arrives at the other two boards at the same time so that > it is 'recognised' on the same rising edge of the reference clock in each > case, so that the boards synchronise together. > > Clearly the attenuation of any 50m length of cable is such that I cannot > connect them directly, but nor do I want the complexity of converting the > pulse to optical fibre and back again. > For the distribution of the reference clock I am using National CLC005/012 > driver and equaliser chipset over UTP, using equal length wires so as to not > introduce propagation skew. For practical reasons I can't use the same > cable for sending this event pulse, and ideally would like a simple, elegant > solution. > I was just wondering if anyone had done anything similar before... if not, I > have a back-up plan using more of the National drivers, but I thought they > might be a sledgehammer to crack a nut - and am unsure what levels of skew > they may introduce themselves... jitter is not so important because the > event is resynced at the receiving fpga, as long as the total difference in > edge is less than half of the reference clock cycle (so 5ns). > > Thank you in advance for any ideas.... 100 MHz on a long cable calls for either 50 Ohms, ECL or perhaps LVDS. There also are the AnalogDevices ADum1400 family of magnetocouplers, some of which are spec'ed for 100MBit. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 69937
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,sv In-Reply-To: <b7a879e0.0405250238.11caeb7f@posting.google.com> Xref: newsmst01a.news.prodigy.com comp.arch.fpga:72469 Have you looked at the FSL interface on MicroBlaze? It will allow you to create custom functions which can be more powerful than custom instructions. Göran Uncle Noah wrote: >>"Stifler" <seannstifler69@hotmail.com> wrote in message >>news:bf780a06.0405241256.1b6a51e1@posting.google.com... >> >> >>>Altera finally wakes up. They realize that the window register type >>>architecture is not good. They can no longer support their own marketing >>>If Nios 1 was so great, why did it need a complete redesign and >>>rearchitecture? It means it was poor. That's the only reason you do a >>>complete redesign. I believe they have switched to 32 bit instructions >>>also. Didn't it used to be 16 bit? Guess that wasn't so great either. >>> >>> > >Other user said: > > >>Nios I with SOPC builder is a small fast, flexible processor with great >>tools. Nios II is even better. It's smaller, faster, and has even better >>tools. >> >> > >Both can have good share in the market. For my own purposes it is more >probable that i would use Nios than MicroBlaze. > >In Microblaze there is no way to add your own custom instructions. It >is not an extensible processor but just provides the means to add >peripherals to a small SoC. Correct me if i am wrong. I just hope that >the tools (assembler, simulator, debugger) can be retargeted for the >new ISA. Or be able to use inline assembly with the new instructions. >The corresponding hardware should be built by some RTL description i >would give. > >Since customization is out of the issue, no Microblaze for me. > >Uncle "The G.B. Man" Noah > >Article: 69938
Hi! I followed an instruction from xilinx website to setup the co-simulation environment for ModelSim. libraries have been updated and smartmodel has been installed. However, when I try to run a behavioral model, which is created by clicking the "simgen" button in EDK6.1 toolbar, things are not going quite well. It seems that the PPC core (from smartmodel) doesn't function correctly. Its 3 reset request signals (C405CHIPRSTREQ,C405CORERSTREQ,C405SYSRSTREQ) always go to "X" after rst_c405_chip, rst_c405_core, rst_c405_sys go back to "0" from "1". Then, I created another structural model for the same design. the problem with these reset signals went away. so, could someone point out what I am missing to create a correct behaviroal model? thank you in advance! --yangArticle: 69939
Hello guys, I want to implement a simple code to generate a AWGN signal quantized in 4 bits unsigned, I'd like to use this as an interference to a turbo code project. At the moment I'm trying to sum 16 differents PN sequences (each one using 32 registers), but I think this project could be implemented using less logic. I'm wondering for any help and comments Thanks IvanArticle: 69940
"Student" <student@nowhere.com> wrote in message news:<40b2f02e@news.starhub.net.sg>... > Hi, there: > > My clock is 40MHz, but I have complicated FFT operations and other DSP > stuff. > The longest path is 25.8ns, though after I set the constraints at > 23ns...Previously it > was 27.5ns at constraints of 25ns... > > What may I do now? How far can over constraining go? The source codes are > from > other people so I can't change a lot of it. > > Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1? > > Does Synplify optimize for speed? How does it compare with XST? > > Kelvin Hi Kelvin, if the source codes are from other people and you cannot change it you should assume that is has been optimized for 40MHz, isn't it? ;o) You have to clarify for which clock frequency the original design has been developed. So basically the best possibility is to think about pipelining your design. By doing so you will not have to worry about constraining. RgdsArticle: 69941
Thanks for your reply Jeroen. I have reflected a bit over what you said. It has however resulted in some other questions. See what I want to do is to have some apps stored in my flash(1MB). On powerup will me boot code get data in my flash that is compressed and then extract the data directly to the RAM so I don't need any SREC file to be translated by the GERMS. How should this be done? Is it just taking the .out file and copy this into the RAM or what kind of actions must I make use of? Regards GreateWhite.DK "Jeroen" <sink@null.dev> wrote in message news:40b31fe5$0$36169$e4fe514c@news.xs4all.nl... > all formats are not neccesarily contigious, that means the file can contain > data for address 0x100-0x200 and 0x40000-0x4000F for example, is the binary > size 0x10F then, or 0x40000F? > > But usually the files contain contigious addresses. The NIOS SDK comes with > a utility called nios-elf-size. Run it like "nios-elf-size > <yourfile>.objout", that will give you an indication how big your file will > be. > > You can also interpret the last line of the SREC file yourself. When you run > out of code/data space I think the linker will give you an error. > > Jeroen > > > "GreateWhite.DK" <mse@ect.dk> schreef in bericht > news:40b1bc0a$0$474$edfadb0f@dread14.news.tele.dk... > > Hi > > > > How can subject be done??? > > > > Regards up front > > GreateWhite.DK > > > > > >Article: 69942
Rene Tschaggelar <none@none.net> wrote in message news:<40b32543$0$718$5402220f@news.sunrise.ch>... > 100 MHz on a long cable calls for either 50 Ohms, ECL or perhaps LVDS. > > There also are the AnalogDevices ADum1400 family of magnetocouplers, > some of which are spec'ed for 100MBit. > > Rene One more vote for LVDS. Here's an app note for TI M-LVDS technology. http://focus.ti.com/lit/an/slla127/slla127.pdf Basically they say -6dB at 30m over UTP for 100 Mbps, and a little over 10% jitter at 50m. I expect you may be able to do better with co-ax cable -- look for a type with low-loss dielectric and, for lower power consumption, higher characteristic impedance -- co-ax goes upto about 100ohm. You will need to be careful about ground differences between the two ends. Regards, -rajeev-Article: 69943
Anyone know what happed to this site? It has been off the air for a few days now. MikeArticle: 69944
> With the few benchmarks that I have done, I didn't see any big savings > in the NIOS I code size. Here's a few results for you: Dhrystone 0.873552983 JPEG 0.651083295 g726 0.781745341 g711 0.724035608 GSM 0.74610231 AES 0.659236641 TCP/IP 0.638751451 bzip2 0.812246882 I.e. NIOS is on average 25% smaller than Microblaze. Note: I have taken into account the size of crt0 etc. etc.. > I think that most NIOS2 users will see that the code size will not > increase that much compared to NIOS1. They will lose that 25%. Maybe it isn't important. > A 32-bit instruction can do more for each instruction than a 16-bit > instruction Sure, but not all the time. > and a 16-bit ISA also have problems with immediate values. I don't know what you mean by problems, but yes, a 16-bit instruction doesn't have as large a range for immediates as a 32-bit instruction. NIOS got around this with their prefix instruction. They just happend to lose out on performance as they didn't choose to decode a prefix and the subsequent instruction in parallel. > So the code size is very application dependent but you will not see a > "significant" difference. Well, 25% seems significant to me. I don't want to come accross as some NIOS fanboy, because I'm not. It's just those are the facts as I seem them. Cheers, JonArticle: 69945
> In Microblaze there is no way to add your own custom instructions. It > is not an extensible processor but just provides the means to add > peripherals to a small SoC. Correct me if i am wrong. I just hope that > the tools (assembler, simulator, debugger) can be retargeted for the > new ISA. Or be able to use inline assembly with the new instructions. > The corresponding hardware should be built by some RTL description i > would give. Is anyone actually doing this? Cheers, JonBArticle: 69946
Jon Beniston wrote: >>With the few benchmarks that I have done, I didn't see any big savings >>in the NIOS I code size. >> >> > >Here's a few results for you: > >Dhrystone 0.873552983 >JPEG 0.651083295 >g726 0.781745341 >g711 0.724035608 >GSM 0.74610231 >AES 0.659236641 >TCP/IP 0.638751451 >bzip2 0.812246882 > >I.e. NIOS is on average 25% smaller than Microblaze. Note: I have >taken into account the size of crt0 etc. etc.. > > Is this with the register window enable or with the mflat option? If you add the data into the sizes, the percentage will be even smaller. For a lot of the application, the data size is normally larger than the code size. The only benefit of smaller application size (code and data) is that you might get away with smaller memories. > > >>I think that most NIOS2 users will see that the code size will not >>increase that much compared to NIOS1. >> >> > > > >They will lose that 25%. Maybe it isn't important. > Normally not. > > > >>A 32-bit instruction can do more for each instruction than a 16-bit >>instruction >> >> > >Sure, but not all the time. > But most of the time. > > > >>and a 16-bit ISA also have problems with immediate values. >> >> > >I don't know what you mean by problems, but yes, a 16-bit instruction >doesn't have as large a range for immediates as a 32-bit instruction. >NIOS got around this with their prefix instruction. They just happend >to lose out on performance as they didn't choose to decode a prefix >and the subsequent instruction in parallel. > Which mean that you will need two 16-bit instructions instead of one 32-bit instruction. Which is then the same size. If you look at the NIOS code, you will find a lot of the PFX instructions. > > > >>So the code size is very application dependent but you will not see a >>"significant" difference. >> >> > >Well, 25% seems significant to me. > >I don't want to come accross as some NIOS fanboy, because I'm not. >It's just those are the facts as I seem them. > > >Cheers, >Jon > GöranArticle: 69947
> My clock is 40MHz, but I have complicated FFT operations and other DSP > stuff. > The longest path is 25.8ns, though after I set the constraints at > 23ns...Previously it > was 27.5ns at constraints of 25ns... > > What may I do now? How far can over constraining go? Keep going until the results don't get any better. > The source codes are > from > other people so I can't change a lot of it. > > Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1? I think there is -opt_level (or something) that makes it work harder. Also, you can set the P&R optimisation level. Note: Estimated frequency after synthesis is not necessarily what you will get after P&R. > > Does Synplify optimize for speed? Yes. > How does it compare with XST? I have found it to be better. The extra performance is often very heavily design dependant. More often than not, for me, it performs much better with large designs. Cheers, JonBArticle: 69948
You may want to try to run map with the '-timing' option. For more ideas check out this Tech Tip from Xilinx: http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=rw_tim_closure Shalin- Jon Beniston wrote: >>My clock is 40MHz, but I have complicated FFT operations and other DSP >>stuff. >>The longest path is 25.8ns, though after I set the constraints at >>23ns...Previously it >>was 27.5ns at constraints of 25ns... >> >>What may I do now? How far can over constraining go? > > > Keep going until the results don't get any better. > > >>The source codes are >>from >>other people so I can't change a lot of it. >> >>Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1? > > > I think there is -opt_level (or something) that makes it work harder. > > Also, you can set the P&R optimisation level. > > Note: Estimated frequency after synthesis is not necessarily what you > will get after P&R. > > >>Does Synplify optimize for speed? > > > Yes. > > >>How does it compare with XST? > > > I have found it to be better. The extra performance is often very > heavily design dependant. More often than not, for me, it performs > much better with large designs. > > Cheers, > JonBArticle: 69949
How about this weird idea: Don't send a pulse, send an edge. Your attenuation might provide a little phase shift but it would be pretty easy to alter the phase to match the clocks. Rather than a smeared pulse with low high-level amplitudes, you get a full transition with a consistent 50% point. "Tom Derham" <uceeted@ucl.ac.uk> wrote in message news:xtvsc.1724$hu1.16883825@news-text.cableinet.net... > I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design > running with a 100MHz master clock. This clock is derived from a single > source and distributed to each board so they are synchronised. The boards > are postioned about 50m apart. > > I need to synchronise events on the boards, but occasionally sending a > single pulse (say 10ns long) from the output pin of one of the FPGAs to the > other boards, to allow them to synchronise internal timers. I need to make > sure that the pulse arrives at the other two boards at the same time so that > it is 'recognised' on the same rising edge of the reference clock in each > case, so that the boards synchronise together. > > Clearly the attenuation of any 50m length of cable is such that I cannot > connect them directly, but nor do I want the complexity of converting the > pulse to optical fibre and back again. > For the distribution of the reference clock I am using National CLC005/012 > driver and equaliser chipset over UTP, using equal length wires so as to not > introduce propagation skew. For practical reasons I can't use the same > cable for sending this event pulse, and ideally would like a simple, elegant > solution. > I was just wondering if anyone had done anything similar before... if not, I > have a back-up plan using more of the National drivers, but I thought they > might be a sledgehammer to crack a nut - and am unsure what levels of skew > they may introduce themselves... jitter is not so important because the > event is resynced at the receiving fpga, as long as the total difference in > edge is less than half of the reference clock cycle (so 5ns). > > Thank you in advance for any ideas.... > >
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