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
Antti <Antti.Lukats@googlemail.com> wrote: > it seems that first references to the upcoming Spartan family are in > the wild already > http://www.linkedin.com/in/ericschristiansen > I assume the spartan-6 mentioned there is not a typo > (actually i am almost sure it isnt) I neither find XILINX. spartan or fpga mentioned in that resume. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 137601
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message news:glc2p3$er6$1@lnx107.hrz.tu-darmstadt.de... > Antti <Antti.Lukats@googlemail.com> wrote: >> it seems that first references to the upcoming Spartan family are in >> the wild already > >> http://www.linkedin.com/in/ericschristiansen > >> I assume the spartan-6 mentioned there is not a typo >> (actually i am almost sure it isnt) > > I neither find XILINX. spartan or fpga mentioned in that resume. > Look harder? Try CTRL-F ? "o Control structure for the digital portion of the transceiver uses an instantiated microBlaze processor running in a Xilinx Spartan 6 FPGA o Component selection for the transceiver Common Public Radio Interface (CPRI) § Selected SFP+ module used for the optical interface, and a Spartan 6 FPGA running CPRI IP to handle the framing, mapping, and interleaving functions " What happened to 4 & 5? HTH., Syms.Article: 137602
On 22 ene, 19:07, sebs <sebastian.schuep...@googlemail.com> wrote:
> how do I access the DCR register when I make the PPC the dcr master.
> What is better to use the xilinx routines Xio_dcrIn and Xio_dcrOut.
> Also on some places I saw people using some kind of inline assembler
> macros. like mtdcr and mfdcr.
I found the Xio functions very slow. Using them also adds many KB of
code to your project, filling your precious BRAMs with useless jump
tables.
In my projects with DCR I use the mtdcr/mfdcr instructions. For
example
#define DCR_AUDIO_BASE 0x0204
#define DCR_AUDIO_FIFO (DCR_AUDIO_BASE+0x00)
void audioLoadSingle (sword nSample) {
slong s;
s = (((slong)nSample) << audio_Volume) >> AUDIO_VOLUME_MAX; //
volume
s += 0x8000; // make unsigned
if (s > 0xffff) s = 0xffff; // clip
if (s < 0x0000) s = 0x0000;
mtdcr(DCR_AUDIO_FIFO, (ulong)s); // write to FIFO
}
Best regards,
Marc
Article: 137603rickman <gnuarm@gmail.com> writes: > Did HP claim that it would reduce the size of the interconnect by > 95%? They have to provide ways of controlling each crossbar > interconnect. That is not free in terms of real estate. Also, if > they are going to design with local routing, there will need to be a > way to control each segment individually. I am sure it will be more > compact than the current configuration storage/pass transistor, but I > doubt that it will be 95% smaller. A lot of the routing is just that, > routing, and that does not get any smaller at all. This is the paper describing the process: http://www.iop.org/EJ/article/0957-4484/18/3/035204/nano7_3_035204.pdf It is a hyprid approach, logic is still CMOS (45nm), the routing is nanotech. They compared such a FPNI (their name of the hybird) with pure CMOS only (also 45nm) FPGA, and their results/estimations are: FPNI 30 (= 30nm nano routing) 1/8 area of cmos 22% slower than cmos only FPNI 9 (= 9 nm nano routing) 4% area of cmos ~6 times slower than cmos (of course this stuff is all conceptual, so do not trust their numbers until you hold on of those in your hands (or you see at least a real working prototype )). FlorianArticle: 137604
"Symon" <symon_brewer@hotmail.com> wrote in message news:glc3ro$ken$1@news.motzarella.org... > > "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message > news:glc2p3$er6$1@lnx107.hrz.tu-darmstadt.de... >> Antti <Antti.Lukats@googlemail.com> wrote: >>> it seems that first references to the upcoming Spartan family are in >>> the wild already >> >>> http://www.linkedin.com/in/ericschristiansen >> >>> I assume the spartan-6 mentioned there is not a typo >>> (actually i am almost sure it isnt) >> >> I neither find XILINX. spartan or fpga mentioned in that resume. >> > > Look harder? Try CTRL-F ? > > "o Control structure for the digital portion of the transceiver uses an > instantiated microBlaze processor running in a Xilinx Spartan 6 FPGA > o Component selection for the transceiver Common Public Radio Interface > (CPRI) > § Selected SFP+ module used for the optical interface, and a Spartan 6 > FPGA running CPRI IP to handle the framing, mapping, and interleaving > functions " > > What happened to 4 & 5? They could not be made to work with MPMC3 ! > HTH., Syms. > Michael KellettArticle: 137605
<nnadal@terra.es> wrote in message news:ab3f226a-9695-456d-b60b-fcd08cda835a@35g2000pry.googlegroups.com... >I have a new design with a XCS05 based on a well proved design where > the fpga runs during few minutes and then fails while expulses an > extrange substance from inside the VCC and GND pins, in some pads is > like spounge-white in other is black, the chip runs cold, never warms > up. I have a lot of experience on this chip and I have never seen > that. Then the chip appears to have a few inputs crossed to GND and > worked never more. We crossed all the VCC pads with wire-wrapping with > no results, no current loops. The prototype worked well (this is the > first series PCB). Any Idea? > Did you buy the parts off Ebay? Syms.Article: 137606
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:h68hn4d2198akklhhj4327ujkshmsr2lej@4ax.com... > On Thu, 22 Jan 2009 07:29:49 -0600, krw <krw@att.zzzzzzzzz> wrote: > > We're not really sure how it gets out. The FPGA feeds dacs clocked at > 128, which feed lowpass filters, output amps, and the connectors. > We're seeing lines as big as -45 dBm coming out the connectors. If you > wave a spectrum analyzer probe around the board, the junk is most > intense just over the FPGA. Some weird points: the lines are at > different frequencies on the two different boards, even though the > fpga's are very similar; one board tends to have lines in pairs, a > couple of MHz apart; we can almost swear that once we saw the whole > spectral forest shift around, in one instant on one board, when > nothing else was going on. > > It would be fun to really investigate the cause of this, but all we > have time to do is fix it. > > > John > John, The Xilinx tools sometimes add in extra clocks to fix problems the NBTI listed in the errata. Especially the MGTs and the DCMs. Might be that. You can prolly turn that stuff off with an environment variable to see if the junk goes away. HTH., Syms.Article: 137607
On Jan 23, 12:25=A0pm, "MK" <nos...@please.thanks> wrote: > "Symon" <symon_bre...@hotmail.com> wrote in message > > news:glc3ro$ken$1@news.motzarella.org... > > > > > > > "Uwe Bonnes" <b...@elektron.ikp.physik.tu-darmstadt.de> wrote in messag= e > >news:glc2p3$er6$1@lnx107.hrz.tu-darmstadt.de... > >> Antti <Antti.Luk...@googlemail.com> wrote: > >>> it seems that first references to the upcoming Spartan family are in > >>> the wild already > > >>>http://www.linkedin.com/in/ericschristiansen > > >>> I assume the spartan-6 mentioned there is not a typo > >>> (actually i am almost sure it isnt) > > >> I neither find XILINX. spartan or fpga mentioned in that resume. > > > Look harder? Try CTRL-F ? > > > "o Control structure for the digital portion of the transceiver uses an > > instantiated microBlaze processor running in a Xilinx Spartan 6 FPGA > > o Component selection for the transceiver Common Public Radio Interface > > (CPRI) > > =A7 Selected SFP+ module used for the optical interface, and a Spartan = 6 > > FPGA running CPRI IP to handle the framing, mapping, and interleaving > > functions " > > > What happened to 4 & 5? > > They could not be made to work with MPMC3 ! > > > HTH., Syms. > > Michael Kellett ROTFL sounds like a valid reason AnttiArticle: 137608
On Fri, 23 Jan 2009 03:27:05 GMT, "Rodo" <noway@youwish.com> wrote: >Hi all, > >I need to generate a squarewave in increments of 2 Hz.(Accuracy should be >1Hz). I thought I use a PIC18 and a AD9833 but I keep thinking about the >MAX3000A. I think the implementation should be simpler on it but I just >can't get started thinking that it is not going to work. I thought I use an >external oscillator and divide the freq. down (with the MAX3000A) to what a >set of BCD (8 to 12 bits) switches are set to. Last time I use a MAX3000A I >drew the schematic but this time I thought Verilog HDL would seem simpler. >Any thought on it? Direct digital synthesis (DDS) is easy to implement, and can give you the resolution you need with no difficulty - PROVIDED you can tolerate the jitter of +/- one system clock period on the generated edges. And yes, it is definitely easier in HDL. If this is for timing of real-world activity such as motion control, DDS is certainly a good method. If you need a very predictable frequency spectrum, free of the spurious components created by jitter on the output edges, then you may need to try some other method. It sounds as though you only want to go up to a few kHz, so there are many possible approaches available. Tell us more! Just a few rough numbers to get these things into perspective: Suppose you have a 30MHz system clock, giving 33ns of jitter on your DDS square wave's edges. If the application is audio-related, that corresponds to a physical shift of about 0.01mm in the distance from source to "listener", or a phase shift of about 0.01 degree in a 1kHz tone. Probably not a big deal. On the other hand, it corresponds to a distance of nearly 10 metres in an optical system, probably rendering it useless for LIDAR or other measurement applications. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137609
On Fri, 23 Jan 2009 11:03:42 -0000, "Symon" <symon_brewer@hotmail.com> wrote: > >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:h68hn4d2198akklhhj4327ujkshmsr2lej@4ax.com... >> On Thu, 22 Jan 2009 07:29:49 -0600, krw <krw@att.zzzzzzzzz> wrote: >> >> We're not really sure how it gets out. The FPGA feeds dacs clocked at >> 128, which feed lowpass filters, output amps, and the connectors. >> We're seeing lines as big as -45 dBm coming out the connectors. If you >> wave a spectrum analyzer probe around the board, the junk is most >> intense just over the FPGA. Some weird points: the lines are at >> different frequencies on the two different boards, even though the >> fpga's are very similar; one board tends to have lines in pairs, a >> couple of MHz apart; we can almost swear that once we saw the whole >> spectral forest shift around, in one instant on one board, when >> nothing else was going on. >> >> It would be fun to really investigate the cause of this, but all we >> have time to do is fix it. >> >> >> John >> >John, >The Xilinx tools sometimes add in extra clocks to fix problems the NBTI >listed in the errata. Especially the MGTs and the DCMs. Might be that. You >can prolly turn that stuff off with an environment variable to see if the >junk goes away. >HTH., Syms. > Yeah, there seem to be many extra clocks inside; this is an XC3S400. One other interesting thing: on one of the units, if we power cycle it, it comes up, randomly, with one of two distinct spectral patterns which have nothing in common but the big 128 and 256 MHz lines. All the junk pops up the instant the chip is configured. All the various birdies must be somehow phaselocked, or maybe just injection locked, to the 128 MHz clock; they couldn't be so rock-stable without an external frequency reference. I suppose that's good... less random jitter issues. We were conjecturing that internal plls and dcms that we don't use may be wandering off and doing things on their own. JohnArticle: 137610
On Jan 23, 10:56=A0am, jetm...@hotmail.com wrote:
> On 22 ene, 19:07, sebs <sebastian.schuep...@googlemail.com> wrote:
>
> > how do I access the DCR register when I make the PPC the dcr master.
> > What is better to use the xilinx routines Xio_dcrIn and Xio_dcrOut.
> > Also on some places I saw people using some kind of inline assembler
> > macros. like mtdcr and mfdcr.
>
> I found the Xio functions very slow. =A0Using them also adds many KB of
> code to your project, filling your precious BRAMs with useless jump
> tables.
>
> In my projects with DCR I use the mtdcr/mfdcr instructions. =A0For
> example
>
> =A0 #define DCR_AUDIO_BASE =A0 =A0 =A0 =A00x0204
> =A0 #define DCR_AUDIO_FIFO =A0 =A0 =A0 =A0(DCR_AUDIO_BASE+0x00)
>
> =A0 void =A0audioLoadSingle =A0 =A0 =A0 =A0 (sword nSample) {
> =A0 =A0 slong s;
>
> =A0 =A0 s =A0=3D (((slong)nSample) << audio_Volume) >> AUDIO_VOLUME_MAX; =
=A0 =A0//
> volume
>
> =A0 =A0 s +=3D 0x8000; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0// make unsigned
>
> =A0 =A0 if (s > 0xffff) s =3D 0xffff; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// =
clip
> =A0 =A0 if (s < 0x0000) s =3D 0x0000;
>
> =A0 =A0 mtdcr(DCR_AUDIO_FIFO, (ulong)s); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// write to FIFO
> =A0 }
>
> Best regards,
> Marc
Thanks Marc, thats exactly what I needed. I got my custom dcr to work
today too.
Article: 137611Hi Daniele, > WHAT'S WRONG? I am not sure but I think that the compiler is "case sensitive" ... then: "xio_out32" --> "Xio_Out32" "xio_in32" --> "Xio_In32" Kappa.Article: 137612
nnadal@terra.es wrote: > I have a new design with a XCS05 based on a well proved design where > the fpga runs during few minutes and then fails while expulses an > extrange substance from inside the VCC and GND pins, in some pads is > like spounge-white in other is black, the chip runs cold, never warms > up. I have a lot of experience on this chip and I have never seen > that. did you take any picture ? -- http://ygdes.com / http://yasep.orgArticle: 137613
I was trying to program signal changes in testbench (see btn_down in
screencap):
http://jleslie48.com/fpga_uartjl_01/notes/screencap08_testbench01t.png
and the simulation window doesn't show the change in state of the
signal:
http://jleslie48.com/fpga_uartjl_01/notes/screencap09_testbench_output.png
so I thought that things were waiting until after the 100ms mark based
on this line of
the source uart_test_tb02.vhd:
-- hold reset state for 100ms.
wait for 100ms;
but that crashed testbench when tried to collect 250ms of a run
(248,749,535ns):
http://jleslie48.com/fpga_uartjl_01/notes/screencap10_testbench_crash.png
so I have 2 questions,
1) it crashed because it used up memory, how can I avoid crashing if I
want longer
time samples of the run (and for that matter make it not take
forever) ,
2) why didn't btn_down ever change state?
Thanks,
Jon
Article: 137614
On Jan 23, 3:37 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> I was trying to program signal changes in testbench (see btn_down in
> screencap):
>
> http://jleslie48.com/fpga_uartjl_01/notes/screencap08_testbench01t.png
>
> and the simulation window doesn't show the change in state of the
> signal:
>
> http://jleslie48.com/fpga_uartjl_01/notes/screencap09_testbench_outpu...
>
> so I thought that things were waiting until after the 100ms mark based
> on this line of
> the source uart_test_tb02.vhd:
>
> -- hold reset state for 100ms.
> wait for 100ms;
>
> but that crashed testbench when tried to collect 250ms of a run
> (248,749,535ns):
>
> http://jleslie48.com/fpga_uartjl_01/notes/screencap10_testbench_crash...
>
> so I have 2 questions,
>
> 1) it crashed because it used up memory, how can I avoid crashing if I
> want longer
> time samples of the run (and for that matter make it not take
> forever) ,
> 2) why didn't btn_down ever change state?
>
> Thanks,
>
> Jon
Ok, it was an easy one. the answer was to reduce the 100ms wait:
-- Stimulus process
stim_proc: process
begin
-- hold reset state for 100ms.
wait for 100ns; -- changed to 100ns from 100ms.
wait for clk_period*10;
-- insert stimulus here
wait for 20ns;
btn_down <= '1';
wait for 30ns;
btn_down <= '0';
wait for 35ns;
wait;
end process;
so now I see my 30ns blip of btn_down,
so the new question is why did the wizard that
made up this testbench create a 100ms delay on the
start, when that delay automatically puts me in a memory overrun
error?
Article: 137615nnadal@terra.es wrote: >I have a new design with a XCS05 based on a well proved design where >the fpga runs during few minutes and then fails while expulses an >extrange substance from inside the VCC and GND pins You let the smoke out and it has to be kept inside the package because that is what makes chips work..... --Article: 137616
I looked at the DDS info in the Altera site but I didn't see any mention that it was for the CPLDs. They talk about a megacore function and FPGAs. Can this be used in a MAX3000? I'm not doing anything fancy but cost and current consumption are an issue. I'd like to use as low a frequency I can to run the CPLD. Do you have any info on implementing a DDS? Thanks "Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:vsajn45uejgjqm0r2lo8vjdij6kt01c7e6@4ax.com... > On Fri, 23 Jan 2009 03:27:05 GMT, "Rodo" <noway@youwish.com> wrote: > >>Hi all, >> >>I need to generate a squarewave in increments of 2 Hz.(Accuracy should be >>1Hz). I thought I use a PIC18 and a AD9833 but I keep thinking about the >>MAX3000A. I think the implementation should be simpler on it but I just >>can't get started thinking that it is not going to work. I thought I use >>an >>external oscillator and divide the freq. down (with the MAX3000A) to what >>a >>set of BCD (8 to 12 bits) switches are set to. Last time I use a MAX3000A >>I >>drew the schematic but this time I thought Verilog HDL would seem simpler. >>Any thought on it? > > Direct digital synthesis (DDS) is easy to implement, > and can give you the resolution you need with no > difficulty - PROVIDED you can tolerate the jitter > of +/- one system clock period on the generated edges. > And yes, it is definitely easier in HDL. > > If this is for timing of real-world activity such > as motion control, DDS is certainly a good method. > If you need a very predictable frequency spectrum, > free of the spurious components created by jitter > on the output edges, then you may need to try some > other method. It sounds as though you only want to > go up to a few kHz, so there are many possible > approaches available. Tell us more! > > Just a few rough numbers to get these things into > perspective: Suppose you have a 30MHz system > clock, giving 33ns of jitter on your DDS square > wave's edges. If the application is audio-related, > that corresponds to a physical shift of about 0.01mm > in the distance from source to "listener", or a phase > shift of about 0.01 degree in a 1kHz tone. Probably > not a big deal. On the other hand, it corresponds to > a distance of nearly 10 metres in an optical system, > probably rendering it useless for LIDAR or other > measurement applications. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.bromley@MYCOMPANY.com > http://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated.Article: 137617
"Rodo" <noway@youwish.com> wrote in message news:Dvtel.1551$Aw2.414@nwrddc02.gnilink.net... >I looked at the DDS info in the Altera site but I didn't see any mention >that it was for the CPLDs. They talk about a megacore function and FPGAs. >Can this be used in a MAX3000? > > I'm not doing anything fancy but cost and current consumption are an > issue. I'd like to use as low a frequency I can to run the CPLD. Do you > have any info on implementing a DDS? > > Thanks > > Do a web search for DDS. You'll find all the info you need. I used info from Google to design a DDS generator for a microcontroller. You can do the same. If you can't then you should try a different career. Bob -- == All google group posts are automatically deleted due to spam ==Article: 137618
>I looked at the DDS info in the Altera site but I didn't see any mention >a squarewave in increments of 2 Hz. Hi, I don't think you need to go the DDS path if what you are planning is divide a clock to lower frequencies. You can use just a modulo adder that runs on your input clock and increments by a value chosen for each required frequency(NCO,numerically controlled oscillator), the output clock can be taken directly from the MSB of adder, thus: output frequency = input frequency * increment/modulus Accuracy can be as low as micro Hz if you choose a wide adder(high value of modulus and increment). You will only get a regular clock if the ratio input frequency/output frequency is integer otherwise you will end up with repeated iregularity. kadhiemArticle: 137619
On Fri, 23 Jan 2009 03:27:05 GMT, "Rodo" <no...@youwish.com> wrote: >Hi all, >I need to generate a squarewave in increments of 2 Hz.(Accuracy should be >1Hz). I thought I use a PIC18 and a AD9833 but I keep thinking about the >MAX3000A. I think the implementation should be simpler on it but I just >can't get started thinking that it is not going to work. I thought I use an >external oscillator and divide the freq. down (with the MAX3000A) to what a >set of BCD (8 to 12 bits) switches are set to. Last time I use a MAX3000A I >drew the schematic but this time I thought Verilog HDL would seem simpler. >Any thought on it? DDS is one solution, but may not map too well to BCD switches. Google CD4527 / HEF4527 for a BCD rate multiplier example. This is effectively a picket fence pulse density modulation, that gives an average Frequency. They can also be used as DAC's Like DDS, it has some jitter, so you start from a high clock, and then do a 12-16 bit BCD Rate Multiplier, and then as much divider following that as practical. Each BCD digit needs 4 bits(MCells) counter + 1 Mcell as Combiner. In a MAX3000, with 32 MCells, you might choose 1999 FS for 15+2 bits,and N/2000 in the BCD block, then 16.384MHz lets you divide by 8192 and you have used 30 macrocells. Or, you might like 9999 FS, and N/10000, (20MC) then 2048 yields 20.48MHz, and 31 Macrocells. The post-divider integrates jitter, and does not have to be 2^N - eg 16MHz divided by 1600, gives '9999' entry into your BCD frequency set. -jgArticle: 137620
"Rodo" <no...@youwish.com> wrote in message >I looked at the DDS info in the Altera site but I didn't see any mention >that it was for the CPLDs. They talk about a megacore function and FPGAs. >Can this be used in a MAX3000? > I'm not doing anything fancy but cost and current consumption are an > issue. I'd like to use as low a frequency I can to run the CPLD. Do you > have any info on implementing a DDS? MAX3000 is not what anyone would call Low Current .. :) Better are Atmel ATF1502BE, Lattice 4032ZE, Xilinx XC2C32A The lower the clock speed, the more the jitter, so you will need to decide what matters there (ie how much spectral width can you tolerate ?) To minimize power, use only as many bits as you need. eg 2MHz gives 0.5u Clk Quantize, and a BCD rate Multiplier divide of 1000, (see my other post) and probably your 2MHz oscillator will draw more than the ZeroPower CPLD !! .Article: 137621
On Jan 22, 9:07 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > whygee <why...@yg.yg> wrote: > > rickman wrote: > >> Just don't even go there. For all practical purposes, changing the > >> diameter will have no noticeable effect in this situation. Don't > >> encourage the guy! > > hummm... > > not even to test the principle before making a PCB ? > > I agree that one should know what one is doing before > designing a PC board. Believing that width doesn't matter > and using very narrow traces isn't a good start, though. We are not talking about traces on a PCB, we're talking about the diameter of a wire in free space. On a PCB the width affects the capacitance and therefore greatly affects the impedance. In free space it has much less effect. I told Whygee to limit the length of the wires in the power circuit and his reply was that he would keep the impedance of the power wires down by using fat wires. With the power loop being a literal loop in the air, the length of the wire will by far outweigh the diameter of the wire in determining the impedance of the circuit. I doubt that you would ever be able to measure the difference in impedance from changes in the width of the wires. RickArticle: 137622
rickman <gnuarm@gmail.com> wrote: (snip) > We are not talking about traces on a PCB, we're talking about the > diameter of a wire in free space. On a PCB the width affects the > capacitance and therefore greatly affects the impedance. In free > space it has much less effect. Compared to a PC trace with a ground plane, yes. But if you have a wire of a given length and distance from other wires through space and you need to reduce its impedance, the only way is to increase the diameter. > I told Whygee to limit the length of the wires in the power circuit > and his reply was that he would keep the impedance of the power wires > down by using fat wires. With the power loop being a literal loop in > the air, the length of the wire will by far outweigh the diameter of > the wire in determining the impedance of the circuit. I doubt that > you would ever be able to measure the difference in impedance from > changes in the width of the wires. Assuming that the inductance is much more important than series resistance, probably true. It isn't hard to get small enough that resistance dominates, though. -- glenArticle: 137623
On Fri, 23 Jan 2009 19:53:29 -0600, "kadhiem_ayob" wrote: >I don't think you need to go the DDS path if what you are planning is >divide a clock to lower frequencies. The terminology for DDS (direct digital synthesis) and NCO (numerically controlled oscillator) is not very well defined, but I was probably wrong to mention DDS when in fact I was talking about a phase-accumulator square wave generator, just as kadhiem describes. kadhiem's scheme works only if the divisor (modulus) is an exact power of 2. With a little more effort it's easy to get N/M frequency multiplication/division for arbitrary N,M. But the jitter problem remains. DDS would allow you to generate an approximate sinewave at the desired frequency. This could be low-pass filtered and then squared using an analogue comparator, giving significantly better jitter performance than a simple square-wave phase accumulator. Unfortunately the OP still hasn't said what he really needs, but instead has just complained that he can't find how to do it - despite many sensible and useful suggestions. I tried a simple phase-accumulator implementation in a MAX3000, and discovered to my horror how expensive it is to construct a wide adder in these devices; the synthesis tool I tried can fit only a 14-bit accumulator in a 32-macrocell device. This would give 2Hz resolution from a 32768Hz watch-crystal oscillator, but of course the jitter would be 30 microseconds which would probably be unacceptable for most applications. For lowest cost, probably the BCD rate multiplier is favourite. But it's very jittery. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137624
Rishi Mathur wrote: > Respected Sir, > In my Partial reconfiguration design, 'clk' and 'dataclk' are the two > clocks going to both 'static' and reconfigurable' modules. Can you > please guide me on what to write in UCF file to declare them as GLOBAL > CLOCKS. The easiest way to make clocks global is to hook them up to a global clock buffer, i.e. instantiate a BUFG and use its output as a clock signal in your design. I don't know if there is a UCF constraint for declaring a signal as a global clock other than specifying a timing constraint for it. It's been a few years since I played with partial reconfiguration, but back then you had to have a top-level for all the "static" and global stuff (such as clock buffers and bus macros for connections between reconfigurable modules and such), and then one or several modules with the reconfigurable stuff. Back then you had to manually instantiate all clock buffers in the top level, don't know if this is still the case. HTH, Sean
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