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
Each of the clock signals is LOCed to a dedicated clock IO pin. So I went in with the FPGA editor to do a little more investigation, and it sure looked like I could just pipe the clock signals from their points of origin to the proper BUFG with no problems. I tried LOCing them down in the UCF and rebuilding, and came up with the excitingly new error of: --- ERROR:Place:1023 - A global clock component <INST_PLL/BUF10/BUFGMUX> configured as a selectable mux is placed in site BUFGMUX6. This configuration requires that the global clock site BUFGMUX7 either be empty or contain a global buffer or mux with the inputs IN0 and IN1 either not driven by a signal or driven by the same signals as the original muxes IN1 and IN0 pins respectively in order to route up both of the inputs. In other words the input signal for IN0 on one buffer must be the same as the input signal driving IN1 on the other buffer (or one of them must not be driven) to place the two buffers in the paired sites. The site BUFGMUX7 has the global buffer <io_clk_BUFG> placed there. This design is unroutable. --- That finally gave me enough information to figure it out. In looking a little more closely at it, the problem seems to be the use of a BUFGCE on the 10 MHz clock. It looks like the Spartan requires adjacent pairs of BUFGMUXes to share the same two input clocks. Trying to make that pair accept CLK20, CLK10, and GLOBAL_LOGIC_0 as potential input clocks was too much for it. Since the logic on the CLK10 path had to be runt-resistant anyhow to handle the case where the 10 MHz clock was suddenly disconnected, I can just switch that over to a regular BUFG rather than a BUFGCE, and live with the runts when the clock is suddenly connected too. Thanks for the help, guys. -- Rob Marvin wrote: > Rob, > > Did you LOC your IOs down? Each BUFG has a dedicated IO that should > be used. A list of these IO locations are available from the Spartan > 3 User Guide. If you LOC the IO to one of the non-dedicated IOs, this > error message will appear. > > Marvin > > On May 8, 4:44 pm, John_H <newsgr...@johnhandwork.com> wrote: >> Rob Gaddi wrote: >> >>> Three of them (including the one throwing the error and the one with the >>> DCM on it) are along the top of the chip (CLK4, CLK6, and CLK7 pins) >>> The fourth is down on the bottom on CLK0. >> <snip> >> >> So are you going to look into the FPGA Editor view like I suggested? >> >> Another question for you to ponder much more than to answer here: did >> you instantiate the BUFGMUX primitives or are those coming from your >> synthesizer? It may be that you need to hook up the I1 channel rather >> than the I0 on one or two of your BUFGMUXs to work with the routing >> from the clock pins to the buffers... which is why I suggested looking >> at the details of the part in FPGA Editor. >> >> - John_H > -- -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 132001
On May 8, 11:29=A0am, austin <aus...@xilinx.com> wrote: > jon, > > Unauthorized distributors are likely to have slower parts re-marked as > faster parts so they can gouge you for more money.... > > -6 is the slowest, so maybe you won't have that problem. > > Or, devices that look like our parts, but are empty inside, or just > remarked garbage (non-functional). > > This is the most common results we have seen when we have looked into > these "sources." > > I am also concerned that we made a gift of Virtex E to Universities a > long time ago. > > These devices were "not suitable for commercial use" ... > > Caveat Emptor! > > Austin Austin, Thanks for the heads up. I am aware of what some of these companies are doing and have taken it to the extreme as to purchase an x-ray machine. The parts that you donated to a University, were they engineering samples? Do you know if the engineering samples meet full spec? I am very aware, but want to at least look at possible options. Do you know of a legitimate OEM/CM that has over bought on these? You would be helping us both out and keeping legitimate product in the marketplace. Regards, Jon E. HansenArticle: 132002
Jon, I believe the parts that were donated had normal production markings. And, no, I know of no legitimate holder of material (Xilinx does not recognize resellers, as we have lost the chain of control), other than our authorized distributors. AustinArticle: 132003
John_H wrote: > maverick wrote: > >>Hi, >>I am using a Spartan3 xc3s1000-4 fg456 FPGA. I have an oscillator >>which gives clk output at 5V p-p swing. I am using the FPGA in LVTTL >>mode which works on 3.3 V signaling. Is it OK to feed the 5V clock to >>one of the GCLK pins of the Spartan 3 FPGA? Should I put a current >>limiting resistor in the clock path before I feed it to the GCLK pin? >>Any issues with that? >> >>Best Wishes, >>Farhan > > > I just got a 3.3V oscillator driving a 2.5V input working. The > oscillator has miserable drive capability and I suspect the 5V > oscillator you're using may have poor drive capability as well. > > Unless you have a rare high-drive oscillator OR if you're oscillating > at a leisurely rate, do like the FPGA vendor recommends: use a 100 ohm > series resistor. > > If you use a resistor divider, your parasitics can severely slow down > your edges. Our 125 MHz oscillator looked almost like a sine wave and > was reduced in amplitude to the point we were getting 25% duty cycle. > Not good for our application. If it was a 20 MHz oscillator, the > resitor divider would probably be fine. If we could deal with 25% > duty cycle we could have probably used what was there. The series > resistor just plain works. The input protection on the Spartan3 is > pretty robust so you can drive the many milliamps (if you have many > milliamps) into the protection diode without affecting reliability. > > If I wanted to be detailed, I'd understand the drive capability, the > frequency, and the parasitics involved. Or, think like a scope probe, and do a capacitive divider, That preserves the edges, and allows higher value resistors (so saves power) Measure the pin/pcb capacitance, and Osc output swing, and then calculate the driving capacitance, likely to be in tne 30-40pF region. Or, add a LVC1G57/58/97/98 to your parts list, and use that. -jgArticle: 132004
http://syndicated.synplicity.com/Q306/aldec.html ngc2edif will not extract encrypted cores. Is it perfectly secure? I'll leave that answer as an exercise for the reader.... 'Greg On May 9, 12:26 am, "fpganut" <r...@myhouse.com> wrote: > Hi, > > Is there anyway to secure a Xilinx NGC file from being reverse engineered ? > Xilinx has a ngc2edif utility to convert the binary ngc file into a > readable netlist. > Still work of course but makes it a lot easier to copy a design. > > So anyway to secure a NGC file ? > > Thanks. > > JimArticle: 132005
"KJ" <kkjennings@sbcglobal.net> wrote in message news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com... >On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote: > >> A better solution would be to feed the clock through a 3.3V buffer that >> is >> 5V tolerant. An AHC family device would do the job I think. In fact, a >> 74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin >> package.- Hide quoted text - > > By what measure would an IC be a "better solution" than two resistors? > KJ Static drive current. Assuming the divider is matched to the impedance of the trace, as originally suggested, the oscillator would need to source and sink around 100 mA.Article: 132006
KJ wrote: > On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote: > > >>A better solution would be to feed the clock through a 3.3V buffer that is >>5V tolerant. An AHC family device would do the job I think. In fact, a >>74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin >>package.- Hide quoted text - >> > > > By what measure would an IC be a "better solution" than two resistors? You don't want slow clock transitions, and high drive impedances at the receiving end. Now, the right choice of resistors probably won't cause such trouble, but it at least needs to be considered. A long clock trace (bad idea, anyway) fed with a series resistor is essentially a lumped-constant low-pass filter. I'm not sure how fast Spartan III is, but if the Tr got slowed to tens of nS it would be really dangerous. Just add a little on-chip or on-board noise, and you have extra clock transitions. I've seen this on a 5V Spartan setup that got its clock from an LVDS receiver. Some reflections on the LVDS cable caused multiple clocks that the Spartan FFs responded to. I'm sure this would only be more sensitive on Spartan 3. I just did a board that had a bunch of logic turned upside down (-5 V and ground) and used resistive networks with matching caps across the series resistor to keep the edges sharp. This had to be done some 70 places on the board, and there's no suitable chip for such a conversion. It worked, but had me sweating until proven. JonArticle: 132007
Fred, ngd does not have placement information, I think you are referring to ncd. Beginning w/ ISE 10.1 PlanAhead is shipped with all versions of ISE, including the webpack (free) version. Prior to that PlanAhead was a separate optional tool, but evaluation licenses are readily available for the asking: http://www.xilinx.com/ise/optional_prod/planahead.htm PlanAhead is a fairly straightforward tool to use. At a high level, to do what you are asking: 1) download and install planAhead 2) create a project by importing an edif/ngc netlist and optionally ucf constraints (and pick a target device if ngc). 3) File->Import Placement and browse to your placed and/or routed ncd file This will import placement from an ncd file and convert them to LOC and BEL constraints. At this point you have tons of options, depending on what you are trying to accomplish. You can go to File->Export Floorplan to write out all these loc/bels into a ucf file, but a huge file of locs is of limited use, for floorplanning, timing closure, ip reuse flows. Take a look at the PlanAhead tutorial and methodology guides, as a starting point. More questions will doubtlessly follow... 'Greg On May 9, 11:14 am, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > Fred wrote: > > Is there any NGD reader which can extract placement information? > > > I know I can use FPGA editor and go through all the primitives, one by > > one, but this would be a mamoth task! Any ideas? > > Are you trying to floorplan or trying to figure out how PAR performed > placement? If the former, PlanAhead is a very nice tool for > floorplanning. -KevinArticle: 132008
On May 9, 1:51=A0pm, "David Spencer" <davidmspen...@verizon.net> wrote: > "KJ" <kkjenni...@sbcglobal.net> wrote in message > > news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com... > > >On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote: > > >> A better solution would be to feed the clock through a 3.3V buffer that= > >> is > >> 5V tolerant. An AHC family device would do the job I think. In fact, a > >> 74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin > >> package.- Hide quoted text - > > > By what measure would an IC be a "better solution" than two resistors? > > KJ > > Static drive current. > > Assuming the divider is matched to the impedance of the trace, as original= ly > suggested, the oscillator would need to source and sink around 100 mA. Make that 50 mA, if the series resistor is 50 Ohm, and the parallel destination termination another 50 Ohm. Peter AlfkeArticle: 132009
"David Spencer" <davidmspencer@verizon.net> wrote in message news:WO2Vj.1895$Uz2.1141@trnddc06... > "KJ" <kkjennings@sbcglobal.net> wrote in message > news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com... >>On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote: > >> >>> A better solution would be to feed the clock through a 3.3V buffer that >>> is >>> 5V tolerant. An AHC family device would do the job I think. In fact, a >>> 74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin >>> package.- Hide quoted text - >> > >> By what measure would an IC be a "better solution" than two resistors? > >> KJ > > Static drive current. > > Assuming the divider is matched to the impedance of the trace, as > originally suggested, the oscillator would need to source and sink around > 100 mA. > Oscillator outputs typically can't drive PCB trace impedance types of values (i.e. 50-100 ohm) anyway so you wouldn't terminate it with that low of a resistor value. Instead you would use something quite a bit higher so that you would get the edge quality that you need and the divider to limit the input voltage to the part. The 5<-> 3.3V ICs are nice when you have a bunch of signals that need translating (like a bus) but if it's just a single net (or a small handful) the resistors work nicely....of course it begs the question of why not use a 3.3V oscillator in the first place. KJArticle: 132010
"maverick" <sheikh.m.farhan@gmail.com> wrote in message news:867bdf28-6f10-4dd4-a00b-dc5f9cae4de7@m44g2000hsc.googlegroups.com... > Hi, > I am using a Spartan3 xc3s1000-4 fg456 FPGA. I have an oscillator > which gives clk output at 5V p-p swing. I am using the FPGA in LVTTL > mode which works on 3.3 V signaling. Is it OK to feed the 5V clock to > one of the GCLK pins of the Spartan 3 FPGA? Should I put a current > limiting resistor in the clock path before I feed it to the GCLK pin? > Any issues with that? > Any reason why you wouldn't just use an oscillator that has a 3.3V swing to begin with? KJArticle: 132011
"Jon Elson" <elson@wustl.edu> wrote in message news:4824C322.9000505@wustl.edu... > > > KJ wrote: >> On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote: >> >> >>>A better solution would be to feed the clock through a 3.3V buffer that >>>is >>>5V tolerant. An AHC family device would do the job I think. In fact, a >>>74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin >>>package.- Hide quoted text - >>> >> >> >> By what measure would an IC be a "better solution" than two resistors? > You don't want slow clock transitions, and high drive impedances at > the receiving end. Now, the right choice of resistors probably won't > cause such trouble, but it at least needs to be considered. I was answering within the context of what info the original poster provided which was that he has a 5V signal going into a 3.3V tolerant input. No mention of any other similar signals that might also be problems, or that the clock is a long distance away or anything, just looking for a way to use (for some unknown reason) a 5V osc into a 3.3V tolerant part. > A long clock trace (bad idea, anyway) fed with a series resistor is > essentially a lumped-constant low-pass filter. I'm not sure how fast > Spartan III is, but if the Tr got slowed to tens of nS it would be really > dangerous. The same can happen with any driver. An electrically long net will need to be terminated KJArticle: 132012
On May 9, 2:33=A0pm, Jon Elson <el...@wustl.edu> wrote: > KJ wrote: > > On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote: > > >>A better solution would be to feed the clock through a 3.3V buffer that = is > >>5V tolerant. An AHC family device would do the job I think. In fact, a > >>74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin > >>package.- Hide quoted text - > > > By what measure would an IC be a "better solution" than two resistors? > > You don't want slow clock transitions, and high drive impedances at > the receiving end. =A0Now, the right choice of resistors probably won't > cause such trouble, but it at least needs to be considered. =A0A long > clock trace (bad idea, anyway) fed with a series resistor is essentially > a lumped-constant low-pass filter. =A0I'm not sure how fast Spartan III > is, but if the Tr got slowed to tens of nS it would be really dangerous. > Just add a little on-chip or on-board noise, and you have extra clock > transitions. =A0I've seen this on a 5V Spartan setup that got its clock > from an LVDS receiver. =A0Some reflections on the LVDS cable caused > multiple clocks that the Spartan FFs responded to. =A0I'm sure this would > only be more sensitive on Spartan 3. > > I just did a board that had a bunch of logic turned upside down (-5 V > and ground) and used resistive networks with matching caps across the > series resistor to keep the edges sharp. =A0This had to be done some > 70 places on the board, and there's no suitable chip for such a > conversion. =A0It worked, but had me sweating until proven. > > Jon When you series-terminate the driver, and parallel-terminate the receiver, each with a resistor that equals the characteristic impedance of the clock trace, then a fast transition sees just a resistive divider, not a lumped capacitance. That's the beauty of terminated transmission lines... Peter AlfkeArticle: 132013
Peter Alfke wrote: > > When you series-terminate the driver, and parallel-terminate the > receiver, each with a resistor that equals the characteristic > impedance of the clock trace, then a fast transition sees just a > resistive divider, not a lumped capacitance. > That's the beauty of terminated transmission lines... That's true, until it bangs into the lumped input capacitance of the FPGA. You also get a voltage-loss with this focus on transmission line matching, which might give noise margin issues, as well as Buffer Current adders, from the lower Vih. -jgArticle: 132014
On May 9, 5:19=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Peter Alfke wrote: > > > When you series-terminate the driver, and parallel-terminate the > > receiver, each with a resistor that equals the characteristic > > impedance of the clock trace, then a fast transition sees just a > > resistive divider, not a lumped capacitance. > > That's the beauty of terminated transmission lines... > > That's true, until it bangs into the lumped input capacitance of the > FPGA. > You also get a voltage-loss with this focus on transmission > line matching, which might give noise margin issues, as > well as Buffer Current adders, from the lower Vih. > > -jg Let's not forget: "Voltage loss" was the purpose of the whole exercise... PeterArticle: 132015
Peter Alfke wrote: > On May 9, 5:19 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>Peter Alfke wrote: >> >> >>>When you series-terminate the driver, and parallel-terminate the >>>receiver, each with a resistor that equals the characteristic >>>impedance of the clock trace, then a fast transition sees just a >>>resistive divider, not a lumped capacitance. >>>That's the beauty of terminated transmission lines... >> >>That's true, until it bangs into the lumped input capacitance of the >>FPGA. >>You also get a voltage-loss with this focus on transmission >>line matching, which might give noise margin issues, as >>well as Buffer Current adders, from the lower Vih. >> >>-jg > > > Let's not forget: "Voltage loss" was the purpose of the whole > exercise... > Peter I should have been clearer : Equal Source/Load terminations will turn the 5V swing into 2.5V Hi, on a 3.3V system. The ideal Vih is 3.3V, (lowest power, best noise immunity), so this is a lower Vih, which was the 'voltage loss' I was getting at. -jgArticle: 132016
On May 9, 7:57=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Peter Alfke wrote: > > On May 9, 5:19 pm, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>Peter Alfke wrote: > > >>>When you series-terminate the driver, and parallel-terminate the > >>>receiver, each with a resistor that equals the characteristic > >>>impedance of the clock trace, then a fast transition sees just a > >>>resistive divider, not a lumped capacitance. > >>>That's the beauty of terminated transmission lines... > > >>That's true, until it bangs into the lumped input capacitance of the > >>FPGA. > >>You also get a voltage-loss with this focus on transmission > >>line matching, which might give noise margin issues, as > >>well as Buffer Current adders, from the lower Vih. > > >>-jg > > > Let's not forget: "Voltage loss" was the purpose of the whole > > exercise... > > Peter > > I should have been clearer : > Equal Source/Load terminations will turn the 5V swing into 2.5V Hi, on a > 3.3V system. > The ideal Vih is 3.3V, (lowest power, best noise immunity), so this > is a lower Vih, which was the 'voltage loss' I was getting at. > > -jg So let's reduce the series resistor at the source to 25 Ohm, and keep the parallel termination at the destination at 50 Ohm. That puts 2/3 of Vcc on the cable and the FPGA input =3D 3.3 V. The 25 Ohm includes the drive impedance, which might mean no external series resistor at all... PeterArticle: 132017
KJ wrote: > "maverick" <sheikh.m.farhan@gmail.com> wrote in message > news:867bdf28-6f10-4dd4-a00b-dc5f9cae4de7@m44g2000hsc.googlegroups.com... >> Hi, >> I am using a Spartan3 xc3s1000-4 fg456 FPGA. I have an oscillator >> which gives clk output at 5V p-p swing. I am using the FPGA in LVTTL >> mode which works on 3.3 V signaling. Is it OK to feed the 5V clock to >> one of the GCLK pins of the Spartan 3 FPGA? Should I put a current >> limiting resistor in the clock path before I feed it to the GCLK pin? >> Any issues with that? >> > > Any reason why you wouldn't just use an oscillator that has a 3.3V swing to > begin with? > > KJ > > Or even better, for a little more money you could use an oscillator with differential LVDS or LVPECL output. Differential signalling would reduce jitter and EMI.Article: 132018
Hi ,everyone,now I use the NicheStack tcp/ip stack for sending and
receiving the udp packets, the hardware platform is as follows,cyc-II
70 ,nios-ii,lan91c111 and so on.the receive code is as follows.
void RecvData(int socket)
{
INT8U rx_buf[1024];
INT8U *rx_buf_pos;
int recv_len;
struct sockaddr_in from_addr;
int fromLen = 100;
rx_buf_pos = rx_buf;
recv_len = recvfrom(socket,rx_buf,100,0,(struct
sockaddr*)&from_addr,&fromLen);
//recv_len = recv(recv_socket,rx_buf,sizeof(rx_buf),0);
if(recv_len == SOCKET_ERROR)
{
printf("Socket error!!\n");
}
else
{
printf("receive %d bytes from 192.168.1.2\n",recv_len);
}
}
the send packet is normal but the receive code seem to be something
wrong,It doesn't work,if the packet is short the funciton doesn't have
any return,if the packet upto 1024 bytes,the console continuous print
"Your Ethernet MAC address is 00:50:04:ee:0a:0d
Static IP Address is 192.168.1.3"
Another strage phenomenon is that the tcp/ip stack will be failed to
initialize if I remove the second line in the follow task
void SSSSimpleSocketServerTask()
{
int send_socket;
static SSSConn conn;
struct sockaddr_in far_addr;
struct sockaddr_in local_addr;
int recv_socket;
............................
}
And the conn is not used in this task,I don't know why,all the data
code is changed based the simple socket server demo code.
Can anyone give any advice,Thanks!
Article: 132019Peter Alfke wrote: (snip, I wrote) >>I like the clocked design that Peter A. has in another post. >>I believe that one works as long as the clock is faster than >>the fastest possible real count. Bounces might be missed, but >>the count will be right. > Bounces should (or must) be missed.. > That's the whole purpose of the circuit .:-) If it bounces long enough, up to the next clock pulse, it won't be missed. As long as the extra counts come in matched (up and down) pairs, the count is right. -- glenArticle: 132020
"austin" <austin@xilinx.com> wrote in message news:g022gp$p032@cnn.xsj.xilinx.com... > Jim, > > Copying the bitstream is trivial, so why bother with the NGC? Copying is fine. I don't care about copies. > > What is the vulnerability you are analyzing? I have some circuits implementing some unique algorithms. I don't want someone to figure out the algorithm by extracting the circuit and figuring out how it operates. > > Who is your threat? (a major government, or an individual hacker...) A motivated competitor. Thanks. Jim > > Not knowing what you are trying to protect (and why), we can't provide > you with an answer. > > AustinArticle: 132021
Conversion from VERILOG READMEMB to INTEL HEX http://bknpk.no-ip.biz/readmemb_to_intel_hex/readmemb_to_intel_hex.htmlArticle: 132022
Peter Alfke wrote: > On May 9, 7:57 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>Peter Alfke wrote: >> >>>On May 9, 5:19 pm, Jim Granville <no.s...@designtools.maps.co.nz> >>>wrote: >> >>>>Peter Alfke wrote: >> >>>>>When you series-terminate the driver, and parallel-terminate the >>>>>receiver, each with a resistor that equals the characteristic >>>>>impedance of the clock trace, then a fast transition sees just a >>>>>resistive divider, not a lumped capacitance. >>>>>That's the beauty of terminated transmission lines... >> >>>>That's true, until it bangs into the lumped input capacitance of the >>>>FPGA. >>>>You also get a voltage-loss with this focus on transmission >>>>line matching, which might give noise margin issues, as >>>>well as Buffer Current adders, from the lower Vih. >> >>>>-jg >> >>>Let's not forget: "Voltage loss" was the purpose of the whole >>>exercise... >>>Peter >> >>I should have been clearer : >>Equal Source/Load terminations will turn the 5V swing into 2.5V Hi, on a >>3.3V system. >>The ideal Vih is 3.3V, (lowest power, best noise immunity), so this >>is a lower Vih, which was the 'voltage loss' I was getting at. >> >>-jg > > > So let's reduce the series resistor at the source to 25 Ohm, and keep > the parallel termination at the destination at 50 Ohm. > That puts 2/3 of Vcc on the cable and the FPGA input = 3.3 V. The 25 > Ohm includes the drive impedance, which might mean no external series > resistor at all... > Peter Yes, that would work, However.... # You are no longer doing strict series-impedance-match termination # One can tell you are used to high-power FPGAs ;) - as this sugestion adds a cost of 33mA in power budget (@50% clk duty cycle). Suppose the target was a Zero power CPLD ? The whole device Icc might be 14.6mA at 200Mhz - 7.5mA @ 100MHz. [OP did not mention speed, but 5V sources are << 100Mhz ] The clock-terminator is consuming far more power than the CPLD ! -jgArticle: 132023
glen herrmannsfeldt wrote: > Peter Alfke wrote: > (snip, I wrote) > >>> I like the clocked design that Peter A. has in another post. >>> I believe that one works as long as the clock is faster than >>> the fastest possible real count. Bounces might be missed, but >>> the count will be right. > > >> Bounces should (or must) be missed.. >> That's the whole purpose of the circuit .:-) > > > If it bounces long enough, up to the next clock pulse, > it won't be missed. As long as the extra counts come > in matched (up and down) pairs, the count is right. Correct. Peter has published a partial VHDL source, and the design he is talking about uses what I'd call an anti-Chatter-Filter, which is a back-lash state engine that uses hand-over edges. That could be a good idea on a user-interface, (less flicker effects) but could be a bad idea on a closed loop control system driven from a rotary encoder. -jgArticle: 132024
I invite you to use free code of a USB full speed project as final work for diploma. The site includes some description of the functionality and main state machines. The code is based on some free cores 8051 and USB function. The PHY is my own code. http://bknpk.no-ip.biz/usb_invitation_for_final_pj.html
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