discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] ISE Project navigator and ISE files


From: Jeff Brower
Subject: Re: [Discuss-gnuradio] ISE Project navigator and ISE files
Date: Thu, 17 Jan 2008 12:35:59 -0600

Eric-

> On Thu, Jan 17, 2008 at 11:55:42AM -0600, Jeff Brower wrote:
> > Eric-
> >
> > > On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O'Connor wrote:
> > > > On Wed, 16 Jan 2008, Ignacio wrote:
> > > > > 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=8
> > > > >25#M825 By the way, take into account that if you use a makefile to
> > > >
> > > > Interesting!
> > > > 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?
> 
> 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 ;)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]