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
"Eric" <ericjohnholland@hotmail.com> wrote in news:1123303914.495112.241380@g49g2000cwa.googlegroups.com: > Genetic Algorithm pseudo code: > > Problem: Solve 2x+1 = 7 (we know the answer is 3, but work with me) > > Step #1 Generate a Random population of numbers: > > Population = 1, 6, 8, 4 > > Step #2 Chose a fitness function. Ours will be Error = ABS(1-(2x + > 1)/7) > > Error(1) = ABS(1-(2x1+1/7)) = 0.57 > Error(6) = ABS(1-(2x6+1/7)) = 0.86 > Error(8) = ABS(1-(2x8+1/7)) = 1.43 > Error(4) = ABS(1-(2x4+1/7)) = 0.29 > > The number with the smallest Error is closest to the answer. > (Still > with me?) > > Step #3 Repopulate your population based on your fitness function > results. This is the tough part to grasp. We need to normalize all of > the errors so we can get a repopulation percentage. This will help us > get the new population of numbers. > > Take the total of the error 0.57 + 0.86 + 1.43 + 0.29 = 3.15 > > 3.15/0.57 = 5.53 > 3.15/0.86 = 3.66 > 3.15/1.43 = 2.20 > 3.15/0.29 = 10.86 ************** Bunch of quoted text trimmed ********************* > > > Kind of make sense??? > > > Eric > Good lord, that will just confuse them!... Of course you realize that your example algorithm converges a little slower than just guessing until you've guessed the right answer. I say a little slower because what you've described essentially IS just guessing until you happen upon the right answer, with a few extra operations to slow everything down! The magic in a genetic algorithm comes from the SEX, which happens in the crossover that you omitted in step 4 above. You HAVE to come up with a way to combine two 'pretty good' solutions to get another 'pretty good, maybe a bit better' solution. Without that combination step (analogous to sex in the world of biology), you don't have a genetic algorithm at all! Now finding a way to combine two 'pretty good' solutions to come up with a new 'pretty good' solution is sometimes difficult. In your example it would be easy; simply average (or perhaps a randomly weighted mean) the parents to get the offspring. Now that would actually converge to a solution in your example. The mutation part is less important than the sex part, but still needed. But i don't think i've EVER seen mutation implemented as simply making up a wholy new, randomly generated member of the population. That would be no better than (and roughly equivilent to) having a larger initial population. The mutation must be a relatively small change to an existing member of the population. The idea is that your population will, after a few generations, be much better adapted than a randomly generated individual and a small change will have a decent chance of being 'pretty good' too. I don't mean to be insulting or belittle the contribution to the newsgroup, but genetic algorithms are important and your example could easily confuse people. -Rob RylandArticle: 88276
Hi All, I have a state machine which produces control signals (synchronous Reset and Enable) for a synchronous counter. The control signals are generated based on the current state and a 8 bit data input. I am seeing glichtes in both output control signals near the rising clock edges. The 8 bit data input is registered. Is there any way to get rid of the glicthes? The VHDL code looks something like this FSM: process(CurrentState,DataIn,Count,NewFrame,...) begin CntrRst <= '0'; -- counter reset CntrEn <= '0'; -- counter enable case CurrentState is when State0 => if NewFrame = '1' then NextState <= State1; else NextState <= State0; CntrRst <= '1'; end if; when State1 => case Count is when "00000" => if DataIn = x"00" then NextState <= State1; CntrEn <= '1'; else NextState <= State0; CntrRst <= '1'; end if; when "00001" => -- same as above except checking for a different -- DataIn -- All other cases test for different DataIn Values . . . end case; end case; end process; Thanks SudhirArticle: 88277
hi, im hoping to buy the following FPGA development board from Avnet. If anyone got any experiance with it please let me know. Model: SP3E-EVL100 Link: http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D21564%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html thank you. CMOSArticle: 88278
Hello all, I am currently using xilinx modular design flow to develop a simple design. The top level design has an inout port for communicating data between an external memory and fpga. I have implemented the necessary control logic for this port in one of the modules and port mapped the port of the module to the top level inout port. After having done this when I run (ngdbuild -modular initial top.edd) with all the modules instantiated (black boxes only) I receive the following error "ERROR:NgdBuild:456 - logical net '***' has both active and tristate drivers". Can anyone suggest what needs to be done in this regard. ThanksArticle: 88279
<bret.wade@gmail.com> schrieb im Newsbeitrag news:1123944130.789425.98570@f14g2000cwb.googlegroups.com... > Hi Antti, > > You would have had your solution a day earlier if you'd put a little > more effort into the Answers search. Something like "7.1i add external > pin" works for this case. You can't always depend on your posting being > read by the person who wrote the Answer Record. > > There is another FPGA Editor issue that you may run into: > http://www.xilinx.com/xlnx/xil _ans_display.jsp?getPagePath=21667 > > Regards, > Bret > Hi Bret yes you are absolutly right, I could have found the AR myself but I did not instead of spending more time in search for AR (what I did not know to exist) I opened a WebCase and yielled loud at caf - thats not very good, and does not always yield results. I agree that all AR's can be found by entering some 'good' keywords into the search, but its very often that you dont find the AR even if it exists. Maybe its only my dis-ability to find the Xilinx AR's, but it is really not the first time I have not found the specific AR until pointed out by AR number by some Xilinx FAE. Maybe all other people are more talented finding Xilinx AR's, can be. --- I am not seeing problems as described in AR21667, but before the patch for exptpin fix I did see another error during translate, maybe that is fixed with the exptin patch, I still need to check that. Antti PS yes I will try to search more hard on AR and errata stuff in the future, maybe one day I learn the trick to find proper ARs quickly without help from others.Article: 88280
"CMOS" <manusha@millenniumit.com> schrieb im Newsbeitrag news:1124005073.000044.130440@g47g2000cwa.googlegroups.com... > hi, > im hoping to buy the following FPGA development board from Avnet. If > anyone got any experiance with it please let me know. > > Model: SP3E-EVL100 > Link: > http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D21564%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html > > > thank you. > CMOS > To my knowledge there are NO S3e based boards shipped to customers and also virtually no S3e chips sent to 'normal' customers. So there could be no one around with experience with S3e boards as of today. I think the S3e eval boards should start shipping in September, so after that you can expect some comments as well. AnttiArticle: 88281
Ed, That is why I don't like to see these kinds of complaint sessions here on comp.arch.fpga. 1) Antti would have received his answer through the hotline, but as he is an frieend of a friend, things were done to get a response back faster than it would have otherwise. This may have been a mistake. With 250,000 active seats of software out there making designs, we have to support all of them, and try to do so with the same high level of quality. As much as I feel for Antti's situation, I can't respond to everyone. Peter and I would make a terrible hotline response team. Instead, he and I act as "quality assurance" to make sure our responses are meeting the mark, and succeeding. 2) It opens the door for everyone who ever had an issue to add their two cents. Of course we test the new software. In fact, we are adding test cases, and whole new test requirements with every service pack that goes out. Are we absolutely perfect? Not yet (one can hope). Is our software getting more, or less buggy? I think in goes in cycles. Virtex 4 added 100 (that we talk about) new features and capabilities. All of those had to get supported. That is a significant development of new software. For every X lines of code written there is a bug. For every Z bugs fixed, there is a new bug created. Best thing you can do for software is stop adding new features to it, but unfortunately, we can't do that. Moore's Law has three of four more turns of the wheel left in it (in its present form - as far as we can see), so we must continue to do what has made us so successful, innovate. (After 10 nm, no one really knows where we go, but we are certain that programmable logic becomes more valuable, not less, regardless of the technology. Carbon nanotube, organic self assembly, etc. are merely the means to implement the FPGA.) I am not providing you with an excuse, just letting you know what the reality is. We test, and we test a lot. But, with new products, and new features, we can't be perfect, and we provide the fixes on a very timely basis (usually every bug found is fixed in the next service pack, or sooner by a tactical patch). AustinArticle: 88282
Well it is fully asynchronous design - sort of concept-proof, more in demonstration purposes. I know FPGA is not the proper platform for it at all, however everything is working fine, apart that problem. So can anyone help with the problem when the synthesiser optimize the design by throwing buffer elements away? -- AlexArticle: 88283
Which is the preferred way to generate the output clock for a deserializer made with a shift register? For example, let's say I feed a 4-bit shift register with a 500 MHz signal, so that I have to store four bits at 125 MHz into a BRAM (or just latch them). How do I generate this 125 MHz clock? I can't use a DCM because the input frequency is out of range, but if I generate the clock with common logic (e.g. a binary counter or a shift register), how can I be sure that it won't violate the hold/setup times in respect to the four output bits? Thank you! -- asdArticle: 88284
I'm not sure what you mean, the WFIFO/RFIFO datapaths are separate from the IP2BUS_DATA and BUS2IP_DATA signals. The IPIF generated by the IP Import Wizard automatically connects things up internally to get data to/from RFIFO/WFIFO to the bus. Are you planning on using the vacancy/occupancy counters for the FIFOs? I see them working in simulation but running on the hardware, reading each from the processor always returns zero. Empty/Full and the FIFO operations themselves are working in both hardware and software. Paul el_boricua wrote: > > I am simulating a IPIF + user core using the BFM simulation model and > in my test I can succesfully write to the WFIFO (write fifo) and > write to the RFIFO (read fifo) but for some reason the data from the > read fifo doesn't get dumped to the IP2BUS_DATA (Data Bus) is there any > signal that I should assert from the IPIF interface to dumped the data > from the RFIFO to the bus? > > Thanks, > NoelArticle: 88285
Sudhir, so you have two sets of synchronous signals (hopefully synchronized by the same global clock) and you combine them through combinatorial logic to generate 2 control signals for the counters. Obviously, you will generate glitches on these outputs, as a result of prop delay differences in the combinatorial logic. But these glitches occur a few nanoseconds AFTER the active clock edge, and they are, therefore, irrelevant and cause no harm. The beauty of synchronous logic is that inputs need only be stable during the set-up time BEFORE the clock edge. Peter Alfke, Xilinx Applications (from home)Article: 88286
dalai lamah wrote: > Which is the preferred way to generate the output clock for a deserializer > made with a shift register? For example, let's say I feed a 4-bit shift > register with a 500 MHz signal, so that I have to store four bits at 125 > MHz into a BRAM (or just latch them). How do I generate this 125 MHz clock? > I can't use a DCM because the input frequency is out of range, but if I > generate the clock with common logic (e.g. a binary counter or a shift > register), how can I be sure that it won't violate the hold/setup times in > respect to the four output bits? Howdy, Two ways to solve this: 1. If the 125 MHz "clock" isn't needed for a considerable amount of logic, strongly consider generating and using a clock enable that is actually in the 500 MHz domain. 2. If you have a bunch of logic that needs to run at 125 MHz, the DCM has a CLKIN_DIVIDE_BY_2 mode to handle higher frequencies: http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/cgd/cgd0064_25.html Have fun, MarcArticle: 88287
Hi guys. An intesresting problem occured when I used "more than three" signals in always block sens list. XST (ISE 6.1i) reported the following error: ERROR:Xst:1468 - dummy.v line 25: Unexpected event in always block sensitivity list. Same code is successfully compiled & simulated in MOdelSim5.7SE. What kind of problem is this ? Related to parser/editor/etc ?? //-------- C O D E - C O D E --------/// module dummy(x); output x; assign x = 1'b0; reg a,b,c,d; reg z; initial begin a=0; b=0; c=0; d=0; z=0; #100 $stop; end always #10 a=~a; always #15 b=~b; always #20 c=~c; always #5 d=~d; always @(posedge a or posedge b or posedge c or posedge d ) begin if(a) z=~z; else if(b)z=~z; else if(c) z=~z; else if(d) z=~z; end endmoduleArticle: 88288
Hi guys. Implementing asynchronous delays in my design via a chain of buffer elements (I know it's a bad practise, but I need few ns delays) I faced the problem with removing them from the design, as Xilinx synthesiser removes these elements from the design, although the OPTIMIZE option is off. So I'd like to ask if anyone can tell me where I missed something, and also if someone already implemented small delays via internal FPGA units (not RC chains)which elements may provide the biggest delay (in order to save space). Thanks a lot. -- AlexArticle: 88289
Hi, Maybe I haven't got your problem, why can't you use asynchronous memory, so you could vary the processor clock as you like. Synchronous design will definitely work, however you will loose in performance. As a compromise you can always gate clock, which is probably not the best practise in FPGA design. At any rate - more details on your system arch. would help. Regards, Alex -- AlexArticle: 88290
Your results are not surprising. Although your code is legal Verilog and is able to simulate, it's not synthesizable. What type of flip-flop would you expect XST to infer from the "always @(posedge a or posedge b or posedge c or posedge d ) " construct? You need to re-think your code! Good luck! John ProvidenzaArticle: 88291
Peter, thanks for your reply. Sudhir Peter Alfke wrote: > Sudhir, > so you have two sets of synchronous signals (hopefully synchronized by > the same global clock) and you combine them through combinatorial logic > to generate 2 control signals for the counters. > Obviously, you will generate glitches on these outputs, as a result of > prop delay differences in the combinatorial logic. But these glitches > occur a few nanoseconds AFTER the active clock edge, and they are, > therefore, irrelevant and cause no harm. > The beauty of synchronous logic is that inputs need only be stable > during the set-up time BEFORE the clock edge. > Peter Alfke, Xilinx Applications (from home)Article: 88292
Hi Rob I undertsand why you are making a point about crossover.I have done exactly the same thing. I use a special class to compare and sort the population based on their fitness. Keeping in mind 'elitism',I also copy the best solution to the new population. Then from a population of six, I select 4 best values and average out consequent numbers. Mutation- to randomise mutation process ,I select 4 members after crossover and either add 1 0r subtract 1 depending on computer clock ticks.This process is completely random. Here's a piece of code for the above: //Elitism - copy the best solution to the next generation Array.Sort(RepopulationPercentage); Best = RepopulationPercentage[popsize-1].accessElement; listBox1.Items.Add("Best = "+Best); //Crossover int m=popsize-1; listBox1.Items.Add("After Crossover"); listBox1.Items.Add(population[0]); for(i=1;i<popsize-1;i++) //elements { population.SetValue((int)((RepopulationPercentage[m].accessElement+RepopulationPercentage[m-1].accessElement)/2),i); listBox1.Items.Add(population[i]); m--; } if(dt.Ticks%2 == 0) population[popsize-1]=Best - 1; else population[popsize-1]=Best + 1; //Mutation listBox1.Items.Add("After Mutation"); listBox1.Items.Add(population[0]); for(i=1;i<popsize;i=i+2) //elements { if(dt.Ticks%2 == 0) population.SetValue((int)(population[i]+1),i); else population.SetValue((int)(population[i]-1),i); listBox1.Items.Add(population[i]); } Eric's psuedo code and a genetic algorithm template from a website helped me write the code. AnkitArticle: 88293
my understanding of verilog is that the code below is umbigous, so it is a bad practice anyway, with or without delays. The reason of the ambiguity is that assignements are analyzed in parallel, so if condition 2 is true, you don't know if the synthezaizer implemented out_reg <= 2'd0; or out_reg <= 2'd2; On Fri, 12 Aug 2005, Jonathan Bromley wrote: > Consider the following rather useful synthesis idiom: > > always @(posedge clk) begin > out_reg <= 2'd0; // Default value > if (condition_1) > out_reg <= 2'd1; > if (condition_2) > out_reg <= 2'd2; > end > > Especially if there are complicated nested conditions, > this can be a very neat way of describing default > conditions - there's no need to check that you have > written the right "else" clauses to mop up all the > default possibilities. However, let's now suppose > that you added delays to the assignments - but you > missed one: > > out_reg <= #1 2'd0; > if (condition_1) > out_reg <= #1 2'd1; > if (condition_2) > out_reg <= 2'd2; // oops, forgot the delay > > Now imagine that we execute the code, and condition_1 > is false but condition_2 is true. The first assignment > schedules an update on out_reg one time unit into the future. > The second assignment is not executed at all, because > its "if" conditional is false. The third assignment > schedules an update in the immediate future. > > "<= #T" delay in Verilog is a transport delay, so both > updates remain active. So the assignment that we > wanted to happen, > > out_reg <= 2'd2 , > > will take place immediately but, one time unit later, it > will be superseded by the default assignment. The design > is broken in a way that's very hard to diagnose, and > what's worse, simulation and synthesis will disagree > (synthesis will give the answer that you wanted, because > it ignores the delays). > > The only way to get this right is to ensure that all > assignments have exactly the same delay. This is > completely absurd, and impossible to maintain across > a large always block - especially if it calls tasks. > DON'T DO IT. No delays, please. > > If you really want to delay the output, then make your > clocked assignments to an internal variable, and copy > that on to the output port using a continuous assign > with a delay. In that way the delay is centralised in > one place and is not subject to the kind of error I > described. > > Note that VHDL does not suffer this problem, because > assignment delays are (by default) inertial and so > the intuitive "most recent assignment wins" rule > works as you'd expect, even if the delays are different. > -- Tullio Grassi ====================================== Univ. of Maryland-Dept. of Physics | College Park, MD 20742 - US | Tel +1 301 405 5970 | Fax +1 301 699 9195 | ======================================Article: 88294
To all, I'm trying to create a test bench where an array data type of "std_logic_vector" is read within a for loop and then stored to a file. The problem I'm facing is that the array accesses the starting index of 0 twice and doesn't capture the last element of the array as it should. That is the line stated below as: "refmemdata <= mem_arr(k)" returns the value of the signal at k = 0 twice eventhough the value of k in the second iteration of the loop is k = 1. Why? Any help would be grateful. Section of VHDL code for above problem: ====================================== -- Signal Declaration signal refmemdata :std_logic_vector(2 downto 0); type mem_vec_arr is array (0 to 4) of std_logic_vector(2 downto 0); constant mem_arr: mem_vec_arr :=(0 => "000",1 => "001",2 => "010", 3 => "011", 4 => "100"); file data_vector_file: text open write_mode is "D:\written_data_file.txt"; -- Array accessing and file storage stimulus: process() variable data_file_line: line; begin for k in 0 to 4 loop wait until (clk'event) and (clk = '1'); refmemdata <= mem_arr(k); write(data_file_line, to_bitvector(refmemdata)); writeline(data_vector_file,data_file_line); end loop; end process;Article: 88295
"austin" <austin@xilinx.com> wrote in message news:1124032605.076143.24740@g14g2000cwa.googlegroups.com... > Ed, > > I am not providing you with an excuse, just letting you know what the > reality is. We test, and we test a lot. But, with new products, and > new features, we can't be perfect, and we provide the fixes on a very > timely basis (usually every bug found is fixed in the next service > pack, or sooner by a tactical patch). > > Austin > The things that bug me are the simple things that work with one version and with the next update they have been "improved" and no longer work. For example (going from memory here...) - after upgrading to ver 7 when you get a compile error - you used to click on the error code and it would give you an explanation of the error. Now when you click on the error code - it goes off and does a Xilinx websearch for the error - and the search includes my application specific variable names. Naturally, everytime it comes back with 'error not found'. Now how in the heck did a function such as that break? Another example - I have an older design written in Abel (OK - it was written long, long ago). Recently I modified the code to change the revision number within the CPLD. Compiled it with version 7.1... it gives no errors and appears to compile just fine. Download it to the part and nada.... nothing works. I look at the JEDEC file and it's half blank. Strange as the compiler didn't give any errors. Compiled the old, unmodified code with 7.1 - same results. Compiled both old and new with version 6.1 and it all works just fine. But, hey, to tell the truth - there really isn't a whole lot to complain about regarding Xilinx sotware now that I've tried Atmel's Prochip Designer. Phew! Brings back memories of the old XACT days with DOS!!! Suggestion.... I use lots of Xilinx Vertex and XC9500xl parts. Hey, these are good parts. But due to selection, for one of my projects, I often have to go with Atmel. They have the ATF150x series CPLD's which are DIRT cheap, operate from 5 volts and come in a PLCC package. Closest thing would be the Xilinx XC9500 series but they cost far, far more. I can easily fit the design in an ATF1504 which costs about $5. To get the same design to compile within a Xilinx part - I had to keep bumping it up in density until I got to the XC95288... and these cost many times the $5 price. It would be real nice if Xilinx would also supply CPLD's with this increased density, operate from 5 volts, be much cheaper like the Atmel parts and be in a large PLCC (MUST be socketable) package. Heck, I can forgo the 5V with an LDO but still MUST retain 5V I/O interface like the XC9500XL's. You know what would be real neat -- if somebody were to come up with a generic 5 volt, 40-PIN DIP CPLD in a high enough density to emulate a 6502 or 6800 processor or the myriad of support parts that are no longer available. Ohhhh.... I'd give an arm and a leg for a cheap and reliable source of this type of part! -- EdArticle: 88296
"CMOS" <manusha@millenniumit.com> wrote in message news:1124005073.000044.130440@g47g2000cwa.googlegroups.com... > hi, > im hoping to buy the following FPGA development board from Avnet. If > anyone got any experiance with it please let me know. > > Model: SP3E-EVL100 > Link: > http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D21564%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html > > > thank you. > CMOS > Had a chance to play with one of these at one of Memec's (recently acquired by Avnet) X-Fest seminars. They integrate with the tools well, and are fairly no-fuss. Last I heard, they were due to be available for purchase about mid September. Cheers, Alf.Article: 88297
Hello All, I'm three days into this configuration problem, so I think it's time to consult the experts. Problem's like this usually seem trivial in retrospect, but I've usually been looking in the wrong places... Briefly, INIT line goes low one CCLK pulse after DONE line goes high. Configuration loads and runs, but INIT line low indicates a CRC error. The signals look quite reasonable on a scope. Specifics: On a new prototype board I'm trying to congigure a Spartan-3 3s1000-5fg456 using a 3.3V IO micro- controller driving the fpga's config lines. Dedicated config lines have serial resistor (100 ohm), as per recommendation for 3.3V tolerant config. I'm using slave-serial mode to write config file, which is stored on the micro's flash memory. I've used the same micro and method successfully in other products (but using Spartan-2). I send all data frames ( FFFFFFFF , AA995566 , ... 20000000 ) start to end of file. I'm not sure exactly _where_ the DONE line should go high. It would seem that it should go high at some point after the last 32-bit configuration frame, but in fact DONE transitions on the 7th CCLK pulse of the (N-4)th configuration frame. XAPP452 shows this as being [CMD Write Packet Data(DESYNC)] frame. The INIT line goes low on the 8th CCLK pulse, Fpga operation commences on the 9th CCLK pulse. All design tweaks (resistor value changes) and clock/ data timing tweaks result in the same behavior. I would have thought that the CRC error would have prevented startup of the fpga (CRC is _not_ disabled in bitgen), but I guess this is not the case... If the DONE line _is_ going high early, I suppose this would mean that extra CCLK transitions were seen by the FPGA, pointing perhaps towards signal integrity issues, but this would puzzle me, as under different circumstances, the transitions happen at the same points. The bit file is being generated by ISE6.2.02. Sorry, this post is longwinded, I'm hoping that someone in the group has encountered a similar situation and can perhaps point me in the right direction. Thanks in advance... Scott@sdeviation.comArticle: 88298
Antti, I consider myself a pretty regular customer and I have some 500e's. Got them a few weeks ago. They'll be on a board and working this week. Xilinx is a little late on the 3e's, but it isn't too bad. Ricky.Article: 88299
GPE wrote: > "austin" <austin@xilinx.com> wrote in message > news:1124032605.076143.24740@g14g2000cwa.googlegroups.com... > >>Ed, >> >>I am not providing you with an excuse, just letting you know what the >>reality is. We test, and we test a lot. But, with new products, and >>new features, we can't be perfect, and we provide the fixes on a very >>timely basis (usually every bug found is fixed in the next service >>pack, or sooner by a tactical patch). >> >>Austin <snip> > > Another example - I have an older design written in Abel (OK - it was > written long, long ago). Recently I modified the code to change the > revision number within the CPLD. Compiled it with version 7.1... it gives > no errors and appears to compile just fine. Download it to the part and > nada.... nothing works. I look at the JEDEC file and it's half blank. Did you check the created files, to see if the fitter, or front end tools, dropped the ball ? > Strange as the compiler didn't give any errors. Compiled the old, > unmodified code with 7.1 - same results. Compiled both old and new with > version 6.1 and it all works just fine. ABEL is like assembler - there are still some designs where it is be best tool. Did you send Xilinx this example, so they can fix it ? > But, hey, to tell the truth - there really isn't a whole lot to complain > about regarding Xilinx sotware now that I've tried Atmel's Prochip Designer. > Phew! Brings back memories of the old XACT days with DOS!!! > > Suggestion.... > I use lots of Xilinx Vertex and XC9500xl parts. Hey, these are good parts. > But due to selection, for one of my projects, I often have to go with Atmel. > They have the ATF150x series CPLD's which are DIRT cheap, operate from 5 > volts and come in a PLCC package. Closest thing would be the Xilinx XC9500 > series but they cost far, far more. I can easily fit the design in an > ATF1504 which costs about $5. To get the same design to compile within a > Xilinx part - I had to keep bumping it up in density until I got to the > XC95288... and these cost many times the $5 price. With over 6x the MC's, the price delta is not suprising. The ATF15xx series are usually ~2x, and in rare cases, up to 3x, more efficent so I'm surprised you need to go to 288MC in the 9500 to get a fit. Sounds more like a tool issue - did you show that to Xilinx ? > It would be real nice if > Xilinx would also supply CPLD's with this increased density, operate from 5 > volts, be much cheaper like the Atmel parts and be in a large PLCC (MUST be > socketable) package. Heck, I can forgo the 5V with an LDO but still MUST > retain 5V I/O interface like the XC9500XL's. Lattice ispMACH4000 series show 5V I/O tolerance, but no PLCC. PLCC packages ( esp the smaller ones ) are usefull, but the trend is to TQFP and MLF, so socketing is going to get harder.... I can understand killing PLCC68 and PLCC84, but PLCC44 is still usefull. Their new MachXO is Spec'd to 4.25V max. > You know what would be real neat -- if somebody were to come up with a > generic 5 volt, 40-PIN DIP CPLD in a high enough density to emulate a 6502 > or 6800 processor or the myriad of support parts that are no longer > available. Ohhhh.... I'd give an arm and a leg for a cheap and reliable > source of this type of part! The volumes for this might kill it as a product - I have seen BGA packages put onto DIP40 headers, which could solve your problem ? -jg
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z