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
Peter Alfke wrote: > Steven, here is another version: > If yor Spartan device has the CLKFX option, then you just use > one DCM to multiply by 16 and simultaneously divide by 25, which gives > you a 48 MHz output. You can then use a simple 2-bit synchronous > counter to divide by 3, and that gives you the 16 MHz accurately. > Peter Alfke, Xilinx Applications (from home) > > Peter Alfke wrote: > > Steven, if yor Spartan device has the CLKFX option, then you just use > > one DCM to multiply by 16 and simultaneously divide by 15, which gives > > you an 80 MHz output. You can then use a simple 3-bit synchronous > > counter to divide by 5, and that gives you the 16 MHz accurately. > > Peter Alfke, Xilinx Applications (from home) > > ================ > > moogyd@yahoo.co.uk wrote: > > > Hi, > > > > > > We have an eval board with a spartan FPGA and a 75MHz XTAL > > > Within ourt design, we require an accurate 16MHz clock. > > > It is not possible to generate this frequency using a single DCM, is it > > > possible to chain 2 DCM's together to generate the 16MHz clock ? > > > > > > (the obvious solution is to change the XTAL, but I'd like to know > > > whether it is possible without changing the XTAL :-) ) > > > > > > Thanks for any feedback, > > > > > > Steven Peter, I do have the CLKFX option, so I can use your suggested solution. Thanks for (both :-) ) replies, StevenArticle: 109851
"jens" <roden@rochester.rr.com> wrote in message news:1160075118.579223.42130@h48g2000cwc.googlegroups.com... >> It lacks nothing. In fact any design that does NOT generate a >> synchronously >> timed trailing edge reset is 'lacking' and will eventually fail because >> at >> some point that trailing edge of reset will come along at a time relative >> to >> the clock that violates setup/hold timing requirements and cause a flip >> flop >> or two to go to the wrong state. This is all assuming that the clock is >> free running (or at least running at the trailing edge of reset). > > I can think of a couple of exceptions where a completely asynchronous > reset won't cause any problems: > > 1. A free-running counter that has no unrecoverable illegal states > (i.e. a bad state that doesn't eventually turn into a good state) and > no requirement to be immediately operational after reset. That's a pretty good description of something that does not require a reset, whether synchronous or asynchronous. My implicit assumption is that there is a functional requirement for a reset behaviour, bringing reset (or any other signal) in to something that doesn't have a functional requirement for that signal isn't a good practice either. > 2. An FPGA that is waiting for an external event (like a discrete input > or CPU register write) to start doing something, and the external event > happens after the reset. I guess I'm assuming here that this is not really another case of #1 where reset is not really needed and that there is some implied handshaking or feedback path of some sort between the CPU and your design. If we're talking about resetting some registers that the CPU can write to but the CPU code doesn't actually take advantage of that behaviour then I think we're back to #1...i.e. reset is not really needed for that writable CPU port and, upon reset, that port should really do nothing so again that port is independent of reset...sync or async reset is then a moot point. I'd also point out though, that if that writable CPU port is not spec'ed to say that it should do something upon reset then one should not reset it. If it is spec'ed to do something then eventually that port will not reset properly if the async reset is not properly handled and fail. Whether or not that failure shows up as an observable symptom of the system though is dependent on the rest of the system. For example, if the guy who wrote the code for the CPU took the defensive approach and did not rely on the spec'ed reset behaviour of that port but instead explicitly wrote to it himself then the failure would be masked. Assuming though that the two do form a feedback loop then.... In isolation you can get away with this as long as the guy who wrote the code for that 'external event that happens after the reset' doesn't do the same thing . Generally speaking if the two things (i.e. your design and the external thing) form any sort of handshake protocol and therefore form a feedback loop then each one must either... 1. Properly handle async inputs like reset 2. Depend on an implicit assumption that the 'other guy' will properly handle async inputs like reset so you don't have to. 3. Eventually fail if given enough time. Depending on the other guy's design to help make your design work is what is generally considered a 'latent bug'. While your design works in the environment that it was originally intended for, when moved to a different environment (i.e. one where the other guy didn't handle things properly and therefore also has a latent bug on the interface to your design) could cause problems down the road for that design. Based on that I'll retract somewhat my statement about "will eventually fail" since in certain applications where the 'other guys' reset behaviour is assumed and that assumption happens to hold then that overall design will not fail. > > I can't think of an FPGA design that I've worked on where one of those > options didn't apply. There's also a little bit of assumption with #1 > and an HDL- that the compiler doesn't do anything funny, like recognize > that a simple up or down counter in the code can be replaced by an > LFSR, in which case there can be illegal states. Interesting. Certainly #1 applies to certain areas...but as I stated those are actually areas that are independent of reset so I think the discussion is moot. As for #2, taking advantage of this opens up your design to assumptions that make your design more reliant on some outside design than it really should be. > So for designs that meet those options, there's no need to panic and do > a massive product recall. Agreed, didn't mean to imply that it should lead to recall either. Depending on what the actual application is though it might lead to proving that instances os #2 are truly 'latent' and, by virtue of how it is being currently used in this specific application, can not happen. > Yet for current & future designs, > synchronizing the trailing edge of a reset signal is a great idea. > Yep. KJArticle: 109852
"RadioShox" <robert.leune@gemidis.be> writes: > Hello, > Hi, <snip> > Has somebody ever found an Altera primitive for internal RAMs? > lpm_ram_* worked for me in the past. But do you have to instantiate? If it s a single clock, you can write code that will infer to RAM blocks in both devices quite easily. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 109853
"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message news:1160088362.036306.87980@c28g2000cwb.googlegroups.com... >> The next question to ponder is, given that the reset must be synchronized >> anyway, why use an asynchronous reset anywhere in your design (with the >> exception of course of the above mentioned synchronizer)? > > A purely synchronous reset requires the clock to be running for the > reset to take effect. The async initiated reset can still initiate the > reset even though the clock may have stopped (for whatever reason). Not quite. If you can't count on the clock being running then I would have the first flop of the synchronizer be asynchronously resetable to capture that event...but that's about it. Well actually, since you're dependent on the startup behaviour of the clock itself then there might be a small shift chain of async resetable flops just so that if the clock startup is squirly you can guarantee that the rest of the design gets at least a one clock cycle reset. That way once the clock does start up the rest of the design would get reset properly. The clock not running is the common rebuttal that keeps coming up but if the clock isn't running then just what behaviour DO you expect out of that part? If you take a step back and realize that you probably shouldn't expect anything useful out of a part that is not receiving the proper inputs yet (perhaps by design, after all it could be a power saving measure) then the outputs that do not actually reset themselves until the clock does start up is not really an issue. There probably are applications where the output of a flip flop in a part really does need to respond in the absence of a clock but even after prodding I haven't been heard of just what exactly that application is. In any case, the mere absence of a clock at the time of reset being asserted does not imply that, once the clock does arrive that things won't reset properly. KJArticle: 109854
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:uhcyhk8u8.fsf@trw.com... > "RadioShox" <robert.leune@gemidis.be> writes: > >> Hello, >> > Hi, > > <snip> >> Has somebody ever found an Altera primitive for internal RAMs? >> > > lpm_ram_* worked for me in the past. > > But do you have to instantiate? If it s a single clock, you can write > code that will infer to RAM blocks in both devices quite easily. Not to mention that using either lpm_ram_* or writing it yourself would make it portable between Xilinx and Altera and probably most other FPGA vendors and would not require any sort of generic to 'select' between the two non-portable options. KJArticle: 109855
vu_5421 wrote: > Hello, > > I am relatively new to VHDL design, and I bought this board as a first > time learning kit. > > I was mainly interested in the I/O expansion connector for this board. > It appears that the connector has both 3.3V and 5V outputs. If I had > wanted to interface the board with a PS/2 port for example (which uses > 5V logic levels), how can I force the Spartan board to output 5V logic > levels and not 3.3V output? > > I'm not too sure if this is even possible since the FPGA's voltage > requirements is only 3.3v. > > Thanks for your help. I believe the S3 starter kit already has a PS/2 port, but I suppose if you want both a mouse and a keyboard, you would need to add another. As for the voltages, 5V devices can see a 3.3V driver just fine. 3.3V is well above the 2.5V threshold for TTL logic. The trouble is that a 3.3V device can't interface directly with a 5V driver as it is beyond the voltage tolerance of most parts. You can simply use a shottky barrier diode to clamp the voltage at 3.3V, though. A lot of development boards already include some I/O with clamping diodes, but I'm not sure about the S3 starter kit board.Article: 109856
Dolphin wrote: > Hello, > > For a future project I need to design a programmable delay line. The > specifications are: steps of +/- 1 ns, range of 0 to 8 ns. I have no > PLLs left so I can't use a high-speed pipeline to design this. Note > that the delay should be fixed when temperature varies, this means that > I'll probably need some calibration. > I think that Xilinx uses something like this to delay the DQS signal in > the S3E DDR controller. > Has anybody got an idea how I should implement this? > > best regards, > Dolphin > Which FPGA? If Virtex4, you can use the idelays which will give you 64 steps of 75ps resolution, or you can use the io serializers. What clocks do you have to work with? Are the clk90 DCM outputs available?Article: 109857
I'm trying to figure out if it is possible to use partitions using either command line flow (I want to integrate it into a Makefile environment) or at least using xflow. So far I have come to the conclusion that there is no documentation at all on how to use it outside of Project Navigator. Something which also annoys me is that it seems like the entire design is synthesized (without any optimization I presume) every time I save a file in ISE if partitions are enabled. Using some -XstNtrc switch to xst which is not documented anywhere that I can find. And it seems like xst also gets an -ise switch which points to the .ise binary blob. (This means that it takes about a minute to save a small file in ISE because it waits for xst to complete...) /AndreasArticle: 109858
Hello, If I'm not mistaken, lpm_ram_* is a MegaFunction. Or can you just write it down without running MegaWizard? Best regards, Robert.Article: 109859
Thanks for all!! Finally I found local distributor who has 3 boards I'm interested in to sell. MarcinArticle: 109860
Robert wrote: > Hello, > > > If I'm not mistaken, lpm_ram_* is a MegaFunction. Or can you just write > it down without running MegaWizard? > > > Best regards, > Robert. LPM is an EIA standard that is supported by several tool vendors. From what I've gathered though Altera was one of the main proponents of the standard...but that doesn't necessarily dilute the fact that it is an accepted and implemented standard. That said, it's not a terribly impressive set of functions but if you don't have the time to code your own fifos memories, multipliers and dividers it can be handy and portable. KJArticle: 109861
Hi Andreas,
ISE 8.2 has a tcl interface and supports partitions,
Aurash
Andreas Ehliar wrote:
>I'm trying to figure out if it is possible to use partitions
>using either command line flow (I want to integrate it into a
>Makefile environment) or at least using xflow.
>
>So far I have come to the conclusion that there is no documentation
>at all on how to use it outside of Project Navigator. Something
>which also annoys me is that it seems like the entire design is
>synthesized (without any optimization I presume) every time I save a
>file in ISE if partitions are enabled. Using some -XstNtrc switch
>to xst which is not documented anywhere that I can find. And it
>seems like xst also gets an -ise switch which points to the .ise
>binary blob. (This means that it takes about a minute to save a
>small file in ISE because it waits for xst to complete...)
>
>
>/Andreas
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 109862RadioShox wrote: > Hello, > > Has somebody ever found an Altera primitive for internal RAMs? > The more portable approach is to use Martin's suggestion. But if you really want to find the Altera primitive just run through the MegaWizard to produce the VHDL file. Then simply open that file and take a look. What you'll likely find is that the MegaWizard produced file is a simple wrapper around the Altera primitive that you're interested in. From that you can search the Altera help for documentation on that primitive. The MegaWizard produced file will also obviously have an instantiation of that primitive with all of the generics set up per however it is that you answered things in the MegaWizard GUI. KJArticle: 109863
Ah, I understand! And very little information to find on the subject indeed. Looks like the FPGA vendors really are not interested in supporting inter-vendor portability... Well, thanks for the info on LPM functions. BR, Robert.Article: 109864
> > 1. A free-running counter that has no unrecoverable illegal states > > (i.e. a bad state that doesn't eventually turn into a good state) and > > no requirement to be immediately operational after reset. > That's a pretty good description of something that does not require a reset, > whether synchronous or asynchronous. My implicit assumption is that there > is a functional requirement for a reset behaviour, bringing reset (or any > other signal) in to something that doesn't have a functional requirement for > that signal isn't a good practice either. In many cases, that's true. However, a neat way to reset a maximum-length LFSR is to reset (or set) only one flip-flop, then there's no need for illegal state recovery. That's useful when implementing the reset is expensive (either in terms or routing or logic), or when the illegal state recovery is expensive (of course a carefully designed LFSR can use shared logic between illegal state recovery and end of sequence detection). Note that assumes you're either not concerned about an SEU (http://en.wikipedia.org/wiki/Single-event_upset) or have another way of recovering. > > 2. An FPGA that is waiting for an external event (like a discrete input > > or CPU register write) to start doing something, and the external event > > happens after the reset. > I guess I'm assuming here that this is not really another case of #1 where > reset is not really needed and that there is some implied handshaking or > feedback path of some sort between the CPU and your design. If we're > talking about resetting some registers that the CPU can write to but the CPU > code doesn't actually take advantage of that behaviour then I think we're > back to #1...i.e. reset is not really needed for that writable CPU port and, > upon reset, that port should really do nothing so again that port is > independent of reset...sync or async reset is then a moot point. > > I'd also point out though, that if that writable CPU port is not spec'ed to > say that it should do something upon reset then one should not reset it. If > it is spec'ed to do something then eventually that port will not reset > properly if the async reset is not properly handled and fail. A simple example of where a reset (of any kind) is needed is a CPU-controlled FPGA output, where you don't want it to turn on unless told to by the CPU (especially during the time between reset and when the CPU has the first opportunity to write to it). As long as the CPU isn't trying to write to the register during or immediately after reset, there won't be any problems, regardless of what type of reset is used. However, the best design doesn't make assumptions about what is happening elsewhere, but sometimes compromises can be made to reduce cost or design time (as long as those compromises are made wisely). I have a theorem: 1 hour at the desk = 1 day in the lab = 1 week in the field. However, it seems that many managers don't want to spend an extra hour now and take the risk of a week + travel (and/or reprogram/recall) later.Article: 109865
jens wrote: > > > 1. A free-running counter that has no unrecoverable illegal states > > > (i.e. a bad state that doesn't eventually turn into a good state) and > > > no requirement to be immediately operational after reset. > > > That's a pretty good description of something that does not require a reset, > > whether synchronous or asynchronous. My implicit assumption is that there > > is a functional requirement for a reset behaviour, bringing reset (or any > > other signal) in to something that doesn't have a functional requirement for > > that signal isn't a good practice either. > > In many cases, that's true. However, a neat way to reset a > maximum-length LFSR is to reset (or set) only one flip-flop, then > there's no need for illegal state recovery. That's useful when > implementing the reset is expensive (either in terms or routing or > logic), or when the illegal state recovery is expensive (of course a > carefully designed LFSR can use shared logic between illegal state > recovery and end of sequence detection). Note that assumes you're > either not concerned about an SEU > (http://en.wikipedia.org/wiki/Single-event_upset) or have another way > of recovering. OK, but the context of the examples that you presented was... "I can think of a couple of exceptions where a completely asynchronous reset won't cause any problems" I interpreted that (possibly incorrectly) to mean that the reset signal was completely asynchronous to the clock....which would then include the all important trailing edge of reset. If the trailing edge of reset is not sync'ed to the clock then even that one bit in the LFSR that you are setting could end up getting reset at the trailing edge, if that trailing edg of reset violates a "reset inactive to clock recovery" time specification that would be applicable. The same would apply to your next example below as well. If you didn't mean that the trailing edge of reset was asynchronous to the clock then I still don't see any inherent advantage of the async over the sync in this instance until you start considering actual devices where one might have an advantage over the other by virtue of "that's the way they designed the chip" > > > > 2. An FPGA that is waiting for an external event (like a discrete input > > > or CPU register write) to start doing something, and the external event > > > happens after the reset. > > A simple example of where a reset (of any kind) is needed is a > CPU-controlled FPGA output, where you don't want it to turn on unless > told to by the CPU (especially during the time between reset and when > the CPU has the first opportunity to write to it). As long as the CPU > isn't trying to write to the register during or immediately after > reset, there won't be any problems, regardless of what type of reset is > used. > Same comments apply here as before. > However, the best design doesn't make assumptions about what is > happening elsewhere, but sometimes compromises can be made to reduce > cost or design time (as long as those compromises are made wisely). I > have a theorem: 1 hour at the desk = 1 day in the lab = 1 week in the > field. However, it seems that many managers don't want to spend an > extra hour now and take the risk of a week + travel (and/or > reprogram/recall) later. That's why it can be good to keep secrets from the boss at times ;) KJArticle: 109866
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message
news:ulkntke5c.fsf@trw.com...
> "Ben Jones" <ben.jones@xilinx.com> writes:
>
>> I have never heard a credible excuse for using an async reset
>> for any internal logic. I'm racking my brains to come up with some
>> clock-domain-crossing circuit that needs one
> Does the flancter count? XCELL37, which doesn't seem to be on the
> Xilinx site anymore... and Google isn't helping me find the original
> place I saw it :-(
I have to confess, I've never heard of it.
Then again, I don't do much flancting in most of my designs. :-)
-Ben-
Article: 109867Hi, This is for a Cyclone II FPGA. best regards, dolphin Ray Andraka schreef: > Dolphin wrote: > > Hello, > > > > For a future project I need to design a programmable delay line. The > > specifications are: steps of +/- 1 ns, range of 0 to 8 ns. I have no > > PLLs left so I can't use a high-speed pipeline to design this. Note > > that the delay should be fixed when temperature varies, this means that > > I'll probably need some calibration. > > I think that Xilinx uses something like this to delay the DQS signal in > > the S3E DDR controller. > > Has anybody got an idea how I should implement this? > > > > best regards, > > Dolphin > > > > Which FPGA? If Virtex4, you can use the idelays which will give you 64 > steps of 75ps resolution, or you can use the io serializers. > > What clocks do you have to work with? Are the clk90 DCM outputs available?Article: 109868
On 2006-10-06, Aurelian Lazarut <aurash@xilinx.com> wrote:
> Hi Andreas,
> ISE 8.2 has a tcl interface and supports partitions,
Yes, I've read that part of the documentation. But my problem
is (correct me if I'm wrong here) that there is no information
about how to use the tcl interface unless the project navigator
GUI is started. Is it even possible to do so?
If not, is it possible to start project navigator and force it
to run a certain tcl script at startup?
For automatic regression testing for example, it is not really
acceptable that you have to start a GUI and manually compile the
project. In fact, you probably don't want to start a GUI at all
since you are probably running it from a cronjob...
Another reason would be that it would be nice if partitions could
be used in flows that do not use Project Navigator such as the
one used in FPGA Advantage where only the Xilinx backend tools
are used.
My personal reason is that I'm not very fond of Project Navigator,
it is basically too sluggish and it doesn't interact well with
dual head. I also don't like the idea of putting all project
data in a binary blob (.ise) which is quite hard on revision
control systems [1]. I use emacs to edit all files anyway so my
only use for project navigator is basically to press the
"Generate bitfile" button.
/Andreas
[1] I know that you (nowadays) can use tcl to export and import
files which makes this situation better but still awkward.
Article: 109869Dolphin wrote: > Hello, > > For a future project I need to design a programmable delay line. The > specifications are: steps of +/- 1 ns, range of 0 to 8 ns. I have no > PLLs left so I can't use a high-speed pipeline to design this. Note > that the delay should be fixed when temperature varies, this means that > I'll probably need some calibration. > I think that Xilinx uses something like this to delay the DQS signal in > the S3E DDR controller. > Has anybody got an idea how I should implement this? > > best regards, > Dolphin Overspecifying can kill the possible solutions. Are you sure you need 1 ns steps? Can n steps (n>=8) that can be shown through internal measurements to cover 8 ns be sufficient? Can you handle some drift with temperature as long as you can adjust the taps when the change makes another tap more "ideal" for a fixed time? With a CycloneII you probably have zero chance of a PVT-independent (process, voltage, tolerance) delay line or a delay line with explicit precision (e.g., 1.0 ns steps). Can you look at other families? The DQS circuitry you might recall could be from the Xilinx Virtex4 or the Lattice ECP2 family. The Virtex-4 uses calibration, the ECP2 uses DLLs and neither covers the 8ns range. External PCB traces from identical drivers to identical drivers might be your only hope, but it's real estate. Good luck with your desires.Article: 109870
Hello John, I can do recalibration in the video blanking time (this for a video application). The step size doesn't have to be 1 ns and not all steps need to have the same latency. However if I program it to 3.5ns it should stay between 3 and 4 ns for the whole temperature range, a drift of 0.5ns is acceptable. Calibration can be done during this sweep through the temperature range. The temperature gradient won't be high so you can assume that there are enough calibration cycles . best regards, Dolphin John_H schreef: > Dolphin wrote: > > Hello, > > > > For a future project I need to design a programmable delay line. The > > specifications are: steps of +/- 1 ns, range of 0 to 8 ns. I have no > > PLLs left so I can't use a high-speed pipeline to design this. Note > > that the delay should be fixed when temperature varies, this means that > > I'll probably need some calibration. > > I think that Xilinx uses something like this to delay the DQS signal in > > the S3E DDR controller. > > Has anybody got an idea how I should implement this? > > > > best regards, > > Dolphin > > Overspecifying can kill the possible solutions. > > Are you sure you need 1 ns steps? Can n steps (n>=8) that can be shown > through internal measurements to cover 8 ns be sufficient? Can you > handle some drift with temperature as long as you can adjust the taps > when the change makes another tap more "ideal" for a fixed time? > > With a CycloneII you probably have zero chance of a PVT-independent > (process, voltage, tolerance) delay line or a delay line with explicit > precision (e.g., 1.0 ns steps). > > Can you look at other families? The DQS circuitry you might recall > could be from the Xilinx Virtex4 or the Lattice ECP2 family. The > Virtex-4 uses calibration, the ECP2 uses DLLs and neither covers the 8ns > range. > > External PCB traces from identical drivers to identical drivers might be > your only hope, but it's real estate. > > Good luck with your desires.Article: 109871
this is a good idea, thanks i am trying to load the quartus_stp package, the file exist in the qurtus/bin libarry but i can't load it, i am not using external logic analyzer how can i load the file? all the commands that belong to the in memorry edit is not available so' how can i load it? thank you very much david Subroto Datta =D7=9B=D7=AA=D7=91: > Hello David, > > You can use the TCL interface to automate the memory update. Use > quartus_sh --qhelp to get the help on the "insystem_memory_edit" TCL > package. This package is only available in the shell provided by > quartus_stp.exe. > > If you are using an external logic analyzer, you can install the free > small standalone programmer > (https://www.altera.com/support/software/download/programming/quartus2/dn= l-quartus2_programmer.jsp) > with SignalTap II on the logic analyzer. This package includes the > quartus_stp.exe executable. If you are using SignalTap II Logic > Analyzer, the acquisition can be started in quartus_stp.exe as well > using the TCL command from the "stp" package. > > Hope this helps, > Subroto Datta > Altera Corp. > > > On Oct 5, 1:54=C2=A0am, "david" <1024.da...@gmail.com> wrote: > > hello > > thank you for your replay > > > > we allready tried this option before, but we have a problam, because we > > need to modify the data in the memory while the system is runing ( the > > in system memory size is to small for ower application), every 512 > > clock cycles. > > can we update the memory automaticly with new data from predefine files > > (hex files) while the system is runing? (it's not practiclly to rewrite > > manually every 512 clocks cycles, we need the system to run at least > > for 32768 clock cycles continusly, we can spend clock cycles as need to > > rewrite the content of the memory) > > > > thanks > > david > > > > Subroto Datta =D7=9B=D7=AA=D7=91: > > > > > > > > > It is definitely possible to update the memory and constants in a pro= grammed > > > device from Quartus using the In System Memory Content Editor. Detail= s can > > > be found at: > > > > >http://www.altera.com/literature/hb/qts/qts_qii53012.pdf > > > > > You can use this in conjunction wiith SignalTap II Embedded logic ana= lyzer > > > to debug your work. > > > > > Hope this helps, > > > Subroto Datta > > > Altera Corp. > > > > > "david" <1024.da...@gmail.com> wrote in message > > >news:1159976602.300018.42380@e3g2000cwe.googlegroups.com... > > > > hello > > > > i am a student, working on development kit nios 2 cyclone edition. > > > > i want to use the logic analyzer to import data to the fpga from the > > > > logic analyzer, can i do it?- Hide quoted text -- Show quoted text -Article: 109872
I'm not an expert in tcl & ISE file but ASFAIK with the tcl console
does't need the GUI , you can find more information in the software docs
(I just checked the ISE help)
Have fun,
Aurash
Andreas Ehliar wrote:
>On 2006-10-06, Aurelian Lazarut <aurash@xilinx.com> wrote:
>
>
>>Hi Andreas,
>>ISE 8.2 has a tcl interface and supports partitions,
>>
>>
>
>Yes, I've read that part of the documentation. But my problem
>is (correct me if I'm wrong here) that there is no information
>about how to use the tcl interface unless the project navigator
>GUI is started. Is it even possible to do so?
>
>If not, is it possible to start project navigator and force it
>to run a certain tcl script at startup?
>
>
>For automatic regression testing for example, it is not really
>acceptable that you have to start a GUI and manually compile the
>project. In fact, you probably don't want to start a GUI at all
>since you are probably running it from a cronjob...
>
>Another reason would be that it would be nice if partitions could
>be used in flows that do not use Project Navigator such as the
>one used in FPGA Advantage where only the Xilinx backend tools
>are used.
>
>My personal reason is that I'm not very fond of Project Navigator,
>it is basically too sluggish and it doesn't interact well with
>dual head. I also don't like the idea of putting all project
>data in a binary blob (.ise) which is quite hard on revision
>control systems [1]. I use emacs to edit all files anyway so my
>only use for project navigator is basically to press the
>"Generate bitfile" button.
>
>
>
>/Andreas
>
>[1] I know that you (nowadays) can use tcl to export and import
> files which makes this situation better but still awkward.
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 109873Hi Jens, I don't have the ISE 8.1i version, so I can't use the patch for 8.1.01. As I say, I have only ISE 6.3i and ISE 8.2i. Thang NguyenArticle: 109874
Dear Jens, I can't use the patch for 8.1i because I don't have the ISE 8.1i. I have only the ISE version 6.3i or ISE 8.2i. Do I misunderstand something? I read in the PREAT_install.doc, and it told me that the PartialFlow_v8.zip file has to be installed on the top of ISE 6.3i SP3. But when I install, the program told me that this only use for ISE 8.1i version. Is there another version of PartialFlow which use with ISE 6.3i??? Thank Jens Thang Nguyen
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