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
This is a multi-part message in MIME format. --------------BAF896A7A4F3694A75CA2732 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kris, I saw your previous post as well, Xilinx port warnings, and these seemed to be a related issue. The problem appears to be that you have defined ports in your top-level entity declaration that are either not connected, or not fully defined and are being optimized out by the synthesis tool. Optimized ports are not defaultly replaced in back-end siulation so the simulator is not able to bind the declaration in the testbench to this entity because of the missing ports. If you are not aware of any unused ports, follow the logic of these optimized ports to see if you can find the cause of the warning. It is generally best to fix the problem rather than ignore it. If things truely "work fine" and you do not wish to modify the code, you have a few options to make timing simulation work. Probably the easiest and best way to circumvent this error is to run the ngd2vhdl netlister using the -a switch. I am not sure how to enable this in the ISE GUI but if you see a switch that says something to the degree of "Generate Architecture Only" that is what you are looking for. What this does is tells the Xilinx tools to generate the architecture portion of the simulation netlist only and to not re-create the entity declaration. After doing this, re-run you functional simulation so that the RTL entity declaration is re-compiled. Then you can run the timing simulation. This should allow the simulator to re-use the entity declaration from your RTL code and link it to the timing simulation architecture. If all goes well, you should be able to get around the binding issues you see and perform your simulation. Another option you can try is to enable the "Corelate Simulation Data to Origional Design" switch. Again not sure where it is in the ISE GUI but if you are running from command-line, it means run ngdanno using the ngm file. In many cases, this will replace the optimized ports in the timing simulation netlist entity declaration and thus eliminate the binding issues you are seeing. Does not work in all cases but I have seen it work for some. Hope this helps, -- Brian Kris Nichols wrote: > Hey there, > It seems I have another challange to overcome in attempting 'timing' > simulations in ModelSIM. Please recall that my environment is the > following: > ModelSIM SE 5.5c > Xilinx Foundation ISE 3.3i (ELITE) > Windows NT (SP6) > > I get the following reported errors from ModelSIM when running a testbench > (i.e. activ_func_sigmoid_tb.vhd) on an entity called 'activ_func_sigmoid': > -------------------------------------------------- > ###### activ_func_sigmoid_tb.vhd(50): ); > # WARNING[1]: activ_func_sigmoid_tb.vhd(50): No default binding for > component: "activ_func_sigmoid". (Port "input_value" is not on the entity) > # -- Compiling configuration activ_func_sigmoid_cfg > # -- Loading entity testbench > # -- Loading architecture testbench_arch of testbench > # vsim -lib work -sdfmax /UUT=activ_func_sigmoid_ppar.sdf testbench > # // ModelSim SE 5.5c Jun 22 2001 > # // > # // Copyright (c) Mentor Graphics Corporation, 1982-2001, All Rights > Reserved. > # // UNPUBLISHED, LICENSED SOFTWARE. > # // CONFIDENTIAL AND PROPRIETARY INFORMATION WHICH IS THE > # // PROPERTY OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS. > # // > # // Copyright (c) Model Technology Incorporated 1990-2001, All Rights > Reserved. > # // > # Loading E:/Modeltech_5.5c/win32/../std.standard > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_1164(body) > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_arith(body) > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_unsigned(body) > # Loading uog.uog_fp_exp(body) > # Loading uog.uog_fp_arith(body) > # Loading E:/Modeltech_5.5c/win32/../std.textio(body) > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_textio(body) > # Loading work.testbench(testbench_arch) > # ** Warning: Component uut is not bound. > # Time: 0 ns Iteration: 0 Region: /testbench > # ERROR: activ_func_sigmoid_ppar.sdf: The design does not have an instance > named '/UUT'. > # Error loading design > # Error: Error loading design > # Pausing macro execution > # MACRO ./activ_func_sigmoid_tb.tdo PAUSED at line 8 > -------------------------------------------------- > > It seems that ModelSIM doesn't believe that a input port called > 'input_value' doesn't exist in the entity, when in fact this port does > exist. Do you have any suggestions on how I can overcome this problem?? > I just wanted to point out that a 'functional' simulation works > successfully with the same 'activ_func_sigmoid' VHDL source file and its > respective testbench. Perhaps there's problems with the SDF (Standard > Delay Format) file that's produced by the Xilinx environment, which the > 'timing' simulation depends on. I did notice that Xilinx produced some > warnings during implementation that were as follows: > > --------------------------------------------------- > Synthesizing Unit <activ_func_sigmoid>. > WARNING : (ADVISOR__0001). Extracting 32-bit latch for signal > <output>. > WARNING : (HDL__0005). Signal <intermediate_mult2<31>> is assigned but > never used. > WARNING : (HDL__0005). Signal <intermediate_mult2<30>> is assigned but > never used. > : > etc. > ---------------------------------------------------- > > I'll be checking with the fellas at Xilinx to see if these warnings lead > to the incorrect implementation of ports. However, any input you have on > this problem would be much appreciated. Thanks for your time. > > Kris Nichols --------------BAF896A7A4F3694A75CA2732 Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofsky;Brian x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:brian.philofsky@xilinx.com fn:Brian Philofsky end:vcard --------------BAF896A7A4F3694A75CA2732--Article: 36626
In article <3BC8037B.1A8840F6@algor.co.uk>, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > >Mike Treseler wrote: > >> Juergen Otterbach wrote: .. >> > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA >> > (means to take of the 1000E and resolder the 2000E). >> >> Removing and replacing a BGA device is not >> a problem for any manufacturing facility >> with a BGA rework station. >> .. > >We had a case some years ago where our assemblers...had a re-work station and did >manage to get the parts off *but* they lost some of the pads doing it. > >The real issue is that a BGA re-work station uses a metal box which is placed >over the BGA to form a mini-oven but, unlike the main re-flow oven, the whole >board doesn't go through the preheat, temperature profiling process. > >Things may have got better since then ... > We've got a rework station (from PACE) that will do full BGA rework including top and bottom-side preheat. Indeed, for our boards the preheat is mandatory, what with up to 4 plane layers and 8 routing layers. These stations make removal a snap, without lifting any pads, provided you've done some profiling in advance. We had some test boards and dummy components we played around with to get the profiles right. In theory, the station can do install as well, and it's actually quite easy, but I still wouldn't trust the results without X-ray inspection. All it takes is one bridge between a VCC and GND to smoke your expensive chip. So notwithstanding the ability to install, it's probably just as well to ship out the board for installation because you're going to have to take it down to your local C/M's for inspection anyway, and if they actually do the installation they'll do the inspection automatically. Alex Rast arast@inficom.com arast@qwest.netArticle: 36627
Edwin Naroska <edwin@ds.e-technik.uni-dortmund.de> writes:
> How about using integers:
>
>
> case to_integer(unsigned(addr)) is
> when 16#3ac# => ...;
> when others => null;
> end case;
>
What about if it's more than 32 bits???
David
Article: 36628Or you can get the whole DVB core with randomizer, interleaver, (208,188) RS coder, trellis coder, puncturer, mapper, and interpolating FIR, at <plug> Insight Design Services. "FredInAShed" <FredInAShed@blueyonder.co.uk> wrote in message news:3BF04D56.C857BBF3@blueyonder.co.uk... > You could just get them off the shelf at > http://www.xilinx.com/ipcenter/fec_index.htm > > > > srinas wrote: > > > Dear All, > > I have to implement a Reed Solomon Encoder and a convolutional > > Interleaver. > > Could anybody send me some examples for a (208,188)or DVB standard RS > > coder (only the encoder) and the Interleaver. > > > > Note: > > The link > > http://www.fokus.gmd.de/research/cc/mobra/products/fec/content.html > > > > is unavailable now. > > Does anybody know where it is know? > > > > Thanks > >Article: 36629
David Rogoff wrote: > > Edwin Naroska <edwin@ds.e-technik.uni-dortmund.de> writes: > > > How about using integers: > > > > > > case to_integer(unsigned(addr)) is > > when 16#3ac# => ...; > > when others => null; > > end case; > > > > What about if it's more than 32 bits??? > Then back to vectors, or segment the address. --Mike TreselerArticle: 36630
In article <3BDFC791.CA95D40D@quest-innovations.com>, Richard Meester <rme@quest-innovations.com> wrote: >Hello all, > >I am searching for a high density non bga package FPGA. I don't want to >use BGA since the high prototyping costs involved. My estimation is that >PGA packages are cheaper to produce. Are there any SPartanII Virtex/II/E >devices in this package? > PGA's are likely to be *more* expensive, not less, than BGA's for similar density, partly because of the low demand, partly because the manufacturing process for BGA's is more efficient. OTOH, PGA's are easier to proto since you can easily socket them (note: for BGA socketing look to http://www.wellscti.com) and it's far easier to probe the device pins. In any case, if you're still interested in PGA parts, looks like the densest is Altera's EP20K400 (1 M system gates, 1664 macrocells) which is available in a 655-pin PGA. However, it's probably best to stay with BGA unless you have *specific* reasons for using a PGA (e.g all through-hole parts in the production board, so you want to have it go through wave solder for the whole process) Alex Rast arast@inficom.com arast@qwest.netArticle: 36631
Brian, It turns out that when implementing my design in Xilinx environment, the XST synthesizer would attempt to reduce logic for optimization purposes. The synthesizer thought that some of my pins were never used, and indirectly removed all logic related to my 'input_value' port (without explicitly stating it had done this). The SDF file produced by Xilinx wouldn't have any reference to the 'input_value' port pins, so a 'timing' simulation in ModelSIM would think that this port doesn't exist. So is it safe to say that the following messages indicate which pins are not implemented: WARNING : (HDL__0002). Input <name_of_pin> is never used. WARNING : (HDL__0005). Signal <name_of_pin> is assigned but never used. Is there any way (workarounds, etc.) I can use prevent the XST synthesizer from doing this? Thanks. Kris Nichols "Brian Philofsky" <brian.philofsky@xilinx.com> wrote in message news:3BF169CE.BA778033@xilinx.com... > > Kris, > > I saw your previous post as well, Xilinx port warnings, and these seemed to > be a related issue. The problem appears to be that you have defined ports in > your top-level entity declaration that are either not connected, or not fully > defined and are being optimized out by the synthesis tool. Optimized ports > are not defaultly replaced in back-end siulation so the simulator is not able > to bind the declaration in the testbench to this entity because of the missing > ports. If you are not aware of any unused ports, follow the logic of these > optimized ports to see if you can find the cause of the warning. It is > generally best to fix the problem rather than ignore it. If things truely > "work fine" and you do not wish to modify the code, you have a few options to > make timing simulation work. > > Probably the easiest and best way to circumvent this error is to run the > ngd2vhdl netlister using the -a switch. I am not sure how to enable this in > the ISE GUI but if you see a switch that says something to the degree of > "Generate Architecture Only" that is what you are looking for. What this does > is tells the Xilinx tools to generate the architecture portion of the > simulation netlist only and to not re-create the entity declaration. After > doing this, re-run you functional simulation so that the RTL entity > declaration is re-compiled. Then you can run the timing simulation. This > should allow the simulator to re-use the entity declaration from your RTL code > and link it to the timing simulation architecture. If all goes well, you > should be able to get around the binding issues you see and perform your > simulation. > > Another option you can try is to enable the "Corelate Simulation Data to > Origional Design" switch. Again not sure where it is in the ISE GUI but if > you are running from command-line, it means run ngdanno using the ngm file. > In many cases, this will replace the optimized ports in the timing simulation > netlist entity declaration and thus eliminate the binding issues you are > seeing. Does not work in all cases but I have seen it work for some. > > Hope this helps, > > > -- Brian > > > > > Kris Nichols wrote: > > > Hey there, > > It seems I have another challange to overcome in attempting 'timing' > > simulations in ModelSIM. Please recall that my environment is the > > following: > > ModelSIM SE 5.5c > > Xilinx Foundation ISE 3.3i (ELITE) > > Windows NT (SP6) > > > > I get the following reported errors from ModelSIM when running a testbench > > (i.e. activ_func_sigmoid_tb.vhd) on an entity called 'activ_func_sigmoid': > > -------------------------------------------------- > > ###### activ_func_sigmoid_tb.vhd(50): ); > > # WARNING[1]: activ_func_sigmoid_tb.vhd(50): No default binding for > > component: "activ_func_sigmoid". (Port "input_value" is not on the entity) > > # -- Compiling configuration activ_func_sigmoid_cfg > > # -- Loading entity testbench > > # -- Loading architecture testbench_arch of testbench > > # vsim -lib work -sdfmax /UUT=activ_func_sigmoid_ppar.sdf testbench > > # // ModelSim SE 5.5c Jun 22 2001 > > # // > > # // Copyright (c) Mentor Graphics Corporation, 1982-2001, All Rights > > Reserved. > > # // UNPUBLISHED, LICENSED SOFTWARE. > > # // CONFIDENTIAL AND PROPRIETARY INFORMATION WHICH IS THE > > # // PROPERTY OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS. > > # // > > # // Copyright (c) Model Technology Incorporated 1990-2001, All Rights > > Reserved. > > # // > > # Loading E:/Modeltech_5.5c/win32/../std.standard > > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_1164(body) > > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_arith(body) > > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_unsigned(body) > > # Loading uog.uog_fp_exp(body) > > # Loading uog.uog_fp_arith(body) > > # Loading E:/Modeltech_5.5c/win32/../std.textio(body) > > # Loading E:/Modeltech_5.5c/win32/../ieee.std_logic_textio(body) > > # Loading work.testbench(testbench_arch) > > # ** Warning: Component uut is not bound. > > # Time: 0 ns Iteration: 0 Region: /testbench > > # ERROR: activ_func_sigmoid_ppar.sdf: The design does not have an instance > > named '/UUT'. > > # Error loading design > > # Error: Error loading design > > # Pausing macro execution > > # MACRO ./activ_func_sigmoid_tb.tdo PAUSED at line 8 > > -------------------------------------------------- > > > > It seems that ModelSIM doesn't believe that a input port called > > 'input_value' doesn't exist in the entity, when in fact this port does > > exist. Do you have any suggestions on how I can overcome this problem?? > > I just wanted to point out that a 'functional' simulation works > > successfully with the same 'activ_func_sigmoid' VHDL source file and its > > respective testbench. Perhaps there's problems with the SDF (Standard > > Delay Format) file that's produced by the Xilinx environment, which the > > 'timing' simulation depends on. I did notice that Xilinx produced some > > warnings during implementation that were as follows: > > > > --------------------------------------------------- > > Synthesizing Unit <activ_func_sigmoid>. > > WARNING : (ADVISOR__0001). Extracting 32-bit latch for signal > > <output>. > > WARNING : (HDL__0005). Signal <intermediate_mult2<31>> is assigned but > > never used. > > WARNING : (HDL__0005). Signal <intermediate_mult2<30>> is assigned but > > never used. > > : > > etc. > > ---------------------------------------------------- > > > > I'll be checking with the fellas at Xilinx to see if these warnings lead > > to the incorrect implementation of ports. However, any input you have on > > this problem would be much appreciated. Thanks for your time. > > > > Kris Nichols >Article: 36632
arast@inficom.com (Alex Rast) writes: > All it takes is one bridge between a VCC and GND to smoke your expensive > chip. A bridge shorting an output pad to VCC or GND is much more likely to damage the chip. In my experience a short between VCC and GND is more likely to damage traces on the board, since that's where the high current flow will be.Article: 36633
"#BASUKI ENDAH PRIYANTO#" <PH892987@ntu.edu.sg> schrieb im Newsbeitrag news:8D5C8824989A21458FFF1C3CE9902036058AF146@mail12.main.ntu.edu.sg... > > When I synthesize my VHDL code, I have warning message that clock skew > may be happened in my design. > How to prevent clock skew ? This warning usually occurs when using non-clock nets for clock distribution, e.g. when you have more than 4 clock in a Spartan-II. Since the non-clock nets are not that strong, fast and well balanced, they are no good for distributing such a high-fan-out signal like a clock with low skew. > Do I need additional circuit / block diagram ? Hmm, first, try to use the global clock nets (Spartan(XL) has 8, Spartan-II/Virtex(E) has 4, Virtex-II has 16). If you are still out of clock nets, you have to use other routing ressources. Uses the following statement in your ucf file (ucf file is a little bit stupid, because ucf already means User Constraints File ;-) NET myclocknet uselowskewlines; This will tell the software to take care of your clock signal on non-clock routing ressources. Try to use these secondary clock nets only for small parts of the design (lets say a maximum fanout of 50..100 ??). -- MfG FalkArticle: 36634
Hey Everyone,
It turns out that I get the following warning whenever
I try to (XST) synthesize entities with ports port-mapped to constants!!!
As a result the input port itself is not implemented during synthesis, and
XST produces the following warning:
WARNING:(HDL__0002). Signal <port_pin_name> is not used.
Has anyone else come across this problem before? Any suggestions on how I
can rectify this problem (i.e. workarounds, etc.)? Thanks :)
Kris Nichols
Article: 36635Indeed, the decision to upgrade was not taken lightly, but we had to choose being able to run the CoreGen (because of the Pentium-4 bug), switching machines and dealing with the associated licensing headaches, or upgrading. Since we had just a single design in 3.1 and new designs in the queue, we chose to upgrade. Xilinx support has confirmed that there are numerous [unnecessary] incompatibilities, and that there is not [yet] a summary. Jim. Falk Brunner wrote: > "Jim Bittman" <jmbj@bittware.com> schrieb im Newsbeitrag > news:3BF01451.5DD62639@bittware.com... > > [ Complaints about Xilinx Sotware update ] > > > I could go on, but here we have a seriously under-utilized device and a > > LOT of work > > to upgrade the software. What gives - are we unique or is everyone just > > accepting > > Hmmm, we did the upgrade too and had a LOT of trouble. Even with pure VHDL > designs. The Xilinx Software guys will have a LOT of bugs to fix :-( > > > this as the necessary pain to upgrade??? > > As always, never change a running system. If your old Software runs O.K. > leave it this way, at least to the end of your current projects. > > -- > MfG > Falk -- ******************************************************************** * Jim Bittman * Tel: 603-226-0404 * * BittWare, Inc. * Fax: 603-226-6667 * * 33 North Main Street * E-Mail: jmbj@bittware.com * * Concord, NH 03301 * WWW: http://www.bittware.com * ********************************************************************Article: 36636
Petter Gustad wrote: > > Austin Lesea <austin.lesea@xilinx.com> writes: > > > Lies, lies, and damned lies, > > > > 2V6000's are yielding just fine. > > I'm glad to hear that. My comment was not a confirmation on the rumor, > just a technical question. Would it be possible to by cheap partially > defective parts like I described, or would the logistics and support > be way to expensive to make it worth it? This was certainly done in the past. Way back in the dark ages (late 70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts (2716s) with one address line tied off to exclude the non-working portion of the die. Because they were windowed parts it was easy to visually confirm that the 2758s were the same die as the 2716s. At the time 2716s were selling for around $30 apiece, IIRC. -- Tim Hubberstey, P.Eng. . . . . . . . . . . . . . . Marmot Engineering Vancouver, BC, Canada . . . . . Hardware/Software Consulting EngineerArticle: 36637
This is a multi-part message in MIME format. --------------46894D576FF6AC191D243FE0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit How do you map an input port to a constant? I can understand defining an output port to be a constant but not exactly following what your problem is with the input ports. Can you include a small snip-it of code to better explain what you are doing and what you are trying to accomplish? Perhaps with that, I can better help you. -- Brian Kris Nichols wrote: > Hey Everyone, > It turns out that I get the following warning whenever > I try to (XST) synthesize entities with ports port-mapped to constants!!! > As a result the input port itself is not implemented during synthesis, and > XST produces the following warning: > WARNING:(HDL__0002). Signal <port_pin_name> is not used. > > Has anyone else come across this problem before? Any suggestions on how I > can rectify this problem (i.e. workarounds, etc.)? Thanks :) > > Kris Nichols --------------46894D576FF6AC191D243FE0 Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofsky;Brian x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:brian.philofsky@xilinx.com fn:Brian Philofsky end:vcard --------------46894D576FF6AC191D243FE0--Article: 36638
No problem. Here's a simple example for you: ------------------------------------------------------------------------- --COMPONENT uog_fp_div IS -- PORT( reset,clock,start: IN std_logic; -- mode : IN std_logic_vector(1 DOWNTO 0); -- x : IN std_logic_vector(31 DOWNTO 0); -- y : IN std_logic_vector(31 DOWNTO 0); -- z : OUT std_logic_vector(31 DOWNTO 0); -- busy : OUT std_logic); -- END COMPONENT; -- one example where I use a constant of X"3F800000" as one of the inputs divider_1: uog_fp_div PORT MAP(reset, system_clock, chip_enable, truncate_mode, incoming, X"3F800000", div_output1, busy_flag1); -- another example where I indirectly use a constant of X"3F800000" -- as one of the inputs positive_one <= X"3F800000"; divider_2 : uog_fp_div PORT MAP(reset, system_clock, chip_enable, truncate_mode, incoming, postive_one, div_output2, busy_flag2); ------------------------------------------------------------------------- In both cases, the XST synthesizer would give me the following: WARNING:(HDL__0002). Signal y<31> is not used. WARNING:(HDL__0002). Signal y<30> is not used. : WARNING:(HDL__0002). Signal y<0> is not used. When I don't use constants these warnings go away, and everything gets implemented properly. Let me know if you need any more clarification. Much appreciated. Kris N. "Brian Philofsky" <brian.philofsky@xilinx.com> wrote in message news:3BF1A8CF.96163E5@xilinx.com... > > > > How do you map an input port to a constant? I can understand defining an > output port to be a constant but not exactly following what your problem is > with the input ports. Can you include a small snip-it of code to better > explain what you are doing and what you are trying to accomplish? Perhaps with > that, I can better help you. > > -- Brian > > > Kris Nichols wrote: > > > Hey Everyone, > > It turns out that I get the following warning whenever > > I try to (XST) synthesize entities with ports port-mapped to constants!!! > > As a result the input port itself is not implemented during synthesis, and > > XST produces the following warning: > > WARNING:(HDL__0002). Signal <port_pin_name> is not used. > > > > Has anyone else come across this problem before? Any suggestions on how I > > can rectify this problem (i.e. workarounds, etc.)? Thanks :) > > > > Kris Nichols >Article: 36639
--------------7959175E83AE16AE4FEFF0A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim, Selling partial functionality parts is definitely a way to stay in business if there is no yield, or yields are poor. We do not have that problem, as we have plenty of 100% working parts. If you then offer reduced functionality parts at the same time you have full functionality parts, you create a support nightmare. I was so upset to see the lie in print, I missed the question, I apologize. Austin Tim Hubberstey wrote: > Petter Gustad wrote: > > > > Austin Lesea <austin.lesea@xilinx.com> writes: > > > > > Lies, lies, and damned lies, > > > > > > 2V6000's are yielding just fine. > > > > I'm glad to hear that. My comment was not a confirmation on the rumor, > > just a technical question. Would it be possible to by cheap partially > > defective parts like I described, or would the logistics and support > > be way to expensive to make it worth it? > > This was certainly done in the past. Way back in the dark ages (late > 70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts (2716s) > with one address line tied off to exclude the non-working portion of the > die. Because they were windowed parts it was easy to visually confirm > that the 2758s were the same die as the 2716s. At the time 2716s were > selling for around $30 apiece, IIRC. > -- > Tim Hubberstey, P.Eng. . . . . . . . . . . . . . . Marmot Engineering > Vancouver, BC, Canada . . . . . Hardware/Software Consulting Engineer --------------7959175E83AE16AE4FEFF0A3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Tim, <p>Selling partial functionality parts is definitely a way to stay in business <b>if </b>there is no yield, or yields are poor. <p>We do not have that problem, as we have plenty of 100% working parts. <p>If you then offer reduced functionality parts at the same time you have full functionality parts, you create a support nightmare. <p>I was so upset to see the lie in print, I missed the question, I apologize. <p>Austin <p>Tim Hubberstey wrote: <blockquote TYPE=CITE>Petter Gustad wrote: <br>> <br>> Austin Lesea <austin.lesea@xilinx.com> writes: <br>> <br>> > Lies, lies, and damned lies, <br>> > <br>> > 2V6000's are yielding just fine. <br>> <br>> I'm glad to hear that. My comment was not a confirmation on the rumor, <br>> just a technical question. Would it be possible to by cheap partially <br>> defective parts like I described, or would the logistics and support <br>> be way to expensive to make it worth it? <p>This was certainly done in the past. Way back in the dark ages (late <br>70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts (2716s) <br>with one address line tied off to exclude the non-working portion of the <br>die. Because they were windowed parts it was easy to visually confirm <br>that the 2758s were the same die as the 2716s. At the time 2716s were <br>selling for around $30 apiece, IIRC. <br>-- <br>Tim Hubberstey, P.Eng. . . . . . . . . . . . . . . Marmot Engineering <br>Vancouver, BC, Canada . . . . . Hardware/Software Consulting Engineer</blockquote> </html> --------------7959175E83AE16AE4FEFF0A3--Article: 36640
Hello all, I have a Verilog design and would like to simulate it in Altera's Max+Plus II. When I insert nodes into the simulator channel file, (SCF) from my compiled netlist, I do not see all of my variables available. (I see all input and output ports, but only one of my five registers). I know that with an Altera graphic design file, one can specify the parameter "LCELL" on a node, which will keep it visible. However, as this is a Verilog file, I do not know how to keep the variables around. If you have an idea, please respond by email. If there seems to be any significant interest in this topic, I will compile a summary of responses and post it to this group. Thank you and regards, Matt mkoepnick@anritsu.comArticle: 36641
The '3042 is getting on a bit as Xilinx have advanced several generations. I'm looking at porting the design to this board: http://www.howell1964.freeserve.co.uk/logic/burched/fpga_devkit_b5.htm There is a lot more logic and I/O available in the chip, so room to use this board for future projects. I should point out that these chips involve a lot of very sensitive gates toggling like crazy, so they do need a good quality PCB design with decent power decoupling and dedicated power and ground planes. Four-layer boards are significantly dearer to produce than two layer boards of course. It's not really economically feasible to make a small production run for a low-value product. What might be worth doing is making a 2-layer board to mate with the B5 board. That would have the relatively simple application specific circuitry. A Z80, a 32K RAM and a ROM (5V flash?).Article: 36642
Hi, I am try to design sdram controller. I think the sdram module interface is similar sdram. Can I treat the sdram module as a larger sdram? Best Regards, ArguoArticle: 36643
I'm glad Xilinx doesn't sell partially functional units. It would wreak
havoc on floorplanned designs. It may be invisible in the Altera
architecture, but that is because the routing architecture permits
hanging extra units on with no noticible effect for extra units added to
improve yield. In the Xilinx routing architecture, this would be a
disaster. That said, I do not mean to imply that the Altera routing is
superior, it is not for data flow designs.
Austin Lesea wrote:
> Tim,
>
> Selling partial functionality parts is definitely a way to stay in
> business if there is no yield, or yields are poor.
>
> We do not have that problem, as we have plenty of 100% working parts.
>
> If you then offer reduced functionality parts at the same time you
> have full functionality parts, you create a support nightmare.
>
> I was so upset to see the lie in print, I missed the question, I
> apologize.
>
> Austin
>
> Tim Hubberstey wrote:
>
>> Petter Gustad wrote:
>> >
>> > Austin Lesea <austin.lesea@xilinx.com> writes:
>> >
>> > > Lies, lies, and damned lies,
>> > >
>> > > 2V6000's are yielding just fine.
>> >
>> > I'm glad to hear that. My comment was not a confirmation on the
>> rumor,
>> > just a technical question. Would it be possible to by cheap
>> partially
>> > defective parts like I described, or would the logistics and
>> support
>> > be way to expensive to make it worth it?
>>
>> This was certainly done in the past. Way back in the dark ages (late
>>
>> 70's) there were 8 kbit EPROMs (2758s) that were 16 kbit parts
>> (2716s)
>> with one address line tied off to exclude the non-working portion of
>> the
>> die. Because they were windowed parts it was easy to visually
>> confirm
>> that the 2758s were the same die as the 2716s. At the time 2716s
>> were
>> selling for around $30 apiece, IIRC.
>> --
>> Tim Hubberstey, P.Eng. . . . . . . . . . . . . . . Marmot
>> Engineering
>> Vancouver, BC, Canada . . . . . Hardware/Software Consulting
>> Engineer
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 36644In article <52758910.0111131827.4f26d43f@posting.google.com>, s9323090@cc.ncu.edu.tw says... > Hi, > I am try to design sdram controller. I think the sdram module interface is > similar sdram. Can I treat the sdram module as a larger sdram? Depending on the SDRAM, perhaps. You might want to look at the timings for the DIMMs and the system-level stuff. Note that registered DIMMs will have to have the registration accounted for in the state machine and modern DIMMs will have information in the serial EEPROM that you may care to support. ---- KeithArticle: 36645
Jerry wrote: > > Russell Shaw <rjshaw@iprimus.com.au> wrote in message news:<3BF064BA.D3841344@iprimus.com.au>... > > > the process. Mixing both styles like your process creates latches. > > > > But with synthesis, i think *everything* that gets assigned a value > > within a process, has to be in the sensitivity list or leonardo gives > > warnings. Only with a "wait until" line, does the process not have a > > sensitivity list. > > > > Russell, > > Please note that VHDL synthesizers generate stupid warnings about signals > missing from the sensitivity list during initial syntax check of the code. > Those warnings are justified only for processes describing COMBINATORIAL > logic. In that case all signals _used_on_the_right-hand_side_ of assignments > should be in the sensitivity list. For clocked processes, such requirements > are clear violation of common sense and basic VHDL rules. I can't remember, but leonardo might only emit a warning for variables/signals being read in the *asynchronous* part of a flip-flop process. > Issuing those > warnings is even more ridiculous if you consider that VHDL synthesizers > usually do not check sensitivity list while infering logic... > I do hope that somebody will kick synthesis tool vendors in the ass to remove > those stupid warnings - it worked (with loooong waiting time) to force > FPGA Express to support rising_edge/falling_edge functions...Article: 36646
Nial Stewart wrote: > > Jim wrote: > > > > If for any reason, the synthesis tool doesn't > > pick the global clock buffer for your clock, you can always add a global > > buffer marco in your code to force the tool to use one. Or try to use a > > better synthesis tool. > > Jim, > > With Altera's Acex devices (and all others I'm aware of) you're tied to > using dedicated GClk pins. If you don't use them for your clocks you're > stuffed. I fixed all my problems. I think it was caused by clock-skew/alignment problems between the state-machine and counter. I figured out how to trace signal paths using the maxplus2 floor-planner. I traced from the clock input pin to the clock divider, and looked at the fanout from the last flip-flop. I found there were a few counters implemented as scattered logic, not being recognized as counter templates. I found just one or two extra lines in a process can prevent recognition by the compiler as a counter. With a slight modification to match standard leonardo templates, they get recognized and implemented as LPM library functions, showing compact grouping in LABs. The next thing was to get that buried node from the clock-divider output onto a global clock track. A simple resource assignment in the floor-planner did that. The externally supplied clock just goes to an 'ordinary' io pin.Article: 36647
Hi, I have a similar problem like srinas has. The convolutional interleaver for ATSC has 52 lines and needs (51x52)/2=1326 delay elements. If the input is 8 bit then 1326x8=10608 delay elements are required. The required number of Flip flops for a 4 symbol delay is 10608x4 = 42432. This is quite large. The same complexity is also valid for DVB interleavers. Is there any way to reduce the Flip Flop count? I know there are megafunctions for altera and xilinx devices, but they are commercial. ThanksArticle: 36648
I'm in need of a pointer for a ASRC implementation using DSP or FPGA. Any source (C-code or VHDL) will be more than welcome. Regards, DamirArticle: 36649
On 14 Nov 2001 00:35:26 -0800, mehmetozcelebi@turk.net (mehmeto) wrote: >Hi, > I have a similar problem like srinas has. >The convolutional interleaver for ATSC has 52 lines and needs >(51x52)/2=1326 delay elements. If the input is 8 bit then 1326x8=10608 >delay elements are required. The required number of Flip flops for a 4 >symbol delay is 10608x4 = 42432. This is quite large. >The same complexity is also valid for DVB interleavers. >Is there any way to reduce the Flip Flop count? I know there are >megafunctions for altera and xilinx devices, but they are commercial. Yes, that's a lot of flip flops. But I've never seen a large interleaver use flip flops for storage. Try RAM. It's much cheaper per bit. You could use an external ram, or you could use ram inside an FPGA. Your application would use less than 10% of the ram on one of the larger FPGA devices. Allan.
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