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
I am trying to perform a functional simulation of a circuit which contains a multiplier (LPM_MULT) feeding into a ram cell (VHDL code). Using the Node Finder, I have added the output of the multiplier "mult:inst|result" to my .vwf file, but I get the following warning message when I simulate: Warning: Can't find node mult:inst|result[0] for functional simulation. Ignored vector source file node. I have read the question posed by Christos (10/9/2003), and responded to by Subroto Datta (10/9/2003). Since I am performing a functional simulation, and the Node Finder can find the node of interest: (1) Should the LCELL still be necessary? (2) Why can't the node be found, is it stripped out when I run the "Generate Functional Simulation Netlist" tool? Regards, DaltonArticle: 72426
"Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10i4h0o226sfi01@news.supernews.com>... > Ok, I finally got ST2 going and it's great! But everytime a add or change a > signal to look at it does a full rebuild (~20min.) > > The docs seem to indicate that simply adding a node shouldn't take so long, > but I can't figure out how to affect it. Smart compile and all the options > listed in the docs are turned on, but I don't see any benefit. > > Even if I just press the build > twice in a row without editting *anything* > it still does a full build. > > What's the secret? :) > > Thanks, > Ken Hello Ken, Here is the secret taken from the Quartus Documentation. "Before using the SignalTap II incremental routing feature, you must perform a Smart compilation by turning on Automatically turn on Smart compilation, in the SignalTap II Logic Analyzer page of the Settings dialog box (Assignments menu). Also, you must reserve trigger and/or data nodes for SignalTap II incremental routing using the Trigger Nodes allocated and Data Nodes allocated boxes before compiling the design, and you must assign a SignalTap II incremental routing source by selecting SignalTap II: post-fitting in the Filter list in the Node Finder." Hope this helps. Subroto Datta Altera Corp.Article: 72427
Well, I'm learning more as I go... It seems that you have to compile the design before you can use the Node Finder. So I added an LCELL between the multiplier and the ram, and named it mult_out. I can then add mult_out to my .vwf file and it appears as it should in the output vectors, with the correct waveforms. Now if I can get the LCELL automagically stripped out when I create the actual device... Dalton Marris wrote: > I am trying to perform a functional simulation of a circuit > which contains a multiplier (LPM_MULT) feeding into a ram > cell (VHDL code). Using the Node Finder, I have added the > output of the multiplier "mult:inst|result" to my .vwf file, > but I get the following warning message when I simulate: > > Warning: Can't find node mult:inst|result[0] for functional > simulation. Ignored vector source file node. > > I have read the question posed by Christos (10/9/2003), and > responded to by Subroto Datta (10/9/2003). > > Since I am performing a functional simulation, and the Node > Finder can find the node of interest: > > (1) Should the LCELL still be necessary? > > (2) Why can't the node be found, is it stripped out when I > run the "Generate Functional Simulation Netlist" tool? > > Regards, > DaltonArticle: 72428
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cfv864$qi8$1@news.netpower.no>... > I'm working with a Nios II processor on an Altera fpga. Mostly, I'm doing > fine, but there is one feature of the Eclipse interface to gdb that I seem > to be missing - a gdb command window. There is a "nios2-gdb-server output" > option for the Console window, but that's for output only. I want to be > able to type my own commands. When using other gui front-ends for gdb, > including gvd, insight and ddd, there is no problem doing this, but I can't > find any way to get it in Eclipse. > > If I can't get this working, does anyone know of information about using gdb > directly from the command line on the Nios2, such as references for the > nios2-gdb-server parameters? Hi David, Here is some info on this from our engineering team: GDB console from the IDE: 1) Start a debug session in the IDE. 2) In the toolbar for the console window, select the triangle next to the "display output from selected processes" icon (which looks like a the "man who looks like he just got a beer from the fridge" icon). 3) Select the "Show Default Output" from the menu. This will switch the Console window to "Nios II Debugger". 4) To allow the user to type gdb commands in this window you need to click the "Show debugger console on target selection" icon from the debug toolbar (right next to the familiar "Step Return/Step Out" debug icon). 5) You can now type gdb commands in the console window. Ensure that your cursor is at the bottom line of the window. Alternatively, here is how you would do the same, but from the command line: 1) Launch a Nios SDK shell from the "Start" menu. 2) Type "nios2-gdb-server". It will tell you what port it's listening on. 3) Write-down the port-number printed by nios2-gdb-server on a post-it note. 4) Launch a *second* Nios SDK shell from the "Start" menu. 5) Type "nios2-elf-gdb" 6) At the (gdb) prompt, type: "target remote localhost:<PORT-NUMBER> 7) You're now talking to the target using command-line gdb. I don't think there's any gdb-command-line facility from *within* the eclipse environment, but you'd better get an answer from Peter Brookes (copied on this message) on that one. If you want to know the command-line parameters for nios2-gdb-server, type "nios2-gdb-server --help."Article: 72429
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cfv864$qi8$1@news.netpower.no>... > I'm working with a Nios II processor on an Altera fpga. Mostly, I'm doing > fine, but there is one feature of the Eclipse interface to gdb that I seem > to be missing - a gdb command window. There is a "nios2-gdb-server output" > option for the Console window, but that's for output only. I want to be > able to type my own commands. When using other gui front-ends for gdb, > including gvd, insight and ddd, there is no problem doing this, but I can't > find any way to get it in Eclipse. > > If I can't get this working, does anyone know of information about using gdb > directly from the command line on the Nios2, such as references for the > nios2-gdb-server parameters? Hi David (and other readers), Please disregard the 2nd to last paragraph in my reply to your question; I did not intend to post that, but pressed the button too soon! Quite obviously there is a method from the IDE (Mr. Brookes provided it). Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 72430
Are you trying to access on board SDRAM? Do you know whether you meet your timing for SDRAM? Most of time, that is the case unless your code is wrong. I also have NIOS I Cyclone Dev. board, but didn't get a chance to play with it. Which board do you have? KevinArticle: 72431
In article <cfvl1t$jm8$2@news.tudelft.nl>, Sidney Cadot <cadot@science-hyphen-and-hyphen-technology-dot.nl> wrote: >Hi all, > >If you have a Spartan-III development board and want to upload BIT files >from Linux, you may want to check out JOLT (a GPL'ed program): > >http://www.science-and-technology.nl/research/jolt/ > >It differs from the recently announced program by Andrew Rogers in that >it can upload BIT files directly, giving you a second alternative to >complete your Linux-only Xilinx FPGA toolchain. > >JOLT resets the FPGA's perfectly; in fact, it emulates the proprietary >IMPACT program bit-for-bit in the way it uploads the bit-image to the >FPGA. This was achieved by recording and analyzing the JTAG stream as >sent by IMPACT. > >A tidbit of useless info: it takes IMPACT (and JOLT) 1,699,882 jtag >clocks to upload a X3S400 bit image, 1,699,136 of which are used to >transfer the configuration data. > >JOLT _might_ work with Spartan-II / Virtex devices, but I don't have >those available for testing. Also, it currently requires the FPGA to be >the second JTAG chain device (the FPGA sits after the PROM on most >modern dev. boards). > >Other coming attractions may include PROM programming. > >These requirements could easily be overcome if I had some more hardware >available for testing, but alas (hint, hint...) > >Many kudos to my employer (Science and Technology BV in The Netherlands) >for providing me the opportunity to work on this, and allowing >distribution of this under the GPL. > Thanks to you for all your hard work and to your employer for their community-mindedness (perhaps Xilinx could learn from this?). So here is yet another example of an open-source community quickly working around problems. In this case the problem was the lack of a facility in Xilinx's WebPack software to allow Linux users to upload bits to their FPGAs. This can probably be traced back to Xilinx's dependence on the proprietary Jungo parallel port driver that (as I recall) requires a per-seat fee. I think I've seen something like four different open-source solutions to this problem now (two for Spartan II and two for Spartan III). If a few people can come up with programs for doing this in a few weeks time (without even having access to all of Xilinx's internal docs, resources, etc), why is it that Xilinx needed to use the Jungo driver anyway? At any rate this shows that there are quite a few resourceful Linux users out there that want to use Xilinx's tool/chips and can work around the missing tools. I ordered a Spartan III starter kit yesterday which now I will be able to use with Linux. PhilArticle: 72432
To clear the record, Jungo does not charge a per-seat fee and was not
the reason that a Linux-based WebPack was absent. The specific issue
was the per-seat license fee associated with Xilinx's GUI development
tool kit.
You may now return to your soapbox...
Phil Tomson wrote:
> In article <cfvl1t$jm8$2@news.tudelft.nl>,
> Sidney Cadot <cadot@science-hyphen-and-hyphen-technology-dot.nl> wrote:
>
>>Hi all,
>>
>>If you have a Spartan-III development board and want to upload BIT files
>
>>from Linux, you may want to check out JOLT (a GPL'ed program):
>
>>http://www.science-and-technology.nl/research/jolt/
>>
>>It differs from the recently announced program by Andrew Rogers in that
>>it can upload BIT files directly, giving you a second alternative to
>>complete your Linux-only Xilinx FPGA toolchain.
>>
>>JOLT resets the FPGA's perfectly; in fact, it emulates the proprietary
>>IMPACT program bit-for-bit in the way it uploads the bit-image to the
>>FPGA. This was achieved by recording and analyzing the JTAG stream as
>>sent by IMPACT.
>>
>>A tidbit of useless info: it takes IMPACT (and JOLT) 1,699,882 jtag
>>clocks to upload a X3S400 bit image, 1,699,136 of which are used to
>>transfer the configuration data.
>>
>>JOLT _might_ work with Spartan-II / Virtex devices, but I don't have
>>those available for testing. Also, it currently requires the FPGA to be
>>the second JTAG chain device (the FPGA sits after the PROM on most
>>modern dev. boards).
>>
>>Other coming attractions may include PROM programming.
>>
>>These requirements could easily be overcome if I had some more hardware
>>available for testing, but alas (hint, hint...)
>>
>>Many kudos to my employer (Science and Technology BV in The Netherlands)
>>for providing me the opportunity to work on this, and allowing
>>distribution of this under the GPL.
>>
>
>
> Thanks to you for all your hard work and to your employer for their
> community-mindedness (perhaps Xilinx could learn from this?).
>
> So here is yet another example of an open-source community quickly
> working around problems. In this case the problem was the lack of a
> facility in Xilinx's WebPack software to allow Linux users to upload bits
> to their FPGAs. This can probably be traced back to Xilinx's dependence
> on the proprietary Jungo parallel port driver that (as I recall) requires
> a per-seat fee. I think I've seen something like four different
> open-source solutions to this problem now (two for Spartan II and two for
> Spartan III). If a few people can come up with programs for doing this in
> a few weeks time (without even having access to all of Xilinx's internal
> docs, resources, etc), why is it that Xilinx needed to use the Jungo
> driver anyway?
>
> At any rate this shows that there are quite a few resourceful Linux users
> out there that want to use Xilinx's tool/chips and can work around the
> missing tools. I ordered a Spartan III starter kit yesterday which now I
> will be able to use with Linux.
>
> Phil
--
You've *read the email* - now *buy the book*
Article: 72433
I hate to say this but you probably could have better spent your time
developing a SVF file interpreter that runs on Linux that way you could
use the SVF files generated from iMPACT which already contain a full
implementation of the configuration algorithm and as updated as the
algorithms improve. Alternatively, you could take the JDrive [open and
free] source code (http://www.xilinx.com/bvdocs/appnotes/xapp500.pdf)
and compile it on Linux (as some already have) to also have an
up-to-date, all device configuration solution.
Sidney Cadot wrote:
> Hi all,
>
> If you have a Spartan-III development board and want to upload BIT files
> from Linux, you may want to check out JOLT (a GPL'ed program):
>
> http://www.science-and-technology.nl/research/jolt/
>
> It differs from the recently announced program by Andrew Rogers in that
> it can upload BIT files directly, giving you a second alternative to
> complete your Linux-only Xilinx FPGA toolchain.
>
> JOLT resets the FPGA's perfectly; in fact, it emulates the proprietary
> IMPACT program bit-for-bit in the way it uploads the bit-image to the
> FPGA. This was achieved by recording and analyzing the JTAG stream as
> sent by IMPACT.
>
> A tidbit of useless info: it takes IMPACT (and JOLT) 1,699,882 jtag
> clocks to upload a X3S400 bit image, 1,699,136 of which are used to
> transfer the configuration data.
>
> JOLT _might_ work with Spartan-II / Virtex devices, but I don't have
> those available for testing. Also, it currently requires the FPGA to be
> the second JTAG chain device (the FPGA sits after the PROM on most
> modern dev. boards).
>
> Other coming attractions may include PROM programming.
>
> These requirements could easily be overcome if I had some more hardware
> available for testing, but alas (hint, hint...)
>
> Many kudos to my employer (Science and Technology BV in The Netherlands)
> for providing me the opportunity to work on this, and allowing
> distribution of this under the GPL.
>
> Best regards, and I'd appreciate your feedback,
>
> Sidney Cadot
> <cadot at science hyphen and hyphen technology dot nl>
>
--
You've *read the email* - now *buy the book*
Article: 72434The flash PROM can now also be programmed using xc3sprog. It has taken a lot of experimenting to get the PROM programming to work. Xilinx has not released details of the programming algorithm for these devices in its datasheets. This means that I cannot be sure that the delays used are correct. Also verification is not performed. Negatives aside, this program has sucessfully programmed the Flash PROM on the $99 Spartan3 Starter Kit. http://www.rogerstech.co.uk/xc3sprog/ Regards Andrew Rogers -- Spartan3 configuration JTAG download tool for GNU/Linux available from http://www.rogerstech.co.uk/xc3sprog/Article: 72435
Hi all, Has anybody tried to simulate the xilinx ultraController design and had issues with the processor reseting itself very often. I have noticed a correlation to the reset having to do with when i write to the gpio. The simulation gives a message about UTLB having problems and that is why it is resetting Thanks MattArticle: 72436
Neil Glenn Jacobson wrote: > To clear the record, Jungo does not charge a per-seat fee and was not > the reason that a Linux-based WebPack was absent. The specific issue > was the per-seat license fee associated with Xilinx's GUI development > tool kit. > > You may now return to your soapbox... Hold on, please allow me up there for a sec :-) Many if not most of the Linux-minded people out here do not care too much about the GUI tools. These people (including me) would be greatly helped if only the command line tools (of which xst, ngdbuild, map, par, and bitgen are the five most important ones) would be made available. A difficult proposition? It doesn't have to be. It's a matter of adding "-static" to your Makefile (probably there already), and putting the executables on the web. I really think it could be that simple. Just a bunch of statically linked executables; no support, a "you're on your own" kind of deal would suffice. Some of us hobbyists would figure out what files would be needed to get it up and running from the Windows webpack. Any help on this would of course be appreciated, but my point is that you guys could make us happy, now, at essentially zero cost. Now, realizing that Xilinx is not in the business of making us happy per sé (it's just a side effect of your nice products!), allow me to state some reasons why this could be a good thing for Xilinx, too. First, this would buy you guys at Xilinx time to decide on a long-run solution w.r.t. Linux Webpack support. There's a lot of rumbling among the proles, so to speak... Throw us a bone and we'll be silent for a couple of months. Second, it would be great - free - PR: "Xilinx makes first steps towards Linux support for its entry-level software". Third, it would have the potential to sell significant numbers of your entry-level kits for university lab-course use, which is not important in itself, but remember that those students will become paying customers in three-to-five years time. The WINE guys did a tremendous job on their glue layer, and your company has been overall very positive w.r.t. Wine support. I for one am truly happy that I am able to do end-to-end VHDL-to-FPGA development on Linux only now, but you could make me much happier still by providing native tools. In each and every aspect, I have been truly impressed with Xilinx ever since I started FPGA work half a year ago. Your level of documentation is superb, and your website support is really wonderful. I didn't check out your competitors but they should be happy if they can approach your company in this respect. The single last blemish for me is the lack of a native low-cost Xilinx toolset. It is easy to underestimate the importance of this, but suffice it to say that if (one of) your competitor(s) /would/ start to provide this for their entry-level software, I'd seriously consider switching technologies - and I suspect that, similarly, there are users of your competitor's products that would switch to Xilinx if you take the first mover advantage here. In short, my hope is that someone would convince middle-to-upper management at Xilinx that there is a world to be won out there for you. Best regards, SidneyArticle: 72437
Andrew Rogers wrote: > The flash PROM can now also be programmed using xc3sprog. It has taken a > lot of experimenting to get the PROM programming to work. Xilinx has not > released details of the programming algorithm for these devices in its > datasheets. This means that I cannot be sure that the delays used are > correct. Also verification is not performed. > > Negatives aside, this program has sucessfully programmed the Flash PROM > on the $99 Spartan3 Starter Kit. > > http://www.rogerstech.co.uk/xc3sprog/ Great work Andrew. It seems we've been doing similar things over the last couple of days. I like your code and the SVF route may be the better way to go in the long run, as pointed out by Mr. Jacobson. I'll put my activities on hold for now and put a link on my web-page to yours. Regards, SidneyArticle: 72438
Neil Glenn Jacobson wrote: > I hate to say this but you probably could have better spent your time > developing a SVF file interpreter [...] You may well be right. I did have a lot of fun in the process though, so no regrets :-) Regards, SidneyArticle: 72439
The short answer that avoids almost all the specific issues you raise is
that we are moving away from a GUI toolkit that is encumbered with a
per-seat license fee.
Sidney Cadot wrote:
> Neil Glenn Jacobson wrote:
>
>> To clear the record, Jungo does not charge a per-seat fee and was not
>> the reason that a Linux-based WebPack was absent. The specific issue
>> was the per-seat license fee associated with Xilinx's GUI development
>> tool kit.
>>
>> You may now return to your soapbox...
>
>
> Hold on, please allow me up there for a sec :-)
>
> Many if not most of the Linux-minded people out here do not care too
> much about the GUI tools.
>
> These people (including me) would be greatly helped if only the command
> line tools (of which xst, ngdbuild, map, par, and bitgen are the five
> most important ones) would be made available.
>
> A difficult proposition? It doesn't have to be. It's a matter of adding
> "-static" to your Makefile (probably there already), and putting the
> executables on the web. I really think it could be that simple. Just a
> bunch of statically linked executables; no support, a "you're on your
> own" kind of deal would suffice.
>
> Some of us hobbyists would figure out what files would be needed to get
> it up and running from the Windows webpack. Any help on this would of
> course be appreciated, but my point is that you guys could make us
> happy, now, at essentially zero cost.
>
> Now, realizing that Xilinx is not in the business of making us happy per
> sé (it's just a side effect of your nice products!), allow me to state
> some reasons why this could be a good thing for Xilinx, too.
>
> First, this would buy you guys at Xilinx time to decide on a long-run
> solution w.r.t. Linux Webpack support. There's a lot of rumbling among
> the proles, so to speak... Throw us a bone and we'll be silent for a
> couple of months.
>
> Second, it would be great - free - PR: "Xilinx makes first steps towards
> Linux support for its entry-level software".
>
> Third, it would have the potential to sell significant numbers of your
> entry-level kits for university lab-course use, which is not important
> in itself, but remember that those students will become paying customers
> in three-to-five years time.
>
>
> The WINE guys did a tremendous job on their glue layer, and your company
> has been overall very positive w.r.t. Wine support. I for one am truly
> happy that I am able to do end-to-end VHDL-to-FPGA development on Linux
> only now, but you could make me much happier still by providing native
> tools.
>
> In each and every aspect, I have been truly impressed with Xilinx ever
> since I started FPGA work half a year ago. Your level of documentation
> is superb, and your website support is really wonderful. I didn't check
> out your competitors but they should be happy if they can approach your
> company in this respect. The single last blemish for me is the lack of a
> native low-cost Xilinx toolset.
>
> It is easy to underestimate the importance of this, but suffice it to
> say that if (one of) your competitor(s) /would/ start to provide this
> for their entry-level software, I'd seriously consider switching
> technologies - and I suspect that, similarly, there are users of your
> competitor's products that would switch to Xilinx if you take the first
> mover advantage here.
>
> In short, my hope is that someone would convince middle-to-upper
> management at Xilinx that there is a world to be won out there for you.
>
> Best regards,
>
> Sidney
>
--
You've *read the email* - now *buy the book*
Article: 72440Sidney Cadot wrote: > Andrew Rogers wrote: > >> The flash PROM can now also be programmed using xc3sprog. It has taken >> a lot of experimenting to get the PROM programming to work. Xilinx has >> not released details of the programming algorithm for these devices in >> its datasheets. This means that I cannot be sure that the delays used >> are correct. Also verification is not performed. >> >> Negatives aside, this program has sucessfully programmed the Flash >> PROM on the $99 Spartan3 Starter Kit. >> >> http://www.rogerstech.co.uk/xc3sprog/ > > > Great work Andrew. > > It seems we've been doing similar things over the last couple of days. I > like your code and the SVF route may be the better way to go in the long > run, as pointed out by Mr. Jacobson. > > I'll put my activities on hold for now and put a link on my web-page to > yours. > > Regards, Sidney > I had considered the SVF route. The problem is that the SVF player cannot give meaningful error messages, the SVF player is not aware of the task in hand. SVF can only report a mismatch between what was read on the TDO and what it was told to expect. http://www.asset-intertech.com/support/svf.pdf I have just updated my webpage, adding a link to yours. Regards Andrew -- Spartan3 configuration JTAG download tool for GNU/Linux available from http://www.rogerstech.co.uk/xc3sprog/Article: 72441
Sidney Cadot wrote: > Neil Glenn Jacobson wrote: > >> I hate to say this but you probably could have better spent your time >> developing a SVF file interpreter [...] > > > You may well be right. I did have a lot of fun in the process though, so > no regrets :-) You probably learned a lot as well, and that's more valuable than just about anything. One thing about proprietary tools and data formats is that they inspire all sorts of "just because" exploratory hacking. Witness the fascination people seem to have with the bitstream encoding. Even if it were published, there's not much that most mortals could do with it anyway. However, because it's Top Secret, it tantalises the reverse engineer in us all.. JohnArticle: 72442
Neil Glenn Jacobson wrote: > The short answer that avoids almost all the specific issues you raise is > that we are moving away from a GUI toolkit that is encumbered with a > per-seat license fee. Thanks for the short answer. This is exciting news, something to look forward to. Regards, SidneyArticle: 72443
Neil Glenn Jacobson wrote: > The short answer that avoids almost all the specific issues you raise is > that we are moving away from a GUI toolkit that is encumbered with a > per-seat license fee. That's good ( and not unexpected ), but in the nearer term, Xilinx could better serve their Linux users by adding a WEB page, that clearly defines which pieces 'work in all cases', which ones 'are available, but for $$', and what the solution option are, with the trade offs. If this page was updated to links to the various Linux support efforts, it would avoid duplication of effort. It seems the user-based Linux FPGA tools deployment is quite advanced, and Xilinx is also working in that direction, so a Linux-beta program could also benefit Xilinx. [ 64 bit tools development would certainly benefit ] This could be run on a model similar to the University program ( and there would be overlap ) -jgArticle: 72444
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cfptk6$n4e$1@news.netpower.no>... > I'm working with a NIOS II cpu on an Altera Stratix chip. I'm finding it > easy enough to make simple Avalon slave devices, using the "interface to > user logic" wizard to connect my components to the bus. But I can't find > any way to deal with memory devices that would logically connect to tristate > buses. I have a couple of synchronous ram devices which should be simple > enough to use (I can access them using a test module I made outside the > NIOS). Is there any simple way of connecting new devices to a tristate bus, > or any application notes that show how? > > Thanks, Hi David, On this: The trick is in the IO signal type (Input,Output,Inout) in the interface to user logic. If you specify your data bus as bi-directional, your peripheral will sprout a tri-state bus, and require an Avalon Tri-State bridge to master it. The next thing is "what about multiple devices on the tri-state bus" - the interface to user logic handles this as well. The trick is to specify which signals are "shared". Anything not "shared" will have a unique pin in the collection of pins on the tri-state bus (this is useful for sharing an IO for read/write/byte enables). The Avalon Bus Spec reference manual should discuss this a bit as well. Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 72445
John Williams wrote: >>> I hate to say this but you probably could have better spent your time >>> developing a SVF file interpreter [...] >> >> You may well be right. I did have a lot of fun in the process though, >> so no regrets :-) > > You probably learned a lot as well, and that's more valuable than just > about anything. I sure did. I hadn't hooked up FPGA's before this. You see, I'm a software, not a hardware, guy by training so I really expected the whole excercise to end in smoke and, well, tears. It did not, so I now know that I can easily tie together a couple of development boards using the user I/O pins if the need arises. Second, I know understand enough of JTAG to be able to use it as intended, instead of swapping parallel cables all the time. > One thing about proprietary tools and data formats is that they inspire > all sorts of "just because" exploratory hacking. Certainly. it is a chilling thought that even the kind of simple reverse engineering (analyzing what IMPACT puts on the parallel port) is getting increasingly difficult from a legal standpoint. I am not sure if I would have posted this openly to a Usenet group if I were a US citizen - a strict reading of the DMCA probably outlaws even this completely innocent stuff that is for the good of everybody (including Xilinx). > Witness the fascination people seem to have with the bitstream encoding. > Even if it were published, there's not much that most mortals could do > with it anyway. However, because it's Top Secret, it tantalises the > reverse engineer in us all.. I guess we're all still kids, taking apart stuff to see how it works :-) Regards, SidneyArticle: 72446
"Subroto Datta" <sdatta@altera.com> wrote in message news:ca4d800d.0408181133.5739aa1e@posting.google.com... > "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10i4h0o226sfi01@news.supernews.com>... > > Ok, I finally got ST2 going and it's great! But everytime a add or change a > > signal to look at it does a full rebuild (~20min.) > > > > The docs seem to indicate that simply adding a node shouldn't take so long, > > but I can't figure out how to affect it. Smart compile and all the options > > listed in the docs are turned on, but I don't see any benefit. > > > > Even if I just press the build > twice in a row without editting *anything* > > it still does a full build. > > > > What's the secret? :) > > > > Thanks, > > Ken > > Hello Ken, > > Here is the secret taken from the Quartus Documentation. > > "Before using the SignalTap II incremental routing feature, you must > perform a Smart compilation by turning on Automatically turn on Smart > compilation, in the SignalTap II Logic Analyzer page of the Settings > dialog box (Assignments menu). Also, you must reserve trigger and/or > data nodes for SignalTap II incremental routing using the Trigger > Nodes allocated and Data Nodes allocated boxes before compiling the > design, and you must assign a SignalTap II incremental routing source > by selecting SignalTap II: post-fitting in the Filter list in the Node > Finder." > > > Hope this helps. > > Subroto Datta > Altera Corp. Hello Subroto, Thanks, I missed the part about manually over allocating Data and Trigger Nodes. I'll try that. Also, do you just hit the normal "Start Compilation" button (>) or do you use incremental route or something. I tried Signal Probe Compilation under Processing->Start, but I haven't tried Incremental Fit. Do you have any tips for either finding renamed (?) post-fit signals or a shure fire way to have a signal not optimized away? Inserting LCELL's (graphical) and naming both the input and the output. I've also got some AHDL and I haven't seen the equivalent of the Preserve or Keep directive. If you don't mind, could you or someone post a snippet of AHDL placing a signal into a named LCELL? BTW, I'm loving this LA. This is like having a source code debugger for hardware! I've put my physical LA away for now as ST is much more flexible and trustworthy. KenArticle: 72447
In article <cg0l1u$jp22@cliff.xsj.xilinx.com>, Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote: >To clear the record, Jungo does not charge a per-seat fee and was not >the reason that a Linux-based WebPack was absent. The specific issue >was the per-seat license fee associated with Xilinx's GUI development >tool kit. > >You may now return to your soapbox... > Ok, it's the MainWin porting tool that requires the per-seat license. That's pretty much what keep Xilinx from having a set of free tools for Linux, correct? BTW: I'm a customer. Just trying to help you guys out ;-) PhilArticle: 72448
In article <cg0pjd$jov3@cliff.xsj.xilinx.com>, Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote: >The short answer that avoids almost all the specific issues you raise is >that we are moving away from a GUI toolkit that is encumbered with a >per-seat license fee. > That works too! Good to hear. Any idea about when we might see the fruits of these efforts? Thanks PhilArticle: 72449
In article <cg0ldg$jp01@cliff.xsj.xilinx.com>, Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n.a.t.x.i.l.i.n.x.c.o.m.> wrote: >I hate to say this but you probably could have better spent your time >developing a SVF file interpreter that runs on Linux that way you could >use the SVF files generated from iMPACT which already contain a full >implementation of the configuration algorithm and as updated as the >algorithms improve. Alternatively, you could take the JDrive [open and >free] source code (http://www.xilinx.com/bvdocs/appnotes/xapp500.pdf) >and compile it on Linux (as some already have) to also have an >up-to-date, all device configuration solution. > Not having been in the FPGA world for several years (but getting back in as a hobbyist)... What's an SVF file? Even if we had an interpreter for SVF files, how would that help us get the bits into the FPGA? Seems like we still need something like JOLT (the physical layer) to actually get the bits there. Phil
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