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 Apr 17, 1:04 pm, "Symon" <symon_bre...@hotmail.com> wrote: > Dave wrote: > > Does anybody out there have a good methodology for determining your > > optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? > > The brute force method is fairly maddening. I'd be curious to hear if > > anybody has any 'tricks of the trade' here. > > > Also, just out of curiosity, how many of you do your own PCB layout, > > versus farming it out? It would certainly save us a lot of money to > > buy the tools and do it ourselves, but it seems like laying out a > > board out well requires quite a bit of experience, especially a 6-8 > > layer board with high pin count FPGA's. > > > We're just setting up a hardware shop here, and although I've been > > doing FPGA and board schematics design for a while, it's always been > > at a larger company with resources to farm the layout out, and we > > never did anything high-speed to really worry about the board layout > > too much. Thanks in advance for your opinions. > > > Dave > > Hi Dave, > I layout my own PCBs. Unlike Mike T., I don't let the FPGA tools pick the > pinout. That said, it is important to consider carefully consider nets which > might have tight timing, e.g. clocks. I reason that there is a lot more > flexibility in the FPGA routing than on my PCB, and it's cheaper, so I can > save most time and money by being flexible in the pinout. I set the banks > the nets are to go on, and firm up the detailed pinout by swapping pins on > the FPGAs banks during the PCB layout process. You need some experience in > what your HDL code is gonna look like to be able to do this, but there you > go. > If you are adept at FPGA work, you'll find learning a PCB layout tool is a > piece of cake. I also use laser drilled microvias from layer 1 to 2, which > make the layout of big BGAs easier and saves layers. SI is easier also. The > price is usually less this way; the layers outweigh the via expense. You > don't need buried vias, IME. > Some of my FPGA buddies and I have had bad experiences with contract PCB > people. Sometimes they are knowledgeable and talented, but sometimes they > are dogmatic idiots, and sometimes they are useless. If you go the contract > route, it's important to closely monitor what they get up to so you find out > early doors which type they are. > Like you and Mike say, it depends a lot on your experience. If you've worked > closely with your layout guys in the past, that'll be a big help to you. > For sure, there's more than one way to skin a cat, but I enjoy PCB layout. > YMMV, good luck with it. > Cheers, Syms. > p.s. One benefit to laying out the PCB yourself is that it can help you spot > stupid mistakes in the circuit as you go. It forces you to look very closely > at the layout. Depending on your PCB layout (and schematic capture) tools' capabilities for defining constraints on pin swappability, you can develop symbols that constrain IO pin swapping to meet the needs of the design and/or FPGA. For example, we have symbols for FPGA's that limit IO pin swapping to the same bank and other banks powered from the same voltage rail. We lock down critical pins (global clock inputs, etc.) and we have to "seed" the banks with their voltage assignments, but after that, we are often able to let the PWB tool auto-swap the FPGA pins, and then clean that up in layout. Then we feed that pin out back to the FPGA design tools, and make sure we can place and route the design in the FPGA while meeting timing. This is often with a preliminary version of the FPGA code, but with relevant IO structures in place. AndyArticle: 131276
Andy wrote: > assignments, but after that, we are often able to let the PWB tool > auto-swap the FPGA pins, and then clean that up in layout. Then we > feed that pin out back to the FPGA design tools, and make sure we can > place and route the design in the FPGA while meeting timing. This is > often with a preliminary version of the FPGA code, but with relevant > IO structures in place. > > Andy Hi Andy, Do you use PADS I/O designer? Also, have you ever found that the PWB tool swapped pins that prevented your FPGA code meeting timing? I never bother testing, because it always does. I'd be interested in any counter examples you have. Thanks for your post, Syms.Article: 131277
Dave We are slightly unusual in that we started as FPGA design house and now probably better known for our boards even though we do an awful lot of internal FPGA design still. A lot of board layout is just common sense. Having a plan of how it all fits together - not just placement but routing runs between chips usually pays great dividends. Having someone who understands both the FPGA and the pcb layout is usually a great advantage as it allows tradeoffs to be made easily and generally ends up with with a better board. Swaping I/Os as you layout will give a much better results. That all said we are still learning on our pcb design skills even after producing development boards for nearly 5 years and I can still say generally that every new board we do is technically better than the previous one we did. Your first board will probably take a long time especially if it as in any way complex. Our first development board (Broaddown2 for the interested) that we released took about 800hrs of man effort. We would do that same board now in probably less than 1/3 of that time now. So in summary you have the difficult decision whether to invest time in learning the trade, making mistakes along the way, and possibly getting better boards versus the direct cost of using someone experienced and reducing the risks of a good enough to ship first layout. Very few people achieve boards that are good enough to ship as practical production boards as first revisions and if you do that you are doing well. Wire mods etc in production cost lots. I'm know of some designs done by customers themselves that have gone to 7 versions due to mistakes in layout. That's not cheap and really hits timescales. I'm proud to say my team have delivered over 50% of our development boards to production, to ship at 1st issue, but that is definately unusual in boards of that level of complexity. Board can be an enjoyable task but it's not for the impatient. John Adair Enterpoint Ltd. On Apr 17, 5:43=A0pm, Dave <dhsch...@gmail.com> wrote: > Does anybody out there have a good methodology for determining your > optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? > The brute force method is fairly maddening. I'd be curious to hear if > anybody has any 'tricks of the trade' here. > > Also, just out of curiosity, how many of you do your own PCB layout, > versus farming it out? It would certainly save us a lot of money to > buy the tools and do it ourselves, but it seems like laying out a > board out well requires quite a bit of experience, especially a 6-8 > layer board with high pin count FPGA's. > > We're just setting up a hardware shop here, and although I've been > doing FPGA and board schematics design for a while, it's always been > at a larger company with resources to farm the layout out, and we > never did anything high-speed to really worry about the board layout > too much. Thanks in advance for your opinions. > > DaveArticle: 131278
HT-Lab wrote: > > As mentioned by Robert if you use Modelsim then look up SignalSpy which is > very powerful and dead easy to use. If you use Riviera then you might be > able to use VHDL2007/8. I am not 100% sure if the VHDL2007/8 syntax below > is correct but it might look something like this: > > txcomstart <= <<signal .UUT.instance_1.txcomstart : std_logic_vector >>; > > if(txcomstart /= '0') then > error <= x"0103"; > end if; > > Any Riviera user would like to comment on this? I tried that with Riviera 2007.06, which did not seem to understand it. I could not find anything in the docs about that syntax. I have not downloaded the newest version of Riviera yet, so maybe that was added very recently. In the version I have, you use a "signal_agent" to access internal signals.Article: 131279
"Duane Clark" <user@domaininvalid.com> wrote in message news:GhNNj.6979$GE1.1520@nlpi061.nbdc.sbc.com... > HT-Lab wrote: >> >> As mentioned by Robert if you use Modelsim then look up SignalSpy which >> is very powerful and dead easy to use. If you use Riviera then you might >> be able to use VHDL2007/8. I am not 100% sure if the VHDL2007/8 syntax >> below is correct but it might look something like this: >> >> txcomstart <= <<signal .UUT.instance_1.txcomstart : std_logic_vector >>; >> >> if(txcomstart /= '0') then >> error <= x"0103"; >> end if; >> >> Any Riviera user would like to comment on this? > > I tried that with Riviera 2007.06, which did not seem to understand it. I > could not find anything in the docs about that syntax. I have not > downloaded the newest version of Riviera yet, so maybe that was added very > recently. In the version I have, you use a "signal_agent" to access > internal signals. Thanks for trying it out. I did a search and found some VHDL2006 info (Riviera-Pro 2008.02) on the Aldec Website but I couldn't find anything related to hierarchical references. http://support.aldec.com/KnowledgeBase/Article.aspx?aid=000730&show=vsa00518.htm Hans www.ht-lab.comArticle: 131280
Try the Xilinx Early Access Partial Reconfiguration Lounge. You have to register for it but it contains a lot more information on the ICAP and PR that the user guide / library guide does. http://www.xilinx.com/support/prealounge/protected/index.htm On Apr 16, 4:05 pm, "rha_x" <alo...@nospamplseece.unm.edu> wrote: > Hi, > I am trying to use the ICAP_VIRTEX4 primitive and I have two questions: > 1.- There is very little documentation. I've only found information at the > Virtex-4 Libraries Guide for HDL Designs. But then again, it doesn't say > much about the protocol. Have anybody find more info, or successfully > worked with it before? > 2.- The manual says I can setup the I/O width to 8, but it doesn't seem to > be working. > > I am using ISE 9.2 SP3 > > Any information will be appreciated. > > alonzo. > > -- > Message posted usinghttp://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/ > More information athttp://www.talkaboutelectronicequipment.com/faq.htmlArticle: 131281
<robquigley@gmail.com> wrote in message news:b111607f-eba0-4eba-85ef-1c14e1431c3b@a70g2000hsh.googlegroups.com... > Hey everybody, > > Just started using Xilinx XST as my synthesis tool and I'm just > looking for the command line instruction (or GUI) to set the design > frequency, I was using precision where it was "setup_design - > frequency=66". > > Anyone know the equivalent command for XST? > > My eyes cant seem to find it in the documentation! :-( > > > Cheers, > > > Rob. UCF file? NET "clk" TNM_NET = "clk"; TIMESPEC "TS_clk" = PERIOD "clk" 0.025 us; Hans www.ht-lab.comArticle: 131282
On Apr 17, 1:48=A0pm, "Chumnarn P." <chumn...@gmail.com> wrote: > On Apr 16, 1:34 am, Michael <nleah...@gmail.com> wrote: > > > > > > > On Apr 15, 2:10 pm, Kevin Neilson > > > <kevin_neil...@removethiscomcast.net> wrote: > > > > Also - is there a Xilinx simulator that is built into ISE? I am > > > > following a Xilinx tutorial (http://www.xilinx.com/support/techsup/ > > > > tutorials/tutorials9.htm) and it first says "Whether you use > > > > the ModelSim simulator or the ISE Simulator with this tutorial, you > > > > will achieve the same results." suggesting there is a fully function= al > > > > tutorial built into ISE, and then two paragraphs down it says "In > > > > order to use this tutorial, you must install ModelSim on your > > > > computer.". So that just confused me. > > > > > Thanks! > > > > > -Michael > > > > The most recent version of ISIM (the ISE simulator) is much faster and= > > > has a new parser so it supports the language(s) much better. =A0The us= er > > > interface is a bit coarser and the waveform viewer is not as nice as > > > Modelsim's, but it might work well for you. =A0I didn't consider this > > > because it's not really free, since ISE isn't free, but if you already= > > > have ISE it might be a good option. =A0-Kevin > > > I'm confused - I just downloaded the "ISE WebPACK 9.2i" a couple days > > ago and didn't pay a thing. (and it never asked me to pay a thing). > > Does this have a built in simulator, or is it only the version that > > you pay for that has a built in simulator? Thanks, > > > -Michael > > ----------------------------------------------------- > ISE WebPACK 9.2i does not include the HDL simulator. Therefore, you > need to install it (ModelSIM XE) separately. There is a WebPack10.1 > now, but I haven't check it if it also include the simulator. > > chumnarn Hi - I do have the three exes Kevin mentioned (vlogcomp.exe, vhpcomp.exe, and fuse.exe) - so I'm assuming that means I have it? Is there a way to quickly test run it? Thanks, -MichaelArticle: 131283
I recently found a couple of XC2018 in a drawer. Although these will probably never see any use again it got me thinking that a chip photo of these chips will probably look pretty nice. Has anyone seen such a photo somewhere? My guess is that it will probably look rather impressive as older chips usually allows you to really appreciate the effort that went into the design. /AndreasArticle: 131284
"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:U5MNj.6956$GE1.6193@nlpi061.nbdc.sbc.com... > qrk wrote: >> On Thu, 17 Apr 2008 09:43:09 -0700 (PDT), Dave <dhschetz@gmail.com> >> wrote: >> >>> Does anybody out there have a good methodology for determining your >>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? >>> The brute force method is fairly maddening. I'd be curious to hear if >>> anybody has any 'tricks of the trade' here. >>> >>> Also, just out of curiosity, how many of you do your own PCB layout, >>> versus farming it out? It would certainly save us a lot of money to >>> buy the tools and do it ourselves, but it seems like laying out a >>> board out well requires quite a bit of experience, especially a 6-8 >>> layer board with high pin count FPGA's. >>> >>> We're just setting up a hardware shop here, and although I've been >>> doing FPGA and board schematics design for a while, it's always been >>> at a larger company with resources to farm the layout out, and we >>> never did anything high-speed to really worry about the board layout >>> too much. Thanks in advance for your opinions. >>> >>> Dave >> >> Sure wish there was a slick way of doing FPGA pinouts. I usually use >> graph paper and figure out the FPGA pinout to other parts to minimize >> routing snarls. >> >> I do pcb layouts on my own and other folks designs. Our boards have >> high-speed routing, switching power supplies, and high-gain analog >> stuff; sometimes all on the same board. Unless the service bureau has >> someone who understands how to lay out such circuitry and place >> sensitive analog stuff near digital junk, it is more trouble to farm >> out than do it yourself if you want the board to work on the first >> cut. >> > > Or find a good layouter and develop a long-term business relationship. My > layouter knows just from looking at a schematic which areas are critical. > He's a lot older than I am and that is probably one of the reasons why his > stuff works without much assistance from me. Nothing can replace a few > decades of experience. > > >> Doing your own layout will take a lot of learning to master the PCB >> layout program and what your board vendor can handle. It will take 5 >> to 10 complicated boards to become mildly proficient at layout. I >> don't know about saving cost. Your time may be better spent doing >> other activities rather than learning about layout and doing the >> layouts. ... > > > Yep, that's why I usually do not do my own layouts. Occassionally I route > a small portion of a circuit and send that to my layouter. No DRC or > anything, just to show him how I'd like it done. > > >> ... The upside to doing your own layout - you control the whole >> design from start to finish. If you have a challenging layout, you'll >> have a much higher probability of having a working board on the first >> try which has hidden savings (getting to market earlier <- less >> troubleshooting + less respins). >> >> --- >> Mark > > > -- > Regards, Joerg > > http://www.analogconsultants.com/ > > "gmail" domain blocked because of excessive spam. > Use another domain or send PM. I agree with Joerg. Good high speed or mixed signal PCB layout is a career choice, and we electrical engineers already chose our career. A good layout requires someone who understands not just the software package, but the details of how the manufacturing operation is going to proceed, what the limits of the processes are, what the assembly operations require of the board, and is anal about things like footprint libraries and solder mask clearances and a thousand other details that I'm only partially aware of. The more complex your design, the more critical these things become. I have two good local outfits for farming out boards. For complex stuff, they know I'll come to their place and sit next to the designer for a good bit of the initial placement. While we are doing placement, we are also discussing critical nets, routing paths, layer usage, etc. That gives us direct face to face communication and avoids spending lots of time trying to write/draw everything in gory detail (which gets ignored or misunderstood a lot of the time). That investment pays big dividends in schedule and board performance. Don't be fooled by the relatively low cost of the software. That's not where the big costs are. I once laid off my entire PCB layout department and sent all the work outside, because although my employees all knew how to use the software, none of them could tell me what their completion date would be, or how many hours it would take, and they certainly weren't interested in meeting schedules. The outside sources would commit to a cost and a delivery date. And we already knew they could meet our performance objectives. Fixed price contracts are great motivators. Missing an engineering test window, or slipping a production schedule because of a layout delay can be enormously expensive. Of course, if I had let my engineers do their own layouts, the motivation would have been present, but the technical proficiency would not. How proficient can anyone become if they only do layout a few times a year? Also, on many projects engineers use the layout period for other important things like documentation, test procedures, writing test code, etc. Doing your own layout serializes these tasks and will stretch your schedule. So my advice is to keep doing what you have been doing. Its far more likely that its the cheapest approach, even though you occasionally have to write a big check. SteveArticle: 131285
On Apr 17, 5:13 pm, "Steve" <sjbur...@comcast.net> wrote: > "Joerg" <notthisjoerg...@removethispacbell.net> wrote in message > > news:U5MNj.6956$GE1.6193@nlpi061.nbdc.sbc.com... > > > > > qrk wrote: > >> On Thu, 17 Apr 2008 09:43:09 -0700 (PDT), Dave <dhsch...@gmail.com> > >> wrote: > > >>> Does anybody out there have a good methodology for determining your > >>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? > >>> The brute force method is fairly maddening. I'd be curious to hear if > >>> anybody has any 'tricks of the trade' here. > > >>> Also, just out of curiosity, how many of you do your own PCB layout, > >>> versus farming it out? It would certainly save us a lot of money to > >>> buy the tools and do it ourselves, but it seems like laying out a > >>> board out well requires quite a bit of experience, especially a 6-8 > >>> layer board with high pin count FPGA's. > > >>> We're just setting up a hardware shop here, and although I've been > >>> doing FPGA and board schematics design for a while, it's always been > >>> at a larger company with resources to farm the layout out, and we > >>> never did anything high-speed to really worry about the board layout > >>> too much. Thanks in advance for your opinions. > > >>> Dave > > >> Sure wish there was a slick way of doing FPGA pinouts. I usually use > >> graph paper and figure out the FPGA pinout to other parts to minimize > >> routing snarls. > > >> I do pcb layouts on my own and other folks designs. Our boards have > >> high-speed routing, switching power supplies, and high-gain analog > >> stuff; sometimes all on the same board. Unless the service bureau has > >> someone who understands how to lay out such circuitry and place > >> sensitive analog stuff near digital junk, it is more trouble to farm > >> out than do it yourself if you want the board to work on the first > >> cut. > > > Or find a good layouter and develop a long-term business relationship. My > > layouter knows just from looking at a schematic which areas are critical. > > He's a lot older than I am and that is probably one of the reasons why his > > stuff works without much assistance from me. Nothing can replace a few > > decades of experience. > > >> Doing your own layout will take a lot of learning to master the PCB > >> layout program and what your board vendor can handle. It will take 5 > >> to 10 complicated boards to become mildly proficient at layout. I > >> don't know about saving cost. Your time may be better spent doing > >> other activities rather than learning about layout and doing the > >> layouts. ... > > > Yep, that's why I usually do not do my own layouts. Occassionally I route > > a small portion of a circuit and send that to my layouter. No DRC or > > anything, just to show him how I'd like it done. > > >> ... The upside to doing your own layout - you control the whole > >> design from start to finish. If you have a challenging layout, you'll > >> have a much higher probability of having a working board on the first > >> try which has hidden savings (getting to market earlier <- less > >> troubleshooting + less respins). > > >> --- > >> Mark > > > -- > > Regards, Joerg > > >http://www.analogconsultants.com/ > > > "gmail" domain blocked because of excessive spam. > > Use another domain or send PM. > > I agree with Joerg. Good high speed or mixed signal PCB layout is a career > choice, and we electrical engineers already chose our career. A good layout > requires someone who understands not just the software package, but the > details of how the manufacturing operation is going to proceed, what the > limits of the processes are, what the assembly operations require of the > board, and is anal about things like footprint libraries and solder mask > clearances and a thousand other details that I'm only partially aware of. > The more complex your design, the more critical these things become. > > I have two good local outfits for farming out boards. For complex stuff, > they know I'll come to their place and sit next to the designer for a good > bit of the initial placement. While we are doing placement, we are also > discussing critical nets, routing paths, layer usage, etc. That gives us > direct face to face communication and avoids spending lots of time trying to > write/draw everything in gory detail (which gets ignored or misunderstood a > lot of the time). That investment pays big dividends in schedule and board > performance. > > Don't be fooled by the relatively low cost of the software. That's not where > the big costs are. > > I once laid off my entire PCB layout department and sent all the work > outside, because although my employees all knew how to use the software, > none of them could tell me what their completion date would be, or how many > hours it would take, and they certainly weren't interested in meeting > schedules. The outside sources would commit to a cost and a delivery date. > And we already knew they could meet our performance objectives. Fixed price > contracts are great motivators. Missing an engineering test window, or > slipping a production schedule because of a layout delay can be enormously > expensive. > > Of course, if I had let my engineers do their own layouts, the motivation > would have been present, but the technical proficiency would not. How > proficient can anyone become if they only do layout a few times a year? > Also, on many projects engineers use the layout period for other important > things like documentation, test procedures, writing test code, etc. Doing > your own layout serializes these tasks and will stretch your schedule. > > So my advice is to keep doing what you have been doing. Its far more likely > that its the cheapest approach, even though you occasionally have to write a > big check. > > Steve I tend to agree with the 'farm-it-out' crowd. Unfortunately, my current employer doesn't want to work with my previous layout people, so I've been trying to search for a new partner. I've found plenty of board fab and assembly places, but not so much on the layout. It made me think that the rest of the world did their own layout. The opinions look pretty split from the replies here, maybe it comes down to how many times you do a layout each year, and how much you enjoy that sort of work. I definitely think it's something you have to do fairly often to keep your chops up. Andy, I'd also like to hear more about your pin-swap FPGA design flow - what tools do that? Also curious about any timing issues that have been caught after the pin-swap. Thank you all very much for the info. If any of you find yourself in the Baltimore area, I owe you a crabcake sandwich and a beer. DaveArticle: 131286
On 17 Apr., 18:13, chrisde...@gmail.com wrote: > Hi, > does anyone know how to use a 2nd FSL peripheral attached to > microblaze? This is what I did. I have attached 2 peripherals, let's > say we call it peripheral1 and peripheral2 to the microblaze's FSL > bus. > > now here comes the problem. Using the commands > putfsl(val,0) and getfsl(val,1), I am able to write and read from > peripheral 1 respectively. > > However, when I do > putfsl(val,2) and getfsl(val,3), nothing happens from peripheral2; I > thought i was supposed to write and read from peripheral 2 > respectively by these commands. > > I have been struggling with this for a while...any of your inputs > would really be great. :D > > --- excerpt from system.mhs file > > BEGIN microblaze > PARAMETER INSTANCE = microblaze_0 > PARAMETER HW_VER = 4.00.a > PARAMETER C_DEBUG_ENABLED = 1 > PARAMETER C_NUMBER_OF_PC_BRK = 2 > PARAMETER C_NUMBER_OF_RD_ADDR_BRK = 1 > PARAMETER C_NUMBER_OF_WR_ADDR_BRK = 1 > PARAMETER C_FSL_LINKS = 2 > PARAMETER C_USE_FPU = 1 > BUS_INTERFACE DLMB = dlmb > BUS_INTERFACE ILMB = ilmb > BUS_INTERFACE DOPB = mb_opb > BUS_INTERFACE IOPB = mb_opb > BUS_INTERFACE SFSL0 = peripheral1_to_microblaze_0 ## IS THE ID 1? > BUS_INTERFACE MFSL0 = microblaze_0_to_peripheral1 ## IS THE ID 0? > BUS_INTERFACE SFSL1 = peripheral2_0_to_microblaze_0 ## IS THE ID 3? > BUS_INTERFACE MFSL1 = microblaze_0_to_peripheral2 ## IS THE ID 2? > PORT CLK = sys_clk_s > PORT DBG_CAPTURE = DBG_CAPTURE_s > PORT DBG_CLK = DBG_CLK_s > PORT DBG_REG_EN = DBG_REG_EN_s > PORT DBG_TDI = DBG_TDI_s > PORT DBG_TDO = DBG_TDO_s > PORT DBG_UPDATE = DBG_UPDATE_s > END > > otherwise, how to determine the corresponding ID of the FSL > peripherals? I have looked through fsl_v20.pdf but dun see anything > useful. > > thanks a million! > Chris your corresponding fsl id is usually in the xparameters.h and should look something like this: #define XPAR_FSL_0_OUTPUT_SLOT_ID 0 #define XPAR_FSL_0_INPUT_SLOT_ID 0 with putfsl(va, 0) you a probably writing to the first peripheral and with getfsl(val, 1) you are reading from the second? you might also use the create peripheral wizard. i generates a nice example how to use the fsl bus with driver templates... urbanArticle: 131287
Dave wrote: > > I tend to agree with the 'farm-it-out' crowd. Unfortunately, my > current employer doesn't want to work with my previous layout people, > so I've been trying to search for a new partner. I've found plenty of > board fab and assembly places, but not so much on the layout. It made Some of the PCB software vendors have lists on their web site of independent consultants and layout houses that use their software. I went on the Mentor site and found zillions of layout people. -JeffArticle: 131288
Rob wrote: > > I'm just looking for the command line instruction (or GUI) > to set the design frequency, I was using precision where it > was "setup_design -frequency=66". > > Anyone know the equivalent command for XST? > XST timing constraints are set up in the .xcf file In the 9.2i XST user manual %xilinx%\doc\usenglish\books\docs\xst\xst.pdf Look at: "XST Constraint File (XCF)", page 325 "XST timing options", page 336 The XST command line field is described in the first section listed above. In the ISE GUI, you add this file to the flow by: - right click on the "Synthesis - XST " line of the processes window, and select "Properties" - in the "Synthesis Options" category: - set "Property Display Level" to "Advanced" - check the "Use Synthesis Constraints" button - fill in the "Synthesis Constraints File" field If you want XST to forward annotate these to P&R tools, also check the "Write Timing Constraints" option. BrianArticle: 131289
"Dave" <dhschetz@gmail.com> wrote in message news:dfc27fc0-c07f-456c-80cb-b31e867dd253@d1g2000hsg.googlegroups.com... > The opinions > look pretty split from the replies here, maybe it comes down to how > many times you do a layout each year, and how much you enjoy that sort > of work. I definitely think it's something you have to do fairly often > to keep your chops up. I think what you're seeing is that fact that, by sheer volume of products, guys doing relatively low-speed digital stuff completely dominate those doing very low-level analog, RF, microwave, or truly high-speed digital. In the former case, it just doesn't really matter that much how you layout the board. Sure, there are definitely better ways and worse ways, but even up to clock rates pushing 100MHz, for digital stuff I think you can give a guy about an hour of education and he'll be able to make boards work just fine. Another point to keep in mind is that there's a significant difference between being able to design a board well when you're talking relatively small volume production for high-end commercial or military customers where you can afford to just toss in some extra layers and pay for blind or buried vias or tigether tolerances if you're at all unsure of how well your layout skills really are vs. designing a complex board for highly cost-competitive mass-markets. The later requires a lot of skills that are anything but what is commonly taught! (E.g., typically at tech seminars you'll hear people preaching, "throw in a ground plane!" -- an action that saves many an otherwise broken design, but one which might not be possible if your competition has already figured out how to live without one.) I'm a big advocate of giving "technical interviews" to would-be PCB layout guys based on what your needs are. If you're doing, e.g., RF or high-speed digital design, ask them how line impedances change with changes in board and trace dimensions, what near-end and far-end crosstalk look like on a scope, what they think about splitting up ground planes, how they'd route some simple circuits, etc... Usually you can find out pretty quickly what their skills are whether or not they're adequate or if they'd need a bit more hand-holding... which could be fine too, if you have the time and the price is right. > Andy, I'd also like to hear more about your pin-swap FPGA design flow > - what tools do that? It's a common feature in most PCB tools to allow pin (and gate) swapping based on the component's library entry being set up to designate which pins and gates are "swappable." After doing so, most of them will produce a simple ASCII "was-is" text file that list the old pin name and the new one, which can be imported back into a schematic capture program or used to update your FPGA place & route constraints. (PADS will do all this, where Pulsonix unfortunately does pin & gate swapping quite nicely but will only update a Pulsonix schematic "directly" rather than providing you with the option to generate a was-is file.) ---JoelArticle: 131290
Joel Koltner wrote: > "Dave" <dhschetz@gmail.com> wrote in message > news:dfc27fc0-c07f-456c-80cb-b31e867dd253@d1g2000hsg.googlegroups.com... >> The opinions >> look pretty split from the replies here, maybe it comes down to how >> many times you do a layout each year, and how much you enjoy that sort >> of work. I definitely think it's something you have to do fairly often >> to keep your chops up. > > I think what you're seeing is that fact that, by sheer volume of products, > guys doing relatively low-speed digital stuff completely dominate those doing > very low-level analog, RF, microwave, or truly high-speed digital. In the > former case, it just doesn't really matter that much how you layout the board. > Sure, there are definitely better ways and worse ways, but even up to clock > rates pushing 100MHz, for digital stuff I think you can give a guy about an > hour of education and he'll be able to make boards work just fine. > Not anymore. Part of my daily bread is earned salvaging designs where someone thought "Oh, it's just slow stuff". But it ain't grampa's old SN7400 anymore, today's logic chips are fast. Some like the tiny logic chips swing their outputs within very few nanoseconds. Then some unexpected weirdnesses show up. Everyone thinks it's software but in reality crosstalk has manifested itself. Other times the moment of truth cometh at the EMC lab when a thick forrest shows up on the spectrum analyzer. > Another point to keep in mind is that there's a significant difference between > being able to design a board well when you're talking relatively small volume > production for high-end commercial or military customers where you can afford > to just toss in some extra layers and pay for blind or buried vias or tigether > tolerances if you're at all unsure of how well your layout skills really are > vs. designing a complex board for highly cost-competitive mass-markets. The > later requires a lot of skills that are anything but what is commonly taught! > (E.g., typically at tech seminars you'll hear people preaching, "throw in a > ground plane!" -- an action that saves many an otherwise broken design, but > one which might not be possible if your competition has already figured out > how to live without one.) > And don't split that plane. But yes, often one has to make do with two-layer phenolic. That is often true art. BTW does that little switcher work? [...] -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131291
"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:ZjRNj.9697$2g1.9469@nlpi068.nbdc.sbc.com... > Not anymore. Part of my daily bread is earned salvaging designs where > someone thought "Oh, it's just slow stuff". But it ain't grampa's old SN7400 > anymore, today's logic chips are fast. OK, ok, good point. Doesn't someone now have a logic family that's purposely been slowed down due to this "problem?" > And don't split that plane. But yes, often one has to make do with two-layer > phenolic. That is often true art. >From Thomas Lee (Stanford) in "Planar Microwave Engineering": In extremely low-cost consumer devices (e.g., toys, pocket radios, etc.), an even less expensive board material is not infrequently encountered. Phenolic is often a caramel brown, typically has an "organical chemical" odor, and is remarkably lossy. Although phenolic is occasionally used for RF toys up to 100MHz, it is totally insuitable for serious applications. It is mentioned here simply to answer the question: "What is that cheap, malodorous board made of?" :-) I know, I know, he's living in an ivory tower a bit, but he is one smart cookie. > BTW does that little switcher work? I've had that board back for about a week, although I haven't actually tested out the switcher yet since the DSP guy isn't interested in working with the new (digital) board until the new RF board comes back (and gets tested) as well, which is still a couple weeks out. (There's this "Big Tester Board" that's needed to test the RF board and said BTB has spent something over a week bouncing around engineering getting tweaked/fixed/etc... we'll be paying a premium to actually get it fabbed in time to start testing RF boards at this point, unfortunately :-( .) I can and probably should just put a dummy load on the switcher, turn it on, and see if there's any obvious problems before the DSP guy starts looking at his clock jitter. Tomorrow sounds like a good day for that... ---JoelArticle: 131292
Joel Koltner wrote: > "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message > news:ZjRNj.9697$2g1.9469@nlpi068.nbdc.sbc.com... >> Not anymore. Part of my daily bread is earned salvaging designs where >> someone thought "Oh, it's just slow stuff". But it ain't grampa's old SN7400 >> anymore, today's logic chips are fast. > > OK, ok, good point. Doesn't someone now have a logic family that's purposely > been slowed down due to this "problem?" > There used to be but it's gone. They also had really high threshold voltages and stuff. >> And don't split that plane. But yes, often one has to make do with two-layer >> phenolic. That is often true art. > > From Thomas Lee (Stanford) in "Planar Microwave Engineering": > > In extremely low-cost consumer devices (e.g., toys, pocket radios, etc.), an > even less expensive board material is not infrequently encountered. Phenolic > is often a caramel brown, typically has an "organical chemical" odor, and is > remarkably lossy. Although phenolic is occasionally used for RF toys up to > 100MHz, it is totally insuitable for serious applications. It is mentioned > here simply to answer the question: "What is that cheap, malodorous board made > of?" > > :-) > > I know, I know, he's living in an ivory tower a bit, but he is one smart > cookie. > Errr, well, those sure sound like ivory tower statements. For some reason all the phenolic I ever used has never smelled. Unless something blew up on there, of course, but then FR4 will also let off a nasty stench. The new stuff looks amazingly similar to FR4, not dark brown. Remarkably lossy? Nah. I have proof to the contrary right here in the garage (if it's still there), a VHF/UHF TV splitter and 60ohm to 240ohm transformer where the UHF part is almost completely done in microstrip. Yes, microstrip on phenolic. There may be a fraction of a dB here and there but on short stretches that hardly matters. Usually those things are for outdoors so it's lacquer coated anyway. Phenolic is somewhat hygroscopic so you have to watch out for moisture. Totally insuitable for serious applications? Oh man. Let's see, what have we here? A 418MHz transmitter, several matching networks, a UHF receiver ... all on phenolic. Sometimes I wish that professors had more nose-to-the-grindstone industry work under the belt. I mean real design work where cost is a big factor. Otherwise they are going to tell students they should use Rogers for just about everything ... >> BTW does that little switcher work? > > I've had that board back for about a week, although I haven't actually tested > out the switcher yet since the DSP guy isn't interested in working with the > new (digital) board until the new RF board comes back (and gets tested) as > well, which is still a couple weeks out. (There's this "Big Tester Board" > that's needed to test the RF board and said BTB has spent something over a > week bouncing around engineering getting tweaked/fixed/etc... we'll be paying > a premium to actually get it fabbed in time to start testing RF boards at this > point, unfortunately :-( .) I can and probably should just put a dummy load > on the switcher, turn it on, and see if there's any obvious problems before > the DSP guy starts looking at his clock jitter. Tomorrow sounds like a good > day for that... > That would be good. Gives you a head start just in case there is a surprise ;-) -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131293
On 2008-04-17, Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: > I recently found a couple of XC2018 in a drawer. Although > these will probably never see any use again it got me > thinking that a chip photo of these chips will probably > look pretty nice. > > Has anyone seen such a photo somewhere? My guess is that > it will probably look rather impressive as older chips > usually allows you to really appreciate the effort that > went into the design. Through a couple of web searches I found the following page which I have never seen before: http://smithsonianchips.si.edu/ice/s4.htm There are a couple of reports related to FPGAs on that page and some for CPLD. The following book was also quite interesting: http://smithsonianchips.si.edu/augarten/ /AndreasArticle: 131294
On Thu, 17 Apr 2008 09:43:09 -0700 (PDT), Dave <dhschetz@gmail.com> wrote: >Does anybody out there have a good methodology for determining your >optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? >The brute force method is fairly maddening. I'd be curious to hear if >anybody has any 'tricks of the trade' here. What's the brute force method? We preassign most fpga pins for clean, no-crossover routing to other chips. We discuss the general issues, especially placement, with our pcb layout guy and he actually decides which pins go where. Then he back-annotates the schematic and gives us a file we can use to create the fpga pin constraints file. Sometimes bank issues complicate the process, but it works pretty well. > >Also, just out of curiosity, how many of you do your own PCB layout, >versus farming it out? It would certainly save us a lot of money to >buy the tools and do it ourselves, but it seems like laying out a >board out well requires quite a bit of experience, especially a 6-8 >layer board with high pin count FPGA's. We'd never farm it out. We do critical mixed-signal stuff, and need to be near our layout guy constantly. He puts up a version on our server daily at least, and we keep an eye on progress. And we have a lot of mini-meetings to change the rules as needed. Besides, we have evolved some styles (and libraries!) that we couldn't very well transfer to a service bureau. PCB layout is too important to farm out. > >We're just setting up a hardware shop here, and although I've been >doing FPGA and board schematics design for a while, it's always been >at a larger company with resources to farm the layout out, and we >never did anything high-speed to really worry about the board layout >too much. Thanks in advance for your opinions. For really critical stuff, sometimes I'll take over and route that part of the board myself. It's just too hard to communicate exactly what I want. JohnArticle: 131295
Joerg wrote: > Joel Koltner wrote: > > > Totally insuitable for serious applications? Oh man. Let's see, what > have we here? A 418MHz transmitter, several matching networks, a UHF > receiver ... all on phenolic. Multi ghz RF+matching stuff, analog and some digital will work on an FR4 derivative. > > Sometimes I wish that professors had more nose-to-the-grindstone > industry work under the belt. I mean real design work where cost is a > big factor. Otherwise they are going to tell students they should use > Rogers for just about everything ... Don't forget rogers is not perfect , intolerance to flexing and intolerant of poor soldering techniques. >Article: 131296
On Apr 18, 8:15 am, Dave <dhsch...@gmail.com> wrote: > On Apr 17, 5:13 pm, "Steve" <sjbur...@comcast.net> wrote: > > > > > "Joerg" <notthisjoerg...@removethispacbell.net> wrote in message > > >news:U5MNj.6956$GE1.6193@nlpi061.nbdc.sbc.com... > > > > qrk wrote: > > >> On Thu, 17 Apr 2008 09:43:09 -0700 (PDT), Dave <dhsch...@gmail.com> > > >> wrote: > > > >>> Does anybody out there have a good methodology for determining your > > >>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? > > >>> The brute force method is fairly maddening. I'd be curious to hear if > > >>> anybody has any 'tricks of the trade' here. > > > >>> Also, just out of curiosity, how many of you do your own PCB layout, > > >>> versus farming it out? It would certainly save us a lot of money to > > >>> buy the tools and do it ourselves, but it seems like laying out a > > >>> board out well requires quite a bit of experience, especially a 6-8 > > >>> layer board with high pin count FPGA's. > > > >>> We're just setting up a hardware shop here, and although I've been > > >>> doing FPGA and board schematics design for a while, it's always been > > >>> at a larger company with resources to farm the layout out, and we > > >>> never did anything high-speed to really worry about the board layout > > >>> too much. Thanks in advance for your opinions. > > > >>> Dave > > > >> Sure wish there was a slick way of doing FPGA pinouts. I usually use > > >> graph paper and figure out the FPGA pinout to other parts to minimize > > >> routing snarls. > > > >> I do pcb layouts on my own and other folks designs. Our boards have > > >> high-speed routing, switching power supplies, and high-gain analog > > >> stuff; sometimes all on the same board. Unless the service bureau has > > >> someone who understands how to lay out such circuitry and place > > >> sensitive analog stuff near digital junk, it is more trouble to farm > > >> out than do it yourself if you want the board to work on the first > > >> cut. > > > > Or find a good layouter and develop a long-term business relationship. My > > > layouter knows just from looking at a schematic which areas are critical. > > > He's a lot older than I am and that is probably one of the reasons why his > > > stuff works without much assistance from me. Nothing can replace a few > > > decades of experience. > > > >> Doing your own layout will take a lot of learning to master the PCB > > >> layout program and what your board vendor can handle. It will take 5 > > >> to 10 complicated boards to become mildly proficient at layout. I > > >> don't know about saving cost. Your time may be better spent doing > > >> other activities rather than learning about layout and doing the > > >> layouts. ... > > > > Yep, that's why I usually do not do my own layouts. Occassionally I route > > > a small portion of a circuit and send that to my layouter. No DRC or > > > anything, just to show him how I'd like it done. > > > >> ... The upside to doing your own layout - you control the whole > > >> design from start to finish. If you have a challenging layout, you'll > > >> have a much higher probability of having a working board on the first > > >> try which has hidden savings (getting to market earlier <- less > > >> troubleshooting + less respins). > > > >> --- > > >> Mark > > > > -- > > > Regards, Joerg > > > >http://www.analogconsultants.com/ > > > > "gmail" domain blocked because of excessive spam. > > > Use another domain or send PM. > > > I agree with Joerg. Good high speed or mixed signal PCB layout is a career > > choice, and we electrical engineers already chose our career. A good layout > > requires someone who understands not just the software package, but the > > details of how the manufacturing operation is going to proceed, what the > > limits of the processes are, what the assembly operations require of the > > board, and is anal about things like footprint libraries and solder mask > > clearances and a thousand other details that I'm only partially aware of. > > The more complex your design, the more critical these things become. > > > I have two good local outfits for farming out boards. For complex stuff, > > they know I'll come to their place and sit next to the designer for a good > > bit of the initial placement. While we are doing placement, we are also > > discussing critical nets, routing paths, layer usage, etc. That gives us > > direct face to face communication and avoids spending lots of time trying to > > write/draw everything in gory detail (which gets ignored or misunderstood a > > lot of the time). That investment pays big dividends in schedule and board > > performance. > > > Don't be fooled by the relatively low cost of the software. That's not where > > the big costs are. > > > I once laid off my entire PCB layout department and sent all the work > > outside, because although my employees all knew how to use the software, > > none of them could tell me what their completion date would be, or how many > > hours it would take, and they certainly weren't interested in meeting > > schedules. The outside sources would commit to a cost and a delivery date. > > And we already knew they could meet our performance objectives. Fixed price > > contracts are great motivators. Missing an engineering test window, or > > slipping a production schedule because of a layout delay can be enormously > > expensive. > > > Of course, if I had let my engineers do their own layouts, the motivation > > would have been present, but the technical proficiency would not. How > > proficient can anyone become if they only do layout a few times a year? > > Also, on many projects engineers use the layout period for other important > > things like documentation, test procedures, writing test code, etc. Doing > > your own layout serializes these tasks and will stretch your schedule. > > > So my advice is to keep doing what you have been doing. Its far more likely > > that its the cheapest approach, even though you occasionally have to write a > > big check. > > > Steve > > I tend to agree with the 'farm-it-out' crowd. Unfortunately, my > current employer doesn't want to work with my previous layout people, > so I've been trying to search for a new partner. I've found plenty of > board fab and assembly places, but not so much on the layout. It made > me think that the rest of the world did their own layout. The opinions > look pretty split from the replies here, maybe it comes down to how > many times you do a layout each year, and how much you enjoy that sort > of work. I definitely think it's something you have to do fairly often > to keep your chops up. > > Andy, I'd also like to hear more about your pin-swap FPGA design flow > - what tools do that? Also curious about any timing issues that have > been caught after the pin-swap. In Altium Designer I use the incredibly useful "subnet jumper" feature for BGA's. The procedure goes something like this: 1) Fan out all the required FPGA pins first (automatically or manually) to just outside the chip boundry. (leave several diagonal entry paths for core and other power flood fills to get in) 2) Fully route all non-pin-swappable pins and other critical lines. 3) Ensure any other parts placements are near any required FPGA pins or block features you think you might need. 4) Route every track just short of the fanout tracks 5) Hit the "add subnet jumper" feature and it finishes the tracks and does all the pin swaps for you and updates the schematic. Probably needs a picture or two to explain it best though... The great part about subnet jumpers is if there are timing or other problems you can just remove the subnet jumpers and add/edit tracks and pins as needed and then replace the subnet jumpers. Only takes a minute or two. Dave.Article: 131297
On Apr 17, 9:58 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > I just tested the new bitfile with the 200ms DCM reset ... it seems to > > work fine. > > We'll see :-) > > Excellent - and I see I'll have to go and peruse the datasheet > further! 200ms is alot longer than I recall! It is reported on the Virtex 4 User Guide ... but before reading it I was using the ISE online help manuals ... and I didn't find any mention to 200ms ... if I remember correctly.Article: 131298
(I had already emailed this to Austin in response to an email which he sent me, but I have just noticed that he posted the email to Usenet as well, so for the benefit of those who did not see my private response, I post it now.) Austin, I trust that you are sincere, but you would not be the first person to work in aerospace who is mistaken and who is utterly convinced that he is not mistaken and whose confidence is understandably bolstered by many positive, genuine experiences of yours of overcoming would-be faults from radiation. Generalization is a problem. Radiation is just a detail. Even without radiation, you can not prove absolute safety. Can you prove at the 100% confidence level that your finite upper bound on metastability is valid? 99.999999999% confidence from empirical measurements are inadequate if you want to claim that a problem is impossible. Can you disprove the claim of quantum mechanics that any component has an infinitesimal (i.e. > 0% therefore necessary to be covered in a claim that something is perfect) probability of being spontaneously teleported to some galaxy we never heard of? Was hysteresis of unknown parameters overlooked in the curve fitting which was used in SPICE? Is the physics of deep submicron processes understood well enough? As others have done, I congratulate you and Xilinx for many fine posts to newsgroups. I thank you for responding (but I would have been content with you responding on comp.arch.fpga) (if you used email to avoid publicly embarrassing me, thank you), but I am still displeased that Xilinx did not answer a challenge I made in a thread to which Anne L. Atkins and Dr. John Williams also posted in 2007 (or maybe 2006) (I compose these posts and emails at home and as trying to find a way to pay for food is a major objective while I have limited networked time, it is not worth my while to give you an exact reference as you can easily search for yourself) in a similar discussion. Austin emailed: |------------------------------------------------------------------| |"It is a question of completeness. | | | |Logically going through every bit, is 100% functionally complete."| |------------------------------------------------------------------| Logic is theoretical whereas the devices are actually subjected to physics. A VHDL simulator can not replace SPICE for electromagnetic compatibility issues and SPICE can not replace empirical experiences and extrapolating empirical experiences to untried conditions can work but it can also fail. Similar points had been admitted in the book Thomas Kropf (editor), "Formal Hardware Verification: Methods and Systems in Comparison", Springer, 1997; in the final sentence of Section 5.3 of the book He Jifeng, C. A. R. Hoare, Jonathan Bowen, "Provably Correct Systems: Modelling of Communication Languages and Design of Optimized Compilers", 1994; in Section 12.1 What Are Formal Methods? of the book Jim Woodcock and Martin Loomes, "Software Engineering Mathematics: Formal Methods Demystified", 1988; on Page 181 (though oddly enough, almost the opposite was argued on Page 180) of the book Fenton and Hill, "Systems Construction and Analysis: A Mathematical and Logical Framework", 1993; and Dr. Fleuriot (who had been involved in collision and detection issues for aeronautics) of the University of Edinburgh said to me in a personal conversation on January 24th, 2008 "[..] there's no such thing as one hundred per cent guarantees [..]". In an even more impressive triumph of missing the point than Fenton's and Hill's Pages 180 and 181, Zerksis D. Umrigar, Vijay Pitchumani, "Formal Verification of a Real-Time Hardware Design", Design Automation Conference 1983 contains: "[..] If there are no errors, inconsistencies or ambiguities in the specifications, and no errors in the correctness proof, then a successful proof enables one to be totally confident that the design will function as desired. [..]" |---------------------------------------------------------------------| |"Sitting in a proton beam is "waiting for Godot" -- how long must you| |wait to check enough bits to achieve the required coverage?" | |---------------------------------------------------------------------| True. (Though actually there are somewhat usable techniques for aiming at desired locations in a device.) An even more important problem with a radiation source than what you have raised is whether it is even similar enough to what will bombard the device in the field. This is similar to I.Q. tests: their goal is to measure intelligence but they can not do so, instead they measure one's ability to do well in those tests, and though intelligent people are more likely to tend to do well in those tests, someone who has been practising those tests will get improved marks without actually becoming more intelligent. A paper in which it is shown that one radiation source can not be relied upon to be a perfect proxy for another is Jamie S. Laird, Toshio Hirao, Shinobu Onoda, Hisayoshi Itoh, and Allan Johnston, "Comparison of Above Bandgap Laser and MeV Ion Induced Single Event Transients in High-Speed Si Photonic Devices", "IEEE Transactions on Nuclear Science", December 2006. A minor discrepancy would probably not be important, but in one device it could make all the difference. Do not make unjustified generalizations. Even if the relevance of the radiation is not in doubt, it can be very difficult to make measurements, as mentioned in Thomas L. Turflinger, "Single-Event Effects in Analog and Mixed-Signal Integrated Circuits", "IEEE Transactions on Nuclear Science", April 1996. |---------------------------------------------------------------------| |"It becomes a matter of "too many dollars to keep the lights on." | |(Beam testing is horribly power hungry, and very expensive, eg TSL is| |$250K for a session, not including the airplane tickets, hotel rooms,| |people, rental cars...)." | |---------------------------------------------------------------------| Omnisys cut costs by using a source in a hospital. As mentioned above, that might not always be good enough, in one case it was. Anyhow, in a field in which spending $2000-$10000 for four megabytes of radhard memory is not a problem, testing with radiation is not merely a useless luxury. |-------------------------------------------------------------------------| |"Additional system testing in a beam is highly desired, but the goals are| |not for functional completeness, but to cover whatever might have been | |missed bu flipping 100%, one by one, every configuration bit. | | | |XTMR Tool(tm) software can not be broken by a single radiative event, | |nor by a single bit flip (as verified by NASA, JPL, CERN, etc....)." | |-------------------------------------------------------------------------| Would that be the same NASA which failed to pay attention to established schedulability analysis techniques for a rover for Mars and which lost a probe in 1973 intended for Venus as a result of being satisfied with a decimal point instead of a comma? Prof. William H. Sanders boasted on April 27th, 2006 at 12:04 that his group convinced NASA JPL that his group solved NASA JPL's supposedly insoluble fault-tolerant spaceborne computer problem posed in 1992. He showed his supposed solution and as it was not perfect and it did not seem that he was going to admit this without being forced to, I challenged him, so he admitted at 12:28 that it was not perfectly solved because of "[..] the classic problem in fault-tolerant computing of who checks the checker?" Scott Hensley of NASA said on June 4th, 2007 that his Europa TopoMapper proposal has still not been approved after fifteen years, partially due to the much worse Jovian radiation. If NASA is convinced that the techniques you use are sufficient, then why is this proposal still not approved? (I recently noticed that the European Space Agency is planning a mission to Jupiter. I do not know whether this is similar to the French space agency's example of ignoring common lore and sending doomed hardware into space, or whether the European Space Agency has actually overcome a serious obstacle.) Would that be the same European center for nuclear research which is partially responsible for the paper Agostinelli, et al., "GEANT4---a simulation toolkit", "Nuclear Instruments and Methods in Physics Research A", 506 (2003) in which it is claimed on Page 252: "[..] It has been created exploiting [..] object-oriented technology [..]" despite being distributed with functions containing copied and pasted statements instead of common statements isolated in a shared function? That is the same European center for nuclear research whose papers did not predict that physical effects would be observed at particular times of day and not at others due to systematic effects of a locomotive influencing particles' trajectories before they realized that they should look at a railway timetable in order to determine when a train would not be around to disrupt an experiment. I doubt that XTMR Tool(TM) was as much help in that case as you might had thought. |-------------------------------------------------------------------------| |"Our flow triplicates the voters, so that every feedback path gets a full| |TMR. A failure in a voter is "voted" out by the other two voters." | |-------------------------------------------------------------------------| TMR can help a lot. It does. It does not work for everything. Your marketing is similar to many inadequate MAPLD papers. If the probability of an upset for any gate is equal to the probability of an upset for any other gate, then winning_result <= majority_of(voter1, voter2, voter3); can work if just one single-event upset hits any of voter1 and voter2 and voter3. It does not work if it hits winning_result. Even so, TMR can be less risky than not copying if for example the data in the voters are hours' worth of data which could have been corrupted. It is true that in the relatively short amount of time used to transfer the hours' worth of data to winning_result that winning_result could get zapped, but it is not very likely so it might not be as dangerous as never bothering to vote on the accumulated readings. Of course, this is not safer than performing the vote immediately instead of waiting hours, but in that case winning_result and all but one of the voters can be unnecessary. Please understand that in one of the less bad MAPLD papers on Klabs.org the reason for placing voter1 into one FPGA susceptible to errors and voter2 into a different FPGA of the same quality and voter3 into yet another identical FPGA and winning_result into a less susceptible FPGA (probably an antifuse one) is that John von Neumann's (Janos Louis Neumann's) T.M.R. works better if the checker is not error-prone (but of course, this provides an incentive to not bother with T.M.R. at all by using less susceptible technology throughout). It has been empirically shown in papers such as J. Benedetto, P. Eaton, K. Avery, D. Mavis, M. Gadlage, T. Turflinger, Paul E. Dodd, and G. Vizkelethyd, "Heavy Ion-Induced Digital Single-Event Transients in Deep Submicron Processes", "IEEE Transactions on Nuclear Science", December 2004 and Matthew J. Gadlage, Paul H. Eaton, Joseph M. Benedetto, and Thomas L. Turflinger, "Comparison of Heavy Ion and Proton Induced Combinatorial and Sequential Logic Error Rates in a Deep Submicron Process", "IEEE Transactions on Nuclear Science", December 2005 that it is better to not ignore reality just because strategies used to work for particular technologies. Please explain what happens if all your voters are fed the same clock pulse and if a single-event latchup is caused by a single-event transient hitting this clock at an unfortunate moment? |-------------------------------------------------------| |"That is why we have so many designers using this flow:| | | | it just works." | |-------------------------------------------------------| Wrong. Yours sincerely, Colin Paul Gloster P.S. Though I cited good I.E.E.E. papers, the I.E.E.E. has also published inadequate items related to this topic.Article: 131299
Hi All, I am new to FPGA development , I have encountered a timing closure problem and would appreciate some advice from experienced xilinx guys. My problem is as follows - My system has three major modules - 1) Microblaze - interfaced with an external Flash and SDRAM.(using EMC IP core). 2) Ethernet Interface - using EMC agian this time inteface with an external SMSC MAC/Phy controller - asynchronously. 3) Our internal radio modem IP - Interfaced with microblaze using an FSL bus. When I integrated only the ethernet module with microblaze it works very well and I can interface with a PCs ehternet port and communicate reliably. I have seen the external bus transactions on a Logic ana and it is fine. when I integrated our modem IP in the FPGA. The ehternet post breaks , the externla bus transaction are exactly the same , but I cannot read and write to the external Ehternet MAC Phy chip registers properly even though the Logic analyser doesnt show any change. By changing some timing constriants now we have a working model with both modules working. But any further changes breaks every thing ( The flash and SDRAM inteface as well). Obviously we are right on the edge. How would you tackle such a situation? Any work around? Thanks Rate
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