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 35350

Article: 35350
Subject: Re: Xilinx Virtex-II reconfiguration
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 30 Sep 2001 17:07:26 GMT
Links: << >>  << T >>  << A >>
Reconfiguration is triggered by pulling PROG_B Low. The chip recognizes this
and answers with a Low on INIT_B.  No need to hold PROG_B Low beyond that
point. The 300 ns number is for "open loop" operation, where you do not look
at INIT_B.

Peter Alfke, Xilinx Applications

Patrick Muller wrote:

> Hi
>
> To reconfigure a Xilinx Virtex-II, the Prog_B signal has to be held low for
> at least 300 ns. Is it sufficent to held the Prog_B signal as long low,
> until the Init_B signal goes low? Or is the delay from the falling edge of
> the Prog_B signal to the falling edge of the Init_B signal anyway longer
> than 300 ns?
>
> Thanks,
>
>    Patrick


Article: 35351
Subject: future Xilinx products wish list ...
From: Eric <erv_NO_SPAM@sympatico.ca>
Date: Sun, 30 Sep 2001 16:12:51 -0400
Links: << >>  << T >>  << A >>
Hi,

A recent thread (Programming flash connected to CPLD via JTAG) and the
chicken & egg problems associated with SRAM based FPGA configuration
remembered me that configuring Xilinx FPGA from standard bytewide memory
was much more convenient with previous FPGA series, and some other previously
available and useful functions were also lost for no apparent reasons.

---

In xilinx's early days (XC2000 / XC3000) there was a "Master Parallel Mode"
that allowed the FPGA to be configured directly from a standard bytewide
Rom / Eprom / Flash.
http://www.xilinx.com/partinfo/3000.pdf (page 25)
Spartan II / Virtex also have a parallel mode, but only in the "slave" role,
without the proper address generation logic (a simple binary counter in facts).

Most of my apps have both a processor and a FPGA, and no being able
to configure it directly from the same parallel flash that holds the processor's
application increases the system's chip count / EMI / power consumption / cost
in a very artificial and inefficient way.

Namely, the 3 main ways to configure a Xilinx FPGA are :
- use a serial config prom that's often more expensive and harder to find
than the FPGA it configures.
In systems that don't already use a bytewide Flash, cost and availability
often make up for the few extra pins needed for the function.
In system that already use a bytewide flash, configuration storage in Flash
is either free or require the next bigger flash size, for an added cost often
under 1$.

- Add an address counter / flash interface CPLD between the Flash and the
FPGA but that's a board space taking, cost increasing and often power hungry
piece of silicon that's completely useless once the FPGA is configured.
Also there is the "how to fill the flash ?" problem and then the "how to fill
the flash in a reasonable time ?" problem that is even more difficult to solve.
Have a look at the "Programming flash connected to CPLD via JTAG" thread
for more informations on this problem.

- put the FPGA out of the processor's data path so that it can start running
even if the FPGA is not configured yet and configure it later (using software).
That's usually what I end up doing, but it adds discrete glue logic and artificial
complexities, and prevents the FPGA from being used in the processor's data
path (memory management / bus demultiplexing, bus arbitration, Etc ...) since
they must be functional before the FPGA is configured.

Since putting the "Master Parallel Mode" back as a configuration option
would add virtually no silicon area/cost to the FPGA (it's just a binary
counter) I can't see any reason for not putting it back, except that it
might hurt expensive serial proms sales.

Few years ago, when FPGA were mostly used in projects where cost was
not a real concern, adding the config prom was no big deal.
Now that FPGA are used for more cost constrained applications (with the
Spartan series), costs associated with configuration need to be reduced,
and the return of the "Master Parallel Mode" would be the easiest way to
do it.
Also, sharing the configuration flash with a processor is a good way to
allow processor software controlled FPGA configuration changes for late
product differentiation / evolution / bug correction. This is not possible
with OTP serial proms and require extra circuitry / software with
reprogrammable serial proms.

The other way around, it also allows the FPGA to program the bytewide
flash containing  it's own application configuration and the processor's
program / data in system, using serial or JTAG configuration to serially
load the FPGA with a flash programmer / JTAG (or serial) emulation
configuration and then use it to program the flash.

-------

While I'm at it, I also can't see why the configuration oscillator that was
available for the user after configuration until Spartan is no more offered.

Having an internal clock source (no matter how imprecise it was) was not
only handy, but a very good way to add a watchdog to a processor based
design, or a low power standby mode (put the main processor in clock
stop mode and keep some background tasks going, such as keyboard scanning,
analog voltage (ADC) monitoring or simply a periodical processor wake up)

Now that this oscillator was enhanced to allow programmable frequency in
master serial configuration mode, it would be even more useful.

-------

Another option that existed with early FPGAs was the crystal oscillator.
With new generation FPGAs supporting so many different IO standards,
adding low gain inverter option on at least a pair of pins so that they
can be used as a quartz oscillator would certainly be both easy and useful.

http://www.xilinx.com/partinfo/3000.pdf (page 16)

-------

Since I'm in a wish list, a device that I would really like to have in
FPGAs and that would be useful in virtually all applications is a good
programmable PLL frequency generator similar to this one :
http://www.icst.com/pdf/ics3070102.pdf
Clock generation nirvana would be (nearly !) attained if it could use a
low power, low EMI, smallest size, very low cost 32768 Hz watch crystal
as the reference.
You can find here an example of such a design (page 44) :
http://www.semiconductors.philips.com/acrobat/3070.pdf
some Atmel ARM processors also use a 32768 hz crystal / PLL to generate
their clock.

Also, lowering the min. frequency of at least one of the DLLs from 25 Mhz
to something around 12 Mhz would allow more choice for fundamental mode
crystal oscillator frequencies (oscillators beyond 24 Mhz usually require
3rd overtone mode that's inherently less reliable, needs more parts including
an inductor and have a longer startup time) as well as reduce power and
EMI generation.

-----------

I really hope to see the first 2 features back in newer FPGAs and the next
2 ones would add value for many applications at negligible cost.

Am I the only one interested in these features, or would other users
also like to see them in future Xilinx products ?

regards,

Eric.


Article: 35352
Subject: Re: Xilinx 4.1 software
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 30 Sep 2001 21:25:12 +0100
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> Tom Brooks <tbrooks@corepower.com> wrote:
> > No, in fact, with 3.3, i was seeing runtimes
> > around 30 minutes, with 4.1, it took well over
> > an hour.
>
> Did you run with equivalent options? "-l 5" (effort level 5)
> implies "-xe 1" (extra effort level 1), which didn't exist on
> 3.1i. You might need -xe 0 to make the options equivalent.
>
> I have been quite pleased with the 4.1i SP1 results
> for a 2V6000 design I'm working on.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

I have a query here, outstanding for some time. Somewhere in the
Synplify documentation it says that use of Xilinx PAR effort level above
4 is not recommended. Anybody know why ? Is it just a fossil from some
old Synplify or Fndtn version ?

Somewhere nearby there's also the statement that use of the -k 5 flag to
MAP [map to 5 input functions] is also not recommended ?



Article: 35353
Subject: Xchecker and NT???
From: "Austin Franklin" <austin@dark98room.com>
Date: Sun, 30 Sep 2001 19:25:03 -0400
Links: << >>  << T >>  << A >>
Does anyone know if xchecker works with NT?  I tried it, and it doesn't seem
to work correctly...




Article: 35354
Subject: Re: future Xilinx products wish list ...
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sun, 30 Sep 2001 16:58:27 -0700
Links: << >>  << T >>  << A >>
On Sun, 30 Sep 2001 16:12:51 -0400, Eric <erv_NO_SPAM@sympatico.ca>
wrote:

>
>- put the FPGA out of the processor's data path so that it can start running
>even if the FPGA is not configured yet and configure it later (using software).
>That's usually what I end up doing, but it adds discrete glue logic and artificial
>complexities, and prevents the FPGA from being used in the processor's data
>path (memory management / bus demultiplexing, bus arbitration, Etc ...) since
>they must be functional before the FPGA is configured.
>

I commonly hang a Xilinx FPGA right on my uP's data bus, and configure
it serially in bit-bang mode after the proccessor is up and running,
using three parallel port pins. The FPGA config pattern data is just
built into the processor's EPROM code. The FPGA is tristated until
it's configured... this works fine.

John




Article: 35355
Subject: Re: future Xilinx products wish list ...
From: sknapp@triscend.com (Steven K. Knapp)
Date: 30 Sep 2001 22:39:11 -0700
Links: << >>  << T >>  << A >>
Just FYI.  If you are using a processor plus FPGA or CPLD, you also
might be interested in the Triscend Configurable System-on-Chip (CSoC)
devices.  The Triscend CSoC parts embed an industry-standard
processor, peripherals, memory, a high-speed bus, and a block of
LUT-based programmable logic, all in a single device.

The CSoC device boots from a single external memory device, per your
request.  The boot PROM holds the configuration data for the embedded
programmable logic plus the application program for the embedded
processor.  You can also download and debug the device directly via a
JTAG port.

There are two Triscend CSoC families available today--one based around
the 8-bit 8051/8052 microcontroller and another based around the
32-bit ARM7TDMI RISC processor.  There is more information at the
following link.
http://www.triscend.com/products

The E5 family--based around the 8051--has both an internal ring
oscillator and a crystal-oscillator amplifier that operates up to 40
MHz.

The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to
synthesize system clock frequencies between 1 and 60 MHz.  It too has
an internal ring oscillator.



Eric <erv_NO_SPAM@sympatico.ca> wrote in message news:<3BB77CC3.DBD58021@sympatico.ca>...
[snip]
> 
> ---
> 
> In xilinx's early days (XC2000 / XC3000) there was a "Master Parallel Mode"
> that allowed the FPGA to be configured directly from a standard bytewide
> Rom / Eprom / Flash.
> http://www.xilinx.com/partinfo/3000.pdf (page 25)
> Spartan II / Virtex also have a parallel mode, but only in the "slave" role,
> without the proper address generation logic (a simple binary counter in facts).
> 
> Most of my apps have both a processor and a FPGA, and no being able
> to configure it directly from the same parallel flash that holds the processor's
> application increases the system's chip count / EMI / power consumption / cost
> in a very artificial and inefficient way.
> 
[snip]
> 
> -------
> 
> Another option that existed with early FPGAs was the crystal oscillator.
> With new generation FPGAs supporting so many different IO standards,
> adding low gain inverter option on at least a pair of pins so that they
> can be used as a quartz oscillator would certainly be both easy and useful.
> 
> http://www.xilinx.com/partinfo/3000.pdf (page 16)
> 
> -------
> 
> Since I'm in a wish list, a device that I would really like to have in
> FPGAs and that would be useful in virtually all applications is a good
> programmable PLL frequency generator similar to this one :
> http://www.icst.com/pdf/ics3070102.pdf
> Clock generation nirvana would be (nearly !) attained if it could use a
> low power, low EMI, smallest size, very low cost 32768 Hz watch crystal
> as the reference.
> You can find here an example of such a design (page 44) :
> http://www.semiconductors.philips.com/acrobat/3070.pdf
> some Atmel ARM processors also use a 32768 hz crystal / PLL to generate
> their clock.
> 
[snip]

Article: 35356
Subject: Re: Xilinx 4.1 software
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Mon, 01 Oct 2001 06:08:28 GMT
Links: << >>  << T >>  << A >>
On Sun, 30 Sep 2001 21:25:12 +0100, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>
>
>hamish@cloud.net.au wrote:
>
>> Tom Brooks <tbrooks@corepower.com> wrote:
>> > No, in fact, with 3.3, i was seeing runtimes
>> > around 30 minutes, with 4.1, it took well over
>> > an hour.
>>
>> Did you run with equivalent options? "-l 5" (effort level 5)
>> implies "-xe 1" (extra effort level 1), which didn't exist on
>> 3.1i. You might need -xe 0 to make the options equivalent.
>>
>> I have been quite pleased with the 4.1i SP1 results
>> for a 2V6000 design I'm working on.
>>
>> Hamish
>> --
>> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>
>I have a query here, outstanding for some time. Somewhere in the
>Synplify documentation it says that use of Xilinx PAR effort level above
>4 is not recommended. Anybody know why ? Is it just a fossil from some
>old Synplify or Fndtn version ?

Most of my designs won't work with effort level less than 5.  That's
at > 160MHz though.

>Somewhere nearby there's also the statement that use of the -k 5 flag to
>MAP [map to 5 input functions] is also not recommended ?

I once had a design that wouldn't work with -k 4 or -k 5.  It needed
-k 6 to route to speed.
Usually -k 4 gives good results.

Synplify also recommend that we use general purpose routing for async
resets instead of the built in gsr net.  I ignore that "advice" as
well.

Regards,
Allan.

Article: 35357
Subject: 45 degree mixer
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Mon, 1 Oct 2001 12:01:22 +0200
Links: << >>  << T >>  << A >>
Hi,

Was wondering if anyone could lend some help. I am implementing a 45 degree
complex mixer. The coefficient sequence should be, if I am correct in
saying,  1 (.707 +j.707) +j (-.707 +j.707) -1 (-.707 -j.707) -j (.707 -
j.707). So, for a 4bit input and output, an input of (6,3) gives, correctly
according to above sequence,
[(6,3),(2,6),(D,6),(A,2),(A,D),(E,A),(3,A),(6,E)]. I get this output from my
timing simulations. However, this waveform is not a mixed waveform (looking
at the output of my FPGA, and also checking the shape of the simulated
output in a spreadsheet). I am running at a slow 16MHz, so I shouldn't be
having any timing problems.

I know this post should probably go to some DSP newsgroup, but I thought
that possibly someone here could give an answer to my dillema.

Thanks
adrian




Article: 35358
Subject: Re: Forcing a LUT logic function (was Synplicity logic replication)
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Mon, 1 Oct 2001 11:37:04 +0100
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote

> Very nice.  I hadn't taken the time to figure out how to parse a string to get
it
> into a form usable as a bit vector.  We had been building a library of fmapped
> functions, but it has grown to the point where it is unwieldy.  I've been
looking
> to do something similar, but have not had the time to put my mind to it.  What
are
> your license terms for use of the VExprEval function?  Is it free for use?,
> licensed?, GPL?

It's free.  No guarantees, but no known bugs :)


As regards Don's problem with generating stuff for Verilog, maybe a
Perl pre-processing stage would do the job.  A little text processing
plus the Perl 'eval()' should do the job.

Start with this:
   LUT3 Magic_Label(Ready = (Shift[0] & Sending | Stall));
and pre-process to this:
   LUT3 #('hnn) Label(Shift[0], Sending, Stall, Ready);

I speak Verilog, but not with enthusiasm.  Perhaps Professor Bromley
could set it as homework for one of his classes.





Article: 35359
Subject: Re: Fastest way to become a Verilog samurai?
From: "Sean Williams" <seanmeac@iname.com>
Date: Mon, 01 Oct 2001 11:48:43 GMT
Links: << >>  << T >>  << A >>
Check out the Aldec Website at www.aldec.com and find the Evita HDL tutorial

It should be at
http://www.aldec.com/Registration/download_form.asp?product=Evita&version=Ve
rilog

There is a very good introductory course on Verilog, starts at a basic
level, and covers the concepts.

Sean.
Principle Design Engineer
Calyptech
www.calyptech.com



>
> What is the fastest way to become a Verilog expert these days?  Classic
books
> like the Thomas/Moorby "The Verilog Hardware Description Language" seem
dated,
> and Smith's "HDL Chip Design" is cluttered (IMHO) with VHDL, which we
can't use
> here.
>




Article: 35360
Subject: Re: 45 degree mixer
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Mon, 1 Oct 2001 15:37:22 +0200
Links: << >>  << T >>  << A >>
Sorry, just found the problem. During simulation, I made the mistake of
using a positive number input... however, upon trying a negative input, ht
emixer falls over. Have found the problem...moral of the story is: don't
trust spreadsheets to do 2's complement arithmetic for you (unless anyone
can tell me how, and which spreadsheet...)

adrian



Article: 35361
Subject: bufgmux in virtex2 not found
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Mon, 01 Oct 2001 11:39:37 -0400
Links: << >>  << T >>  << A >>
When I try to use a bufgmux in a virtex2 vhdl design I get the following
error message.

# WARNING[1]: test.vhd(58): No default binding for component: "bufgmux".
(No entity named "bufgmux" was found)


I have the following in my top level design


--
-- pragma translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- pragma translate_on
--



In the body I have as a component

component BUFGMUX
  port (
    I0   : in std_logic;
        I1   : in std_logic;
        S    : in std_logic;
        O    : out std_logic
 );
end component;

and I used the following as an instantiation

U_BUFGMUX: BUFGMUX
  port map (
 I0     => zero, -- insert clock input used when select (S) is Low
 I1     => clk, -- insert clock input used when select (S) is High
 S      => ena, -- insert Mux-Select input
 O      => bufclk  -- insert clock output
 );


Note: I am using Foundation ISE 3.3i.

Any answers?

Thanks,
Theron Hicks


Article: 35362
Subject: ANN: VHDL Studio for Solaris
From: "Scott Thibault" <thibault@gmvhdl.com>
Date: Mon, 1 Oct 2001 12:02:01 -0400
Links: << >>  << T >>  << A >>
The latest release of VHDL Studio is now available for the SPARC/Solaris
platform.  This is the first low-cost, integrated VHDL design suite on the
market for the SPARC/Solaris platform.  VHDL Studio integrates proven VHDL
simulation technology with advanced VHDL entry tools including a
state-machine editor and graphical testbench editor.  Node locked licenses
available for 1595 USD with no annual maintenance fees.

For more information, see http://www.gmvhdl.com

--Scott Thibault
Green Mountain Computing Systems, Inc.
http://www.gmvhdl.com




Article: 35363
Subject: Re: Forcing a LUT logic function (was Synplicity logic replication)
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Mon, 1 Oct 2001 17:35:33 +0100
Links: << >>  << T >>  << A >>
In article <1001952786.11968.0.nnrp-07.9e9832fa@news.demon.co.uk>, Tim
<tim@rockylogic.com.nospam.com> writes

>It's free.  No guarantees, but no known bugs :)

Cheap at aleph-null times the price :-)

>As regards Don's problem with generating stuff for Verilog, maybe a
>Perl pre-processing stage would do the job.  A little text processing
>plus the Perl 'eval()' should do the job.
>
>Start with this:
>   LUT3 Magic_Label(Ready = (Shift[0] & Sending | Stall));
>and pre-process to this:
>   LUT3 #('hnn) Label(Shift[0], Sending, Stall, Ready);
>
>I speak Verilog, but not with enthusiasm.  Perhaps Professor Bromley
>could set it as homework for one of his classes.

Miaow!

And I don't speak Perl at all, and I'm allergic to preprocessors.

And I never was a Professor (except in the lower-case sense); and
these days my classes are populated with people whose employers have
paid for them, so leaving things "as a trivial exercise for the 
student" is less easy to get away with than it once was :-)

Seriously - the LUT-evaluator thing in VHDL looks like a really nice
piece of work, one of those things that's easy enough in principle
and really handy if you've access to it "off the shelf", but too
much trouble to write for most people to be bothered.  So,
many thanks!
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 35364
Subject: Re: future Xilinx products wish list ...
From: Ray Andraka <ray@andraka.com>
Date: Mon, 01 Oct 2001 16:46:47 GMT
Links: << >>  << T >>  << A >>
Steve,

How big is your FPGA fabric these days (ie how many CLBs).  Last I looked, you were using a
rough equivalent of the xilinx 4K architecture.  IIRC the equivalent device size was not very
big, so it didn't meet the needs of something that needed alot of FPGA plus some
microprocessor.  What is the top of your line now?

"Steven K. Knapp" wrote:

> Just FYI.  If you are using a processor plus FPGA or CPLD, you also
> might be interested in the Triscend Configurable System-on-Chip (CSoC)
> devices.  The Triscend CSoC parts embed an industry-standard
> processor, peripherals, memory, a high-speed bus, and a block of
> LUT-based programmable logic, all in a single device.
>
> The CSoC device boots from a single external memory device, per your
> request.  The boot PROM holds the configuration data for the embedded
> programmable logic plus the application program for the embedded
> processor.  You can also download and debug the device directly via a
> JTAG port.
>
> There are two Triscend CSoC families available today--one based around
> the 8-bit 8051/8052 microcontroller and another based around the
> 32-bit ARM7TDMI RISC processor.  There is more information at the
> following link.
> http://www.triscend.com/products
>
> The E5 family--based around the 8051--has both an internal ring
> oscillator and a crystal-oscillator amplifier that operates up to 40
> MHz.
>
> The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to
> synthesize system clock frequencies between 1 and 60 MHz.  It too has
> an internal ring oscillator.
>
>

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35365
Subject: Re: Forcing a LUT logic function (was Synplicity logic replication)
From: Ray Andraka <ray@andraka.com>
Date: Mon, 01 Oct 2001 16:50:20 GMT
Links: << >>  << T >>  << A >>
LOL

Tim wrote:

> I speak Verilog, but not with enthusiasm.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35366
Subject: Xilinx Spartan-II slave parallel configuration
From: "Chris Elliott" <Chris.P.Elliott@ieee.org>
Date: Mon, 1 Oct 2001 15:40:17 -0400
Links: << >>  << T >>  << A >>
I am trying to configure a Spartan-II XC2S50 using Slave Parallel Mode and
am unsuccessful.  DONE never goes high and INIT never goes low.  Is there
any way to debug what state the configuration is in?  For instance do the
FPGA drive a pin after it detects the sync pattern (or something like that)?

The manual states the "The D0 pin is considered the MSB bit of each byte."
I thought I knew how to interpret that, but I'm not sure.  The 5th byte is
the bit stream is 0xaa.  Do the bits D7-D0 read 10101010 or 01010101?  I
have tried both with no success, so I must have other problems.

Here is what I am doing:

1.  Drive PROG  low.
2.  Wait for DONE to go low.
3.  Drive PROG high.
4.  Wait for INIT to go high.
5.  Drive CS and WRITE low.
6.  Write 64 bytes of 0xff (CCLK is driven low then high during each byte).
7.  Write 69900 bytes of bit stream (CCLK is driven low then high during
each byte).
8.  Write 64 bytes of 0x00 (CCLK is driven low then high during each byte).
9.  Drive CS and WRITE high.
10. Wait for INIT to go low or DONE to go high (neither occurs).

I added the 64 bytes of 0xff at the beginning, because I don't have a
freerunning CCLK and need to make sure the FPGA configuration state machine
is ready.  I wasn't sure if I should have CS & WRITE low during these
writes, but it looks like it is designed to throw out the extra 0xff bytes
before the sync word.  The same thing goes for the 0x00 bytes at the end.

If anyone can help me shed some light on this, it would be greatly
appreciated.
-Chris



Article: 35367
Subject: Re: bufgmux in virtex2 not found
From: "Jon Harrison" <jon.harrison@spock.fsbusiness.co.uk>
Date: Mon, 1 Oct 2001 20:49:07 +0100
Links: << >>  << T >>  << A >>
Sounds like you need to re-compile your unisim library to me, with the
unisim files from 3.1i SP8, these have the Virtex II primitives in them and
some bug fixes. Either that or you should check that you have your Modelsim
library mappings setup correctly for unisim.

Note that if you system has been upgraded using the Xilinx patches to SP8
make sure that the SP6 patch has not been missed out this is the critical
one which adds most of the Virtex II functionality. We had a problem where
by Xilinx 'forgot' to send us the SP6 patch, but remembered 7 & 8 (applying
7&8 without 6 means problems with Virtex 2), so it might be worth checking
with your sysadmin.

Jon

Theron Hicks <hicksthe@egr.msu.edu> wrote in message
news:3BB88E39.DD27850A@egr.msu.edu...
> When I try to use a bufgmux in a virtex2 vhdl design I get the following
> error message.
>
> # WARNING[1]: test.vhd(58): No default binding for component: "bufgmux".
> (No entity named "bufgmux" was found)
>
>
> I have the following in my top level design
>
>
> --
> -- pragma translate_off
> library UNISIM;
> use UNISIM.VCOMPONENTS.ALL;
> -- pragma translate_on
> --
>
>
>
> In the body I have as a component
>
> component BUFGMUX
>   port (
>     I0   : in std_logic;
>         I1   : in std_logic;
>         S    : in std_logic;
>         O    : out std_logic
>  );
> end component;
>
> and I used the following as an instantiation
>
> U_BUFGMUX: BUFGMUX
>   port map (
>  I0     => zero, -- insert clock input used when select (S) is Low
>  I1     => clk, -- insert clock input used when select (S) is High
>  S      => ena, -- insert Mux-Select input
>  O      => bufclk  -- insert clock output
>  );
>
>
> Note: I am using Foundation ISE 3.3i.
>
> Any answers?
>
> Thanks,
> Theron Hicks
>



Article: 35368
Subject: Re: Hitop Warning hi434
From: Arthur <>
Date: Mon, 1 Oct 2001 13:42:15 -0700
Links: << >>  << T >>  << A >>
If you're not seeing any problems, then you've probably got sufficient decoupling caps - and the programmable grounds are helpful as well. 

One thing to try if you're worried about this, is to set some macrocells to low power mode - this will help prevent so many signals clocked off the same edge from transitioning all at the same time. Another alternative is to adjust the slew rate of some outputs to slow to help ward off ground bounce issues.

Regards,
Arthur

Article: 35369
Subject: Re: Hitop Warning hi434
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 01 Oct 2001 14:19:56 -0700
Links: << >>  << T >>  << A >>
SI Trick:

Take the Vcc to its highest operational value (but do not exceed the absolute maximum DC specifications).

Take the design down to its coldest operating environment (and add an extra -10C, ie get colder).

See if you have any problems there.

If there is an issue with Simultaneous Switching Outputs (SSOs), they will be far worse at this "corner."

Austin

Arthur wrote:

> If you're not seeing any problems, then you've probably got sufficient decoupling caps - and the programmable grounds are helpful as well.
>
> One thing to try if you're worried about this, is to set some macrocells to low power mode - this will help prevent so many signals clocked off the same edge from transitioning all at the same time. Another alternative is to adjust the slew rate of some outputs to slow to help ward off ground bounce issues.
>
> Regards,
> Arthur


Article: 35370
Subject: CTL Register in Virtex-E Configuration
From: "Dave Brown" <dbrown@novatel.ca>
Date: Mon, 1 Oct 2001 17:07:18 -0600
Links: << >>  << T >>  << A >>
I was reading XAPP151 and noticed that it said for Virtex devices, bit 2 of
the CTL regsiter must be zero. Is this also the case for Virtex E devices? I
have a .bit file for a Virtex E that has a 1 in bit 2 of the CTL register,
and as it happens, we can't get this device to configure. Do I need to have
a zero there?
Thanks,
Dave




Article: 35371
Subject: Re: CTL Register in Virtex-E Configuration
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 01 Oct 2001 16:39:42 -0700
Links: << >>  << T >>  << A >>
Dave,

It is my understanding that the only change from Virtex to Virtex E in
configuration was the longer frame size to accomodate the extra memory bits.

Control, etc. all remained identical.

Austin

Dave Brown wrote:

> I was reading XAPP151 and noticed that it said for Virtex devices, bit 2 of
> the CTL regsiter must be zero. Is this also the case for Virtex E devices? I
> have a .bit file for a Virtex E that has a 1 in bit 2 of the CTL register,
> and as it happens, we can't get this device to configure. Do I need to have
> a zero there?
> Thanks,
> Dave


Article: 35372
Subject: barrel shifter in Xilinx Virtex-E
From: Nate Goldshlag <nateg@pobox.com>
Date: Mon, 01 Oct 2001 21:15:17 -0400
Links: << >>  << T >>  << A >>
Hi,

I have implemented a barrel shifter in a Virtex-E part as:

module barrel_up (datain, bs, dataout);
 
   // port definitions
   input[31:0]    datain;     // data in
   input[4:0]     bs;         // barrel shift value
   output[31:0]   dataout; // barrel shift out data
   
   reg[31:0]      output_reg;
               
   always @(datain or bs)
      begin
         case (bs)
            5'h00:
               output_reg = datain;
            5'h01:
               output_reg = {datain[30:0], 1'b0};
            5'h02:
               output_reg = {datain[29:0], 2'b0};
            5'h03:
               output_reg = {datain[28:0], 3'b0};
            5'h04:
               output_reg = {datain[27:0], 4'b0};
            5'h05:
               output_reg = {datain[26:0], 5'b0};
            5'h06:
               output_reg = {datain[25:0], 6'b0};
            5'h07:
               output_reg = {datain[24:0], 7'b0};
            5'h08:
               output_reg = {datain[23:0], 8'b0};
            5'h09:
               output_reg = {datain[22:0], 9'b0};
            5'h0a:
               output_reg = {datain[21:0], 10'b0};
            5'h0b:
               output_reg = {datain[20:0], 11'b0};
            5'h0c:
               output_reg = {datain[19:0], 12'b0};
            5'h0d:
               output_reg = {datain[18:0], 13'b0};
            5'h0e:
               output_reg = {datain[17:0], 14'b0};
            5'h0f:
               output_reg = {datain[16:0], 15'b0};
            5'h10:
               output_reg = {datain[15:0], 16'b0};
            5'h11:
               output_reg = {datain[14:0], 17'b0};
            5'h12:
               output_reg = {datain[13:0], 18'b0};
            5'h13:
               output_reg = {datain[12:0], 19'b0};
            5'h14:
               output_reg = {datain[11:0], 20'b0};
            5'h15:
               output_reg = {datain[10:0], 21'b0};
            5'h16:
               output_reg = {datain[9:0], 22'b0};
            5'h17:
               output_reg = {datain[8:0], 23'b0};
            5'h18:
               output_reg = {datain[7:0], 24'b0};
            5'h19:
               output_reg = {datain[6:0], 25'b0};
            5'h1a:
               output_reg = {datain[5:0], 26'b0};
            5'h1b:
               output_reg = {datain[4:0], 27'b0};
            5'h1c:
               output_reg = {datain[3:0], 28'b0};
            5'h1d:
               output_reg = {datain[2:0], 29'b0};
            5'h1e:
               output_reg = {datain[1:0], 30'b0};
            5'h1f:
               output_reg = {datain[0], 31'b0};
            default:
               output_reg = datain;
         endcase
      end
   
   assign dataout = output_reg;
   
endmodule


This synthesizes to 5 logic levels, which seems like a lot to me.  I tried 
doing it another way but it was also 5 levels.  Anybody have any ideas on how 
to make it less, or is that just the way it is?

I am using Synplify for synthesis.

Nate

----------------------------------------------------
Nate Goldshlag      nateg@pobox.com
Arlington, MA       http://www.pobox.com/~nateg

Article: 35373
Subject: Re: barrel shifter in Xilinx Virtex-E
From: Tom Dillon <tdillon@dilloneng.com>
Date: Tue, 02 Oct 2001 01:43:41 GMT
Links: << >>  << T >>  << A >>
How about a multiplier? Definitely would be good in Virtex II.

We synthesize with Exemplar Leonardo and it will add pipeline registers =

within the multiplier logic which will make for a very fast clock rate. =
I=20
can get well over 100MHz clock rate for a multiplier that Leonardo=20
creates with pipeline registers.

I don't know if Synplify will do that for you.

Good luck,

Tom Dillon
Dillon Engineering, Inc.
http://www.dilloneng.com



>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 10/1/01, 8:15:17 PM, Nate Goldshlag <nateg@pobox.com> wrote regarding=
=20
barrel shifter in Xilinx Virtex-E:


> Hi,

> I have implemented a barrel shifter in a Virtex-E part as:

> module barrel_up (datain, bs, dataout);

>    // port definitions
>    input[31:0]    datain;     // data in
>    input[4:0]     bs;         // barrel shift value
>    output[31:0]   dataout; // barrel shift out data

>    reg[31:0]      output_reg;

>    always @(datain or bs)
>       begin
>          case (bs)
>             5'h00:
>                output_reg =3D datain;
>             5'h01:
>                output_reg =3D {datain[30:0], 1'b0};
>             5'h02:
>                output_reg =3D {datain[29:0], 2'b0};
>             5'h03:
>                output_reg =3D {datain[28:0], 3'b0};
>             5'h04:
>                output_reg =3D {datain[27:0], 4'b0};
>             5'h05:
>                output_reg =3D {datain[26:0], 5'b0};
>             5'h06:
>                output_reg =3D {datain[25:0], 6'b0};
>             5'h07:
>                output_reg =3D {datain[24:0], 7'b0};
>             5'h08:
>                output_reg =3D {datain[23:0], 8'b0};
>             5'h09:
>                output_reg =3D {datain[22:0], 9'b0};
>             5'h0a:
>                output_reg =3D {datain[21:0], 10'b0};
>             5'h0b:
>                output_reg =3D {datain[20:0], 11'b0};
>             5'h0c:
>                output_reg =3D {datain[19:0], 12'b0};
>             5'h0d:
>                output_reg =3D {datain[18:0], 13'b0};
>             5'h0e:
>                output_reg =3D {datain[17:0], 14'b0};
>             5'h0f:
>                output_reg =3D {datain[16:0], 15'b0};
>             5'h10:
>                output_reg =3D {datain[15:0], 16'b0};
>             5'h11:
>                output_reg =3D {datain[14:0], 17'b0};
>             5'h12:
>                output_reg =3D {datain[13:0], 18'b0};
>             5'h13:
>                output_reg =3D {datain[12:0], 19'b0};
>             5'h14:
>                output_reg =3D {datain[11:0], 20'b0};
>             5'h15:
>                output_reg =3D {datain[10:0], 21'b0};
>             5'h16:
>                output_reg =3D {datain[9:0], 22'b0};
>             5'h17:
>                output_reg =3D {datain[8:0], 23'b0};
>             5'h18:
>                output_reg =3D {datain[7:0], 24'b0};
>             5'h19:
>                output_reg =3D {datain[6:0], 25'b0};
>             5'h1a:
>                output_reg =3D {datain[5:0], 26'b0};
>             5'h1b:
>                output_reg =3D {datain[4:0], 27'b0};
>             5'h1c:
>                output_reg =3D {datain[3:0], 28'b0};
>             5'h1d:
>                output_reg =3D {datain[2:0], 29'b0};
>             5'h1e:
>                output_reg =3D {datain[1:0], 30'b0};
>             5'h1f:
>                output_reg =3D {datain[0], 31'b0};
>             default:
>                output_reg =3D datain;
>          endcase
>       end

>    assign dataout =3D output_reg;

> endmodule


> This synthesizes to 5 logic levels, which seems like a lot to me.  I=20=

tried
> doing it another way but it was also 5 levels.  Anybody have any ideas=
 on=20
how
> to make it less, or is that just the way it is?

> I am using Synplify for synthesis.

> Nate

> ----------------------------------------------------
> Nate Goldshlag      nateg@pobox.com
> Arlington, MA       http://www.pobox.com/~nateg

Article: 35374
Subject: Re: barrel shifter in Xilinx Virtex-E
From: Ray Andraka <ray@andraka.com>
Date: Tue, 02 Oct 2001 02:30:29 GMT
Links: << >>  << T >>  << A >>
The multipliers in virtexII do indeed work as a shifter, but they are quite
slow compared to what you can do in the fabric.  The barrel shift, as
implemented in the previous post has n^2 cost.  By using a merged tree
structure you can reduce that to nlog(n).  If you look at an individual bit
output, it can be represented as a function of a numbr of inputs.  That
function can be represented as a tree of logic blocks.  A merged tree is the
result of taking the intermediate values and sharing them among adjacent trees
for the adjacent bits.   In the case of a barrel shift, the merged tree
consists of layers of 2:1 muxes.  In your case, one layer selects between
straight through or shift by 16 bits.  The next layer takes that output and
either passes it through or shifts by 8 bits and so on.  The advantage of the
merged tree is less logic and considerably less routing congestion, which makes
it faster.  It is also very easy to pipeline as well as to describe in RTL
code.  No synthesizer will infer a merged tree from the description given in
the code below.

BTW, you need 5 layers if your kernel is a 4 lut because you can only get a 2:1
mux in each layer.  You can use the f5 and f6 muxes to make the layers faster,
but they still count as layers of logic.  You may have to instantiate the muxf5
and muxf6's to get your synthesizer to use them consistently.

Tom Dillon wrote:

> How about a multiplier? Definitely would be good in Virtex II.
>
> We synthesize with Exemplar Leonardo and it will add pipeline registers
> within the multiplier logic which will make for a very fast clock rate. I
> can get well over 100MHz clock rate for a multiplier that Leonardo
> creates with pipeline registers.
>
> I don't know if Synplify will do that for you.
>
> Good luck,
>
> Tom Dillon
> Dillon Engineering, Inc.
> http://www.dilloneng.com
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 10/1/01, 8:15:17 PM, Nate Goldshlag <nateg@pobox.com> wrote regarding
> barrel shifter in Xilinx Virtex-E:
>
> > Hi,
>
> > I have implemented a barrel shifter in a Virtex-E part as:
>
> > module barrel_up (datain, bs, dataout);
>
> >    // port definitions
> >    input[31:0]    datain;     // data in
> >    input[4:0]     bs;         // barrel shift value
> >    output[31:0]   dataout; // barrel shift out data
>
> >    reg[31:0]      output_reg;
>
> >    always @(datain or bs)
> >       begin
> >          case (bs)
> >             5'h00:
> >                output_reg = datain;
> >             5'h01:
> >                output_reg = {datain[30:0], 1'b0};
> >             5'h02:
> >                output_reg = {datain[29:0], 2'b0};
> >             5'h03:
> >                output_reg = {datain[28:0], 3'b0};
> >             5'h04:
> >                output_reg = {datain[27:0], 4'b0};
> >             5'h05:
> >                output_reg = {datain[26:0], 5'b0};
> >             5'h06:
> >                output_reg = {datain[25:0], 6'b0};
> >             5'h07:
> >                output_reg = {datain[24:0], 7'b0};
> >             5'h08:
> >                output_reg = {datain[23:0], 8'b0};
> >             5'h09:
> >                output_reg = {datain[22:0], 9'b0};
> >             5'h0a:
> >                output_reg = {datain[21:0], 10'b0};
> >             5'h0b:
> >                output_reg = {datain[20:0], 11'b0};
> >             5'h0c:
> >                output_reg = {datain[19:0], 12'b0};
> >             5'h0d:
> >                output_reg = {datain[18:0], 13'b0};
> >             5'h0e:
> >                output_reg = {datain[17:0], 14'b0};
> >             5'h0f:
> >                output_reg = {datain[16:0], 15'b0};
> >             5'h10:
> >                output_reg = {datain[15:0], 16'b0};
> >             5'h11:
> >                output_reg = {datain[14:0], 17'b0};
> >             5'h12:
> >                output_reg = {datain[13:0], 18'b0};
> >             5'h13:
> >                output_reg = {datain[12:0], 19'b0};
> >             5'h14:
> >                output_reg = {datain[11:0], 20'b0};
> >             5'h15:
> >                output_reg = {datain[10:0], 21'b0};
> >             5'h16:
> >                output_reg = {datain[9:0], 22'b0};
> >             5'h17:
> >                output_reg = {datain[8:0], 23'b0};
> >             5'h18:
> >                output_reg = {datain[7:0], 24'b0};
> >             5'h19:
> >                output_reg = {datain[6:0], 25'b0};
> >             5'h1a:
> >                output_reg = {datain[5:0], 26'b0};
> >             5'h1b:
> >                output_reg = {datain[4:0], 27'b0};
> >             5'h1c:
> >                output_reg = {datain[3:0], 28'b0};
> >             5'h1d:
> >                output_reg = {datain[2:0], 29'b0};
> >             5'h1e:
> >                output_reg = {datain[1:0], 30'b0};
> >             5'h1f:
> >                output_reg = {datain[0], 31'b0};
> >             default:
> >                output_reg = datain;
> >          endcase
> >       end
>
> >    assign dataout = output_reg;
>
> > endmodule
>
> > This synthesizes to 5 logic levels, which seems like a lot to me.  I
> tried
> > doing it another way but it was also 5 levels.  Anybody have any ideas on
> how
> > to make it less, or is that just the way it is?
>
> > I am using Synplify for synthesis.
>
> > Nate
>
> > ----------------------------------------------------
> > Nate Goldshlag      nateg@pobox.com
> > Arlington, MA       http://www.pobox.com/~nateg

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759





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