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
Hi, friends, Does anyone know is there any commercial DSP and FPGA based general purpose control board suitable to motor drive control? FPGA takes care of the A/D, D/A and gating and DSP takes care of the calculation part. Thanks JackArticle: 22001
This is a multi-part message in MIME format. --------------52C692F9DB6146CF0CAA6CA1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Abhijit, Thanks for the info. One more question though. What about the clamp diode? The 3.3v PCI buffer is supposed to have a clamp diode and the 5v PCI buffer cannot. Do we have to specify this somewhere as well or will the tools know to put a clamp on the input if it is 12ma (3.3vPCI) and not if it is 24ma (5v PCI). Tom Abhijit Athavale wrote: > Tom, > > It is as easy as that. Set the PCI outputs to FAST slew rate and set > DRIVE=24 for 5V PCI signaling and DRIVE=12 for 3.3V signaling. The regular > XLA buffers are PCI compliant. > > Tom McLaughlin wrote: > > > All, > > We know how to specify PCI buffers in Virtex and Virtex E. We put the > > statement: > > > > set_attribute -port "outchan1_bp(2)" -name buffer_sig -value > > OBUF_PCI33_3 > > > > in the synthesis script and it passes the attribute to the backend. > > > > The problem is that we want to use a PCI compliant buffer on an XLA > > part. The docs say that it supports it, but we cannot figure out how to > > implement it. To check if the architecture does support it, I pulled up > > the constraints editor after choosing an XLA part. When I click on I/O > > standards, I only have the option to set drive strength, slew rate, but > > not the I/O standard. If you do this with a Virtex part, a new column > > appears called "I/O standards" which has all the I/O options, LVTTL, > > SSTL, PCI etc. > > > > The libraries guide on the Xilinx web site does not show support for XLA > > that we can find. We tried using the above statement for the XLA > > architecture, but it is not valid. > > > > The datasheet goes to great lengths to say the XLA has these PCI > > compiant buffers, but does not say how to implement them. Please > > help!!! Do we just implement LVTTL buffers with 12ma of drive strength > > and that is PCI compliant....it can't be that easy.....??? > > > > BTW, we are using Alliance 2.1i. > > > > Tom --------------52C692F9DB6146CF0CAA6CA1 Content-Type: text/x-vcard; charset=us-ascii; name="tomm.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom McLaughlin Content-Disposition: attachment; filename="tomm.vcf" begin:vcard n:McLaughlin;Tom tel;fax:314-935-7302 tel;work:314-935-7198 x-mozilla-html:FALSE url:http://www.arl.wustl.edu/~tomm org:Washington University;Applied Research Lab version:2.1 email;internet:tomm@arl.wustl.edu title:Research Associate adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA x-mozilla-cpt:;0 fn:Tom McLaughlin end:vcard --------------52C692F9DB6146CF0CAA6CA1--Article: 22002
FPGAs don't have built in ADCs or DACs, although you can get at DAC through pulse width modulation for lower frequency outputs. If you are using an FPGA for the motor drive controller, you can also do the PID or other control fucntion in the FPGA and eliminate the processor, or conversely, if the DSP already has enough umph to handle the calculation part, it should be able to handle the gating, and might even have a built in DAC and/or ADC. "Jack D. Ma" wrote: > Hi, friends, > > Does anyone know is there any commercial DSP and FPGA based general > purpose control board suitable to motor drive control? FPGA takes care > of the A/D, D/A and gating and DSP takes care of the calculation part. > > Thanks > > Jack -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 22003
Use a DDFS. The jitter will be a maximum of one cycle of the 77.76 MHz clock. The frequency accuracy depends on the number of bits. Basically this is an accumulator clocked at the 77.76 MHz, to which a constant increment is added so that the accumulator overflows once per 1.544MHz cycle. The digital output, assuming tht is what you are looking for, is the msb of the accumulator. If you need a different wave shape, the msbs of the accumulator can drive a look up or other waveshape converter (the upper bits represent phase as a fractional revolution). For example, if you use a 12 bit accumulator, an increment value of 81 gives an output frequency of 1.5377MHz. More bits will get better frequency resolution. You could get real close with a 12 bit accumulator if you modulate the increment so it is 81 for 2 clocks and 82 for the 3rd. Xanatos wrote: > Hey all, > > I need to create a small clock divider circuit that divides a 77.76MHz clock > downto 1.544MHz, and I need to have the resultant 1.544MHz clock to be as > close to a 50/50 duty cycle as possible (as precise as possible), so that I > don't have alot of jitter. > > Any suggestions? > > Thanks, > > Dave -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 22004
Hello All, as it happens we have recently ported our control architecture to a simple low cost fpga based board, (XESS). At present it is complete and under test. Only single axis control, (via parallel port interface), is implemented. Output to amp is pwm signal which needs to be amplified and shifted, if you wish to use simple digital amp this would be easier, (e.g. technology Artisans..since you are in Toronto!). I would expect that we will have a multiple,(6 to 8), axis system using our stateline architecture over the summer. The encoder feedback and overall system speed and capability are equivalent or better than a system we previously built using HP quad decode and 80c196 cpu, Regards Ian "Jack D. Ma" wrote: > > Hi, friends, > > Does anyone know is there any commercial DSP and FPGA based general > purpose control board suitable to motor drive control? FPGA takes care > of the A/D, D/A and gating and DSP takes care of the calculation part. > > Thanks > > JackArticle: 22005
Tom, For 5v PCI, there is a bitgen switch (-g 5V_Tolerant_IO) which you should set to Yes. It can also be accessed in the Design Manager GUI under the Configuration Template. Mike Tom McLaughlin wrote: > Abhijit, > > Thanks for the info. One more question though. > > What about the clamp diode? The 3.3v PCI buffer is supposed to have a clamp > diode and the 5v PCI buffer cannot. Do we have to specify this somewhere as > well or will the tools know to put a clamp on the input if it is 12ma > (3.3vPCI) and not if it is 24ma (5v PCI). > Tom > > Abhijit Athavale wrote: > > > Tom, > > > > It is as easy as that. Set the PCI outputs to FAST slew rate and set > > DRIVE=24 for 5V PCI signaling and DRIVE=12 for 3.3V signaling. The regular > > XLA buffers are PCI compliant. > > > > Tom McLaughlin wrote: > > > > > All, > > > We know how to specify PCI buffers in Virtex and Virtex E. We put the > > > statement: > > > > > > set_attribute -port "outchan1_bp(2)" -name buffer_sig -value > > > OBUF_PCI33_3 > > > > > > in the synthesis script and it passes the attribute to the backend. > > > > > > The problem is that we want to use a PCI compliant buffer on an XLA > > > part. The docs say that it supports it, but we cannot figure out how to > > > implement it. To check if the architecture does support it, I pulled up > > > the constraints editor after choosing an XLA part. When I click on I/O > > > standards, I only have the option to set drive strength, slew rate, but > > > not the I/O standard. If you do this with a Virtex part, a new column > > > appears called "I/O standards" which has all the I/O options, LVTTL, > > > SSTL, PCI etc. > > > > > > The libraries guide on the Xilinx web site does not show support for XLA > > > that we can find. We tried using the above statement for the XLA > > > architecture, but it is not valid. > > > > > > The datasheet goes to great lengths to say the XLA has these PCI > > > compiant buffers, but does not say how to implement them. Please > > > help!!! Do we just implement LVTTL buffers with 12ma of drive strength > > > and that is PCI compliant....it can't be that easy.....??? > > > > > > BTW, we are using Alliance 2.1i. > > > > > > TomArticle: 22006
Hi - I should have added (at least) one thing. The "typ," "min," and "max" categories refer to typical, minimum, and maximum drive strength. Max therefore corresponds to the lowest impedance and min the highest. There's nothing unusual about the roughly 2:1 impedance spread for a given driver. Much of this is due to process variation, and the rest to voltage and temperature variation. Bob Perlman On Tue, 11 Apr 2000 16:38:25 GMT, bobperl@best_no_spam_thanks.com (Bob Perlman) wrote: >On Tue, 11 Apr 2000 15:49:02 +0200, "Jean-Paul GOGLIO" ><goglio@getris.com> wrote: > >>Hi All, >> >>Does anyone on this group know the output impedance of a Virtex E pad using >>LVTTL standard and the influence of the drive current on this impedance ? >> >>Thanks > >Hi - > >I downloaded the (just-about-brand-new) Virtex-E IBIS files from: > >http://www.xilinx.com/support/sw_ibis.htm > >I then did a quick and dirty output impedance calculation for the >LVTTL outputs: > LOW HIGH > typ min max typ min max >------------------------------------------------ >LVTTL2S 131 197 103 157 245 117 >LVTTL4S 64 96 51 81 125 61 >LVTTL8S 26 39 21 42 64 32 >LVTTL16S 16 23 13 24 37 18 >LVTTL24S 10 14 8 15 22 11 > >The file also contains information for a couple other driver >strengths, but I got tired. > >Please note that the IBIS file itself is an approximation, having been >generated from Spice models. I got the impedances by dividing the 1V >Pullup and Pulldown table entries by the corresponding currents, which >is also an approximation. So the table represents an approximation of >an approximation. > >Note that: > 1) Roughly speaking, the impedances are inversely proportional to the >driver current rating, which makes sense. > 2) Logic HIGH impedances are somewhat higher than the corresponding >logic LOW impedances. > >Bob Perlman > > > >----------------------------------------------------- >Bob Perlman >Cambrian Design Works >Digital Design, Signal Integrity >http://www.best.com/~bobperl/cdw.htm >Send e-mail replies to best<dot>com, username bobperl >----------------------------------------------------- ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 22007
On Tue, 11 Apr 2000 21:32:37 GMT, Ray Andraka <randraka@ids.net> wrote: >Use a DDFS. The jitter will be a maximum of one cycle of the 77.76 MHz clock. >The frequency accuracy depends on the number of bits. Basically this is an >accumulator clocked at the 77.76 MHz, to which a constant increment is added so >that the accumulator overflows once per 1.544MHz cycle. The digital output, >assuming tht is what you are looking for, is the msb of the accumulator. If you >need a different wave shape, the msbs of the accumulator can drive a look up or >other waveshape converter (the upper bits represent phase as a fractional >revolution). > >For example, if you use a 12 bit accumulator, an increment value of 81 gives >an output frequency of 1.5377MHz. More bits will get better frequency >resolution. You could get real close with a 12 bit accumulator if you modulate >the increment so it is 81 for 2 clocks and 82 for the 3rd. Hi! The phase accumulator actually isn't a good circuit to use for this application, as the division will need to be exact (these are telecommunications frequencies), and the ratio is such that it can't be represented exactly with 2^N in the denominator. That means that an infinite number of bits in the phase accumulator is needed to get the exact frequency. I suggest a fractional-N divider. My fractional-N divider generator program suggests that this particular divider is best implemented with a /50, /51 dual modulus prescaler (i.e. a counter that has selectable division ratios of 50 and 51). The prescaler is controlled such that for every 193 output clocks, 123 of them are /50 and 70 of them are /51. Output jitter will have a fundamental frequency of 8kHz, and its amplitude will be minimised if the 70 clocks of /51 are interleaved as evenly as possible between the 123 clocks of /50. The minimum peak to peak jitter is 1 clock period of the 77.76MHz input. Note that the modulus controller can be clocked at the output frequency of 1.544MHz (for low power) or at the input frequency of 77.76MHz (if you run out of clock nets, or are afraid of crossing clock domain boundaries). You will need to use clock enables if the modulus controller is clocked from the input clock. BTW, jitter is measured between like clock edges. The duty cycle usually doesn't come into it. However, it is simple to design the prescaler so that its output is high for 25 clocks, and low for 25 or 26 clocks (for /50 or /51, respectively), which gives a duty cycle of either 49% or 50%. Regards, Allan. >Xanatos wrote: > >> Hey all, >> >> I need to create a small clock divider circuit that divides a 77.76MHz clock >> downto 1.544MHz, and I need to have the resultant 1.544MHz clock to be as >> close to a 50/50 duty cycle as possible (as precise as possible), so that I >> don't have alot of jitter. >> >> Any suggestions? >> >> Thanks, >> >> DaveArticle: 22008
Hi! I have a few modules that works in this way... In_module which works at .. say 33Mhz( f), out_module at ard 2MHz ( f/16). I have synchornized the out_module to in_module and the warning goes away... and yup! The simulation result is now correct :-)) but I suffer some delay(1-2 clk cycles) in sending data... :-( There is another out2_module that works at much higher speed, (max f/3 or 11MHz). I believe my method no longer works since the delay (1-2 clk cycles) is intolerable in this case... Does yer method work in this case? btw, in Synplify, I managed to design all my modules to work at, say all >70Mhz. But when I use schematic to interconnect the modules in max+plus2 (use fast logic synthesis), after compilation, the max frequency drops drastically to ard 40MHz.... is there any way to improve the final max frequency close to 70MHz?? Thanks Iglasner & Christian for sharing yer experiences... They're useful for novice like me :-) Regards MK <iglasner@zumanetworks.com> wrote in message news:8cvpj6$51g$1@nnrp1.deja.com... > Hi, > > You ommite the clock frequance of the 2 clock's (or maybe more ?) > you are talking about as well as are the infomation delay is crusial or > can you wait a clock or two. > > according to the above there are few way to approch the problem. > > as an example assume you have a data stored in module1 work with clk1 > in few buffers and you want to read a certain buffer to a module2 that > work in clk2 > > than a general sulotion will be that module2 will prepare the buffer > number he want to read and than will rais a single saying he want to > read. > > this read signal you will pass through syncronizer (to clk1) to module1 > domain and than module1 will look and see the address which is > already "long ago" stable. > > module1 will than put the data and will rais a signal saying data is > ready. > > this data is ready signal will also be syncronize (to clk2) and when > module2 see it the data is already stable, and can be "used safely". > > than module 2 pulldown the read and as soon as mosule 1 see that the > read signal is pulldown he pulldown the data is ready signal. > > this is just one way (usually called full-handshake) and there are many > other. > > have a nice day > > Illan > > > In article <8cu1mq$3v1$1@coco.singnet.com.sg>, > "MK Yap" <mkyap@REMOVE.ieee.org> wrote: > > Hi all, > > > > For my design, there is a global clock, some input signals, some > output > > signals (clocked by external source). > > > > When input signals come in(synchronized by global clock), the central > > controller will collect, organize, manipulate & store in buffer. > > The output port interface portion will at intervals (ctrl by external > clk) > > request data from buffer. > > During my design, I encounter hundreds of design warning by > max+plus2 (i'm > > using synplify vhdl sythesizer) saying sth like this > > "Design Dr warning: flipflop or synchronous memory 'q_data_7' > receives data > > that is synchronized by another clock at flipflop or synchronous > memory > > 'subc_datareq' " > > & > > "Design Dr warning: inverting delay chain starting at primitive > > 'cntr_1_lut_5' feeds primitive 'statemachine_cntr_i_0' " > > > > & my project fails to work during timing simulation. > > Can somebody pls shed some light on how to properly design a multiple > clock > > system that meets all setup time, hold time....??? > > or is there any good reference that stress on this area of design? > > > > Any help is much appreciated. Thanks in advance. > > > > Rgds > > MK > > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 22009
First, it is possible you are adding relatively long combinatorial delays when you connect the modules together, or you may be loading down a signal with too high a fanout. That can be mitigated somwhat by duplicating logic. You may be filling the device up to where routing congestion gets in the way and slows it down. The Altera devices are vulnerable to this phenomenon, especially in heavily data path and arithmetic designs because of the routing structure. Here, about all that really helps is going to a different design approach. You can go to a larger device, but you won't get the same speeds for your modules there (see below). Also be aware that the Altera line slows down as you go to bigger devices in the same family/speed grade, again due to the routing resources. Without knowing more about your design, it is hard to say what the exact problem is. MK Yap wrote: > Hi! > > I have a few modules that works in this way... > In_module which works at .. say 33Mhz( f), out_module at ard 2MHz ( f/16). I > have synchornized the out_module to in_module and the warning goes away... > and yup! The simulation result is now correct :-)) > but I suffer some delay(1-2 clk cycles) in sending data... :-( > > There is another out2_module that works at much higher speed, (max f/3 or > 11MHz). I believe my method no longer works since the delay (1-2 clk cycles) > is intolerable in this case... Does yer method work in this case? > > btw, in Synplify, I managed to design all my modules to work at, say all > >70Mhz. But when I use schematic to interconnect the modules in max+plus2 > (use fast logic synthesis), after compilation, the max frequency drops > drastically to ard 40MHz.... is there any way to improve the final max > frequency close to 70MHz?? > > Thanks Iglasner & Christian for sharing yer experiences... They're useful > for novice like me :-) > > Regards > MK > > <iglasner@zumanetworks.com> wrote in message > news:8cvpj6$51g$1@nnrp1.deja.com... > > Hi, > > > > You ommite the clock frequance of the 2 clock's (or maybe more ?) > > you are talking about as well as are the infomation delay is crusial or > > can you wait a clock or two. > > > > according to the above there are few way to approch the problem. > > > > as an example assume you have a data stored in module1 work with clk1 > > in few buffers and you want to read a certain buffer to a module2 that > > work in clk2 > > > > than a general sulotion will be that module2 will prepare the buffer > > number he want to read and than will rais a single saying he want to > > read. > > > > this read signal you will pass through syncronizer (to clk1) to module1 > > domain and than module1 will look and see the address which is > > already "long ago" stable. > > > > module1 will than put the data and will rais a signal saying data is > > ready. > > > > this data is ready signal will also be syncronize (to clk2) and when > > module2 see it the data is already stable, and can be "used safely". > > > > than module 2 pulldown the read and as soon as mosule 1 see that the > > read signal is pulldown he pulldown the data is ready signal. > > > > this is just one way (usually called full-handshake) and there are many > > other. > > > > have a nice day > > > > Illan > > > > > > In article <8cu1mq$3v1$1@coco.singnet.com.sg>, > > "MK Yap" <mkyap@REMOVE.ieee.org> wrote: > > > Hi all, > > > > > > For my design, there is a global clock, some input signals, some > > output > > > signals (clocked by external source). > > > > > > When input signals come in(synchronized by global clock), the central > > > controller will collect, organize, manipulate & store in buffer. > > > The output port interface portion will at intervals (ctrl by external > > clk) > > > request data from buffer. > > > During my design, I encounter hundreds of design warning by > > max+plus2 (i'm > > > using synplify vhdl sythesizer) saying sth like this > > > "Design Dr warning: flipflop or synchronous memory 'q_data_7' > > receives data > > > that is synchronized by another clock at flipflop or synchronous > > memory > > > 'subc_datareq' " > > > & > > > "Design Dr warning: inverting delay chain starting at primitive > > > 'cntr_1_lut_5' feeds primitive 'statemachine_cntr_i_0' " > > > > > > & my project fails to work during timing simulation. > > > Can somebody pls shed some light on how to properly design a multiple > > clock > > > system that meets all setup time, hold time....??? > > > or is there any good reference that stress on this area of design? > > > > > > Any help is much appreciated. Thanks in advance. > > > > > > Rgds > > > MK > > > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 22010
On Wed, 12 Apr 2000 03:15:52 GMT, allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman) wrote: [snip description of fractional-N divider] Another approach that results in even less jitter is to use a /50, /50.5 prescaler instead of a /50, /51 prescaler. The controller will give 53 counts of /50 and 140 counts of /50.5 The fundamental output jitter frequency is still 8kHz (= 1.544MHz / (53 + 140)), but the amplitude will be only 0.5 periods of the 77.76MHz clock (assuming this clock has a 50% duty cycle). This is only 0.010 UIp-p, which is surely good enough for your application. The output duty cycle also improves to 49.5% Regards, Allan.Article: 22011
P A R T 2 0 0 0
The Seventh Australasian Conference on Parallel and Real-Time Systems
29 -- 30 November 2000, Sydney, Australia
CALL FOR PAPERS
PART is the premier conference for Parallel and Real-Time Systems
researchers in the Australasian region. The seventh annual event will be
held in Sydney, 29 - 30 November, 2000. The aim of this conference is
to
bring together Australasian and International researchers in parallel
and
real-time systems and their applications, and to provide the opportunity
for creative discussions.
The theme for the 2000 event is:
Internet and Multimedia --- Parallel and Real-Time Issues.
With their inherent parallelism, real-time demands, and widespread usage
and appeal, Internet-based distributed multimedia systems raise
important
issues for researchers and practitioners in the real-time and parallel
systems areas. The 2000 conference aims to bring researchers involved
in parallel and real-time systems together with researchers involved in
developing the Internet and multimedia applications of the future.
Authors are invited to submit manuscripts that demonstrate original
unpublished research in all areas of parallel and real-time systems.
Submissions with applications or addressing issues in the multimedia and
Internet areas are particularly encouraged. Topics of interest include,
but will not be limited to:
o Parallel architectures and algorithms
o Parallel programming
o Performance analysis and modelling
o Mobile computing
o Network-based concurrent computing
o Object-oriented Real-time and Parallel computing
o Parallel I/O systems
o Heterogeneous computing
o Multimedia systems
o Internet applications for parallel and real-time systems
o Distributed operating systems
o Message Passing Systems
o Real-time languages and tools
o Fault-tolerant computing
o Real-time aspects of distributed systems
o Real-time scheduling
o AI and neural networks in real-time control
o Reconfigurable Computing
o Real-time collaboration support
o Real-time aspects of database management systems
o Parallel databases
o Visualisation and visual programming of parallel systems
SUBMISSION GUIDELINES
Authors should submit manuscripts not exceeding ten (10) A4 pages
and not more than 5000 words. The authors' names, affiliations,
and email addresses should be on the front page. All papers will be
refereed and authors will be notified of acceptance as per the dates
given below. Proceedings of PART2000 will be published by
Springer-Verlag.
Authors are encouraged to submit manuscripts electronically
by emailing them as attachments in plain Postscript to
part2000@cse.unsw.edu.au. Alternatively, a hardcopy of the paper may be
sent to the Address for Correspondence below.
CONFERENCE ATTENDANCE
Accepted papers must be presented at the conference with the presenting
author registering as a delegate in order for the papers to be included
in the proceedings. Manuscripts whose authors are full-time students,
as certified by their universities, should be marked as student papers
to be considered for a ``Best Student Paper'' award.
SPECIAL SESSIONS
Proposals for special sessions are solicited. Interested individuals
should submit a proposal to the Program Co-Chairs.
TUTORIALS
Friday 1 December, 2000 is reserved for tutorials. We welcome
expressions
of interest in presenting a half- or full-day tutorial related to the
theme of the conference. Please send the title, a brief description
(not longer than 4 pages), and a short biography of the presenters to
the Program Co-Chairs by the date specified below. Electronic submission
is preferred.
IMPORTANT DATES
Paper Submission Deadline 3rd July 2000
Author Notification 31st July 2000
Camera-ready copies due 18th August 2000
Tutorial expression of interest 24th July 2000
ADDRESS FOR CORRESPONDENCE
PART2000 email:
part2000@cse.unsw.edu.au
c/o Oliver Diessel Tel: +61 2 9385 5922
School of Computer Science and Engineering Fax: +61 2 9385 5995
The University of New South Wales
UNSW SYDNEY NSW 2052
Australia
ORGANISATION
General Co-chair: Dr Arcot Sowmya (UNSW)
Organising Co-chairs: Dr Oliver Diessel (UNSW)
Partha Roop (UNSW)
Program Co-chairs: A/Prof. Hossam Elgindy (UNSW)
Dr Colin Fidge (UQ)
Steering chair: A/Prof. Nalin Sharda(VU)
FURTHER INFORMATION
For more information please visit the PART2000 web site
http://www.cse.unsw.edu.au/~part2000 or contact the Organising Co-Chairs
at the Address for Correspondence.
Article: 220121) Anyone know of a good block diagram for the PCI bus controller? 2) What is the critical path in the design? Thanks. JJArticle: 22013
In article <8cuclp$h1d$1@okapi.ict.pwr.wroc.pl>, "Tomasz Brychcy" <tbrychcy@sensor.ime.pz.zgora.pl> wrote: > Hello, > > What programator should I have if i would like to programm circuits of > xilinx (virtex,xc4000xl,l,xv). If you just want to experiment, you can simply download the configuration directly into the device with the Xilinx Parallel port cable. You lose the configuration when the power is removed, of course. The cable is quite cheap, or you can make your own from the circuit Xilinx provide on their web site. Leon -- Leon Heller, G1HSM Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824 Email: leon_heller@hotmail.com Web: http://www.geocities.com/SiliconValley/Code/1835 Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22014
Hi, has anyone an opinion about parity checking within a FPGA (e.g. Virtex), especially protecting the content of Block-RAMs? Bye ThomasArticle: 22015
This is a multi-part message in MIME format. --------------65D9547E859CAB932CE5ADFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Abhijit, Thanks very much. Our confusion lied in the fact that we could specificly call out a PCI primitive in the Virtex lib, but not in the XLA lib. You have cleared it up. Thanks very much. Tom Abhijit Athavale wrote: > Tom, > > It is a bitgen option and you can choose that in the configuration options > window if you are using the design manager. You can either select 5V tolerance > or 3.3V tolerance. If you select 5V tolerance, device is not 3.3V pci compliant. > If you choose 3.3V tolerance, device will lose its 5V compliance. > > We achieve 5V compliance through the ESD protection diode as per the databook > and add a clamping diode for 3.3V protection. > > Tom McLaughlin wrote: > > > Abhijit, > > > > Thanks for the info. One more question though. > > > > What about the clamp diode? The 3.3v PCI buffer is supposed to have a clamp > > diode and the 5v PCI buffer cannot. Do we have to specify this somewhere as > > well or will the tools know to put a clamp on the input if it is 12ma > > (3.3vPCI) and not if it is 24ma (5v PCI). > > Tom > > > > Abhijit Athavale wrote: > > > > > Tom, > > > > > > It is as easy as that. Set the PCI outputs to FAST slew rate and set > > > DRIVE=24 for 5V PCI signaling and DRIVE=12 for 3.3V signaling. The regular > > > XLA buffers are PCI compliant. > > > > > > Tom McLaughlin wrote: > > > > > > > All, > > > > We know how to specify PCI buffers in Virtex and Virtex E. We put the > > > > statement: > > > > > > > > set_attribute -port "outchan1_bp(2)" -name buffer_sig -value > > > > OBUF_PCI33_3 > > > > > > > > in the synthesis script and it passes the attribute to the backend. > > > > > > > > The problem is that we want to use a PCI compliant buffer on an XLA > > > > part. The docs say that it supports it, but we cannot figure out how to > > > > implement it. To check if the architecture does support it, I pulled up > > > > the constraints editor after choosing an XLA part. When I click on I/O > > > > standards, I only have the option to set drive strength, slew rate, but > > > > not the I/O standard. If you do this with a Virtex part, a new column > > > > appears called "I/O standards" which has all the I/O options, LVTTL, > > > > SSTL, PCI etc. > > > > > > > > The libraries guide on the Xilinx web site does not show support for XLA > > > > that we can find. We tried using the above statement for the XLA > > > > architecture, but it is not valid. > > > > > > > > The datasheet goes to great lengths to say the XLA has these PCI > > > > compiant buffers, but does not say how to implement them. Please > > > > help!!! Do we just implement LVTTL buffers with 12ma of drive strength > > > > and that is PCI compliant....it can't be that easy.....??? > > > > > > > > BTW, we are using Alliance 2.1i. > > > > > > > > Tom --------------65D9547E859CAB932CE5ADFB Content-Type: text/x-vcard; charset=us-ascii; name="tomm.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom McLaughlin Content-Disposition: attachment; filename="tomm.vcf" begin:vcard n:McLaughlin;Tom tel;fax:314-935-7302 tel;work:314-935-7198 x-mozilla-html:FALSE url:http://www.arl.wustl.edu/~tomm org:Washington University;Applied Research Lab version:2.1 email;internet:tomm@arl.wustl.edu title:Research Associate adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA x-mozilla-cpt:;0 fn:Tom McLaughlin end:vcard --------------65D9547E859CAB932CE5ADFB--Article: 22016
Hi, I try to use Modeltech 5.3a to perform a timing analysis (XILINX ping design). The simulation script stops with: sdf file: requires Xilinx primitive library I included the the primsim and unisim library from the <XILINX> directory. Does anybody have an idea, how to fix this problem ? Thank, ThomasArticle: 22017
Thomas Rinder wrote in message <8d23b9$bsm$1@rzsun03.rrz.uni-hamburg.de>...
>Hi,
>
>I try to use Modeltech 5.3a to perform a timing analysis (XILINX ping
>design).
>
>The simulation script stops with:
>sdf file: requires Xilinx primitive library
>
>I included the the primsim and unisim library from the <XILINX> directory.
>
>Does anybody have an idea, how to fix this problem ?
See the following Xilinx tech answer doc. it tells all.
http://support.xilinx.com/techdocs/2561.htm
--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 22018Hi, you mention that you have low freq which are f/16, IF this low freq is generate from the base freq (f) than you might not need the syncronizer at all BUT here come the tricky quesiton, how do you generate the low freq ? if you have a counter/devider than depend on the way you designed this devide, if you design is such as that both posedge of the low freq and high freq are togther (a cascade DFF as a simple counter therfore will not do) than when you send a signla from the low freq to the high the signal not need to have any "handling" HOWEVER when you send from the high to the low than you must hold it for few clock so it will still be active when the low freq finaly get to the posedge. (if you also use negedge of clock somewhere you will need that also both negedge of the clock will be on the same time). BTW the "suffer" of clock delay is expected as after all you sample it twice in the syncronizer. also you might consider not a full-handshake incase you are certain that the other module "saw" the signla, and in this case you can de- active the signal as soon as you belive it is ok. unless you are limited due to number of FF/gates I belive this will work also in higher frequance, what you might consider doing but is all depend on your desing is that you might consider adding a fifo, or maybe make the data passing as burst mode meaning that when you ask to read the data you also tell how many read you want to do in this read (the how many will be treated as data and not need to be syncronized) and than you can get few block of data but again it is all just an idea's and it all depoend on your design. have a nice day Illan In article <8d0qfd$d19$1@coco.singnet.com.sg>, "MK Yap" <mkyap@REMOVE.ieee.org> wrote: > Hi! > > I have a few modules that works in this way... > In_module which works at .. say 33Mhz( f), out_module at ard 2MHz ( f/16). I > have synchornized the out_module to in_module and the warning goes away... > and yup! The simulation result is now correct :-)) > but I suffer some delay(1-2 clk cycles) in sending data... :-( > > There is another out2_module that works at much higher speed, (max f/3 or > 11MHz). I believe my method no longer works since the delay (1-2 clk cycles) > is intolerable in this case... Does yer method work in this case? > > btw, in Synplify, I managed to design all my modules to work at, say all > >70Mhz. But when I use schematic to interconnect the modules in max+plus2 > (use fast logic synthesis), after compilation, the max frequency drops > drastically to ard 40MHz.... is there any way to improve the final max > frequency close to 70MHz?? > > Thanks Iglasner & Christian for sharing yer experiences... They're useful > for novice like me :-) > > Regards > MK > > <iglasner@zumanetworks.com> wrote in message > news:8cvpj6$51g$1@nnrp1.deja.com... > > Hi, > > > > You ommite the clock frequance of the 2 clock's (or maybe more ?) > > you are talking about as well as are the infomation delay is crusial or > > can you wait a clock or two. > > > > according to the above there are few way to approch the problem. > > > > as an example assume you have a data stored in module1 work with clk1 > > in few buffers and you want to read a certain buffer to a module2 that > > work in clk2 > > > > than a general sulotion will be that module2 will prepare the buffer > > number he want to read and than will rais a single saying he want to > > read. > > > > this read signal you will pass through syncronizer (to clk1) to module1 > > domain and than module1 will look and see the address which is > > already "long ago" stable. > > > > module1 will than put the data and will rais a signal saying data is > > ready. > > > > this data is ready signal will also be syncronize (to clk2) and when > > module2 see it the data is already stable, and can be "used safely". > > > > than module 2 pulldown the read and as soon as mosule 1 see that the > > read signal is pulldown he pulldown the data is ready signal. > > > > this is just one way (usually called full-handshake) and there are many > > other. > > > > have a nice day > > > > Illan > > > > > > In article <8cu1mq$3v1$1@coco.singnet.com.sg>, > > "MK Yap" <mkyap@REMOVE.ieee.org> wrote: > > > Hi all, > > > > > > For my design, there is a global clock, some input signals, some > > output > > > signals (clocked by external source). > > > > > > When input signals come in(synchronized by global clock), the central > > > controller will collect, organize, manipulate & store in buffer. > > > The output port interface portion will at intervals (ctrl by external > > clk) > > > request data from buffer. > > > During my design, I encounter hundreds of design warning by > > max+plus2 (i'm > > > using synplify vhdl sythesizer) saying sth like this > > > "Design Dr warning: flipflop or synchronous memory 'q_data_7' > > receives data > > > that is synchronized by another clock at flipflop or synchronous > > memory > > > 'subc_datareq' " > > > & > > > "Design Dr warning: inverting delay chain starting at primitive > > > 'cntr_1_lut_5' feeds primitive 'statemachine_cntr_i_0' " > > > > > > & my project fails to work during timing simulation. > > > Can somebody pls shed some light on how to properly design a multiple > > clock > > > system that meets all setup time, hold time....??? > > > or is there any good reference that stress on this area of design? > > > > > > Any help is much appreciated. Thanks in advance. > > > > > > Rgds > > > MK > > > > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22019
"MK Yap" <mkyap@REMOVE.ieee.org> writes: > Hi! > > I have a few modules that works in this way... > In_module which works at .. say 33Mhz( f), out_module at ard 2MHz ( f/16). I > have synchornized the out_module to in_module and the warning goes away... > and yup! The simulation result is now correct :-)) > but I suffer some delay(1-2 clk cycles) in sending data... :-( > > There is another out2_module that works at much higher speed, (max f/3 or > 11MHz). I believe my method no longer works since the delay (1-2 clk cycles) > is intolerable in this case... Does yer method work in this case? > You are writing "f" and "f/16". Are these frequencies synchronous, that is, is that f/16 created from f by division? In this case, it would be much easier and better to feed the higher frequency to all modules and to do the "frequency division" by distributing a f/16 clock-enable signal. This would be a fully synchronous design, and all synchronization problems would be solved, maybe (but not necessarily) at the cost of higher logic consumption. > btw, in Synplify, I managed to design all my modules to work at, say all > >70Mhz. But when I use schematic to interconnect the modules in max+plus2 > (use fast logic synthesis), after compilation, the max frequency drops > drastically to ard 40MHz.... is there any way to improve the final max > frequency close to 70MHz?? This is very hard to tell without knowing more about the whole design. The timing analyzer might help you to find the specific signal that needs that 25ns. chm. -- cmautner@ - Christian Mautner utanet.at - Vienna/Austria/EuropeArticle: 22020
Check out my music at http://nav.to/deviant3/ eveything under the sun.. mp3s and impulse tracker files are available...Article: 22021
Hello, I am a student. I start with a project at my university and therefore I also need a communication between a DSP (Ti-TMS320C60x) and a Xilinx (Virtex) for a realtime network. Does anybody have some experiences about this topic ??? Should (could) I use some demo-ports with pci-slots and start the comminication with the pci-bus (is it fast enough??) or can I make a direct connection ??? Are any other connections possible ?? Thanks for all informations! GerhardArticle: 22022
Hello, I'm looking for demo board to do some design practice on my own (the university board is not very good). It should work with the Xilinx 4000 series, have at least 3 7-seg displays and some switches, buttons, ADC, etc. and serial download. Maybe somebody can recommend me a cheap and good one. Thanks, Philipp Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22023
Please is there any way to convert from parallel to serial without
using a counter to control the shift register?
Thanks
Article: 22024Hello! Command line? I presume DOS-Prompt. As I saw the .bsd file has a long file name not 8.3 format. The DOS prompt can't find file beyond 8.3 format. Try changing names or similar. Greetings Marko >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 7.4.00, 10:00:32, Joerg RiTTer <ritter@informatik.uni-halle.de> wrote= =20 regarding jtag/jtagprog and fpga-demo-board: > Hi, > I've successfully downloaded designs to a fpga-demo-board with the > hardware-debugger-software and the xchecker-cable. > Now I was looking for a command line version. > I've realized, that the jtagprog command line tool could be a=20 solution. > Downloading with jtag / jtagprog fails with the following error=20 message > : > JTAG Programmer Started 2000/04/06 10:20:37 > Loading Boundary-Scan Description Language (BSDL) file > 'g:/Xilinx/xc4000e/data/xc4005e_pc84.bsd'.....completed > successfully. > Checking boundary-scan chain integrity...ERROR:JTag -=20 Boundary-scan > chain test failed at bit position '1' on instance 'addsub(Device1)'. > Check that the cable, system and device JTAG TAP connections are= > correct, > that the target system power supply is set to the correct level,= > that the system grounds are connected and that the parts are > properly decoupled. > ERROR:JTag - Boundary scan chain has been improperly specified. > Please check your configuration and re-enter the boundary-scan=20= chain > information. > Boundary-scan chain validated unsuccessfully. > ERROR:JTag - : The boundary-scan chain has not been declared > correctly. > Verify the syntax and correctness of the device BSDL files,=20 correct > the files, > reset the cable and retry this command. > I was using the same xchecker cable, fpga-board and the exactly the=20= same > switch/flying leads settings. > Any ideas ? > Is there a command line version of the hardware debugger ? > Thanks > Joerg
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