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
2017JanFebMarApr2017

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 14550

Article: 14550
Subject: Re: VHDL problem (Xilinx-problem)
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Thu, 04 Feb 1999 13:13:49 GMT
Links: << >>  << T >>  << A >>
Lars Fomsgaard wrote:
> 
> Hi
> 
> I have some problems with a design, that I can not make synthesize properly
> in Xilinx Foundation
> (the code is listed belov). The problem is that the tool removes to signals
> (swon and t16m)from the
> netlist and from the macro symbol.
> 
> Basicly i have a counter (cur_cnt), that is reset whenever a certain
> condition is meet (t16m = '1'), and
> incremented whenever an rising edge occours on the signal swon.
> 
> I have sent the design to Xilinx hotline, and their "VHDL-expert" claims
> that the problem is as follows:
> 
> I assign the signal swon_d the value of swon, and after this (but in the
> same clocked process) I test
> wheater the condition (swon = '1' AND swon_d = '0') is meet, and this can
> never be the case, so the
> signals swon and t16m can be removed.
>

this is wrong, signals are not updated untill you exit the process, so 
swon_d will(should :)) be a register, so inside the process it will have 
the value of swon from the last rising edge, since it is not updated
until
the exit
    
           _   _   _   _   _
clk      _| |_| |_| |_| |_| | 
            _________________
swon     __//
               ______________
swon_d  ______|
             ^
process see: |  


> I do not agree with this, and so I would like if someone could tell me if I
> have completely misunderstood
> the principle of VHDL processes. And if someone else have experienced
> similar problems and knows
> a workaround.
> 
> Thanks in advance
> Lars Fomsgaard
> 
snip
>

--Lasse                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 14551
Subject: Re: Off topic DRAM/SIMM question....
From: z80@ds2.com (Peter)
Date: Thu, 04 Feb 1999 13:36:28 GMT
Links: << >>  << T >>  << A >>

Only if they all use all the memory too. They might not.

NT has a weird memory management strategy, gradually using up all the
RAM there is and continually swapping pages to disk even if there is
far more RAM that it "should" need. This brain-dead strategy has been
much criticised but MS claim, IIRC, that it represents the best
tradeoff for a "server" situation. But then we all know that MS is not
exactly an innovative company, preferring to stick with code which
does the job.

Win3.x, in comparison, will use up the RAM it needs and stop there. If
you have a system with 64MB and running some little app then most of
the RAM won't get touched, AFAIK, after the initial himem.sys memory
test (which is very primitive anyway).

I don't know about win9x and OS/2. I would expect win9x to be similar
to win3.x in this respect.

>If using the whole memory space could make your system crash, then all other
>OS's should have problems too.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.

Article: 14552
Subject: Re: Opinions requested : Minc/Synario alternatives
From: rjmyers@dseg.ti.com (Bob Myers)
Date: 4 Feb 1999 13:43:34 GMT
Links: << >>  << T >>  << A >>
***** I'm posting this conversation in the 2 sci.electronics groups
      at this time to get opinions from those who frequent these
      newsgroups.  
                     
- bob

-------------------------------------------------------------------

Here's what I'm mostly concerned about -- it seems that
the vendors, such as Vantis and Xilinx, are now going to
target their own CPLD/FPGA lines with ABEL.  I need to
find a product that is not a "point" solution; something that
will handle programming PLDs (aka 16R8s, 22V10s, etc.) that
are still being made by various manufacturers.

I am trying to find possible solution(s) that cover the 
following needs:

1) Will target multiple vendor PLDs (not just CPLDs and/or FPGAs).
2) Can program parts using Data I/O Unisite subsystem.
3) Available to run under PC-NT platform (Sun Solaris & HPUX may
   be optional).
4) Uses FlexLM license checkout, if required.  (Have to service
   multiple engineers per building/site, which may have access
   to an open or closed LAN).

The only vendor that seems to meet this criteria now is Logical
Devices with their CUPL Total Designer suite.

If anyone has any additional suggestions/inputs, please post
them or send me email directly.

Thanks,
Bob


In article <79brhj$699$1@nnrp1.dejanews.com>, peter.trott@vantis.com writes:
> In article <796uds$cb3@news.rsc.raytheon.com>,
>   rjmyers@ti.com wrote:
> > As some/many of you may know, Minc/Synario closed their
> > doors and had turn over their assets to be liquidated
> > (see EETimes article, dated around Dec 18, 1998).
> >
> > I am trying to determine what people/other organizations
> > are doing to support the programming of PLDs (and possibly
> > CPLDs) now that the company that supplied ABEL has shut down.
> > It appears that Logical Devices may be the only "non-biased"
> > vendor out their, with their CUPL system that targets
> > multiple PLD vendor devices.
> 
> Vantis purchased the Synario GUI and the rights to use the ABEL
> language in a new product that is available free from the Vantis
> web site. It is called DesignDirect-CPLD.
> If you are familiar with Synario the GUI is similar with some
> added enhancements to the flow including an easy to use constraints
> editor and timing analyser at the back.
> It supports all Vantis SPLD and CPLD parts, from the lowly 16V8 up to the
> 512 macrocell MACH5's.
> 
> This tool will allow you to migrate old design by maintaining the ABEL
> language. DD-CPLD allows ABEL, schematic and EDIF inputs so that it can be
> bolted under any third party synthesis tool.
> 
> 
> 
> >
> > Any thoughts/insights on this matter are welcomed.
> >
> > -Bob
> >
> > p.s.  I have not received any inputs from our AVNET reps
> > regarding what Xilinx's plans are regarding what Xilinx
> > purchased from the liquidator.
> >
> >
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    




Article: 14553
Subject: Re: Off topic DRAM/SIMM question....
From: "Austin Franklin" <austin@dark9room.com>
Date: 4 Feb 1999 13:44:48 GMT
Links: << >>  << T >>  << A >>
> > I just do not believe NT does anything with the chip set.  Why do you
> > believe this?  Are you speculating or do you have first hand knowledge
of
> > this?
> 
> No, but as I said before, this is the most plausible explanation. Why ?
> 
> I have seen the same memory blocks not perform on one mainboard with NT,
but
> performing very well on another mainboard with NT, indicating that the
quality
> of this RAM was not an issue. 

There could be timing differences in the systems/chip sets that have
nothing to do with NT.  Also, the BIOS settings may be different....who
knows.  Unless you have done this as a controlled experiment,
checking/verifying every variable and only changing one at a time, and any
conclusion you might want to draw from this is pure speculation.
  
> > I believe there are many other plausible explanations...such as it
actually
> > uses it, may be NT loads high, may be it just uses a LOT more memory, a
LOT
> > more often.  May be it actually cares that it gets the right answer,
unlike
> >  the virus W95 that could care less?  I really don't know, but my last
> > guess would be it re-programs the chip set.  Also, I believe NT uses
> > features of the processor that others don't....
> 
> If using the whole memory space could make your system crash, then all
other
> OS's should have problems too.

No, if NT loaded all over the place, and takes up substantially more
memory, then it would be more sensitive.  Besides, other OSs DO have the
same problem, namely Linux.

> And all systems crash if they don't get the
> "right answer" It is not that the OS is determining the sensibility level
with
> regards to the CPU getting bad opcodes :-)

But if the OS code/data was much larger, then it would be much more
susceptible.  And if you note, that virus W95 crashes ALL the time.  Given
that, memory problems might plague W95 just as they do NT, they just
manifest them selves differently.
 
Austin

Article: 14554
Subject: Re: VHDL problem (Xilinx-problem)
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Thu, 04 Feb 1999 08:54:30 -0500
Links: << >>  << T >>  << A >>
Lars Fomsgaard wrote:
> 
<snip>
> I have sent the design to Xilinx hotline, and their "VHDL-expert" claims
> that the problem is as follows:
> 
> I assign the signal swon_d the value of swon, and after this (but in the
> same clocked process) I test
> wheater the condition (swon = '1' AND swon_d = '0') is meet, and this can
> never be the case, so the
> signals swon and t16m can be removed.
> 
<snip>

Well then Xilinx's "VHDL Expert" is wrong. As long as swon, swon_d, and
t16m are all signals, the circuit should work.

 
      sync :
         PROCESS (clk, RESET)
         BEGIN
            IF RESET = '1' THEN
               swon_d      <= '0' ;
               cur_cnt      <= (OTHERS => '0') ;
               -- Some additional lines removed as they were
               -- related to other signals.
             ELSIF clk='1' AND clk'EVENT THEN
                swon_d      <= swon ;
                IF t16m = '1' THEN                                    --
                   -- Counter for counting overcurrents.
                   cur_cnt      <= (OTHERS => '0') ;
                ELSIF swon = '1' AND swon_d = '0' THEN  -- Xlinx claims
                                                        -- that  this
condition can never be meet.
                   cur_cnt      <= cur_cnt + "0001" ;   -- as swon is
equal to swon_d.
                END IF ;

---->>>         TRY MOVING swon_d <= swon; HERE AND SEE IF THIS SOLVES
YOUR APPARENT COMPILER PROBLEM.


             END IF;
          END PROCESS sync ;
 

-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 14555
Subject: DES in VHDL for FPGAs
From: "Matthias D. Kistler" <recomp@satie.ee.ethz.ch>
Date: Thu, 04 Feb 1999 15:04:02 +0100
Links: << >>  << T >>  << A >>
Hi !

I am looking for the VHDL sources for a DES implementation suitable for
an FPGA.
I only need the encryption part, since the eventual goal is a in
implementaion of the UNIX crypt(3) Algorithm in an FPGA.
Any Help is greatly appreciated.

Matt.
Article: 14556
Subject: Re: VHDL problem (Xilinx-problem)
From: Markus Michel <mmichel@kius.ch>
Date: Thu, 04 Feb 1999 15:15:02 +0100
Links: << >>  << T >>  << A >>
Hi
try it with two separate processes, one for the rising edge detection and the
second for the counter!

Good luck,
Markus Michel

Lars Fomsgaard wrote:

> Hi
>
> .....



Article: 14557
Subject: Re: Off topic DRAM/SIMM question....
From: Brian Dam Pedersen <brian@kom.auc.dk>
Date: Thu, 04 Feb 1999 14:15:03 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> > And all systems crash if they don't get the
> > "right answer" It is not that the OS is determining the sensibility level
> with
> > regards to the CPU getting bad opcodes :-)
> 
> But if the OS code/data was much larger, then it would be much more
> susceptible.  And if you note, that virus W95 crashes ALL the time.  Given
> that, memory problems might plague W95 just as they do NT, they just
> manifest them selves differently.
> 
> Austin

OK - I have learned a few things since my last posting. Memory problems are more
common than I thought they were, Linux users have confirmed this. In Linux they
typically manifest themselves during a kernel recompile, which excercise the
system in an unusual manner. Usually timing problems either in the cache or in
the RAM rows. People have also reported CPU overheating as a cause of failure
when recompiling kernels (!), and HDD timing/data transfer problems. 

But what I don't get is, that the NT errors typically manifest themselves during
install (see Lasses post). They are very consistent in doing so (rules out
spurious RAM errors but not permanent failing to meet timing demands), but can
be cured with a RAM replacement. This indicates a more permanent RAM problem.
But how come that the same RAM blocks in another brand of main board with the
same timing settings suddenly works OK then ? 

And what is NT doing that heavily excercises 64Mb RAM in the startup phase of an
install ? Disk caching doesn't count here - a failing read/write would not lock
up the install program here, just mess up the installed files, and a CRC check
would usually be performed on the written file on disk, not on the memory image. 

Self test could be an answer, but testing the SIMMS would mean disabling the
external cache, which requires a chipset reprogram, which cannot be done by NT
since it cannot know all chip sets according to you. Further more failure to
pass the test would probably result in some kind of error message, not a
lock-up. What else ?

--                                               
Brian Pedersen, DSP Student                    _/     _/_/_/  _/_/_/  _/
Applied Signal Processing and Implementation  _/_/   _/       _/   _/ _/
Department of Communication Technology       _/  _/   _/_/_/  _/_/_/  _/
Aalborg University, Denmark                 _/_/_/_/       _/ _/      _/
URL: http://www.danbbs.dk/~kibria/brian/   _/      _/ _/_/_/  _/      _/

Article: 14558
Subject: Re: PCI based development board?
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Thu, 4 Feb 1999 07:25:22 -0800
Links: << >>  << T >>  << A >>
There are a few boards that may be of interest.  Check out the Boards
section on The Programmable Logic Jump Station at
http://www.optimagic.com/boards.html.

In specific, you may want to check out the following vendors:

Virtual Computer (VCC):    http://www.optimagic.com/boards.html#VCC
Annapolis Microsystems:    http://www.optimagic.com/boards.html#Annapolis
NxM:                       http://www.optimagic.com/boards.html#NXM
MiroTech:                  http://www.optimagic.com/boards.html#Mirotech
The Dini Group             http://www.optimagic.com/boards.html#Dini

.. . . among others.

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------


Martin van Eersel wrote in message <79bsu8$ae5$1@news.worldonline.nl>...
>Hello,
>
>I am looking for a (PCI based) development board for either PLD's or
FPGA's.
>
>The function of the board should be sampling of an 8 bit parallel bus (at
>about 4Mb/s). Is there any development board that already has a PCI
>interface on it, with the option of programming some local PLD (or FPGA).
>The board should have software support for windows NT.
>
>Does anybody know if any of the major PLD vendors offer such a board?
>
>All comments welcome, please reply via email
>
>Martin
>
>mes@odme.nl
>
>


Article: 14559
Subject: Re: VHDL problem (Xilinx-problem)
From: David Kessner <davidk@peakaudio.com>
Date: Thu, 04 Feb 1999 08:43:08 -0700
Links: << >>  << T >>  << A >>
Lars Fomsgaard wrote:

>                cur_cnt      <= (OTHERS => '0') ;
>                   cur_cnt      <= (OTHERS => '0') ;

There is a couple of things I can spot:

    1.  The use of (Others=>'0') is not always accepted by all VHDL
         compilers.  I forget is Xilinx is one that doesn't accept it, but
         it wouldn't supprise me.  Use "0000" instead.
    2.  The signals swon and t16m should be in the process sensitivity
         list.  The Xilinx VHDL compiler DOES warn you about this, but
         you have to hunt through lots of logs and report files to find it.
         Since it isn't in the sensitivity list, the process doesn't know to
run
         when these signals change-- hence those signals don't effect the
         outcome of the process and are optimized out.

With these changes, your code should work.  There is not need to
make it into two processes (at least from a functional standpoint).


Hope that helps!

David Kessner
davidk@peakaudio.com


Article: 14560
Subject: Re: Off topic DRAM/SIMM question....
From: Phil Short <pjs3@nospam.ix.netcom.com>
Date: Thu, 04 Feb 1999 08:10:02 -0800
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
>
[snip]
> 
> There could be timing differences in the systems/chip sets that have
> nothing to do with NT.  Also, the BIOS settings may be different....who
> knows.  Unless you have done this as a controlled experiment,
> checking/verifying every variable and only changing one at a time, and any
> conclusion you might want to draw from this is pure speculation.
> 

This gets to the heart of the matter.  A combination of controlled
experimentation and observation with a logic analyser and/or
oscilloscope would answer this question more accurately and quicker than
anything else.

While I have my own personnal suspicions (DRAM pattern sensitivity that
causes problems with NT/Linux because these OS's have different patterns
of memory access and usage), this can only be verified (or refuted) by
the techniques mentioned above.

--

Phil

Article: 14561
Subject: Re: Foundation v1.5i Spartin Problems
From: "Mickey Balter" <mbalter@eimsys.co.il>
Date: Thu, 4 Feb 1999 18:46:40 +0200
Links: << >>  << T >>  << A >>
There is a patch for this problem, which you can find a reference to at:
http://www.xilinx.com/techdocs/4986.htm

Mickey Balter
EIM




Article: 14562
Subject: Re: Ratings for Synplicity Synplify
From: Geir Harris Hedemark <geirhe@hridil.ifi.uio.no>
Date: 04 Feb 1999 17:54:13 +0100
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM writes:
> 1) I still can't get 1998.08 to accept 'entity E is...end entity E'; I
> don't believe it has the '93 extensions.

I still think this is on the "todo-soon" list at Synopsys.

> extensions, except that the notes say that FPGA Compiler II (ie., FPGA
> Express) now has initial '93 support - maybe this is what you saw???

Actually, I don't think I have ever seen it documented, and I can't
seem to find it myself. I think someone from Synopsys must have told
me so at DAC. Or perhaps I am mistaken.  :-)

Geir

Article: 14563
Subject: Timing Simulation and Foundation
From: kfalser@durst.it
Date: Thu, 04 Feb 1999 17:12:06 GMT
Links: << >>  << T >>  << A >>
Hello,

Im using Xilinx Foundation 1.4 and I'm trying to verify a design with
VHDL-Timing simulation.

On my machine, Foundation creates the file time_sim.vhd and time_sim.sdf,
which contains the routet design in VHDL.
Following the documentation there should be created a 3th file, time_sim.tvhd
with a testbench for the design.
I simply can not find this last file, although on the log of the flow engine
there are 3 xcpy commands, even without a error message.

...(begin part of log)

Global signal "PRLD" is undriven.
Generating vhdl sdf file:time_sim.sdf
Generating VHDL netlist file:time_sim.vhd

xcpy time_sim.vhd c:\projekte\inkjet\xilinx\head_if\time_sim.vhd

xcpy time_sim.tvhd c:\projekte\inkjet\xilinx\head_if\time_sim.tvhd

xcpy time_sim.sdf c:\projekte\inkjet\xilinx\head_if\time_sim.sdf

hplusas6 -i head_if -s -a -l head_if.log -o fe_temp

Fitter1:  version M1.4.12
(c) Copyright 1989-1997 Xilinx Inc. All rights reserved.

... (end part of log)

When I'm going to look at the destination directory of the copy operation,
I'm able to find the other two files, but not time_sim.tvhd.

Please, does anybody have a explanation for this strange behavior?

Thank you
        Klaus

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14564
Subject: Re: VHDL problem (Xilinx-problem)
From: mench@mench.com
Date: 4 Feb 1999 17:54:43 GMT
Links: << >>  << T >>  << A >>
David Kessner <davidk@peakaudio.com> wrote:
>     2.  The signals swon and t16m should be in the process sensitivity
>          list.  The Xilinx VHDL compiler DOES warn you about this, but
>          you have to hunt through lots of logs and report files to find it.
>          Since it isn't in the sensitivity list, the process doesn't know to
>          run when these signals change-- hence those signals don't effect the
>          outcome of the process and are optimized out.

The process doesn't need to run when these signals change.  It's a
synchronos model with an asynch reset.  The process needn't run when
other control signals change.

Paul

-- 
Paul Menchini          | mench@mench.com | "Non si vive se non il
OrCAD                  | www.orcad.com   |  tempo che si ama."
P.O. Box 71767         | 919-479-1670[v] |  --Claude Adrien Helvetius
Durham, NC  27722-1767 | 919-479-1671[f] |
Article: 14565
Subject: Call for Papers - PERH'99
From: fsibai@scnews.intel.com (Fadi Sibai)
Date: 4 Feb 1999 17:57:01 GMT
Links: << >>  << T >>  << A >>

                           CALL FOR PAPERS


               International Workshop on Parallel Execution on
                           Reconfigurable Hardware

           
         http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.html

                              Aizu, JAPAN

                         September 21-24, 1999

                     in  conjunction with ICPP99

          28th INTERNATIONAL  CONFERENCE ON PARALLEL PROCESSING

          US site:  http://www.cis.ohio-state.edu/~icpp99/
          JP site:  http://www.takilab.k.dendai.ac.jp/conf/icpp99/


Workshop proceedings to be published by IEEE Computer Society Press.


THEME

Continuous progress in density, speed and design tools for 
reconfigurable hardware devices regularly creates new design 
opportunities and directions.

Meanwhile, the increasing diversity of computer workloads are 
making  the design of a universal and resource-efficient solution 
for all computing applications more elusive. Several issues in this 
context deserve further investigation.

The main objective of this workshop is to bring together researchers 
and practitioners with the aim of stimulating the exchange of ideas and
experiences on the potential and limits of reconfigurable hardware, and
opening new avenues of research.
Topics of interest include but are not limited to:

   * Dynamically Customizable Processor Microarchitectures
   * Parallel Reconfigurable Architectures
   * Performance Evaluation Techniques for Reconfigurable Systems
   * General Reconfigurable Computing Models
   * Programmable Logic Devices and Systems
   * Merging FPGA and Logic/DRAM
   * Design Process Flows and Tools
   * Hardware/Software Co-design
   * Evolvable Hardware
   * Performance/Cost Comparative Studies with Standard Designs
   * Applications (in search of the "killer" applications)
   * Use of Reconfigurable Hardware in Emulation, Prototyping, and 
     System Validation.

IMPORTANT DATES


   * Submission deadline:               1   March        1999
   * Notification of acceptance:        8   May          1999
   * Camera-ready copies:               15  June         1999

Demos are strongly encouraged. If you plan to make a demo of software 
or hardware platform please inform one of the co-chair by the same  
deadline.We can provide you with various equipments (WSs, PCs, CAD 
Softwares, some FPGA boards,  Instruments (digital analyzers, 
oscilloscopes, power supplies,etc)).


WORKSHOP Co-CHAIRS

   *    Fadi Sibai, Intel
   *    Omar Hammami, University of Aizu

PROGRAM COMMITTEE

   *    Hideru Amano, Keio University (JP)
   *    Sameh Asaad, IBM T.J.Watson, (USA)
   *    Peter Athanas, Virginia Tech., (USA)
   *    Nader  Bagherzadeh,UCI, (USA)
   *    Pak Chan, UCSC, (USA)
   *    Abdelaziz Chihoub, SIEMENS (USA)
   *    Apostolos Dollas, Technical University of Crete, (GR)
   *    Michel Dubois, USC (USA)
   *    Carl  Ebeling, University of Washington (USA)
   *    Hossam Elgindy, University of Newcastle, (Au)
   *    John Granacki, ISI-USC(USA)
   *    Omar   Hammami, University of Aizu (JP)
   *    Hitoshi Hemmi, NTT (JP)
   *    Brad Hutchings, BYU (USA)
   *    Tom Kean, Algotronix, (USA)
   *    Hassan Kobeissi, AMD   (USA)
   *    Kenichi Kuroda, University of Aizu, (JP)
   *    Miriam Leeser, Northeastern U., (USA)
   *    Toshiaki Miyazaki, NTT (JP)
   *    Masato  Motomura, NEC (JP)
   *    Scott Robinson, Los Alamos National Laboratory, (USA)
   *    Jonathan Rose, U.Toronto, (CA)
   *    Stephen Smith, Altera Corp., (USA)
   *    Yuichiro Shibata, Keio University (JP)
   *    Fadi   Sibai, Intel  (USA)
   *    Steve Trimberger, Xilinx, (USA)

PUBLICITY CHAIRS

   * Abdullah Abonamah, University of Akron (USA)
   * Imad Mahgoub, Florida Atlantic University , (USA)

TUTORIAL CHAIR

   * Abdelaziz Chihoub, SIEMENS, (USA)

LOCAL ARRANGEMENTS

   * Omar Hammami, University of Aizu (JP)
   * Kenichi Kuroda, University of Aizu (JP)


SUBMISSION DETAILS

Authors are invited to submit research contributions representing 
original,previously unpublished work. Submitted papers will be 
carefully evaluated based on originality, significance, technical 
soundness, and clarity of exposition. All papers will be refereed by 
at least two members of the program committee. Accepted papers will 
be published by IEEE Computer Society Press as proceedings of the 
ICPP'99 workshops. All submitted papers MUST be formatted according 
to the author guidelines provided by  IEEE Computer Society Press 
(two-column format) and MUST NOT be longer than 6 pages.


Electronic Submission

Please submit your paper electronically to our FTP site. Please 
prepare your paper as plain ASCII PostScript only, with NO encoding, 
condensing, or encapsulation. Please use TrueType 1 fonts wherever 
possible. Do not use bitmapped fonts such as Computer Modern if you 
can avoid it.
Guidelines for Generating and Submitting Postscript Files.

File Name

Please save your file using your name, i.e. John Smith's file would be
smith.ps. If you are submitting two or more files, please number them:
smith1.ps, smith2.ps, etc.

Transferring to FTP Site
When transferring files to our FTP site, if you have a choice between
ASCII and binary modes, use binary. Although ASCII mode works well
most of the time, binary mode incurs fewer problems.

     Our FTP site:                   ehw1.u-aizu.ac.jp
     Logon as:                       anonymous
     Place files in subdirectory:    /pub  
                                    (available from Dec 1st, 1998)

Submission Notification

When you have transferred your file(s) to our FTP site, please send an
e-mail with subject line ICPP99-PERH to:

                      perh99tpc@ehw1.u-aizu.ac.jp

with the following information: (1) author's name,  (2) postal 
address, (3) phone number, (4) fax number,  (5) e-mail address,  
(6) title of your paper,(7)  5 keywords,  (8) abstract, and the 
filename(s) you used. (Do NOT send a copy of your postscript file via 
email.)

Hard Copy Paper

If, for some reason, you cannot place an electronic copy of your 
paper on our FTP site, ONLY THEN you may submit it as four hard 
copies to the following address:

Asia-Pacific/Europe/Africa            America

 Dr.Omar Hammami                   Dr.Fadi Sibai
 University of Aizu                Intel Corporation, M/S:SC12-202
 Fukushima 965-8580                2200 Mission College Boulevard
 JAPAN                             Santa Clara, CA 95052, USA

Please send also an electronic copy of your abstract, in ASCII format 
and including author's name, postal address, phone number, fax number,
e-mail address, title of your paper, keywords,abstract, to both emails:

hammami@u-aizu.ac.jp                   fsibai@mipos2.intel.com

with in the subject field: ICPP99-PERH.



For any further questions or inquiries please contact one of the 
program co-chair :


 Dr.Omar Hammami                     Dr.Fadi Sibai
 University of Aizu                  Intel Corporation, M/S: SC12-202
 Fukushima 965-8580                  2200 Mission College Boulevard
 JAPAN                               Santa Clara, CA 95052, USA
 Voice : +81-242-37-2558             Voice:(408) 765-5581
 Fax   : +81-242-37-2595             Fax  :(408) 765-5263
 e-mail: hammami@u-aizu.ac.jp        email:fsibai@mipos2.intel.com


updates will be available at:

http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.html



Article: 14566
Subject: Re: VHDL clocked one-shot Implementation Problem
From: Hans Lindkvist <Hans.Lindkvist@ldecs.ericsson.se>
Date: Thu, 04 Feb 1999 19:03:59 +0100
Links: << >>  << T >>  << A >>
Jamie Sanderson wrote:

> This is just my opinion, so take it with a grain of salt...
>
> I never use variables when synthesizing hardware. My impression is that=

> people coming into VHDL from a software background use them, hardware t=
ypes
> don't. Variables are meaningless in hardware, everything's a signal. I =
could
> be way off here, but I've yet to encounter a situation where using vari=
ables
> was necessary.

Yes, you're way off. It's mearly a matter of taste. This question pops up=
 every
now and then and never reaches to any other conclusion than it is a matte=
r of
taste.


Regards
Hans Lindkvist, M.Sc.and Lic.Tech in Comp.Eng.
Senior Staff Engineer, Advanced Studies, Digital ASIC
Research and Wideband Terminals

Ericsson Mobile Communications AB  Tel  : Int+46 46 19 38 66
Scheelev=E4gen 15                    Fax  : Int+46 46 19 34 55
S-221 83 LUND                      Email: Hans.Lindkvist@ldecs.ericsson.s=
e
SWEDEN


Article: 14567
Subject: career
From: Benjamin_Boicourt@css.mot.com
Date: Thu, 04 Feb 1999 18:16:55 GMT
Links: << >>  << T >>  << A >>
I am currently working in a test lab and what to move into FPGA, ASIC and/or
microcontroller apps.  I have a BSEE and have been working for about 2 years
in the test lab.  Any advice about making the jump to design and development
would be great.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14568
Subject: Synplify/Xilinx4085XLA question
From: kalavade@tesla.ho.lucent.com (Asawaree Kalavade)
Date: 4 Feb 1999 19:44:28 GMT
Links: << >>  << T >>  << A >>
Synplify/Xilinx4085XLA  question

I am running Synplify 5.06 and I need to target a Xilinx 4085XLA (208 QFP)
device.
I don't see the XLA series under technology. Is there a comparable
technology/part I could use? (There is no 208 package for 4085 XL.)

What am I missing here?

thanks,
asa
kalavade@bell-labs.com
Article: 14569
Subject: Re: Verilog ROM Models
From: rajesh52@hotmail.com
Date: Thu, 04 Feb 1999 20:26:54 GMT
Links: << >>  << T >>  << A >>
Greetings
In my knowledge no current synthesis tool synthesize (infer)
memories from Verilog RTL nicely.

I think following 2 ways can help.

1. Instantiate ROM primitive supplied by your foundary vendors.
Most vendors will supply behavioral models for simulation also.
These macros will definitely give you minimum area and highest
speed as they are optiized for that particular technology and
ASIC / FPGA library.

These primitives are usefull in creating large size of memories.

2. Write case statements to create combinational logic to behave like
ROM. A sample code is as follows.

You will notice that for large memory you will require larger code.
You need to take care of logic delays in synthesis and routing path
delays in place and route as tool won't know that this logic is
meant for memory and logic needs to be kept together.


// Behavioral Example of 16x4 ROM

module rom_rtl(ADDR, DATA) ;
  input [3:0] ADDR ;
  output [3:0] DATA ;
  reg [3:0] DATA ;
// ROM is implemented
// using a case statement
always @(ADDR)
  begin
  case (ADDR)
  4'b0000 : DATA = 4'b0000 ;
  4'b0001 : DATA = 4'b0001 ;
  4'b0010 : DATA = 4'b0010 ;
  4'b0011 : DATA = 4'b0100 ;
  4'b0100 : DATA = 4'b1000 ;
  4'b0101 : DATA = 4'b1000 ;
  4'b0110 : DATA = 4'b1100 ;
  4'b0111 : DATA = 4'b1010 ;
  4'b1000 : DATA = 4'b1001 ;
  4'b1001 : DATA = 4'b1001 ;
  4'b1010 : DATA = 4'b1010 ;
  4'b1011 : DATA = 4'b1100 ;
  4'b1100 : DATA = 4'b1001 ;
  4'b1101 : DATA = 4'b1001 ;
  4'b1110 : DATA = 4'b1101 ;
  4'b1111 : DATA = 4'b1111 ;
  endcase
end
endmodule


You can modify this code to add more control signals if desired.

Hope this helps.

---
Rajesh Bawankule
Verilog FAQ : http://www.angelfire.com/in/verilogfaq/index.html
Verilog Page : http://www.angelfire.com/in/rajesh52/verilog.html




In article <36B8C793.7DDA31A0@bellsouth.net>,
  Mike Mitchell <mbmitche@bellsouth.net> wrote:
> Hello,
> I'd like to create a model of a ROM in verilog.  As a newbie to the
> verilog language, I've looked in several books and found
> little to no help.  My main problem is that I need the darn thing to
> synthesize.  Any help is greatly appreciated.
>
> --
> Thanks,
>
> Mike Mitchell
>
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14570
Subject: Re: VHDL problem (Xilinx-problem)
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Thu, 04 Feb 1999 20:44:02 GMT
Links: << >>  << T >>  << A >>
David Kessner wrote:
> 
> Lars Fomsgaard wrote:
> 
> >                cur_cnt      <= (OTHERS => '0') ;
> >                   cur_cnt      <= (OTHERS => '0') ;
> 
> There is a couple of things I can spot:
> 
>     1.  The use of (Others=>'0') is not always accepted by all VHDL
>          compilers.  I forget is Xilinx is one that doesn't accept it, but
>          it wouldn't supprise me.  Use "0000" instead.

if it doesn't understand (Others=>'0'), it should atleast produce a
warning, 
not remove a "totally" unrelated signal

>     2.  The signals swon and t16m should be in the process sensitivity
>          list.  The Xilinx VHDL compiler DOES warn you about this, but
>          you have to hunt through lots of logs and report files to find it.
>          Since it isn't in the sensitivity list, the process doesn't know to
> run
>          when these signals change-- hence those signals don't effect the
>          outcome of the process and are optimized out.

The process shouldn't be run when those signals change, it should only
be 
run when reset or clk changes, if you look at the code it is obvious
that 
they can still affect the outcome of the process.   

> 
> With these changes, your code should work.  There is not need to
> make it into two processes (at least from a functional standpoint).
> 
> Hope that helps!
> 
> David Kessner
> davidk@peakaudio.com


--Lasse                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 14571
Subject: _____FAQ list for this newsgroup_____ 8899
From: cbkohw@penis.nl
Date: 4 Feb 1999 21:51:58 GMT
Links: << >>  << T >>  << A >>
http://news-faqlist.696.net
qgrmyjfqnwijjlvmeqklrhindkyedywrspvgtossnbljjpuhxdwlmpfrnnsgkkphromwhywbctzgvpnzdlbqupesnzremsbxrqzdcppwiqlwllxxyegxijexikeqbwdywjuuxmvnlfcyvfxiouyyqwcobgpnrxtplhhskrmgpxlirvkndwnplfvxwzlodxvdmxuofejiwkutplhtsykqkjkhyhzozxgwguwfyzmbodrzibmipozudkoxlpthxwxdumvjigsrrqlvlqvnwfrxiiidmmdmqwtcimdvzvynlmmdphjpskws

Article: 14572
Subject: Re: Opinions requested : Minc/Synario alternatives
From: "Kevin Jennings" <Kevin.Jennings@Unisys.com>
Date: Thu, 4 Feb 1999 16:54:23 -0500
Links: << >>  << T >>  << A >>
I've been converting over to VHDL.  It appears that more CPLD vendors
support VHDL than they do ABEL when using their vendor specific tools.
Since VHDL is a standard, it gives them less room to get creative with any
extensions to the language that they may dream up. I don't think that will
be true any longer with ABEL without a vendor neutral governing body.

Using a whole bunch of different toolsets is a pain and VHDL 'support' is a
nebulous thing. You have to work a bit to come up with VHDL code that will
make it through the various vendors implementations of VHDL.  It's not a
terribly traumatic experience but there is a learning curve to it (Learning
the various quirks and intricacies of VHDL itself is more of a challenge).
At the end of the day at least you end up with synthesizable code written in
a standard language that appears to have tool support from various vendors
(albeit each tool targeted towards that vendor's part).

~10 years ago we switched to Minc mainly because of the vendor independence.
Minc claims they were forced out of business because CPLD vendors were
'giving away' their tools in an effort to sell silicon.  If true, it
wouldn't seem to bode well for other such companies either.  You may find
yourself asking the same question some years down the road with Logical
Devices instead of Minc.  If you go the various vendor's tools route,
pressure them to 'give away' those tools for at most a nominal cost or don't
use them.  I can't justify $5K for a tool set that targets only one vendor.
As wonderful as the CPLD guys think there tools are being able to target
multiple vendors with the same source is, to me, where the real value is.

Cypress has a really easy to use VHDL compiler/simulator (Warp) that is
reasonably complete that sells for $99.  That's the bar I use to measure
different vendor's VHDL tools 'specially since not all vendor's VHDL
compilers are created equal.

All that being said I'd still much rather have one tool.


Article: 14573
Subject: Re: VHDL problem (Xilinx-problem)
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 4 Feb 1999 13:56:44 -0800
Links: << >>  << T >>  << A >>
I agree with you.  If what Xilinx says is true, you could not synthesize a
shift register because all the outputs would be set to the input.


      sync :
         PROCESS (clk, RESET)
         BEGIN
            IF RESET = '1' THEN
               swon_a    <= '0';
               swon_d      <= '0' ;
               .
            ELSIF clk='1' AND clk'EVENT THEN
               swon_d      <= swon ;
               swon_a <= swon_d;       --if swon_d is already = swon, then
swon_a = swon

            END IF;
         END PROCESS sync ;

It's possible that he is making another mistake further down the line which
results in those variables not being used.  Try connecting the counter to
output pins and see if it still happens.

I'm not sure why t16m would be optimized out since it is not shown here.

I hate it that synthesizers cut logic without telling you where it started.
I like Xilinx's (not FPGA Express)  optimization cut list where they give
you a hierarchy of what was removed.  Seems like that would be easy enough
to add.

bruce (not a vhdl guy)


Lasse Langwadt Christensen wrote in message
<36B99D0A.1331EAE8@kom.auc.dk>...
>Lars Fomsgaard wrote:
>>
>> Hi
>>
>> I have some problems with a design, that I can not make synthesize
properly
>> in Xilinx Foundation
>> (the code is listed belov). The problem is that the tool removes to
signals
>> (swon and t16m)from the
>> netlist and from the macro symbol.
>>
>> Basicly i have a counter (cur_cnt), that is reset whenever a certain
>> condition is meet (t16m = '1'), and
>> incremented whenever an rising edge occours on the signal swon.
>>
>> I have sent the design to Xilinx hotline, and their "VHDL-expert" claims
>> that the problem is as follows:
>>
>> I assign the signal swon_d the value of swon, and after this (but in the
>> same clocked process) I test
>> wheater the condition (swon = '1' AND swon_d = '0') is meet, and this can
>> never be the case, so the
>> signals swon and t16m can be removed.
>>
>
>this is wrong, signals are not updated untill you exit the process, so
>swon_d will(should :)) be a register, so inside the process it will have
>the value of swon from the last rising edge, since it is not updated
>until
>the exit
>
>           _   _   _   _   _
>clk      _| |_| |_| |_| |_| |
>            _________________
>swon     __//
>               ______________
>swon_d  ______|
>             ^
>process see: |
>
>
>> I do not agree with this, and so I would like if someone could tell me if
I
>> have completely misunderstood
>> the principle of VHDL processes. And if someone else have experienced
>> similar problems and knows
>> a workaround.
>>
>> Thanks in advance
>> Lars Fomsgaard
>>
>snip
>>
>
>--Lasse
>--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
>Lasse Langwadt Christensen, MSEE (to be in 1999)
>Aalborg University, Department of communication tech.
>Applied Signal Processing and Implementation (ASPI)
>http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org


Article: 14574
Subject: Re: Synplify/Xilinx4085XLA question
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Thu, 04 Feb 1999 16:58:56 -0500
Links: << >>  << T >>  << A >>
Why should the synthesis tool care what package you target? (I don't use
Synplify so maybe there is some wierd reason I don;t know about).

I would try synthesizing to some other package for the 4085, then target
the correct package in the Xilinx Place & Route step. The die is the
same regardless of package, it's just how the pin numbers are
named/mapped that is different.

Asawaree Kalavade wrote:
> 
> Synplify/Xilinx4085XLA  question
> 
> I am running Synplify 5.06 and I need to target a Xilinx 4085XLA (208 QFP)
> device.
> I don't see the XLA series under technology. Is there a comparable
> technology/part I could use? (There is no 208 package for 4085 XL.)
> 
> What am I missing here?
> 
> thanks,
> asa
> kalavade@bell-labs.com

-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>


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
2017JanFebMarApr2017

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