Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 20450

Article: 20450
Subject: Re: Spartan and timing analyzer: clock nets using non-dedicated
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 10 Feb 2000 13:41:40 -0800
Links: << >>  << T >>  << A >>


Tom Burgess wrote:

> <snip>. This also applies to Peter's suggestion of distributing a 40 MHz CE,
> in which case you have to worry about meeting CE setup times back in the 80 MHz domain.
> It looks like derived clocks will be much easier to deal with in the Virtex/Spartan 2 family.
>

I made the assumption that meeting the 80 MHz set-up time with a global net ( plus divider delay)
would be no problem.
One gets spoiled with the newer  parts, like Virtex-E:
clock-to-Q = 1ns, Tilo = 0.5 ns, Tsu = 1 ns,
plus of course routing which is also very fast.
100 MHz designs are not difficult anymore.

And the DLL lets you divide the clock without intoducing any delay between the two clock domains.
Neat stuff !

Peter Alfke, Xilinx Applications

Article: 20451
Subject: Master/Serial mode for Virtex
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Thu, 10 Feb 2000 16:15:59 -0600
Links: << >>  << T >>  << A >>
All,
I've read the Xilinx docs until I can't stand it anymore.  From my
interpretation, they contradict themselves.....please help.  We are
building a prototype system that is a chasis system with 17 boards.  We
want to put a board in the system that holds the PROMs for the FPGAs as
there are several boards that are the same and we don't want to have to
put PROMS on the identicle boards.  One board in a set will define the
FPGA on that board as the master and the rest will be slave.  We are
planning to use the 1800 series proms from Xilinx.  We believe that
CCLK, DONE, INIT, DATA, and PROGRAM have to be connected between the
master FPGA and the PROM.  Okay, program only if we are going to use it,
but we are.  We know that CCLK and DATA have to go to the slaves, but:

1) Does DONE of the slaves have to be connected?
2) Does INIT of the slaves have to be connected?

In one diagram, INIT is connected to all of the devices connected and in
another only the master.

I think we can just put pullups on the DONE signals of the slaves???

Can someone explain why INIT is a bidirectional signal???

Thanks for the help...anyone done this before???

Tom


Article: 20452
Subject: Xilinx Virtex Reset
From: mark.luscombe@lineone.net (Mark Luscombe)
Date: Thu, 10 Feb 2000 22:47:21 GMT
Links: << >>  << T >>  << A >>
Hi,


I am trying to work out a satifactory method for resetting a
synchronously design Virtex running at 74MHz.

Now, the reset signal needs to be synchronised with the 74MHz clock
and the propagation delay from this to the CLB and IOB DFFs needs to
be less than 13ns to ensure that all registers within the device at
reset on the sam clock edge.

Xilinx seem to have been telling people not to use the GSR net, as it
is too slow, but it does seem a pity not to use it, and use extra
routing and CLB inputs for a global reset.

It seems as though the STARTUP_VIRTEX component can accept a USER_CLK
input, i.e. the 74MHz, so is this a good solution ?
Also, this component has a GSR input for an external reset signal,
does anybody know if this is also synchronised with the USER_CLK input
?
The device is configured in 8-bit parallel with CCLK which is related
to the 74MHz.

What have other designers done in this situation.


Cheers, Mark.

Article: 20453
Subject: quantiser + ....
From: erika_uk@my-deja.com
Date: Thu, 10 Feb 2000 22:54:31 GMT
Links: << >>  << T >>  << A >>
Hi all,

Has anyone implemented the Run-length encoding and the HUFFMAN coding
in FPGA

any related work about the vectorial quantiser ...

thanks in advance


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20454
Subject: Re: Spartan and timing analyzer: clock nets using non-dedicated
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Thu, 10 Feb 2000 16:55:46 -0800
Links: << >>  << T >>  << A >>
The newer parts are amazing all right. Even a slow XLA should give
12.5 - (1.5 Tcko + 1.5? route + 3.0 Tgls + 0.7 Tecck) = 5.8 ns margin.
If we were talking about ye olde 4000 series of 5+ years ago, then "worry"
might have been the right word.

regards, tom


Peter Alfke wrote:
> 
> Tom Burgess wrote:
> 
> > <snip>. This also applies to Peter's suggestion of distributing a 40 MHz CE,
> > in which case you have to worry about meeting CE setup times back in the 80 MHz domain.
> > It looks like derived clocks will be much easier to deal with in the Virtex/Spartan 2 family.
> >
> 
> I made the assumption that meeting the 80 MHz set-up time with a global net ( plus divider delay)
> would be no problem.
> One gets spoiled with the newer  parts, like Virtex-E:
> clock-to-Q = 1ns, Tilo = 0.5 ns, Tsu = 1 ns,
> plus of course routing which is also very fast.
> 100 MHz designs are not difficult anymore.
> 
> And the DLL lets you divide the clock without intoducing any delay between the two clock domains.
> Neat stuff !
> 
> Peter Alfke, Xilinx Applications

-- 
Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@hia.nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767
Article: 20455
Subject: Re: FPGA IP complexity
From: Mike DeBruin <mikedebruin@uswest.net>
Date: Thu, 10 Feb 2000 19:30:39 -0600
Links: << >>  << T >>  << A >>
Yes, you are right. There is a bunch of press about stuff that isn't
realizable. Both Altera and Xilinx get into little spats about every little
thing. We can do partial re-programming, and then the other says they can
too, even though neither of them can. They put the hooks into the hardware
but neither can get the software algorithm to do it. The devices are getting
very very large and not that expensive. The biggest changes in the past
couple of years is of course the size but more importantly, speed, SRAM, and
DLL (PLL like delay locked loop). All of the IP and buy our cores and this
and that, I don't buy it!
Mike


anurag wrote:

> Hi,
>
> There's a lot of talk on IP for FPGAs - ( tons of articles can be found
> on this at EET, EDTN, Optimagic....etc.  sites). The
> reconfigurable-silicon concept does look very powerful & attractive !
> The question is  " What level of functional complexity can exactly be
> achieved on the currently available FPGAs ? "
>
> The designs that I've come across so far are ,at best, complex
> independent functional blocks ie; FIR/IIR filters, Veterbi
> codecs....etc.  I've yet to come across a full fledged system level
> design on an FPGA - something like (say) a design where a FPGA can be
> instantly reconfigured to be a MP3 codec in one mode and a soft modem in
> another. Another ex. I cld. quote is a FPGA behaving as one of the
> wireless air interface standards ie; GSM/TDMA/CDMA ( in other words - a
> S/W radio ) depending on the core downloaded on it (an ASIC from
> Motorola exactly does this ! )
>
> What I'm trying to get at is that all this seems to be theoritically
> possible but I haven't seen any working design yet ! Even the ref.
> examples at the Xilinx site are mostly glue-logic designs. SO, can the
> examples quoted above be realised on a FPGA ( assuming that the required
> no. of gates are available ) ?
> If not (since it's possible theoritically) what cld. be the primary
> reason for this ?
>
> Any comments wld. be appreciated !
>
> Thanks........Anurag
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Article: 20456
Subject: Re: Simulation problem
From: Mike DeBruin <mikedebruin@uswest.net>
Date: Thu, 10 Feb 2000 19:33:12 -0600
Links: << >>  << T >>  << A >>
I've had the same problem. What you need to do is remove the "xor" statement and
do the following:

Old statement:
A = B xor C;

New statement:
A = ( (B AND (NOT C)) OR ((NOT B) AND C) );

This seemed to work in MaxPlusII, Foundation and the Warp tool.
Mike

Pradeep Rao wrote:

> Hi,
> I am using the following code to XOR two bytes. I am able to simulate it
> using Active HDL(3.1) and seems to work, but when I use Warp I get the
> following error while compiling :
>
> C:\warp\bin\WARP.EXE -q -e10 -w100 -o2 -yga -fO -fP -v10 -dC371 -pCY7C371-14
> 3JC -b byte_xor.vhd
> VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95)
> Setting library 'work' to directory 'lc371'
> ----------------------------------------
> Compiling 'byte_xor.vhd' in 'C:\WARP\EXAMPLES\Pradeep'.
> VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95)
> Library 'work' => directory 'lc371'
> Linking 'C:\warp\lib\common\work\cypress.vif'.
> byte_xor.vhd (line 8, col 30):  (E56) Expected FUNCTION, but got IS
> Error occurred within 'PROCESS' at line 8, column 16 in byte_xor.vhd.
> byte_xor.vhd (line 8, col 30):  (E10) Syntax error at/before reserved symbol
> 'is'.
> ----------------------------------------
> WARP done.
>
> Here's my code :
> -----------------------
> entity bytexor is
> port (xin1,xin2 : in bit_vector(0 to 7);
>   xout : out bit_vector(0 to 7));
> end entity bytexor;
>
> architecture behave of bytexor is
> begin
> compute:process(xin1,xin2) is
> begin
>   for index in 0 to 7 loop
>     xout(index)<= xin1(index) xor xin2(index);
>   end loop;
> end process compute;
> end architecture behave;
> ------------------------------------------------
> I'd be glad if someone could help me out.
> Thanks,
> Pradeep Rao

Article: 20457
Subject: Re: Xilinx Virtex Decoupling Cap Guidelines
From: "peter dudley" <padudle@worldnet.att.net>
Date: Fri, 11 Feb 2000 01:55:39 GMT
Links: << >>  << T >>  << A >>
I aggree the Xilinx recommendation is overkill.

I use one 10uF, two or three 1uF tantalums per board per power plane. For
the Virtex 300 I use eight .01uF ceramic caps on each of its two power
supplies. The fpga runs at 125 MHz with lots of simultaneous switching.

If you can afford good power/ground planes, don't worry about getting the
caps directly adjacent to the power pins of the fpga. What you should be
doing is AC coupling together the ground and power planes.

For the ultimate in high frequency decoupling it's possible to use "buried
capacitance layers" imbedded directly into the board. These are power/ground
layers placed very close together in the board stack up.

Avoid creating islands in the ground or power planes as these will only
degrade signal integrity.

--
Pete Dudley

Arroyo Grande Systems

John Janusson <jjanusson@nospami-o.com> wrote in message
news:fZIl4.1502$wR.121291@news.flash.net...
> Hello:
>
> I have read XAPP158 (Powering Virtex FPGAs
> http://www.xilinx.com/xapp/xapp158.pdf) and found the following
> recommendations:
>
>
> VCCINT    ->    Guideline
> -------------------
> 0.1 uF    ->    One per VCC
> 47 uF    ->    Four per device (XCV50 - XCV300)
> 470 uF    ->    One per device
>
> 470uF!!!  In my experience, this seems excessive, even after reading the
> disclaimer in Answers record #777
> (http://support.xilinx.com/techdocs/777.htm)...  I was planning on
following
> the guidelines sans 470uF cap.  It's a low power design in a XCV100
running
> at mostly 4 to 32 MHz...
>
> Can others comment on power related issues in Virtex parts, particularly
> related to decoupling and startup???
>
> Thanks...
>
> John
>
>


Article: 20458
Subject: ROL VHDL operator.. need help!
From: TeikMing Goh <ming@morgan.ucs.mun.ca>
Date: Thu, 10 Feb 2000 22:53:11 -0330
Links: << >>  << T >>  << A >>
Hi All,

Can someone tell me what library I should use in order to use ROL
operation(rotate left)?  I used LIBRARY IEEE, use ieee.std_logic_1164.all
and use ieee.std_logic_arith.all, but I got syntax error on that.
Thank you

Regards
Teik-Ming




Article: 20459
Subject: Re: Altera vs Cypress?
From: "Clyde R. Shappee" <clydes@world.std.com>
Date: Fri, 11 Feb 2000 02:23:27 GMT
Links: << >>  << T >>  << A >>
Mary,

We have used these similar Lattice devices at my company in the past, and
although I was not involved, the design flow was apparently a nightmare.  I
beleive it was Exemplar to an EDIF to their fitter.  This was  a while ago
and things may be different now.

At my bosses recommendation, follow on projects have used the MAX7000
series, Exemplar, and the Atera Max Plus II fitter.

This has gone very smoothly for us.

However, I have always had a soft spot for Cypress, because I have used
their tool quite succcessfully for many PAL devices.

In my most recent design, I used a MAX7128.  At the final hour, someone in
our company brought in Cypress for a technical overview, and I brought up
the fact that I could not get the design to compile under their tool, in a
comparable device.

In a very short order, they fixed my design to make it compile with their
tool in the appropriate device,  but I was so close to committing to etch
that I could not make a change in the final hour.  I believe the change was
to convert resets to synchronous.  In truth, I have not had the time to dig
into what they did for my design.

All that said, If you have access to the  high end tools like Exemplar (I
guess they call it differently now) the Altera flow works well, and is not
so restrictive on VHDL style.  The Warp tool is a little more restrictive.

If you only are going to use the WARP tool because of economics,   be
careful and if you have problems, give their applications team a chance to
help you out.  They do stand behind their products and will help.

I think Altera has a great product, and Cypress is an Underdog.  Sometimes
it is worth considering the Underdog.

Another thing to consider is that the Altera tools do little optimization
(that's why we use Exemplar) and Cypress' tool does.

Good Luck.

Clyde

Mary Frantz wrote:

> We have been using Lattice CPLD's (ispLSI1024, ispLSI2064, etc.) in the
> past with Synopsis software and are dissatisfied with the performance of
> both.  Our designs are generally quite simple (glue logic and
> registers).  Does anyone have a recommendation either for or against
> Altera (MAX7000 family) using MAXBaseline or MAXPlus, and Cypress (Ultra
> 37000 family) using Warp 5.2?  Any known hardware or software prolems?
>
> Thanks in advance.
> Mary Frantz

Article: 20460
Subject: Re: Master/Serial mode for Virtex
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 10 Feb 2000 22:54:22 -0500
Links: << >>  << T >>  << A >>
Tom McLaughlin wrote:
> 
> All,
> I've read the Xilinx docs until I can't stand it anymore.  From my
> interpretation, they contradict themselves.....please help.  We are
> building a prototype system that is a chasis system with 17 boards.  We
> want to put a board in the system that holds the PROMs for the FPGAs as
> there are several boards that are the same and we don't want to have to
> put PROMS on the identicle boards.  One board in a set will define the
> FPGA on that board as the master and the rest will be slave.  We are
> planning to use the 1800 series proms from Xilinx.  We believe that
> CCLK, DONE, INIT, DATA, and PROGRAM have to be connected between the
> master FPGA and the PROM.  Okay, program only if we are going to use it,
> but we are.  We know that CCLK and DATA have to go to the slaves, but:
> 
> 1) Does DONE of the slaves have to be connected?
> 2) Does INIT of the slaves have to be connected?
> 
> In one diagram, INIT is connected to all of the devices connected and in
> another only the master.
> 
> I think we can just put pullups on the DONE signals of the slaves???
> 
> Can someone explain why INIT is a bidirectional signal???
> 
> Thanks for the help...anyone done this before???
> 
> Tom

This is not really simple stuff, but once you get the hang of it, it is
not too bad. It is very confusing at first though, partly because
several of the signals are dual purpose and some are shared. 

One thing you really should consider is using a small micro on your
common board and having it download all of the FPGAs individually. This
will not be slower than the chained serial method and will be much
easier to debug except for the added complexity of writing the code for
the microprocessor. Chained FPGA configuration is a bit like Christmas
tree lights. If you have a problem configuring any one, none of them
will start up, including the master! This can be a pain to debug,
especially with the shared signals. 

But the part that will be simpler with a micro is the fact that you can
update each of the FPGA bit files individually. In the chained mode, you
will have to generate one large bit file each time you change any of the
individual bit files. I feel that this is not worth the small effort it
takes to program a small microprocessor to download the FPGAs
separately. It is also quite a bit easier to debug if you have a problem
with any one FGPA. 

But you still need to understand how all of the signals work. I had
planned to write a description of this and post it on my web site, but
other events took priority. I will catch up with it someday. Peter Alfke
offered to proofread it when I got it done. So here is a start. 

The PRGM- signal normally is tied together on all of the FPGAs,
regardless of the mode you are using to configure them. The main reason
you would want to make these separate signals is if you want to be able
to load any of them without loading them all. The PRGM- signal will
start
the configuration process when asserted low. The INIT- signal (which
should be wired together from all FPGAs if using a daisychain config) is
pulled low by the FPGAs. When PRGM- released high, the FPGAs run through
at least one more
config reset cycle and then release INIT-. Because INIT- is open
collector,
all chips have to release INIT- for it to go high. If you are
configuring the FPGAs with separate data and clocks, then the INIT-
signals can also be separate. 

Once INIT- is high, you can start clocking the data out. The CCLK should
not be clocked by a free running clock. The clock edges are counted by
the FPGA and
must match the count contained within the bit file. 

There are a lot of details associated with clocking the data. You have
to supply the right number of clocks without no clocks coming before the
beginning of the data. Further, you will have to provide some number of
extra clocks at the end with the data high. This number depends on how
the bit file
is specified for the synchonization of the DONE, the internal GSR being
released, the release of the IO tristate control and the end of the data
configuration. This is all specified to
the program that builds the bit file. It is a bit complex. I always use
the default which I believe uses three extra clocks. I think you can add
some extra clocks beyond the ones required at the end without hurting
anything. 

When fully configured the DONE signal is released high by the FPGAs.
This is also an
open collector signal which can be tied together between the different
FPGAs. The FPGA will not go through the final steps of activating the
IOs and releasing the internal GSR signal until the DONE signal is high.
This is part of what you can specify when making the bit file. Tying the
DONE signals together from the different FPGAs will allow them to all
start running together. Again, I don't normally bother with this, but it
depends on your application. The proper synchonization also depends on
whether you control the final steps with the CCLK signal or some other
user supplied clock. This gets a bit more complex as you try to assure
proper release of the GSR signal for your synchronous logic which is a
whole discussion in itself. 

I think I have hit the main points. I am sure that others will be
posting more details that I have missed or may have gotten incorrect.
But as I said, I think that it would be easier to debug initially and
maintain by separate configuration of the different FGPAs whether done
with a micro or PLD or other logic. But that is just my opinion.


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 20461
Subject: Re: Xilinx Virtex Reset
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 10 Feb 2000 23:19:33 -0500
Links: << >>  << T >>  << A >>
Mark Luscombe wrote:
> 
> Hi,
> 
> I am trying to work out a satifactory method for resetting a
> synchronously design Virtex running at 74MHz.
> 
> Now, the reset signal needs to be synchronised with the 74MHz clock
> and the propagation delay from this to the CLB and IOB DFFs needs to
> be less than 13ns to ensure that all registers within the device at
> reset on the sam clock edge.
> 
> Xilinx seem to have been telling people not to use the GSR net, as it
> is too slow, but it does seem a pity not to use it, and use extra
> routing and CLB inputs for a global reset.
> 
> It seems as though the STARTUP_VIRTEX component can accept a USER_CLK
> input, i.e. the 74MHz, so is this a good solution ?
> Also, this component has a GSR input for an external reset signal,
> does anybody know if this is also synchronised with the USER_CLK input
> ?
> The device is configured in 8-bit parallel with CCLK which is related
> to the 74MHz.
> 
> What have other designers done in this situation.
> 
> Cheers, Mark.

This is a subject that is often discussed here. What you describe with
using a user clock for startup is one way to do it. That should work if
the GSR net is fast enough to operate within your clock cycle. 

Another way to use the GSR which does not depend on sychronized release
of the GSR is to make sure that all of the inputs to your various FSMs
or other sychronous logic are in a state that will not cause the
machines to make a state change. For example if the FSMs reset to an
IDLE state, then make sure that none of the inputs that let the machine
leave the IDLE state are asserted. Then even if the GSR is released on
different clock cycles for different FFs, it will not matter. 

Or use a couple of delay FFs to generate (from the GSR) a separate,
synchronized input to the FSMs which will delay state changes from this
initial state until it releases. This net will not need to go to all of
the FFs in your design and can be routed much faster. 

Another method which is similar to this last one is to have a separate,
external reset signal which is controlled by a micro or other logic.
This will only be released well after the config is complete and is
synchrnized to the clock. As in the last method, this reset will not
need to go to every FF in the FPGA and so can be routed more quickly. 

The GSR is nice in that it puts every FF into a known state and it is
asynch so it does it NOW! But releasing it can be a problem. A second,
more limited reset is a good way to get the FPGA started on the right
foot. 

I can't remember other ways that have been described, but I am sure
there are some.


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 20462
Subject: Re: FLASH-based reconfigurability
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 10 Feb 2000 23:41:25 -0500
Links: << >>  << T >>  << A >>
Paul Mondello wrote:
> 
> I have an application where I would like to be able to remotely re-program a
> FLASH configuration PROM (XC18V00). The PROM and FPGA reside on an expansion
> card inside a PC.
> 
> Basically I would like to be able to download a new FPGA configuration file
> to the Host over the network, re-program the Flash PROM, and then
> re-configure the FPGA with the new code. The FPGA will be connected to an
> embedded processor which will handle the task of interfacing to the Host via
> the PCI bus and passing the configuration bits to the FPGA, which will then
> have the task of re-programming the Flash, I'm guessing through the JTAG
> port. At that point the embedded processor will force the FPGA to
> reconfigure.
> 
> Does anyone have any experience or ideas on how to do this? We basically
> want a "simple" way to download feature changes and/or bug fixes to the FPGA
> without having to remove the board from the PC.
> 
> Thanks in advance for any help you can provide.
> 
> -Paul
> 
> P.S. I have read a little about "Xilinx Online" and think that this method
> is more complicated than what we need.

This is not really an answer to your question, but if you have an
embedded processor on board, why not program the FPGA from the processor
and let the processor manage the flash directly? You can get byte wide
or 16 bit wide flash which is very easy to program from a processor
without JTAG, 12 volts or any other hassles. They are large enough (> 1
MB) that you can even keep the processor code in it with multiple FPGA
loads. I don't know how expensive the XC18V00 is, but you can get 1 MB
of flash for about $5 to $10 depending on quantity. 

Programming the FPGA as if it were a peripheral is not hard. The asynch
peripheral mode is easy and just as fast as serial mode. I believe there
is also a parallel mode which is faster than the other modes. It lets
you clock in a byte at a time without waiting for it to be serialized. 

What do you think? Do you really need to use the JTAG and programming
the Flash via the FPGA?


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 20463
Subject: Re: ROL VHDL operator.. need help!
From: "Domagoj" <abednego@africamail.com>
Date: Fri, 11 Feb 2000 06:39:56 +0100
Links: << >>  << T >>  << A >>
Hi,

        The shift operators (sll,srl,sla,sra,rol,ror also xnor and many
other constructs) are not provided in VHDL-87 standard, only in VHDL-93,
I suppose that's it.

Hope this helps,

-----------------
=    Domagoj   =
-----------------
TeikMing Goh <ming@morgan.ucs.mun.ca> wrote in message
news:Pine.OSF.3.95.1000210225125.25643A-100000@plato.ucs.mun.ca...
> Hi All,
>
> Can someone tell me what library I should use in order to use ROL
> operation(rotate left)?  I used LIBRARY IEEE, use ieee.std_logic_1164.all
> and use ieee.std_logic_arith.all, but I got syntax error on that.
> Thank you
>
> Regards
> Teik-Ming
>
>
>
>


Article: 20464
Subject: Re: Altera vs Cypress?
From: "Geoffrey G. Rochat" <geoff@pkworks.com>
Date: Fri, 11 Feb 2000 00:43:19 -0500
Links: << >>  << T >>  << A >>
I've had excellent results with Max+Plus II using the included AHDL for
many years.  It's a nice package if using a (decent) proprietary
language is acceptable to you.  The free Baseline package does not
support timing-driven compilation (last I checked) which is a bit of a
bother for FPGAs; I've not tried it with CPLDs - but the price sure is
right!  I tried an early Verilog/VHDL compiler for Max+Plus II from
Altera several years ago, but at the time it was Not Yet Ready For
Production.  Things may have changed, but I've not checked.  I've not
had the opportunity to use Warp, but people who have used it haven't
complained to me about it.  If you run some tests to make your decision
please post the results, as you bring up some very interesting
questions.



Article: 20465
Subject: RLOC_RANGE property.
From: "George" <g_roberts75@hotmail.com>
Date: Fri, 11 Feb 2000 05:52:19 -0000
Links: << >>  << T >>  << A >>
Hi Folks,

I am using Foundation 2.1i-SP4 to target XC4k series. I am having
difficulties with 'RLOC_RANGE' property. I am using schematic design entry.
I attach a property 'RLOC_RANGE=Rr1Cc1:Rr2Cc2' on a symbol if I wanted it to
be placed between Rows r1 and r2, and Columns c1 and c2. However, when I map
the design,  I do not get what I expect. This directive seems to be toatally
ignored.
Has anybody anybody out there used this property? How did it work for you?

I appreciate your help.


Article: 20466
Subject: RLOC_RANGE property.
From: "George" <g_roberts75@hotmail.com>
Date: Fri, 11 Feb 2000 06:08:09 -0000
Links: << >>  << T >>  << A >>
Hi Folks,

I am using Foundation 2.1i-SP4 to target XC4000. I am having problems using
the 'RLOC_RANGE' property. I am using schematic design entry. I attach the
property 'RLOC_RANGE=Rr1Cc1:Rr2Cc2' to a symbol in order to place it between
Rows r1 and r2, and between Columns c1 and c2. However, when it maps, it
does not give what I expect. It seems that it is ignoring this directive.
Has anybody out there used this property? How did it work for you?

I appreciate your help.


Article: 20467
Subject: RLOC_RANGE property.
From: "George" <g_roberts75@hotmail.com>
Date: Fri, 11 Feb 2000 06:09:04 -0000
Links: << >>  << T >>  << A >>
Hi Folks,

I am using Foundation 2.1i-SP4 to target XC4000. I am having problems using
the 'RLOC_RANGE' property. I am using schematic design entry. I attach the
property 'RLOC_RANGE=Rr1Cc1:Rr2Cc2' to a symbol in order to place it between
Rows r1 and r2, and between Columns c1 and c2. However, when it maps, it
does not give what I expect. It seems that it is ignoring this directive.
Has anybody out there used this property? How did it work for you?

I appreciate your help.


Article: 20468
Subject: Re: Xilinx Virtex Decoupling Cap Guidelines
From: Andreas Heiner <Andreas.Heiner@de.bosch.com>
Date: Fri, 11 Feb 2000 08:41:44 +0100
Links: << >>  << T >>  << A >>

> I aggree the Xilinx recommendation is overkill.
>
> I use one 10uF, two or three 1uF tantalums per board per power plane. For
> the Virtex 300 I use eight .01uF ceramic caps on each of its two power
> supplies. The fpga runs at 125 MHz with lots of simultaneous switching.
>
> If you can afford good power/ground planes, don't worry about getting the
> caps directly adjacent to the power pins of the fpga. What you should be
> doing is AC coupling together the ground and power planes.
>
> For the ultimate in high frequency decoupling it's possible to use "buried
> capacitance layers" imbedded directly into the board. These are
power/ground
> layers placed very close together in the board stack up.

The last two things are exactly what I mean with bideband decoupling. A very
good AC coupling over the whole frequence range (requires a filter design)
and very close power layers (we're using 68um, the last boards has 50um
distance between the layers).

>
> Avoid creating islands in the ground or power planes as these will only
> degrade signal integrity.

If you will separate the ground plane the design would !!! NOT !!! work
!!!!. Please don't do this! The separation of the VCC plane is just
neccessary for two purposes:
1. The possible max decoupling frequency depends on the size of the area. If
you decrease the area, you increase the maximun decoupling frequency
(physical law). Our program calculates up to 1 GHz.
2. If you have analog and digital parts on one PCB it is much better to
seperate the power planes. It's the same for "rough" digital logic (as
FPGA's) and "sensible" logic (as SDRAM's). But this is not absolutely
neccessary.

>
> --
> Pete Dudley

Best regards,

Andreas Heiner


Article: 20469
Subject: Re: Xilinx error message
From: Klaus Falser <kfalser@durst.it>
Date: Fri, 11 Feb 2000 07:52:12 GMT
Links: << >>  << T >>  << A >>
In article <87utdq$k27$1@nnrp1.deja.com>,
  bjorn_lindegren@my-deja.com wrote:
> Hi using Xilinx foundation2.1i. (xc9536 vq44-15)
>
> Writing a VHDL program and recive an error
> message:
> The net'/ver1/klar' has more than one driver.
>
> All of our variables are STD_LOGIC.
>
> Thankful for help.
>
> Björn Lindegren, Christian Jerkeborg
>
> library IEEE;
> use IEEE.std_logic_1164.all;
>
> use IEEE.std_logic_arith.all;
> use IEEE.std_logic_unsigned.all;
>
> library SYNOPSYS;
> use SYNOPSYS.attributes.all;
>
> entity fyren1 is
>   port (CLK: in STD_LOGIC;
>         OSC: in STD_LOGIC;
>         RESET: in STD_LOGIC;
>         KLAR: inout STD_LOGIC;
>         START: inout STD_LOGIC);
> end;
>
> architecture fyren1_arch of fyren1 is
>
> -- SYMBOLIC ENCODED state machine: COUNT
> type COUNT_type is (KLART, OSC0, OSC1, OSCSTART);
> signal COUNT: COUNT_type;
>
> -- SYMBOLIC ENCODED state machine: FEMTON
> type FEMTON_type is (S1, S2);
> signal FEMTON: FEMTON_type;
>
> begin
> --concurrent signal assignments
>
> COUNT_machine: process (CLK)
> --machine variables declarations
> variable COUNTER: INTEGER range 0 to 100;
>
> begin
>
> if CLK'event and CLK = '1' then
> 	if START='1' then
> 		COUNT <= OSCSTART;
> 		COUNTER:=0;
> 		KLAR<='0';
> 	else
> 	case COUNT is
> 		when KLART =>
> 			KLAR<='1';
> 			if COUNTER<=3 then
> 				COUNT <= OSC0;
> 				KLAR<='0';
> 			end if;
> 		when OSC0 =>
> 			COUNTER:=COUNTER+1;
> 			if OSC='1' then
> 				COUNT <= OSC1;
> 				KLAR<='0';
> 			elsif COUNTER=3 then
> 				COUNT <= KLART;
> 			end if;
> 		when OSC1 =>
> 			if OSC='0' then
> 				COUNT <= OSC0;
> 				KLAR<='0';
> 			end if;
> 		when OSCSTART =>
> 			KLAR<='0';
> 			if OSC='1' then
> 				COUNT <= OSC1;
> 				KLAR<='0';
> 			end if;
> 		when others =>
> 			null;
> 	end case;
> 	end if;
> end if;
> end process;
>
> FEMTON_machine: process (CLK)
>
> begin
>
> if CLK'event and CLK = '1' then
> 	if RESET='1' then
> 		FEMTON <= S1;
> 		KLAR<='0';
> 		START<='1';
> 		START<='0';
> 	else
> 	case FEMTON is
> 		when S1 =>
> 			START<='0';
> 			if KLAR<='1' then
> 				FEMTON <= S2;
> 				KLAR<='0';
> 				START<='1';
> 			end if;
> 		when S2 =>
> 			START<='0';
> 			if KLAR<='1' then
> 				FEMTON <= S1;
> 				KLAR<='0';
> 				START<='1';
> 			end if;
> 		when others =>
> 			null;
> 	end case;
> 	end if;
> end if;
> end process;
>
> end fyren1_arch;
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

The signal KLAR is driven in boths processes, with the result that
(theoreticely) on the same clock egde one would like to set it to high,
and the other to low.
During simulation this is no problem, since KLAR is from type STD_LOGIC
which is a resolved type, and from such collisions (simply speaking) a
new resulting value is calculated.

On an architecture like the XC9500 CPLDs the synthesizer can not
resolve this type of conflict and requires that any signal is driven
from exactly one process.

You have to modify your design this way.

Hope this helps

--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20470
Subject: Re: Xilinx board
From: Leon Heller <leon_heller@hotmail.com>
Date: Fri, 11 Feb 2000 07:59:59 GMT
Links: << >>  << T >>  << A >>



> ERROR:basut - Boundary scan chain has been improperly specified.
Please
> check your configuration and re-enter the boundary-scan chain
information.
> Boundary-scan chain validated unsuccessfully.
> ERROR:basut - : The boundary-scan chain has not been declared
correctly.
>  Verify the syntax and correctness of the device BSDL files, correct
the
> files,
>  reset the cable and retry this command.
>
> Have you any suggestions ?

Have you tried downloading the latest BSDL file from the Xilinx web
site? This worked when I had a similar problem with a Spartan device.

Leon
--
Leon Heller, G1HSM
Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824
Email: leon_heller@hotmail.com
Web: http://www.geocities.com/SiliconValley/Code/1835


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20471
Subject: Re: MP3 & Wavelet on FPGA
From: "Mark Harvey" <mark.harvey@iol.it>
Date: Fri, 11 Feb 2000 08:34:51 GMT
Links: << >>  << T >>  << A >>
try here:

http://www.xilinx.com/products/xaw/mp3/index.htm

there are some links at the bottom of the web page.



anurag <anurag@earthling.net> wrote in message
news:87ph56$ogj$1@nnrp1.deja.com...
> Hi,
>
> wld. appeciate if anyone cld. point out to MP3 and Wavelet codec
> implemented on a FPGA...if any  ?
>
> Thanks......
>
> AK
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 20472
Subject: Re: Simulation problem
From: Alan Fitch <alan.fitch@doulos.com>
Date: Fri, 11 Feb 2000 09:25:04 +0000
Links: << >>  << T >>  << A >>
In article <87vrg6$jdt$1@news.vsnl.net.in>, Pradeep Rao
<pradeeprao@planetmail.com> writes
>Hi,
>I am using the following code to XOR two bytes. I am able to simulate it
>using Active HDL(3.1) and seems to work, but when I use Warp I get the
>following error while compiling :
>
>C:\warp\bin\WARP.EXE -q -e10 -w100 -o2 -yga -fO -fP -v10 -dC371 -pCY7C371-14
>3JC -b byte_xor.vhd
>VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95)
>Setting library 'work' to directory 'lc371'
>----------------------------------------
>Compiling 'byte_xor.vhd' in 'C:\WARP\EXAMPLES\Pradeep'.
>VHDL parser (C:\warp\bin\vhdlfe.exe V4 IR x95)
>Library 'work' => directory 'lc371'
>Linking 'C:\warp\lib\common\work\cypress.vif'.
>byte_xor.vhd (line 8, col 30):  (E56) Expected FUNCTION, but got IS
>Error occurred within 'PROCESS' at line 8, column 16 in byte_xor.vhd.
>byte_xor.vhd (line 8, col 30):  (E10) Syntax error at/before reserved symbol
>'is'.
>----------------------------------------

From the error, it looks like Warp doesn't support VHDL '93, or you
haven't enabled VHDL '93.

In VHDL '87, you have to leave out the 'is', i.e.

-- VHDL '87
process(xin1, xin2)
begin

--VHDL '93
process(xin1, xin2) is

So probably, Active HDL is set to accept 1993 syntax, and Cypress Warp
is set to accept VHDL 1987 syntax.

If you leave out the 'is', it is compatible with both VHDL 1987 and VHDL
1993.

kind regards

Alan 

-- 
Alan Fitch
DOULOS Ltd. 
        Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK
Tel: +44 (0)1425 471 223                    Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471 573             
**               Visit THE WINNING EDGE  www.doulos.com               **

Article: 20473
Subject: Re: Xilinx error message
From: Alan Fitch <alan.fitch@doulos.com>
Date: Fri, 11 Feb 2000 09:31:25 +0000
Links: << >>  << T >>  << A >>
In article <87v2gi$2enp$1@noao.edu>, Andy Peters <apeters.Nospam@nospam.
noao.edu.nospam> writes
>bjorn_lindegren@my-deja.com wrote in message
><87utdp$k24$1@nnrp1.deja.com>...
>>Hi using Xilinx foundation2.1i. (xc9536 vq44-15)
>>
>>Writing a VHDL program and recive an error
>>message:
>>The net'/ver1/klar' has more than one driver.
>>
>>All of our variables are STD_LOGIC.
>>
>[snip code]
>
>You drive the signal klar from more than one process.
>
>-- a
>-----------------------------------------
>Andy Peters
>Sr Electrical Engineer
>National Optical Astronomy Observatories
>950 N Cherry Ave
>Tucson, AZ 85719
>apeters (at) noao \dot\ edu
>
>"Money is property; it is not speech."
>            -- Justice John Paul Stevens
>
>
>

Also, you've used "if klar <= '1'" when I would guess you meant "if klar
= '1'" in the code below

regards

Alan

P.S. This is nothing to do with the error message, I just noticed it!


FEMTON_machine: process (CLK)

begin

if CLK'event and CLK = '1' then
        if RESET='1' then
                FEMTON <= S1;
                KLAR<='0';
                START<='1';
                START<='0';
        else
        case FEMTON is
                when S1 =>
                        START<='0';
                        if KLAR<='1' then  ---???
                                FEMTON <= S2;
                                KLAR<='0';
                                START<='1';
                        end if;
                when S2 =>
                        START<='0';
                        if KLAR<='1' then  ---???
                                FEMTON <= S1;
                                KLAR<='0';
                                START<='1';
                        end if;
                when others =>
                        null;
        end case;
        end if;
end if;
end process;

end fyren1_arch;

-- 
Alan Fitch
DOULOS Ltd. 
        Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK
Tel: +44 (0)1425 471 223                    Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471 573             
**               Visit THE WINNING EDGE  www.doulos.com               **

Article: 20474
Subject: Re: ROL VHDL operator.. need help!
From: Alan Fitch <alan.fitch@doulos.com>
Date: Fri, 11 Feb 2000 09:35:41 +0000
Links: << >>  << T >>  << A >>
In article <Pine.OSF.3.95.1000210225125.25643A-100000@plato.ucs.mun.ca>,
TeikMing Goh <ming@morgan.ucs.mun.ca> writes
>Hi All,
>
>Can someone tell me what library I should use in order to use ROL
>operation(rotate left)?  I used LIBRARY IEEE, use ieee.std_logic_1164.all
>and use ieee.std_logic_arith.all, but I got syntax error on that.
>Thank you
>
>Regards
>Teik-Ming
>
>
>
>

ROL is in NUMERIC_STD, but it only works on type UNSIGNED, not on
STD_LOGIC_VECTOR.

e.g.

library IEEE;
use IEEE.STD_LOGIC_1164.all, IEEE.NUMERIC_STD.all;

entity
...

architecture...

   signal U, UU : UNSIGNED(7 downto 0);
   signal V, VV : STD_LOGIC_VECTOR(7 downto 0);

begin

...
   
  UU <= U ROL 1;

-- for std_logic_vector, use  concatenation

  VV <= V(6 downto 0) & V(7);




kind regards

Alan
-- 
Alan Fitch
DOULOS Ltd. 
        Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK
Tel: +44 (0)1425 471 223                    Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471 573             
**               Visit THE WINNING EDGE  www.doulos.com               **



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search