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
Hi, I please you to suggest me how I can find a good performances, free, RF Numerical Controlled Oscillator (or RF downconverter) program(s), not IP covered, for non professional use. Thanks. -- "Malo ho'omou tokoni " 73's de IZ5FCY Roberto ----------------------------- http://www.iz5fcy.it (work in progress..)Article: 108326
Chao wrote: > I am trying to use I2C to configure TI TFP410 DVI transmitter. I put > differential clock input and VSYNC/HSYNC with the data. I suppose to get > 1600x1200 image on the monitor. Basically, I just want to show a simple > image and my hardware pins configuration is like below: > > DKEN (35) <--- GND > /PD (10) <--- GND > MSEN (11) <--- pull high > EDGE (09) <--- float with a serial resistor 1k > DE (02) <--- floating (since it should be ignored after I2C > configured it as disabled) > ISEL (13) <--- pull high > Vref (03) <--- VDD > > I believe this chip should work with only input VSYNC/HSYNC, +/-CLOCK > and 24bits DATA. Point me out if I am wrong. Thanks. > > Chao /PD (10) <--- GND This pin need to be pulled high otherwise the chip is powered down. DE (02) <--- floating (since it should be ignored after I2C > configured it as disabled) This pin must toggle. It defines whether data or syncs are encoded in the output as well as indicating active video. Your monitor will not understand the signal otherwise. See the DVI spec for details. http://www.ddwg.org > EDGE (09) <--- float with a serial resistor 1k Must pull high or low depending on the polarity of the clock. BTW at 162MHz dot clock (1600x1200) the PCB layout is ultra critical and should be run through a DVI compliance test with stressful test patterns. Silicon Image have a test kit for this which can be used with Tektronix TDS 6000 series scopes.Article: 108327
Hi, If these state machines runs same clock, you can use it directly. another advice: in your source, P is same with B, but more signal variables may raise complexity of your source. As you wrote : > P <= '1' WHEN ( B='1' ) ELSE '0'; > > P1 <='1' WHEN P='1' AND D > "00000000000000000" ELSE '0'; that is same with: > P1 <='1' WHEN B='1' AND D > "00000000000000000" ELSE '0'; and use B on all instance of P. (another thing: Synthesizer can recognise this equivalence, or - if needed- inserting a buffer). Best regards dhruvakshad@gmail.com wrote: > I have one more question. If I have two state machines with following > signals gating their states > > P <= '1' WHEN ( B='1' ) ELSE '0'; > > P1 <='1' WHEN P='1' AND D > "00000000000000000" ELSE '0'; > > both these two signals are needed > Now when I pass signal P1 to the state machine then do I have to pass > it via a flip flop ? > > the signals B and D are assigned in another state machine and both the > state machines are running at same clock. > Thanks, > -D > > > dhruvakshad@gmail.com wrote: > > Thank you very much for the tip. I realised my mistake. It works fine > > now. > > -DArticle: 108328
Chao <ssc3k@yahoo.com> writes: What speed is your clock? Have you tried to produce a lower resolution display? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 108329
"Charlie Edmondson" <edmondson@ieee.org> wrote in message news:44ff2839$1@news.cadence.com... > Had a similiar situation when I worked on the 91 Express lanes toll > road. My boss was a real A-hole, who would do things like, pull out a > knife and shave his arms, commenting on how sharp it was, while asking > for the status of your assignments. The threat was very thinly veiled... Occasionally leave an empty gun holster on your desk. Works wonders.Article: 108330
Mike Treseler <mike_treseler@comcast.net> writes: > avishay wrote: > > > I would appreciate if anyone can give me an idea if such tools exist on > > the market, or to let me know how such task is being handled in other > > companies. > > Step one is quality source control. > Spot on! I've also moved from Sourcesafe to SVN - life is much nicer now. Sourcesafe lost one of my files completely, I've lost trust in it. TortoiseSVN integrates really nicely with Explorer, so you don't need to use another tool for accessing the library. This makes it easy to convert others! It also does 3 way merging of differences, which sourcesafe never did. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 108331
avishay wrote: > Hi everyone, > A few months ago, I have started working in a small group which designs > FPGAs for video application. By the nature of this application, there > is a collection of building blocks that are repeatedly being used in > our designs. Currently, the knowledge about cores available and how to > use them is kept by each designer, so if I need a core from someone I > have to ask him to send it to me by e-mail. Certainly, this model is > very problematic causing the same cores to be designed again and again > by different engineers. > I would like to suggest my managers a better way to share this valuable > data between the engineers, and I'm looking for a solution that will > provide: > > * Integration with a source control system (sadly, SourceSafe is being > used in my company, so > I'm binded to that awful tool) > * A catalog of available cores > * An easy way to add new cores and to update existing ones > * A structured way to minimally document the core (functionality, > interface) > * Integration with design tools (Quartus, HDL Designer, Synplify...) > > I would appreciate if anyone can give me an idea if such tools exist on > the market, or to let me know how such task is being handled in other > companies. > After improved source control - as mentioned elsewhere on this thread - you could set up (if there isn't already) an in-house web-server, hosting a Wiki page. Then let everyone document what they do as they go, on the Wiki. You can set up a proforma page, that they just fill in the blanks, & voila: instant manual:)Article: 108332
"Michael A. Terrell" <mike.terrell@earthlink.net> wrote in message news:44FB18BC.CED74990@earthlink.net... > I got stuck working the overtime because the idiot ordered the wrong > piece of equipment for a CATV headend. he insisted that Jerrold, > (General Instruments) didn't know what they were talking about, and that > our 10,000 cable converters were already tuned to the channel he > ordered. They weren't, and the jackass refused to change the order, so > I had to modify 10,000 pieces of equipment instead. No, you did not *have* to do that: You chose to bail the arsehole out so he will be there to screw up in the future - and - said person being a jackass will not even be buying you beer for it too. Counterproductive!Article: 108333
"David Ashley" <dash@nowhere.net.dont.email.me> wrote in message news:450072e1$3_1@x-privat.org... > Hi, > > I have about 4 different independent things that each need to access > a ddr. Then you need a 4 port arbitrator to control access to the DDR. > On one hand it seems I can make them all wishbone > compliant then just have a wishbone ddr interface. > The arbitrator would then have 4 user ports and one DDR port, all can be Wishbone compliant and connect up nicely. > Would be workable/advisable to instead just have each device > control the ddr itself, and use the ddr's own interface directly? > Probably not. Arbitration by nature needs 'global' knowledge of the scope of what it is arbitrating in order to be effective: Some things needed are - It needs to know about the 4 (or however many) users - Preferred burst sizes for each port - How long the other ports should wait while they're waiting for their turn (i.e. how important is latency). - Arbitration scheme (round robin, etc.) All of the above can be implemented in a single arbiter where basically all of the above can (and should...IMO) be input as generic parameters and will be very efficient in terms of logic resources. Without expanding the arbiter design beyond the design considerations that are important to your particular application, you can write such an arbiter and still parameterize it enough that it might be either directly useful the next time this situation comes up again or will at least provide a solid baseline for you to generalize it a bit more for that next application without having to totally re-invent the wheel. Each device (i.e. user of the DDR) should not be concerned with this type of information they should just think that they have exclusive access to a Wishbone port. Gumming up the user design with this info would be counterproductive at best. By moving bits and pieces of the arbitration into each user's design code you're most likely to create something that is - Less efficient in terms of logic resource usage than it should be (at best it would be no worse but I doubt it could be better) - Created a less than useful 'device' since now it is a device that is only applicable if it is used in a system with three other users all sharing a DDR. > I'd only need one complicated mechanism to initialize the ddr > after reset, but from then on each of the user processes can just > request access to the ddr, and when granted just take over > the lines. Again, what is needed is the arbitration logic. > > One concern is that ddr timing at 100 mhz is pretty tight. Having > the logic to combine 4 different sources into control signals for > the ddr might add too much overhead. Of course it can be > accomplished with a single LUT just doing a non-registered > OR, if all 4 sources know to zero out their control lines when > they're not the master... > The four port inputs into the arbiter can be as fast or faster since they will all be inside the FPGA. DDR may be fast but FPGA internal is faster. KJArticle: 108334
Hi folks, How do I calculate the gamma values for LCD module? I am trying to design a LCD driver board. Cheers PArticle: 108335
sjulhes wrote: > Hello all, > > We are trying to design a small microblaze design in a spartan 3 and the > problem we have is that the microblaze does not always start when the > bitsream is downloaded with JTAG. > > But when we implement the debug module it always works. > > Does anyone has a clue ? > Is it timing problems ? Is there specific timing constraints to add for > microblaze ? > Software problem ( linker script is automatically generated by edk)? > > Any idea is welcome. > > Thank you. > > Stéphane. > > Hi, It's too little information to point out the what is wrong. - How do you detect that is doesn't start? - Are you using external memory? - Can the program fit totally in the internal BRAM? - What download cable are you using? Göran BilskiArticle: 108336
Let's make an open-hardware embedded CableServer/cable, say an Atmel SAM7X with PHY and a Coolrunner, or a Spartan3 with Microblaze/MAC/PHY? Henk van Kampen www.mediatronix.com zcsizmadia@gmail.com wrote: > Hi All, > > Here is a open-source CableServer replacement,ent for Impact. Currently > Parallel III and Alter ByteBlaster are supported, but any 3rd party can > be implemented easily and can be used from Impact. > > I've tested only Impact 8.2, if anybody has any problem with 7.1, > please let me know! > > Impact and Xilinx CableServer communication are very pooly written. > There is no error recovery at all. If server stops, Impact GUI will > crash. To avoid this you must disconnect server from GUI using > Output/Cavble disconnect menu. > > http://sourceforge.net/projects/xilprg > http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209 > > Regards, > > ZoltanArticle: 108337
hi i just started to work with the microblaze processor and ethernet (i hav the digilent spartan3e board) and it seems the the test programm i compiled doesn't fit into the bram.. the warning i get is : Address Map for Processor microblaze_0 (0x00000000-0x00003fff) dlmb_cntlr dlmb (0x00000000-0x00003fff) ilmb_cntlr ilmb (0x22000000-0x23ffffff) DDR_SDRAM_16Mx16 mb_opb (0x40000000-0x4000ffff) LEDs_8Bit mb_opb (0x40020000-0x4002ffff) DIP_Switches_4Bit mb_opb (0x40040000-0x4004ffff) Buttons_4Bit mb_opb (0x40600000-0x4060ffff) RS232_DCE mb_opb (0x40c00000-0x40c0ffff) Ethernet_MAC mb_opb (0x41400000-0x4140ffff) debug_module mb_opb Initializing Memory... Checking ELFs associated with MICROBLAZE instance microblaze_0 for overlap... Analyzing file TestApp_Peripheral/executable.elf... WARNING:MDT - Elf file TestApp_Peripheral/executable.elf does not reside completely within BRAM memory of processor microblaze_0. WARNING:MDT - The sections of ELF residing outside BRAMs must be initialized separately using a debugger, a bootloader, or an ACE file INFO:MDT - BRAM lmb_bram will be initialized with ELF of processor microblaze_0 Running Data2Mem with the following command: data2mem -bm implementation/system_bd -bt implementation/system.bit -bd TestApp_Peripheral/executable.elf tag lmb_bram -o b implementation/download.bit Memory Initialization completed successfully. does this mean it worked?? i don't get any output on the UART terminal. i do get an output with the "testmem_app" though so uart should be working. can anybody help me here please? does somebody also have some code snippets or tutorial how to send and recieve data with the ethernet ip core that comes wit the edk? that would be a great help! thanks urbanArticle: 108338
Weng, One thing that I think has been ignored by this thread, and yet is probably the most important point, is that the semiconductor industry has a roadmap. That roadmap defines exactly what will happen, for as far into the future as they are capable of either guessing, or hoping. Which is pretty far. This is one of the reasons why the industry has been so successful: there is no risk (really). Everything from lithography, to wafers, to chemicals, gases, reaction chambers, implanters, metals, packages, has been set out for you. There is a "goal" of what is needed, and you can go and execute to that goal. Yes, occasionally they ask for something that can't be done (yet), like the Hi-K gate dielectric (unobtainium?). But generally, the fab industry and its ecosystem is a well "regulated" technology monopoly. If the technology is completely defined, then there is no way to build anything that is not on the roadmap. Doing so, is doomed to failure. There are many examples of this, by the way. First comes CMOS, then comes DRAM, and finally comes flash. Even the sequence of arrivals of the flavors of each technology node is completely pre-ordained. To even suggest that you would like to have a different thickness of a single metal layer is completely heretical: it may happen once, but since it isn't in the roadmap, it will not happen again. Even those who own their own fabs are so constrained. They must buy their equipment from the same people that are supplying the "roadmap." Thus even if you want to do something "out of the box" you are unable to find the equipment to do it. Our a "best known method." As the dimensions crash into quantum mechanics limitations, it will be interesting to see if the roadmap diverges, or if every "backroad" is just as highly constrained as it is today. My bet is that the roadmap will be with us for a long time, as it is a proven method to nurture, supply, and execute, in semiconductors. AustinArticle: 108339
I'm thinking "The sections of ELF residing outside BRAMs must be initialized separately using a debugger, a bootloader, or an ACE file" you should think about initialialising using a debugger, bootloader or ACE file. ;-) When you use the microblaze it writes your code into a block RAM... Err, in picoblaze you get a handy little compiler that reads your assembler and spits out a .vhd file with INIT values in it. Of course if your code goes longer than the blockram length then how can it initialise the memory to the correct values? Ok, I digress. 1. Make sure your code is super efficient or/then.. 2. figure out a way to get more than one block RAM initialised with your values, AND get it addressed and executed from by the microblaze.. Have a google, it's been done before probably. Ben <u_stadler@yahoo.de> wrote in message news:1157722253.916953.60550@i42g2000cwa.googlegroups.com... > hi > > i just started to work with the microblaze processor and ethernet (i > hav the digilent spartan3e board) and it seems the the test programm i > compiled doesn't fit into the bram.. the warning i get is : > > Address Map for Processor microblaze_0 > (0x00000000-0x00003fff) dlmb_cntlr dlmb > (0x00000000-0x00003fff) ilmb_cntlr ilmb > (0x22000000-0x23ffffff) DDR_SDRAM_16Mx16 mb_opb > (0x40000000-0x4000ffff) LEDs_8Bit mb_opb > (0x40020000-0x4002ffff) DIP_Switches_4Bit mb_opb > (0x40040000-0x4004ffff) Buttons_4Bit mb_opb > (0x40600000-0x4060ffff) RS232_DCE mb_opb > (0x40c00000-0x40c0ffff) Ethernet_MAC mb_opb > (0x41400000-0x4140ffff) debug_module mb_opb > > Initializing Memory... > Checking ELFs associated with MICROBLAZE instance microblaze_0 for > overlap... > > > Analyzing file TestApp_Peripheral/executable.elf... > WARNING:MDT - Elf file TestApp_Peripheral/executable.elf does not > reside > completely within BRAM memory of processor microblaze_0. > WARNING:MDT - The sections of ELF residing outside BRAMs must be > initialized > separately using a debugger, a bootloader, or an ACE file > INFO:MDT - BRAM lmb_bram will be initialized with ELF of processor > microblaze_0 > Running Data2Mem with the following command: > data2mem -bm implementation/system_bd -bt implementation/system.bit > -bd > TestApp_Peripheral/executable.elf tag lmb_bram -o b > implementation/download.bit > > Memory Initialization completed successfully. > > > does this mean it worked?? > i don't get any output on the UART terminal. i do get an output with > the "testmem_app" though so uart should be working. > > can anybody help me here please? > does somebody also have some code snippets or tutorial how to send and > recieve data with the ethernet ip core that comes wit the edk? that > would be a great help! > thanks > > urban >Article: 108340
> - How do you detect that is doesn't start? : Test program is a hello world print onto the UART, sometimes there is nothing on the hyperterminal > - Are you using external memory? NO > - Can the program fit totally in the internal BRAM? YES, hello world is quite light when it's alone !!! > - What download cable are you using? JTAG DLC7 "Göran Bilski" <goran.bilski@xilinx.com> a écrit dans le message de news: edrjlu$9501@cliff.xsj.xilinx.com... > sjulhes wrote: >> Hello all, >> >> We are trying to design a small microblaze design in a spartan 3 and the >> problem we have is that the microblaze does not always start when the >> bitsream is downloaded with JTAG. >> >> But when we implement the debug module it always works. >> >> Does anyone has a clue ? >> Is it timing problems ? Is there specific timing constraints to add for >> microblaze ? >> Software problem ( linker script is automatically generated by edk)? >> >> Any idea is welcome. >> >> Thank you. >> >> Stéphane. > Hi, > > It's too little information to point out the what is wrong. > > - How do you detect that is doesn't start? > - Are you using external memory? > - Can the program fit totally in the internal BRAM? > - What download cable are you using? > > Göran BilskiArticle: 108341
Hi, I need to buy a Virtex4 FX12: XC4FX12-10FFG668C and a Spartan3: XC3S2000-4FGG676C >From Avnet it takes at least 8 weeks of lead time.Can anybody tell me were I can buy these part, with a shorter lead time please? Can sombody from Xilinx answer please? :-) Regards, FrancescoArticle: 108342
I am using virtes II pro pci card .The card has a pci bridge with a bus linking processor in the bridge to the fpga. The constraints on the processor bus signals were givent by the vendor. My design gives me a negative slack on 2 of the signals on the processor bus. Will this affect the design ? I am doing dma from the fpga to the host RAM along the bus. The transfer rate is low. I was googling for links to read on negative slacks but could not find good ones for a starter. Thanks, -DArticle: 108343
Francesco schrieb: > Hi, I need to buy a Virtex4 FX12: XC4FX12-10FFG668C and a Spartan3: > XC3S2000-4FGG676C > >From Avnet it takes at least 8 weeks of lead time.Can anybody tell me > were I can buy these part, with a shorter lead time please? > Can sombody from Xilinx answer please? :-) > > Regards, > Francesco Francesco, 8 weeks are pretty normal for any distributor. And there is nothing much for you to hope for unfortunatly. Xilinx cant help you, they will only say: "contact disti" - so you have to push the disti. for the Xilinx online web-shop to be re-opened I am afraid the chances are getting smaller and smaller as time is passing by since the close of the online shop. so your only could be if some company has overstocked or has the parts as overleft, but even so, I think it is not even legal for them to resell those parts to you. As parts purchased from Xilinx disties can not be resold. AnttiArticle: 108344
KJ wrote: >>Would be workable/advisable to instead just have each device >>control the ddr itself, and use the ddr's own interface directly? >> > > Probably not. Arbitration by nature needs 'global' knowledge of the scope > of what it is arbitrating in order to be effective: Some things needed are > - It needs to know about the 4 (or however many) users > - Preferred burst sizes for each port > - How long the other ports should wait while they're waiting for their turn > (i.e. how important is latency). > - Arbitration scheme (round robin, etc.) > KJ The arbitration is separate from the interface. Wishbone probably already has an arbitor capability built in, I'd guess. It's either USER <-> Arbitrator <-> Wishbone <-> DDR or USER <-> Arbitrator <-> DDR Actually the arbitration logic is not really *in* the chain, it just selectively allows the USER to access the next stage on the other side. It's critical that bursts be handled well. DDR effectively has a minimum burst of 2, and the 2 addresses are always at A and A+1. Probably A is even also, but I don't remember at the moment. Also a burst within DDR can't cross a row. Then there is arbitrary CAS latency. Wishbone supports bursting, but there probably aren't any restrictions. That is, bursts probably don't need to start on an even address, and they don't have to end before they cross some arbitrary boundary. But I can easily make the 4 users of the DDR work within the DDR's limitations. They can also take full advantage of the DDR's capabilities. With the wishbone approach I get a generic piece of logic I can reuse with other DDR's. But at what cost? Complications: 1) To support bursting, it needs to have some sort of fifo. An easy way would be the core stores up the whole burst, then transacts it to the DDR when all is known. But to reduce latency, the DDR transaction probably ought to start while the USER is still pushing data into the wishbone interface. The whole goal is to get as close to 2 memory accesses per clock, since that's what DDR supports. 2) The wishbone core must deal with page crossing bursts somehow. This would mean breaking up a burst into 2 ddr bursts. Otherwise if I impose address/burst restrictions on the wishbone core, it's not 100% compliant, I'd expect. 3) The wishbone core must deal with the even/odd address limitations, otherwise it's not 100% compliant, I expect. The disadvantages of involving wishbone are 1) More complicated, more work, later time to market 2) Almost certainly will introduce latency in pipeline 3) To implement, I've got to learn wishbone AND ddr, as opposed to just ddr now and perhaps wishbone at a later date. The advantages are 1) Single logic driving DDR pins, so supposedly clock timing can be met easier. 2) More general for code reuse, since lots of things already support wishbone. Also of note that the end result of all this is a system meant to be released as open source. That's why if I were going to use wishbone I'd feel compelled to do it right. Anyway it still isn't clear to me the wishbone approach is automatically right for this particular application. Thanks for everyone's input on this so far. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108345
u_stadler@yahoo.de wrote: > hi > > i just started to work with the microblaze processor and ethernet (i > hav the digilent spartan3e board) and it seems the the test programm i > compiled doesn't fit into the bram.. the warning i get is : > > Address Map for Processor microblaze_0 > (0x00000000-0x00003fff) dlmb_cntlr dlmb > (0x00000000-0x00003fff) ilmb_cntlr ilmb > (0x22000000-0x23ffffff) DDR_SDRAM_16Mx16 mb_opb > (0x40000000-0x4000ffff) LEDs_8Bit mb_opb > (0x40020000-0x4002ffff) DIP_Switches_4Bit mb_opb > (0x40040000-0x4004ffff) Buttons_4Bit mb_opb > (0x40600000-0x4060ffff) RS232_DCE mb_opb > (0x40c00000-0x40c0ffff) Ethernet_MAC mb_opb > (0x41400000-0x4140ffff) debug_module mb_opb > > Initializing Memory... > Checking ELFs associated with MICROBLAZE instance microblaze_0 for > overlap... > > > Analyzing file TestApp_Peripheral/executable.elf... > WARNING:MDT - Elf file TestApp_Peripheral/executable.elf does not > reside > completely within BRAM memory of processor microblaze_0. > WARNING:MDT - The sections of ELF residing outside BRAMs must be > initialized > separately using a debugger, a bootloader, or an ACE file > INFO:MDT - BRAM lmb_bram will be initialized with ELF of processor > microblaze_0 > Running Data2Mem with the following command: > data2mem -bm implementation/system_bd -bt implementation/system.bit > -bd > TestApp_Peripheral/executable.elf tag lmb_bram -o b > implementation/download.bit > > Memory Initialization completed successfully. > > > does this mean it worked?? > i don't get any output on the UART terminal. i do get an output with > the "testmem_app" though so uart should be working. > > can anybody help me here please? > does somebody also have some code snippets or tutorial how to send and > recieve data with the ethernet ip core that comes wit the edk? that > would be a great help! > thanks > > urban > Urban, I'm not sure but this sounds similiar to problems I've had before with the EDK + ppc development. As I recall you ought to go and generate a custom linker script, then make sure each and every one of the code sections for the ELF executable are set to load into the boot BRAM memory region. It doesn't seem to automatically do this. Find your ELF executable binary that is built and supposed to be loaded into the BRAM, and try doing an "objdump" on it, you can see where the sections are getting loaded. They should all be in the same region, which is your small boot BRAM. I think often they put code in one place and data somewhere else... Regarding the edk, if you use the wizard to set up your design I think it offers the option of creating 2 applications, one is a simple memory test, the other tests all the peripherals. It tests the ethernet ip core if you've included that. I think it just does a simple loopback test but I don't remember for sure... Hope this helped... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108346
Antti, Parts can be resold: if I bought too many, and I don't need them, there are reputable resellers who buy overstock, and resell. After all, once I buy the parts, they are mine, they do not somehow still belong to Xilinx...no one is breaking any 'laws' here. Happens all the time (unfortunately). What Xilinx does not do is offer support to companies who have parts purchased through resellers (as it detracts from the distributors, and it is impossible for us to warranty product when it has passed through a reseller). Now, "not offering support" does not mean that you can not file a webcase. We are not going to check a part's pedigree for a webcase (unless it runs out that the part has been mis-marked, or mishandled -- see below). What it means is that if there is an issue with one of these resold parts, we do not honor the warranty, as the parts have passed out of the accepted 'chain of control'. Something as simple as parts being unpacked, allowed to absorb moisture, and then sent off to a reseller, who then sends them to some poor user, who then assembles them without a proper re-bake, and has the packages "blow up" due to the water turning to steam in the solder reflow process is what we are concerned with, and what we have seen There are other issues with ESD, and other items that often can go wrong when parts are not handled properly. I am sure if Francesco has enough friends, he might find a few parts to help him out? But to kit a full production run may be a tough thing to do on a moment's notice. And, if you do get parts from a reseller, assume they need a full re-bake, regardless of how "well" they are packaged. You may want to test them before you use them, too. (Even if you get them from your friends....) There are (bad) people out there who remark good parts (up the speed grade) so they can make more money, and also folks who take parts that are not even our FPGAs, and remark them as Xilinx FPGAs. So in general, unless you have had a successful history with a reseller, Caveat Emptor! AustinArticle: 108347
Frithiof Andreas Jensen wrote: > > "Michael A. Terrell" <mike.terrell@earthlink.net> wrote in message > news:44FB18BC.CED74990@earthlink.net... > > > I got stuck working the overtime because the idiot ordered the > wrong > > piece of equipment for a CATV headend. he insisted that Jerrold, > > (General Instruments) didn't know what they were talking about, and > that > > our 10,000 cable converters were already tuned to the channel he > > ordered. They weren't, and the jackass refused to change the order, > so > > I had to modify 10,000 pieces of equipment instead. > > No, you did not *have* to do that: > > You chose to bail the arsehole out so he will be there to screw up in > the future - and - said person being a jackass will not even be buying > you beer for it too. Counterproductive! It was either do the work or be fired. I didn't do it to help him, in any way. I needed the job, because there was nothing else available in my field at the time. The only open job I could find was chief engineer at WRGT TV, Ch 45 in Dayton, Ohio which was an even longer drive. They were only offering minimum wage for a 40 hour a week salary, and you would be on call 24/7. They also demanded that I live no more than 2 miles from the studio and transmitter sites which didn't have any reasonably priced homes. Would you take a loss on the sale of your home and buy one at five times the price, while taking a 70% cut in pay? I couldn't, and I didn't. I just suffered though another of his messes, and made a lot in overtime. -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 108348
Austin Lesea wrote: >... > First comes CMOS, then comes DRAM, and finally comes flash. Even the > sequence of arrivals of the flavors of each technology node is > completely pre-ordained. Sounds like conspiracy theory :). I'd guess the driving force is the market. Technology avenues are always opening up. Which ones get pursued? Only the ones that have a good chance of getting widely adopted. A technology or fab process that is only applicable to one very specific problem...probably won't become mainstream. Xilinx probably doesn't do its own fabrication, which means they need to work within the system. BTW what's next on the roadmap? What stocks should I invest in now? :) -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108349
Austin Lesea schrieb: > Antti, > > Parts can be resold: if I bought too many, and I don't need them, there > are reputable resellers who buy overstock, and resell. After all, once > I buy the parts, they are mine, they do not somehow still belong to > Xilinx...no one is breaking any 'laws' here. Happens all the time > (unfortunately). > > What Xilinx does not do is offer support to companies who have parts > purchased through resellers (as it detracts from the distributors, and > it is impossible for us to warranty product when it has passed through a > reseller). > > Now, "not offering support" does not mean that you can not file a > webcase. We are not going to check a part's pedigree for a webcase > (unless it runs out that the part has been mis-marked, or mishandled -- > see below). What it means is that if there is an issue with one of > these resold parts, we do not honor the warranty, as the parts have > passed out of the accepted 'chain of control'. > > Something as simple as parts being unpacked, allowed to absorb moisture, > and then sent off to a reseller, who then sends them to some poor user, > who then assembles them without a proper re-bake, and has the packages > "blow up" due to the water turning to steam in the solder reflow process > is what we are concerned with, and what we have seen There are other > issues with ESD, and other items that often can go wrong when parts are > not handled properly. > > I am sure if Francesco has enough friends, he might find a few parts to > help him out? But to kit a full production run may be a tough thing to > do on a moment's notice. > > And, if you do get parts from a reseller, assume they need a full > re-bake, regardless of how "well" they are packaged. You may want to > test them before you use them, too. > > (Even if you get them from your friends....) > > There are (bad) people out there who remark good parts (up the speed > grade) so they can make more money, and also folks who take parts that > are not even our FPGAs, and remark them as Xilinx FPGAs. So in general, > unless you have had a successful history with a reseller, Caveat Emptor! > > Austin Austin, just short comment to your post - careful here: to what I know buying from Avnet and simply reselling the IC's will get you into trouble. It's not related to Xilinx anyhow. But there have been cases where entities bying from disties have sold below the disti prices - and you can imagine that want make the disties very happy. I dont have the 'fine print' handy but I am relativly sure there is something that at least tries to prevent that parts purchased from disti are only purchased for re-re-sale. Sure if you have some parts overstocked and have sold them once then it's still ok. Antti
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z