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
Frank van Eijkelenburg wrote: > I know about the bscan blocks in the xilinx virtex devices (bscan_virtex4 > for instance). With these blocks you can make your own interface by use of > the boundary scan usercode instruction. > > Does something like this exists for altera devices? Yes, but not very well documented. Contact me directly. Best regards, BenArticle: 110076
hi i hav a problem with edk. i created a poject a while ago and everything worked fine. but today i changed some c code and wanted to compile it. i got the following error message : Console Log) At Local date and time: Tue Oct 10 22:53:30 2006 xbash -q -c "cd /cygdrive/c/CodeGeeks/test_edk8/; /usr/bin/make -f system.make program; exit;" started... system.make:173: *** target pattern contains no `%'. Stop. Done! i tired to reinstall everything but it didn't help. any ideas somebody? thanks urbanArticle: 110077
u_stadler@yahoo.de wrote: > hi > > i hav a problem with edk. i created a poject a while ago and everything > worked fine. but today i changed some c code and wanted to compile it. > i got the following error message : > > Console Log) > At Local date and time: Tue Oct 10 22:53:30 2006 > xbash -q -c "cd /cygdrive/c/CodeGeeks/test_edk8/; /usr/bin/make -f > system.make program; exit;" started... > system.make:173: *** target pattern contains no `%'. Stop. > > Done! > > > i tired to reinstall everything but it didn't help. any ideas somebody? > > thanks > urban > Find that system.make file and look at line 173, maybe it is a syntax error that never got exercised until you changed that 'c' program... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 110078
hi well this is the system.make file from line 164 to 179: TestApp_Peripheral_programclean: rm -f $(TESTAPP_PERIPHERAL_OUTPUT) ################################################################# # BOOTLOOP ELF FILES ################################################################# $(MICROBLAZE_0_BOOTLOOP): $(MICROBLAZE_BOOTLOOP) @mkdir -p $(BOOTLOOP_DIR) cp -f $(MICROBLAZE_BOOTLOOP) $(MICROBLAZE_0_BOOTLOOP) ################################################################# # HARDWARE IMPLEMENTATION FLOW ################################################################# the only thing i changed in the c file was i added a xil_prinf(). i actually get this error message with all things i try to do. ( same when i try to generate a net list, a bitstream, libraries.......) everytime the same... urbanArticle: 110079
oen_br wrote:
> > No, you want the continuous clock that
> > generated ALE. In a synchronous system,
> > ALE is an input, not a clock.
>
> Mike, I don't have access to this clock.
>
> Luiz Carlos.
Few years ago I had this asynchronous interface running at ~25Mhz, not
sure for 60Mhz. You may try to load the address asynchronous. No
reason why it doesn't work if you take care setup/hold time
process(ALE, WRITE#)
if (ALE = '1') then
addr <= dtadd;
elsif rising_edge(WRITE#) then
addr <= addr + 1;
end if;
end process;
Article: 110080did you happen to update the cygwin installation? there were some changes in the newer versions of make. /siva u_stadler@yahoo.de wrote: > > the only thing i changed in the c file was i added a xil_prinf(). > i actually get this error message with all things i try to do. ( same > when i try to generate a net list, a bitstream, libraries.......) > everytime the same... > > urbanArticle: 110081
Marlboro wrote: > oen_br wrote: > >>>No, you want the continuous clock that >>>generated ALE. In a synchronous system, >>>ALE is an input, not a clock. >> >>Mike, I don't have access to this clock. >> >>Luiz Carlos. > > > Few years ago I had this asynchronous interface running at ~25Mhz, not > sure for 60Mhz. You may try to load the address asynchronous. No > reason why it doesn't work if you take care setup/hold time > > process(ALE, WRITE#) > if (ALE = '1') then > addr <= dtadd; > elsif rising_edge(WRITE#) then > addr <= addr + 1; > end if; > end process; > For the love of god, would the original poster please post a follow up on what finally makes the thing work? Too many people post questions, get answers, then vanish. Note the WRITE# isn't enough, there's also the READ#. But this code seems perfect, if it works. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 110082
Ray Andraka wrote: > trust me, "Open" is better than "closed" with the notation of something > like "will be addressed in next major release". Once they get a CR > assigned, they go into a black hole. I agree. But I have an even bigger complaint about the whole webcase system. We use a lot of Xilinx parts, and occasionally we run into problems. We generally only use webcase as a last resort, as I hate to clog up their system with simple cases. So sometimes we find a problem and a work-around ourselves. This information should be valuable to Xilinx, so I open a case to tell them this. My frustration is that the basic response is "So you have a work-around? Case closed!" This info goes into the same black hole. My most recent example: We are using a lot of spartan 3E parts, with the BPI mode configuration - which is awesome for our application. The early parts (stepping 0) had an issue where JTAG configuration would fail if the FPGA is set to BPI mode and the attached memory had a valid bitstream. The datasheet says that this has been fixed in stepping 1. We have never had any stepping 0 devices so we ignored this issue, but it turns out that it is still present in stepping 1. This wasted a lot of our time until we figured out what was going on. Xilinx has two suggested work arounds, which both work, but weren't good for our application. Now we are in production and the JTAG interface is not needed (as it was used for development only), so this is no longer an issue for us. I figured that Xilinx would like to know that this issue was not fixed in stepping 1, and that they still have an issue with their silicon, so I opened a webcase. But I basically got the response I mentioned previously: "So this isn't a problem for you? Case Closed!" I opened the case in August, and the engineer ran an example design himself and then ended the case with: "I let the Spartan group know that this problem still exists in Stepping 1 parts. They are looking into why this is not fixed. Since you are ok with the workaround and expressed that this is not a problem. I am going to go ahead and close this case. Please feel free to open up additional cases if need be. Thank you." No, it isn't a problem for us, anymore, but there should be some sort of errata posted ASAP so that other customers do not run into the same problems we did. I gave it some time, but I still don't see anything, so I am posting here. Xilinx's system is broken, as they have no good means for customer feedback. So I am hoping that comp.arch.fpga might work better than webcase? Jason Daughenbaugh http://www.advanced.proArticle: 110083
rickman wrote: > jacko wrote: > > all instructions are load -> alu -> store (using the 1 memory bus) > > this would make a two cycle minimum. for 2 memory accesses. > > each memory access takes 2 cycles, this is due to 1 cycle data out or > > in settling time before 1 cycle latching time. this allows cheap > > external memory use, internal use could reduce mem io to 1 cycle, but > > not designed in yet. > > so total = 4 clock cycles so far. > > then 2 instructions come in one word so 2 cycles for fetch but only 1 > > equiv cycle per instruction. > > so grand total of 5 cycles per instruction. > > > > is that clearer? the two cycle memory access also makes for an easier > > WAIT pin which halts the processor after the current memory access. > > memory access wait state insertion would have to occur via clock > > division. > > That is a big difference. My design only runs on internal FPGA memory. > It is intended to be a chip controller, not a general purpose CPU. > > > > I think it may work, got rid of many logic errors by simplyfying some > > logic and changing the external bus, moved to 5 cycle per instruction > > throughput in design while maintaining low complexity. This required > > the removal of RAS, CAS addressing easy direct support, but SRAM is > > best at 128KB maximum memory size ( except when using CS[1] to isolate > > stack memory from program and data memory. (( CS[0] selects program=0 > > or data=1 memory.but no dictionary extension can occur if CS[0] is used > > like this. )) > > > > cheers. > > > > p.s. when you must simply fit in 330 LEs then this is whats needed. > > What is the application for this design? 1. Open and Free Specification IP 2. For the hell of it 3. 2007 Christmas toy market, investigating options 4. 8-bit replacement of low complexity 5. 32 and 64 bit options should not be that hard to engineer. need to find best utility for extra 16 or 48 bits in instruction word. 6. test before manufacture in full custom as a 44-pin QFP. there may be others. Any interested Fab $ 0.25 per chip royalty with right to use any utility ROM images and more complicated 32 and 64 bit technologies. cheersArticle: 110084
I generated a fifo with block rams with two independent clocks and a symmetric widths and depths. the fifo manual digrams state that with read enable high the data can be read out of the fifo every clock cycle. The wr_en signal is running at a half of the write cycle frequency .i.e the valid data is present on the input bus every second cycle of write clock. Now once the data has been written I disable the wr_en . I enable the read enable and the signal is kept at constant high till the fifo becomes empty. I simulated the fifo and it turns out that the fifo ouputs the data every second cycle with a constant high on the rd_en pin. Is there something to be tweaked to make it output every clock cycle or is that the peak performance?Article: 110085
If your clock rate is reasonable, then I suspect incorrect timing (set-up and hold) between the WE and the write clock, so that you are actually writing on each clock edge (although you want to write only on every other one.) That means you write every word twice, and thus it looks as if the reading is at half speed. Peter Alfke, Xilinx ============= nbg2006@gmail.com wrote: > I generated a fifo with block rams with two independent clocks and a > symmetric widths and depths. the fifo manual digrams state that with > read enable high the data can be read out of the fifo every clock > cycle. > The wr_en signal is running at a half of the write cycle frequency .i.e > the valid data is present on the input bus every second cycle of write > clock. Now once the data has been written I disable the wr_en . I > enable the read enable and the signal is kept at constant high till the > fifo becomes empty. > I simulated the fifo and it turns out that the fifo ouputs the data > every second cycle with a constant high on the rd_en pin. > > Is there something to be tweaked to make it output every clock cycle or > is that the peak performance?Article: 110086
Brad Smallridge wrote: > Let's say at t=0nS the FPGA issues a write > enable along with the write address. > > I have a separate DCM clocking the SRAM and > say for setup purpose I delay this clock by > 4 ns. So at t=4nS, the SRAM has a write command > and the write address. > > At t=20nS, the FPGA does a read at a specified > read address. This gets clocked into the SRAM > at t=24ns. > > At t=40ns the FPGA issues the write data, > according to the staggered data delivery > architecture of the ZBT or NoBL SRAMs. > > At t=44 the SRAM gets another clock. Let's > say it's another write enable and address, > although it doesn't matter. > > After Tco(time clock to output) about 3ns, > or at about t=47ns, the SRAM is outputing data > for the read clock at 24ns. > > There's the issue. The FPGA is outputing data > from t=40ns to t=60ns and the SRAM is outputting > data from 47 ns to perhaps 67ns creating a > collision on the bidirectional lines. > > I have thought of minimizing this affect by > using a clock pin that is negatively delayed > by the FPGA clock, something of the order > of Tco, but it doesn't seem right that I should > have to split hairs like this. Isn't the point > of the ZBT architecture is so you can have write > and read effortlessly meshed? Yes, but you made it complicated again be delaying the clock. The ZBT is designed to have a full clock cycle of setup. If anything you need to have a negative delay on the clock to avoid hold issues. But in principle the ZBT interface is design for SRAM an FPGA using the same undelayed clock. At t=0 you cycle the clock and simultaneously change address and set the command to read. The SRAM clocks in whatever the FPGA has output before. At t=20 the the SRAM clocks in your read command, you simultaneously set the outputs of the FPGA to a write command. At t=40 the SRAM clocks in your write command and starts driven the output At t=47 the SRAM read data will be on the bus At t=60 the FPGA can latch the read data and start driving the bus, the SRAM stops driving it. Bus contention only occurs in the time difference between the FPGA clock_to_out and the SRAM clock_to_Z times. Application note: http://www.xilinx.com/esp/wired/optical/xlnx_net/zbt_sram.htm Kolja SulimmaArticle: 110087
Frank van Eijkelenburg wrote: > The project wizard is creating the application and > library directories in location B (while the workspace is at location A). > > Who knows the solution for this problem (or is it not possible)? It's been a while, but just looking back at the directory structure of my last NIOS project, I have... PROJECT_ROOT \_software (containing NIOS project) \_synth (containing Quartus project, include .ptf) The workspace, which has very little to do with the project itself, but is rather a legacy of eclipse if I understand correctly, is in a completely different place altogether, and is not archived as part of the project itself - mainly because different people have their own workspaces with different files and/or absolute paths. It's a real pain in the butt IMHO. So yes, it should be possible, but don't ask me how - though I didn't do anything special!?! Maybe I didn't use the 'wizard'?!? Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 110088
Mark McDougall wrote: > So yes, it should be possible, but don't ask me how - though I didn't do > anything special!?! Maybe I didn't use the 'wizard'?!? I do recall re-creating the syslib many, many times and it definitely didn't try to create the project in the .pft directory... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 110089
I posted a service request with Altera on this, but I thought I would see if anyone else has seen this problem. I have written a small 8-bit microcomputer system for my Altera DE2 board. The system has 16kB ROM that I preinitialize with an intel .hex format file. The design takes quite a while to fit because I want to operate it at a relatively high clock rate (100MHz), so I turned on smart-compile. Now that the basic hardware is functioning, and I am only changing the ROM image, I would expect to simply recompile and let Quartus read in the new .hex file. However, when I try to recompile, I get an error: Internal Error: Sub-system: QATM, File: qatm_mif_update.cpp, Line: 554 RAM/CAM MIF reconfig failed Quartus II Version 5.1 Build 216 03/06/2006 SJ Web Edition Service Pack Installed: 2 Note, the fitter doesn't (seem) to have a problem reading the .hex file. I can manually rerun the fitter, and it appears to work just fine. I believe the fitter is working properly because the address patterns seems consistent with a hang - not an uninitialized memory. This is on a Windows XP workstation. The project files are mounted from a file server on drive Y:. Thanks!Article: 110090
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:euumi29ukmsmbgg5fvq70k52nsudt3mn6d@4ax.com... > On Tue, 10 Oct 2006 00:05:25 -0500, "GPE" > <See_my_website_for_email@cox.net> wrote: > >>OK -- our old label maker is on the fritz and parts are no longer >>available.... >> >>Does anybody make a label sized for PALS such as 16V8's in a DIP package >>that can be used in a laser printer? >>The size we were using with our old printer was 0.2" x 0.8". 0.25" wide >>is >>too big for a 0.3" DIP and I'd prefer not to cut each and every one of >>them. >> >>Thanks, >>Ed > > http://uk.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU=463802 > > Should also be available from Newark in the US. > > - Brian > Checked on that label -- it's discontinued. However, there is a replacement from Tyco - Part number 301-LE. Perfect for PAL labels and can be fed in a laser printer. But - nobody stocks them. Thanks anyways, EdArticle: 110091
Where did you install ISE? Is your environment set-up? You shoul modify your .bashrc file to automatically launch the settings.sh which is found in your Xilinx ISE main directory. Henrik Pedersen wrote: > Sylvain Munaut wrote: > > > Henrik Pedersen wrote: > >> GaLaKtIkUs? wrote: > >> > >>> Try to type in a shell: comxlib --s mti_se -arch all -l all -lib all -w > >>> -smartmodel_setup > >>> If it doesn't compile tell me the exact error message. > >>> Be sure that the modelsim's binary files are accessible (update you > >>> PATH environment variable) > >>> > >>> On Oct 8, 11:08 pm, Henrik Pedersen <henrik.kir...@gmail.com> wrote: > >>>> GaLaKtIkUs? wrote: > >>>>> Hi, > >>>>> After you got the libraries compiled using the compxlib tool (included > >>>>> in ISE), you shouldn't get any trouble. > >>>>> Please precise the exact problem you encountred > >>>>> On Oct 8, 9:47 pm, Henrik Pedersen <henrik.kir...@gmail.com> wrote: > >>>>>> Hey there > >>>>>> I have a lot of trouble finding directions/guides/manuals on how to > >>>>>> get subject working. > >>>>>> Anyone able to point me in the right direction ? > >>>>>> HenrikI'm a step further from that. > >>>> What libs should i compile. > >>>> > >>>> Let me resume for a moment. > >>>> Downloaded WebPack 8,2,03i and installed it. > >>>> Done a few recomended jumps and it works. > >>>> > >>>> When i click "Simulate Behavorial" i get a error saying: > >>>> Model technologies vsim cannot be found be Project navigator. .... > >>>> > >>>> Where do i start ? > >>>> > >>>> Henrik > >> > >> > >> Tried above solution with the folowing result: > >> > >> ./compxlib --s mti_se -arch all -l all -lib all -w -smartmodel_setup > >> ./compxlib: error while loading shared libraries: > >> libPersonalityModule.so: cannot open shared object file: No such file or > >> directory > >> > >> The module in question is located in the same directory. > >> What would be a logical next step to try ? > > > > . /path/to/ise/settings.sh > > > > (the dot and the following space are important !) > > > > Sylvain > > Not sure on the exact syntax directory to execute the command. > > Could you be a little more specific, please ? > > HenrikArticle: 110092
>Hi Austin, >I'm confused too. Anyway here's what the Datasheet says: >"The rules guiding the use of DCI standards on banks are as >follows: >1. No more than one DCI I/O standard with a Single >Termination is allowed per bank. >2. No more than one DCI I/O standard with a Split >Termination is allowed per bank. >3. Single Termination, Split Termination, Controlled- >Impedance Driver, and Controlled-Impedance Driver >with Half Impedance can co-exist in the same bank." >-- Spartan 3 Datasheet -yy "Austin Lesea" <austin@xilinx.com> wrote in message news:45293220.9090106@xilinx.com... >I agree, > > Those rules ARE confusing. > > I will ask tomorrow am at work. But I know from the way the IOB is > designed, that the ONLY limitations are the Vcco has to be the same (for > all standards in a bank), and the choice of DCI impedance (ie 50 ohms) > will mean that all series terminated drivers in the back (eg LVDCI) will > be 50 ohms, and all split terminated inputs (or outputs) will also be 50 > ohms (100 ohms to Vcco, 100 ohms to ground). > > Once the referencve resistors are set in value, then the choices of 1/2, > 1, and 2X the reference impedance are fixed in actual value. > > Perhaps the rules are implying that you can not have a 50 ohm, and a 68 > ohm reference DCI standard in the same bank? This does make sense, as > there is only one DCI controller per bank. > > Austin > Austin, What did you find out about this? Is LVDS_25_DCI and SSTL2_II_DCI allowed in the same S3 bank? Thanks, BobArticle: 110093
Thomas Stanka wrote: > scott moore schrieb: > >> Does anyone have experience with antifuse fpgas? Are they lower cost >> than static ram fpgas? > > Define lower cost *g*. Cost per device? Cost from the equipment view? > You need generally more money per device for same complexity and have > additional costs for the programming. But your equipment needs only one > device, reducing costs from the equipment point of view. You need to > think about a lot of parameters, before you could say if antifuse fpgas > have lower or higher costs. I guess most designs are cheaper with > ram-based fpgas. > > bye Thomas > Per device. One obvious cost savings is the lack of need for an EEPROM to load the device. However, I was just referring to the raw part cost as compared to an equivalent gate count chip between the two technologies. Disregarding NRE. The motivation for the question is that there are plenty of places to look up current SRAM fpga prices on the web, but so far, no obvious prices for antifuse. However, I have come across some cost/performance studies on the web, and the upshot appears to be that the price per gate was roughly equivalent at the time of those studies. I guess its (again) one of those fortunate or unfortunate effects of the market. Antifuse should be inherently cheaper per gate, due to better density, but the sram fpgas have the advantage of volume. Scott MooreArticle: 110094
Kolja Sulimma wrote: > radarman wrote: > >> Peter, >> Reprogrammability, and testing, aren't an issue once the design is >> stable. > > I believe that Peter was talking about chip test during manufacturing. > You can not test an antifuse before shipping it to the customer. > Therefore it is impossible to build large antifuse FPGAs. > (Yield has an exponentian dependency size) > > > Kolja Sulimma I don't see testability as a barrier. Your yield is not dependent on the good or bad design of the customer (as it is in custom ICs), so the design as burned is testable. The design flow becomes more like an ASIC, with the customer providing bits and vectors. All the maker cares about is the go/no go for the device. It certainly argues for the maker getting more involved in the programming process, and judging from typical makers web sites, that is exactly what they do (Actel, etc.). Scott MooreArticle: 110095
The smaller size of antifuse FPGAs is largely a myth. Even though the antifuse itself is small, there is an on-chip overhead to direct the programming voltage and current to it. But the market has clearly spoken against antifuses, and it was not for lack of trying. Texas instruments was at one time the second source for Actel, so it was not for lack of manufacturing expertise either... Xilinx also once had an antifuse program (XC8100) but gave up on it: too many problems, too little reward... The same engineering team then designed Virtex, a much more rewarding undertaking. Peter Alfke ============== scott moore wrote: > Thomas Stanka wrote: > > scott moore schrieb: > > > >> Does anyone have experience with antifuse fpgas? Are they lower cost > >> than static ram fpgas? > > > > Define lower cost *g*. Cost per device? Cost from the equipment view? > > You need generally more money per device for same complexity and have > > additional costs for the programming. But your equipment needs only one > > device, reducing costs from the equipment point of view. You need to > > think about a lot of parameters, before you could say if antifuse fpgas > > have lower or higher costs. I guess most designs are cheaper with > > ram-based fpgas. > > > > bye Thomas > > > > Per device. One obvious cost savings is the lack of need for an EEPROM > to load the device. However, I was just referring to the raw part cost > as compared to an equivalent gate count chip between the two > technologies. Disregarding NRE. > > The motivation for the question is that there are plenty of places to > look up current SRAM fpga prices on the web, but so far, no obvious > prices for antifuse. > > However, I have come across some cost/performance studies on the web, > and the upshot appears to be that the price per gate was roughly > equivalent at the time of those studies. > > I guess its (again) one of those fortunate or unfortunate effects of > the market. Antifuse should be inherently cheaper per gate, due to > better density, but the sram fpgas have the advantage of volume. > > Scott MooreArticle: 110096
Hi , I need either the ARMv6 ISA or the ARMv7-A ISA doc. Please help Thanks, VitsArticle: 110097
radarman wrote: > Ben Twijnstra wrote: >> Michael Kraemer wrote: >> >>> Actually I cannot understand why Altera is so generous to give away >>> this software for free, which I appreciate a lot, and then attach such >>> restrictions. Anyway, this is perhaps the wrong question if one gets >>> something for free. >>> >> Well, it's not entirely Altera's fault. The FlexLM license software they >> _link_ (i.e. they don't have the source code) in has a function that >> queries the validity of a certain feature name based on the feature name, >> the current date, software version etc. The linked-in FlexLM bit then >> refuses to validate _ANY_ feature if the system clock has been set back, >> and there you go. >> >> On the other hand, many customer calling me with this problem tend to find >> some bug in their overall system (network, application, whatever), so from >> a sysadmin standpoint it could actually be positive that this check is >> there (ducks and runs). >> >> In the past I have questioned Altera Tools Marketing's decision to have a >> license check in the Free Edition at all, but I do understand their reasons >> for it - they want to know which sites are active and which ones are not. >> >> Best regards, >> >> >> >> Ben > > I believe the reason is that you can convert the "free" edition into > the "full" edition by buying a license with no need to do a full > reinstall. However, I understand there are some problems with that > approach. > Personally, I don't see why they have a licensing system at all, even on the full package, or why they charge for the full package. It would be much easier for users if the FPGAs cost very slightly more (to be fair, the increase should be on larger FPGAs, and only when bought in small quantities), and the software should be free. I fully understand why Altera would like it to be registered in some way, and to track who is using it, but letting users use it freely would remove all the hassles associated with licensing, node locks, battles with "FlexLM", moving computers, and so on. In recent times I've had a couple of customers battle with licensing issues (not with any FPGA-related software) - the wasted time and effort has cost far more than the software licenses in the first place.Article: 110098
scott moore wrote: > > I don't see testability as a barrier. Your yield is not dependent on the > good or bad design of the customer (as it is in custom ICs), so the > design as burned is testable. The design flow becomes more like an ASIC, > with the customer providing bits and vectors. All the maker cares about > is the go/no go for the device. It certainly argues for the maker > getting more involved in the programming process, and judging from > typical makers web sites, that is exactly what they do (Actel, etc.). Where that matters, is in the impacts of < 100% yield. You can't really mount the devices before programing, and so suffer another handling step. Then you ideally need to be able to decide which devices are duds _before_ you mount them on your expensive PCB (that means costly vector testing), and finally, who pays for the dud's ? I think only TI still makes OTP CPLDs (Atmel have a couple of MilSpec ones alive )- everyone else has gone to EE, and that's on small/simple devices. Looking at Actel's latest push, I see their FLASH devices are pushed as low power (not their antifuse), and Actel claim the QuickLogic PolarPro benchmark as the worst battery life of the low power alternatives. http://www.actel.com/products/igloo/ Pretty much places any OTP device in the NFND bucket ? -jgArticle: 110099
Mark McDougall wrote: > Frank van Eijkelenburg wrote: > >> The project wizard is creating the application and >> library directories in location B (while the workspace is at location A). >> >> Who knows the solution for this problem (or is it not possible)? > > It's been a while, but just looking back at the directory structure of > my last NIOS project, I have... > > PROJECT_ROOT > \_software (containing NIOS project) > \_synth (containing Quartus project, include .ptf) > > The workspace, which has very little to do with the project itself, but > is rather a legacy of eclipse if I understand correctly, is in a > completely different place altogether, and is not archived as part of > the project itself - mainly because different people have their own > workspaces with different files and/or absolute paths. It's a real pain > in the butt IMHO. > > So yes, it should be possible, but don't ask me how - though I didn't do > anything special!?! Maybe I didn't use the 'wizard'?!? > > Regards, > Can you tell me what the location of your eclipse workspace is? Regards, Frank
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