Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 69275

Article: 69275
Subject: Re: Connecting a crystal to a Cyclone or Max PLD
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 04 May 2004 09:24:59 GMT
Links: << >>  << T >>  << A >>
Peter Alfke wrote:



> A crystal is usually connected as a Colpitts oscillator, where the IC
> provides the first 180 degree phase shift, and the xtal plus external RC
> combine for the remaining 180 degrees. The total circuit loop must have 360
> degree phase shift and a gain of exactly 1.0. That is the condition for
> stable oscillation.

Is this for series resonant crystals?   I am trying to remember
the difference in the oscillator for series and parallel resonant
crystals.

> XC3000 had such a single-stage amplifier, and could implement an oscillator
> with just a crystal, two capacitors and two resistors.
> But there were lots of problems when users connected obscure crystals,
> ranging from 32 kHz to 100 MHz. Most digital designers lack even the most
> rudimentary understanding of oscillators, why they require a single
> amplifier stage, and why they cannot reliably be implemented with the
> multi-stage amplifier typically between an input and an output of a modern
> CMOS IC.

The ones I remember from the 1970's used three CMOS inverters, I think
more reliably than using just one.  An additional inverter was used as
a buffer between the crystal and the rest of the circuit.

I can see that unusual results would happen as the propagation
delay through the inverters approached half the period.

> So, please, don't even try. You will not be able to design a reliable xtal
> oscillator this way, one that starts and runs reliably, and does not break
> out in wild harmonic or non-harmonic oscillations.

The worst crystal problems I ever had were trying to get an 8284 clock
generator to run at 8MHz using a 24MHz crystal.  (It has a divide by
three in it.)   That was to run an 80287.  I finally found another
crystal that wasn't much lower frequency and ran reliably.

That was for a circuit that was designed to be a crystal oscillator!

-- glen


Article: 69276
Subject: [ANN] DSP for FPGAs 4-Day Course
From: "Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk>
Date: Tue, 4 May 2004 10:54:40 +0100
Links: << >>  << T >>  << A >>

Just to let you know we have a DSP for FPGAs
course running on 24th-27th May.  Info and
details at:

http://www.sli-institute.ac.uk/fpgacourse




Article: 69277
Subject: ASIC design
From: Christian Haase <nospams@today.de>
Date: Tue, 04 May 2004 15:20:45 +0200
Links: << >>  << T >>  << A >>
Hello,

are there any valuable sources (links, papers, books) that
guide to ASIC design? (esp. synthesis + implementation e. g.
with the Cadence tools).

Thanks a lot for any kind of interesting advice
Christian


Article: 69278
Subject: Re: Not enough sites to place MULT18X18?
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 04 May 2004 15:18:13 GMT
Links: << >>  << T >>  << A >>
Do you need the 64-bit width of your RAMs at full speed?  If you need wide
but can handle a little latency, going 16 bits wide with the BlockRAMs into
64 bits of register would give you the width and depth you need in one
BlockRAM *and* allow access to the accompanying MULT.

This might help - I only scanned it recently...

  XAPP229 - Wider Block Memories
      http://www.xilinx.com/bvdocs/appnotes/xapp229.pdf


"Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message
news:4096ff41$1@news.starhub.net.sg...
> i used core generator to generate the RAMs, and they have 64-depth 64-bit
> RAMs,
> so I have no much control over how XST implements it in the synthesis.
> Actually in
> Floor Planner I can see some BRAM and MULT18X18 side by side...
>
> I have replaced 16 multipliers with LUTs implementions from Core
> generator...
> And it is working now but I am concerned with the slice usage...
>
> Kelvin
>
>
>
>
>
> "Ken Morrow" <junk@not_morro.co.uk> wrote in message
> news:vzrkc.36293$h44.5385972@stones.force9.net...
> > Kelvin,
> >
> > You will probably find that some of the multiplier sites are blocked
from
> > being used due to
> > some block RAMs having widths of > 18 bits. If so, try to change some of
> the
> > RAMs to
> > have smaller widths.
> >
> > I have a design which now uses all 144 of the V2-6000 multipliers, and
> most
> > of the RAMs
> > without prob. I had to reduce the width of all of the RAMs to 18 bits or
> > less for the multipliers
> > to be available for use.
> >
> > (I was impressed that Mentor Precision automatically used multipliers
> built
> > with LUTs, once it had
> > used up all the available multipiers).
> >
> > Good Luck,
> >
> > Ken,
> > Morrow Electronics Limited, UK
> > Currently specialising in FPGA design for 3G.
> > www.morro.co.uk
> >
> >
> > "Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message
> > news:4091f4e6@news.starhub.net.sg...
> > > Hi, there:
> > >
> > > I am implementing a partial chip for virtex-2-6000. My module has 116
> > > multipliers, the module is allocated an area group with 120
multipliers.
> > > Later I got 9 multipliers not placed, while the PAR
> > > informs there are 13 available sites for placing them...However, the
> > > placement failed...
> > >
> > > How may I handle such a situation?
> > >     Replace some smaller * with rtl implementation? How many slices
can
> I
> > > implement an 8X8 muldipler?
> > >     Repartitioning to put some * signs in somebody else's modules?
> > Possible
> > > but troublesome...
> > >
> > > Best Regards,
> > > Kelvin
> > >
> > >
> > >
> > >
> > >
> > >
> > > Phase 6.9
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wkq_calc_mul_inst_
> > > m
> > >    ult_11 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wkq_calc_mul_inst
> > > _mul
> > > t_11".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wkq_calc_mul_inst_
> > > mult
> > > _11 will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_q0_b_mul_inst_mu
> > > l
> > >    t_2 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_q0_b_mul_inst_m
> > > ult_
> > > 2".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_q0_b_mul_inst_mu
> > > lt_2
> > > will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0009_inst_mu
> > > l
> > >    t_3 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0009_inst_m
> > > ult_
> > > 3".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0009_inst_mu
> > > lt_3
> > > will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataii_mul_inst_mu
> > > l
> > >    t_1 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataii_mul_inst_m
> > > ult_
> > > 1".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataii_mul_inst_mu
> > > lt_1
> > > will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_a_mul_inst_mu
> > > l
> > >    t_2 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_a_mul_inst_m
> > > ult_
> > > 2".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_a_mul_inst_mu
> > > lt_2
> > > will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0010_inst_mu

> > > l
> > >    t_3 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0010_inst_m
> > > ult_
> > > 3".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_multipath_top/i_multipath_wk_calc/Mmult__n0010_inst_mu
> > > lt_3
> > > will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataqq_mul_inst_mu
> > > l
> > >    t_1 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataqq_mul_inst_m
> > > ult_
> > > 1".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_dataqq_mul_inst_mu
> > > lt_1
> > > will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wki_calc_mul_inst_
> > > m
> > >    ult_11 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wki_calc_mul_inst
> > > _mul
> > > t_11".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_wk_calc/Mmult_wki_calc_mul_inst_
> > > mult
> > > _11 will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > WARNING:Place:119 - Unable to find location.  MULT component
> > >
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_b_mul_inst_mu
> > > l
> > >    t_2 not placed.
> > >    MULT18X18
> > >
> >
>
"i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_b_mul_inst_m
> > > ult_
> > > 2".
> > >       COMPGRP "RX.MULT18X18" LOCATE = SITE
> > "MULT18X18_X1Y23:MULT18X18_X5Y0"
> > > LEVEL 4 ;
> > > Only the one associated with MULT18X18
> > >
> >
>
i_ofdm_rx/i_wrx_top/i_channel_top/i_channel_calc/Mmult_data_i0_b_mul_inst_mu
> > > lt_2
> > > will be looked at.
> > > The AREA group contains 120 possible sites for this component.   13 of
> > these
> > > sites were available to place this component into.
> > > ===============================================================
> > > List of 13 available sites in area are:
> > >    Site MULT18X18_X1Y3
> > >    Site MULT18X18_X1Y5
> > >    Site MULT18X18_X1Y12
> > >    Site MULT18X18_X1Y15
> > >    Site MULT18X18_X1Y19
> > >    Site MULT18X18_X2Y4
> > >    Site MULT18X18_X2Y6
> > >    Site MULT18X18_X2Y8
> > >    Site MULT18X18_X2Y12
> > >    Site MULT18X18_X2Y16
> > >    Site MULT18X18_X2Y19
> > >    Site MULT18X18_X2Y20
> > >    Site MULT18X18_X2Y22
> > > ===============================================================
> > > List of comps in area without same LOC are:
> > > ===============================================================
> > > ERROR:Place:120 - There were not enough sites to place all selected
> > > components
> > > Phase 6.9 (Checksum:39386fa) REAL time: 27 mins 46 secs
> > >
> > > Total REAL time to Placer completion: 27 mins 47 secs
> > >
> > >
> > >
> >
> >
>
>



Article: 69279
Subject: Stratix - Virtex2Pro Co-Simulation using modelsim !
From: "Adarsh Kumar Jain" <adarsh.jain@cern.ch>
Date: Tue, 4 May 2004 17:44:17 +0200
Links: << >>  << T >>  << A >>
Hi,
I am trying to simulate together a Stratix and a V2Pro design using
ModelSim.
Both the designs simulate correctly individually.
I use the Rocket IOs in the V2Pros so have set the modelsim.ini file
correctly.
The interesting thing is that in the co-simulation, all parts of the design
are ok except the
Rocket IO part which makes me think that it is probably due to the
Smartmodel interface
which i may not be correctly setting up.
When I simulate the Xilinx alone, while loading the design files in ModelSim
the first line I see is :

Loading C:/Modeltech_5.7f/win32/libswiftpli.dll

but i do not see such a line when running the co-simulation, which could
possibly be the reason for not seeing anything come out of the Rocket IOs in
the Co-Simulation.

Could anyone help with this ?
I will be grateful.
Thanks in advance,
adarsh



Article: 69280
Subject: Re: Best way to handle multiple common data busses in Altera FPGA (and others)
From: george.martin@att.net (George)
Date: 4 May 2004 08:52:37 -0700
Links: << >>  << T >>  << A >>
gabor@alacron.com (Gabor Szakacs) wrote in message news:<8a436ba2.0405031357.39ec912b@posting.google.com>...
> george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>...
> > Hello:
> > 
> > I'm generating a new design using an Altera Cyclone FPGA.  But I think
> > this issue may be applicable to all FPGAs.  I have 8 identical modules
> > that each have an 11 bit status register.  The CPU (in this case a
> > NIOS embedded on the same device) needs to read these status
> > registers.
> > 
> > The question is what is the best (size first, speed second)
> > configuration for these inputs?  Can I use a tristate type
> > construction and save interconnects to the CPU.  Does this really save
> > any routine resources and at what expense.  In this design I can live
> > with long delays on reading the status registers.
> > 
> If you can live with very long delays, consider one long shift register
> or eight 11-bit shift registers with an 8:1 mux.  Status can be loaded into
> the shift registers in parallel and then shifted into the CPU.  This is
> a little like JTAG boundary scan logic.  It reduces global interconnect,
> but probably uses as much resources (though different kind, flip-flops
> vs. LUT's or TriState buffers) as the brute force parallel method.
> 
> > Any input would be appreciated.
> > 
> > Thanks
> > George


Well I entered a TriState mux 8 times into the design.  I placed,
routed and simulated with out large delays.  But I did notice the LE
(logic Elements) usage creeping up.

I like the serial shifting scheme.  I can generate a SPI controller in
the CPU so I only have to design the end that goes into each of the 8
status registers.  The penality with this approach is that I might
need 11 bit register to capture and shift the status values.  Perhaps
I could just make one counter (4 bit = 16 status inputs) for all
status registers and an 11:1 mux for the data values.  I like this a
lot!!!

Thanks for the help.
This group Rocks!!
George

Article: 69281
Subject: Re: Connecting a crystal to a Cyclone or Max PLD
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 04 May 2004 08:58:48 -0700
Links: << >>  << T >>  << A >>
Every xtal has parallel as well as series resonance. These two frequencies
are very close together, and the typical Colpitts oscillator actually
oscillates at a frequency in-between.
For most typical low-precision applications, the difference between parallel
and series resonance is irrelevant for the user. The crystal just picks a
point in-between.
Peter Alfke 
===============
>> A crystal is usually connected as a Colpitts oscillator, where the IC
>> provides the first 180 degree phase shift, and the xtal plus external RC
>> combine for the remaining 180 degrees. The total circuit loop must have 360
>> degree phase shift and a gain of exactly 1.0. That is the condition for
>> stable oscillation.
> 
> Is this for series resonant crystals?   I am trying to remember
> the difference in the oscillator for series and parallel resonant
> crystals.
> 
>


Article: 69282
Subject: Re: timing constraints
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 4 May 2004 09:16:10 -0700
Links: << >>  << T >>  << A >>
My pleasure! I forgot to point out, you have to remove the contraint(s) that
caused the error when you run the translate first time. When you've found
the name, you can put the constraint back in!
Cheers, Syms.
"Frank van Eijkelenburg" <someone@work.com> wrote in message
news:409731b9$0$67512$ee9da40f@news.versatel.net...
> Symon,
>
> thanks for the tip. I can not run the floorplanner, because the translate
> process is generating the error, but your suggestion about the name did
> work.
>
> Frank
>



Article: 69283
Subject: synthsizing multi-dimensional array XST
From: rajarsheeb@yahoo.com (raj)
Date: 4 May 2004 09:24:52 -0700
Links: << >>  << T >>  << A >>
Hi,

For one of my applications,I was coding in Behavioral Level(vhdl) for
a non-pipelined matrix multiplication(only combinational logic).The
functional simulation went fine.Though synthesis went on without any
erros, XST did not extract any multipliers/adders(I did enable the
options in synthesis properties).XST documentation says it can
synthesize upto 3 dimensional  arrays.

I don't want to write a structural vhdl in terms of multipliers and
adders.
Should I unroll the loops!!
Suggestions concerning my coding style,modification etc will be very
helpful.

regards
--raj


----------------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;


entity matrix_multiply  is
		port (
		       init : 	in std_logic;
		       select_in:	in std_logic_vector(3 downto 0);
		       done  : out std_logic_vector(15 downto 0)
		      );

end matrix_multiply;

architecture Behavioral of matrix_multiply is
---------------------------------------------
subtype WORD8 is integer range 0 to 255;
type TAB4 is array (3 downto 0) of WORD8; --one dimension of matrix
type TAB4x4 is array (3 downto 0) of TAB4; 
signal MATRIXA,MATRIXB :TAB4X4;

----------------------------------------------------
subtype WORDBIT is std_logic_vector(15 downto 0);
type 	OUT4 	is array (3 downto 0) of WORDBIT;-- one dimension of
matrix
type 	OUT4x4 is array (3 downto 0) of OUT4;
signal 	MATRIXC:OUT4X4;


--------------------------------------------

--------------------------------------------

constant CST_A : TAB4x4 := (
										(5,6,7,8),
										(1,2,3,4),
										(2,4,5,8),
										(1,1,1,1)
										
								    );


constant CST_B : TAB4x4 := (
										(2,3,4,5),
										(1,2,3,4),
										(6,7,6,8),
										(1,1,1,1)
										
								    );
constant CST_C : OUT4x4 := (
										((others=>'0'),(others=>'0'),(others=>'0'),(others=>'0')),
										((others=>'0'),(others=>'0'),(others=>'0'),(others=>'0')),
										((others=>'0'),(others=>'0'),(others=>'0'),(others=>'0')),
										((others=>'0'),(others=>'0'),(others=>'0'),(others=>'0'))
										
								    );



begin

MATRIXA<=CST_A;
MATRIXB<=CST_B;
---------------CORE----------------
process(init,MATRIXC)
variable temp:integer;
begin
if(init='0')then 
MATRIXC<=CST_C;
else
for row in 0 to 3 loop
	for col in 0 to 3 loop 
		temp:=0;
		for k in 0 to 3 loop
		temp:=temp+(MATRIXA(row)(k)* MATRIXB(k)(col)); 
		end loop;
	 MATRIXC(row)(col)<= CONV_STD_LOGIC_VECTOR(temp,16) ;
	end loop;
 end loop;
end if;		 	 	

end process ; 
----------SENDING THE OUTPUT--------------------------
done <=  MATRIXC(0)(0)  when select_in = "0000" else
         MATRIXC(0)(1)  when select_in = "0001" else
         MATRIXC(0)(2)  when select_in = "0010" else
         MATRIXC(0)(3)  when select_in = "0011" else
	 MATRIXC(1)(0)  when select_in = "0100" else
         MATRIXC(1)(1)  when select_in = "0101" else
	 MATRIXC(1)(2)  when select_in = "0110" else
	 MATRIXC(1)(3)  when select_in = "0111" else	
         MATRIXC(2)(0)  when select_in = "1000" else
         MATRIXC(2)(1)  when select_in = "1001" else
         MATRIXC(2)(2)  when select_in = "1010" else
	 MATRIXC(2)(3)  when select_in = "1011" else
	 MATRIXC(3)(0)  when select_in = "1100" else
         MATRIXC(3)(1)  when select_in = "1101" else
         MATRIXC(3)(2)  when select_in = "1110" else
	 MATRIXC(3)(3)  when select_in = "1111" else
-----------------------------------------------------

Article: 69284
Subject: Re: Not enough sites to place MULT18X18?
From: widding@birger.com (Erik Widding)
Date: 4 May 2004 12:02:17 -0700
Links: << >>  << T >>  << A >>
"Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message news:<4096ff41$1@news.starhub.net.sg>...
> i used core generator to generate the RAMs, and they have 64-depth 
> 64-bit RAMs, so I have no much control over how XST implements it in
> the synthesis.

If you want to force the core generator to use x16 BRAMs just tell it
that you want a ram that is 1K deep, as it will be forced to build it
from 1K x 16 BRAMs.  We have generally found that it is easier to
instantiate primitives (i.e. BRAMs) in the VHDL with loops, than it 
is to use the core generator for things like memories.  When you use
core generator to make a memory, XST is really just treating it as a
black box.


> I have replaced 16 multipliers with LUTs implementions from Core
> generator... And it is working now but I am concerned with the slice
> usage...

It might make more sense to use SelectRAMs rather than BRAMs for the
rather shallow memories.  This will use slices to build the memories,
but may be a better trade off than using slices for the multipliers.
You did mention 8x8 multipliers in your original posts, so this is
probably not the case.


Regards,
Erik Widding.

---
Birger Engineering, Inc. -------------------------------- 617.695.9233
100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com

Article: 69285
Subject: Re: Best way to handle multiple common data busses in Altera FPGA (and others)
From: kempaj@yahoo.com (Jesse Kempa)
Date: 4 May 2004 13:53:02 -0700
Links: << >>  << T >>  << A >>
george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>...
> Hello:
> 
> I'm generating a new design using an Altera Cyclone FPGA.  But I think
> this issue may be applicable to all FPGAs.  I have 8 identical modules
> that each have an 11 bit status register.  The CPU (in this case a
> NIOS embedded on the same device) needs to read these status
> registers.
> 
> The question is what is the best (size first, speed second)
> configuration for these inputs?  Can I use a tristate type
> construction and save interconnects to the CPU.  Does this really save
> any routine resources and at what expense.  In this design I can live
> with long delays on reading the status registers.
> 
> Any input would be appreciated.
> 
> Thanks
> George


To get the data into the processor the easiest method would be to use
a PIO peripheral (included in the Nios kit). Someone mentioned that
Nios doesn't have 88 IOs...it can have as many as you want (as long as
it fits)! However, for this application the most efficient way may be
to create two PIO periherals that Nios directly addresses: an 11-bit
intput to capture the data of a single logic module, and a 3-bit
output that goes to a mux which connects your single 11-bit input PIO
to the 8x11-bit status register values coming out of each module.

Outside of the Nios/SOPC Builder logic you would wire up the PIO
output to a 8:3 mux, and you're in business...

Your software source would then look like this, to read each status
register into an array of memory (C pseudocode):

unsigned short status[8];

for(i=0; i<8; i++)
{
  *select_pio_data = i;
  status[i] = *status_pio_data;
}

It may be advisable to put a small delay statement in between the PIO
write (to mux select) and PIO read (to fetch data)... but that is
probably overkill.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 69286
Subject: Re: Ethernet & FPGA
From: Guenter Dannoritzer <dannoritzer@web.de>
Date: Tue, 04 May 2004 23:20:20 +0200
Links: << >>  << T >>  << A >>
Hi Stefan,

Stefan Kopetsch wrote:

> Hi...
> 
> i'll write my bachelor thesis about the implementation of ethernet and 
> possible tcp/ip layers in an fpga. does someone have experience doing 
> it? especially using open source ip cores like the ethernet MAC core 
> from opencores.org? would be nice if someone could share their 
> experience. another point is the implementation of tcp/ip. does it make 
> sense to do it all in hardware or is it simpler to run a processor core 
> on the fpga and then implement the tcp/ip layers using a highlevel 
> language like C? i gotta stress that the aim is initially to build an 
> runnable ethernet core and then implement the data transfer step by step
> 
> TIA
> 
> Stefan

I have been looking into hardware implemented tcp/ip chips a year or two 
ago for an embedded project. I was intrigued by the idea not to have to 
bother the processor with the tcp/ip stack. I found only two vendors at 
that time and one of them phased their chip already out. One issue I 
found in the other chip was, that it only could handle four tcp 
connections. Granted it still provided access to the ethernet layer, 
which would allow a connected processor to implement a tcp/ip stack, but 
that defeats the purpose of the hardware stacks in the first place.

If you don't have any requirements concerning the tcp/ip layer I guess 
the question will be what do you like to do better, implement a 
processor core in hardware and the tcp/ip stack in software or do the 
tcp/ip stack in hardware. Which brings up the questions what are you 
allowed to take as available ip and what do you have to do by yourself?

With the uClinux running on the OpenRisc and the ethernet core you will 
find, I believe (haven't tested it), a running system with ethernet and 
tcp/ip stack in software on open cores.

Guenter


Article: 69287
Subject: Re: EDK 3.2
From: Vinod <vinod@nospam.net>
Date: Tue, 04 May 2004 14:49:41 -0700
Links: << >>  << T >>  << A >>
yes, XILINX_EDK is before XILINX.
Infact, both of them are installed in the same directory, ie C:\EDK.
Is that a problem?

Im wondering if any of these patches for windows XP are causing a
problem.

thanks
vinod

On Mon, 03 May 2004 09:42:42 -0700, Paulo Dutra
<paulo.dutra@xilinx.com> wrote:

>Check your PATH environment. XILINX_EDK must before XILINX
>
>
>Matthew Ouellette wrote:
>> Vinod,
>> 
>> EDK 3.2 is compatible with 5.2 SP1 and greater only.  Check the Getting 
>> Started Guide for more information.
>> 
>> Matt
>> 
>> Vinod wrote:
>> 
>>> Hi,
>>> I am having problems starting up the Xilinx Platform Studio. I have
>>> installed EDK 3.2 with service pack 2. When I run it, I get a message
>>> saying
>>>
>>> "The procedure entry point
>>> ?GetProjectToolBarID@Dco_PlToolBarManager@@SAIXZ could not be located
>>> in the dynamic link library libDco_Plugin.dll"
>>>
>>> Im running Windows XP professional with SP1. Also have Xilinx ISE
>>> 5.1.3i installed. My env variables seem to be pointing to the correct
>>> location. I've tried reinstalling, but of no avail.
>>>
>>> Any help will be appreciated.
>>>
>>> Vinod


Article: 69288
Subject: Altera SoPC builder command line system generator
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 05 May 2004 00:08:58 +0200
Links: << >>  << T >>  << A >>

According to "Reference Manual SOPC Builder PTF File":

"The System Generator Program can also be run from the command-line
independent from the GUI. When the System Generator Program runs, it
must read system design data from a PTF file. The name of the PTF file
is given as a command line argument to the System Generator Program."

But how do I run the system generator from the command line?

The GUI appears to buld a script called SYSTEM_generation_script, but
this seem to use an arguement ($1) which I can't seem to guess since I
will get an malformed argument error in wiz_utils.pm later.


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 69289
Subject: Re: Connecting a crystal to a Cyclone or Max PLD
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 05 May 2004 00:38:34 GMT
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Every xtal has parallel as well as series resonance. These two frequencies
> are very close together, and the typical Colpitts oscillator actually
> oscillates at a frequency in-between.
> For most typical low-precision applications, the difference between parallel
> and series resonance is irrelevant for the user. The crystal just picks a
> point in-between.

Maybe not close enough if you are building a clock or frequency
counter, but probably close enough for a CPU clock, I agree.

I agree that the frequencies are close.  Different oscillator circuits
work differently, and I wasn't sure which your description was about.

Also, some crystals are designed to run at a higher odd harmonic of
the fundamental, which complicates things a little.

I once knew the difference between the two types of oscillators, but
I don't remember it now.

-- glen


Article: 69290
Subject: How to drive record fields from procedure AND testbench?
From: joseph_484@hotmail.com (Joe Vanderwall)
Date: 4 May 2004 18:44:15 -0700
Links: << >>  << T >>  << A >>
Hi folks,

I am having a problem that is beyound my present VHDL capabilities. 

I am trying to model a bus in a testbench using the following
(incomplete) record:

type rec is record
  rd, wr, waitreq : std_logic;
  writedata       : std_logic_vector(31 downto 0);
end record;

(I left a bunch out for brevity).

- rd, wr, and writedata are driven by the master of the bus.
- waitreq is driven by the slave, indicating when it can't immediately
satisfy a master request.

I then have some useful functions having prototypes:

  procedure InitBus( signal busRec: inout rec );
  procedure WriteValue( signal busRec: inout rec; 
                        address: integer; 
                        value: integer );

And in my code I hook things up:

  architecture ...
    signal busRec : rec;
    ...
  begin
    DUT_inst : DUT port map ( wr=>wr, rd=>rd, 
                 waitreq=>waitreq, readdata=>readdata,
                 ... );

    wr <= rec.wr;
    rd <= rec.rd;
    writedata <= rec.writedata;
    rec.waitreq  <= waitreq;

    InitBus( rec );

  end;

This setup causes an error, presumably because some records are driven
from the procedure, and others from the DUT.

How do the "professionals" create and use a record that has some
fields driving one way, and others driving the other?

I've successfully used this arrangement before, but I managed to have
all the fields of the record driven from the procedures. In this case
I now have a waitreq, which is an integral part of the bus model,
driven by the DUT . Is it possible to bring this signal into the
procedures using a single record? Or do things have to get messy?

A further question is when I have a birectional data bus (driven by
the master during writes, driven by the DUT during reads). Example:

  begin
    DUT_inst: DUT port map ( data => bidir_data ... );
    rec.bidir_data  <= bidir_data;
  end;

Can I even manage bidirection data buses with the record approach?

Can someone suggest further reading on how to do this stuff? An
admittedly cursory Google search brought up all kinds of stuff on
records, but nothing that I could relate to my problem. Obviously,
though, this sort of thing must be done all the time in testbenches,
but I somehow haven't come across. I certainly don't want to manually
write out bus transaction without procedures.

Joe

Article: 69291
Subject: chipscope nuance question?
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Tue, 4 May 2004 23:44:04 -0400 (EDT)
Links: << >>  << T >>  << A >>
So i have been using chipscope for 4 months now and lately its been much
easier to use because when I want to select nets I get a full hiearchy to
look through.
but somethign changed in my design(i do not know wut) and now I no longer
get the nice hiearchy.  just a giant list of alphabetized nets.

How do i get the hiearchy back?

Thanks

Matt

Article: 69292
Subject: Wire crossing in a large partially reconfigurable design.
From: "Student" <student@nowhere.com>
Date: Wed, 5 May 2004 12:06:01 +0800
Links: << >>  << T >>  << A >>
Hi, there:

I am compiling a design which takes up 80% of the XC2V6000...After I put in
the
bus macros and run implementation, I found that there are a large number of
wire
crossings...For example, some VCC_FAKE_LEFT can route as long as three
slices
into the Right...vice versa...These wires just run into a switch boxes on
the opposite
side then flip back, but not connected to any slices I think...The same
phenomenon
never happened in my previous design which only uses 30% of the FPGA...

Is this acceptable for a partially reconfigurable design?

Best Regards,
Kelvin




Article: 69293
Subject: Max7000s: how to use the enable of the dffe flip-flop?
From: javodv@yahoo.es (javid)
Date: 5 May 2004 01:09:20 -0700
Links: << >>  << T >>  << A >>
Dear all,

I would like to register an address bus with the rising edge of the
clk and if the LOAD is '1'. Below is my VHDL code.

The problem is that when I analyse and elaborate with QII and see the
RTL view I see a mux that choose A_I or A_O with LOAD and the the
output of this mux goes to a dffe flip-flops (the output of this
flip-flops are feedback to the input of the mux). I would like to use
the enable input of the dffe flip-flops instead of the mux with the
LOAD. How to do this? is the RTL view related with what finally will
be placed and routed?.

Thanks a lot and best regards,

Javi


entity DIR_LATCH is
  
  port(  A_O:   out std_logic_vector ( 18 downto 2 );  
         LOAD:   in  std_logic;  
         CLK_I:   in  std_logic;  
         A_I:    in  std_logic_vector ( 18 downto 2)  
      );
		
end entity DIR_LATCH;


-------------------------------------------------------------------------------
-- Definicion de la Arquitectura
-------------------------------------------------------------------------------

architecture DIR_LATCH_A1 of DIR_LATCH is

begin

  -----------------------------------------------------------------------------
  -- Definicion de la Arquitectura
  -----------------------------------------------------------------------------

  ADR_REG: process ( CLK_I )
  begin

    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 2) <=
A_I( 2); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 3) <=
A_I( 3); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 4) <=
A_I( 4); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 5) <=
A_I( 5); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 6) <=
A_I( 6); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 7) <=
A_I( 7); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 8) <=
A_I( 8); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 9) <=
A_I( 9); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(10) <=
A_I(10); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(11) <=
A_I(11); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(12) <=
A_I(12); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(13) <=
A_I(13); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(14) <=
A_I(14); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(15) <=
A_I(15); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(16) <=
A_I(16); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(17) <=
A_I(17); end if; end if;
    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(18) <=
A_I(18); end if; end if;

  end process ADR_REG;

end architecture DIR_LATCH_A1;

Article: 69294
Subject: Re: EDK 3.2
From: Vinod <vinod@nospam.net>
Date: Wed, 05 May 2004 03:32:10 -0700
Links: << >>  << T >>  << A >>
whew! finally got it working. the problem was having both ISE and EDK
installed in the same directory. guess that was pretty stupid.
thanks a lot for your help, Paulo, Mathew and Frank.

vinod
On Tue, 04 May 2004 14:49:41 -0700, Vinod <vinod@nospam.net> wrote:

>yes, XILINX_EDK is before XILINX.
>Infact, both of them are installed in the same directory, ie C:\EDK.
>Is that a problem?
>
>Im wondering if any of these patches for windows XP are causing a
>problem.
>
>thanks
>vinod
>
>On Mon, 03 May 2004 09:42:42 -0700, Paulo Dutra
><paulo.dutra@xilinx.com> wrote:
>
>>Check your PATH environment. XILINX_EDK must before XILINX
>>
>>
>>Matthew Ouellette wrote:
>>> Vinod,
>>> 
>>> EDK 3.2 is compatible with 5.2 SP1 and greater only.  Check the Getting 
>>> Started Guide for more information.
>>> 
>>> Matt
>>> 
>>> Vinod wrote:
>>> 
>>>> Hi,
>>>> I am having problems starting up the Xilinx Platform Studio. I have
>>>> installed EDK 3.2 with service pack 2. When I run it, I get a message
>>>> saying
>>>>
>>>> "The procedure entry point
>>>> ?GetProjectToolBarID@Dco_PlToolBarManager@@SAIXZ could not be located
>>>> in the dynamic link library libDco_Plugin.dll"
>>>>
>>>> Im running Windows XP professional with SP1. Also have Xilinx ISE
>>>> 5.1.3i installed. My env variables seem to be pointing to the correct
>>>> location. I've tried reinstalling, but of no avail.
>>>>
>>>> Any help will be appreciated.
>>>>
>>>> Vinod


Article: 69295
Subject: Re: JTAG, Master Serial Mode
From: "Jamin" <jamin@zju.edu.cn>
Date: Wed, 5 May 2004 20:01:05 +0800
Links: << >>  << T >>  << A >>
jtag mode has the highest priority
"Symon" <symon_brewer@hotmail.com> дÈëÓʼþ
news:c6m0rm$dneba$1@ID-212844.news.uni-berlin.de...
> Xilinx went to great efforts to write it, so read the bloody datasheet!
> Quote:-
> "Configuration through the boundary-scan port is always available,
> independent of the mode selection. Selecting the Boundary-Scan mode simply
> turns off the other modes."
> Syms.
>
> "Chao" <c.chen@gmx.de> wrote in message
> news:8228a344.0404270556.23004f45@posting.google.com...
> > Hello,
> >
> > I have one general question concerning the FPGA supported
> > configuration mode. I am using Xilinx ISE iMpact to program Spartan-3.
> > I use the JTAG Cable-IV to download the bitstream to the Spartan-3.
> > Meanwhile I set up the configuration jumper on board to JTAG mode
> > (i.e. M0,M1,M2=0,1,0). That works fine. But if I set up the jumper to
> > MASTER-SERIAL (i.e. M0,M1,M2=1,1,1) mode, I can still download the
> > bitstream to the Spartan-3 via JTAG cable. I expected that I can
> > download the bitstream via JTAG cable only under JTAG mode jumper set
> > on board.  Does the jumper on board have nothing to do with the iMpact
> > "software" based configuration mode set?
> >
> > Thanks in advance for your explanation.
> >
> > Chao.
>
>



Article: 69296
Subject: Re: Max7000s: how to use the enable of the dffe flip-flop?
From: Marc Randolph <mrand@my-deja.com>
Date: Wed, 05 May 2004 07:15:17 -0500
Links: << >>  << T >>  << A >>
javid wrote:
> Dear all,
> 
> I would like to register an address bus with the rising edge of the
> clk and if the LOAD is '1'. Below is my VHDL code.
> 
> The problem is that when I analyse and elaborate with QII and see the
> RTL view I see a mux that choose A_I or A_O with LOAD and the the
> output of this mux goes to a dffe flip-flops (the output of this
> flip-flops are feedback to the input of the mux). I would like to use
> the enable input of the dffe flip-flops instead of the mux with the
> LOAD. How to do this? is the RTL view related with what finally will
> be placed and routed?.

Oh my that's alot of typing (and very prone to typos).  I believe the 
problem is that you have more than one controlling if statement within 
the process (in this case, more than one rising edge statement).  But 
the reality of the matter is that you only need one!


ADR_REG: process ( CLK_I )
begin

    if( rising_edge(CLK_I) ) then
       if( LOAD = '1' )
          A_O( 2) <= A_I( 2);
       end if;
       if( LOAD = '1' )
          A_O( 3) <= A_I( 3);
       end if;
....etc....
       if( LOAD = '1' )
          A_O(18) <= A_I(18);
       end if;
    end if;

end process ADR_REG;

But you'll notice the load's are all the same... so why not:

ADR_REG: process ( CLK_I )
begin

    if( rising_edge(CLK_I) ) then
       if( LOAD = '1' )
          A_O( 2) <= A_I( 2);
          A_O( 3) <= A_I( 3);
....etc....
          A_O(18) <= A_I(18);
       end if;
    end if;

end process ADR_REG;


But that's still WAY too much error-prone typing!  In reality, we should 
be using the vector form:


ADR_REG: process ( CLK_I )
begin

    if( rising_edge(CLK_I) ) then
       if( LOAD = '1' )
          A_O(18 downto 2) <= A_I(18 downto 2);
       end if;
    end if;

end process ADR_REG;


If you had a real reason to not use the vector form above, you could use 
a generate statement (this would allow you to optionally have a 
different clock enable for each bit, if you needed that for some reason):

adr_gen : for i in 2 to 18 GENERATE

ADR_REG: process ( CLK_I )
begin

    if( rising_edge(CLK_I) ) then
       if( LOAD = '1' )
          A_O(i) <= A_I(i);
       end if;
    end if;

end process ADR_REG;

end generate;



Good luck,

    Marc



> Thanks a lot and best regards,
> 
> Javi
> 
> 
> entity DIR_LATCH is
>   
>   port(  A_O:   out std_logic_vector ( 18 downto 2 );  
>          LOAD:   in  std_logic;  
>          CLK_I:   in  std_logic;  
>          A_I:    in  std_logic_vector ( 18 downto 2)  
>       );
> 		
> end entity DIR_LATCH;
> 
> 
> -------------------------------------------------------------------------------
> -- Definicion de la Arquitectura
> -------------------------------------------------------------------------------
> 
> architecture DIR_LATCH_A1 of DIR_LATCH is
> 
> begin
> 
>   -----------------------------------------------------------------------------
>   -- Definicion de la Arquitectura
>   -----------------------------------------------------------------------------
> 
>   ADR_REG: process ( CLK_I )
>   begin
> 
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 2) <=
> A_I( 2); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 3) <=
> A_I( 3); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 4) <=
> A_I( 4); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 5) <=
> A_I( 5); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 6) <=
> A_I( 6); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 7) <=
> A_I( 7); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 8) <=
> A_I( 8); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 9) <=
> A_I( 9); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(10) <=
> A_I(10); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(11) <=
> A_I(11); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(12) <=
> A_I(12); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(13) <=
> A_I(13); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(14) <=
> A_I(14); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(15) <=
> A_I(15); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(16) <=
> A_I(16); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(17) <=
> A_I(17); end if; end if;
>     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(18) <=
> A_I(18); end if; end if;
> 
>   end process ADR_REG;
> 
> end architecture DIR_LATCH_A1;

Article: 69297
Subject: ChipScope Core Generator Flow
From: Thomas Reinemann <thomas.reinemann@masch-bau.uni-magdeburg.de>
Date: Wed, 05 May 2004 15:41:05 +0200
Links: << >>  << T >>  << A >>
Hello,

I want to use the Xilinx Chipscope. As described I generated the 
controller and logic analyzer using the ChipScope Core Generator and 
than instantiated the icon and ila instances in my VHDL and synthesised 
it using Precision RTL. But the generated edif file does not contain any 
cell icon and ila. Therefore Chipscpoe logic isn't implemented and I 
can't use it.

What is my fault?

Regards

Thomas Reinemann

Article: 69298
Subject: XST, Virtex2-Pro, odd PAR counter timing failure
From: johnp3+nospam@probo.com (John Providenza)
Date: 5 May 2004 08:01:49 -0700
Links: << >>  << T >>  << A >>
I'm using XST for synthesis and I'm seeing an odd timing failure
from PAR with a 19 bit counter.  The counter code is:

  reg     [19:1]                  rd_addr;        // read port
  wire    [19:1]                  rd_addr_preload;

  // handle ram address counter
  assign rd_addr_preload = (repeat_done) ? next_wave_addr :
cur_wave_addr ;
  always @(posedge clk_mem)
    if (next_instr)
        rd_addr         <= rd_addr_preload ;
    else if (rd_req_i)
        rd_addr         <= rd_addr + 1'b1;

The signal "next_wave_addr" comes from the output of a block ram and
is used
to broadside load the counter.  Also note that "cur_wave_addr" could
load
the counter, but it's not in the critical path.

For some reason, PAR traces "next_wave_addr" though the carry chain as
a critical path.  This seems wrong. I'm scheptical that bit 4 of the
broadside load data should ripple into bit 18 of the counter.

Here's the PAR timing info:


Slack:                  -0.008ns
  Source:               Mram_program_inst_ramb_21.B (RAM)
  Destination:          rd_addr_73 (FF)
  Requirement:          5.999ns
  Data Path Delay:      5.894ns (Levels of Logic = 9)
  Clock Path Skew:      -0.113ns
  Source Clock:         clk_mem rising at 1.172ns
  Destination Clock:    clk_mem rising at 7.171ns
  Clock Uncertainty:    0.000ns

  Data Path: Mram_program_inst_ramb_21.B to upatgen/rd_addr_73
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    ------------------------------------------------- 
-------------------
    RAMB16_X5Y6.DOB1     Tbcko                 1.500  
Mram_program_inst_ramb_21
                                                      
Mram_program_inst_ramb_21.B
    SLICE_X36Y49.F2      net (fanout=2)        1.711   seq_rd_data<77>
    SLICE_X36Y49.X       Tilo                  0.288  
rd_addr_preload<4>
                                                      
Mmux_rd_addr_preload_Result<3>1
    SLICE_X34Y48.F3      net (fanout=1)        0.262  
rd_addr_preload<4>
    SLICE_X34Y48.COUT    Topcyf                0.744   rd_addr<4>
                                                      
rd_addr_inst_lut3_911
                                                      
rd_addr_inst_cy_125
                                                      
rd_addr_inst_cy_126
    SLICE_X34Y49.CIN     net (fanout=1)        0.000  
rd_addr_inst_cy_126
    SLICE_X34Y49.COUT    Tbyp                  0.083   rd_addr<6>
                                                      
rd_addr_inst_cy_127
                                                      
rd_addr_inst_cy_128
    SLICE_X34Y50.CIN     net (fanout=1)        0.000  
rd_addr_inst_cy_128
    SLICE_X34Y50.COUT    Tbyp                  0.083   rd_addr<8>
                                                      
rd_addr_inst_cy_129
                                                      
rd_addr_inst_cy_130
    SLICE_X34Y51.CIN     net (fanout=1)        0.000  
rd_addr_inst_cy_130
    SLICE_X34Y51.COUT    Tbyp                  0.083   rd_addr<10>
                                                      
rd_addr_inst_cy_131
                                                      
rd_addr_inst_cy_132
    SLICE_X34Y52.CIN     net (fanout=1)        0.000  
rd_addr_inst_cy_132
    SLICE_X34Y52.COUT    Tbyp                  0.083   rd_addr<12>
                                                      
rd_addr_inst_cy_133
                                                      
rd_addr_inst_cy_134
    SLICE_X34Y53.CIN     net (fanout=1)        0.000  
rd_addr_inst_cy_134
    SLICE_X34Y53.COUT    Tbyp                  0.083   rd_addr<14>
                                                      
rd_addr_inst_cy_135
                                                      
rd_addr_inst_cy_136
    SLICE_X34Y54.CIN     net (fanout=1)        0.000  
rd_addr_inst_cy_136
    SLICE_X34Y54.COUT    Tbyp                  0.083   rd_addr<16>
                                                      
rd_addr_inst_cy_137
                                                      
rd_addr_inst_cy_138
    SLICE_X34Y55.CIN     net (fanout=1)        0.000  
rd_addr_inst_cy_138
    SLICE_X34Y55.Y       Tciny                 0.891   rd_addr<18>
                                                      
rd_addr_inst_cy_139
                                                      
rd_addr_inst_sum_135
    SLICE_X34Y55.DY      net (fanout=1)        0.000  
rd_addr_inst_sum_135
    SLICE_X34Y55.CLK     Tdyck                 0.000   rd_addr<18>
                                                       rd_addr_73
    ------------------------------------------------- 
---------------------------
    Total                           5.894ns (3.921ns logic, 1.973ns
route)
                                            (66.5% logic, 33.5% route)

Any ideas?

Thanks!

John Providenza

Article: 69299
Subject: Re: chipscope nuance question?
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 5 May 2004 09:19:20 -0700
Links: << >>  << T >>  << A >>
Matthew,
Sounds like you've flattened the hierarchy somehow. Check the options for
the processes in Navigator. Or maybe your synthesis tool.
Chipscope is a wonderful thing. I haven't used a logic analyser for years.
And as the parts get faster, so does Chipscope. I use it to debug my home
brew soft processor. You can export the analysis results and I run a Perl
script to view the disassembly. Xilinx should do an integrated version for
MicroBlaze and PowerPC.
Cheers, Syms.





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search