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
"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> schrieb im Newsbeitrag news:eaampt$pvr$1@sunnews.cern.ch... > Hi everyone, (especially those Xilinx chaps) :-) > > I've been having an interesting debate with a colleague here, regarding > Virtex 4 Rocket IO (and Virtex II for that matter). The challenge is to > make a really high speed signal sampler in the fabric of one of these > FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s > > We figure using a local clock of 100M, should be mutiplied by 20 inside > the rocket IO, giving 20 bits per 100M period that can be shuffled to get > some indication of the input waveform. i.e. a 2G sampler. > > Ok, ignoring the hugely important fact that FPGA has to be able to process > this, and that the PCB has to be well designed, and that the input signal > might have some new frequency and electrical constraints, are there any > pitfalls we've missed? btw: the idea comes from an expansion Figure-7 of: > http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF > > Are there any potential flaws in these ideas anyone can see? > > Thanks in advance, > Ben Hi Ben, I think its almost 2 years now from when I posted some screenshots about the use or MGTs as 3GB/s sampler. The demo displayed the USB HS test pattern captured with MGT its nothing new. AnttiArticle: 105626
Ben, The problem with using the MGT receiver as a sampler, is that it wants to "recover" the embedded clock signal in the data. If you can gain access to the input sliced data, after it has been clocked into the serial to parallel converter, the only question is: "what was the clock to the serial to parallel shift register?" Look at page 34 of http://direct.xilinx.com/bvdocs/userguides/ug076.pdf The receiver depends on recovery of an input clock to then shift/transfer/unscramble/decode the received data. The paths are all there to bypass the 8B10B, etc. but how to you solve the chicken and egg problem of no clock -- no data? Page 68 discusses the receiver clock options, and if the receiver can't or won't lock to the sampled data based on the clock reference, then I think the serial recovered clock is just a multiple of the refclk as you describe. But the receiver "knows" it has no lock, and how does this affect the rest of the operation? Austin Benjamin Todd wrote: > Hi everyone, (especially those Xilinx chaps) :-) > > I've been having an interesting debate with a colleague here, regarding > Virtex 4 Rocket IO (and Virtex II for that matter). The challenge is to > make a really high speed signal sampler in the fabric of one of these FPGAs > by using the Rocket IO in a custom manner. I'm talking some GS/s > > We figure using a local clock of 100M, should be mutiplied by 20 inside the > rocket IO, giving 20 bits per 100M period that can be shuffled to get some > indication of the input waveform. i.e. a 2G sampler. > > Ok, ignoring the hugely important fact that FPGA has to be able to process > this, and that the PCB has to be well designed, and that the input signal > might have some new frequency and electrical constraints, are there any > pitfalls we've missed? btw: the idea comes from an expansion Figure-7 of: > http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF > > Are there any potential flaws in these ideas anyone can see? > > Thanks in advance, > Ben > >Article: 105627
Antti, Does not locking to the data affect its operation? What if it tries to lock to the data? What if it can't lock to the data? Austin Antti Lukats wrote: > "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> > schrieb im Newsbeitrag news:eaampt$pvr$1@sunnews.cern.ch... >> Hi everyone, (especially those Xilinx chaps) :-) >> >> I've been having an interesting debate with a colleague here, regarding >> Virtex 4 Rocket IO (and Virtex II for that matter). The challenge is to >> make a really high speed signal sampler in the fabric of one of these >> FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s >> >> We figure using a local clock of 100M, should be mutiplied by 20 inside >> the rocket IO, giving 20 bits per 100M period that can be shuffled to get >> some indication of the input waveform. i.e. a 2G sampler. >> >> Ok, ignoring the hugely important fact that FPGA has to be able to process >> this, and that the PCB has to be well designed, and that the input signal >> might have some new frequency and electrical constraints, are there any >> pitfalls we've missed? btw: the idea comes from an expansion Figure-7 of: >> http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF >> >> Are there any potential flaws in these ideas anyone can see? >> >> Thanks in advance, >> Ben > Hi Ben, > > I think its almost 2 years now from when I posted some screenshots about the > use or MGTs as 3GB/s sampler. > The demo displayed the USB HS test pattern captured with MGT > > its nothing new. > > Antti > > >Article: 105628
PROBLEM: CPU memory bus is routed into FPGA, where memory-mapped registers are needed for accessing soft perhipherals. Memory bus is asynchronouse (i.e. EMIF). I would create a table of registers, where the following parameters can be specified for each register. REGISTER NAME WIDTH OFFSET FROM BASE ADDRESS ACCESS TYPE: R, W, R/W INTERNAL CLOCK NAME (assume bus I/F is async to this clock) WRITE STROBE GEN (sync'd to INTERNAL clock) READ STROBE GEN (sync'd to INTERNAL clock) These register table would be the input to a code generator script/program which would output a VHDL file that has the bus interface on one side and the register in/out/sync signals on the back side. I did something like this quite a few years ago, where the table was generated in MS Excel and the VHDL code generator was written in VBA for a serial (SPI-like) bus. I could modify this, but I wondered if anyone knew of some script/code in the public domain which already does this. I would prefer something in perl, but any language would be acceptable. If this doesn't exist, would anyone be interested in such a code generation tool. I'm more of a software hack, so my code isn't very pretty or pure. But, it works and is reasonably commented. TIA UrbArticle: 105629
If you can live with "just" 2GSPS, that can be done in a virtex2 or above with a little known, regular IOB function called the ibufds_diff_out. With it, a single differential pair input can feed two DDR input registers (one of them gets an inverted signal). If you use two 500 MHz clocks in quadrature (generated by the DCM), you get up to 2 GSPS sampling. If you're in a v4 or above, the iserdes blocks can demultiplex that down to a reasonable rate before it even hits the fabric. In a v5, you could get up to 2.2 GSPS. That way you can use FPGAs that don't have rocket-io (and are thus cheaper). Andy Antti Lukats wrote: > "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> > schrieb im Newsbeitrag news:eaampt$pvr$1@sunnews.cern.ch... > > Hi everyone, (especially those Xilinx chaps) :-) > > > > I've been having an interesting debate with a colleague here, regarding > > Virtex 4 Rocket IO (and Virtex II for that matter). The challenge is to > > make a really high speed signal sampler in the fabric of one of these > > FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s > > > > We figure using a local clock of 100M, should be mutiplied by 20 inside > > the rocket IO, giving 20 bits per 100M period that can be shuffled to get > > some indication of the input waveform. i.e. a 2G sampler. > > > > Ok, ignoring the hugely important fact that FPGA has to be able to process > > this, and that the PCB has to be well designed, and that the input signal > > might have some new frequency and electrical constraints, are there any > > pitfalls we've missed? btw: the idea comes from an expansion Figure-7 of: > > http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF > > > > Are there any potential flaws in these ideas anyone can see? > > > > Thanks in advance, > > Ben > Hi Ben, > > I think its almost 2 years now from when I posted some screenshots about the > use or MGTs as 3GB/s sampler. > The demo displayed the USB HS test pattern captured with MGT > > its nothing new. > > AnttiArticle: 105630
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:eaaru5$gks2@xco-news.xilinx.com... > Antti, > > Does not locking to the data affect its operation? What if it tries to > lock to the data? What if it can't lock to the data? > > Austin Hi Austin, the MGTs can actually be used as simple 20 bit serial to parallel shift register :) I did no tricks, and I did not see any misbehavior related to CDR locking attempts so the all thing was mgt in bypass mode connected to 20 chipscope ILA controlled by custom application that collected the data and dsiplayed it in correctly the rocketio input was just parallel attach to USB HS link as passive monitor the MGT sampling clock was not any direct multiply of the USB data rate as of my results I can say that an USB HS receive only PHY can be made with rokectio that would make a real nice usb analyzer with 3GS/s time granularity. sure the phy would be somewhat tricky to make, but possible. AnttiArticle: 105631
"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message news:87d5bqopve.fsf@gustad.com... > > I used guided par a lot around 2001 with Alliance 3.1i around 2001. It > saved me a lot of time as you can see in > > http://tinyurl.com/kv3al > > However it appears that things have changed a bit since then... > > Petter Guided place & route worked fabulously back in the schematic entry days (pre 1995 for me). Small changes would re-route in seconds on designs that would take hours for a full place & route. The migration to HDL design and synthesis seems to have made guided routes totally ineffective, although I'm not sure why. Or it may have to do with the "new" Xilinx tools (par, map, etc.) that they originally acquired from NeoCAD back in 1995. I only ever used guided routes with the "old" tools (ppr, etc.). Anyone who still uses schematic entry had any luck using guided routes with the current ISE tools? RobArticle: 105632
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:eaar1q$gks1@xco-news.xilinx.com... > Ben, > > The problem with using the MGT receiver as a sampler, is that it wants > to "recover" the embedded clock signal in the data. > > If you can gain access to the input sliced data, after it has been > clocked into the serial to parallel converter, the only question is: > "what was the clock to the serial to parallel shift register?" > > Look at page 34 of > http://direct.xilinx.com/bvdocs/userguides/ug076.pdf > > The receiver depends on recovery of an input clock to then > shift/transfer/unscramble/decode the received data. > > The paths are all there to bypass the 8B10B, etc. but how to you solve > the chicken and egg problem of no clock -- no data? hm, look here.. http://www.xilant.com/downloads/csp.pdf page 9 :) rocketIO useage as high speed sampler (USB HS 480MBit/s data rate input) AnttiArticle: 105633
"Brannon" <brannonking@yahoo.com> writes: > > I was wondering if anyone had succeded in saving time by using guided > > MAP/PAR. I personally find that every time I want to use it, even in the > > most obvious cases when 99.9% of design hasn't changed, I then have to > > re-run everything from scratch anyway... > > 80% of the times I ran it, it crashed. The other 20% of the time it > took longer than running without it. That includes all versions from I used guided par a lot around 2001 with Alliance 3.1i around 2001. It saved me a lot of time as you can see in http://tinyurl.com/kv3al However it appears that things have changed a bit since then... Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 105634
>From some documentation I'm following from Memec. 1. Device Configuration > Download Bitstream (Download a simple Memory Test Project) I can't find it in the documentation at the moment, but I though I read it somewhere that you need to have something initialized in the bram before loading to flash? (this is the reason for this step) I am fairly new to this stuff, so this step may not be needed. 2. Device Configuration > Program Flash Memory a. File to Program = your .elf file b. check the auto cover file to bootable SREC format c. Flash Mem. Properties Instance name = Flash base address d. Scratch Mem. Properties Instance name = DDR base address e. check to creat a flash bootloader application f. click program flash! then ok. 3. You should see a bootloader project come up in your projects window. 4. Make sure your flash is downloaded succesfully. 5. Uncheck your Memory test to be initialized in the bram. 6. Check the bootloader app to be initialized in the bram. 7. Device Configuration > Download Bitstream! Well I'm about to try this. If anything is incorrect someone please correct me! Thanks for your time.Article: 105635
Antti, I am impressed it was that simple. I would have thought that the CDR trying to lock would add too much jitter, but then, who cares? You are just sampling, and sampling is always +/- one bit anyway. Austin Antti Lukats wrote: > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:eaar1q$gks1@xco-news.xilinx.com... >> Ben, >> >> The problem with using the MGT receiver as a sampler, is that it wants >> to "recover" the embedded clock signal in the data. >> >> If you can gain access to the input sliced data, after it has been >> clocked into the serial to parallel converter, the only question is: >> "what was the clock to the serial to parallel shift register?" >> >> Look at page 34 of >> http://direct.xilinx.com/bvdocs/userguides/ug076.pdf >> >> The receiver depends on recovery of an input clock to then >> shift/transfer/unscramble/decode the received data. >> >> The paths are all there to bypass the 8B10B, etc. but how to you solve >> the chicken and egg problem of no clock -- no data? > > hm, > > look here.. > > http://www.xilant.com/downloads/csp.pdf > > page 9 :) > > rocketIO useage as high speed sampler (USB HS 480MBit/s data rate input) > > Antti > >Article: 105636
Hi Brannon, I want to buy a book on JPEG, what books do you recommend? itu-t81.pdf is 176 pages and it is too long. I know Huffman encoding, and it encodes and decodes data based on appearance frequency of keywords. I just want to know what generates appearance frequency of keywords in JPEG algorithm. Thank you. Weng Brannon wrote: > Weng Tianxiang wrote: > > Hi Brannon, > > Can you explain further about a full huffman analysis for JPEG? > > > > I have no any knowledge about JPEG and what books you recommend about > > the topics? > > Google this: "MIL-STD-188-198A" > > and Google this: "itu-t81.pdf" > > Those are two fundamental JPEG documents. There is one nice book on the > topic I've seen, but I don't have a copy handy. If you can understand > the above two documents, you won't need it. It has a pink cover. And if > you don't know what Huffman encoding is, you had better Google that one > as well.Article: 105637
> I can't find it in the documentation at the moment, but > I though I read it somewhere that you need to have something > initialized in the bram before loading to flash? (this is the reason > for this step) I am fairly new to this stuff, so this step may not be > needed. I couldn't find it in the doc. I was reading (anyways) because it's on the Program Flash Mem. window down at the bottom. Must have an EMC peripheral connected to the flash prior to flash download! EMC?Article: 105638
raso wrote: >>>More or less. Wait a tick. Look at the data sheet of the 74xx297, it >>>says the lock range (pull range) of the PLL is >>>delta_f_max = fc * M / (2*K*N ) >>>using your values >>>delta_f_max = 50 Hz * 600000 / (2* 300000 * 40) = 1.25 Hz >>>Hmm, this should be enought. > > > I/D counter is a 2 divider. In locked condition, its output is 30MHz/2 > = 15MHz. > Therefore, in addition to N=40 divider, I have to use an f_out > prescalar (=7500). In > this case : > > delta_f_max = fc * M / (2*K*N*f_out_prescalar ) > delta_f_max = 50 Hz * 600000 / (2* 300000 * 40 * 7500) = 1.25/7500 Hz > > Is this correct? It depends where your add/swallow is done. Another way to figure the range, is that every phase compare, can generate one add/swallow. If you do it at 2KHz, then the 1.25Hz is 50Hz/40. If you do it at 2KHz x 7500, then yes, lock range is less. Note also that with a low 50Hz Fout, there will be a finite phase-skew rate in these add/swallow schemes, that will give long lock times. eg 50Hz to 0.5Hz is a "1 pulse in 100" area, which gives > 2 second lock times. [the simplest phase detectors can give 'go the wrong way' output, so the actual lock time will be longer - a frequency detector will lock faster] Might be a problem in many systems ? You should define your jitter ceilings, and work from that as all pure-digital methods have some jitter, or step size. -jgArticle: 105639
Do you want a 2GS/s sampler of 2GB/s data or do you just want high resolution of a lower speed signal? I'm getting a minimum of 9 GS/s in a Spartan3E for a 600 MB/s signal (the sample rate isn't set as much as detected). Depending on requirements, there are alternatives to RocketIO. See also XAPP671 http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> wrote in message news:eaampt$pvr$1@sunnews.cern.ch... > Hi everyone, (especially those Xilinx chaps) :-) > > I've been having an interesting debate with a colleague here, regarding > Virtex 4 Rocket IO (and Virtex II for that matter). The challenge is to > make a really high speed signal sampler in the fabric of one of these > FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s > > We figure using a local clock of 100M, should be mutiplied by 20 inside > the rocket IO, giving 20 bits per 100M period that can be shuffled to get > some indication of the input waveform. i.e. a 2G sampler. > > Ok, ignoring the hugely important fact that FPGA has to be able to process > this, and that the PCB has to be well designed, and that the input signal > might have some new frequency and electrical constraints, are there any > pitfalls we've missed? btw: the idea comes from an expansion Figure-7 of: > http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF > > Are there any potential flaws in these ideas anyone can see? > > Thanks in advance, > Ben >Article: 105640
I recently traveled to another company to try to debug the company's hardware that they were building for us. The hardware consists of a CPU and a large CPLD, etc. I wrote all of the firmware code and much of the test code, and had identified hardware failures on earlier boards. Anyway, I didn't have to pay a thing for the airline flights, hotel, or rental car. However, when I asked if I was getting paid for my time spent traveling (~ 12 hours in airports/airplanes). I was told that was not normally done. BTW I eventually did get my company to pay for my travel time, so I am content. But, is paying for travel time standard practice or not? -Dave PArticle: 105641
Just checked. I think they are ok ... 4 MGTs on the top use TOP_BREF_CLK (pins B14 and C14) and 4 MGTs on the bottom row use BOTTOM_BREF_CLK2 (pins AE13 and AD13) The same code works for a ML310 board, so I'm guessing there some specific board related issue. Any tips? Thanks, Billu Falk Brunner wrote: > billu schrieb: > > > I'm trying to create a serial link operating at 2.5Gbps or higher using > > all 8 MGTs on the ML321 board. I modified a code that was used to > > create a 8 MGT link on a ML310 board. (Changed the MGT,Phase align, > > I keep getting these errors while trying to place & route in ISE: > > > > ERROR:Place:482 - Bref comp BOTTOM_BREF_CLK_P locked incorrectly. Has > > to be PAD41 or PAD237 > > ERROR:Place:482 - Bref comp BOTTOM_BREF_CLK_P locked incorrectly. Has > > to be PAD41 or PAD237 > > ERROR:Place:482 - Bref comp BOTTOM_BREF_CLK_P locked incorrectly. Has > > to be PAD41 or PAD237 > > ERROR:Place:482 - Bref comp BOTTOM_BREF_CLK_P locked incorrectly. Has > > to be PAD41 or PAD237 > > > > I've checked to make sure that clock & MGTs are defined correctly in > > the ucf file, and referenced appropriately in the verilog code. The > > code seems to work on the ML310 board. Any ideas on what could cause > > such an error and how I can fix it? > > Looks like you mixed up the top/botton MGTs and the corresponding > BREF_CLKs. Remember, those are very dedicaded low jitter clocks with > very resticted conectivity. > Check again. > > Regards > FalkArticle: 105642
Dave Pollum wrote:
> BTW I eventually did get my company to pay for my travel time, so I am
> content. But, is paying for travel time standard practice or not?
I normally pay everything on my own card
and file an expense report to get a refund.
Salary is the same in the cube or on a plane.
-- Mike Treseler
Article: 105643Hello Rob, I am very proud to say I still do some FPGA design work with ViewDraw (oops, I meant DxDesigner...) I have had good luck with exact guide mode in PAR using all ISE tool versions since version 2.1 when using netlists from a schematic tool. There is something to be said for the excruciating level of control you have over the netlist instance and net names when you work with a schematic. When I have needed this level of control, I found the use of guide in MAP unnecessary... If you consider the circuit of interest -- and you know all the instance and net names -- you simply apply LOC and BEL constraints to nail everything down. This not only fully places everything, but dictates the SLICE packing (and as a side effect, the SLICE instance names) for MAP. There's no "wiggle room" and no need to ask MAP to guide anything. Then you can just use exact guide in PAR. There is a relatively new mechanism to achieve the same end result, called directed routing constraints. I find this very appealing; you can open a placed and routed design in FPGA Editor, select a net, and click an option to get a directed routing constraint in addition to all of the LOC and BEL constraints for the instances attached to it. It works well and my favorite thing about it is that you put the DIRT constraint into the UCF file, it's all text-based. For HDL designs, I am sure all of this is frustrating. I haven't had to do it, but based on my experience with schematic designs, I would say that if you require exact guide to deliver a specific, repeatable result -- you really have to design for it up front in what will become non-portable HDL. If you leave it up to chance, it often may help timing closure during place and route but that's gambling, a design technique I do not endorse! Sometimes you win, sometimes you lose. Incidentally -- things like core dumps, hangs, and crashes are NEVER an expected termination for any vendor's tools. If anyone ever experiences this with Xilinx tools, please let us know by opening a webcase. I know it's asking a favor -- seriously, who has time -- but we greatly appreciate this information especially if you can provide your design files so we can reproduce and debug the error. Thanks, Eric "RobJ" <rob@abc.net> wrote in message news:_c7yg.25554$Z67.20356@tornado.socal.rr.com... > Guided place & route worked fabulously back in the schematic entry days (pre > 1995 for me). Small changes would re-route in seconds on designs that would > take hours for a full place & route. The migration to HDL design and > synthesis seems to have made guided routes totally ineffective, although I'm > not sure why. Or it may have to do with the "new" Xilinx tools (par, map, > etc.) that they originally acquired from NeoCAD back in 1995. I only ever > used guided routes with the "old" tools (ppr, etc.). > > Anyone who still uses schematic entry had any luck using guided routes with > the current ISE tools?Article: 105644
>
>hi mikhail,
my problem is solved, itz not the problem with my code. The
componet which iam adding (i.e inverter.vhd) synthesize this file before
adding to user_logic.vhd file,so that it will generate edif or ngc files
known as netlist files,that can be used in synthesis. After doing this
right click on the inverter.vhd file and click the option 'move to surce'
add it to ur core.
Then it works fine!
regards
gary
Article: 105645Dave, If you are expected to travel as part of your job (field service engineer, marketing job, vice president..) then no, you get no pay for the time you spent traveling. You do get paid a salary, which is usually expected to amount to working a 40 hour week. If you are a consultant, then you set your own rules. Up to you if you charge or not. Makes sense to charge, as you are not going to be able to do work for anyone else while flying to Tokyo! If you are a lawyer, you typically get paid for travel time. If your job normally doesn't require travel, then perhaps you can negotiate with your boss, although I don't hear about anyone ever getting paid for travel time. You might get "comp" time which is the ability to take some time off without using up any vacation days. Austin Dave Pollum wrote: > I recently traveled to another company to try to debug the company's > hardware that they were building for us. The hardware consists of a > CPU and a large CPLD, etc. I wrote all of the firmware code and much of > the test code, and had identified hardware failures on earlier boards. > Anyway, I didn't have to pay a thing for the airline flights, hotel, or > rental car. However, when I asked if I was getting paid for my time > spent traveling (~ 12 hours in airports/airplanes). I was told that was > not normally done. > BTW I eventually did get my company to pay for my travel time, so I am > content. But, is paying for travel time standard practice or not? > > -Dave P >Article: 105646
For some of us who are salaried, exempt, it's common to travel on a workday and get paid for the workday. As salaried, exempt, there is no overtime but if you feel strongly about it, often a little "comp time" can make up for it. If travel is on a Saturday, it's still part of the salaried, exempt workweek. I try not to travel on the weekends. "Dave Pollum" <vze24h5m@verizon.net> wrote in message news:1154031435.955245.100680@b28g2000cwb.googlegroups.com... >I recently traveled to another company to try to debug the company's > hardware that they were building for us. The hardware consists of a > CPU and a large CPLD, etc. I wrote all of the firmware code and much of > the test code, and had identified hardware failures on earlier boards. > Anyway, I didn't have to pay a thing for the airline flights, hotel, or > rental car. However, when I asked if I was getting paid for my time > spent traveling (~ 12 hours in airports/airplanes). I was told that was > not normally done. > BTW I eventually did get my company to pay for my travel time, so I am > content. But, is paying for travel time standard practice or not? > > -Dave PArticle: 105647
Eric, > Incidentally -- things like core dumps, hangs, and crashes are NEVER an > expected termination for any vendor's tools. If anyone ever experiences > this with Xilinx tools, please let us know by opening a webcase. I know > it's asking a favor -- seriously, who has time -- but we greatly appreciate > this information especially if you can provide your design files so we can > reproduce and debug the error. I can't believe you need webcases for this. Take any big design, e.g. GSRD and start playing with it. The tools are guaranteed to crash in a matter of hours. We see all kinds of things all the time. If I opened a case for every mystery I have to resolve here it would be a full-time job. One of the recent problems of today was disappearing check marks in EDK memory map view with which we are supposed to be able to lock memory spaces. The problem was tracked down to corrupted xmp file, which I was able to fix by manual editing despite the warning advising against it (#Please do not modify this file by hand). /MikhailArticle: 105648
Dave Pollum wrote: > I recently traveled to another company to try to debug the company's > hardware that they were building for us. The hardware consists of a > CPU and a large CPLD, etc. I wrote all of the firmware code and much of > the test code, and had identified hardware failures on earlier boards. > Anyway, I didn't have to pay a thing for the airline flights, hotel, or > rental car. However, when I asked if I was getting paid for my time > spent traveling (~ 12 hours in airports/airplanes). I was told that was > not normally done. > BTW I eventually did get my company to pay for my travel time, so I am > content. But, is paying for travel time standard practice or not? > > -Dave P > What does your contract say? Doesn't matter much what other people get paid, what matters is what you (or your company) agreed to.Article: 105649
MM wrote: > Eric, > > >>Incidentally -- things like core dumps, hangs, and crashes are NEVER an >>expected termination for any vendor's tools. If anyone ever experiences >>this with Xilinx tools, please let us know by opening a webcase. I know >>it's asking a favor -- seriously, who has time -- but we greatly > > appreciate > >>this information especially if you can provide your design files so we can >>reproduce and debug the error. > > > I can't believe you need webcases for this. Take any big design, e.g. GSRD > and start playing with it. The tools are guaranteed to crash in a matter of > hours. We see all kinds of things all the time. If I opened a case for every > mystery I have to resolve here it would be a full-time job. One of the > recent problems of today was disappearing check marks in EDK memory map view > with which we are supposed to be able to lock memory spaces. The problem was > tracked down to corrupted xmp file, which I was able to fix by manual > editing despite the warning advising against it (#Please do not modify this > file by hand). Then you would love for that to have been a Binary file !! [ Another argument against binary files.. ] -jg
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