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
jenze a écrit : > 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 > Hallo Jens, Where did you find this information? This information could explain why it works in a previous version of my antifuse design. Probably some routing delay that made setup and hold time not conforms. I will check that. Regards, smu > 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 >> >>smu > >Article: 100051
in the doc of liberary guid of vitex4 where we can find the model hdl and symbole of ICAP so I'm sur icap is in the virtex4 but hwicap!!!!!!! no idea! maybe there will have another version ip will be used !!! Paul Hartke a =E9crit : > Hi Alan, > > This would only work if the ICAP in Virtex4 operated the same way as in > Virtex2/Virtex2p. Maybe they are not the same and this is why the > ARCH_SUPPORT doesn't include Virtex4. > > Paul > > Alan Nishioka wrote: > > > > zhangxun0501@gmail.com wrote: > > > but in the sit of xilinx , it said the hwicap support the virtex4-fx > > > > Have you tried adding virtex4 to the list of supported architectures > > in: > > EDK/hw/XilinxProcessorIPLib/pcores/opb_hwicap_v1_00_b/data/opb_hwicap_v= 2_1_0.mpd > > > > That is, change > > OPTION ARCH_SUPPORT =3D virtex2:virtex2p > > to > > OPTION ARCH_SUPPORT =3D virtex2:virtex2p:virtex4 > > > > I don't have 8.1 and am not using hwicap, so I have not tried this and > > don't know if it will work. > >=20 > > Alan NishiokaArticle: 100052
I think that is the reason maybe the new version will different than the oldArticle: 100053
On Sat, 01 Apr 2006 21:07:24 GMT, Joerg <notthisjoergsch@removethispacbell.net> 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. Emitter followers? JohnArticle: 100054
<zhangxun0501@gmail.com> schrieb im Newsbeitrag news:1144003952.207614.206090@z34g2000cwc.googlegroups.com... >I think that is the reason maybe the new version will different than > the old > yes, ICAP is OK in V4, its just the EDK that has the ip cores not updated with V4 support :( AnttiArticle: 100055
On Sun, 02 Apr 2006 02:32:13 GMT, "Michael A. Terrell" <mike.terrell@earthlink.net> wrote: >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. The 32 KHz oscillator/PLL thing is really a pain on the Moto parts. It's a lot easier and much more reliable to just buy a packaged XX MHz oscillator and use it directly. JohnArticle: 100056
On Sat, 01 Apr 2006 19:25:56 GMT, "RobJ" <rsefton@abc.net> wrote: >"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. I've highlighted a number of howlers in Black Magic. Half his stuff is right and half is silly. If you know enough to tell the difference, you don't need the book. His opinions on "return currents" are hilarious. > >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. Exactly. Everybody has his religiously-observed way to do bypassing. The fact is that most any bypassing scheme works fine in most situations on multilayer/powerplane boards. I know a guy who uses no bypass caps at all, and that works too. I like four 0.33 uF caps per FPGA per supply, and that's just cowardly overkill. I saw a board being stuffed once (on a Panasonic turret p-n-p, in a tin-roof assembly shack in Hamamatsu) that had over 3000 bypass caps, part of an Anritsu memory tester, as I recall. > >Signal integrity is a different story. There are tons of ways to get in >trouble there, as I've proven to myself many times. :) Amen. And it's not getting any easier. The FPGA designers should take pity on us and give us the option to slow down i/o cells and clock buffers. Not every FPGA works flat-out. JohnArticle: 100057
John Larkin wrote: > > On Sun, 02 Apr 2006 02:32:13 GMT, "Michael A. Terrell" > <mike.terrell@earthlink.net> wrote: > > >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. > > The 32 KHz oscillator/PLL thing is really a pain on the Moto parts. > It's a lot easier and much more reliable to just buy a packaged XX MHz > oscillator and use it directly. > > John I agree, but the design team insisted that they needed the ability to reprogram the CPU's clock rate, "Just in case." Then to add insult to injury, they mounted the watch type tuning fork crystal vertically, and soldered the bottom edge of the crystal's case to a large pad rather than lay it down and use a drop of RTV to shock mount it. I saw a lot of dead boards with dead crystals. There were so many that I kept 10 spare crystals on my bench. They mounted the less sensitive baud rate crystal the right way, and soldered the top of the can to a pad. All of this was done a year before I was hired so I was stuck with getting the things out of production, and into customer's hands. -- 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: 100058
Brian Drummond wrote: > (1) Viewing/drawing block diagrams and state machines gives me a very > clear view of the design, which helps me handle the complexity. Note that ISE and Quartus now have added serviceable block viewers. While you can't click on anything in this pdf printout, http://home.comcast.net/~mike_treseler/uart.pdf when seen live from Quartus, clicking on a yellow box will bring up a graphical state diagram, even though all I actually wrote was a case statement in text. > (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) HDL designer does hierarchy with a block diagram editor. To fill these boxes, it provides logic entry from state diagrams or flowcharts. This style appeals to schematically oriented designers who would rather drag boxes, wires, circles and arrows around than write code. This is a valid alternative for those who don't like writing HDL code, and Mentor has made lots of money with this product. Code generation from graphics *appalls* designers who know an HDL and see a tidy code listing as the only viable and portable source format. A single block HDL style allows the bottom up use of variable (register) structures, functions and procedures to construct a design of arbitrary complexity from a standard template. While verbosity is possible, so is a clean, modular, single-threaded logic description with registers, wires and muxes inferred as needed by synthesis. > (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. Yes, synthesis has improved in the last eight years, and it is no longer necessary to use write deeply nested structural designs down to the gate, mux and register level. For designers who know an HDL for synthesis and simulation, tools like HDL designer are largely irrelevant. I use the emacs vhdl-mode compose commands to wire up my single-process instances into a top entity. If I need to view the design graphically, I use the Quartus pre-map RTL viewer. -- Mike TreselerArticle: 100059
Hello John, >>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. > > Emitter followers? > Yes, generally. But you need a negative supply and ideally a +8V or higher as well (really, really good bypasses or it'll oscillate). This is usually the case for the systems I work on but the analog folks are often suspicious about me tapping into "their" supplies for lowly digital purposes. Once I tell them that I am an analog guy myself that relieves them from their worries. Now, about that big honking stepper motor... Regards, Joerg http://www.analogconsultants.comArticle: 100060
Mike, Brian - Thanks for sharing your experiences with the tools. I now have 30-day demo licenses for both ModelSim Designer and HDL Designer, so I'll try to make time to see if there's anything here I can't live without. I use Verilog almost exclusively, and I don't use the methodology of building a library of low-level logic primitives and then building up my designs from that. As Mike said, the synthesis tools are smart enough now to not require that, and with that approach you may as well be drawing schematics, which I was happy to leave behind probably 12 years ago. I have two main motivations for looking at these tools. First, I'd like to increase my productivity. I've been doing things basically the same way for years and it's time to see what's out there that can make the job faster, easier, and even better than what I'm doing now. Second, my main customer (I'm a consultant) is an avionics company (non-defense), and the FAA requires extensive documentation to certify a product. They've been very strict with software for years, but recently they've adopted the same standards for programmable logic. I want to come up with an FPGA design methodology for my customer that will make the FAA happy without requiring a ton of extra work. By the way, Brian, the Mentor sales guy said ModelSim Designer does not work the same as ModelSim. He used some corny analogy to describe it, but the bottom line is that they're different tools that are not interchangeable or even necessarily compatible. Still, for $2500 I'd consider buying it if it has the documentation and task automation features I'm looking for. I just wouldn't use it as my simulation engine. I'll post back with comments from my evals if I have anything worth reporting. RobArticle: 100061
Rob, > 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. What you're talking about here has to do with what Altera calls 'DPA' . What the data book has to say about DPA is the following (page 51 of 68) http://www.altera.com/literature/hb/stx2/stx2_sii5v2_03.pdf: The DPA block aligns the incoming data to one of eight clock phases to maximize the receiver's skew margin. The DPA circuit can be bypassed on a channel-by-channel basis if it is not needed. Set the DPA bypass statically in the Quartus II MegaWizard Plug-In or dynamically by using the optional RX_DPLL_ENABLE port. DPA has to do with skewing the SERDES clock a bit (with one of 8 settings) relative to a particular bit position in order to improve receiver skew margin in order to correct for known skew that may exist in your system but can be accounted for ahead of time (i.e. at design time when you're picking one of those 8 settings). This is not the same thing that I was talking about though. What I was talking about was along the lines of what is on the next page in the section titled "Receiver Data Realignment Circuit" where they say... The data realignment circuit aligns the word boundary of the incoming data by inserting bit latencies into the serial stream. An optional RX_CHANNEL_DATA_ALIGN port controls the bit insertion of each receiver independently controlled from the internal logic. The data slips one bit for every pulse on the RX_CHANNEL_DATA_ALIGN port. If you scroll a bit further to page 58 under the section titled "Differential I/O Bit Position" is a nice description showing the bit order of differential data that basically shows that the nominal rising edge of the SERDES clock occurs roughly at the transition between when data bits 2 and 1 are being transmitted. What they don't say is that you have to use the above mentioned "Receiver Data Realignment" feature first in order to get the bits in the proper position. I ran across this one first in simulation since the receiver was not performing per the 'Figure 5-14' diagram where I suspected that it was just Altera's simulation model that was in error. After opening a service request and subsequent escalations since the problems wasn't resolved and actually talking to someone at Altera who is very familiar with the SERDES circuitry the end result was that the simulation model is correct the diagrams they agreed are somewhat misleading and that the 'Receiver Data Realignment' feature really does need to be used in order to guarantee that your design is working correctly at every power up. Typically everything seems to power up in the same fashion but I've also seen the actual hardware have to get 're-aligned' after having already been aligned. > Most discrete SERDES type chips, like National's 90CR types, align the > data with the rising edge of the PLL clock. In this case And this was my mistake when I thought this to be true with Stratix SERDES also...thanks to Figure 5-14 KJArticle: 100062
Chris, > without losing any words during the switching), but would it be possible > to > just multiplex the serial data? > The problem is that no you can't just multiplex the serial data at 1Gbs even though fundamentally that is all you're trying to do. FPGAs circa 2006 do not do any logic from external sources at that speed. All you can do is deserialize then multiplex and re-serialize. KJArticle: 100063
There is one engineer on our team who is a real PITA. He is always kibitzing other people's designs for trivial things that no one else thinks is worth mentioning. These resistor issues is one of those things. Just so I don't have to change the parts on my schematic, can I get you to explicitly say it is ok to use pullups to 2.5 volts of up to 10k ohms on the various signals lines powered by VCCAUX? I can't believe he is trying to say the direct connection shown in the 3.3 volt configuration guide is an indication that we should not be using pull up resistors. But the process we use for design requires me to consider his input and justify my decision. His only reason for making that assertion is the digram in the app note which shows direct connections. Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > 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: 100064
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:1144017247.324185.173090@i40g2000cwc.googlegroups.com... > There is one engineer on our team who is a real PITA. He is always > kibitzing other people's designs for trivial things that no one else > thinks is worth mentioning. These resistor issues is one of those > things. Just so I don't have to change the parts on my schematic, can > I get you to explicitly say it is ok to use pullups to 2.5 volts of up > to 10k ohms on the various signals lines powered by VCCAUX? > > I can't believe he is trying to say the direct connection shown in the > 3.3 volt configuration guide is an indication that we should not be > using pull up resistors. But the process we use for design requires me > to consider his input and justify my decision. His only reason for > making that assertion is the digram in the app note which shows direct > connections. > > I think I know that guy!! Everything you need to know to justify your design is in the data sheet. If people knew who writes most app notes in our business they wouldn't treat them with such veneration. Slap that PITA for me!! RobArticle: 100065
There are two good and two marginal reasons to use external pull-up resistors instead of a short circuit to Vcc.: If the pin is dual-use and might also be input or output (that's obvious) If you want to change the level for testing purposes, by shortening it to ground. If you are an old TTL guy who remembers that LS-TTL inputs could be damaged by a very high Vcc. (historical-hysterical reason). If you think a resistor is dirt-cheap and buys you some flexibility or peace of mind. Peter Alfke, Xilinx, from home.Article: 100066
Peter Alfke wrote: > There are two good and two marginal reasons to use external pull-up > resistors instead of a short circuit to Vcc.: > > If the pin is dual-use and might also be input or output (that's > obvious) > > If you want to change the level for testing purposes, by shortening it > to ground. > > If you are an old TTL guy who remembers that LS-TTL inputs could be > damaged by a very high Vcc. (historical-hysterical reason). > > If you think a resistor is dirt-cheap and buys you some flexibility or > peace of mind. .. and another testing use, is to use the pin to bring out an internal signal, for probing. - ie I'd add a resistor _and_ a probe pad. [ you also then side-step his input, as now your use is clearly not in that appnote :) ]Article: 100067
Mike Treseler wrote: > 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 It depends on the nature of the state machine (SM). Sometimes it is helpful to take advantage of the inherent parallelism available in a FPGAs and ASICs by having multiple state machines operating at once while a "master" SM coordinates their activities. However, this typically implies only two levels of hierarchy (the master machine, and the servant machines) That said, there are few circumstances that call for true hierarchy in state machine design, and I would recommend also that you reexamine the problem. Often, a problem can be more easily solved with an external (to the SM) counter, pipeline register, or signal than by adding additional states. As a hint, try to limit the number of outputs each SM generates. This will force you to partition the problem better, and should result in a cleaner design. For example, rather than implement a full microprocessor for a test application, I wrote two state machines that were attached to an internal UART model. One state machine handled incoming data, while the other acted as a message generator. By partitioning in this way, each machine became much simpler, and performance improved greatly. Note, there are some graphical tools on the market (Mentor Graphics' HDL Designer, and Xilinx' StateCAD) that allow you to implement hierarchical state machines graphically - allowing them to be understood more easily. However, if you examine the output, you will find that the SM has almost invariably been flattened to just one (in either two or three processes depending on what you specified in the options)Article: 100068
I guess if you cannot answer or help than its much better not to say anything. I think you need some help in this area :)Article: 100069
Hello All, Any of you have ever used Xilinx Kernel in any project. I am wondering how easy its is to use. I am planning to embed some applciation on PowerPC 405 of Virtex4 FX. My only use to have kernel is to have some basic scheduler so i can schedule the processes. Any known issues with it? Round Robin scheduler is my priority :-)Article: 100070
I suppose Duane is wondering how such a naive ( impossible to answer) and poorly worded question comes from somebody working in such a sophisticated company..."interesting" We all want to be helpful, but I will also point out that posters should do a little bit of thinking and googling before they embarrass themselves. We learned recently that we must be tolerant of "creative spelling"... Peter AlfkeArticle: 100071
Mike Treseler wrote: > Code generation from graphics *appalls* designers > who know an HDL and see a tidy code listing > as the only viable and portable source format. Actually HDL designer creates quite clean code from the FSM editor and block diagrams. It can easily be read also manually. The problem is lack of comments in the code if it is automatically generated tough. > A single block HDL style allows the bottom up > use of variable (register) structures, functions and procedures > to construct a design of arbitrary complexity > from a standard template. While verbosity is Just be wary with functions and procedures. Especially procedures seem to be a big problem still for design tools. I think I have seen all the major implementation tools to create garbage or crash with very simple procedures (DC, Synplify, FormalPro, Formality, few linters etc.) > For designers who know an HDL for synthesis and simulation, > tools like HDL designer are largely irrelevant. Actually what I have seen very experienced VHDL coders (10+ years) also like HDL designer. They usually use only the block diagrams and text views. Block diagrams are good way of documenting the functionality. Especially when the design team is big, different coders have to read and sometimes fix other peoples code. Just browsing the code is slower than to start with block diagrams that have the dataflow clearly shown etc. --KimArticle: 100072
Hi people, I ran into a similar problem with a similar design, with an embedded 8-bit cpu and some cross domain signals. The design works with chipscope, while it does not without it. Now, adding a KEEP_HIERARCHY constrain actually makes it work again, and that without chipscope. I am pretty sure that KEEP_HIERARCHY will keep module ports that the PAR tools think is better to trim. So that it would be crucial to add the property. Just to be on the safe side, I re-ran the flow a couple of more times, with and without the attribute and it indeed makes the difference. Pretty much sure MAP is trimming off where it is not suppose to. My two rupee :) JAArticle: 100073
Hi smu, i have had similar problems some years ago on the Virtex-E. Virtex-E ist (nearly) the same as Spartan-2E. The BUSY Signal will be driven high if: 1) an abort has been requested. 2) the internal buffer is full. This will be the case if: 2a) CCLK is above 50 MHz 2b) the internal configuration packet processor is confused about the configuration data and stops interpretation. 3) the internal buffer is empty, and you try to readback configuration data. This is the case if: 3a) CCLK is above MHz 3b) switching from write to read, so the buffer need to be filled initially. Regards Jens smu schrieb: > Hallo Jens, > > Where did you find this information? > > This information could explain why it works in a previous version of my > antifuse design. Probably some routing delay that made setup and hold > time not conforms. I will check that. > > Regards, > > smu >Article: 100074
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes: > I wonder if anyone has ever kluged a bga layout, sort of like one of > those jellyfish with a thousand tentacles. > We once soldered tiny wires to the vias on the *top* of a BGA package to get at some signals we'd thought we wouldn't need to get to on the prototype... that was fun :-) -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conekt
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