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
Ray: I remember somewhere people use < I'Q - IQ' > / < I^2 + Q^2 > to demodulate (digitally). Do you mean that we can demodulate this signal with CORDIC to do the same operation, without these of multipliers, and divider? -- Best Regards, ----------------------------------------------------------------- Xu Qijun Engineer "Ray Andraka" <ray@andraka.com> wrote in message news:3D07E8CC.C67268F0@andraka.com... > First, you might get a copy of Marv Frerking's Digital SIgnal Processing > in COmmunications Systems text. It is very well written, and if you are > into digital radio, is worth more than you pay for it. The ARRL Radio > Amateur's handbook is also a useful reference. > > The resolution of converters is more or less inversely proportional to the > max sample frequency. You can get 8 bit converters at 1GHz or more. 12 > bits seems to top out at a just a bit over 100MHz (the AD9432 is a 105 MHz > 12 bit converter). If you want more bits, you get lower sampling rates. > > With a limited number of bits in RF capable converters, you wind up with a > very limited (wrt the entire spectrum) dynamic range. For a practical > radio, you'll need a fairly narrow filter to block out strong signals near > the desired signal. 12 bits isn't much to quantize the entier RF > spectrum. If you have an analog front end, you can do this by mixing to > an IF where you can filter the signal with a high Q analog filter before > digitizing it, which is what you are doing. > > We've got a demo application in process that puts a direct conversion > digital HAM radio in a SpartanII-100. The entire radio consists of an > antenna tuner/preamp, a burr-brown ADC demo board, and insight SpartanII > demo board with a pair of RC filters and a phone jack added to it, and a > pair of PC speakers. The spartan has in it all the tuning, filtering > decimation, demodulation and a PWM output. It will do AM, SSB, DSB, AM > stereo and CW demodulation, with plans for FM later. It makes for a > pretty cool demo, although it is not all that practical because of the > limited dynamic range of the 12 bit ADC. I am hoping to get it in a state > suitable for showing for the MAPLD conference in Laurel MD in September. > > FM needs a complex baseband in order to recover the phase. In a digital > radio, you can mix your real-only digitized IF with a complex sinusoid and > then decimate it to make your filtering a whole heck of a lot easier. One > of the advantages of digital IQ separation is that you don't have the > phase and matching sensitivities you have with an analog IQ stage. With a > 10 KHz BW, you can decimate to a couple times that (pick a sample rate > that makes your filter easier). Once it is filtered, then you need to > recover phase from that complex baseband signal. Phase recovery can be > done by a number of methods, a conceptually simple one being to use a > CORDIC rotator to pull out phase and magnitude. > > jaideep wrote: > > > Hi Newsgroup, > > > > In continuation to my earlier post with the same subject, I would > > appreciate very much, if someone can provide me with the following > > answer: what is highest frequency analog signal that I can sample with > > the currently available data converters. I am considering 2 sampling > > rates; one Nyquist and the other 4x upsampling. > > > > Thanks to Noddy for providing the information. I forgot to mention > > that the IF signal (10.7 MHz +/- 125 KHz) contains FM data around > > another subcarrier located 70KHz from the center of 10.7 MHz. The FM > > data BW is 10 KHz around this subcarrier. Therefore I guess we need to > > have a very sharp BPF centered at 70 KHz with a BW of 10KHz.Invite any > > suggestion/discussion on this subject and also as how to implement > > this in FPGA. > > > > Thanks in advance. > > > > Jaideep Bose > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 44176
I am working with a XCV800 and I want to perform a Readback-Capture of the contents of the FPGA. It seems (I am not sure) that it is necessary to use the Xilinx MultiLINX cable to perform this operation, but it is no software available that supports this operation. Anyone can tell me if there is any commercial software to perform a readback-capture and which hardware I need to use? Please, reply to this address: ddandres@disca.upv.es Thank you very much.best regards, David de Andrés.Article: 44177
Hi all,
I am running WebPack 4.1, using the included ModelSim 5.5b starter
version.
The design is written in VHDL.
Given a signal (D) sourced by a VHDL-coded flipflop, running into
a Xilinx "FD" primitive, clocked from the same clock as the data,
I find the FD's output goes to X for one clock, whenever it changes
state.
The signals below (use a monospaced font) are ModelSim's wave trace
of the signals *within* the FD block (as far as one can trace it).
Q 1 1 1 1 1 X X X X X 0 0 0 0 0
D 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
C 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0
D_IPD 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
C_IPD 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0
The rest of the design runs as expected: it's just the FD blocks seem
to do this, whenever they change state. The fact that the data changes
at the same clock edge is irrelevant: the same effect is observed if
the data is stable, but opposite state to the FD itself.
The FD instantiation runs thus:-
LIBRARY ieee ;
USE ieee.std_logic_1164.all;
-- synopsys translate_off
library unisim;
use unisim.vcomponents.all; -- Call in the Xilinx prims.
-- synopsys translate_on
Entity...
Architecture...
component FD -- Xilinx primitive
port(D : in std_logic;
C : in std_logic;
Q : out std_logic);
end component;
begin
...
Any ideas?
TIA
Article: 44178
On Thu, 13 Jun 2002 18:06:19 +0800, David R Brooks
<daveb@iinet.net.au> wrote:
>Hi all,
> I am running WebPack 4.1, using the included ModelSim 5.5b starter
>version.
>
> The design is written in VHDL.
>
> Given a signal (D) sourced by a VHDL-coded flipflop, running into
>a Xilinx "FD" primitive, clocked from the same clock as the data,
>I find the FD's output goes to X for one clock, whenever it changes
>state.
> The signals below (use a monospaced font) are ModelSim's wave trace
>of the signals *within* the FD block (as far as one can trace it).
>
>Q 1 1 1 1 1 X X X X X 0 0 0 0 0
>D 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
>C 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0
>D_IPD 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
>C_IPD 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0
You've violated the timing on the FD (D changed at the same time as
the clock), and it has decided to produce an 'X' to indicate this.
*We know* you are doing a functional simulation without timing, but
modelsim doesn't. You just have to convince it that this is the case.
Try the following:
1. Reduce modelsim's timing resolution to 1ns, which has the side
effect of making all the FD delays (which are < 1ns) equivalent to
0ns. This is ugly, but it works.
The command line is:
vsim -t ns ...
2. Run modelsim with the +notimingchecks option, which disables
Verilog and VITAL timing checks.
The command line is:
vsim +notimingchecks ...
3. Set the generic TimingChecksOn to FALSE when you instantiate the
FD. You will need to put in pragmas to stop the synthesiser from
seeing the generics:
ff : FD
-- synopsys translate_off
generic map (
TimingChecksOn => FALSE
)
-- synopsys translate_on
port map (
....
There is no standard pragma that works in all tools. You will need to
read the documentation for your synthesis tool.
BTW, this issue applies to almost all the UNISIM components. The same
fixes apply.
I hope this helps.
Regards,
Allan.
Article: 44179
Depends on how agile you need it. A wide band Analog LO has its problems too,
as does component matching for the I and Q channels. One thing youcan do to
make the LO easier is to generate a quadrature LO digitally, send that out
through DACs to do the complex mix in analog. The advantage there is you can
then do an analog BPF on the I and Q which significantly reduces the
requirements for the ADC. Still, doing the complex mix on the digital side gets
you the best IQ matching and perfect quadrature.
Noddy wrote:
> This is definately an easier way to go, and happens to be the same method I
> am using for radio astronomical applications. Although, I use an analogue
> complex mixer to mix down from IF. This eases up on power usage and timing
> issues considerably. Try use the AD6121 which has a nice 92 dB gain control.
> This should be easier than sampling at IF and then mixing down to get I/Q
> signals.
>
> adrian
>
> > The Hilbert transform will leave you a hole at DC if you are doing single
> conversion,
> > and can make for a complicated filter. FOr digital IQ separation, you are
> better off
> > using a complex mixer and then low pass filtering the I and Q outputs.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44180
We are still refining it, but we did run into lots of problems with 12 bits not
being enough for quantizing the RF spectrum. That is addressed to some degree
with a narrowband tunable filter on the input (we're currently playing with one
of those tunable antenna preamps, although it doesn't really give enough gain or
a narrow enough BPF to be really practical for Ham radio. Like I said, this was
originally intended as more of a demo than anything else. The ADC is AC
coupled, so there isn't a DC issue at its input. In the digital section however
you can get a DC offset which can cause problems. All the usual cautions with
direct conversion apply.
Bevan Weiss wrote:
> With the direct conversion radio you have designed...
>
> What kind of problems did you run into with DC offsets?
> Any problems with the DC causing swamping of the ADC range?
>
> I'm currently trying to implement one as a project for polytech. I haven't
> reached hardware yet, as I'm a little worried that all I'll end up with is a
> maxed out ADC.
> The current design has got a DDS as the LO, using quadrature outputs into
> two active mixers, to produce a baseband signal. +30dB LNA from analog
> devices as the frontend, with a 120MHz low pass filter just before it, to
> reduce the bandwidth a little...
> Further amplification after mixing, just before the ADC's to optimize the
> ADC's resolution. No point having a 16bit ADC and only really using 8bit of
> it...
>
> Any possible problems that I should be warned about??
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3D07E8CC.C67268F0@andraka.com...
> > First, you might get a copy of Marv Frerking's Digital SIgnal Processing
> > in COmmunications Systems text. It is very well written, and if you are
> > into digital radio, is worth more than you pay for it. The ARRL Radio
> > Amateur's handbook is also a useful reference.
> >
> > The resolution of converters is more or less inversely proportional to the
> > max sample frequency. You can get 8 bit converters at 1GHz or more. 12
> > bits seems to top out at a just a bit over 100MHz (the AD9432 is a 105 MHz
> > 12 bit converter). If you want more bits, you get lower sampling rates.
> >
> > With a limited number of bits in RF capable converters, you wind up with a
> > very limited (wrt the entire spectrum) dynamic range. For a practical
> > radio, you'll need a fairly narrow filter to block out strong signals near
> > the desired signal. 12 bits isn't much to quantize the entier RF
> > spectrum. If you have an analog front end, you can do this by mixing to
> > an IF where you can filter the signal with a high Q analog filter before
> > digitizing it, which is what you are doing.
> >
> > We've got a demo application in process that puts a direct conversion
> > digital HAM radio in a SpartanII-100. The entire radio consists of an
> > antenna tuner/preamp, a burr-brown ADC demo board, and insight SpartanII
> > demo board with a pair of RC filters and a phone jack added to it, and a
> > pair of PC speakers. The spartan has in it all the tuning, filtering
> > decimation, demodulation and a PWM output. It will do AM, SSB, DSB, AM
> > stereo and CW demodulation, with plans for FM later. It makes for a
> > pretty cool demo, although it is not all that practical because of the
> > limited dynamic range of the 12 bit ADC. I am hoping to get it in a state
> > suitable for showing for the MAPLD conference in Laurel MD in September.
> >
> > FM needs a complex baseband in order to recover the phase. In a digital
> > radio, you can mix your real-only digitized IF with a complex sinusoid and
> > then decimate it to make your filtering a whole heck of a lot easier. One
> > of the advantages of digital IQ separation is that you don't have the
> > phase and matching sensitivities you have with an analog IQ stage. With a
> > 10 KHz BW, you can decimate to a couple times that (pick a sample rate
> > that makes your filter easier). Once it is filtered, then you need to
> > recover phase from that complex baseband signal. Phase recovery can be
> > done by a number of methods, a conceptually simple one being to use a
> > CORDIC rotator to pull out phase and magnitude.
> >
> > jaideep wrote:
> >
> > > Hi Newsgroup,
> > >
> > > In continuation to my earlier post with the same subject, I would
> > > appreciate very much, if someone can provide me with the following
> > > answer: what is highest frequency analog signal that I can sample with
> > > the currently available data converters. I am considering 2 sampling
> > > rates; one Nyquist and the other 4x upsampling.
> > >
> > > Thanks to Noddy for providing the information. I forgot to mention
> > > that the IF signal (10.7 MHz +/- 125 KHz) contains FM data around
> > > another subcarrier located 70KHz from the center of 10.7 MHz. The FM
> > > data BW is 10 KHz around this subcarrier. Therefore I guess we need to
> > > have a very sharp BPF centered at 70 KHz with a BW of 10KHz.Invite any
> > > suggestion/discussion on this subject and also as how to implement
> > > this in FPGA.
> > >
> > > Thanks in advance.
> > >
> > > Jaideep Bose
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44181
The ADC max clock spec. Right now I'm sampling at 40 MHz because that was the
clock oscillator I had handy. The BB ADC I am using is a 55MS/Sec converter so
there is not too much room for improvement there. I could go to an AD9432 to
get up to 100MS/sec, but I couldn't get one on an eval board (they are also
about 3x the cost of the BB device).
Noddy wrote:
> > It makes for a
> > pretty cool demo, although it is not all that practical because of the
> > limited dynamic range of the 12 bit ADC. I am hoping to get it in a state
> > suitable for showing for the MAPLD conference in Laurel MD in September.
>
> What's to stop you from oversampling? Will increase your dynamic range by
> sqrt(N).
>
> adrian
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44182
Yes. Note that if you limit I and Q first, then there is no divide...of course
the limiting has to be to the unit circle, so it probably will involve CORDIC
anyway. The equation below essentially arrives at the arctan through the
backdoor. CORDIC computes the arctan directly, so it replaces the derivative
approach. It also avoids the problems the derivative approach has with
imperfect differentiators and the delay imparted by the differentiator.
XU QIJUN wrote:
> Ray:
>
> I remember somewhere people use < I'Q - IQ' > / < I^2 + Q^2 > to demodulate
> (digitally). Do you mean that we can demodulate
> this signal with CORDIC to do the same operation, without these of
> multipliers, and divider?
>
> --
> Best Regards,
> -----------------------------------------------------------------
> Xu Qijun
> Engineer
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3D07E8CC.C67268F0@andraka.com...
> > First, you might get a copy of Marv Frerking's Digital SIgnal Processing
> > in COmmunications Systems text. It is very well written, and if you are
> > into digital radio, is worth more than you pay for it. The ARRL Radio
> > Amateur's handbook is also a useful reference.
> >
> > The resolution of converters is more or less inversely proportional to the
> > max sample frequency. You can get 8 bit converters at 1GHz or more. 12
> > bits seems to top out at a just a bit over 100MHz (the AD9432 is a 105 MHz
> > 12 bit converter). If you want more bits, you get lower sampling rates.
> >
> > With a limited number of bits in RF capable converters, you wind up with a
> > very limited (wrt the entire spectrum) dynamic range. For a practical
> > radio, you'll need a fairly narrow filter to block out strong signals near
> > the desired signal. 12 bits isn't much to quantize the entier RF
> > spectrum. If you have an analog front end, you can do this by mixing to
> > an IF where you can filter the signal with a high Q analog filter before
> > digitizing it, which is what you are doing.
> >
> > We've got a demo application in process that puts a direct conversion
> > digital HAM radio in a SpartanII-100. The entire radio consists of an
> > antenna tuner/preamp, a burr-brown ADC demo board, and insight SpartanII
> > demo board with a pair of RC filters and a phone jack added to it, and a
> > pair of PC speakers. The spartan has in it all the tuning, filtering
> > decimation, demodulation and a PWM output. It will do AM, SSB, DSB, AM
> > stereo and CW demodulation, with plans for FM later. It makes for a
> > pretty cool demo, although it is not all that practical because of the
> > limited dynamic range of the 12 bit ADC. I am hoping to get it in a state
> > suitable for showing for the MAPLD conference in Laurel MD in September.
> >
> > FM needs a complex baseband in order to recover the phase. In a digital
> > radio, you can mix your real-only digitized IF with a complex sinusoid and
> > then decimate it to make your filtering a whole heck of a lot easier. One
> > of the advantages of digital IQ separation is that you don't have the
> > phase and matching sensitivities you have with an analog IQ stage. With a
> > 10 KHz BW, you can decimate to a couple times that (pick a sample rate
> > that makes your filter easier). Once it is filtered, then you need to
> > recover phase from that complex baseband signal. Phase recovery can be
> > done by a number of methods, a conceptually simple one being to use a
> > CORDIC rotator to pull out phase and magnitude.
> >
> > jaideep wrote:
> >
> > > Hi Newsgroup,
> > >
> > > In continuation to my earlier post with the same subject, I would
> > > appreciate very much, if someone can provide me with the following
> > > answer: what is highest frequency analog signal that I can sample with
> > > the currently available data converters. I am considering 2 sampling
> > > rates; one Nyquist and the other 4x upsampling.
> > >
> > > Thanks to Noddy for providing the information. I forgot to mention
> > > that the IF signal (10.7 MHz +/- 125 KHz) contains FM data around
> > > another subcarrier located 70KHz from the center of 10.7 MHz. The FM
> > > data BW is 10 KHz around this subcarrier. Therefore I guess we need to
> > > have a very sharp BPF centered at 70 KHz with a BW of 10KHz.Invite any
> > > suggestion/discussion on this subject and also as how to implement
> > > this in FPGA.
> > >
> > > Thanks in advance.
> > >
> > > Jaideep Bose
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44183
The unisims have timing built into them (why xilinx did that for a
functional sim library is beyond me), which you need to disable or timing
will be violated in the simulation when connected with RTL logic. To do
that, set the TimingChecksOn generic on the component to false as I have
done in your code sample below. Also, it appears you may have the
simulator resolution set too high (which will be a problem if you are
using the DLL). use vsim -t 10ps to set the resolution to 10 ps.
David R Brooks wrote:
> Hi all,
> I am running WebPack 4.1, using the included ModelSim 5.5b starter
> version.
>
> The design is written in VHDL.
>
> Given a signal (D) sourced by a VHDL-coded flipflop, running into
> a Xilinx "FD" primitive, clocked from the same clock as the data,
> I find the FD's output goes to X for one clock, whenever it changes
> state.
> The signals below (use a monospaced font) are ModelSim's wave trace
> of the signals *within* the FD block (as far as one can trace it).
>
> Q 1 1 1 1 1 X X X X X 0 0 0 0 0
> D 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
> C 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0
> D_IPD 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
> C_IPD 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0
>
> The rest of the design runs as expected: it's just the FD blocks seem
> to do this, whenever they change state. The fact that the data changes
> at the same clock edge is irrelevant: the same effect is observed if
> the data is stable, but opposite state to the FD itself.
>
> The FD instantiation runs thus:-
>
> LIBRARY ieee ;
> USE ieee.std_logic_1164.all;
> -- synopsys translate_off
> library unisim;
> use unisim.vcomponents.all; -- Call in the Xilinx prims.
> -- synopsys translate_on
>
> Entity...
> Architecture...
>
> component FD -- Xilinx primitive
-- syn_translate_off
generic map ( TimingChecksOn => FALSE)
-- syn_translate_on
>
> port(D : in std_logic;
> C : in std_logic;
> Q : out std_logic);
> end component;
>
> begin
> ...
>
> Any ideas?
> TIA
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44184Background: Xilinx ISE, VHDL, VirtexII I am trying do something that should be simple. I have one clock line feeding 3 filter sections. I need the first two filter sections routed to a 10 ns period spec. The last filter section only needs to route to 20 ns(it's shut down when operating at fastest rate). I thought I could just get by using by renaming the clock into the third section, i.e. Slo_Clk <= Clk; First two sections use Clk and the last section uses Slo_Clk. My .ucf is set up to constrain Clk to 10ns and Slo_Clk to 20ns. The design compiles and PARs fine. The timing analysis, however, only shows the request/actual times for Slo_Clk so I have no way of knowing whether the fast clock really works to 10 ns. Should I assume because no timing errors were reported that the 10ns spec was met? Is it possible that the PAR used 20 ns for both Clk and Slo_Clk? Any suggestions for a better way to do this? Thanks, Clark PopeArticle: 44185
"Peter Alfke" <Peter.Alfke@xilinx.com> wrote : > The flip-flops in Virtex-II are very fast, but the feedback from > Q to D is very general, and thus relatively slow, so the loop has > a delay of just around one ns, which means 1 GHz is barely possible. 1 GHz is about 20% faster than possible according to the minimum pulse width requirements for a CLB clock listed in table 21 of this document: http://www.xilinx.com/partinfo/ds031-3.pdf So 820 MHz appears to be the fastest counter that's within the Xilinx spec. I don't doubt that 1 GHz is possible but is it reliable over normal process variations? Is it safe for me to ship? Paul.Butler@ni.comArticle: 44186
John_H wrote: > > I recently discovered the Xilinx LOC constraint can apply to a group of > signals. I ended up specifying all the pads in a single IOB group as my > LOC groups to help me keep track of which signals are on which rows. > The group capability was a nice discovery. > Thanks. Does this work with the WebPack software? Kind regards, IwoArticle: 44187
Jay wrote: > > You could constrain (locate) all pins (including unused ones) except > the largest group of pins that are interchangeable, then let the > placer have at it. I personally don't think that I/O is going to have > that much effect on a large FPGA though, especially if you register > your outputs. > Neat idea! This will certainly improve things, although I'd prefer to let the fitter do it with all memory busses simultaneously. I'm using a 256 cell Coolrunner at the moment, about 99% full. Not exactly large... In this particular design, swapping the order of one bus was needed to make it fit. Kind regards, IwoArticle: 44188
Hi, when you run a mppr, it makes a new directory in your project folder /mppr_result_dir/ make sure you dont have read only, or some other limitation set there -- Benjamin Todd European Organisation for Nuclear Research SL SPS/LHC -- Control -- Timing Division CERN, Geneva, Switzerland, CH-1211 Building 864 Room 1 - A24 "Jim Raynor" <chris_cheung66@hotmail.com> wrote in message news:RUtN8.9254$Aa4.512552@news0.telusplanet.net... > hi, > > When I use the Xilinx Foundation Multi-pass PAR, it always search for > the non-existing directory mppr_result.dir/*.*_0_0_0 and it says Error: > Unable to open directory...blah blah blah.... > > Does anyone know how to fix that problem? > > Thanks > > >Article: 44189
The redefinition was "module MUXCYdammit(...) /* synthesis syn_hier="hard" */;" with the MUXCY stated inside. The black box approach is an interesting fallback. Thanks for the suggestion! Brian Davis wrote: > John_H wrote: > > > >I tried a MUXCY primitive redefinition (I called it MUXCYdammit) with > >syn_hier="hard" like I did earlier with an FDRE but if you push down > >into the instance in HDL_Analyst, there's a pass-LUT on the sel input. > > > > By "redefinition", do you mean: > > A) put a MUXCYdammit wrapper with syn_hier="hard" around a MUXCY > > or, > > B) black box something called MUXCYdammit and edit the EDIF > post-synthesis to fix up the primitive names > > I think "B" is fairly bulletproof, but you need a search-and-replace > to fix up the EDIF names, and a wrappered simulation library to let you > sim the primitives that have the tiny brown paper bags over their heads. > > Brian > > John_H <johnhandwork@mail.com> wrote in message news:<3D07B0CB.F77B1634@mail.com>... > > I'm having MUXCY trimming problems *right now*. I tried to take my 29 MUXCY > > instantiations and convert them into an array of instances. Yuck! The physical > > implementation of my chain became toast once Synplify started "optimizing" the pass > > elements out of the chain (I have several in the middle). > > > > The inclusion of oh-so-many LUT1_2 elements is getting at my nerves as well: I > > tried a MUXCY primitive redefinition (I called it MUXCYdammit) with syn_hier="hard" > > like I did earlier with an FDRE but if you push down into the instance in > > HDL_Analyst, there's a pass-LUT on the sel input. Once again Synplify knows > > better. Oy. > > > > The apps engineers are looking at my chain, but I imagine it's back to the 29 > > individual instances. I hope those aren't broken! > > > > - John_H > > > >Article: 44190
I "hadn't" had many problems with MUXCYs either. 7.1 is messing me up. With a syn_keep on the LUT outputs, Synplify is adding a LUT1_2 (through-wire) between the keepbuf and the MUXCY select. Since the Xilinx P&R tools don't expect such superfluous slop, it dutifully implements the LUT1_2 with the MUXCY and the LUT that *should* drive it ends up in the adjacent LUT, out through .Y and back in through .BX - yeesh. Ray Andraka wrote: > I haven't had too much trouble with the MUXCY's if I put syn_keeps on the LUT output > driving the select. > > Brian Davis wrote: > > > John_H wrote: > > > > > >I tried a MUXCY primitive redefinition (I called it MUXCYdammit) with > > >syn_hier="hard" like I did earlier with an FDRE but if you push down > > >into the instance in HDL_Analyst, there's a pass-LUT on the sel input. > > > > > > > By "redefinition", do you mean: > > > > A) put a MUXCYdammit wrapper with syn_hier="hard" around a MUXCY > > > > or, > > > > B) black box something called MUXCYdammit and edit the EDIF > > post-synthesis to fix up the primitive names > > > > I think "B" is fairly bulletproof, but you need a search-and-replace > > to fix up the EDIF names, and a wrappered simulation library to let you > > sim the primitives that have the tiny brown paper bags over their heads. > > > > Brian > > > > John_H <johnhandwork@mail.com> wrote in message news:<3D07B0CB.F77B1634@mail.com>... > > > I'm having MUXCY trimming problems *right now*. I tried to take my 29 MUXCY > > > instantiations and convert them into an array of instances. Yuck! The physical > > > implementation of my chain became toast once Synplify started "optimizing" the pass > > > elements out of the chain (I have several in the middle). > > > > > > The inclusion of oh-so-many LUT1_2 elements is getting at my nerves as well: I > > > tried a MUXCY primitive redefinition (I called it MUXCYdammit) with syn_hier="hard" > > > like I did earlier with an FDRE but if you push down into the instance in > > > HDL_Analyst, there's a pass-LUT on the sel input. Once again Synplify knows > > > better. Oy. > > > > > > The apps engineers are looking at my chain, but I imagine it's back to the 29 > > > individual instances. I hope those aren't broken! > > > > > > - John_H > > > > > > > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 44191
WebPack should allow the user to specify User Constraints like all the rest of the Xilinx tools. Check the Xilinx online software manual's Constraints Guide for syntax of the LOC constraint. I read about it there. Iwo Mergler wrote: > John_H wrote: > > > > I recently discovered the Xilinx LOC constraint can apply to a group of > > signals. I ended up specifying all the pads in a single IOB group as my > > LOC groups to help me keep track of which signals are on which rows. > > The group capability was a nice discovery. > > > > Thanks. Does this work with the WebPack software? > > Kind regards, > > IwoArticle: 44192
I don't mean to be argumentative, but I might not understand what you are saying. John_H wrote: > > For minimum "impedance at the frequency of interest," the SRF *is* what we care > about (along with the equivalent series resistance). If you use a cap with a > higher SRF, the impedance will be higher than you could otherwise achieve. If you > use a cap with a lower SRF you are - once again - losing out on the impedance > because of the inductive effect. You make it sound like you are trying to create a low impedance at a single frequency. All of my experience has indicated that you need to handle noise at a wide range of frequencies above the clock rate(s). So trying to place the narrow SRF at a single point is of little or no value. Further, the fact that a cap is inductive at a given frequency is not an issue. The impedance can still be quite low and in fact you will want to put the SRF near the middle of the frequency range you need to silence. So half the work will be done in the range where the cap is inductive. > The different packages tend to allow either > deeper curves (lower impedance across the frequency range around the SRF) and/or > wider "bottoms" where the impedance is comfortably low. Again this sounds like you are targeting the SRF to a narrow freq range. How do you determine where to put the SRF and how do you pick your caps to match that. Further, if you are trying to match the SRF to the design, how do you accomodate the parasitic inductance and capacitance. Won't that throw off the SRF? > We could just add capacitors until there's no more room on our boards and the > paralleled impedances at the frequency of interest might be near where we want > them. A judicious choice of caps "near" the chip (1/10 wavelength for the > frequency of interest, perhaps) - not for each power/ground pin pair - might be a > best fit. Might. Plane inductances to the caps and to the devices do play a > part. You can put your caps near the "chip" if you are just trying to lower the impedance of the ground/power planes. But if you are addressing the needs of the chip, then you should keep the caps near the power/ground pins. If I remember correctly, the issue is the area of the loop including the cap, the traces, the chip leads and the power distribution on the chip which determines the inductance of the connection to the cap. > It really is voodoo. If you say that again, I'll tell Dr. Howard Johnson on you. Howard Johnson, Howard Johnson, Howard Johnson! There, now look out! > rickman wrote: > > > I know the > > argument that the smaller caps have a higher self resonant frequency > > (SRF), but that does not hold water. The SRF is higher, but the SRF is > > not what we care about. The important spec is the impedance at the > > frequency of interest. If you go to the cap manufacturer's web site and > > download the docs, you will see that the impedance curves for different > > value caps are nearly identical at the frequencies of interest. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 44193
Hellom is there any compatibility issue between the Foundation 3.1 and Foundation 4.1. I use schematic entry thanks -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 44194
Hello,
I know both .edf and .edn come from synthesis step, and it seems
they are different, then what's the different?
thanks,
Article: 44195The thing to keep in mind when using FPGAs is that while the HDL may let you describe all kinds of crazy clocking schemes, only a few of the most basic ones will work reliably in the FPGA itself. If your design is constrained to Vertex, then just use those rams in their dual-port mode, this is the clean way to achieve 2 accesses per clock. If you're accessing the exact same location, consider time multiplexing, that is to say, double your clock, and twice the operations. John Williams <j2.williams@qut.edu.au> wrote in message news:<3D081A8E.82F3A57B@qut.edu.au>... > Peter Alfke wrote: > > > > Are you reading and writing the same location? > > Virtex-II does that for free, with one clock edge ( read the old, then > > write the new data value, if you wish) > > Yes, I am doing that, (read, update, write) however for now I am > constrained to target a Virtex. > > Out of interest though, what is the VHDL template to do this dual > read/write on a single clock edge? > > Regards, > > JohnArticle: 44196
Using the I/O flops is a nice way to get predictable consistent timing out of a generally unpredictable (delay) FPGA. If you need to make sure that your write strobe come after the address/data lines, you can make those lines high drive and the write strobe low drive, stuff like that... Lasse Langwadt Christensen <langwadt@ieee.org> wrote in message news:<3D0770B5.C70CA400@ieee.org>... > Hi, > > What is the smart way to constrain something like an interface to > external async. ram ? (reading only) > > I guess I could setup a timespec from FF's to address pads and from > data pads to FF's have the two time specs plus the ram access time > be equal to my desired clk period. > > But, as fas as I can tell that means I'd have to have a pretty good > guess on how the delays are distributed before and after the ram. > > Is there way that i can constrain it all in one go? , > because I really don't care how the FF's to address pads and > data pads to FF's delays are, as long as I can get all the way > within my period, less the ram access time. > > thanks, > > -LasseArticle: 44197
There's so many aspects to "clean decoupling design" that it's hard to communicate well what I do understand. I communicate what I don't understand even worse ;-) rickman wrote: > I don't mean to be argumentative, but I might not understand what you > are saying. The conversation is good, no negatives seen from my end. > John_H wrote: > > > > For minimum "impedance at the frequency of interest," the SRF *is* what we care > > about (along with the equivalent series resistance). If you use a cap with a > > higher SRF, the impedance will be higher than you could otherwise achieve. If you > > use a cap with a lower SRF you are - once again - losing out on the impedance > > because of the inductive effect. > > You make it sound like you are trying to create a low impedance at a > single frequency. All of my experience has indicated that you need to > handle noise at a wide range of frequencies above the clock rate(s). So > trying to place the narrow SRF at a single point is of little or no > value. Further, the fact that a cap is inductive at a given frequency > is not an issue. The impedance can still be quite low and in fact you > will want to put the SRF near the middle of the frequency range you need > to silence. So half the work will be done in the range where the cap is > inductive. The wide range of frequencies is, indeed, very important. I had kept close to my engineering heart the "truth" that more capacitance is most often a good thing, that low capacitance values were silly. If I throw together a dozen 1uF ceramic caps, I end up with a nice low impedance at the SRF but not so very low a decade or two above or below. One graph I'm looking at shows an SRF of about 7MHz for a 1uF 1206. The impedance at 7MHz is about 0.1 Ohm each. The impedance drops to 1ohm around 250kHz and 150MHz. While these values aren't bad, consider the current demands for 150MHz: 1/12 Ohm (12 1uF caps in parallel, ignoring other parasitics for the moment) will keep the voltage tolerance within 100mV for 1.2A surges. Maybe this is sufficient, but one cap with an SRF around 150MHz would give you performance nearly as good at 150MHz. The 7MHz filtering in the 12 cap configuration above is probably significant overkill at 8.3 milliOhm. A mix would allow a low overall impedance floor without overkill. > > The different packages tend to allow either > > deeper curves (lower impedance across the frequency range around the SRF) and/or > > wider "bottoms" where the impedance is comfortably low. > > Again this sounds like you are targeting the SRF to a narrow freq > range. How do you determine where to put the SRF and how do you pick > your caps to match that. Further, if you are trying to match the SRF to > the design, how do you accomodate the parasitic inductance and > capacitance. Won't that throw off the SRF? The parasitic inductance will throw the numbers off. It won't throw them off by much if the cap is within a fraction of a "wavelength of interest" on a good plane and the caps and power/ground pins have good connections to the planes. The "swiss cheese effect" of getting power to the center pins of a BGA with its array of holes has been shown to be manageable - it doesn't throw too much extra inductance into the situation at realiztic frequencies. The caps need to be selected with a nice "spread" across the frequencies you're working with. An SRF at 1MHz and another at 100MHz will actually give you problems - a resonance - at 10MHz, reducing the effects of even the one type of capacitor. If the SRF values are kept somewhat close, the resonance shouldn't be a big issue (evaluate "somewhat?" I don't have a good value to suggest, but a decade is well beyond what I'd like to use). My clock frequency is a major design consideration. The clocks have harmonics and the data gives a spread below that frequency as well. Since bulk caps contribute to the lower frequency end, I'd concentrate on frequencies at the clock and above for solid selection. > > We could just add capacitors until there's no more room on our boards and the > > paralleled impedances at the frequency of interest might be near where we want > > them. A judicious choice of caps "near" the chip (1/10 wavelength for the > > frequency of interest, perhaps) - not for each power/ground pin pair - might be a > > best fit. Might. Plane inductances to the caps and to the devices do play a > > part. > > You can put your caps near the "chip" if you are just trying to lower > the impedance of the ground/power planes. But if you are addressing the > needs of the chip, then you should keep the caps near the power/ground > pins. If I remember correctly, the issue is the area of the loop > including the cap, the traces, the chip leads and the power distribution > on the chip which determines the inductance of the connection to the > cap. The chip needs very low impedance to ground. If you can't mount your cap on the same side of the board as the chip, you have to go through a via anyway, encountering loop inductance. If you can mount the cap on the same side of the board but have to use more track to connect, the narrow line gives you loop inductance. When you have the cap and the pins both connected to a plane - even the swiss cheese - the inductance is manageable. One cap per power/ground pin pair isn't helping out much except for paralleling the impedances. > > It really is voodoo. > > If you say that again, I'll tell Dr. Howard Johnson on you. Howard > Johnson, Howard Johnson, Howard Johnson! There, now look out! :-X > > rickman wrote: > > > > > I know the > > > argument that the smaller caps have a higher self resonant frequency > > > (SRF), but that does not hold water. The SRF is higher, but the SRF is > > > not what we care about. The important spec is the impedance at the > > > frequency of interest. If you go to the cap manufacturer's web site and > > > download the docs, you will see that the impedance curves for different > > > value caps are nearly identical at the frequencies of interest. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 44198
In article <aeao2h$5bfsh$1@ID-84877.news.dfncis.de>, Falk Brunner <Falk.Brunner@gmx.de> wrote: >"Roger King" <roger@king.com> schrieb im Newsbeitrag >news:lRvN8.287033$t8_.195817@news01.bloor.is.net.cable.rogers.com... >> I don't have the info, but what about the XC2S50 chip/family? > >XC2S50 is a Spartan-II, 50k gates (whatever gates means . .;-) > >It has also 6 BlockRams, 4kbit each. > >> and is that a good number? > >XC2S50 is a nice chip to start with. But as others already said, go for a >200K or 300K gates device, they cost not much more (together with a >demoboad). >Also remember, the bigger the device, the cheaper the logic funktions >($/LUT), with some minor exceptions. Actually, it's seems to be more of a bathtub curve: Small parts are package dominated, therefore more expensive per lut. Very large parts are yeild dominated, therefore more expensive per lut. It is teh ones in the small middle (eg, the larger Spartan II parts) which are cheapest per lut, as tehy are small enough to have very very good yeild, but large enough to not just be entirely packaging costs. But the small, "cheap" parts are very impressive these days. You can almost put a synthesised, 32 bit sparc on a SII 300. You can easily do >1 GB AES on a SII 100. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 44199
"Peter Brenner" <i_wok@hotmail.com> schrieb im Newsbeitrag news:b337f814.0206121627.2902d6b9@posting.google.com... > > What package type/dimensions ? Is BGA ok ? > > Correction to : > BGA is fine. We have room for a 3mm * 3mm device, although we only > need substantially less resources than typically contained in such a > device. > > - sorry, meant to be: 30mm * 30mm Have a look at the Coolrunner-II from Xilinx. They look pretty fast. The size should be no problem (30x30 can hold a 600++ pin BGA) -- MfG Falk
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