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
Yes in my first design i used quickswich devices but then i decide to go to the newer devices like txs0108e. This is octal bi-directional bus with voltage level translation. And now i dont know is this design ok becuse like you write in previus post best metod is to use quickswich. What do you think about txs0108e in this design. Also i would not use cyclone just for memory, i want to use mc68000 core with sdram controler to replace mc68000 on the board. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152376
In article <0PSdnccmCKE4gtnTnZ2dnUVZ_tWdnZ2d@giganews.com>, foxclab01 @n_o_s_p_a_m.yahoo.gr says... > Are FPGA chips only for development boards or can I use them independently > in a PCB as I would do with any microcontroller? > Of course you can use the FPGA or CPLD components on your own boards. The development boards exist for the main purpose to enable initial playing around and algorithm development before there is a commitment to produce a full product PCB. -- Michael Karas Carousel Design Solutions http://www.carousel-design.comArticle: 152377
"majsta" <imajstorovic@n_o_s_p_a_m.yahoo.com> wrote in message news:68-dnacDFLV-AdTTnZ2dnUVZ_tqdnZ2d@giganews.com... > Hi there, i just fount this page and i hope that you can help me. Here is > what i need to do. I want to interface MC68000 to cyclone II. As you > allready know MC68000 is 5V system and i need to convert that signals to > 3.3V so i can use it in cyclone. I was working with txs0108e and now i > know > that 5V<=>3.3V are done in bidirectional mode but i dont know what > happened > to FCT to LVTTL conversion. Can it be done on this way or i need to use > some external FCT to TTL converters. Or i need to use something like > quickswich like QS3861. Can anyone help? I would offer You to use simple and trivial SN74LVC8T245. Thats also 8bit translator with two voltages.Article: 152378
scrts <hidden@email.com> wrote: > "majsta" <imajstorovic@n_o_s_p_a_m.yahoo.com> wrote in message > news:68-dnacDFLV-AdTTnZ2dnUVZ_tqdnZ2d@giganews.com... > > Hi there, i just fount this page and i hope that you can help me. Here is > > what i need to do. I want to interface MC68000 to cyclone II. As you > > allready know MC68000 is 5V system and i need to convert that signals to > > 3.3V so i can use it in cyclone. I was working with txs0108e and now i > > know > > that 5V<=>3.3V are done in bidirectional mode but i dont know what > > happened > > to FCT to LVTTL conversion. Can it be done on this way or i need to use > > some external FCT to TTL converters. Or i need to use something like > > quickswich like QS3861. Can anyone help? > I would offer You to use simple and trivial SN74LVC8T245. Thats also 8bit > translator with two voltages. Why not stay with the switches? That saves you from switching direction in the drivers. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 152379
Hi Folks, Incredibly busy summer here, so before burning my brain cells, Googling or -worst- digging in my very dusty math courses, I submit this question to the DSP experts who usually float around, hoping some aren't at the beaches ;-) How would you extract D from a X = K / (D * D) value (16 bits) ? - in a small FPGA indeed, which has no embedded mult (but a mult could be synthesized) - please don't answer to synthesize sqrt(1/x) ! - I have lots of clock cycles available to compensate the lack of FPGA resources. - I would like to avoid a Piece-Wise Linear estimator if possible (though it would allow for coding sensor non-linearities). In the past, I remember implementing an sqrt operator using a suite (the suite didn't converge as rapidly as it might, but the implementation was easy), so a similar technique would be nice. But I keep an open mind : any idea is most welcome :-) Thanks, BertArticle: 152380
Bert_Paris <do_not_spam@me.com> wrote: (snip) > How would you extract D from a X = K / (D * D) value (16 bits) ? > - in a small FPGA indeed, which has no embedded mult (but a mult could > be synthesized) > - please don't answer to synthesize sqrt(1/x) ! > - I have lots of clock cycles available to compensate the lack of FPGA > resources. > - I would like to avoid a Piece-Wise Linear estimator if possible > (though it would allow for coding sensor non-linearities). There is an iterative sqrt algorithm that only does subtraction. For only 16 bits, it shouldn't take a lot of LUTs, and not so many cycles, either. I haven't thought about coding it in logic lately, though. What about the K? -- glenArticle: 152381
glen herrmannsfeldt said : > There is an iterative sqrt algorithm that only does subtraction. > For only 16 bits, it shouldn't take a lot of LUTs, and not > so many cycles, either. I haven't thought about coding it > in logic lately, though. What about the K? > > -- glen As mentioned, I have no problem regarding sqrt, but it is 1 / Sqr(D) that I have to transform. The solution I had in mind before posting was to use a non-restore division (for 1/X) followed by the iterative sqrt. But maybe some one has a better idea. BertArticle: 152382
On 17/08/2011 13:11, Bert_Paris wrote:
> Hi Folks,
> Incredibly busy summer here, so before burning my brain cells, Googling
> or -worst- digging in my very dusty math courses, I submit this question
> to the DSP experts who usually float around, hoping some aren't at the
> beaches ;-)
>
> How would you extract D from a X = K / (D * D) value (16 bits) ?
> - in a small FPGA indeed, which has no embedded mult (but a mult could
> be synthesized)
> - please don't answer to synthesize sqrt(1/x) !
> - I have lots of clock cycles available to compensate the lack of FPGA
> resources.
> - I would like to avoid a Piece-Wise Linear estimator if possible
> (though it would allow for coding sensor non-linearities).
Have you figured out what accuracy you need? It will make a /big/
difference to the ease of implementation.
Implementing a linear interpolation means having a table of
coefficients. Have you got space to allow lookup in a table of some sort?
You can reduce the coefficients a bit by first left-shifting X by two
bits repeatedly until you have a 1 in either of the two MSB's. Once you
have calculated D, right-shift it by 1 bit for each 2 bits you
left-shifted X. This will save you from having to have high-precision
lookups for small X.
>
> In the past, I remember implementing an sqrt operator using a suite (the
> suite didn't converge as rapidly as it might, but the implementation was
> easy), so a similar technique would be nice.
> But I keep an open mind : any idea is most welcome :-)
>
You don't just have to do a square root - you also have to do a
reciprocal. These are both relatively hard to implement accurately
(unlike multiplication, which is fairly easy - and quite small if you
have lots of clock cycles and can do it bit for bit).
If you are looking for a series of estimators, Newton-Raphson generally
gives fast convergence. The sequence for your problem would be:
D_{n+1} = (3/2).D_n - (X/2K).D_n^3
Unfortunately, that will need a number of multiplies per cycle. You
would also need to test how well it worked with limited bit precision.
Article: 152383
Thanks for your feedback !
David Brown a formulé la demande :
> On 17/08/2011 13:11, Bert_Paris wrote:
>>
>> How would you extract D from a X = K / (D * D) value (16 bits) ?
>> - in a small FPGA indeed, which has no embedded mult (but a mult could
>> be synthesized)
>> - please don't answer to synthesize sqrt(1/x) !
>> - I have lots of clock cycles available to compensate the lack of FPGA
>> resources.
>> - I would like to avoid a Piece-Wise Linear estimator if possible
>> (though it would allow for coding sensor non-linearities).
>
> Have you figured out what accuracy you need? It will make a /big/ difference
> to the ease of implementation.
10 bits looks good enough.
> Implementing a linear interpolation means having a table of coefficients.
> Have you got space to allow lookup in a table of some sort?
Not ideal in the context (uninitialized RAMs) :-( but that's doable.
> You can reduce the coefficients a bit by first left-shifting X by two bits
> repeatedly until you have a 1 in either of the two MSB's. Once you have
> calculated D, right-shift it by 1 bit for each 2 bits you left-shifted X.
> This will save you from having to have high-precision lookups for small X.
If I calculate the sqrt first, I may not need this.
>
>> In the past, I remember implementing an sqrt operator using a suite (the
>> suite didn't converge as rapidly as it might, but the implementation was
>> easy), so a similar technique would be nice.
>> But I keep an open mind : any idea is most welcome :-)
>>
>
> You don't just have to do a square root - you also have to do a reciprocal.
Absolutely !
> These are both relatively hard to implement accurately (unlike
> multiplication, which is fairly easy - and quite small if you have lots of
> clock cycles and can do it bit for bit).
>
> If you are looking for a series of estimators, Newton-Raphson generally gives
> fast convergence. The sequence for your problem would be:
>
> D_{n+1} = (3/2).D_n - (X/2K).D_n^3
>
> Unfortunately, that will need a number of multiplies per cycle. You would
> also need to test how well it worked with limited bit precision.
While googling, I found a "magical" estimator based on manipulating
an IEEE floating point as an integer (which they refine with
an iteration of the NR above). Not useful here I guess.
After some thinking I will probably try this :
- calculate sqrt in format 8.2 or 8.3
- use a 1024 entries LUT for the reciprocal
or (due to lack of ROM) :
- use a non-restore division 2**N / X
Thanks !
Article: 152384Hi I have found old parts lying around in the lab and I could put them to good use. Alas, they are not supported by Quartus any more. Do you know which version of the tool I should get (and where I could get it, if Altera doesn't provide it) ? Thanks NicolasArticle: 152385
Bert_Paris <do_not_spam@me.com> wrote: (snip, I wrote) >> There is an iterative sqrt algorithm that only does subtraction. >> For only 16 bits, it shouldn't take a lot of LUTs, and not >> so many cycles, either. I haven't thought about coding it >> in logic lately, though. What about the K? > As mentioned, I have no problem regarding sqrt, but it is 1 / Sqr(D) > that I have to transform. > The solution I had in mind before posting was to use a non-restore > division (for 1/X) followed by the iterative sqrt. But maybe some one > has a better idea. In Newton-Raphson, reciprocal square root is easier than just square root, but that might not be true for the subtract based version. Non-restore divide is pretty small, or even restore divide, if you have the clock cycles to spare. How many cycles do you have? -- glenArticle: 152386
"Nicolas Matringe" <nicolas.matringe@fre.fre> wrote in message news:4e4c1188$0$7330$426a74cc@news.free.fr... > Hi > I have found old parts lying around in the lab and I could put them to > good use. Alas, they are not supported by Quartus any more. Do you know > which version of the tool I should get (and where I could get it, if > Altera doesn't provide it) ? > > Thanks > Nicolas Quartus V9.1 sp2 (the last sensible version before the excellent internal simulator was dropped) supports Flex10k. Should still be available on Altera website. PhilArticle: 152387
Le 17/08/2011 21:18, Phil Emmup a écrit : > Quartus V9.1 sp2 (the last sensible version before the excellent internal > simulator was dropped) supports Flex10k. > > Should still be available on Altera website. Thanks a lot. I finally found the old version page on Altera website. NicolasArticle: 152388
On Aug 4, 12:51=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Jul 29, 6:59=A0am, Mawa_fugo <cco...@netscape.net> wrote: > > > Let say I have two DVI streams - generated by two encoders, those have > > different video contents but same pixel clock > > > The two tmds streams travel thru cables then - are decoded by two > > decoders - then fed into an FPGA > > > The question is how the two clocks at the output of the encoders look > > like, are they the same? Can we use only one clock for both channel to > > clock the data in the FPGA? > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > My theory is that, the original clock goes to two 10x then divided > > back 1/10, so they are supposedly be in same phase... or what > > else ??? > > If the same source is used for the pixel clock of both encoders, and > by same I mean only one physical clock oscillator is used for both > encoders, then you can be sure that that the bit rate for both > encoders is the same. =A0However, there will be no guaranteed phase > relationship between the data output of the two encoders. > > You could use the same original clock source, or one of the two clock > outputs from the encoders, and a dynamic phase aligner for the > receivers in the FPGA to cut down on the clocking resource requirement > in the FPGA. =A0However, you may find it easier to use the clock/data > from each encoder to capture the data and then put it through a simple > shallow depth synchronous FIFO and use a single global clock for the > rest of your system. > > Ed McGettigan > -- > Xilinx Inc. Good idea, that's what I'm heading to - thanks all for advicesArticle: 152389
I'm troubleshooting the first rev of my first Spartan 6 PCB design; this is sort of a learn-by-making-all-the-mistakes process, but I could sure use a hint or two here from the gurus. Obviously there are a million things that can lead to a board not coming up, but my understanding is that very few things can lead to the situation where the JTAG interface won't even shift (i.e. TDO stuck at zero). For example, the JTAG interface doesn't rely on any of the clock inputs, nor the I/O banks. Basically, if Vcore (1.2v) and Vccaux (3.3v) are supplied, and there are no shorts, then the JTAG ought to work, right? Even mis-configured mode pins (M0, M1) shouldn't affect this. Designing a good power distribution network (bypass caps) is tricky, but even getting that wrong shouldn't matter for something running at the JTAG TCK rate (dozens of khz), right? FWIW, I tried the board without any of the bypass caps -- nothing soldered down but the two voltage regulators and the Spartan chip -- still no luck. Current draw is around 11mA from the 6V supply, so I doubt there's a short. I think that sounds right for an unconfigured device with no pins toggling, right? I'm only powering one of the four I/O banks (same supply as Vccaux); the others are unconnected. Thanks for any ideas or suggestions or ideas on what to try next (or pointers on which M to RTF)! (PS: this board doesn't use any high speed I/Os or anything fancy like that.. in fact, unbelievably, the design clock input is the *only* user I/O pin! All communication with the device is via BSCAN_SPARTAN6. For that reason and others this is probably the simplest Spartan6 board ever designed, which is the only reason I attempted it!)Article: 152390
Of course you'll have to deal with the special case 1/sqrt(0) = infinity. Leaving that aside: >> You can reduce the coefficients a bit by first left-shifting X by two >> bits repeatedly until you have a 1 in either of the two MSB's. Once >> you have calculated D, right-shift it by 1 bit for each 2 bits you >> left-shifted X. This will save you from having to have high-precision >> lookups for small X. This is very good advice, it makes the problem *much* easier. This approach works because 1/sqrt(4D) = 1/sqrt(D) >> 1 The HW required is a leading-1 detector that selects whether to left shift the input 16 bits by 0/2/4/8/10/12/14 bits and later to right shift the output by 0/1/2/3/4/5/6/7 bits. This approach means that you now only have to deal with the input range 16384...65535. Why is that an advantage ? Because the function 1/sqrt(D) is highly nonlinear over the range 1...65535 but only mildly nonlinear over the range 16384...65535. Linear interpolation will work *much* better over the reduced range. Some numbers to back this up: derivative of 1/sqrt(D) is -1/2Dsqrt(D) derivative @ 1 = -0.5 derivative @ 16384 = -2.38e-7 derivative @ 65535 = -2.98e-8 The /gradient/ of the curve changes by a factor of roughly 17,000,000 times between 1 and 65535 but only by a factor of 12.5 between 16384 and 65535. In other words, the curve is *much* more linear over the reduced range. Applying piecewise linear interpolation over the reduced range should work well. As an example, using just 1 linear segment will give you around a 20% worst case error (at the middle of the range ie 40960). Using 64 linear segments will give you about 12 bit accuracy. Hope that helps. Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.auArticle: 152391
Hi Karl, On 08/18/2011 01:53 PM, karl schrunk wrote: > I'm troubleshooting the first rev of my first Spartan 6 PCB design; > this is sort of a learn-by-making-all-the-mistakes process, but I > could sure use a hint or two here from the gurus. > > Obviously there are a million things that can lead to a board not > coming up, but my understanding is that very few things can lead to > the situation where the JTAG interface won't even shift (i.e. TDO > stuck at zero). Correct. > For example, the JTAG interface doesn't rely on any of the clock > inputs, nor the I/O banks. Basically, if Vcore (1.2v) and Vccaux > (3.3v) are supplied, and there are no shorts, then the JTAG ought to > work, right? Even mis-configured mode pins (M0, M1) shouldn't affect > this. Correct. > Designing a good power distribution network (bypass caps) is tricky, > but even getting that wrong shouldn't matter for something running at > the JTAG TCK rate (dozens of khz), right? FWIW, I tried the board > without any of the bypass caps -- nothing soldered down but the two > voltage regulators and the Spartan chip -- still no luck. Depending on your JTAG cable, it's probably clocking in the range 1MHz to 33MHz. Signal integrity does matter for JTAG, but it should be easy to make it good enough - use serial termination resistors of 30-60 ohms at the sources and make sure that the traces are never very far away from a ground plane. > Current draw is around 11mA from the 6V supply, so I doubt there's a > short. I think that sounds right for an unconfigured device with no > pins toggling, right? For a small Spartan 6 that sounds right. > I'm only powering one of the four I/O banks > (same supply as Vccaux); the others are unconnected. That's your show stopper. Don't ever leave ground or power pins unconnected unless the data sheet specifically tells you to do so. If you can, hook up your Vccaux supply to the unconnected banks. Should solve the problem. > Thanks for any ideas or suggestions or ideas on what to try next (or > pointers on which M to RTF)! One thing I always do when bringing up a new board: assemble two or three of them, minimum. When you see something unexpected, test to see if it affects all three boards in the same way - that way you can tell whether it's a design problem or just dodgy soldering on one board. Another suggestion is to buy an off the shelf development board that uses the same FPGA so that you have a known working system to compare with. If you're using Spartan 6 LX4 or LX9 you'll find some very affordable ones here: www.sioi.com.au/shop/ Best regards, Stephen Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.auArticle: 152392
Steve <theecobs@gmail.com> wrote: (snip, someone wrote) >>> You can reduce the coefficients a bit by first left-shifting X by two >>> bits repeatedly until you have a 1 in either of the two MSB's. Once >>> you have calculated D, right-shift it by 1 bit for each 2 bits you >>> left-shifted X. This will save you from having to have high-precision >>> lookups for small X. > This is very good advice, it makes the problem *much* easier. > This approach works because 1/sqrt(4D) = 1/sqrt(D) >> 1 Usually this would be done with a barrel shifter, but they are not very LUT efficient in many FPGAs. If you aren't so restricted in cycles, though, you can use an ordinary shift register. I am not sure sure how much that saves in cycles or cells. -- glenArticle: 152393
Hi Stephen, thanks so much for taking the time to reply... > > I'm only powering one of the four I/O banks > > (same supply as Vccaux); the others are unconnected. > That's your show stopper. =A0Don't ever leave ground or power pins > unconnected unless the data sheet specifically tells you to do so. Hrm, I only did that because page 32 of UG393 seemed to say that it was okay to: "In some cases, one or more I/O banks in an FPGA are not used (for example, when an FPGA has far more I/O pins than the design requires). In these cases, it might be desirable to leave the bank=92s associated VCCO pins unconnected, as it can free up some PCB layout constraints (less voiding of power and ground planes from via antipads, less obstacles to signals entering and exiting the pinout array, more copper area available for other planelets in the otherwise used plane layer)." Clearly in an ideal world I should have spent the time wiring up those pins. But in light of the paragraph above, I'm a bit hesitant to bet a week and a board order on this being the problem... unless I've misread it, which is absolutely possible. Have I? > Depending on your JTAG cable, it's probably clocking in the range 1MHz to= 33MHz I tried forcing the clock rate to 2400 hz (no, that's not a typo) in urjtag; still all zeroes on TDO. > > Current draw is around 11mA from the 6V supply > For a small Spartan 6 that sounds right. It's an LX25, so it's sort of middle-size.Article: 152394
On 08/18/2011 05:11 PM, karl schrunk wrote: > Hi Stephen, thanks so much for taking the time to reply... > > >>> I'm only powering one of the four I/O banks >>> (same supply as Vccaux); the others are unconnected. > >> That's your show stopper. Don't ever leave ground or power pins >> unconnected unless the data sheet specifically tells you to do so. > > Hrm, I only did that because page 32 of UG393 seemed to say that it > was okay to: > > "In some cases, one or more I/O banks in an FPGA are not used (for > example, when an FPGA has far more I/O pins than the design requires). > In these cases, it might be desirable to leave the bank’s associated > VCCO pins unconnected, as it can free up some PCB layout constraints > (less voiding of power and ground planes from via antipads, less > obstacles to signals entering and exiting the pinout array, more > copper area available for other planelets in the otherwise used plane > layer)." > > Clearly in an ideal world I should have spent the time wiring up those > pins. But in light of the paragraph above, I'm a bit hesitant to bet > a week and a board order on this being the problem... unless I've > misread it, which is absolutely possible. Have I? You're right, UG393 says that it's okay to leave unused VCCO pins unconnected. Sorry for steering you wrong there. > >> Depending on your JTAG cable, it's probably clocking in the range 1MHz to 33MHz > > I tried forcing the clock rate to 2400 hz (no, that's not a typo) in > urjtag; still all zeroes on TDO. > > >>> Current draw is around 11mA from the 6V supply > >> For a small Spartan 6 that sounds right. > > It's an LX25, so it's sort of middle-size. How are you converting the 6V down to 3.3V and 1.2V ? Have you checked that these supply rails aren't noisy ? I'm happy to take a quick look if you want to send me your schematic offline. Best regards, Stephen Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.auArticle: 152395
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Steve <theecobs@gmail.com> wrote: > (snip, someone wrote) > >>> You can reduce the coefficients a bit by first left-shifting X by two > >>> bits repeatedly until you have a 1 in either of the two MSB's. Once > >>> you have calculated D, right-shift it by 1 bit for each 2 bits you > >>> left-shifted X. This will save you from having to have high-precision > >>> lookups for small X. > > This is very good advice, it makes the problem *much* easier. > > This approach works because 1/sqrt(4D) = 1/sqrt(D) >> 1 > Usually this would be done with a barrel shifter, but they are > not very LUT efficient in many FPGAs. If you aren't so restricted > in cycles, though, you can use an ordinary shift register. You can use a Multiplier as barrel shifter too (Xilinx xapp195) -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 152396
karl schrunk <karlschrunk@gmail.com> wrote: > I'm troubleshooting the first rev of my first Spartan 6 PCB design; > this is sort of a learn-by-making-all-the-mistakes process, but I > could sure use a hint or two here from the gurus. > Obviously there are a million things that can lead to a board not > coming up, but my understanding is that very few things can lead to > the situation where the JTAG interface won't even shift (i.e. TDO > stuck at zero). In a hand soldered engineering design, bad contacts or shorts in the JTAG chain can be common... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 152397
>> Usually this would be done with a barrel shifter, but they are >> not very LUT efficient in many FPGAs. If you aren't so restricted >> in cycles, though, you can use an ordinary shift register. > > You can use a Multiplier as barrel shifter too (Xilinx xapp195) Given that there are plenty of clock cycles available and not much HW, I'd spend the first 8 clock cycles looking at the two MSBs and left shifting two positions when those MSBs are 00. The detection of the zero input special case can also be folded into this part very efficiently. Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.auArticle: 152398
On Aug 17, 2:27=A0pm, Nicolas Matringe <nicolas.matri...@fre.fre> wrote: > Le 17/08/2011 21:18, Phil Emmup a =E9crit : > > > Quartus V9.1 sp2 =A0(the last sensible version before the excellent int= ernal > > simulator was dropped) supports Flex10k. > > > Should still be available on Altera website. > > Thanks a lot. > I finally found the old version page on Altera website. > > Nicolas Note, Altera often supports parts long after they stop showing up in the device selection panel. I have a board with somewhat rare Flex10K100 on it (specifically, a 10K100GC503-3), that quit showing up in the drop downs a very long time ago. The original design was done in MaxPlusII! I have to manually edit the QSF with the specific part number to get it to work. However, if you get the part number exactly right, Quartus will set everything else up for you. Even the pin mapper works correctly. It's as if Altera doesn't want to advertise support for these older parts, but keeps it anyway. This may not apply to the Flex10K for current versions, but as a general rule, Altera (and Xilinx) often support obsolete parts this way.Article: 152399
On Thursday, August 18, 2011 5:18:07 AM UTC-4, Uwe Bonnes wrote: > karl schrunk <karls...@gmail.com> wrote: > > I'm troubleshooting the first rev of my first Spartan 6 PCB design; > > this is sort of a learn-by-making-all-the-mistakes process, but I > > could sure use a hint or two here from the gurus. >=20 > > Obviously there are a million things that can lead to a board not > > coming up, but my understanding is that very few things can lead to > > the situation where the JTAG interface won't even shift (i.e. TDO > > stuck at zero). >=20 > In a hand soldered engineering design, bad contacts or shorts in the JTAG > chain can be common... > --=20 > Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de >=20 > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- What's also common is for the JTAG to be connected incorrectly. Assuming th= is is the only device in the chain, TDI of the programmer goes to TDI of th= e FPGA, _not_ TDO. Then, obviously, TDO of the programmer goes to TDO, _not= _ TDI.=20 As someone else already stated, make sure you have some series termination = resistors (roughly 33ohm) in place. Put them as close as practical to the d= riving pin. That would be near the TDI, TCK, and TMS pins of the JTAG conne= ctor and TDO pin of the FPGA. Signal integrity is not dependent on the freq= uency of your signal, it's dependent on the edge rate. You could have signa= l integrity issues even at your 2400Hz. Also make sure that you supply ground and a reference voltage to the progra= mmer. Make sure you have all the required pull ups and downs on the JTAG si= gnals. Look at the JTAG signals on a scope and make sure that the edges look clean= . Look at TDO coming out of the FPGA to see if it really is low all the tim= e. IIRC, Xilinx has a debug mode for the JTAG programmer so that you can ex= ercise the lines.=20 -- Marc
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