Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 72425

Article: 72425
Subject: Viewing internal nets during Quartus functional simulation
From: Dalton Marris <dmarris@charter.net>
Date: Wed, 18 Aug 2004 14:37:36 -0400
Links: << >>  << T >>  << A >>
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,
Dalton

Article: 72426
Subject: Re: Secret to SignalTapII Incremental Build?....
From: sdatta@altera.com (Subroto Datta)
Date: 18 Aug 2004 12:33:55 -0700
Links: << >>  << T >>  << A >>
"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
Subject: Re: Viewing internal nets during Quartus functional simulation
From: Dalton Marris <dmarris@charter.net>
Date: Wed, 18 Aug 2004 16:19:23 -0400
Links: << >>  << T >>  << A >>
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,
> Dalton

Article: 72428
Subject: Re: Nios II debugging with gdb
From: kempaj@yahoo.com (Jesse Kempa)
Date: 18 Aug 2004 13:31:15 -0700
Links: << >>  << T >>  << A >>
"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
Subject: Re: Nios II debugging with gdb
From: kempaj@yahoo.com (Jesse Kempa)
Date: 18 Aug 2004 13:42:31 -0700
Links: << >>  << T >>  << A >>
"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 com

Article: 72430
Subject: Re: SDRAM Controller on a cyclone dev kit
From: "kattice" <kattice@hotmail.com>
Date: Wed, 18 Aug 2004 16:49:05 -0400
Links: << >>  << T >>  << A >>
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?

Kevin  


Article: 72431
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: ptkwt@aracnet.com (Phil Tomson)
Date: 18 Aug 2004 21:15:22 GMT
Links: << >>  << T >>  << A >>
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

Article: 72432
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: 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.>
Date: Wed, 18 Aug 2004 15:26:00 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: 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.>
Date: Wed, 18 Aug 2004 15:32:11 -0700
Links: << >>  << T >>  << A >>
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: 72434
Subject: Free Flash PROM programming tool for GNU/Liunx
From: Andrew Rogers <andrew@_NO_SPAM_rogerstech.co.uk>
Date: Wed, 18 Aug 2004 23:54:47 +0100
Links: << >>  << T >>  << A >>
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/

Regards
Andrew Rogers


-- 
Spartan3 configuration JTAG download tool for GNU/Linux available from
http://www.rogerstech.co.uk/xc3sprog/


Article: 72435
Subject: xilinx ultracontroller reseting in simulation
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Wed, 18 Aug 2004 19:12:35 -0400 (EDT)
Links: << >>  << T >>  << A >>
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

Matt

Article: 72436
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: Sidney Cadot <cadot@science-hyphen-and-hyphen-technology-dot.nl>
Date: Thu, 19 Aug 2004 01:25:07 +0200
Links: << >>  << T >>  << A >>
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


Article: 72437
Subject: Re: Free Flash PROM programming tool for GNU/Liunx
From: Sidney Cadot <cadot@science-hyphen-and-hyphen-technology-dot.nl>
Date: Thu, 19 Aug 2004 01:30:56 +0200
Links: << >>  << T >>  << A >>
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


Article: 72438
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: Sidney Cadot <cadot@science-hyphen-and-hyphen-technology-dot.nl>
Date: Thu, 19 Aug 2004 01:35:14 +0200
Links: << >>  << T >>  << A >>
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, Sidney


Article: 72439
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: 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.>
Date: Wed, 18 Aug 2004 16:43:35 -0700
Links: << >>  << T >>  << A >>
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: 72440
Subject: Re: Free Flash PROM programming tool for GNU/Liunx
From: Andrew Rogers <andrew@_NO_SPAM_rogerstech.co.uk>
Date: Thu, 19 Aug 2004 00:56:23 +0100
Links: << >>  << T >>  << A >>
Sidney 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
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 19 Aug 2004 09:58:04 +1000
Links: << >>  << T >>  << A >>
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..

John

Article: 72442
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: Sidney Cadot <cadot@science-hyphen-and-hyphen-technology-dot.nl>
Date: Thu, 19 Aug 2004 02:14:13 +0200
Links: << >>  << T >>  << A >>
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, Sidney


Article: 72443
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 19 Aug 2004 12:19:16 +1200
Links: << >>  << T >>  << A >>
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 )

-jg


Article: 72444
Subject: Re: NIOS II memory devices on tristate bridges
From: kempaj@yahoo.com (Jesse Kempa)
Date: 18 Aug 2004 17:57:41 -0700
Links: << >>  << T >>  << A >>
"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 com

Article: 72445
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: Sidney Cadot <cadot@science-hyphen-and-hyphen-technology-dot.nl>
Date: Thu, 19 Aug 2004 03:03:55 +0200
Links: << >>  << T >>  << A >>
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, Sidney


Article: 72446
Subject: Re: Secret to SignalTapII Incremental Build?....
From: "Kenneth Land" <kland_not_this@neuralog_not_this.com>
Date: Wed, 18 Aug 2004 22:07:44 -0500
Links: << >>  << T >>  << A >>

"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.

Ken



Article: 72447
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: ptkwt@aracnet.com (Phil Tomson)
Date: 19 Aug 2004 03:53:11 GMT
Links: << >>  << T >>  << A >>
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 ;-)

Phil

Article: 72448
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: ptkwt@aracnet.com (Phil Tomson)
Date: 19 Aug 2004 04:00:17 GMT
Links: << >>  << T >>  << A >>
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

Phil

Article: 72449
Subject: Re: Announcing JOLT - Yet Another Xilinx Programming Tool
From: ptkwt@aracnet.com (Phil Tomson)
Date: 19 Aug 2004 04:11:16 GMT
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search