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
On Nov 1, 4:24 pm, Frank Buss <f...@frank-buss.de> wrote: > raull...@hotmail.com wrote: > > My FPGA master clock is at 100MHz. I have assigned a counter to count > > from 0 to 99 to achieve a period of 1usec. As the counter is counting > > from 0 to 99, i will take 1 sample at each count and therefore i have > > a total of 100 samples. Now my task requires me to increase my sample > > size to 200. However, i can't increase the counter count to 0 - 200 as > > this will increase the period to 2usec. My task requires me to double > > the sample size while maintaing the period at 1usec. > > Use a PLL to double the clock frequency, if your FPGA has one. > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de Hi Frank, i am not allowed to double the clock frequency, my clock period have to remains at 10ns(1usec/100).Article: 125701
<raullim7@hotmail.com> wrote in message news:1193906454.426594.11470@i13g2000prf.googlegroups.com... > On Nov 1, 4:24 pm, Frank Buss <f...@frank-buss.de> wrote: >> raull...@hotmail.com wrote: >> > My FPGA master clock is at 100MHz. I have assigned a counter to count >> > from 0 to 99 to achieve a period of 1usec. As the counter is counting >> > from 0 to 99, i will take 1 sample at each count and therefore i have >> > a total of 100 samples. Now my task requires me to increase my sample >> > size to 200. However, i can't increase the counter count to 0 - 200 as >> > this will increase the period to 2usec. My task requires me to double >> > the sample size while maintaing the period at 1usec. >> >> Use a PLL to double the clock frequency, if your FPGA has one. >> >> -- >> Frank Buss, >> f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de > > Hi Frank, i am not allowed to double the clock frequency, my clock > period have to remains at 10ns(1usec/100). > Have half of the samples sampled with the pos edge of the clock and the other half caught with the neg edge of the clock. Treat these as asynchronous clocks. MikeArticle: 125702
On 1 Nov, 12:23, "Toni Merwec" <mistertorp...@freenet.de> wrote: > "Patrick Dubois" <prdub...@gmail.com> schrieb im Newsbeitragnews:1193673009.082475.114600@k35g2000prh.googlegroups.com... > > > > > The two proms can be considered as one big prom twice as large. No > > prom is exclusively dedicated to one FPGA in particular. For example, > > the bit file for FPGA #1 might take 2/3 of the first prom and the bit > > file for FPGA #2 might be half in prom #1 and half in prom #2. This is > > handled for you when you create your mcs files for the proms. > > Okay, thank you very much. But one more question: What about the DO pins > from the PROMs to the FPGA? In the Platform Flash In-System Programmable > Configuration PROMs data sheet ds123.pdf (page 18) it is recommended to tie > the DO outputs of both PROMs together and connect the FPGAs in series. I > don't see any reason to do it this way. What I would have done normally > (without having read the user guide) is having the DO of one PROM connected > to one FPGA (DIN) and the other DO of the second PROM to the the other DIN > of the remaining FPGA. What is the reason not to do so, i.e. is there any > reason? Any help is highly appreciated! > > Regards > > Toni Surely this is a simple bom cost option. If each fpga needs 4.1 Mbit you would need two 8MBit PROMs seperately or an 8 and a 1MBit if combining them.Article: 125703
"colin" <colin_toogood@yahoo.com> schrieb im Newsbeitrag news:1193927393.785875.316600@22g2000hsm.googlegroups.com... > > Surely this is a simple bom cost option. If each fpga needs 4.1 Mbit > you would need two 8MBit PROMs seperately or an 8 and a 1MBit if > combining them. So I'm fine with my solution if cost doesn't matter, right? :-) Technically it is not wrong, I guess...Article: 125704
You are "not allowed to"... Do you live in a police state that prohibits obvious solutions? What's the penalty? Peter Alfke ============== On Nov 1, 6:33 am, raull...@hotmail.com wrote: > On Nov 1, 4:24 pm, Frank Buss <f...@frank-buss.de> wrote: > > > raull...@hotmail.com wrote: > > > My FPGA master clock is at 100MHz. I have assigned a counter to count > > > from 0 to 99 to achieve a period of 1usec. As the counter is counting > > > from 0 to 99, i will take 1 sample at each count and therefore i have > > > a total of 100 samples. Now my task requires me to increase my sample > > > size to 200. However, i can't increase the counter count to 0 - 200 as > > > this will increase the period to 2usec. My task requires me to double > > > the sample size while maintaing the period at 1usec. > > > Use a PLL to double the clock frequency, if your FPGA has one. > > > -- > > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de > > Hi Frank, i am not allowed to double the clock frequency, my clock > period have to remains at 10ns(1usec/100).Article: 125705
>> >> > raull...@hotmail.com wrote: >> > > My FPGA master clock is at 100MHz. I have assigned a counter to count >> > > from 0 to 99 to achieve a period of 1usec. As the counter is counting >> > > from 0 to 99, i will take 1 sample at each count and therefore i have >> > > a total of 100 samples. Now my task requires me to increase my sample >> > > size to 200. However, i can't increase the counter count to 0 - 200 >> > > as >> > > this will increase the period to 2usec. My task requires me to double >> > > the sample size while maintaing the period at 1usec. >> Is the requirement to keep the period at 1usec or the frequency at 100Mhz? mikeArticle: 125706
raullim7@hotmail.com wrote: > Hi Frank, i am not allowed to double the clock frequency, my clock > period have to remains at 10ns(1usec/100). Maybe you misunderstood me: The PLL is inside the FPGA (at least in Spartan, Cyclone etc.). Most FPGA clock circuits even provide multiple outputs. So you can run the rest of your design at 100 MHz and the sampling at 200 MHz. But maybe you need some FIFO and other tricks to couple it to the 100 MHz domain, or if the speed is too high for your built-in memory or external memory. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 125707
Hi all! I have a simple Spartan3A design where I feed a digital video stream to bank 3 of the device. The idea is to use one of the Left hand clocks in the device to clock data in the IO pads and to the write side of a FIFO and then use a Global clock for the read side and further processing. In order for this to work I have created an AREA_GROUP with all the logic where the Left hand clock occurs, including the BUFGMUX and have assigned a range of slices and clock buffers for this goroup to confine it to the left half of the device, where the clock is supposedly available. Moreover, I have given a specific LOC constraint to the BUFGMUX. All these constraints have been accepted by Translate. The sad part is that (apart for a breif moment last night) PAR persists in placing the BUFGMUX in one of the global sites in bank 2. This means that the routing from the clock pin (that is one of the LHCLK-pins right near the left hand BUFGMUX) goes across the die and screws ut the timing. I see no reason for this, the clock net is confined to the left hand of the die (verified in FPGA editor) and the specified left hand BUFGMUX is free. Here is a snippet from the .ucf-file. The dual range AREA_GROUP constraint (commented out below) does not seem to make any differance, I have tried both with and without it. I have also tried giving a range for the LOC constraint, spanning all the left hand BUFGMUX, but no cigar. # Video input clock buffer, Left hand BUFGMUX X0Y2 INST "fe_mux_inst/vin_clk_buf_inst" LOC = BUFGMUX_X0Y2; # Force VinCLK related logic and clock to left hand side INST "fe_mux_inst" AREA_GROUP = "LeftHandClockedGRP" ; INST "fe_engine_inst" AREA_GROUP = "LeftHandClockedGRP" ; INST "fe_mux_inst/vin_clk_buf_inst" AREA_GROUP = "LeftHandClockedGRP" ; AREA_GROUP "AG_LeftHandClockedGRP" RANGE = SLICE_X0Y0:SLICE_X31Y143 ; #AREA_GROUP "AG_LeftHandClockedGRP" RANGE = SLICE_X32Y8:SLICE_X39Y135 ; AREA_GROUP "AG_LeftHandClockedGRP" RANGE = RAMB16_X0Y0:RAMB16_X0Y15 ; Time is ticking, the deadline is aproaching, the desperation is building... Any clues out there? I run ISE 9.1.03i under Windows XP. Synthesis is XST. Clobber me if there are more details I should have included... /Lars (Remove the obvious from the email address for direct replies)Article: 125708
Sounds like a homework restriction to me. ---Matthew Hicks > You are "not allowed to"... > Do you live in a police state that prohibits obvious solutions? > What's the penalty? > Peter Alfke > ============== > On Nov 1, 6:33 am, raull...@hotmail.com wrote: >> On Nov 1, 4:24 pm, Frank Buss <f...@frank-buss.de> wrote: >> >>> raull...@hotmail.com wrote: >>> >>>> My FPGA master clock is at 100MHz. I have assigned a counter to >>>> count from 0 to 99 to achieve a period of 1usec. As the counter is >>>> counting from 0 to 99, i will take 1 sample at each count and >>>> therefore i have a total of 100 samples. Now my task requires me to >>>> increase my sample size to 200. However, i can't increase the >>>> counter count to 0 - 200 as this will increase the period to 2usec. >>>> My task requires me to double the sample size while maintaing the >>>> period at 1usec. >>>> >>> Use a PLL to double the clock frequency, if your FPGA has one. >>> >>> -- >>> Frank Buss, >>> f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de >> Hi Frank, i am not allowed to double the clock frequency, my clock >> period have to remains at 10ns(1usec/100). >>Article: 125709
Has anyone implemented a circuit similar to the one below?
VCC
+
|
.---------------o
| |
| |
| .-.
| | |
| | | weak pullup
| '-'
| |
| |
| .-----o
| | | -----
| |\| | | |
--------| >-----|-------| PIN |
|/ | | |
| -----
|
| floating
| or
| GND
/| |
To Internal Fpga Logic <---------< |-------
\|
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
When the input pin is floating, the weak pullup causes the output
buffer to drive Vcc out, negating any extraneous noise that may exist
on the external line.
When the input pin is driven to ground, the buffer momentarily tries
driving Vcc to ground but stops once the tristate is disabled.
I've always just used a weak pullup on the input (no tristate buffer
at all) but another engineer in our group says this is a good way to
protect input pins from noise on undriven inputs. I'm a little
concerned about the brief period of time when the tristate buffer is
driving ground but he assures me that the fpga can handle it.
Do you agree?
Article: 125710As one might expect, I was on a wild goose chase. Please ignore the above post, I had two clock buffers in the block, one called vin_clk_buf_inst and one called vin_clk2_buf_inst. I placed the constraints on vin_clk_buf_inst, that I didn't use and that got optimized away in MAP so I missed that vin_clk2_buf_inst was left without any LOC constraint. I still can't see why ISE could not figure this topology out by itself. But I guess that is why there are still a need for engineers... Regards, /LarsArticle: 125711
Petrov, Why are you trying to do this? What is it supposed to protect the FPGA from? AustinArticle: 125712
Matthew Hicks wrote: > Sounds like a homework restriction to me. > Perhaps this is a task for a 5ns delay line then ? The tutor may not have restricted those ;) -jgArticle: 125713
Petrov_101@hotmail.com wrote: > Has anyone implemented a circuit similar to the one below? > > VCC > + > | > .---------------o > | | > | | > | .-. > | | | > | | | weak pullup > | '-' > | | > | | > | .-----o > | | | ----- > | |\| | | | > --------| >-----|-------| PIN | > |/ | | | > | ----- > | > | floating > | or > | GND > /| | > To Internal Fpga Logic <---------< |------- > \| > (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de) > > > When the input pin is floating, the weak pullup causes the output > buffer to drive Vcc out, negating any extraneous noise that may exist > on the external line. > > When the input pin is driven to ground, the buffer momentarily tries > driving Vcc to ground but stops once the tristate is disabled. > > I've always just used a weak pullup on the input (no tristate buffer > at all) but another engineer in our group says this is a good way to > protect input pins from noise on undriven inputs. Wow - How much noise is he used to dealing with ? > I'm a little > concerned about the brief period of time when the tristate buffer is > driving ground but he assures me that the fpga can handle it. Also be worried about if the contention can get past the logic threshold. > > Do you agree? Yes, "the fpga can handle it" - but you have wider issues. Can the device driving the fPGA handle it. You would need to spec the lowest drive option on the FPGA, and the best drive on the external device. What if the designer of the external device is thinking exactly the same as you :) The 80C51 has a port structure similar, but they use Weak PFET and Strong NFET, so they know they will not get stuck in no-mans land with part variations. -jgArticle: 125714
On Nov 1, 2:25 pm, austin <aus...@xilinx.com> wrote: > Petrov, > > Why are you trying to do this? > > What is it supposed to protect the FPGA from? > > Austin I'm not convinced I should be trying this, that's the problem. I've always just enabled a weak pullup resistor on the input of a floating pin. My coworker is trying to convince me that this approach offers better noise immunity when nothing is connected to the input pin. The thing is, this input feeds a two-stage synchronizer... I would think that alone would eliminate most noise to the synchronous logic that follows.Article: 125715
On Nov 1, 2:50 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Petrov_...@hotmail.com wrote: > > Has anyone implemented a circuit similar to the one below? > > > VCC > > + > > | > > .---------------o > > | | > > | | > > | .-. > > | | | > > | | | weak pullup > > | '-' > > | | > > | | > > | .-----o > > | | | ----- > > | |\| | | | > > --------| >-----|-------| PIN | > > |/ | | | > > | ----- > > | > > | floating > > | or > > | GND > > /| | > > To Internal Fpga Logic <---------< |------- > > \| > > (created by AACircuit v1.28.6 beta 04/19/05www.tech-chat.de) > > > When the input pin is floating, the weak pullup causes the output > > buffer to drive Vcc out, negating any extraneous noise that may exist > > on the external line. > > > When the input pin is driven to ground, the buffer momentarily tries > > driving Vcc to ground but stops once the tristate is disabled. > > > I've always just used a weak pullup on the input (no tristate buffer > > at all) but another engineer in our group says this is a good way to > > protect input pins from noise on undriven inputs. > > Wow - How much noise is he used to dealing with ? > > > I'm a little > > concerned about the brief period of time when the tristate buffer is > > driving ground but he assures me that the fpga can handle it. > > Also be worried about if the contention can get past the logic threshold. > > > > > Do you agree? > > Yes, "the fpga can handle it" - but you have wider issues. > Can the device driving the fPGA handle it. > You would need to spec the lowest drive option on the FPGA, > and the best drive on the external device. > What if the designer of the external device is thinking exactly the same > as you :) > > The 80C51 has a port structure similar, but they use Weak PFET and > Strong NFET, so they know they will not get stuck in no-mans land with > part variations. > > -jg- Hide quoted text - > > - Show quoted text - My coworker did suggest setting the drive to the lowest setting. I assume he's done this on past designs... I've just never seen it before.Article: 125716
On Nov 1, 1:50 pm, Petrov_...@hotmail.com wrote: > On Nov 1, 2:25 pm, austin <aus...@xilinx.com> wrote: > > > Petrov, > > > Why are you trying to do this? > > > What is it supposed to protect the FPGA from? > > > Austin > > I'm not convinced I should be trying this, that's the problem. I've > always just enabled a weak pullup resistor on the input of a floating > pin. My coworker is trying to convince me that this approach offers > better noise immunity when nothing is connected to the input pin. > > The thing is, this input feeds a two-stage synchronizer... I would > think that alone would eliminate most noise to the synchronous logic > that follows. So are you saying that the input to your synchronizer would be floating??? -Dave PollumArticle: 125717
On Nov 1, 2:55 pm, Dave Pollum <vze24...@verizon.net> wrote: > On Nov 1, 1:50 pm, Petrov_...@hotmail.com wrote: > > > > > > > On Nov 1, 2:25 pm, austin <aus...@xilinx.com> wrote: > > > > Petrov, > > > > Why are you trying to do this? > > > > What is it supposed to protect the FPGA from? > > > > Austin > > > I'm not convinced I should be trying this, that's the problem. I've > > always just enabled a weak pullup resistor on the input of a floating > > pin. My coworker is trying to convince me that this approach offers > > better noise immunity when nothing is connected to the input pin. > > > The thing is, this input feeds a two-stage synchronizer... I would > > think that alone would eliminate most noise to the synchronous logic > > that follows. > > So are you saying that the input to your synchronizer would be > floating??? > -Dave Pollum- Hide quoted text - > > - Show quoted text - No... it would still have the weak pullup enabled.Article: 125718
What are you sampling? Where do the samples go? If you store your samples in some sort of a memory buffer, just add another buffer of the same size and write to it on falling edge. /MikhailArticle: 125719
Dear all, Is it possible to implement power management unit(idle and active) in FPGA? pls give suggestions to implement clock generation unit in FPGA.... regards, fazalArticle: 125720
I am mainly looking to make my ModelSim test bench simulation creations easier/faster. How does Xilinx's System Generator versus Mathworks' Link for Modelsim compare for that? With System Generator, I usppose it is possible to use Black Box for creating Simulink test benches?Article: 125721
Petrov, I can see no reason to do what your co-worker is suggesting, unless there are IOs very near this input, and those IOs are switching with large, and strong, currents (like LVCMOS 24 mA FAST, or PCI bus). The above assumes that this input is only weakly driven. If there is a strong driver to this input, then the only concern is if there is so much cross-talk or bounce that a driven signal to this pin is upset (requires many tens of mA of coupling, or volts of bounce!). If there are nearby switching, and the concern is crosstalk or ground bounce, then the real solution is to do the simulations, and either use the right part (like the V4 or V5 with the SpaseChevron(tm) package which minimizes crosstalk and bounce by a factor of 7.5 over other solutions), or ground the pins on either side of the input (which is another way to limit the crosstalk and bounce on the sensitive pin). Your friend's idea may not harm the output (it will not), but it won't really do what you want, either (deal with crosstalk or bounce). AustinArticle: 125722
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:472a1dc0$1@clear.net.nz... > Matthew Hicks wrote: >> Sounds like a homework restriction to me. >> > > Perhaps this is a task for a 5ns delay line then ? > The tutor may not have restricted those ;) > > -jg > Hi Jim, I think we may need to be more creative than that. I suggest accelerating the tutor to about 0.866 times the speed of light while carrying out the FPGA sampling. From his point of view, the sampling will then be at ~200MHz. Or maybe give him a barometer? HTH., Syms.Article: 125723
Symon wrote: > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:472a1dc0$1@clear.net.nz... > >>Matthew Hicks wrote: >> >>>Sounds like a homework restriction to me. >>> >> >>Perhaps this is a task for a 5ns delay line then ? >>The tutor may not have restricted those ;) >> >>-jg >> > > Hi Jim, > I think we may need to be more creative than that. I suggest accelerating > the tutor to about 0.866 times the speed of light while carrying out the > FPGA sampling. From his point of view, the sampling will then be at ~200MHz. > Or maybe give him a barometer? > HTH., Syms. and that gives me another idea -[just in case the tutor was smart enough to say no active components], the OP could use appx 1m of wire as a delay line. He'd need to measure and trim it to whatever precision was needed, but my rusty collection is ~200m/us (after velocity factor correction) - an "A" student would make a vernier screw sliding contact, allowing fine adjustments of the 5ns delay. -jgArticle: 125724
"fazulu deen" <fazulu.vlsi@gmail.com> wrote in message news:1193934339.923442.65740@q5g2000prf.googlegroups.com... > Dear all, > > Is it possible to implement power management unit(idle and active) in > FPGA? > > pls give suggestions to implement clock generation unit in FPGA.... > > regards, > fazal Is it possible to ask the question in a way that we can answer? Are you trying to control the FPGA from the FPGA? Control a procesor from the FPGA? Control a nuclear power pland from the FPGA? What kind of clock generation are you looking for? Please think about the kind of answer you want and ask the question in a way that's obvious what you're driving toward. Please. - John_H
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