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
If I read this right, you want to run X86 code on an FPGA, along with the FPU. Don't go there, you'll be really dissapointed with the performance. A common misconception about configurable computing in FPGAs is that the computer implemented in the FPGA is like a common CPU. Sure, you can do that, but it ain't gonna touch the performance of the dedicated CPU chip. Where FPGAs get their power is the ability to become a custom processor highly optimized for the task at hand. If you were going to do nothing but hammer nails all day, you would spend your money on the best hammer you could get, not on the mechanics tool chest full of all kinds of tools, half of which you haven't a clue what they're for. You'd be really good at banging in nails, but the hammer wouldn't help too much for repairing cars. On the otherhand, if one day you were hammering, and the next you were fixing cars, if you could trade the hammer for the wrenches you need you might be able to get away with not buying both. It is similar with FPGA processors. For example, if I need to add a whole bunch of numbers, A CPU would be pretty much stuck with adding one or two at a time to eventually end up with the sum. You can't do too much more than that with the CPU, because you have a very limited amount of adder resources. In an FPGA, you have alot of uncommitted gates, so when we need to do that adding, we just use more gates to do the additions in parallel if we need to do it fast. mu0lia0ni@my-deja.com wrote: > Hi, I have an idea about combining Configurable > computers/CPU / Processor modules based on FPGA > with the new Transmeta's CODE MORPHING software. > If succesful, the Intel X86 programs can run > on the configurable computer. > Is this possible? What is your comments/opinion? > Is there any problem with Floating Point operation > on FPGA based configurable computers? > What is the typical setup delay? > Regards > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 20001
Paul Walker wrote: PW> Get the acrobat version of the data book and device-specific pin tables; PW> Extract the text of the table into the clipboard; This suggestion is a good starting point for text/script pinouts for some device/package combinations, thank you. When I tried this on one specific table, I couldn't copy the text. I will complain to the guilty party before mentioning a name here. Why don't the vendors just supply a plain text version of pinout tables? PW> Does anyone else understand why it is the .pcf format that the tools PW> produce an example of (in the .pad file) rather than the .ucf format? There is a pin2ucf.exe program in M2.1i that you might want to try. Andreas Doering wrote: AD> Therefore, I propose (and used) a modification of 2) AD> 4) Generate a constraint file with a script (perl or whatever). Scripts can help a lot with the regular parts of the pinout. Another good suggestion, thank you. It is just not as easy when multiple types of IO levels are used. Yes, I guess that a script could be written that checked the Vref and Vcco of the bank for each pin. -- Phil HaysArticle: 20002
On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein" <mbillens@one.net> wrote: > All, > > I've not seen (or cannot find) an appropriate appnote or reference design > for laying down these fine pitch BGA parts (say FG256 for example) There > doesn't seem to be a lot of room between BGA solder pads (0.400 millimeters > nominal) to route out or drop vias of any substantial size... I can route > out two rows around the whole part with very little trouble, but I think I > have to dogbone anything further inside the part. How are you folks here > doing it? When I switched FPGA manufacturers (at gun-point :-|) I went from a BG560 to a FG680 to make things a little easier (it didn't). My choices were either a 3mil line width to get two out traces per channel or another plane and 5mil traces and one per channel. Since I needed a 50 ohm environment and this widget is a "cost is no object" type of deal, I chose another plane (actually two - one for another power plane to keep 50 ohms). I have a total of ten planes (5p, 5S). ---- KeithArticle: 20003
mu0lia0ni@my-deja.com wrote: : Hi, I have an idea about combining Configurable : computers/CPU / Processor modules based on FPGA : with the new Transmeta's CODE MORPHING software. : If succesful, the Intel X86 programs can run : on the configurable computer. : Is this possible? [...] I believe Star Bridge Systems claim to be able to perform programmable logic-based x86 emulation: http://www.starbridgesystems.com/ They use ``Synthesized Hyper-Specificity Specificity Processors(TM)'' - according to their marketing department. Quite why anyone would want to emulate an x86 in programmable logic appears obscure today. An FPGA solution will probably do several of: be more expensive, run much slower, consume more power and get hotter than the real thing. Transmeta's "Code Morphing" software targets their own VLIW architecture - which appears to have very little to do with FPGAs. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Save the whales. Collect the whole set.Article: 20004
In article <pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost>, krw@attglobal.net wrote: > On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein" > <mbillens@one.net> wrote: > > > All, > > > > I've not seen (or cannot find) an appropriate appnote or reference design > > for laying down these fine pitch BGA parts (say FG256 for example) There > > doesn't seem to be a lot of room between BGA solder pads (0.400 millimeters > > nominal) to route out or drop vias of any substantial size... I can route > > out two rows around the whole part with very little trouble, but I think I > > have to dogbone anything further inside the part. How are you folks here > > doing it? > > When I switched FPGA manufacturers (at gun-point :-|) I went from > a BG560 to a FG680 to make things a little easier (it didn't). My > choices were either a 3mil line width to get two out traces per > channel or another plane and 5mil traces and one per channel. > Since I needed a 50 ohm environment and this widget is a "cost is > no object" type of deal, I chose another plane (actually two - > one for another power plane to keep 50 ohms). I have a total of > ten planes (5p, 5S). > > ---- > Keith > > According to the High-Speed Digital Design book by Howard Johnson and Martin Graham, if faced with adding another plane, a ground plane is a better choice than another power plane. It minimizes the jump of return currents through bypass capacitors as the signal traverses it's different routing layers (Section 5.8.6) Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20005
On Sat, 22 Jan 2000 19:54:52 GMT, bob_42690@my-deja.com wrote: |In article <pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost>, | krw@attglobal.net wrote: |> On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein" |> <mbillens@one.net> wrote: |> |> > All, |> > |> > I've not seen (or cannot find) an appropriate appnote or reference |design |> > for laying down these fine pitch BGA parts (say FG256 for example) |There |> > doesn't seem to be a lot of room between BGA solder pads (0.400 |millimeters |> > nominal) to route out or drop vias of any substantial size... I can |route |> > out two rows around the whole part with very little trouble, but I |think I |> > have to dogbone anything further inside the part. How are you folks |here |> > doing it? |> |> When I switched FPGA manufacturers (at gun-point :-|) I went from |> a BG560 to a FG680 to make things a little easier (it didn't). My |> choices were either a 3mil line width to get two out traces per |> channel or another plane and 5mil traces and one per channel. |> Since I needed a 50 ohm environment and this widget is a "cost is |> no object" type of deal, I chose another plane (actually two - |> one for another power plane to keep 50 ohms). I have a total of |> ten planes (5p, 5S). |> |> ---- |> Keith |> |> | |According to the High-Speed Digital Design book by Howard Johnson and |Martin Graham, if faced with adding another plane, a ground plane is a |better choice than another power plane. It minimizes the jump of return |currents through bypass capacitors as the signal traverses it's |different routing layers (Section 5.8.6) | | |Sent via Deja.com http://www.deja.com/ |Before you buy. Bob, I don't believe this. The planes themselves have so much mutual capacitance that the bypass caps don't matter... a plane's a plane. I usually run a test trace on my multilayer boards, starting at a tiny surfmount coax connector layout, zigzagging through all the layers, computed to be constant 50 ohms, and ending with a 50 ohm 0805 resistor. I then TDR the trace to see how we're doing. Even with no parts loaded (bare board, no caps) the 'return plane' distinction is invisible. Johnson's book is roughly 2/3 good stuff and 1/3 nonsense; the obvious problem is figuring out which is which. JohnArticle: 20006
I am searching Cypress programming information for old 370 devices.
Who can help me?
Thank you very much.
Article: 20007On Thu, 1 Jan 1970 02:59:59, John Larkin <jjlarkin@highlandSnipSniptechnology.com> wrote: > On Sat, 22 Jan 2000 19:54:52 GMT, bob_42690@my-deja.com wrote: > > |In article <pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost>, > | krw@attglobal.net wrote: > |> On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein" > |> <mbillens@one.net> wrote: > |> > |> > All, > |> > > |> > I've not seen (or cannot find) an appropriate appnote or reference > |design > |> > for laying down these fine pitch BGA parts (say FG256 for example) > |There > |> > doesn't seem to be a lot of room between BGA solder pads (0.400 > |millimeters > |> > nominal) to route out or drop vias of any substantial size... I can > |route > |> > out two rows around the whole part with very little trouble, but I > |think I > |> > have to dogbone anything further inside the part. How are you folks > |here > |> > doing it? > |> > |> When I switched FPGA manufacturers (at gun-point :-|) I went from > |> a BG560 to a FG680 to make things a little easier (it didn't). My > |> choices were either a 3mil line width to get two out traces per > |> channel or another plane and 5mil traces and one per channel. > |> Since I needed a 50 ohm environment and this widget is a "cost is > |> no object" type of deal, I chose another plane (actually two - > |> one for another power plane to keep 50 ohms). I have a total of > |> ten planes (5p, 5S). > |> > |> ---- > |> Keith > |> > |> > | > |According to the High-Speed Digital Design book by Howard Johnson and > |Martin Graham, if faced with adding another plane, a ground plane is a > |better choice than another power plane. It minimizes the jump of return > |currents through bypass capacitors as the signal traverses it's > |different routing layers (Section 5.8.6) > | > | > |Sent via Deja.com http://www.deja.com/ > |Before you buy. > > Bob, > > I don't believe this. The planes themselves have so much mutual > capacitance that the bypass caps don't matter... a plane's a plane. I totally agree. Planes are planes. In any case, my offsetting factor is that I converted a split 5V/3.3V plane into two contiguous planes, at least under the high-speed stuff. A good portion of the board is regulators, so I went with maximum surface metal for whatever the PowerFETS tabs were connected. I do have split planes because some devices require different voltages (can't fit any more planes into .062"), but I burried them between two other solid planes. I don't believe any high-speed line crosses any discontinuity in planes and all high-speed lines are 50ohm. The outer two (signal) planes are reserved for house-keeping, BGA pads, and metal for heatsinking. There are no critical nets on the surface (I may regret this). The real critical nets never see a via, except at the BGAs. They're wired on a single plane each (three planes). I should know if this works in a couple of weeks. Actually, I already know of two flaws, one in the impedance of differential PECL/LVPECL clocks (the nets were set up to 50ohm, but differentially they're more like 40), and another really dumb mistake (reused an "address" line). > I usually run a test trace on my multilayer boards, starting at a tiny > surfmount coax connector layout, zigzagging through all the layers, > computed to be constant 50 ohms, and ending with a 50 ohm 0805 > resistor. I then TDR the trace to see how we're doing. Even with no > parts loaded (bare board, no caps) the 'return plane' distinction is > invisible. What do you see at the vias? This is very interesting. I threatened to break the layout person's legs if he switched planes on a critical net. The clocks are routed inbetween planes - never to surface, except at the BGA's Vias. > Johnson's book is roughly 2/3 good stuff and 1/3 nonsense; the > obvious problem is figuring out which is which. Yikes! That's what life is about! ...well maybe in different proportions. ;-) ---- KeithArticle: 20008
On Fri, 21 Jan 2000 13:21:07 +0800, "Sherdyn" <sherdyn@yahoo.com> wrote: >But how am I going to know the clk frequency? One of the feature of this >design is that it should be able to support 4 different frequencies. (in the >range 400us - 500 us period) > >Sherdyn > >Kelly Hall <khall@pacbell.net> wrote in message >news:5aRh4.83$oj1.7843@nnrp3-w.snfc21.pbi.net... >> On Fri, 21 Jan 2000 10:42:59 +0800, Sherdyn <sherdyn@yahoo.com> wrote: >> >Can someone tell me how I can extract a clock embedded in a serial stream >> >which is biphase mark coded? I have only a single input stream to FPGA >and >> >need to extract some bits within a frame of 90 bits (assuming I have an >> >independent clock which is running 2 times or more). The only thing I >know >> >is I would be able to do that with a Digital PLL but do not exactly sure >> >what it is. >> >> As I recall, you should have a 32x clock. Sample on counts 7 and 23. >> If the two samples are the same, the data is a 1, else a 0. You can >> use different clock periods, but be test to test interoperability. >> >> Kelly > Well . . . what ARE the four frequencies? Thee must be a spec somewhere. While you're checking what is wanted here, perhaps you can find out precisely what the modulation (coding) scheme is. It may well be BIPHASE-L (Manchester) from which clock extraction is quite straightforward. There should also be a specification for a sync word from which you can extract framing. In any case, the DPLL I'd propose is quite simple and requires at least four flipflops and perhaps a fifth as transient memory for the incoming data pulse. The incoming data./clock pulse can only be used once in each 8-count window. It's up to you to see that it never extends beyond the count window within which it occurs. If you'd like your DPLL to work well, you really need a 16x clock, else you'll not be happy with the jitter on your clock. You can then wait for the arrival of a data pulse, using a 4-bit counter which skips head a count if the data pulse occurs during the first three counts (0,1,2,8,9,A), does nothing but count if it occurs during the middle counts (3,4,B,C), and is disabled for one count, essentially retarding the counter by one count, if the pulse occurs during the last 3 counts of each 8-count cycle (5,6,7,D,E,F). Take your output from the MSB of the 4-bit counter. This scheme should lock in four bit periods of the counter, provided that the data rate is within 5% of 1/16th the driver clock. The output clock will jitter at most 6.25%. DickArticle: 20009
On 23 Jan 2000 03:01:46 GMT, krw@attglobal.net (Keith R. Williams) wrote: |I totally agree. Planes are planes. In any case, my offsetting |factor is that I converted a split 5V/3.3V plane into two |contiguous planes, at least under the high-speed stuff. A good |portion of the board is regulators, so I went with maximum |surface metal for whatever the PowerFETS tabs were connected. | |I do have split planes because some devices require different |voltages (can't fit any more planes into .062"), but I burried |them between two other solid planes. I don't believe any |high-speed line crosses any discontinuity in planes and all |high-speed lines are 50ohm. The outer two (signal) planes are |reserved for house-keeping, BGA pads, and metal for heatsinking. |There are no critical nets on the surface (I may regret this). |The real critical nets never see a via, except at the BGAs. |They're wired on a single plane each (three planes). I should |know if this works in a couple of weeks. | |Actually, I already know of two flaws, one in the impedance of |differential PECL/LVPECL clocks (the nets were set up to 50ohm, |but differentially they're more like 40), and another really dumb |mistake (reused an "address" line). | Keith, 40 ohms isn't bad if you were shooting for 50. I use three different microstrip/stripline calculator programs, and they often disagree by 10% or so. We do split planes, too (say, an island of 3.3v in a 5v plane) and don't worry about crossing boundaries. | |What do you see at the vias? This is very interesting. I |threatened to break the layout person's legs if he switched |planes on a critical net. The clocks are routed inbetween planes |- never to surface, except at the BGA's Vias. If your edges are over 100 ps, vias are invisible, too. Even with a 30 ps resolution TDR, vias are just little bumps. We do EclipsLite all the time, with tons of vias. Interestingly, on one board I put a bunch of Hirose coax connector pads so I could TDR the power planes and the little 3.3v island. As far as I could tell, a plane behaves like an ideal capacitor of the expected value. Adding bypass caps - anywhere - then makes it look like a *bigger* ideal capacitor. If your power and ground planes are close, all you need is a few scattered bypass caps, but nothing like one per chip. Some brave souls build BIG digital boards with no bypass caps at all! (I'm not quite that brave...) If you solder some SMAs on your board and send it to me, I'll TDR it and send you snapshots. JohnArticle: 20010
you can define the pins in a seperate file "not VHDL" if you do not know how to define it change the options of the webfitter to download get a file then you can edit it according to your need Anthony Ellis - LogicWorks wrote: > For someone new to Xilinx. > I am planning to use a XC9572 PLD using the online Web compiler and fitter - > using VHDL source code. > Does anyone know how to embedd my pin allocation details into the VHDL > source. > > Thanks AnthonyArticle: 20011
In article <For2F5.Ex@bath.ac.uk>, Tim Tyler <tt@cryogen.com> wrote: >mu0lia0ni@my-deja.com wrote: >: Hi, I have an idea about combining Configurable >: computers/CPU / Processor modules based on FPGA >: with the new Transmeta's CODE MORPHING software. >: ... > ... >Transmeta's "Code Morphing" software targets their own VLIW architecture - >which appears to have very little to do with FPGAs. What VLIWs and FPGAs have in common is that they both can exploit instruction-level parallelism (ILP). Because of this, I've found it very useful to employ VLIW compilation techniques --- hyperblock formation, predication, speculation, (sw) pipelining --- in my work in extracting loops from ISO C programs for acceleration on a rapidly reconfigurable coprocessor. As Ray said, you don't want to make the mistake of building an instruction-based processor using your FPGA, even if it's VLIW and specialized. You'd be shackling yourself with the same limitations of fixed instruction issue bandwidth, fixed reg file bandwidth, and n^2 complexity in your bypassing network. And you'd be a lot slower than a hardwired VLIW. My approach is to use VLIW techniques to extract the dataflow graph for the loop, exposing the ILP, but then map it directly---spatially---to hardware. No reuse of function units, so each can be optimized for the one operation is executing. Often multiple adjacent operations in the DFG can be merged into a single optimized FPGA module (kind of like compiling to CISC instructions). Of course, this fully-specialized approach means that you must completely reconfigure each time you want to accelerate a different kernel. The VLIW-on-top-of-FPGA approach would allow you to change just the instructions/microcode. But then your problem is specializing your configured VLIW processor to be good at two or more loops, so it probably won't be -great- at any of them. So, my philosophy is, use the VLIW compilation/morphing techniques, but don't build a VLIW processor on your FPGA. -- Tim ------------------------------------------------------------------------ Tim Callahan 415 Soda Hall, (510) 643-4203 timothyc@cs.Berkeley.EDU http://www.cs.berkeley.edu/~timothyc/ ------------------------------------------------------------------------Article: 20012
On Thu, 1 Jan 1970 02:59:59, John Larkin <jjlarkin@highlandSnipSniptechnology.com> wrote: > On 23 Jan 2000 03:01:46 GMT, krw@attglobal.net (Keith R. Williams) > wrote: > > |I do have split planes because some devices require different > |voltages (can't fit any more planes into .062"), but I burried > |them between two other solid planes. I don't believe any > |high-speed line crosses any discontinuity in planes and all > |high-speed lines are 50ohm. The outer two (signal) planes are > |reserved for house-keeping, BGA pads, and metal for heatsinking. > |There are no critical nets on the surface (I may regret this). > |The real critical nets never see a via, except at the BGAs. > |They're wired on a single plane each (three planes). I should > |know if this works in a couple of weeks. > | > |Actually, I already know of two flaws, one in the impedance of > |differential PECL/LVPECL clocks (the nets were set up to 50ohm, > |but differentially they're more like 40), and another really dumb > |mistake (reused an "address" line). > | > > Keith, > > 40 ohms isn't bad if you were shooting for 50. I use three different > microstrip/stripline calculator programs, and they often disagree by > 10% or so. We do split planes, too (say, an island of 3.3v in a 5v > plane) and don't worry about crossing boundaries. I'm not too concerned about the impedance. I'd rather be low than high here. If it's a problem there are already two rather simple solutions available. I think only four (possibly eight) pairs of signals are long enough to count as transmission lines. I can lower the termination resistors if necessary. The drivers might complain, but this isn't in any way going to be a product. The other alternative would be to change the traces slightly. That's interesting. In the list of no-nos for EMI design is plane crossings because of the return path. I can see how the plane capacitance coupled via the contiguous ground plane would couple the return current across but these capacitors are in series, no? I guess if the capacitance is big enough... > |What do you see at the vias? This is very interesting. I > |threatened to break the layout person's legs if he switched > |planes on a critical net. The clocks are routed inbetween planes > |- never to surface, except at the BGA's Vias. > > If your edges are over 100 ps, vias are invisible, too. Even with a 30 > ps resolution TDR, vias are just little bumps. We do EclipsLite all > the time, with tons of vias. > > Interestingly, on one board I put a bunch of Hirose coax connector > pads so I could TDR the power planes and the little 3.3v island. As > far as I could tell, a plane behaves like an ideal capacitor of the > expected value. Adding bypass caps - anywhere - then makes it look > like a *bigger* ideal capacitor. If your power and ground planes are > close, all you need is a few scattered bypass caps, but nothing like > one per chip. Some brave souls build BIG digital boards with no bypass > caps at all! (I'm not quite that brave...) Not this chicken! ;-) I think I have about 460 capacitors on this board. Only a few of them do something interesting, most are there to ward off evil spirits. Many of them are 470uF for bulk decoupling, switcher filters and such. I used the Xilinx recommendations (as close as I could reasonably follow them) for decoupling the VCCO and VCCint balls (how do you get two caps in a 1mm space??). I also have about twelve voltage levels so 460 isn't all *that weird. There are also a ton of pretty "hot" LVCMOS and HSTL drivers with 64 bit busses so simultaneous switching is a problem. The ECL stuff is just used for clock generation, timing, and distribution. I'm not so concerned about it. I can see how one could get away with less decoupling in ECL, but CMOS? That's not somewhere my boss would like me to go. > If you solder some SMAs on your board and send it to me, I'll TDR it > and send you snapshots. I have access to a TDR. I could do this, but I won't have any bare boards. I know the vendor is making extras in case of defects. Maybe I can snag one and take a look at it with a TDR. I'm also interested in the power supply to the chip this board is intended to play with. A TDR is the way to go. I'd like to understand how you attach the TDR. What do you do with the planes? Tie them all to the TDR's ground? Tie the GND plane to the TDR and let the rest float? This is very interesting. I'm going to look into this further. I'd like to hear other's comments about this subject as well. ---- Keith Reply-To: "Sherdyn" <sherdyn@yahoo.com>Article: 20013
First of all, thank you very much to all of you that taking time replying my mail!! The four frequencies are 420 us, 450 us, 500 us and 520 us. The module must be able to auto-detect these frequencies as the bits which need to be extracted later on are embedded in different locations away from the synchronization word. What I intend to do is to generate a clock which is running 8X or 16X faster than the detected clock (I have a system clock of 25 MHz). Use this generated clock to run a counter which is then use as indicator to sample data at the correct interval. After synchronization on bit boundary is achieved, I can then synch to synchronization word before extraction of bits can be performed. My problem is how can I detect these four frequencies? I'm thinking of using a fast clock to start counting when the first data transition occur and check the number of count when a second data transition elapsed ... but, I face the second problem, the data transition can occur at middle of bit or start of bit. Richard Erlacher <edick@hotmail.com> wrote in message news:388a6a41.955324305@mindmeld.idcomm.com... > > > > On Fri, 21 Jan 2000 13:21:07 +0800, "Sherdyn" <sherdyn@yahoo.com> > wrote: > > >But how am I going to know the clk frequency? One of the feature of this > >design is that it should be able to support 4 different frequencies. (in the > >range 400us - 500 us period) > > > >Sherdyn > > > >Kelly Hall <khall@pacbell.net> wrote in message > >news:5aRh4.83$oj1.7843@nnrp3-w.snfc21.pbi.net... > >> On Fri, 21 Jan 2000 10:42:59 +0800, Sherdyn <sherdyn@yahoo.com> wrote: > >> >Can someone tell me how I can extract a clock embedded in a serial stream > >> >which is biphase mark coded? I have only a single input stream to FPGA > >and > >> >need to extract some bits within a frame of 90 bits (assuming I have an > >> >independent clock which is running 2 times or more). The only thing I > >know > >> >is I would be able to do that with a Digital PLL but do not exactly sure > >> >what it is. > >> > >> As I recall, you should have a 32x clock. Sample on counts 7 and 23. > >> If the two samples are the same, the data is a 1, else a 0. You can > >> use different clock periods, but be test to test interoperability. > >> > >> Kelly > > > Well . . . what ARE the four frequencies? Thee must be a spec > somewhere. While you're checking what is wanted here, perhaps you can > find out precisely what the modulation (coding) scheme is. It may > well be BIPHASE-L (Manchester) from which clock extraction is quite > straightforward. There should also be a specification for a sync word > from which you can extract framing. In any case, the DPLL I'd propose > is quite simple and requires at least four flipflops and perhaps a > fifth as transient memory for the incoming data pulse. The incoming > data./clock pulse can only be used once in each 8-count window. It's > up to you to see that it never extends beyond the count window within > which it occurs. > > If you'd like your DPLL to work well, you really need a 16x clock, > else you'll not be happy with the jitter on your clock. You can then > wait for the arrival of a data pulse, using a 4-bit counter which > skips head a count if the data pulse occurs during the first three > counts (0,1,2,8,9,A), does nothing but count if it occurs during the > middle counts (3,4,B,C), and is disabled for one count, essentially > retarding the counter by one count, if the pulse occurs during the > last 3 counts of each 8-count cycle (5,6,7,D,E,F). Take your output > from the MSB of the 4-bit counter. This scheme should lock in four > bit periods of the counter, provided that the data rate is within 5% > of 1/16th the driver clock. The output clock will jitter at most > 6.25%. > > Dick > >Article: 20014
Sherdyn wrote: > The four frequencies are 420 us, 450 us, 500 us and 520 us. The module must > be able to auto-detect these frequencies as the bits which need to be > extracted later on are embedded in different locations away from the > synchronization > word. What I intend to do is to generate a clock which is running 8X or 16X > faster > than the detected clock (I have a system clock of 25 MHz). Use this > generated clock to run a counter which is then use as > indicator to sample data at the correct interval. After synchronization on > bit boundary is achieved, I can then synch to synchronization word before > extraction of bits can be performed. My problem is how can I detect these > four frequencies? I'm thinking of using a fast clock to start counting when > the first data transition occur and check the number of count when a second > data transition elapsed ... but, I face the second problem, the data > transition can occur at middle of bit or start of bit. Just start your 25 MHz counter on any transition, then ignore any transition while the counter is below about 10,000. Then stop the counter on the next transition. If you let the counter clear itself at 10,000 ( or thereabouts), you get relatively small values for the four frequencies ( 500, 1250, 2500, 3000) Look-up tables or a RAM can be used as discriminator with an optimized guardband. Then you can derive your 16 x clock from you 25 MHz. The numbers do not work out perfectly, but you can fix that by alternating between two very similar clock periods. Should be fairly simple. The enormous difference between 25 MHz and about 2 kHz helps you a lot. Peter Alfke, XilinxArticle: 20015
Keith, Hirose makes some itty bitty surface-mount coax connectors (the H.FL series) you can buy from Digikey. We often plop a few here and there on multilayer boards. The three gnd pins go to vias to the nearest ground plane, and the center pin goes through a via to whatever we're interested in: a test trace, a power plane, a power island, stuff like that. We then solder the connectors onto a bare board, TDR things, and see how close our theory came to real life. We often find that the PCB fab houses aren't too religious about the dielectric stackups! It's good to know this before you populate a mess of boards. The next time you buy boards, ask for a 'solder sample'. All board houses make 10-50% extras to make up for yield problems, and don't usually mind giving rejects or extras away. They'll sometimes punch a hole on it to ensure it's not usable! Keep in mind that a 30 ps TDR magnifies trace discontinuities greatly in most cases. You have to mentally (or mathematically!) lowpass filter the TDR display to make it consistant with your actual risetimes. We usually use four ceramic caps per Xilinx chip, near the corners of a 3.3 volt island. Seems to work fine. 460 is a LOT of caps! JohnArticle: 20016
I am working on my final project in EE which involves improving a single board computer used in several classes. Students usually build their own board (from a kit) for one class and many use the board in their projects. I am hoping to replace the GAL16V8 used for address decoding with something easier to program. So far all I have found is Lattice's ispGAL22V10. I found a schematic of the programmer cable and can get the software with a free 6 month license. I was wondering if anyone has any suggestions. It should easily replace a GAL device. Small size, low cost and ease of soldering (DIP or PLCC package) are important. The programmer must be simple and easy to build and software should be available for free. Thanks in advance for any suggestions. -- Shawn D'Alimonte - sdalimon@ee.ryerson.ca "Faster processors are nice, but they are not truly revolutionary. And neither are colors." - Jim Collas, Amiga Inc.Article: 20017
In article <86gmtj$bvg$1@ns2.ryerson.ca>, Shawn D'Alimonte <sdalimon@www.ee.ryerson.ca> wrote: > I am working on my final project in EE which involves improving a > single board computer used in several classes. Students usually build > their own board (from a kit) for one class and many use the board in > their projects. I am hoping to replace the GAL16V8 used for address > decoding with something easier to program. > > So far all I have found is Lattice's ispGAL22V10. I found a schematic > of the programmer cable and can get the software with a free 6 month > license. > > I was wondering if anyone has any suggestions. It should easily > replace a GAL device. Small size, low cost and ease of soldering (DIP > or PLCC package) are important. The programmer must be simple and > easy to build and software should be available for free. > > Thanks in advance for any suggestions. > > -- > Shawn D'Alimonte - sdalimon@ee.ryerson.ca > "Faster processors are nice, but they are not truly revolutionary. And > neither are colors." - Jim Collas, Amiga Inc. > You could use the smallest Xilinx XC9500 device. Programming software is free and downloadable from there site (WebPack) and programming is done through JTAG (6 pins ) form the parellel port of a PC. The adapter should cost around 50$, but if you want to build it itself there should be the schematics somewhere on Xilinx's Web-sites. -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20018
It sounds like CAM might be a solution. If so, Altera's APEX devices has memory blocks that can be configured as CAM. -Nikolay Mark Summerfield <m.summerfield@ieee.org> wrote in message news:388780C9.80BB528F@ieee.org... > Andreas Doering wrote: > > I am interested in the implementation of indexing memory in hardware > > (custom or FPGA). > > The problem is the following: > > say we have inputs a0,a1 > > and a0 (a 5-bit-vector) can have 19 different values and > > a1 (also 5-bit) can have 21 different values. > > We need to address a memory with binary addresses. > > Hence we could concatenate both vectors and needed 1K memory words. > > Have you considered commercially-available content-addressable memory > (CAM)? I don't have any experience actually using it myself, but it > seems to me that it could be used to do what you describe. A quick > web search turned up a number of manufacturers, or which Quality > Semiconductor (www.qualitysemi.com) is just one -- their data sheets > look pretty comprehensive. > > I don't know anything about the cost of such parts, and of course I > have no idea about the requirements of your application -- this is > just a thought. > > MarkArticle: 20019
Hi FPGA Experts, I have a Virtex prototyping board from VCC (www.vcc.com) which I currently program from an NT PC running the Xilinx alliance tools. The problem is that I run all of the other tools (VHDL simulation & synthesis, place & route) on a Sun; this machine is locked away in a machine room somewhere, and I have a Linux PC on my desk which I use as an X-terminal. I'd like to be able to get rid of the NT PC and plug the VCC board directly into my Linux box, but I can't find a way to download the bit file. What I need is either a utility that will download a bit file from Linux (I don't need anything like the hardware debugger), or alternatively a way to make the Sun version of the alliance tools talk to a serial port that's not on the local machine. Xilinx support tell me that neither is possible. I can't believe that I'm the only person ever to try to do this. Does anyone have any experience to share? If someone knows the protocol needed to talk to an X-checker or MultiLINX cable I'm happy to write my own tool. Thanks in advance, --Phil.Article: 20020
Hello, I want to use standard sdram ( 64 MByte ) with FPGA. Is it possible and where are examples to find ? Greetings Thomas SittArticle: 20021
Does anyone knows how to make polynomial calculation on FPGA ? Do you have any experience or do you know an homepage which is talking about ??? Best regards,Article: 20022
I've spent the last 6 months trying to design 10ka's with asynchronous fifo's. The E architecture came out just too late but we probably would have made up a couple of the months that we "saved" by going with the A. If they used the E type EAB from the outset we might have a different opinion but our next gen stuff is VERTEX all the way. To be fair the 10K had some advantages over the XC4000's I just can't quite put my finger on any. Does anyone still think that the ALTERA human interface is better? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 20023
Phil Endecott <phil_endecott@spamcop.net> writes: > I have a Virtex prototyping board from VCC (www.vcc.com) which I > currently program from an NT PC running the Xilinx alliance tools. The > problem is that I run all of the other tools (VHDL simulation & > synthesis, place & route) on a Sun; this machine is locked away in a > machine room somewhere, and I have a Linux PC on my desk which I use as > an X-terminal. I'd like to be able to get rid of the NT PC and plug the > VCC board directly into my Linux box, but I can't find a way to download > the bit file. What I need is either a utility that will download a bit > file from Linux (I don't need anything like the hardware debugger), or > alternatively a way to make the Sun version of the alliance tools talk > to a serial port that's not on the local machine. Xilinx support tell > me that neither is possible. What would probably work is to implement a fake serial port on the Sun box that behaves as a "'fake-serial-interface'->tcp/ip" proxy. Then on the Linuxbox you just convert back to a serial port. I would go looking on <url://freshmeat.net/> and maybe ask in a Unix/ Linux group. On freshmeat I at least found this: Serproxy is a multi-threaded proxy program for redirecting network socket connections to/from serial ports, in cases where the remote end of the serial link doesn't have a TCP/IP stack (eg an embedded or microcontroller system). The proxy allows other hosts on the network to communicate with the system on the remote end of the serial link. and: Sredird is a serial port redirector that is compliant with the RFC 2217 "Telnet Com Port Control Option" protocol. This protocol lets you share a serial port through the network. These might be suitable with som changes - and they're with free source code so that shouldn't be impossible:) Good luck -sig -- sigurd urdahlArticle: 20024
Thomas Sitt wrote:
>
> Hello,
> I want to use standard sdram ( 64 MByte ) with FPGA.
> Is it possible
Yes. You need to make a state machine to control splitting
and sequencing the address bus into row and column and
applying "strobes" at the proper times.
Synchronous DRAM adds requirements for setting a mode
register and synchronizing the IO.
Skip the fancy modes until you get a single beat
read/write working.
> and where are examples to find ?
http://209.67.241.58/reg/1997/060597/12df_04.htm
-Mike Treseler
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