Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
whatisofdm wrote: > I'm a digital ASIC engineer looking for some *beginner* > (not reference/advanced!) books on Orthogonal Frequency > Division Multiplexing (OFDM.) Well, hopefully such a book exists? > > The book I already have "Multi-carrier Digital Communications: > Theory and Applications of OFDM" (by Bahai, Saltzberg, and > Ergen) seems a bit beyond me. It's a great reference > for researchers, but as you've probably guessed, it's difficult > for math-challenged engineers like myself to put that into > practice. Van Nee and Prasad "OFDM for Wireless Multimedia Communcations" ISBN 0-89006-530-6 Good luck, DaveArticle: 88026
Dear
I need some help on ChipScope Pro.
I implemented simple processing element(PE) and directly connected the
PE with BRAM (RAMB16_S36). Job of this PE is
- to read 4 numbers 3,4,1,2 (each stored in address
0000,0001,0002,0003, respectively) from BRAM.
- sort them.
- store 1 ->2 ->3 ->4 in BRAM (each stored in address
000A,000B,000C,000D)
Both of the functional (Modelsim) and the post-synthesis timing
simulation (Modelsim,XST,ISE6.3i) are okay. Problem is to verify the
design after downloading into the device (V2pro).
Problem is that
In Analyzer, the wavefrom is always "0100", which is the last sorted
number. I am trying possible configuration but I could not see the
waveform "1->2->3->4. I think this is possibly because of the improper
setting in ILA and Analyzer.
If someone helps me with this troubleshooting, it will be appreciated.
Thankyou in advance. Regards.
The configuration for the (ILA,ICON,VIO) core generation is the
following.
------------------------------
* ICON
- 2 control ports
* ILA
- 2 input trigger ports
- Trig0 : 2 bit wide, 1 match unit, basic w/edge type
- Trig1 : 16 bit wide, 1 match unit, basic type
- 4 bit wide data
* VIO
- 1 bit wide asynchronous input
- 7 bit wide asynchronous ouput
* Analyzer
- Match function M0 == R1 , M1 == 000A
- Trigger condition == M0 and M1
- Windows and position=0
------------------------------
------------------------------------------------------------
library ieee;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
library UNISIM;
use UNISIM.vcomponents.all;
-- Top Entity
entity PE_MEM_Direct is
port( clk : in std_logic;
sorted : out std_logic );
end PE_MEM_Direct;
architecture TB_ARCHITECTURE of PE_MEM_Direct is
-------------------------------------------------------------------
-- User Design : Processing element component declaration
-------------------------------------------------------------------
component PE
port(
en: in std_logic; -- PE enable
clock: in std_logic;
reset: in std_logic;
Din: in std_logic_vector(31 downto 0); -- Data input
ce: out std_logic; -- Memory chip enable
r: out std_logic; -- 'read' memory
w: out std_logic; -- 'write' memory
addr: out std_logic_vector(15 downto 0); -- Address
Dout: out std_logic_vector(31 downto 0); -- Data out
sorted: out std_logic );
end component;
signal T_enPE,T_reset,T_ce,T_r,T_w,T_sorted: std_logic;
signal T_dinPE,T_dout: std_logic_vector(31 downto 0);
signal T_addrPE: std_logic_vector(15 downto 0);
-------------------------------------------------------------------
-- BRAM : component declaration
-------------------------------------------------------------------
component RAMB16_S36
generic (
INIT_00 : BIT_VECTOR
:=X"0000000000000002000000010000000000000000000000000000000400000003"
);
port (
DO: out STD_LOGIC_VECTOR (31 downto 0);
DOP: out STD_LOGIC_VECTOR (3 downto 0);
ADDR: in STD_LOGIC_VECTOR (8 downto 0);
CLK: in STD_ULOGIC;
DI: in STD_LOGIC_VECTOR (31 downto 0);
DIP: in STD_LOGIC_VECTOR (3 downto 0);
EN: in STD_ULOGIC;
SSR: in STD_ULOGIC;
WE: in STD_ULOGIC);
end component;
signal T_we,T_enMem,T_ssr: std_logic;
signal T_addrMem: std_logic_vector(8 downto 0);
signal T_dinMem,T_DO: std_logic_vector(31 downto 0);
signal T_dip,T_dop: std_logic_vector(3 downto 0);
-------------------------------------------------------------------
-- ICON core component declaration
-------------------------------------------------------------------
component icon
port
( control0 : out std_logic_vector(35 downto 0);
control1 : out std_logic_vector(35 downto 0) );
end component;
------------------------------------------------------------------
-- ICON core signal declarations
-------------------------------------------------------------------
signal control0 : std_logic_vector(35 downto 0);
signal control1 : std_logic_vector(35 downto 0);
-------------------------------------------------------------------
-- ILA core component declaration
-------------------------------------------------------------------
component ila
port
( control : in std_logic_vector(35 downto 0);
clk : in std_logic;
data : in std_logic_vector(3 downto 0);
trig0 : in std_logic_vector(1 downto 0);
trig1 : in std_logic_vector(15 downto 0) );
end component;
-------------------------------------------------------------------
-- ILA core signal declarations
------------------------------------------------------------------
signal data : std_logic_vector(3 downto 0);
signal trig0 : std_logic_vector(1 downto 0);
signal trig1 : std_logic_vector(15 downto 0);
-------------------------------------------------------------------
-- VIO core component declaration
-------------------------------------------------------------------
component vio
port
( control : in std_logic_vector(35 downto 0);
async_in : in std_logic_vector(0 downto 0);
async_out : out std_logic_vector(6 downto 0) );
end component;
-------------------------------------------------------------------
-- VIO core signal declarations
-------------------------------------------------------------------
signal async_in : std_logic_vector(0 downto 0);
signal async_out : std_logic_vector(6 downto 0);
begin
-------------------------------------------------------------------
-- User Design and BRAM instantiation
-------------------------------------------------------------------
UUT : PE port map
(T_enPE, clk, T_reset, T_dinPE, T_ce, T_r, T_w, T_addrPE, T_dout,
T_sorted);
R1 : RAMB16_S36 port map
(T_DO, T_dop, T_addrMem, clk, T_dinMem, T_dip, T_enMem, T_ssr, T_we);
-------------------------------------------------------------------
-- Interface logic between PE and BRAM
-------------------------------------------------------------------
sorted <= T_sorted; -- connection between memory and processor
T_dinPE <= T_DO;
T_enMem <= T_ce;
T_addrMem <= T_addrPE(8 downto 0);
T_dinMem <= T_dout;
process(T_ce,T_r,T_w)
begin
if T_ce='1' and T_w='1' and T_r='0' then
T_we <= '1';
else T_we <='0';
end if;
end process;
-------------------------------------------------------------------
-- ICON core instance
-------------------------------------------------------------------
i_icon : icon
port map
( control0 => control0,
control1 => control1 );
-------------------------------------------------------------------
-- ILA core instance
-------------------------------------------------------------------
-- Trigger signals
trig0(0) <= T_ce; -- Memory chip enable
trig0(1) <= T_w; -- Write
-- Address bus (16 bit)
trig1(0) <= T_addrPE(0);
trig1(1) <= T_addrPE(1);
trig1(2) <= T_addrPE(2);
trig1(3) <= T_addrPE(3);
trig1(4) <= T_addrPE(4);
trig1(5) <= T_addrPE(5);
trig1(6) <= T_addrPE(6);
trig1(7) <= T_addrPE(7);
trig1(8) <= T_addrPE(8);
trig1(9) <= T_addrPE(9);
trig1(10) <= T_addrPE(10);
trig1(11) <= T_addrPE(11);
trig1(12) <= T_addrPE(12);
trig1(13) <= T_addrPE(13);
trig1(14) <= T_addrPE(14);
trig1(15) <= T_addrPE(15);
-- Data capture
data(0) <= T_dout(0);
data(1) <= T_dout(1);
data(2) <= T_dout(2);
data(3) <= T_dout(3);
i_ila : ila
port map
( control => control0,
clk => clk,
data => data,
trig0 => trig0,
trig1 => trig1 );
-------------------------------------------------------------------
-- VIO core instance
-------------------------------------------------------------------
-- 7 outputs for VIO :
process(async_out)
begin
T_enPE <= async_out(0);
T_reset <= async_out(1);
T_ssr <= async_out(2);
T_dip(0) <= async_out(3);
T_dip(1) <= async_out(4);
T_dip(2) <= async_out(5);
T_dip(3) <= async_out(6);
end process;
-- This is the way I drive the internal signal
async_out(0) <= '1'; -- 'en'
async_out(1) <= '0'; -- 'reset'
async_out(2) <= '0'; -- 'ssr'
async_out(3) <= '1'; -- 'dip(0)'
async_out(4) <= '1'; -- 'dip(1)'
async_out(5) <= '1'; -- 'dip(2)'
async_out(6) <= '1'; -- 'dip(3)'
---- 1 Input for VIO
async_in(0) <= T_dout(0);
i_vio : vio
port map
( control => control1,
async_in => async_in,
async_out => async_out );
end TB_ARCHITECTURE;
Article: 88027Jon Beniston wrote: > I'm struggling to see that, when it appears you can use the design > without distributing the source. > > Cheers, > Jon > I get it: "Who are Lattice?" "Lattice? Oh they released that free 8bit IP core" "Oh you mean free like the PPC402 and Pico/MicroBlaze IPs..." "No, the Lattice core is vendor independent...." "Oh..... Danish?" "No, just a cookie, I'm watching my diet"Article: 88028
On Fri, 05 Aug 2005 00:12:48 -0700, usenet_10 wrote:
> You mean the ones with de devision bug inside?
>
And the F00F bug
--
"Electricity is of two kinds, positive and negative. The difference
is, I presume, that one comes a little more expensive, but is more
durable; the other is a cheaper thing, but the moths get into it."
(Stephen Leacock)
Article: 88029On Thu, 04 Aug 2005 13:25:29 GMT, "Genome" <ilike_spam@yahoo.co.uk> wrote: > ><jjlindula@hotmail.com> wrote in message >news:1123088364.723402.137130@g47g2000cwa.googlegroups.com... >> What? >> > > >..... > >Go ride a bike. Turn a corner. > >Now start thinking about/analysing what you are doing. Turn a corner. > >DNA > Good way to get killed. JohnArticle: 88030
Genome wrote: > <jjlindula@hotmail.com> wrote in message > news:1123088364.723402.137130@g47g2000cwa.googlegroups.com... > >>What? >> > > > > ..... > > Go ride a bike. Turn a corner. > > Now start thinking about/analysing what you are doing. Turn a corner. The centipede was happy (quite!) Until the toad for spite Asked, "Pray; which leg comes after which?" That threw his soul in such a pitch He lay distracted in a ditch, Considering how to run. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 88031
>I've been named "system architect" on more than one project, and I've >always been profoundly grateful to the folks that have caught out my >errors. I always let folks know this, too -- and not just the folks >finding my errors, but their managers as well. At worst the equation >goes like this: I do something stupid, you notice and don't say >anything; we both look bad. Alternately: I do something stupid, you >point it out, we both fix it; we both look good. Praise the messenger! Make sure the rest of the group hears the praise, not just his manager. >The best thing about this attitude is that it is one of the areas where, >with the right PR, ethical behavior and selfish behavior march hand in >hand. When I can say "Ralph found an error in my system design, I did >some analysis and found out that my integrator wasn't nearly deep enough >for the modified filter" then the project wins because an error has been >fixed, Ralph wins because he's gotten credit for finding a problem, I >win because I found a solution, _and_ I win because an embarrassing >problem with my design was found at an early stage instead of in front >of some Major in procurement who really wanted to buy the competitor's >product instead. Many years (10?) ago, my boss handed me a paper titled "Bugs are Good" by Doug Clark. Scribbled on it was "must read". I haven't been able to find it online, but it's easy to find references to it. (We were all working for DEC/Digital at the time.) The main theme, at least as I remember it, is that you should praise the people who find bugs. It take a group-culture approach to understand the logic. Finding bugs today is better than having them find you tomorrow. The other half is that you want other people to check your work. They have a different point of view. They won't make the same errors/blunders that you made. (hopefully) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 88032
I am trying to develop the LANs which need to implement the hareware layer, can anybody tell me where and how can i get it?Article: 88033
i'm designing a board with a Xilinx XC4VFX12-11SF363C and DDR2 memory components following the design used in Virtex-4 ML461 Memory Interfaces Development Board User Guide [ug079].pdf as a general guideline the question i have is regarding the signal termination for the bidirectional signals the guide recommends FPGA Driver Termination at FPGA Termination at Memory SSTL18_II 50 ohms pull up to 0.9V 50 ohms pull up to 0.9V but one could also use FPGA Driver Termination at FPGA Termination at Memory DIFF_SSTL_II_18_DCI No termination 50 ohms pull up to 0.9V so i can save placing the required pull up resistors near the fpga but if the memory components are close to the fpga can i safely remove the memory component pull up resistors? thanks enzo ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =----Article: 88034
Jerry Avins wrote:
Reprise:
The centipede was happy (quite!) until the toad in fun
Asked, "Pray; which leg comes after which?"
That threw his soul in such a pitch
He lay distracted in a ditch,
Considering how to run.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Article: 88035Enzo, You need to run a signal integrity simulation to answer your question. AustinArticle: 88036
Jeremy Stringer wrote: > Jim Thompson wrote: >> On Thu, 4 Aug 2005 07:59:08 -0400, "Clay S. Turner" >> <Physics@Bellsouth.net> wrote: >> Yes, But certainly not the one who made P4's slower than P3's, for >> numerical operations. > > Isn't that clock for clock? My understanding was that they had to make > architectural changes in order to be able to run the things at a higher > frequency.. > > JEremy Either that, or Intel employed more of the cheap workforce, relied heavily on automated tools and procedures and used less of the expensive brains. AdrianArticle: 88037
Enzo - DDR2 SDRAMs have something called on-die termination, or ODT. Each DQ and DQS line has a Thevenin terminator that can be enabled during writes; if the DIMM has two ranks of SDRAMs, you'll have two lines. You'll need a timing signal(s) to enable/disable ODT, but you should be able to dispense with discrete terminations at the DIMM. Of course, it always pays to simulate. Bob Perlman Cambrian Design Works On Sun, 7 Aug 2005 07:34:16 -0400, "Enzo Guerra" <talon@pathcom.com> wrote: >i'm designing a board with a Xilinx XC4VFX12-11SF363C and DDR2 memory >components >following the design used in Virtex-4 ML461 Memory Interfaces Development >Board User Guide [ug079].pdf as a general guideline >the question i have is regarding the signal termination for the >bidirectional signals >the guide recommends >FPGA Driver Termination at FPGA Termination at Memory > >SSTL18_II 50 ohms pull up to 0.9V 50 ohms pull up >to 0.9V > >but one could also use > >FPGA Driver Termination at FPGA >Termination at Memory > >DIFF_SSTL_II_18_DCI No termination 50 ohms >pull up to 0.9V > >so i can save placing the required pull up resistors near the fpga > >but if the memory components are close to the fpga > >can i safely remove the memory component pull up resistors? > >thanks > >enzo > > > >----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- >http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups >----= East and West-Coast Server Farms - Total Privacy via Encryption =----Article: 88038
Jerry Avins wrote: > Jerry Avins wrote: > > Reprise: > > The centipede was happy (quite!) until the toad in fun > Asked, "Pray; which leg comes after which?" > That threw his soul in such a pitch > He lay distracted in a ditch, > Considering how to run. > > Jerry Is that Kipling or other? Just 'know' I've seen it before.Article: 88039
On 3 Aug 2005 07:47:42 -0700, jjlindula@hotmail.com wrote: >Hello, I couldn't find a single newsgroup to post my question, but I >needed a good group of people to post my question to. So let me >apologize if you don't think should be in your newsgroup. My question >is regarding the value (or importance) of System Engineering practices >in the R/D World. I work for the government and there are about 40 >people in my branch. We do a lot of R/D projects as well as projects >for the testing groups. I would like to know from people in the R/D >world how important do you feel System Engineering practices are on >your job? Many of my co-workers say, "oh that's for really big >programs, we don't do that hear". Do you agree? Some believe System >engineering only pertains to the integration of the pieces of the >design. To me that is only part of SE, there's so much more. Without >being long winded, can those who work in the R/D world, could you >please give your opinions of SE in your workplace? Is it important or a >waste of time? What practices do you feel are necessary? Is SE only for >the production people? I appreciate any responses and hope I don't >offend anyone for posting my question. My intention is to gain enough >information to convince my coworkers to use some of the SE practices >I've read about. > >thanks, >joe Just curious: did you also post your original query to the misc.business.product-dev newsgroup? JohnArticle: 88040
Richard Owlett wrote: > Jerry Avins wrote: > >> Jerry Avins wrote: >> >> Reprise: >> >> The centipede was happy (quite!) until the toad in fun >> Asked, "Pray; which leg comes after which?" >> That threw his soul in such a pitch >> He lay distracted in a ditch, >> Considering how to run. >> >> Jerry > > > Is that Kipling or other? Just 'know' I've seen it before. Out of my dim past. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 88041
Can anybody please tell me where can I find the documentation on the list of functions included in the Small version of NIOS C library (newlib)? Altera's documentation really not helping me. Thanks.Article: 88042
Hi, In the error update path of an adaptive filter I am implementing a power of two multiplier; I am converting the full binary error to the next higher magnitude power of two which then gets encoded to a sign and shift count. So the multiplication is a barrel shift and a sign change if necessary. So far this has a trivial verilog implementation but both the RTL and the gate level output reads as if there can be some interesting optimizations. I am currently using a special code to represent errors of exactly zero and a mux after the shifter to generate multiplication by zero. Anyone has done a similar update path or multiplier? Any ideas, tricks which I can use to reduce the critical path/area ? Thanks.Article: 88043
if you or your friend have design experience about USB2.0 OTG and 10G Ethernet,plz contact us: fopisarr@hotmail.com i have project cooperateArticle: 88044
Alfred Arnold has kindly added support for the new Lattice Mico8 OpenSource soft CPU, http://www.latticesemi.com/products/devtools/ip/refdesigns/mico8.cfm to his OpenSource AS assembler. Download bin & source from http://john.ccac.rwth-aachen.de:8000/as/download.html AS is a multi-target macro assembler, non linking, ideal for small uC targets. AS also supports the PicoBlaze, which is quite similar [in 18 bit opcode variant] to the 18 bit opcode Mico8. Extensions: AS supports INC Rn, and DEC Rn , which map onto addi Rn,1 etc AS allows and Rn,Rm and also and Rn,0x33, (same as PicoBlaze) in addition to the mico8 separate immediate mnemonic. andi Rn,0x33 -jgArticle: 88045
hi, i m doing project on image processing.For that i need to store pixel value of any frame in memory. I read from one journal that there is one circular read address generator which is used to generate physical address from logical address this help to reduce the size of memory. I have to store 30*32 pixel in memory.NOW for that i have to generate physical address for those memory location.THey suggest circular read address generator for this. But i never read about circular read address generato.So please anybody tell me about this generator. Is it possible to reduce memory size using this method.Article: 88046
Hello. I'm new to Spartan-3, before I only worked on the legacy XC6216 FPGA. I am trying to port a university project over to a modern FPGA platform. I assume that the full details of the Spartan-3 bitstream are not published beyond what is described in XApp452 (XC6216 bitstream was fully published). Also I assume that it is possible to damage the FPGA using invalid bitstreams (as opposed to the XC6216). I want to generate a placed & routed design using my own custom algorithms and then upload it to the Spartan-3, without resorting to PAR tools and such. At what point would I have to enter the workflow? Convert my design to NCD files? (Most likely, the NCD format is closed as well?) Thank you, TobiasArticle: 88047
Hello,
I'd like to bring to your attention FOUR important items:
FPGA 2006:
1) NEW - Online Submission is now open (http://www.isfpga.org)
2) REMINDER - FPGA 2006 Call for Papers (Sept 23)
Upcoming "Special Issue on FPGA" journal submissions:
3) REMINDER - J. of Microprocessors and Microsystems (Sept 15)
4) NEW - EURASIP J. on Embedded Systems (Dec 15)
More details for items 2,3 and 4 are provided below.
Enjoy!
Prof. Guy Lemieux
University of British Columbia
Vancouver, Canada
---------------------------------------------------------------------------
FPGA 2006: Call for Papers
Fourteenth ACM/SIGDA International Symposium
on Field-Programmable Gate Arrays
Hyatt Regency Hotel
Monterey, California
February 22-24, 2006
The ACM/SIGDA International Symposium on Field-Programmable Gate Arrays
is the premier conference for presentation of advances in all areas
related
to FPGA technology. For FPGA 2006, we are soliciting submissions
describing
novel research and developments in the following (and related) areas of
interest:
FPGA Architecture: Novel logic block and routing architectures,
combination of FPGA fabric and system blocks (processors, memories,
etc.), new commercial architectures, impact of modern and future
technologies (including ultra-deep submicron and nanometer scale)
on the design of FPGA's (e.g. soft errors, leakage, power density,
fabrication defects).
Circuit Design for FPGAs: Novel FPGA circuits and circuit-level
techniques.
CAD for FPGAs: Placement, routing, retiming, logic optimization,
technology mapping, system-level partitioning, logic generators,
testing
and verification, CAD for FPGA-based accelerators, CAD for
incremental
FPGA design and on-line design mapping and optimization.
High-level abstractions, tools, and systems for FPGAs:
General-purpose
and domain-specific models, languages, tools, and techniques that
facilitate the design, development, debugging, verification, and
deployment of large-scale and high-performance FPGA-based
applications
and systems.
FPGA-based and FPGA-like computing engines: Compiled accelerators,
reconfigurable computing, adaptive computing devices, systems and
software.
Rapid-prototyping: Fast prototyping for system-level design and logic
emulation.
Applications: Innovative use of FPGAs, exploitation of FPGA features
and
architectures, uses of FPGAs to achieve high-performance, low-power,
or
high-reliability, FPGA-optimized DSP techniques, novel uses of
reconfiguration, FPGA-based cores.
Authors are invited to submit English language PDF of their paper (10
pages maximum) and panel proposals by September 23, 2005. Notification
of acceptance will be sent by November 21, 2004. The authors of
accepted
papers will be required to submit the final camera-ready copy by
December 19, 2004. A proceedings of the accepted papers will be
published
by ACM, and included in the Annual ACM/SIGDA CD-ROM Compendium
publication.
Address questions to:
Andre' DeHon, Program Chair FPGA 2006
Dept. of CS, 256-80, CALTECH
Pasadena, CA 91125
Phone : (626) 395-6569
Email : andre@cs.caltech.edu
Organizing Committee
General Chair: Steve Wilton, University of British Columbia
Program Chair: Andre' DeHon, California Institute of Technology
Finance Chair: Herman Schmit, Tabula
Publicity Chair: Guy Lemieux, University of British Columbia
---------------------------------------------------------------------------
Call for Papers
Special Issue on FPGA-based Reconfigurable Computing
Journal of Microprocessors and Microsystems
Overview:
Recent advances in Field Programmable Gate Arrays (FPGAs) make
reconfigurable
computing possible that the boundary between hardware and software is
blurred.
Some of the computation extensive code can be shifted directly to
hardware
either through on-line and off-line mapping. Performance will be
greatly
enhanced especially in systems such as scientific computing, multimedia
applications, computer security, etc.
The purpose of this special issue is to provide a unique scientific
opportunity for researchers, engineers, vendors, and designers to
report
recent advances in this important area of reconfigurable computing and
applications using FPGAs. Topics include, but not limited to, the
following:
FPGA Technologies
" FPGA architectures
" New algorithms for space reduction
" Placement and routing techniques
" Partial Reconfiguration
" Reconfigurable computing
" Evolvable Hardware
" FPGA Nanotechnology
High Performance Computing using FPGAs
" Scientific computing
" Image processing
" Software testing and debugging
" Just-in-time compilation
" System-on-chip Solutions
" Power-aware design
" Arithmetic computation
" Tools
" Networking
" Security
Submissions will be evaluated on Novelty, Generality, Significance,
Clarity
and Support criteria. We invite the submission of full length papers to
this
special issue that will details the state-of-the-art technology and
trends
in FPGAs and reconfigurable computing.
Important Dates:
" Paper submission deadline: Sep. 15, 2005
" Notification of the first review: Oct. 30, 2005.
" Revisions due: Nov. 30, 2005.
" Final notice of acceptance: Dec. 15, 2005.
" Final version manuscripts due: Jan. 15, 2006.
" Special issue to appear: Early 2006.
Instructions to the authors:
http://www.ece.iastate.edu/~morris/cfp_fpga.doc
Guest Editors
J. Morris Chang
Department of Electrical & Computer Eng.
Iowa State University, Ames, Iowa, U.S.A.
morris@iastate.edu www.ece.iastate.edu/~morris
Chia-Tien Dan Lo
Department of Computer Science
University of Texas at San Antonio
San Antonio, Texas, U.S.A.
danlo@ieee.org www.cs.utsa.edu/~danlo
---------------------------------------------------------------------------
EURASIP Journal on Embedded Systems
Special Issue on
Field-Programmable Gate Arrays in Embedded Systems
Call for Papers
Field-Programmable Gate Arrays (FPGAs) are increasingly used
in embedded systems to achieve high performance in a compact
area. FPGAs are particularly well suited to processing data
straight from sensors in embedded systems. More importantly,
the reconfigurable aspects of FPGAs give the circuits the
versatility to change their functionality based on processing
requirements for different phases of an application, and for
deploying new functionality.
Modern FPGAs integrate many different resources on a single chip.
Embedded processors (both hard and soft cores), multipliers, RAM
blocks, and DSP units are all available along with reconfigurable
logic. Applications can use these heterogeneous resources to
integrate
several different functions on a single piece of silicon. This makes
FPGAs particularly well suited to embedded applications.
This special issue focuses on applications that clearly show the
benefit
of using FPGAs in embedded applications, as well as on design tools
that
enable such applications. Specific topics of interest include the use
of reconfiguration in embedded applications, hardware/software
codesign
targeting FPGAs, power-aware FPGA design, design environments for
FPGAs,
system signalling and protocols used by FPGAs in embedded
environments,
and system-level design targeting modern FPGA's heterogeneous
resources.
Papers on other applicable topics will also be considered. All papers
should address FPGA-based systems that are appropriate for embedded
applications. Papers on subjects outside of this scope (i.e., not
suitable for embedded applications) will not be considered.
Authors should follow the EURASIP JES' manuscript format
described at the journal's web site: http://www.hindawi.info/es/ .
Prospective authors should submit an electronic copy of their
complete manuscript through the EURASIP JES' manuscript
tracking system at the journal's web site, according to the
following timetable.
Manuscript Due December 15, 2005
Acceptance Notification May 1, 2006
Final Manuscript Due August 1, 2006
Publication Date 4th Quarter, 2006
GUEST EDITORS:
Miriam Leeser, Northeastern University, USA; mel@coe.neu.edu
Scott Hauck, University of Washington, USA; hauck@ee.washington.edu
Russell Tessier, University of Massachusetts, Amherst, USA;
tessier@ecs.umass.edu
Article: 88048On Fri, 05 Aug 2005 03:30:30 GMT, "whatisofdm" <whatisofdm@nowhere.net> wrote: >I'm a digital ASIC engineer looking for some *beginner* >(not reference/advanced!) books on Orthogonal Frequency >Division Multiplexing (OFDM.) Well, hopefully such a book exists? > >The book I already have "Multi-carrier Digital Communications: >Theory and Applications of OFDM" (by Bahai, Saltzberg, and >Ergen) seems a bit beyond me. It's a great reference >for researchers, but as you've probably guessed, it's difficult >for math-challenged engineers like myself to put that into >practice. > Hi, what ever you do, avoid buying "OFDM Wireless LANs" by Heiskala & Terry. I have never, in 20 years, seen a book with more typographical errors and gross technical mistakes. After re-rereading the the "glowing" Amazon.com "reviews" for this book I now think 70%-90% of the reviews were written by one, or both, of the authors. I bought this crappy book and I wasted my money. Keep away from this book, or you'll be sorry. AxilArticle: 88049
Axil Frawley wrote: ... > After re-rereading the the "glowing" Amazon.com > "reviews" for this book I now think 70%-90% of the reviews > were written by one, or both, of > the authors. I bought this crappy book and I wasted my > money. > > Keep away from this book, or you'll be sorry. Axil, Have you written a review of your own? Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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