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 36575

Article: 36575
Subject: Re: Hex numbers in VHDL
From: Edwin Naroska <edwin@ds.e-technik.uni-dortmund.de>
Date: Mon, 12 Nov 2001 20:07:40 +0100
Links: << >>  << T >>  << A >>
Hi,


Chua Kah Hean wrote:

>>-------
>>function hex10 
>>  ( hex12 : std_logic_vector(11 downto 0))
>>return std_logic_vector is
>>begin
>>  return hex12(9 downto 0);
>>end hex10;
>>-------
>>
>>and use:
>>
>>slv(9 downto 0) <= hex10(X"3AC");
>>
> 
> Hi all experts out there,
> 
> I remember having a problem with the case statement when using this
> approach.  For example, the case statement below will not compile
> because hex10(X"3AC") is not locally static.  I think even if we make
> hex10 a pure function taking in constants only, we only make it
> globally static only, still not acceptable to the case statement. 
> Does anybody have a solution to this?  Thanks in advance.
> 
> case addr is
>   when hex10(X"3AC") => REG_3AC <= edi;
>   when others => null;
> end case;
> 



How about using integers:


    case to_integer(unsigned(addr)) is
   	when 16#3ac# => ...;
   	when others => null;
    end case;


--
Edwin


Article: 36576
Subject: Xilinx F 2.1i files incompatible with 4.1i
From: arast@inficom.com (Alex Rast)
Date: Mon, 12 Nov 2001 19:43:03 GMT
Links: << >>  << T >>  << A >>
Nothing like lack of backward compatibility. We just upgraded to Foundation 
4.1i. Now I'm finding the new S/W won't read any of my files created in 2.1i. 
Is there are file conversion/import utility? Or am I missing a trick? We need 
to get the files migrated to 4.1i ASAP because I need to modify several of 
them as I speak.

Thanks for any suggestions.

Alex Rast
arast@inficom.com
arast@qwest.net 

Article: 36577
Subject: Jpeg 2000
From: Eduardo Augusto Bezerra <eduardob@acm.org>
Date: Mon, 12 Nov 2001 19:56:55 +0000
Links: << >>  << T >>  << A >>
Hello

We are trying to do a hardware implementation of JPEG2000 to be used for
at least 15fps video. From the algorithm, it looks to us like a
hardware/software co-design seems more feasilble than a pure hardware
implementation. Any thoughts on this?

We are also thinking of using a Virtex-II FPGA as a prototyping platform
perhaps
with an embedded processor. Other options we are investigating are
Altera and
Actel FPGAs but we would be happy for your advice on this subject.

Many thanks

Marianne.

--
Altek Technologies Ltd.
East Sussex Advanced Technology Hub
Ashdown House
Brighton
BN1 9RT

tel. +44 (0)1273 877703

Article: 36578
Subject: Re: Carry chain in Virtex II
From: Neil Franklin <neil@franklin.ch.remove>
Date: 12 Nov 2001 21:19:08 +0100
Links: << >>  << T >>  << A >>
ndeshmukh@yahoo.com (nitin) writes:

>    well i suppose the floor planning of the slices within a CLB is
> driven by the fact that they were going to have two carry chains
> through it... so they put two this side & two that side...  other wise
> why not all four in a column...?

Because the aspect ration of the CLBs would get problematic.

XC3000 and XC4000 have 2x1 LUTs/CLB
XC5200 has 4x1 LUTs/CLB
Virtex has 2x2 LUTs/CLB
Virtex-2 has 4x2 LUTs/CLB

Having a "square" was obviously considered better in Virtex. And 4x2
is the nearest possible with 8 LUTs/CLB.

Do not forget that having "high" CLBs with 8x1 ratio would result in
less dense horizontal wiring, or require wider (and so asymmetrical)
wiring bundles in horizontal direction.

Alteras FLEX chips actually do this so (8x1 or 10x1), because they
are adapted CPLD designs (with the product term array replaced by
PIPs and the ORs replaced by LUTs).

OTOH Atmel has 1x1 CLBs.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 36579
Subject: Re: ZX81 production run, is there any interest?
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Mon, 12 Nov 2001 20:49:04 -0000
Links: << >>  << T >>  << A >>


<Big Snip>


All,

Has anyone thought of setting up a specific group for this.
Seems there is loads of interest but no coordination.

I'm interested too

Dave (via comp.arch.fpga)



Article: 36580
Subject: Re: Incrementing counter from state-machine
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 12 Nov 2001 21:41:59 GMT
Links: << >>  << T >>  << A >>
Russell Shaw wrote:
> 
> When the state machine enters state 2 and gets to <1>, then
> ptr_en<='1'. Can i assume the counter at <2> will be clocked
> in advance of ptr_en being tested at <3> ?  I don't know
> what to assume about the closeness of timing between the
> counter clock <2>, and the state machine clock <4>.

First things first: look at what happens when you see a rising edge of
the clock.  The following all happen simultaneously (to split an infinitive):

a) the value of state gets updated from next_state; and
b) the counter process tests the reset and enable signals and updates
the counter if necessary.

The first assignment is easy -- the value of next_state is essentially
copied to state.

Think about the second.  The ONLY thing you (or rather, your process)
care about is the *state of all the signals that affect the outcome _AT
THE RISING EDGE OF THE CLOCK._*  So, at the rising edge of the clock,
one of three things will happen:

1) ptr is zeroed.
2) ptr is incremented.
3) ptr remains untouched.

Now, to your state machine.  The state machine process is only triggered
when there's a change on either state or ptr.  Now, since both state and
ptr both change with the clock, they take on their new values after the
clock changes.  Therefore, the assignments to ptr_reset and ptr_enable
take place AFTER state and ptr change, so the new values of ptr_reset
and ptr_enable won't affect state and ptr until the NEXT clock edge.

This is Delta Delays 101.

Now, if *I* were writing this code, which is not what you asked, I'd
write it as a one-process (clocked) state machine, because I find it to
be less ambigious at first blush.

> Is there a way of keeping the clocks closely aligned? How
> do you specify to use a global clock path from within
> vhdl code? (i'm using leonardo)

You can assume that your synthesis tool will put all clocks on global
low-skew clock nets unless a) you tell it to do otherwise, or b) your
design has more clocks than global low-skew clock buffers.

--a


> TIA
> 
> library ieee;
> use ieee.numeric_bit.all;
> 
> entity host is
>     port(
>         reset: in bit;
>         clk: in bit);
> end host;
> 
> architecture arch of host is
> 
> subtype stype is integer range 0 to 2;
> signal state,next_state: stype;
> 
> signal ptr_reset,ptr_en: bit;
> signal ptr: integer range 0 to 16;
> 
> begin
> 
> ptr_cntr:
>     process
>     begin
> <2>     wait until clk'event and clk='1';
>         if ptr_reset='1'
>         then
>             ptr<=0;
> <3>     elsif ptr_en='1'
>         then
>             ptr<=ptr+1;
>         end if;
>     end process;
> 
> host_proc:
>     process(state,ptr)
>     begin
>         report "Ans= " & integer'image(ptr);
>         case state is
>         when 0=>
>             ptr_reset<='1';  -- reset ptr
>             ptr_en<='0';
>             next_state<=1;
>         when 1=>
>             ptr_reset<='0';
>             ptr_en<='0';
>             next_state<=2;
>         when 2=>
>             if ptr<16
>             then
> <1>             ptr_en<='1';        -- inc ptr
>                 next_state<=1;
>             else
>                 next_state<=0;
>             end if;
>         end case;
>     end process;
> 
> 
> state_proc:
>     process(reset,clk,next_state)
>     begin
>         if reset='1'
>         then
>             state<=0;
> <4>     elsif clk'event and clk='1'
>         then
>             state<=next_state;
>         end if;
>     end process;
> 
> end arch;

Article: 36581
Subject: Re: Incrementing counter from state-machine
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 12 Nov 2001 13:52:58 -0800
Links: << >>  << T >>  << A >>
Russell Shaw wrote:
> 
> Hi all,
> 
> I've got funny problems of code like this not working well
> in the chip (acex 1k30 with 5MHz clock).

Consider adding some outputs to your entity 
to avoid a null synthesis.

Consider doing simulation before synthesis.

By single stepping through a testbench, you
can answer all of your own questions.

> Is there a way of keeping the clocks closely aligned? 

Make sure you use one of the dedicated global
clock/reset pins for your clock.

> How
> do you specify to use a global clock path from within
> vhdl code? (i'm using leonardo)

I prefer to keep vhdl code free of pin assignments.
Let the place and route pick the pins and then
edit the resulting assignment file.

 --Mike Treseler

Article: 36582
Subject: CASE vs. IF statements
From: "Sul Weh" <sweather1999@yahoo.com>
Date: Mon, 12 Nov 2001 21:57:09 GMT
Links: << >>  << T >>  << A >>
What is the advantages/disadvantages of using a CASE statement or an if
statement?
For example, if I have 10 arrays of 10 integers (array0, array1,...) and I
want to sequentially output each array I can either use a CASE statment or a
10 separate IF statements.
e.g. if (counter = 0) then ... end if
if (counter = 1) then ... end if

What I have seen is the clk is slower in a CASE statement than an IF
statement because the counter has a huge fanout.

any advice or comments?

thanks

SW



Article: 36583
Subject: Re: ideas
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 12 Nov 2001 22:27:15 GMT
Links: << >>  << T >>  << A >>
Samuel Bogale wrote:
> 
> Can someone suggest ideas what FPGA can be used for?

Um, vending machines, traffic-light controllers, pizza-delivery route optimizers...

--a

Article: 36584
Subject: Re: Interleaver and Reed Solomon Encoder example
From: FredInAShed <FredInAShed@blueyonder.co.uk>
Date: Mon, 12 Nov 2001 22:28:54 GMT
Links: << >>  << T >>  << A >>
You could just get them off the shelf at
http://www.xilinx.com/ipcenter/fec_index.htm



srinas wrote:

> Dear All,
>  I have to implement a Reed Solomon Encoder and a convolutional
> Interleaver.
> Could anybody send me some examples for a (208,188)or DVB standard RS
> coder (only the encoder) and the Interleaver.
>
> Note:
> The link
> http://www.fokus.gmd.de/research/cc/mobra/products/fec/content.html
>
> is unavailable now.
> Does anybody know where it is know?
>
> Thanks


Article: 36585
Subject: Re: Multiple levels of reset in CPLD
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 12 Nov 2001 22:37:44 GMT
Links: << >>  << T >>  << A >>
Dean,

Try using the push-button reset (perhaps through some debouncing) to
pull the FPGA INIT# line low, which will start the FPGA configuration
process.  If the CPLD's FPGA-configuration logic is essentially isolated
from the rest of the CPLD logic, you won't need another reset signal.

When I did an FPGA-configurator-in-a-9536, it was a state machine that
idled when done (or in event of configuration failure).  In that mode,
it would wait for the FPGA to tell it that it wanted to be configured.

--a

Dean Armstrong wrote:
> 
> Hi All,
> 
> I am designing a system which contains a Xilinx XC95288XL CPLD.
> 
> This CPLD has two functions. It must act as an FPGA loader, reading an
> FPGA image from ROM and writing it to a Xilinx Spartan II. The second
> function is for it to act as an I/O device for the Spartan (which is
> configured as a CPU). It is always in only one of these two modes.
> 
> There are two possible reset levels on the board.
> 
> A hard reset (equivalent to power cycling the board, but also possible
> via a button) should cause the CPLD to configure the Spartan II.
> 
> A CPU reset (normal reset button) should cause the CPLDs I/O mode to
> reset itself (clear status and control registers).
> 
> I would like to know if this is possible to do using the XC95288XL.
> On this chip there is only one GSR input. I would probably use this for
> the board reset input. Can I use a normal I/O pin for the second reset
> signal?
> 
> Thanks very much,
> Dean Armstrong

Article: 36586
Subject: Re: Xilinx dedicated IO pins
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 12 Nov 2001 22:39:36 GMT
Links: << >>  << T >>  << A >>
Jens-Christian Lache wrote:

> I'm not sure if I understood the question right. According to
> ds_001_4.pdf
> these pins are I/O pins, so there is no reason why not to use them.

Well, it complicates whatever non-startup logic is connected to 'em.

I always leave the configuration/dedicated pins alone.  Saves lotsa
headaches later.

-a

Article: 36587
Subject: Re: Question about pipelining a design
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 12 Nov 2001 23:12:01 GMT
Links: << >>  << T >>  << A >>
Marty wrote:
> 
> I am working on a waveform generator that gets data from a dual-port RAM,
> and outputs it. It also has timing and jump instructions in the RAM data.
> The goal is to run at 50 MHz.  The RAM, is 64K deep, and 15 nS access time.
> 
> I can get the machine to simulate at 33 MHz, but not at 50 MHz.  I think the
> way to solve this is to redesign the machine in a pipelined form.
> I have fit the non pipelined design into an Altera 7512AE.
> Some of the problems are getting the machine to do relative jumps - absolute
> jumps work.

I just finished a waveform generator design, with single-port sync SRAM
storing the pattern and jump information.  It's pipelined, too.

Relative jumps require an adder, which probably wants a clock tick to
compute a sum.  But you already have an adder if you've got an
incrementing counter for your address.  Normal operations add 1 to the
current address, relative jumps add some (possibly read from RAM) offset
to the current address, absolute jumps reload the address counter.

Consider that you're using a flow-through type sync SRAM.  On clock tick
1, an address is registered.  On clock tick two, your data appears on
the outputs.  (If you use pipelined SRAM, the data will appear with the
*second* clock after the address is registered.)  The trick to running
fast is to make sure you can compute a new address every clock tick. 
You can also "hold" things by deasserted the SRAM CKE# signal.  There's
other games you can play, too.
 
> Does anyone know of any tools to help visualize or design a project like this?

Pencil and paper (as well as ModelSim) worked for me ....

--a

Article: 36588
Subject: Re: Virtex 2 parts shipping = receiving
From: "Austin Franklin" <austin@dark98room.com>
Date: Mon, 12 Nov 2001 18:35:27 -0500
Links: << >>  << T >>  << A >>
Jim,

Thanks!  You're the first one to actually admit to having them IN hand!
What package are you using?

Regards,

Austin

"Jim Bittman" <jmbj@bittware.com> wrote in message
news:3BF00EF0.62AC256A@bittware.com...
> We've been using 10's of 2V1000's (XC2V1000-4FG), and have had no
> trouble with deliveries, and the prices have even been coming down!
>
> We recently asked about some 2V3000's and I think the quote was quite
> reasonable with respect to price and delivery.
>
> Austin Lesea wrote:
>
> > Austin F,
> >
> > As in shipments of parts?
> >
> > 2V40, 2V1000, 2V3000, 2V4000, 2V6000 ....
> >
> > Maybe someone didn't get their order in on time?
> >
> > Austin L
> >
>
> --
>  ********************************************************************
>  * Jim Bittman                      * Tel: 603-226-0404             *
>  * BittWare, Inc.                   * Fax: 603-226-6667             *
>  * 33 North Main Street             * E-Mail: jmbj@bittware.com     *
>  * Concord, NH 03301                * WWW: http://www.bittware.com  *
>  ********************************************************************
>
>



Article: 36589
Subject: Re: Incrementing counter from state-machine
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 13 Nov 2001 11:09:30 +1100
Links: << >>  << T >>  << A >>


Thomas Stanka wrote:
> 
> Hi all,
> 
> Russell Shaw <rjshaw@iprimus.com.au> wrote:
> 
> > Is there a way of keeping the clocks closely aligned? How
> > do you specify to use a global clock path from within
> 
> see below
> 
> [..]
> > <2>     wait until clk'event and clk='1';
> 
> I wouldn't use this in synthesizeable code.
> This is eqivalent to process(Clk) and leed to synchronous FF.

From what i've seen, its quite valid for synthesizeable code. Its
in Bhasker: A VHDL Synthesis Primer, and in the leonardo synthesis
manual.
 
> [..]
> >         when 2=>
> >             if ptr<16
> >             then
> > <1>             ptr_en<='1';        -- inc ptr
> >                 next_state<=1;
> 
> This is a Mealy description in a mainly Moore automate. First place to get
> problems, but should do in this case..
> 
> > state_proc:
> >     process(reset,clk,next_state)
> 
> This is your problem.
> If you want to sysnthesize your code, you've got two [1] kinds of proces:
> one for Logik and one for Register. If you want to get Register, your
> process should be sensitive to Clk and Reset, if you want to get logik, you
> should be sensitive to every signal that effects the signals changed during
> the process. Mixing both styles like your process creates latches.

But with synthesis, i think *everything* that gets assigned a value
within a process, has to be in the sensitivity list or leonardo gives
warnings. Only with a "wait until" line, does the process not have a
sensitivity list.
 
> Your code mixes synch. FF and asynch Latches (I wonder, that you get no
> errors or warnings during synthesis) something you should use _very_
> carefully.

The latches should just hold ptr_en and ptr_reset, because they're
not assigned in every case option.
 
> [1] actually two an a half, because sometimes you want Latches.

Article: 36590
Subject: Re: Incrementing counter from state-machine
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 13 Nov 2001 11:13:58 +1100
Links: << >>  << T >>  << A >>


Andy Peters wrote:
> 
> Russell Shaw wrote:
> >
> > When the state machine enters state 2 and gets to <1>, then
> > ptr_en<='1'. Can i assume the counter at <2> will be clocked
> > in advance of ptr_en being tested at <3> ?  I don't know
> > what to assume about the closeness of timing between the
> > counter clock <2>, and the state machine clock <4>.
> 
> First things first: look at what happens when you see a rising edge of
> the clock.  The following all happen simultaneously (to split an infinitive):
> 
> a) the value of state gets updated from next_state; and
> b) the counter process tests the reset and enable signals and updates
> the counter if necessary.
> 
> The first assignment is easy -- the value of next_state is essentially
> copied to state.
> 
> Think about the second.  The ONLY thing you (or rather, your process)
> care about is the *state of all the signals that affect the outcome _AT
> THE RISING EDGE OF THE CLOCK._*  So, at the rising edge of the clock,
> one of three things will happen:
> 
> 1) ptr is zeroed.
> 2) ptr is incremented.
> 3) ptr remains untouched.
> 
> Now, to your state machine.  The state machine process is only triggered
> when there's a change on either state or ptr.  Now, since both state and
> ptr both change with the clock, they take on their new values after the
> clock changes.  Therefore, the assignments to ptr_reset and ptr_enable
> take place AFTER state and ptr change, so the new values of ptr_reset
> and ptr_enable won't affect state and ptr until the NEXT clock edge.

agree with all of above.

> This is Delta Delays 101.
> 
> Now, if *I* were writing this code, which is not what you asked, I'd
> write it as a one-process (clocked) state machine, because I find it to
> be less ambigious at first blush.

I did that the first few times, but it wasn't clear how the code
would be synthesized when having numbers incremented inside of case
statements.

> > Is there a way of keeping the clocks closely aligned? How
> > do you specify to use a global clock path from within
> > vhdl code? (i'm using leonardo)
> 
> You can assume that your synthesis tool will put all clocks on global
> low-skew clock nets unless a) you tell it to do otherwise, or b) your
> design has more clocks than global low-skew clock buffers.

Article: 36591
Subject: Re: Incrementing counter from state-machine
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 13 Nov 2001 11:16:48 +1100
Links: << >>  << T >>  << A >>


Mike Treseler wrote:
> 
> Russell Shaw wrote:
> >
> > Hi all,
> >
> > I've got funny problems of code like this not working well
> > in the chip (acex 1k30 with 5MHz clock).
> 
> Consider adding some outputs to your entity
> to avoid a null synthesis.
> 
> Consider doing simulation before synthesis.
> 
> By single stepping through a testbench, you
> can answer all of your own questions.

Well, i did simulation to see why it wouldn't work (the code
in the original posting), but it did work.
 
> > Is there a way of keeping the clocks closely aligned?
> 
> Make sure you use one of the dedicated global
> clock/reset pins for your clock.

I'll try...

Article: 36592
Subject: Re: Decoupling capacitors on Virtex II
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 13 Nov 2001 11:27:32 +1100
Links: << >>  << T >>  << A >>
It should be easy to verify if your board will be ok. Just remove
the caps around one chip, power-up, and look at glitch levels on
the pins/pads with a high-speed cro (you'll need to have a good
ground-pin on the cro probe). If the glitching is less than 10%
of VCC, or adding the caps makes little difference, the caps
aren't really needed. Its important that the power-ground
planes are large in area, and adjacent (higher capacitance,
lower pulse impedance). Standard 2/4-layer board probably
wouldn't be good enough.

Austin Lesea wrote:
> 
> Russell,
> 
> You must enjoy dangerous living ....
> 
> And, the inductance of the flip chip packages is 5 to 8 times less than that of
> the wire bonded packages as there are no wires, just hundreds and hundreds of tiny
> solder balls over the entire top surface of the die connecting to ground and
> Vcc's.
> 
> Austin
> 
> Russell Shaw wrote:
> 
> > pete dudley wrote:
> > >
> > > Our bread and butter decoupling cap is .01uF (10nF) 0805 surface mount, like
> > > 1 per 4 VCC on fpga's, and we back them up with a few larger caps up to 10uF
> > > tantalums...
> > >
> > > We use terminated differential signalling for the high speed stuff if
> > > possible to cancel the ground bounce and use slew rate control on the rest.
> > >
> > > On the highest end of the switching spectrum the ground/power planes help
> > > you and my guess is that 100pF or smaller chip caps do nothing for you.
> > >
> > > Once we built some multiprocessor boards that ran about 150MHz but the caps
> > > were bad so we removed all of them. The boards ran fine without any
> > > decoupling. I'd like to try that experiment again with high speed fpga's.
> > >
> > > I like Austin's idea of tuning the caps to the operating frequency.
> >
> > With *thin* layers (such as in 8 layer boards etc), all the caps
> > can be left off except one electro per board. The VCC and GND planes
> > must be adjacent to provide very low planar transmission line
> > impedance (lumped capacitance is meaningless at fast edges).
> >
> > A bit of track to bypass caps and vias hardly matters relative
> > to the inductance in many internal bond wires.

Article: 36593
Subject: Re: Funny voltage levels
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 13 Nov 2001 11:32:52 +1100
Links: << >>  << T >>  << A >>


Nial Stewart wrote:

> > However, i
> > think there might be a clock-alignment problem somewhere.
> 
> There shouldn't be. If you've used a global clock input pin
> for your clock they guarantee set up and hold times from
> egister to register. it's then just a matter or making
> sure you're writing good synchronous code.

Actually, i was using the global clock pin for a 20MHz clock,
then the 5MHz clock i used for everything comes from a vhdl
x4 counter, so i'll need to check that clock routing.

Article: 36594
Subject: Re: CASE vs. IF statements
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 13 Nov 2001 11:40:47 +1100
Links: << >>  << T >>  << A >>


Sul Weh wrote:
> 
> What is the advantages/disadvantages of using a CASE statement or an if
> statement?
> For example, if I have 10 arrays of 10 integers (array0, array1,...) and I
> want to sequentially output each array I can either use a CASE statment or a
> 10 separate IF statements.
> e.g. if (counter = 0) then ... end if
> if (counter = 1) then ... end if
> 
> What I have seen is the clk is slower in a CASE statement than an IF
> statement because the counter has a huge fanout.
> 
> any advice or comments?

I'd do it this way (less code): Declare an array of 10 items with 10-bit
integers, and initialize them. The synthesizer should see this
hard-coding,
and make a small rom. Now all you need to do is have a counter index the
pointer of this array:  output_sig<=array_of_int(cntr);

Article: 36595
Subject: Timing constraints for multiple clock logic paths
From: grtuvwx@yahoo.com (G)
Date: 12 Nov 2001 16:43:36 -0800
Links: << >>  << T >>  << A >>
Hi,
I'm using a Spartan II-50-5 with Base Express 3.3.08i.   I have a design where
a main state machine sends out clock enables to registers in other areas.  A
data path I have between two sets of registers contains combinatorial logic that
takes ~17ns to complete.  My clock is 9ns.  Since I control when the clock
enables happen in the main state machine, I know I have plenty of time to let
that path chug.  How do I convey this information to the Xilinx tools?
The par comes back saying that the 9ns clock can't be met because of these
extra long paths.  I'd rather not pipeline the logic because that would use up
a lot of FF's, which are already getting scarce.  Bigger/faster parts are also
out due to cost.

Thanks for any ideas or pointers,
g

Article: 36596
Subject: Re: CASE vs. IF statements
From: "Sul Weh" <sweather1999@yahoo.com>
Date: Tue, 13 Nov 2001 01:19:18 GMT
Links: << >>  << T >>  << A >>
Yes, but if I have *10* roms, each each 10 integers in them then it would be
if (cntr2 = 0) then
output_sig <= array_of_int0(cntr)

so I have 10 arrays of 10 integers
"Russell Shaw" <rjshaw@iprimus.com.au> wrote in message
news:3BF06C0F.32B632D2@iprimus.com.au...
>
>
> Sul Weh wrote:
> >
> > What is the advantages/disadvantages of using a CASE statement or an if
> > statement?
> > For example, if I have 10 arrays of 10 integers (array0, array1,...) and
I
> > want to sequentially output each array I can either use a CASE statment
or a
> > 10 separate IF statements.
> > e.g. if (counter = 0) then ... end if
> > if (counter = 1) then ... end if
> >
> > What I have seen is the clk is slower in a CASE statement than an IF
> > statement because the counter has a huge fanout.
> >
> > any advice or comments?
>
> I'd do it this way (less code): Declare an array of 10 items with 10-bit
> integers, and initialize them. The synthesizer should see this
> hard-coding,
> and make a small rom. Now all you need to do is have a counter index the
> pointer of this array:  output_sig<=array_of_int(cntr);



Article: 36597
Subject: Re: ideas
From: Ray Andraka <ray@andraka.com>
Date: Tue, 13 Nov 2001 02:00:11 GMT
Links: << >>  << T >>  << A >>
You forgot elevator controllers and blackjack machines ;-)

Andy Peters wrote:

> Samuel Bogale wrote:
> >
> > Can someone suggest ideas what FPGA can be used for?
>
> Um, vending machines, traffic-light controllers, pizza-delivery route optimizers...
>
> --a

--
--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: 36598
Subject: Re: ideas
From: rk <stellare@nospamplease.erols.com>
Date: Mon, 12 Nov 2001 21:33:08 -0500
Links: << >>  << T >>  << A >>
And the classical number sequence recognizer.

Ray Andraka wrote:
> 
> You forgot elevator controllers and blackjack machines ;-)
> 
> Andy Peters wrote:
> 
> > Samuel Bogale wrote:
> > >
> > > Can someone suggest ideas what FPGA can be used for?
> >
> > Um, vending machines, traffic-light controllers, pizza-delivery route optimizers...

-- 
rk
Just an OldEngineer

The history of engineering is full of examples of dramatic failures that
were once considered confident extrapolations of successful designs.
-- H. Petroski

No extrapolating without a permit.
-- rk, circa 1988

Article: 36599
Subject: Re: Incrementing counter from state-machine
From: "Jim" <johnsonw10@hotmail.com>
Date: Tue, 13 Nov 2001 03:00:00 GMT
Links: << >>  << T >>  << A >>
> > By single stepping through a testbench, you
> > can answer all of your own questions.
>
> Well, i did simulation to see why it wouldn't work (the code
> in the original posting), but it did work.
>

Your code is perfectly OK and should work in any unit delay simulators.

> > > Is there a way of keeping the clocks closely aligned?
> >
> > Make sure you use one of the dedicated global
> > clock/reset pins for your clock.
>
> I'll try...

As Andy.P said in his message, the synthesis tool should add a global clock
buffer to your clock tree. The clock skew out of the global buffer is
usually very low (within 0.1ns in one Xilinx Virtex FPGA I had used before).
I think it is a valid assumption that your logic delays are always longer
than the clock skew. I am not sure about acex 1k30 though. My guess is that
it should have similar thing. If for any reason, the synthesis tool doesn't
pick the global clock buffer for your clock, you can always add a global
buffer marco in your code to force the tool to use one. Or try to use a
better synthesis tool.








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