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
jcooley@world.std.com (John Cooley) wrote: >Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of >Easics, both complained of having to deal with type conversions in VHDL. In actual design practice, type conversions in VHDL are the least of my problems. The clue is to choose types well, and to have the freedom to do so. Rather, in my feedback on the contest, I remarked that I was forced to design in a "bit-oriented" way which, among other disadvantages, makes a lot of type conversions unavoidable, and which I therefore consider to be suboptimal. In a real project, I would choose a constrained integer type for a count, booleans for flags, and an enumerated type for the control, instead of the unavoidable std_logic(_vector) for everything. std_logic was invented to make gate-level and sign-off simulation possible and competitive with Verilog (it didn't succeed very well) but it has little to do with the concept of "high-level design" (still, it has been very efficient in making a mess of that concept in a lot of places). Using VHDL without using high-level typing capabilities is like using C++ without classes. I makes no sense. In that case, better use Verilog, or C. Regards, Jan -- =================================================================== Jan Decaluwe === Easics === Design Manager === VHDL-based ASIC design services === E-mail: jand@easics.be =================================== Tel: +32-16-270 400 Fax: +32-16-270 319 Kapeldreef 60, B-3001 Leuven, BELGIUMArticle: 1876
In article <1995Sep13.151045.40585@waikato.ac.nz> pac1@waikato.ac.nz writes: > >I'm trying to download a makebit from xact5 to a XC3030 PGA via LPT1 cable to a >XC1736 socket. > > >After I reset the PGA, XACT5 says "programming ....." and then "done still low" >or something like this as if the PGA is not programmed correctly so it isn't >putting Done pin high. > > >Anyone had this problem - - can you give any suggestions on my problem? > >Regards, PC (Peter Cossey) If you have wired the 1736 socket up right, then this is unlikely to work. This is because the 1736 connected to the FPGA usually requires the FPGA to be set in Master Serial mode. The download cable requires the FPGA to be in Slave Serial mode. You would need to deal with this difference first. Usually, I have a 5 pin headder on my pcb with VCC, GND, CCLK, D/P*, and DIN. If I'm going to use a 17xx as well then there is a dipswitch to change between Master and slave serial mode. Also check the following: Pull up resistor on all of the following signals: D/P* INIT PowerDown. If this doesn't get you going, you need to give more info. All the best, Philip Freidin.Article: 1877
Ola Torudbakken (otoe@si.sintef.no) wrote: : I need some recommendation of FPGA's which may achieve a system speed : of 40MHz. I'm not interested in hearing about FPGA products which can XC3100-3 family. Use timing-driven place and route, limit full speed logic to 3 levels of CLB combinatorial logic between registers, 1 level from chip inputs, and use IOB FFs for all chip outputs.Article: 1878
Solution: Move the entire ORCA project from Allentown to sunny New Mexico, or maybe Rancho Bernardo CA.... You probably wouldn't have to recruit so hard. Doug Shade rxjf20@email.sps.mot.comArticle: 1879
Hi all,
Is anyone using the Altera 8820A? I'm trying to
download one using the Bitblaster, and the download
process is unable to complete. Altera has suggested things
to check, but they appear to be stumped at this point. I'm
wondering if I'm the first to discover a bug in the software
for a relatively new part. Our setup works just fine with the
8452A and MAXPLUS2 version 5.4.
All replies appreciated.
L
==========================================================================
Lyle Kraft AA6LK
##################### Hewlett-Packard
###### /_ _ ###### System Interconnect Lab -
##### / / /_/ ##### Information Networks Division
###### / ###### Roseville, CA 95747-5601
##################### 916-785-5798 FAX 916-785-2875
lkraft@core.rose.hp.com
==========================================================================
Article: 1880
jcooley@world.std.com (John Cooley) wrote:
>Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of
>Easics, both complained of having to deal with type conversions in VHDL.
Jan Decaluwe <jand> wrote:
>The clue is to choose types well, and to have the freedom to do so.
>Rather, in my feedback on the contest, I remarked that I was forced to design
>in a "bit-oriented" way which, among other disadvantages, makes a lot of type
>conversions unavoidable, & which I therefore consider to be suboptimal. In a
>real project, I would choose a constrained integer type for a count, booleans
>for flags, and an enumerated type for the control, instead of the unavoidable
>std_logic(_vector) for everything.
>
>std_logic was invented to make gate-level and sign-off simulation possible
>and competitive with Verilog (it didn't succeed very well) but it has
>little to do with the concept of "high-level design" (still, it has been
>very efficient in making a mess of that concept in a lot of places).
Jan, I'm sorry but I couldn't disagree with you more on this topic. Maybe
being able to mix & match a wide variety of data types *might* be useful
in a large project, but I think they're just a source of headaches for
designers on small projects. That is, using std_logic(_vector) for all
the signals in the 9-bit up/down counter makes life easier. (What does it
buy the hardware designer to use a fruity mix of data types on such a
small design as this? It's not going to be instantiated into a design with
37 layers of hierarchy; it's just a simple counter.)
I personally tend to see hardware when I design hardware, so, to me, a wide
mix of data types is just a source of design confusion.
On a broader scale, the "strong typing" question turned out to be one of
the more controversial topics I got feedback on from the 317 engineers who
responded to the write-up. The 88 who commented on "typing" with:
If the engineer had:
VHDL-only experience: 15% hated strong typing
19% loved strong typing
11% noted but couldn't decide
if it was good or bad
-----------------------------
45% had something to say on this
Bilingual experience: 29% hated strong typing
9% loved strong typing
9% noted but couldn't decide
if it was good or bad
-----------------------------
49% had something to say on this
Verilog-only and
unknown experience: 5% hated strong typing
3% loved strong typing
4% noted but couldn't decide
if it was good or bad
-----------------------------
12% had something to say on this
- 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 3713 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: 1881In article <DEvyE5.64L@hpqmoea.sqf.hp.com>, mjm@hpqtdzk.sqf.hp.com (Murdo McKissock) writes: > Ola Torudbakken (otoe@si.sintef.no) wrote: > > : I need some recommendation of FPGA's which may achieve a system speed > : of 40MHz. I'm not interested in hearing about FPGA products which can > > XC3100-3 family. Use timing-driven place and route, limit full speed logic to > 3 levels of CLB combinatorial logic between registers, 1 level from chip > inputs, and use IOB FFs for all chip outputs. I've already used them in a previous design. The problem is the routing resources available. I've had really trouble getting these up to 20MHz (xc3195a) (large design). I think its possible to go as high as 30MHz, if you are using a lot of effort with the placing and routing, but not any further. You should also remember that the Xilinx people haven't managed to run a state machine (25 states, 40 transitions) faster than 30MHz, and still then the design contained only the fsm. So, always look at fsm designes from the vendor, when you're lookin for speed. OlaArticle: 1882
In article <DExErq.L5u@world.std.com>, jcooley@world.std.com (John Cooley) writes: |> jcooley@world.std.com (John Cooley) wrote: |> >Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of |> >Easics, both complained of having to deal with type conversions in VHDL. |> |> Jan Decaluwe <jand> wrote: |> >The clue is to choose types well, and to have the freedom to do so. |> >Rather, in my feedback on the contest, I remarked that I was forced to design |> >in a "bit-oriented" way which, among other disadvantages, makes a lot of type |> >conversions unavoidable, & which I therefore consider to be suboptimal. In a |> >real project, I would choose a constrained integer type for a count, booleans |> >for flags, and an enumerated type for the control, instead of the unavoidable |> >std_logic(_vector) for everything. |> > |> >std_logic was invented to make gate-level and sign-off simulation possible |> >and competitive with Verilog (it didn't succeed very well) but it has |> >little to do with the concept of "high-level design" (still, it has been |> >very efficient in making a mess of that concept in a lot of places). |> |> Jan, I'm sorry but I couldn't disagree with you more on this topic. Maybe |> being able to mix & match a wide variety of data types *might* be useful |> in a large project, but I think they're just a source of headaches for |> designers on small projects. That is, using std_logic(_vector) for all |> the signals in the 9-bit up/down counter makes life easier. (What does it |> buy the hardware designer to use a fruity mix of data types on such a |> small design as this? It's not going to be instantiated into a design with |> 37 layers of hierarchy; it's just a simple counter.) |> |> I personally tend to see hardware when I design hardware, so, to me, a wide |> mix of data types is just a source of design confusion. |> Hi, I can't resist getting in this discussion also. John, according to me, you don't get Jan's point. He - and others - do make quite abstraction from the hardware they are describing. Hence they wouldn't describe a counter in terms of std_logic_vector. They simply use an constrained integer type, which doesn't demand mixing of types. I think this certainly will be the approach in the future. Then one will not be concerned about describing hardware on bit or FF level. One will describe larger systems on a behavioral level. The used data types will be integers, records, arrays and so. On the other hand, Jan, one must be very aware that there is some danger in using the integer f.i. for a counter. By restricting the values of the counter to only correct and allowed values, one is not able anymore f.i. to catch a reset problem. If one of your integer counters is not reset, you won't catch it. When using the more hardware related types such as std_logic, your simulation will catch the error. Probably you will argue - and not wronly - that this kind of troubles must be catch in the later gatelevel simulations. However my personal experience is that it is, up to now, quite difficult to validate gatelevel's which behaviour differs from the behavioral description. And they certainly will do when the types of the behavioral (integers ...) and the gatelevel (std_logic ...) differ. The type of problem in the contest is - according to me - a problem of yesterday. The problem was a low level hardware problem. ( Didn't you say "tend to see hardware when I design hardware") This kind of problems I would - having years of experience as well in Verilog as in VHDL - describe in Verilog. This is also the outcome of your experiment. The approach of Jan is the one of tomorrow. It is very appropriate for describing complex systems, quite hardware independent. It does ask however more of synthesis and validation tools. It does ask also a strong language. I think it is here that VHDL will be the first choice. A problem is that I nowadays have the kind of problems between both levels. Regards. Jos De Laender, Alcatel Bell - SH144 Antwerp Belgium (This are my opinions and they are not necessarily those of Alcatel Bell)Article: 1883
Does anyone make an EEPROM version of the Xilinx XC17256D configuration PROM? TIA - AlanArticle: 1884
In Article <43b8a2$hsq@hermetix.si.sintef.no> otoe@si.sintef.no (Ola Torudbakken) writes: > >In article <DEvyE5.64L@hpqmoea.sqf.hp.com>, mjm@hpqtdzk.sqf.hp.com (Murdo >McKissock) writes: >> Ola Torudbakken (otoe@si.sintef.no) wrote: >> >> : I need some recommendation of FPGA's which may achieve a system speed >> : of 40MHz. I'm not interested in hearing about FPGA products which can >> >> XC3100-3 family. Use timing-driven place and route, limit full speed logic to >> 3 levels of CLB combinatorial logic between registers, 1 level from chip >> inputs, and use IOB FFs for all chip outputs. > >I've already used them in a previous design. The problem is the routing >resources available. I've had really trouble getting these up to 20MHz >(xc3195a) (large design). I think its possible to go as high as 30MHz, if you >are using a lot of effort with the placing and routing, but not any further. >You should also remember that the Xilinx people haven't managed to run a state >machine (25 states, 40 transitions) faster than 30MHz, and still then the >design contained only the fsm. >So, always look at fsm designes from the vendor, when you're lookin for speed. > > The 3K family can easily reach 40 MHz. I have done designs in the -7 part that ran at 35 Mhz with no floorplanning and no extraordinary heroics. That design was in a 3042A-7, used all but 3 CLBs and had over 200 flip flops. The design decoded commands from a bastardized I2C, interfaced a UART, scanned, debounced and encoded a keypad, and interfaced a smart card. The design included arbitration logic for the I2C master as well. This design contained several fairly complex state machines. I set the 4 global timing parameters, but did nothing else to set up PPR. Just pushed the button and went to lunch. The trick is to pay attention to the device architecture when you do the design. Keep the combinatorial logic to one level whenever at all possible (yes this is possible more than is obvious...pipeline your decodes and state machines). Use OHE statemachines, and LFSR counters for timers. Without doing anything special with the tool (ie floorplanning or handcrafting), you should be able to get at least 35 Mhz out of a -3 part. If you don't believe me I'd be happy to show you how to do it (on your nickel :-) ). -Ray Andraka Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 email randraka@ids.net The Andraka Consulting Group is a digital hardware design firm specializing in obtaining the maximum performance from FPGAs. 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: 1885
otoe@si.sintef.no (Ola Torudbakken) writes: > > I need some recommendation of FPGA's which may achieve a system speed > of 40MHz. I'm not interested in hearing about FPGA products which can > be used to implement really fast counter designs. What I'm looking at, > is an FPGA which can operate at a system speed of 40MHz. The design > implements a big state machine and a quite complex data-path. > > Ola For the big state machine you ought to look at the Lattice CPLD's instead Thay are ideally suited for state machines and can easily wotk at system speeds of up to and over 100 MHz.Article: 1886
otoe@si.sintef.no (Ola Torudbakken) wrote: > >In article <DEvyE5.64L@hpqmoea.sqf.hp.com>, mjm@hpqtdzk.sqf.hp.com (Murdo McKissock) writes: >> Ola Torudbakken (otoe@si.sintef.no) wrote: >> >> : I need some recommendation of FPGA's which may achieve a system speed >> : of 40MHz. I'm not interested in hearing about FPGA products which can >> >> XC3100-3 family. Use timing-driven place and route, limit full speed logic to >> 3 levels of CLB combinatorial logic between registers, 1 level from chip >> inputs, and use IOB FFs for all chip outputs. > >I've already used them in a previous design. The problem is the routing resources available. I've had really trouble getting these = up to 20MHz (xc3195a) (large design). I think its possible to go as high as 30MHz, if you are using a lot of effort with the placing= and routing, but not any further. >You should also remember that the Xilinx people haven't managed to run a state machine (25 states, 40 transitions) faster than 30MH= z, and still then the >design contained only the fsm. >So, always look at fsm designes from the vendor, when you're lookin for speed. > > > >Ola One of the best methods to improve state machine performance for Xilinx FPGAs is to use something called "one-hot" encoding. Most state machine compilers create a highly-encoded state machine (few flip-flops, lots of combinatorial logic). Highly-encoded state machines are great for PAL devices and EPLDs because they match the sum-of-product architecture. Most FPGA architectures have the opposite trade-off (lots of flip-flops, smaller pieces of combinatorial logic). The one-hot encoding (OHE) method is tailored to the FPGA architecture. The encoding is built into Xilinx' X-ABEL product. We've also described how to use it with other synthesis products in our "HDL Synthesis for FPGAs Design Guide" publication available on the Xilinx WebLINX site at http://www.xilinx.com/products/appsweb.htm#FPGA Or, you can also it from our Literature Support on CD-ROM by contacting 'karene@xilinx.com'. A summary description of this technique and other applicable state machine design approaches can also be found in the 1994 XILINX DATA BOOK beginning on page 8-169. The OHE method has the following advantages: * Very few levels of logic between flip-flops ==> high performance * Localized feedback and little fanout on state signals ==> easy routing * Conceptually easy to understand ==> state diagrams look like a flow chart (see the diagram on page 8-172 in the Xilinx Data Book) Depending on the state machine's complexity, you can expect clock rates much greater than 40 MHz with OHE. -- Steve K. Knapp Corporate Applications Manager Xilinx, Inc.Article: 1887
You wrote: > >Ola Torudbakken (otoe@si.sintef.no) wrote: > >: I need some recommendation of FPGA's which may achieve a system speed >: of 40MHz. I'm not interested in hearing about FPGA products which can > >XC3100-3 family. Use timing-driven place and route, limit full speed logic to >3 levels of CLB combinatorial logic between registers, 1 level from chip >inputs, and use IOB FFs for all chip outputs. Or... You could have just used a QuickLogic part and gotten the job done without hassle. Bill Cox cox@qlogic.comArticle: 1888
In article <4377gm$r61@news.Belgium.EU.net> Jan Decaluwe <jand> writes: > Rather, in my feedback on the contest, I remarked that I was forced to design > in a "bit-oriented" way which, among other disadvantages, makes a lot of type > conversions unavoidable, and which I therefore consider to be suboptimal. In a > real project, I would choose a constrained integer type for a count, booleans > for flags, and an enumerated type for the control, instead of the unavoidable > std_logic(_vector) for everything. This is the whole point of a VHDL based design process. Start at the highest appropriate level of abstraction and decompose once the design unit is verified. If synthesis can handle the higher level of abstraction, then leave it abstract. Coding in a ' "bit-oriented" way' does however become necessary when you have to get down and dirty with things like EDAC, parity etc. > std_logic was invented to make gate-level and sign-off simulation possible > and competitive with Verilog. Uh... Actually std_logic was the product of the desire to be able to create interoperable models. The effort was begun as part of an EIA initiative to provide VHDL models of commercial parts that could be used together with perhaps your own home grown models. It ws specicically stated that the interface standard was neither required nor necessarily desirable inside of the model, only where the model was expected to "talk" to other models. > Using VHDL without using high-level typing capabilities is like using C++ > without classes. I makes no sense. In that case, better use Verilog, or C. Here, Hear!! -- --------------------------------------------------------------------------- John Winkler Voice (813) 539-2007 Honeywell Inc./MS 934-4 FAX (813) 539-2183 13350 U.S. Highway 19 North winkler@space.honeywell.com Clearwater, FL 34624-7290 Mac: jewinkler@space.honeywell.com ---------------------------------------------------------------------------Article: 1889
I'm using an EPM5016 in a small project. I'm using 4 i/o pins for 2 NOT gates osc. The component is getting very very hot (after about 5 min.) Does anybody knows why? Thanks in advance. R.HArticle: 1890
Here's one story on how One-Hot Encoding improved real-life performance. In my Ph.D. Qualifying Exams one problem was to design an 8-bit error detecting code and design the circuit that implements the error detection on an incoming bit stream. The time allotted to this complete problem was about 30-45 mins. (as there were other similarly tough questions I had to spend time on). The 2 out of 8 error detection code design was done quickly, and the dumb-but-quick state transition diagram of the error detector took 2 pages. To translate the state diagram quickly into FFs and gates, I assigned one FF per state, quickly drew up the state transition logic from one FF to the next, and, Voila! an almost complete circuit design (which, if simulated, would definitely not work.) I got 80% credit for that problem - which is as good as getting 100% -- it was not circuit correctness that mattered but design knowledge and methodology. If I had to implement that state diagram with as few FFs as possible, that problem would have taken the entire day by itself. Joe -- USE std.disclaimers.all; -- I don't speak for Intel Corp.Article: 1891
I am presently starting a project using emitter coupled logic (ECL). Does anyone know of a manufacturer of ECL fpga. The data rate that must be achieved is 150 mbits/sec, and the input voltage is ECL. One of the task is to be built a P-N sequence decoder. Thanks.Article: 1892
The Design Automation Conference is looking for papers on design experiences
and design methods. The idea is to disuss leading-edge electronic or
electro-mechanical systems (ATM, RF, Processors), designs with difficult
constraints (development time, low power, high speed or unusual environment)
or designs using cutting-edge design technology (high-level synthesis,
formal verification, layout generation). The papers should focus more on
HOW the devices were built (the DESIGN METHODS), rather than how they do
their function.
They can be success stories or horror stories (we accept good news or bad).
The tools used can be commercial tools or proprietary. It is OK to name
names. We want the truth, not sanitized marketing pitches.
Last year we had some interesting papers on the design techniques used to
build leading-edge and well-know designs (for example, we had a whole session
from Sun on the design of the UltraSparc).
Watch the WWW for updates! (http://www.dac.com/dac.html)
-------------
DAC DESIGNER TRACK
CALL FOR PAPERS
33rd DESIGN AUTOMATION CONFERENCE
LAS VEGAS CONVENTION CENTER
JUNE 3 - 7, 1996
The Design Automation Conference, the premier conference in the DA field,
has broadened its scope to include the use of automation in the design of
electronic systems. The user oriented sessions of the 1995 DAC
attracted large audiences and were very successful.
We encourage submissions which will interest circuit and systems
designers, design managers and DA support engineers.
Now is your chance to participate in the 1996 DAC!
DESIGNER TRACK TOPICS OF INTEREST
The Design Automation Conference has expanded its emphasis on the use of DA
tools. We are soliciting papers and proposals for panels and tutorials of
interest to system and circuit designers, design managers and DA support
engineers. Topics can include (but are not limited to) the suggested
subjects listed below:
9.1 Complete DA Systems
Integration of Vendor DA Tools;
Design Information Management
9.2 User Experience with DA Systems
The Design of State-of-the-art Systems;
Tool Integration Experience
9.3 Electronic Design Using DA
Silicon strategies: FPGA, PLD, ASIC;
Design reuse; Design for Manufacture
9.4 Management of DA Systems
Standards issues: VHDL/CFI/EDIF;
Modeling and Component Libraries;
Design Team Organization
9.5 Design Methodology
Advanced Methodology:
ASIC/Low Power/Deep Submicron;
Design Flows for DSP/Communication/RF/High-Reliability;
Rapid Prototyping and Emulation;
Concurrent Engineering
Other topics of interest to DA researchers, developers, managers and
users are encouraged. For questions regarding the suitability of your
topic, contact the Design Methods Chair: design.methods@dac.com.
PANELS, TUTORIALS, SPECIAL TOPIC SESSIONS
Proposals for Panels, Tutorial Sessions, and Full-Day Tutorials should be
submitted to the Program Chair no later than October 6, 1995.
Proposals should not exceed two pages in length. Proposals must describe
the topic and intended audience; provide a list of participants, with
address and phone number (including the moderator for panels); and the
name, phone number and complete mailing address of the contact person. All
participants must be contacted prior to submission of the proposal. All
proposals will be reviewed.
For further information, send a one-line Email message to
proposals@dac.com
Special Topic Sessions may be either independent papers with a common
theme or a set of closely related papers describing an overall system. In
both cases,independent reviews of each paper and evaluation of the session
as a whole will be used to select sessions. Proposals for Special Topic
Sessions should be submitted along with the list of papers to be included
in the session and should describe the sessionOs theme. These proposals
and paper submissions must be postmarked no later than October 6, 1995.
DAC TOOLS TRACK
DAC is the premier conference devoted solely to the field of Design
Automation. All aspects of the use of computers as aids to the design
process are welcome, from conceptual design through manufacturing. Four
types of submissions are invited: regular papers, special topic sessions,
panels, and tutorials.
TOPICS OF INTEREST
Authors are invited to submit original technical papers describing recent
and novel research or engineering developments in all areas of design
automation.
Topics include, but are not limited to:
1.1 Electrical Simulation
1.2 Discrete Simulation
1.3 Timing Analysis and Verification
2.1 Testing, Fault Modeling and Simulation, Test Pattern Generation,
Test Validation and Design-for-Testability
2.2 Design and Implementation Verification
3.1 Floorplanning and Placement
3.2 Global and Detailed Routing
3.3 Physical Module Generation, Symbolic Layout, Compaction,
Layout Verification
4.1 Technology-Independent, Combinational Logic Synthesis and
Optimization
4.2 Technology Mapping and the Interaction between Logic
Synthesis and Layout
4.3 Sequential Synthesis and Optimization
4.4 High-Level Synthesis and System-Level Design Aids
4.5 Asynchronous Synthesis
5.1 Hardware Description Languages
5.2 Design Systems and Databases
6.1 Computer Aids for IC Fabrication and
Manufacturing, Technology CAD
7.1 DA for Analog Circuits
7.2 High-Speed Systems and Microwave DA
7.3 DA for Electronic Packaging
8.1 Human Factors in DA
8.2 Frameworks and Software Engineering in DA
8.3 Hardware/Software Codesign, Concurrent Engineering, Issues
in System Design
9.1 Complete DA Systems
9.2 User Experience with DA Systems
9.3 Electronic Design Using DA
9.4 Management of DA Systems
9.5 Design Methodology
REQUIREMENTS FOR SUBMISSION OF PAPERS
Authors should submit their papers to the Program Chair postmarked no
later than October 6, 1995. Previously published papers, including
workshop proceedings, will not be considered. Each submission should
include one cover page and ten (10) stapled copies of the complete
manuscript.
The one cover page should include:
-Name, affiliation, and complete address for each author
-A designated contact person including his/her telephone number,
fax number, and email address
-A designated presenter, should the paper be accepted
-A list of topic numbers, ordered by relevancy, most clearly
matching the content of the paper
The following signed statement: "All appropriate organizational
approvals for the publication of this paper have been obtained. If
accepted, the author(s) will prepare the final manuscript in time for
inclusion in the Conference proceedings and will present the paper at
the Conference."
To permit a blind review, do not include name(s) or affiliation(s) of
the author(s) on the manuscript. Include:
-Title of paper
-60 word abstract indicating significance of contribution. The
abstracts of accepted papers will appear on the World Wide Web before
the Conference.
-The complete text of the paper in English, including all
illustrations and references, not exceeding 5000 words. The papers
will be reviewed as finished papers. Preliminary submissions will be
at a disadvantage.
Notice of acceptance will be mailed to the contact person by Feb 16, 1996.
Authors of accepted papers must sign a copyright release form.
PROGRAM CHAIR
MP Associates, Inc.
ATTN: Program Chair, 33rd DAC
5305 Spine Rd., Suite A
Boulder, Colorado 80301
For information call: (303) 530-4333
Watch the WWW for updates! (http://www.dac.com/dac.html)
Article: 1893In article <43fgn7$45f@news.Belgium.EU.net>, Jan Decaluwe <jand> wrote: >jcooley@world.std.com (John Cooley) wrote: > >>Jan, I'm sorry but I couldn't disagree with you more on this topic. > >John, thanks for disagreeing! I have no doubt that the opinion you >express is the one held by the majority of the design community. As I >am convinced that it leads to suboptimal design productivity, it was >not the first time that I suggested this "controversial" approach in >this newsgroup, in the hope to trigger the discussion. But until now, >to my surprise and disappointment, no one cared to disagree! (and >then there's no discussion, of course.) > >>I personally tend to see hardware when I design hardware, > >This argument is widely used against design methodologies that rely >on higher levels of abstration. I believe it is misleading. It is the >same argument that schematic entry addicts use(d) against RTL synthesis. >However, I feel safe to assert, John, that you're a convicted synthesis user!! > >Using synthesis implies that you think about hardware at a certain >abstraction level, and that you let the tool handle the hardware >details below that level. It's a trade-off between a certain amount >of lost visibility (but not necessarily lost design efficiency!) and >design productivity. The question is where to put that abstraction level >for optimal results in terms of design efficiency and productivity. > >Regards, Jan > I have to agree with Jan - the higher level the description, the better. The only difficult part is making sure that you still describe the complete behavior at the higher level. This means that you need tools that can cope with the higher-level description, and also spot when things are missing (more like a synthesis-expert tool, in the old AI days).Article: 1894
jcooley@world.std.com (John Cooley) wrote: >Jan, I'm sorry but I couldn't disagree with you more on this topic. John, thanks for disagreeing! I have no doubt that the opinion you express is the one held by the majority of the design community. As I am convinced that it leads to suboptimal design productivity, it was not the first time that I suggested this "controversial" approach in this newsgroup, in the hope to trigger the discussion. But until now, to my surprise and disappointment, no one cared to disagree! (and then there's no discussion, of course.) >I personally tend to see hardware when I design hardware, This argument is widely used against design methodologies that rely on higher levels of abstration. I believe it is misleading. It is the same argument that schematic entry addicts use(d) against RTL synthesis. However, I feel safe to assert, John, that you're a convicted synthesis user!! Using synthesis implies that you think about hardware at a certain abstraction level, and that you let the tool handle the hardware details below that level. It's a trade-off between a certain amount of lost visibility (but not necessarily lost design efficiency!) and design productivity. The question is where to put that abstraction level for optimal results in terms of design efficiency and productivity. Regards, Jan -- =================================================================== Jan Decaluwe === Easics === Design Manager === VHDL-based ASIC design services === E-mail: jand@easics.be =================================== Tel: +32-16-270 400 Fax: +32-16-270 319 Kapeldreef 60, B-3001 Leuven, BELGIUMArticle: 1895
jdla@btmp09.be (jos de laender sh144 7461) wrote: >I can't resist getting in this discussion also. Jos, thank you for agreeing! Just 2 remarks: >The approach of Jan is the one of tomorrow. I obviously agree. However, this statement reminded me of a statement commonly made about Brasil: "Is is the country of the future ... and it always will be !!". Let there be no doubt: this methodology is perfectly applicable today. In our design services at Easics we have been using it during the past 3.5 years to design a number of complex chips with (I believe) considerable success in design quality, productivity, and satisfied customers. >On the other hand, Jan, one must be very aware that there is some >danger in using the integer f.i. for a counter. By restricting the values of >the counter to only correct and allowed values, one is not able anymore f.i. >to catch a reset problem. If one of your integer counters is not reset, >you won't catch it. When using the more hardware related types such as >std_logic, your simulation will catch the error. >Probably you will argue - and not wronly - that this kind of troubles >must be catch in the later gatelevel simulations. Our approach to this problem is a combination of methodology and "formal" check (much better than simulation). Our policy is to make every FF resettable (with very few exceptions). After synthesis, we check on the type of flip-flops used (in the report -reference synthesis report). If you think about it, it could be argued that the synthesis tool itself should synthesize the reset value from the initial value at the start of the simulation. Regards, Jan -- =================================================================== Jan Decaluwe === Easics === Design Manager === VHDL-based ASIC design services === E-mail: jand@easics.be =================================== Tel: +32-16-270 400 Fax: +32-16-270 319 Kapeldreef 60, B-3001 Leuven, BELGIUMArticle: 1896
Hi folks, I found that editor that I was looking for. It's called Crisp and beats the hell out of anything I have ever seen on UNIX. it's not PD but it's worht every bit of the $350 for a node locked lic. or $550 for a floating lic. It runs on just about any flavor of UNIX. Kent -- /* "There is no king who has not had a slave among his ancestors and */ /* no slave that has not had a king among his." ---- Helen Keller */ /* Kent L. Shephard ----- K. L. Shephard Consulting */Article: 1897
winkler@ews2dev.cfen.honeywell.com (John E. Winkler) wrote: >In article <4377gm$r61@news.Belgium.EU.net> Jan Decaluwe <jand> writes: >> std_logic was invented to make gate-level and sign-off simulation possible >> and competitive with Verilog. > >Uh... Actually std_logic was the product of the desire to be able to >create interoperable models. The effort was begun as part of an EIA >initiative to provide VHDL models of commercial parts that could be >used together with perhaps your own home grown models. You're right. I mixed up a valuable primary purpose with a by-product. >It ws specicically stated that the interface standard was neither required >nor necessarily desirable inside of the model, only where the model >was expected to "talk" to other models. .. and still, it went wrong. Regards, Jan -- =================================================================== Jan Decaluwe === Easics === Design Manager === VHDL-based ASIC design services === E-mail: jand@easics.be =================================== Tel: +32-16-270 400 Fax: +32-16-270 319 Kapeldreef 60, B-3001 Leuven, BELGIUMArticle: 1898
winkler@ews2dev.cfen.honeywell.com (John E. Winkler) wrote: >In article <4377gm$r61@news.Belgium.EU.net> Jan Decaluwe <jand> writes: >> std_logic was invented to make gate-level and sign-off simulation possible >> and competitive with Verilog. > >Uh... Actually std_logic was the product of the desire to be able to >create interoperable models. The effort was begun as part of an EIA >initiative to provide VHDL models of commercial parts that could be >used together with perhaps your own home grown models. You're right. I mixed up a valuable primary purpose with a by-product. >It ws specicically stated that the interface standard was neither required >nor necessarily desirable inside of the model, only where the model >was expected to "talk" to other models. .. and still, it went wrong. Regards, Jan -- =================================================================== Jan Decaluwe === Easics === Design Manager === VHDL-based ASIC design services === E-mail: jand@easics.be =================================== Tel: +32-16-270 400 Fax: +32-16-270 319 Kapeldreef 60, B-3001 Leuven, BELGIUMArticle: 1899
We have been informed by the manuf. AMD that the production of this device will be stopped in the coming weeks. does anyone know a second source of this pld? or a similar device? the major features of this pal are: - High output current drive capability (64ma Iol) - Programmable Totem-Pole or Open Drain Outputs - 200 mV Histeresis - Programmable Direct or latched Inputs. regards, Maurizio Lippi +------------------------------------------------------------------------+ + Maurizio Lippi R&D Division + + + + CAEN SpA + + Via Vetraia, 11 50049 VIAREGGIO (ITALY) + + Tel. +39 584 388 398 Fax +39 584 388 959 + + E-Mail: lippi@caen.it URL: http://www.caen.it + +------------------------------------------------------------------------+
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