Hi,
I had a look around the SVN repo when the most recent USRP announcement
was made and I noticed that the .ise project file has been committed.
In my experience this doesn’t work very well - project navigator touches
it everytime you do just about everything. Also I’ve had PN crash when
you open an ise file from another platform. It also has a tendency to
corrupt it and recreating it by hand sucks.
To work around this I have a script that uses the ‘pjcli’ tool, it looks
like this…
Create the project
NewProject(foo.ise)
Set basic properties
SetProperty(Device Family, spartan3)
SetProperty(Device, xc3s400)
SetProperty(Package, tq144)
SetProperty(Speed Grade, -4)
SetProperty(Top-Level Module Type, HDL)
Add the sources
AddSource(foo.v, Verilog Design File)
AddSource(foo.ucf, foo)
AddSource(alu.xco, Coregen Design File)
AddSource(alu_wrap.v, Verilog Design File)
Test bench sources
AddSource(foo_test.v, Verilog Design File)
SetProperty(Simulation Run Time, 5000 ns, foo_test_v, Simulate
Post-Place & Route Model, 9, foo)
Close the project to tidy up
CloseProject()
To use it you run…
pjcli -f foo.npl
On Wed, Jan 16, 2008 at 04:40:18PM +1030, Daniel O’Connor wrote:
like this…
Daniel, we’d love to have a better solution. We’re using 9.2.04i.
Can you create what ever this script is and tell how to use it? On a
related topic, we were wondering if you really can run the xilinx
tools from a Makefile and get access to all of the options that are
available in ISE. In looking at the tcl log, it appears that it’s
passing most of the options by way of the .ise binary blob.
Thanks,
Eric
On Wed, 16 Jan 2008, Eric B. wrote:
related topic, we were wondering if you really can run the xilinx
I found about it when I asked Xilinx tech support. The only commands in
it I’m aware of are the ones I’ve listed below although you can infer
parameters from PN.
I normally use 8.2 but I did try it with 9.2 when I was testing
something and it seemed to work fine. I normally run it under FreeBSD
and 9.2 has issues with the emulation.
tools from a Makefile and get access to all of the options that are
available in ISE. In looking at the tcl log, it appears that it’s
passing most of the options by way of the .ise binary blob.
I believe you can do it - I did start writing one but I ran into
difficulties with simulation. I don’t have ModelSim and I couldn’t get
iverilog or cver to grok my code (I use Coregen cores and they don’t
like them).
I have found a few links you might be interested in WRT makefiles…
http://www.xess.com/appnotes/makefile.html
Also if you want to use Impact in Linux then you can use this
XILINX USB/Parallel JTAG cables on Linux without windrvr (I’d like to build a Linux libusb that
works with FreeBSD’s USB subsystem one day 
Dear people,
I use xilinx ise tools regularly so please do not commit the whole ise
project, this generates a corrupted project sooner o later. Xilinx made
a
workaround to make versioning of the files, please check this link to do
it:
http://forums.xilinx.com/xlnx/board/message?board.id=ISE&message.id=825#M825
By the way, take into account that if you use a makefile to build the
bitstream file, you can not use ise to manage the project, specially if
you
use coregen.
best regards,
Pedro Ignacio Martos
http://www.fi.uba.ar/~pmartos/
----- Original Message -----
From: “Daniel O’Connor” [email protected]
To: “Eric B.” [email protected]
Cc: [email protected]
Sent: Wednesday, January 16, 2008 5:29 AM
Subject: Re: [Discuss-gnuradio] ISE Project navigator and ISE files
On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O’Connor wrote:
wrote, but automatically. (Not that I can test it ATM, no 9.1 installs
handy)
build the bitstream file, you can not use ise to manage the project,
specially if you use coregen.
Hmm I think you can use both but you end up duplicating settings in the
makefile which is annoying (and potentially dangerous)
We’re not using coregen, so that part shouldn’t be a problem.
Eric
Eric-
It would seem the export option basically just generates the script I
wrote, but automatically. (Not that I can test it ATM, no 9.1 installs
handy)
build the bitstream file, you can not use ise to manage the project,
specially if you use coregen.
Hmm I think you can use both but you end up duplicating settings in the
makefile which is annoying (and potentially dangerous)
We’re not using coregen, so that part shouldn’t be a problem.
How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a
‘non-Xilinx’
method?
-Jeff
On Thu, Jan 17, 2008 at 11:55:42AM -0600, Jeff B. wrote:
We’re not using coregen, so that part shouldn’t be a problem.
How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a ‘non-Xilinx’
method?
We write them in verilog. We like to avoid vendor specific code when
possible, and non-free code like the plague.
We’ve pulled a fair amount of stuff from opencores.org. We’ve found
that the quality of code there is highly variable. Matt’s fixed the
parts we care about, or found people to fix them. This includes a GbE
MAC, wishbone compatible microblaze knock off (currently running at
50 MHz in a Spartan 3), lots of simple periperals such as I2C, SPI,
UART, interrupt controller, etc. That free software / open source
idea really does work 
Eric
On Jan 17, 2008 12:55 PM, Jeff B. [email protected] wrote:
How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a ‘non-Xilinx’
method?
I don’t think there’s any SDRAM on the new USRP2, but if there were,
you can still write an SDRAM controller in RTL. DDR, on the other
hand, has some different requirements.
For the other stuff, RTL should work just fine. The repository is here:
http://gnuradio.org/trac/browser/usrp2/trunk/fpga
Brian
Brian-
http://gnuradio.org/trac/browser/usrp2/trunk/fpga
Ok… would prefer Verilog, which Eric indicates he and Matt are using.
-Jeff
On Thu, Jan 17, 2008 at 12:35:59PM -0600, Jeff B. wrote:
We’ve pulled a fair amount of stuff from opencores.org. We’ve found
that the quality of code there is highly variable. Matt’s fixed the
parts we care about, or found people to fix them. This includes a GbE
MAC, wishbone compatible microblaze knock off (currently running at
50 MHz in a Spartan 3), lots of simple periperals such as I2C, SPI,
UART, interrupt controller, etc. That free software / open source
idea really does work
Ok understand. Matt’s expertise is the key then, patching and fixing as needed.
And contributing the fixes back.
Otherwise you’d be dependent on the originators, which as I’m sure you’ve found they
can sometimes be less than reliable or in the worst case no longer “findable”.
Same as with pretty much anything. That’s why the code’s there.
What about the Microblaze clone… would Xilinx have any issue with that?
Shouldn’t be any problem regardless of where we’re running it.
It’s a clean-room implementation that executes the same instruction set.
Eric
Eric-
25#M825 By the way, take into account that if you use a makefile to
makefile which is annoying (and potentially dangerous)
that the quality of code there is highly variable. Matt’s fixed the
parts we care about, or found people to fix them. This includes a GbE
MAC, wishbone compatible microblaze knock off (currently running at
50 MHz in a Spartan 3), lots of simple periperals such as I2C, SPI,
UART, interrupt controller, etc. That free software / open source
idea really does work 
Ok understand. Matt’s expertise is the key then, patching and fixing as
needed.
Otherwise you’d be dependent on the originators, which as I’m sure
you’ve found they
can sometimes be less than reliable or in the worst case no longer
“findable”. What
about the Microblaze clone… would Xilinx have any issue with that? I
would hope
not since it’s their chips being used.
-Jeff