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
<fpga_toys@yahoo.com> wrote in message news:1140557635.764072.297020@g44g2000cwa.googlegroups.com... > Or a throttle control system or ABS system that fails causing you and > your car/truck/suv to be in harms way resulting in injury. Or a fire > alarm system that fails in a a major high rise. Or a train crossing > system for gating pedestrian and vehicles at a major crossing where > fast trains frequent a blind track access. There are lots of systems > that can cause harm with failure. How about a new disclaimer: "Xilinx products are not intended for use in traffic light controller applications. Use of Xilinx products in such applications without the written consent of the appropriate Xilinx officer is prohibited." Maybe then the first-year students would stop pestering us :) -Ben-Article: 97426
fpga_toys@yahoo.com wrote: > Isaac Bosompem wrote: > > For me the biggest hurlde of learning to utilize VHDL was programming > > my brain to not think of it as a programming language. Then everything > > began to fall into place. > > Interesting discussion. In a prior discussion regarding "programming" > or "designing" with C syntax HLL or HDLs, it was interesting how many > people took up arms that they could do everything in VHDL or Verilog > that could be done with a C based fpga design language such as > Celoxica's Handel-C, Impulse-C, FpgaC or similar tools. That arguement > was that VHDL/Verilog really isn't any different that C based HLL/HDL's > for FPGA design, and frequently with the assertion that VHDL/Verilog > was better. > snipping > > So is an fpga design in VHDL/Verilog hardware, and the same realized > equiv gates written in in Celoxica's Handel-C software just because of > the choice of language? Or is a VHDL/Verilog design that is the same > as a Handel-C design software? It reaslly depends on the style of design and synthesis level. Traditionally Synopsys style DC synthesis performed on RTL code is hardware design more or less no matter how the RTL is prepared, even javascript if thats possible. But HandelC and the other new entrants from my knowledge are usually based on behavioural synthesis, thats the whole point for their existance is to raise productivity by letting these tools figure how to construct the RTL dataflow code so that mere mortal software engineers don't have to be familiar with RTL design. They still find out about real harware issue sooner or later though. On the ASIC side, Synopsys BC didn't fare too well with hardcore ASIC guys, better with system guys. Since FPGAs let software, system guys into the party, BC style synthesis is going to be far more acceptable and widespread, cost of failure so much lower than with ASICs. As for is it HW or SW, I decline, but the ASIC guys would tend to call BC design too software like given early results, I don't think their opinion for C style behavioural design has changed any either. If the end result of BC style design produces results as good as typically achieved by DC synthesis then it is everybit as good as hardware but does it produce such results? In hardcore hardware land we expect to drive upwards of 300MHz cycle rates and plan a hardware design onto a floorplan but I wouldn't expect such performance or efficiency from these BC tools. Do they routinely produce as good results, I very much doubt? Replacing RTL for behavioural design may raise productivity but it is not the same thing as replacing assembler coding for HLL coding IMHO given the current nature of OoO cpus.Article: 97427
Hi, I am working with JBits 2.8 & the RC1000pp board. I have a system up & running where i can configure the RC1000pp board using JBits 2.8. This RC1000pp board contains a XCV1000 FPGA. I want to achieve the same system but with RC1000pp board with a XCV400 instead of a RC1000pp board with a XCV1000 . When i try to download configuration data to the XCV400 via JBits it fails. I am using the same RC1000pp drivers as i did for the XCV1000 system. My own feeling is that the I am using incorrect drivers for the system but i have had no luck locating a correct driver. If anybody has a driver for the board or any comments, please let me know. Thanks, ColinArticle: 97428
>can you perform a timing simulation including timings and synthesis >results >of your FPGA ? You could at least see if timings of >DQS, DQ, RasN/CasN/WeN/CsN , ClkP, ClkN are correct when >coming out of the FPGA ... I could perform only simulation using ModelSim. With ModelSim timings of all signals which you mentioned are correct. With a real FPGA I could look only at RasN/CasN/WeN/CsN signals when they come out of the FPGA. I think I did not mentioned my clocks. The board has 3 FPGA clocks - 40MHz, 66MHz and 125MHz. Currently I am using 125MHz FPGA clock (input_clk). Then I have 2 DCMs from which I get clk, clk90 and clk270. They both have fixed CLKOUT_PHASE_SHIFT, low DLL_FREQUENCY_MODE and sure 8.0 CLKIN_PERIOD. After using FDDRRSEs I generate ddr_clks from clk. I tried to use different PHASE_SHIFT values but it did not really help.Article: 97429
Hi, Maybe you all know... if not... take a look to <Path_Were_is_Xilinx>/Xilinx/vhdl/src/unisims/unisim_VITAL.vhd there are the vhdl VITAL source code for unisim library used for simulation purpose. there are DIFF_OUT, IDDR... almost all SandroArticle: 97430
<fpga_toys@yahoo.com> wrote in message news:1140557635.764072.297020@g44g2000cwa.googlegroups.com... > > Or a throttle control system or ABS system that fails causing you and > your car/truck/suv to be in harms way resulting in injury. > I remember the throttle stuck open on my old MR2. The accelerator cable frayed where it joined the throttle body housing and got stuck in the bowden cable sheath. The return spring couldn't close the thing. Had to drive around on the ignition switch for a day or two! Which reminds me, I've found a good interview question for hardware engineers is to ask candidates if they can change the brake pads on their car. It separates the soft from the hard! :-) Cheers, Syms.Article: 97431
Hi can any body explain i am working on ddrsdram controller .in sample synthesis script i got like this while giving timing setings in assinment editor (quartusII software) pls explain what is the meaning of under lines i.e create clk period10_waveform{0,5} find (port,"clk") setclock_skewclk-minus uncertinty0.25-plus uncertinty0.25 dclk_arrival is the arrival time of dclk relative to clk input and include tck_dealy cell create_clock-period10_waveform{0,5}find(port,"dclk") set_clock_skew dclk_dealy DCLK_ARRIVAL-minus_uncertainty0.25, plus_uncertainty pls anybody tel what is that how to give ?explain all the things? advanced thanks venkiArticle: 97432
>Is that the famous one about the X-ray machine that irradiated people >with 100X dose? Yup. >That case you could call imaging, but the consequences of the particular >failure (lethal radiation doses) are a little different from, for >instance, the failure of a blood pressure machine. Is your blood pressure machine plugged into the wall? Very sick people often have electrodes attached at critical places. A friend was jack-of-all-trades involving electronics at Mass General Hospital. He reported that one of the really nasty things that happens all too often to gear he worked on is that saline solution would get dumped down the air vents. When he told me that story, I was thinking of long term problems. Short term might be interesting too. How much isolation does your magic opto-isolator chip provide when covered with salt water? Are we being paranoid enough? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 97433
JJ wrote: > It is kind of ironic where we have come from. It is too easy to think > of a HDL as ASIC and HDL as FPGA perfoming as well forgetting about any > potential logic upsets. I wonder how some of the FPGA based MP3 players > behave on air flights, or even how reliable laptops are up there. So > FPGAs and large cache CPUs are more similar as the SRAM area dominates. > I am under the impression though that the BRAM is the usual generic 6/8 > T cell with modest Cs and the config bits are entirely bigger with far > more robust cells given the nature of the beast. I would expect the > logic to be far more reliable than the data it is processing. I actually have to bite my tongue to avoid the flamebait when the hardware guys here starting beating their chests about how reliable their engineering is and how full of shit software engineers work is from a quality and reliability perspective. I live in colorado, where there is enough altitude that SEU's are a problem, and just chukle thinking about how much worse it is in Vail. I actually wonder sometimes if people really have a right to blame Microsoft for all the lockups at these altitudes. I really have to wonder given the SEU problem, if any FGPA engineer understands zero defect engineering for financial and hi-rel applications. Having spent over a year working at a bank in So. Cal in the late 1970's, I got something of a dose of zero defect software engineering, then worked beside a couple flight systems engineers in the late 1980's that also did a stint at zero defect software development from the government side of the business. I've also wondered what would happen if I took a neutron emitter to vegas to play the slots :) Or to Blackhawk. Do they disallow big wins when the machine locks up or glitches? Do they have detectors at the door? Given the rosetta numbers Xilinx gathered at this altitude, it seems that a few thousand slot machines with FPGA machines in them would be a huge reliability problem at Blackhawk .... or even a lot of small micros with static rams. Does the gaming commissions even consider the hardware might be less reliable than the software that they also strictly regulate like the medical folks?Article: 97434
> I think > what is suprising to some, is that low level software design is long > gone, Back in the old days, it was common to build FSMs using ROMs. That approach makes it natural to think of the problem as software - each word in the ROM holds the instruction you execute at that PC plus the right external conditions. That still seems like a good approach to me Seems pretty low level too. I've done a reasonable amount of hack programming where I count every cycle to get the timing right. I could probably have done it in c, but I'm a bottom up rather than top down sort of person. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 97435
Hello, I am using stratix fpga for a design of mine and i am using Bank 4 for GTL interface and so that IO bank is supplied with 1.5 V and Vref is 1v. But this bank has some of the configuration pins and TDO is one of them. It is said that TDO reqiures 3.3 V in the configuration datasheet. But since this IO bank is given 1.5 V. So this may create problem in configuration. Can you please suggest a solution for this? Thanks and regards PraveenArticle: 97436
Hi ada, yes, Modelsim is the point. You can perform a timing simulation using Modelsim that is you have to include the FPGA timing information file (=2Esdf) and the FPGA netlist (.vho) in your simulation. You have simulated the VHDL description but not the synthesis result, am I right ? Try to find out how to perform a timing simulation because that kind of simulation shows real behavior of your FPGA. Rgds Andr=E9 > I could perform only simulation using ModelSim. With ModelSim timings of > all signals which you mentioned are correct. With a real FPGA I could look > only at RasN/CasN/WeN/CsN signals when they come out of the FPGA. > > I think I did not mentioned my clocks. The board has 3 FPGA clocks - > 40MHz, 66MHz and 125MHz. Currently I am using 125MHz FPGA clock > (input_clk). Then I have 2 DCMs from which I get clk, clk90 and clk270. > They both have fixed CLKOUT_PHASE_SHIFT, low DLL_FREQUENCY_MODE and sure > 8.0 CLKIN_PERIOD. After using FDDRRSEs I generate ddr_clks from clk. I > tried to use different PHASE_SHIFT values but it did not really help.Article: 97437
JJ wrote: > On the ASIC side, Synopsys BC didn't fare too well with hardcore ASIC > guys, better with system guys. Since FPGAs let software, system guys > into the party, BC style synthesis is going to be far more acceptable > and widespread, cost of failure so much lower than with ASICs. As for > is it HW or SW, I decline, but the ASIC guys would tend to call BC > design too software like given early results, I don't think their > opinion for C style behavioural design has changed any either. As a half EE and CSc guy from the 1970's I spent more than a few years doing hard core assembly language systems programming and device driver work. The argument about C for systems programming was much louder and much more opinionated about "what real systems programmer can do". As an early Unix evanglist and systems programmer, it didn't take long to discover that I could code C easily to produce exactly the asm I needed. As the DEC systems guys and the UNIX systems guys war'ed over what was best, it was more than fun to ask them for their rosetta assembly language, and frequently knock out a faster C design in a few hours, for a piece of code that took weeks to fine tune in asm. It was almost always because they got fixated on micro optimization of a few loops, and missed the big picture optimizations. Rewriting asm libraries in C as we ported to microprocessors and away from PDP11's was seldom a performance hit at all. I see similar things happening with large ASIC and FPGA designs, as the real performance gains are in highly optimized, but more complex architectures, and less in the performance of any particular FSM and data path. Doing the very best gate level designs, just like the very best asm designs, at some point is just a distraction, when you start looking at complex systems with high degrees of parallelism and specialized functional units where the system design/architecture is the win, not a few cycles at the bottom of some subsystem. The advantage of transfering optimization knowledge into HLL tools, is that they do it right EVERY time after that. Where the same energy spent optimizing one low level design is seldom leveraged to other designs. Because of this HLL programming languages routinely deliver three or four nines of the performance hand coding will do, and frequently better as all optimations are automatically taken and applied, where a hand coder would not be able to. We see the same evolution in bit level boolean design for hardware engineers. A little over a decade ago, all equations were hand optimized .... today that is a lost art. As the tools do more of it, probably in another decade it will no longer be taught as a core subject to EE's, if not sooner. There are far more important things for them to learn that they WILL actually use and need. That will not stop the oldie moldies from lamenting how little the kids today know, and claiming they don't even know their trade. The truth is, that the kids will have new skills that leave the Dino's just that. > If the end result of BC style design produces results as good as > typically achieved by DC synthesis then it is everybit as good as > hardware but does it produce such results? In hardcore hardware land we > expect to drive upwards of 300MHz cycle rates and plan a hardware > design onto a floorplan but I wouldn't expect such performance or > efficiency from these BC tools. Do they routinely produce as good > results, I very much doubt? Replacing RTL for behavioural design may > raise productivity but it is not the same thing as replacing assembler > coding for HLL coding IMHO given the current nature of OoO cpus. I believe, having seen this same technology war from the other side, that it is not only the same, but will actually evolve better because the state of the art and knowledge about how to take optimizations and exploit them is much better understood these days. The limits in software technology and machine performance that slowed extensive computational optimizations for software compilers are much less of a problem with VERY fast cpus and large memory systems today. Probably the hard part will be yanking the knowledge set to do a good job from the minds of heavilly protesting EE's worried about job security. I suspect a few, will see the handwritting on the wall, and will become coders for tools, just to have a job.Article: 97438
FSL links are connected to MB core and can not access the OPB the OPB_MCH_SDRAM IP core has slave FSL ports so external FSL (XCL) master can access the SDRAM over FSL (but not the rest of OPB bus) so you have options 1) MB software will read FSL and translate it to OPB transaction in software 2) you write your own FSL 2 OPB (master) bridge 3) if you want to access BRAM then you can access the second port of the BRAMs but its rew BRAM port not FSL AnttiArticle: 97439
FSL links are connected to MB core and can not access the OPB the OPB_MCH_SDRAM IP core has slave FSL ports so external FSL (XCL) master can access the SDRAM over FSL (but not the rest of OPB bus) so you have options 1) MB software will read FSL and translate it to OPB transaction in software 2) you write your own FSL 2 OPB (master) bridge 3) if you want to access BRAM then you can access the second port of the BRAMs but its rew BRAM port not FSL AnttiArticle: 97440
The speaker at Xilinx presentation at Embedded World asked the crowd: "Has anyone managed to create an FPGA System On Chip design - with first time success?" "I have", was my reply: "... using LEON3 GRLIB!" to be fully honest my response wasnt exactly true. I did manage to get LEON3 system working in FPGA within a few hours, but I dont really recall if first FPGA configuration loaded was actually working or not. Maybe not. But as of today, I could answer the same question with: "Yes I have" - and be really correct this time. Some 20 minutes ago, I started XPS (EDK 8.1 SP1), new project, V4FX-12, click, click, done, changing 3 PIN location constraints (sys_clk, rxd, txd).. save .ucf file, then menu Device->Download and I got a prompt on serial console connected to FPGA board! First time synthesis, first FPGA download, system working. So the first time success is possible! :) AnttiArticle: 97441
Hal Murray wrote: > Back in the old days, it was common to build FSMs using ROMs. That > approach makes it natural to think of the problem as software - each word > in the ROM holds the instruction you execute at that PC plus the right > external conditions. Any of us educated in engineering school in the 1970's probably have more than a few times. On the other hand, I also built a DMA engine out of an M68008 using address space microcoding which saved a bunch of expensive PAL's and board space, plus used the baby 68k to implement a scsi protocol engine to emulate a WD1000 chipset. The whole design took a couple months to production. Having done it the hard way with bipolar bit slices, just gives you the tools to take a more powerful piece of silicon and refine it better. That is the beauty of FPGAs as computational engines today. Looking past what it's ment to do, and looking forward to what you can do with it tomarrow, by exploiting the parallism and avoiding the sequential bottlenecks of cpu/memory designs. Designers that only know how to use a cpu + memory, and lack the skills of designing with lower level building blocks miss the big picture - both at a software and hardware level. > I've done a reasonable amount of hack programming where I count > every cycle to get the timing right. I could probably have done > it in c, but I'm a bottom up rather than top down sort of person. it's not about up or down, its simply learning your tools. for 30 years I've written C thinking asm, and coding C line for line with the asm it produced. For the last couple years, after learning TMCC and taking a one day Celoxica intro seminar, I started writing C thinking gates, just as a VHDL/Verilog engineer writes in that syntax thinking gates. Hacking on, and extending TMCC as FpgaC has only widened my visualization of what we can do with the tool. The things that TMCC/FpgaC does wrong are almost purely masked by the back end boolean optimizer which comes very close to getting it right. Where it doesn't, is because its synthesis rules are targeted at a generic device, and it lacks device specific optimizations to target the available CLB/Slice implementation. That will come with time, but really don't have that big an impact today. Right now we are focused on implementng the rest of the C language that was left out of TMCC, which is mostly parser work, and some utility routine work inside the compiler. That will be completed march/april, then we can move on to back end work, and target what I call compile, load and go work, which will focus on targeting the backend to current devices. With that will come distributed arithmetic optimized to several platforms as well as using carry chains and muxes available in the slices these days. At that point, FpgaC will be very close to fiting designs as current HDL's do .... if you can learn to write C thinking gates. FpgaC will over time hide most of that from less skilled programmers, requiring only modest retraining. The focus will be computing with fpgas, not fpga designs to support computing hardware development. RC. For the last couple weeks we have been doing integration and cleanup from a number of major internal changes, mostly from a symbol table manager and scoping rules fix to bring TMCC inline with Std C scoping and naming, so that we could support Structures, typedef and enum. We've also implemented the first crack at traditional typing in prep for enum/typedef, allowing unsigned and floating point now in the process. Both are likely to be in beta-2 this month. The work I checked in last night has the core code for FP using intrinsic functions, and probably needs a few days to finish. It also now has do-while and for loops, along with structures and small LUT based arrays or BRAM arrays. It currently regression tests pretty well, with a couple minor problems left, including one that cause some temp symbols to end up with the same names. That should be gone by this weekend, as FP gets finished and hopefully unsigned is done too. svn co https://svn.sourceforge.net/svnroot/fpgac/trunk/fpgac fpgac alpha/beta testers and other developers welcome :)Article: 97442
dear all, ** I have been working on i2c programme which is given out by xlinx, i am tring it on libero... sadly its not working even though i worked to my maximum. ** so i changed to hdlworks to downloaded their code that too not working..... **** IS the state machine is dependent to the compiler ? CAN anyone help me on this? regardsArticle: 97443
embyembu wrote: > dear all, > > ** I have been working on i2c programme which is given out by xlinx, i > am tring it on libero... > sadly its not working even though i worked to my maximum. > > ** so i changed to hdlworks to downloaded their code that too not > working..... > > **** IS the state machine is dependent to the compiler ? > > CAN anyone help me on this? > > regards > > Can you provide more details of exactly what you are doing, and what is meant by "not working", do you mean not compiling, not simulating correctly, not synthesising, not working in hardware etc etc?Article: 97444
Last summer mention was made of a DSP / FPGA book by Ray Andraka hitting the (online) shelves this fall: http://tinyurl.com/s4v5s Has this come to pass? Aside from Meyer-Baese's "Digital Signal Processing with Field Programmable Gate Arrays" book, which I found somewhat difficult to read, are there any other FPGA-specific DSP books out there? Thanks! StephenArticle: 97445
ALuPin@web.de wrote: > Hi ada, > > yes, Modelsim is the point. You can perform a timing simulation using > Modelsim that is you have to include the FPGA timing information file > (.sdf) > and the FPGA netlist (.vho) in your simulation. You have simulated > the VHDL description but not the synthesis result, am I right ? > Try to find out how to perform a timing simulation because that kind > of simulation shows real behavior of your FPGA. > > Rgds > Andr=E9 > > > I could perform only simulation using ModelSim. With ModelSim timings of > > all signals which you mentioned are correct. With a real FPGA I could l= ook > > only at RasN/CasN/WeN/CsN signals when they come out of the FPGA. > > > > I think I did not mentioned my clocks. The board has 3 FPGA clocks - > > 40MHz, 66MHz and 125MHz. Currently I am using 125MHz FPGA clock > > (input_clk). Then I have 2 DCMs from which I get clk, clk90 and clk270. > > They both have fixed CLKOUT_PHASE_SHIFT, low DLL_FREQUENCY_MODE and sure > > 8.0 CLKIN_PERIOD. After using FDDRRSEs I generate ddr_clks from clk. I > > tried to use different PHASE_SHIFT values but it did not really help. While you are at it, get the simualation files from DDR vendors (here, for example, is a typical page at Micron) http://www.micron.com/products/dram/ddrsdram/part.aspx?part=3DMT46V128M4TG-= 5B On the left, you'll see a range of available simulation models you can integrate into your test bench. Although this is not the same as a module, it's a lot closer than nothing at all. A module will typically add some jitter and round trip delay, but make sure your design works with a part used on the modules first :) Cheers PeteSArticle: 97446
Hi John, My color is 75%.... And it is a combination of U and V.... I am working on trying to match these two values.....for every transition from one color to the other... On doing so, using the approximate values, I can see that the vectors have straightened abit. But this seems to take a whole lot of iterations to finally set it straight....Article: 97447
Stephen Craven wrote: > Last summer mention was made of a DSP / FPGA book by Ray Andraka > hitting the (online) shelves this fall: > http://tinyurl.com/s4v5s > > Has this come to pass? > > Aside from Meyer-Baese's "Digital Signal Processing with Field > Programmable Gate Arrays" book, which I found somewhat difficult to > read, are there any other FPGA-specific DSP books out there? > > Thanks! > Stephen > No, unfortunately, I am still working on it, and my publisher (elsevier) is sitting on my rather firmly to get it done. Only so many hours per day. They have set a new deadline for me to have it to them by August so that they can get it out in the fall.Article: 97448
Hi , I also had the same problem, but after i patched the UCF for ml310_base_design.zip everything worked fine... One of the questions that I have is where is your DDR (on the PLB or on the OPB)..I have ours set up on the OPB and everything works fine... The other thing that I would recommend is to use one of the designs from the web. http://www.xilinx.com/products/boards/ml310/current/index.html and then try it out before you start using your own. -- Parag king_azman wrote: > hi, > > i'm trying to work with the ddr sdram on the ml310 development board. i > tried creating a simple base system with the ddr using the bsb wizard. > i also changed the ucf file as in the sample file provided. however, i > keep getting 'memory test - failed" when running the generated memory > test program. can anybody help me?Article: 97449
I've had similar problems with MicroBlaze designs (not PPC). I was able to use the memory only after reseting the board after programming. Stephen
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