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
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! -- glenArticle: 69276
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/fpgacourseArticle: 69277
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 ChristianArticle: 69278
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: 69279Hi, 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, adarshArticle: 69280
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!! GeorgeArticle: 69281
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
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
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"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.comArticle: 69285
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: 69286Hi 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. GuenterArticle: 69287
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. >>> >>> VinodArticle: 69288
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
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. -- glenArticle: 69290
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: 69291So 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 MattArticle: 69292
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, KelvinArticle: 69293
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: 69294whew! 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. >>>> >>>> VinodArticle: 69295
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
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: 69297Hello, 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 ReinemannArticle: 69298
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: 69299Matthew, 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:
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