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
Sean and Kelvin, I had the same problem (Fatal Errors due to logic0/logic1 on signals). The logic0/logic1 doesn't seem the problem itself but it leads in the right direction. In my case, the error was mostly caused by unconstraint top level logic.If the logic was moved into a module, the final par was successful. However, I still have trouble setting constant '0' and '1' on the bus macro inputs, which also causes your problem even if no real logic is involved. What puzzles me is that it works for the tutorial (xapp290). Please correct me if I am wrong. MarkusArticle: 67101
Hello,
Maybe it is a newbie question but i try to learn and because i'm not very
fluent in english i want to know what this sentence mean.
"parts need to be reballed"
Thanks for the help
Article: 67102Hello, A colleague of mine is simulating a post-routed with back-annotated FPGA design for an Actel chip on Modelsim. He is getting a number (1000's) of glitch warnings related to what seems to be combinatorial logic that is part of a counter and or muxes which is registered on the outputs anyway. None of the glitches are visible on the input or outputs but is on the internal nets. Can we safely ignore these warnings or better yet turn them off with -no_glitch option? Thanks in advance. SalmanArticle: 67103
According to the Virtex-II datasheet, if your SRL16 is configured as a simple 16-bit shift register, you have direct access to the "shift-out" bit of the register, so it would seem you don't need to worry about the LUT inputs. I believe this essentially bypasses the LUT address mux, although I could be wrong. Ray Andraka wrote: > The configuration holds the LUTs contents which defines the combinatorial > function of the LUT, but that does not describe the LUT's output value. You > cross couple two luts, but I don't see how you force a particular initial value > from initialization. This is much different than an SRL16, where the > configuration bits are the SRL16 state, or even a flip-flop where the state is > part of the initialization. What am I missing here? > > Peter Alfke wrote: > > >>The LUT content is defined in the bitstream. That defines the original state >>of the latch. Same for SRL16. >>Peter Alfke >> >> > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > > -- Pierre-Olivier -- to email me directly, remove all _N0SP4M_ from my address --Article: 67104
"Reballing" is required to re-use parts in BGA packages that were once soldered onto a board. "Reballing" is a way to reclaim these BGA parts. -- SKK <ouadid@iquebec.com> wrote in message news:xn12c.18959$qA2.1251023@news20.bellglobal.com... > Hello, > Maybe it is a newbie question but i try to learn and because i'm not very > fluent in english i want to know what this sentence mean. > "parts need to be reballed" > Thanks for the helpArticle: 67105
Hi Peter, CLKIN doesn't need to be free running when the DCM is locked, unless you're using CLKFX or CLKFX180. Here's a quote from the user guide. <quote> Input Clock Changes Changing the period of the input clock beyond the maximum input period jitter specification requires a manual reset of the DCM. Failure to reset the DCM produces an unreliable lock signal and output clock. While the DCM is in the locking process, no input clock edge can be missing. Once locked, it is possible to temporarily stop the input clock with little impact to the de-skew circuit, as long as CLKFX or CLKFX180 is not used. </quote> Complicated things, those DCMs! Cheers, Syms. Peter Alfke <peter@xilinx.com> wrote in message news:<4044CEE5.15179D88@xilinx.com>... > Basic functionality: > In its simplest use, the DCM eliminates the clock delay between the > incoming clock signal and the low-skew global clock distribution. With > the appropriate feedback to its CLKFB input the DCM inserts the right > amount of delay so that CLKIN and CLKO signals occur simultaneously > (within a very small fraction of a nanosecond). Physically, CLKO is > delayed by exactly one clock period, and this obviously requires a > free-running, constant-frequency CLKIN. > I hope this long posting is helpful. > Peter Alfke, Xilinx ApplicationsArticle: 67106
I'm not sure what that has to do with my statement, but you are correct, for VirtexII
the SRL16 has a cascade out that is permanently connected to the last 'register' in
the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and
looking at the normal output. The cascade output was a new feature for virtexII.
What Peter was saying is that you can create a latch out of cross-coupled LUTs that
will not be affected by global reset (which is true), however he also seemed to
indicate that you could have that latch come up in a known state on reconfiguration.
My statement simply says that for a LUT, the configuration sets the combinatorial
function of the LUT, but does not determine its output value (the output is
determined by the values of the inputs and the ccombinatorial function assigned to
the LUT). Therefore, the latch created from cross coupled LUTs cannot be directly
assigned an initial value by configuration. To get it to a known state, one of the
set/reset inputs must be asserted, which requires something external to the latch and
explicitly designed in the user logic to accomplish. The SRL16 is different than a
LUT in that it has internal storage accessible to the user circuit. The SRL16 can be
viewed as a LUT whose program can be altered by shifting new bits into it. If held
with the WE='0', it behaves exactly as a LUT, with the output being the value of the
program bit selected by the inputs.
PO Laprise wrote:
> According to the Virtex-II datasheet, if your SRL16 is configured as
> a simple 16-bit shift register, you have direct access to the
> "shift-out" bit of the register, so it would seem you don't need to
> worry about the LUT inputs. I believe this essentially bypasses the LUT
> address mux, although I could be wrong.
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 67107"Balls", as in Ball-Grid-Array describe the many small half-spheres of solder on the bottom of modern BGA packages, from a few hundred to over a thousand of them. In board assembly, these balls are heated up and collapse onto the pc-board "pad" and form a perfect solder joint. When, for any reason, a package has been removed from the pc-board, the balls are left behind or damaged or deformed, so the device package must be refurbished with new balls, and that step in re-manufacturing is called "re-balling". Peter Alfke > From: ouadid@iquebec.com > Organization: Bell Sympatico > Newsgroups: comp.arch.fpga > Date: Fri, 5 Mar 2004 15:51:08 GMT > Subject: A newbie question > > Hello, > Maybe it is a newbie question but i try to learn and because i'm not very > fluent in english i want to know what this sentence mean. > "parts need to be reballed" > Thanks for the helpArticle: 67108
"Michael Chan" <m.chan1@uq.edu.au> wrote in message news:<c261a1$atj$1@bunyip.cc.uq.edu.au>... > Just wondering if anyone can point me to some articals or papers that analyse > the characteristics of xilinx DLLs vs altera PLLs. > > Thanks. Michael, Altera has published a document comparing PLLs to DLLs, specifically looking at jitter. http://www.altera.com/literature/tb/tb70.pdf We also publish specs for PLL jitter in the appropriate device datasheet, so you can take a look at those as well. Sincerely, Greg Steinke gregs@altera.com Altera CorporationArticle: 67109
Max <mtj2@btopenworld.com> wrote: > On Fri, 5 Mar 2004 23:01:01 +1300, Bevan Weiss wrote: > > >I was really just looking for something slightly removed from mainstream... > >Just like a bit of challenge I guess. > >I'll have a look at the common algorithms too, I think they be sufficient > >for the requirements also. > > An interesting project might be to implement Rijndael/AES in an FPGA. > It's pretty efficient for a block cypher algorithm, and about as > secure as you can get: > http://www.esat.kuleuven.ac.be/~rijmen/rijndael/ > There is a core on opencores.org that is probably suitable for a prng (its slightly lacking for my taste as a general crypto core) -- Sander +++ Out of cheese error +++Article: 67110
Sorry, my bad. I thought you were referring to his statement on the use of the SRL16. However, the OP implied that his global clear was post-power-up. Couldn't there be a way to initialize the latch at power-up, after which the value would be kept across global clears? I haven't thought out the details, but it doesn't seem too complicated (famous last words ;)... I was under the impression that there was a way of differentitating power-up reset and subsequent global clears... Ray Andraka wrote: > I'm not sure what that has to do with my statement, but you are correct, for VirtexII > the SRL16 has a cascade out that is permanently connected to the last 'register' in > the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and > looking at the normal output. The cascade output was a new feature for virtexII. > > What Peter was saying is that you can create a latch out of cross-coupled LUTs that > will not be affected by global reset (which is true), however he also seemed to > indicate that you could have that latch come up in a known state on reconfiguration. > My statement simply says that for a LUT, the configuration sets the combinatorial > function of the LUT, but does not determine its output value (the output is > determined by the values of the inputs and the ccombinatorial function assigned to > the LUT). Therefore, the latch created from cross coupled LUTs cannot be directly > assigned an initial value by configuration. To get it to a known state, one of the > set/reset inputs must be asserted, which requires something external to the latch and > explicitly designed in the user logic to accomplish. The SRL16 is different than a > LUT in that it has internal storage accessible to the user circuit. The SRL16 can be > viewed as a LUT whose program can be altered by shifting new bits into it. If held > with the WE='0', it behaves exactly as a LUT, with the output being the value of the > program bit selected by the inputs. > > PO Laprise wrote: > > >> According to the Virtex-II datasheet, if your SRL16 is configured as >>a simple 16-bit shift register, you have direct access to the >>"shift-out" bit of the register, so it would seem you don't need to >>worry about the LUT inputs. I believe this essentially bypasses the LUT >>address mux, although I could be wrong. > > > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > > -- Pierre-Olivier -- to email me directly, remove all _N0SP4M_ from my address --Article: 67111
erojr <janos.nojunk.nospam.ero@cern.nojunk.nospam.ch> wrote in message news:<c29ac5$ovb$1@sunnews.cern.ch>... > rickman wrote: > > > TRST puts the state machine in a defined state. Most devices also reset > > the state machine on power up. In addition, if you hold the TMS line > > high and clock TCK it will return the state machine to the starting > > state after 5 clock cycles, IIRC. Of course, depending on the > > implementation, the mechanism that operates the state machine can get > > fouled up by power glitches or other anomalies. Then the machine may > > get into a state that operating the TCK line may not control the state. > > Then you will need a power on or a TRST type reset. I don't know that > > this is common, but in theory it is possible. > > Thank you for the description. This is exactly that I also found. I do not > use the TRST pin but I have never seen a case when the JTAG State Machine > did not return to RESET state after 5 clocks. I use the JTAG chain for > regular check of the FPGA input pins, not only for programming. > > The original question was the open TRST pin, but due to the standard > internal pullup - I hope this is the case in Altera FPGAs too, but this > was not yet confirmed by anybody - the open input must not be the reason > for incorrect behavior. > > Janos Ero Hi Janos, Altera devices that have a TRST pin have a weak internal pull-up on them. The literature is not very clear on this, so we'll update this. However, not all Altera devices have TRST as it is optional. The EPC8 is one of those without TSRT. It's possible that a floating TRST on some other non-Altera device in the chain would cause such a problem, but I imagine that most JTAG devices would have a weak pull-up on TRST. Another thing to check would be the TCK on the devices in the chain. If one of the devices is getting double-clocked then this would foul up the data passing through the JTAG chain. The tricky part is that a double-clock on any device could cause a problem, not just on the EPC8. Sincerely, Greg Steinke gregs@altera.com Altera CorporationArticle: 67112
In article <7752c.112739$2g.74392@charlie.risq.qc.ca>, PO Laprise <pl_N0SP4M_apri@cim._N0SP4M_mcgill.ca> wrote: > Sorry, my bad. I thought you were referring to his statement on the >use of the SRL16. However, the OP implied that his global clear was >post-power-up. Couldn't there be a way to initialize the latch at >power-up, after which the value would be kept across global clears? I >haven't thought out the details, but it doesn't seem too complicated >(famous last words ;)... I was under the impression that there was a >way of differentitating power-up reset and subsequent global clears... There is. SRL16, initialized to 0x0001, arbitrary delay lenght, with the input as a 0. The first cycle on startup it will be a 1, but every cycle thereafter, even after global reset, it will be a 0. If you want a longer "start high" you can make the initial chain of 1s be longer. Or use logic to drive a LUT-as-ram which you then set to 0 after enough startup time has passed. Basically, you observe that LUT-as-RAM, SRL, BlockRAM contents are preserved across global reset, but start on initialization in a defined state. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 67113
Hello everyone, I have a verilog design that is tested and works properly with ModelSim simulator. I have synthesized it with Xilinx Project Navigator tool using XST. I want to verify if the design works properly(after synthesis) before I can go on with downloading the BIT stream onto a Xilinx FPGA board. I could not find a way to do this. Could anyone please help me in this matter. Thanks a lot, KumarArticle: 67114
Thanks a lot for the explanations, it's well understood now what
means reballing. I guess it must be a special process that you can't
do in your home...
Article: 67115kumar wrote: > Hello everyone, > > I have a verilog design that is tested and works properly with > ModelSim simulator. I have synthesized it with Xilinx Project > Navigator tool using XST. I want to verify if the design works > properly(after synthesis) before I can go on with downloading the BIT > stream onto a Xilinx FPGA board. > I could not find a way to do this. Could anyone please help me in this > matter. > Thanks a lot, > Kumar Just simulate it with the same testbench you used to test the verilog design (i.e. use the post place and routed generated verilog file with back-annotated timing file (sdf file) with your testbench and you should then now how good it really works. SalmanArticle: 67116
Hi every body,
I tried to make a P&R with ISE 5.2 and i saw that there is no XC4000
target possible. Is there a library i have to download or do i have to
look for an old version of Xilinx tools. If so what is the last version
and tool that will be capable of making P&R for and XC4003A and an
XC3020A
Thanks
Article: 67117Hello everyone, I have a verilog design that is tested with ModelSim simulator and it works properly. I have synthesized it with Xilinx ISE Tool using XST and I want to test it(after synthesis) before I can go on with downloading the BIT file onto a Xilinx FPGA board. I could not find a way to do it. Can anyone please help me in this matter? Thanks a lot, KumarArticle: 67118
On Fri, 05 Mar 2004 16:22:45 -0500, salman sheikh wrote: > kumar wrote: >> Hello everyone, >> >> I have a verilog design that is tested and works properly with >> ModelSim simulator. I have synthesized it with Xilinx Project >> Navigator tool using XST. I want to verify if the design works >> properly(after synthesis) before I can go on with downloading the BIT >> stream onto a Xilinx FPGA board. >> I could not find a way to do this. Could anyone please help me in this >> matter. >> Thanks a lot, >> Kumar > > Just simulate it with the same testbench you used to test the verilog > design (i.e. use the post place and routed generated verilog file with > back-annotated timing file (sdf file) with your testbench and you should > then now how good it really works. > > Salman ngd2ver converts an ngd file back to verilog, you can plug the gate level verilog file back into your testbench. Simulating a gate level netlist is painfully slow especially with a slow simulator like ModelSim. Unless you suspect that you've had a synthesis error there is no reason to do a gate level simulation. Even if you suspect a synthesis problem you are better off trying to narrow it down using ChipScope then trying to do a gate level simulation.Article: 67119
erojr wrote: > > rickman wrote: > > > TRST puts the state machine in a defined state. Most devices also reset > > the state machine on power up. In addition, if you hold the TMS line > > high and clock TCK it will return the state machine to the starting > > state after 5 clock cycles, IIRC. Of course, depending on the > > implementation, the mechanism that operates the state machine can get > > fouled up by power glitches or other anomalies. Then the machine may > > get into a state that operating the TCK line may not control the state. > > Then you will need a power on or a TRST type reset. I don't know that > > this is common, but in theory it is possible. > > Thank you for the description. This is exactly that I also found. I do not > use the TRST pin but I have never seen a case when the JTAG State Machine > did not return to RESET state after 5 clocks. I use the JTAG chain for > regular check of the FPGA input pins, not only for programming. > > The original question was the open TRST pin, but due to the standard > internal pullup - I hope this is the case in Altera FPGAs too, but this > was not yet confirmed by anybody - the open input must not be the reason > for incorrect behavior. I don't know about Altera, but I read that TI uses just the opposite convention on their chips. They require a *pulldown* on the board and the JTAG emulator has to have an active pullup to assert the TRST. I assume the TI TRST inputs have no pullup or down. Why not put a TRST pullup on the board to be safe? 10K should do the job and not get in the way. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 67120
Greg, Two things: first, the spec is not peak to peak, but cycle to cycle, so we do not "exceed" our spec as you erroneously state, and second, the jitter from the DLL is decidely non-gaussian so any statistical estimates are wrong. Can't "multiply by 6" or any other shortcut. The peak to peak jitter is entirely random, but not a normal distribution as the taps are discrete, and the selection of the taps is from a digital control system. The intrinsic jitter is not very interesting, as the "when busy" jitter of our part is 1/3 of yours under the same conditions. Choosing the 2X output is also not entirely honest, as the 1X outputs have half the jitter (something you fail to mention, but we freely advise our customers of). Other than that, we also have LeCroy equipment, and use it often. The +/- 6 ps intrinsic measurement capability for jitter is selling you short, however, as the Wavecrest with its +/- 3 ps peak to peak worst case intrinsic jitter would make the PLL look better. Austin Greg Steinke wrote: > "Michael Chan" <m.chan1@uq.edu.au> wrote in message news:<c261a1$atj$1@bunyip.cc.uq.edu.au>... > >>Just wondering if anyone can point me to some articals or papers that analyse >>the characteristics of xilinx DLLs vs altera PLLs. >> >>Thanks. > > > Michael, > Altera has published a document comparing PLLs to DLLs, specifically > looking at jitter. > http://www.altera.com/literature/tb/tb70.pdf > > We also publish specs for PLL jitter in the appropriate device > datasheet, so you can take a look at those as well. > > Sincerely, > Greg Steinke > gregs@altera.com > Altera CorporationArticle: 67121
Hi all, I have two boards with the exactly same fpga (spartanIIE) and same code inside them. One of the boards hangs 2~10 minute after power on. I want to find out the reason. Is it due to power problem on one of the boards? grouding or ...? please let me know your ideas. regards.Article: 67122
Hi I have a query for those of you whish to help My Problem Variable frequency output via a PLD control of a Switched reluctance motor. (Overview) The system should be capable of driving a three phase Switched Reluctance motor open-loop (no current or position feedback), no-load, at a minimum speed of 10 r.p.m. The system should include a soft start (frequency ramp) facility and the ability to operate in either direction. Any suitable power electronic devices may be used. The control electronics must be isolated from the power electronics. The control electronics should comprise of PLD technology. So my part is the softstart (thanks guys) I have only cupl available and a Lattice Gal20v8 device. my max frequency output would be 200Hz my minimum requirement is 2 Hz. from this I would like to try and make the input frequency to say around 400Hz.Then somehow cut this frequency by use of a counter type flip-flop array in the Gal, but would also like to take the outputs from the said (4 bit) counter to use as my ramp. Thus Giving a possible 16 frequency outputs. Is it possible to have the counter and then have a state machine use the outputs of the counter to generate a ramping frequency effect on 1 single output pin of the GAL? My knowledge of cupl is to say, at best is limited, I have seen programs in VHDL (of which my knowledge is even less), which claim to be able to achieve this. I am a student undertaking an assignment so I am not looking for answers (I want to learn) only pointers on how to get there. Very best regards StewartArticle: 67123
First: check that both boards really operate with the same input signals. Swap the boards and check where the failure moves. Next: Vary ambient temperature and also (separately) Vcc, and note their impact on the behavior. These two simple test should give you some clues. "Minutes" almost always points to a temperature effect, unless you have extremely long counters in the chip. It could also be caused by hanging undriven pins that very slowly drift High or Low. Hope this helps. Peter Alfke > From: naderimisc@yahoo.com (Masoud Naderi) > Organization: http://groups.google.com > Newsgroups: comp.arch.fpga > Date: 5 Mar 2004 14:17:52 -0800 > Subject: FPGA hangs > > Hi all, > I have two boards with the exactly same fpga (spartanIIE) and same > code inside them. One of the boards hangs 2~10 minute after power on. > I want to find out the reason. Is it due to power problem on one of > the boards? grouding or ...? > please let me know your ideas. > regards.Article: 67124
rickman wrote: > erojr wrote: >> >> rickman wrote: >> >> > TRST puts the state machine in a defined state. Most devices also reset >> > the state machine on power up. In addition, if you hold the TMS line >> > high and clock TCK it will return the state machine to the starting >> > state after 5 clock cycles, IIRC. Of course, depending on the >> > implementation, the mechanism that operates the state machine can get >> > fouled up by power glitches or other anomalies. Then the machine may >> > get into a state that operating the TCK line may not control the state. >> > Then you will need a power on or a TRST type reset. I don't know that >> > this is common, but in theory it is possible. >> >> Thank you for the description. This is exactly that I also found. I do not >> use the TRST pin but I have never seen a case when the JTAG State Machine >> did not return to RESET state after 5 clocks. I use the JTAG chain for >> regular check of the FPGA input pins, not only for programming. >> >> The original question was the open TRST pin, but due to the standard >> internal pullup - I hope this is the case in Altera FPGAs too, but this >> was not yet confirmed by anybody - the open input must not be the reason >> for incorrect behavior. > > I don't know about Altera, but I read that TI uses just the opposite > convention on their chips. They require a *pulldown* on the board and > the JTAG emulator has to have an active pullup to assert the TRST. I > assume the TI TRST inputs have no pullup or down. > > Why not put a TRST pullup on the board to be safe? 10K should do the > job and not get in the way. The idea is to hard ground it (0 ohms) to ensure that the part does stay in the operating mode (TEST-LOGIC-RESET). TRST* is asserted low. There have been cases observed where a part that has left the TEST-LOGIC-RESET state and dumped garbage into the command register (the holding register is a don't care) has not recovered with the 5 TCK's with TMS=1. Two causes that I have seen. One, the TCK is shared with a pin in the device that has decided to drive out, low, clamping the system clock to a '0'. The other was putting junk into the command register which sort of took the whole system down. -- rk, Just an OldEngineer "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- R. Feynman, Appendix F.
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