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 32375

Article: 32375
Subject: 2500ad 68HC05 assembler
From: Leon Willett <leonwillett@hotmail.com>
Date: Mon, 25 Jun 2001 16:31:47 +0200
Links: << >>  << T >>  << A >>
Hi,

My name's Leon Willett. I'm building an embedded system based on Bob
Moses' miditools computer, an I wonder if you could check something out.
The problem is, that 2500AD -- The company that made the 6805 assembler
and linker -- was bought by Avocet. The assembler then went through so
many updates and changes since Bob Moses used the software, over ten
years ago, that the original assembler-specific directives are no longer
respected.

Basically I'm really stuck, because I have no way of finishing my
project without the ancient software, which was discontinued in 1996.
This is because I am using Bob's own BIOS code, and just writing my own
application code -- which is the whole miditools concept.

Since the only way of obtaining it is second-hand, I wrote to Bob, and
asked if he would send me a copy of the assembler if he still had it
around, but he doesn't. This is why I'm posting this request. Do you
have an old copy of the 2500AD 68HC05 assembler and linker? Do you think
you could help?

Regards,

Leon Willett.


Article: 32376
Subject: Re: Date Code Problem?
From: Bob Perlman <bob@cambriandesign.com>
Date: Mon, 25 Jun 2001 15:26:45 GMT
Links: << >>  << T >>  << A >>
Hi - 

How much timing margin do you have?

Bob Perlman


On Mon, 25 Jun 2001 06:48:52 -0700, "Dan Briggs" <dbriggs@opex.com>
wrote:

>I am having a problem with XC95108 programmable part. The part has worked in the past 
without problem, but with the following date codes, the part doesn't
function properly. With date codes 0017, 0033, & 0037 I am recieving
varying degrees of failure. With the 0017 I have one output that
doesn't function and the output oscillates. With the other two I
cannot generate any outputs or read inputs. The parts verify using
both the Jtag in circuit programmer and a data I/O external
programmer. With date code 0001 the board functions without error. All
of the above stated problems occur with multiple samples of each date
code, the problem is repeatable with the various date codes. I am new
to the programmable device world, so any help in troubleshooting this
problem would be greatly appriciated. 
>
>Dan Briggs  Opex Corporation  dbriggs@opex.com


Article: 32377
Subject: Re: Date Code Problem?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 25 Jun 2001 09:04:14 -0700
Links: << >>  << T >>  << A >>
If this is a speed problem ( the part being either too slow or too fast for your specific
design) make the following simple tests:

Cool the part down as cold as you can ( -40 degr?, using cold spray).
If it works cold, you are expecting too much speed from the part. Examine your design.

Heat it up to over 100 degr C.
If it works then, you have designed poorly and rely on the part being slow ( race
conditions, hold time problems ) Analyze your design for bad asynchronous tricks.


Peter Alfke, Xilinx Applications
===============================
Bob Perlman wrote:

> Hi -
>
> How much timing margin do you have?
>
> Bob Perlman
>
> On Mon, 25 Jun 2001 06:48:52 -0700, "Dan Briggs" <dbriggs@opex.com>
> wrote:
>
> >I am having a problem with XC95108 programmable part. The part has worked in the past
> without problem, but with the following date codes, the part doesn't
> function properly.


Article: 32378
Subject: Re: Register balancing in FPGA Express
From: Alan Nishioka <alann@accom.com>
Date: Mon, 25 Jun 2001 09:29:47 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> I have a feeling that you mix up two things:
> Pipelining breaks up long combinatorial paths and inserts a flip-flop, so
> that tha clock can run faster.

It is my understanding that "re-timing" or "register balancing" is automatic
pipelining of large combinatorial blocks.

> If you do this indiscriminately, you may get into a situation where two
> branches of logic must meet, but they have different numbers of pipeline
> stages. You must compensate this and "balance" the number of flip-flops, so
> that the branches have the same number of pipeline delays. It's obvious if
> you think about it.

It is difficult for a human to keep track of the timing for a bunch of
different paths.  It is easy for a computer, however.  That is why I want the
compiler to do it for me.

My designs up to now are all pipelined by hand.  I was hoping to save some time
in the future, or squeeze a little more performance out of existing designs.

Are the tools able to do this?  Am I misunderstanding their capabilities?

Alan Nishioka
alann@accom.com



Article: 32379
Subject: Xilinx Spartan - Power Rail Related Timing Problem
From: "Gary Meakin" <gmeakin@compd.com>
Date: Mon, 25 Jun 2001 09:33:14 -0700
Links: << >>  << T >>  << A >>
I am using a Xilinx Spartan XCS40 (PQ208) FPGA running at 40MHz.

I am having problems with running a nubus interface design on this FPGA with the power rails approaching 5.00v. If the power rails are dropped to 4.80v then the design works.

When the voltage rail is slowly increased from 4.80v upto 5.00v parts of the design will stop working. If you reset the FPGA it sometimes starts working but will quickly stop functioning. I believe the timing in the FPGA is changing with the increased voltage on the rails but I cannot see why it is causing serious problems that I am experiencing.

Has anyone come across a similar problem or knows what might be going wrong with the FPGA when the power rail is increased?

Article: 32380
Subject: Re: IOB FF in Synplicity
From: Alan Nishioka <alann@accom.com>
Date: Mon, 25 Jun 2001 09:40:14 -0700
Links: << >>  << T >>  << A >>
With earlier versions of Synplicity, /*synthesis syn_useioff=1*/ worked for me.
With the latest version, I haven't been able to get it to work consistently.  Some
of my output FF's were turned into SRL16's because I had more than one FF in a row.

The only thing I could make work was to instantiate the output and input FF's
directly (ie. FD  FD0 ( output, input, clock ); several hundred times)

Unfortunately, this is just what you don't want to do.

Alan Nishioka
alann@accom.com



Article: 32381
Subject: Xilinx unified library
From: "ENapoli" <napoli@diesun.die.unina.it>
Date: Mon, 25 Jun 2001 18:49:42 +0200
Links: << >>  << T >>  << A >>
Can anyone suggest how to
insert the ADD8 component from the
XilinX unified library in a VHDL design?

Our target device is the XC4005XL fpga.

The ADD8 component is a macro and not
a primitive for XC4005XL devices.
As a consequence the straightforward inclusion
of the component ADD8 doesn't work.

Is it necessary to include the XilinX unified library explicitely?

Thank you for your attention,

E. Napoli
University of Napoli




Article: 32382
Subject: Re: IOB FF in Synplicity
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Mon, 25 Jun 2001 17:13:07 GMT
Links: << >>  << T >>  << A >>
Rick Collins wrote:
> 
> We are targeting a Xilinx XC4000 part and need to push some registers
> into the IOBs. We like to keep our designs vendor independant, so we
> prefer not to instantiate special features in the Verilog, such as IOB
> FFs.
> 
> I checked on the Xilinx web site and found that there is a directive to
> designate a register to be implemented in the IOB. The directive is /*
> synthesis IOB=TRUE */, and is placed in the reg declaration. This is
> claimed to work with Synplify and Xilinx Alliance. When this was tried,
> the FFs were still in the CLBs.
> 
> Does anyone have experience with what we are trying to do? Should we
> give up and instantiate the IOB FFs?

Rick,

As (the other) Rick says, don't instantiate, just tell the P+R tool to
use IOFFs.

For some reason, the option to use IOFFs is OFF by default.  Should be
ON, IMHO.

-andy

Article: 32383
Subject: Re: Xilinx Spartan - Power Rail Related Timing Problem
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 25 Jun 2001 19:17:41 +0200
Links: << >>  << T >>  << A >>
Gary Meakin schrieb:
> 
> I am using a Xilinx Spartan XCS40 (PQ208) FPGA running at 40MHz.
> 
> Has anyone come across a similar problem or knows what might be going wrong with the FPGA when the power rail is increased?

Looks like an asynchronous race condition, because the device is faster
with increased supply voltage.
As one of the NG gurus (here P.A. ;-) said, always test your design at
cold temperatures with high Vcc (fastes condition) and high temperature
with low Vcc (slowes condition). When the design fails at low
temperature/high Vcc, its an race condition problem, if it fails at high
temperature and low Vcc, the part (design) is to slow (too much delay in
the logic paths between the FFs).

-- 
MFG
Falk


Article: 32384
Subject: Re: Unisim Library Question?
From: Charles Ross <rossc@cs.colostate.edu>
Date: Mon, 25 Jun 2001 12:27:08 -0600
Links: << >>  << T >>  << A >>
Ray -

Thank you VERY much.  They were exactly where you said they were, and the
xilinx website showed me how to compile them in modelsim.  I appreciate the
help.

But now im hitting some new snags...

Context:
For synthesis We're using Synplify 6.2.0, and foundation 3.3ip8 for
Virtex1000 and Virtex200E based Annapolis Microsystem Boards.

Heres a small snippet of my vhdl code:

-- synthesis translate_off
Library UNISIM;
use UNISIM.all;
-- synthesis translate_on

entity TEST is

  -- snip (portmap)

end TEST;

architecture BEHAVIOR of TEST is

  -- snip (signal declarations etc.. )

  attribute syn_black_box : boolean;
  component M2_1B2
    port (
      S0 : in  std_logic;
      D0 : in  std_logic;
      D1 : in  std_logic;
      O  : out std_logic);
  end component;
  attribute syn_black_box of M2_1B2 : component is true;
begin

  --snip irrelivant vhdl

  testmux : M2_1B2 port map(S0 => select,
                                 D0 => a,
                                 D1 => b,
                                 O  => out);

  -- snip MORE irrelivant vhdl

end BEHAVIOR;


When I compile this in synplify, I get a little black box in the edf file...
But when I get down to the ngdbuild phase I get:

ERROR:NgdBuild:432 - logical block
   '........./textmux' with type 'M2_1B2' is
   unexpanded

-------------------

Heres my real questions:

Do I need to have anything in my synplify prj file (like the vhdl for the
unisim libraries)? or will simply using the component declarations in the vhdl
like above work?  Do I even need to include those compnent declarations?  Im
having nightmares down the road of making many entity which use of these
unisim compnents.  If I have to make the complete list of each of the
components I use in each entity, so be it... but I am hoping there is a nicer
way to do it.

I know I will need to include the (now precompiled) unisim library when doing
simulation, but im not positive that I can just ignore it completely in the
synthesis step.

Do I need to do anything at the level of the foundation tools to make them
find these components? or should they be there already?

Again... Sorry to be asking what are probably VERY basic questions, but you
have to start someplace.  Thanks again

Ray Andraka wrote:

> The unisim source should be in your xilinx install directory under
> $XILINX/vhdl/src/unisims.   You'll need to compile the library for your
> simulator.  There are instructions available in the answers database on the
> xilinx website.  If you can't find them there, I'm pretty sure you can
> download them from xilinx's website, but I'm not sure exactly where they
> are.    If you can't find them there, Aldec has them on their website under
> the downloads, although you should probably check the version, it may not
> be the latest.

--
          _____ _____
   ___   |     | __  |
  |___|  |   --|    -|
         |_____|__|__|




Article: 32385
Subject: Re: synplicity 6.2.4 'optimizing' instantiated designs
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Jun 2001 19:01:29 GMT
Links: << >>  << T >>  << A >>
I tried putting the syn_hier=hard on the mapped combinatorial logic, but it still breaks
it apart on me.  It is taking my mapped LUT, keeping that logic but with an input ties to
a constant, then producing a mux after the xorcy.  Putting the syn_hier on there keeps it
from optimizing off that input that is tied to a constant but does not prevent the
rearrangent of the logic.

Rotem Gazit wrote:

> I came across this problem about a month ago.
> The work around I found was to stuff the primitives in different sub
> Modules (I use Verilog) and use the Directive :
>   /* synthesis syn_hier = "hard " */ in the sub module declaration.
> Hope it helps,
> Rotem.
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3B32271D.7B7A6B17@andraka.com>...
> > Synplicity 6.2 is "optimizing" an instantiated design.  In particular, I
> >
> > have a design with instantiated Xilinx primitives including a carry
> > chain.  The synthesis is apparently flattening the xilinx primitives and
> >
> > doing its own optimization on them, which results in a multiplexer
> > placed between the xorcy and the flip-flop.  When I instantiate
> > primitives, I don't expect to see them remapped.  I didn't see this
> > happening in 5.3.1.  The instantiated primitives have a syn_black_box
> > attribute on them.   This new 'feature' makes Synplicity useless for the
> >
> > designs I am doing, and actually does damage for the large base I have
> > already fielded.
> >
> > Has anyone else seen this?  Any fixes?
>
> Rotem Gazit
> MystiCom LTD
> mailto:rotemg@mysticom.com
> http://www.mysticom.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



Article: 32386
(removed)


Article: 32387
Subject: Re: RAM_blocks inference in Leonardo Spectrum!
From: "Andrew Ince" <andrew.ince@gecm.com>
Date: Mon, 25 Jun 2001 19:08:15 -0000
Links: << >>  << T >>  << A >>
In our experience It is often due to a badly shaped RAM
e.g. 3 k deep is built with 3* 1k deep + logic (muxes?)

but 4k deep uses narrower 4k deep blocks but no logic
(It does use an extra 33% Blocks, but is much faster)

Andrew Ince

(P.S. sample numbers above for example only, not tested)



"Kevin VAZ" <vazkevin@hotmail.com> wrote in message
news:241f7389.0106202024.695ebff@posting.google.com...
> Dear Friends,
>
> I'am having problems in understanding if my design is infering block rams
or
> not.
>
> The device used is Vertex E 600ebg432
> the EDA is Leonardo Spectrum
> The design has 22 3Kbit ram instantiations
> yet reports after optimisation is 66CLB
> If rams are made black boxes report is 35CLB
>
> I would appreciate if any one can suggest a suitable solution.
> Thanks,
> Kevin.



Article: 32388
Subject: Re: IOB FF in Synplicity
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 25 Jun 2001 20:55:51 +0100
Links: << >>  << T >>  << A >>


Alan Nishioka wrote:

> With earlier versions of Synplicity, /*synthesis syn_useioff=1*/ worked for me.
> With the latest version, I haven't been able to get it to work consistently.  Some
> of my output FF's were turned into SRL16's because I had more than one FF in a row.
>

You could get around the SRL16 problem by putting some sort of set/reset on the FFs ? A
workaround I discovered for 6.1.3 (?) which was inferring an SRL16 for my
parallel-in/serial-out shift reg.

>
> The only thing I could make work was to instantiate the output and input FF's
> directly (ie. FD  FD0 ( output, input, clock ); several hundred times)
>
> Unfortunately, this is just what you don't want to do.
>

Maybe a perl script & include file would reduce the hassle ?

This Xilinx packing thing has caught me out so many times right from the start of using
Synplify that I'm now getting really pissed off with it. What's the point of having a
synth attribute if they don't do anything with it.

For Virtex the rules are very simple:

output reg - no feed-back and no post FF inversion.

input reg - no pre FF inversion.

bi-dir registered - both of the above + common clock(easy if its a global) + common
initialisation signal

The common init signal in the bi-dir case doesn't even have to do the same thing to
both FFs.

I think the only thing you have to add for XC4K is a common clock enable.

I turns out that the one Synplify breaks most often is the no-feedback rule.


Article: 32389
Subject: Re: Xilinx Spartan - Power Rail Related Timing Problem
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 25 Jun 2001 21:08:07 +0100
Links: << >>  << T >>  << A >>


Gary Meakin wrote:

> I am using a Xilinx Spartan XCS40 (PQ208) FPGA running at 40MHz.
>
> I am having problems with running a nubus interface design on this FPGA with the power rails approaching 5.00v. If the power rails are dropped to 4.80v then the design works.
>
> When the voltage rail is slowly increased from 4.80v upto 5.00v parts of the design will stop working. If you reset the FPGA it sometimes starts working but will quickly stop functioning. I believe the timing in the FPGA is changing with the increased voltage on the rails but I cannot see why it is causing serious problems that I am experiencing.
>
> Has anyone come across a similar problem or knows what might be going wrong with the FPGA when the power rail is increased?

Generally more volts => faster so you may have a hold time problem somewhere.

Questions you need to ask yourself:

1. How many clock domains are there ? If > 1 then check your domain crossing synchronisers. This also applies to any inputs that are async to the 40MHz clock.

2. What does the timing analyser say ?

3. Does your UCF have multi-cycle delay relaxations that are not justified.

What version of the s/w are you running ?



Article: 32390
Subject: black box instantiation in Spartan II Design
From: "Metin Yerlikaya" <metinnn@gmx.de>
Date: Mon, 25 Jun 2001 22:41:36 +0200
Links: << >>  << T >>  << A >>
Hi !
I'm using the Foundation Series 3.1 of Xilinx  and installed it with a
Target Device Spartan II Family.
It seems that LogiBLOX tool does not support this family.
If i try to add a new source to a Project , there is no LogicBLOX option but
Coregenerator. Also when i start the logiBlox tool alone, i can not choose
any Device
Family and SpartanII was the only Target Family i set during installation.
I want to instantiate a RAM Block in my design without having to write to
behavioral Code for it as Xilinx also suggests. "Never describe RAM
behaviorally in the HDL code, because combinatorial feedback paths will be
inferred."

How can i do this now ...i have edif file of the RAM Block i want to
instantiate.
Would it be enough to declare the Component and instantiate it , let the
tool create
a blackbox and everything will be fine during implementation phase ???

Any Reply appreciated !

Metin




Article: 32391
Subject: Re: what tools run OK on windows 2000?
From: sduncanae@yahoo.com (Steve Duncan)
Date: 25 Jun 2001 13:43:53 -0700
Links: << >>  << T >>  << A >>
Synopsys FPGA Compiler 2, version 3.6, released this month now
supports Windows 2000 in addition to 98 and NT.

Steve Duncan
Sales Support Engineer
Synopsys, Inc.

> Petter Gustad <newsmailcomp1@gustad.com> wrote in message > news:<871yo9fwkv.fsf@firewall.home.gustad.com>...
> Duane Clark <dclark@akamail.com> writes:
> 
> > Synopsis - Design Compiler and other tools. It is not clear whether they
> > are actually available yet, and I don't see prices.
> > http://www.synopsis.com/news/announce/press2000/linux_pr.html
> 
> I use Synopsys Design Compiler, PrimeTime, and VCS under Linux. The
> latter has been available for several years.
> 
> > Cadence - NCSim and other tools - US$5K (I think, the Cadence web site
> > is rather hard to use)
> > http://www.cadence.com/company/pr/04_17_00linux.html
> 
> I use Cadence Verilog XL under Linux - works great.
> 
> I have simulations running for weeks. I can't use Windows since it has
> to be booted all the time. A reboot is an accepted part of the
> installation procedure on Windows. Install a small utility program,
> and you have to reboot - three weeks worth of simulation has to be
> halted.
> 
> Petter

Article: 32392
Subject: Re: black box instantiation in Spartan II Design
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 25 Jun 2001 22:33:53 +0100
Links: << >>  << T >>  << A >>


Metin Yerlikaya wrote:

> Hi !
> I'm using the Foundation Series 3.1 of Xilinx  and installed it with a
> Target Device Spartan II Family.
> It seems that LogiBLOX tool does not support this family.
> If i try to add a new source to a Project , there is no LogicBLOX option but
> Coregenerator. Also when i start the logiBlox tool alone, i can not choose
> any Device
> Family and SpartanII was the only Target Family i set during installation.
> I want to instantiate a RAM Block in my design without having to write to
> behavioral Code for it as Xilinx also suggests. "Never describe RAM
> behaviorally in the HDL code, because combinatorial feedback paths will be
> inferred."
>
> How can i do this now ...i have edif file of the RAM Block i want to
> instantiate.
> Would it be enough to declare the Component and instantiate it , let the
> tool create
> a blackbox and everything will be fine during implementation phase ???
>
> Any Reply appreciated !
>
> Metin

Firstly you can get SpartanII macros from Coregen by setting the the family to
Virtex [SpartanII = cheap virtex].

Secondly as to the Xilinx comment

"Never describe RAM behaviorally in the HDL code, because combinatorial feedback
paths will be
inferred."

This is true for FPGA Express [all RAMs] but Synplify and Leonardo can at infer
the small select RAMs and at least some BlockRAM structures. I don't know what
the story is for XST.



Article: 32393
(removed)


Article: 32394
Subject: Re: XPower
From: John Hubbard <John.Hubbard@xilinx.com>
Date: Mon, 25 Jun 2001 16:07:18 -0600
Links: << >>  << T >>  << A >>
Phil,

I personally have performed correlation testing for the Xilinx CoolRunner XPLA3
CPLDs.  I have a test suite containing simple designs, more complex designs, and
very complex designs.  In all cases of the production released devices, >90% have
been within +/-10% accuracy with the remaining 10% within +/-20% accuracy.  I speak
only for the production released Xilinx CoolRunner XPLA3 CPLDs and will forward your
question to those devoted to the Xilinx FPGAs.

Thanks!
John


Phil Hays wrote:

> I've just today tried Xilinx's new power estimation tool, XPower.  XPower is
> "early access" software, which I think is a new code name for beta software.
> I'm working on a design with a tight power and cooling budget, and power
> estimation is difficult.  The measured difference between the spreadsheet
> estimates and the real hardware in my past designs has been 2:1, 4:1 or worse,
> which might lead to wildly over designed power supplies or worse.  With large
> power budgets in past designs, this hasn't been a problem for me, however this
> project is different.  While the answer I get from this tool is a lot closer to
> what I expect (and rather less than the spreadsheet estimate), and less than my
> power budget, I'm wondering how accurate this tool's results are.  Any XPower
> users that have verified results against real hardware care to speak out?
>
> This tool uses a simulation pattern out of ModelSim and the placed and routed
> design, so with a realistic simulation pattern I would expect a fairly realistic
> answer.
>
> If you haven't seen this tool yet, answer 10667 has a pointer to the download
> page, or search answers for for XPower.  Skip the GUI, it's gakky buggy, run in
> command line mode.
>
> --
> Phil Hays


Article: 32395
Subject: Re: Xilinx Configuration Bitstream
From: "Steve Casselman" <sc@vcc.com>
Date: Mon, 25 Jun 2001 16:01:34 -0700
Links: << >>  << T >>  << A >>
As far as I know Xilinx has published bitstream Information on the xc6200
line (now defunct) and some information on the Virtex family. The Virtex
information is in XAPP 151 "Virtex Configuration Architecture Advanced Users
Guide." We use that information to dynamically configure a target system
through the select map. We designed a microcoded state machine / controller
that consists of a single Block Ram and 20 CLBs in a Virtex or VirtexE. We
read a placed and routed design (.ncd) into what we call a "FPGA Browser"
where you can select a block ram. You can change that Ram while the Virtex
is running live. If that Ram is a controller ram you can pop up the "C" code
and edit that then download directly into the running Virtex system. It
takes less than 1 second to compile your code and download the resulting
partial configuration bitstream. The controller runs at 125 MHz. To use the
controller you connect the state bits up to Flip-flop clock enables and mux
controls and other control bits of your design (resets or what not). The
program then outputs bitstream data when connected live to a system or
INIT_xx style initialization data for the UCF file. What is great about this
approach (IMHO) is that you can change the behavior of your design without
changing the design itself (in that all routing and placement are held
constant just the data content of the ram is changed). We just showed this
at live at DAC where we were the only company doing partial reconfiguration.

Steve Casselman, President
Virtual Computer Corporation
www.vcc.com




"Alfredo Benso" <alfredo.benso@tiscalinet.it> wrote in message
news:9fgaom$opj$1@menelao.polito.it...
> Hi everybody,
> I am a researcher at Politecnico di Torino in Italy.
> I am looking for information about the format of the Xilinx configuration
> bit stream. Is the format public? Is there some document or file available
> explaining how to generate a stream of configuration bits for a Xiling
FPGA?
>
> Anybody can help?
>
> Thanks Alfredo
>
> ----ooo---ooo---ooo---ooo----
> BENSO Alfredo, PhD
>
> Politecnico di Torino
>
> Dip. Automatica e Informatica
>
> C.so Duca degli Abruzzi 24
>
> Torino - Italy
>
> Phone: +39-011-564.7080
>
> Fax: +39-011-564.7099
>
> email: alfredo.benso@polito.it
>
> ----------ooo---ooo-------------
>
>
>
>
>



Article: 32396
Subject: Re: XPower
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 25 Jun 2001 16:15:02 -0700
Links: << >>  << T >>  << A >>
You have to make sure that you simulate the average behavior of the circuit, not the
things you would normally like to simulate.
For example, you would normally not simulate the one million clock ticks of a 20-bit
counter. You would simulate it from shortly before to shortly after Terminal Count.
That's not the typical power consumption!

Sorry for this simplistic example ( counter power is actually very easy to estimate)
but I always point out the difficulty of determining "average" patterns.

Peter Alfke, Xilinx Applications

>
>
> Phil Hays wrote:
>
> >
> > This tool uses a simulation pattern out of ModelSim and the placed and routed
> > design, so with a realistic simulation pattern I would expect a fairly realistic
> > answer.
> > --
> > Phil Hays


Article: 32397
Subject: Re: Register balancing in FPGA Express
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Jun 2001 23:46:43 GMT
Links: << >>  << T >>  << A >>
Peter,

The retiming feature in synplicity is supposed to redistribute the registers in
a pipeline to equalize the delays between, so although putting the registers in
at the end of the pipe is meaningless by itself, when taken together with
retiming software, it provides the information the tools need to generate a
pipeline with the delays distributed between the combinatorial logic instead of
bunched up at the end.

Alan, I haven't tried the retimign feature in synplicity yet.  Synplicity will
reduce strings of flip-flops to SRL16's if they are simple flip-flops with no
resets.  You can keep it from doing that by putting a global reset on the FFs
or syn_preserve=true attributes on the intermediate signals.  I'm not sure if
the syn_preserve will work with the retiming, but that is where I'd probably
start.  As for the making timing worse, that is most likely because when
synplicity does convert flip-flops to SRL16's, it does it to all of them in the
chain.  The clock to out of the SRL16 is comparatively quite poor, which is not
really a problem if it is driving the d input of the flip-flop in the same
slice, but does add considerably to the delay if it is driving a different
flip-flop, because of the routing and LUT delays.  The proper way to use
SRL16's is to reduce the number of FF's by one and then feed the Q through an
FD or FDE.  Unfortunately, synplicity does not do that automatically.  It's a
shame since that flip-flop really can't be used for anything else anyway due to
routing restrictions.  Finally, I presume you are using synplify pro 6.2.4.  I
don't believe the 'amateur' version supports retiming. (I use the 'amateur'
version, I couldn't justify the additional cost of the Pro version for the type
of work I am doing).

Synplicity,  please read the above.  In future versions you should consider
changing the inference of an SRL16 to infer an SRL16 plus an FD to avoid the
clock to Q penalty.



Peter Alfke wrote:

> I have a feeling that you mix up two things:
> Pipelining breaks up long combinatorial paths and inserts a flip-flop, so
> that tha clock can run faster.
>
> If you do this indiscriminately, you may get into a situation where two
> branches of logic must meet, but they have different numbers of pipeline
> stages. You must compensate this and "balance" the number of flip-flops, so
> that the branches have the same number of pipeline delays. It's obvious if
> you think about it.
> And SRL16s are ideally suited to implement several cascaded flip-flops.
>
> Just cascading flip-flops at the end of a combinatorial chain is
> meaningless, unless it is needed for balancing purposes. You got the higher
> speed from breaking up the combinatorial chains...
>
> Peter Alfke, Xilinx Applications
> ================================
> Alan Nishioka wrote:
>
> > Does FPGA Express do register balancing?
> >
> > Synplicity calls this "retiming".  The idea is to take a large block of
> > combinatorial code and move registers into it to speed up the clock
> > speed.
> >
> > Then you would define a multiplier (for example) as a large
> > combinatorial block and simply add registers to the output until it
> > meets your timing requirement.
> >
> > I have seen this used in ASIC code, but I have not seen it work for
> > FPGA's.
> >
> > I have been trying to get Synplify Pro 6.2.4, which supports retiming,
> > to do this with no success.  When I add more than a couple of registers
> > to the output, it turns them into an SRL and makes it *slower*.
> >
> > I am using Xilinx XCV1000E, Synplify Pro 6.2.4, Xilinx Alliance 3.3.08i,
> > Win2K, Netscape 4.75, Red Hat Linux 5.2, Flash 5, Acrobat 4.0
> >
> > Alan Nishioka
> > alann@accom.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



Article: 32398
Subject: Re: IOB FF in Synplicity
From: Ray Andraka <ray@andraka.com>
Date: Tue, 26 Jun 2001 00:02:38 GMT
Links: << >>  << T >>  << A >>
Rick,

I don't bother with the synplify attribute for the IOs.  They don't seem to
work consistently, and frankly it isn't worth the time diddling around with
it when it is likely to change behavior in the next release.  The xilinx
mapper will push the FF's to the IOBs if you set the IOB FF's option
appropriately provided the rules are met for the IOB FFs.  That means no
feedback from output flip-flops and no inverters on the pin side of either
input or output.  The inputs should meet the rules in most cases.  For the
outputs, if it is a signal that is also used inside the FPGA, you need to
duplicate the flip-flop, one for the IOB and one for the internal signal .
The problem of course, is that synplify tends to merge that duplicated FF
back into one FF, or in the case of more than one FF in a chain, infers an
SRL16 (if there is no reset).  You can avoid the merging of duplicated FFs
by putting syn_keeps on the d inputs to the flip-flops (syn_preserve
doesn't seem to prevent merging ff's). That will also prevent merging of
the final FF into an SRL16.  The SRL16 inference can also be avoided by
putting a global reset on the flip-flops.


attribute syn_keep:boolean;
attribute syn_keep of iob_FF_d:signal is true;
attribute syn_keep of internal_FF_d:signal is true;

begin
iob_FF_d<=FF_d;
internal_FF_d<= FF_d;

process(clk)
begin
    if clk'event and clk='1' then
        iob_FF_q<=iob_ff_d;
        internal_ff_q<=internal_ff_d;
    end if;
end process;


Rick Collins wrote:

> We are targeting a Xilinx XC4000 part and need to push some registers
> into the IOBs. We like to keep our designs vendor independant, so we
> prefer not to instantiate special features in the Verilog, such as IOB
> FFs.
>
> I checked on the Xilinx web site and found that there is a directive to
> designate a register to be implemented in the IOB. The directive is /*
> synthesis IOB=TRUE */, and is placed in the reg declaration. This is
> claimed to work with Synplify and Xilinx Alliance. When this was tried,
> the FFs were still in the CLBs.
>
> Does anyone have experience with what we are trying to do? Should we
> give up and instantiate the IOB FFs?
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

--
-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



Article: 32399
Subject: Re: Unisim Library Question?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 26 Jun 2001 00:10:47 GMT
Links: << >>  << T >>  << A >>
The edif netlist black boxes have to either be xilinx primitives or must link to
another edif netlist for the black box.  The M2_1B2 unisim element is not a
primitive, rather it is a macro, therefore when it is instantiated, there must be
a matching netlist that can be linked from the edif netlist.  AFAIK, there are no
already compiled netlists for the unisim macros.  You can either compile these
yourself and put them in the same directory as your design edif netlist
(cumbersome at best), or you can avoid using anything other than unisim
primitives.  BTW, the library guide indicates which are primitives and which are
macros.

To do combinatorial logic, I put the (max 4 input) function in a separate VHDL
entity and include the synplicity xc_map attribute.  This essentially turns the
logic into a LUT, which you can then instantiate in your design as well as
decorate with user attributes for placement.  I find this is more readable and
less error prone than the alternative of using LUTs directly with an
initialization vector.



Charles Ross wrote:

> Ray -
>
> Thank you VERY much.  They were exactly where you said they were, and the
> xilinx website showed me how to compile them in modelsim.  I appreciate the
> help.
>
> But now im hitting some new snags...
>
> Context:
> For synthesis We're using Synplify 6.2.0, and foundation 3.3ip8 for
> Virtex1000 and Virtex200E based Annapolis Microsystem Boards.
>
> Heres a small snippet of my vhdl code:
>
> -- synthesis translate_off
> Library UNISIM;
> use UNISIM.all;
> -- synthesis translate_on
>
> entity TEST is
>
>   -- snip (portmap)
>
> end TEST;
>
> architecture BEHAVIOR of TEST is
>
>   -- snip (signal declarations etc.. )
>
>   attribute syn_black_box : boolean;
>   component M2_1B2
>     port (
>       S0 : in  std_logic;
>       D0 : in  std_logic;
>       D1 : in  std_logic;
>       O  : out std_logic);
>   end component;
>   attribute syn_black_box of M2_1B2 : component is true;
> begin
>
>   --snip irrelivant vhdl
>
>   testmux : M2_1B2 port map(S0 => select,
>                                  D0 => a,
>                                  D1 => b,
>                                  O  => out);
>
>   -- snip MORE irrelivant vhdl
>
> end BEHAVIOR;
>
> When I compile this in synplify, I get a little black box in the edf file...
> But when I get down to the ngdbuild phase I get:
>
> ERROR:NgdBuild:432 - logical block
>    '........./textmux' with type 'M2_1B2' is
>    unexpanded
>
> -------------------
>
> Heres my real questions:
>
> Do I need to have anything in my synplify prj file (like the vhdl for the
> unisim libraries)? or will simply using the component declarations in the vhdl
> like above work?  Do I even need to include those compnent declarations?  Im
> having nightmares down the road of making many entity which use of these
> unisim compnents.  If I have to make the complete list of each of the
> components I use in each entity, so be it... but I am hoping there is a nicer
> way to do it.
>
> I know I will need to include the (now precompiled) unisim library when doing
> simulation, but im not positive that I can just ignore it completely in the
> synthesis step.
>
> Do I need to do anything at the level of the foundation tools to make them
> find these components? or should they be there already?
>
> Again... Sorry to be asking what are probably VERY basic questions, but you
> have to start someplace.  Thanks again
>
> Ray Andraka wrote:
>
> > The unisim source should be in your xilinx install directory under
> > $XILINX/vhdl/src/unisims.   You'll need to compile the library for your
> > simulator.  There are instructions available in the answers database on the
> > xilinx website.  If you can't find them there, I'm pretty sure you can
> > download them from xilinx's website, but I'm not sure exactly where they
> > are.    If you can't find them there, Aldec has them on their website under
> > the downloads, although you should probably check the version, it may not
> > be the latest.
>
> --
>           _____ _____
>    ___   |     | __  |
>   |___|  |   --|    -|
>          |_____|__|__|

--
-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





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