Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Fri, 31 Mar 2006 22:10:24 -0800, Phil Hays <Spampostmaster@comcast.net> wrote: >John Larkin wrote: > >>And we sure will be more careful about oscillators and clock >>distribution in the future... everything's getting too fast. It was >>probably the move of the ground plane to layer 5 of 6 (the clock is >>mostly routed on 6), and the fast/weak xo, that caused the problem. >>Clock-on-the-bottom isn't ideal for noise immunity, either. > >The change in stackup might have made the problem worse, but >daisy-chained clocks are a bad idea with high speed logic. It is >better to star route them, with equal length lines from the clock >driver to each destination with source termination resisters. For a >fanout greater than 1, don't use the oscillator output directly, use >it to drive a higher drive gate. Yup, that's about ideal. >Daisy chaining clocks is bad for signal integrity and for clock skew. Skew doesn't matter here, and daisy chaining is fine *if* everything is done right, which it wasn't in this case. ECL clocks are usually daisy-chained... many small chips and picosecond skew requirements between nearby chips. Star fanout to 50 or so loads gets messy. We're leaning towards slowing down the edge at the xo, maybe with an R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at each fpga, giving most of a volt of noise immunity. There's no room for star traces, or at least not without a lot of ripups. If we put the tinies on the bottom, under the fpga's, they fit nicely and we don't have to waste a bunch of hundreds of bucks on a new solder-paste stencil and reprogramming the pick-and-place. Hey, the CPU has a clock-out pin, same freq as the clock-in in this case. We could use *that* to drive the two following FPGAs in the string. It's a 68332, ancient process cmos, swings hard and makes nice sedate edges! May as well leave the deglitcher in there, so we don't have to re-release the designs. JohnArticle: 100026
Hi Jim and Rich, Thanks for the replies. Rich is right, I do use fpgas for my designs. But nonetheless, i apologize for not reading the datasheet a little more carefully. Thanks you two; much appreciated. Regards, PhilArticle: 100027
On Sat, 1 Apr 2006 03:17:55 +0000 (UTC), kensmith@green.rahul.net (Ken Smith) wrote: >In article <p6nq22l4nf53kqanjhu7d4ojn70nb933nm@4ax.com>, >John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >[....] >>I wonder if anyone has ever kluged a bga layout, sort of like one of >>those jellyfish with a thousand tentacles. > >More likely it would be a costly blind-via PCB that sits between the BGA >and the base PCB. (Vomit) > One of my customers screwed up the pinout on a largish microprocessor chip, *every pin*, and kluged it to work. It looked like a chip sitting on a ball of red yarn. JohnArticle: 100028
On Sat, 01 Apr 2006 17:53:36 GMT, John_H <johnhandwork@mail.com> wrote: >rickman wrote: >> In general, the power and ground plane coupling provides capacitance at >> the highest frequencies where caps are too high impedance to do much >> good. So don't skimp on the planes, keep them as large as possible. >> In the end you may need to add a second power layer or mix power and >> signals just because most parts require two voltages and running split >> power planes to the same part can be difficult. > >Another right answer :-) > >But consider: while the capacitance is larger to have 100 sqare inches >rather than 16, the point where the open edges of the PCB make the plane >capacitance worthless due to replections (think quarter wave antenna >here) is 2.5x worse. The bulk capacitance is better but the board >capacitance will "open circuit" at a lower frequency. I sometimes add SMA connector footprints to my boards so I can TDR the bare boards and measure plane/pour noise on working boards. I've never been able to resolve an edge reflection, using a 20 GHz TDR. I think a typical pcb dielectric+copper structure is just too lossy. As far as I can measure, a small-gap ground/powerplane structure behaves like an ideal capacitor, and as you add bypasses *anywhere* on the board, it looks like a bigger ideal capacitor. I've seen no advantage to mixing ceramics, so I just use 0.33 uF. > >As Howard Johnson pointed out in last week's Xilinx webcast, that point >is rather moot for modern BGAs with the chips separated from the board >by the "masking inductance" to where those higher frequencies are a >problem for the BGA package or the chip itself. Howard knows a lot of stuff, and makes up the rest. JohnArticle: 100029
On Fri, 31 Mar 2006 21:57:49 +0100, "Slurp" <slip@slop.slap> wrote: > >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:ot0r22p8pdcr2g956ef1ln8h852ll9s7g2@4ax.com... >> On 30 Mar 2006 22:22:07 -0800, "Jeff Brower" <jbrower@signalogic.com> >> wrote: >> >>>John- >>> >>>> Except that I can flip through a 20-page schematic and not only >>>> understand what it does, I can usually spot hazards and bugs quickly, >>>> sometimes in seconds. Nobody can do that with a few thousand lines of >>>> uncommented HDL. >>>> >>>> Parallel beats sequential, which is what FPGAs are all about. >>>> >>>> And if they call you Gramps, it's easy enough to fire them and hire a >>>> fresh batch. >>> >>>Sure if it's OrCAD, which we use it for complex board designs. Yes you >>>can spot errors fast and things jump out that can save your board >>>desgin. >> >> PADS has a beautiful schematic editor. >> >>> >>>But ISE? A 20 page schematic in ISE is like trying to cut concrete >>>with knife. You can do it, but only if you have a LOT of time on your >>>hands, maybe for example a need to escape from prison :-) >>> >> >> Well, the library symbols sure are hideous. What *were* they thinking? >> >> Too bad there's no universal schematic file format. Schematics would >> be more pleasant if, for example, old Foundation schematics could be >> imported into ISE; it's criminal that they can't. >> >> LT Spice seems to have a nice external ASCII file format for >> expressing schematics. >> >> John >> > >Now if you use the Altera Quartus schematic capture I personally believe you >get a superb set of tools and symbols. > >Here is an example I dropped together inside 3 mins, ready to synthesise. >Only needs the pins and device defining before I can drop it straight into a >part. > >http://www.wheelnut.plus.com/Block1_bdf.pdf > >I bet not many engineers cannot see what the intent is in this extreme >trivial example.... Very nice. > >..... as opposed to shedloads of VHDL which would take a week and numerous >sketches to work out what is going on, looking for typos and missed >declarations etc. Or you can buy an expensive software thingie that turns your VHDL into a (very, very ugly) schematic to help you understand what it does. JohnArticle: 100030
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:mbit229a62jkgeffc3r9h8jgmr9ekh2s96@4ax.com... > > Howard knows a lot of stuff, and makes up the rest. > > John > That's hilareous, but partly true. I've been a Howie fan since Black Magic came out and it's been interesting to see what is gospel one year become anathema the next. The whole topic of high-speed design (SI, PDS design, modeling, etc.) reminds me of the FDA guidelines on what's good and bad to eat. It's all a constantly moving target, which is understandable because this is very complicated stuff. After seeing some awful board stackups and PDS designs work flawlessly, I've concluded that a lot of the advanced art of PDS design is only needed for boards with super high-speed and high-current devices, like Pentium processors and the like. The research is driven mainly by companies like Sun, who deal in that area, and by the consultants and EDA tool vendors who have a vested interest in companies trying to follow the "state of the art" PDS design methodologies. Way overkill for most designs, even very large FPGA designs. Signal integrity is a different story. There are tons of ways to get in trouble there, as I've proven to myself many times. :) RobArticle: 100031
Hello John, > We're leaning towards slowing down the edge at the xo, maybe with an > R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at > each fpga, giving most of a volt of noise immunity. There's no room > for star traces, or at least not without a lot of ripups. If we put > the tinies on the bottom, under the fpga's, they fit nicely and we > don't have to waste a bunch of hundreds of bucks on a new solder-paste > stencil and reprogramming the pick-and-place. > That increases phase noise. It may not matter in the digital world but I wouldn't do that for ADC clocks. One technique I use if a home-run star system isn't practical is a nicely impedance controlled clock line (or a few) and then tapping off with low-C RF transistors wherever the clock is needed. It raises the hackles of the digital folks during design reviews but after a thorough explanation they like it. That's how TV distribution used to be done in Europe, one line down from the roof and tapped off with -20dB couplers. At the very end there is a terminator. I use AC termination, mostly. Regards, Joerg http://www.analogconsultants.comArticle: 100032
> Altera provides these SERDES transmit and receive functions within their > Mega Wizard tool box. These packaged functions take care of all of the > timing needed to either receive or transmit the high speed serial data. > The one thing that bit me though was that the SERDES transmit/receivers is that the Stratix II family had no knowledge of bit alignment.relative to the SERDES clock. My previous SERDES experience used discrete parts where the timing of each bit relative to the rising edge of the clock was defined. The Stratix II documentation I worked with sure implied that this was true also (bit as I realized later when the bite chomped down it did not directly say so. Having worked with the discrete chips seeing the same drawings in the Stratix documentation led me astray). With Stratix II (and maybe this is common with all SERDES other than discrete chips) the receive side needs to manually align the bits relative to the clock. The MegaWizard brings has an optional input that you absolutely must use since you most likely will not power up with bits aligned where you want them. Also, each SERDES channel needs to be individually aligned (i.e. bit 7 may show up at one spot relative to the clock on channel 1 but there is no guarantee that bit 7 on channel 2 will be there as well). The problem then becomes how do you get the transmitter and receiver to 'know' when they should be trying to align bits relative to the clock and when are you all aligned and ready to go? That solution comes on a case by case basis depending on what your system is. In hindsight this was all ignorance on my part in part caused by prior SERDES knowledge with the discrete chips...but thought I'd pass the 2 cents along. KJ "Rob" <robnstef@frontiernet.net> wrote in message news:V9lXf.4539$kg.2858@news02.roc.ny... > Stratix has fast fabric on two sides of the chip for handling the SERDES > interface. The internal logic fabric can NOT handle these high serialized > data rates. One must de-serialize the data, do whatever logic is > necessary, and send it through a SERDES transmitter on the other side of > the FPGA. > > Altera provides these SERDES transmit and receive functions within their > Mega Wizard tool box. These packaged functions take care of all of the > timing needed to either receive or transmit the high speed serial data. > > It sounds like you have 2 SERDES channels coming in and one going out; and > you need to select which input gets routed to the output--the FPGA is the > right solution for his situation. If the input and output SERDES channels > have the same make up (lanes and bits / lane) and there is nothing you > have to do with the data, then the design is fairly staright forward. > Deserialize both of the input SERDES channels (using the MegaWizard > function) into a mux; and then connect the output of the mux to the input > of the SERDES transmitter (MegaWizard function). > > Take care, > Rob > > > "pinku" <praveenkumar.bm@gmail.com> wrote in message > news:1143824706.197533.207620@u72g2000cwu.googlegroups.com... >> Hello Groups, >> >> I have a 1Gbps SERDES output from the Network processor. But as i have >> 2 SERDES signal coming from the back plane, depending of SEL line i >> have to connect one of the SERDES to network processor. So i am using >> FPGA to interface this, which takes a SERDES input and I have FIFO for >> transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again >> connected to another SERDES which in turn connect to the Backplane. So >> i need 4 SERDES for implementing it. Will this intermediate Logic >> create for end to end SERDES data transfer ? Is there any other way of >> implementing this logic? I am planning to use Stratix GX FPGA. >> >> Please let me know your suggestion, >> waiting for your reply, >> Kumar >> > >Article: 100033
"johnp" <johnp3+nospam@probo.com> wrote in message news:1143913431.274974.10660@j33g2000cwa.googlegroups.com... > The OP wanted a "time efficient" approach for adding USB support. > > I suspect trying to embed USB IP inside a FPGA does not meet > this requirement. Yes, you could add a USB core and a PHY and > an embedded processor and write and debug a bunch of code.... > > Or you could leverage parts like the Cypress FX2 that provides several > easy approaches to doing this. > > Which is more "time efficient"? > > John Providenza > What's more time efficient then going to your EDK and just adding an OPB_USB peripheral? I was just asking why such a thing doesn't appear to exist. But, yes, I agree I strayed off topic. -ClarkArticle: 100034
rickman wrote: > I just had a design review on my board and I was zinged for using > resistors to pull the M[2:0] pins to power or ground. I have always > done it that way and do not see a reason to change. But the Xilinx > documents were shown to me, specifically XAPP453, where they clearly > show the pins being pulled hard to power or ground. For Spartan-3 FPGAs, it is perfectly acceptable to tie the M[2:0] pins directly to either VCCAUX (2.5V) or to GND. External pull-up or pull-down resistors are also acceptable, but not required. I tend to use external pull-ups or pull-downs as it allows me to override the default FPGA configuration mode on the board. In some systems, this may be desirable for field diagnostics, etc. On Spartan-3E FPGAs, the M[2:0] pins _can_ be user-I/O after configuration. If using these pins as user-I/O, then you definitely want to use pull-up or pull-down resistors. BTW, the mode pins have internal pull-up resistors that are active during configuration. If left floating externally, the M[2:0] mode pins will see "111" and the FPGA will be in Slave Serial configuration mode. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 100035
The JTAG interface on Spartan-3 FPGAs are powered by the VCCAUX (2.5V) supply. The key limitation is to avoid back-driving the JTAG inputs. For example, if you apply a 3.3V input to a JTAG input, then there will be a path back through the ESD protection diode. There are a variety of solutions here, depending on your specific application. 1. If driving the JTAG interface with 2.5V, no problem. 2. If actively driving the JTAG interface with 3.3V, be sure to use current-limiting series resistors and it is best to park the lines low or let them float when not in use. You can also three-state the JTAG pins after configuration or drive them using open-drain outputs. The JTAG pins have dedicated pull-up resistors to VCCAUX during configuration. After configuration, these pull-up resistors are left enabled by default. Via bitstream options, you can also change these to pull-down resistors or turn them off. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 100036
To concatenate strings in Verilog, you can generally just use vector
concatenation of the regs containing the string values. However, you
should remain aware that it is not really a string concatenation,
because that matters in some situations. For example, if you tried to
do
reg [8*80:1] dir_name, file_name, full_name;
initial
begin
dir_name = "./mydir/";
file_name = "file.dat";
full_name = {dir_name, file_name};
$display("%s", full_name);
end
This won't work, because file_name is not just "file.dat". It is
"file.dat" with an extra 70 null or zero bytes in front of it. Those
extra nulls will appear in the concatenation too. That 160 byte wide
concatenation will get truncated back to 80 bytes when assigned to
full_name, losing the part from dir_name entirely. But if you declared
file_name to be 10 bytes, dir_name to be 70 bytes, and full_name to be
80 bytes, then everything would fit without any truncation.
Note that this also relies on the tools to ignore the embedded null
characters in the full name when it is passed to a system task like
$readmem, which some might not do.
Another way to build filenames with Verilog-2001 would be to use
$swrite to print the filename, including numbers from loop counters,
into a reg variable.
Article: 100037oen_no_spam@yahoo.com.br wrote: > I have some doubts about the SPT3E Phase Shifter. > > First: > Data sheet V3.0, pg. 54, fig. 44: CLK180 is wrong. I must start as > high! (easy to see) To quote the immortal Homer Simpson, "Doh!" I'll see that this is fixed! > > Data sheet V3.0, pg. 57, eq. 6: MAX_STEPS = > +/-[integer(20*(TCLKIN-3ns))] > For example a 20MHz clock, TCLKIN=50ns > MAX_STEPS = +/-[integer(20*47n)] = +/-[integer(940*10E-9)] = +/- 0 > > Only seeing the "Answer Record: 22414" I understood. > How about changing it to: MAX_STEPS = > +/-[integer(20*10E9*(TCLKIN-3ns))] ? Is the confusion with the "ns" term in the equation? It was added only to emphasize that the equation is operating in time, not frequency. > Now my doubts. > What happens when we overflow the Phase Shifter? > For the same 20MHz clock, MAX_STEPS = +/-940. > And if I shift 941 times (same direction form zero) ? The output will be phase shifted by 940 steps. The DCM outputs no longer shift when incremented, but will decrement. > > >From the data sheet, PSCLK_FREQ (phase shift frequency input) ranges > from 1MHz to 167MHz. > For 1MHz: MAX_STEPS = +/-19940 > There must be at least 19940 internal delay taps (for each side)! > So I can go past 940 (the shifter doesn't know the frequency of the > clock, I think). The phase shift limit is frequency dependent. The equation uses the clock period, which is inversely proportional to the clock frquency. The phase shifting range depends on the CLKIN input, not the PSCLK. The minimum CLKIN frequency is 5 Mz, which equates to +/-3,940 steps. Each step, called DCM_DELAY_STEP, is between 20 to 40 ps. The VARIABLE phase shfit mode provide a phase shift range of between +/- (3,940 * 20 ps) to +/- (3,940 * 40 ps) or between +/- 78.8 ns to 157.6 ns. The confusing difference between the Virtex-II/Spartan-3 variable phase shifter and the Spartan-3E variable phase shifter is that Virtex-II/Spartan-3 shifts by fraction of a period, the Spartan-3E variable phase shift always shifts by time. The FIXED phase shift mode for Virtex-II, Spartan-3, and Spartan-3E are always measured in fraction of a clock period. > Again the 20MHz clock. > As MAX_STEPS = +/-940, the phase shift ranges from 940*20ps=18.8ns to > 940*40ps=37.6ns, both below 50ns (TCLKIN). > If 940 is the limit, how can the phase shifter, in the fixed mode, > cover all the range from 0 to 2*pi (or 360 degrees, if you prefer)? In FIXED phase shift mode, the Spartan-3E phase shifter works over the range -180 degress to +180 degrees. For software compatibility, this range is mapped to the Virtex-II/Spartan-3 range of -360 to +360 degrees. > I want to know if there is a way of changing the phase continuously, > crossing the borders of +/-2*N*pi smoothly (from 2*pi back to zero). I have a clarifying question on your question. Are you using VARIABLE phase shift mode to shift beyond -360 or +360 degrees and asking what happens when you exceed a full period? --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e Tel: (408) 626-7447 E-mail: steve.knapp@xilinx.com --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 100038
I actually synched both the data and the trigger. I can see how that would produce the same erros though. I guess I chalk it up to working b/c of P and R differences. I should probably go back and put a holding register in the 26 MHz module and just resynch the trigger into the 38.4 domain using a couple of flip flops. The shift register still shifts in data when it triggers the state machine (I can't lose a bit and the data stream is continuous - until the enable goes low). I guess it is VERY possible that the data is sometimes unstable when it crosses into the 38.4 domain. There is only one 26 MHz cycle available for this, and depending on the phase relationship of the two clocks, I could see timing issues arrising. Putting a holding register in plus the trigger synch flops in the 38.4 module should allow plenty of time for the data to be stable. Thanks all for the replys!! .Article: 100039
> Eventually the penny dropped - the significant parameter was not the > probe's capacitance, but its _weight_. Somehow, of about 6000 joints on > that board, this one had missed out on its dose of solder paste. > A tiny spot of solder, and all was well. I've had that happen, too! I laughed out loud reading your post. It is good to know that others in the world have gone through the same pain :) ! Take care, Rob "Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:8prs22p57q2c8g5c1bcpfea9obbt7annhe@4ax.com... > On Sat, 01 Apr 2006 03:51:26 GMT, "Rob" <robnstef@frontiernet.net> > wrote: > >>> Interestingly, the fpga glitch stopped when the TDS probe was touched >>> on the clock pin of the 2nd FPGA, which added about 0.5 pF. >> >>I hate when that happens :) > > Yup. > > I spent most of the night once on such a problem, on a SOIC on my first > big SMT board. Probing anywhere else on the net - even a via half an > inch away - didn't fix the problem, nor did series termination, parallel > termination, or capacitive loading on the via. > > Eventually the penny dropped - the significant parameter was not the > probe's capacitance, but its _weight_. Somehow, of about 6000 joints on > that board, this one had missed out on its dose of solder paste. > A tiny spot of solder, and all was well. > > - BrianArticle: 100040
Joerg wrote: > > Hello John, > > > We're leaning towards slowing down the edge at the xo, maybe with an > > R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at > > each fpga, giving most of a volt of noise immunity. There's no room > > for star traces, or at least not without a lot of ripups. If we put > > the tinies on the bottom, under the fpga's, they fit nicely and we > > don't have to waste a bunch of hundreds of bucks on a new solder-paste > > stencil and reprogramming the pick-and-place. > > > > That increases phase noise. It may not matter in the digital world but I > wouldn't do that for ADC clocks. > > One technique I use if a home-run star system isn't practical is a > nicely impedance controlled clock line (or a few) and then tapping off > with low-C RF transistors wherever the clock is needed. It raises the > hackles of the digital folks during design reviews but after a thorough > explanation they like it. > > That's how TV distribution used to be done in Europe, one line down from > the roof and tapped off with -20dB couplers. At the very end there is a > terminator. I use AC termination, mostly. > > Regards, Joerg > > http://www.analogconsultants.com CATV systems still use backmatched taps, but the tap value drops the further you get from the amp. the systems I worked with were designed for a +10 dBm signal at the port on the tap to allow for four TVs per drop, and up to 4 dB loss in the drop and house wiring. It was an average sized system with 10,000 active drops, and 4,000 homes passed that didn't have service. -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 100041
KJ, > The one thing that bit me though was that the SERDES transmit/receivers is > that the Stratix II family had no knowledge of bit alignment.relative to > the SERDES clock. Of course the FPGA doesn't have any knowledge of the bit stream; which is why you have to tell it where the data is in relation to the rising edge of the clock. In the case of a receiver, the MegaWizard function gives you the option of choosing 0, 45, 90, 135, 180, 225, 270, & 315 degrees. This is possible because the Wizard funcion uses a PLL to strip the data from the serialized stream. Most discrete SERDES type chips, like National's 90CR types, align the data with the rising edge of the PLL clock. In this case you would setup the FPGA's receiver to have 0 degree phase between the data and the clock, which will tell Quartus to latch the data on the falling edge of the receiver's PLL clock. I've used this functionality about 1/2 dozen times over the last year and have NEVER had a problem. I've interefaced with National parts and other FPGA (which simulated National parts). >Also, each SERDES channel needs to be individually aligned (i.e. bit 7 may >show up at one spot relative to the clock on channel 1 but there is no >guarantee that bit 7 on channel 2 will be there as well). If this is the case then the data coming into the FPGA probably has too much skew between the lanes. This is not the FPGA's problem. The receiver assumes that all the lanes are aligned. If they're not then one has to play games with the timing on each lane--not fun (I've been there). Also remember that all systems like this get affected by clock jitter, cable skew, and flop setup/hold times: all of which contribute to the RSKM (receiver skew margin). Take care, Rob "KJ" <kkjennings@sbcglobal.net> wrote in message news:xvCXf.50568$2O6.3316@newssvr12.news.prodigy.com... >> Altera provides these SERDES transmit and receive functions within their >> Mega Wizard tool box. These packaged functions take care of all of the >> timing needed to either receive or transmit the high speed serial data. >> > The one thing that bit me though was that the SERDES transmit/receivers is > that the Stratix II family had no knowledge of bit alignment.relative to > the SERDES clock. My previous SERDES experience used discrete parts where > the timing of each bit relative to the rising edge of the clock was > defined. The Stratix II documentation I worked with sure implied that this > was true also (bit as I realized later when the bite chomped down it did > not directly say so. Having worked with the discrete chips seeing the > same drawings in the Stratix documentation led me astray). > > With Stratix II (and maybe this is common with all SERDES other than > discrete chips) the receive side needs to manually align the bits relative > to the clock. The MegaWizard brings has an optional input that you > absolutely must use since you most likely will not power up with bits > aligned where you want them. Also, each SERDES channel needs to be > individually aligned (i.e. bit 7 may show up at one spot relative to the > clock on channel 1 but there is no guarantee that bit 7 on channel 2 will > be there as well). > > The problem then becomes how do you get the transmitter and receiver to > 'know' when they should be trying to align bits relative to the clock and > when are you all aligned and ready to go? That solution comes on a case > by case basis depending on what your system is. > > In hindsight this was all ignorance on my part in part caused by prior > SERDES knowledge with the discrete chips...but thought I'd pass the 2 > cents along. > > KJ > > "Rob" <robnstef@frontiernet.net> wrote in message > news:V9lXf.4539$kg.2858@news02.roc.ny... >> Stratix has fast fabric on two sides of the chip for handling the SERDES >> interface. The internal logic fabric can NOT handle these high >> serialized data rates. One must de-serialize the data, do whatever logic >> is necessary, and send it through a SERDES transmitter on the other side >> of the FPGA. >> >> Altera provides these SERDES transmit and receive functions within their >> Mega Wizard tool box. These packaged functions take care of all of the >> timing needed to either receive or transmit the high speed serial data. >> >> It sounds like you have 2 SERDES channels coming in and one going out; >> and you need to select which input gets routed to the output--the FPGA is >> the right solution for his situation. If the input and output SERDES >> channels have the same make up (lanes and bits / lane) and there is >> nothing you have to do with the data, then the design is fairly staright >> forward. Deserialize both of the input SERDES channels (using the >> MegaWizard function) into a mux; and then connect the output of the mux >> to the input of the SERDES transmitter (MegaWizard function). >> >> Take care, >> Rob >> >> >> "pinku" <praveenkumar.bm@gmail.com> wrote in message >> news:1143824706.197533.207620@u72g2000cwu.googlegroups.com... >>> Hello Groups, >>> >>> I have a 1Gbps SERDES output from the Network processor. But as i have >>> 2 SERDES signal coming from the back plane, depending of SEL line i >>> have to connect one of the SERDES to network processor. So i am using >>> FPGA to interface this, which takes a SERDES input and I have FIFO for >>> transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again >>> connected to another SERDES which in turn connect to the Backplane. So >>> i need 4 SERDES for implementing it. Will this intermediate Logic >>> create for end to end SERDES data transfer ? Is there any other way of >>> implementing this logic? I am planning to use Stratix GX FPGA. >>> >>> Please let me know your suggestion, >>> waiting for your reply, >>> Kumar >>> >> >> > >Article: 100042
John Larkin wrote: > > Hey, the CPU has a clock-out pin, same freq as the clock-in in this > case. We could use *that* to drive the two following FPGAs in the > string. It's a 68332, ancient process cmos, swings hard and makes nice > sedate edges! May as well leave the deglitcher in there, so we don't > have to re-release the designs. The MC68340 is the same family as the MC68332. I saw a lot of MC68340 on the embedded controllers we built for the Microdyne 700 & 1620 series of telemetry equipment, as well as a satellite tracking controller that used a modified version of the same custom controller. They made a layout error for the 32,768 Hz oscillator that no one had noticed. It caused starting problems, and there was no way to fix it without changing the board layout. -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 100043
Let us know if the holding register scheme helps! John ProvidenzaArticle: 100044
Davy wrote:
> I am new to hierarchical FSM design.
> Is there any paper or guideline for design hierarchical FSM?
> Any suggestions will be appreciated!
I would suggest that if your state machine
needs a hierarchy, there is likely a simpler
logic description possible, using multiple
process variables, not all of them enumerated.
-- Mike Treseler
Article: 100045
RobJ wrote:
> I found out that HDL Designer is really what I'm looking for,
I suggest a full evaluation with a real design
to validate that idea.
> Have you used HDL Designer? Any comments on it?
I did an evaluation, but settled on emacs vhdl-mode
which is non-graphical, but covers much of the
same ground for free.
With HDL designer I did not enjoy fussing
with wires and attaching text to graphical
views to get the code to come out right.
In vhdl-mode, I especially like the templates,
the port copy/paste functions, and the Makefile
generation for simulation.
-- Mike Treseler
Article: 100046"David Colson" <dscolson@rcn.com> writes: > This is the ieee1532 bsdl file that describes the programming > algorithm. for the xc18v00. Using this file and an understanding of > the JTAG interface, you maybe able to decipher how to program your > device. The BSDL file does not describe the programming algorithm. It just describes the boundry scan registers (some which are used for programming). I would not call this decipher, but using the SVF file and the JTAG state machine you can extract how to program the device. The SVF file describes how to select the programming registers and the contents of these registers, the JTAG state machine describes how to shift data into boundry-scan registers. e.g. if you toggle TMS and TDI according to this model: http://www.gustad.com/petter/18v01.v you should end up with what is described by the SVF given by the O.P. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 100047
> I should probably go back and put a holding register in the 26 MHz > module and just resynch the trigger into the 38.4 domain using a couple > of flip flops. I had assumed you were transferring the data to an output_register(95..0) in the 26 MHz domain at the same time as you generate the 'data ready' signal. > The shift register still shifts in data when it > triggers the state machine (I can't lose a bit and the data stream is > continuous - until the enable goes low). I guess it is VERY possible > that the data is sometimes unstable when it crosses into the 38.4 > domain. There is only one 26 MHz cycle available for this, and > depending on the phase relationship of the two clocks, I could see > timing issues arrising. Putting a holding register in plus the trigger > synch flops in the 38.4 module should allow plenty of time for the data > to be stable. Exaclty, you can re-time the enable signal into the 38MHz domain a number of clock cycles so the data should be settled at the 38MHz register inputs. Nial. > > Thanks all for the replys!! . >Article: 100048
Hi smu, usually this behavior is caused by incorrect data loaded into the device. The BUSY Signal will be driven high some CCLK cycles after the incorrect data has been loaded into the device. Have you checked the data alignment (D0=MSB), correct assertion/deassertion of CS#, and the setup/hold times on the select map interface? Regards Jens smu schrieb: > Hi, > > I have developed board with a Spartan 2E. The Spartan is configured by > an antifuse fpga with the SelectMAP mode. The configuration of M[2:0] is > ok. The configuration stream is transferred at 2.5MBytes/s. > It said in the datasheet that the busy flag is provide for frequency > above 50MHz. But in my design, I see a high level on the busy flag. > > Somebody saw this kind of phenomena on Spartan 2E device? > What was the origin of this phenomenon? > > Thank you in advance > > smuArticle: 100049
On Sat, 01 Apr 2006 15:58:04 GMT, "RobJ" <rsefton@abc.net> wrote: >"Brian Drummond" <brian_drummond@btconnect.com> wrote in message >news:fnss22hl486nr858dj1b4bkj3d7bg550qc@4ax.com... >> On Fri, 31 Mar 2006 16:05:11 GMT, "RobJ" <rsefton@abc.net> wrote: >> >>>Anyone using this tool from Mentor? If so, any comments about it would be >>>much appreciated. And any comments on how ModelSim + ModelSim Designer >>>compares to Aldec's Active-HDL environment would be even better. I >>>currently >>>own ModelSim but am looking for a more complete environment (testbench >>>automation, graphical tools, code coverage, etc.). >>> >>>Thanks, >>>Rob >> >> It's OK, but it won't work with designs from older versions of HDL >> Designer or Renoir. This wasn't made clear when I bought it, so I am >> using it as a Modelsim seat alongside my (legacy) HDL Designer. >> >> - Brian > >Hi Brian - > >Ends up I misunderstood what ModelSim Designer is. I thought it was a >product that runs with ModelSim, but adds new features (automated testbench >generation, HDL to graphics, etc.). I talked at length with a Mentor sales >person yesterday and Designer is a stand-alone simulator and development >environment meant to attract the "low-end" FPGA crowd (like me) away from >Active-HDL. They just lowered the price from $5500 to $2500, so it caught my >interest. But I already own ModelSim so I'm not looking to replace it. I >found out that HDL Designer is really what I'm looking for, but HDL Designer >is a $17.5K tool. > >Have you used HDL Designer? Any comments on it? Can't comment on the new versions, I'm still using the transition version from Renoir (which dates from 2001). I agree with Mike that some of it is clunky, like adding text to graphical blocks for the this you can't deal with in wiring. Strong plus points : (1) Viewing/drawing block diagrams and state machines gives me a very clear view of the design, which helps me handle the complexity. (2) Code generation from these blocks means I have very little contact with the alleged verbosity of VHDL. (And when I do, it's helping me by providing clarity, instead of making me type long words) Neutral points: (1) Creating and using components works well and greatly encourages re-use. I make this neutral because when I started (1998), I created components at a low level of abstraction - even down to a parameterisable pipeline register. And re-used them in higher level blocks, etc - to give quite a deep hierarchy. Not necessarily a bad thing, but somewhat opposed to e.g. Mike Treseler's "one process" style. These are two approaches to the same goal - minimising complexity, so to some extent, using one renders the other less important. On the other hand, this hierarchy can be allowed to persist through the tools, and greatly aids floorplanning, and creating RPMs. So to me it's positive overall, but I recognise that's open to debate. Negative points. (May have been addressed in new versions) (1) Allows creation of either "blocks" (compile to entity/arch pairs) for direct instantiation, or "components" for component instantiation, which is deprecated in some styles. Aside: I don't know why component instantiation is deprecated ... is it just verbose? If so, that's less important here... (see plus point 2 above) The trouble is (a) Navigating "up" from a block moves to the parent (instantiating) block; "up" from a component, just to the component's symbol itself. Annoying, especially if you just moved "down" into the component from a parent. I can see why ... a component may have many parents. But this is really just an excuse for the developers not to maintain a navigation trail, so it's really not an acceptable excuse. (b) Blocks cannot be copied or moved to different libraries or re-used in other than the original instantiating block. Unless you convert them to components. (And then, if you move the component into a different library, you also need to convert every block instantiated within it!) Thus in the longer term, blocks tend to be self-deprecating. (2) There are some vaguely useful concepts like "bundles" of signals that are implemented in a half-assed way, and tend to atrophy with newer versions. These should map neatly onto VHDL records, but don't. They should also allow mixe signal directions and port types, like Data, Address, Req, Ack (InOut, Out, Out, In), but don't. And so on... My gripes aren't actually fundamental to the concept, but specific to the implementation. And haven't changed much in years. But overall I'm with Hans that I'd definitely not want to work without it. I don't know how much use this is to you, given the version differences. But I'd question the value of the full product, and ask if Modelsim Designer doesn't give you most of what you need (basic non-graphical VHDL import, block diagrams, and state machines) as well as another Modelsim seat (full function PE as far as I can tell). As I said, I've ended up simply using it as ModelSim, but I believe I'd have been satisfied with it - IF - I didn't have a legacy database. - Brian
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