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 98100

Article: 98100
Subject: Hollybush1 - PC104+ Board
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sat, 4 Mar 2006 19:29:35 -0000
Links: << >>  << T >>  << A >>
Now on our website is our new PC104Plus board Hollybush1. Base board is 
Spartan-3 based but Virtex support is coming soon on an expansion module 
giving high speed serial and PowerPC support. You can use this board as a 
development board or as a OEM product. Details are here 
http://www.enterpoint.co.uk/moelbryn/hollybush1.html. We are taking this new 
board to DATE where you can see it in more details on stand F48 along with 
the other new products we have.

John Adair
Enterpoint Ltd. - Home of Hollybush1. The Flexible PC104+ Board.
http://www.enterpoint.co.uk



Article: 98101
Subject: Re: why use an FPGA when a CPLD will do ??
From: "Hendra" <u1000393@email.sjsu.edu>
Date: 4 Mar 2006 12:02:26 -0800
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Matt,
>
> If you use a a cpld, you need to post in comp.arch.cpld
> 
> Austin

There is no comp.arch.cpld

Hendra


Article: 98102
Subject: Re: EDK: choices for simple internal control
From: "MM" <mbmsv@yahoo.com>
Date: Sat, 4 Mar 2006 15:47:30 -0500
Links: << >>  << T >>  << A >>
"Duane Clark" <dclark@junkmail.com> wrote in message
news:ZMjOf.18743$2O6.14086@newssvr12.news.prodigy.com...
> For one project, the GPIO approach might be easiest. But it is a pain
> when every time a new signal is desired, the EDK portion has to be
> recompiled.
>
> What I did was to start with the GPIO core and then modify it to output
> signals for address, read data, write data, and read/write control. Then
> I have a register implementation as part of my ISE project, and that is
> the only place I need to make changes. A little extra work up front, but
> well worth it in my opinion.

It's an interesting idea, but isn't the DCR doing essentially the same
thing?

What I don't like about GPIO or DCR for that matter is that I can't for
example implement a self-clearing write-only bit... Well, on the other hand,
perhaps, it's a bad design practice...


/Mikhail





Article: 98103
Subject: Re: EDK: choices for simple internal control
From: Duane Clark <dclark@junkmail.com>
Date: Sat, 04 Mar 2006 23:33:44 GMT
Links: << >>  << T >>  << A >>
MM wrote:
> "Duane Clark" <dclark@junkmail.com> wrote in message
> news:ZMjOf.18743$2O6.14086@newssvr12.news.prodigy.com...
>> For one project, the GPIO approach might be easiest. But it is a pain
>> when every time a new signal is desired, the EDK portion has to be
>> recompiled.
>>
>> What I did was to start with the GPIO core and then modify it to output
>> signals for address, read data, write data, and read/write control. Then
>> I have a register implementation as part of my ISE project, and that is
>> the only place I need to make changes. A little extra work up front, but
>> well worth it in my opinion.
> 
> It's an interesting idea, but isn't the DCR doing essentially the same
> thing?
> 
> What I don't like about GPIO or DCR for that matter is that I can't for
> example implement a self-clearing write-only bit... Well, on the other hand,
> perhaps, it's a bad design practice...
> 

It is certainly very similar to the DCR interface. But a separate bus is 
not needed. I would think something like this for both the PLB and OPB 
buses would be simple and useful enough for others to be part of the EDK 
pcores.

I'm not sure what a write-only bit is ;) But the register method I use 
certainly allows all sorts of flexibility, and having a a bit be self 
clearing is easy to do this way. I am not sure where that would be 
difficult with the DCR bus, but then, I have not used the DCR bus.

Partly my going this direction is driven by the method I use for 
performing VHDL simulations. I don't bother with the complex BFM PPC 
models provided by Xilinx, and don't simulate the processor memory. 
Instead, I wrote a simple functional model of my own which correctly 
handles the basic read and write bus operations on the PLB bus. I do use 
the Xilinx supplied models for the PLB and OPB buses, arbiters, etc. It 
is accurate enough that the components always work in the real system, 
and is simple to use and simulates fast. In part, I ended up with a 
system like that because it is the way I handle all bus models (PCI, 
VME, etc). I have over time developed a style for this kind of thing 
that I am comfortable with, and so I stick with it.


Article: 98104
Subject: Re: why use an FPGA when a CPLD will do ??
From: Duane Clark <dclark@junkmail.com>
Date: Sat, 04 Mar 2006 23:36:51 GMT
Links: << >>  << T >>  << A >>
Hendra wrote:
> Austin Lesea wrote:
>> Matt,
>>
>> If you use a a cpld, you need to post in comp.arch.cpld
>>
>> Austin
> 
> There is no comp.arch.cpld
> 

I suspect he was being facetious, and just forgot the smiley ;)


Article: 98105
Subject: Re: why use an FPGA when a CPLD will do ??
From: austin <austin@xilinx.com>
Date: Sat, 04 Mar 2006 17:17:52 -0800
Links: << >>  << T >>  << A >>
Duane,

Yes, I apologize for my sarcasm.

I had just read the posting concerning newsgroups, and how to get the 
best answers from them.  This post was a classic example of someone who 
had not even had the foresight to do any research on their own.

Given that everyone who posts here has access to google (or any other 
search engine), it is generally annoying to see questions that could be 
answered by three minutes of browsing and reading.

Sarcasm is the weapon of the weak, and I should have been more civil,

Austin

Duane Clark wrote:

> Hendra wrote:
> 
>> Austin Lesea wrote:
>>
>>> Matt,
>>>
>>> If you use a a cpld, you need to post in comp.arch.cpld
>>>
>>> Austin
>>
>>
>> There is no comp.arch.cpld
>>
> 
> I suspect he was being facetious, and just forgot the smiley ;)
> 

Article: 98106
Subject: Re: How do I make dual-port RAM from single port RAM?
From: sharp@cadence.com
Date: 4 Mar 2006 17:43:34 -0800
Links: << >>  << T >>  << A >>
When you wrote PortA address 17, you wrote into address 17 of RAM0 and
RAM1. You also wrote 0 (meaning A is valid) into address 17 of
VALID_BIT.  When you read PortB address 17, you read address 17 of RAM1
and RAM3.  You also read address 17 of VALID_BIT, which gives you back
0, telling you to select the output of RAM1.  This gives you the value
you just wrote to RAM1 when you wrote to PortA address 17.

If you had written to address 17 via PortB last, then address 17 of
VALID_BIT would have been set to 1, telling you to select the output of
RAM3 instead.  This would have been correct, since a write to portB
would have written to RAM2 and RAM3.  If you read portA address 17, you
will read address 17 of RAM0 and RAM2 instead, and selected between
those based on VALID_BIT.

Or perhaps what you are missing is that each of these RAMs has a read
port and a write port, which can be used simultaneously with
independent addresses.  This was one of the components that was
described as being available.  So PortB can be reading address 17 of
RAM1 at the same time PortA is writing address 22 of RAM1.


Article: 98107
Subject: Re: How do I make dual-port RAM from single port RAM?
From: sharp@cadence.com
Date: 4 Mar 2006 17:58:11 -0800
Links: << >>  << T >>  << A >>
Another clever solution.  This requires the same amount of RAM as Ulf's
scheme, but without requiring the 2Rd/2Wr VALID_BIT array.  However, it
may require a longer write cycle time, to allow completing the
associated read and XOR with enough setup time for the write.  But part
of the write can overlap the read, so it should still be faster than
the time-multiplexing approaches.


Article: 98108
Subject: Re: How do I make dual-port RAM from single port RAM?
From: John_H <johnhandwork@mail.com>
Date: Sun, 05 Mar 2006 02:55:34 GMT
Links: << >>  << T >>  << A >>
sharp@cadence.com wrote:
> Another clever solution.  This requires the same amount of RAM as Ulf's
> scheme, but without requiring the 2Rd/2Wr VALID_BIT array.  However, it
> may require a longer write cycle time, to allow completing the
> associated read and XOR with enough setup time for the write.  But part
> of the write can overlap the read, so it should still be faster than
> the time-multiplexing approaches.

What I did forget is that the memory may be synchronous read and write. 
  If the read is asynchronous then this method still works but youre 
comment on timing is well taken.  In the FPGA there's a nice, small 
setup time for memory address and data.  An asynchronous read would 
require the address access time before that XOR.  If the translation is 
from FPGA to ASIC, there may be enough margin in the timing to specify 
the read access and XOR from the address and the XOR alone from the data 
before the write strobe.

If the ASIC memory is synchronous read without the async data, this 
method would require more RAMs and some feedback to account for 
just-written addresses.

Is the memory 1Wr/2Rd memory primitive an asynchronous read?

Article: 98109
Subject: Re: why use an FPGA when a CPLD will do ??
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Sun, 5 Mar 2006 19:40:34 +1300
Links: << >>  << T >>  << A >>
but sarcasm is so much better than a pointy stick.

Simon

"austin" <austin@xilinx.com> wrote in message
news:dude5h$ar25@xco-news.xilinx.com...
> Duane,
>
> Yes, I apologize for my sarcasm.
>
> I had just read the posting concerning newsgroups, and how to get the
> best answers from them.  This post was a classic example of someone who
> had not even had the foresight to do any research on their own.
>
> Given that everyone who posts here has access to google (or any other
> search engine), it is generally annoying to see questions that could be
> answered by three minutes of browsing and reading.
>
> Sarcasm is the weapon of the weak, and I should have been more civil,
>
> Austin
>
> Duane Clark wrote:
>
> > Hendra wrote:
> >
> >> Austin Lesea wrote:
> >>
> >>> Matt,
> >>>
> >>> If you use a a cpld, you need to post in comp.arch.cpld
> >>>
> >>> Austin
> >>
> >>
> >> There is no comp.arch.cpld
> >>
> >
> > I suspect he was being facetious, and just forgot the smiley ;)
> >



Article: 98110
Subject: FpgaC Beta-2 release on sourceforge.net today
From: fpga_toys@yahoo.com
Date: 5 Mar 2006 02:19:34 -0500
Links: << >>  << T >>  << A >>
http://sourceforge.net/projects/fpgac

svn co https://svn.sourceforge.net/svnroot/fpgac/tags/fpgac.1.0.beta-2
 fpgac.1.0.beta-2


CHANGES FROM FpgaC 1.0-beta to 1.0-beta-2F

- A new html users manual has been updated for this release by John
Bass.

- Major changes to variable creation and naming have occured to
implement declaration scoping more properly. Variable names can now be
reused per Std C scoping rules. If you find problems, please bug
report.

- FOR loops and DO while loops have been added as alpha test by Rahul
Menon please report any suprises.

- Integer Multiply, Divide, and Mod/Remainder function interfaces have
been added as alpha test for this release by John Bass. See users
manual for details.

- Preliminary intrinsic stubs for Floating point are now in the
compiler.

- Small LUT/BRAM based arrays and structures have been added as alpha
test for this release by John Bass. See users manual for details.

- A new concurrent process type has been added for testing. Functions
declared with the type of fpgac_process will be started at load, and
will loop implictly. See users manual for details.

- Changes to support building on MS Windows Platforms by Isaac
Pentinmaki

- FpgaC specific keywords have been prefixed with fpgac_ to prevent
naming conflicts. This was applied to all the #pragma names from the
previous release.

- new example code, including prototype work toward a PCI Target mode
core.


Article: 98111
Subject: Re: Virtex-4FX MiniModule Atmel Flash
From: "Marco T." <marc@blabla.com>
Date: Sun, 5 Mar 2006 08:44:00 +0100
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message 
news:ducf74$2d9$1@online.de...
> "Marco T." <marc@blabla.com> schrieb im Newsbeitrag 
> news:dubove$q2j$1@nnrp.ngi.it...
>>
>> "Antti Lukats" <antti@openchip.org> wrote in message 
>> news:dubnbo$irm$1@online.de...
>>> "Marco T." <marc@blabla.com> schrieb im Newsbeitrag 
>>> news:dubn68$pcc$1@nnrp.ngi.it...
>>>>
>>>> "Antti Lukats" <antti@openchip.org> wrote in message 
>>>> news:dubmqm$hct$1@online.de...
>>>>> "Marco T." <marc@blabla.com> schrieb im Newsbeitrag 
>>>>> news:dubggf$n6a$1@nnrp.ngi.it...
>>>>>>
>>>>>> "Antti" <Antti.Lukats@xilant.com> wrote in message 
>>>>>> news:1141400003.663570.191020@i40g2000cwc.googlegroups.com...
>>>>>>> yes
>>>>>>>
>>>>>>
>>>>>> May I use the "configuration memory port" on the baseboard to write 
>>>>>> into atmel memory?
>>>>>>
>>>>> if that port has access to the atmel memory then yes?
>>>>>
>>>>> but why are you asking it, doesnt the memec board come with 
>>>>> documentation !?
>>>>>
>>>>> Antti
>>>>>
>>>>
>>>> no documentation about it...
>>>>
>>>> Only one example that stores code into bram... not so useful.
>>>>
>>>
>>> but they usually have some examples how to flash the serial rom at least 
>>> other memec boards have some docu, are you sure that there is nothing 
>>> relevant at memec online RDC ? did you look at all docs and examples at 
>>> RDC ??
>>>
>>> Antti
>>>
>>
>>
>> There are two examples: the first that implements a webserver; the second 
>> is a demo that send datas to the serial connetor, tests the ddr, 
>> read/write datas into flash.
>> But software is stored into bram and there is no documentation about 
>> storing software into flash.
>>
>
> Dear Marco,
>
> c.a.f. is not memec-avnet support.
>
> memec uses Xilinx XAPP800 based solution for the FPGA config in several 
> boards, I assume also in the case of the mini module. For V4 board that I 
> have there is memec docu and script how to program the seiral flash over 
> SPI port using X_SPI, I assume something similar exists for the mini 
> module also
>
> as the minimodule has parallel flash so it is logical that memec guys 
> think that everyone uses parallel flash to store software applications, in 
> that case it is possible to use the flash_writer.tcl - it is very 
> unfriendly path but it works sometimes.
>
> if you want to use dataflash then just append your sw application code 
> after the config bitstream and thats it. in your soc you need to implement 
> spi bootloader what is about 30-40 lines of C code and can be written 
> within a few hours. Too bad that memec hasnt provided a demo with that 40 
> lines, bad luck, you need to write them yourself. Of course you can use 
> some existing code but that may take more time than rewriting from 
> scratch.
>
> http://xilant.com/content/view/38/2/
>
> there is a similar module where spi flash is used as config and sw storage 
> (linux image) i had absolutly no problems impementing the bootloader, well 
> actually the load process is 2 step, first a pre-boot loader (in BRAM) is 
> loading u-boot, then u-boot is taking aver to provide a more felxible 
> bootloader
>
> u-boot source code includes some dataflash support, for my case I had to 
> add the ST25 SPI support myself
>
> Antti
>

I know  c.a.f. is not memec support and I'm sorry to have posted here.
I have tried to contact reference design center through email, but I don't 
have receive any answer.

So I thought to post into c.a.f. to know if someone has my trouble and in 
which way has solved it.

I appreciate very much your help.

I will try as you told.

Many Thanks again.
Marco 



Article: 98112
Subject: Question for the EDK ppc users ...
From: me_2003@walla.co.il
Date: 5 Mar 2006 01:00:48 -0800
Links: << >>  << T >>  << A >>
Hi all, my question is as follows,
I am now going through a ppc design that I would like to run as follows
:
I need to use a internal BRAM for boot sequence and a NAND FLASH to
contain all the code. the code will be placed and run on external SRAM.
My question are as follows:
1) what should I choose as internal BRAM IF OCM or PLB_CTLR ?
2) Are there any better ways to design such a system ?
Thanks in advance, Mordehay?


Article: 98113
Subject: Which CPU and Screen Rez for ISE 6.3i ?
From: "Hendra" <u1000393@email.sjsu.edu>
Date: 5 Mar 2006 01:24:06 -0800
Links: << >>  << T >>  << A >>
I own a notebook 700 MHz PIII / 256 MB / 10.4" / 1024*768. I am
thinking of upgrading because ISE 6.3i runs very slooooowwwww with this
notebook. Not to mention that at 1024*768, nothing much that I can see
on the screen. I need higher resolution and faster CPU.
1. What screen resolution is the ideal one for ISE?
2. Which screen resolution that you usually use at work?
3. What is the ideal CPU speed and RAM if I limited my self to an FPGA
less than 1.5 M gates with little constraint in the design.
 
Hendra


Article: 98114
Subject: Par error in Spartan-3
From: kent.mou@gmail.com
Date: 5 Mar 2006 07:01:56 -0800
Links: << >>  << T >>  << A >>
I met problem while doing place for Spartan-3 in ISE 7.1 .They said.
  Number of BUFGMUXs                  2 out of 8      25%
   Number of External IOBs            31 out of 221    14%
      Number of LOCed IOBs             0 out of 31      0%

   Number of Slices                 9643 out of 13312  72%
      Number of SLICEMs               52 out of 6656    1%
  WARNING:Place:119 - Unable to find location.  SLICEL component
   ins_rsa_core_combine/U_reg[768] not placed.
......
......
.....
   0,256   ins_rsa_core_combine/U_reg[1024]
ERROR:Place:120 - There were not enough sites to place all selected
components

I used large width register and adder in this design, the reg will map
into FF with the SLICES? And I can see SLICEM only used 52. If the
silces is not enough, why the tools did not use SLICEM?

kent


Article: 98115
Subject: Re: Par error in Spartan-3
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 5 Mar 2006 16:11:42 -0000
Links: << >>  << T >>  << A >>
Kent

I'm guessing you have a core here that is done for something like a 
Virtex-2. The SLICEM and SLICEL are something new in Spartan-3 where only 1 
out of 2 slices can support a memory type use for LUTs in that slice. In an 
older Virtex2 all slices can support the memory function. So if you have a 
core that is a RPM or has equivalent constraints you may be trying to place 
a memory element where there is none and hence your error message. If it is 
constraints you can remove the LOC statement that causes the issue. 
Otherwise you are going to have to dig into the design with FPGA Editor and 
can edit the LOCs.

John Adair
Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan3 Development Board.
http://www.enterpoint.co.uk

<kent.mou@gmail.com> wrote in message 
news:1141570916.501126.110560@i39g2000cwa.googlegroups.com...
>I met problem while doing place for Spartan-3 in ISE 7.1 .They said.
>  Number of BUFGMUXs                  2 out of 8      25%
>   Number of External IOBs            31 out of 221    14%
>      Number of LOCed IOBs             0 out of 31      0%
>
>   Number of Slices                 9643 out of 13312  72%
>      Number of SLICEMs               52 out of 6656    1%
>  WARNING:Place:119 - Unable to find location.  SLICEL component
>   ins_rsa_core_combine/U_reg[768] not placed.
> ......
> ......
> .....
>   0,256   ins_rsa_core_combine/U_reg[1024]
> ERROR:Place:120 - There were not enough sites to place all selected
> components
>
> I used large width register and adder in this design, the reg will map
> into FF with the SLICES? And I can see SLICEM only used 52. If the
> silces is not enough, why the tools did not use SLICEM?
>
> kent
> 



Article: 98116
Subject: Re: DMA and PCI in SoPC Builder
From: brendan.rankin@gmail.com
Date: 5 Mar 2006 11:04:22 -0800
Links: << >>  << T >>  << A >>
Martin,

The PCI Compiler does not provide a way to handle interrupts in
Avalon/SOPC Builder.  Your options are to instantiate a small Nios II
core, design your own IRQ management master.....or wait for the next
release of the PCI Compiler core, which should certainly address this.

- Brendan


Article: 98117
Subject: Re: Simple ADS5273 -> Xilinx Interconnect Model
From: "Brian Davis" <brimdavis@aol.com>
Date: 5 Mar 2006 11:50:37 -0800
Links: << >>  << T >>  << A >>
austin wrote:
>
> I am sorry that you feel compelled to post on this subject compulsively.
>
 The only compulsive behavior demonstrated here is your
continuing, insulting, and unwarranted attacks on me when
I suggest a simple method to make your parts work better.

 You've had over five years to produce some sort of V2 app note
on how to deal with high speed drivers, but haven't; instead, you
flame up my posts when I point out problems and workarounds.

>
> I am sorry to see that you discredit yourself in public by posting a
> spice fantasy.
>
 Better a SPICE fantasy than an IBIS nightmare.

 I wouldn't trust any results until confirming them in the
lab on actual hardware, which I stated quite clearly in
those simple simulation models.

 Regardless of the exact accuracy of the simulation, the
advantages of adding extra attenuation (when the drive
strength is available) should be clear with either method
of simulation.

 For SI work, IBIS is basically a faster SPICE with blinders on.
It has merits in certain situations, like automatic SI verification
of a massive autorouted line card, but I prefer to start in SPICE,
verify in the lab by prototyping, then use those results to guide
and cross-check any post-layout IBIS simulations.

>
>I am sorry I took your posting seriously enough to do a
> real simulation and show that there is no problem
>
 You didn't show us anything!

 You just made a lot of noise, insulted me yet again,
and once again lacked the backbone to back up, with data,
your ridiculous claims that there's nothing wrong with having
a Cin of 10 pf (single ended) when dealing with sub-200 ps
input edge rates from a fast driver.

>
> I am sorry that I have been unable to resolve this issue with you in a
> mutually positive way.
>
 Making parts with better Cpin would resolve things quite nicely.

Brian


Article: 98118
Subject: Re: why use an FPGA when a CPLD will do ??
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 06 Mar 2006 11:06:06 +1300
Links: << >>  << T >>  << A >>
Matt Clement wrote:
> Hey guys/gals
> 
> What are the advantages and disadvantages of using a CPLD instead of using 
> an FPGA for a design?

  The answer to the heading is "You wouldn't" - if 'a CPLD will do',
in engineering terms means meet/exceed the price performance levels of a 
FPGA.

  The more general answer, of when to choose FPGA or CPLD, changes over 
time.
  10 years ago, CPLDs were cheap, non volatile logic, but most had High 
Iccs. FPGAs were all SRAM based, and had low Static Iccs.

  Now, the distinction is much more blurred :
# There are FPGAs with on Chip FLASH, [Lattice, Actel]
# FPGA static Icc is no longer low, but can hit hundreds of mA (!)
#  Newest CPLDs from Altera, Lattice have FPGA fabric, but CPLD-like 
FLASH - but at the same time, they have moved up the 'smallest device' 
point, so there are no real low cost members in this family.
# Lowest power devices are now the CMOS structure ones from Xilinx,
   Lattice, Atmel.
# Above a certain Logic size, FPGAs tend to self-select over the
  thinning ranks of large CPLDs

  In many cases, designs have BOTH CPLD and FPGA, and the CPLD can
be used to Boot the FPGA, via cheaper memory, and/or to control
power off, to have deeper sleep modes.

-jg


Article: 98119
Subject: Re: PCI configuration for ML310
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 06 Mar 2006 09:25:41 +1000
Links: << >>  << T >>  << A >>
Hi Isaac,

igelado@gmail.com wrote:
> No, I did not, because the misc_logic is written in Verilog and I have
> no idea about Verilog, so I "ported" that piece of code to VHDL. The
> code in Verilog is as follows:
> 
> always @(posedge clk)
>  pci_int_or <= (~pci_inta) | (~pci_intb) |  (~pci_intc)  |  (~pci_intd)
> | (~pci_inte) | (~pci_intf) | (~pci_core_intr_a) | (sbr_int);
> 
> Which I wrote in VHDL as:
> process(clk)
>  if(clk'event and clk='1') then
>   pci_merge <= pci_sbr or not pci_inta or not pci_intb or not pci_inc
> or not pci_ind or not pci_inte or not pci_intf ot not pci_core_intr_a;
>  end if;
> end process;

I'm not much of a verilog guy either, but your translation looks ok to me.

> I think both codes are doing the same, aren't they? However, the base
> configuration from Xilinix is using a really old opb2pci bridge (if I
> try using it I get an error because it is deprecated) and I'm using the
> latest one. Both cores have the same interrupt lines, but I do not know
> if they are compatible.
> 
> My first guess was that maybe in the current core the pci_int<a> lines
> are active in high, so instead of merging the signals inverting the
> pci_int<a> and making a logical or I didn't invert them. Unfortunately
> the result was the same :(.  Right now I am merging all the signals as
> shown on the previous VHDL code but not using pci_inte, pci_intf
> pci_core_intr_a, which I think there are not used by my hardware
> configuration. With this schema only the PCI-IDE controller is getting
> interrupts.

I'm not sure what's going on here.  Looking back to your first post on
this topic, you mentioned that in Xilinx's design there were multiple
interrupt signals connected:

"Looking at the system.vhd I see that the SBR pin is connected to the
interrupt 0, lines PCI<n>_INT are connected to interrupts 1 to 6, and
the IP2INTC line is connected to interrupt 12. The problem is that I
don't know which line is actually used to deliver the interrupts coming
from the PCI devices. I've tried using all of them, but all attempts
were failed."

This contradicts the idea of merged interrupts that we've discussed
subsequently.  Maybe there's a clue in there somewhere?

Sorry I can't be more help, this stuff is fiddly and probably won't work
at all until you get it exactly right.  ChipScope might help, to at
least see what's going on inside with the various interrupt signals etc.

Also, the time-honoured tradition of peppering your kernel with printk()
calls should not be overlooked.  Sometimes that's easier than trying to
debug/single step the thing, particularly where interrupts are involved.
 The "Understanding the Linux kernel" book, and also "Linux Device
Drivers" will give you pointers on where in the source you should be
looking.

Regards,

John

Article: 98120
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: "Frank" <frank.invalid@hotmail.com>
Date: Mon, 6 Mar 2006 10:02:09 +0800
Links: << >>  << T >>  << A >>

"Love Singhal" <lovesinghal@gmail.com> wrote in message
news:1141379383.985179.15670@i40g2000cwc.googlegroups.com...
> Hi Frank,
> >From what I have read in the documents (I have not implemented the
> complete flow yet), the support for partial reconfiguration has indeed
> evolved in Virtex 4.
> First, the Planahead tool handles modular based flow better than just
> the floorplanner in the previous modular based flow.
> Second, the Virtex 4 has fixed size frames (16 clbs) based partial
> reconfiguration rather than a column based partial reconfiguration.
> This basically means that there can be multiple frames in one column of
> any Virtex 4 device. Thus, the whole column does not have to be
> reconfigured all at once. This could reduce a lot of complexity for
> interconnects that connects one side of reconfigurable region to
> another side (they do not have to be routed using long wires only, for
> example).
> I think designs with partial reconfiguration could be implemented
> better in Virtex 4 than in Virtex 2, but as I said, I have not yet
> implemented the complete flow.
>
> Love Singhal
> http://www.ics.uci.edu/~lsinghal
>

Frame based partial reconfiguration is really neat. Next time I will
definitely
try them out, but is the software available in Webpack 8?




Article: 98121
Subject: Re: EDK: choices for simple internal control
From: "MM" <mbmsv@yahoo.com>
Date: Sun, 5 Mar 2006 21:45:55 -0500
Links: << >>  << T >>  << A >>
Duane,

"Duane Clark" <dclark@junkmail.com> wrote in message
news:stpOf.27023$_S7.14217@newssvr14.news.prodigy.com...
>
> I'm not sure what a write-only bit is ;) But the register method I use
> certainly allows all sorts of flexibility, and having a a bit be self
> clearing is easy to do this way.

A write-only bit can be something as simple as this (please ignore syntax
errors if any :)):

process ()
begin
    if rising_edge(clk) then
        wr_only_bit <= bus_address_match and write_en else;
    end;
end process;

If it needs to cross the clock domains it can be resynchronized to another
clock.

You got me confused. You said you started with the GPIO core and you are
saying that you can do self-clearing bits with it somehow. Could you please
elaborate a little bit?

> Partly my going this direction is driven by the method I use for
> performing VHDL simulations. I don't bother with the complex BFM PPC
> models provided by Xilinx, and don't simulate the processor memory.
> Instead, I wrote a simple functional model of my own which correctly
> handles the basic read and write bus operations on the PLB bus. I do use
> the Xilinx supplied models for the PLB and OPB buses, arbiters, etc. It
> is accurate enough that the components always work in the real system,
> and is simple to use and simulates fast. In part, I ended up with a
> system like that because it is the way I handle all bus models (PCI,
> VME, etc). I have over time developed a style for this kind of thing
> that I am comfortable with, and so I stick with it.

I've been using a similar approach when simulating local bus of a PCI
controller in my previous designs... However, I am again a little confused
about what exactly you are doing. On one hand you are saying that you wrote
a simple model of your own that handles basic PLB read/write operations. On
the other hand you are saying that you are using Xilinx supplied bus
models... I guess I am missing something, perhaps because I haven't looked
at the Xilinx models yet... But I would appreciate if you could explain what
you are doing in a little more detail...

Thanks,
/Mikhail





Article: 98122
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: Steve Lass <lass@xilinx.com>
Date: Sun, 05 Mar 2006 21:10:26 -0700
Links: << >>  << T >>  << A >>
I am responsible for the partial reconfiguration software.  Let me try 
to answer all of the questions posted:

Q: Does the released ISE software support partial reconfiguration?
A: In some cases, yes.

Q: Does anyone have a commercial product that successfully employed 
partial reconfig?
A: Yes, there are a few.

Q: Why did Xilinx say partial reconfig worked when most of the time, it 
doesn't?
A: We released software for partial reconfig about 4 years ago.  At that 
time, there was a flow that worked if you did everything in the right 
way.  There were a couple of people in my group that were assigned to 
help customers through the mine field.  It was rare that our sales force 
told us about customers using partial reconfig, so we assumed that 
nobody was using it.  Because of other priorities, and the apparent lack 
of interest, the partial reconfig software languished.

Q: Is there a killer app that will drive Xilinx to put the effort needed 
to make partial reconfig a workable flow?
A: Yes.  There are software defined radio applications that are 
lucrative enough to get our attention.

Q: Does Xilinx now have software that works for partial reconfig?
A: Yes.  We have a team that has modified the current software, created 
a new flow, and tested the software with different applications.  In 
addition, PlanAhead makes it much easier to lay out your design and run 
DRCs to ensure that partial reconfig will work.

Q: How do I get this software?
A: Contact your local FAE.  If you're at a university, contact the 
university program.  Our Xilinx Labs research department is supporting 
the universities.

Q: Why don't you release the software with ISE?
A: The plan is to release it with ISE in version 9.1i.  For now, we have 
an efficient team assigned to refine the flows and fix bugs as soon as 
they are found.

Q: Is frame reconfiguration really cool?
A: Yes.  However, Virtex2 and Virtex2-Pro together with our new software 
let you do what could be considered a partial frame write.  Even though 
you are writing the entire frame (column), Virtex devices don't glitch 
when you write exactly the same config bits.  This allows you to have 
static logic above or below a reconfig region.  We reconfigure the 
static region, but it continues to work.  This also allows us to have 
static routes that pass through a reconfig region.  The software 
reserves these routes when routing the reconfig region.

Q: The software license fees are $3k - $5k.  How can we use this for 
reconfigurable computing?
A; I'm not sure where these prices came from.  If you are creating a 
reconfigurable computer, contact me and we can discuss an OEM deal for 
much less money.

Q: Should I feel comfortable adding partial reconfig to my current 
application?
A: Personally, I would wait a couple of months.  We are currently 
rolling out the software to our SDR customers and will be spending our 
effort supporting them.  In addition, many of the FAEs have not been 
trained on the new partial reconfig flow.  And they are the first line 
of support.

Steve


Article: 98123
Subject: Re: can I port ppclinux to virtex4-fx?
From: "wicky" <wicky.zhang@gmail.com>
Date: 5 Mar 2006 21:02:41 -0800
Links: << >>  << T >>  << A >>
oh, I see. it seems that you only use the convenient building process
of uClinux and in fact the source code is based on ppclinux dist. am I
right? 

thank you!

wicky


Article: 98124
Subject: Re: can I port ppclinux to virtex4-fx?
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 6 Mar 2006 07:40:35 +0100
Links: << >>  << T >>  << A >>
"wicky" <wicky.zhang@gmail.com> schrieb im Newsbeitrag 
news:1141621361.704629.39410@j52g2000cwj.googlegroups.com...
> oh, I see. it seems that you only use the convenient building process
> of uClinux and in fact the source code is based on ppclinux dist. am I
> right?
>
> thank you!
>
> wicky
>
exactly!
100%

its just simplicity that counts
build run and it works!

antti 





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