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 51350

Article: 51350
Subject: Re: Generating a 4x Clock using DLLs with Spartan-II
From: rsg@payload.com (Robert S. Grimes)
Date: 11 Jan 2003 08:21:21 -0800
Links: << >>  << T >>  << A >>
Brian,

Thanks much!  Obviously, you were right, and all is fine.

But you know, I'm sure that I tried that, though with my memory... 
Anyway, when I first tried it, it seemed to make no difference.  It
comfused me, actually, as I didn't get any errors (either way) about
the INST names being undefined, like it would with NET directives. 
Anyway, whatever I did before, it wasn't right; thanks for putting me
back on the right track!!!

-Bob

Brian Drummond <brian@shapes.demon.co.uk> wrote in message news:<79102vsa24b5f5233hsm0bjj43uq8727ri@4ax.com>...
> On 10 Jan 2003 13:25:46 -0800, rsg@payload.com (Robert S. Grimes) wrote:
> 
> >I am trying to generate three clocks from my 25 MHz clock input.  I
> >want SysClock (25 MHz), SysClockX2 (50 MHz), and SysClockX4 (100 MHz)
> >in my XC2S200 Spartan-II design. 
>  
> >The problem is, I can't seem to figure out how to get the constraints
> >to work!  Here is my attempt:
> >
> >  NET "p_sysclock" LOC = "P185";	# GCLk3 input clock
> >  INST "sysclockdll2" LOC=DLL3;         # First DLL
>  
> >When I run these, PAR seems to totally ignore these constraints, and I
> >get the exact same errors!
> >
> >Help please!
> The error messages are a pretty good guide to what's wrong.
> 
> >PAR Errors
> >    p_sysclock of type GCLK IOB is placed at P185.
> This constraint worked.
> 
> >    clocksgenerator_hsclocksgenerator_sysclockdll2 of type DLL is
> >unplaced.
> 
> This constraint won't work because the name on the constraint 
> ("sysclockdll2") does not match the instance name
> ("clocksgenerator_hsclocksgenerator_sysclockdll2")
> 
> And so on.
> 
> Edit the constraints file to match the actual instance names.
> (Be aware that if you change the design hierarchy or the synthesis
> settings, the instance names subsequently generated might change again)
> 
> - Brian

Article: 51351
Subject: Partial reconfiguration
From: "Antonio Di Stefano" <NOSPAMragazzoionico@tin.it>
Date: Sat, 11 Jan 2003 16:44:24 GMT
Links: << >>  << T >>  << A >>
Hi all!
I heard that some Xilinx devices allow partial reconfiguration.
Exactly which family implement this feature?
It exist a way to partially reconfigure even the oldest parts?
Thanks

Antonio









Article: 51352
Subject: Re: Help for Generating Video Clock synchronous to Hsync of the Video..........
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 11 Jan 2003 19:18:01 +0100
Links: << >>  << T >>  << A >>
"arvind" <arvindstomar@india.com> schrieb im Newsbeitrag
news:56147fd4.0301110622.77a47d0@posting.google.com...
> Hi,
>    I want a 16mhz clock synchronous to Hsync of the video.I want my 16mhz
> clock should lock on the rising edge of the Hsync.
> I want a pixel clock for Xilinx Spartan 2 Fpga for Video frame
> storage Application.

If you need a pixel clock, frequency locked to Hsync, to drive a ADC to get
digital video data, you need a "real" PLL with a god VCO, maybe a VCXO.
The Virtex-II with its DCMs can do clock multiplication, similat to a PLL,
but AFAIk they cany lock to such low frequency inputs. Also, the generated
jitter is higher than  this of a good VCO.
Oversampling PLL design which uses just the 16 MHz clock (or maybe 32, 64 or
higher) will be AFAIK not so good, since the jitter will be too high.

--
MfG
Falk






Article: 51353
Subject: Re: typedef ram in Handel-C
From: "Steffan Westcott" <steffanDOTwestcott@ntlworld.com>
Date: Sat, 11 Jan 2003 18:36:57 -0000
Links: << >>  << T >>  << A >>
"astonish" <astonishs@yahoo.com> wrote in message
news:c27d8629.0301100248.47aa45be@posting.google.com...
> How can I define a RAM type, initialize it, and
> initialize more than one copy of such type?
>
> e.g.
> typedef rom unsigned 8 Tab[60];
>
> How to initialize above ram and how to use several instances?

You need to explicitly construct each RAM instance in your code. Each
instance has a distinct identifier (name). In the following example, they
are  instance1 and instance2.

In a header file "example.hch"

typedef ram unsigned 8 TABLE_TYPE[60];
TABLE_TYPE instance1;
TABLE_TYPE instance2;

In the corresponding source file "example.hcc"

#include "example.hch"
#define DEFINE_TABLE(NAME) TABLE_TYPE NAME = {0, 2, ...rest of data...}
DEFINE_TABLE(instance1);
DEFINE_TABLE(instance2);


The result is two RAMs instance1[] and instance2[] that are pre-initialised
with the same contents. Duplication of ROMs is done the same way, just
change the 'ram' specifier in the typedef statement to 'rom'.

Cheers,
Steffan



Article: 51354
Subject: Re: VLSI training and prospects?
From: ptkwt@shell1.aracnet.com (Phil Tomson)
Date: 11 Jan 2003 20:28:39 GMT
Links: << >>  << T >>  << A >>
In article <adb3971c.0301102328.66c090e1@posting.google.com>,
john jakson <johnjakson@yahoo.com> wrote:
>ptkwt@shell1.aracnet.com (Phil Tomson) wrote in message
>news:<avne1q01um3@enews1.newsguy.com>...

>> >- Do you think Asian vlsi engineers are going to be dumped completely or
>> >just partly as soon as they become too expensive compared to people in
>> >some other underdeveloped country?
>> >(http://www.eetimes.com/story/OEG20020627S0032)
>> 
>> Well, it's happening to US engineers right now.  In the global marketplace 
>> that (for better or worse) now exists if employers can find cheaper 
>> qaulified labor somewhere else they're going to do it.  If a wage 
>> differential exists and you're on the high-side then it's only a matter of 
>> time before your job is outsourced.  Think about it, manufacturing jobs 
>> were 'outsourced' (exported) from the US starting in the late 80's and 
>> into the 90's.  Now engineering jobs are being outsourced and with the 
>> internet it's much easier to move these jobs overseas than it was to move 
>> manufacturing jobs - we're just talking about moving bits over the 
>> internet as opposed to moving materials and factories; it's trivial to 
>> move engineering jobs to another locale. 
>> 
>> Since US engineers would have to be making something close to minimum wage 
>> in order to compete with their counterparts in India, China or Russia it's 
>> not likely that engineering will remain a viable profession going forward 
>> in the US since it's quite difficult to live on minimum wage here - and 
>> nobody wants to work for minimum wage in a job that takes the kind of 
>> training that vlsi engineering does.  
>> This is a catastrophic change for US engineers - most of us don't have a 
>> fall-back position and it's not likely that we'll be able to migrate to 
>> places where one can survive on these lower wages since most of these 
>> countries (like India, China, Russia) make it much harder for us to get a 
>> work visa than it is for their people coming to work in the US (via H1B 
>> visas).  Until the relative costs of living equalize between the US
>and some of 
>> these other countries (and that could take decades) the wage differential 
>> will be a problem.
>> 
>> ...but I hope this is an overly pessimistic analysis... who knows, there 
>> could be unforseen, unaccounted-for market forces, new technologies or 
>> political changes that keep this scenario from happening.
>> 
>> Phil
>
>
>I would have to agree with this assesment atleast right now.
>
>From where I am sitting, union blue collar jobs that can't be exported
>like say painters, plumbers, toll collectors, auto mechanics, seem to
>be able to easily make maybe half as much as veteran EEs. The pressure
>on EEs though is getting rediculous, more & more education required
>for jobs in order to stay only a little further ahead than many
>tradesmen.
>
>However, the HW & SW jobs that seem to have been exported to India &
>China so far seem to be at the bottom end of the skill spectrum 

Up till now that has been the case, but it's beginning to change...
Last week there was an article in a local paper, the Portland Tribune, 
where they 
interviewed a Venture Capitalist (he found Costco) and asked him where he 
thought the Oregon economy was going.  He said that it doesn't look good 
because of all of the outsourcing going on this time.  He 
mentions that engineering jobs are being outsourced and as an example he 
mentions that Mentor Graphics is going to invest $40million in an R&D 
center in India.  When he asked Mentor why they're doing this here's the 
answer he got: "they said they can't hire anyone graduating from 
engineering schools here because they're just not prepared, they're not 
ready to go into that sophisticated end of the business."

Now of course we all know that the real reason is that they can pay Indian 
engineers about 1/5 of what they pay their counterparts in the US.  Also, 
we know that when it comes to graduate level studies (the 'sophisticated' 
end of the business) US Universities are still among the best in the world 
(I recently took a grad-level class on logic synthesis algorithms - of the 
~40 students ~75% were from India, so if they're turning'em out in India 
why are they coming here to get their graduate degrees?).  To suggest that 
US engineers are not up to the task of doing the 'sophisticated end of the 
business' is an insult to the many engineers here who are looking for 
work and going back to school to improve their knowledge base (in order 
to, hopefully make them more valuable).

The problem is that as engineering jobs (on the 'sophistacted' end) start 
leaving that will eventually have a deleterious on US Universities.  Why? 
well for starters if you're a senior in highschool and you go to your 
career guidance counselor he/she isn't going to recommend that you go into 
engineering since there are fewer jobs available in that field.  Fewer 
students going into engineering means fewer going into undergrad 
engineering programs at the University level which of course means fewer 
'home-grown' grad students as well (already the numbers are small).  And 
if we as a country are producing fewer engineers and more lawyers, 
marketeers, etc. then why concentrate on math & science at the highschool 
level?

>and at
>the end of the day as long as the US is the leading consumer of
>technology, I thinks the better jobs will remain here. 

I hope you're right.

>And English
>language & culture remains a huge barrier to these countries too esp
>China/Russia.

Remember, there are more people in the world who speak Mandarin than those 
who can speak English.  

>
>In the end, most of us do it because we are interested in it, not for
>the huge $, if you aren't driven by 1s & 0s or whatever, I'd look
>elsewhere.

Exactly, most of us can't imagine NOT being engineers.  We're engineers 
because it's part of our nature - even if we're forced to change careers 
we'll still think of ourselves as engineers.

Phil
-- 
"Or perhaps the truth is less interesting than the facts?" 
Amy Weiss (accusing theregister.co.uk of engaging in 'tabloid journalism')
Senior VP, Communications
Recording Industry Association of America  

Article: 51355
Subject: Re: Help for Generating Video Clock synchronous to Hsync of the Video..........
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 12 Jan 2003 09:45:19 +1300
Links: << >>  << T >>  << A >>
arvind wrote:
> 
> Hi,
>    I want a 16mhz clock synchronous to Hsync of the video.I want my 16mhz
> clock should lock on the rising edge of the Hsync.
> I want a pixel clock for Xilinx Spartan 2 Fpga for Video frame
> storage Application.
> I am using oscillator for generating the 16mhz Clock but my video out
> is not stable it have some color problem on the top of the frame
> manse on the first 100 lines of the video and it vary on changing
> of source, first I thought it is a clock stability problem so that I
> changed the oscillator to 5ppm but the problem is still there so I
> want a clock synchronous to video Hsync.
> Can u help me, How can I get the clock synchronous to the video
> because it is affecting the performance of video.
> If u have some idea how we can generate in Fpga so pl'z help me out.I
> Need your urgent Help.
> Thanks For any suggestion.

 This is often called GenLock, and you could also search for Teletext
chip info, both apps involve locking to an incomming SYNC stream.

 The complexity of this problem can change, depending on the Hsysnc
stability, and Video Recorders can have high jitter values.
 PAL can be tricker than NTSC, as you really need frame lock, 
not line lock, and interlace is another issue...

 If you are only inserting text, another 'vanilla' alternative to a
PLL, is to use a Gated RC osc, so that it (re) starts relative to the 
HSYNC ( & stops before line end ). 
 Text width becomes OSC precision dependant, and you need to
watch multiple clock domains in a FPGA, but the HW cost is very low.

-jg

Article: 51356
Subject: Re: internal nets
From: "Gilad Cohen" <edcohen@012.net.il>
Date: Sat, 11 Jan 2003 13:28:11 -0800
Links: << >>  << T >>  << A >>
Hi Nagaraj, 
1. You can use the post-timing-analyzer to find out the delay from the clock to any FF/RAM. 
2. You can use the "Period" constraint (See documentation for syntax) to specify the period of your clock. This covers FFs to FFs delay - for all FFs using the same clock. 
3. If you want specific delay between two signals, you can use the FROM-TO constraint (See documentation for syntax). This constraint overrides the 'Period' constraint. 

Gilad.

Article: 51357
Subject: Re: Partial reconfiguration
From: "Steve Casselman" <sc@vcc.com>
Date: Sat, 11 Jan 2003 21:30:34 GMT
Links: << >>  << T >>  << A >>
All the Xilinx Virtex devices (V1, V1E, V2, V2P) and the old 6200 are
partially reconfigurable. The Atmel devices are. I think the Trisend devices
are. I don't know if the Altera devices are, they don't have any docs (that
I know of) about their bitstreams. Some of the older parts Xilinx parts may
be but not in any useful kind of way.

Steve


"Antonio Di Stefano" <NOSPAMragazzoionico@tin.it> wrote in message
news:IRXT9.107153$TC5.3429047@twister1.libero.it...
> Hi all!
> I heard that some Xilinx devices allow partial reconfiguration.
> Exactly which family implement this feature?
> It exist a way to partially reconfigure even the oldest parts?
> Thanks
>
> Antonio
>
>
>
>
>
>
>
>



Article: 51358
Subject: MPEG ASIC
From: "Emil Wennman" <d00emwe@stud.hh.se>
Date: Sat, 11 Jan 2003 22:57:46 +0100
Links: << >>  << T >>  << A >>
Hi im looking for a good (read chep) asic/fpga solution for jpeg/mpeg
encoding.

Anyone know where i can find one.

Thanks in advance
/Emil




Article: 51359
Subject: Re: Asynchronous RAM problems
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Sat, 11 Jan 2003 18:42:07 -0500
Links: << >>  << T >>  << A >>
> Any ideas on what could be going wrong ? I checked my code and it is
> completely synchronous (except for the external RAM).

What is the RAM part number ? It isn't some sort of pseudo-static ram part
that actually does hidden refresh internally ? How is the RAM organized ?
You mention there is 512kB, is it a single RAM ? Or are there multiple RAMs
on the board using a common bus ? RAMs that aren't being used would still
require signals to disable chips selects. There isn't another device on the
board that could be interfering ?

Can you try reducing the block size from 512 bytes ? The fact that it works
fine for the first 44500 values then starts going haywire seems to indicate
that perhaps some charge resource is being drained (power supply). Can you
restart the operation without reconfiguring or recycling the power supply to
verify that the first 44500 values are still valid on a second pass ? This
might help show whether it's a timing problem or a ps problem.

Maybe it's a bad solder connection ? Could it be a bad bypass cap near the
ram ? You mentioned before that it seemed to work fine using one
configuration but not using the second. FPGA's can use widely varying
amounts of power depending on the configuration. Maybe the second
configuration sucks all the juice out the board causing the ram to operate
improperly. Is there another design that could be loaded into the board that
has roughly the same power requirements, and does it work ? How "beefy" is
the power supply ?

Another admittedly remote possibility is that the tools may not be
synthesizing the code correctly. The tools are very good but may not be
perfect. Do you have a way of verifying the output of the tools manually ? A
while ago I found an error in Webpack where it wasn't generating a
subtractor properly under some circumstances. My design "almost" worked
properly.

There are many, many things that could go wrong. Once all the obvious
heuristic possibilities are exhausted one has to start in the middle and
divide and conquer.


Rob
rob@birdcomputer.ca
www.birdcomputer.ca






Article: 51360
Subject: Bidirectional Digital Switch in CPLD ?
From: TigerMole <Mole@huegel.de>
Date: Sun, 12 Jan 2003 00:49:57 +0100
Links: << >>  << T >>  << A >>
Is it possible to implement a bidirectional digital switch
in a CPLD ? I want to cut off a databus ...

TigerMole

Article: 51361
Subject: Re: MicroBlaze MDK2.2 opb_timer
From: Raj Kumar Nagarajan <rknagara@cs.ncsu.edu>
Date: Sat, 11 Jan 2003 19:37:05 -0500
Links: << >>  << T >>  << A >>
Hi,

> Is there anyone having the same problem before and how to fix it? Will
> it help if i upgrade to EDK version of MicroBlaze?
>

EDK version of Microblaze has changed a lot since MDK, it has lot more
features - both hardware and software. I guess if you have MDK, u can
download EDK and the service pack from Xilinx's website.

Raj
 
> Thanks
> Duy K Do

Article: 51362
Subject: Re: Spartan-2 reset: sync or async?
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Sat, 11 Jan 2003 20:10:58 -0500
Links: << >>  << T >>  << A >>
> I have a  choice between synchronous and asynchronous global reset in the
> design. In older devices choosing async reset usually lowered resource
> utilization due to dedicated async reset input of the CLB.
>
> How is it now, with Spartan-2 and newer that have sync/async choice for
the
> dedicated reset input? Which method is recommended? Sync method seems
better
> (simpler timing management), but maybe there are some dark sides. Can you
> share some experience?
>

Based on the discussions in this newsgroup: I use an asynchronous global
reset (with lax timing constraints = none) to make use of the global reset
network so routing resource are not wasted on reset. Then I use a locally
generated synchronous "critical" reset signal to synchronously reset the few
ff's (say a dozen) who's reset state is critical to the operation of the
design. The global reset signal resets everything (including the critical
reset generator) by taking a varying number of clock cycles (it's async).
The critical reset generator holds the reset state of the few ff's until a
few cycles after the global reset is gone. Because the critical synchronous
reset net is very localized it does not impact meeting timing requirements
for the design, which might be a problem if a global synchronous reset were
being used.

 // Generate critical reset
 always @(posedge clk)
  if (reset)                // this is the async reset fed into the system
   cres <= 8'hFF;    // This is just the timeout pattern (active high reset)
  else
   cres <= {cres[6:0],1'b0};    // shift reg

// creset is the synch. reset signal which drive the few ff's that need to
be synchronously reset
// for proper operation. It will be held active until some cycles after the
async reset.
// How long the creset signal has to be held depends on how many clock
cycles difference
// there could be between different ff's in the design being reset async.
This depends on the
// clock operating frequency and the amount of delay in the async reset to
various parts of the
// design.
assign creset = cres[6];


I wonder how hard it would be for FPGA manufacturers to feed a global reset
signal to only a few CLB's sprinkled around the FPGA rather than driving
every ff with a global reset signal ? This would allow for a few local reset
generators. Then, for the few parts of a design that may require synch.
reset local routing could be used. The LUT shift registers are great but it
sure would be nice if they could accomodate a reset input. Otherwise how
about some dedicated shift registers with reset input ?

Rob
rob@birdcomputer.ca
www.birdcomputer.ca






Article: 51363
Subject: from ABEL/PLDs to VHDL&VeriLog/FPGAs
From: 2Penny <LW_Rogers@sbcglobal.net>
Date: Sun, 12 Jan 2003 01:36:54 GMT
Links: << >>  << T >>  << A >>
Gentlement:

I've built a small computer board I've made for a small college here.
I'd like to simplify the design by putting the glue logic into an
fpga, but I know nothing about fpgas.  I think I can ask the college
to spring for the software if it isn't too much, but how do I download
this to the chip.  I do this fairly regularly with ABEL and PLDs, but
I think I should update my skills, but I don't know where to turn.
I'm looking for clues.  Please point me in the right direction.

TIA

2Penny


Article: 51364
Subject: Call for Papers: 6th MAPLD International Conference
From: "Richard B. Katz" <richard.b.katz@nospamplease.nasa.gov>
Date: 12 Jan 2003 02:29:31 GMT
Links: << >>  << T >>  << A >>

                            Call for Papers

                    6th MAPLD International Conference

           Reagan Reagan Building and International Trade Center
                            Washington, D.C.

                          September 9-11, 2003

   Abstracts are being accepted for the 6th annual Military and Aerospace
   Programmable Logic Devices (MAPLD) International Conference.
   Programmable devices, technologies, and related aspects of digital
   engineering will comprise the major emphasis of this conference.

   This year, there will be a special emphasis on papers with the following 
themes: 

       Reliability of Hardware and Designs; Fault Tolerance 
       Reconfigurable/Adaptive Computing Systems 
       Long-term Space Missions: > 15 Years 
       Hardware and Software: The line is blurring 
       Radiation Hardening by Design 
       Digital Signal Processing with Programmable Devices 
       Design Security 
       "War Stories" and Lessons Learned 

   The Technical Program will consist of technical paper presentations and
   a poster session. We are planning an exciting program including several
   special Invited Speakers including the annual Invited History talk.
   Select papers will be published in the AIAA Journal of Spacecraft and
   Rockets.  This conference is open to both foreign participation and US
   citizens and is unclassified.  For conference program and registration
   information, please visit the AIAA at http://aiaa.org/events/mapld
   For technical information, please visit http://klabs.org or the 2003 
   MAPLD International Conference Home Page at http://klabs.org/mapld03

   MAPLD topics include (but are not limited to) the following: 

       Design and Analysis            
           CPU
           Logic 
           Low-Power Techniques 
           High-Speed Techniques 

       Applications
           Military (Ground, airborne, artillery, etc.) 
           Launch Vehicle 
           Spaceborne 
           Arithmetic and Signal Processing 
           Encryption Systems 
 
       Devices
           Advanced Devices, Technologies, and Software and Their
              Impact on Critical System Reliability 
           Programmable Technologies and State-of-the-Art Devices
              and Programmable Elements 
           Device Architecture 

       Systems and Software
           System-on-Chip 
           Software Tools for Design/Analysis - HDLs, Synthesis,
              Design Entry Systems 
           Translation from High Level Languages 
           Intellectual Property 
 
       Reliability
           Experience and "Lessons Learned" from Mission Experience 
           Radiation Effects, Device Reliability and Element Characteristics 
           Fault Tolerance 
           Use of COTS Devices in the Military and Spaceflight Environment 
           Testing and Analysis Techniques 
           Advanced Packaging 

       Adaptive Computing Systems
           Evolvable Hardware 
           Reconfigurable Computing 
 
   BIRDS-OF-A-FEATHER SESSIONS: The 2002 MAPLD International Conference
   "Birds-of-a-Feather" session on reconfigurable computing was a success
   and will be continuing into 2003 as a MAPLD feature.  We are planning 
   to add a second "Birds-of-a-Feather" session on the radiation testing
   of programmable devices.

   PANEL SESSION: Again, we will have leading engineers and managers on
   our panel for a spirited "discussion."   One question left open from
   the 2002 panel that will be discussed at the 2003 panel is...

                        Why Is Software So Hard?
             A Discussion of the Technical, Programmatic, and
          Political Factors That Have Lead To Failures Over the
             Last 40 Years and Its Impact for Future Systems

   SEMINARS will again be offered (with a separate registration).  Seminars
   will be on September 8th, 2003. Two full-day seminars will be given: 

      "Advanced Design: Digital Signal Processing, Programmable Device
      Architecture, and Military/Aerospace Applications" led by Ray Andraka. 

      "Reconfigurable Computing: FPGA-Based, General Purpose, High
      Performance Systems" led by Tarek El-Ghazawi, Maya Gokhale, Duncan
      Buell, and Allan Snavely. 

   The 6th MAPLD International Conference is:

      Hosted By:

          American Institute of Aeronautics and Astronautics
          NASA Office of Logic Design

      Sponsored By:

          Goddard Space Flight Center
          National Security Agency
          NASA's Electronics Radiation Characterization Project
          NASA Theme: Mission and Science Measurement Technology

      Supported By:

          Air Force Research Laboratory
          The IEEE,  IEEE Aerospace & Electronic Systems Society (AESS)

   For more conference information, please visit 
   http://aiaa.org/events/mapld03 or http://klabs.org/mapld03
   or contact:

      Richard Katz - Conference [Grunt] Chair
      NASA Goddard Space Flight Center
      mapld2003@klabs.org
      Tel: (301) 286-9705

      Alan W. Hunsberger - Conference Co-Chair
      National Security Agency
      al@klabs.org
      Tel: (301) 688-0692
  
      Tanya Vladimirova - Conference Co-Chair
      University of Surrey
      tanya@klabs.org
      +44(0)1483 879137

      Kevin Hames - Conference Co-Chair, Journal of Spacecraft and Rockets
      NASA Johnson Space Center
      kevin@klabs.org
      Tel: 281 483-8592
  
      Hans Tiggeler 
      Conference Co-Chair, European Liaison
      hans@klabs.org

      Rod Barto - Conference Co-Chair
      rod@klabs.org
      Office of Logic Design/Spacecraft Digital Engineering 

   Abstracts should be approximately 2 pages long.  They should include
   an introduction, a brief summary of related work and references, and
   a discussion of the key elements of the paper and conclusions.  

   Please send abstracts to mapld2003@klabs.org.   Submit abstracts in
   an attached file, using the following format: lastname_a.ext - where
   last name is the name of the first author - e.g., katz_a.txt.  Please
   include first author information for point of contact (name,
   affiliation, phone number, and e-mail address).   

   Important: Technology Transfer Considerations, Copyright, and
   Proprietary Information 

      Prospective authors are reminded that technology transfer guidelines
      and policies can considerably extend the time required for review of
      abstracts, presentations, and completed papers. Internal (company)
      plus external (Government) reviews can in some cases consume 16
      weeks or more. Proper Government reviews, ownership of copyright,
      and the absence of proprietary information is solely the
      responsibility of the author. Authors should determine the extent of
      approval necessary early in the paper preparation process to preclude
      paper withdrawals and late submissions. The organizing committee and
      AIAA will assume that all abstracts, presentations, and papers are
      appropriately cleared for unrestricted distribution to an
      international audience. 

   Abstracts are due April 25th, 2003.  Late papers will be accepted for
   the Poster Session, only.  The program will be announced no later than
   June 2, 2003.

   INDUSTRIAL EXHIBIT reservations should be sent to mapld2003@klabs.org
   and should include company name and contact information (phone and
   email).  For additional information, please see:

      http://klabs.org/richcontent/MAPLDCon03/Industrial_Exhibits.htm


   Richard B. Katz
   NASA Office of Logic Design
   Chairman, MAPLD International Conference

Article: 51365
Subject: Anyone Used DCI in Virtex-2?
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 12 Jan 2003 04:08:56 GMT
Links: << >>  << T >>  << A >>
I am doing a design in Virtex-2 and am tight on board real estate.  I would
like to use the Digitally Controlled Impedance feature of V-2, but before I
do, I need to know if anyone here has used this feature successfully all the
way to the lab.   I do not want to run into a situation where I lay out the
board without series termination resistors on many drivers and then find out
that this feature is advertised but not working.

I plan on connecting VRN to VCCO and VPN to ground through 33 Ohm resistors
and implement LVDCI_33 drivers using the UCF file line:
  NET "O_signal" IOSTANDARD=LVDCI_33;

Anyone had any problems implementing DCI using this method?

Thanks.

Simon Ramirez, Consultant
Synchronous Design, Inc.



Article: 51366
Subject: Re: Virtex-II Pro misfire?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Sun, 12 Jan 2003 05:11:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <adb3971c.0301102259.628b0fd3@posting.google.com>,
john jakson <johnjakson@yahoo.com> wrote:
>I only wish Xilinx could have made an ARM deal too. I know, I know,
>next person will want MIPS and so on.
>
>I am pretty sure too that embedded PPC cores are a low priority for
>most FPGA guys right now but the path to PPC leads to certain markets
>(higher performance, high value). The path to ARM leads to lower cost
>and smaller designs I hazard & I bet much larger consumer markets as
>well as perhaps ASIC conversions. Perhaps Spartan.. pro whatever could
>have ARM offering instead. If I were a gadget guy counting all the
>embedded cpus in my toys I'm sure I would find lots of ARMs and few
>PPCs (although my 3com cable box has one).

How much does choice of ISA really matter?  You get decent tools, a
good compiler, your OS, and the ISA itself becomes secondary.
Arm has a couple of gimmics that help (a 16 bit ISA variant for more
code density, condition coding), but those are secondary effects.

If you have legacy code, or a specific OS support, ISA may matter.
Then again, you can always use a soft core for that.

But if you are doing a NEW project, why care?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51367
Subject: Re: Student development board
From: "Alex Gibson" <alxx@ihug.com.au>
Date: Sun, 12 Jan 2003 17:24:07 +1100
Links: << >>  << T >>  << A >>

"David" <gretzteam@hotmail.com> wrote in message
news:gVlT9.10113$3u5.32039@weber.videotron.net...
> Hi,
> Does anyone know what is the best choice for an fpga developement kit?
> Altera offers this kit for University student :
> http://www.altera.com/education/univ/kits/unv-kits.html
> I wonder if there are other supplier of boards like this (could be Xilinx
> too) that could compete with this. Are there third party manufacturer that
> are worth considering?
> Thanks
> David
>

digilent, they make cpld and fpga boards
http://www.digilentinc.com/
they produce the coolrunner2 design kit board for xilinx.
nice range of boards and periphals

If you have the cash  the Burched kit looks good.
http://www.burched.com.au/

Also look at xess www.xess.com

It depends what features you are after.

see
http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=protoboards_protoboards_page
for a larger list of boards

Alex



Article: 51368
Subject: Re: Asynchronous RAM problems
From: dmitrik@mailandnews.com (Dmitri Katchalov)
Date: 12 Jan 2003 01:21:11 -0800
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3E1F1F12.A6722E19@yahoo.com>...

> The main issue is to keep the address and data stable while the write
> strobe is asserted.  

Just wondering if I can achieve that without extra wait state.

My RAM has 0 min hold time for address and data with respect to /WE and /CS. 
If I drive /CS and /WE with fast slew rate drivers and drive address lines 
with slow drivers, is it too risky? 

Also someone suggested using bus keepers on the data bus to ensure enough
data hold time. If I set /WE high and at the same time set data bus to HiZ,
this should be work, right?

Finally SpartanIIE has 2.2 ns max clock-to-HiZ and my RAM has 3ns min 
/WE-to-LoZ. This gives me 0.7ns plus clock-to-pad delay (which has no
specified minimum) to aviod bus contention. Is it sufficient?

On a separate note I couldn't find any numbers for the max *difference* 
in clk-to-pad time between two outputs. I don't think one output can be 
upto 2.9ns either ahead or behind another given that they both are at 
the same Vcc and temperature.

BTW my project is a one-off hobby stuff, not for production.

Thanks,
Dmitri

Article: 51369
Subject: schematic to VHDL conversion???
From: sudharr@myw.ltindia.com (RANGA REDDY)
Date: 12 Jan 2003 01:22:33 -0800
Links: << >>  << T >>  << A >>
Dear friends,

is there any tool which converts ALTERA MAXPLUS II shematic design to
VHDL code. if any limited version software is there, pls give me reply
saying that who is giving that facility.

regards,

S.RANGA REDDY

Article: 51370
Subject: Open FPGA please!
From: Andrew Rogers <andrew@rogerstech.co.uk>
Date: Sun, 12 Jan 2003 11:03:17 +0000
Links: << >>  << T >>  << A >>
It would seem that the Open Source software developers haven't quite 
managed to produce a complete tool chain for programming FPGAs. The 
remaining issue seems to be that FPGA manufactures are not willing to 
supply the necessary bit-stream specification and make excuses, giving 
the details of the bit-stream would allow reverse engineering of 
commercial products that use their FPGAs. That's probably true, but any 
one wishing to clone such a product only has to duplicate the bit-stream 
and no reverse engineering is required.

If FPGA manufactures continue this ridiculous trend then maybe the only 
option is to develop a new FPGA which has all of its specifications 
available.

I know that this issue has been raised in the past, but this time I am 
following up a different approach, the development of an Open FPGA.

Can anyone (Xilinx maybe) estimate the cost and time involved in 
development of a new and open FPGA?

Maybe I could test out the new Open FPGA with my University Ph.D. work 
on Turbo codecs!

Thanks
Andrew Rogers


Article: 51371
Subject: Re: Xilinx 5202 peripheral mode configuration problem
From: db@esl.tex.com (David Buckley)
Date: 12 Jan 2003 03:10:48 -0800
Links: << >>  << T >>  << A >>
db@esl.tex.com (David Buckley) wrote in message news:<d31f9208.0301051956.2b0ead75@posting.google.com>...
> I'm trying to get a board working that has a XC5202 and an 80188
> variant chip working together in asynchronous perhipheral mode.  Just
> a single chip, no chains.
> 
> I've taken the .bit file, and after skipping the header am literally
> pushing the bytes direct to the XC5202, and it all goes OK up till
> about byte 51 (its always at the same place, but I'm not at the bench
> at the mo, and the memory has faded a little), whereupon the /INIT pin
> drops, indicating a framing error.  The same bitstream, if fed
> serially by the same processor to the same XC5202, works just fine.

And the answer is:

In parallel mode during configuration the data bits are the other way
round, ie D7 is the LSB, and D0 is the MSB.

Thank you to Marc Baker at Xilinx for this gem, which you can read all
about at

http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=1941.

Article: 51372
Subject: Re: In-Rush current in Stratix device
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Sun, 12 Jan 2003 12:16:59 +0100
Links: << >>  << T >>  << A >>
Just out of curiosity, what is the reason for larger startup currents ?
Larger overall current would be explainable with larger structures and
larger dies. What amazes it the obvious reduction of the current after
a certain time. Is that the configuration time ?

Rene


Greg Steinke wrote:
> Alon,
> 
> The EP1S25 ES devices have a higher power-up current than the
> production devices. The typical power-up current for the ES device is
> 2.5 A (on the 1.5-V VCCINT supply), as shown in the Stratix Errata
> Sheet version 2.2. This value is typical, and individual devices use
> more or less current during power up. Also it is important to note
> that charging the decoupling capacitors on the board will consume some
> amount of current during the power up, so not all of the current
> coming from the supply is consumed by the Stratix device.
> 
> We have improved the EP1S25 production devices, which are available
> now. These devices are tested for a maximum power-up current of 1.2 A
> on the VCCINT supply. We are now characterizing the entire Stratix
> family for power-up current and will update the data sheet with
> power-up specifications for all Stratix devices.
> 
> Power-up current in general is quite low for the production Stratix
> devices. In fact, the EP1S80 is over 3x larger than the EP1S25 and we
> are seeing typical power-up current that is under 1A. We are still
> working on what the maximum power-up current will be for the EP1S80,
> but it should be below 2A or so.
> 
> Many customers have purchased the EP1S25ES devices and we have not
> heard any examples of customers seeing the current consumption that
> you have seen. I would like to suggest that you contact me at Altera
> and we can try to see why your board shows this characteristic.


Article: 51373
Subject: Re: Open FPGA please!
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sun, 12 Jan 2003 13:33:15 +0100
Links: << >>  << T >>  << A >>
"Andrew Rogers" <andrew@rogerstech.co.uk> schrieb im Newsbeitrag
news:3E214B75.5080507@rogerstech.co.uk...

> If FPGA manufactures continue this ridiculous trend then maybe the only
> option is to develop a new FPGA which has all of its specifications
> available.

;-)

This is funny.

--
MfG
Falk





Article: 51374
Subject: Re: Open FPGA please!
From: Andrew Rogers <andrew@rogerstech.co.uk>
Date: Sun, 12 Jan 2003 13:22:16 +0000
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> "Andrew Rogers" <andrew@rogerstech.co.uk> schrieb im Newsbeitrag
> news:3E214B75.5080507@rogerstech.co.uk...
> 
> 
>>If FPGA manufactures continue this ridiculous trend then maybe the only
>>option is to develop a new FPGA which has all of its specifications
>>available.
> 
> 
> ;-)
> 
> This is funny.


Funny because it seems an impossible task to design a new FPGA? If so, 
then is it not possible to just change the bit-stream decoding in an 
existing FPGA design to create an open version that has a different 
bit-stream to closed FPGAs.

Regards
Andrew Rogers




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