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
Symon wrote: >> > > Dear Nana Nmichou, > You could display the data on a monitor driven by the XSGA port of one > board, and use a USB webcam to read the data back into the other board. > HTH, Syms. > > Gee Symon, why not drive a paper tape punch with one board and then run the tape through a paper tape reader to get it into the other one.Article: 112051
Ray Andraka wrote: > Symon wrote: > > >> > > > > Dear Nana Nmichou, > > You could display the data on a monitor driven by the XSGA port of one > > board, and use a USB webcam to read the data back into the other board. > > HTH, Syms. > > > > > > Gee Symon, why not drive a paper tape punch with one board and then run > the tape through a paper tape reader to get it into the other one. I don't think this board has a paper tape reader/punch interface. I guess you could implement your own by emulating a PC parallel port, but that would require work while the video/USB interfaces are available as IP. ;^)Article: 112052
On 2006-11-15, tclin1998@gmail.com <tclin1998@gmail.com> wrote: > Hi All: > > Could anyone point me where can I get an example of VCD file? > Or you have one and willing to share? > > I need one to learn gkWave. I put up one at http://www.da.isy.liu.se/~ehliar/stuff/vga.vcd.gz (Some waveforms from a very simple vga module I used when I played around with gtkwave and icarus.) /AndreasArticle: 112053
"rickman" <gnuarm@gmail.com> wrote in message news:1163611134.424119.44610@i42g2000cwa.googlegroups.com... > Ray Andraka wrote: >> Symon wrote: >> >> > >> > Dear Nana Nmichou, >> > You could display the data on a monitor driven by the XSGA port of one >> > board, and use a USB webcam to read the data back into the other board. >> > HTH, Syms. >> > >> > >> >> Gee Symon, why not drive a paper tape punch with one board and then run >> the tape through a paper tape reader to get it into the other one. > > I don't think this board has a paper tape reader/punch interface. I > guess you could implement your own by emulating a PC parallel port, but > that would require work while the video/USB interfaces are available as > IP. > > ;^) > Exactly. Thanks Rick! At first, I was going to suggest writing the data to a DDR SDRAM DIMM and then swapping the DIMM _really_ quickly to the other board. But that's obviously daft. ;-)Article: 112054
I've inherited a tray of TQFP Spartan-2 (XC2S50, standard performance version) with date code from mid-2001. Is it worth my while to put these down on prototypes, or have there been significant silicon changes since then/has this family been slated for discontinuation? Thanks.Article: 112055
If you inherited a box of the "pocket PCs" mid-2001, would you use those in your systems? If your need is limited to stock on hand and the performance you get from them is sufficient, I'd say "go for it" but if you end up purchasing more of these devices in the long run, you'll probably be MUCH better with a current generation device. The performance is better. The density is significantly greater. The tool support is active rather than legacy. Added functionality is in the new devices. You should expect to be able to get Spartan-IIs for several more years but they are at the bottom of the "price maturity curve" and aren't cost effective compared to new parts. <zwsdotcom@gmail.com> wrote in message news:1163614524.693308.210830@k70g2000cwa.googlegroups.com... > I've inherited a tray of TQFP Spartan-2 (XC2S50, standard performance > version) with date code from mid-2001. > > Is it worth my while to put these down on prototypes, or have there > been significant silicon changes since then/has this family been slated > for discontinuation? > > Thanks. >Article: 112056
Symon wrote: > "rickman" <gnuarm@gmail.com> wrote in message > news:1163611134.424119.44610@i42g2000cwa.googlegroups.com... > >>Ray Andraka wrote: >> >>>Symon wrote: >>> >>> >>>>Dear Nana Nmichou, >>>>You could display the data on a monitor driven by the XSGA port of one >>>>board, and use a USB webcam to read the data back into the other board. >>>>HTH, Syms. >>>> >>>> >>> >>>Gee Symon, why not drive a paper tape punch with one board and then run >>>the tape through a paper tape reader to get it into the other one. >> >>I don't think this board has a paper tape reader/punch interface. I >>guess you could implement your own by emulating a PC parallel port, but >>that would require work while the video/USB interfaces are available as >>IP. >> >>;^) >> > > Exactly. Thanks Rick! At first, I was going to suggest writing the data to a > DDR SDRAM DIMM and then swapping the DIMM _really_ quickly to the other > board. But that's obviously daft. > ;-) > > I didn't realize the board had the usb and XVGA interfaces on it. since it has USB, you could write to a USB flash.... :^)Article: 112057
Hi All, Does anyone have experience with getting Xilinx DMA SG working with a peripheral? When you create your user IP using Create/Import peripheral, you just select DMA and it adds it for you, but then what? I am using EDK 8.2.01i. I have read ipif_dma_sg.pdf in C:\EDK\doc, dma_sg.pdf in C:\EDK\hw\XilinxProcessorIPLib\pcores\dma_sg_v2_01_a\doc and ipif_dma_sg.pdf in C:\EDK\hw\XilinxProcessorIPLib\pcores\opb_ipif_v1_23_e\doc\ipif_dma_sg I have also looked for reference designs installed with EDK and on the Xilinx website. Does receive SG DMA not wait for some kind of "receive data in buffer just arrived" bit before it reads the data to the FIFO from the address?? I have such a bit in my peripheral, indicating data is ready to be read. If SG DMA does not work that way, how would it work? It does not seem reasonable that receive DMA would just continue reading from the address, because it might fill up memory with duplicate receive data! I could not find a description or an indication of the receive SG DMA philosophy or operation along these lines in the documentation or in the reference designs on the website. I could really use a good, detailed writeup in plain language!! Or even something that hints at everything so I can at least puzzle it out!! Did anybody locate a good writeup on the Xilinx website about this? Also it would be really nice if the DMA SG read could be triggered only by a rising edge of such a "receive data ready in peripheral" bit! Also it would be nice if transmit DMA SG could wait for such a bit (to go low, i.e., falling edge but I could add a rising edge signal for that) before sending, as well. Thanks in advance, -JamesArticle: 112058
On Wed, 15 Nov 2006 09:06:17 +0100, "Göran Bilski" <goran.bilski@xilinx.com> wrote: >Hi Murali, > >It can never proceed until the memory access is finished. >MicroBlaze currently don't have an out-of-order exexcution. > >Göran > >"Murali" <vmurali@mit.edu> wrote in message >news:455a9e33$0$558$b45e6eb0@senator-bedfellow.mit.edu... >> Hi all >> >> Does Microblaze (v 5.00) stall on store (to a non-BRAM memory) till it >> receives an ack, or can it process other instructions while this store is >> on fly? A write buffer is different from OOE. You don't necessarily have to wait for the N number of writes to succeed (where N is the size of your write buffer) before executing the next instruction(s) perfectly in order.Article: 112059
I'm seeing some strange behavior when trying to program a Spartan 2e (XC2S150E) directly via JTAG. In the system it is normally programmed using master serial mode from the XCF02S "platform flash" part. The JTAG chain starts with the XCF02S and then ends at the XC2S150E - no other parts. I can program the XCF02S without problem using JTAG. I can also program the XC2S150E without problems via JTAG _IF_ the XCF02S is blank. Once the FPGA has been programmed from the XCF02S using master serial mode, which is the normal case after power-up, attempts to re-program the FPGA using JTAG fail. This does not seem to be a problem with the FPGA running. I can re-program the FPGA via JTAG when it is running _IF_ the FPGA was originally configured via JTAG. I have opened a web case on this, but I thought someone here may have some insight on this issue. I saw in an old thread the following note: David Kinsell wrote: We've seen different problems with an XCF02S in the chain ahead of a Spartan 2 part. Done never goes high on the Spartan when attempting JTAG programming. Take the XCF02 out of the chain and it works. Discovered that if the XCF02 is blank, then we can program the Spartan OK. Xilinx has some answer records (18644 and others) on related issues, but that didn't seem to apply to us.Article: 112060
Hio folks, I'm trying to find a document that describes adding a delay between the inverted lock signal of one DCM that feeds forward to the reset of the next DCM. I have seen this document before, so I know it exists. Anyone know where I can find this doc? Brad Smallridge aivisionArticle: 112061
Symon wrote: > "rickman" <gnuarm@gmail.com> wrote in message > news:1163611134.424119.44610@i42g2000cwa.googlegroups.com... > > Ray Andraka wrote: > >> Symon wrote: > >> > >> > > >> > Dear Nana Nmichou, > >> > You could display the data on a monitor driven by the XSGA port of one > >> > board, and use a USB webcam to read the data back into the other board. > >> > HTH, Syms. > >> > > >> > > >> > >> Gee Symon, why not drive a paper tape punch with one board and then run > >> the tape through a paper tape reader to get it into the other one. > > > > I don't think this board has a paper tape reader/punch interface. I > > guess you could implement your own by emulating a PC parallel port, but > > that would require work while the video/USB interfaces are available as > > IP. > > > > ;^) > > > Exactly. Thanks Rick! At first, I was going to suggest writing the data to a > DDR SDRAM DIMM and then swapping the DIMM _really_ quickly to the other > board. But that's obviously daft. > ;-) I agree, that is *obviously* daft! SDRAM DIMMs are getting expensive. <g>Article: 112062
I would like to eventually make an 8080 out of Field Solderable Gate Arrays. ;) (trasistors) First, I want to design the whole thing in an FPGA for logic proofing There will be a LOT of circuit boards required for this and I want to limit failure... My idea was to create small macro blocks that emulate standard TTL chips and use those TTL chips (or customized versions) to build the processor. Any recomendations on how to proceed? I want to make the core I/O compatible with the 8080, which means full status signal support and a 2 phase clock. Thanks, GrantArticle: 112063
John_H wrote: > Thanks for throwing this back in after your "Now come, Austin" comment. The > tools will report what the chip will *absolutely* support under worst case > conditions as long as none of the input conditions for that specification > are exceeded. Maximum acceptable jitter is specified in the data sheet but > must also be considered *internal* to the device since a poor set of > switching I/Os and/or improperly bypassed and distributed rails can affect > the amount of jitter seen by the time it gets to the global clock routing. > > - John_H I try to be fair, and in defence of Xilinx, I will say that the tools are accurate when properly set up, and when all constraints are indeed properly set, but that leaves a huge hole in the analysis, sometimes known as the external circuitry and circuit board. A single via can induce 50ps or more of deterministic jitter on a highspeed line, and we won't even get into proper termination or the dozens of other gotchas in timing budget analysis. My point would simply be that I have to be able to trust the tools to give me the information I need to do a thorough timing budget analysis; but simply because one part of the design is supposed to work does not relieve me of the responsibility of making sure it all works together ;) Cheers PeteS > > "PeteS" <peter.smith8380@ntlworld.com> wrote in message > news:fXr6h.14160$yz3.6788@newsfe4-gui.ntli.net... >> At bottom: >> >> PeteS wrote: >>> Inline: >>> >>> Austin Lesea wrote: >>>> Thomas, >>>> >>>> Comments below, >>>> >>>> Austin >>>> >>>> -snip- >>>> >>>>> I hadn't a thermometer ready, but I can always touch the FPGA for a >>>>> long time, it may be 50°C. >>>> How much slack does your timing report say it has? >>>> >>>>> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of >>>>> 78.777MHz, and logic utilization is about 60%. >>>> I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz). That >>>> is pretty darned small. If you have 400 ps of jitter on your clock, you >>>> now have 327 - 1/2 (400) = 127 ps of slack ... >>>> >>>> If you have 800 ps of jitter, then you are failing (slack less than 0). >>>> >>>> If you have any paths that were not constrained properly, then 327 ps of >>>> slack is a fiction, you really may have paths that are failing to meet >>>> timing. >>> Now come, Austin. If the tool tells me I have positive margin (however >>> small) I expect that to be true. I've done designs where I calculated the >>> worst case and had a _guaranteed_ margin of 8 ps. Note the word >>> guaranteed. I thought the post-PAR analysis tools gave me guaranteed >>> timings. >>> >>> >>>>> One board works as expected and two other show the explained effect, >>>>> the boards have the same layout but are made by different >>>>> manufacturers. At least the not working are lead free. >>>> Parts will vary: some will be faster than specified. none will be >>>> slower than specified. >>> Lead free processes stress a part more than the non-lead free; there is >>> also the issue that the joints may not have the same highspeed >>> performance; your application is highspeed enough to be susceptible to >>> soldering issues. However, I agree with Austin that your margin is sorta >>> small. >>> >>> >>>>> Just now, we had a discusion to the influence of temperature to >>>>> propagation delay. I don't believe that it influences clock lines and >>>>> other logic resources in a (big) different way. Is It true or not? >>>> Temperature affects all delays. The resource affected may be different, >>>> and may be affected more, or less, but they will all slow down at hotter >>>> temperatures. >>>> >>>>> I read the thread "Propagation delay sensitivity to temperature, >>>>> voltage, and manufacturing", but the answers are very related to DCMs. >>>> DCM's vary, too. So does everything else. >>>> Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a >>>> rule of thumb, not anything we characterize or guarantee. >>>> >>>> You are just too close to the edge: go back and review your constraints >>>> (to see if they cover all the critical paths), and perhaps apply a >>>> smaller clock period as a timing specification. >>> I would also check to see if you are adding the signal rise/fall (which >>> can get quite high for non-rocket IO pins) as temperatures increase. >>> >>> Cheers >>> >>> PeteS >> You are obviously clocking things from somewhere. A margin of 300 ps or so >> can get lost in the rise/fall times of a hot clock source. Have you >> characterised your clock inputs properly for post-PAR analysis? >> >> Cheers >> >> PeteS > >Article: 112064
Austin Lesea wrote: > John, > > I, too, have a problem with people making assumptions about our product > quality. > > If you are interested, we do publish what our criteria are, and the > probability that a part is a test escape of some sort, or fails upon > first insertion, etc. is something we do document, and care deeply about. > > http://www.xilinx.com/products/quality/ > > Obviously, we strive like most companies for a '0 defect' goal, and like > all companies, we somehow are unable to ship only perfect components > (funny how the real world conspires against perfection). > > Since every bitstream is different for each application, and we don't > know any of them, it makes assuring 100% perfection a daunting task, yet > one that we willingly accept and strive towards. > > In fact, if you really want a component that is absolutely best tested > for exactly your bitstream (design), then you should be using the > EasyPath(tm) program, as that program has a customer program for the > FPGA that exercises the paths and logic that you actually are going to > depend on (based on your design). > > Austin In further defence of IC manufacturers and in particular FPGA vendors, I have _never_ had a failure due to FPGA timing with Xilinx (and others) parts except for my own failure to properly analyse the system. I have designed with others, but Quicklogic was 12 years ago and any issues from then would be unfiar, to say the least. I've also used Lattice and Altera parts and provided I used the tools properly, they worked as expected as well. The key (as I note elsewhere) is that provided I get guaranteed characteristics, (which I _do_ insist on, whatever they may be) I can use them as part of an overall budget; and it is _my_ responsibility to make sure I give the tools sufficient information to give me the information I need, to say nothing of taking all external effects into account. I wouldn't normally buy parts that are statistically characterised (AQL) *unless* it's a mature part with a track record of not having issues on the particular tests that are AQL only. Both the vendor and designer has responsibilities, and although I expect quite a bit from the vendor, I am perfectly willing to assume my part of those responsibilities. Cheers PeteSArticle: 112065
John_H wrote: > If you inherited a box of the "pocket PCs" mid-2001, would you use those in > your systems? Maybe :) It depends how big the box was. > If your need is limited to stock on hand and the performance you get from > them is sufficient, I'd say "go for it" but if you end up purchasing more of > these devices in the long run, you'll probably be MUCH better with a current I just did a quick price compare vs. Spartan-III and I see what you mean. I don't have a specific need for these parts right now; nothing I build uses FPGAs. I was planning to lay down some footprints in "spare" space and wire the FPGA to the footprint of the 8-bit micro I use in an existing design, for experiments. But if I can't be sure of getting these parts on an ongoing basis, there's no point.Article: 112066
Brad Smallridge wrote: > Hio folks, > > I'm trying to find a document that describes adding > a delay between the inverted lock signal of one DCM > that feeds forward to the reset of the next DCM. > > I have seen this document before, so I know it exists. > Anyone know where I can find this doc? > > Brad Smallridge > aivision > > Brad, I believe it is in the old app notes describing the DLLs in Virtex.Article: 112067
olive_dominguez@yahoo.fr wrote: > PeteS a écrit : > >> olive_dominguez@yahoo.fr wrote: >>> Anyone knows the I/O impedance on SPARTAN3 board ? I didn't find it in >>> datasheet! >> The IO impedance of Spartan3 pins depends on the IO standard selected. >> As already noted, you can get the IBIS files which specify (in >> excruciating detail) the properties of the IO drivers. >> >> Cheers >> >> PeteS > > I have read IBIS files, my I/O is :LVCMOS25-S-12mA. > What's the impedance of this I/O standard ? > > Thanks. > I just got the latest IBIS models, and I'm not going to plug them into anything right now, but the information you need to use is the package data (which will give you the packaging equivalent circuit) which is driven by the model you show. If you take the IBIS drive model, you will see it also has loading components listed (these are the components on the testbed where the data were gathered). So draw a little circuit; Driver -> package model -> load circuit Now plug in the numbers (a delta is more useful than any one number) and you'll get a V/I curve vs. the entire circuit. That's your impedance, as close as you should need. If you look at the impedance of the two external circuits, you'll see they don't give you that same impedance; what's left is the buffer impedance. Xilinx don't (nor do Altera as far as I know) specify impedances in the datasheet for at least 2 very good reasons: 1. They would have to list them (vs. frequency) for every single IO buffer model, and the datasheet would be swamped (although I will admit it would be nice as a separate design note - hint to Xilinx as you have the data and it can't be too hard to automate the process and get at least *predicted* impedances into a specific load :) 2. It depends on the package, so the same issues as in (1) apply. Use Spice or equivalent or even Matlab if you have it if you want to automate the process a little. I remember doing this for a Virtex part a few years ago and I used a Perl script to generate the numbers to plug into a spreadsheet ;) Cheers PeteSArticle: 112068
Jon Elson wrote: > > > logjam wrote: > >> I would like to eventually make an 8080 out of Field Solderable Gate >> Arrays. ;) (trasistors) >> >> First, I want to design the whole thing in an FPGA for logic proofing >> There will be a LOT of circuit boards required for this and I want to >> limit failure... My idea was to create small macro blocks that emulate >> standard TTL chips and use those TTL chips (or customized versions) to >> build the processor. >> >> Any recomendations on how to proceed? I want to make the core I/O >> compatible with the 8080, which means full status signal support and a >> 2 phase clock. >> >> > Logjam sounds like a good name for this project. A google search turns up > it was built from 6000 transistors. Well, each transistor is going to > need a > drain (or collector) resistor at the least. What will you use for > gating, diodes? > Add at least one more resistor to pull up the diode gate's output to the > transistor's > gate or base. Well, assuming most of the transistors are for 2-input > gates, now > we have 6000 times 5 components (2 diodes, 2 res, one trans) = 30,000 > components. > Does this still sound practical? > > I don't know the specific logic design for the 8080 other than it was > some form > of NMOS. So, it may be that this can be done in a lot less than 6000 > transistors > if you use diode gates. > > Anyway, it should be fairly easy to design the CPU for FPGA implementation. > I'd forget the TTL component emulation, and use either VHDL or Verilog, > or maybe > one of the RTL synthesis tools. These are able to specify a CPU very > concisely. > > Jon > I seem to recall from the distant past that the 8080 (some versions) used depletion load; i.e. a depletion mode device with gate tied to source instead of a resistive load. Not that it reduces the components (an in fact adds a pin per active transistor). Cheers PeteSArticle: 112069
Borge wrote: > Good idea! > > Or perhaps even better, have a register with no reset value be counted > up towards a preset and let the local reset be active between preset > one and preset two. After reaching preset two there's no more counting. > > > If we can KNOW that the register is reset to either 0xFF or 0x00, and > not the preset values, this should generate a local reset pulse. > > So, for example, a 4-bit register could count up from 0 (or F) to 2, > activate reset, count to 4 and then deactivate reset and stop counting. > > > I love your abbreviations, but how would you declare the 4-bit register > in practical, synthesizable Verilog? > > > Thanks, > Borge > Without trying to write verilog after a couple of glasses of wine, use the 'initial' keyword for a block instead of 'always'; it gets executed precisely once (immediately post configuration). Cheers PeteS > > > Slurp skrev:> As all the FPGA's FF's are reset to zero on powerup, why > not create a >> counter that inhibits itself after reaching a suitable a preset value when >> clocked with one of your system clocks? >> Use the terminal count decode as your POR (adjusting polarity as >> appropriate). >> >> >> Slurp >Article: 112070
I have built a prototyp board with wires between the FPGA and an external component. With the scope I can see glitches (looks like from crosstalk when switching other signals) and multiple transitions are detected by the FPGA when switching signals. Looks like the noise is < 200 ns. The period of the wanted signal is > 3 us. I think with a PCB there would be less problems, but there is lots of space left inside the FPGA, so it should be possible enhance the signal with logic so that it works even with the noisy wired prototype. What do you do normally to solve this kind of problems? My idea is to use a low-pass filter: a n bit counter, which is incremented with system clock, if the input signal is 1 and decremented otherwise. If all n bits are 1, the counter is not incremented and if all bits are 0, it is not decremented. If the highest bit is set, then the sampled signal is considered as 1, otherwise as 0. I could encapsulate this function within a VHDL entity, so it is easy to use it for multiple input signals and maybe a generic for specifying n. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 112071
logjam wrote: >I would like to eventually make an 8080 out of Field Solderable Gate >Arrays. ;) (trasistors) > >First, I want to design the whole thing in an FPGA for logic proofing >There will be a LOT of circuit boards required for this and I want to >limit failure... My idea was to create small macro blocks that emulate >standard TTL chips and use those TTL chips (or customized versions) to >build the processor. > >Any recomendations on how to proceed? I want to make the core I/O >compatible with the 8080, which means full status signal support and a >2 phase clock. > > Logjam sounds like a good name for this project. A google search turns up it was built from 6000 transistors. Well, each transistor is going to need a drain (or collector) resistor at the least. What will you use for gating, diodes? Add at least one more resistor to pull up the diode gate's output to the transistor's gate or base. Well, assuming most of the transistors are for 2-input gates, now we have 6000 times 5 components (2 diodes, 2 res, one trans) = 30,000 components. Does this still sound practical? I don't know the specific logic design for the 8080 other than it was some form of NMOS. So, it may be that this can be done in a lot less than 6000 transistors if you use diode gates. Anyway, it should be fairly easy to design the CPU for FPGA implementation. I'd forget the TTL component emulation, and use either VHDL or Verilog, or maybe one of the RTL synthesis tools. These are able to specify a CPU very concisely. JonArticle: 112072
Frank Buss wrote: > I have built a prototyp board with wires between the FPGA and an external > component. With the scope I can see glitches (looks like from crosstalk > when switching other signals) and multiple transitions are detected by the > FPGA when switching signals. Looks like the noise is < 200 ns. The period > of the wanted signal is > 3 us. I think with a PCB there would be less > problems, but there is lots of space left inside the FPGA, so it should be > possible enhance the signal with logic so that it works even with the noisy > wired prototype. What do you do normally to solve this kind of problems? > > My idea is to use a low-pass filter: a n bit counter, which is incremented > with system clock, if the input signal is 1 and decremented otherwise. If > all n bits are 1, the counter is not incremented and if all bits are 0, it > is not decremented. If the highest bit is set, then the sampled signal is > considered as 1, otherwise as 0. I could encapsulate this function within a > VHDL entity, so it is easy to use it for multiple input signals and maybe a > generic for specifying n. > Hi Frank You are describing a soft filter. I have a number of them in a current design (it's in a rather noisy environment) and I use a 5 bit counter as part of a state machine. I assume you have an appropriate clock, so simply qualify the signal as continuously present (or perhaps mostly present) for the 3us you state. With a 10MHz clock, for example, a 5 bit counter is almost perfect (and besides, we can always terminate at count = 30 ;) I like your approach, but this is simple and uses pretty limited resources. so, somewhere wire Sig; // the signal we are watching reg SigValid; // valid indicator reg [4:0] SigCount; always @(posedge clk) begin if (!Sig) begin SigCount <= 5'b00000; // signal disappeared, clear counter SigValid <= 1'b0; end else if(Sig & SigCount < 28) begin SigCount <= SigCount+1; end else if (SigCount == 28) begin SigValid <= 1'b1; // Signal has been true for 30 consecutive // clocks. end end Simple, as I said, and if you find bugs, I state in my defence I have had a couple of glasses of wine :) Cheers PeteSArticle: 112073
A small fix :) PeteS wrote: > Frank Buss wrote: >> I have built a prototyp board with wires between the FPGA and an external >> component. With the scope I can see glitches (looks like from crosstalk >> when switching other signals) and multiple transitions are detected by >> the >> FPGA when switching signals. Looks like the noise is < 200 ns. The period >> of the wanted signal is > 3 us. I think with a PCB there would be less >> problems, but there is lots of space left inside the FPGA, so it >> should be >> possible enhance the signal with logic so that it works even with the >> noisy >> wired prototype. What do you do normally to solve this kind of problems? >> >> My idea is to use a low-pass filter: a n bit counter, which is >> incremented >> with system clock, if the input signal is 1 and decremented otherwise. If >> all n bits are 1, the counter is not incremented and if all bits are >> 0, it >> is not decremented. If the highest bit is set, then the sampled signal is >> considered as 1, otherwise as 0. I could encapsulate this function >> within a >> VHDL entity, so it is easy to use it for multiple input signals and >> maybe a >> generic for specifying n. >> > > Hi Frank > > You are describing a soft filter. > > I have a number of them in a current design (it's in a rather noisy > environment) and I use a 5 bit counter as part of a state machine. > > I assume you have an appropriate clock, so simply qualify the signal as > continuously present (or perhaps mostly present) for the 3us you state. > > With a 10MHz clock, for example, a 5 bit counter is almost perfect (and > besides, we can always terminate at count = 30 ;) > > I like your approach, but this is simple and uses pretty limited resources. > > so, somewhere > > wire Sig; // the signal we are watching > reg SigValid; // valid indicator > reg [4:0] SigCount; > > > always @(posedge clk) > begin > if (!Sig) > begin > SigCount <= 5'b00000; // signal disappeared, clear counter > SigValid <= 1'b0; > end > else if(Sig & SigCount < 28) > begin > SigCount <= SigCount+1; > > end // fix the next line // was else if (SigCount == 28) else if (Sig & SigCount == 28) // qualify signal properly > begin > SigValid <= 1'b1; // Signal has been true for 30 > consecutive // clocks. > end > end > > Simple, as I said, and if you find bugs, I state in my defence I have > had a couple of glasses of wine :) > > > Cheers > > PeteSArticle: 112074
On 15 Nov 2006 12:48:29 -0800, zwsdotcom@gmail.com wrote: >+++ >+++John_H wrote: >+++> If you inherited a box of the "pocket PCs" mid-2001, would you use those in >+++> your systems? >+++ >+++Maybe :) It depends how big the box was. >+++ >+++> If your need is limited to stock on hand and the performance you get from >+++> them is sufficient, I'd say "go for it" but if you end up purchasing more of >+++> these devices in the long run, you'll probably be MUCH better with a current >+++ >+++I just did a quick price compare vs. Spartan-III and I see what you >+++mean. I don't have a specific need for these parts right now; nothing I >+++build uses FPGAs. I was planning to lay down some footprints in "spare" >+++space and wire the FPGA to the footprint of the 8-bit micro I use in an >+++existing design, for experiments. But if I can't be sure of getting >+++these parts on an ongoing basis, there's no point. *********** The Spartan 2 (XC2S**) are 5 volt tolerant and will easily interface with older 8 bit micros that are 5 volt devices. T he Spartan 2E and later is not 5 volt tolerant. S With that in mind these parts still have some minimal value. james
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