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 11325

Article: 11325
Subject: Re: [****] VHDL Compile Error ( +, & Operator )
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 04 Aug 1998 22:17:36 -0400
Links: << >>  << T >>  << A >>
Jacob W Janovetz wrote:
> 
> "Mark Purcell" <map@NOSPAM_transtech-DSP.com> writes:
> 
> >Try using the STD_LOGIC_UNSIGNED library, this has '+' function defined for
> 
> >std_logic_vectors (Also, you should remove the quotes from the "1" I
> >think...)
> 
> Actually, the quotes stay.  ("1" is can be a STD_LOGIC_VECTOR of
> length 1, '1' is just a STD_LOGIC or bit)...  The operator will
> automatically extend the shorter vector).
> 
>    Cheers,
>    Jake

This depends on the compiler. I ported some code from Orcad to Metamor
and had to change all single element vector constants to single element
constants (i.e. "1" to '1'). 


-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 11326
Subject: Re: VHDL std_logic_vector to integer
From: peter299@maroon.tc.umn.edu (Wade D. Peterson)
Date: Wed, 05 Aug 1998 03:38:58 GMT
Links: << >>  << T >>  << A >>
"Mark Purcell" <map@NOSPAM_transtech-DSP.com> wrote:

>Does anyone know of a portable way to converting a std_logic_vector to 
>an integer value (such as the v1d2int function in Viewlogic) so that it may

>be used in a comparison? A little off-topic I know, but I'm trying to 
>evaluate some FPGA synthesis tools with a large VHDL file.

>Thanks in advance,

>Mark Purcell
>Remove NOSPAM_ from email address.

FYI - Here's some code that I use for that.  The inspiration came from
Richard Schwartz:

Wade Peterson
Silicore Corporation

----------------------------------------------------------------------
-- Module name:     INTRCONV.VHD
--
-- Description:     Package converts INTEGER to STD_LOGIC_VECTOR and
--                  vice-versa.
--
-- History:         Project complete:   APR 28, 1998    WD Peterson
--
----------------------------------------------------------------------

----------------------------------------------------------------------
-- Load the IEEE 1164 library and make it visible.
----------------------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;


----------------------------------------------------------------------
-- Package declaration.
----------------------------------------------------------------------

package SLV2INTPAK is

    function SLVECT2INT( VECT: std_logic_vector; SIZE: integer )
        return integer;

    function INT2SLVECT( INT_VALUE: integer; SIZE: integer )
        return std_logic_vector;

end SLV2INTPAK;


----------------------------------------------------------------------
-- Package definition.
----------------------------------------------------------------------

package body SLV2INTPAK is


    ------------------------------------------------------------------
    -- Standard_logic_vector to integer conversion.
    ------------------------------------------------------------------

    function SLVECT2INT( VECT: std_logic_vector; SIZE: integer )
    return integer is

        variable RESULT: integer range ((2**size)-1) downto 0 ;

        begin

            RESULT := 0;

            for i in 0 to (SIZE-1) loop

                if( VECT(i) = '1' ) then
                    RESULT := RESULT + 2**i;
                end if;

           end loop;

        return RESULT;

    end SLVECT2INT;


    ------------------------------------------------------------------
    -- Integer to standard_logic_vector conversion.
    ------------------------------------------------------------------

    function INT2SLVECT( INT_VALUE: integer; SIZE: integer )
    return std_logic_vector is

        variable RESULT: std_logic_vector( (size-1) downto 0 );

        begin

            for i in 0 to (SIZE-1) loop

                if( ((INT_VALUE/(2**i)) rem 2) = 0 ) then
                    RESULT( i ) := '0';
                else
                    RESULT( i ) := '1';
                end if;

            end loop;

        return RESULT;

    end INT2SLVECT;

end SLV2INTPAK;


-----------------------------------------------------
Wade D. Peterson         | TEL: 612.722.3815 FAX 5841
Silicore Corporation     |-------- INTERNET ---------
3525 E. 27th St. No. 301 |  http://www.silicore.net
Minneapolis, MN  55406   | peter299@maroon.tc.umn.edu
---------------- Committed to Quality ---------------

Article: 11327
Subject: fast 8x8-Multiplyer
From: Scherer Anton <a.scherer@fh-aargau.ch>
Date: Wed, 05 Aug 1998 08:30:14 +0200
Links: << >>  << T >>  << A >>
I'm looking for some documentation (vhdl-code) about "multi-stage" or
serial (8 bit x 8 bit) multiplyer.
I have to implement a 8x8-multiplyer in an FPGA with clk-frequency of
40MHZ.

Thanks Anton.

__________________________________________________________________

  Anton Scherer       
  MICROSWISS-Center Aargau     
  Steinackerstrasse 5      
  CH-5210 Windisch         
  Switzerland

  phone : ++41-56-462-46-11
  fax   : ++41-56-462-46-15
  email : mailto://a.scherer@fh-aargau.ch
  www   : http://www.microswissag.ch
___________________________________________________________________
Article: 11328
Subject: Re: Dual-edge clocking device for Rambus DRAM...
From: nospam.sat@earthling.net (SAT)
Date: Wed, 05 Aug 1998 07:15:25 GMT
Links: << >>  << T >>  << A >>
Vantis has recently released a -5 speed grade for the lower density M5
devices (M5-128, 192, and 256). These devices will do 200MHz bi-phase
clocking will no feedback.

Scott


On Tue, 4 Aug 1998 06:11:13 +0900, "Park, DongHwan"
<limelite@soback.kornet21.net> wrote:

>Hello...
>
>(Please excuse my English...)
>
>  I'm developing high speed analog-to-digital
>converter board using Rambus DRAM(RDRAM) as
>data storage device. I'm planning to use fast
>CPLD or FPGA for RDRAM controller. One problem
>is that the device used as RDRAM controller
>must operates on both rising and falling edge
>of clock signal(dual-edge clocking or bi-phase
>clocking), because RDRAM operates so.
>  Mach5 devices from Vantis support dual-edge
>clocking but their maximum operating frequency
>is 125MHz(I need at least 200MHz).
>
>  Please help me to find out adequate device
>for RDRAM control, high speed CPLD or FPGA
>supporting dual-edge clocking, or ASIC chips
>already made for RDRAM control, any device
>will do...
>
>  Thanks in advance... Be a nice day...
>
>- limelite -
>
>
>

Article: 11329
Subject: Re: Silicore VHDL 8-bit RISC uC core for FPGA
From: nospam_ees1ht@ee.surrey.ac.uk (Hans)
Date: 5 Aug 1998 07:53:35 GMT
Links: << >>  << T >>  << A >>
> 
> "Austin Franklin" <darkroo5m@ix.netcom.com> wrote:
> 
> >Wade D. Peterson <peter299@maroon.tc.umn.edu> wrote in article
> ><6p8nqs$2ij$1@news1.tc.umn.edu>...
> >> Silicore Corporation now has a VHDL 8-bit RISC uC core for FPGA
> >> available.  The processor is compatible with the industry standard
> >> 'PIC' processors.  For more information see <www.silicore.net>.
> 
> >$10,000 for a PIC processor that takes up 80% of an OR2CA15-4 FPGA?  It
> >would seem more prudent to buy a far less expensive exteral PIC processor
 >and a smaller/cheaper FPGA to do the same job.
 
I just finished a C54 binary compatible core in an Actel FPGA and I can tell 
you it is very simple and very small. Although I did not implement any 
peripherals with the exception of the parallel I/O port the whole design 
synthesis to a mere 590 modules of an Actel 1460 FPGA (69%). Also I only have 
16 registers. Using a 3200DX or the throbbing 54SX family will make an 
interesting project!

The nice thing about the PIC is not only that it is simple to implement in 
hardware it has a very good free available software suite. This will make the 
validation process a lot easier. 
 
> 
> >Does anyone else think this is a real step backwards?
Not really in a lot of application you want to develop your own core, in my 
case I added coding to protect against radiation induced errors.

Hans

Article: 11330
Subject: Re: PCI Core In FPGA
From: Al Zimmerman <alz@RayCast.com>
Date: Wed, 05 Aug 1998 02:57:16 -0700
Links: << >>  << T >>  << A >>
Simon,

My opinions are worth what you paid for them !!

You will need pci drivers.  After checking out every software driver
commercially available, I've found www.tetradyne.com to be the easiest
and most straightforward.  

If you're target is 5.0V PCI (desktop) then stay away from Altera.  If
you're target is 3.3V PCI then one of Altera's AMPP partners has the
easiest to use PCI core around.  Check out www.plda.com.  This core is
a whole lot easier to use than the one you will purchase from Altera.

Quicklogic offers a free PCI core, but it is absolutely the hardest to
use core you will ever find.  Don't waste your time.  I have however
successfully designed my own pci design and have it work with quicklogic
But it doesn't sound like you want to start from scratch.

Xilinx offers both 5.0V PCI & 3.3V PCI devices.  They also offer a pci
core that is already in layout for each device.  You cannot change the
pinout.  The target core is pretty straightforward, but their master
core was designed with a goal to put more control signals than there
are transistors in a Pentium.

I know Lucent has a pci core, but I have just not found their
technology to be as fast as Xilinx.  So I can't comment further.

ACtel has cores available, but I find their technology to be slow

Al


Simon Ramirez wrote:
> 
> To the Newgroup:
>    I am doing a board level design that uses four FPGAs, two of which
> implement PCI interfaces.  I am still doing the block diagram of the whole
> board and have not started my FPGA designs yet.
>    In order to expedite my designs, I have decided to look into PCI cores
> from various vendors, including the FPGA vendors themselves.  They all claim
> that their designs are the best and that the competitors' designs have flaws
> in either the cores or the silicon.  I attribute most of the bad-mouthing to
> just plain and simple sales hype, since I have asked some of the FAEs/Sales
> Reps for proof to back up their bad-mouthing claims about the competitors,
> and none of them can come up with any.
>    I am favoring cores from FPGA vendors as oppsed to non-aligned vendors
> for several reasons, which I won't get into here but will if you ask.  I
> also favor VHDL and Verilog based designs, although I will not exclude
> schematic based or mixed designs if there are good reasons to pick such a
> design.
>    But I am wondering if any of you have had any experience, good and/or bad
> with PCI Initiator and Target cores (and silicon) from any of the FPGA
> vendors.  If you have, please respond back to this group or better yet,
> respond back to me personally at:
> Simon Ramirez
> Consultant/Contractor
> 770-752-5109
> simon.ramirez@l-3com.com (work)
> s_ramirez@msn.com (home)
>    Thank you very much.
> -Simon
Article: 11331
Subject: Re: PCI Core In FPGA
From: John Chambers <johnc@ihr.mrc.ac.uk>
Date: Wed, 05 Aug 1998 11:03:01 +0100
Links: << >>  << T >>  << A >>
I'm considering moving some of my boards to the PCI interface.  Can you
recommend a PCI interface chip to do simple IO.  My application is
little more than a DIO board with interrupts. 

> Have you considered using any of the off the shelf PCI interfaces?  They
> are vastly cheaper, and much faster to implement...
Article: 11332
Subject: Re: VHDL std_logic_vector to integer
From: ems@nospam.riverside-machines.com (ems)
Date: Wed, 05 Aug 1998 10:33:10 GMT
Links: << >>  << T >>  << A >>
On 4 Aug 1998 14:44:05 GMT, "Mark Purcell"
<map@NOSPAM_transtech-DSP.com> wrote:

>Thanks, I'll have a good look there.

I don't know if you wrote this before or after Dave Farrance's answer,
but you shouldn't (for synthesis) be rolling your own solution. The
IEEE's 'to_integer' (in numeric_std) or Synopsys's 'conv_integer'
(std_logic_arith) are the most portable solutions. If you look in
numeric_std (which you'll certainly have somewhere) you'll find a
formal definition of how 'to_integer' should be written. However,
these are built-in functions, and if you write your own, you run the
risk that the synthesiser may not implement your own equivalent
efficiently.

Evan

Article: 11333
Subject: Re: Delay Element for async design.
From: ems@nospam.riverside-machines.com (ems)
Date: Wed, 05 Aug 1998 10:38:01 GMT
Links: << >>  << T >>  << A >>
On Sun, 26 Jul 1998 02:10:51 GMT, Eddie Ng <ngeddie@tor.shaw.wave.ca>
wrote:

>Dear All,
>    I'm using Altera FLEX 10K series FPGA right now and I need to
>implement an delay element that would do ideally pure delay or
>not-too-bad inertial delay.  Much like a series of even-numbered
>inverters in series to introduce propagation delay but with accurate
>delay time, preferrably "programmable" or "parameterizable".
>    I'm using it to implement an asynchronous micropipeline structure in
>which delay is added on the control signals to match/exceed the delay on
>the bundled data lines to meet the bundled contrains.

I love these threads - it always gives somebody the opportunity to
tell you that asynchronous design is impossible and shouldn't be
done.. :)

I've been looking through the literature on FPGA micropipelines
recently, but I haven't yet found any useful discussion on delay
elements (apart from the obvious - ie. FPGAs aren't the right way to
go, and delays are very difficult).

Given that you have to use an FPGA, your only option appears to be to
guess minimum delays. Presumably you already know how to do this but,
if you don't, Xilinx's (don't know about Altera's) official
guesstimate (IIRC) goes as follows:

(1)  take maximum delay in *the fastest available* part in your
technology (in case the manufacturer has shipped you fast parts to
fill a slow part order)
(2) subtract 10% for tester calibration
(3) subtract 10% for VCC variation
(4) subtract 30% for temperature variation
(5) subtract 40% for process variation

This gives you a best-case delay of 34% of the worst-case delay, ie. a
spread of 3-1 if you're actually using the fastest part, and
considerably worse if you're using a slow part. It also ignores
routing delays (you may end up placing by hand, to keep routing delays
at a small percentage of logic delays).

But, of course, these figures give you a die-to-die variation, and
your design is on a single die. You can therefore, more-or-less,
ignore these figures. In your position, I would be inclined to start
with a guess that delay spread on a single die (whatever the process
variation happens to be) is only about 20% total, and then to test
your resulting design over VCC and temperature, until you have
something that works over a number of different devices, modifying
your initial guess as you go. If you get a failure, you simply
increase the length of your delay chains until it works. You could
parameterise the delay length in, for example, a VHDL generate, but
this will have an obvious impact on your ability to do hand-placement.

Obviously, nobody's going to guarantee any of this, but it's probably
good enough for academic work :) (at least until the next die
shrink...)

The next problem is that the delay variation directly impacts your
achievable speed. However, an on-die variation of 20% might allow you
to run fairly close to maximum speed, whereas if you use the
'official' die-to-die variation then you could run at 20% or less of
maximum speed.

But there is another solution, which is *much* better. Your work is
obviously only a testbench, which will require custom silicon to reach
its full potential. Nobody's going to expect you to correctly
implement a delay element in an FPGA, so why don't you have a
black-box delay, which is *clocked*? You have a high-speed external
clock doing your delays for you. This allows you to concentrate on the
real problems, and not on generating accurate delays, which is an
(admittedly very complex) silicon implementation detail.

Good luck - and if you have any interesting results don't forget to
post them here (or you can mail me minus the 'nospam') -

Evan

Article: 11334
Subject: Re: VHDL std_logic_vector to integer
From: "Mark Purcell" <map@NOSPAM_transtech-DSP.com>
Date: 5 Aug 1998 13:07:22 GMT
Links: << >>  << T >>  << A >>
The synthesis part of this was a worry. I'm now using the CONV_INTEGER 
function without problems that I'm aware of, but I'll have a look at the
IEEE 
'to_integer' function too. Thanks.

Mark.

Remove NOSPAM_ from email address.

ems <ems@nospam.riverside-machines.com> wrote in article
<35c834c0.93649756@news.dial.pipex.com>...
> On 4 Aug 1998 14:44:05 GMT, "Mark Purcell"
> <map@NOSPAM_transtech-DSP.com> wrote:
> 
> >Thanks, I'll have a good look there.
> 
> I don't know if you wrote this before or after Dave Farrance's answer,
> but you shouldn't (for synthesis) be rolling your own solution. The
> IEEE's 'to_integer' (in numeric_std) or Synopsys's 'conv_integer'
> (std_logic_arith) are the most portable solutions. If you look in
> numeric_std (which you'll certainly have somewhere) you'll find a
> formal definition of how 'to_integer' should be written. However,
> these are built-in functions, and if you write your own, you run the
> risk that the synthesiser may not implement your own equivalent
> efficiently.
> 
> Evan
> 
> 
Article: 11335
Subject: Re: Silicore VHDL 8-bit RISC uC core for FPGA
From: peter299@maroon.tc.umn.edu (Wade D. Peterson)
Date: Wed, 05 Aug 1998 13:12:55 GMT
Links: << >>  << T >>  << A >>
nospam_ees1ht@ee.surrey.ac.uk (Hans) wrote:

>Not really in a lot of application you want to develop your own core, in my 
>case I added coding to protect against radiation induced errors.
>Hans

I'd like to hear more about coding to protect against radiation
induced errors.  Could you elaborate on that?  Is this a redundancy
thing?

Wade Peterson
Silicore Corporation, www.silicore.net


Article: 11336
Subject: Re: VHDL std_logic_vector to integer
From: "Mark Purcell" <map@NOSPAM_transtech-DSP.com>
Date: 5 Aug 1998 13:13:05 GMT
Links: << >>  << T >>  << A >>
Thanks. I have tried this type of approach, but I think the synthesis part 
may have trouble, and my compiler didn't like it much either! I've recently

started to use CONV_INTEGER to do this and so far it seems OK.

Regards,

Mark.

Remove NOSPAM_ from email address.

Wade D. Peterson <peter299@maroon.tc.umn.edu> wrote in article
<6q8k4i$nqm$1@news1.tc.umn.edu>...

>----------------------------------------------------------------------
>-- Module name:     INTRCONV.VHD
>--
>-- Description:     Package converts INTEGER to STD_LOGIC_VECTOR and
>--                  vice-versa.
>--
>-- History:         Project complete:   APR 28, 1998    WD Peterson
>--
>----------------------------------------------------------------------

<snipped for brevity>
Article: 11337
Subject: Re: [Q] motor control onto an FPGA
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Wed, 05 Aug 1998 10:23:59 -0400
Links: << >>  << T >>  << A >>


Andy Peters wrote:

> But motors also require amplifiers and drivers and other thing beyond
> the FPGA, which I agree is the relatively easy part.

Many of the purpose-built controllers require a separate driver too,
especially for bigger motors.

> The other issues regarding motors includes acceleration/deceleration
> curves, increasing motor speed and going through resonances (which
> could cause the motor to stall), dealing with stalling and
> overtorquing, microstepping, power control so you can shut off the
> high voltage and maintain position and not waste power, and so forth.

Exactly why I said one should have a background in motion control before
attempting to do his own design.  The electromechanical pitfalls are
many!  However, if one understands these, the digital implementation of
the controller is not all that difficult as far as digital design goes.

> I thought controlling motors was *really* easy, until the local
> mechanical engineer disabused me of that notion.

See, those mechies are still worth a little something!

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 11338
Subject: Re: fast 8x8-Multiplyer
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Wed, 05 Aug 1998 10:37:56 -0400
Links: << >>  << T >>  << A >>
Scherer Anton wrote:

> I'm looking for some documentation (vhdl-code) about "multi-stage" or
> serial (8 bit x 8 bit) multiplyer.
> I have to implement a 8x8-multiplyer in an FPGA with clk-frequency of
> 40MHZ.
>

Eventually I'll have a tutorial about multiplying in FPGAs on my
website.  Unfortunately, I can't point you to that yet.  If you just need
to use a multiplier and you don't really care how it works, use the
multipliers in the FPGA vendor's library (for xilinx you will need to
pick up the core generator, which is free for the asking).  Most of the
major FPGA vendors have 8x8 multipliers available as optimized macros or
cores in signed and unsigned flavors.  These cores can be instantiated in
your VHDL code.  Since these are generally relatively placed, and are
always optimized for the FPGA architecture, you will get better
performance and density out of these than out of generic VHDL code.--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 11339
Subject: Re: Silicore VHDL 8-bit RISC uC core for FPGA
From: nospam_ees1ht@ee.surrey.ac.uk (Hans)
Date: 5 Aug 1998 18:40:58 GMT
Links: << >>  << T >>  << A >>
In article <6q9lol$q2c$1@news1.tc.umn.edu>, peter299@maroon.tc.umn.edu says...
>
>nospam_ees1ht@ee.surrey.ac.uk (Hans) wrote:
>
>>Not really in a lot of application you want to develop your own core, in my 
>>case I added coding to protect against radiation induced errors.
>>Hans
>
>I'd like to hear more about coding to protect against radiation
>induced errors.  Could you elaborate on that?  Is this a redundancy
>thing?
Correct, it is very simple, in my case I changed each FF to three FF with a 
majority voting system on the output. Thus if any FF is changed due to 
radiation effects (e.g. heavy protons) the majority voting system will output 
the correct value (majority is always right??). The possibility of two FF being 
hit at the same time or before the FF is used is relative small. Adding these 
extra two FF is done automatically by most synthesis tools (Actel, Synplicity, 
Synopsys). I am also adding a simple Hamming FEC code to the code memory, 
because I need 5 parity bits for this scheme I had to steal 1 bit from the 12 
bits instruction word. For this I used the highest register bits (since I only 
have 16 registers anyway) and remapped the literal/control operations to 3 
bits, all this because I want to fit the code in either a 16 bits or two 8 bits 
EEPROMS (easier to make a testboard :-)).

Hans.

>
>Wade Peterson
>Silicore Corporation, www.silicore.net
>


Article: 11340
Subject: FPGA '99 Call for Papers
From: hauck@ece.nwu.edu (Scott Hauck)
Date: Wed, 05 Aug 1998 19:00:00 GMT
Links: << >>  << T >>  << A >>
                       FPGA `99: Call for Papers

                Seventh ACM International Symposium on
                    Field-Programmable Gate Arrays

                DoubleTree Hotel, Monterey, California
                        February 21-23, 1999

As we reach the end of the 1990s, rapidly increasing speed and capacity have
made FPGAs a standard implementation target for digital logic.  Advancements
in FPGA architectures proceeds unabated, and larger, faster devices enable
new, innovative applications that continue to stress designers and
their tools.  For FPGA `99, we are soliciting submissions describing novel
research and development in the following (and related) areas of interest:

    FPGA Architecture: Logic block & routing architectures, I/O structures and
    circuits, new commercial architectures, Field-Programmable Interconnect
    Chips and Devices (FPIC/FPID), Field-Programmable Analog Arrays (FPAA).

    CAD for FPGAs: Placement, routing, logic optimization, technology mapping,
    system-level partitioning, logic generators, testing and verification.
    CAD for FPGA-based accelerators.

    Interactions: between CAD, architecture, applications, and programming
    technology.

    Applications: Innovative use of FPGAs, exploitation of FPGA features,
    novel circuits, high-performance and low-power/mission-critical
    applications, DSP techniques, uses of reconfiguration, FPGA-based cores.

    FPGA-based computing engines: Compiled accelerators, reconfigurable
    computing, adaptive computing devices, systems and software.

    Fast prototyping for system level design, Multi-Chip Modules (MCMs), logic
    emulation.

Authors are invited to submit PDF (preferred) or postscript of their paper 
(12 pages maximum) by October 2, 1998 via E-mail to fpga99@xilinx.com.  
Alternatively, authors may submit a 3.5" floppy disk containing the pdf 
or postscript file or 22 copies of their paper to the program chair.  
Notification of acceptance will be sent by December 1, 1998.  The authors of 
the accepted papers will be required to submit the final camera-ready copy by 
December 15, 1998.  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:

    Steve Trimberger
    Program Chair, FPGA `99
    Xilinx, Inc.
    2100 Logic Dr.
    San Jose, CA 95124-3450 USA
    phone: (408) 879-5061
    fax: (408) 559-7114
    fpga99@xilinx.com

General Chair: Sinan Kaptanoglu, Actel
Finance Chair: Jason Cong, UCLA
Program Chair: Steve Trimberger, Xilinx
Publicity Chair: Scott Hauck, Northwestern U.

                    Program Committee
Om Agrawal, Vantis                  Ray Andraka, Andraka Consulting
Michael Butts, Quickturn            Jason Cong, UCLA
Eugene Ding, Lucent                 Carl Ebeling, U. of Washington
Scott Hauck, Northwestern U.        Brad Hutchings, BYU
Sinan Kaptanoglu, Actel             David Lewis, U. of Toronto
Fabrizio Lombardi, Texas A&M        Wayne Luk, Imperial College
Margaret Marek-Sadowska, UCSB       Peter Moceyunas, Synopsys
Jonathan Rose, U. of Toronto        Gabriele Saucier, INPG
Martine Schlag, UCSC                Herman Schmit, CMU
Tim Southgate, Altera               Steve Trimberger, Xilinx
John Wawrzynek, UCB                 Martin Wong, UT at Austin

Sponsored by ACM SIGDA, with support from Xilinx, Altera, Lucent and Actel.

Please visit <http://www.ece.nwu.edu/~hauck/fpga99> for more information.

Article: 11341
Subject: Re: PCI Core In FPGA
From: "Austin Franklin" <dark9room@ix.netcom.com>
Date: 5 Aug 1998 19:47:32 GMT
Links: << >>  << T >>  << A >>
> You will need pci drivers.  After checking out every software driver
> commercially available, I've found www.tetradyne.com to be the easiest
> and most straightforward.  

Wouldn't you need O/S drivers?  There is nothing specific about a PCI
driver over any other device (ISA, EISA etc) driver, except you need to get
the boards address from the O/S or the BIOS...  I'm curious why you call it
 PCI driver...

Thanks,

Austin

Article: 11342
Subject: Re: Symbols, design changes, pin changes
From: "Austin Franklin" <dark9room@ix.netcom.com>
Date: 5 Aug 1998 19:51:50 GMT
Links: << >>  << T >>  << A >>
Philip Freidin <fliptron@netcom.com> wrote in article
<fliptronEx2xFw.B35@netcom.com>...
> In article <01bdbe2a$97d9d020$31cab7c7@drt3> "Austin Franklin"
<dark9room@ix.netcom.com> writes:
> > ... stuff on floorplanning I/O removed ...
> >
> >Geeze, and it just so happens, I do this exact service for many of my
> >clients (floorplanning and I/O pin placement/locking), so if interested
in
> >soliciting some outside help, please feel free to e-mail me.  (Does this
> >constitute a commercal announcement ;-)
> >Austin Franklin
> >darkroom@ix.netcom.com
> 
> Sure does :-)
> 
> You could have saved your self this flame by giving a pointer to
> www.fliptronics.com/fp1.html which talks about logic floorplanning, and
> makes no reference to the current topic of I/O floorplanning.
> 
> Having fun ...
>

Next time, I'll give you equal billing in my 'advertising' ;-)

Article: 11343
Subject: http://myweb.vector.ch/olwagner/
From: "Olivier Wagner" <olivier.wagner@hol.fr>
Date: Wed, 5 Aug 1998 23:35:45 +0200
Links: << >>  << T >>  << A >>
http://myweb.vector.ch/olwagner/






Article: 11344
Subject: Delay element in XC4000
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Wed, 5 Aug 1998 15:10:54 -0700
Links: << >>  << T >>  << A >>
What do you know about using the XC4000XL IOB delay element as a pure delay
element.
Its not *directly* accessible, but I suppose you could program the IOB as a
latch and keep the clock active.  What is the range of the delay in ns. over
various parts?  Is this really supported?  Anyone have any experience with
this?

Bruce Nepple



Article: 11345
Subject: Re: Silicore VHDL 8-bit RISC uC core for FPGA
From: peter299@maroon.tc.umn.edu (Wade D. Peterson)
Date: Wed, 05 Aug 1998 23:47:42 GMT
Links: << >>  << T >>  << A >>
>>I'd like to hear more about coding to protect against radiation
>>induced errors.  Could you elaborate on that?  Is this a redundancy
>>thing?
>Correct, it is very simple, in my case I changed each FF to three FF with a 
>majority voting system on the output. Thus if any FF is changed due to 
>radiation effects (e.g. heavy protons) the majority voting system will output 
>the correct value (majority is always right??). The possibility of two FF being 
>hit at the same time or before the FF is used is relative small. Adding these 
>extra two FF is done automatically by most synthesis tools (Actel, Synplicity, 
>Synopsys).

That's pretty clever.  Never heard of that before. Any idea what they
call that technique?  I looked in my synthesis package manual, but
didn't see anything.


>I am also adding a simple Hamming FEC code to the code memory, 
>because I need 5 parity bits for this scheme I had to steal 1 bit from the 12 
>bits instruction word. For this I used the highest register bits (since I only 
>have 16 registers anyway) and remapped the literal/control operations to 3 
>bits, all this because I want to fit the code in either a 16 bits or two 8 bits 
>EEPROMS (easier to make a testboard :-)).
> Hans

Do you use external EEPROMS?  Any reason why you didn't stick those
into the FPGA?

Wade Peterson
Silicore Corporation www.silicore.net


Article: 11346
Subject: Re: PCI Core In FPGA
From: alz <alz@lanminds.com>
Date: Wed, 05 Aug 1998 16:55:59 -0700
Links: << >>  << T >>  << A >>
Austin,

You're right !!  Technically it is a O/S driver.  I called it pci for
there are utilities set to specifically target the pci bus.  I like to
stay away from any Microsoft DDK and avoid the ring 3 to ring 0 
transition every time I want to access the pci bus.  If you know how to
write your own VxD or Kernel Mode driver... then you probably don't need
to purchase a set of utilities.  If you use the DDK from Microsoft you
will have to context switch every time you call your driver.

Al

Austin Franklin wrote:
> 
> > You will need pci drivers.  After checking out every software driver
> > commercially available, I've found www.tetradyne.com to be the easiest
> > and most straightforward.
> 
> Wouldn't you need O/S drivers?  There is nothing specific about a PCI
> driver over any other device (ISA, EISA etc) driver, except you need to get
> the boards address from the O/S or the BIOS...  I'm curious why you call it
>  PCI driver...
> 
> Thanks,
> 
> Austin
Article: 11347
Subject: Re: PCI Core In FPGA
From: alz <alz@lanminds.com>
Date: Wed, 05 Aug 1998 16:59:40 -0700
Links: << >>  << T >>  << A >>
Austin,

You're right !!  Technically it is a O/S driver.  I called it pci for
there are utilities set to specifically target the pci bus.  I like to
stay away from any Microsoft DDK and avoid the ring 3 to ring 0 
transition every time I want to access the pci bus.  If you know how to
write your own VxD or Kernel Mode driver... then you probably don't need
to purchase a set of utilities.  If you use the DDK from Microsoft you
will have to context switch every time you call your driver.

Al

Austin Franklin wrote:
> 
> > You will need pci drivers.  After checking out every software driver
> > commercially available, I've found www.tetradyne.com to be the easiest
> > and most straightforward.
> 
> Wouldn't you need O/S drivers?  There is nothing specific about a PCI
> driver over any other device (ISA, EISA etc) driver, except you need to get
> the boards address from the O/S or the BIOS...  I'm curious why you call it
>  PCI driver...
> 
> Thanks,
> 
> Austin
Article: 11348
Subject: Re: PCI Core In FPGA
From: alz <alz@lanminds.com>
Date: Wed, 05 Aug 1998 17:00:02 -0700
Links: << >>  << T >>  << A >>
Austin,

You're right !!  Technically it is a O/S driver.  I called it pci for
there are utilities set to specifically target the pci bus.  I like to
stay away from any Microsoft DDK and avoid the ring 3 to ring 0 
transition every time I want to access the pci bus.  If you know how to
write your own VxD or Kernel Mode driver... then you probably don't need
to purchase a set of utilities.  If you use the DDK from Microsoft you
will have to context switch every time you call your driver.

Al

Austin Franklin wrote:
> 
> > You will need pci drivers.  After checking out every software driver
> > commercially available, I've found www.tetradyne.com to be the easiest
> > and most straightforward.
> 
> Wouldn't you need O/S drivers?  There is nothing specific about a PCI
> driver over any other device (ISA, EISA etc) driver, except you need to get
> the boards address from the O/S or the BIOS...  I'm curious why you call it
>  PCI driver...
> 
> Thanks,
> 
> Austin
Article: 11349
Subject: Re: PCI Core In FPGA
From: alz <alz@lanminds.com>
Date: Wed, 05 Aug 1998 17:01:09 -0700
Links: << >>  << T >>  << A >>
Austin,

You're right !!  Technically it is a O/S driver.  I called it pci for
there are utilities set to specifically target the pci bus.  I like to
stay away from any Microsoft DDK and avoid the ring 3 to ring 0 
transition every time I want to access the pci bus.  If you know how to
write your own VxD or Kernel Mode driver... then you probably don't need
to purchase a set of utilities.  If you use the DDK from Microsoft you
will have to context switch every time you call your driver.

Al

Austin Franklin wrote:
> 
> > You will need pci drivers.  After checking out every software driver
> > commercially available, I've found www.tetradyne.com to be the easiest
> > and most straightforward.
> 
> Wouldn't you need O/S drivers?  There is nothing specific about a PCI
> driver over any other device (ISA, EISA etc) driver, except you need to get
> the boards address from the O/S or the BIOS...  I'm curious why you call it
>  PCI driver...
> 
> Thanks,
> 
> Austin


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