Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Mar 30, 5:27=A0pm, Oliver Faust <oliver.fa...@gmail.com> wrote: > Hi, > I want to network multiple embedded processors using optical fiber as > physical layer. This network is realised with point to point > connections. At the moment, the network is established using RS232. To > get higher data rates (around 100Mb/s) and better protection against > EMI the electrical RS232 should be exchanged with optical data > transfer. > In order to realise this change, I'm searching for a technology > similar to Fiber Channel (FC). The only, difficulty with FC is that > the speed is too high, the slowest speed for fiber channel is 1Gb/s. > Furthermore, fiber channels use sophisticated IO (Xilinx rocket IO) , > for cost effectiveness I don't want to invest in these expensive IOs. > I looked around on the net for some possible solutions, but fiber > channel was the closest solution to my problem I could find. My > question is therefore: > Did I overlook something? Is there an IP-core or external chip which > allows me to establish a 100Mb/s data communication link between two > embedded processors using fiber optic. > > Thank you in advance for your help. > Oliver Faust up to 10m up to 125mbits TOSLINK http://en.wikipedia.org/wiki/TOSLINK there are possible other options as well AnttiArticle: 139451
On Mar 30, 4:46=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 30, 5:27=A0pm, Oliver Faust <oliver.fa...@gmail.com> wrote: > > > > > Hi, > > I want to network multiple embedded processors using optical fiber as > > physical layer. This network is realised with point to point > > connections. At the moment, the network is established using RS232. To > > get higher data rates (around 100Mb/s) and better protection against > > EMI the electrical RS232 should be exchanged with optical data > > transfer. > > In order to realise this change, I'm searching for a technology > > similar to Fiber Channel (FC). The only, difficulty with FC is that > > the speed is too high, the slowest speed for fiber channel is 1Gb/s. > > Furthermore, fiber channels use sophisticated IO (Xilinx rocket IO) , > > for cost effectiveness I don't want to invest in these expensive IOs. > > I looked around on the net for some possible solutions, but fiber > > channel was the closest solution to my problem I could find. My > > question is therefore: > > Did I overlook something? Is there an IP-core or external chip which > > allows me to establish a 100Mb/s data communication link between two > > embedded processors using fiber optic. > > > Thank you in advance for your help. > > Oliver Faust > > up to 10m up to 125mbits > TOSLINK > > http://en.wikipedia.org/wiki/TOSLINK > > there are possible other options as well > > Antti Thank you for this quick response. I considered TOSLINK as being more in the area of audio data transfer. But with a data rate of 125mbits it looks applicable for my application. On top of your head, do you know any IP-cores or external chips which implement TOSLINK? Furthermore, you mentioned other possible solutions, what are these solutions? OliverArticle: 139452
On Mar 30, 10:05=A0am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On 30 Mar 2009 09:48:25 GMT, Allan Herriman > > > > <allanherri...@hotmail.com> wrote: > >On Sun, 29 Mar 2009 19:12:58 -0700, John Larkin wrote: > > >> On Sun, 29 Mar 2009 21:00:48 -0500, krw <k...@att.bizzzzzzzzzzz> wrote= : > > >>>On Sun, 29 Mar 2009 17:02:47 -0700, Joerg > >>><notthisjoerg...@removethispacbell.net> wrote: > > >>>>krw wrote: > >>>>> On Sun, 29 Mar 2009 14:38:26 -0700, Joerg > >>>>> <notthisjoerg...@removethispacbell.net> wrote: > > >>>>>> Jan Panteltje wrote: > > >>>>>> [...] > > >>>>>>> That is the nice thing about digital processing, no trimmers, no > >>>>>>> tolerances, no monte carlos. > > >>>>>> Don't need Monte Carlo, there's an Indian gambling place down the > >>>>>> road but I don't gamble anyhow. > > >>>>>> Oh, wait ... > > >>>>>>> You may want an FPGA with onboard flash.. > > >>>>>> Flash? That's frowned upon as morally indecent in the more > >>>>>> conservative regions out here :-) > > >>>>>>> Just make sure you can actually get the chips from several source= s, > >>>>>>> watch the price too. ... > > >>>>>> That's the two main problems. FPGA are usually all single-sourced > >>>>>> (having several distributors doesn't count) and expensive. Seen to= o > >>>>>> many purchasing nightmares there. > > >>>>> Technically single-sourced, yes. =A0As long as you stay away from t= he > >>>>> quirks (LVDS performance can be considered a "quirk" ;), unique > >>>>> features, and IP cores, they're pretty easy to substitute. =A0The c= osts > >>>>> have come *way* down, as well. =A0$5-$20 buys a lot of logic these > >>>>> days. > > >>>>That's true, but a lot of times my whole design including board and > >>>>assembly can't cost nearly as much as that (in large quantities). > > >>>No, FPGAs aren't the right answer for every question but you're not > >>>going to buy that function, or anything near it, for less. =A0We have = a > >>>pile of crap logic that I'd *love* to sweep into a FPGA. =A0It would s= ave > >>>a lot of money and grief. =A0If I was convinced I could do a decent de= lta > >>>sigma modulator I'd do even more. > > >> D-S dacs work just fine in FPGAs. They're especially handy for slow > >> trims, like dc offset, vcxo freq, stuff like that. One FPGA pin and on= e > >> external RC makes a pretty good dac. > > >> John > > >I've used external CMOS buffers to give a noise-free Voh for this > >application. =A0FPGA outputs can have quite a lot of noise on them, coup= led > >from other outputs on the same bank. =A0(The numbers vary from family to > >family, etc.) > > >Regards, > >Allan > > A delta-sigma dac needs a ton of lowpass filtering anyhow, so the only > noise that matters is slow stuff on the +3.3 rail, which is usually > easy to control. Most fpga's bank Vcc_out anyhow, so only the "dac > bank" supply needs to be quiet at low frequencies. I have found that digital noise on an analog component can be a very *real* problem. It is surprising where noise can come from. A component I was using turned out to have 0 dB of PSRR. It wasn't in the data sheet and I didn't think to ask. I only found out because there was a problem with buzzing in the output at certain times. When all the troubleshooting was done, the source turned out to be power supply noise. When the DSP was in the code to pass data to the output, it was in a loop at 300 Hz and the difference in power consumption between the wait loop and the "move data" loop was creating 10 mV of 300 Hz noise on the power rail. I suppose that would not be an issue if I wasn't using a crappy part. Still, with a VCO you need to be very careful about having a clean power supply. It doesn't take much to put noise of all frequencies on the rails and once there, it is hard to clean up... although I did find that a 1000 uF capacitor can do wonders at 300 Hz. RickArticle: 139453
On Mon, 30 Mar 2009 09:30:28 -0500, "dts4theworld" <dts4theworld@gmail.com> wrote: >I'm trying now to figure out what I need to know in order to get some >results. First off, I now need a processor design which can support this >UVC driver (parts of it) - Can I use here an open-core design? Any processor which has a C compiler can be made to work in this context. >The signal processing has to be hardware.. i'm not sure how to get these >together. You advised me not to try a hardware implementation of the UVC.. >but then wouldn't my driver need to control the signal processing part as >well? No. The UVC stack basically has the responsibility of delivering the client app the frames coming from the webcam which is where your DSP shoud start. >About the FX2 - the manual sais it's no problem to run it as host. That's good news. >I was also thinking if it would be easier to get the data from the webcam >through the laptop, which would then feed the FPGA board through some other >interface. That's the solution I'd suggest. Writing a client app on the PC which then transfers individual frames back to the fpga board again in USB but in a much simpler protocol (specific to your design) makes your life much easier. Even if you need an integrated solution in the future, starting this way to validate your signal processing algorithms make sense. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139454
You know, the simplest, best tested, _widely_ available, and likely cheapest solution is ... (drumroll) 100 Mbps Ethernet. Ethernet is very tolerant of EMI, and with Cat 6 cables I seriously doubt you could have an issue. Fiber is fun (and healthy in your diet), but it just isn't mainsteam enough which translates into either high cost or lots of custom development. TommyArticle: 139455
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:s8cts4d6jcmvbk2tu3cd3tua362o6gtde7@4ax.com... > We did some playing with FPGA-based PLLs. The classic charge-pump PDs > didn't work very well. This works... Nice. What PFD frequency was the FPGA running at? > No deadband, fast as all getout, low phase noise. And certainly cheaper than purchasing a separate PLL IC if you already need an FPGA. ---JoelArticle: 139456
On Mon, 30 Mar 2009 10:09:09 -0700, "Joel Koltner" <zapwireDASHgroups@yahoo.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:s8cts4d6jcmvbk2tu3cd3tua362o6gtde7@4ax.com... >> We did some playing with FPGA-based PLLs. The classic charge-pump PDs >> didn't work very well. This works... > >Nice. What PFD frequency was the FPGA running at? > >> No deadband, fast as all getout, low phase noise. > >And certainly cheaper than purchasing a separate PLL IC if you already need an >FPGA. > >---Joel > Most recent case, we're locking a 128 MHz VCXO to an external 10 MHz reference, so we divided both down to 2 MHz. This phase detector gave us a lot less phase noise and phase error than any of the classic charge-pumps we tried to fake. Given that there's some overlap designed into the up/down blips, the loop gain is higher (2x) in the overlap region than farther from zero phase error. JohnArticle: 139457
Does anybody know where I can find the toolchain for programming MACH2 parts? Lattice Semiconductor does no longer support these very old parts. However we have plenty of Mach211SP ( 24 parts). It would be a waste if we could not use these parts anymore due to lack of support in newer tools. These parts can operate with 5V supply and they are very good for learning/teaching purposes. Best Regards, Marcio.Article: 139458
In article <c646ed48-f64d-4353-b508-b6f41f32364f@z9g2000yqi.googlegroups.com>, mitrusc1980-newsgroup@yahoo.com.br writes: |> Does anybody know where I can find the toolchain for programming MACH2 |> parts? Google does. Searching for "MachXL 2" brings up e.g. http://noel.feld.cvut.cz/hw/amd/mxl21sw_.html RainerArticle: 139459
On Mar 30, 4:27=A0pm, Oliver Faust <oliver.fa...@gmail.com> wrote: > Hi, > I want to network multiple embedded processors using optical fiber as > physical layer. This network is realised with point to point > connections. At the moment, the network is established using RS232. To > get higher data rates (around 100Mb/s) and better protection against > EMI the electrical RS232 should be exchanged with optical data > transfer. > In order to realise this change, I'm searching for a technology > similar to Fiber Channel (FC). The only, difficulty with FC is that > the speed is too high, the slowest speed for fiber channel is 1Gb/s. > Furthermore, fiber channels use sophisticated IO (Xilinx rocket IO) , > for cost effectiveness I don't want to invest in these expensive IOs. > I looked around on the net for some possible solutions, but fiber > channel was the closest solution to my problem I could find. My > question is therefore: > Did I overlook something? Is there an IP-core or external chip which > allows me to establish a 100Mb/s data communication link between two > embedded processors using fiber optic. > > Thank you in advance for your help. > Oliver Faust You can check the TLK family of transceivers from Texas Instruments; they exist in different speeds. Apart from a couple of these you will need a photodiode and a laser (of course). The chip uses 8b/10b to encode the data, but it is all transparent for the user. hope it helps, ChristosArticle: 139460
On Sun, 29 Mar 2009 19:12:58 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Sun, 29 Mar 2009 21:00:48 -0500, krw <krw@att.bizzzzzzzzzzz> wrote: > >>On Sun, 29 Mar 2009 17:02:47 -0700, Joerg >><notthisjoergsch@removethispacbell.net> wrote: >> >>>krw wrote: >>>> On Sun, 29 Mar 2009 14:38:26 -0700, Joerg >>>> <notthisjoergsch@removethispacbell.net> wrote: >>>> >>>>> Jan Panteltje wrote: >>>>> >>>>> [...] >>>>> >>>>>> That is the nice thing about digital processing, no trimmers, no tolerances, >>>>>> no monte carlos. >>>>> >>>>> Don't need Monte Carlo, there's an Indian gambling place down the road >>>>> but I don't gamble anyhow. >>>>> >>>>> Oh, wait ... >>>>> >>>>> >>>>>> You may want an FPGA with onboard flash.. >>>>> >>>>> Flash? That's frowned upon as morally indecent in the more conservative >>>>> regions out here :-) >>>>> >>>>> >>>>>> Just make sure you can actually get the chips from several sources, watch >>>>>> the price too. ... >>>>> >>>>> That's the two main problems. FPGA are usually all single-sourced >>>>> (having several distributors doesn't count) and expensive. Seen too many >>>>> purchasing nightmares there. >>>> >>>> Technically single-sourced, yes. As long as you stay away from the >>>> quirks (LVDS performance can be considered a "quirk" ;), unique >>>> features, and IP cores, they're pretty easy to substitute. The costs >>>> have come *way* down, as well. $5-$20 buys a lot of logic these days. >>> >>> >>>That's true, but a lot of times my whole design including board and >>>assembly can't cost nearly as much as that (in large quantities). >> >>No, FPGAs aren't the right answer for every question but you're not >>going to buy that function, or anything near it, for less. We have a >>pile of crap logic that I'd *love* to sweep into a FPGA. It would >>save a lot of money and grief. If I was convinced I could do a decent >>delta sigma modulator I'd do even more. > >D-S dacs work just fine in FPGAs. They're especially handy for slow >trims, like dc offset, vcxo freq, stuff like that. One FPGA pin and >one external RC makes a pretty good dac. I'm looking to replace a 16bit (24bit but don't believe the specs) audio codec.Article: 139461
Hi all, Is there a way to initialize BRAM contents (of memories created using CoreGen) into a new bit file without having to recompile the whole thing? I understand that was possible using data2mem with older versions, e.g ISE 8.2. AR#18637 says it doesn't work for newer versions. Does somebody know a work around? Alonzo.Article: 139462
On Mar 30, 4:42 pm, alonzo <rh...@yahoo.com> wrote: > Hi all, > Is there a way to initialize BRAM contents (of memories created using > CoreGen) into a new bit file without having to recompile the whole > thing? I understand that was possible using data2mem with older > versions, e.g ISE 8.2. AR#18637 says it doesn't work for newer > versions. Does somebody know a work around? > Alonzo. There are tools installed with the EDK that do that. ALArticle: 139463
I recently bought a Digilent Nexys 2 board, and after a few days of research got to the point where I can successfully program it over USB from a Linux host without the use of a separate (and expensive!) JTAG interface. Google told me even before I purchased the board that this is a very common requirement; it seems that I'm not the only one interested in linux-hosted FPGA development. The pieces to make this work were all there, happily (see the README in the download below for details -- the chain of responsibility here is long); it just took work to assemble them correctly. For those interested, I wrote a quick perl script to automate the process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz [/url] This wraps the multi-step mess (device detection/configuration, SVF generation, and JTAG download) as fully as possible, most importantly by doing the USB bus enumeration and dynamically reprogramming the Nexys 2 with a patched usb_jtag firmware blob in the script itself. The user just specifies the Xilinx bitstream file as the sole argument. Installation is as simple as I could make it, requiring only Xilinx ISE, two binary packages (fxload and libftdi -- both available via apt- get on Ubuntu Intrepid) and one source install (UrJTAG -- just a simple "./configure;make;make install" will do). Hopefully this will help other newbies with the learning curve. Let me know if something doesn't work, or if there are questions.Article: 139464
On Mar 30, 4:44=A0pm, LittleAlex <alex.lo...@email.com> wrote: > On Mar 30, 4:42 pm, alonzo <rh...@yahoo.com> wrote: > > > Hi all, > > Is there a way to initialize BRAM contents (of memories created using > > CoreGen) into a new bit file without having to recompile the whole > > thing? I understand that was possible using data2mem with older > > versions, e.g ISE 8.2. AR#18637 says it doesn't work for newer > > versions. Does somebody know a work around? > > Alonzo. > > There are tools installed with the EDK that do that. > > AL Yes. I know about bitinit. But it is not transparent. It works with cores that EDK provides and requires a MHS file. My project is a simple ISE project that instantiate a couple BRAMs. I don't think it would help. Do you know about any other tool? alnz.Article: 139465
On Mar 31, 3:05=A0am, alonzo <rh...@yahoo.com> wrote: > On Mar 30, 4:44=A0pm, LittleAlex <alex.lo...@email.com> wrote: > > > On Mar 30, 4:42 pm, alonzo <rh...@yahoo.com> wrote: > > > > Hi all, > > > Is there a way to initialize BRAM contents (of memories created using > > > CoreGen) into a new bit file without having to recompile the whole > > > thing? I understand that was possible using data2mem with older > > > versions, e.g ISE 8.2. AR#18637 says it doesn't work for newer > > > versions. Does somebody know a work around? > > > Alonzo. > > > There are tools installed with the EDK that do that. > > > AL > > Yes. I know about bitinit. But it is not transparent. It works with > cores that EDK provides and requires a MHS file. My project is a > simple ISE project that instantiate a couple BRAMs. I don't think it > would help. Do you know about any other tool? > alnz. Xilinx AR's are really ROTFL stuff, from the AR you referred Note: Using data2mem on CORE Generator memories in 9.1i or later works only sporadically. So Xilinx 9.1 and later are now "Sporadic software" ! ok, but that only relaced to coregen, and you have no need to used coregen just use the brams in ISE create a BMM file and use data2mem it defenetly works in 10.1 too http://www.xilinx.com/itp/xilinx10/books/docs/d2m/d2m.pdf make BMM, use MEM file and all works :) AnttiArticle: 139466
Hi, I received recently the Vita 57 standard. I would like to congratulate the Vita team that has written it. It is a beautiful standard that many people have been waiting for since a long time. On the first page there is a warning stating that the dedicated clock distribution pins from Carrier to Mezzanine (C2M) were going to be replaced by Mezzanine to Carrier (M2C) pins. This means that if you ever want to feed a clean, stable, low jitter you will have to pass through the FPGA using standard differential IOs. Adding more M2C pairs is not really helpful as standard FPGA IOs can already be routed to the DCM reference clock input without major problems (please correct me if I am wrong). On the other hand the added jitter by the FPGA will be a liming factor for high accuracy data acquisition applications that do not receive their reference clock directly on the FMC front panel. I would like to know the FPGA community opinion. Who knows? If we give the right reasons perhaps the Vita 57 working group could change their mind after all. Best regards Pablo AlvarezArticle: 139467
Hi all, I have an issue with the IOB and DCM placement in my design. The problem seems to be that the IOB of the CLKIN pin is located in the upper half of the device and the IOB for CLKFB is located in lower half. Hence, I always get a packing error because the DCM is not in the same half of the device as the IOB connected to either CLKIN or CLKFB and a dedicated clock route can not be used. Anyone know how I can get around this problem? The CLKFB is external because a SRAM is in the feedback loop. This is the default setup for a EDK uBlaze system for the ML506 board. Can anyone tell me why it set up like this? I know it somehow synchs the SRAM and the FPGA but I don't really understand how the feedback works. Additional info: I am using the clock_manager module of the uBlaze to generate additional clocks that I need for other firmware. It instanciates two PLL_ADVs and one DCM_ADV in an unknown consfiguration.Article: 139468
On Mar 30, 9:09=A0pm, czam <csat...@gmail.com> wrote: > On Mar 30, 4:27=A0pm, Oliver Faust <oliver.fa...@gmail.com> wrote: > > > > > Hi, > > I want to network multiple embedded processors using optical fiber as > > physical layer. This network is realised with point to point > > connections. At the moment, the network is established using RS232. To > > get higher data rates (around 100Mb/s) and better protection against > > EMI the electrical RS232 should be exchanged with optical data > > transfer. > > In order to realise this change, I'm searching for a technology > > similar to Fiber Channel (FC). The only, difficulty with FC is that > > the speed is too high, the slowest speed for fiber channel is 1Gb/s. > > Furthermore, fiber channels use sophisticated IO (Xilinx rocket IO) , > > for cost effectiveness I don't want to invest in these expensive IOs. > > I looked around on the net for some possible solutions, but fiber > > channel was the closest solution to my problem I could find. My > > question is therefore: > > Did I overlook something? Is there an IP-core or external chip which > > allows me to establish a 100Mb/s data communication link between two > > embedded processors using fiber optic. > > > Thank you in advance for your help. > > Oliver Faust > > You can check the TLK family of transceivers from Texas Instruments; > they exist in different speeds. Apart from a couple of these you will > need a photodiode and a laser (of course). > > The chip uses 8b/10b to encode the data, but it is all transparent for > the user. > > hope it helps, > Christos Dear Christos, Thank you for the suggestion. However, a brief glance over the TLK family of transceivers from Texas Instruments showed me that these are converters Gbit Ethernet to Fiber Channel. Unless I missed something, this is too fast for my application. Oliver FaustArticle: 139469
On Wed, 25 Mar 2009 04:07:58 -0700, Antti wrote: > I was entering FPGA in wikipedia, entered Silicon Blue, found nothing > added SiliconBlue page, as i did think it is worth of being covered, but > the censors of the wikipedia think otherwise :( > > Any ideas how to convince them? > here is the page that is pending deletion (was one time deleted already) > > http://en.wikipedia.org/wiki/SiliconBlue_Technologies > > maybe i am so stupid and do not understand why only the worlds 5 first > FPGA > can be included in wikipedia? > Hi Antti, Good you are trying to increase information on Wikipedia. The discussion page has a lot of feedback as to why the editors thought this page should be deleted. I don't think they are being unreasonable. You need to explain what makes Silicon Blue notable - what is so special about their chip. Then you need to back that up with some strong *independent* references. Company press releases and the Silicon Blue user group are not independent. For example, perhaps there are academic research papers behind the low power technology that Silicon Blue are bringing to market? Actually you are a step on the way. The article by Clive Maxwell is (IMHO) an independent reference, and he does explain what he believes makes their technology unique. You could explore those points rather more in the article. If it's any consolation I've found writing good Wikipedia articles for niche technology really hard (and in the scale of Wikipedia, 6th biggest FPGA vendor makes them niche). Very often the only people who are interested are the vendor and their user group. Establishing notability with independent references is difficult. I've added a comment to the discussion page on Wikipedia and some ideas for improvement in the article. Readers of this group may like to make suggestions of why (or why not) Silicon Blue is a notable organization that should appear on Wikipedia! JeremyArticle: 139470
On Mar 31, 11:33=A0am, Jeremy Bennett <jeremy.benn...@embecosm.com> wrote: > On Wed, 25 Mar 2009 04:07:58 -0700, Antti wrote: > > I was entering FPGA in wikipedia, entered Silicon Blue, found nothing > > added SiliconBlue page, as i did think it is worth of being covered, bu= t > > the censors of the wikipedia think otherwise :( > > > Any ideas how to convince them? > > here is the page that is pending deletion (was one time deleted already= ) > > >http://en.wikipedia.org/wiki/SiliconBlue_Technologies > > > maybe i am so stupid and do not understand why only the worlds 5 first > > FPGA > > can be included in wikipedia? > > Hi Antti, > > Good you are trying to increase information on Wikipedia. The discussion > page has a lot of feedback as to why the editors thought this page should > be deleted. I don't think they are being unreasonable. > > You need to explain what makes Silicon Blue notable - what is so special > about their chip. > > Then you need to back that up with some strong *independent* references. > Company press releases and the Silicon Blue user group are not > independent. For example, perhaps there are academic research papers > behind the low power technology that Silicon Blue are bringing to market? > > Actually you are a step on the way. The article by Clive Maxwell is > (IMHO) an independent reference, and he does explain what he believes > makes their technology unique. You could explore those points rather more > in the article. > > If it's any consolation I've found writing good Wikipedia articles for > niche technology really hard (and in the scale of Wikipedia, 6th biggest > FPGA vendor makes them niche). Very often the only people who are > interested are the vendor and their user group. Establishing notability > with independent references is difficult. > > I've added a comment to the discussion page on Wikipedia and some ideas > for improvement in the article. Readers of this group may like to make > suggestions of why (or why not) Silicon Blue is a notable organization > that should appear on Wikipedia! > > Jeremy Hi thanks a lot, i had not noticed the new warnings that appeared again : ( eh well there are different point of views, there are so little FPGA vendors around (alive) that my point that all of them should be noteable is well, yes.. ehm thanks for commentary appreiciate there are not so many articles in sources that wikipedia would accept as independant, i tried to include most of them (there are some more but mostly from same publisher/author or then i could not find suitable link to the original article) AnttiArticle: 139471
On Mar 31, 11:33=A0am, Jeremy Bennett <jeremy.benn...@embecosm.com> wrote: > On Wed, 25 Mar 2009 04:07:58 -0700, Antti wrote: > > I was entering FPGA in wikipedia, entered Silicon Blue, found nothing > > added SiliconBlue page, as i did think it is worth of being covered, bu= t > > the censors of the wikipedia think otherwise :( > > > Any ideas how to convince them? > > here is the page that is pending deletion (was one time deleted already= ) > > >http://en.wikipedia.org/wiki/SiliconBlue_Technologies > > > maybe i am so stupid and do not understand why only the worlds 5 first > > FPGA > > can be included in wikipedia? > > Hi Antti, > > Good you are trying to increase information on Wikipedia. The discussion > page has a lot of feedback as to why the editors thought this page should > be deleted. I don't think they are being unreasonable. > > You need to explain what makes Silicon Blue notable - what is so special > about their chip. > > Then you need to back that up with some strong *independent* references. > Company press releases and the Silicon Blue user group are not > independent. For example, perhaps there are academic research papers > behind the low power technology that Silicon Blue are bringing to market? > > Actually you are a step on the way. The article by Clive Maxwell is > (IMHO) an independent reference, and he does explain what he believes > makes their technology unique. You could explore those points rather more > in the article. > > If it's any consolation I've found writing good Wikipedia articles for > niche technology really hard (and in the scale of Wikipedia, 6th biggest > FPGA vendor makes them niche). Very often the only people who are > interested are the vendor and their user group. Establishing notability > with independent references is difficult. > > I've added a comment to the discussion page on Wikipedia and some ideas > for improvement in the article. Readers of this group may like to make > suggestions of why (or why not) Silicon Blue is a notable organization > that should appear on Wikipedia! > > Jeremy eh the wiki censors are not really doing proper job: on the main article about FPGAs there is picture of altera chip with following description: "Foto of an IC - FPGA - Altera-StratixIIGX mounted on a PCB Source http://www.xilinx.com/xlnx/xebiz/utils/image_window_product.jsp?valueA=3DHW= -V5-ML501-UNI-G " This is most likely pretty rude violation (dont know against what) but both Xilinx and Altera should be legally unhappy about this picture AnttiArticle: 139472
Thank you for your replies, It's working now : 1- ISE --> Your project 2- New File : XPS system ( Create your system with XPS ) 3- Close XPS 4- Update bitstream in ISE ( This updates only the hardware modifications) 5- Use Data2mem if u need to put any software application (in the Bram for example) : data2mem -bm "system/implementation/system_bd" -bt "system_stub_download.bit" -bd "system\SDK_projects\application\Debug \application.elf" tag microblaze_0 -o b system_bram_initialised.bitArticle: 139473
On Mar 30, 6:55=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > You know, the simplest, best tested, _widely_ available, and likely > cheapest solution is ... (drumroll) 100 Mbps Ethernet. Ethernet is > very tolerant of EMI, and with Cat 6 cables I seriously doubt you > could have an issue. > > Fiber is fun (and healthy in your diet), but it just isn't mainsteam > enough which translates into either high cost or lots of custom > development. > > Tommy Dear Tommy, At the moment I'm in the discovery phase of the project. Slowly, I understand the point that fiber optics are not mainstream. Fiber optics are only considered for applications where weight is an issue and / or EMI resilience. Oliver FaustArticle: 139474
Hi, 1- Hardware : Generate you bit file whatever how . ---> system_stub_download.bit 2- Software : Compile you application ---> application.elf 3- Use Data2me to put software into bitsream. Example : data2mem -bm "system/implementation/system_bd" -bt "system_stub_download.bit" -bd "system\SDK_projects\application\Debug \application.elf" tag microblaze_0 -o b system_bram_initialised.bit
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