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 27 Sep., 19:32, rickman <gnu...@gmail.com> wrote: > On Sep 23, 10:50 am, hei...@iname.com wrote: > > > > The low pass filter will not give you a sine wave. It will > > > approximate one, but with 20 MHz components on a 10 MHz signal, you > > > will not be able to fully filter it out. > > > Is that because the FPGA will not generate a perfect square wave? > > > I purchased a DAC but it seemed like a waste to send 8 bits at a time > > when there are really only two values. Anyway, thanks for the info. > > Why can't an FPGA output a "perfect" sine wave? > > It is because of the limitation of filters. If you output a "perfect" > square wave at 10 MHz, you will have harmonics at 30 MHz, 50 MHz, etc > (ignore my 20 MHz comment above). To get a good sine wave, you need > to reduce these harmonic levels by more than 20 dB and more like 40 > dB. To get 40 dB attenuation over a 3:1 frequency range requires one > heck of a good filter. That is why delta-sigma converters sample at > much higher rates and interpolate or decimate. By sampling at a freq > much higher than the signal frequency, filters can be designed to give > a better cut off. > > Rick with a three step wave, e.g. high, tristate,low, two resistors and the right timing it should be possible to get no 3rd harmonic -LasseArticle: 135351
thutt wrote: > doug <xx@xx.com> writes: > > >>thutt wrote: >> >>>David R Brooks <davebXXX@iinet.net.au> writes: >>> >>> >>>>thutt wrote: >>>> >>>> >>>>>Kevin Neilson <kevin_neilson@removethiscomcast.net> writes: >>>>> >>>>> >>>>> >>>>>>thutt wrote: >>>>>> >>>>>> >>>>>>>Hello everyone, >>>>>>>I'm tired of using the Xilinx ISE to look at RTL schematics, mainly >>> >>><snip> >>> >>>>>If there were a lookup table of initialization values to the standard >>>>>'and / or / xor'-type logic that each represents, then it would be >>>>>quite possible to write a script to make an external RTL viewer based >>>>>on the technology netlist output by the Xilinx tools. >>>>> >>>>>Anyone game for a little sleuthing to determine all the LUT init >>>>>codes? >>>>> >>>> >>>>It's a bit harder than that. Assume a LUT has 4 inputs (it varies >>>>with different FPGA families). The synthesiser (eg XST) will look >>>>for a piece of combinatorial logic with 4 inputs & 1 output. It then >>>>simulates that logic, evaluating its output for all 16 possible >>>>input combinations. The initialisation string is simply the map of >>>>those 16 outputs, written out in hex. So there really isn't an >>>>underlying logic representation: the designer might have specified >>>>any Boolean function whatever (adder, parity tree, etc): the >>>>synthesiser doesn't care. >>> >>>I'm more confused now. Somehow the LUT must correspond to some >>>concrete logic, and each LUT must be reconfigurable, right? >>>How does the netlist indicate what logic is implemented in the LUT? >>>If it's possible to determine that information, I'll be happy. >>> >> >>A LUT is a 16x1 memory. It implements the truth table of the logic. >>That is what is does. The memory contents tell you the truth table >>of the logic. > > > Your answer is not very descriptive. *HOW* do the memory contents > tell you the truth table? > It is a 16x1 memory. The four inputs are the adress bits. The output is the truth table. > Can one determine the memory contents from the initialization string? > > >>The details of the logic are unimportant, the output is important. >>That is what is implemented. > > > If you recall, my goal is only to produce a schematic of the RTL, so > the details of the logic *ARE* improtant to me. > If you want the bare logic for some reason, you need to work out a set of gates that give you the truth table. That may be a bit of work. You could work out a set of truth tables of all possible combinations of 1,2,3, and 4 inputs gates of all types in all combinations and then search that but it seems like a lot of work. > >>To make a schematic of this, just draw a 16x1 memory and list the >>memory contents. > > > Pray tell, how does one map the memory contents into the karnaugh map > or the logic equations? They have been collapsed into a truth table. It is up to you to try to get the logic gates back if it is important. The memory contents are much more descriptive of function since it has the truth table for the four inputs. > > thutt > http://www.harp-project.com/ >Article: 135352
<langwadt@fonz.dk> wrote in message news:d976369a-b3a5-4cc2-ac41-c5811e83dbe9@w7g2000hsa.googlegroups.com... > > with a three step wave, e.g. high, tristate,low, two resistors and the > right timing it > should be possible to get no 3rd harmonic > That third (and other) harmonics will still be there. KJArticle: 135353
Symon wrote: > have more than enable, and so the tool needs to be told which is the more than _one_ enableArticle: 135354
On Sep 26, 12:37=A0pm, jhal...@TheWorld.com (Joseph H Allen) wrote: > You have to use a > dedicated PLL feedback input pin for this to work. =A0This way is nice > because you can usually leave the PLL phase shift setting at 0. Thanks. This is a nice solution and I've used it on other projects. Unfortunately, I didn't design Terasic's DE2-70 dev kit and it doesn't have a feedback clock trace, so this isn't an option here. TommyArticle: 135355
Anybody got this in their library? Thanks!Article: 135356
On Sep 27, 9:20=A0pm, Totally_Lost <air_b...@yahoo.com> wrote: > Anybody got this in their library? > > Thanks! Mucho thanks for the email pointer to http://web.archive.org/web/20010821020414/http://www.insight-electronics.co= m/solutions/kits/xilinx/downloads/SpartanPCISchematics.PDF would still be nice to find a pdf users manual and ucf fileArticle: 135357
KJ, thanks for a detailed reply. It makes perfect sense, unfortunately as detailed below I'm not sure it's all feasible for me to do this analytically, but I feel more comfortable playing with phase shifting of the clock. On Sep 26, 12:14=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Sep 26, 2:34=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > First, all output are fully registered (and constrained to guarantee > > they stay registered). The main logic is clocked by a PLL. A second > > but identically configured output on this PLL drives the SSRAM. > > Keep in mind though that there can easily be different delays from > these two PLL outputs to the different destinations. Opps. I had assumed they were phase locked and that the screw between them would be small enough to ignore. Using just a single PLL doesn't seem like it would help (?) as the on-die clock might be offset from the clock at the pin. > You'll need to know... > - What is an achievable skew between the clock at the internal flops > and the clock as it is leaving your controller. Ok, but how do I find that? Browsing the Cyclone II data sheet didn't reveal anything useful (unless I missed it). >=A0In some sense it > doesn't matter too much what that actual skew is, but you need to know > what it is so that you can then add a timing constraint so that this > delay is always met, or flagged as a timing error for you. =A0For the > sake of an example, let's just say that that there is a skew of 1 ns > between the internal clock and the clock at the output of the FPGA. > Keep in mind that this skew will have both a minimum and a maximum so > the skew is really a range between those two extremes. > > - Net lengths and capacitive loading of the signals on the PCBA that > go between the two devices. Ough. While that makes perfect sense, I simply don't think I have enough information (or experience) to do that. Remember, this is an off-the-shelf development kit and the provided examples do not even use constraints. I do have the SSRAM datasheet which lists the Cin as 6 pF and Cout as 8 pF. Eyeballing the traces, they looks roughly an inch long (the SSRAM sits very close to the FPGA). >=A0What's important here is really > differences between the various SRAM inputs and the clock. =A0From that > you calculate an additional delay. Again, eyeballing it, the clock trace looks near identical to most of the data. >=A0Practically speaking, you most > likely have roughly equal net lengths and loading on all of the > signals and this is not going to be a concern, but you should at least > be aware of this as well. =A0Different parts may have different > capacitive loading so if you want to get nit picky this delay will > also be a range with a min and a max but that range will typically be > much smaller than the uncertainty with the FPGA. > > From the FPGA clock skew min/max add on the additional delay for > length/loading differences and now you have a known window of clock > uncertainty. =A0Now get a piece of paper and sketch out some waveforms > showing the min/max switching times of the control signals (i.e. > address, oe, write, data_in, data_out) as well as the setup/hold time > of both the SRAM and the FPGA (for the data coming back in). =A0Somebody > was advertising a free timing waveform tool out here a few months back > (I don't remember the name), that may help but it's not that difficult > to paper sketch it either. > > From all of that you should come out with a sketch that shows where > things need to be valid in order for the system to read and write > properly. =A0Adjust the nominal phase of the clock leaving the device > (or equivalently the FPGA internal clock) so that the clock occurs > (both min and max time) at a point where everything is stable. =A0Keep > in mind that as you shove the clock one way to improve setup time at > the SRAM, you're most likely stealing that from the setup time at the > FPGA when it is reading data back. Exactly. Which is why I was weary of the advice I found multiple places: phase shift the SSRAM clock by 180 degree. > There can also be other concerns like if the nets are long you'll get > ringing which distorts the waveforms which basically means that you'll > need to wait a longer for things to stabilize which cuts into the > allowable timing. =A0At 100 MHz, just 1 ns is 10% of the clock cycle > budget. =A0Whether or not that's an issue or not you'll need to > determine with a scope. Thankfully this board appears to be well designed. I can already hit 170 MHz with my simple solution, but I'd like to push it to the limit of the SRAM (200 MHz). > > Phase-shift the SSRAM clock? > > Yes > > > Specify it as a timing constraint? > > Yes > > > Do timing constraints influence the output buffer or are they purely fo= r > > checking? > > For the most part it's just checking, although it can affect place and > route as well. =A0I haven't seen a case where it affected the output > buffer itself (i.e. kicked up or down the drive strength) in order to > meet a constraint. =A0This is most likely because drive strength > considerations have a much larger impact than just timing. =A0It does go > the other way though, as you fiddle with drive strength the software > should take this into account when it does the timing analysis. > > Since it appears from your constraint that you're using Quartus, you > might want to put in numbers that are representative of the correct > capacitive loading as well as checking that the I/O drive strengths > are appropriate and not just the defaults (unless =A0you've already done > this). Ah, yes, I should do that. The pin capacitive loading I gave above. I'm not sure how much I should estimate for the short trace. The DC ELECTRICAL CHARACTERISTICS states this: Output HIGH Voltage min 2.4 V (test cond I_OH =3D -4 mA) Output LOW Voltage max 0.4 V (test cond I_OL =3D -8 mA) Input HIGH Voltage min 2.0 V Input LOW Voltage max 0.8 V Input Leakage [-5 uA; 5 uA] Output Leakage [-5 uA; 5 uA] but doesn't explicitly mention an IO standard. I assume that LVTTL (3.3 V) is a fine choice (the default?). Or is LVCMOS a better choice. I guess I have no idea of how to pick a suitable drive strength. Thanks again TommyArticle: 135358
"KJ" <kkjennings@sbcglobal.net> wrote in news:Y8wDk.1655$Ws1.508 @nlpi064.nbdc.sbc.com: > > <langwadt@fonz.dk> wrote in message > news:d976369a-b3a5-4cc2-ac41-c5811e83dbe9 @w7g2000hsa.googlegroups.com... >> >> with a three step wave, e.g. high, tristate,low, two resistors and the >> right timing it >> should be possible to get no 3rd harmonic >> > > That third (and other) harmonics will still be there. > > KJ Indeed! However, using two outputs with different weighting resistors it is (more or less) possible to eliminate the troublesome 3rd and 5th harmonics. Here is the output pattern for each cycle of the "sine wave": AB 10 11 11 10 01 00 00 01 The A output is weighted more strongly than the B output by a factor of (1 + sqrt(2)). Regards, AllanArticle: 135359
langwadt@fonz.dk wrote: > with a three step wave, e.g. high, tristate,low, two resistors and the > right timing it should be possible to get no 3rd harmonic Assuming you're using the two resistors to create the "bias" level for the tristate condition, yes, that could work, but the output impedance of such a circuit would be jumping all over the place, creating other issues. A better solution is to use two totem-pole square wave digital outputs, 60 degrees out of phase and a resistor from each one to the analog output node. The third harmonic (and *its* odd harmonics, such as 9th, 15th, etc.) will be cancelled completely, and the filter will just have to deal with the remaining ones, starting with the 5th and 7th. With more outputs and more resistors, you can generalize on this concept to cancel out more of the higher-order harmonics, although your ability to match the resistors and/or get the precise values you need limits how far you can practically take this scheme. For example, if you're using 1% resistors, the whole thing runs out of steam at about 13 outputs. I did an extensive writeup about this for the Circuit Cellar "EQ quiz" back in 2001, but unfortunately, it no longer seems to be available on the web. Draw yourself some phasor diagrams and it shows the principle pretty clearly. A simple way do drive such a circuit is with a "Johnson counter". -- Dave TweedArticle: 135360
On Sun, 28 Sep 2008 12:21:04 -0400, David Tweed <dtweed@acm.org> wrote: >I did an extensive writeup about this for the Circuit Cellar "EQ quiz" >back in 2001, but unfortunately, it no longer seems to be available on >the web. Draw yourself some phasor diagrams and it shows the principle >pretty clearly. A simple way do drive such a circuit is with a "Johnson >counter". > >-- Dave Tweed Is it this one: http://archive.chipcenter.com/circuitcellar/december01/c1201eq.htm?Article: 135361
On Sep 28, 1:52=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote: > KJ, thanks for a detailed reply. It makes perfect sense, unfortunately > as detailed below I'm not sure it's all feasible for me to do this > analytically, but I feel more comfortable playing with phase shifting > of the clock. > Well, the bottom line in the calculations will still be coming up with a phase shift of the clock so you're poking around at what the correct solution will be > > > Keep in mind though that there can easily be different delays from > > these two PLL outputs to the different destinations. > > Opps. I had assumed they were phase locked and that the screw between > them would be small enough to ignore. Using just a single PLL doesn't > seem like it would help (?) as the on-die clock might be offset from > the clock at the pin. > Some pins (actually one) will be better choices than others since they are intended to be used as a PLL output pin. Using other pins is not necessarily a problem, just that you'll get more skew and have somewhat less control of it. But as you've discovered, there must be some skew between the two otherwise your adjusting of the phase wouldn't have made any difference (and it did). > > You'll need to know... > > - What is an achievable skew between the clock at the internal flops > > and the clock as it is leaving your controller. > > Ok, but how do I find that? Browsing the Cyclone II data sheet didn't > reveal anything useful (unless I missed it). > Peruse the timing reports of your design. There should be something saying what the delay to the output pin that goes to the SRAM is. Here it can get a bit muddy depending on whether you're using the 'Classic' timing analyzer or 'TimeQuest' but what you're trying to determine should be in the timing reports. What you do with that delay min/max numbers is use it to set a timing constraint that it will now have to always meet and also use that constraint to figure out what the phase shift is needs to be on the internal clock so that everything hangs together. It may sound kind of backwards using the result of a run to figure out what the constraints needs to be but it's not really. Ideally you would like there to be 0ns skew at the clock output pin, but if the software can't deliver that then what? At the end of the day, the absolute value of the delay doesn't matter since that gets accomodated for by changing the PLL phase delay, what hurts the most is the difference between the min and the max of that delay (again, available from the timing reports). The spread between min and max is something that can't be designed around and is something that will be tighter if the 'pll_out' pin is used. I'm not sure if the board you're using did this, but it's easy enough to check...nothing you can do about it, but might be worth knowing. > > > - Net lengths and capacitive loading of the signals on the PCBA that > > go between the two devices. > > Ough. While that makes perfect sense, I simply don't think I have > enough information (or experience) to do that. Remember, this is an > off-the-shelf development kit and the provided examples do not even > use constraints. I do have the SSRAM datasheet which lists the Cin as > 6 pF and Cout as 8 pF. Eyeballing the traces, they looks roughly an > inch long (the SSRAM sits very close to the FPGA). > That's good. Trace delays is ~6 inch per ns so round trip delay from FPGA to SRAM and back (as you would have during an SRAM read) would be < 1/3 ns which is pretty small (~3% of the overall clock cycle). > >=A0What's important here is really > > differences between the various SRAM inputs and the clock. =A0From that > > you calculate an additional delay. > > Again, eyeballing it, the clock trace looks near identical to most of > the data. > That's good too. > > > From all of that you should come out with a sketch that shows where > > things need to be valid in order for the system to read and write > > properly. =A0Adjust the nominal phase of the clock leaving the device > > (or equivalently the FPGA internal clock) so that the clock occurs > > (both min and max time) at a point where everything is stable. =A0Keep > > in mind that as you shove the clock one way to improve setup time at > > the SRAM, you're most likely stealing that from the setup time at the > > FPGA when it is reading data back. > > Exactly. Which is why I was weary of the advice I found multiple > places: phase shift the SSRAM clock by 180 degree. > 180 degrees means you're inverting the clock. While that's an easy technique, giving up half of a 10 ns clock period will likely end up in still failing timing. It's best to figure out based on the Tco of the outputs, the skew of the clocks and the setup and hold times just where the clock can be placed. If it happens to be that an inverted clock would work, OK. If not, your analysis will show just where it can be placed. Again, ideally you would like the FPGA and the SRAM to both receive the clock at exactly the same time, that will give you the most margin. > > Thankfully this board appears to be well designed. I can already hit > 170 MHz with my simple solution, but I'd like to push it to the limit > of the SRAM (200 MHz). > Pushing to the limit usually just means that some extra analysis work is needed in order to make the design solid. That's all that is going on here. > > Since it appears from your constraint that you're using Quartus, you > > might want to put in numbers that are representative of the correct > > capacitive loading as well as checking that the I/O drive strengths > > are appropriate and not just the defaults (unless =A0you've already don= e > > this). > > Ah, yes, I should do that. The pin capacitive loading I gave above. > I'm not sure how much I should estimate for the short trace. The DC > ELECTRICAL CHARACTERISTICS states this: > > Output HIGH Voltage min 2.4 V (test cond I_OH =3D -4 mA) > Output LOW Voltage max 0.4 V (test cond I_OL =3D -8 mA) > Input HIGH Voltage min 2.0 V > Input LOW Voltage max 0.8 V > Input Leakage [-5 uA; 5 uA] > Output Leakage [-5 uA; 5 uA] > > but doesn't explicitly mention an IO standard. I assume that LVTTL > (3.3 V) is a fine choice (the default?). Or is LVCMOS a better choice. > > I guess I have no idea of how to pick a suitable drive strength. > LVTTL is the voltage standard (LVCMOS will be essentially the same). There is another setting for drive strength, look for something measured in mA. Since it sounds like the PCBA design has no obvious problems, set the drive strength to the max (likely 24mA). Kevin JenningsArticle: 135362
Muzaffer Kal wrote: > On Sun, 28 Sep 2008 12:21:04 -0400, David Tweed <dtweed@acm.org> > wrote: >> I did an extensive writeup about this for the Circuit Cellar "EQ quiz" >> back in 2001, but unfortunately, it no longer seems to be available on >> the web. Draw yourself some phasor diagrams and it shows the principle >> pretty clearly. A simple way do drive such a circuit is with a "Johnson >> counter". > > Is it this one: > http://archive.chipcenter.com/circuitcellar/december01/c1201eq.htm? Yes, that's it. Thanks! I'll have to update some links ... -- Dave TweedArticle: 135363
jhallen@TheWorld.com (Joseph H Allen) wrote: >There are a number of ways to do this. Here is one way: > >What you usually want is for the clock at the pin of the SRAM chip to rise >at the same time as the FPGA internal global clock driving the output pads. > >A way to do this is to route the clock from the second PLL to two output >pins (right next to each other). One pin goes to the SSRAM. The other pin >goes to the feedback input of the PLL. The trace length for this feedback >line should be the same as the one which goes to the RAM. You have to use a >dedicated PLL feedback input pin for this to work. This way is nice because >you can usually leave the PLL phase shift setting at 0. This is quite cumbersome and the PLL will add extra jitter (clock uncertainty). An easier way without the extra jitter is to use an output flipflop (aka DDR flipflop) which can be clocked using 2 clocks. The first clock sets the output, the second clock (inverted first clock) resets the output. And presto, you'll have a clock output which is (within pin-to-pin skew) perfectly synchronous to the other outputs. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 135364
"Nico Coesel" <nico@puntnl.niks> wrote in message news:48dfe4ee.168426254@news.planet.nl... > jhallen@TheWorld.com (Joseph H Allen) wrote: > > An easier way without the extra jitter is to use an > output flipflop (aka DDR flipflop) which can be clocked using 2 > clocks. The first clock sets the output, the second clock (inverted > first clock) resets the output. And presto, you'll have a clock output > which is (within pin-to-pin skew) perfectly synchronous to the other > outputs. > Hold time requirements (like the .4ns in the OP) will be impossible to guarantee with this method though. KJArticle: 135365
Hello All, Please i am doing a research that invloves PLD's. Can one please tell me the difference between a PLD whether( FPGA,CPLD,GAL or PAL) and a general purpose CPUArticle: 135366
Guys,
I am designing a conventional Digital down converter on virtex
-4 Sx55 FPGA for GSM applications.
The Input clock frequency is above 160 Mhz for the initial CIC
decimation filter. After decimation , the data is fed to low pass
filter at a very low rate of ~1 Mhz
The issue is ,I am not able to generate this low frequency clcok with
Virtex -4 DCM , obviously the min output frequency is 32 Mhz.
After I looked into the previous threads , i dont feel its a clean way
to generate the divided clock by internal clock divider or clock
gating circuit in FPGA .
Can anyone let me know any other way of generating the low frequency
clock or is it safe to use internal clock divider considering my
asynchronous design ( FIFO between each filter stage) ?
Iam using the latest FIR compiler to generate the LP filter core. but
i do see the option of input sample per no of clock cycles in
previous Distributed FIR core which made life easy. but the FIR
compiler core doesnt have this option.
Please advice
Thanks in Advance
Vijay
Article: 135367Vjay, If you need to generate a low frequency that is an integer fraction of your incoming clock frequency, then you just build a synchronous divider, and you get an output frequency that has its edges aligned with your incoming clock, but one clock-to-Q delay later. Your concern may be the phase alignment between the fast clock and the slow clock. If that is critical, just use the synchronous integer divider, and rely on the fact thet the edges of the slow frequency are very slightly later than the rising edge of the high frequency, say 2 or 3 ns max. You might alteratively use the fast clock to also do the slow clocking, but with a control signal disabling the clock most of the time. That gives you a totally synchronous system (with slightly higher power consumption) If the ratio is not an integer, then you can use the DCM to do some multiply/divide operation, followed up by an integer divider, For example, you can use the DCM to multiply 160 MHz by 17 and simultaneously divide it by 27, and follow that up by any integer division. Obviously, the phase relationship between the clocks is then an unontrolled variable, but that is unavoidably part of your assumptions. Peter Alfke, on Sunday watch from home. Old habits never die.Article: 135368
On 27 Wrz, 21:02, "Kappa" <NO_SPAM_78kapp...@virgilio.it_NO_SPAM> wrote: > Hi Jerzy Gbur. > > > I'm not sure I understood. But what I propose is, for narrow band set, > > for example [0 - 511 Data] [512 - 1535 Nul] [1536 - 2047 Data], It > > depend what band you exactly want. > > Lenght of IFFT transform should stay the same. > > I still do not understand ... how can I reduce the number of carriers if I > have to maintain a "Standard" ? > I'm sorry. You can't maintain a standard that way, I thougt you are building own system, undependly of standards. You have to switch clock. Regards, Jerzy GburArticle: 135369
On 29 Sep., 04:05, onwuka.ar...@gmail.com wrote: > Hello All, > > Please i am doing a research that invloves PLD's. Can one please tell > me the difference between a PLD whether( FPGA,CPLD,GAL or PAL) and a > general purpose CPU The CPU uses instructions of a few bits (4 to 64 bits, depending on the architecture) to configure its behaviour on a cycle by cycle basis. Only a few specialized operations like additons and comparisons can be performed in every cycle. Complex behaviour is obtained by issuing billions of these simple instructions per second. An FPGA is configured using a few million bits that can describe almost arbitrary behaviour in much detail. This can be seen as one big complex instruction. However, a conventional FPGA is then bound to this instruction (called configuration) and executes the same instruction over and over again. Issuing a new instruction takes tens of milliseconds. There have been experimental FPGAs (e.g. DPGA at MIT) that allow to switch between a small number of instructions on a cycle to cycle basis. Kolja SulimmaArticle: 135370
vlodiya@gmail.com wrote: > Guys, > > I am designing a conventional Digital down converter on virtex > -4 Sx55 FPGA for GSM applications. > > The Input clock frequency is above 160 Mhz for the initial CIC > decimation filter. After decimation , the data is fed to low pass > filter at a very low rate of ~1 Mhz > > The issue is ,I am not able to generate this low frequency clcok with > Virtex -4 DCM , obviously the min output frequency is 32 Mhz. > Hi Vijay, You don't need to generate a 1MHz clock, instead you should generate a 1MHz clock enable for the parts of your design that run at 1MHz. The whole design is clocked at 160MHz, but the slow part is only enabled for one cycle in 160. This makes it a trivial task to pass data between the domains of the design. Cheers, Syms.Article: 135371
I've been tasked to write some code for an FPGA to interface to 10BASE- T Ethernet using differential drivers and receivers. The information is one way, transmit only! I will have an IP address within the network range, give myself a MAC number and know the MAC and IP address of the destination PC. Do I require any ARP or any other protocol? Will it just work, with the destination PC receiving UDP packets? FredArticle: 135372
Hi, On Mon, 2008-09-29 at 08:10 -0700, Fred wrote: > Do I require any ARP or any other protocol? Will it just work, with > the destination PC receiving UDP packets? You have to include the FPGA host (mac and ip) into the ARP table of the host PC. Then you didn't need to implement the ARP protocol. BenArticle: 135373
Fred wrote: > I've been tasked to write some code for an FPGA to interface to > 10BASE- T Ethernet using differential drivers and receivers. > http://www.fpga4fun.com/10BASE-T.htmlArticle: 135374
On Sep 29, 11:15 am, Benjamin Krill <b...@codiert.org> wrote: > You have to include the FPGA host (mac and ip) into the ARP table of the > host PC. Then you didn't need to implement the ARP protocol. I don't think that will be needed, since the PC is not expected to reply. I suppose there might be software on the PC that would consider this "traffic from nowhere" suspicious and possibly forged, but that's a configuration problem, not a fundamental one.
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