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
Hello all, I'm working on a project where I need to do manchester code conversion. Output is easy, but input clock recovery is less than trivial. I need to know if anyone has a reference design for an fpga to do this across 2048 bits. Thanks, danArticle: 4126
orachat@imap2.asu.edu wrote: > > Are there anybody having experiences on writing VHDL code for FPGA > multiplier? I would like to get a suggestion or openion which > multiplication arichitecture is appropriate for FPGA. If you have sample > VHDL source code, it will be wonderful! Some VHDL synthesis tools sush as Exemplar can handle the multiplier operator (*). To see which FPGA may be more appropriate for this function if you don't have access to Exemplar check out the September issue of APP Review by Synario Design Automation. Hope this helps.Article: 4127
FPGA'97: Call for Papers
1997 ACM/SIGDA Fifth International Symposium on
Field-Programmable Gate Arrays
Sponsored by ACM SIGDA, with support from Altera, Xilinx, and Actel
Monterey Beach Hotel, Monterey, California
February 9-11, 1997
(Web page: http://www.ece.nwu.edu/~hauck/fpga97)
The annual ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related to the FPGA technology. The topics of interest of this symposium
include, but are not limited to:
o Advances in FPGA architectures, including design of programmable logic blocks,
programmable interconnects, programmable I/Os, and development of new
FPGAs and field-configurable memories.
o New CAD algorithms and tools for FPGAs, including new algorithms for
sequential and combinational logic optimization, technology mapping,
partitioning, placement, routing, and development of new FPGA synthesis or
layout systems.
o Novel applications of FPGAs, including rapid prototyping, logic emulation,
reconfigurable custom computing, and dynamically reconfigurable
applications.
o Advances in field-programmable technology, including new process
and fabrication technologies, and field-programmable analog arrays.
Authors should submit 20 copies of their original work by September 27, 1996.
Each submission should include an 100-250 words abstract, and is limited
in length to 12 pages (including figures and tables, minimum point size 10).
Notification of acceptance will be sent by November 18, 1996.
A proceedings of accepted paper will be published by ACM.
Authors must assign copyright of their accepted papers to ACM as a condition
of publication. Final versions of accepted papers will be limited
to seven pages, and must be submitted by December 6, 1996.
All submissions should include the e.mail addresses of the authors, as all
correspondence with authors will be done via e.mail.
Submissions should be sent to:
Prof. Jason Cong
FPGA'97 Program Chair
UCLA Computer Science Department
4711 Boelter Hall
Los Angeles, CA 90095
Phone: (310) 206-2775, Fax: (310) 825-2273, E.mail: fpga97@cs.ucla.edu
Organizing Committee:
General Chair: Carl Ebeling, University of Washington
Program Chair: Jason Cong, UCLA
Publicity Chair: Scott Hauck, Northwestern University
Finance Chair: Jonathan Rose, University of Toronto
Local Chair: Pak Chan, UC Santa Cruz
Program Committee:
Michael Butts Quickturn
Pak Chan UCSC
Jason Cong UCLA
Carl Ebeling U. Washington
Masahiro Fujita Fujitsu Labs
Scott Hauck Northwestern Univ.
Dwight Hill Synopsys
Brad Hutchings BYU
Sinan Kaptanoglu Actel
David Lewis U. Toronto
Jonathan Rose U. Toronto
Richard Rudell Synopsys
Rob Rutenbar CMU
Gabriele Saucier Imag
Martine Schlag UCSC
Tim Southgate Altera
Steve Trimberger Xilinx
Martin Wong UT Austin
Nam-Sung Woo Lucent Technologies
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Scott A. Hauck, Assistant Professor |
| Dept. of ECE Voice: (847) 467-1849 |
| Northwestern University FAX: (847) 467-4144 |
| 2145 Sheridan Road Email: hauck@ece.nwu.edu |
| Evanston, IL 60208 WWW: http://www.ece.nwu.edu/~hauck |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 4128Hi there, I've worked with PAL's and GAL's before, but never FPGA's. I would like to learn how to use them for hobbyist-type electronic projects. Can anyone suggest good starting points for me? i.e., any cheap or free software that can be used, places to find information on fuse-file formats (or whatever the equivalent is in FPGA's), websites, or books that would be helpful in starting out? I have a working 68hc11 interfaced to my computer already, and can download code to it, so was hoping that I might be able to use this as a programmer instead of shelling out more $$$ for a hardware programmer in addition to whatever other costs are involved in FPGA design. Any tips (followup or through email) would be greatly appreciated, -RudiArticle: 4129
Rudi Cilibrasi (cilibrar@ugcs.caltech.edu) wrote: : Hi there, : I've worked with PAL's and GAL's before, but never FPGA's. I would : like to learn how to use them for hobbyist-type electronic projects. : Can anyone suggest good starting points for me? i.e., any cheap or : free software that can be used, places to find information on fuse-file : formats (or whatever the equivalent is in FPGA's), websites, or books : that would be helpful in starting out? I have a working 68hc11 interfaced : to my computer already, and can download code to it, so was hoping that : I might be able to use this as a programmer instead of shelling out more : $$$ for a hardware programmer in addition to whatever other costs are : involved in FPGA design. : Any tips (followup or through email) would be greatly appreciated, Pick up a copy of "VHDL for Programmable Logic" by Kevin Skahill which includes for $49.95 the Warp2 software that will synthesize and place and route to Cypress Semiconductor's C38X FPGA (and PLDs and CPLDs). While simulation is only for PLDs and CPLDs (Nova JEDEC simulator) if you have access to a VHDL or Verilog or Viewlogic simulator you can do pre and post synthesis simulation. Note the C38X family is one time programmable, most of the PLDs and CPLDs are flash programmable and the C37X series of CPLDs are flash and are also in circuit reprogrammable. Application notes and a PC to board cable are available. The CPLDs get quite large and might be sufficient for your needs. -Rich AulettaArticle: 4130
DGILL@priacc.com wrote: >I'm working on a project where I need to do manchester >code conversion. Output is easy, but input clock recovery >is less than trivial. I need to know if anyone has a reference design >for an fpga to do this across 2048 bits. Clock recovery is usually done with an analog phase-locked loop. There are several easy-to-use PLL chips that work over various frequency ranges. I have had good luck with the AT&T T703X-series parts from 10MHz-100MHz. Your comments about easy output and 2048 bits make no sense to me. Please rephrase! _________________________________________________________ Kirk Hobart Santa Barbara, California hobart@rain.orgArticle: 4131
I am currently evaluating Xilinx software tools and have built a board with two XC4010 devices on it so that I can check for hardware performance against that deduced by timing simulations. The design which I decided to test first of all is an array of fifteen up counters which are cascaded on to each other such that the output goes high when all fifteen counters have completed. My design entry is VHDL and I used Mentor's Autologic 2 to synthesise the design. From here I generated a schematic and then an xnf file for entry into the Xilinx PPR, etc. On completion of place and route I observed that the XDelay tool figured that the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I ran a full timing simulation on Mentor's Quicksim and sure enough the maximum speed at which I could run the design before timing violations was about 9.4MHz. My problem: when I configured a single XC4010 (which was fairly highly utilised) and increased the system clock speed the design worked quite happily at over 20MHz before some of the counter elements failed to operate as required. Has anyone else had similar experiences of inaccuracies with the Xilinx gate and layout delays or could you suggest what I might be doing wrong. My devices are speed grade 4 and I've double checked that I've set the synthesis tool and the Xilinx tools up for this. I've also went straight to an xnf file from Autologic 2 i.e. without generating a schematic, and this made no difference to XDelay results. As it is I find these inaccurate estimations intolerable for forecasting device operating speed. Thanks in advance David RennieArticle: 4132
roger gook (rgook@parsys.co.uk) wrote:
: > Mark Smotherman (mark@hubcap.clemson.edu) wrote:on the 4th Sept
: > : I would like to get pointers to any work on custom computing
: > : machines that transform selected C (or Fortran) routines into
: > : FPGA netlists. I have found papers and links to PRISM-II, being
: > : done at the Lab for Engineering Man/Machine Systems at Brown
: > : University. Are there other configuration compilers available,
: > : either at universities or from vendors?
Have a look for the BRASS and IRAM pages at Berkeley. They are working with
Stanford to make such compilers.
Cheerio,
Ray
--
_/_/_/ ""\ ""\ ""\ ""\ """""""\ ""\ _/_/_/_/_/_/_/_/_/_/_/
_/_/_/ """"\ """\ """\ ""\ ""\ """"\ _/ StarWriter / _/
_/_/_/ ""\ ""\ ""\"""\""\ ""\ ""\ """\ ""\ ""\ _/ Genisys _/
_/_/_/ _/_/_/ """"""""\ ""\ "\ ""\ ""\ ""\ ""\ """"""""\ _/ _/
_/_/_/_/_/ ""\ ""\ ""\ ""\ ""\ """""""\ ""\ ""\ _/_/_/_/_/_/_/
_/_/_/ Amiga - The canvas of the Gods.
Article: 4133sjadam@trog.dra.hmg.gb wrote: > > I am currently evaluating Xilinx software tools and have built > a board with two XC4010 devices on it so that I can check for > hardware performance against that deduced by timing simulations. > The design which I decided to test first of all is an array of > fifteen up counters which are cascaded on to each other such > that the output goes high when all fifteen counters have > completed. > My design entry is VHDL and I used Mentor's Autologic 2 to > synthesise the design. From here I generated a schematic and then > an xnf file for entry into the Xilinx PPR, etc. On completion > of place and route I observed that the XDelay tool figured that > the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I > ran a full timing simulation on Mentor's Quicksim and sure enough > the maximum speed at which I could run the design before timing > violations was about 9.4MHz. My problem: when I configured a > single XC4010 (which was fairly highly utilised) and increased > the system clock speed the design worked quite happily at over > 20MHz before some of the counter elements failed to operate as > required. > Has anyone else had similar experiences of inaccuracies with the > Xilinx gate and layout delays or could you suggest what I might > be doing wrong. My devices are speed grade 4 and I've double > checked that I've set the synthesis tool and the Xilinx tools > up for this. I've also went straight to an xnf file from > Autologic 2 i.e. without generating a schematic, and this made > no difference to XDelay results. > As it is I find these inaccurate estimations intolerable for > forecasting device operating speed. The deviation between the estimated and actual speed of your device is due to Xilinx' guardbanding of timing specifications. The timing analysis is worst case, your part could be best case. I'd be quite angry if my hardware pooped out at the simulated maximum frequency. What assurance would I have that over temperature, voltage and process variations my design would continue to work at that frequency? Regards, ScottArticle: 4134
Hello fpga users,
I made a projekt on an XC 4005-5 PC84 device. The schematic is structured. One of the hiraichal
drawings works with about 20MHz Clock-Frequenzy and the rest only with 5MHz. The FPGA works fine.
When I insert now a new Register or anything else into any file, I get timing problems. How can I
solve this problem. Is there a posibility to say, that XILINX handle a spezific file or part of the
projekt carefully and put all marked parts close together?
Thanks for help.
----------------------------------------
Name: Detlef Justen
Company: Center for Sensor Systems
University of Siegen
EMail: justen@zess.uni-siegen.de
----------------------------------------
Article: 4135
The due date for papers has been extended to October 4, 1996 (though
papers must ARRIVE by that date). Also, selected papers from FPGA'97 will
appear in a special issue of IEEE Transactions on VLSI Systems. See the
revised call for papers below for details.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
1997 ACM/SIGDA Fifth International Symposium on
Field-Programmable Gate Arrays
Sponsored by ACM SIGDA, with support from Altera, Xilinx, and Actel
Monterey Beach Hotel, Monterey, California
February 9-11, 1997
(Web page: http://www.ece.nwu.edu/~hauck/fpga97)
The annual ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related to the FPGA technology. The topics of interest of this symposium
include, but are not limited to:
o Advances in FPGA architectures, including design of programmable logic
blocks, programmable interconnects, programmable I/Os, and development of
new FPGAs and field-configurable memories.
o New CAD algorithms and tools for FPGAs, including new algorithms for
sequential and combinational logic optimization, technology mapping,
partitioning, placement, routing, and development of new FPGA synthesis
or layout systems.
o Novel applications of FPGAs, including rapid prototyping, logic emulation,
reconfigurable custom computing, and dynamically reconfigurable
applications.
o Advances in field-programmable technology, including new process
and fabrication technologies, and field-programmable analog arrays.
Authors should submit 20 copies of their original work to the program
chair, with papers arriving no later than October 4, 1996.
Each submission should include an 100-250 words abstract, and is limited
in length to 12 pages (including figures and tables, minimum point size 10).
Notification of acceptance will be sent by November 18, 1996.
A proceedings of accepted papers will be published by ACM.
Authors must assign copyright of their accepted papers to ACM as a condition
of publication. Final versions of accepted papers will be limited
to seven pages, and must be submitted by December 6, 1996.
All submissions should include the e.mail addresses of the authors, as all
correspondence with authors will be done via e.mail.
In addition, a special issue of selected papers presented in the
symposium will be published by IEEE Transactions on VLSI Systems in
the March issue. The symposium authors will be invited to submit an
extended journal version of their work by March 31, 1997 for review
for publication in the special issue. Notification of accepted papers
will be given by Sept. 15, 1997.
Submissions should be sent to:
Prof. Jason Cong
FPGA'97 Program Chair
UCLA Computer Science Department
4711 Boelter Hall
Los Angeles, CA 90095
Phone: (310) 206-2775, Fax: (310) 825-2273, E.mail: fpga97@cs.ucla.edu
Organizing Committee:
General Chair: Carl Ebeling, University of Washington
Program Chair: Jason Cong, UCLA
Publicity Chair: Scott Hauck, Northwestern University
Finance Chair: Jonathan Rose, University of Toronto
Local Chair: Pak Chan, UC Santa Cruz
Program Committee:
Michael Butts Quickturn
Pak Chan UCSC
Jason Cong UCLA
Carl Ebeling U. Washington
Masahiro Fujita Fujitsu Labs
Scott Hauck Northwestern Univ.
Dwight Hill Synopsys
Brad Hutchings BYU
Sinan Kaptanoglu Actel
David Lewis U. Toronto
Jonathan Rose U. Toronto
Richard Rudell Synopsys
Rob Rutenbar CMU
Gabriele Saucier Imag
Martine Schlag UCSC
Tim Southgate Altera
Steve Trimberger Xilinx
Martin Wong UT Austin
Nam-Sung Woo Lucent Technologies
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Scott A. Hauck, Assistant Professor |
| Dept. of ECE Voice: (847) 467-1849 |
| Northwestern University FAX: (847) 467-4144 |
| 2145 Sheridan Road Email: hauck@ece.nwu.edu |
| Evanston, IL 60208 WWW: http://www.ece.nwu.edu/~hauck |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 4136Phil and Peter and others, it's about time I took one of these questions... You've been carrying the major load, so this time it's your time to relax... :-) David, You're vexed because the Xilinx timing verifier said your design would work at up to 9.4 MHz, but in fact you run your design on one instance of the target FPGA at up to 20MHz. I'm afraid you'll have to learn to live with this problem, both with regard to Xilinx and all the other semi mfrs out there. The timing verifier is there to give the designer an accurate estimate of the *worst-case* delays (or operating frequency) for any instance of the part/speed grade which passes the mfr's production tests, whilst operating under the worst-case operating conditions over which the AC specs are guaranteed in the data book. CMOS is notorious, actually *NOTORIOUS* for exhibiting wild swings in AC performance (relative to bipolar, for example) over process variations, junction temperature, and voltage. The process variations can be largely factored out by the mfr's production tests, but the worst case operating junction temperature and operating voltage will have a significant effect on the product's AC performance. Were you running the device at low-voltage, with a weenie plastic package (i.e. worst-case thermal properties), with high on-chip power levels (to help warm up the junctions), at elevated ambient air temperatures (like in an unvented chassis) ? And did you let the device warm up for a while before you checked it at 20 MHz ? My guess is that you were relatively easy on the device, but a lot of Xilinx (and Lucent and Altera and TI and Moto and ...) customers depend on the devices operating at rated speed under these conditions, and these conditions are *not* all that unrealistic. And then the mfr will add some "error margin" to the timing verification tool, or to the device testing, to ensure that miscellaneous and/or unanticipated factors plu normal measurement errors don't result in customers' products which fail in the field. There's a balance between being aggressive on spec'ing the device speed and being meticulour/conservative on reliability. Also, as process geometries shrink and average AC performance vs. yield improves, there may not be enough fall-out parts from the -3 speed grade bin to fill the demand for -4 (slower) parts, so you may get a part that would qualify for -3 when you order a -4 part (which will be *marked* as -4). Xilinx, et al will guarantee absolute maximum delays, but not absolute minimum delays. Guaranteeing minimum delays for digital logic devices is very rare, and is usually found in the bipolar (not CMOS) world, particularly ECL and/or AS logic families. There have been appnotes written for derating CMOS FPGA AC performance vs. Junction Temp and VCC, and I believe Xilinx and Lucent both include such charts, or their equivalent, in their data books. You can use the same charts for "uprating" as well as "derating" performance, although you should be careful and conservative when you do so. The charts aren't guaranteed beyond the worst case "envelope" described in the data books. And by the way, you will sometimes see significant differences between different manufacturers' versions of worst-case operating conditions over which they'll guarantee minimum AC performance. So you won't be too happy using the timing verifier to predict the min delays of your 4010-4. But here's what *will* work... You can use the timing verifier to accurately guage the relative differences in performance between variations in your design, run on the one instance of the 4010-4. If the timing verifier says 5 MHz instead of 9.4 MHz, you can be sure that there will be a commensurate change in performance from the 20 MHz you realised, as long as you test under the same operating conditions. Whew, I think I beat this one to death. All those weeks of reading posts instead of answering have resulted in excessive accumulation of verbiage. -- Bob Elkind In article <51m03n$a7u@trog.dra.hmg.gb>, sjadam@trog.dra.hmg.gb says... > I am currently evaluating Xilinx software tools and have built > a board with two XC4010 devices on it so that I can check for > hardware performance against that deduced by timing simulations. > The design which I decided to test first of all is an array of > fifteen up counters which are cascaded on to each other such > that the output goes high when all fifteen counters have > completed. > My design entry is VHDL and I used Mentor's Autologic 2 to > synthesise the design. From here I generated a schematic and then > an xnf file for entry into the Xilinx PPR, etc. On completion > of place and route I observed that the XDelay tool figured that > the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I > ran a full timing simulation on Mentor's Quicksim and sure enough > the maximum speed at which I could run the design before timing > violations was about 9.4MHz. My problem: when I configured a > single XC4010 (which was fairly highly utilised) and increased > the system clock speed the design worked quite happily at over > 20MHz before some of the counter elements failed to operate as > required. > Has anyone else had similar experiences of inaccuracies with the > Xilinx gate and layout delays or could you suggest what I might > be doing wrong. My devices are speed grade 4 and I've double > checked that I've set the synthesis tool and the Xilinx tools > up for this. I've also went straight to an xnf file from > Autologic 2 i.e. without generating a schematic, and this made > no difference to XDelay results. > As it is I find these inaccurate estimations intolerable for > forecasting device operating speed. > > Thanks in advance > > David Rennie > -- ************************************************************************** Bob Elkind mailto:eteam@aracnet.com CIS:72022,21 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ******** Video processing, R&D, ASIC, FPGA design consulting *************Article: 4137
>: I've worked with PAL's and GAL's before, but never FPGA's. I would >: like to learn how to use them for hobbyist-type electronic projects. I missed the original post, but I would recommend only RAM-based FPGAs for this requirement. OTP parts will be too much hassle. Especially if one is learning VHDL (or some dialect of) at the same time. Furthermore, the cost of place-route software will probably rule out Xilinx, which is a pity because they do good parts. Peter.Article: 4138
>I'm working on a project where I need to do manchester >code conversion. Output is easy, but input clock recovery >is less than trivial. I need to know if anyone has a reference design >for an fpga to do this across 2048 bits. You can do it with a one-shot. I can't remember the circuit, but it is very simple. It should take only a few mins to work out. The problem with a one-shot is that it needs to be accurate, which is hard to do at high data rates. I was trying to do it at 10mbits/sec, and it was hairy. I vaguely remember that the one-shot had to be set to between 55 and 70% of the bit period, or something like that. It was used as a pulse width discriminator. A digital PLL is the normal way. I have done it with an analog PLL but you have to be careful, because Manchester contains both F and 2F components, and a simple analog PLL will lock onto either. I am sure this can be overcome, but you need to watch this. You also need to make sure there is enough preamble (which you can afford to lose) to get things started. You are right about encoding being trivial, normally it is just one XOR gate, gating the clock and the data. But this gives you slightly unequal bit widths, and there is a more ingenious circuit which is normally used, which is better for higher data rates. This was supplied to me years ago by Zilog, who apparently use it in their 85c30 SCC. A pity they also didn't give me the DPLL decoder from the 85c30, which is very good. Peter.Article: 4139
Detlef Justen wrote: > > Hello fpga users, > > I made a projekt on an XC 4005-5 PC84 device. The schematic is structured. One of the hiraichal > drawings works with about 20MHz Clock-Frequenzy and the rest only with 5MHz. The FPGA works fine. > When I insert now a new Register or anything else into any file, I get timing problems. How can I > solve this problem. Is there a posibility to say, that XILINX handle a spezific file or part of the > projekt carefully and put all marked parts close together? > 1. Floorplan. If you're using Xact 6, the graphical floorplanner makes this pretty easy. If not, you need to delve into your reference guides that came with your earlier XACT software to learn how to floorplan. 2. Use level compression. This means limiting the number of levels in your logic between registers to an appropriate amount. As a rough rule of thumb, figure the prop delay to be twice the delay through the CLB to account for routing, then leave a bit of slack. At 20 Mhz, you should be OK with less than 3 levels. 3. Design to the architecture. Tailor your design to take advantage of the small fan-in and large number of ffs, the carry chains and the wide decodes.Article: 4140
In article <323e355f.1976311@news.rain.org> hobart@rain.org (Kirk Hobart) writes:
>From: hobart@rain.org (Kirk Hobart)
>Subject: Re: manchester clock recovery
>Date: Tue, 17 Sep 1996 05:35:39 GMT
>DGILL@priacc.com wrote:
>>I'm working on a project where I need to do manchester
>>code conversion. Output is easy, but input clock recovery
>>is less than trivial. I need to know if anyone has a reference design
>>for an fpga to do this across 2048 bits.
Instead of the manchester code you can use a selfclocking code.
For this code you don't need a clock recovery (the delayed
input signal is the clock).
uncoded coded data received data
D7....D0 start-msb..lsb-stop d7..d0-neg-stop D7....D0
00000000 1-001001001001-00 00000000-0-0 00000000
00000001 1-001001001010-00 00000001-0-0 00000001
00000010 1-101101101011-00 11111101-1-0 00000010
. . . .
. . . .
. . . .
11111110 1-001001001011-00 00000001-1-0 11111110
11111111 1-101101101101-00 11111111-0-0 11111111
DELAY must delay the signal 1.5 T (T is the transfer time for one Bit).
+-----+ +----------------------+
+-+DELAY+----->clock |
| +-----+ | 5 Bit Shift Register |
+-------------+data |
| +-----+--+--+--+--+----+
| | | | | | for di (0<=i<8):
| neg d1 d3 d5 d7
| +-----+
| di-+ |
Din ---+ | xor +- Di
| neg-+ |
| +-----+
| stop d0 d2 d4 d6
| | | | | |
| +-----+ +-----+--+--+--+--+----+
+-+DELAY+O---->clock |
| +-----+ | 5 Bit Shift Register |
+-------------+data |
+----------------------+
For the byte synchronization a 5-counter (or for higher speed a 5 bit
shift register) is used. The automatic synchronization of the counter
with the datastream can be done with
- the stopbit (which must be always 0 for a correct synchronization)
(shift the synchronization by 1 if the stopbit is 1)
- if there are more then 6 0-bits received (sender pause) the counter
is reset
Because of the 2 stopbits you have 2 clock cycles to store the received
byte.
Article: 4141
sjadam@trog.dra.hmg.gb () wrote:
[snip]
>the worst clock-to-setup delay was about 106nS i.e. 9.4MHz. I
>ran a full timing simulation on Mentor's Quicksim and sure enough
>the maximum speed at which I could run the design before timing
>violations was about 9.4MHz. My problem: when I configured a
>single XC4010 (which was fairly highly utilised) and increased
>the system clock speed the design worked quite happily at over
>20MHz before some of the counter elements failed to operate as
>required.
Remember that XDELAY always uses the worst-case parameters for its
calculations. You are guaranteed at least the speed indicated by
XDELAY. Practical designs do normally run much faster, however Xilinx
don't guarantee it.
-- Dave Brooks <http://www.iinet.net.au/~daveb>
PGP public key: finger daveb@opera.iinet.net.au
servers daveb@iinet.net.au
fingerprint 20 8F 95 22 96 D6 1C 0B 3D 4D C3 D4 50 A1 C4 34
What's all this? see http://www.iinet.net.au/~daveb/crypto.html
Article: 4142That's easy. I published a design in XCELL, the Xilinx quarterly journal, issue 17, 2nd quarter 1995, page 30. The design assumes an eight-times clock, which of course can be asynchronous to the incoming data. The clock must be faster than 5 times the incoming bit rate, and slower than 12 times. So there is plenty of margin. The design takes three CLBs and has been simulated to operate in excess of 200 MHz clock rate, i.e. 25 MHz data rate, when implemented in an XC3120-2. ( It uses less than 5 percent of the available resources in that part ). I can fax the schematic to anybody who requests it. ( Proud father syndrome ). Peter Alfke, Xilinx ApplicationsArticle: 4143
A small public company located in Sunnyvale, CA, is looking for a candidate who 1. has strong ASIC design experience, 3+ year prefered, 2. is very familiar with Synopsys synthesis and Verlog. Knowledge with MPEG and video compression is a plus. Please fax resume to 408-727-6275. H.R. Dept. Our company offers very competetive salary and stock option.Article: 4144
Dear ASIC/FPGA Designers, hereby we would like to introduce the "A Survey on Design Errors" WWW-server: http://www.lis.e-technik.tu-muenchen.de/DEP/ and invite all of you to visit it. This server is installed to collect the opinions of ASIC and/or 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üeller, W. Stechele, VHDL International Users' Forum, Spring 1996 (VIUF'96). or get its postscript version from the server. 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 appriciate 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. Thank you for taking time to visit and fill out the survey Institute for Integrated Circuits Technical University of Munich Munich, Germany For any question or further information, feel free to drop us a message: M_Movahedin@lis.e-technik.tu-muenchen.de IMPORTANT: A e-mail version of the survey is available too. please contact us to send it for you by e-mail. ############################################################################## The survey includes two groups of questions: In the first group, some general questions about your experiences in ASIC/FPGA design and the concept of design errors are asked. The second part of the 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.Article: 4145
Failure to account for things like delay reconvergence, multicycle paths and asynchronous elements also come to mind as potential reasons for a pessimistic static timing analysis. Has anyone compared Xdelay results with tools such as Motive or Designtime? -- David PashleyArticle: 4146
Dear Sir/Madam,
please find below the Call for Papers for the CHDL'97 conference. You
can also get more information about this event in the following URL:
http://www.it.uc3m.es/~ifip/chdl97/
-----------------------------------------------------------------------
Call for Papers
CHDL '97
XIII IFIP WG 10.5 Conference on Computer Hardware Description Languages and
Their Applications 1997
Silver Jubilee
[Toledo]
Hotel Beatriz - Toledo, Spain - 20-25 April 1997
----------------------------------------------------------------------------
CHDL has been held every other year since 1973, rotating between locations
in Europe, North America and Asia. The conference originated under IEEE/ACM
sponsorship and since 1981 has been organized by IFIP Working Group 10.2
(now WG 10.5).
The topic has had a significant history with over 100 HDLs published in the
1970s. Since the mid-1980s, HDLs have become commonplace in system design
and VLSI. This can be attributed to many factors including:
* the advancing complexity of digital electronics, leading to more
sophisticated modeling, simulation, and verification tools.
* the migration of VLSI design to high-level synthesis based on HDLs
* advances in microelectronics CAD toward support of system-level design
* the increasing prevalence of generic and programmable components, of
software-hardware and mixed digital-analog hybrid designs.
Presently, we are in a consolidation phase, in which languages and standards
are increasingly being used, at the same time as the scope is being
broadened to additional application areas (such as analog, microwave or
system-level design).
CHDL'97 will present the latest developments in the area in the form of
tutorials, invited talks, panel sessions and reviewed papers. In 1997, CHDL
will be celebrating its Silver Jubilee, and this will be a very special
occasion to learn from the past and look forward to what we might expect
from the future.
CHDL'97 will be held in conjunction with other workshops on closely related
areas:
* the Spring '97 Working Conference of the VHDL Forum for CAD in Europe
* the Esprit NADA workshop (about New Hardware Design Methods).
* the Workshop on Libraries, Component Modelling and Quality Assurance
An exhibition will be held in parallel to these events.
----------------------------------------------------------------------------
Topics
The topics of CHDL include several emerging design methods and technologies
based on HDLs, including
* Hardware Description Languages, Standards
* Formal Methods
* Verification and Validation
* Design Analysis and Test
* System-Level Specification and Design
* High-Level Synthesis
* Design Systems and Tools
* New Application Areas
----------------------------------------------------------------------------
Submission of Papers
Contributions on these or related topics are solicited. Papers on original
research, experiences, reviews, and tutorial articles are welcome. Proposals
for special sessions are also invited (please contact the Program Chair).
Accepted papers will appear in proceedings published by Chapman & Hall. A
best-paper award will be given.
Papers (6 copies) should be submitted by 1 October 1996 to the Program
Chair. A cover page should specify
1. title;
2. authors and affiliation;
3. mailing address, phone and fax numbers, and e-mail address of the
primary author;
4. a brief abstract; and
5. one or two topics from the list to which the paper belongs.
Submissions should use A4 or 8.5" x 11" paper and be at most 20 pages in
length (minimum line spacing 1 1/2). Submission by e-mail to the Program
Chair <chdl97@iro.umontreal.ca> of PostScript files is preferred, but since
there may be printing or transmission problems, it is suggested that paper
copies be also sent by regular mail.
Important dates:
* Submission deadline: 1 October 1996
* Notification of acceptance/rejection: 29 November 1996
* Camera-ready version: 22 December 1996
* Conference: 20-25 April 1997
----------------------------------------------------------------------------
Toledo
Toledo is without doubt one of the cities with the greatest density of
monuments in the world. Nearly all the different stages of Spanish art are
represented in Toledo, which has Moorish-Mudejar-Jewish buildings, such as
the Transito and Santa Maria la Blanca Synagogues; Gothic structures, such
as the splendid cathedral; and Renaissance buildings. In the 16th century,
the city became home to El Greco, and Toledo has many of his paintings,
among which is "The Burial of the Count of Orgaz", his masterpiece, which is
housed in the Mudejar Church of Santo Tome. Among its many museums, of
special note is the one located in the old Santa Cruz Hospital.
----------------------------------------------------------------------------
General Chair
Prof. Dr. Carlos Delgado Kloos
Universidad Carlos III de Madrid
C/Butarque, 15
E-28911 Leganes (Madrid/Spain)
Tel: (+34-1) 624-9979
Fax: (+34-1) 624-9430
E-mail: ifip@it.uc3m.es
Program Chair
Prof. Dr. Eduard Cerny
Dept. IRO
Universite de Montreal
C.P. 6128, Succ. Centre-Ville
Montreal (Quebec)
Canada H3C 3J7
Tel: (+1-514) 343-7472
Fax: (+1-514) 343-5834
E-mail: chdl97@iro.umontreal.ca
Exhibition Chair
Dr. Serafin Olcoz Yanguas
TGI - Tecnologia y Gestion de la Innovacion
C/Velazquez, 134 bis
E-28006 Madrid (Spain)
Tel: (+34-1) 396-4925
Fax: (+34-1) 396-4841
E-mail: sera@www.tgi.es
Local Arrangements
Natividad Martinez Madrid
Ingenieria Telematica
Universidad Carlos III de Madrid
C/Butarque, 15
E-28911 Leganes/Madrid (Spain)
Tel: (+34-1) 624-9903
Fax: (+34-1) 624-9430
E-mail: nmadrid@it.uc3m.es
Asia-Pacific Representative
Prof. Masaharu Imai
Department of Computer Science
Graduate School of Engineering Science
Osaka University
1-3 Machikane-yama, Toyonaka, Osaka, Japan 560
Tel & Fax: (+81-6) 850-6623
E-mail: imai@ics.es.osaka-u.ac.jp, m.imai@ieee.org
Program Committee
* David Agnew, Canada
* François Anceau, France
* Przemyslaw Bakowski, France
* Mario R Barbacci, USA
* Howard Barringer, UK
* Graham Birtwistle, UK
* Dominique Borrione, France
* Raul Camposano, USA
* Eduard Cerny, Canada
* Luc Claesen, Belgium
* Edmund M Clarke, USA
* Francisco Corella, USA
* Werner Damm, Germany
* Carlos Delgado Kloos, Spain
* Nikil D Dutt, USA
* Hans Eveking, Germany
* Norbert Fristacky, Slovakia
* Masahiro Fujita, Japan
* Ganesh Gopalakrishnan, USA
* Werner Grass, Germany
* Rainer Hartenstein, Germany
* Graham Hellestrand, Australia
* Masaharu Imai, Japan
* Steven D Johnson, USA
* Thomas Kropf, Germany
* David C Luckham, USA
* Paul Menchini, USA
* Jean Mermet, France
* Wolfgang Nebel, Germany
* Adam Pawlak, Germany
* Robert Piloty, Germany
* Paolo Prinetto, Italy
* Franz Rammig, Germany
* Peter Schwarz, Germany
* Jørgen Staunstrup, Denmark
* P A Subrahmanyam, USA
* Flavio Wagner, Brazil
* Ronald Waxman, USA
* Akihiko Yamada, Japan
* Michael Yoeli, Isreal
Article: 4147I would like to know if anyone have used Cypress FPGA parts (e.g., 8K gates)and Warp2/3 $99 Design Kits. Especially, I would like to know 1) if I can get high percentage of usable gates out of these parts, 2) whether I can use the design kit to read in existing VHDL code that was written for Model Technology simulator (and someone else synthesis and P/R tools), 3) if the technical support from Cypress is acceptable... Any comments on the above will be greatly appreciated. takeArticle: 4148
I agree with Scott, but let me add some specifics about guardbanding: We actually test all commercial devices at 4.75 V and 85 degree temperature. The tests take only a few seconds and create very little power dissipation, so we preheat the devices to slightly more than 85 degrees C and then perform the test. Junction temperature is then only very little above case temperature, which is 85 degrees centrigrade. A device that fails any ( even a single ) test limit under these conditions is rejected for this speed grade and is then tested for a slower speed grade. We have measured the temperature coefficient of delay parameters, and we assume it to be between 0.25 and 0.35% per degree C. The voltage dependence of the delay parameters is roughly inversely proportional. ( Not all parameters behave the same way, because there are several different physical phenomena involved here. That's why we cannot test at room temperature and just calculate the worst-case values. We actually test under the guaranteed worst-case operating conditions ) You can expect a 5% improvement in performance when you run at 5.00 V, and a 15 to 20% improvement when you run at room temperature and low power consumption, i.e. a junction temperature close to 25 degrees. When you multiply 0.95 times 0.80 you get 0.76 for the delay, or 1.316 for the clock rate. So the first 32% of the extra performance you got were due to your more benign operating conditions. The next 25% of extra performance may have been due to luck, because you may have gotten a part that was almost a speed grade better than its marking. The remaining 25% of extra performance come courtesy of the conservative test and characterization methodology used by Xilinx. Most users don't complain when parts are faster than the worst-case spec, but all hell would break loose if they were slower. By the way, all semiconductor manufacturers also reserve the right to "downbin", i.e. to mark a fast part with a slower speed grade than it really is, when the market demand is higher for slower parts. Designers should assume that a device can be up to four times faster than the worst-case spec ( that also covers ambient conditions ), but never slower than the worst-case spec. I have seen working designs where combinatorial delays deliberately exceeded the clock period. These designs worked until the temperature got cold, or until faster devices were plugged in. The original designer had wisely departed, so he could not be lynched, but somebody else had to clean up the mess. Never rely on the slowness of an integrated circuit ! I hope this was not too rambling. Enjoy your fast Xilinx devices. Peter Alfke, Xilinx ApplicationsArticle: 4149
Just a reminder, I maintain a well-used, but not well-publicized, listing of chipmaker website URLs. I have recently revamped it so that you can view just a brief listing of URLs, or a listing URLs with a summary of the chips made by each company. http://www.scruznet.com/~gcreager/hello5.htm Use the above URL to choose between the two sites. You can print out either listing in hardcopy format (I've made versions with colors that are "printer friendly") and post it on your wall, or just bookmark whichever webpage you like best. I've added a growing engineer humor page as well (some funny stuff there actually). I am constantly updating this listing and it is the most up-to-date that you'll find anywhere. I will soon be adding some investor links as well (for those who invest in semi stocks). Use it as much as you like and tell others about it. -- Gray Creager
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