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 91650

Article: 91650
Subject: Re: fpga speed logic/density MIPS/FLOPS as compared to general purpose microprocessors
From: "Stephen Craven" <scraven@vt.edu>
Date: 10 Nov 2005 09:32:37 -0800
Links: << >>  << T >>  << A >>
I know that Keith Underwood of Sandia National Labs has compared the FP
performance of FPGAs to GPPs and projected this into the future.

http://portal.acm.org/citation.cfm?id=968305

Stephen


Article: 91651
Subject: Re: Can't pack into OLOGIC
From: fastgreen2000@yahoo.com
Date: 10 Nov 2005 09:50:39 -0800
Links: << >>  << T >>  << A >>

john wrote:

> It is for a bidirectionnal signal: input is registered into IOB, output is also registered there, but the duplicated tristate_enable registers don't want to go inside the OLOGIC (Virtex 4). Each of them is not that far, but not into the IOB!
>

- Make sure the tristate 'registers' are duplicated, not the output of
the tristate register.
- Make sure the duplicated registers have proper attribute so the
synthesis tool doesn't optimize them into a single register.


Article: 91652
Subject: Re: Can't pack into OLOGIC
From: fastgreen2000@yahoo.com
Date: 10 Nov 2005 09:52:42 -0800
Links: << >>  << T >>  << A >>
You may have already done what I mentioned.  One more
- make sure the tristate registers feed nothing else outside of the
IOB.

You might want to post your code if it still doesn't do it...


Article: 91653
Subject: Re: fpga speed logic/density MIPS/FLOPS as compared to general purpose
From: "g.wall" <wallge@eng.fsu.edu>
Date: Thu, 10 Nov 2005 12:54:04 -0500
Links: << >>  << T >>  << A >>
Stephen Craven wrote:
> I know that Keith Underwood of Sandia National Labs has compared the FP
> performance of FPGAs to GPPs and projected this into the future.
> 
> http://portal.acm.org/citation.cfm?id=968305
> 
> Stephen
> 

I have several papers by Mr Underwood and will probably cite
him in my work. These are excellent sources for floating
point comparison and very helpful to that end. I was hoping
that someone might know of a similar resource that compared
other aspects of FPGA based designs to microprocessors.


thanks

Article: 91654
Subject: Re: Can't pack into OLOGIC
From: john <john.wo.71@gmail.com>
Date: Thu, 10 Nov 2005 10:00:26 -0800
Links: << >>  << T >>  << A >>
the

Article: 91655
Subject: Re: Can't pack into OLOGIC
From: john <john.wo.71@gmail.com>
Date: Thu, 10 Nov 2005 10:04:41 -0800
Links: << >>  << T >>  << A >>
I don't have any error: I just checked with fpga_editor that I am not using both FF inside the OLOGIC.

This results in a poor timing because the routing adds to the iobuf timing

Article: 91656
Subject: Re: Can't pack into OLOGIC
From: john <john.wo.71@gmail.com>
Date: Thu, 10 Nov 2005 10:11:17 -0800
Links: << >>  << T >>  << A >>
thanks for help.

I respect these three conditions. (I checked with fpgaeditor)

code is (removed reset as in teXclusive on xilinx website):



iob_t:process(CLK) begin if rising_edge(CLK) then DATA_REG(i) <= DATA(i); tristate_enable_reg(i) <= tristate_enable_reg(i); end if; end process;

well maybe I'll consider opening a webcase!

Article: 91657
Subject: Re: fpga speed logic/density MIPS/FLOPS as compared to general purpose
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 10 Nov 2005 10:13:22 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Geoffrey,
> the most important aspect is the freedom in systems architecture
> offered by FPGAs. This allows you to use massive parallelism for higher
> performance, or serial processing for lower cost etc.
> If you look just at clock rate, FPGAs suffer a penalty imposed by the
> interconnect flexibility. You have to compensate for that by taking
> advantage of the architectural flexibility offered in FPGAs.
> And do not forget (dynamic) reconfigurability...
> Peter Alfke, Xilinx Applications
> 
For video processing the biggest impact that this flexibility has is on 
memory bandwidth.  I have watched attempts to use DSP chips for video 
processing, I have studied using them, and I have been involved to 
varying degrees with a number of successful video processing designs 
using FPGAs.

In all cases the FPGA won the design primarily because you can make the 
memory as wide as you need, and can often play tricks like having 
multiple memory buses feeding the processing.  When you have a 
processing algorithm that requires more than one frame buffer, or a 
frame buffer and coefficient memory operating simultaneously, a DSP with 
one memory interface just can't cut it.  By the time you pile enough 
DSPs on a board to equal the performance of an FPGA solution you're 
burning holes in the carpet with the power dissipation.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 91658
Subject: Re: Bus for Spartan3
From: "Antonio Pasini" <removethis_pasini.a@tin.it>
Date: Thu, 10 Nov 2005 19:13:36 +0100
Links: << >>  << T >>  << A >>
"Marco" <marco@marylon.com> ha scritto nel messaggio 
news:1131461408.810685.93980@g14g2000cwa.googlegroups.com...
> How could I implement a bus in my Spartan3 to let it communicate
> thorough a 16bit wide, 100MHz bus with a Blackfin DSP? Thanks, Marco

Perhaps you can borrow some ideas from the Analog Devices own FPGA (Spartan 
3) extension board for the Blackfin.

http://www.analog.com/en/epHSProd/0,,BF-EXTENDERFPG,00.html

I don't know how the FPGA talks to the chip, via PPI or with a complete bus 
interface.




Article: 91659
Subject: Re: Can't pack into OLOGIC
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 10 Nov 2005 10:20:58 -0800
Links: << >>  << T >>  << A >>
John,

tristate_enable_reg(i) <= tristate_enable_reg(i);  ??

Is that what you wanted?

Syms

"john" <john.wo.71@gmail.com> wrote in message 
news:ee91b0b.5@webx.sUN8CHnE...
> thanks for help.
>
> I respect these three conditions. (I checked with fpgaeditor)
>
> code is (removed reset as in teXclusive on xilinx website):
>
>
>
> iob_t:process(CLK) begin if rising_edge(CLK) then DATA_REG(i) <= DATA(i); 
> tristate_enable_reg(i) <= tristate_enable_reg(i); end if; end process;
>
> well maybe I'll consider opening a webcase! 



Article: 91660
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries, working toward a GNU (for hardware) paradigm
From: "jvdh" <johannes.vanderhorst@gmail.com>
Date: 10 Nov 2005 10:24:01 -0800
Links: << >>  << T >>  << A >>
I'm using the GRLIB/LEON processor from Gaisler research
(www.gaisler.com) which provides a fairly flexible/implementation
independent set of VHDL libraries to implement a 32bit SPARC compliant
processor.

The project appears popular with the European Space Agency, and LEON
based designs keep popping up all over... From satellite applications
to network routing.

The library is available under a dual license scheme where a GPLed
version is released, but a commercial license is also available.  This
allows/encourages academic research/playing around (which I confess i'm
doing), while also allowing developers to build their own (proprietary)
applications on the LEON base.  This model makes the whole project much
more sustainable than other after-hours hobby type projects.

But it  can be tricky applying the GPL to an HDL project, because
traditional concepts like source code and binary executables are
transferred to a domain with source, several intermediate netlist
formats, some of which can be regarded as source when you're wide
awake... And distribution of embedded systems is the other ill defined
part - most users don't care/know about the embedded configurable
logic, and they are unlikely to expand on a very application specific
design (as Eli stated above).  And what happens when you start
combining HDL code with presynthesised netlists?  I think a modified
(HDL) GPL would be required to accurately cover the issue, much as is
done by the GNU Free Documentation License.

In the meantime, if I have a nifty piece of HDL solving a problem, I'll
probably post it somewhere, and hope someone else finds a use for it...
 

johannes


Article: 91661
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries,
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Thu, 10 Nov 2005 18:35:40 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Thu, 10 Nov 2005 11:24:08 -0500) it happened Eli Hughes
<emh203@psu.edu> wrote in <dkvs78$s80$1@f04n12.cac.psu.edu>:

>I seriously doubt you see anything much bigger that the snippets on Open 
>Cores.  This is may be different in the educational community where open 
>source is much more widely used, but in industry very few would be 
>willing to give away what they spent zillions of man hours developing.
>
>One could make the argument that there should be a library for simple 
>constructs that would be common to all FPGA, ASIC platforms.  What you 
>would end with is the equivalent of a C library that only adds to 
>numbers. Not very useful for serious work.
Not completely correct, does not Altera has the 7400 TTL library?
Is not opencores doing this exactly?

>In the FPGA world, there are lots of places were you can buy working IP 
>cores that are fully documented and supported.  My boss isn't willing to 
>spend 4 times the cost of working 3rd party IP to debug an open source 
>version that isn't documented that well and has no support.
My experience with open source, as a WRITER of open source, is that 
bug are fixed and replies are within one or 2 days (by me).
Some people take weeks to reply-- if at all. YMMV.
Some send you a very complicated question you spend ages to figure out,
you reply, and then never hear anything....
Some commercial companies have the same pattern, for example Xilinx
representatives here.
THESE behave almost like it is a favor that you can buy a FPGA.
And on the other side of it, lots<<< of those 'commercial companies / IP'
you seem to like so much, grab open source code and use it in their product
WITHOUT mentioning or respecting GPL.
I even found one website that sold my GPL program, hehe I announced a new
feature, so did they, then I left it at the announcement :-) So they were
stuck.. I could do that.. Bad for a commercial company, not sure
they still are on the net.
Kiss DVD players grabbed code from the mplayer project, some Chinese company
actually ASKED me if they could use my code, I wanted to negotiate a price,
then they were going to use it anyways, I referred to the GPL, and
'clean room' BIOS designs, they let somebody else do the coding..... in that
company.. who did not use my source.. believe it? Its true, hard to argue.
So, and I have seen this happen in places I worked, websearch 'grab those
few lines of code'.
Natural thing.
At that time my boss had the decency to try to contact the guy and pay him
something.


>The problem in this model is the same problem with the open source 
>software community. While some of the products are nice, they are 
>plagued with *lots* of useless projects/libraries that take a week to 
>install, have poor documentation and no support.
Ever try to install and run an official MS library?
Most open source projects install without problems (on the right 
architecture).
You mean you do not want to think AT ALL?
;-)

> Why would I want to 
>spend my time on that.  Most forget that while open source stuff is free 
>, it may take 4 times the time to use.  This is only cheaper if your 
>time doesn't cost a whole lot.
Not correct, it does not 4 times the time to use, makes no sense.


>All this being said, I really like the open cores site.  I would use it 
>for hobby/side projects. As for serious commercial projects, I place 
>more trust in either my own or paid for IP that is tested and supported.

Sure, many times I wrote something because it was not there (in Linux).
that is how the 50+ applications I released under GPL came about.
If it EXISTED I would not have bothered writing it.

Sure a HDL library would be nice, if a university has that, maintains
that, then it will benefit everybody, save you money.
But if released under GPL-1 the rest of your HDL will likely have to be
under GPL too.
So, I have heard they are working on GPL-3 now..... do not know details.
Software patents should not exist.
And yes I admit to keeping HDL secret to protect others copying the design.
It is the last border, the last defense!
(... capitalism - communism... but maybe we need a synthesis, look at China).

But wait, somebody will invent the (startrek) replicator, and then what.



Article: 91662
Subject: Re: Can't pack into OLOGIC
From: john <john.wo.71@gmail.com>
Date: Thu, 10 Nov 2005 10:36:40 -0800
Links: << >>  << T >>  << A >>
sorry I mistyped!

obviously it is: tristate_enable_reg(i) <= tristate_enable(i);

Article: 91663
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries,
From: Eli Hughes <emh203@psu.edu>
Date: Thu, 10 Nov 2005 13:58:37 -0500
Links: << >>  << T >>  << A >>

> 
> Not completely correct, does not Altera has the 7400 TTL library?
> Is not opencores doing this exactly?

Yes, but having a TTL library is only useful for doing schematic in 
Altera's tools, not HDL.  Evening thinking in TTL when you have an HDL 
is counter-productive!

> My experience with open source, as a WRITER of open source, is that 
> bug are fixed and replies are within one or 2 days (by me).
> Some people take weeks to reply-- if at all. YMMV.
> Some send you a very complicated question you spend ages to figure out,
> you reply, and then never hear anything....
> Some commercial companies have the same pattern, for example Xilinx
> representatives here.
> THESE behave almost like it is a favor that you can buy a FPGA.
> And on the other side of it, lots<<< of those 'commercial companies / IP'
> you seem to like so much, grab open source code and use it in their product
> WITHOUT mentioning or respecting GPL.
> I even found one website that sold my GPL program, hehe I announced a new
> feature, so did they, then I left it at the announcement :-) So they were
> stuck.. I could do that.. Bad for a commercial company, not sure
> they still are on the net.
> Kiss DVD players grabbed code from the mplayer project, some Chinese company
> actually ASKED me if they could use my code, I wanted to negotiate a price,
> then they were going to use it anyways, I referred to the GPL, and
> 'clean room' BIOS designs, they let somebody else do the coding..... in that
> company.. who did not use my source.. believe it? Its true, hard to argue.
> So, and I have seen this happen in places I worked, websearch 'grab those
> few lines of code'.
> Natural thing.
> At that time my boss had the decency to try to contact the guy and pay him
> something.

I would agree mostly with this.  But, generally for any company that is 
worth a damn I have never had a problem with support.

> Ever try to install and run an official MS library?

Yes, double clikc on icon.  Wait a bit.  Start programming.  My 
experience with PC/GUI stuff is very limited though. I like to live in 
the hardware/micrcontroller world where I have control.  I do not wish 
to be encumbered by an operating system which will only get in my way!

> Most open source projects install without problems (on the right 
> architecture).
> You mean you do not want to think AT ALL?
> ;-)

Not when it comes to installing and using something.  My job is to make 
a product work, not chasing down 200 dependecies.  :-)

You are right though. This has improved.

I prefer not to think.  I like to "be still like broccolli".

> 
> 
>>Why would I want to 
>>spend my time on that.  Most forget that while open source stuff is free 
>>, it may take 4 times the time to use.  This is only cheaper if your 
>>time doesn't cost a whole lot.
> 
> Not correct, it does not 4 times the time to use, makes no sense.
> 

I should have said: "4x the time to get the same useful result".  This 
isn't always true, but when I pay for something I am paying for 
documentation.  When I have to reverse engineer something to get it to 
work right I am wasting my time. And when the docs are skimpy, I get 
angry. This is not true of all open-source software (I love the PHP 
project, I use php for my web scripts!) but most open source projects 
are not that organized.

> 
> 
>>All this being said, I really like the open cores site.  I would use it 
>>for hobby/side projects. As for serious commercial projects, I place 
>>more trust in either my own or paid for IP that is tested and supported.
> 
> 
> Sure, many times I wrote something because it was not there (in Linux).
> that is how the 50+ applications I released under GPL came about.
> If it EXISTED I would not have bothered writing it.
> 
> Sure a HDL library would be nice, if a university has that, maintains
> that, then it will benefit everybody, save you money.
> But if released under GPL-1 the rest of your HDL will likely have to be
> under GPL too.
> So, I have heard they are working on GPL-3 now..... do not know details.
> Software patents should not exist.
> And yes I admit to keeping HDL secret to protect others copying the design.
> It is the last border, the last defense!
> (... capitalism - communism... but maybe we need a synthesis, look at China).
> 
> But wait, somebody will invent the (startrek) replicator, and then what.
> 
> 

Boy, I wish the replicator existed!  Then I could go home. :-)


-ELi

Article: 91664
Subject: Re: Coolrunner output pins stuck at 0V
From: "Gabor" <gabor@alacron.com>
Date: 10 Nov 2005 11:32:36 -0800
Links: << >>  << T >>  << A >>
Since the output state after configuration is probably low for those
outputs stuck at ground, I would first make sure that you are indeed
supplying a clock to the part and that the pin you supply the clock
to is the same one used by the logic...

"when everything doesn't move, check the clock first..."

Just my 2 cents,

Gabor

jvdh wrote:
> Maybe someone can make a suggestion:
>
> I'm building a board with a Coolrunner XPLA3384 on it, however, my
> intitial (very very basic) test code is running into problems... The
> device is programmed and verified successfully, but all (configured)
> output pins remain at ground.
>
> Pins not configured as outputs a pulled up by the internal pullup
> resistors, just as when the device is in an erased state.  I'm using
> dedicated JTAG pins to configure the device
>
> I've checked the power and ground pins, all are looking good, same goes
> for short circuits between the pins and ground...
>
> I feel I'm missing something small - can anyone perhaps make a
> suggestion on where to look?
> 
> Thanks
> 
> johannes
> 
> http://students.sun.ac.za/~jvdh


Article: 91665
Subject: Signal timing problem
From: "motty" <tlassiter@rfmd.com>
Date: 10 Nov 2005 12:31:01 -0800
Links: << >>  << T >>  << A >>
I am having difficulty solving a timing problem using a Spartan 3
embedded platform.  We are using a MicroBlaze core with some user IP
modules and some Xilinx modules attached through the OPB bus.  One of
the IP modules is a 3-wire serial data interface.  We have to be able
to generate multiple protocols so this module handles all of that.  The
"data" line is bidirectional.  It is connected correctly to a
bidirectional buffer at the top level.  We write data to a "part" and
then can read that data back from the part.  The part sends back a bit
of data on the FPGA's "data_clock" rising edge.  The FPGA clocks that
data in on the falling edge of the "data_clock" signal.  All was
working fine unitl we placed an extension board on our platform.  This
effectively makes the external path from the "part" to the FPGA much
longer.  The readback does NOT work when using this board.  The FPGA
reads back data, but not the correct data.

There are test points on our platform that allow us to look at the
3-wire interface signals in between the part and the FPGA.  These
signals look fine (with respect to timing) when using the board that
works and the one that doesn't.  It seems that the critical delay is
happening in the FPGA.  It seems like the data going in to the pin is
not getting to the module IP logic before the critical clock edge
occurs.  Is there a way to tell the Xilinx tools (via UCF constraints)
to constrain that path to a certain time spec?

Another problem is that I have looked at the ngc file for the
EDK-produced wrapper for my module.  The correct three signals
("data_O", "data_I", and "data_T") are I/O pins on the module, but once
I dive down into the mapped implementation, the "data_I" is not longer
anywhere to be found!  I don't know where it goes, so I can't find a
net name or anything like that to constrain!  What is going on there?

Thanks....


Article: 91666
Subject: Re: Can't pack into OLOGIC
From: Joseph Samson <user@example.net>
Date: Thu, 10 Nov 2005 20:34:27 GMT
Links: << >>  << T >>  << A >>
john wrote:
> the

You might want to try:

attribute equivalent_register_removal of tristate_enable_reg: signal is 
"no";

---
Joe

Article: 91667
Subject: Re: Signal timing problem
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 10 Nov 2005 12:58:47 -0800
Links: << >>  << T >>  << A >>
motty wrote:
>  We write data to a "part" and
> then can read that data back from the part.  The part sends back a bit
> of data on the FPGA's "data_clock" rising edge.  The FPGA clocks that
> data in on the falling edge of the "data_clock" signal. 

    clk __--__--__--__--__--
   data ___----____----_
sample-____|___|___|___ wastes half of your setup time vs
sample+__|___|___|___

          -- Mike Treseler



Article: 91668
Subject: Is this even true???
From: "Subhasri krishnan" <subhasri.krishnan@gmail.com>
Date: 10 Nov 2005 13:27:59 -0800
Links: << >>  << T >>  << A >>
Hey all,
I am designing(trying to design) an sdram controller (for a PC133
module) to work as fast as it is possible and as I understand from the
datasheet, if I read faster than I need to refresh, then I can avoid
refresh altogether. i.e if the refresh period is 64ms and if i access
the data every, say, 20ms then I dont have to refresh. Please tell me
if this is true or if I am getting confused.
Thanks in Advance.


Article: 91669
Subject: Re: Signal timing problem
From: "motty" <tlassiter@rfmd.com>
Date: 10 Nov 2005 13:40:33 -0800
Links: << >>  << T >>  << A >>
Mike--

Seems you are telling me to sample the data on the rising edge.  This
is the same clock that the external part is seeing.  The external part
changes data on the rising edge.  I can't be sure that data is valid
then.  The part is spec'd to interface to a device that will sample on
the falling edge.  If I look at an o-scope of the data vs. clock
signal, the data becomes "valid" about halfways throught the positive
cycle of the the clock.  It is definitely valid on the falling edge of
that clock.  But that is external to the FPGA.  Those signals look
entirely different at the logic interface in the FPGA.  I need to
understand what is happening from the pin to the path inside.


Article: 91670
Subject: Re: Is this even true???
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 10 Nov 2005 14:01:31 -0800
Links: << >>  << T >>  << A >>
On 10 Nov 2005 13:27:59 -0800, "Subhasri krishnan"
<subhasri.krishnan@gmail.com> wrote:

>Hey all,
>I am designing(trying to design) an sdram controller (for a PC133
>module) to work as fast as it is possible and as I understand from the
>datasheet, if I read faster than I need to refresh, then I can avoid
>refresh altogether. i.e if the refresh period is 64ms and if i access
>the data every, say, 20ms then I dont have to refresh. Please tell me
>if this is true or if I am getting confused.
>Thanks in Advance.

If you accessed every row within each SDRAM at least once during the
refresh period, you would not have to refresh explicitly.  

If your access pattern is predictable and continuous, you could do
this, but it requires some careful thought.  In virtually all cases,
you'd need a mighty good reason to dispense with conventional refresh
cycles, which typically eat up only 2 to 3 percent of available memory
bandwidth.



Bob Perlman
Cambrian Design Works

Article: 91671
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries, working toward a GNU (for hardware) paradigm
From: air_bits@yahoo.com
Date: 10 Nov 2005 14:08:40 -0800
Links: << >>  << T >>  << A >>

g.wall wrote:
> has anyone in the dig. design and reconfig. computing community looked
> seriously at open source hardware design libraries, working toward a
> hardware paradigm similar to that in the open source software community?
> I am aware of the existence of opencores.org, but this seems like a
> small first step, of which many more could be taken toward improving the
> availability and ease of access and use of open source logic designs.
> does anyone have any thoughts or knowledge or any thing to say about
> an open source hardware paradigm?

One of the reasons behind starting the FpgaC project on sourceforge was
to
head in that direction, especially in terms of reconfigurable computing
at
a hobby level, and small business level as the normal commercial tools
are way out of sight, and everybody has a proprietary IP mindset.

For pure digital design, it's frequently pretty difficult to extract
meaningful
reusable IP, as many cores have such complex interfaces that it's
common
to have difficulty in fitting them into a completely difference
architecture.

For reconfigurable computing, there is a lot of common library code
that
becomes usable with C based varients, particulary in terms of dynamic
reconfiguration, interprocess (hardware threads) communication, and
even
high level device interfaces (drivers) that can be much more easily
reused
in various SoC and reconfigurable projects. Even basic OS services for
reconfigurable computing are in dire need at this point. And compilers
and
loader tools that can handle dynamic partitioning and loadable
segments.
Doing this with ISE and mainstream tools is painful at best.

John


Article: 91672
Subject: Re: Signal timing problem
From: Kunal Shenoy <kunal.shenoy@xilinx.com>
Date: Thu, 10 Nov 2005 14:33:32 -0800
Links: << >>  << T >>  << A >>
motty wrote:
> I am having difficulty solving a timing problem using a Spartan 3
> embedded platform.  We are using a MicroBlaze core with some user IP
> modules and some Xilinx modules attached through the OPB bus.  One of
> the IP modules is a 3-wire serial data interface.  We have to be able
> to generate multiple protocols so this module handles all of that.  The
> "data" line is bidirectional.  It is connected correctly to a
> bidirectional buffer at the top level.  We write data to a "part" and
> then can read that data back from the part.  The part sends back a bit
> of data on the FPGA's "data_clock" rising edge.  The FPGA clocks that
> data in on the falling edge of the "data_clock" signal.  All was
> working fine unitl we placed an extension board on our platform.  This
> effectively makes the external path from the "part" to the FPGA much
> longer.  The readback does NOT work when using this board.  The FPGA
> reads back data, but not the correct data.
> 
> There are test points on our platform that allow us to look at the
> 3-wire interface signals in between the part and the FPGA.  These
> signals look fine (with respect to timing) when using the board that
> works and the one that doesn't.  It seems that the critical delay is
> happening in the FPGA.  It seems like the data going in to the pin is
> not getting to the module IP logic before the critical clock edge
> occurs.  Is there a way to tell the Xilinx tools (via UCF constraints)
> to constrain that path to a certain time spec?
> 
> Another problem is that I have looked at the ngc file for the
> EDK-produced wrapper for my module.  The correct three signals
> ("data_O", "data_I", and "data_T") are I/O pins on the module, but once
> I dive down into the mapped implementation, the "data_I" is not longer
> anywhere to be found!  I don't know where it goes, so I can't find a
> net name or anything like that to constrain!  What is going on there?
> 
> Thanks....
> 

You can specify how early the data will arrive with respect to the 
active clock edge that will register it. This can be done in the UCF 
file using the OFFSET-IN-BEFORE constraint.

eg.
NET "<DataInputPin>" OFFSET = IN <X> ns BEFORE "<ClockPin>" HIGH/LOW;

The static timing analyzer will calculate the clock path and data path 
delays and ensure that
X - data_path_delay + clock_path_delay > setup_time_required.
Where X is from your constraint above.
If not timing for that path will fail.

As Mike said, I think you are better off using the the rising edge. 
Don't worry about the hold time, Xilinx devices are designed to have 
zero hold time.But, you will have problems if the clock delay is more 
than the data delay, but that is unlikely.

Kunal

Article: 91673
Subject: Re: fpga speed logic/density MIPS/FLOPS as compared to general purpose microprocessors
From: air_bits@yahoo.com
Date: 10 Nov 2005 14:38:54 -0800
Links: << >>  << T >>  << A >>
A number of the various papers fail to search out the best space time
tradeoffs. Mistakes like doing 64bit floating point multipliers the
hard
way in an fpga, or doing an FFT/IFFT as wide parallel which isn't
always the best space time tradeoff.

There are MANY other architectures that can be developed to optimize
the performance of a particular application to FPGA, beside brute force
implementation of wide RISC/CISC processor core elements here.
Frequently bit serial will yield a higher clocking rate (as it doesn't
need
a long carry chain), and doesn't need extra logic for partial sums or
carry lookahead, so it also delivers more functional units per part,
but
at the cost of latency which can frequently be hidden with the faster
clock rate and high function density per part. It can also remove
memory as a staging area for wide paralle functional units, and thus
remove a serialization imposed by the solutions architecture.

Bit serial operations using Xilinx LUT fifo's can be expensive in both
power and clock rate reductions, but that is not the only way to use
LUTs for bit serial memory. Consider using some greycode counters
and using the LUT's simply as 16x1 rams instead ... faster and less
dynamic power.

There are lots of ways to get unexpected performance from FPGAs,
but not by doing it the worst possible way.

Be creative. $30M US of FPGAs and memories can easily build a
1-10 Petaflop super computer that would smoke existing RISC/CISC
designs ... we just don't have good software tools and compilers to
run applications on these machines, or have developed enough
programming talent used to getting good/excellent performance
from these devices.

There are a few dozen better ideas about how to make FPGAs
as we know them today, into the processor chip of tomarrow,
but that is another discussion.

Consider distributed arithmetic made FPGA's popular for high
performance integer applications, and it's not even a basic type
available from any of the common compilers or HDL's. Consider
the space time performance of three variable floating point multiple
accumulate (MAC) algorithms using this approach for large matrix
operations.

Consider this approach for doing high end energy/force/weather
simulations using a traditional Red/Black interleave as you would
use for these applications under MPI. 3, 6, 9, 12 variable MAC's
are a piece of cake with distributed arithmetic, and highly space
time efficient. The core algorithms of many of these simulations
are little more than MAC's, frequently with constants, or near
constrants that seldom need to be changed.

Consider for many applications the dynamic range needed during
most of the simulation is very limited, allowing systems to be
built with FP on both ends of the run, and scaled integers in the
middle of the run, even simpifing the hardware and improving the
space time fit even more.

The big advantage to FPGAs is breaking the serialization that
memory creates in RISC/CISC architectures. Memoryless
computing using pipelined distributed arithmetic is the ultimate
speedup for many applications, including a lot of computer
vision and pattern recognition applications.

So read the papers carefully, and consider if there might not be
a better architecture to solve the problem. If so, take the numbers
and conclusions presented with a grain of salt.


Article: 91674
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 10 Nov 2005 14:48:40 -0800
Links: << >>  << T >>  << A >>
Another developer joined the FpgaC project today to cleanup some of
the yacc/lex design issues as a C compiler (like variable scope).

This, structures, unions, typing, and unsigned variables are on the
near
term list of things to fix in this compiler so it will take a cleaner
subset
of traditional C.

Longer term I would like to add direct support for bit serial
distributed
arithmetic to be able to support multiply, multiply-accumulate, divide
and mod (%) operations. Plus add direct support for threads by using
some compiler primatives that know about fork(), exec(), along with
library primatives for MPI and posix-threads so that parallelism would
remain expressed the same way in FPGA and RISC/CISC testing
environments.

Anybody else have pet ideas, suggestions, or wish-list items that
a C based HLL/HDL tool should handle?




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