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 25300

Article: 25300
Subject: ADV7185 & AVD7194
From: rickballantyne@home.com
Date: Tue, 05 Sep 2000 14:32:15 GMT
Links: << >>  << T >>  << A >>
Joseph
I have a couple of questions regarding the
7185/7194 eval board. You mentioned back in June
that you were expecting rev 2 silicon to be
available in the Aug/Sept time frame and that the
evaluation board would be equipped with the new
silicon. I do not see any mention of the eval
board on the Analog Devices web site, so I do not
know the part number or how the order this
product. In addition are you going to put the
board schematic and/or a reference design on the
web site?

The recommended circuit layout in the preliminary
data sheet shows termination resistors for
the video inputs, I suspect that the resistors are
75 ohms for CVBS and YUV but I'm not
sure as to the values  for S-video inputs. Is the
RC network the only termination required?

--

/ /\/  Rick Ballantyne           Senior Staff
Engineer
\ \    Xilinx, Inc.
/ /    34 Hampel Cres.           Phone:(613) 836
5255
\_\/\  Stittsville, Ontario      Fax:  (613) 836
5393
       Canada K2S 1E4
E-Mail:rickb@xilinx.com

Xilinx's Web @ http://www.xilinx.com


Article: 25301
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Ray Andraka <ray@andraka.com>
Date: Tue, 05 Sep 2000 18:08:13 GMT
Links: << >>  << T >>  << A >>
I've had several inquiries off-line about how to generate many local logic '1's
or '0's, so I'll elaborate here.

Basically the idea is to explicitly generate local '1' and '0' values and
control where they are connected.  The local constants can be generated in
virtex from the carry chain, a LUT or an unused flip-flop.  Note however that
generally speaking, these will be removed either in synthesis or in the place
and route if they are recognized as being a constant.  Generally speaking, black
boxes don't seem to have a problem getting optimized out.  That said, I think
the best solution is to directly instantiate MUXCY's with the select connected
to '1' and the CI and DI connected to either '1' or '0' depending on what you
need.  This winds up having to go in the bottom half of a slice, and it blocks
the BX input.  I think in most cases this is the best option, and it avoids
using attributes that may not be supported.  A similar trick can be used
substituting a LUT or a flip-flop (with the D set to an appropriate constant). 
In the case of the flip-flop, It can be inferred rather than instantiated, but I
think you need to put a syn_preserve attribute on it to keep synplicity from
optimizing it out.  SImilarly, a keep attribute might have to be placed on the
nets into or out of the fl,.ip-flop to keep the mapper from cutting it out.  In
any event, the direct instantiation of muxcys as shown below does do the trick 


Here is a little test code that shows it in action.  I ran this through
synplicity 6.0 and Alliance 3.1 to verify that it does indeed generate separate
local '1's and '0's:

--Author			Ray Andraka
--					Andraka Consulting Group, Inc.
--					16 Arcadia Drive
--					North Kingstown, RI 02852
--					+1 401-884-7930  FAX +1 401-884-7950
--					email: randraka@ids.net
--					http://users.ids.net/~randraka
--
-- copyright (c) 1999, Andraka Consulting Group, Inc. All rights reserved
--
-- 


library IEEE;
use IEEE.std_logic_1164.all;	  
use IEEE.numeric_std.all;
--synthesis translate_off
library unisim;
use unisim.all;	  
--synthesis translate_on

entity srl16_demo is									
	port (	
		clk: in STD_LOGIC;	
		di: in STD_LOGIC_VECTOR(0 to 3);
		qo:out STD_LOGIC_VECTOR(0 to 3)
);
end srl16_demo;


architecture structural of srl16_demo is												  
	-- Component declaration of the "MUXCY(MUXCY_V)" unit
	-- File name contains "MUXCY" entity: .\src\unisim_VITAL.vhd
	component MUXCY
	port(
		O : out std_ulogic;
		DI : in std_ulogic;
		CI : in std_ulogic;
		S : in std_ulogic);
	end component;	 
attribute syn_black_box:boolean;
attribute syn_black_box of MUXCY : component is true;

	-- Component declaration of the "srl16(srl16_v)" unit
	-- File name contains "srl16" entity: .\src\unisim_VITAL.vhd
	component srl16
	port(
		D : in std_ulogic;
		CLK : in std_ulogic;
		A0 : in std_ulogic;
		A1 : in std_ulogic;
		A2 : in std_ulogic;
		A3 : in std_ulogic;
		Q : out std_ulogic);
	end component;
attribute syn_black_box of srl16 : component is true;
		
		
begin
	set:for i in 0 to 3 generate	
		signal logic_0a:std_logic;
		signal logic_1a:std_logic;		 
		signal d, q: std_logic;
	begin					   
	d<= di(i);
	qo(i)<=q;
	U1: MUXCY port map(
		o=>logic_0a,
		DI=>'0',
		CI=>'0',
		S=>	'1');
	U2: MUXCY port map(
		o=>logic_1a,
		DI=>'1',
		CI=>'1',
		S=>	'1');
	U3: SRL16 port map(
		D=> d,
		CLK=> clk,
		A0=> logic_0a,
		A1=> logic_1a,
		A2=> logic_0a,
		A3=> logic_1a, 
		Q=> q);
	end generate set;
	
end structural;



Ray Andraka wrote:
> 
> I've ran into this one first in v3.1.  You can get around it by explicitly
> defining logic_1 and logic_0 signals. for smaller groups of SRL16's.  You may
> need to put the appropriate attributes on the instances to keep them from beig
> eaten in synthesis.
> 
> news@rtrussell.co.uk wrote:
> >
> > Johan Petersson <Johan.Petersson@uab.ericsson.se> wrote:
> >
> > : All I can say is that the problem does not remain in
> > : 3.1i, which improves par times enormously!
> >
> > Actually it turns out that the problem I am having is
> > related to the use of very large numbers of SRL16 shift-
> > registers, which is resulting in over 25000 VCC routes!
> > I have confirmed that the problem is just the same in
> > 3.1i; it is described at support.xilinx.com thus:
> >
> > "Currently map generates a GLOBAL_LOGIC1 and GLOBAL_LOGIC0
> >  signal to drive constants onto the F & G inputs of LUT RAM
> >  used in the SRL library element. The extreme number of VCC
> >  loads that can occur in such designs will often lead to
> >  excessive router run time as well as poor circuit performance
> >  due to route congestion."
> >
> > The solution recommended is to add the environment variable
> > XIL_MAP_NOSHIFTONES, but when I do this 'bitgen' aborts with
> > over 25000 errors telling me that the F and G inputs are not
> > connected!  If I ignore these errors (bitgen -d) the device
> > doesn't work, exhibiting all the symptoms of the shift-
> > registers not operating correctly.
> >
> > Richard.
> > http://www.rtrussell.co.uk/
> 
> --
> -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  or http://www.fpga-guru.com

-- 
-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  or http://www.fpga-guru.com
Article: 25302
Subject: Re: Slow routing of PWR/GND (Virtex)
From: fjz001@email.mot.com
Date: Tue, 05 Sep 2000 20:02:23 GMT
Links: << >>  << T >>  << A >>
Richard,

Try setting XIL_PWRGND_MAX_SOURCES_PER_LOAD=50. This will reduce
the "search radius" of PAR for eligible PWR / GND connections. Sadly, I
do not recall what the default value should be.... This value works
well with our current 2000E designs.

Jeff

>
> news@rtrussell.co.uk wrote:
> >
> > The problem of very slow routing of PWR/GND nets is
> > supposed to be fixed in 2.1i Service Pack 6, but I
> > am still suffering from it (running the Unix tools
> > on a Sun Ultra 10 workstation).  An XCV600 is taking
> > about 8 hours to build, of which over 7 hours is the
> > PWR/GND routing (all signals are successfully routed
> > in under 40 minutes).  Does the problem remain in SP6,
> > or is this a specific issue related to the use of the
> > Unix version ?
> >
> > Richard.
> > http://www.rtrussell.co.uk/
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25303
Subject: sowtware/programmer
From: "Daniel Nilsson" <danielnilsson@hem3.passagen.se>
Date: Wed, 6 Sep 2000 00:37:44 +0200
Links: << >>  << T >>  << A >>
Hi. Does anyone know of free software and/or projects for building your own
fpga programmer for some sort of fpga?




Article: 25304
Subject: Re: Mealy vs Moore FSM model
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 5 Sep 2000 23:08:09 GMT
Links: << >>  << T >>  << A >>
Be warned, this is pet-peeve of mine :-)

A big consideration between Mealy & Moore coding style is how much of a mess
your verilog source becomes.  The Mealy style has you separating out your
next state logic from your 'always @(posedge clk)' block.  This means that
you need to type in all of the signal names in the header of the
combinatorial always block, type all your register names at the beginning of
the block if you want old values to be carried automatically to new values,
and retype them again to declare all the 'ns_' prefixed versions of your
registers.  It's a huge mess.  Stick with Moore for smaller, simpler, more
readable code, and generate Mealy signals in your Moore state machines (and
then, only when you have to).

Simple Moore state machine:

wire start, ok, done;
reg q;
reg [1:0] state;

always @(posedge clk or negedge reset_l)
  if(~negedge reset_l)
    begin
      state <= IDLE;
    end
  else case(state)
    IDLE:
      begin
        if(start)
          begin
            q <= 1;
            state <= FIRST;
          end
      end

    FIRST:
      begin
        if(ok)
          begin
            q <= 0;
            state <= SECOND;
          end
      end

    SECOND:
      begin
        if(done) state <= IDLE;
      end
  endcase

Messy Mealy version of above:

wire start, ok, done;
reg q, ns_q;			// extra regs
reg [1:0] state, ns_state;

always @(posedge clk or negedge reset_l)
  if(~reset_l)
    begin
      state<=IDLE;
      q<=0;
    end
  else
    begin
      state<=ns_state;		// State machine is in separate always block.
      q<=ns_q;
    end

always @(state or start or ok or done)	// List all inputs
  begin
    ns_q = q;			// Copy all registers
    ns_state = state;
    case(ns_state)		// Finally, the state machine
      IDLE:
        begin
          if(start)
            begin
              ns_q=1;
              ns_state=FIRST;
            end
        end

      FIRST:
        begin
          if(ok)
            begin
              ns_q=0;
              ns_state=SECOND;
            end
        end

      SECOND:
        begin
          if(done) ns_state=IDLE;
        end
    endcase
  end




False arguments against Moore in Verilog:

- registers will revert to zero from state-to-state.
     This is not true.  Only the registers on the left hand side of <=
     change, others remain the same.



- you can not use expression temporary variables in Moore:
     This is not true.  Consider the following code fragment:

reg tmp;	// Temporary value

always @(posedge clk or negedge reset_l)
  ...
  case(state)
    begin
      STATE_FOO:
        begin
          tmp = input1;
          if(j) tmp = input2;
          foo <= tmp;
          state <= STATE_BAR;
        end
  ...

    Notice that 'tmp' uses = instead of <=.  = assignments happen
    sequenctially, and before any <= assignments.  In the code above, 'tmp'
    will actually be optimized out by the synthesizer (it will not use up
    any flip-flops or latches).



- It is difficult to share flip-flops, output registers, etc. between state
    machines in Moore.  This is the main reason people use the Mealy style,
    and is not true either: you can generate Mealy signals in Moore style
    state machines.  First, here is an example of the problem:

reg [15:0] databus;

// State machine 1
always @(posedge clk)
  ...
  FOO:
    begin
      database <= inputbus;
      state1 <= NEXT;

// State machine 2
always @(posedge clk)
  ...
  FRED:
    begin
      database <= internalregister;
      state2 <= NEXT;

This fails, since two state machines can not write to the same register.
This can be fixed with Mealy signals, and without having to put all of your
next state logic in a separate always blocks as is commonly done.  The key
is to understand the difference between '=' and '<=':

reg awrites, bwrites;	// Mealy signals
reg [15:0] databus;

// Bus driver
always @(posedge clk)
  if(awrites) databus<=inputbus;
  else if(bwrites) databus<=internalregister;

// State machine 1
always @(posedge clk)
  begin
    awrites=0;		// Must always initialize Mealy output signals.
    ...
    case(state1)
      ...
      FOO:
        begin
          awrites = 1;	// Note that =, not <= is used here
          state1 <= NEXT;

// State machine 2
always @(posedge clk)
  begin
    bwrites=0;		// Must always initialize Mealy signals
    ...
    case(state2)
      ...
      FRED:
        begin
          bwrites = 1;	// Note that = is used here.
          state2 <= NEXT;
  end

Most state machines have few Mealy signals, and many Moore signals.  Thus
this ends up being the most concise way of coding state machines.  It has
the advantage that the potentially slow Mealy signals are very apparent,
since they have to be initialized to avoid latches.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 25305
Subject: Re: sowtware/programmer
From: Dave Vanden Bout <devb@xess.com>
Date: Tue, 05 Sep 2000 20:07:57 -0400
Links: << >>  << T >>  << A >>

--------------B8AF6CB46C2DFC40D997D4BD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Daniel Nilsson wrote:

> Hi. Does anyone know of free software and/or projects for building your own
> fpga programmer for some sort of fpga?

The appendix in "The Practical Xilinx Designer Lab Book" (ISBN 0-13-021617-8)
shows how to build both CPLD-based and FPGA-based protoboards.

You can download the free WebPACK software from Xilinx.  Here is a document
that shows how to get it, install it, and use it for implementing CPLD-based
designs.

http://www.optimagic.com has many links to free software, tutorials, and
prototyping boards.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


--------------B8AF6CB46C2DFC40D997D4BD
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Daniel Nilsson wrote:
<blockquote TYPE=CITE>Hi. Does anyone know of free software and/or projects
for building your own
<br>fpga programmer for some sort of fpga?</blockquote>
The appendix in "The Practical Xilinx Designer Lab Book" (ISBN 0-13-021617-8)
shows how to build both CPLD-based and FPGA-based protoboards.
<p>You can download the free WebPACK software from Xilinx.&nbsp; Here is
a <a href="http://www.xess.com/manuals/webpack-3_1.pdf">document</a> that
shows how to get it, install it, and use it for implementing CPLD-based
designs.
<p><A HREF="http://www.optimagic.com">http://www.optimagic.com</A> has many links to free software, tutorials,
and prototyping boards.
<p>--
<br>|| Dr. Dave Van den Bout&nbsp;&nbsp; XESS Corp.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(919) 387-0076 ||
<br>|| devb@xess.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2608 Sweetgum Dr.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (800) 549-9377
||
<br>|| <A HREF="http://www.xess.com">http://www.xess.com</A>&nbsp;&nbsp;&nbsp;&nbsp; Apex, NC 27502 USA&nbsp;&nbsp;
FAX:(919) 387-1302 ||
<br>&nbsp;</html>

--------------B8AF6CB46C2DFC40D997D4BD--

Article: 25306
Subject: Re: Model for 8101 - 8104
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 05 Sep 2000 17:15:38 -0700
Links: << >>  << T >>  << A >>
"Ron" <skalarv@usa.net> writes:
> Looking for simulation model (VHDL) for 8101 or 8104

The only 8101 chip I know is the Intel 8101 256x4 static RAM
(equivalent to the Intel 2101).  Is that what you're looking for?
If not, it might help for you to provide more information.
Article: 25307
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Sep 2000 01:25:19 GMT
Links: << >>  << T >>  << A >>
There is/was a bug in the pwr/gnd algorithm that doesn't limit the fanout to
SRL16's like it does to other pwr/gnd nets.  For designs with lots of SRL16's
(and that covers a large percentage of DSP designs), that can lead to huge
power/ground nets.  Xilinx posted a solution for the '1's in solution 9603 which
is basically to leave the '1's open and let the lut internal pull-ups handle
them (it is done with an environment variable).  That doesn't help with the
'0's, which as I understand are the bigger problem.  The zero source can
apparently be overloaded when it drives too many LUT input pullups.  I first
encountered ths problem as a DRC error pinging it as an overloaded net.  Xilinx
said the DRC error is real because of loading issues, but did not have a ready
made workaround.  That is from where my workaround came from.  Now, that was in
the first release of 3.1.  It may have been fixed in a subsequent service pack,
I havent specifically inquired or investigated.

fjz001@email.mot.com wrote:
> 
> Richard,
> 
> Try setting XIL_PWRGND_MAX_SOURCES_PER_LOAD=50. This will reduce
> the "search radius" of PAR for eligible PWR / GND connections. Sadly, I
> do not recall what the default value should be.... This value works
> well with our current 2000E designs.
> 
> Jeff
> 
> >
> > news@rtrussell.co.uk wrote:
> > >
> > > The problem of very slow routing of PWR/GND nets is
> > > supposed to be fixed in 2.1i Service Pack 6, but I
> > > am still suffering from it (running the Unix tools
> > > on a Sun Ultra 10 workstation).  An XCV600 is taking
> > > about 8 hours to build, of which over 7 hours is the
> > > PWR/GND routing (all signals are successfully routed
> > > in under 40 minutes).  Does the problem remain in SP6,
> > > or is this a specific issue related to the use of the
> > > Unix version ?
> > >
> > > Richard.
> > > http://www.rtrussell.co.uk/
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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  or http://www.fpga-guru.com
Article: 25308
Subject: Re: Model for 8101 - 8104
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Sep 2000 01:27:52 GMT
Links: << >>  << T >>  << A >>
Boy, talk about a blast from the past!  Are those still being made?  I remember
using 2101's and 2102s in some of my first computers, and they were lots of
money then.

Eric Smith wrote:
> 
> "Ron" <skalarv@usa.net> writes:
> > Looking for simulation model (VHDL) for 8101 or 8104
> 
> The only 8101 chip I know is the Intel 8101 256x4 static RAM
> (equivalent to the Intel 2101).  Is that what you're looking for?
> If not, it might help for you to provide more information.

-- 
-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  or http://www.fpga-guru.com
Article: 25309
Subject: Program & Readback Spartan II from 188
From: P <mx3000@my-deja.com>
Date: Wed, 06 Sep 2000 04:57:59 GMT
Links: << >>  << T >>  << A >>
Hey,

My partner and I are getting ready to send out a board with
a Spartan II FPGA.  We want this to be as general as possible
so that we can test as much as possible.  Our current stumbling
block is with the programming and readback of the device.
We're hooking up the JTAG ports, and that seems relatively
easy.  But being serial, it's going to be very slow.  We wanted
to set up the parallel mode to do both programming and readback.

Currently, we're using an AM188 as the host device.  We've looked
at XAPP176 - Spartan II FPGA Family Configuration and Readback.
The configuration section is reasonably understandable,
but the readback section is somewhat skimpy.

Our best bet for the system is to set it up in a way where we do
both  'Non-Contiguous Data Strobing' and 'Controlled CCLK',
as described on pg 14 of XAPP176.  Thus we would only clock CCLK
when necessary, but CS# and WRITE# would be also be asserted
or deasserted inbetween CCLKs.

During readback, we need to both write commands and then read data
back from the FPGA.  Is it acceptable to pulse CS# and WRITE#
as described above during the write-command or read-data part,
as long as they are both valid during a CCLK?   Or do we need
to keep CS# and WRITE# in their proper states during the entire
readback process?

Note: CS# and WRITE# are the pins at the SpartanII.  There is
likely to be some glue logic that generates those signals (as
well as CCLK) from what's available on the AM188.

Also, if we configure the FPGA to allow readback, the readback pins
become dedicated.  Does this mean that we have to bring
our data bus in to the FPGA twice?

Thanks for the help!

Peter


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25310
Subject: 3.3/2.5 voltage regulators
From: Alexandr V Shuvalov <a_shuvalov@mail.ru>
Date: Wed, 06 Sep 2000 09:39:19 +0400
Links: << >>  << T >>  << A >>
Hellow!

Which voltage regulators ICs are commonly used to power supply Xilinx XL
and other low voltage (3.3-2.5v) devices?

Thank in advance.

Alexandr.

Article: 25311
Subject: Cypress Delta39K availability
From: "Tim" <topedm@ms11.hinet.net>
Date: Wed, 6 Sep 2000 15:14:09 +0800
Links: << >>  << T >>  << A >>
Hello,

I'm seeking a FPGA/CPLD device for my project. Would anyone let me know if
the cypress Delta39K chips are available now, and who carry this product ?

Thanks for you help.
Tim


Article: 25312
Subject: Re: XC3000A Configuration data
From: "Peter Schulz" <p.schulz@signaal.de>
Date: Wed, 6 Sep 2000 09:39:21 +0200
Links: << >>  << T >>  << A >>
It is a secret, definitively.

Reason: To prevent from reverse engineering.

Peter


Anthony Tekatch schrieb in Nachricht ...
>
>> The programmable logic data book (1998) explains that in more detail on
>> page 4-315 to 4-318, but not down to the level where each bit in the
>> data frame is explained.
>
>I do not have any printed manuals and cannot find that one on their web
>site.
>
>
>> That is probably a big secret. At least to me it is. I agree that it
>> would be interesting to know, though.
>
>I certainly hope it's no secret.. I'm sure there must be a market for
>programming the devices from uP generated data rather than predefined
>layouts.
>
>I have a "support" request in to Xilinx, hopefully I'll get an answer
>shortly and post the results here.
>
>Anthony
>


Article: 25313
Subject: Re: Mealy vs Moore FSM model
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 06 Sep 2000 09:01:53 GMT
Links: << >>  << T >>  << A >>
On Tue, 5 Sep 2000 23:08:09 GMT, jhallen@world.std.com (Joseph H
Allen) wrote:

I haven't read the rest of this thread, and I probably haven't
(re)read your post enough, but it seems to me that you're not actually
describing the difference between a Mealy and a Moore machine. Your
two code examples show (1) a Moore FSM coded using a single-process
style, and (2) a Moore FSM coded using two processes, one for the
state register, and one for the next-state logic. The Q output in the
second FSM is registered, not combinatorial:

>always @(posedge clk or negedge reset_l)
>  if(~reset_l)
>    begin
>      state<=IDLE;
>      q<=0;
>    end
>  else
>    begin
>      state<=ns_state;		// State machine is in separate always block.
>      q<=ns_q;
>    end

So this isn't a Mealy machine: you'd need a *third* process, combining
current inputs with the state register, and producing combinatorial
outputs, to have a Mealy machine. If you're actually saying that a
one-process model is more compact and readable than a 2-process model,
for the core FSM in either a Mealy or Moore machine, then I'd have to
agree with you.

Also: in both machines, Q is simply another state bit, which you
haven't placed in your state register. I'm surprised to see this in a
Verilog description - it may be necessary in VHDL, if you were using
an enumerated type for the state register, but I can't see why it's
necessary in Verilog.

>Simple Moore state machine:
>
>wire start, ok, done;
>reg q;
>reg [1:0] state;
>
>always @(posedge clk or negedge reset_l)
>  if(~negedge reset_l)
>    begin
>      state <= IDLE;
>    end

This is an interesting one - you're not resetting Q in your async
reset branch, but you are resetting state, and you're assigning to
both in your clock branch - is this a typo? This will potentially lead
to a synthesis error (what happens if you get a clock edge and a reset
edge at the same time?)

>- It is difficult to share flip-flops, output registers, etc. between state
>    machines in Moore.  This is the main reason people use the Mealy style,
>    and is not true either: you can generate Mealy signals in Moore style
>    state machines.  First, here is an example of the problem:
> <code snipped>
>This fails, since two state machines can not write to the same register.
>This can be fixed with Mealy signals, and without having to put all of your
>next state logic in a separate always blocks as is commonly done.  The key
>is to understand the difference between '=' and '<=':
>
>reg awrites, bwrites;	// Mealy signals
>reg [15:0] databus;
>
>// Bus driver
>always @(posedge clk)
>  if(awrites) databus<=inputbus;
>  else if(bwrites) databus<=internalregister;
>
>// State machine 1
>always @(posedge clk)
>  begin
>    awrites=0;		// Must always initialize Mealy output signals.
>    ...
>    case(state1)
>      ...
>      FOO:
>        begin
>          awrites = 1;	// Note that =, not <= is used here
>          state1 <= NEXT;

Isn't this a classic Verilog race condition? What happens if the 2
always blocks are executed in a different order?

Hope you don't think I'm picking on you...  :)

Evan

Article: 25314
Subject: Re: XC4013 available
From: kolja@prowokulta.org
Date: Wed, 06 Sep 2000 10:19:26 GMT
Links: << >>  << T >>  << A >>
Ray:
$5 is a very low price considered that the least cost pin compatible
device is listed at $52.
The price might even be lower. (But not below $2)

I agree, that you should propably choose a XC2S for a new design
adn ignore this offer.
But there are still a lot of xc4k around, and for those it should
be good offer.
Also: Remember that you can configure a XC4K from a $3 parallel FlashROM
instead of using expensive serial PROMs. And it will even configure
addition FPGAs for you
So you could use it to replace the XC9500XL from XAPP178 and get
13K extra Gates for free.

I do not know the speed grade. I will only find out, after I bought
them.

My location is Germany. Shipping cost will vary on deliver time, COD
cost if necessary,  and destination.

Please note: I am not a commercial reseller. I just want to by some
myself, and thought this might be usefull for someone else, too.

CU,
	Kolja


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25315
Subject: Re: 3.3/2.5 voltage regulators
From: Leon Heller <leon_heller@hotmail.com>
Date: Wed, 06 Sep 2000 10:28:31 GMT
Links: << >>  << T >>  << A >>
In article <39B5D887.9C54EBEA@mail.ru>,
  Alexandr V Shuvalov <a_shuvalov@mail.ru> wrote:
> Hellow!
>
> Which voltage regulators ICs are commonly used to power supply Xilinx
XL
> and other low voltage (3.3-2.5v) devices?

I just use an LM317 on the boards I design at home. At work we use a
Nat. Semi. switcher to keep the power down; we have a 12 V supply to
the system. If you have a 5V supply you could just use three diodes to
drop it to 5 - 1.8 = 3.2 V.

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: 25316
Subject: Re: 3.3/2.5 voltage regulators
From: "Rémi SEGLIE" <rseglie@celogic.com>
Date: Wed, 6 Sep 2000 14:13:36 +0200
Links: << >>  << T >>  << A >>
Hi,

I use MICREL "MIC39300" and it can be use with 3.3V or 5V and it works fine.


"Alexandr V Shuvalov" <a_shuvalov@mail.ru> a écrit dans le message news:
39B5D887.9C54EBEA@mail.ru...
> Hellow!
>
> Which voltage regulators ICs are commonly used to power supply Xilinx XL
> and other low voltage (3.3-2.5v) devices?
>
> Thank in advance.
>
> Alexandr.
>


Article: 25317
Subject: About XNF, EDIF and UCF
From: "Peter Desmet" <peter.desmet@barco.com>
Date: Wed, 6 Sep 2000 14:34:26 +0200
Links: << >>  << T >>  << A >>
Hi all,

Does anyone know how to modify constraints when using an EDIF for
design implementation instead of an XNF file?
I've recently switched to a new PC, with brand new software, yippie, but now
it seems that FPGA Express (v3.4) generates edif-files for my XC4036XLA
part. That used to be an xnf-file.
My constraint file contains stuff like
  INST name TNM = CPUFFS;
but since edif-files have a totally different structure, Design manager
reports
numerous errors in the translation step and basically says 'bugger off and
give me decent constraints'.

There doesn't seem to be a menu option that allows switching between edif
and xnf, so...

I suppose I can always re-install an older version of FPGA Express and get
me
an xnf-file to work with.

Thnx for any replies



Article: 25318
Subject: floorplanning
From: erika_uk@my-deja.com
Date: Wed, 06 Sep 2000 13:10:43 GMT
Links: << >>  << T >>  << A >>
hey,

my question is mainly to you RAY. you are saying all the time that you
perform flooplanning.
could you give us some tips for free ?
I find it really hard, how one should do a placement, escpecially for
parrallel arithmetic.
Let's take an example. a simple FIR , inverted mode, multpliers and
adders built from the carry logic, could you tell me please how you
will floorplan such architecture?
Moreover is the flooplanning soft placement or hard one

with best regards

--Erika


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25319
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 06 Sep 2000 14:49:46 +0100
Links: << >>  << T >>  << A >>


Johan Petersson wrote:

> Hi Ray,
> There is also a flag that disables the router so that you can let the
> placer
> run with different "cost table entries" as a background job - when the
> check sum
> is low enough you kill the bastard and run with -t x, no -n and WITH the
> router
> enabled....... I don't remember the name for the "disable router" flag
> :)

For 2.1i this approach only works with SP6 but maybe not even then - see solution
#8371. Before that you couldn't guarantee that doing a single run with -t <x> would
get the same results as when an MPPR got to table value <x>!

I found this last year & spent 4-5 month persuading Xilinx that is was a bug.


Article: 25320
Subject: Re: About XNF, EDIF and UCF
From: Thomas Karlsson <thomas.karlsson@emw.ericsson.se>
Date: Wed, 06 Sep 2000 15:55:55 +0200
Links: << >>  << T >>  << A >>
Hello Peter!

The different structure of XNF and EDIF files does not affect the syntax
of the UCF file in any way, but when you do a new synthesis run
(especially with new software),
the tool may invent totally new names for signals. 
So in 
INST name TNM = CPUFFS;
name may not exist anymore.

Could this be the problem in your case?

/Thomas Karlsson

Peter Desmet wrote:
> 
> Hi all,
> 
> Does anyone know how to modify constraints when using an EDIF for
> design implementation instead of an XNF file?
> I've recently switched to a new PC, with brand new software, yippie, but now
> it seems that FPGA Express (v3.4) generates edif-files for my XC4036XLA
> part. That used to be an xnf-file.
> My constraint file contains stuff like
>   INST name TNM = CPUFFS;
> but since edif-files have a totally different structure, Design manager
> reports
> numerous errors in the translation step and basically says 'bugger off and
> give me decent constraints'.
> 
> There doesn't seem to be a menu option that allows switching between edif
> and xnf, so...
> 
> I suppose I can always re-install an older version of FPGA Express and get
> me
> an xnf-file to work with.
> 
> Thnx for any replies
Article: 25321
Subject: Re: XC3000A Configuration data
From: kolja@prowokulta.org
Date: Wed, 06 Sep 2000 14:26:00 GMT
Links: << >>  << T >>  << A >>


  "Peter Schulz" <p.schulz@signaal.de> wrote:

> >I certainly hope it's no secret.. I'm sure there must be a market for
> >programming the devices from uP generated data rather than predefined
> >layouts.

There is some reverse engineered LCA documentation. You can uses that
together with makebits to generate bitstreams on the fly.

But today you should move to Spartan-II and use Steve Guccione and
Delon Levi's JBits Software instead.
It is a Java API that allows you to modify Virtex Bitstreams on the fly.

Officiall the bitsream is not disclosed to prevent the distruction
of the device by short circuit connections, which is allegedly
checked by JBits.
But as someone on FPL'99 pointed out, it is easy to damage the chip
anyway by bus contention or by implementing a couple of oscillator to
overheat it. So this function is more or less useless.

CU,
	Kolja Sulimma



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25322
Subject: Re: Mealy vs Moore FSM model
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Wed, 6 Sep 2000 17:30:22 +0200
Links: << >>  << T >>  << A >>
> Correct-it's the two-process style that I'm complaining about.  A single
> process can be used for both Mealy and Moore state machines.  Many people
> assume that two processes are needed for Mealy, and write all of their
state
> machines that way.  (actually the second always block is not really a
> process- just combinatorial logic).
>

I thought the main reason for dividing up state machines into several
processes is limitations in synthesizers

--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden




Article: 25323
Subject: Re: Mealy vs Moore FSM model
From: jhallen@world.std.com (Joseph H Allen)
Date: Wed, 6 Sep 2000 15:55:37 GMT
Links: << >>  << T >>  << A >>
In article <39b607f5.7405564@news.dial.pipex.com>,
 <eml@riverside-machines.com.NOSPAM> wrote:

>Isn't this a classic Verilog race condition? What happens if the 2
>always blocks are executed in a different order?

Oops, you're right, it is.  You can use = for temporary variables, since
execution within an always block is sequential, but you had better not use
it for generating Mealy state signals unless it's in a seperate
combinatorial always block.

Verilog just doesn't work the way I want it to :-)

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 25324
Subject: Re: floorplanning
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Sep 2000 16:21:39 GMT
Links: << >>  << T >>  << A >>
Starting with the last question, I use RLOCs embedded in the source for peices
that I anticipate using more than once or twice so that I don't have to manually
place every instance of it.  That is to say the floorplanning for those peices
is "hard".  For layouts that are one-offs, I use the graphical floorplanner to
lay the stuff out, so those layouts I guess would be "soft", as they are
perishable if the netlist changes, and they are not hierarchical.

MOstly, I do the floorplanning, at least in my mind, during the design so by the
time I am working in the floorplanner, I already have a pretty good idea of how
things will fit together.  Data path stuff is pretty easy to floorplan.  The
goal is to arrange the peices to minimize routing congestion and minimize the
lengths of the routes.  With that in mind, some basic guidelines:  arrane your
data paths going across the chip so that the individual elements are vertical. 
That lets you take advantage of the carry chains.  Since the carry chains want
the LSB at the bottom (highest column numbr) arrange the bits in that order. 
NOw when you layout successive elements line the bits up horizontally so that
the connections are kept within the same row.  Wire your controls vertically and
put the drivers in the same columns as the destinations.  The best way to learn
the floorplanning is to take a design and paly with it in the floorplanner.  If
you first let the design autoplace, and then open it, you'll see that the logic
is kinda just shotgunned in by the the automatic tools.  Start moving that
around manually save the layout and run the PAR again to see what your moving
stuff around did to the timing.  Even simple manual arrangement can have
profound effects on the timing.  Once you've plasyed with designs in the
floorplanner, you'll start to get a feel for what works well and what doesn't. 
You can take that knowolege and use it to put rloCs in your source to make a
"hard" hierarchical placement.



erika_uk@my-deja.com wrote:
> 
> hey,
> 
> my question is mainly to you RAY. you are saying all the time that you
> perform flooplanning.
> could you give us some tips for free ?
> I find it really hard, how one should do a placement, escpecially for
> parrallel arithmetic.
> Let's take an example. a simple FIR , inverted mode, multpliers and
> adders built from the carry logic, could you tell me please how you
> will floorplan such architecture?
> Moreover is the flooplanning soft placement or hard one
> 
> with best regards
> 
> --Erika
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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  or http://www.fpga-guru.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
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