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
Go John GO!!!!! Drive them all out! (giggle). John Cooley (jcooley@world.std.com) wrote: : >Reference Number: 1000417 : >Title: FPGA Design Engineer, Avionics : >Location: NH : >Type: Permanent : >Salary: Open, relative to experience : > : >Description: : > : >Design and develop electronic circuits that will be primarily digital : >with some custom components including FPGAs and/or ASICs. Designs may : >involve processors, data bus interfaces, combinatorial functions, and : >aircraft or spacecraft interfaces. The design process will include : >simulations using state of the art tools. : This one's easy; it's Lockheed-Sanders up in New Hampshire. I even : know the engineers up there! If anyone's is looking for a job : there, blow off this headhunter and send your resumes to me. I'll : forward them to the engineers there and they can get the referal : bonus! (Or if you want to send your resume up to their HR dept., : call (603) 555-1212 and ask for "Lockheed-Sanders".) : Why can't these headhunters post in the job newsgroups? : - John Cooley : Part Time EDA Consumer Advocate : Full Time ASIC, FPGA & EDA Design Consultant : =========================================================================== : Trapped trying to figure out a Synopsys bug? Want to hear how 4599 other : users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)! : : !!! "It's not a BUG, jcooley@world.std.com : /o o\ / it's a FEATURE!" (508) 429-4357 : ( > ) : \ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys, : _] [_ Verilog, VHDL and numerous Design Methodologies. : Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222 : Legal Disclaimer: "As always, anything said here is only opinion."Article: 3801
VHDL System Solutions P\L are now accepting orders for their HDL (VHDL and Verilog) editor called Setanta ED. A 45-day evaluation copy of Setanta ED may be downloaded from : http://www.vhdl.com.au Trivia : "Setanta" is the name of a famous Irish mythical warrior who was capable of defeating armies, single-handedly. Setanta ED has been designed and developed by FPGA/ASIC designers.Article: 3802
> > -------------------------------------------------------------------- > > Newsgroup: comp.arch.fpga > > * Multi-FPGA Partitioners? - "J. A. Herrera Camacho" (21) > * assigning LOC in XACT - Rafiki Kim Hofmans (30) > o Andy Gulliver (6) > o Raghavendra G Jorapur (17) > * Re: Job posting - John Cooley (30) > * Re: Question: FPGA versus ASIC design. - Peter (28) > * Reconfigurable Hardware - Pasquale Corsonello (13) > * ANNOUNCE: FREE Model of the Month - IPCRA - Rob Hurley (53) > * ANNOUNCE: New FREE Tip of the Month - Encapsulation - Rob > Hurley (52) > * US-NH FPGA Design Engineer, Avionics - Kevin Hawes (35) > o John Cooley (40) > + Mark Christensen (53) > + suzanne M southworth (48) > * US-NH FPGA Computer Architecture Design Engineer - Kevin Hawes > (39) > * Re: Clearing security fuse on Lattice ispLSI2032? - Matt Cross > (15) > * Re: Question: FPGA versus ASIC design. - Hajimowlana Hossain > (20) > * Xilinx/FPGA Timing Problems - Jeff Hunsinger (36) > o Peter (33) > * Re: Question about books for FPGA - Peter Alfke (26) > * ANNOUNCE : HDL Editor - gary crothers (12) > > -------------------------------------------------------------------- >Article: 3803
HighTech <hightech@mv.mv.com> wrote: >> >>Are we going to start posting job listings to these newsgroups? >> jcooley@world.std.com (John Cooley) wrote: >Please don't. Job postings are for the job newsgroups. Once the >headhunters start massively job posting in the technical newsgroups, >it effectively kills the technical discussions in the newsgroups >because it turns off too many engineers. >It's all a matter of signal-to-noise; what does the fact that 8 >different headhunters posting and reposting "HOT JOBS AT SGI!!!" >have to do with my getting a solution to the EDA bug I'm currently >fighting? Nothing. > - John Cooley > Part Time EDA Consumer Advocate > Full Time ASIC, FPGA & EDA Design Consultant John, I haven't done a count, but it seems that your crusade against these job postings have generated much more "noise" than the postings themselves. I have to wonder about the effectiveness of your tactics if your goal is to keep the group focused on technical issues. As another poster stated, the job postings can be easily skipped in most decent news readers. Now, before anyone takes me wrong, I do not defend the posting of off topic articles to *any* group. Those who violate netiquette should be sent a copy of the FAQ and the charter and asked politely to refrain from such violations in the future. By email, not by post. Repeat offenders should be dealt with more sternly. However, as a pragmatic sort, I realize that these posts will occur in spite of anyone's best efforts to prevent them. So why waste valuable time (John - read 'billable hours') tilting at windmills? So far, the number of jobs postings are a small percentage of the total traffic in this group. They are nowhere near a threat to overwhelm the technical content. If and when that starts to happen, I'll be right there beside you helping to preserve our forum. Until then, let's be careful not to overreact. -Jerry Certus Consulting Group | Consulting in Integrated Circuit 3733 Chesapeake Court | Design and Verification, Antioch, CA 94509 | Fault Grading, Test Development, (510)757-0685 | and Logic Synthesis http://www.certus.com/certus/Article: 3804
On Sat, 3 Aug 1996, Peter Alfke wrote: > In article <Pine.SUN.3.91.960729074337.16136A-100000@Bundy>, Rainer > Scharnow <amigo@bintec.de> wrote: > > > Of course, no > > one describes the limitations of the products 8-). > > > Did it ever occur to you that the only thing the parameter values in the > data sheet describearet device limitation? > ... > Our industry gives you hundreds ( thousands ? ) of pages of product limitations. > I suppose you have never looked at it this way. :-) Hi, I must appologize, my statement about limitations was very weak :-). Wanted to say the limitations of a specific device have to do with the kind of logic I have to synthesize (bus oriented logic vs. state machine oriented applications for example). Or think of geometry aspects at the FPGA (left-right orientation in XC3xxx, nearly symmetric orientation in XC4xxx) that will influence the design preparations strongly - nothing for softies :-) E-regards --------------------------- Rainer Scharnow (amigo@bintec.de) BinTec Commmunications GmbH ---------------------------Article: 3805
In article <4to4cb$bt@rc1.vub.ac.be>, tw38966@vub.ac.be says... > >Hi, > >can someone tell me how I can assign LOCs to a 16 bit IOPAD in the Xilinx >schematic entry ? >I suppose I have to make a file with the LOCs. > >Or is the only solution using 16 times 1 IOPAD ? :( When you edit I assume you're using Active cad. From what I can tell... For a single IOPAD you assign the property LOC=Pnn. For an bulti-bit IOPAD, assign a whole heap of properties, called LOC[0] to LOC[n-1] to match the bits. eg. LOC[0]=P5 LOC[1]=P6 LOC[2]=P7 ... LOC[15]=P20 #disclaimer<I'm a newbie> -- ------------ When all else fails, find a scapegoat ---------------- Charles Manning manningc@southern.co.nz Christchurch, New Zealand -------------------------------------------------------------------Article: 3806
Dear ASIC/FPGA Designer
This is the E-mail version of the survey on design errors.
You can visit us at http://www.lis.e-technik.tu-muenchen.de/DEP/ and
run the survey online, or fill out this E-mail and return it to us.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This server is installed to collect the opinions of ASIC and FPGA designers
regarding the concept of design errors and problems they can cause. Our
final goal is to develop special technology extensions and synthesis
algorithms that allow the designers to correct their mistakes even after
chip fabrication. (This capability is named Correctability) These mistakes
are principally those design errors that are made during the design
development steps and have not been found in verification phases. In order
to get more familiar with this subject, you can refer to:
"Modeling of VHDL Design Errors and Methods for their Correctability",
M.R. Movahedin, P. Kindsmόller, W. Stechele,
VHDL International Users' Forum, Spring 1996 (VIUF'96).
or get its postscript version.
This survey will help us to find out what kind of design errors have to be
concentrated more on, and which imaginable ones are less important.
We appreciate your efforts in filling out this questionnaire, and will send
you a copy of the processed results, if you provide us with an E-mail
address here:
IMPORTANT: Answers to some questions seem to be your confidential
information, or violate copyright of your organization. Hereby we state that
all of the collected data will be processed absolutely confidentially. It
means:
1. The log-file of this WWW-Server, which holds your host-name, will be
used only for administration purposes (if any were necessary), and will
be erased after a short time.
2. Above E-mail address (if you have provided) will not be used for any
intention, but sending the results to you.
3. None of the answers will be published individually, but among others
after statistical processes.
(If you need, we can also send a signed version of this statement to you).
However, most of the questions are non-critical as far as the
confidentiality is concerned, and you may leave any question un-answered if
you wish.
Thank you again.
Institute for Integrated Circuits
Technical University of Munich
Munich, Germany
For any question or further information, feel free to send us a message:
M_Movahedin@lis.e-technik.tu-muenchen.de
----------------------------------------------------------------------------
please fill the multiple choices with a `X';
e.g. <X> (selected) or
< > (unselected)
----------------------------------------------------------------------------
PART 1: GENERAL QUESTIONS
----------------------------------------------------------------------------
----------------------------------------------------------------------------
1. You are mainly involved in the design of digital systems using:
< > Full Custom ASICs
< > Gate Arrays, Standard Cells
< > Programmable Logic (FPGA, CPLD)
Note: if you are involved both in ASIC and FPGA designs, please fill
this questionnaire two times, one as an ASIC designer, and second as an
FPGA one.
-----------------------------------------------------------------------
2. The average size of your designs (excluding RAMs and ROMs) is:
< > less than 3K
< > 3K - 10K
< > 10K - 20K
< > 20K - 50K
< > 50K - 100K
< > 100K - 200K
< > more than 200K
-----------------------------------------------------------------------
3. Which of the following design methods describes your strategy best:
< > Describe the design in a high level using an HDL, and have the
synthesizers make necessary resource scheduling, allocation and
technology mapping automatically, and provide desired design
constraints. (e.g. you are a Synopsys Behavioral Compiler user)
< > Make resource scheduling and allocation manually, and let the
synthesizer automatically define the data elements (registers,
operators, etc.) and their bussing structure, do eventually resource
sharing, map them to the technology in use, and provide desired design
constraints. (e.g. you use Synopsys VHDL/HDL/Design Compiler at RTL
level without being very deeply involved in hardware design concepts)
< > Make resource scheduling and allocation, data element selection and
their bussing structure and resource sharing manually, define all of
them in an HDL, use a synthesizer to translate and map it to the
technology in use, and provide desired design constraints. (e.g. you
are a conventional hardware designer, are always strongly aware of the
structure of final design, using Synopsys VHDL/HDL/Design Compiler at
RTL level)
< > Do all jobs manually using schematic capture tools.
< > others (please specify) : [ ]
-----------------------------------------------------------------------
4. As an HDL, you use:
o VHDL
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Verilog
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o others (please specify) : [ ]
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
5. How many percent of your designs (chips) work quite properly in the
first system they are integrated in?
< > 90%-100%
< > 65%-90%
< > 35%-65%
< > 10%-35%
< > 0%-10%
-----------------------------------------------------------------------
6. If your chip did not work properly in the first system integration, how
many times averagely would you have to modify your design, till it
works fairly after its integration in the whole system?
< > 1
< > 2-3
< > 4-7
< > more than 7
-----------------------------------------------------------------------
7. Having a flawed chip in the hand, you can do some of the following
tasks.
How often can they be applied (i.e. practically possible)?
o You do not need to be aware of design errors, because you develop
your designs first in FPGAs and then translate them to ASICs.
Nothing to lose, even in case of some design errors.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Though the chip is flawed, it is still usable, however with a
reduction in performance or desired features.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o The chip is still usable, however a change in the software is
necessary in order to compensate for the hardware flaw.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o The chip is still usable, however some extras or changes in the
hardware around it (at the board level) are necessary in order to
compensate for the hardware flaw.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o The hardware error can be corrected using Laser or Focused Ion
Beam on the chip, so it would be quite usable later on.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Unfortunately nothing, the chip is functionally not usable at all,
i.e. the chip has some fatal errors.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o others (please specify) : [ ]
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
8. A flawed chip can not work properly in the whole system because of
errors or malfunctions in its different parts, some of which are listed
below.
How often can each of them happen?
o Malfunction or design error in the chip logic functionality.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
In this particular case, the design error lies in:
o Data Section, i.e. data elements like registers,
operators & multiplexers, and their bussing structure.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Control Section, i.e. the state machine that controls
the operations.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Malfunction or error in the internal timings.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Malfunction or error of environmental interfaces, namely I/O
specifications.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Error or failing in chip fabrication that could not been detected
in the test phase.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o others (please specify) : [ ]
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
9. How often does each of the following points influence on the
malfunction of a chip in a system in which the chip is integrated:
o Mistakes and errors in the original specification that specifies
the functionality of the design and is sent to designers to
develop the necessary hardware and software based on it.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Incompleteness of the original specification, i.e. some seldom
happening situations are not considered carefully, and hence the
designers would not take care of.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Errors and/or bugs in the HDL description of the design, which is
developed by you or your design team and is further synthesized by
a synthesizer tool.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Errors and/or bugs in the CAD tools. (synthesis, place&route,
timing analysis, functionality verification, etc.)
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o Errors in the specification and/or prediction of the environment
status, with which the chip has to interface. (e.g. thermal
conditions, etc. )
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
o others (please specify) : [ ]
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
10. If some methods are developed that would allow you to correct your
design errors even after the fabrication of your ASIC (namely
correctability), then you would be ready to pay for its advantages
with:
o an increase in the area of the design by at most
< > 10%
< > 30%
< > 75%
< > 100%
< > 200%
< > no matter
o a decrease in the speed of the design by at most
< > 60%
< > 40%
< > 20%
< > 10%
< > 5%
< > not at all
----------------------------------------------------------------------------
----------------------------------------------------------------------------
PART 2: (V)HDL DESIGN ERROR MODEL
The second part of this questionnaire concentrates on a (V)HDL design error
model. This model is mainly based on the usually used synthesizable subset
of VHDL, but you can answer the questions, even if you are a Verilog user.
This model deals mainly with the mistakes made during the development of the
design HDL description, and are propagated to gate level by a synthesizer,
resulting in a flawed chip. In view of the fact that a quite complete
simulation and/or verification of a large design takes a long time and is
practically impossible, those flaws could not be detected before chip
fabrication and only after the chip takes effect in the whole system, they
would be detected by observing the system malfunctions. Thus, a redesign ,
i.e. rewriting the HDL description and correcting its mistakes, will be
necessary to achieve to a flawless chip.
The answer to the question why these errors have happened and not detected
in verification phases is beyond this questionnaire, and depends strongly on
the designers' design methodology. But it can not be forgotten that no one
can claim that his/her design is quite error free. The VLSI history shows
that even large powerful companies have designed and fabricated flawed
microprocessors and their mistakes are first detected after a very long
while.
Below, different possible and imaginable (V)HDL design errors (mostly with
an example showing it more clearly) are presented. These different classes
of mistakes have a very important point in common: they do not cause any
syntax error and don't make the design unsynthesizable based on the
synthesizable VHDL subset in use, because the HDL description after these
changes should be compiled again and be synthesized as before. In each item,
you are asked to define: how often can they appear, i.e. how probable are
they;
-----------------------------------------------------------------------
1. Mistakes in ENTITY declaration of any making up modules, including:
extra or inadequate ports, false port direction, false port width.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
ENTITY e IS
PORT (
a, b, _c_ : IN INTEGER;
d: IN BIT_VECTOR(7 DOWNTO 0))
END e;
Corrected VHDL Code:
ENTITY e IS
PORT (
a,b: IN INTEGER;
d: OUT BIT_VECTOR(_15_ DOWNTO 0);
_f_: IN BOOLEAN)
END e;
-----------------------------------------------------------------------
2. Mistakes in declaration parts, including: false signal and/or variable
bit wide, false signal and/or variable type.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
3. Mistakes in constants, e.g. logic value, integer value, state machine
state enumeration names, etc.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
a <= 12;
b <= TRUE;
next_state <= state_5
Corrected VHDL Code:
a <= _15_;
b <= _FALSE_;
next_state <= _state_8_;
-----------------------------------------------------------------------
4. Mistakes in net (identifier) names.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
a <= b + c ;
z <= x AND y ;
Corrected VHDL Code:
a <= b + _e_ ;
z <= x AND _t_ ;
-----------------------------------------------------------------------
5. Misplacement of parenthesis.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
x <= a AND ( b OR c );
Corrected VHDL Code:
x <= _(_ a AND b _)_ OR c;
-----------------------------------------------------------------------
6. Mistake in operators, e.g. logic operators and arithmetic ones.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
x <= a AND b ;
y <= c - d ;
Corrected VHDL Code:
x <= a _OR_ b ;
y <= c _+_ d ;
-----------------------------------------------------------------------
7. Assignment errors, including: deficiency in a necessary assignment,
extra existence of an assignment, incomplete assignment.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
----
y <= a AND b;
z <= a XOR b;
Corrected VHDL Code:
>>> x <= a OR b;
>>> ----
>>> z <= a XOR b XOR c;
-----------------------------------------------------------------------
8. Absence of a conditional (IF-THEN-ELSE and WHEN-CASE) expression.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
next_state <= state_8;
Corrected VHDL Code:
IF a='1' THEN
next_state <= state_8;
END IF;
-----------------------------------------------------------------------
9. Extra conditional control of some expressions that do not need any,
though the conditional expression itself must exist to control other
expressions.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
output_1 <= FALSE;
IF a='1' THEN
next_state <= state_8;
output_1 <= TRUE;
END IF;
Corrected VHDL Code:
output_1 <= FALSE;
IF a='1' THEN
next_state <= state_8;
END IF;
-----------------------------------------------------------------------
10. Deficiency in controlling of some expressions with a conditional
expression, though the conditional expression itself exists.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
IF a='1' THEN
next_state <= state_8;
END IF;
output_1 <= TRUE;
Corrected VHDL Code:
IF a='1' THEN
next_state <= state_8;
output_1 <= TRUE;
END IF;
-----------------------------------------------------------------------
11. Misplacement of an expression in a WHEN-CASE structure.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
Example:
Flawed VHDL Code:
CASE a(1 DOWNTO 0) IS
WHEN "00" => b <= c+1;
WHEN "01" => b <= c-1;
WHEN OTHERS => b <= c;
END CASE;
Corrected VHDL Code:
CASE a(1 DOWNTO 0) IS
WHEN "00" => b <= c+1;
WHEN "01" => b <= c-1;
WHEN "10" => b <= c+1;
WHEN OTHERS => b <= c;
END CASE;
-----------------------------------------------------------------------
12. Mistakes in component instantiation, including: false component name,
false port binding or false passed generic parameters.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
13. Mistakes in GENERATE expressions, i.e. extra/inadequate generation of
concurrent codes.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
14. Mistakes in function and procedure calls, i.e. false function name,
false ports and parameters.
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
15. others (please specify) : [ ]
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
16. others (please specify) : [ ]
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
-----------------------------------------------------------------------
17. others (please specify) : [ ]
< > almost always (90%-100%)
< > often (65%-90%)
< > sometimes (35%-65%)
< > seldom (10%-35%)
< > almost never (0%-10%)
----------------------------------------------------------------------------
----------------------------------------------------------------------------
You are welcome to comment on this survey:
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Article: 3807> The "proper" way to do this is to use one of the global clock nets to > clock all the D-types, and use clock enables to decide which actually > get clocked. I already do this, but I still get flakey operation. Re-routing with tightened (or even loosened!) frequency constraints can result in a working design, but I'm hesitant to trust these "fixes". Sometimes one part of a circuit will start working after re-routing, but another area will develop a problem. If I ever need to define frustration, this will serve me well. ---------------------------------------------------------------------- Jeff Hunsinger jeffh@oakhill-csic.sps.mot.comArticle: 3808
!! Semiconductor SuperSite.Net -- The Semiconductor SuperSite features a directory of 1,000 semiconductor vendors and thousands of products from semiconductor processing vendors. ******************** SuperSite.Net, Inc. Sales@SuperSite.Net http://SuperSite.Net *********************************** http://SuperSite.Net/Semiconductor/ http://SuperSite.Net/TechJobs/ ***********************************Article: 3809
In article <peter-2307961035010001@appsmac-1.xilinx.com>, peter@xilinx.com (Peter Alfke) wrote: >In article <DuyvHJ.50J@news.uwindsor.ca>, hajimow@engn.uwindsor.ca wrote: > >> I am using Xilinx 4000 series and I want to design a dual port RAM. > >Pelase don't even try to do that. >The XC4000E has additional hardware ( transistors ) that facilitate >dual-port RAM operation. The XC4000 does not. If you need true dual port >RAM operation, use the XC4000E. As a bonus, it is also cheaper than the >equivalent XC4000. Is there a VHDL model available which is also synthesizeable? BTW: As far I read the databook (1993) I saw that the dual ported ram cannot be written on both ports? Are there any Xilinx FPGAs available which support symmetrically dual ported ram operations? Ciao, GerhardArticle: 3810
> I haven't done a count, but it seems that your crusade against > these job postings have generated much more "noise" than the postings > themselves. I have to wonder about the effectiveness of your tactics > if your goal is to keep the group focused on technical issues. As > another poster stated, the job postings can be easily skipped in most > decent news readers. > Agreed. The amount of ANY postings to this group is so small that the few extra posts by headhunters (as long as they are looking for Cadence people) is not going to damage it. As it is there are more posts from those misguided AutoCAD people than messages about IC or PCB design texhnical issues. Another issue: It's easy to say "post into the jobs groups," but when is the last time you tried to go thru the 2000 or more posts a day posted to those various groups for the one or two posts a month for designers? IMHO, it's time to worry more about MAKING technical posts than worrying about the few posts that will show up here for jobs. If it bothers anyone THAT much, they ought to step forward to form a moderated Cadence group. -- +----------------------------------------------------------------+ | George H. Patrick III Take what you like and leave the rest | | gpatrick@aracnet.com My opinion ONLY | | George.Patrick@pii.com http://www.aracnet.com/~gpatrick | +----------------------------------------------------------------+Article: 3811
Hughes Research Laboratories has an immediate opening for a researcher to join our Embedded Real-Time Processing Project team developing special purpose, high performance, processors for embedded real-time signal and image processing. While specific duties will be matched to the skills of the team as a whole, anticipated job functions include developing special purpose processors at one or more levels of: architecture, performance modeling, HDL design, ASIC/FPGA design, digital circuit design, and board level design; developing software tools to support the design process, including runtime support software and application code for the special purpose. Additional responsibilities will include working with customers to analyze, identify and develop new research areas. Preference will be given to candidates with greater technical breadth. It is desired that candidates posses technical knowledge in several (not all) areas from the following list: digital system design (including custom ASIC, gate array, and FPGA design) computer architecture digital signal and image processing processor performance modeling software tool development hardware design in VHDL or Verilog software engineering programming in C or C++ for UNIX/WindowsNT parallel processing Candidates should possess a M.S. or Ph.D. in Electrical Engineering, Computer Engineering, or Computer Science; a Ph.D. is preferred. In addition, candidates should possess: strong verbal and written communications skills, the ability to function effectively in a team environment; and an openness to technical challenges and learning new skills. Based on government restrictions regarding the export of technical data, a U.S. citizenship or permanent resident status is required. HRL staff members are encouraged to invent, patent and publish on a regular basis. This commitment helps keep Hughes poised at the frontiers of electronics and information technology. Our ideal location, competitive salary and benefits package contribute to a work environment designed to optimize creative research. Please send your resume to: Lynn W. Ross Department 3DSWWW Hughes Research Laboratories 3011 Malibu Canyon Road, Malibu CA 90265 FAX: 310-317-5651 E-mail: lross@hrl.com. To learn more about HRL, visit our WebPage at http://www.hrl.com/ Proof of legal right to work in the United States is required. An Equal Opportunity Employer.Article: 3812
>I already do this, but I still get flakey operation. Re-routing with tightened >(or even loosened!) frequency constraints can result in a working design, but >I'm hesitant to trust these "fixes". Sometimes one part of a circuit will start >working after re-routing, but another area will develop a problem. Does it simulate OK, with a simulator? Which one? Another area, speaking from memory, is one of the command line switches on xnfmap (I think) which allows the use of the "direct" input. This has a nonzero hold time, whereas normal D-types have a zero hold time. Or something like that. But I never had problems with that. Peter.Article: 3813
Hello ... I would like to know the cost of the following devices Actel ... A1425A 84 pins 2,500 gates Actel ... A1240A 84 pins 4,000 gates Actel ... A14100A 257 pins 10,000 gates. Thanks for your help Bassam bxa8@po.cwru.edu -- Bassam A. Al-Kharashi email bxa8@po.cwru.eduArticle: 3814
Hello ... I would like to know the cost of the following devices Actel ... A1425A 84 pins 2,500 gates Actel ... A1240A 84 pins 4,000 gates Actel ... A14100A 257 pins 10,000 gates. Thanks for your help Bassam bxa8@po.cwru.edu -- Bassam A. Al-Kharashi email bxa8@po.cwru.eduArticle: 3815
Does the security fuse protect the fpga from beeing able to read it? -- Bassam A. Al-Kharashi email bxa8@po.cwru.eduArticle: 3816
In article <Pine.SUN.3.91.960805093518.21200A-100000@Bundy>, Rainer Scharnow <amigo@bintec.de> wrote: > Wanted to say the limitations of a specific device have to do with the > kind of logic I have to synthesize (bus oriented logic vs. state machine > oriented applications for example). Don't look for marketing literature to tell you that information. You would have to read between the lines, and you might still get the wrong information. Nobody, especially no marketing group, wants to say anything remotely negative about the products they are selling. I would be looking for information from users, especially universities. Regarding Xilinx devices, you may want to look up the app note "Chosing a Xilinx Product Family" on page 14-3 in the new 1996 Data Book that is being distributed right now. Your best bet may be on the web ( www.xilinx.com ). I wrote those 6 pages, and it is as close to being candid as you may ever get information from any supplier. Peter Alfke, Xilinx ApplicationsArticle: 3817
Xilinx 8100 series users may want to check out the August 5th EE Times cover page. Not surprising given all the problems with the part. -- Mark Christensen ascom-Nexion email: markc@nexen.com 289 Great Road ph: (508) 266-2315 Acton, MA 01720Article: 3818
Two Short Courses in Image Processing and Voice Recognition For more information and a complete brochure contact Andreas Spanias spanias@asu.eduArticle: 3819
ft63@dial.pipex.com (Peter) wrote: > [stuff deleted] > But I have more often come across a nastier problem, common to all > FPGAs: say you have a 16-bit shift register. Obviously, for a SR to > work, the clock skew stage-to-stage has to be less than the clock-to-Q > propagation delay. IOW, you ideally want to clock all the stages > together. True. Use the global clock to minimize skew. > [stuff deleted] > The "proper" way to do this is to use one of the global clock nets to > clock all the D-types, and use clock enables to decide which actually > get clocked. Of course, in my above SR example, they all get clocked > together anyway, but you may still need to gate the clocks, otherwise > the SR will be shifting all the time! > > Unless I am oversimplifying your problem, it is possible that this is > what you are seeing. Even if you do everything "synchronous", this is > where you get caught. > If you are gating clocks you are not synchronous! The right way to do this is to create an enable in the logic using feedback. This uses up two variables to the LUT but it is fast and avoids any clock skew problems. If you must gate the clock(avoidable in most cases) you should use the clock enable inputs to the CLBs, but beware their use can congest routing. -Ray Andraka Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 mailto:randraka@ids.net http://www.ids.net/~randraka/ The Andraka Consulting Group is a digital hardware design firm specializing in high performance FPGA designs. Services include complete design, development, simulation, and integration of these devices and the surrounding circuits. We also evaluate,troubleshoot, and improve existing designs. Please call or write for a free brochure.Article: 3820
Quick question for Model Tech. experts: How do you get around the problem of grouping individual signals to create and view a bus on Model Tech? If I start with a signal like counter(7 downto 0) and go through synthesis and place and route my final netlist now has eight individual signals representing counter(7 downto 0). Since Model Tech does not have the capablity to group signals; what'd be an easy way to group them back together at the netlist level? Regards, Kayvon Irani Lear AstronicsArticle: 3821
I'm using Xilinx's Xact 6.0 development set with the Viewlogic tools. It was my customer's choice. My problem is with the PROwave waveform display and editor tool. It seems to change the sequence of signals I specify in the PROsim wave command and displays them in a different apparently random fashion. For example, I say wave xyz.wfm a b c d in PROsim and PROwave displays the signals as d a c b or something different each time I run a simulation. Any help is greatly appreciated. It would sure be nice to see the simulation waveforms the way I want them. I you think the rest of the news group would benefit from an answer please post the reply here otherwise e-mail is fine. Regards, Mark Garaway mgaraway@deltanet.comArticle: 3822
Ray Andraka wrote: > > ft63@dial.pipex.com (Peter) wrote: > > > [stuff deleted] > > > But I have more often come across a nastier problem, common to all > > FPGAs: say you have a 16-bit shift register. Obviously, for a SR to > > work, the clock skew stage-to-stage has to be less than the clock-to-Q > > propagation delay. IOW, you ideally want to clock all the stages > > together. > > True. Use the global clock to minimize skew. > > > > [stuff deleted] > > > The "proper" way to do this is to use one of the global clock nets to > > clock all the D-types, and use clock enables to decide which actually > > get clocked. Of course, in my above SR example, they all get clocked > > together anyway, but you may still need to gate the clocks, otherwise > > the SR will be shifting all the time! > > > > Unless I am oversimplifying your problem, it is possible that this is > > what you are seeing. Even if you do everything "synchronous", this is > > where you get caught. > > > If you are gating clocks you are not synchronous! The right way to > do this is to create an enable in the logic using feedback. This uses > up two variables to the LUT but it is fast and avoids any clock skew > problems. If you must gate the clock(avoidable in most cases) you > should use the clock enable inputs to the CLBs, but beware their use > can congest routing. There is no difference between creating an enable in the logic and using the clock enable input (which just wraps the ff output back to the ff input.) Using the enable is not the same as gating the clock. The former doesn't change the clock timing as it only controls the feedback path. AFAIK using the CE inputs does not congest routing anymore than using a logic contrived CE, unless the signal that drives the CE is sourced within the same CLB and therefore doesn't need local interconnect. Regards, ScottArticle: 3823
Hello,
I am designung for ALTERA devices (namely EPM9560, EPF10K50)
using SYNOPSYS-FPGA-compiler and Maxplus2. I want to put
my pin assignments into the VHDL-source.
I know that I can edit the .acf file, but Maxplus2-online help tells
that it can be done using EDIF-properties, too.
Now I do not know how to produce these property entries with
FPGA compiler. Attributes on the speciphic ports seem to be ignored.
Is there another way to get around (some kind of awk script,
that extracts the pin assignments and inserts them into the edif file.
I guess this is tedious to write this.
Thanks in advance.
Andreas
--
---------------------------------------------------------------
Andreas Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Email: doering@iti.mu-luebeck.de
----------------------------------------------------------------
Article: 3824Ray Andraka <randraka@ids.net> wrote: >ft63@dial.pipex.com (Peter) wrote: >> >[stuff deleted] > >> But I have more often come across a nastier problem, common to all >> FPGAs: say you have a 16-bit shift register. Obviously, for a SR to >> work, the clock skew stage-to-stage has to be less than the clock-to-Q >> propagation delay. IOW, you ideally want to clock all the stages >> together. > >True. Use the global clock to minimize skew. You may manually route clock back to the data flow. So, if data goes from 1 to 16 register, clock goes to clock16 !before! then to clock15 and so on. This kills your problem. Best regards. Alex
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