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 17425

Article: 17425
Subject: NRZ Deserializing in Virtex
From: "Eirik Esp" <eirik@proxima.mv.com>
Date: Tue, 27 Jul 1999 07:52:20 -0400
Links: << >>  << T >>  << A >>
I am looking at trying to extract clock & data from a ~100 MHz NRZ serial
data stream.  I was just wondering if anyone has tried this and had any
successes of failures to report?  Any suggestions?


Article: 17426
Subject: Re: NRZ Deserializing in Virtex
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Tue, 27 Jul 1999 13:34:31 GMT
Links: << >>  << T >>  << A >>
On Tue, 27 Jul 1999 07:52:20 -0400, "Eirik Esp" <eirik@proxima.mv.com>
wrote:

>I am looking at trying to extract clock & data from a ~100 MHz NRZ serial
>data stream.  I was just wondering if anyone has tried this and had any
>successes of failures to report?  Any suggestions?

It's not that hard, but you need a PLL of sorts.

A completely digital solution in an FPGA at those rates could be quite
challenging, as digital PLLs usually require an oversampling clock.
To keep the jitter low enough (to avoid eye closure (and at 100Mbps
you need the widest eye you can get)) you need to sample at several
times the data rate, and several x 100MHz = difficult.

You might be able to get the Virtex DLLs to provide a multiphase clock
and have the input go to multiple flip flops, each on a different
clock phase.  This is equivalent to having a really fast clock.  Have
fun controlling routing skew.

If you really want to design one yourself, you need to know a few
things:
1. Transition density (or maximum run length).
2. Jitter tolerance.
3. Rate tolerance.
4. Lock time.

A possible high speed phase detector design:

Clk from VCO
----------+-------------+-----------+---------------+
          |             |           |               |
Data      |             |           |               |
----+-----|-------+     |           |               |
    |     |       |     |           |               |
    |     |       |     0           |               |
    |  +-----+    |  +-----+     +-----+         +-----+
    |  | clk |    |  | clk |     | clk |         | clk |
    +->|D   Q|-+  +->|D   Q|---->|D   Q|---+  +->|D   Q|-+->Data out
       |     | |     |     |     |     |   |  |  |     | |
       +-----+ |     +-----+     +-----+   |  |  +-----+ |
               |                           |  |          |
               +---------------------------|--+          |
               |                           |             |
               |                           |  +----------+
               |                           |  |  +-----+
               |                           |  +->|     |    speed
               |                           |     | XOR |--->up vco
               |                           +---->|     |
               |                           |     +-----+
               |                           |
               |                           |     +-----+
               |                           +---->|     |    slow
               |                                 | XOR |--->down vco
               +-------------------------------->|     |
                                                 +-----+

(Note the second ff has an inverted clock)
When the loop is locked, the data signal changes with the falling edge
of the clock, and there will be an equal number of speed up and slow
down pulses.

My suggestion: buy a chip that does it for you:

There are plenty of clock and data recovery chips available.  They
output a clock and data when NRZ is present at their inputs.  The I/O
is usually ECL compatible.

They use analog PLLs usually based around ring oscillators.
However, they are mostly trimmed to work at standard rates.
(Analog Devices AD807 at 155.52Mbps and AD808 at 622.08Mbps for
example).

Some use external oscillators, such as the AD805.  You will need a
100MHz VCXO to get it to work, but that's starting to sound expensive.

Check out the Microcosm MC2070 at:
http://ourworld.compuserve.com/homepages/Microcosm_Communications/mc2070.html
It's claimed to work down to less than 100MHz (you set the centre
frequency with a resistor).

These chips are often designed to be part of optical fibre receivers,
so they have sensitive differential comparators at the front end.
This helps with cable connections too, but it may see a signal even if
it's only a few mV of crosstalk from something nearby.

Another tack would be to change your data rate to suit the available
chips.  It is also possible to use these chips at integer submultiples
of their data rate.  For example, you can use a 155.52Mbps chip with a
77.76Mbps input.  It still outputs 155.52MHz, but the output data only
changes every second clock.

Regards,
Allan.
Article: 17427
Subject: Re: XACT vs. Workview office
From: Ray Andraka <randraka@ids.net>
Date: Tue, 27 Jul 1999 09:46:47 -0400
Links: << >>  << T >>  << A >>
Your question is along the lines of  "I would like to know if there are any
major differences between a screwdriver and a hammer".  WVO is a design
capture tool, while XACT is the old version of a place and route tool.  YOu
need to capture (and if it is a synthesis flow synthesize) the design before
you run the place and route.

Zhibin Dai wrote:

> Hi,
>
> I am a grads student and just start to learn FPGA.  My research
> direction is FPGA routing. I may use some FPGA design software like XACT
> step or Workview Office. I would like to know if there are any major
> differences between XACT or Workview Office. Any help would be
> appreciated.
>
> Zhibin



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


Article: 17428
Subject: Re: NRZ Deserializing in Virtex
From: Ray Andraka <randraka@ids.net>
Date: Tue, 27 Jul 1999 10:04:31 -0400
Links: << >>  << T >>  << A >>
You'll need to use a PLL to get your bit clock.  An all digital PLL usually
requires a system clock several times higher than the bit rate (how much
depends on your tolerance to jitter), which would be a challenging design in
an FPGA.  You might be able to do something with the virtex DLLs, but I think
the constraints on their use may be too limiting in this case.  TThere are
some deserializer chips out there such as the AMCC 8401 which have an
integral PLL and clock recovery.  Most of those are tuned to a specific bit
clock, however (8401 is just under 1.5 Gbit/sec serial).  You might not find
one that matches your bit clock needs.  If that is the case, I think your
best bet is to put a decoder on chip coupled with an external analog PLL for
recovering the bit clock.

Once you have the bit clock, the rest is fairly easy, even in 4K.   After
parallelizing the data with a shift register, you may need to descramble it
and you will need to frame it.  Descrambling removes a polynomial modulation
intended to make sure there are sufficient edges in the signal to recover the
clock, and that there is no DC offset over a relatively short number of
bits.  The recovery polynomial is different for different systems, so you
will need to know the polynomial used on your transmission.  Framing
generally looks for a sync pattern in the data and uses that to select how
much the data is shifted to align the bits to the parallel output.

 I offer a descrambler and framer core for Xilinx 4K which is designed for
SMPTE 292 (HDTV) signals and works with the AMCC8401 deserializer (which is
just a shift register and clock recovery).

Eirik Esp wrote:

> I am looking at trying to extract clock & data from a ~100 MHz NRZ serial
> data stream.  I was just wondering if anyone has tried this and had any
> successes of failures to report?  Any suggestions?

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


Article: 17429
Subject: Re: Microcomputer buses for use inside FPGA/ASIC devices?
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
Date: Tue, 27 Jul 1999 09:12:58 -0500
Links: << >>  << T >>  << A >>
> 3. interfaces (signaling): would work unchanged across architectures.
>
> (I do not propose the J32 bus for any purpose.  I thought it might of
> historical interest.)

If you ever decide to publish something, I'll add it to my database of FPGA
interconnection buses.  I just found another one this morning called
FISPbus(tm).  Apparently, it's a Mentor Graphics thingee.  I've got the database
going at: http://www.silicore.net/uCbusum.htm


> >> Old articles which touched on this subject:
> >I tried these links, but they appear to be dead.
>
> Try again!

Okay, I got something this time.  Thanks.


> FPGA Device Architects: this on-chip bus stuff is so much easier if you
> follow the XC4000 lead and provide the abstraction of long, wide,
> partitionable buses with *abundant* 3-state drivers -- one per logic cell is
> good.  The bus control itself can be built in programmable logic.

We've been avoiding any requirements for three-state buses.  They just don't
seem to be very portable across multiple FPGA target devices.  They also don't
seem to fit very well in some FPGA architectures like Xilinx, as they tend to
require their 'horizontal long-lines'.  This tends to kludge up the placement.

In this Wishbone interconnect that we're doing, we allow both standard and
three-state interconnections.  Actually, the 'Wishbone' name comes from this
feature.  If we do input and output buses we can handle standard logic, and then
shift to three-state logic by the addition of three-state buffers.  This forms a
'Y' shaped interconnect in the shape of a Wishbone.  It seems to be a reasonable
approach to the problem.

Also...three-state buses were originally designed and used to limit the number
of I/O pins on connectors and IC packages.  We've found that those limits really
don't exist in FPGA/ASIC interconnection buses, as these devices have a rich set
of interconnections.  In virtually all cases, we've found that the use of
multiplexors (rather than three-state interconnects) results in a faster and
more compact design.  It seems that most placement tools have a much easier time
of working with multiplexors.  I know this is counter-intuitive, but it seems to
work well.


> Finally, in designing a on-chip bus with an eye on standardization, note
> some interesting design tensions:
>
> 1. malleable or fixed bus topologies and clocking disciplines? -- why not
> take advantage of FPGA flexibility and define a general bus architecture
> space, making allowance for one or more 8-, 16-, 32-, even arbitrary k-bit
> buses, and other dimensions of the design space I described above?  Then
> customers can specialize designs to suit.  -- Oops, that adds complexity and
> makes validation much harder.

I agree that it makes the uC bus less portable, but we've found that there is no
one right way to do an interconnection.  On Wishbone, we've specified 8 - 64 bit
buses, and have the ability to add the k-bit option.  It does add complexity and
makes validation harder, but it isn't too bad.  There are just too many
functional blocks to interconnect to stick with a single bus width.


> 2. lightweight or heavyweight?  My current bus has a control overhead of ~2
> CLBs per peripheral.  At the opposite extreme, imagine an on-chip PCI bus.
> The latter would offer many features, like configuration registers, but
> these would be of little value in a cheap SOC in an XCS10XL or 20XL.

For FPGAs the 'lightweight' approach seems to work the best.  I've seen several
people attempt to integrate a 'PCI-like' bus on an FPGA or ASIC, but (a) it's
not granular enough, (b) those buses are designed to overcome the large
capacitance and inductance of microcomputer boards and backplanes (not a big
problem on chips) and (c) they're too big.

Wishbone tends to fit into the lightweight catagory, but we can still do
multiprocessing and so forth.  Also, we've found that the lightweight interface
makes it suitable for large design teams.  With this approach, we can take a
more structured approach to the design task.  For example, if we can get three
or four people all creating funtional modules, then it's very handy to give them
a common interface, and let them create the individual components more-or-less
independantly.  At some point in the project we gather up all of the (fully
tested) functional modules, and interconnect them together.

This approach is very analogous to other types of structured programming
environments like C++/UNIX.  The same rules seem to apply to system-on-chip
(SOC) projects.


> I can't wait to see an on-chip bus standard (or standards) for FPGAs -- then
> we might finally see a marketplace of plug-and-play processors and
> peripherals cores.

I heartily agree!  It's going to take awhile, though.  From past experience (in
the microcomputer board market), we will only see that when there is a
significant consolidation of the industry.  That may take 5-10 years.

--
Wade D. Peterson
Silicore Corporation
3525 E. 27th St. No. 301, Minneapolis, MN USA 55406
TEL: (612) 722-3815, FAX: (612) 722-5841
URL: http://www.silicore.net/  E-MAIL: peter299@maroon.tc.umn.edu



Article: 17430
Subject: Xilinx Fountation 1.5 Question
From: Nicholas Brown <nbrownNOT@gulfaccess.com>
Date: Tue, 27 Jul 1999 12:59:41 -0400
Links: << >>  << T >>  << A >>
Hello,
I’m trying to use a parity generator written in ABEL in a schematic
design. I did this for a VHDL version and it worked. For the ABEL
version, I don’t see where to specify "Entity: EVPAR8" (this would be in
the Advanced options in the synthesis options tab for the VHDL version)
which tells the synth that its a top level file.  Also it is unclear to
me if I should open the design containing the ABEL macro as a Schematic
or HDL design (the ABEL design is to be added to the symbol list of the
schematic editor where you can then place it on a schematic design.)
Thanks in advance.
-Nick


Article: 17431
Subject: Re: NRZ Deserializing in Virtex
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 27 Jul 1999 10:21:50 -0700
Links: << >>  << T >>  << A >>


Eirik Esp wrote:

> I am looking at trying to extract clock & data from a ~100 MHz NRZ serial
> data stream.  I was just wondering if anyone has tried this and had any
> successes of failures to report?  Any suggestions?

I once published a circuit that recovers clock and data from a
Manchester-encoded bitstream.

To my knowledge, Non-Return-to-Zero does not contain clock information, so you
would have to know the clock frequency very precisely.

Peter Alfke, Xilinx Applications


Article: 17432
Subject: Re: NRZ Deserializing in Virtex
From: muzok@nospam.pacbell.net (muzo)
Date: 27 Jul 1999 12:08:01 PDT
Links: << >>  << T >>  << A >>
Actually it does but in a statistical way. You can look at the
transitions to generate a timing error and use a VCO/Loop Filter to
adjust your local clock. This is a very common thing to do in
communication system design. There are ways of doing it without the
VCO and PLL which are more suited to a fully dsp system.

Peter Alfke <peter@xilinx.com> wrote:

>
>
>Eirik Esp wrote:
>
>> I am looking at trying to extract clock & data from a ~100 MHz NRZ serial
>> data stream.  I was just wondering if anyone has tried this and had any
>> successes of failures to report?  Any suggestions?
>
>I once published a circuit that recovers clock and data from a
>Manchester-encoded bitstream.
>
>To my knowledge, Non-Return-to-Zero does not contain clock information, so you
>would have to know the clock frequency very precisely.
>
>Peter Alfke, Xilinx Applications
>

muzo

Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)
Article: 17433
Subject: Re: XACT vs. Workview office
From: "rodger" <brownsco@frii.com>
Date: Tue, 27 Jul 1999 14:16:08 -0600
Links: << >>  << T >>  << A >>
Actuallly, WVO is an entire suite of tools to peform design
capture, simulation, and analysis, as well as synthesis. The
design capture part includes the schematic entry tool,
ViewDraw, StateCAD for graphical statemachine entry,
and an HDL editor.

Ray has correctly identified what XACT is.

The question you are probably asking is what is
the difference betwen WVO and Xilinx Foundation.

The differences are many, but in a nutshell, Foundation is
designed to do one thing: work with the mid-to-lower-end
of the Xilinx FPGA families. WVO is a full-blown EDA toolset
that can handle all Xilinx programmables, plus any other
vendor's, as well as board-level design.


Ray Andraka wrote in message <379DB847.1134486E@ids.net>...
>Your question is along the lines of  "I would like to know if there are any
>major differences between a screwdriver and a hammer".  WVO is a design
>capture tool, while XACT is the old version of a place and route tool.  YOu
>need to capture (and if it is a synthesis flow synthesize) the design
before
>you run the place and route.
>
>Zhibin Dai wrote:
>
>> Hi,
>>
>> I am a grads student and just start to learn FPGA.  My research
>> direction is FPGA routing. I may use some FPGA design software like XACT
>> step or Workview Office. I would like to know if there are any major
>> differences between XACT or Workview Office. Any help would be
>> appreciated.
>>
>> Zhibin
>
>
>
>--
>-Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email randraka@ids.net
>http://users.ids.net/~randraka
>
>


Article: 17434
Subject: APEX initial values
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Tue, 27 Jul 1999 15:23:34 -0500
Links: << >>  << T >>  << A >>
Hello,
We are currently using Xilinx Virtex FPGAs, but are evaluating the new
Altera APEX FPGAs.  One question we have is whether or not you can set
initial values in the embedded RAM in the APEX devices.  You can do this
in the Virtex BlockSelect RAM and it has become very convienient for us.

Thanks in advance.
Tom


Article: 17435
Subject: Re: Microcomputer buses for use inside FPGA/ASIC devices?
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
Date: Tue, 27 Jul 1999 16:43:10 -0500
Links: << >>  << T >>  << A >>
Many thanks to Jim Frenzel for supplying this link:

The ARM AMBA spec can be downloaded from 
http://www.arm.com/Documentation/UserMans/AMBA/index.html.

The early spec was also described in an IEEE Micro article,
Jul/Aug 97.

I've added this to the database at http://www.silicore.net/uCbusum.htm

-- 
Wade D. Peterson
Silicore Corporation
3525 E. 27th St. No. 301, Minneapolis, MN USA 55406
TEL: (612) 722-3815, FAX: (612) 722-5841
URL: http://www.silicore.net/  E-MAIL: peter299@maroon.tc.umn.edu


Article: 17436
Subject: Re: Microcomputer buses for use inside FPGA/ASIC devices?
From: "Anthony Ellis - LogicWorks" <aelogic@iafrica.com>
Date: Wed, 28 Jul 1999 06:52:14 +0200
Links: << >>  << T >>  << A >>
My own pennys worth here.

I have the feeling that the current move in uComputer busses is away from
parallel but back to serial. Witness NGIO, FutureIO, FibreChannel etc.
Going parallel 8/16/32/64 with byte ordering etc..etc is a step backwards
for future efforts. The way forward is only to look at the past for what not
to do next.
An 8 bit wide "serial-link" interface would suffice for most applications
providing the protocol is simple.  At 50 Mhz this gives 400 Mbits/sec at 100
Mhz you can knock VME.
This would also allow an external chip-chip and board to board link using
the same "network" using say LVDS I/O.

Anthony.


Wade D. Peterson wrote in message <7ndpnl$pcu$1@news1.tc.umn.edu>...
>I'm working on a project where we're doing a microcomputer bus (kind of
like
>VMEbus or PCIbus) for use *INSIDE* of FPGAs and ASICs.  It's for hooking
>system-on-chip (SOC) components together.  If anyone has done this before,
or
>know of any references to this kind of project, I'd like to hear about it.
>
>Our project is called WISHBONE, and we're giving away the rights and
>specification for anybody who is interested in using the technology.  More
>details can be found at: http://www.silicore.net/wishbone.htm
>
>IBM has also recently released a similar project called CoreConnect(tm).
More
>details about this can be found at:
>http://www.chips.ibm.com/products/powerpc/cores/crcon_ug.html
>
>If anybody knows of similar technology, I'd like to hear about it.  If
there are
>more, then my intention is to start a FAQ database on our website for all
to
>use.
>
>--
>Wade D. Peterson
>Silicore Corporation
>3525 E. 27th St. No. 301, Minneapolis, MN USA 55406
>TEL: (612) 722-3815, FAX: (612) 722-5841
>URL: http://www.silicore.net/  E-MAIL: peter299@maroon.tc.umn.edu
>
>


Article: 17437
Subject: Problem with Max+PlusII / Flex10k
From: Nicolas Matringe <nicolas@dot.com.fr>
Date: Wed, 28 Jul 1999 13:15:40 +0200
Links: << >>  << T >>  << A >>
Hi

I tried to put a "hardwired" version number in a design but it is
impossible to read.
The simulation runs OK (and the number is readable), but the FPGA won't.
The returned value is always zero.
Is my code OK, therefore indicating that Max+plus is nothing but junk,
or is my code wrong (but then, why would the simulation work?)
Or maybe the Flex 10k doesn't support such fixed values?

code sample :

LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY registers IS
  PORT (
        d_out		: OUT std_logic_vector(15 DOWNTO 0);

        i2c_rd		: IN std_logic;

        sda			: IN std_logic;  --  >  I2C bus

        clk			: IN std_logic;
        rst			: OUT std_logic
       );
END registers;

ARCHITECTURE beh OF registers IS
  SIGNAL ver_num : std_logic_vector(5 DOWNTO 0);  -- version number
  SIGNAL rst_i : std_logic;

  BEGIN
    ver_num <= "000010";
    rst <= rst_i;
    PROCESS (clk, rst_i)
    BEGIN
      IF rst_i = '1' THEN
        d_out <= "0000000000000000";
      ELSIF clk = '1' AND clk'EVENT THEN
        IF i2c_rd = '1' THEN
          d_out(0) <= sda;
          d_out(7 DOWNTO 2) <= ver_num;
        END IF;
      END IF;
    END PROCESS;
  END beh;

(rst_i is generated somewhere... don't bother about it, it works :o)
The I2C bus reading works fine (bit 0), but the version number won't
appear on the output bus.


Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
Fax 00 33 1 46 67 51 01    FRANCE
Mail reply: remove one dot from my address
Article: 17438
Subject: Re: Problem with Max+PlusII / Flex10k
From: Alex Makris <alexander.makris@soton.sc.philips.com>
Date: Wed, 28 Jul 1999 13:11:09 GMT
Links: << >>  << T >>  << A >>
Nicolas Matringe wrote:

> Hi
>
> I tried to put a "hardwired" version number in a design but it is
> impossible to read.
> The simulation runs OK (and the number is readable), but the FPGA won't.
> The returned value is always zero.
> Is my code OK, therefore indicating that Max+plus is nothing but junk,
> or is my code wrong (but then, why would the simulation work?)
> Or maybe the Flex 10k doesn't support such fixed values?
>
> code sample :
>
> LIBRARY ieee;
> USE ieee.std_logic_1164.all;
>
> ENTITY registers IS
>   PORT (
>         d_out           : OUT std_logic_vector(15 DOWNTO 0);
>
>         i2c_rd          : IN std_logic;
>
>         sda                     : IN std_logic;  --  >  I2C bus
>
>         clk                     : IN std_logic;
>         rst                     : OUT std_logic
>        );
> END registers;
>
> ARCHITECTURE beh OF registers IS
>   SIGNAL ver_num : std_logic_vector(5 DOWNTO 0);  -- version number
>   SIGNAL rst_i : std_logic;
>
>   BEGIN
>     ver_num <= "000010";
>     rst <= rst_i;
>     PROCESS (clk, rst_i)
>     BEGIN
>       IF rst_i = '1' THEN
>         d_out <= "0000000000000000";
>       ELSIF clk = '1' AND clk'EVENT THEN
>         IF i2c_rd = '1' THEN
>           d_out(0) <= sda;
>           d_out(7 DOWNTO 2) <= ver_num;
>         END IF;
>       END IF;
>     END PROCESS;
>   END beh;
>
> (rst_i is generated somewhere... don't bother about it, it works :o)
> The I2C bus reading works fine (bit 0), but the version number won't
> appear on the output bus.
>
> Nicolas MATRINGE           DotCom S.A.
> Conception electronique    16 rue du Moulin des Bruyeres
> Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
> Fax 00 33 1 46 67 51 01    FRANCE
> Mail reply: remove one dot from my address

Hello Nicolas,

I am not sure about this but why don't you try to define ver_num as a
constant after the ARCHITECTURE .... statement.

Why it doesn't work, I don't know although I am a bit suspicious with the
process sensitivity list.


Regards,


Alex.

Article: 17439
Subject: Re: Problem with Max+PlusII / Flex10k
From: ps@PSPCNT.emi.dtu.dk (Peter Sørensen)
Date: 28 Jul 1999 13:23:08 GMT
Links: << >>  << T >>  << A >>
nicolas@dot.com.fr (Nicolas Matringe) wrote in 
<379EE65C.D4D21308@dot.com.fr>:

>Hi
>
>I tried to put a "hardwired" version number in a design but it is
>impossible to read.
>The simulation runs OK (and the number is readable), but the FPGA won't.
>The returned value is always zero.
>Is my code OK, therefore indicating that Max+plus is nothing but junk,
>or is my code wrong (but then, why would the simulation work?)
>Or maybe the Flex 10k doesn't support such fixed values?
>

Hi Nicholas

No the Maxplus is okay except for some VHDL synthesis bugs and missing 
support. If the Maxplus simualation is okay the VHDL code is okay too.
If you use a VHDL simulator you must check the Maxplus simulator too or use 
a god 3. party VHDL synthesis. Maxplus do fullfill the VHDL standard.
It is properly some HW think like have you assigned the correct pin numbers
Maxplus assigns pins rather random if you let it do it.
Another likely error is that output pin corresponding to your single 1 bit 
in the version number is not soldered properly. You need a microscope to 
check the soldering.

Hi Peter

Article: 17440
Subject: Re: Microcomputer buses for use inside FPGA/ASIC devices?
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
Date: Wed, 28 Jul 1999 08:27:40 -0500
Links: << >>  << T >>  << A >>
Anthony Ellis - LogicWorks <aelogic@iafrica.com> wrote in message
news:7nm29r$nrg$1@nnrp01.ops.uunet.co.za...
> My own pennys worth here.
>
> I have the feeling that the current move in uComputer busses is away from
> parallel but back to serial. Witness NGIO, FutureIO, FibreChannel etc.
> Going parallel 8/16/32/64 with byte ordering etc..etc is a step backwards
> for future efforts. The way forward is only to look at the past for what not
> to do next.

As a general rule, I don't disagree with that...at least for (non intra-chip)
system-level work.

Remember, though, that we're talking here about uC buses inside of an FPGA or
ASIC (for system-on-chip).  We're routing the uC bus across the surface of the
die.  In this situation the parallel buses will always be much faster and
require less logic than a serial bus.

FPGA and ASIC design rules are easily allowing 50 - 100 MHz buses across the
die, and some of the latest product introductions are starting to nudge up to
the 1 Ghz toggle rates.  I'm looking a little bit into the future here, but if
we could get a 1 Ghz system clock with a 64-bit wide data bus, we're talking
about a 8 Gbyte/second data rate.  Also note that I'm saying Gbyte, and not
Gbit.

Buses like VMEbus, PCI and cPCI, NGIO and so forth all have inherent speed
limits that are caused by large inductance and capacitance caused by IC pins, PC
boards and connectors.  With system-on-chip, the inductance and capacitance of
the interconnections are a small fraction of what they are with these other
technologies, and are inherently faster.


> An 8 bit wide "serial-link" interface would suffice for most applications
> providing the protocol is simple.  At 50 Mhz this gives 400 Mbits/sec at 100
> Mhz you can knock VME.
> This would also allow an external chip-chip and board to board link using
> the same "network" using say LVDS I/O.
>
> Anthony.

I agree with your numbers that an 8-bit wide serial interconnect (such as
Myrinet) could get you to 400 Mbit/sec = 50 Mbyte/sec (actually, you can get
about 160 Mbyte/sec on a single Myrinet link).  However, this is still a far cry
from the cutting edge of VMEbus, which is now pushing 500 Mbyte/sec.  For more
information about the high speed versions of VMEbus, see the VME320 technology
at http://www.arizonadigital.com/

Actually, I don't see the internal FPGA/ASIC buses as really competing with the
backplane/cable buses.  They solve a different set of problems.  However, the
data rates of these other buses are fundamentally limited as to how fast data
can be delivered to them.  In this case, we're still back to how fast we can
move data on system-on-chip.

Wade D. Peterson
Silicore Corporation
3525 E. 27th St. No. 301, Minneapolis, MN USA 55406
TEL: (612) 722-3815, FAX: (612) 722-5841
URL: http://www.silicore.net/  E-MAIL: peter299@maroon.tc.umn.edu



Article: 17441
Subject: Re: Problem with Max+PlusII / Flex10k
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Jul 1999 09:42:58 -0400
Links: << >>  << T >>  << A >>
Nicolas Matringe wrote:
> 
> Hi
> 
> I tried to put a "hardwired" version number in a design but it is
> impossible to read.
> The simulation runs OK (and the number is readable), but the FPGA won't.
> The returned value is always zero.
> Is my code OK, therefore indicating that Max+plus is nothing but junk,
> or is my code wrong (but then, why would the simulation work?)
> Or maybe the Flex 10k doesn't support such fixed values?

I don't see clearly what you are trying to do in your code. Your code is
specifying a set of registers for the 7 d_out bits listed inside of the
IF i2c_rd = '1' THEN clause. But the rest of the d_out bits are not
assigned a value inside of the ELSEIF clk = "1"... clause. So they
specify latches instead. 

But I don't see why you need to put the version number inside a clocked
process. I am also not clear as to how this circuit is intended to
operate. It looks like maybe you are just using the sda input as a pass
through and letting processor read it bit by bit. But since you never
assign bits 7 downto 2 to anything other than the SN or 0 on reset, you
could just use a mux selected on reset for those bits. 

I don't really see what is wrong with your code below. It looks like it
will put the SN out on bits 7 downto 2 anytime you are not in reset. But
only after a clk has been sent. Perhaps that is your problem. If you
don't have a clk edge and i2c_rd, the register will not be loaded with
the SN constant. 

Another possibility is that Max+ is seeing that your code is specifying
FFs with only one possible output and somehow is optimizing things away.
Can you check the logic that is actually being put into the part?

Try the code change shown below. It will only produce a single FF and
should work even if you don't get a clk edge before you read the data
bus. 



LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY registers IS
  PORT (
        d_out           : OUT std_logic_vector(15 DOWNTO 0);

        i2c_rd          : IN std_logic;

        sda                     : IN std_logic;  --  >  I2C bus

        clk                     : IN std_logic;
        rst                     : OUT std_logic
       );
END registers;

ARCHITECTURE beh OF registers IS
  SIGNAL ver_num : std_logic_vector(5 DOWNTO 0);  -- version number
  SIGNAL rst_i : std_logic;

  BEGIN
    ver_num <= "000010";
    rst <= rst_i;
    PROCESS (clk, rst_i)
    BEGIN
      IF rst_i = '1' THEN
        d_out <= "0000000000000000";
      ELSE
        d_out(7 DOWNTO 2) <= ver_num;
        d_out(1) <= "0";
        d_out(15 DOWNTO 8) <= (others => '0');
        IF clk = '1' AND clk'EVENT THEN
          IF i2c_rd = '1' THEN
            d_out(0) <= sda;
          END IF;
        END IF;
      END IF;
    END PROCESS;
  END beh;


> code sample :
> 
> LIBRARY ieee;
> USE ieee.std_logic_1164.all;
> 
> ENTITY registers IS
>   PORT (
>         d_out           : OUT std_logic_vector(15 DOWNTO 0);
> 
>         i2c_rd          : IN std_logic;
> 
>         sda                     : IN std_logic;  --  >  I2C bus
> 
>         clk                     : IN std_logic;
>         rst                     : OUT std_logic
>        );
> END registers;
> 
> ARCHITECTURE beh OF registers IS
>   SIGNAL ver_num : std_logic_vector(5 DOWNTO 0);  -- version number
>   SIGNAL rst_i : std_logic;
> 
>   BEGIN
>     ver_num <= "000010";
>     rst <= rst_i;
>     PROCESS (clk, rst_i)
>     BEGIN
>       IF rst_i = '1' THEN
>         d_out <= "0000000000000000";
>       ELSIF clk = '1' AND clk'EVENT THEN
>         IF i2c_rd = '1' THEN
>           d_out(0) <= sda;
>           d_out(7 DOWNTO 2) <= ver_num;
>         END IF;
>       END IF;
>     END PROCESS;
>   END beh;
> 
> (rst_i is generated somewhere... don't bother about it, it works :o)
> The I2C bus reading works fine (bit 0), but the version number won't
> appear on the output bus.
> 
> Nicolas MATRINGE           DotCom S.A.
> Conception electronique    16 rue du Moulin des Bruyeres
> Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
> Fax 00 33 1 46 67 51 01    FRANCE
> Mail reply: remove one dot from my address


-- 

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: 17442
Subject: Re: Problem with Max+PlusII / Flex10k
From: mench@mench.com
Date: 28 Jul 1999 09:45:06 -0400
Links: << >>  << T >>  << A >>
On Wed, 28 Jul 1999 13:15:40 +0200, in comp.lang.vhdl Nicolas Matringe
<nicolas@dot.com.fr> wrote in article <379EE65C.D4D21308@dot.com.fr>:
> I tried to put a "hardwired" version number in a design but it is
> impossible to read.  The simulation runs OK (and the number is
> readable), but the FPGA won't.  The returned value is always zero.
> Is my code OK, therefore indicating that Max+plus is nothing but
> junk, or is my code wrong (but then, why would the simulation work?)

Your code looks fine.

Paul
-- 
Paul Menchini          | mench@mench.com |"The last thing I want to do is
OrCAD                  | www.orcad.com   | spread fear, uncertainty and
P.O. Box 71767         | 919-479-1670[v] | doubt in the users' minds."
Durham, NC  27722-1767 | 919-479-1671[f] |  --Don Jones, MS's Y2K Product Mgr
Article: 17443
Subject: Re: Problem with Max+PlusII / Flex10k
From: Renaud Pacalet <pacalet@enst.fr>
Date: Wed, 28 Jul 1999 16:13:01 +0200
Links: << >>  << T >>  << A >>
Nicolas Matringe wrote:
> Hi
> 
> I tried to put a "hardwired" version number in a design but it is
> impossible to read.
> The simulation runs OK (and the number is readable), but the FPGA won't.
> The returned value is always zero.
> Is my code OK, therefore indicating that Max+plus is nothing but junk,
> or is my code wrong (but then, why would the simulation work?)
> Or maybe the Flex 10k doesn't support such fixed values?

Your code looks OK. The bug could be in the other parts of your
design. Or in M+2. Did you try using a constant instead of a signal
for your ver_num version number ?

Regards,
-- 
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pacalet@enst.fr
Article: 17444
Subject: Re: Problem with Max+PlusII / Flex10k
From: Nicolas Matringe <nicolas@dot.com.fr>
Date: Wed, 28 Jul 1999 17:22:25 +0200
Links: << >>  << T >>  << A >>
Rickman wrote:
[...]

> I don't see clearly what you are trying to do in your code. Your code
> is specifying a set of registers for the 7 d_out bits listed inside of
> the IF i2c_rd = '1' THEN clause. But the rest of the d_out bits are
> not assigned a value inside of the ELSEIF clk = "1"... clause. So they
> specify latches instead.

Well, ti make the code lighter to read, I removed lots of it that wasn't
interesting because working fine. The whole architecture is a set of
registers accessed through an ISA bus. I only gave you the part that
didn't work i.e. the version number.
The 16 bits of the data bus are used somewhere else :o)

I finally found a workaround by specifying the version number at reset:
...
   PROCESS (clk, rst_i)
    BEGIN
      IF (rst_i = '1') THEN
        d_out <= "00000000" & ver_num & "00";
...

That doesn't look "clean" to me but it works

The reason I didn't use a constant is that I'm not very familiar with
constants :o)

Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
Fax 00 33 1 46 67 51 01    FRANCE
Mail reply: remove one dot from my address
Article: 17445
Subject: Partial Reconfiguration?
From: jff@mrc.uidaho.edu (Jim Frenzel)
Date: 28 Jul 1999 19:59:03 GMT
Links: << >>  << T >>  << A >>
I've fallen a bit behind on the latest developments.

Which FPGAs support partial reconfiguration?

I see that the Xilinx Virtex parts do to some degree
and I assume the XC6200 series is no more (or did some
company pick that up?) ...


--
Jim Frenzel, Assoc. Professor      phone:            (208) 885-7532
Electrical Engineering, BEL 213    fax:              (208) 885-7579
University of Idaho, MS 1023       email:       jfrenzel@uidaho.edu
Moscow, ID 83844-1023 USA          www:    www.uidaho.edu/~jfrenzel
Article: 17446
Subject: Re: Digital modulator? Synthesisable Sin(x) funct.
From: melus@esi.us.es (Luis Yanes)
Date: Wed, 28 Jul 1999 21:08:00 GMT
Links: << >>  << T >>  << A >>
On Fri, 16 Jul 1999 22:22:01 -0400 Rickman <spamgoeshere4@yahoo.com>
wrote:

First, thanks for the replies. I'd some problem to access the
newsgroups last week.

>You didn't say how wide your data path is, but for anything practical,
>the XC5202 is way too small. For the purposes of education, you might be
>able to do something useful with just a very few bits. Perhaps 4 would
>fit. The phase accumulator is easy in a Xilinx part, but the multipliers
>are not so easy and I believe there are some good design methods for the
>sin and cos based on cordic. But I can't help you with that. But there
>are many others here who are very capable that I am sure you will be
>hearing from. 

I started with a 24bit phase acc. and thought about an 8bit
multiplier. First did it myself, then used the LogiBlox one, but soon
realized about the HUGE amount of logic needed to make the four
multipliers, and that the LogiBlox utility doesn't have multipliers,
at least for the XC5000. Now I'm reading about CORDIC, that didn't
knew about it before. Still must read much!.
73's de Luis

mail: melus@esi.us.es
Ampr: eb7gwl.ampr.org
http://www.esi.us.es/~melus/   <- Homebrewed Hardware Projects with PCBs
Article: 17447
Subject: Re: Digital modulator? Synthesisable Sin(x) funct.
From: melus@esi.us.es (Luis Yanes)
Date: Wed, 28 Jul 1999 21:08:02 GMT
Links: << >>  << T >>  << A >>
On Sat, 17 Jul 1999 10:47:52 -0400 Ray Andraka <randraka@ids.net>
wrote:

First, thanks for the replies. I'd some problem to access the
newsgroups last week.

>The way you show is the expensive way of doing it, since you need both a
>quadrature sinusoid generator and a complex multiplier.  Considering that
>the more efficient way of doing multiplication in an FPGA involves lookups,
>and ostensibly the sin and cosine require look=ups too, one simplification
>is to combine the LUTs.  If the required phase resolution is low, then you
>can use a "limited set constant multiplier" with partial product expansion.
>In other words, you'd have a partial products table driven by the outputs of
>the phase accumulator and subsets of the bits in the signal to be
>modulated.  You then need to add the partials together in an adder tree or
>scaling accumulator.  The approach depends on the data rate too.  This
>approach loses viability as the phase resolution, the input width and/or the
>data rate is increased.

Good idea. Always a trade off between speed/resolution/complexity can
be weighted to choose what I could do. I wanted to have 8bit phase
resolution for the Sin/Cos. Think that isn't too much high, but really
isn't small.

>Note also, the hardware needs to be duplicated for
>complex modulation.  Check the multiplier page under the DSP section of my
>website for a tutorial on multiplication in FPGAs.

I've been looking your pages and althought still under development
looks very nice, and clarified some of my doubts when looking at the
datasheets of the olds 74284/85 and 74261 chips with the multiply two
bits at a time. All the 'modern' digital electronics books I've or
seen, seems that forgot to talk enought about multiplication. And
nothing at all about complex vector/multiplication, althought being
near the same, or about other hardware algorithms so usefull when
you haven't a microprocessor.

I think that I was again doing it the long way, since I got 4 real
multiplications to get the product of two complex vectors: 

(a+bj)*(x+yj)=(ax-by)+(ay+bx)j

I forgot that Sin/Cos are orthogonal and with real/imaginary null.
So the modulation (AM/SSB/FM) can be done with two real
multiplications. Isn't it?

>The look up table modulator can be combined with a 2's complement and a
>controllable inversion on the phase input to take advantage of the symmetry
>in the sinusoid without making the table bigger.  Still, for most
>applications the look up table does not map well to an FPGA because of the
>small LUT size available.

I thought before to use only 1/4 of the Sin, or even less, doing an
aproximation with Sin(x)~x for the first degrees at the expense of
some distortion.
Right, with 4/5 input LUTs in the XC5202 there isn't much resolution
available without eating too much Logic Cells. That is why I was
asking about some way to generate the sinewave without an external
lookup table, and didn't knew if I was right.

>If you can lock your sample rate to 4x the modulation frequency, then the
>modulator becomes a mux and a controllable 2's complement because you can
>chose the phase angles of the sampled sinusoid  to be 0,90,180 and 270.
>This means that you are multiplying the input signal by the sequence
>1,0,-1,0,... for the I output and by 0,1,0,-1 for the Q output.

I thought about a digitized voice analog modulation signal, not
digital one, so any frecuency in the passband can be present at a
time. For digital modulation the way you describe seems to me
interesting.

>If you need more phase resolution, or can't lock the local oscillator to the
>sample clock and since you need a complex sinusoid, and you are modulating
>it, the best approach is a CORDIC rotator.  CORDIC is an iterative shift-add
>algorithm for rotating vectors in a plane.  This is essentially all that
>modulation by a complex sinusoid does.  Look on my website under the
>publications page for the "Survey of Cordic algorithms for FPGA based
>computers" paper for a tutorial on CORDIC with a slant toward FPGA
>implementation.  The number of CORDIC iterations will determine the phase
>resolution of your modulator.

I've downloaded the tutorial, and am going to read it. Seems very
powerfull, but not to read in a couple of minutes. Althought I'm
wondering if I could fit all in my very small fpga if using the CORDIC
algorithm, then I couldn't mix the Sin/Cos with the multiplier as you
sugest before, and think that probably will need the external LUT.

>The XC5000 series is not the best choice for DSP applications as its carry
>chain structure is quite weak (requires two CLBs for each bit in an adder).
>The 5202 only has an 8x8 array of CLBs, so you've got a maximum of 32bits of
>adds in it.  That ain't much; for higher data rates you'll find you need
>considerably more than that for any of the above approaches except the 4x
>modulation frequency one.  If your data rate requirement is really low, you
>might be able to fit a bit serial iterative CORDIC in there, but it will be
>really tight.  If you move to a spartan series device, you can get much
>higher data rates and much better utilization of the FPGA.  A 10 iteration
>pipelined CORDIC modulator with 12 bits of precision will easily fit in an
>XCS20 and can support sample rates better than 100MS/S with floorplanning.

I don't know much about fpga architecture, nor even digital design,
and choose Xilinx becouse in my enginnering school switched to they
and the Foundation F1.3 package was available. So I bought it.
Althought now I don't know how to upgrade mine to a newer version
without to buy the complete package again. And use the F1.4 of the
school.

I'm using the XC5202 becouse I've it. Isn't easy/cheap to buy single
unit quantities here. I'm really starting to do some a little more
complex than some state machines, and small designs that never filled
it. I agree that its very small, and the Spartan series fpgas are
cheap if one don't need to buy a full bar.

I only want to do voice grade modulation, with about 8Ks/s I will be
pretty happy, since could receive/demodulate with my ham equipment.
The 100Ms/s are many orders of magnitude over my thoughts!
So may be that a serial multiplication will be small/fast enought to
do it in the XC5202.

Searching the net I've just found the Analog Devices AD7008 that is
near what I want to get. Althought I strictly don't need to make
nothing practical, nor serious, becouse first I like to learn more, I
think that looking how it works in the real world will help me to
understand it much better, and may be have a good piece of my own
homebrewed equipment.

Probably should I begin building a DSS in the fpga first, using the
CORDIC to warm my head?

Again, thanks. I'm very gratefull for your comments.
73's de Luis

mail: melus@esi.us.es
Ampr: eb7gwl.ampr.org
http://www.esi.us.es/~melus/   <- Homebrewed Hardware Projects with PCBs
Article: 17448
Subject: Re: Xilinx Virtex Block Select RAM, is is reg or flow thru output
From: James Yeh <jiahau@uclink4.berkeley.edu>
Date: Wed, 28 Jul 1999 14:43:57 -0700
Links: << >>  << T >>  << A >>


Paul Butler wrote:

> Courtenay Johnson wrote in message <7nhis2$6q5$1@news.igs.net>...
> >
> >On the data sheet the terms "fully Sycnhronous" is used, but in another
> place it
> >states the it states "the data out bus reflects the memory cells referenced
> by
> >the address at the last active ckock edge.
> >
> >This last fact, plus the data sheet times of 3.3 ns of clock to output
> suggest
> >to me that this is a fow through output, (unregistered)
> >
>
> Contrariwise, this last fact, plus the data sheet times of any clock to
> output suggest to me that this is a registered output.  I think I
> misunderstand the question.
>
> I have found that questions like this are often answered quickest by
> simulating a test design.  I assume that the simulation models Xilinx
> provides are, if not timing accurate, at least functionally correct.
>

If you think you can simulate the BRAM,
Well to quote a Judas Priest song, "You gotta another thing comin."

>
> Paul Butler
> Paul.Butler@natinst.com

Article: 17449
Subject: Re: Digital modulator? Synthesisable Sin(x) funct.
From: Ray Andraka <randraka@ids.net>
Date: Wed, 28 Jul 1999 18:00:14 -0400
Links: << >>  << T >>  << A >>
At your low data rate, you could use an iterative serial CORDIC to do the
modulation.  In my CORDIC survey paper, (available on my website) I show an
example of a bit serial iterative CORDIC that fits in 22 CLBs in a xilinx 4K or
spartan device.  That one will handle bit rates over 100 Mb/sec in current
devices, so the possible data rates are much higher than your 8Ks/s needs.  It
doesn't map as nicely into the 5200 series because it uses the CLB RAM for the
shift registers.  Still, I think an iterative approach may fit into the 5202.

If you use the CORDIC approach, you don't need a multiplier!  The rotation mode
CORDIC takes an input vector and rotates it by a phase angle (also an input).  If
you feed the I component of the CORDIC input with your signal and the  component
with zero, then rotation by a moving phase angle will modulate the input signal.
CORDIC does have a gain of roughly A=1.65.  The CORDIC outputs are then:
        I = Axcos(p)      and  Q = Axsin(p)
where A=1.65, x is your real input (the q component is zero) and p is the phase
angle.  All you will need is the CORDIC rotator, control logic for the rotator
and a phase accumulator.  The iterative rotator needs 3 adder/subtractors and a
very small angle translation ROM.  If you make it bit serial, then the
adder-subtractors collapse to a single bit adder/subtracter.

You mentioned using the sin(x)=x approximation for small angles and a LUT for
larger angles.  Generally, you don't want to do this unless you have to.  It
introduces a data dependency on the processing, which makes the hardware
considerably more complex;  you wind up with more complicated control logic, data
decodes, and conditional data paths.  A solution that has all the data processed
the same way is much more elegant.

One more thing, check to make sure you can compile the 5200 series with F1.3.
I'm not sure the 5200 series is supported under M1.  You may have to use the old
xact6 software to use it.  You should be able to get the spartan parts in small
quantities from a reseller such as hamilton avnet.  Try http://www.avnet.com .
The foundation tools are upto 1.5i.  You should be able to download updates from
the web (although I'm not sure you can with the student edition).  Xilinx has
just released 2.1 which has added capabilities and improved PAR.

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




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